From tim.one@home.com  Sun Apr  1 05:27:48 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 31 Mar 2001 23:27:48 -0500
Subject: [Python-Dev] nano-threads?
In-Reply-To: <20010326210824.B17390@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>

[Neil Schemenauer
 Tuesday, March 27, 2001 12:08 AM
]
> Here are some silly bits of code implementing single frame
> coroutines and threads using my frame suspend/resume patch.
> ...
> If your sick of such postings on python-dev flame me privately
> and I will stop.

Since the postings stopped there, did someone flame you?  I'm projecting my
own situtation onto everyone else, namely that this is interesting but I
can't make time for it now.  If you're still playing with this, though, I
hope you do continue to let Python-Dev know how it's going!

the-archives-house-many-wonders-ly y'rs  - tim



From fredrik@pythonware.com  Sun Apr  1 10:38:42 2001
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sun, 1 Apr 2001 11:38:42 +0200
Subject: [Python-Dev] nano-threads?
References: <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>
Message-ID: <044d01c0ba8f$8c0e4910$e46940d5@hagrid>

tim wrote:
> > If your sick of such postings on python-dev flame me privately
> > and I will stop.
> 
> Since the postings stopped there, did someone flame you?

well, I threatened to flame Neil if he stopped working on this...

Sorry /F



From fdrake@acm.org  Sun Apr  1 16:55:48 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Sun, 1 Apr 2001 11:55:48 -0400 (EDT)
Subject: [Python-Dev] Parro-DL -- new documentation project
Message-ID: <15047.20356.586507.158341@beowolf.pythonlabs.org>

Announcing a new joint documentation effort...


                                  Parro-DL

                        Parrot Documentation Language


With the public announcement of the development of Parrot (see
http://use.perl.org/article.pl?sid=01/03/31/206248 and
http://www.python.org/parrot.htm), a new documentation effort is being
initiated to provide developer information on the new language and its
libraries.

Guido van Rossum and Larry Wall, joint creators of the new language,
are both aware of the significance of quality documentation in the
adoption of Parrot.  Shortly after the decision to create Parrot, they
enlisted Fred Drake and Tom Christiansen to begin work on the
documentation system for Parrot.  The two advocates of language and
library documentation have collaborated privately for the past six
months to design a new markup language that can be embedded into the
language or used indepentently, similar to POD, but which allows
richer semantic markup similar to the LaTeX-based markup used by the
Python documentation project.

Drake and Christiansen expect to release the reference manual for the
new markup language, call Parro-DL (for "Parrot Documentation
Language") within two weeks.  The specification, which weighs in at
about 150 typeset pages, was written in Parro-DL and is processed by
new tools written using an early prototype interpreter for the Parrot
language.  The specification includes information on syntax,
linguistic integration, and processing expectations.  ISO
standardization is expected to be complete in 3rd quarter of 2006.

Drake and Christiansen are joining their efforts to organize a
documentation project dedicated to producing free documentation for
Parrot to avoid a monopoly on the reference documentation by the
technical publisher O'Reilly.  The effort will be subsidized by their
new joint venture, Iterpolated Documentation Systems.  Offices for the
new firm will be located in Chicago.  Drake's separation from
PythonLabs came as a surprise to his colleagues there.



  -Fred

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



From nas@python.ca  Sun Apr  1 18:51:50 2001
From: nas@python.ca (Neil Schemenauer)
Date: Sun, 1 Apr 2001 10:51:50 -0700
Subject: [Python-Dev] nano-threads?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>; from tim.one@home.com on Sat, Mar 31, 2001 at 11:27:48PM -0500
References: <20010326210824.B17390@glacier.fnational.com> <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>
Message-ID: <20010401105150.A9246@glacier.fnational.com>

Tim Peters wrote:
> Since the postings stopped there, did someone flame you?

No.

> I'm projecting my own situtation onto everyone else, namely
> that this is interesting but I can't make time for it now.

I got that impression.  I'll try to provoke some interest after
2.1 is released.  For now, I'm spending my spare time studying
stackless (among other things).

> If you're still playing with this, though, I hope you do
> continue to let Python-Dev know how it's going!

Okay.

  Neil


From jeremy@alum.mit.edu  Sun Apr  1 20:00:57 2001
From: jeremy@alum.mit.edu (Jeremy Hylton)
Date: Sun, 1 Apr 2001 15:00:57 -0400 (EDT)
Subject: [Python-Dev] Perl and Python to begin joint development
Message-ID: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>

[FYI:  This press release was also sent to c.l.py.a.  Dan and I expect
to have the release schedule PEP ready soon.  And, yes, that's Parrot
Enhancement Proposal (PEP). --jeremy]

04/01/2001
SEBASTOPOL, CA

Perl and Python to begin joint development

Larry Wall, the creator of Perl, and Guido van Rossum, creator of
Python, today announced that their respective projects are about to
begin a period of joint development. 

According to the language designers, the idea surfaced at last year's
Open Source Convention - "We at the Perl Conference were aware of a need
for a new direction for Perl and for its community, and that's why we
announced the work on Perl 6," said an excited Wall. "At the same time,
Guido was thinking very hard about Python 2.0 and where it was going,
and we got together and started talking about helping each other out."

Initially, the pair planned to have their development communities
working together for mutual benefit. van Rossum cited some of the
technical reasons for the collaboration: "Perl's highly powerful regular
expression engine would be integrated into Python, and would benefit us
greatly; in return, we've got a number of things right that Perl could
gain from, such as signal handling and robust software engineering."

However, as both designers talked about the changes their languages were
going through, they came to the conclusion that they had much to share
at the language level as well as the interpreter level. According to
Larry Wall, "Perl's always been about taking the best features of all
the other languages available; it's perfectly natural for us to
integrate the best features of Python too."

The specifications for the combined language, called Parrot, will be
documented in the forthcoming book "Programming Parrot In A Nutshell",
to be published by O'Reilly and Associates. In the meantime, the Python
Software Foundation is said to be making arrangements to merge with Yet
Another Society. YAS president Kevin Lenzo was delighted at the move:
"It's a natural extension of what YAS was set up to facilitate -
collaboration and communication between programming communities."

Parrot development will begin with the merger of the Py3K development
team with the Perl 6 internals working group; Jeremy Hylton and Dan
Sugalski will be the joint development leads.

Larry Wall and Guido van Rossum both accepted positions at the Vancouver,
Canada development company ActiveState. A spokesman for ActiveState said
that the company was obviously very pleased with the decision, but
denied that ActiveState had influenced it in any way.


From jeremy@alum.mit.edu  Sun Apr  1 20:27:34 2001
From: jeremy@alum.mit.edu (Jeremy Hylton)
Date: Sun, 1 Apr 2001 15:27:34 -0400 (EDT)
Subject: [Python-Dev] Re: Perl and Python to begin joint development
In-Reply-To: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>
References: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <15047.33062.39302.211557@w221.z064000254.bwi-md.dsl.cnc.net>

It seems that the folks at O'Reilly are working overtime this weekend.
The Parrot book announcement, which I didn't expect to see until
mid-week, is already available at http://www.ora.com.

You can also read an interview with Guido and Larry Wall at
http://www.perl.com.

Barry should be checking in PEP 250 (Parrot Release Schedule) as soon
as he converts it from POD to the PEP format.  

Jeremy


From barry@digicool.com  Mon Apr  2 03:39:40 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Sun, 1 Apr 2001 22:39:40 -0400
Subject: [Python-Dev] Re: Perl and Python to begin joint development
References: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>
 <15047.33062.39302.211557@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <15047.58988.606995.260675@anthem.wooz.org>

>>>>> "JH" == Jeremy Hylton <jeremy@alum.mit.edu> writes:

    JH> Barry should be checking in PEP 250 (Parrot Release Schedule)
    JH> as soon as he converts it from POD to the PEP format.

Sorry, I think that's going to be PEP 0401 instead.

-Barry


From Paul.Moore@uk.origin-it.com  Mon Apr  2 10:09:07 2001
From: Paul.Moore@uk.origin-it.com (Moore, Paul)
Date: Mon, 2 Apr 2001 10:09:07 +0100
Subject: [Python-Dev] PEP: Use site-packages on all platforms
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADDB@ukrux002.rundc.uk.origin-it.com>

From: Guido van Rossum [mailto:guido@digicool.com]
> 
> I think this is a good idea.  Submit the PEP to Barry!

Done.

> I doubt that we can introduce this into Python 2.1 this late in the
> release cycle.  Would that be a problem?

I thought as much. I can't see it being a major issue. My only concern (as
noted in the PEP) is that with distutils becoming more commonly used, there
will be more and more packages installed using distutils, and so ending up
in the directory which distutils uses by default. The longer it is before
the change is made, the more of a mixed setup people will have. But then
again, (a) the change is backward-compatible, and (b) extension modules will
need recompiling (and reinstalling) anyway. So no, 2.2 seems OK.

Hmm, that does raise one issue - if people rebuild and reinstall after the
change, the reinstall won't overwrite the old version. As a consequence,
there will be an old version on sys.path, with the potential for a crash...
Of course, people should uninstall before reinstalling, so it shouldn't be a
problem. Making distutils search for old versions would be possible, but it
seems like major overkill...

I'll assume this is for 2.2, and that the reinstall-not-overwriting problem
isn't an issue. I'll note the details in the PEP.

Paul.


From thomas.heller@ion-tof.com  Mon Apr  2 18:02:11 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Mon, 2 Apr 2001 19:02:11 +0200
Subject: [Python-Dev] Making types behave like classes
References: <3ABBF553.274D535@ActiveState.com>
Message-ID: <052a01c0bb96$a8b1b180$e000a8c0@thomasnotebook>

> These are some half-baked ideas about getting classes and types to look
> more similar.

Somewhat different thoughts:

Which limitations are there in python as a consequence
of the type/class split?

In python code itself, it is not too bad. Instead of deriving
from builtin types, you can always delegate to them.

In c-code, the situation is worse, on the other hand,
ExtensionClass comes to rescue. Write the base class in C,
subclass in python.

The worst limitation is in the most useful builtin object:
the dictionary. One can use or derive from UserDict,
but one cannot pass UserDict instances or other homegrown dict
lookalikes to exec, you cannot use them as class or instance
dictionaries.

If this limitation would be removed, you could implement your
own rules in namespaces: readonly, case insentitive, whatever.
One could even implement a mapping object in a C extension,
and use it in the aforementioned ways.

IMO this limitation would be easy to remove:
The current PyDict_* API could be implemented in terms of
the PyMapping_ and PyObject_ protocol, using different code
depending on the outcome of an additional PyDict_Check() test.

The performance hit would be rather small.

Thomas



From pf@artcom-gmbh.de  Tue Apr  3 00:19:33 2001
From: pf@artcom-gmbh.de (Peter Funk)
Date: Tue, 3 Apr 2001 01:19:33 +0200 (MEST)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
Message-ID: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de>

At the moment it is very silent on Python-dev.  I guess you guys are
all out hunting dead parrots, which escaped from the cages on April 1st. ;-)

So this might be the right moment to present a possibly bad idea (TM).
see below.
Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen, Germany)

PEP: XXXX
Title: String Scanning
Version: $Revision$
Author: pf@artcom-gmbh.de (Peter Funk)
Status: Not yet Draft
Type: Standards Track
Python-Version: 2.2 
Created: 02-Apr-2001
Post-History:

Abstract

    This document proposes a string scanning feature for Python to
    allow easier string parsing.  The suggested syntax change is to
    allow the use of the division '/' operator for string operands
    as counterpart to the already existing '%' string interpolation
    operator.  In current Python this raises an exception: 'TypeError:
    bad operand type(s) for /'.  With the proposed enhancement the
    expression string1 / format2 should either return a simple value,
    a tuple of values or a dictionary depending on the content of
    the right operand (aka. format) string.


Copyright

    This document is in the public domain.


Specification

    The feature should mimic the behaviour of the scanf function
    well known to C programmers.  For any format string sf and any
    matching input string si the following pseudo condition should 
    be true:

        string.split( sf % (si / sf) ) == string.split( si )

    That is modulo any differences in white space the result of the
    string interpolation using the intermediate result from the string
    scanning operation should look similar to original input string.

    All conversions are introduced by the % (percent sign) character.  
    The format string may also contain other characters.  White space 
    (such as blanks, tabs, or newlines) in the format string match any  
    amount of white space, including none, in the input.  Everything
    else matches only itself.  Scanning stops when an input character  
    does not match such a format character.  Scanning also stops when 
    an input conversion cannot be made (see below).


Examples

    Here is an example of an interactive session exhibiting the
    expected behaviour of this feature.

        >>> "12345 John Doe" / "%5d %8s"
        (12345, 'John Doe')
        >>> "12 34 56 7.890" / "%d %d %d %f"
        (12, 34, 56, 7.8899999999999997)
        >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
        {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
        >>> "1 2" / "%d %d %d"
        Traceback (innermost last):
          File "<stdin>", line 1, in ?
        TypeError: not all arguments filled


Discussion

    This should fix the assymetry between arithmetic types and strings.
    It should also make the life easier for C programmers migrating to
    Python (see FAQ 4.33).  Those poor souls are acustomed to scanf
    as the counterpart of printf and usually feel uneasy to convert
    to string slitting, slicing or the syntax of regular expressions.


Security Issues

    There should be no security issues.


Implementation

    There is no implementation yet.  This is just an idea.
   


Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:



From guido@digicool.com  Tue Apr  3 02:43:24 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 02 Apr 2001 20:43:24 -0500
Subject: [Python-Dev] Python9 footage on www.technetcast.com
Message-ID: <200104030143.UAA04839@cj20424-a.reston1.va.home.com>

Dr. Dobb's technetcast is playing audio and video footage from
Python9: video of a brief interview with me, and (coming up next?)
audio from the two keynotes (Bruce Eckel's and mine).  Go to

    www.technetcast.com

(RealAudio support required, I believe.)

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


From guido@digicool.com  Tue Apr  3 02:51:06 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 02 Apr 2001 20:51:06 -0500
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: Your message of "Tue, 03 Apr 2001 01:19:33 +0200."
 <m14kDbi-000CnFC@artcom0.artcom-gmbh.de>
References: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <200104030151.UAA04918@cj20424-a.reston1.va.home.com>

Peter, if you can do a prototype implementation (in Python would be
best), the idea might be received better.

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


From paulp@ActiveState.com  Tue Apr  3 02:06:49 2001
From: paulp@ActiveState.com (Paul Prescod)
Date: Mon, 02 Apr 2001 18:06:49 -0700
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
References: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <3AC92229.A5566E6A@ActiveState.com>

Peter Funk wrote:
> 
> 
>         >>> "12345 John Doe" / "%5d %8s"
>         (12345, 'John Doe')
>         >>> "12 34 56 7.890" / "%d %d %d %f"
>         (12, 34, 56, 7.8899999999999997)
>         >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
>         {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
>         >>> "1 2" / "%d %d %d"
>         Traceback (innermost last):
>           File "<stdin>", line 1, in ?
>         TypeError: not all arguments filled

I would prefer "foo".scanf("%5d %8s") or maybe "parse" or "parseformats"
or something like that. I know that punctuation abuse leads inexorably
to further punctuation abuse but the cycle must stop somewhere. It's too
late for "%" but let's save "/" while we still can!
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook


From thomas@xs4all.net  Tue Apr  3 08:09:28 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Tue, 3 Apr 2001 09:09:28 +0200
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <3AC92229.A5566E6A@ActiveState.com>; from paulp@ActiveState.com on Mon, Apr 02, 2001 at 06:06:49PM -0700
References: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de> <3AC92229.A5566E6A@ActiveState.com>
Message-ID: <20010403090928.A2820@xs4all.nl>

On Mon, Apr 02, 2001 at 06:06:49PM -0700, Paul Prescod wrote:
> Peter Funk wrote:

> >         >>> "12345 John Doe" / "%5d %8s"
> >         (12345, 'John Doe')
> >         >>> "12 34 56 7.890" / "%d %d %d %f"
> >         (12, 34, 56, 7.8899999999999997)
> >         >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
> >         {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
> >         >>> "1 2" / "%d %d %d"
> >         Traceback (innermost last):
> >           File "<stdin>", line 1, in ?
> >         TypeError: not all arguments filled

> I would prefer "foo".scanf("%5d %8s") or maybe "parse" or "parseformats"
> or something like that. I know that punctuation abuse leads inexorably
> to further punctuation abuse but the cycle must stop somewhere. It's too
> late for "%" but let's save "/" while we still can!

Agreed, on both issues. We don't have 'printf', lets not use something as
inexplicable as 'scanf'!

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From pf@artcom-gmbh.de  Tue Apr  3 09:35:02 2001
From: pf@artcom-gmbh.de (Peter Funk)
Date: Tue, 3 Apr 2001 10:35:02 +0200 (MEST)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <200104030151.UAA04918@cj20424-a.reston1.va.home.com> from Guido van Rossum at "Apr 2, 2001  8:51: 6 pm"
Message-ID: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>

Guido van Rossum:
> Peter, if you can do a prototype implementation (in Python would be
> best), the idea might be received better.

I believe a strawman derived from the UserString class could be done
in pure Python.  But I'm sorry: I've no time for this during April.

I'm also not sure, whether this is really a worthwile effort and whether
I should champion this idea further.  From Pauls response I got the
impression that people already consider the '%' string interpolation
operator as a language wart rather than an elegant feature.

I however often like the infix notation better.  
That may be a matter of taste.  Imagine we would have to write:
	"%5d %20s %s\n".printf((num, name, adr))
instead of
	"%5d %20s %s\n" % (num, name, adr)
I'm happy, that this is not the case in todays Python.

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen, Germany)



From guido@digicool.com  Tue Apr  3 13:12:50 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 03 Apr 2001 07:12:50 -0500
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: Your message of "Tue, 03 Apr 2001 10:35:02 +0200."
 <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <200104031212.HAA06304@cj20424-a.reston1.va.home.com>

> > Peter, if you can do a prototype implementation (in Python would be
> > best), the idea might be received better.
> 
> I believe a strawman derived from the UserString class could be done
> in pure Python.  But I'm sorry: I've no time for this during April.

Oh well, maybe someone else will like the idea.

> I'm also not sure, whether this is really a worthwile effort and whether
> I should champion this idea further.  From Pauls response I got the
> impression that people already consider the '%' string interpolation
> operator as a language wart rather than an elegant feature.

Well, that was one response.  Besides, it's easy to factor out two
separate design decisions: (1) a string scanning mechanism that takes
two strings (a format and an input string) and returns one or more
values extracted from the input string according to the rules set by
the format string, and (2) how to spell this: scanf(format, input) or
format/input or input/format or whatever.

> I however often like the infix notation better.  

See my two examples above for a concern: already I cannot recall
whether your PEP proposes format/input or input/format.  That's a bad
sign for either spelling. :-)

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


From pf@artcom-gmbh.de  Tue Apr  3 12:44:00 2001
From: pf@artcom-gmbh.de (Peter Funk)
Date: Tue, 3 Apr 2001 13:44:00 +0200 (MEST)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <200104031212.HAA06304@cj20424-a.reston1.va.home.com> from Guido van Rossum at "Apr 3, 2001  7:12:50 am"
Message-ID: <m14kPE8-000CnFC@artcom0.artcom-gmbh.de>

Guido van Rossum:
[...]
> Well, that was one response.  Besides, it's easy to factor out two
> separate design decisions: (1) a string scanning mechanism that takes
> two strings (a format and an input string) and returns one or more
> values extracted from the input string according to the rules set by
> the format string, and (2) how to spell this: scanf(format, input) or
> format/input or input/format or whatever.
> 
> > I however often like the infix notation better.  
> 
> See my two examples above for a concern: already I cannot recall
> whether your PEP proposes format/input or input/format.  That's a bad
> sign for either spelling. :-)

Hmmm.... May be I've stressed the analogy to arithmetic a bit to far:

If the string interpolation operator were '*' instead of '%'
then you could think of "multiplying" a format string with one
or more values gives a result string which than represents some kind of
"product".  Taking this result string now as input to the scanning
operation is some kind of "division" reverting the previous string
interpolation operation.  From that POV it would be pretty obvious,
that "dividing" the input string by the format string as denominator
returns the values previously formatted into it.

But since the string interpolation operator is '%' the analogy from
multiplication to formatting is obviously not at all that obvious.  :-(

Regards, Peter



From michel@digicool.com  Tue Apr  3 18:54:24 2001
From: michel@digicool.com (Michel Pelletier)
Date: Tue, 3 Apr 2001 10:54:24 -0700 (PDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.LNX.4.32.0104031052400.11179-100000@localhost.localdomain>

On Tue, 3 Apr 2001, Peter Funk wrote:

> I'm also not sure, whether this is really a worthwile effort and whether
> I should champion this idea further.  From Pauls response I got the
> impression that people already consider the '%' string interpolation
> operator as a language wart rather than an elegant feature.

It is one seriously useful wart!

> I however often like the infix notation better.
> That may be a matter of taste.  Imagine we would have to write:
> 	"%5d %20s %s\n".printf((num, name, adr))
> instead of
> 	"%5d %20s %s\n" % (num, name, adr)
> I'm happy, that this is not the case in todays Python.

Agreed.  I like your proposal.

-Michel



From paul@pfdubois.com  Wed Apr  4 00:22:32 2001
From: paul@pfdubois.com (Paul F. Dubois)
Date: Tue, 3 Apr 2001 16:22:32 -0700
Subject: [Python-Dev] Re: s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <E14kTFV-0001wa-00@mail.python.org>
Message-ID: <ADEOIFHFONCLEEPKCACCMEKACHAA.paul@pfdubois.com>

Well, as usual I have a complete lack of aesthetic judgment because *I*
thought it was a great idea.

I could just picture my scientists parsing input lines from data files with
it. A similar feature in Basis is heavily used.

Then again, I *love* s % f. See, I'm totally sick.



From paulp@ActiveState.com  Wed Apr  4 00:45:54 2001
From: paulp@ActiveState.com (Paul Prescod)
Date: Tue, 03 Apr 2001 16:45:54 -0700
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <3ACA60B2.6B09B36D@ActiveState.com>

Peter Funk wrote:
> 
> ...
> 
> I however often like the infix notation better.
> That may be a matter of taste.  Imagine we would have to write:
>         "%5d %20s %s\n".printf((num, name, adr))
> instead of
>         "%5d %20s %s\n" % (num, name, adr)
> I'm happy, that this is not the case in todays Python.

Either way it is infix (as opposed to prefix or postfix). The question
is whether it is an infix *operator* or a method.

I believe that the only thing aesthetically wrong with this:

"%5d %20s %s\n".insert(num, name, adr)

is that people are not "used" to seeing method invocations on literal
strings. But then new Python programmers are not used to seeing people
divide or mod strings either!

And the nice thing about using a method name is that you can look method
names up in the indexes of books easily and even guess the meaning of
them from their English meanings. Symbols are (IMHO) best reserved for
usages where their meanings are already set by real-world convention.
(i.e. 5+3!)

If some other language convinces millions of programmers that string
division is natural then we could follow suit but I'd rather not lead
the way.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook


From tim.one@home.com  Wed Apr  4 01:05:50 2001
From: tim.one@home.com (Tim Peters)
Date: Tue, 3 Apr 2001 20:05:50 -0400
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>

[Peter Funk]
> I believe a strawman derived from the UserString class could be done
> in pure Python.  But I'm sorry: I've no time for this during April.

sscanf for Python gets reinvented like clockwork; e.g., see

ftp://ftp.python.org/pub/python/
    contrib-09-Dec-1999/Misc/sscanfmodule.README

for 1995's version of this crusade.

> I'm also not sure, whether this is really a worthwile effort and
> whether I should champion this idea further.  From Pauls response I
> got the impression that people already consider the '%' string
> interpolation operator as a language wart rather than an elegant
> feature.

Not me!  Infix "%" is great.  But while "%" was mnemonic for the heavy use of
"%" in format strings, "/" doesn't say anything to me.  Combine that with the
relative infrequency of sscanf vs sprintf calls (in C code, Perl code, or (I
sure suspect) in Python code too), and I'm -1 on infix "/" for sscanf.

Making it a method of the format string would be fine (why the format string?
because capturing a bound method object like

    parse3d = "%d %d %d".whatever

would be darned useful, but the other way wouldn't be).

Finally, since .scanf() is a rotten method name (like .join() before it, it
doesn't make clear which operand is scanned and which format), try something
like format.scanning(string) instead.

language-design-is-easy<wink>-ly y'rs  - tim



From jeremy@alum.mit.edu  Wed Apr  4 02:17:42 2001
From: jeremy@alum.mit.edu (Jeremy Hylton)
Date: Tue, 3 Apr 2001 21:17:42 -0400 (EDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
 <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
Message-ID: <15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "TP" == Tim Peters <tim.one@home.com> writes:

  TP> Making it a method of the format string would be fine (why the
  TP> format string?  because capturing a bound method object like

  TP>     parse3d = "%d %d %d".whatever

  TP> would be darned useful, but the other way wouldn't be).

  TP> Finally, since .scanf() is a rotten method name (like .join()
  TP> before it, it doesn't make clear which operand is scanned and
  TP> which format), try something like format.scanning(string)
  TP> instead.

My preference would be to have a separate module with the necessary
support.  It sure would be easy to add to the language.

I imagine something like this:

import fileinput
import scanf

fmt = scanf.Format("%d %d %d")
for line in fileinput.intput():
    mo = fmt.scan(line)
    if mo:
        print mo.group(1, 2, 3)

Jeremy


From skip@pobox.com (Skip Montanaro)  Wed Apr  4 02:19:50 2001
From: skip@pobox.com (Skip Montanaro) (Skip Montanaro)
Date: Tue, 3 Apr 2001 20:19:50 -0500 (CDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
 <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
Message-ID: <15050.30390.69707.3375@beluga.mojam.com>

    Tim> Finally, since .scanf() is a rotten method name (like .join()
    Tim> before it, it doesn't make clear which operand is scanned and which
    Tim> format), try something like format.scanning(string) instead.

Hmmm... If method names are the way to go, I'd much rather we found a more
active verb name than "scanning".  How about "extract" or "slice"?  Even
simply "scan" sounds better to me.

Back to the infix operator idea, I agree with Peter on the one hand that
there's a certain symmetry to using infix "/" and with the opposing camp
that the only reason "%" works for emitting strings is the use of C's %
format character.  "*" sort of suggests exploding... ;-)

Skip





From skip@pobox.com (Skip Montanaro)  Wed Apr  4 02:22:10 2001
From: skip@pobox.com (Skip Montanaro) (Skip Montanaro)
Date: Tue, 3 Apr 2001 20:22:10 -0500 (CDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
 <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
 <15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <15050.30530.466650.219047@beluga.mojam.com>

    Jeremy> I imagine something like this:

    Jeremy> import fileinput
    Jeremy> import scanf

    ...

Placing the functionality in a module is fine as well, but again, "scanf"
only means something if you've programmed in C before.  I suspect there are
college students graduating from CS departments now who have used C++ but
not C and wouldn't have the slightest idea what "scanf" means.

Skip


From jeremy@alum.mit.edu  Wed Apr  4 02:39:28 2001
From: jeremy@alum.mit.edu (Jeremy Hylton)
Date: Tue, 3 Apr 2001 21:39:28 -0400 (EDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <15050.30530.466650.219047@beluga.mojam.com>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
 <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
 <15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>
 <15050.30530.466650.219047@beluga.mojam.com>
Message-ID: <15050.31568.301926.504672@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "SM" == Skip Montanaro <skip@pobox.com> writes:

  Jeremy> I imagine something like this:

  Jeremy> import fileinput import scanf

  SM>     ...

  SM> Placing the functionality in a module is fine as well, but
  SM> again, "scanf" only means something if you've programmed in C
  SM> before.  I suspect there are college students graduating from CS
  SM> departments now who have used C++ but not C and wouldn't have
  SM> the slightest idea what "scanf" means.

I don't care much about the name.  scanf is fine with me ("scan with
format") but so is "scan" -- or "parrot."

I do care about it being based on a module rather than a builtin
operator or a string method.  I see scanf-based scanning as roughly
equivalent to regular expressions, which live happily in a module.

If we're going to add a scan method to strings, I can imagine people
wanting "\d+".re_match() and "\d+".re_search() methods on strings,
too. 

Jeremy


From Jason.Tishler@dothill.com  Wed Apr  4 15:20:11 2001
From: Jason.Tishler@dothill.com (Jason Tishler)
Date: Wed, 4 Apr 2001 10:20:11 -0400
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
Message-ID: <20010404102011.L63@dothill.com>

Recently significant pthreads support has been added to Cygwin.  When I
attempted to build a Cygwin Python with threads, I got the following
compilation error:

    gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Python/pythonrun.o Python/pythonrun.c
    In file included from /usr/include/signal.h:8,
                     from Python/pythonrun.c:21:
    /usr/include/sys/signal.h:162: parse error before `thread'

Cygwin's sys/signal has the following at line 162:

    #if defined(_POSIX_THREADS)
    int _EXFUN(pthread_kill, (pthread_t thread, int sig));
    #endif

The author of the recent Cygwin pthreads enhancements states that
_POSIX_THREADS is a kernel level #define and should not be defined in
user level code.  Please see the following for his reasoning:

    http://sources.redhat.com/ml/cygwin/2001-03/msg01693.html

Unfortunately, I am not knowledgeable is this area.  Can someone please
confirm or refute the above claim?

If it is concluded that Python should not #define _POSIX_THREADS, then I
am willing to generate a patch to substitute _POSIX_THREADS with a more
benign symbol in the less than 20 occurrences that my grep-ing found.
Any suggestions on what to call this new symbol?

Will such a patch be considered this late in the release cycle?  Or,
should I hold off until after 2.1 final?  If the patch is accepted into
2.1, then users can get a Cygwin Python with thread support without
having to wait for 2.2 or working off of CVS.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com


From Jason.Tishler@dothill.com  Wed Apr  4 18:34:46 2001
From: Jason.Tishler@dothill.com (Jason Tishler)
Date: Wed, 4 Apr 2001 13:34:46 -0400
Subject: [Python-Dev] Re: Case-sensitive import
In-Reply-To: <20010228151728.Q449@dothill.com>; from Jason.Tishler@dothill.com on Wed, Feb 28, 2001 at 03:17:28PM -0500
References: <20010228120229.M449@dothill.com> <LNBBLJKPBEHFEDALKOLCMELLJCAA.tim.one@home.com> <20010228151728.Q449@dothill.com>
Message-ID: <20010404133446.T63@dothill.com>

Tim,

On Wed, Feb 28, 2001 at 03:17:28PM -0500, Jason Tishler wrote:
> On Wed, Feb 28, 2001 at 12:36:45PM -0500, Tim Peters wrote:
> > Jason, about this:
> > 
> >     However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will
> >     require one to configure with:
> > 
> >         CC='gcc -mwin32' configure ...
> > 
> > How can we make that info *useful* to people?
> 
> I have posted to the Cygwin mailing list and C.L.P regarding my original
> 2.0 patches.  I have also continue to post to Cygwin regarding 2.1a1 and
> 2.1a2.  I intended to do likewise for 2.1b1, etc.
> 
> > The target audience for the
> > Cygwin port probably doesn't search Python-Dev or the Python patches
> > database.
> 
> Agreed -- the above was only offered to the curious Python-Dev person
> and not for archival purposes.
> 
> > So it would be good if you thought about uploading an
> > informational patch to README and Misc/NEWS briefly telling Cygwin folks
> > what they need to know.  If you do, I'll look for it and check it in.
> 
> I will submit a patch to README to add a Cygwin section to "Platform
> specific notes".  Unfortunately, I don't think that I can squeeze it in
> by 2.1b1.  If not, then I will submit it for the next release (2.1b2 or 2.1
> final).  I also don't mind waiting for the Cygwin gcc stuff to settle
> down too.  I know...excuses, excuses...

As promised:

    http://sourceforge.net/tracker/index.php?func=detail&aid=413750&group_id=5470&atid=305470

Note that the following goofiness:

    CC='gcc -mwin32' configure ...

is no longer needed.

Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com


From m.favas@per.dem.csiro.au  Wed Apr  4 20:19:44 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Thu, 05 Apr 2001 03:19:44 +0800
Subject: [Python-Dev] Little hits add up...
Message-ID: <3ACB73D0.DD94C59F@per.dem.csiro.au>

Since it's a quiet time on python-dev at the moment <grin>, I thought
I'd just toss this bedraggled parrot in...
Every now and then, the comment arises "this <enhancement X> should only
incur a small performance hit". I just ran one of my apps under 1.5.2+
and 2.1b2. The little hits along the way have here added up to a 26%
slowdown. Around the time 2.0 was released, there was a brief thread
along the lines of "let's get 2.0 out the door, and tune it up in 2.1 -
there's some low-hanging fruit about". Any chance we could get someone
like Christian and Tim wound up on looking at performance issues,
however briefly <wink>? (I know, they don't have time - I just
remembered the old days on c.l.py when they'd try to outdo each other
with weird and wonderful optimizations.) This is not a flame at 2.x, BTW
- 2.x is a good thing! (BTW, gc.disable() improved things by 3%.)
-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From nas@python.ca  Wed Apr  4 20:34:15 2001
From: nas@python.ca (Neil Schemenauer)
Date: Wed, 4 Apr 2001 12:34:15 -0700
Subject: [Python-Dev] Little hits add up...
In-Reply-To: <3ACB73D0.DD94C59F@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Thu, Apr 05, 2001 at 03:19:44AM +0800
References: <3ACB73D0.DD94C59F@per.dem.csiro.au>
Message-ID: <20010404123415.A15008@glacier.fnational.com>

Mark Favas wrote:
>(BTW, gc.disable() improved things by 3%.)

I am extremely happy that number is so small. :-)

  Neil


From nas@python.ca  Wed Apr  4 21:56:17 2001
From: nas@python.ca (Neil Schemenauer)
Date: Wed, 4 Apr 2001 13:56:17 -0700
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: <E14ks3t-0001ut-00@usw-sf-web3.sourceforge.net>; from noreply@sourceforge.net on Wed, Apr 04, 2001 at 11:31:21AM -0700
References: <E14ks3t-0001ut-00@usw-sf-web3.sourceforge.net>
Message-ID: <20010404135617.B15146@glacier.fnational.com>

Tim writes:
> Assigned to me; deleted patch 4958 (Jason, whenever you try 
> to change something, it generally won't work unless you add 
> a comment at the same time -- don't know whether that's 
> what actually happened to you, but that's my best guess).

Jason Tishler writes:
> I *did add a comment!  I always do!
> 
> I'm using Netscape again, may be I should only use IE
> whenever I submit SF patches.  Sigh...

Is it a browser issue or is it that only people on the project
can delete things?

  Neil


From tim.one@home.com  Wed Apr  4 22:28:58 2001
From: tim.one@home.com (Tim Peters)
Date: Wed, 4 Apr 2001 17:28:58 -0400
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: <20010404135617.B15146@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>

[Neil Schemenauer]
> Is it a browser issue or is it that only people on the project
> can delete things?

I don't know.  Another possibility to consider is that perhaps only project
Admins can delete things (which I am, but Jason isn't -- can you delete
things, Neil?).



From nas@python.ca  Wed Apr  4 23:28:37 2001
From: nas@python.ca (Neil Schemenauer)
Date: Wed, 4 Apr 2001 15:28:37 -0700
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>; from tim.one@home.com on Wed, Apr 04, 2001 at 05:28:58PM -0400
References: <20010404135617.B15146@glacier.fnational.com> <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>
Message-ID: <20010404152837.A15443@glacier.fnational.com>

Tim Peters wrote:
> [Neil Schemenauer]
> > Is it a browser issue or is it that only people on the project
> > can delete things?
> 
> I don't know.  Another possibility to consider is that perhaps only project
> Admins can delete things (which I am, but Jason isn't -- can you delete
> things, Neil?).

With Netscape Communicator 4.76 on Linux I can attach a file
without entering a comment.  I can also delete a file without
entering a comment.  This works when using a Squid 2.2.5 proxy
and when using a direct connection.

  Neil


From tim.one@home.com  Thu Apr  5 01:44:17 2001
From: tim.one@home.com (Tim Peters)
Date: Wed, 4 Apr 2001 20:44:17 -0400
Subject: [Python-Dev] Little hits add up...
In-Reply-To: <3ACB73D0.DD94C59F@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEENJKAA.tim.one@home.com>

[Mark Favas]
> Since it's a quiet time on python-dev at the moment <grin>, I thought
> I'd just toss this bedraggled parrot in...
> Every now and then, the comment arises "this <enhancement X> should only
> incur a small performance hit". I just ran one of my apps under 1.5.2+
> and 2.1b2. The little hits along the way have here added up to a 26%
> slowdown.

How do you know it is in fact "the little bits" and not one specific bit?
For example, I recall that line-at-a-time input was dozens of times slower
(relatively speaking) on your box than on anyone else's box.  Not enough info
here, and especially not when you say (emphasis added) "I just ran ONE of my
apps ...".  Perhaps that app does something unique?  Or perhaps that app does
something common that's uniquely slow on your box?  Or ...

> Around the time 2.0 was released, there was a brief thread along the
> lines of "let's get 2.0 out the door, and tune it up in 2.1 - there's
> some low-hanging fruit about".

Heh heh.  I remember that too.  Good followup <wink>.

> Any chance we could get someone like Christian and Tim wound up on
> looking at performance issues, however briefly <wink>? (I know, they
> don't have time -

No chance for Tim.  I have no spare work time or spare spare time left.  And
AFAIK, PythonLabs has no plans to do any performance tuning.  If you identify
a specific new choke point, though, then repairing it should be a focused
low-effort job.  I doubt you're seeing an accumulation of small slowdowns
adding to 26% anyway -- there's really nothing we've done that should have an
ubiquitous effect other than adding cyclic gc (but you said later that gc
only accounted for 3% in your app).

Hmm.  One other:  the new comparison code is both very complex and very
cleanly written.  As a result, I've worn my finger numb stepping through it
in a debugger:  if your app is doing oodles of comparisions, I wouldn't be
surprised to see it losing 20% to layers and layers of function calls trying
to figure out *how* to compare things.

> I just remembered the old days on c.l.py when they'd try to outdo each
> other with weird and wonderful optimizations.)

Recall that none of those got into the distribution, though.  Guido doesn't
like weird and wonderful optimizations in the Python source code.  And,
indeed, many of those eventually succumbed to the *obvious* ways to write
them in C (e.g., converting an MD5 digest to a string of hex digits -- 2.0
added an md5.hex_digest() method to solve that directly, and
binascii.hexlify() for the general case).

> This is not a flame at 2.x, BTW - 2.x is a good thing!

You're not fooling me, Mark.  I've known from the start that this is just
another thinly veiled attack on 2.1's __future__ statement <wink>.

first-find-out-where-it's-slower-ly y'rs  - tim



From tim.one@home.com  Thu Apr  5 07:23:26 2001
From: tim.one@home.com (Tim Peters)
Date: Thu, 5 Apr 2001 02:23:26 -0400
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <20010404102011.L63@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>

[Jason Tishler, passing on someone's objection to Python #define'ing
 _POSIX_THREADS sometimes]

Right or wrong, it's too late to change this for 2.1 (IMO).  Thread support
across platforms is very touchy, because so poorly standardized and
implemented across vendors, and fiddling with *any* of that support code is
very dangerous.  Can you swear that Python never #define'ing _POSIX_THREADS
on its own won't break threading on some other platform?  If not, changing it
needs *lots* of lead time for x-platform testing.

> ...
> The author of the recent Cygwin pthreads enhancements states that
> _POSIX_THREADS is a kernel level #define and should not be defined in
> user level code.  Please see the following for his reasoning:
>
>     http://sources.redhat.com/ml/cygwin/2001-03/msg01693.html
>
> Unfortunately, I am not knowledgeable is this area.  Can someone please
> confirm or refute the above claim?

At heart, the claim was based on little more than "I said so", as far as I
could see.  What does the POSIX pthreads standard say?  I haven't had an
employer willing to buy me a copy of that (expensive) document since 1992, so
I can't say (and POSIX stds are not available for online browsing).

He's certainly right that _POSIX_THREADS "is _NOT_ a userland symbol".  *All*
identifiers beginning with an underscore and followed by another underscore
or an uppercase letter are reserved names in std C, for use by the
implementation (incl. system libraries).  But lots of stuff violates that
rule, so I'm afraid it's not a killer argument in practice (although it's a
*good* argument!).

BTW, it's safe to remove this from thread.c:

#ifdef __ksr__
#define _POSIX_THREADS
#endif

I probably put that in around '93, but there are no more KSR machines
anymore -- that I know of.  I won't even make that change for 2.1 at this
late stage.

for-all-i-know-mac-os-x-#defines-__ksr__-ly y'rs  - tim



From fredrik@pythonware.com  Thu Apr  5 08:37:01 2001
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 5 Apr 2001 09:37:01 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
References: <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>
Message-ID: <015201c0bda3$368aaa30$e46940d5@hagrid>

tim wrote:
> At heart, the claim was based on little more than "I said so", as far as I
> could see.  What does the POSIX pthreads standard say?

the SUSv2 spec says:

    "On XSI-conformant systems, _POSIX_THREADS,
    _POSIX_THREAD_ATTR_STACKADDR, _POSIX_THREAD_ATTR_STACKSIZE
    and _POSIX_THREAD_PROCESS_SHARED are always defined"

which doesn't say much about what the POSIX standard says,
of course...

fwiw, regarding the pthread.h file, it also says:

    "An interpretation request has been filed with IEEE PASC
    concerning requirements for visibility of symbols in this
    header"

which implies that the specification doesn't always "say so" ;-)

Cheers /F



From m.favas@per.dem.csiro.au  Thu Apr  5 11:42:03 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Thu, 05 Apr 2001 18:42:03 +0800
Subject: [Python-Dev] Late enhancements breaks termios build
Message-ID: <3ACC4BFB.7143EF4D@per.dem.csiro.au>

In the past day or so, extra functionaility has been added to the CVS
version of the termios module. This breaks the compilation of termios.c
on Tru64 Unix, as a number of the new constants collide with macros of
the same name defined in /usr/include/sys/ioctl.h - so the #ifdef
NEW_THING succeeds, but with incompatible values from ioctl.h, rather
than compatible values from termios.h. I thought we were at the "fix
bugs" stage, rather than the "it'd be nice to add this" <wink>. Yes,
I'll file a bug report - sorry for the interruption.

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From fdrake@acm.org  Thu Apr  5 12:11:01 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 5 Apr 2001 07:11:01 -0400 (EDT)
Subject: [Python-Dev] Late enhancements breaks termios build
In-Reply-To: <3ACC4BFB.7143EF4D@per.dem.csiro.au>
References: <3ACC4BFB.7143EF4D@per.dem.csiro.au>
Message-ID: <15052.21189.904560.185718@cj42289-a.reston1.va.home.com>

Mark Favas writes:
 > than compatible values from termios.h. I thought we were at the "fix
 > bugs" stage, rather than the "it'd be nice to add this" <wink>. Yes,
 > I'll file a bug report - sorry for the interruption.

  Gosh, it sounded like a bug to me.  Can you tell me which file on
Tru64 defines the right constants?
  Please assign the bug report to me -- it's my mess.  Sorry!  ;-(


  -Fred

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



From thomas@xs4all.net  Thu Apr  5 18:53:39 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 5 Apr 2001 19:53:39 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>; from tim.one@home.com on Thu, Apr 05, 2001 at 02:23:26AM -0400
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>
Message-ID: <20010405195338.C2820@xs4all.nl>

On Thu, Apr 05, 2001 at 02:23:26AM -0400, Tim Peters wrote:

> [Jason Tishler, passing on someone's objection to Python #define'ing
>  _POSIX_THREADS sometimes]

> Right or wrong, it's too late to change this for 2.1 (IMO).  Thread support
> across platforms is very touchy, because so poorly standardized and
> implemented across vendors, and fiddling with *any* of that support code is
> very dangerous.  Can you swear that Python never #define'ing _POSIX_THREADS
> on its own won't break threading on some other platform?  If not, changing it
> needs *lots* of lead time for x-platform testing.

We could define _POSIX_THREADS only if it isn't already defined. Or better
yet, defined PY_POSIX_THREADS, have the Python source itself just trigger
off of that, and #define _POSIX_THREADS somewhere in pyport.h,
PY_POSIX_THREADS is defined and _POSIX_THREADS is not.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From Jason.Tishler@dothill.com  Thu Apr  5 19:40:59 2001
From: Jason.Tishler@dothill.com (Jason Tishler)
Date: Thu, 5 Apr 2001 14:40:59 -0400
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <20010405195338.C2820@xs4all.nl>; from thomas@xs4all.net on Thu, Apr 05, 2001 at 07:53:39PM +0200
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com> <20010405195338.C2820@xs4all.nl>
Message-ID: <20010405144059.C402@dothill.com>

Thomas,

On Thu, Apr 05, 2001 at 07:53:39PM +0200, Thomas Wouters wrote:
> On Thu, Apr 05, 2001 at 02:23:26AM -0400, Tim Peters wrote:
> > [Jason Tishler, passing on someone's objection to Python #define'ing
> >  _POSIX_THREADS sometimes]
> >
> > Right or wrong, it's too late to change this for 2.1 (IMO).  Thread support
> > across platforms is very touchy, because so poorly standardized and
> > implemented across vendors, and fiddling with *any* of that support code is
> > very dangerous.  Can you swear that Python never #define'ing _POSIX_THREADS
> > on its own won't break threading on some other platform?  If not, changing
> > it needs *lots* of lead time for x-platform testing.
> 
> We could define _POSIX_THREADS only if it isn't already defined. Or better
> yet, defined PY_POSIX_THREADS, have the Python source itself just trigger
> off of that, and #define _POSIX_THREADS somewhere in pyport.h,
> PY_POSIX_THREADS is defined and _POSIX_THREADS is not.

I was thinking of something like the above, but not with as much
understanding as you already have.  Would you be willing to submit such
a patch for consideration *after* 2.1 final?

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com


From guido@digicool.com  Thu Apr  5 23:06:22 2001
From: guido@digicool.com (Guido van Rossum)
Date: Thu, 05 Apr 2001 17:06:22 -0500
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: Your message of "Wed, 04 Apr 2001 15:28:37 MST."
 <20010404152837.A15443@glacier.fnational.com>
References: <20010404135617.B15146@glacier.fnational.com> <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>
 <20010404152837.A15443@glacier.fnational.com>
Message-ID: <200104052206.RAA11393@cj20424-a.reston1.va.home.com>

> Tim Peters wrote:
> > [Neil Schemenauer]
> > > Is it a browser issue or is it that only people on the project
> > > can delete things?
> > 
> > I don't know.  Another possibility to consider is that perhaps only project
> > Admins can delete things (which I am, but Jason isn't -- can you delete
> > things, Neil?).
> 
> With Netscape Communicator 4.76 on Linux I can attach a file
> without entering a comment.  I can also delete a file without
> entering a comment.  This works when using a Squid 2.2.5 proxy
> and when using a direct connection.
> 
>   Neil

There's a tiny checkbox next to the file upload entry box.  If you
don't check the checkbox, the upload is ignored.  (God knows why they
added this feature -- it's not like it's easy to upload a file by
mistake. :-)

Could it be that those users who complain they can't upload didn't
check the box?

Other random theories: maybe it works differently when not logged in?
Certainly you can't delete a file when you're not logged in.

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



From thomas@xs4all.net  Thu Apr  5 22:27:12 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 5 Apr 2001 23:27:12 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <20010405144059.C402@dothill.com>; from Jason.Tishler@dothill.com on Thu, Apr 05, 2001 at 02:40:59PM -0400
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com> <20010405195338.C2820@xs4all.nl> <20010405144059.C402@dothill.com>
Message-ID: <20010405232712.D2820@xs4all.nl>

On Thu, Apr 05, 2001 at 02:40:59PM -0400, Jason Tishler wrote:

> > We could define _POSIX_THREADS only if it isn't already defined. Or better
> > yet, defined PY_POSIX_THREADS, have the Python source itself just trigger
> > off of that, and #define _POSIX_THREADS somewhere in pyport.h,
> > PY_POSIX_THREADS is defined and _POSIX_THREADS is not.

> I was thinking of something like the above, but not with as much
> understanding as you already have.  Would you be willing to submit such
> a patch for consideration *after* 2.1 final?

Actually, I think the above should go in *before* 2.1 final. It won't break
anything new, and it fixes some warnings and possible some problems.
Because:

- if _POSIX_THREADS is not already defined, nothing changes
- if _POSIX_THREADS is already defined, to the same value as we are defining
  it to, nothing changes
- if _POSIX_THREADS is already defined, but to a different value than Python
  wants to define it to, it used to break and starts working now. There is
  nothing that depends on the actual value of _POSIX_THREADS in Python right
  now (because it doesn't *have* a value.)

Unfortunately, I lack the time to write the patch and test it. I'm busy
moving, redecorating the house I'm half moved into, lack any kind of
connectivity at home (*@#$&*! cable and DSL companies), and have several
projects at work that *need* my 80h/week attention (each one) the next few
of months at least. Python (and Mailman, btw, Barry) are *slightly* on the
back burner right now.

But if someone does write a patch, I can make the time to test it on the
BSDI and FreeBSD machines I have (asside from the Linux machines everyone
and their dog has, nowadays :)

Jetlagged-at-Apachecon-ly y'rs,
-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From claird@starbase.neosoft.com  Thu Apr  5 23:36:46 2001
From: claird@starbase.neosoft.com (Cameron Laird)
Date: Thu, 5 Apr 2001 17:36:46 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
Message-ID: <200104052236.RAA52963@starbase.neosoft.com>

Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).

Successful installation requires
  ./configure --with-cxx=gcc
  sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
  mv /tmp/Makefile Makefile

The result of a plain configure is
  loading cache ./config.cache
  checking MACHDEP... osf1V4
  checking for --without-gcc...
  checking for --with-cxx=<compiler>... no
  checking for c++... c++
  checking whether the C++ compiler (c++  ) works... no
  configure: error: installation or configuration problem: C++ compiler cannot create executables.       

If I leave the Makefile unaltered, I see
  gcc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Modules/ccpython.o ./
  Modules/ccpython.cc
  gcc: 1500: No such file or directory
  cc1plus: Invalid option `-Olimit'
  make: *** [Modules/ccpython.o] Error 1 

Yes, there's probably a way to configure this in one line.
I think this is a better explanation, for now.

Do I need to figure out the correct patch to configure.in,
or is there a specialist who takes responsibility for that?


From claird@starbase.neosoft.com  Thu Apr  5 23:51:13 2001
From: claird@starbase.neosoft.com (Cameron Laird)
Date: Thu, 5 Apr 2001 17:51:13 -0500 (CDT)
Subject: [Python-Dev] A kind of configuration question
Message-ID: <200104052251.RAA53506@starbase.neosoft.com>

Why's there no Win* executable pydoc?

Let me know if I should ask this elsewhere.  In part,
I think I'm searching for larger generalizations that
I'm particularizing with this specific instance.

A Unix-side installation-from-source provides, along
with much else, an executable /usr/local/bin/pydoc,
whose content is simply
  #!/usr/bin/env python

  import pydoc
  pydoc.cli()    
As near as I can tell, installation of the 2.1 Python
binaries for Win* gives no corresponding executable or
"shortcut" for that (those) platform(s).  Is it intended
generally to provide homologous facilities for each of
Unix and Win* (and MacOS)?  Is ... well, how should I
think about this?

I wrote Ka-Ping Yee (the pydoc lord--right?) earlier in
the day.  I've received no response.


From ping@lfw.org  Thu Apr  5 17:29:36 2001
From: ping@lfw.org (Ka-Ping Yee)
Date: Thu, 5 Apr 2001 09:29:36 -0700 (PDT)
Subject: [Python-Dev] Re: A kind of configuration question
In-Reply-To: <200104052251.RAA53506@starbase.neosoft.com>
Message-ID: <Pine.LNX.4.10.10104050927340.474-100000@skuld.kingmanhall.org>

On Thu, 5 Apr 2001, Cameron Laird wrote:
> Why's there no Win* executable pydoc?

There is.  There's a shortcut to pydoc.pyw on the Start Menu.

> I wrote Ka-Ping Yee (the pydoc lord--right?) earlier in
> the day.  I've received no response.

I'm at the CHI 2001 conference in Seattle right now; e-mail
checking frequency is down to less than 50 uHz. :)


-- ?!ng



From nas@python.ca  Fri Apr  6 01:50:31 2001
From: nas@python.ca (Neil Schemenauer)
Date: Thu, 5 Apr 2001 17:50:31 -0700
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <200104052236.RAA52963@starbase.neosoft.com>; from claird@starbase.neosoft.com on Thu, Apr 05, 2001 at 05:36:46PM -0500
References: <200104052236.RAA52963@starbase.neosoft.com>
Message-ID: <20010405175031.A17937@glacier.fnational.com>

Cameron Laird wrote:
> Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).
> 
> Successful installation requires
>   ./configure --with-cxx=gcc
>   sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
>   mv /tmp/Makefile Makefile

Can you send me the output from configure?  Also, try
--without-cxx instead.  Finally, an easier work around is:

    OPT=-O ./configure --with-cxx=gcc

Can someone tell me why with-cxx is the default?  It pissed me off
more than a few times when I was on a machine without a working C++
compiler.
 
  Neil


From fredrik@pythonware.com  Fri Apr  6 07:18:05 2001
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 6 Apr 2001 08:18:05 +0200
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
References: <200104052236.RAA52963@starbase.neosoft.com>
Message-ID: <07ee01c0be61$5ab63690$e46940d5@hagrid>

Cameron Laird wrote:

> Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).
> 
> Successful installation requires
>   ./configure --with-cxx=gcc
>   sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
>   mv /tmp/Makefile Makefile

umm.  isn't there an -Olimit test in the configure script?

did you run configure with "cc" first, and forgot to remove the
cache files?

it would be nice if Python didn't default to "gcc" on the axp.
"cc" is standard, and creates much better code on the AXP.

Cheers /F



From fredrik@pythonware.com  Fri Apr  6 07:07:41 2001
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 6 Apr 2001 08:07:41 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com> <20010405195338.C2820@xs4all.nl> <20010405144059.C402@dothill.com> <20010405232712.D2820@xs4all.nl>
Message-ID: <07ed01c0be61$5a4e4d00$e46940d5@hagrid>

thomas wrote:
> Actually, I think the above should go in *before* 2.1 final. It won't break
> anything new, and it fixes some warnings and possible some problems.
> Because:
> 
> - if _POSIX_THREADS is not already defined, nothing changes
> - if _POSIX_THREADS is already defined, to the same value as we are defining
>   it to, nothing changes
> - if _POSIX_THREADS is already defined, but to a different value than Python
>   wants to define it to, it used to break and starts working now. There is
>   nothing that depends on the actual value of _POSIX_THREADS in Python right
>   now (because it doesn't *have* a value.)

on the other hand, cygwin is the only platform that has reported
problems with this, and your solution doesn't address their problem.
(which is that Python assumes that a system that has pthread_create
in a library is a fully compliant POSIX thread system)

the right thing to do appears to be to let configure compile and
link a program that uses *all* pthread features needed, and define
_POSIX_THREAD (or better, PY_POSIX_THREADS) only if that
works...

Cheers /F



From tim.one@home.com  Fri Apr  6 09:46:54 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 6 Apr 2001 04:46:54 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
Message-ID: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>

Jim Fulton bumped into a gross problem in the 2.1b2 asynchat.py today,
introduced by conversion to string methods (one change got the order of
.find() arguments backwards).

This is embarrassing (or should be <wink>), because it meant asynchat.py
really had no chance of working at all!  And if Jim hadn't bumped into it, we
would have shipped it this way for 2.1 final next week.

I haven't used those modules myself, so don't know whether this request is
reasonable:  could someone please whip up an at least minimal standard test
case for these modules?  So long as it runs on at least one of {Windows,
Linux}, we'd catch problems like this almost instantly.  As is, AFAICT we
don't even import asynchat (the "import asynchat" line in test_sundry.py is
commented out but no reason is given for that -- anyone know why?).

don't-everyone-volunteer-at-once-ly y'rs  - tim



From jack@oratrix.nl  Fri Apr  6 09:50:24 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Fri, 06 Apr 2001 10:50:24 +0200
Subject: [Python-Dev] Re: [Pythonmac-SIG] __builtins__ a dictionary or a module?
In-Reply-To: Message by Jonathan Wight <JWight@bigfoot.com> ,
 Thu, 05 Apr 2001 01:38:31 -0500 , <B6F17D15.194B8%JWight@bigfoot.com>
Message-ID: <20010406085024.7548A312BA0@snelboot.oratrix.nl>

Python-devvers, can anyone help with this behaviour?

> If I run Just's Python IDE and run the same code it tells mes that
> __builtins__ is a module.
> 
> And finally if I run the following code from within the Interactive console
> contained in standard 'code.py' file I get told __builtins__ is a
> dictionary.
> 
> So what is it? Is __builtins__ a module or a dictionary? I know that they're
> essentially the same thing, but it unnerves me to have the same code produce
> different results in different platforms.

Well, I've narrowed down the difference to the exec statement:
>>> exec "print type(__builtins__)"
<type 'module'>
>>> exec "print type(__builtins__)" in {}
<type 'dictionary'>

Can anyone explain what is going on here?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From Paul.Moore@uk.origin-it.com  Fri Apr  6 09:55:38 2001
From: Paul.Moore@uk.origin-it.com (Moore, Paul)
Date: Fri, 6 Apr 2001 09:55:38 +0100
Subject: [Python-Dev] A kind of configuration question
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFC@ukrux002.rundc.uk.origin-it.com>

On Thu, 5 Apr 2001, Cameron Laird wrote:
> Why's there no Win* executable pydoc?

There's an issue on Windows, because there are two types of executable
(console and GUI). I've raised a bug report on this (407300), but the action
taken was to remove the pydoc script (as opposed to the module) from the
Windows installer, although there is still a start menu entry.

The problem is that pydoc does two things - first, it starts a web server
(with a small GUI control interface). This script needs to be run as a GUI
command, to avoid an unnecessary console window. This is what the entry on
the start menu does. The other thing is to support the command line usage
"pydoc XXX". For this, I believe there should be a console command. A small
"pydoc.bat" as follows would provide this functionality:

--- pydoc.bat ---
@echo off
if "%1"=="" pythonw -c "import pydoc; pydoc.cli()"
if NOT "%1"=="" python -c "import pydoc; pydoc.cli()" %1 %2 %3 %4 %5 %6 %7
%8 %9
---

I do the test on %1 so that if the command is called without any arguments,
it uses pythonw to spawn the GUI webserver, whereas with arguments it does
the command line stuff.

Paul Moore


From tim.one@home.com  Fri Apr  6 10:06:02 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 6 Apr 2001 05:06:02 -0400
Subject: [Python-Dev] Re: [Pythonmac-SIG] __builtins__ a dictionary or a module?
In-Reply-To: <20010406085024.7548A312BA0@snelboot.oratrix.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEJCJKAA.tim.one@home.com>

Please read this the right way <wink>:  it's none of your business whether
__builtins__ is a module or a dictionary.  __builtin__ (no trailing 's') is a
module, but __builtins__ is a module attribute that can be either a module or
a dictionary, depending on what Python feels like doing.  Which it decides to
do is an internal implementation detail of no material consequence to correct
Python code.

More info on why the two choices exist-- and documentation that __builtins__
*can* be either a dict or a module --can be found in the "Code blocks,
execution frames, and namespaces" setion of the Language Reference manual.

BTW, the primary reason __builtins__ is a module when bringing up a native
command-line shell (I know that doesn't apply on a Mac Classic) is simply so
that if a curious user types

    >>> __builtins__

they get

    <module '__builtin__' (built-in)>

instead of a giant dict dump.  The primary use for making __builtins__ a dict
is to support restricted execution modes.



From tim.one@home.com  Fri Apr  6 10:25:16 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 6 Apr 2001 05:25:16 -0400
Subject: [Python-Dev] A kind of configuration question
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFC@ukrux002.rundc.uk.origin-it.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEJDJKAA.tim.one@home.com>

[Moore, Paul]
> There's an issue on Windows, because there are two types of executable
> (console and GUI). I've raised a bug report on this (407300), but
> the action taken was to remove the pydoc script (as opposed to the
> module) from the Windows installer, although there is still a start
> menu entry.

Paul, that action had nothing to do with your bug report.  Ping managed to
break AMK's pydoc script on Windows the morning of 2.1b2 release day, and
that left the Windows installer installing a non-functional Start menu link
for pydoc.  Unfortunately, I didn't discover that until after the 2.1b2 code
base was frozen.  Fortunately, Ping had also checked in a new pydoc.pyw
script (under Tools/scripts/) that *did* work on Windows, so *after* the last
second I simply changed the Start menu link to point to that instead, and
stopped copying AMK's no-longer-worked-on-Windows Tools/scripts/pydoc script
to the installation directory.  And I don't know why Guido copied AMK's pydoc
script to the Windows install directory to begin with, since (as your bug
report pointed out) it was a nearly useless thing on Windows even before it
got broken.

> ...
> The other thing is to support the command line usage "pydoc XXX".

Given that Win9x systems come with feeble cmdline shells (they're 50 lines
max, and no way to scroll back), I have no interest in pretending to support
pydoc's cmdline usage under Windows DOS boxes.  Writing a cmdline script to
drive pydoc is a trivial exercise for any knowledgable Windows user who wants
that, while the non-knowledgable should learn to use pydoc from within IDLE
or PythonWin or PythonWorks or ... instead (all of which provide a *capable*
Python shell under all flavors of Windows).



From Paul.Moore@uk.origin-it.com  Fri Apr  6 11:18:45 2001
From: Paul.Moore@uk.origin-it.com (Moore, Paul)
Date: Fri, 6 Apr 2001 11:18:45 +0100
Subject: [Python-Dev] A kind of configuration question
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com>

>[Moore, Paul]
>> There's an issue on Windows, because there are two types of executable
>> (console and GUI). I've raised a bug report on this (407300), but
>> the action taken was to remove the pydoc script (as opposed to the
>> module) from the Windows installer, although there is still a start
>> menu entry.
>
>Paul, that action had nothing to do with your bug report.  Ping managed to
>break AMK's pydoc script on Windows the morning of 2.1b2 release day, and
>that left the Windows installer installing a non-functional Start menu link
>for pydoc.

Oh. Sorry about that - I seem to have misread your comments from when you
reclosed the bug. I read them as "I've removed the scripts, so your bug no
longer applies", rather than "the script needed to be removed, so ths issue
has gone away". I apologise if I sounded critical. I do still think that
being able to type "pydoc MODULE" at the command line would be very nice,
and I feel that my batch file does this in a simple way. I'd be disappointed
if it wasn't included in 2.1 (the whole pydoc suite appeared quite late, so
minor fixes like this do get pushed up to the wire, but that doesn't
necessarily mean they should be discarded as "too late"), but if it is
deemed too late for that, could it be put into 2.2?

On a related note, has anything happened on my other bug report (406280)? At
the very least, using tempfilepager instead of pipepager as a workaround
would be sensible. Leaving things broken makes no real sense. This is a
patch:

--- pydoc.py.orig	Fri Mar 23 12:42:06 2001
+++ pydoc.py	Fri Apr 06 10:56:02 2001
@@ -910,7 +910,10 @@
     if not sys.stdin.isatty() or not sys.stdout.isatty():
         return plainpager
     if os.environ.has_key('PAGER'):
-        return lambda a: pipepager(a, os.environ['PAGER'])
+        if sys.platform == 'win32':
+            return lambda a: tempfilepager(a, os.environ['PAGER'])
+        else:
+            return lambda a: pipepager(a, os.environ['PAGER'])
     if sys.platform == 'win32':
         return lambda a: tempfilepager(a, 'more <')
     if hasattr(os, 'system') and os.system('less 2>/dev/null') == 0:

>> ...
>> The other thing is to support the command line usage "pydoc XXX".
>
>Given that Win9x systems come with feeble cmdline shells (they're 50 lines
>max, and no way to scroll back), I have no interest in pretending to
support
>pydoc's cmdline usage under Windows DOS boxes.

Given that Windows NT/2000 command line shells are fine, and reasonably
capable (including command history both at the prompt and within
applications, whatever size you like, and scrolling buffers), refusing to
support them just because 9x (which frankly is a dying environment for
developers) is pathetic, is not a very helpful stance to take. I've supplied
two low-impact patches which make pydoc work on the Windows NT command line.
Sure, I can apply them manually to my installation, but why not make them
available to everyone?

frustrated-ly y'rs,
Paul.


From jim@digicool.com  Fri Apr  6 13:04:12 2001
From: jim@digicool.com (Jim Fulton)
Date: Fri, 06 Apr 2001 08:04:12 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
Message-ID: <3ACDB0BC.2533D8C2@digicool.com>

Tim Peters wrote:
> 
> Jim Fulton bumped into a gross problem in the 2.1b2 asynchat.py today,
> introduced by conversion to string methods (one change got the order of
> .find() arguments backwards).
> 
> This is embarrassing (or should be <wink>), because it meant asynchat.py
> really had no chance of working at all!  And if Jim hadn't bumped into it, we
> would have shipped it this way for 2.1 final next week.
> 
> I haven't used those modules myself, so don't know whether this request is
> reasonable:  could someone please whip up an at least minimal standard test
> case for these modules?  So long as it runs on at least one of {Windows,
> Linux}, we'd catch problems like this almost instantly.  As is, AFAICT we
> don't even import asynchat (the "import asynchat" line in test_sundry.py is
> commented out but no reason is given for that -- anyone know why?).

Do we have test cases for other networking code? This seems a kinda
hard, though I haven't given it much thought.  I imagine one would
want some sort of faux sockets to support this.  Library modules
would need to be written so thier sockets could be passed in...

I've got a more basic question. Should asynchat *really* be in the standard
library?  Is it really used by anything but medusa? (There is another
module in the standard distribution that uses it, but it's unclear
whether anyone is using it. The Author isn't.)

Jim

--
Jim Fulton           mailto:jim@digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.


From guido@digicool.com  Fri Apr  6 16:02:03 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 06 Apr 2001 10:02:03 -0500
Subject: [Python-Dev] A kind of configuration question
In-Reply-To: Your message of "Fri, 06 Apr 2001 11:18:45 +0100."
 <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com>
Message-ID: <200104061502.KAA14238@cj20424-a.reston1.va.home.com>

> On a related note, has anything happened on my other bug report (406280)? At
> the very least, using tempfilepager instead of pipepager as a workaround
> would be sensible. Leaving things broken makes no real sense. This is a
> patch:

What's broken?  After "from pydoc import help" I can use help(...)
just fine, both in the command line version (where it invokes some
pager) and in IDLE (where it just scrolls off the window, but IDLE has
infinite scroll-back so that's no problem).  This is on Win98se with
Python 2.1b2.
 
> Given that Windows NT/2000 command line shells are fine, and reasonably
> capable (including command history both at the prompt and within
> applications, whatever size you like, and scrolling buffers), refusing to
> support them just because 9x (which frankly is a dying environment for
> developers) is pathetic, is not a very helpful stance to take. I've supplied
> two low-impact patches which make pydoc work on the Windows NT command line.
> Sure, I can apply them manually to my installation, but why not make them
> available to everyone?

We seem to disagree on how Windows users use their system.  You seem
to be a command line user on Windows.  Both Tim & me are more
mouse-based users, and neither of us spends a lot of time in the
command line, so we don't see the point of adding yet another thing to
the distribution.  It is my expectation that *most* Windows users (and
developers) are like Tim & me, not like you, so we don't feel (if I
may channel Tim for a change :-) that this would benefit most users.

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


From fredrik@effbot.org  Fri Apr  6 15:20:08 2001
From: fredrik@effbot.org (Fredrik Lundh)
Date: Fri, 6 Apr 2001 16:20:08 +0200
Subject: [Python-Dev] A kind of configuration question
References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com>  <200104061502.KAA14238@cj20424-a.reston1.va.home.com>
Message-ID: <0a8201c0bea4$b24cb760$e46940d5@hagrid>

> It is my expectation that *most* Windows users (and developers)
> are like Tim & me

no, we're not.

(no real windows developer use 98SE these days.  and just's
brother cannot possibly be a typical user of anything ;-)

I'm +0 on a pydoc command, but even if it's not added to the
standard distribution, I'm +1 on making sure pydoc works in case
someone wants to add a batchfile shortcut themselves.

Cheers /F



From jeremy@digicool.com  Fri Apr  6 15:13:43 2001
From: jeremy@digicool.com (Jeremy Hylton)
Date: Fri, 6 Apr 2001 10:13:43 -0400 (EDT)
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
Message-ID: <15053.53015.996756.656235@slothrop.digicool.com>

>>>>> "TP" == Tim Peters <tim.one@home.com> writes:

  TP> Jim Fulton bumped into a gross problem in the 2.1b2 asynchat.py
  TP> today, introduced by conversion to string methods (one change
  TP> got the order of .find() arguments backwards).

  TP> This is embarrassing (or should be <wink>), because it meant
  TP> asynchat.py really had no chance of working at all!  And if Jim
  TP> hadn't bumped into it, we would have shipped it this way for 2.1
  TP> final next week.

This leads to the natural question:  Are there other modules that we
changed for string methods that don't have test suites?  If this
problem happened once, it could have happened twice.

Jeremy



From aahz@rahul.net  Fri Apr  6 15:26:08 2001
From: aahz@rahul.net (Aahz Maruch)
Date: Fri, 6 Apr 2001 07:26:08 -0700 (PDT)
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: <3ACDB0BC.2533D8C2@digicool.com> from "Jim Fulton" at Apr 06, 2001 08:04:12 AM
Message-ID: <20010406142608.DD66299CA0@waltz.rahul.net>

Jim Fulton wrote:
> 
> I've got a more basic question. Should asynchat *really* be in the standard
> library?  Is it really used by anything but medusa? (There is another
> module in the standard distribution that uses it, but it's unclear
> whether anyone is using it. The Author isn't.)

asynchat should probably be in the Tools directory, but my former
employer used asyncore (stand-alone, in addition to Medusa) and I was
quite happy when it went into the standard library.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.


From claird@starbase.neosoft.com  Fri Apr  6 15:37:27 2001
From: claird@starbase.neosoft.com (Cameron Laird)
Date: Fri, 6 Apr 2001 09:37:27 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <20010405175031.A17937@glacier.fnational.com>
Message-ID: <200104061437.JAA79762@starbase.neosoft.com>

	From nas@arctrix.com  Thu Apr  5 19:51:35 2001
			.
			.
			.
	Can you send me the output from configure?  Also, try
	--without-cxx instead.  Finally, an easier work around is:
			.
			.
			.
Oops!  Sorry, everybody;
  configure --without-cxx
(which my notes say I'd earlier tried, with unsatisfying
results) appears indeed to be the minimal invocation in
my environment to yield a happy conclusion.

We're carrying on some of this in private correspondence.
While I remain uncertain about python-dev folkways, I'll
report more conclusions as I judge them of general interest.


From fredrik@effbot.org  Fri Apr  6 15:47:45 2001
From: fredrik@effbot.org (Fredrik Lundh)
Date: Fri, 6 Apr 2001 16:47:45 +0200
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <20010406142608.DD66299CA0@waltz.rahul.net>
Message-ID: <0ac301c0bea8$8cef9ab0$e46940d5@hagrid>

jim wrote:
> I've got a more basic question. Should asynchat *really* be in the standard
> library?  Is it really used by anything but medusa?

yes.

Cheers /F



From claird@starbase.neosoft.com  Fri Apr  6 15:49:48 2001
From: claird@starbase.neosoft.com (Cameron Laird)
Date: Fri, 6 Apr 2001 09:49:48 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <07ee01c0be61$5ab63690$e46940d5@hagrid>
Message-ID: <200104061449.JAA80212@starbase.neosoft.com>

	From fredrik@pythonware.com  Fri Apr  6 01:53:58 2001
			.
			.
			.
	> Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).
	> 
	> Successful installation requires
	>   ./configure --with-cxx=gcc
	>   sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
	>   mv /tmp/Makefile Makefile

	umm.  isn't there an -Olimit test in the configure script?

	did you run configure with "cc" first, and forgot to remove the
	cache files?
			.
			.
			.
Yes.  No.
  make distclean
  configure
  make
gives
  ...
  gcc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Modules/ccpython.o ./Modules/ccpython.cc
  gcc: 1500: No such file or directory
  cc1plus: Invalid option `-Olimit'
  make: *** [Modules/ccpython.o] Error 1   

Should I track this down, or do we have a specialist
on-hand in autoconfig?  I find it like sendmail.cf; I
can read and write, but never understand the *meaning*
of what others have done, just its syntax.  So, yes, I
can see the -Olimit test in configure.in, but it's
likely to take me a while to figure out what's wrong
with it.


From claird@starbase.neosoft.com  Fri Apr  6 15:50:56 2001
From: claird@starbase.neosoft.com (Cameron Laird)
Date: Fri, 6 Apr 2001 09:50:56 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <07ee01c0be61$5ab63690$e46940d5@hagrid>
Message-ID: <200104061450.JAA80284@starbase.neosoft.com>

	From fredrik@pythonware.com  Fri Apr  6 01:53:58 2001
			.
			.
			.
	it would be nice if Python didn't default to "gcc" on the axp.
	"cc" is standard, and creates much better code on the AXP.

	Cheers /F
Me, too.


From barry@digicool.com  Fri Apr  6 16:01:46 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 6 Apr 2001 11:01:46 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
 <3ACDB0BC.2533D8C2@digicool.com>
Message-ID: <15053.55898.791123.146656@anthem.wooz.org>

>>>>> "JF" == Jim Fulton <jim@digicool.com> writes:

    JF> I've got a more basic question. Should asynchat *really* be in
    JF> the standard library?  Is it really used by anything but
    JF> medusa? (There is another module in the standard distribution
    JF> that uses it, but it's unclear whether anyone is using it. The
    JF> Author isn't.)

That'd be me.  I wrote smtpd.py a long while ago, got approval from
Guido to add it to the standard library, then forgot about it until
around the 2.1a1 time frame.  smtpd.py itself is probably useful to
only a handful of people (and maybe that hand belongs to a shop
teacher), so I wouldn't be offended if it and async* were moved to
Tools -- eventually.  It is, of course, much too late to do this for
Py2.1.

-Barry


From barry@digicool.com  Fri Apr  6 16:04:57 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 6 Apr 2001 11:04:57 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
 <3ACDB0BC.2533D8C2@digicool.com>
Message-ID: <15053.56089.93466.30362@anthem.wooz.org>

Oh, one other thing.  Last time I traded email with Sam Rushing
(almost a year ago, and I'm not even sure if he's on python-dev), he
was moving toward a coroutine based Medusa and away from async* based.

-Barry


From jim@digicool.com  Fri Apr  6 16:20:46 2001
From: jim@digicool.com (Jim Fulton)
Date: Fri, 06 Apr 2001 11:20:46 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <20010406142608.DD66299CA0@waltz.rahul.net>
Message-ID: <3ACDDECE.E4E7806E@digicool.com>

Aahz Maruch wrote:
> 
> Jim Fulton wrote:
> >
> > I've got a more basic question. Should asynchat *really* be in the standard
> > library?  Is it really used by anything but medusa? (There is another
> > module in the standard distribution that uses it, but it's unclear
> > whether anyone is using it. The Author isn't.)
> 
> asynchat should probably be in the Tools directory, but my former
> employer used asyncore (stand-alone, in addition to Medusa) and I was
> quite happy when it went into the standard library.

I was only talking about asynchat. :)

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org


From jim@digicool.com  Fri Apr  6 16:22:49 2001
From: jim@digicool.com (Jim Fulton)
Date: Fri, 06 Apr 2001 11:22:49 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
 <3ACDB0BC.2533D8C2@digicool.com> <15053.56089.93466.30362@anthem.wooz.org>
Message-ID: <3ACDDF49.A641466E@digicool.com>

"Barry A. Warsaw" wrote:
> 
> Oh, one other thing.  Last time I traded email with Sam Rushing
> (almost a year ago, and I'm not even sure if he's on python-dev), he
> was moving toward a coroutine based Medusa and away from async* based.

I don't think that was medusa. I tink it was something else.

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org


From barry@digicool.com  Fri Apr  6 16:34:54 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 6 Apr 2001 11:34:54 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
 <3ACDB0BC.2533D8C2@digicool.com>
 <15053.56089.93466.30362@anthem.wooz.org>
 <3ACDDF49.A641466E@digicool.com>
Message-ID: <15053.57886.530944.174828@anthem.wooz.org>

>>>>> "JF" == Jim Fulton <jim@digicool.com> writes:

    JF> I don't think that was medusa. I tink it was something else.

Sam called it the "next generation medusa". :)


From guido@digicool.com  Fri Apr  6 18:52:16 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 06 Apr 2001 12:52:16 -0500
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: Your message of "Fri, 06 Apr 2001 04:46:54 -0400."
 <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
Message-ID: <200104061752.MAA15185@cj20424-a.reston1.va.home.com>

> I haven't used those modules myself, so don't know whether this request is
> reasonable:  could someone please whip up an at least minimal standard test
> case for these modules?  So long as it runs on at least one of {Windows,
> Linux}, we'd catch problems like this almost instantly.  As is, AFAICT we
> don't even import asynchat (the "import asynchat" line in test_sundry.py is
> commented out but no reason is given for that -- anyone know why?).

I just checked in a testcase for asynchat that also tests asyncore.

It works on Windows98se and Linux Red Hat 6.2, at least.  Enjoy!

I guess the line from test_sundry.py can now be deleted -- ditto for
the import of asyncore.

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


From tim.one@home.com  Fri Apr  6 20:00:06 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 6 Apr 2001 15:00:06 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: <200104061752.MAA15185@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEKNJKAA.tim.one@home.com>

[Guido]
> I just checked in a testcase for asynchat that also tests asyncore.

Excellent -- thank you!

> ...
> I guess the line from test_sundry.py can now be deleted -- ditto for
> the import of asyncore.

Done.



From tim.one@home.com  Fri Apr  6 23:27:53 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 6 Apr 2001 18:27:53 -0400
Subject: [Python-Dev] A kind of configuration question
In-Reply-To: <200104061502.KAA14238@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIELMJKAA.tim.one@home.com>

[Guido, to Paul Moore]
> ...
> We seem to disagree on how Windows users use their system.  You seem
> to be a command line user on Windows.  Both Tim & me are more
> mouse-based users, and neither of us spends a lot of time in the
> command line, so we don't see the point of adding yet another thing to
> the distribution.  It is my expectation that *most* Windows users (and
> developers) are like Tim & me, not like you, so we don't feel (if I
> may channel Tim for a change :-) that this would benefit most users.

Well, when playing Windows developer I spend most of my life in a DOS box.
But when playing Windows developer, I also have no need for anyone to write a
trivial .bat file for me, and indeed would probably write my own anyway to
cater to that, e.g., I can set up useful cmdline associations for Python on
Win2K but not Win9X.  Is there *any* Windows developer out there too lame to
do this for themself?  I doubt it.

Does it hurt to include a little .bat file anyway?  YES!  Most Python users
on Windows are not Windows developers, and unlike Paul I'm going to spend a
fair chunk of my life on the Tutor and Help lists trying to explain to the
vast majority *why* the pydoc.bat file in the install directory is useless to
them on their Win9X boxes.  BTW, I use Win9X deliberately at home, partly
because that's what my sisters use, and partly to keep my sympathy high for
all of Python's thousands of Win9X sufferers.

If you want to supply pydoc .bat files, fine, work out a minimal set with
Ping and submit a patch to put them in the Tools/scripts/ directory.  One of
them has to be suitable for linking to directly from the pydoc Start menu
item, but beyond that if they're out of sight they're out of mind so I don't
much care.  I actively want to keep them *out* of the main installation
directory, because newbies want to know about *every* file in that directory,
and there's nothing positive we can tell them about a pydoc.bat file under
their Win9X systems (unless all it does is bring up a GUI).  It's no accident
that Python doesn't ship with any .bat files today.

no-need-to-bend-over-backwards-to-help-people-who-don't-need-help-ly y'rs
    - tim



From tim.one@home.com  Fri Apr  6 23:42:22 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 6 Apr 2001 18:42:22 -0400
Subject: [Python-Dev] A kind of configuration question
In-Reply-To: <0a8201c0bea4$b24cb760$e46940d5@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELNJKAA.tim.one@home.com>

[/F]
> I'm +0 on a pydoc command, but even if it's not added to the
> standard distribution, I'm +1 on making sure pydoc works in case
> someone wants to add a batchfile shortcut themselves.

Can you be more specific?  AMK's Tools/scripts/pydoc works on Windows,
although from a Win9x shell the text modes are more frustrating than useful,
and if you use "python" to start it instead of "pythonw" and ask for a GUI
mode, you're subject to Tk freezing the DOS box (etc) from time to time.  So
does pydoc "work" now or not in your view?  If not, what does "work" mean?

The Windows installer currently creates a Start menu item pointing to Ping's
Tools/scripts/pydoc.pyw program instead, which works fine, and just executes
pydoc.gui().



From fdrake@cj42289-a.reston1.va.home.com  Sat Apr  7 06:45:43 2001
From: fdrake@cj42289-a.reston1.va.home.com (Fred Drake)
Date: Sat,  7 Apr 2001 01:45:43 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010407054543.226DD2879A@cj42289-a.reston1.va.home.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


Lots of small fixes, but also the first installment of the unittest
documentation.



From jack@oratrix.nl  Sat Apr  7 13:00:15 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Sat, 07 Apr 2001 14:00:15 +0200
Subject: [Python-Dev] Import hook to do end-of-line conversion?
Message-ID: <20010407120021.5503DEA11D@oratrix.oratrix.nl>

[Oops, try again]

There's talk on the PythonMac-SIG to create an import hook that would
read modules with either \r, \n or \r\n newlines and convert them to
the local convention before feeding them to the rest of the import
machinery. The reason this has become interesting is the mixed
unixness/macness of MacOSX, where such an import hook could be used to
share a Python tree between MacPython and bsd-Python. They would only
need a different site.py (probably), living somehwere near the head of
sys.path, that would be in local end of line convention and enable the
hook.

However, it seem that such a module would have a much more general
scope, for instance if you're accessing samba partitions from windows,
or other foreign file systems, etc.

Does this sound like a good idea? And (even better:-) has anyone done
this already? Would it be of enough interest to include it in the
core Lib?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | ++++ see http://www.xs4all.nl/~tank/ ++++


From fredrik@pythonware.com  Sat Apr  7 17:25:52 2001
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sat, 7 Apr 2001 18:25:52 +0200
Subject: [Python-Dev] Import hook to do end-of-line conversion?
References: <20010407120021.5503DEA11D@oratrix.oratrix.nl>
Message-ID: <004c01c0bf7f$6b64e4e0$e46940d5@hagrid>

jack wrote:
> There's talk on the PythonMac-SIG to create an import hook that would
> read modules with either \r, \n or \r\n newlines and convert them to
> the local convention before feeding them to the rest of the import
> machinery.

why not fix the compiler instead?

Cheers /F



From gstein@lyra.org  Sat Apr  7 17:21:14 2001
From: gstein@lyra.org (Greg Stein)
Date: Sat, 7 Apr 2001 09:21:14 -0700
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <004c01c0bf7f$6b64e4e0$e46940d5@hagrid>; from fredrik@pythonware.com on Sat, Apr 07, 2001 at 06:25:52PM +0200
References: <20010407120021.5503DEA11D@oratrix.oratrix.nl> <004c01c0bf7f$6b64e4e0$e46940d5@hagrid>
Message-ID: <20010407092114.E31832@lyra.org>

On Sat, Apr 07, 2001 at 06:25:52PM +0200, Fredrik Lundh wrote:
> jack wrote:
> > There's talk on the PythonMac-SIG to create an import hook that would
> > read modules with either \r, \n or \r\n newlines and convert them to
> > the local convention before feeding them to the rest of the import
> > machinery.
> 
> why not fix the compiler instead?

Exactly. That is where the correct fix should go. The compile can/should
recognize all types of newlines as the NEWLINE token.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


From just@letterror.com  Sat Apr  7 17:40:02 2001
From: just@letterror.com (Just van Rossum)
Date: Sat,  7 Apr 2001 18:40:02 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <20010407092114.E31832@lyra.org>
Message-ID: <20010407184003-r01010600-1327fbb2@213.84.27.177>

Greg Stein wrote:

> On Sat, Apr 07, 2001 at 06:25:52PM +0200, Fredrik Lundh wrote:
> > jack wrote:
> > > There's talk on the PythonMac-SIG to create an import hook that would
> > > read modules with either \r, \n or \r\n newlines and convert them to
> > > the local convention before feeding them to the rest of the import
> > > machinery.
> > 
> > why not fix the compiler instead?
> 
> Exactly. That is where the correct fix should go. The compile can/should
> recognize all types of newlines as the NEWLINE token.

The same goes for file objects in text mode...

Just


From fredrik@pythonware.com  Sat Apr  7 17:54:28 2001
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sat, 7 Apr 2001 18:54:28 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
References: <20010407184003-r01010600-1327fbb2@213.84.27.177>
Message-ID: <00b901c0bf83$69b1e0e0$e46940d5@hagrid>

Just wrote:
> > > why not fix the compiler instead?
> > 
> > Exactly. That is where the correct fix should go. The compile can/should
> > recognize all types of newlines as the NEWLINE token.
> 
> The same goes for file objects in text mode...

probably -- but changing can break stuff (in theory, at least), and
may require a PEP.  changing the compiler is more of a bugfix, really...

Cheers /F



From just@letterror.com  Sat Apr  7 18:26:26 2001
From: just@letterror.com (Just van Rossum)
Date: Sat,  7 Apr 2001 19:26:26 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <00b901c0bf83$69b1e0e0$e46940d5@hagrid>
Message-ID: <20010407192627-r01010600-b0457661@213.84.27.177>

Fredrik Lundh wrote:

> Just wrote:
> > > > why not fix the compiler instead?
> > > 
> > > Exactly. That is where the correct fix should go. The compile can/should
> > > recognize all types of newlines as the NEWLINE token.
> > 
> > The same goes for file objects in text mode...
> 
> probably -- but changing can break stuff (in theory, at least), and
> may require a PEP.  changing the compiler is more of a bugfix, really...

But if we only fix the compiler, we'll get complaints that other things
don't work, eg. bogus tracebacks due to a non-fixed linecache.py, broken IDE's,
etc.

Btw. I can't seem to think of any examples that would break after such a change.
I mean, who would depend on a \n text file with embedded \r's?

Just


From paul@pfdubois.com  Sat Apr  7 18:33:57 2001
From: paul@pfdubois.com (Paul F. Dubois)
Date: Sat, 7 Apr 2001 10:33:57 -0700
Subject: [Python-Dev] Progress report on PEP 242
Message-ID: <ADEOIFHFONCLEEPKCACCCENICHAA.paul@pfdubois.com>

If I understand correctly I need to supply a reference implementation for
PEP 242.

I have made considerable progress on this:

C:\Paul\Numerical\Packages\kinds>python
Python 2.1b2 (#12, Mar 23 2001, 14:01:30) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import kinds
>>> f=kinds.float_kind(5,100)
>>> f.max
1.7976931348623157e+308
>>> f.min
2.2250738585072014e-308
>>> f.epsilon
2.2204460492503131e-016
>>> f.radix
0.3010299956639812
>>> f.epsilonbyradix
1.1102230246251565e-016
>>> 10.0**f.radix
2.0    # in case you were wondering...
>>> f(7)
7.0
>>>

These five attributes are the standard ones computed by routines such as
d1mach.
(See netlib.org, search for d1mach).

These attributes I made up:

f.name ('Float' in this case)
f.typecode ('d' in this case, a typecode suitable for modules array or
Numeric

I haven't updated the PEP itself with the comments I got, but it essentially
amounts to fixing the section on coercion, which I mainly realized I don't
really have to deal with.



From guido@digicool.com  Sat Apr  7 19:43:45 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 07 Apr 2001 13:43:45 -0500
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Sat, 07 Apr 2001 14:00:15 +0200."
 <20010407120021.5503DEA11D@oratrix.oratrix.nl>
References: <20010407120021.5503DEA11D@oratrix.oratrix.nl>
Message-ID: <200104071843.NAA23537@cj20424-a.reston1.va.home.com>

> There's talk on the PythonMac-SIG to create an import hook that would
> read modules with either \r, \n or \r\n newlines and convert them to
> the local convention before feeding them to the rest of the import
> machinery. The reason this has become interesting is the mixed
> unixness/macness of MacOSX, where such an import hook could be used to
> share a Python tree between MacPython and bsd-Python. They would only
> need a different site.py (probably), living somehwere near the head of
> sys.path, that would be in local end of line convention and enable the
> hook.
> 
> However, it seem that such a module would have a much more general
> scope, for instance if you're accessing samba partitions from windows,
> or other foreign file systems, etc.
> 
> Does this sound like a good idea? And (even better:-) has anyone done
> this already? Would it be of enough interest to include it in the
> core Lib?

I know that it's too late for 2.1, but for 2.2, I think we can do
better: like Java, the import mechanism should accept all three line
ending conventions on all platforms!  It would also be nice if opening
a file in text mode did this transformation, but alas, that would
probably require more work on the file object than I care for.  But
import should be doable!

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


From guido@digicool.com  Sat Apr  7 19:57:10 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 07 Apr 2001 13:57:10 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Sat, 07 Apr 2001 19:26:26 +0200."
 <20010407192627-r01010600-b0457661@213.84.27.177>
References: <20010407192627-r01010600-b0457661@213.84.27.177>
Message-ID: <200104071857.NAA23651@cj20424-a.reston1.va.home.com>

> > > The same goes for file objects in text mode...

Yes.

> > probably -- but changing can break stuff (in theory, at least), and
> > may require a PEP.  changing the compiler is more of a bugfix, really...

Yes.

> But if we only fix the compiler, we'll get complaints that other
> things don't work, eg. bogus tracebacks due to a non-fixed
> linecache.py, broken IDE's, etc.

Yes.

> Btw. I can't seem to think of any examples that would break after
> such a change.  I mean, who would depend on a \n text file with
> embedded \r's?

On Unix, currently, tell() always give you a number that exactly
matches the number of characters you've read since the beginning of
the file.  This would no longer be true.  In general, code written on
Unix with no expectation to ever leave Unix, can currently be sloppy
about using binary mode, and open binary files in text mode.  Such
code could break.  I'm sure there's plenty such code around (none
written by me :-).

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



From tim.one@home.com  Sat Apr  7 22:15:30 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 7 Apr 2001 17:15:30 -0400
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104071843.NAA23537@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIENFJKAA.tim.one@home.com>

As Guido said, Java defines that source-code lines end with any of LF, CR, or
CRLF, and that needn't even be consistent across lines.

If source files are opened in C binary mode, this is easy enough to do but
puts all the burden for line-end detection on Python.

Opening source files in C text mode doesn't solve the problem either.  For
example, if you open a source file with CR endings in Windows C text mode,
Windows thinks the entire file is "one line".  I expect the same is true if
CR files are opened in Unix text mode.

So, in the end, binary mode appears to be better (more uniform code).  But
then what happens under oddball systems like OpenVMS, which seem to use
radically different file structures for text and binary data?  I've no idea
what happens if you try to open a text file in binary mode under those.

[Guido]
> ...
> It would also be nice if opening a file in text mode did this
> transformation, but alas, that would probably require more work
> on the file object than I care for.

Well, Python source files aren't *just* read by "the compiler" in Python.
For example, assorted tools in the std library analyze Python source files
via opening as ordinary (Python) text files, and the runtime traceback
mechanism opens Python source files in (C) text mode too.  For that stuff to
work correctly regardless of line ends is lots of work in lots of places.  In
the end I bet it would be easier to replace all direct references to C
textfile operations with a "Python text file" abstraction layer.

importing-is-only-the-start-of-the-battle-ly y'rs  - tim



From tim.one@home.com  Sat Apr  7 22:27:35 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 7 Apr 2001 17:27:35 -0400
Subject: [Python-Dev] FW: PyChecker - a python source code bug finder
Message-ID: <LNBBLJKPBEHFEDALKOLCCENHJKAA.tim.one@home.com>

Way cool!  Check this out.  I picked 4 of the problems Neal found "at
random", and all appear to still exist under current CVS.  How about everyone
take their favorite module and fix it?

Thank you, Neal!

-----Original Message-----
From: python-list-admin@python.org
[mailto:python-list-admin@python.org]On Behalf Of Neal Norwitz
Sent: Saturday, April 07, 2001 2:28 PM
To: python-announce-list@python.org; python-list@python.org
Subject: PyChecker - a python source code bug finder



PyChecker is a python source code checking tool to help you find common bugs.
It is meant to find problems that are typically caught by a compiler. Because
of the dynamic nature of python, some warnings may be incorrect; however,
spurious warnings should be fairly infrequent.

Types of problems that can currently, be found include:

    * No doc strings in modules, classes, functions, and methods
    * self not the first parameter to a method
    * Wrong number of parameters passed to functions/methods
    * No global found (e.g., using a module without importing it)
    * Global not used (module or variable)

PyChecker currently runs on Python 2.0.  If there's interest, it can be back
ported to Python 1.5.2.

I have run PyChecker against Python 2.1b2a, the following are problems found
in the standard python modules:

    ### Warnings
        codeop.py:3 Imported module (sys) not used
        codeop.py:4 Imported module (traceback) not used
        fileinput.py:292 Function (input) doesn't require named arguments
        multifile.py:30 Imported module (sys) not used
        pipes.py:62 Imported module (sys) not used
        urllib.py:598 Function (quote) doesn't require named arguments
        urllib.py:611 Function (quote) doesn't require named arguments
        string.py:190 Variable (_StringType) not used
        tabnanny.py:15 Imported module (string) not used
                        imported again @ 241 and used there

    ### Errors:
        audiodev.py:214 No global (BUFFERSIZE) found
        bdb.py:111 No method (do_clear) found
        chunk.py:109 No attribute (chunk_size) found
			should be chunksize
        locale.py:253 No global (l) found
        netrc.py:13 No global (file) found
        pydoc.py:1070 No global (DocImportError) found
        pydoc.py:1070 No global (filename) found


PyChecker is available on Source Forge:
    web page:		http://pychecker.sourceforge.net/
    project page:	http://sourceforge.net/projects/pychecker/

Enjoy!  Feedback is greatly appreciated.

Neal
--
pychecker@metaslash.com

--
http://mail.python.org/mailman/listinfo/python-list



From tim.one@home.com  Sun Apr  8 07:41:55 2001
From: tim.one@home.com (Tim Peters)
Date: Sun, 8 Apr 2001 02:41:55 -0400
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <ADEOIFHFONCLEEPKCACCCENICHAA.paul@pfdubois.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com>

[Paul F. Dubois]
> If I understand correctly I need to supply a reference implementation
> for PEP 242.

Somebody does, but not necessarily you.

> I have made considerable progress on this:

Cool!  I'm glad it was you <wink>.

> C:\Paul\Numerical\Packages\kinds>python
> Python 2.1b2 (#12, Mar 23 2001, 14:01:30) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import kinds
> >>> f=kinds.float_kind(5,100)
> >>> f.max
> 1.7976931348623157e+308

What type of float is the result?  Is that defined?  Of the same float kind
as requested?  Or of some fixed float kind?  Or does/can it vary across
attributes?

> >>> f.min
> 2.2250738585072014e-308

Is it customary to ignore the existence of denorms?  All the same to me, but
since that's not the smallest positive non-zero double on a 754 box, the name
"min" is a fiction.  If it's a *useful* fiction, fine.

> >>> f.epsilon
> 2.2204460492503131e-016
> >>> f.radix
> 0.3010299956639812

I expect that, if you really try, you can think of a better name <wink -- but
log10radix would make a lot more sense here; + see below>.

> >>> f.epsilonbyradix
> 1.1102230246251565e-016
>
> These five attributes are the standard ones computed by routines such
> as d1mach.
> (See netlib.org, search for d1mach).

There are several.  Most are Fortran routines that ask you to first uncomment
the correct section of hard-coded DATA stmts for the platform you're running
on.  I trust you're using a dynamic approach.

Question:  are these attributes useful enough in the absence of the model
parameters from I1MACH?  That is, D1MACH exposes an idealized floating point
model approximating machine reality, parameterized by a base (radix), number
of digits, and minimum and maximum exponents.  Those four are all integers,
so were traditionally exposed via I1MACH instead (at I1MACH indices 10, 14,
15 and 16).  I expect people would find it useful if you exposed those as
attributes too, i.e. hypothetically continuing the above:

>>> f.radix  # assuming existing f.radix renamed
2
>>> f.numdigits
53
>>> f.emin
-1021
>>> f.emax
1024
>>>

Then the explanation of what the other attributes *mean* is easy, relating
them directly to the idealized f.p. model D1MACH is based on:

f.log10radix = log10(f.radix)
f.epsilon = f.radix ** (1-f.numdigits)
f.epsilonbyradix = f.radix ** -f.numdigits
f.min = f.radix ** (f.emin - 1)
f.max = f.radix**f.emax * (1 - f.epsilonbyradix)

(That last one isn't numerically correct, but mathematically; in code you'd
have to write it

    math.ldexp(1.0 - f.epsilonbyradix, f.emax)

and assuming f.radix is 2).  Note that exposing this stuff also makes clearer
why f.min doesn't tell the hardware's notion of truth for 754 boxes.

> These attributes I made up:
>
> f.name ('Float' in this case)

Since you're extending Python's floating type system with precision & range
parameters, I'd much rather see this one called 'double', since you're
obviously using a box with IEEE-754 doubles here, and all C implementations I
know of call this a double too; I expect that 99+% of all F77 implementations
also call this one double.  In addition, I expect you'll soon deal with IEEE
singles too, and then the question "single or double?" makes clear sense, but
"single or float?" is just baffling.

> f.typecode ('d' in this case, a typecode suitable for modules array or
> Numeric

Yet another reason to start f.name with "d", right?  Right <wink>.



From jim@interet.com  Sun Apr  8 14:50:23 2001
From: jim@interet.com (James C. Ahlstrom)
Date: Sun, 08 Apr 2001 09:50:23 -0400
Subject: [Python-Dev] Problems with zipfile.py
Message-ID: <3AD06C9F.848B0A98@interet.com>

The zipfile module seems to have been well received, and
I have the impression that many people are using it.  But
I have been getting complaints that it won't read ZIP files
created by InfoZip.  At first I thought this was a problem
with incompatible zlib compression versions, but now I have
found the problem.

It turns out that InfoZip's Wiz version 5.02 (and maybe other
InfoZip versions) creates ZIP files with an incorrect value
for "extra data length" in the central directory, but the correct
value in the file header.  The "extra data" is before the compressed
file data, and so this causes the file data offset to be off slightly
thus causing complaints from the zlib decompressor.  I changed
zipfile.py to use the file header value, and it fixes the problem.

I also added a new method restore(self, name, fileobject) which
was suggested some time ago by MAL.  It writes to an open file
or any other object with a write() method.  It avoids the need
to read the whole file into memory.

I also changed the "raise" statements to use the "zipfile.error"
exception.  This agrees with the documentation, but previously
zipfile raised a variety of exceptions.  This also fixes the
complaint that "BadZipfile" should be spelled "BadZipFile".

The new changed zipfile.py is available from
            ftp://ftp.interet.com/pub/zipfile.py
and is currently being tested by a user.  Please take a look.

JimA


From guido@digicool.com  Sun Apr  8 16:23:36 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 08 Apr 2001 10:23:36 -0500
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: Your message of "Sun, 08 Apr 2001 02:41:55 -0400."
 <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com>
Message-ID: <200104081523.KAA31118@cj20424-a.reston1.va.home.com>

I don't know if it answers all the questions one could ask about a
floating point implementation, but long ago my esteemed Dutch
colleague Steven Pemberton (ABC project lead, these days chair of the
W3C XHTML working group) wrote a C program, "enquire.c", that attempts
to figure out lots of machine details.  It might help finding the
properties of floats and doubles without assuming IEEE-754.

http://www.cwi.nl/~steven/enquire.html

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


From fdrake@acm.org  Sun Apr  8 16:21:27 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Sun, 8 Apr 2001 11:21:27 -0400 (EDT)
Subject: [Python-Dev] Problems with zipfile.py
In-Reply-To: <3AD06C9F.848B0A98@interet.com>
References: <3AD06C9F.848B0A98@interet.com>
Message-ID: <15056.33271.519639.865010@cj42289-a.reston1.va.home.com>

James C. Ahlstrom writes:
 > It turns out that InfoZip's Wiz version 5.02 (and maybe other
 > InfoZip versions) creates ZIP files with an incorrect value
 > for "extra data length" in the central directory, but the correct
 > value in the file header.  The "extra data" is before the compressed
 > file data, and so this causes the file data offset to be off slightly
 > thus causing complaints from the zlib decompressor.  I changed
 > zipfile.py to use the file header value, and it fixes the problem.

  This was fixed by a patch from Jens Quade in CVS revision 1.7 of
zipfile.py.

 > I also added a new method restore(self, name, fileobject) which
 > was suggested some time ago by MAL.  It writes to an open file
 > or any other object with a write() method.  It avoids the need
 > to read the whole file into memory.

  Cool!  I'll try to look at this Monday, but I'm not sure it should
go in for Python 2.1 -- it is a new feature, and we're supposed to be
in a feature freeze.

 > I also changed the "raise" statements to use the "zipfile.error"
 > exception.  This agrees with the documentation, but previously
 > zipfile raised a variety of exceptions.  This also fixes the
 > complaint that "BadZipfile" should be spelled "BadZipFile".

  I think the exceptions situation has been cleaned up as well.  You
might want to take a look at the version in Python CVS (soon to be
Python 2.1) to see what else has changed (most substantially, Itamar
Shtull-Trauring added support for loading ZIP files from open file
objects).


  -Fred

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



From paul@pfdubois.com  Sun Apr  8 16:31:53 2001
From: paul@pfdubois.com (Paul F. Dubois)
Date: Sun, 8 Apr 2001 08:31:53 -0700
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com>
Message-ID: <ADEOIFHFONCLEEPKCACCAEOFCHAA.paul@pfdubois.com>

Thank you for your excellent critique of my example. I will consider your
comments carefully.

The standard C library defines some constants in math.h that give the
required information. I think the right thing to do is simply include all of
those using names that make an identifiable connection to the standard
quantities (I had five of them, but there are more). This begs the question
of what to do if you are implementing Python over something other than C but
the definitions in the standard C library are clear, so in principle this
can be done.

The default Python floating point kind would be the one used to return the
(floating) attributes when queried, since I can't rely on their being any
other such kind; i.e., a C double.

Naming is going to be confusing no matter what we do. We're starting with
Python "float" == C "double" == Numeric Float == typecode 'd'. We're
doomed...




From tim.one@home.com  Sun Apr  8 20:32:34 2001
From: tim.one@home.com (Tim Peters)
Date: Sun, 8 Apr 2001 15:32:34 -0400
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <200104081523.KAA31118@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEPAJKAA.tim.one@home.com>

[Guido, on
   http://www.cwi.nl/~steven/enquire.html
]

Yup, we used that program back in my KSR days!  Looks like the source code
has grown by a factor of ~6 since then.  One of the most recent change log
entries is scary:

   5.1  Length 88739; Sep 1998
	...
	Speeded up search for max char (first 32 bit char machine
      turned up...)

The Python source code is going to be delighted with 32-bit chars.

assuming-they-went-out-of-business-already<0.7-wink>-ly y'rs  - tim



From greg@cosc.canterbury.ac.nz  Mon Apr  9 02:26:47 2001
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 09 Apr 2001 13:26:47 +1200 (NZST)
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <20010407120021.5503DEA11D@oratrix.oratrix.nl>
Message-ID: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz>

Jack Jansen <jack@oratrix.nl>:

> read modules with either \r, \n or \r\n newlines
> Does this sound like a good idea?

YES! It's always annoyed me that the Mac (seemingly without
good reason) complains about sources with \n line endings.
I have often shuttled code between Mac and Unix systems
during development, and having to do \r/\n translations
every time is a royal pain.

> Would it be of enough interest to include it in the
> core Lib?

I'd vote for building it right into the interpreter! Is
there any reason why anyone would want *not* to have it?

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@home.com  Mon Apr  9 06:00:18 2001
From: tim.one@home.com (Tim Peters)
Date: Mon, 9 Apr 2001 01:00:18 -0400
Subject: [Python-Dev] A kind of configuration question
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFC@ukrux002.rundc.uk.origin-it.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEABJLAA.tim.one@home.com>

[Moore, Paul]
> ...
> --- pydoc.bat ---
> @echo off
> if "%1"=="" pythonw -c "import pydoc; pydoc.cli()"
> if NOT "%1"=="" python -c "import pydoc; pydoc.cli()" %1 %2 %3 %4 ...
> ---
>
> I do the test on %1 so that if the command is called without any
> arguments, it uses pythonw to spawn the GUI webserver, whereas with
> arguments it does the command line stuff.

FYI, that's what appears to have gotten broken the morning of the 2.1b2
release.  If you do

    pythonw -c "import pydoc; pydoc.cli()"

then or today, "nothing happens" (actually, a usage blurb gets printed to
stdout, but under pythonw that's effectively /dev/null).

If you're determined to write .bat scripts <wink>, now you want

    pythonw -c "import pydoc; pydoc.gui()"

or

    pythonw -c "import pydoc; pydoc.cli()" -g

instead.



From tim.one@home.com  Mon Apr  9 07:36:24 2001
From: tim.one@home.com (Tim Peters)
Date: Mon, 9 Apr 2001 02:36:24 -0400
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <ADEOIFHFONCLEEPKCACCAEOFCHAA.paul@pfdubois.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEADJLAA.tim.one@home.com>

[Paul F. Dubois]
> The standard C library defines some constants in math.h that give
> the required information. I think the right thing to do is simply
> include all of those using names that make an identifiable connection
> to the standard quantities (I had five of them, but there are more).

It's in float.h in C.  Suggest looking at the new C99 std, since they did a
better job of defining these things than C89.  Luckily, they use the same
idealized model as R1MACH/D1MACH/I1MACH (in particular, they also view the
radix point as being "to the left" of all digits, so they agree on min and
max exponents).  float.h doesn't have an equivalent to your epsilonoverradix,
though).

> This begs the question of what to do if you are implementing Python
> over something other than C but the definitions in the standard C
> library are clear, so in principle this can be done.

Since virtually all boxes on Earth use IEEE-754 f.p. now, it's not like
there's a lot of variety they'll need to contend with (and, e.g., the Java
language spec requires 754 arithmetic specifically, so Jython's life can be
hardcoded).

> The default Python floating point kind would be the one used to
> return the (floating) attributes when queried, since I can't rely
> on their being any other such kind; i.e., a C double.

Hmm.  On second thought, if I do

    f = kinds.float_kind(m, n)

and it doesn't raise an exception, then surely the kind of float f() creates
*must* exist in this implementation.  Yes?  In that case f.min and f.max
(etc) can be of exactly the kind f() returns.  If you stick to C double, then
e.g. if I implement (say) IEEE double-extended, the kind object k building
such beasts couldn't return anything sensible for k.max and k.min, because C
double doesn't have enough precision or range to represent the max and min
(or epsilon or ...) double-extended values.  But a double-extended float can.

> Naming is going to be confusing no matter what we do. We're starting
> with Python "float" == C "double" == Numeric Float == typecode 'd'.
> We're doomed...

You can break that here, though.  Are these kinds utterly distinct types, or
merely different flavors of a single float type?  I assumed the latter (BTW,
the PEP really isn't clear about how kinds work in Python's type system), in
which case there's no problem saying that (for example)

    float_kind(1, 10)

builds floats of the single flavor,

    float_kind(1, 100)

builds floats of the double flavor, and

    float_kind(1, 1000)

builds floats of the extended or quad flavor.  Etc.  Since there is only one
kind of float in (base; non-NumPy) Python today, the need for distinctions
hasn't arisen.  But once a need arises, it seems downright natural to
continue calling all of them floats, but with a kind qualifier indicating
relative precision and/or range.  Then qualifiers like "single", "double",
"quad", "extended" and "unbounded" make intuitive sense to people, and that's
Good.  "float" implies something about size only to C programmers (much like
"real" implies something about size only to Fortran programmers).





From guido@digicool.com  Mon Apr  9 14:41:22 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 08:41:22 -0500
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Mon, 09 Apr 2001 13:26:47 +1200."
 <200104090126.NAA12369@s454.cosc.canterbury.ac.nz>
References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz>
Message-ID: <200104091341.IAA00888@cj20424-a.reston1.va.home.com>

> I'd vote for building it right into the interpreter! Is
> there any reason why anyone would want *not* to have it?

No, but (as has been explained) fixing the parser isn't enough -- all
tools dealing with source would have to be fixed.  Or we would have to
write our own C-level file object, which has its own drawbacks.

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


From Paul.Moore@uk.origin-it.com  Mon Apr  9 14:36:34 2001
From: Paul.Moore@uk.origin-it.com (Moore, Paul)
Date: Mon, 9 Apr 2001 14:36:34 +0100
Subject: [Python-Dev] A kind of configuration question
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AE08@ukrux002.rundc.uk.origin-it.com>

From: Guido van Rossum [mailto:guido@digicool.com]
> > On a related note, has anything happened on my other bug 
> > report (406280)? At the very least, using tempfilepager
> > instead of pipepager as a workaround would be sensible.
> > Leaving things broken makes no real sense. This is a
> > patch:
> 
> What's broken?  After "from pydoc import help" I can use help(...)
> just fine, both in the command line version (where it invokes some
> pager) and in IDLE (where it just scrolls off the window, but IDLE has
> infinite scroll-back so that's no problem).  This is on Win98se with
> Python 2.1b2.

It doesn't work in console version python.exe if you set PAGER in the
environment. I have PAGER set to "less", a much better replacement for
"more". This is on Win2000 SP1.

It works if you leave PAGER unset.

Please can this bug-fix be applied before 2.1 release? It makes it look like
pydoc just "doesn't work", as things stand. And the link to having PAGER set
is obscure, at best.

Paul.


From info@webb2e.com  Mon Apr  9 19:35:09 2001
From: info@webb2e.com (info@webb2e.com)
Date: Mon, 9 Apr 2001 11:35:09 -0700
Subject: [Python-Dev] Free register of online company's profile
Message-ID: <051071035180941MAIL@mail3.chinainfoland.com>

This is a multi-part message in MIME format.

------=_NextPart_000_127BC_01C0C0E9.221728F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

How much are you paying to advertise your business to the world? 

Expose Your service to the world with bold register of online business
profile. Sign up today! 

Introducing WebB2E.com -- your direct link to global information; source
of business, products, education/research, social/culture, entertainment
and travel... 
Additionally you can BUY, SELL or PROMOTE your products and services 
At www.webb2e.com <http://webb2e.com/promo1.asp>  you'll get: 

--Message center (open to the public). 
--Employment center. 
--Sponsorship center. 
--Bulletin board (business and service issue). 
--Flexible Online Office (Business Online Report). 
--Economic news. 
--View thousands of trade leads. 
--Post business propositions. 
--Merchandise marketing (Vast advertising at a low cost). 
--World shopping center. 

.. and much more. Please visit www.webb2e.com
<http://webb2e.com/promo1.asp>  

If you do not want to recieve any more e-mails from WebB2E.com and wish
to be removed from e-mail list please click here
<http://webb2e.net/remove.asp?email=python-dev@python.org> . 



------=_NextPart_000_127BC_01C0C0E9.221728F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html><head><title>www.webb2e.com</title><meta =
http-equiv=3D'Content-Type' content=3D'text/html; =
charset=3Diso-8859-1'></head><body bgcolor=3D'#FFFFFF'>How much are you =
paying to advertise your business to the world? <br><br>Expose Your =
service to the world with bold register of online business profile. Sign =
up today! <br><br>Introducing WebB2E.com -- your direct link to global =
information; source of business, products, education/research, =
social/culture, entertainment and travel... <br>Additionally you can =
BUY, SELL or PROMOTE your products and services  <br>At <a =
href=3D'http://webb2e.com/promo1.asp'>www.webb2e.com</a> you'll get:  =
<br><br>--Message center (open to the public).  <br>--Employment center. =
<br>--Sponsorship center. <br>--Bulletin board (business and service =
issue). <br>--Flexible Online Office (Business Online Report).  =
<br>--Economic news. <br>--View thousands of trade leads.  <br>--Post =
business propositions.  <br>--Merchandise marketing (Vast advertising at =
a low cost).  <br>--World shopping center. <br><br>... and much more. =
Please visit <a href=3D'http://webb2e.com/promo1.asp'>www.webb2e.com</a> =
 <br><br>If you do not want to recieve any more e-mails from WebB2E.com =
and wish to be removed from e-mail list please <a =
href=3D'http://webb2e.net/remove.asp?email=3Dpython-dev@python.org'>click=
 here</a>. <br><br></body></html>
------=_NextPart_000_127BC_01C0C0E9.221728F0--


From chrishbarker@home.net  Mon Apr  9 19:47:25 2001
From: chrishbarker@home.net (Chris Barker)
Date: Mon, 09 Apr 2001 11:47:25 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> <200104091341.IAA00888@cj20424-a.reston1.va.home.com>
Message-ID: <3AD203BD.E544ED0F@home.net>

Guido van Rossum wrote:
> No, but (as has been explained) fixing the parser isn't enough -- all
> tools dealing with source would have to be fixed.  Or we would have to
> write our own C-level file object, which has its own drawbacks.

>From what people have posted, it seems clear that having our own C-level
file object is the only reasonable choice. It would take care of all the
issues that have been brought up (both code and other text files, etc).
Even if people have been sloppy and used binary mode for text files
under *nix, that code would still work with *nix text files, which is
the only way it works now anyway.

Given that something like this has been done in numerous places (JAVA,
MATLAB, ???), It seems likely that there is some code out there that
could be used. Hopefully there is some without licensing issues (Maybe
Scilab or Octave, both are MATLAB clones)

What are the drawbacks?? (besides the below example)

I'm not sure who wrote:
> what happens under oddball systems like OpenVMS, which seem to use
> radically different file structures for text and binary data?  I've no idea
> what happens if you try to open a text file in binary mode under those.

Would we have to? At the Python level, you would open a text file, and
get what you expected. The "oddball" port would have to have some
probably very different code for the C-level file object, but that's
presumable the case anyway. what happens when you want to read a
non-native text file on those systems now? So you have to read it as
binary?

By the way, does any of this tie in at all with trying to add Perl-like
speed to processing text files?

-Chris



-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker@home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------


From guido@digicool.com  Mon Apr  9 21:20:13 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 15:20:13 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Mon, 09 Apr 2001 11:47:25 MST."
 <3AD203BD.E544ED0F@home.net>
References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> <200104091341.IAA00888@cj20424-a.reston1.va.home.com>
 <3AD203BD.E544ED0F@home.net>
Message-ID: <200104092020.PAA02237@cj20424-a.reston1.va.home.com>

> Guido van Rossum wrote:
> > No, but (as has been explained) fixing the parser isn't enough -- all
> > tools dealing with source would have to be fixed.  Or we would have to
> > write our own C-level file object, which has its own drawbacks.
> 
> From what people have posted, it seems clear that having our own C-level
> file object is the only reasonable choice. It would take care of all the
> issues that have been brought up (both code and other text files, etc).
> Even if people have been sloppy and used binary mode for text files
> under *nix, that code would still work with *nix text files, which is
> the only way it works now anyway.
> 
> Given that something like this has been done in numerous places (JAVA,
> MATLAB, ???), It seems likely that there is some code out there that
> could be used. Hopefully there is some without licensing issues (Maybe
> Scilab or Octave, both are MATLAB clones)

I doubt that we could use anything that was done for another language,
because everybody who codes this kind of thing makes it do exactly
what their environment needs, e.g. in terms of error handling API,
functionality, and performance.

> What are the drawbacks?? (besides the below example)

The drawbacks aren't so much technical (I have a pretty good idea of
how to build such a thing), they're political and psychological.
There's the need for supporting the old way of doing things for years,
there's the need for making it easy to convert existing code to the
new way, there's the need to be no slower than the old solution,
there's the need to be at least as portable as the old solution (which
may mean implementing it *on top of* stdio since on some systems
that's all you've got).

> I'm not sure who wrote:
> > what happens under oddball systems like OpenVMS, which seem to use
> > radically different file structures for text and binary data?  I've no idea
> > what happens if you try to open a text file in binary mode under those.
> 
> Would we have to? At the Python level, you would open a text file, and
> get what you expected. The "oddball" port would have to have some
> probably very different code for the C-level file object, but that's
> presumable the case anyway. what happens when you want to read a
> non-native text file on those systems now? So you have to read it as
> binary?
> 
> By the way, does any of this tie in at all with trying to add Perl-like
> speed to processing text files?

It would be one way towards that goal.  But notice that we've already
gotten most of the way there with the recent readline changes in 2.1.

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


From just@letterror.com  Mon Apr  9 21:00:22 2001
From: just@letterror.com (Just van Rossum)
Date: Mon,  9 Apr 2001 22:00:22 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104092020.PAA02237@cj20424-a.reston1.va.home.com>
Message-ID: <20010409220023-r01010600-7dc11706@213.84.27.177>

Proposal for 2.2, outline for a PEP?


1)
The Python file object needs to be modified so that in text mode it can
recognize all major line ending conventions (Unix, Win and Mac).

Reading data:
  - recognize \n, \r and \r\n as line ending, present as \n to Python
Writing data:
  - convert \n to the platform line endings (this is already the case)

This modification should be _optional_, because it may break code under unix
(insert Guido's explanation here), and because it may not support oddball
systems like OpenVMS.

It should be _on_ by default under:
- Windows
- MacPython Classic
- MacPython Carbon
- Unix Python under MacOS X / Darwin

It should probably be off by default on all other systems (I think a
compile-time switch is good enough). Maybe if we advertize the potential
sloppy-unix-code-breakage loud enough we can make the feature mandatory in a
later release, however I don't see a practical way of issuing warnings for the
situation.


2)
I assume there are quite a few places where Python uses raw C text files: these
places should be identified, we should figure out how much work it is to fix
these so they behave just like the Python file object as described above.



Who would like to team up with me to write a decent PEP and maybe an example
implementation?


Just


From nhodgson@bigpond.net.au  Mon Apr  9 21:46:11 2001
From: nhodgson@bigpond.net.au (Neil Hodgson)
Date: Tue, 10 Apr 2001 06:46:11 +1000
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
References: <20010409220023-r01010600-7dc11706@213.84.27.177>
Message-ID: <007401c0c136$f7d1cb10$8119fea9@neil>

Just van Rossum:

> It should probably be off by default on all other systems (I think a
> compile-time switch is good enough). Maybe if we advertize the potential
> sloppy-unix-code-breakage loud enough we can make the feature mandatory in
a
> later release, however I don't see a practical way of issuing warnings for
the
> situation.

    It should be on by default for the Python interpreter reading Python
programs as making it off by default leads to the inability to run programs
written with Windows or Mac tools on Unix which was the problem reported by
'dsavitsk' on comp.lang.python.

   If it is going to be off by default then the error message should include
"Rerun with -f to fix this error".

   Neil




From just@letterror.com  Mon Apr  9 22:07:20 2001
From: just@letterror.com (Just van Rossum)
Date: Mon,  9 Apr 2001 23:07:20 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <007401c0c136$f7d1cb10$8119fea9@neil>
Message-ID: <20010409230721-r01010600-08aa8401@213.84.27.177>

Neil Hodgson wrote:

> Just van Rossum:
> 
> > It should probably be off by default on all other systems (I think a
> > compile-time switch is good enough). Maybe if we advertize the potential
> > sloppy-unix-code-breakage loud enough we can make the feature mandatory in
> > a later release, however I don't see a practical way of issuing warnings for
> > the situation.
> 
>     It should be on by default for the Python interpreter reading Python
> programs as making it off by default leads to the inability to run programs
> written with Windows or Mac tools on Unix which was the problem reported by
> 'dsavitsk' on comp.lang.python.

Yes, but as was mentioned before: this will lead to other problems for which we
wouldn't have a good excuse: any program printing a traceback with the traceback
module will output bogus data if linecache.py will read the source files
incorrectly. And that's just one example. I don't think the two features should
be switchable separately.

Maybe it should be on by default, provided we have a command line switch to to
turn the new behavior *off*, just like there used to be a command line switch to
revert to string based exceptions.

Just


From greg@cosc.canterbury.ac.nz  Tue Apr 10 00:56:09 2001
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 11:56:09 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104071857.NAA23651@cj20424-a.reston1.va.home.com>
Message-ID: <200104092356.LAA12517@s454.cosc.canterbury.ac.nz>

Guido:

> code written on
> Unix with no expectation to ever leave Unix, can currently be sloppy
> about using binary mode

Maybe there should be a third mode, "extremely text mode",
which Python-source-processing utilities (and anything else
which wants to be cross-platform-line-ending-friendly) can
use.

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 Apr 10 01:21:36 2001
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 12:21:36 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD203BD.E544ED0F@home.net>
Message-ID: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>

Chris Barker <chrishbarker@home.net>:

> Even if people have been sloppy and used binary mode for text files
> under *nix, that code would still work with *nix text files, which is
> the only way it works now anyway.

That's a good point. The only thing that could break is if
you opened a non-Unix file in *text* mode, and then expected
it to behave as though it had been opened in *binary* mode.
I can't imagine any code being screwy enough to do 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 chrishbarker@home.net  Tue Apr 10 01:37:39 2001
From: chrishbarker@home.net (Chris Barker)
Date: Mon, 09 Apr 2001 17:37:39 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
References: <20010409220023-r01010600-7dc11706@213.84.27.177>
Message-ID: <3AD255D3.9872C019@home.net>

Just van Rossum wrote:
> Proposal for 2.2, outline for a PEP?

Thanks, Just, for getting this rolling.

> 1)
> The Python file object needs to be modified so that in text mode it can
> recognize all major line ending conventions (Unix, Win and Mac).
> 
> Reading data:
>   - recognize \n, \r and \r\n as line ending, present as \n to Python
> Writing data:
>   - convert \n to the platform line endings (this is already the case)
> 
> This modification should be _optional_, because it may break code under unix
> (insert Guido's explanation here), and because it may not support oddball
> systems like OpenVMS.
> 
> It should be _on_ by default under:
> - Windows
> - MacPython Classic
> - MacPython Carbon
> - Unix Python under MacOS X / Darwin
> 
> It should probably be off by default on all other systems (I think a
> compile-time switch is good enough). Maybe if we advertize the potential
> sloppy-unix-code-breakage loud enough we can make the feature mandatory in a
> later release, however I don't see a practical way of issuing warnings for the
> situation.

I agree that is should be possible to turn the proposed off, but I still
think it should be on by default, even on *nix systems (which is mostly
what I use, buy the way), as it would only cause a problem for "sloppy"
code anyway. Would it be possible to have it be turned on/off at
runtime, rather than compile time ? It would be pretty awkward to have a
program need a specific version of the interpreter to run. Even a
command line flag could be awkward enough, then only the main program
could specify the flag, and modules might not be compatible.

Another option is for the new version to have another flag or set of
flags to the open command, which would indicate that the file being
opened is "Unix", "Mac", "DOS", or "Any". this would make it easy to
write text files in a non-native format, as well as read them.

Even if we didn't go that far, we could use the "t" flag (analogous to
"b" for binary), to specify the universal text format, and the default
would still be the current, native format. This would keep the "sloppy"
*nix code from breaking, and still give full functionality to new code.

While we are at it, what would get written is something we need to
consider. If we just have the above proposal, reading a file would work
great, it could be on a server with a different line ending format, and
that would be transparent. Writing, on the other hand is an issue. If a
program is running on a windows box, and writing a file on a *nix
server, what kind of line ending should it write? Would it even know
what the native format is on the server? It seems we would need to be
able to specify the line ending format explicitly for writing.

Just a few thoughts, maybe we'll get a PEP out of this after all!

-Chris







-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker@home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------


From greg@cosc.canterbury.ac.nz  Tue Apr 10 01:29:42 2001
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 12:29:42 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD203BD.E544ED0F@home.net>
Message-ID: <200104100029.MAA12528@s454.cosc.canterbury.ac.nz>

Disregard what I just said. The problem isn't about reading
text files at all, it's about reading non-text files without
explicitly opening them in binary mode.

I think the trouble is with the idea that if you don't
specify the mode explicitly it defaults to text mode, which
on Unix just happens to be the same as binary mode.

Could we change that so binary mode is the default on
Unix, and if you want any line ending translation, you
have to specify text mode explicitly? Is there any standard
which says that text mode must be the default?

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 chrishbarker@home.net  Tue Apr 10 01:47:34 2001
From: chrishbarker@home.net (Chris Barker)
Date: Mon, 09 Apr 2001 17:47:34 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>
Message-ID: <3AD25826.8C95D0AB@home.net>

Greg Ewing wrote:
> Chris Barker <chrishbarker@home.net>:
> > Even if people have been sloppy and used binary mode for text files
> > under *nix, that code would still work with *nix text files, which is
> > the only way it works now anyway.
> 
> That's a good point. The only thing that could break is if
> you opened a non-Unix file in *text* mode, and then expected
> it to behave as though it had been opened in *binary* mode.
> I can't imagine any code being screwy enough to do that!

Actually, I thought about it more, and of course, Guido is right. On
*nix, if you open a binary file in text mode, it works just fine, as
there is no difference. However, under the proposed scheme, the text
mode would translate "\r" into "\n", messing up your binary data. It
would also do it only with a couple of particular byte values, so it
might not be obvious that anything is wrong right away.

I've done that myself, by mistake. I wrote a little tool that used FTP
to transfer some binary files. It worked fine under Linux, but then I
tried to run it on the Mac, and the files got corrupted. It took me WAY
too long to figure out that I had read the file in text mode.
Personally, I've always thought it was unfortunate that the default was
text mode, rather than binary, or even better, there could be no
default: you have to specify either "b" or "t", then there would be no
room for confusion.

-Chris

-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker@home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------


From greg@cosc.canterbury.ac.nz  Tue Apr 10 02:07:28 2001
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 13:07:28 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD255D3.9872C019@home.net>
Message-ID: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz>

Chris Barker <chrishbarker@home.net>:

> If a program is running on a windows box, and writing a file on a *nix
> server, what kind of line ending should it write? Would it even know
> what the native format is on the server? It seems we would need to be
> able to specify the line ending format explicitly for writing.

Yes, I think that's the best that can be done. To do any better
would require all file servers to be aware of the text/binary
distinction and be willing to translate, and for there to be
some way for the Python file object to communicate to the OS
which mode is intended. Neither of these things are true in
general.

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 Apr 10 02:18:25 2001
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 13:18:25 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD25826.8C95D0AB@home.net>
Message-ID: <200104100118.NAA12540@s454.cosc.canterbury.ac.nz>

Chris Barker <chrishbarker@home.net>:

> It took me WAY
> too long to figure out that I had read the file in text mode.

My favourite way of falling into that trap involves AUFS
(the Appleshare Unix File Server). You're browsing the web
on a Unix box and come across a juicy-looking Stuffit file.
You download it into your AUFS directory, hop over to the
Mac and feed it to Stuffit Expander, which promptly throws
a wobbly.

"Shazbot," you mutter, "it got corrupted in the download
somehow." You try a couple more times, with the same result.
You're just about to write to the web site maintainer telling
them that their file is corrupt, when it dawns on you that:

(a) AUFS performs CR/LF translation on files whose Mac
type code is 'TEXT';

(b) Unix-created files default to type 'TEXT'.

(Sorry, not really Python-related. Pretend you've implemented
your Stuffit expander in Python...)

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@digicool.com  Tue Apr 10 03:32:51 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:32:51 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Tue, 10 Apr 2001 12:21:36 +1200."
 <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>
References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>
Message-ID: <200104100232.VAA03655@cj20424-a.reston1.va.home.com>

> Chris Barker <chrishbarker@home.net>:
> 
> > Even if people have been sloppy and used binary mode for text files
> > under *nix, that code would still work with *nix text files, which is
> > the only way it works now anyway.
> 
> That's a good point. The only thing that could break is if
> you opened a non-Unix file in *text* mode, and then expected
> it to behave as though it had been opened in *binary* mode.
> I can't imagine any code being screwy enough to do that!

Actually, that *is* the scenario I'm worried about.  Someone can open
a GIF file in text mode today on a Unix platform and it'll just work
(until they port the program to another platform, that is. ;-).  So
Unix weenies haven't had much of an incentive (or warning) about using
binary mode properlu.

In text translation mode, if there happen to be bytes with values 0x0d
in the file, they will be mangled.

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


From guido@digicool.com  Tue Apr 10 03:33:53 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:33:53 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Tue, 10 Apr 2001 12:29:42 +1200."
 <200104100029.MAA12528@s454.cosc.canterbury.ac.nz>
References: <200104100029.MAA12528@s454.cosc.canterbury.ac.nz>
Message-ID: <200104100233.VAA03669@cj20424-a.reston1.va.home.com>

> Disregard what I just said. The problem isn't about reading
> text files at all, it's about reading non-text files without
> explicitly opening them in binary mode.

What I said. :-)

> I think the trouble is with the idea that if you don't
> specify the mode explicitly it defaults to text mode, which
> on Unix just happens to be the same as binary mode.
> 
> Could we change that so binary mode is the default on
> Unix, and if you want any line ending translation, you
> have to specify text mode explicitly? Is there any standard
> which says that text mode must be the default?

It's pretty clear that the default is text mode.  But we could add a
new mode character, 't', to force text mode on.

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


From guido@digicool.com  Tue Apr 10 03:39:36 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:39:36 -0500
Subject: [Python-Dev] Release schedule heads up
Message-ID: <200104100239.VAA03697@cj20424-a.reston1.va.home.com>

We're planning the release candidate for 2.1 early this Friday (the
13th :-).  We need to have all changes ready early Thursday.

Then we plan to release the final version Monday the 16th, complete
with a press release and all!

The final release should be identical to the release candidate if all
goes well.

Between now and Thursday, only the most important bugs should be
fixed.  For anything else, please hold off till after 2.1final is
released!

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


From guido@digicool.com  Tue Apr 10 03:41:54 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:41:54 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Tue, 10 Apr 2001 13:07:28 +1200."
 <200104100107.NAA12536@s454.cosc.canterbury.ac.nz>
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz>
Message-ID: <200104100241.VAA03714@cj20424-a.reston1.va.home.com>

> > If a program is running on a windows box, and writing a file on a *nix
> > server, what kind of line ending should it write? Would it even know
> > what the native format is on the server? It seems we would need to be
> > able to specify the line ending format explicitly for writing.
> 
> Yes, I think that's the best that can be done. To do any better
> would require all file servers to be aware of the text/binary
> distinction and be willing to translate, and for there to be
> some way for the Python file object to communicate to the OS
> which mode is intended. Neither of these things are true in
> general.

You might need to be able to specify a specific line ending format,
but there should also be a default -- and it should be the default
appropriate to the OS.  So, \n on Unix, \r\n on Windows, \r on Mac
running in "Mac mode", and \n on MacOS X running in "Unix mode".

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


From jwblist@olympus.net  Tue Apr 10 07:47:44 2001
From: jwblist@olympus.net (John W Baxter)
Date: Mon, 9 Apr 2001 23:47:44 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do
 end-of-line conversion?
In-Reply-To: <200104100241.VAA03714@cj20424-a.reston1.va.home.com>
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz>
 <200104100241.VAA03714@cj20424-a.reston1.va.home.com>
Message-ID: <p05100903b6f85ba98f1b@[207.149.192.229]>

At 21:41 -0500 4/9/01, Guido van Rossum wrote:
>You might need to be able to specify a specific line ending format,
>but there should also be a default -- and it should be the default
>appropriate to the OS.  So, \n on Unix, \r\n on Windows, \r on Mac
>running in "Mac mode", and \n on MacOS X running in "Unix mode".

Is it the same in Mac OS X when reading a file from a UFS volume as from an
HFS(+) volume?

Only if the underlying libraries make it so.  (Typing in Mac OS X, but I
don't have any UFS volumes lying around.)

It's a little scary to contemplate that reading two different files, which
happen to be on the same disk spindle, will behave differently for the file
on the HFS+ volume than for the file on the UFS volume.  [There are perhaps
similar issues for our Linux friends who mount Windows volumes.]

What ever happened to "move text files to another system using FTP in ASCII
mode?"  Ah, yes...it probably died of Unicode.

  --John (there may no be any answers for this) Baxter
-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA


From moshez@zadka.site.co.il  Tue Apr 10 07:52:11 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Tue, 10 Apr 2001 09:52:11 +0300
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>
References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>
Message-ID: <E14ms0Z-0000kP-00@darjeeling>

On Tue, 10 Apr 2001, Greg Ewing <greg@cosc.canterbury.ac.nz> wrote:
 
> That's a good point. The only thing that could break is if
> you opened a non-Unix file in *text* mode, and then expected
> it to behave as though it had been opened in *binary* mode.
> I can't imagine any code being screwy enough to do that!

Then you've got another thing coming. Most UNIXers aren't aware
that the 'b' modifier exists: open(file) opens the file, whether
it is text or binary.
-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez@debian.org  |http://www.{python,debian,gnu}.org


From ping@lfw.org  Tue Apr 10 12:32:32 2001
From: ping@lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 04:32:32 -0700 (PDT)
Subject: [Python-Dev] SocketServer and UserDict patches
Message-ID: <Pine.LNX.4.10.10104100406540.26105-100000@localhost>

Hello all,

I'd like to call your attention to two small patches that i would
like to check in for the 2.1 RC.  They're small, but they correct
breakages that i think are worth fixing.

1.  UserDict.get(), .update(), and .setdefault()

https://sourceforge.net/tracker/?func=detail&aid=413171&group_id=5470&atid=305470

    These three methods are currently implemented by calling the
    underlying object's .get(), .update(), or .setdefault() method.
    This is bad because a UserDict that overrides __getitem__ now
    will have an inconsistent or failing get() method.

    A glaring example of this is cgi.SvFormContentDict.  For such
    an object x, x['spam'] returns a single item but x.get('spam')
    returns a list of one item!

    Instead, these three methods should be implemented in terms of
    the object's own __getitem__, __setitem__, and has_key methods.
    This patch makes this change.


2.  SocketServer.StreamRequestHandler

https://sourceforge.net/tracker/?func=detail&aid=415111&group_id=5470&atid=305470

    The setup() method here duplicates the socket twice (once to
    make a read-only file, once to make a write-only file).  That
    yields three descriptors, but finish() closes only two.  This
    causes my browser to hang indefinitely waiting for the socket
    to close when SimpleHTTPServer is used to deliver a small page.

    This patch adds self.connection.close() to setup() so that
    there are just two descriptors to worry about.



-- ?!ng

"All models are wrong; some models are useful."
    -- George Box




From ping@lfw.org  Tue Apr 10 11:45:55 2001
From: ping@lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 03:45:55 -0700 (PDT)
Subject: [Python-Dev] distutils.sys: None in sys.modules
Message-ID: <Pine.LNX.4.10.10104100337350.12232-100000@skuld.kingmanhall.org>

When i import distutils.util, i get:

    >>> sys.modules.keys()
    ['os', 'distutils.sys', 'distutils.os', 'exceptions', 'posix', 'distutils.spawn', 're', 'sre_constants', 'distutils.errors', 'string', 'signal', 'sre', 'posixpath', 'sre_parse', '_sre', 'os.path', 'distutils.string', 'readline', 'distutils.util', 'distutils.re', '__main__', 'distutils.dep_util', 'types', 'sys', '__builtin__', 'site', 'UserDict', 'distutils', 'sre_compile', 'copy_reg', 'stat', 'distutils.distutils']

What are 'distutils.sys', 'distutils.os', 'distutils.string',
'distutils.re', 'distutils.distutils' doing in there?  (The
sys.modules dictionary maps all these keys to None.)


-- ?!ng

"All models are wrong; some models are useful."
    -- George Box



From mal@lemburg.com  Tue Apr 10 12:43:32 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Apr 2001 13:43:32 +0200
Subject: [Python-Dev] distutils.sys: None in sys.modules
References: <Pine.LNX.4.10.10104100337350.12232-100000@skuld.kingmanhall.org>
Message-ID: <3AD2F1E4.2B61D2CD@lemburg.com>

Ka-Ping Yee wrote:
> 
> When i import distutils.util, i get:
> 
>     >>> sys.modules.keys()
>     ['os', 'distutils.sys', 'distutils.os', 'exceptions', 'posix', 'distutils.spawn', 're', 'sre_constants', 'distutils.errors', 'string', 'signal', 'sre', 'posixpath', 'sre_parse', '_sre', 'os.path', 'distutils.string', 'readline', 'distutils.util', 'distutils.re', '__main__', 'distutils.dep_util', 'types', 'sys', '__builtin__', 'site', 'UserDict', 'distutils', 'sre_compile', 'copy_reg', 'stat', 'distutils.distutils']
> 
> What are 'distutils.sys', 'distutils.os', 'distutils.string',
> 'distutils.re', 'distutils.distutils' doing in there? 

These are loaded by site.py for the case where you run Python
from the installation directory on Posix systems.

> (The
> sys.modules dictionary maps all these keys to None.)

This basically means that the corresponding modules have already
been loaded at top-level.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From ping@lfw.org  Tue Apr 10 12:55:28 2001
From: ping@lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 04:55:28 -0700 (PDT)
Subject: [Python-Dev] distutils.sys: None in sys.modules
In-Reply-To: <3AD2F1E4.2B61D2CD@lemburg.com>
Message-ID: <Pine.LNX.4.10.10104100447510.26105-100000@localhost>

On Tue, 10 Apr 2001, M.-A. Lemburg wrote:
> > What are 'distutils.sys', 'distutils.os', 'distutils.string',
> > 'distutils.re', 'distutils.distutils' doing in there? 
> > (The sys.modules dictionary maps all these keys to None.)
> 
> This basically means that the corresponding modules have already
> been loaded at top-level.

But there's no 'sys' module in the distutils package.
If there were one, it would be called 'distutils.sys'
everywhere, even within the distutils package, since
we decided that packages would always use absolute
module paths, right?

This behaviour seems quite confusing to me:

    localhost[1]% ls -al foo
    total 9
    drwxr-xr-x   2 ping     users        1024 Apr 10 04:50 ./
    drwxr-xr-x  12 ping     users        5120 Apr 10 04:49 ../
    -rw-r--r--   1 ping     users           0 Apr 10 04:49 __init__.py
    -rw-r--r--   1 ping     users         106 Apr 10 04:50 __init__.pyc
    -rw-r--r--   1 ping     users          50 Apr 10 04:50 sys.py
    -rw-r--r--   1 ping     users         216 Apr 10 04:50 sys.pyc
    localhost[2]% cat foo/sys.py
    import sys, os

    print 'here is foo.sys'

    blah = 1
    localhost[3]% python -S
    Python 2.1b2 (#28, Apr 10 2001, 02:49:05) 
    [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
    Type "copyright", "credits" or "license" for more information.
    >>> import sys, foo
    >>> sys.modules.keys()
    ['__main__', '__builtin__', 'sys', 'foo', 'signal', 'exceptions']
    >>> import foo.sys
    here is foo.sys
    >>> sys.modules.keys()
    ['os.path', 'os', 'foo', 'foo.sys', 'exceptions', '__main__', 'foo.os', 'posix', 'sys', '__builtin__', 'signal', 'UserDict', 'posixpath', 'stat']
    >>> sys.modules['foo.os']
    >>> sys.modules['foo.sys']
    <module 'foo.sys' from '/home/ping/python/foo/sys.py'>
    >>> import foo.os
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ImportError: no module named 'os' could be found
    >>> import foo.sys

At this point sys.modules['foo.sys'] is a real module, as it should
be, but sys.modules['foo.os'] is None.  I don't see why 'foo.os'
should be present at all.


-- ?!ng

"All models are wrong; some models are useful."
    -- George Box



From gmcm@hypernet.com  Tue Apr 10 13:02:42 2001
From: gmcm@hypernet.com (Gordon McMillan)
Date: Tue, 10 Apr 2001 08:02:42 -0400
Subject: [Python-Dev] distutils.sys: None in sys.modules
In-Reply-To: <Pine.LNX.4.10.10104100337350.12232-100000@skuld.kingmanhall.org>
Message-ID: <3AD2BE22.26211.DFF74CD@localhost>

[Ka-Ping]
> 
> What are 'distutils.sys', 'distutils.os', 'distutils.string',
> 'distutils.re', 'distutils.distutils' doing in there?  (The
> sys.modules dictionary maps all these keys to None.)

Relative imports come first. Their failure is recorded so the 
next module in the package importing the same name doesn't 
go hunting for it on disk all over again.



- Gordon


From mal@lemburg.com  Tue Apr 10 13:06:47 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Apr 2001 14:06:47 +0200
Subject: [Python-Dev] distutils.sys: None in sys.modules
References: <Pine.LNX.4.10.10104100447510.26105-100000@localhost>
Message-ID: <3AD2F757.B1258004@lemburg.com>

Ka-Ping Yee wrote:
> 
> On Tue, 10 Apr 2001, M.-A. Lemburg wrote:
> > > What are 'distutils.sys', 'distutils.os', 'distutils.string',
> > > 'distutils.re', 'distutils.distutils' doing in there?
> > > (The sys.modules dictionary maps all these keys to None.)
> >
> > This basically means that the corresponding modules have already
> > been loaded at top-level.
> 
> But there's no 'sys' module in the distutils package.

The None entry is used to cache the import miss. Please see
Python/import.c for details (function mark_miss).

> If there were one, it would be called 'distutils.sys'
> everywhere, even within the distutils package, since
> we decided that packages would always use absolute
> module paths, right?
> 
> This behaviour seems quite confusing to me:
> 
>     localhost[1]% ls -al foo
>     total 9
>     drwxr-xr-x   2 ping     users        1024 Apr 10 04:50 ./
>     drwxr-xr-x  12 ping     users        5120 Apr 10 04:49 ../
>     -rw-r--r--   1 ping     users           0 Apr 10 04:49 __init__.py
>     -rw-r--r--   1 ping     users         106 Apr 10 04:50 __init__.pyc
>     -rw-r--r--   1 ping     users          50 Apr 10 04:50 sys.py
>     -rw-r--r--   1 ping     users         216 Apr 10 04:50 sys.pyc
>     localhost[2]% cat foo/sys.py
>     import sys, os
> 
>     print 'here is foo.sys'
> 
>     blah = 1
>     localhost[3]% python -S
>     Python 2.1b2 (#28, Apr 10 2001, 02:49:05)
>     [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
>     Type "copyright", "credits" or "license" for more information.
>     >>> import sys, foo
>     >>> sys.modules.keys()
>     ['__main__', '__builtin__', 'sys', 'foo', 'signal', 'exceptions']
>     >>> import foo.sys
>     here is foo.sys
>     >>> sys.modules.keys()
>     ['os.path', 'os', 'foo', 'foo.sys', 'exceptions', '__main__', 'foo.os', 'posix', 'sys', '__builtin__', 'signal', 'UserDict', 'posixpath', 'stat']
>     >>> sys.modules['foo.os']
>     >>> sys.modules['foo.sys']
>     <module 'foo.sys' from '/home/ping/python/foo/sys.py'>
>     >>> import foo.os
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>     ImportError: no module named 'os' could be found
>     >>> import foo.sys
> 
> At this point sys.modules['foo.sys'] is a real module, as it should
> be, but sys.modules['foo.os'] is None.  I don't see why 'foo.os'
> should be present at all.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From thomas@xs4all.net  Tue Apr 10 13:54:06 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Tue, 10 Apr 2001 14:54:06 +0200
Subject: [Python-Dev] INSTALL_PROGRAM
Message-ID: <20010410145406.I2820@xs4all.nl>

I just noticed that INSTALL_PROGRAM is defined as just INSTALL (either the
system "install" or the install-sh script, with possibly -c as argument)
without a -m argument (to set the mode.) INSTALL_DATA does have a -m
argument, to set the mode for all 'data' files to 644 explicitly.
INSTALL_PROGRAM gets called not just for the python executable, but also for
all files in Lib/ that have their executable bit set. Because
INSTALL_PROGRAM does not set the mode, the files (potentially, depending on
the install program/script in question) are subject to the umask and/or the
original file mode.

I've already screwed up my Python installation on a couple of BSDI boxes
twice, before I realized what the problem was :) What about we set the mode
for executables to 755 explicitly ? Distutils seems to do the right thing,
right now, but I'm pretty sure it was screwed up before. What logic does
distutils use to figure these things out ?

(There is also INSTALL_SCRIPT, but that doesn't seem to be used anywhere.)
-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From guido@digicool.com  Tue Apr 10 14:58:39 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 08:58:39 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Mon, 09 Apr 2001 23:47:44 MST."
 <p05100903b6f85ba98f1b@[207.149.192.229]>
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> <200104100241.VAA03714@cj20424-a.reston1.va.home.com>
 <p05100903b6f85ba98f1b@[207.149.192.229]>
Message-ID: <200104101358.IAA05924@cj20424-a.reston1.va.home.com>

[me]
> >You might need to be able to specify a specific line ending format,
> >but there should also be a default -- and it should be the default
> >appropriate to the OS.  So, \n on Unix, \r\n on Windows, \r on Mac
> >running in "Mac mode", and \n on MacOS X running in "Unix mode".

[JW Baxter]
> Is it the same in Mac OS X when reading a file from a UFS volume as from an
> HFS(+) volume?

I'm not sure that the volume from which you're *reading* could or
should have any influence on the default delimiter used for *writing*.
The volume you're *writing* to might, if it's easy to determine -- but
personally, I'd be happy with a default set at compile time.

> Only if the underlying libraries make it so.  (Typing in Mac OS X, but I
> don't have any UFS volumes lying around.)
> 
> It's a little scary to contemplate that reading two different files, which
> happen to be on the same disk spindle, will behave differently for the file
> on the HFS+ volume than for the file on the UFS volume.  [There are perhaps
> similar issues for our Linux friends who mount Windows volumes.]

Anyway, disk spindles are the wrong abstraction level to consider
here.  Who cares about what spindle your files are on?

> What ever happened to "move text files to another system using FTP in ASCII
> mode?"  Ah, yes...it probably died of Unicode.

No, obviously it's cross-platform disk sharing.  The first time this
came up was when it became possible to mount Unix volumes on NT boxes
many years ago, and that's when Python's parser (eventually) grew the
habit of silently ignoring a \r just before a \n in a source file.

It's a sign of how backward the Mac world is that the problem only now
pops up for the Mac. :-)

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


From guido@digicool.com  Tue Apr 10 15:19:33 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 09:19:33 -0500
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: Your message of "Tue, 10 Apr 2001 04:32:32 MST."
 <Pine.LNX.4.10.10104100406540.26105-100000@localhost>
References: <Pine.LNX.4.10.10104100406540.26105-100000@localhost>
Message-ID: <200104101419.JAA06049@cj20424-a.reston1.va.home.com>

> I'd like to call your attention to two small patches that i would
> like to check in for the 2.1 RC.  They're small, but they correct
> breakages that i think are worth fixing.
> 
> 1.  UserDict.get(), .update(), and .setdefault()
> 
> https://sourceforge.net/tracker/?func=detail&aid=413171&group_id=5470&atid=305470
> 
>     These three methods are currently implemented by calling the
>     underlying object's .get(), .update(), or .setdefault() method.
>     This is bad because a UserDict that overrides __getitem__ now
>     will have an inconsistent or failing get() method.

I agree with the gist of this -- it should have been done the way you
propose.

>     A glaring example of this is cgi.SvFormContentDict.  For such
>     an object x, x['spam'] returns a single item but x.get('spam')
>     returns a list of one item!

But can you guarantee that fixing this so late in the release cycle
won't break anybody's code?

>     Instead, these three methods should be implemented in terms of
>     the object's own __getitem__, __setitem__, and has_key methods.
>     This patch makes this change.

I'm reluctant (-0) to making this change now.

> 
> 2.  SocketServer.StreamRequestHandler
> 
> https://sourceforge.net/tracker/?func=detail&aid=415111&group_id=5470&atid=305470
> 
>     The setup() method here duplicates the socket twice (once to
>     make a read-only file, once to make a write-only file).  That
>     yields three descriptors, but finish() closes only two.  This
>     causes my browser to hang indefinitely waiting for the socket
>     to close when SimpleHTTPServer is used to deliver a small page.
> 
>     This patch adds self.connection.close() to setup() so that
>     there are just two descriptors to worry about.

I don't think this is the right solution.  A principle I like very
much to keep my head clear about closing files is "whoever opens it
closes it".  The request/connection socket is created by a different
class, so should really be closed there.

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


From just@letterror.com  Tue Apr 10 14:20:41 2001
From: just@letterror.com (Just van Rossum)
Date: Tue, 10 Apr 2001 15:20:41 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104101358.IAA05924@cj20424-a.reston1.va.home.com>
Message-ID: <20010410152043-r01010600-eda55263@213.84.27.177>

Guido van Rossum wrote:

> It's a sign of how backward the Mac world is that the problem only now
> pops up for the Mac. :-)

I know I shouldn't bite, but I find this a very childish remark, Guido! It's
also not true... Here's an excerpt from a private thread between me, Jack and
Guido. It's dated january 8, 1996, I remember I was just learning Python. (I'll
give a translation below.)

"""
> >>     files:
> >>         is het een probleem om Mac *en* Unix files transparant te kunnen
> >>         lezen/executen? (een unix.py file veroorzaakt vreemde
> >>         error...)

(Ik neem aan dat je bedoelt files met '\n' in plaats van '\r' als line
separator.)

> >Hmm, ik weet niet of ik dit een goed idee vindt. Weet je wat: vraag
> >eens wat Guido er van vind (met een cc-tje naar mij).

Geen goed idee, tenzij de C stdio library dit automatisch doet
(kennelijk niet dus).  Het is over het algemeel een kleine moeite dit
bij het file transport recht te trekken (ftp in text mode etc.).
"""

Translation:

"""
[Just]
>>>    files:
>>>        is it a problem to read/execute Mac *and* Unix files transparently?
>>>        (a unix.py file causes a strange error...)

[Guido]
(I take it you mean files with '\n' instead of '\r' as line separator.)

[Jack]
>> Hm, I don't know whether I think this is a good idea. You know what,
>> ask Guido what he thinks (and cc me).

[Guido]
Not a good idea, unless the C stdio library does this automatically (apparently
it doesn't). In general it's a small effort to correct this during the file
transport (ftp in text mode etc.).
"""


So it's not that the problem wasn't there, it was just not taken very seriously
at the time...

Just


From guido@digicool.com  Tue Apr 10 15:23:21 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 09:23:21 -0500
Subject: [Python-Dev] distutils.sys: None in sys.modules
In-Reply-To: Your message of "Tue, 10 Apr 2001 04:55:28 MST."
 <Pine.LNX.4.10.10104100447510.26105-100000@localhost>
References: <Pine.LNX.4.10.10104100447510.26105-100000@localhost>
Message-ID: <200104101423.JAA06087@cj20424-a.reston1.va.home.com>

> At this point sys.modules['foo.sys'] is a real module, as it should
> be, but sys.modules['foo.os'] is None.  I don't see why 'foo.os'
> should be present at all.

See Gordon's reply (I think Marc-Andre was off base on this one):
sys.modules['foo.sys'] is set to None to prevent every "import sys" in
submodules of the foo package to hit the disk looking for foo/sys.py.

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


From jeremy@digicool.com  Tue Apr 10 16:33:42 2001
From: jeremy@digicool.com (Jeremy Hylton)
Date: Tue, 10 Apr 2001 11:33:42 -0400 (EDT)
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: <200104101419.JAA06049@cj20424-a.reston1.va.home.com>
References: <Pine.LNX.4.10.10104100406540.26105-100000@localhost>
 <200104101419.JAA06049@cj20424-a.reston1.va.home.com>
Message-ID: <15059.10198.788558.316692@slothrop.digicool.com>

>>>>> "GvR" == Guido van Rossum <guido@digicool.com> writes:

  >> A glaring example of this is cgi.SvFormContentDict.  For such an
  >> object x, x['spam'] returns a single item but x.get('spam')
  >> returns a list of one item!

  GvR> But can you guarantee that fixing this so late in the release
  GvR> cycle won't break anybody's code?

  >> Instead, these three methods should be implemented in terms of
  >> the object's own __getitem__, __setitem__, and has_key methods.
  >> This patch makes this change.

  GvR> I'm reluctant (-0) to making this change now.

I with you, Guido.  The cgi model is complicated and widely used.
That combination means that it would be easy for users to get the
impression that x['spam'] and x.get('spam') work the way they do
intentionally.  I'm not comfortable changing the behavior of the model
without a beta release.

Jeremy



From chrishbarker@home.net  Tue Apr 10 19:13:56 2001
From: chrishbarker@home.net (Chris Barker)
Date: Tue, 10 Apr 2001 11:13:56 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> <200104100241.VAA03714@cj20424-a.reston1.va.home.com>
 <p05100903b6f85ba98f1b@[207.149.192.229]> <200104101358.IAA05924@cj20424-a.reston1.va.home.com>
Message-ID: <3AD34D64.7F66DF52@home.net>

Guido van Rossum wrote:
> No, obviously it's cross-platform disk sharing.  The first time this
> came up was when it became possible to mount Unix volumes on NT boxes

I'm sure it came up before that, I know it has for me, and I don't
happen to do any cross platform disk sharing. It is just a little more
soluble if you aren't doing disk sharing.

> many years ago, and that's when Python's parser (eventually) grew the
> habit of silently ignoring a \r just before a \n in a source file.

It can do that? I had no idea. Probably because I work on the Mac and
Linux almost exclusively, and hardly ever encounter a Windows box.
 
> It's a sign of how backward the Mac world is that the problem only now
> pops up for the Mac. :-)

Actually it's a sign of how *nix/Windows focused Python is. It's sad to
see that someone thought to fix the problem for *nix/Windows, and didn't
even consider the Mac (as Just pointed out the problem has been know for
a long time). Frankly, it's also a symptom the the isolationist attitude
of a lot of Mac users/developers. and Don't get me started on the spaces
vs tabs thing!


Just,

Are you planning on putting together a PEP from all of this? I'd really
like to see this happen!

-Chris




-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker@home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------


From barry@digicool.com  Tue Apr 10 19:32:35 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 10 Apr 2001 14:32:35 -0400
Subject: [Python-Dev] SocketServer and UserDict patches
References: <Pine.LNX.4.10.10104100406540.26105-100000@localhost>
 <200104101419.JAA06049@cj20424-a.reston1.va.home.com>
 <15059.10198.788558.316692@slothrop.digicool.com>
Message-ID: <15059.20931.149158.432871@anthem.wooz.org>

>>>>> "JH" == Jeremy Hylton <jeremy@digicool.com> writes:

    JH> I with you, Guido.  The cgi model is complicated and widely
    JH> used.  That combination means that it would be easy for users
    JH> to get the impression that x['spam'] and x.get('spam') work
    JH> the way they do intentionally.  I'm not comfortable changing
    JH> the behavior of the model without a beta release.

I'd be reluctant to change the cgi module's behavior /at all/ at this
point.  As broken as cgi.py is (and it is pretty broken), I think
you'll break a lot of code by changing its quirky API.  Better to
design a new API and write a new module.

-Barry


From ping@lfw.org  Tue Apr 10 20:46:08 2001
From: ping@lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 12:46:08 -0700 (PDT)
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: <200104101419.JAA06049@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10104101006250.641-100000@skuld.kingmanhall.org>

On Tue, 10 Apr 2001, Guido van Rossum wrote:
> > 1.  UserDict.get(), .update(), and .setdefault()
[...]
> I agree with the gist of this -- it should have been done the way you
> propose.
[...]
> But can you guarantee that fixing this so late in the release cycle
> won't break anybody's code?

Right, obviously i can't.  Here are some thoughts:
(Nonetheless i do agree it's a bit late to notice this.)

    1.  All the standard tests pass with this change (though
        of course that's a small sample).

    2.  It's hard to imagine someone's code depending on this
        particular bug (i think i can justify calling it a bug).
        Anyone who wrote a UserDict-derived class that actually
        intended to use "get" most likely had to work around it
        anyway, to get any reasonable sort of result.

    3.  Would you consider allowing the addition of a get()
        method just to cgi.SvFormContentDict to fix its behaviour?
        (The broken get() behaviour was present for this particular
        class in 2.0 but not in 1.5.2.)


> > 2.  SocketServer.StreamRequestHandler
[...]
> I don't think this is the right solution.  A principle I like very
> much to keep my head clear about closing files is "whoever opens it
> closes it".  The request/connection socket is created by a different
> class, so should really be closed there.

Good point.  How about adding to BaseServer.handle_request instead?

    def handle_request(self):
        """Handle one request, possibly blocking."""
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                self.process_request(request, client_address)
            except:
                self.handle_error(request, client_address)
  +     request.close()

I forgot to mention that this is a testable and observable fix
(Netscape gets stuck in Linux and IE gets stuck in Win2K without
the fix, and both work properly when i make this fix.)

Note that this makes explicit the division of responsibilities
that, if the request handler wants to continue dealing with the
request connection after its constructor returns (as in the
case of the forking and threading variants), it must duplicate
its own copy of the file descriptor (which it already does).
I think this is good, as then each file descriptor can be
associated with a clear owner.


-- ?!ng

"Don't worry about people stealing an idea.  If it's original, you'll
have to jam it down their throats."
    -- Howard Aiken



From guido@digicool.com  Tue Apr 10 21:45:35 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 15:45:35 -0500
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: Your message of "Tue, 10 Apr 2001 12:46:08 MST."
 <Pine.LNX.4.10.10104101006250.641-100000@skuld.kingmanhall.org>
References: <Pine.LNX.4.10.10104101006250.641-100000@skuld.kingmanhall.org>
Message-ID: <200104102045.PAA07295@cj20424-a.reston1.va.home.com>

> On Tue, 10 Apr 2001, Guido van Rossum wrote:
> > > 1.  UserDict.get(), .update(), and .setdefault()
> [...]
> > I agree with the gist of this -- it should have been done the way you
> > propose.
> [...]
> > But can you guarantee that fixing this so late in the release cycle
> > won't break anybody's code?
> 
> Right, obviously i can't.  Here are some thoughts:
> (Nonetheless i do agree it's a bit late to notice this.)
> 
>     1.  All the standard tests pass with this change (though
>         of course that's a small sample).
> 
>     2.  It's hard to imagine someone's code depending on this
>         particular bug (i think i can justify calling it a bug).
>         Anyone who wrote a UserDict-derived class that actually
>         intended to use "get" most likely had to work around it
>         anyway, to get any reasonable sort of result.
> 
>     3.  Would you consider allowing the addition of a get()
>         method just to cgi.SvFormContentDict to fix its behaviour?
>         (The broken get() behaviour was present for this particular
>         class in 2.0 but not in 1.5.2.)

Let's just fix this after releasing 2.1, OK?  As you say, it's
unlikely that this affects anybody one way or the other, and right now
I'm for stability in favor of fixing warts (believe me, I have a few
other favorite warts that I won't fix before releasing 2.1 :-).

> 
> > > 2.  SocketServer.StreamRequestHandler
> [...]
> > I don't think this is the right solution.  A principle I like very
> > much to keep my head clear about closing files is "whoever opens it
> > closes it".  The request/connection socket is created by a different
> > class, so should really be closed there.
> 
> Good point.  How about adding to BaseServer.handle_request instead?
> 
>     def handle_request(self):
>         """Handle one request, possibly blocking."""
>         try:
>             request, client_address = self.get_request()
>         except socket.error:
>             return
>         if self.verify_request(request, client_address):
>             try:
>                 self.process_request(request, client_address)
>             except:
>                 self.handle_error(request, client_address)
>   +     request.close()

Alas, this is still at the wrong level.  The get_request() method is
overridable (e.g. by the UDPServer class) and the request that it
returns may not have a close method.  The best I can come up with is
to add an empty method self.close_request(request) to the base class,
call it in handle_request(), and override it to call request.close()
in the TCPServer class.

> I forgot to mention that this is a testable and observable fix
> (Netscape gets stuck in Linux and IE gets stuck in Win2K without
> the fix, and both work properly when i make this fix.)

I believe you -- I've noticed weird slownesses when using
SimpleHTTPServer.

> Note that this makes explicit the division of responsibilities
> that, if the request handler wants to continue dealing with the
> request connection after its constructor returns (as in the
> case of the forking and threading variants), it must duplicate
> its own copy of the file descriptor (which it already does).
> I think this is good, as then each file descriptor can be
> associated with a clear owner.

No argument there!

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


From guido@digicool.com  Tue Apr 10 22:47:08 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 16:47:08 -0500
Subject: [Python-Dev] SourceForge search-by-ID implemented
Message-ID: <200104102147.QAA07642@cj20424-a.reston1.va.home.com>

I received the email below from the friendly folks at SourceForge --
you can now search bugs and patches by number.  Cool!

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

------- Forwarded Message

Date:    Tue, 10 Apr 2001 19:45:55 +0300
From:    Paul Sokolovsky <pfalcon@sourceforge.net>
To:      Guido van Rossum <guido@python.org>
Subject: Fwd: [alexandria - Feature Requests] ANN: search artifacts (bugs etc.)
	   by #

Hello Guido,

      I would like to notify that another of your feature requests
for SourceForge has been done. Sorry that it took so much time -
search is one of the most straining parts of the site, and there was a
marathory for any changes to it...

This is a forwarded message
From: noreply@sourceforge.net <noreply@sourceforge.net>
To: noreply@sourceforge.net <noreply@sourceforge.net>
Subject: [alexandria - Feature Requests] ANN: search artifacts (bugs etc.) by #

===8<==============Original message text===============

Read and respond to this message at:
http://sourceforge.net/forum/message.php?msg_id=137990
By: pfalcon

There were many request to allow to display bugs, support requests, etc. by
their number, having typed it into search box. Finally, it's here. By typing
digit sequence, optionally preceeded by #, you'll get that item (in addition
to items where that string present literally, of course).


Enjoy!



______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge and visit:
http://sourceforge.net/forum/monitor.php?forum_id=4


===8<===========End of original message text===========



- --
Paul Sokolovsky,        http://sourceforge.net/users/pfalcon
SourceForge developer   http://sourceforge.net


------- End of Forwarded Message



From nas@python.ca  Tue Apr 10 22:08:55 2001
From: nas@python.ca (Neil Schemenauer)
Date: Tue, 10 Apr 2001 14:08:55 -0700
Subject: [Python-Dev] SourceForge search-by-ID implemented
In-Reply-To: <200104102147.QAA07642@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 10, 2001 at 04:47:08PM -0500
References: <200104102147.QAA07642@cj20424-a.reston1.va.home.com>
Message-ID: <20010410140854.B31183@glacier.fnational.com>

Guido van Rossum wrote:
> I received the email below from the friendly folks at SourceForge --
> you can now search bugs and patches by number.  Cool!

Yah!  This reminds me of something the Debian bug tracking system
does that is really cool.  If you include the string "Fixes: #123"
in the changelog the bug system will notice and close the bug for
you.

I don't think SourceForge should implement this feature.
Instead, some ambitious person could write a script that watches
the CVS checkin list and interact with the sourceforge site.  The
script could also add a comment to the bug logging who fixed it
and the versions of the files changed.  That information is
probably useful when trying to bugfix release.

  Neil


From ping@lfw.org  Wed Apr 11 02:06:36 2001
From: ping@lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 18:06:36 -0700 (PDT)
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: <200104102045.PAA07295@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10104101746580.641-100000@skuld.kingmanhall.org>

On Tue, 10 Apr 2001, Guido van Rossum wrote:
> > > > 1.  UserDict.get(), .update(), and .setdefault()
[...]
> Let's just fix this after releasing 2.1, OK?

Okay.

> As you say, it's
> unlikely that this affects anybody one way or the other

True, it is largely about people writing *new* scripts conveniently.

> > > > 2.  SocketServer.StreamRequestHandler
[...]
> Alas, this is still at the wrong level.  The get_request() method is
> overridable (e.g. by the UDPServer class) and the request that it
> returns may not have a close method.  The best I can come up with is
> to add an empty method self.close_request(request) to the base class,
> call it in handle_request(), and override it to call request.close()
> in the TCPServer class.

Yes, i agree that's a good division of responsibilities.  See the
updated patch.  I think it would be nice if it could go in, but it's
up to you if you want to accept it.


-- ?!ng

"Don't worry about people stealing an idea.  If it's original, you'll
have to jam it down their throats."
    -- Howard Aiken




From guido@digicool.com  Wed Apr 11 04:29:31 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 22:29:31 -0500
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: Your message of "Tue, 10 Apr 2001 18:06:36 MST."
 <Pine.LNX.4.10.10104101746580.641-100000@skuld.kingmanhall.org>
References: <Pine.LNX.4.10.10104101746580.641-100000@skuld.kingmanhall.org>
Message-ID: <200104110329.WAA11332@cj20424-a.reston1.va.home.com>

> > > > > 2.  SocketServer.StreamRequestHandler
> [...]
> > Alas, this is still at the wrong level.  The get_request() method is
> > overridable (e.g. by the UDPServer class) and the request that it
> > returns may not have a close method.  The best I can come up with is
> > to add an empty method self.close_request(request) to the base class,
> > call it in handle_request(), and override it to call request.close()
> > in the TCPServer class.
> 
> Yes, i agree that's a good division of responsibilities.  See the
> updated patch.  I think it would be nice if it could go in, but it's
> up to you if you want to accept it.

I've accepted this and assigned it to you.  That means that *you*
should check it in!  (This is so that the CVS logs show the author of
the patch.)

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


From tim.one@home.com  Wed Apr 11 05:20:42 2001
From: tim.one@home.com (Tim Peters)
Date: Wed, 11 Apr 2001 00:20:42 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <3AD34D64.7F66DF52@home.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEGKJLAA.tim.one@home.com>

[Guido]
>> ...
>> that's when Python's parser (eventually) grew the habit of
>> silently ignoring a \r just before a \n in a source file.

[Chris Barker]
> It can do that? I had no idea. Probably because I work on the Mac and
> Linux almost exclusively, and hardly ever encounter a Windows box.

>> It's a sign of how backward the Mac world is that the problem only
>> now pops up for the Mac. :-)

> Actually it's a sign of how *nix/Windows focused Python is. It's sad
> to see that someone thought to fix the problem for *nix/Windows, and
> didn't even consider the Mac (as Just pointed out the problem has
> been know for a long time).

This is a reversal of history.  The code to ignore
    \r
when seeing
    \r\n
originally (1995) applied to *all* platforms.  I don't know why, but Jack
submitted a patch to disable this behavior only when "#ifdef macintosh", in
revision 2.29 of Parser/tokenizer.c, about 4 years ago.  The #ifdef
introduced then still exists today; 3 lines introduced by that patch start
with XXX here for clarity (appropriately defined <wink>):

XXX #ifndef macintosh
			/* replace "\r\n" with "\n" */
XXX			/* For Mac we leave the \r, giving a syntax error */
			pt = tok->inp - 2;
			if (pt >= tok->buf && *pt == '\r') {
				*pt++ = '\n';
				*pt = '\0';
				tok->inp = pt;
			}
XXX #endif

I have no idea what Mac C libraries return for text-mode reads.  They must
convert \r to \n, right?  In which case I guess any \r remaining *should* be
"an error" (but where would it come from, if the C library converts all \r
thingies?).  Do they leave \n alone?  Etc:  submit a patch that makes the
code above "work", and I'm sure it would be accepted, but a non-Mac person
can't guess what's needed.

As to "considering the Mac", guilty as charged:  I don't know anything about
it.  What's to consider?  How often do you consider the impact of chnages on,
say, OpenVMS?  Same thing, provided you're as ignorant of it as I am of your
system.

> Frankly, it's also a symptom the the isolationist attitude of a
> lot of Mac users/developers. and Don't get me started on the spaces
> vs tabs thing!

The std for distributed Python code is 4-space indents, no hard tab
characters.  So there's nothing left there to get started on <wink>.

it's-not-that-we-don't-want-to-"fix"-macs-it's-that-we-don't-know-
    how-macs-work-or-what-"fix"-*means*-to-a-macizoid-ly y'rs  - tim



From just@letterror.com  Wed Apr 11 11:03:27 2001
From: just@letterror.com (Just van Rossum)
Date: Wed, 11 Apr 2001 12:03:27 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEGKJLAA.tim.one@home.com>
Message-ID: <20010411120330-r01010600-75da8509@213.84.27.177>

Tim Peters wrote:

> This is a reversal of history.  The code to ignore
>     \r
> when seeing
>     \r\n
> originally (1995) applied to *all* platforms.  I don't know why, but Jack
> submitted a patch to disable this behavior only when "#ifdef macintosh", in
> revision 2.29 of Parser/tokenizer.c, about 4 years ago.  The #ifdef
> introduced then still exists today; 3 lines introduced by that patch start
> with XXX here for clarity (appropriately defined <wink>):

Interesting, I didn't know that. Jack's on holiday now, so he won't be able to
comment for a while.

> I have no idea what Mac C libraries return for text-mode reads.  They must
> convert \r to \n, right? 

Yes.

> In which case I guess any \r remaining *should* be
> "an error" (but where would it come from, if the C library converts all \r
> thingies?).  Do they leave \n alone? 

Nope: \r's get translated to \n and for whatever reason \n's get translated to
\r... So when opening a unix file on the Mac, it will look like it has \r line
endings and when opening a Windows text file on the Mac, it will appear as if it
has \n\r line endings...

> Etc:  submit a patch that makes the
> code above "work", and I'm sure it would be accepted, but a non-Mac person
> can't guess what's needed.

That's probably easy enough -- although would require changing all tokenizer
code that looks for \n to also look for \r, including PyOS_ReadLine(), so it
goes well beyond the snippet you posted. And then there's the Python file
object...

Just


From tim.one@home.com  Wed Apr 11 23:15:01 2001
From: tim.one@home.com (Tim Peters)
Date: Wed, 11 Apr 2001 18:15:01 -0400
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Lib/test test_math.py,1.10,1.11 test_fork1.py,1.8,1.9 test_fcntl.py,1.16,1.17
In-Reply-To: <E14nRh0-0003EH-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEJJJLAA.tim.one@home.com>

> Update of /cvsroot/python/python/dist/src/Lib/test
> In directory usw-pr-cvs1:/tmp/cvs-serv12386
>
> Modified Files:
> 	test_math.py test_fork1.py test_fcntl.py
> Log Message:
> Unixware 7 support by Billy G. Allie (SF patch 413011)
> ...
> ***************
> *** 36,40 ****
>   testit('atan2(-1, 0)', math.atan2(-1, 0), -math.pi/2)
>   testit('atan2(-1, 1)', math.atan2(-1, 1), -math.pi/4)
> ! testit('atan2(0, 1)', math.atan2(0, 1), 0)
>   testit('atan2(1, 1)', math.atan2(1, 1), math.pi/4)
>   testit('atan2(1, 0)', math.atan2(1, 0), math.pi/2)
> --- 37,44 ----
>   testit('atan2(-1, 0)', math.atan2(-1, 0), -math.pi/2)
>   testit('atan2(-1, 1)', math.atan2(-1, 1), -math.pi/4)
> ! if sys.platform in ['unixware7']:
> !     testit('atan2(0, 1)', math.atan2(0, 1), math.pi)
> ! else:
> !     testit('atan2(0, 1)', math.atan2(0, 1), 0)
>   testit('atan2(1, 1)', math.atan2(1, 1), math.pi/4)
>   testit('atan2(1, 0)', math.atan2(1, 0), math.pi/2)

atan2(0, 1) should be 0 on *all* platforms.  It's too bad if the original
test fails on unixware7, but if it does it means their libm's atan2() is
buggy.  C99 spells this out in excruciating detail.  C89 isn't as clear, but
is clear enough:

    The atan2(y, x) function computes the principal value of the
    arc tangent of y/x, using the signs of both arguments to
    determine the quadrant of the return value.  A domain
    error may occur if both arguments are 0.

IOW, atan2 returns the angle with x-axis made by a unit vector from the
origin to the point (x, y).  The point (1, 0) lies on the x axis, pointing to
the right, so is at an angle of 0.  The only question is whether it should be
+0 or -0, and while C99 spells that out too, Python's test doesn't
distinguish those cases so we don't have to answer that here.

So, if nobody leaps to defend unixware7, I'm going to revert that part of the
patch.



From mwh21@cam.ac.uk  Wed Apr 11 23:31:48 2001
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 11 Apr 2001 23:31:48 +0100
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/plat-unixware7 FCNTL.py,NONE,1.1 IN.py,NONE,1.1 SOCKET.py,NONE,1.1 STROPTS.py,NONE,1.1 TERMIOS.py,NONE,1.1 regen,NONE,1.1
In-Reply-To: Guido van Rossum's message of "Wed, 11 Apr 2001 13:54:46 -0700"
References: <E14nRdW-00032q-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <m3ae5nrru3.fsf@atrus.jesus.cam.ac.uk>

Guido van Rossum <gvanrossum@users.sourceforge.net> writes:

> Update of /cvsroot/python/python/dist/src/Lib/plat-unixware7
> In directory usw-pr-cvs1:/tmp/cvs-serv11682
> 
> Added Files:
> 	FCNTL.py IN.py SOCKET.py STROPTS.py TERMIOS.py regen 

Ehh... I didn't think we did TERMIOS.py or SOCKET.py any more?

Cheers,
M.



From greg@cosc.canterbury.ac.nz  Thu Apr 12 00:44:01 2001
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Apr 2001 11:44:01 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do
In-Reply-To: <20010411120330-r01010600-75da8509@213.84.27.177>
Message-ID: <200104112344.LAA12806@s454.cosc.canterbury.ac.nz>

end-of-line conversion?

Just van Rossum <just@letterror.com>:
> Tim Peters wrote:
> > I have no idea what Mac C libraries return for text-mode reads.  They must
> > convert \r to \n, right? 
> Yes.

Unless you're using the MPW compiler, which swaps the meanings
of \r and \n in the source 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 tim.one@home.com  Thu Apr 12 01:14:19 2001
From: tim.one@home.com (Tim Peters)
Date: Wed, 11 Apr 2001 20:14:19 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010411120330-r01010600-75da8509@213.84.27.177>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com>

[Just van Rossum]
> Nope: \r's get translated to \n and for whatever reason \n's get
> translated to \r... So when opening a unix file on the Mac, it
> will look like it has \r line endings and when opening a Windows
> text file on the Mac, it will appear as if it has \n\r line endings...

Then it's probably a Good Thing Jack disabled this code, since it wouldn't
have done anything useful on a Mac anyway (for Python to ever see \r\n the
source file would have had to contain \n\r, which is nobody's text file
convention).

>> Etc:  submit a patch that makes the code above "work", and I'm
>> sure it would be accepted, but a non-Mac person can't guess
>> what's needed.

> That's probably easy enough -- although would require changing all
> tokenizer code that looks for \n to also look for \r, including
> PyOS_ReadLine(), so it goes well beyond the snippet you posted.

No, there's nothing wrong with the tokenizer code:  it's coded in C, and the
C text convention is that lines end with \n, period.  Reliance on that
convention is ubiquitous -- and properly so.  What we need instead are
platform-specific implementations of fgets() functionality, which deliver
lines containing \n where and only where the platform Python is supposed to
believe a line ends.  Then nothing else in the parser needs to be touched
(and, indeed, the current \r\n mini-hack could be thrown away).

> And then there's the Python file object...

Different issue.  If this ever gets that far, note that the crunch to speed
up line-at-a-time file input ended up *requiring* use of the native fgets()
on Windows, as that was the only way on that platform to avoid having the OS
do layers of expensive multithreading locks for each character read.  So
there's no efficient way in general to get Windows to recognize \r line
endings short of implementing our own stdio from the ground up.  On other
platforms, fileobject.c's get_line() reads one character at a time, and I
expect its test for "is this an EOL char?" could be liberalized at reasonable
cost.

OTOH, how does the new-fangled Mac OS fit into all this?  Perhaps, for
compatibility, their C libraries already recognize both Unix and Mac Classic
line conventions, and deliver plain \n endings for both?  Or did they blow
that part too <wink>?



From guido@digicool.com  Thu Apr 12 03:21:36 2001
From: guido@digicool.com (Guido van Rossum)
Date: Wed, 11 Apr 2001 21:21:36 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Wed, 11 Apr 2001 20:14:19 -0400."
 <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com>
Message-ID: <200104120221.VAA14315@cj20424-a.reston1.va.home.com>

> Different issue.  If this ever gets that far, note that the crunch
> to speed up line-at-a-time file input ended up *requiring* use of
> the native fgets() on Windows, as that was the only way on that
> platform to avoid having the OS do layers of expensive
> multithreading locks for each character read.  So there's no
> efficient way in general to get Windows to recognize \r line endings
> short of implementing our own stdio from the ground up.  On other
> platforms, fileobject.c's get_line() reads one character at a time,
> and I expect its test for "is this an EOL char?" could be
> liberalized at reasonable cost.

I expect that the right solution here is indeed to write our own
stdio-like library from the ground up.  That can solve any number of
problems: telling how many characters are buffered (so you don't have
to use unbuffered mode when using select or poll),
platform-independent line end recognition, and super-efficient
readline() to boot.

But it's a lot of work, and won't be compatible with existing
extensions that use FILE* (not too many I believe).

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


From guido@digicool.com  Thu Apr 12 03:46:21 2001
From: guido@digicool.com (Guido van Rossum)
Date: Wed, 11 Apr 2001 21:46:21 -0500
Subject: [Python-Dev] Proposed patch to cgi.py for 2.1 -- please review!
Message-ID: <200104120246.VAA14451@cj20424-a.reston1.va.home.com>

I'd like some feedback on the patch below to cgi.py.  For background,
read SF bug #231249:

  http://sourceforge.net/tracker/?func=detail&aid=231249&group_id=5470&atid=105470

The problem is that when a POST request is received with a
Content-type of multipart/form-data, an anonymous temporary file is
created and kept open for each part -- whether or not it is a
file-upload!  For forms with many fields, this can use up more file
descriptors than the server is allowed to have.  There's no way to
tell whether a particular part is a file or not; the filename are
optional and the input field type is not available here.  My solution
uses a StringIO and transparently switches to a temporary file object
when a part grows larger than 1000 characters.

Question: does this look like it could break anything?  I know the cgi
module is used a lot so any change in semantics, however subtle, could
potentially cause problems for some poor soul out there...

(It could break code if someone tries to use the fileno() on a field
object's file attribute.)

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

Index: cgi.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/cgi.py,v
retrieving revision 1.63
diff -c -r1.63 cgi.py
*** cgi.py	2001/03/19 13:40:44	1.63
--- cgi.py	2001/04/11 20:18:20
***************
*** 633,644 ****
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.file = self.make_file('')
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
--- 633,652 ----
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.file = self.__file = StringIO()
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
+     def __write(self, line):
+         if self.__file is not None:
+             if self.__file.tell() + len(line) > 1000:
+                 self.file = self.make_file('')
+                 self.file.write(self.__file.getvalue())
+                 self.__file = None
+         self.file.write(line)
+ 
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
***************
*** 646,652 ****
              if not line:
                  self.done = -1
                  break
!             self.file.write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
--- 654,660 ----
              if not line:
                  self.done = -1
                  break
!             self.__write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
***************
*** 674,680 ****
                  line = line[:-1]
              else:
                  delim = ""
!             self.file.write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""
--- 682,688 ----
                  line = line[:-1]
              else:
                  delim = ""
!             self.__write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""


From greg@cosc.canterbury.ac.nz  Thu Apr 12 04:02:39 2001
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Apr 2001 15:02:39 +1200 (NZST)
Subject: [Python-Dev] Proposed patch to cgi.py for 2.1 -- please review!
In-Reply-To: <200104120246.VAA14451@cj20424-a.reston1.va.home.com>
Message-ID: <200104120302.PAA12841@s454.cosc.canterbury.ac.nz>

Guido:

> (It could break code if someone tries to use the fileno() on a field
> object's file attribute.)

Switch to a real file when someone accesses the file attribute?

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@beowolf.digicool.com  Thu Apr 12 05:39:34 2001
From: fdrake@beowolf.digicool.com (Fred Drake)
Date: Thu, 12 Apr 2001 00:39:34 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010412043934.B61E12879C@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


Almost to Python 2.1 release candidate 1 status.  This includes a variety
of small updates and a good bit more documentation on the PyUnit version
that will be included with the final release (new text essentially 
converted from Steve Purcell's HTML docs).



From jeremy@digicool.com  Thu Apr 12 06:08:00 2001
From: jeremy@digicool.com (Jeremy Hylton)
Date: Thu, 12 Apr 2001 01:08:00 -0400 (EDT)
Subject: [Python-Dev] make install produces compiler warnings
Message-ID: <15061.14384.617116.153973@slothrop.digicool.com>

I just noticed that a make install prints out a bunch of warnings
about .py files it is compiling.  Many of the errors are in files that
I included in Lib/test that are designed to trigger errors or warnings
about future statements.  Rather than stuff all the different bogus
code examples into strings and pass them to exec, I placed them in
files that are imported by test_future.py.  nocaret.py is a similar
file used to test the exceptions printed for SyntaxErrors.

I think tokenize_tests.py is doing the same thing, but it isn't my
fault :-).

Here's the full list of output to stderr:

  File "/usr/local/lib/python2.1/test/nocaret.py", line 2
    [x for x in x] = x
SyntaxError: can't assign to list comprehension
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future3.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future4.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future5.py, line 4)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future6.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future7.py, line 3)
SyntaxError: duplicate argument 'rest' in function definition (tokenize_tests.py, line 147)
  File "/usr/local/lib/python2.1/test/nocaret.py", line 2
    [x for x in x] = x
SyntaxError: can't assign to list comprehension
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future3.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future4.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future5.py, line 4)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future6.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future7.py, line 3)
SyntaxError: duplicate argument 'rest' in function definition (tokenize_tests.py, line 147)
warning: install: modules installed to '/usr/local/lib/python2.1/lib-dynload/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself

Should we do something to quiet these warnings?  I never noticed them
before since there's *so much* noise produced by make install.

Jeremy



From tim.one@home.com  Thu Apr 12 06:30:28 2001
From: tim.one@home.com (Tim Peters)
Date: Thu, 12 Apr 2001 01:30:28 -0400
Subject: [Python-Dev] make install produces compiler warnings
In-Reply-To: <15061.14384.617116.153973@slothrop.digicool.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOELBJLAA.tim.one@home.com>

[Jeremy]
> I just noticed that a make install prints out a bunch of warnings
> about .py files it is compiling.

Yes, JimF noticed that within the last week too, and it threw him off track
(me too).  Meant to mention it.  Of course it's not a problem on Windows --
no make there to make make problems <wink>.

Irrelevantly, the damaged files test_future.py is trying to import should not
have been named with a "test_" prefix (maybe a "bad_" prefix instead), and
then there would have been no need to add them to the NOTTEST list in
regrtest.py either.

Could the Unix makefile be taught not to compile the supposed-to-fail .py
files?  Would that be easier if all the supposed-to-fail files were renamed
to something other than test_*.py?



From tim.one@home.com  Thu Apr 12 07:41:20 2001
From: tim.one@home.com (Tim Peters)
Date: Thu, 12 Apr 2001 02:41:20 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104120221.VAA14315@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCELFJLAA.tim.one@home.com>

[Guido]
> I expect that the right solution here is indeed to write our own
> stdio-like library from the ground up.  That can solve any number of
> problems: telling how many characters are buffered (so you don't have
> to use unbuffered mode when using select or poll), platform-
> independent line end recognition, and super-efficient readline()
> to boot.

We also have the old

    http://sourceforge.net/tracker/?group_id=5470&
        atid=105470&func=detail&aid=210821

complaining that use of FILE* in our C API can make it impossible to (in that
fellow's case) write an app in Borland C++ on Windows that tries to use those
API functions (cuz Borland's FILE* is incompatible with MS's FILE*).  I'm not
sure the best solution to *that* is to give them a FILE* that's incompatible
with everyone's, though <wink>>

> But it's a lot of work, and won't be compatible with existing
> extensions that use FILE* (not too many I believe).

I'm more concerned about the "lot of work" part, with which I agree.

OTOH, Plauger's book "The Standard C Library" contains source code for every
library required by C89.  He reported that implementing libm took him twice
as long as everything else combined.  But those who haven't written a libm
will be prone to take a wrong lesson from that <wink>.

it's-not-that-i/o-is-easy-despite-that-his-libm-code-isn't-production-
    quality-ly y'rs  - tim



From just@letterror.com  Thu Apr 12 09:03:33 2001
From: just@letterror.com (Just van Rossum)
Date: Thu, 12 Apr 2001 10:03:33 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com>
Message-ID: <20010412100334-r01010600-5b54bb95@213.84.27.177>

Tim Peters wrote:

> No, there's nothing wrong with the tokenizer code:  it's coded in C, and the
> C text convention is that lines end with \n, period.  Reliance on that
> convention is ubiquitous -- and properly so. 

I don't get it: why would a thin layer on top of stdio be bad? Seems much less
work than reimplementing stdio.

Just


From mwh21@cam.ac.uk  Thu Apr 12 11:43:19 2001
From: mwh21@cam.ac.uk (Michael Hudson)
Date: Thu, 12 Apr 2001 11:43:19 +0100 (BST)
Subject: [Python-Dev] python-dev summary, 2001-03-19 - 2001-04-12
Message-ID: <Pine.LNX.4.10.10104121142060.1820-100000@localhost.localdomain>

 This is a summary of traffic on the python-dev mailing list between
 Mar 29 and Apr 11 (inclusive) 2001.  It is intended to inform the
 wider Python community of ongoing developments.  To comment, just
 post to python-list@python.org or comp.lang.python in the usual
 way. Give your posting a meaningful subject line, and if it's about a
 PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep
 iteration) All python-dev members are interested in seeing ideas
 discussed by the community, so don't hesitate to take a stance on a
 PEP if you have an opinion.

 This is the fifth summary written by Michael Hudson.
 Summaries are archived at:

  <http://starship.python.net/crew/mwh/summaries/>

   Posting distribution (with apologies to mbm)

   Number of articles in summary: 166

    25 |                                                 [|]    
       |                                 [|]             [|]    
       |                                 [|]             [|]    
       |                                 [|]             [|]    
    20 |     [|]                         [|]             [|]    
       |     [|]                         [|]             [|]    
       |     [|]                         [|]             [|]    
       |     [|]                         [|]             [|]    
    15 |     [|]                         [|]         [|] [|]    
       |     [|]                         [|]         [|] [|]    
       |     [|]                         [|]         [|] [|]    
       |     [|]             [|]     [|] [|]         [|] [|]    
    10 |     [|]             [|]     [|] [|] [|]     [|] [|]    
       |     [|]             [|]     [|] [|] [|]     [|] [|]    
       |     [|]             [|]     [|] [|] [|]     [|] [|]    
       |     [|]             [|] [|] [|] [|] [|]     [|] [|] [|]
     5 |     [|]     [|]     [|] [|] [|] [|] [|] [|] [|] [|] [|]
       |     [|]     [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
       | [|] [|]     [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
       | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
     0 +-003-022-002-006-005-013-007-013-026-012-006-017-027-007
        Thu 29| Sat 31| Mon 02| Wed 04| Fri 06| Sun 08| Tue 10|
            Fri 30  Sun 01  Tue 03  Thu 05  Sat 07  Mon 09  Wed 11

 Not much traffic this fortnight.  As ever, lots of bug-fixing for
 2.1.  If all goes to plan, I won't be able to say that in the next
 summary!


    * Assigning to __debug__ *

 About 2 weeks ago, changes were checked in that made assignments to
 the magic variable __debug__ SyntaxErrors.  Martin von Loewis pointed
 out that this would probably break code, and thus not be well
 received:

  <http://mail.python.org/pipermail/python-dev/2001-March/013995.html>

 There was general agreement, and it was decided that the error would
 be reduced to a warning.  Code to this effect has now been checked
 in.


    * Inverse string interpolation *

 Peter Funk posted a proposal for using the "/" operator on strings as
 a kind of dual to "%", i.e. be to "%" what "scanf" is to "printf" in
 C:

  <http://mail.python.org/pipermail/python-dev/2001-April/014027.html>

 There was muted approval for the idea, but less so for the spelling.
 Of course "scanf" isn't much better unless you've programmed in C...
 It's possible that this functionality will be somewhere in Python 2.2
 (though builtin, module, infix operator or string method is still to
 be decided, and it might be conditional on someone coming up with a
 good name!).


    * Line endings *

 A recurring theme (with a pretty long period) cropped up again: that
 of line endings in Python source code.  The thread stars here:

  <http://mail.python.org/pipermail/python-dev/2001-April/014090.html>

 At present, one cannot import a file with Unix line endings on the
 Macintosh.  While it would be relatively straightforward to bodge the
 compiler into accepting any of \n, \r or \r\n as a line terminator,
 this would not entirely solve the problem; for instance linecache.py
 in the standard library would need to be fixed.

 One option would be to implement a wrapper around file objects that
 would make .readline() work with all line endings.  However, this
 would be entertainingly difficult to get right on all platforms...

 You author hopes resolution is near, but admits to being slightly
 confused about the details!


    * Release schedule *

 A release candidate for Python 2.1 should be released tomorrow (the
 13th), and if all goes well, the final release will be on Monday (the
 16th).  Fingers crossed everyone!

Cheers,
M.



From guido@digicool.com  Thu Apr 12 19:47:12 2001
From: guido@digicool.com (Guido van Rossum)
Date: Thu, 12 Apr 2001 13:47:12 -0500
Subject: [Python-Dev] Proposed patch to cgi.py for 2.1 -- please review!
In-Reply-To: Your message of "Thu, 12 Apr 2001 15:02:39 +1200."
 <200104120302.PAA12841@s454.cosc.canterbury.ac.nz>
References: <200104120302.PAA12841@s454.cosc.canterbury.ac.nz>
Message-ID: <200104121847.NAA20986@cj20424-a.reston1.va.home.com>

> > (It could break code if someone tries to use the fileno() on a field
> > object's file attribute.)
> 
> Switch to a real file when someone accesses the file attribute?

Hm.  I can do that, but I'm less happy about the resulting mess. :-(

Here's the patch.  I think I'get back to this post-2.1...

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

Index: cgi.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/cgi.py,v
retrieving revision 1.63
diff -c -r1.63 cgi.py
*** cgi.py	2001/03/19 13:40:44	1.63
--- cgi.py	2001/04/12 16:45:50
***************
*** 509,515 ****
                  raise ValueError, 'Maximum content length exceeded'
          self.length = clen
  
!         self.list = self.file = None
          self.done = 0
          if ctype == 'application/x-www-form-urlencoded':
              self.read_urlencoded()
--- 509,515 ----
                  raise ValueError, 'Maximum content length exceeded'
          self.length = clen
  
!         self.list = self.__file = None
          self.done = 0
          if ctype == 'application/x-www-form-urlencoded':
              self.read_urlencoded()
***************
*** 524,531 ****
--- 524,537 ----
                  `self.name`, `self.filename`, `self.value`)
  
      def __getattr__(self, name):
+         if name == 'file':
+             self.file = self.__file_incarnate()
+             self.file.seek(0)
+             return self.file
          if name != 'value':
              raise AttributeError, name
+         if self.__file:
+             return self.__file.getvalue()
          if self.file:
              self.file.seek(0)
              value = self.file.read()
***************
*** 614,620 ****
              self.skip_lines()
          else:
              self.read_lines()
!         self.file.seek(0)
  
      bufsize = 8*1024            # I/O buffering size for copy to file
  
--- 620,627 ----
              self.skip_lines()
          else:
              self.read_lines()
!         if not self.__file:
!             self.file.seek(0)
  
      bufsize = 8*1024            # I/O buffering size for copy to file
  
***************
*** 633,644 ****
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.file = self.make_file('')
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
--- 640,665 ----
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.__file = StringIO()
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
+     def __file_incarnate(self):
+         file = self.make_file('')
+         file.write(self.__file.getvalue())
+         self.__file = None
+         return file
+ 
+     def __write(self, line):
+         if self.__file is not None:
+             if self.__file.tell() + len(line) <= 1000:
+                 self.__file.write(line)
+                 return
+             self.file = self.__file_incarnate()
+         self.file.write(line)
+ 
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
***************
*** 646,652 ****
              if not line:
                  self.done = -1
                  break
!             self.file.write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
--- 667,673 ----
              if not line:
                  self.done = -1
                  break
!             self.__write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
***************
*** 674,680 ****
                  line = line[:-1]
              else:
                  delim = ""
!             self.file.write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""
--- 695,701 ----
                  line = line[:-1]
              else:
                  delim = ""
!             self.__write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""


From guido@digicool.com  Thu Apr 12 23:37:09 2001
From: guido@digicool.com (Guido van Rossum)
Date: Thu, 12 Apr 2001 17:37:09 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Thu, 12 Apr 2001 10:03:33 +0200."
 <20010412100334-r01010600-5b54bb95@213.84.27.177>
References: <20010412100334-r01010600-5b54bb95@213.84.27.177>
Message-ID: <200104122237.RAA21755@cj20424-a.reston1.va.home.com>

> I don't get it: why would a thin layer on top of stdio be bad? Seems
> much less work than reimplementing stdio.

Because by layering stuff you lose performance.  Example: fgets() is
often implemented in a way that is faster than you can ever do
yourself with portable code.  (Because fgets() can peek in the buffer
and see if there's a \n somewhere ahead, using memcmp() -- and if this
succeeds, it can use memcpy().  You can't do that yourself - only the
stdio implementation can.  And this is not a hypothetical situation --
Tim used fgets() for a significant speed-up of readline() in 2.1.

But if we want to use our own line end convention, we can't use
fgets() any more, so we lose big.

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


From nas@python.ca  Thu Apr 12 22:39:37 2001
From: nas@python.ca (Neil Schemenauer)
Date: Thu, 12 Apr 2001 14:39:37 -0700
Subject: [Python-Dev] Problem with SSL and socketmodule on Debian Potato?
Message-ID: <20010412143937.A3784@glacier.fnational.com>

Fresh CVS tree:

Python 2.1c1 (#2, Apr 12 2001, 17:23:20) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/scratch/nascheme/py_cvs/dist/src/Lib/socket.py", line 41, in ?
    from _socket import *
ImportError: /scratch/nascheme/py_cvs/dist/src/linux/build/lib.linux-i686-2.1/_socket.so: undefined symbol: RAND_status

socketmodule is linked thusly:

gcc -shared build/temp.linux-i686-2.1/socketmodule.o -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-i686-2.1/_socket.so

The SSL package is:

    libssl09-dev 0.9.4-5

I've no time to dig into the details right now but I should have
time tonight.  I will be gone on holiday tomorrow.

  Neil


From martin@loewis.home.cs.tu-berlin.de  Thu Apr 12 22:59:58 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 12 Apr 2001 23:59:58 +0200
Subject: [Python-Dev] Problem with SSL and socketmodule on Debian Potato?
Message-ID: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de>

> ImportError:
> /scratch/nascheme/py_cvs/dist/src/linux/build/lib.linux-i686-2.1/_socket.so:
> undefined symbol: RAND_status

That symbol should be defined in libcrypto.so (it is on my SuSE
system); so that may be a problem with the Debian libssl package. SuSE
ships openssl-0.9.5a-54.

It appears that RAND_status was indeed added between 0.9.4 and
0.9.5. A test for OPENSSL_VERSION_NUMBER would probably help; in
0.9.5a, it has the value of 0x0090581fL.

Regards,
Martin


From sdm7g@Virginia.EDU  Thu Apr 12 23:08:50 2001
From: sdm7g@Virginia.EDU (Steven D. Majewski)
Date: Thu, 12 Apr 2001 18:08:50 -0400 (EDT)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
In-Reply-To: <200104122237.RAA21755@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.NXT.4.21.0104121755170.227-100000@localhost.virginia.edu>

[ re: various remarks about layering on stdio ] 

Has anybody looked at sfio ? 

I used it long ago for other reasons -- for a while the distribution 
seemed to have disappeared from att ( or maybe I just couldn't find
it on netlib ), but I just did a google search and found that there
is a new distribution: sfio2000: 

http://www.research.att.com/sw/tools/sfio/

I haven't looked at the package or the code for a LONG time & I 
don't know how portable it is, but it has some nice features and
advantages -- if you're at the point of considering rewriting 
stdio it might be worth looking at. 

-- Steve Majewski




From nas@python.ca  Fri Apr 13 01:41:19 2001
From: nas@python.ca (Neil Schemenauer)
Date: Thu, 12 Apr 2001 17:41:19 -0700
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Apr 12, 2001 at 11:59:58PM +0200
References: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de>
Message-ID: <20010412174118.A4120@glacier.fnational.com>

Martin v. Loewis wrote:
> It appears that RAND_status was indeed added between 0.9.4 and
> 0.9.5. A test for OPENSSL_VERSION_NUMBER would probably help; in
> 0.9.5a, it has the value of 0x0090581fL.

Right.  From my RAND_status man page:

       RAND_seed() and RAND_screen() are available in all
       versions of SSLeay and OpenSSL. RAND_add() and
       RAND_status() have been added in OpenSSL 0.9.5,
       RAND_event() in OpenSSL 0.9.5a.

The Debian libssl09-dev package does not work while
libssl096-dev does.  Both are available in the current stable
version of Debian (Potato).  We should patch socketmodule or add
a note to the README.

Sometimes I wonder if going to setup.py to build modules was a
mistake.  It would be easy to use autoconf to test of the
RAND_status function exists.  OTOH, its probably not too hard to
add the smarts to setup.py.

  Neil


From m.favas@per.dem.csiro.au  Fri Apr 13 01:43:57 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Apr 2001 08:43:57 +0800
Subject: [Python-Dev] 2.1c1: test_format failing?
Message-ID: <3AD64BCD.DD91216E@per.dem.csiro.au>

A couple of additions to test_format.py between April 12 and 13 now
cause the test to fail on Tru64 Unix (with Compaq's C compiler). Has
anyone else noticed errors with the test? The failures when running the
test standalone are:

'%#o' % 0 =? '0' ... no
u'%#o' % 0 =? '0' ... no

and from "make test":

test_format
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == '00' != '0'",
expected: ''

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From aahz@rahul.net  Fri Apr 13 01:54:56 2001
From: aahz@rahul.net (Aahz Maruch)
Date: Thu, 12 Apr 2001 17:54:56 -0700 (PDT)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
In-Reply-To: <Pine.NXT.4.21.0104121755170.227-100000@localhost.virginia.edu> from "Steven D. Majewski" at Apr 12, 2001 06:08:50 PM
Message-ID: <20010413005457.432DD99C86@waltz.rahul.net>

Steven D. Majewski wrote:
> 
> [ re: various remarks about layering on stdio ] 
> 
> Has anybody looked at sfio ? 

That reminds me of QIO, the stdio replacement in INN, which has already
been ported to Python.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.


From tim.one@home.com  Fri Apr 13 02:00:08 2001
From: tim.one@home.com (Tim Peters)
Date: Thu, 12 Apr 2001 21:00:08 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <Pine.NXT.4.21.0104121755170.227-100000@localhost.virginia.edu>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENKJLAA.tim.one@home.com>

[Steven D. Majewski]
> Has anybody looked at sfio ?
> ...
> http://www.research.att.com/sw/tools/sfio/

Did just now.  Only runs on Unix boxes, so would be a heavyweight way to
solve line-end problems across platforms that don't have any <wink>.
Possible to run it on Windows, but only on top of the commercial UWIN Unix
emulation package (http://www.research.att.com/sw/tools/uwin/).  They didn't
mention Macs at all.  The papers should be worth reading for anyone intending
to tackle this, though.



From tim.one@home.com  Fri Apr 13 02:17:09 2001
From: tim.one@home.com (Tim Peters)
Date: Thu, 12 Apr 2001 21:17:09 -0400
Subject: [Python-Dev] 2.1c1: test_format failing?
In-Reply-To: <3AD64BCD.DD91216E@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCEENLJLAA.tim.one@home.com>

[Mark Favas]
> A couple of additions to test_format.py between April 12 and 13 now
> cause the test to fail on Tru64 Unix (with Compaq's C compiler). Has
> anyone else noticed errors with the test? The failures when runnin
> the test standalone are:
>
> '%#o' % 0 =? '0' ... no
> u'%#o' % 0 =? '0' ... no
> ...
> But instead we got: "'%#o' % 0 == '00' != '0'"

Please run this C program:

#include <stdio.h>
void main() {
    printf("%#o\n", 0);
}

Does it print 00?  It *should* print 0:

    # The result is converted to an ‘‘alternative form’’. For
      o conversion, it increases the precision, if and only if
      necessary, to force the first digit of the result to be a
      zero (if the value and precision are both 0, a single 0 is
      printed). ...

In the test program, the value and precision are both 0, so a single '0' must
be the result (else your platform C is buggy).

Please let us know what happens.  Does anyone else get 00 from the above?



From m.favas@per.dem.csiro.au  Fri Apr 13 02:43:19 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Apr 2001 09:43:19 +0800
Subject: [Python-Dev] 2.1c1: test_format failing?
References: <LNBBLJKPBEHFEDALKOLCEENLJLAA.tim.one@home.com>
Message-ID: <3AD659B7.8F24082F@per.dem.csiro.au>

I've tried the test program on a few of my Tru64 boxes (with different
versions of the OS and different versions of the compiler) and all print
"00".


Tim Peters wrote:
> 
> [Mark Favas]
> > A couple of additions to test_format.py between April 12 and 13 now
> > cause the test to fail on Tru64 Unix (with Compaq's C compiler). Has
> > anyone else noticed errors with the test? The failures when runnin
> > the test standalone are:
> >
> > '%#o' % 0 =? '0' ... no
> > u'%#o' % 0 =? '0' ... no
> > ...
> > But instead we got: "'%#o' % 0 == '00' != '0'"
> 
> Please run this C program:
> 
> #include <stdio.h>
> void main() {
>     printf("%#o\n", 0);
> }
> 
> Does it print 00?  It *should* print 0:
> 
>     # The result is converted to an ??alternative form??. For
>       o conversion, it increases the precision, if and only if
>       necessary, to force the first digit of the result to be a
>       zero (if the value and precision are both 0, a single 0 is
>       printed). ...
> 
> In the test program, the value and precision are both 0, so a single '0' must
> be the result (else your platform C is buggy).
> 
> Please let us know what happens.  Does anyone else get 00 from the above?

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From tim.one@home.com  Fri Apr 13 03:51:56 2001
From: tim.one@home.com (Tim Peters)
Date: Thu, 12 Apr 2001 22:51:56 -0400
Subject: [Python-Dev] 2.1c1: test_format failing?
In-Reply-To: <3AD659B7.8F24082F@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEOFJLAA.tim.one@home.com>

[Mark Favas]
> I've tried the test program on a few of my Tru64 boxes (with different
> versions of the OS and different versions of the compiler) and all
> print "00".

Then that's why Python '%#o' % 0 also returns "00" (formats of short ints use
the platform sprintf).  As far as I'm concerned, then, this is a
long-standing bug in Compaq's C (the blurb I quoted before was verbatim from
the C standard, and addressed this specific case).

I expect you'll find that '%#o' % 0L returns "0" even on your box, because
Python does its own formats on long ints.

As time goes on, and we eradicate the differences between ints and longs, I
expect we'll end up using the Python long int format code all the time.

Before then, I'm disinclined to add more code to the short int case trying to
worm around platform C bugs, unless at least one other platform is found
where

#include <stdio.h>
void main() {
    printf("%#o\n", 0);
}

prints 00.

BTW, what does this print for you (just changing "o" to "x")?

#include <stdio.h>
void main() {
    printf("%#x\n", 0);
}

If they print 0x0 for that (they're supposed to print 0), current CVS Python
will assert-fail in debug mode on '%#x' % 0.



From m.favas@per.dem.csiro.au  Fri Apr 13 04:43:29 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Apr 2001 11:43:29 +0800
Subject: [Python-Dev] 2.1c1: test_format failing?
References: <LNBBLJKPBEHFEDALKOLCAEOFJLAA.tim.one@home.com>
Message-ID: <3AD675E1.C93AFE56@per.dem.csiro.au>

Responses interpolated below...

[Tim Peters]
> 
> [Mark Favas]
> > I've tried the test program on a few of my Tru64 boxes (with different
> > versions of the OS and different versions of the compiler) and all
> > print "00".
> 
> Then that's why Python '%#o' % 0 also returns "00" (formats of short ints use
> the platform sprintf).  As far as I'm concerned, then, this is a
> long-standing bug in Compaq's C (the blurb I quoted before was verbatim from
> the C standard, and addressed this specific case).
> 
> I expect you'll find that '%#o' % 0L returns "0" even on your box, because
> Python does its own formats on long ints.

It does indeed.


> 
> As time goes on, and we eradicate the differences between ints and longs, I
> expect we'll end up using the Python long int format code all the time.
> 
> Before then, I'm disinclined to add more code to the short int case trying to
> worm around platform C bugs, unless at least one other platform is found
> where
> 
> #include <stdio.h>
> void main() {
>     printf("%#o\n", 0);
> }
> 
> prints 00.

I've just tried Solaris 2.5.1, Solaris 8, FreeBSD 4.2 and even(!) Irix
6.5 - all produce "0" - :( or :) depending on your POV.


> 
> BTW, what does this print for you (just changing "o" to "x")?
> 
> #include <stdio.h>
> void main() {
>     printf("%#x\n", 0);
> }
> 
> If they print 0x0 for that (they're supposed to print 0), current CVS Python
> will assert-fail in debug mode on '%#x' % 0.

This produces "0"

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From fdrake@beowolf.digicool.com  Fri Apr 13 06:10:02 2001
From: fdrake@beowolf.digicool.com (Fred Drake)
Date: Fri, 13 Apr 2001 01:10:02 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010413051002.795BD2879C@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


More description and explanation in the unittest documentation; update to
match the final code and decisions from the pyunit-interest mailing list.

Added information on urllib.FancyURLopener's handling of basic 
authentication and how to change the prompting behavior.

Added documentation for the ColorPicker module for the Macintosh.



From rushing@nightmare.com  Fri Apr 13 06:45:14 2001
From: rushing@nightmare.com (Sam Rushing)
Date: Thu, 12 Apr 2001 22:45:14 -0700
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
 <3ACDB0BC.2533D8C2@digicool.com> <15053.56089.93466.30362@anthem.wooz.org>
Message-ID: <3AD6926A.12C937B@nightmare.com>

"Barry A. Warsaw" wrote:

> Oh, one other thing.  Last time I traded email with Sam Rushing
> (almost a year ago, and I'm not even sure if he's on python-dev), he
> was moving toward a coroutine based Medusa and away from async* based.

One of the reasons I originally offered them into the distribution was
that those two modules were always distributed under a standard python
license, while the rest of medusa was still 'commercial'.  Since that's
no longer the case, there's less of a reason to have it in the standard
lib.  [But I think there are a lot of async* users out there...]

Coupla other points:

  1) there are folks (myself included) that would like to see a new
design for asyncore and asynchat, one that doesn't require the expensive
polling of objects and that can have lots of its underbelly parts
replaced with C when necessary.  A totally new 'official' facility that
was aware of and could take advantage of the features of /dev/poll,
kqueue, rtsig, etc.. would be way cool.  I don't think that backward
compatibility would be all that important, since most software uses
async* in a 'shallow' way rather than a 'deep' way - it's be easy to
recode to a newer more efficient API.

  2) it'll be a while before anything polished will be along to obsolete
async*/medusa.  I'm currently working with kqueue and stackless
coroutines but don't know when/if I might be able to release the code.
Such a beast will be radically different from medusa, and would certainly
have a new name...  it's almost more of a 'python-level user-threading
package' (like uthread) than a replacement for async*.

-Sam




From tim.one@home.com  Fri Apr 13 08:12:05 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 13 Apr 2001 03:12:05 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010412100334-r01010600-5b54bb95@213.84.27.177>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEONJLAA.tim.one@home.com>

[Tim]
> No, there's nothing wrong with the tokenizer code:  it's coded
> in C, and the C text convention is that lines end with \n, period.
> Reliance on that convention is ubiquitous -- and properly so.

[Just van Rossum]
> I don't get it: why would a thin layer on top of stdio be bad?
> Seems much less work than reimplementing stdio.

What does that question have to do with the snippet you quoted?  In context,
that snippet was saying that if you did write a small layer on top of stdio,
one that just made \n show up when and only when you think Python should
believe a line ends, then nothing in the tokenizer would need to change
(except to call that layer instead of fgets()), and even the tokenizer's
current \r\n mini-hack could be thrown away.

If that's all you want, that's all it takes.  If you want more than just
that, you need more than just that (but I see Guido already explained that,
and I explained too why the Windows Python cannot recognize \r endings with
reasonable speed for *general* use short of building our own stdio -- but I
don't really much care how fast the compiler runs, if all you want is the
same limited level of hack afforded by the existing one-shot \r\n tokenizer
trick -- and the compiler isn't using the *general*-case fileobject.c
get_line() anyway).

you-pay-for-what-you-want-and-the-more-you-want-the-more-you'll-pay-ly
    y'rs  - tim



From tim.one@home.com  Fri Apr 13 08:40:47 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 13 Apr 2001 03:40:47 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104122237.RAA21755@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEOOJLAA.tim.one@home.com>

[Guido]
> ...
> But if we want to use our own line end convention, we can't use
> fgets() any more, so we lose big.

Well, people said "we couldn't" use fgets() for get_line() either, because
Python strings can contain embedded nulls but fgets() doesn't tell you how
many bytes it read and makes up null bytes of its own.  But I have 200 lines
of excruciating code in fileobject.c that proved them excruciatingly wrong
<wink>.  The same kind of excruciating crap could almost certainly be used to
search for alternative line endings on top of fgets() too.  We would have to
layer our own buffer on top of the hidden platform buffer to get away with
this, because while fgets() will stop at the first \n it sees, there's no way
to ask it to stop at any other character (so in general fgets() would
"over-read" when looking for a non-native line-end, and we'd have to save the
excess in our own buffer).

Hard to say how much that would cost.  I think it surprised everyone (incl.
me!) that even with all the extra buffer-filling and buffer-searching the
fgets() hackery does, that method was at worst a wash with the
getc_unlocked() method on all platforms tried.

In any case, the fgets() hack is only *needed* on Windows, so every other
platform could just make get_line()'s character-at-a-time loop search for
more end conditions.  This can't be impossible <wink>.

s/\r\n?/\n/g-ly y'rs  - tim



From mal@lemburg.com  Fri Apr 13 09:24:18 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 13 Apr 2001 10:24:18 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
References: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de> <20010412174118.A4120@glacier.fnational.com>
Message-ID: <3AD6B7B2.18C3788D@lemburg.com>

Neil Schemenauer wrote:
> 
> Martin v. Loewis wrote:
> > It appears that RAND_status was indeed added between 0.9.4 and
> > 0.9.5. A test for OPENSSL_VERSION_NUMBER would probably help; in
> > 0.9.5a, it has the value of 0x0090581fL.
> 
> Right.  From my RAND_status man page:
> 
>        RAND_seed() and RAND_screen() are available in all
>        versions of SSLeay and OpenSSL. RAND_add() and
>        RAND_status() have been added in OpenSSL 0.9.5,
>        RAND_event() in OpenSSL 0.9.5a.
> 
> The Debian libssl09-dev package does not work while
> libssl096-dev does.  Both are available in the current stable
> version of Debian (Potato).  We should patch socketmodule or add
> a note to the README.
> 
> Sometimes I wonder if going to setup.py to build modules was a
> mistake.  It would be easy to use autoconf to test of the
> RAND_status function exists.  OTOH, its probably not too hard to
> add the smarts to setup.py.

distutils has the machinery for this built-in, but it's not
really ready for prime-time yet. See the mxSetup.py file in my
egenix-mx-base source archive for some auto-conf style code
built on top of the basic tools available in distutils.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From just@letterror.com  Fri Apr 13 10:43:21 2001
From: just@letterror.com (Just van Rossum)
Date: Fri, 13 Apr 2001 11:43:21 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEOOJLAA.tim.one@home.com>
Message-ID: <20010413114324-r01010600-54b4467f@213.84.27.177>

I understand now that I simply don't have enough clue about the implementation
to even try to be involved with this. Unless it makes sense to have a PEP that
doesn't touch the implementation at all (doubtful, IMHO), I'll take back my
offer to write one. I still think it's an important issue, but it's simply
beyond what I can deal with.

To solve the issues on MacOS X, maybe it's enough to hack the Carbon version of
stdio so it can handle unix text files. That way we can simply settle for unix
line ending if sharing code between BSD Python and Carbon Python is desired. At
the same time this would allow using CVS under Darwin for MacPython sources,
which is something I look forward to...

Just


From mal@lemburg.com  Fri Apr 13 12:09:09 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 13 Apr 2001 13:09:09 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
References: <20010413114324-r01010600-54b4467f@213.84.27.177>
Message-ID: <3AD6DE54.ED351E8E@lemburg.com>

Just van Rossum wrote:
> 
> I understand now that I simply don't have enough clue about the implementation
> to even try to be involved with this. Unless it makes sense to have a PEP that
> doesn't touch the implementation at all (doubtful, IMHO), I'll take back my
> offer to write one. I still think it's an important issue, but it's simply
> beyond what I can deal with.

Please write the results of this discussion up as a PEP. PEPs don't
necessarily have to provide an implementation of what is covered;
it sometimes simply suffices to start out with a summary of the
discussions that have been going on. Then someone may pick up the
threads from there and possibly find a solution which will then
get implemented.
 
> To solve the issues on MacOS X, maybe it's enough to hack the Carbon version of
> stdio so it can handle unix text files. That way we can simply settle for unix
> line ending if sharing code between BSD Python and Carbon Python is desired. At
> the same time this would allow using CVS under Darwin for MacPython sources,
> which is something I look forward to...

AFAIR, this discussion was about handling line endings in Python
source code. There have been discussions about turning the tokenizer
into a Unicode based machine. We could then use the Unicode tools
to do line separations.

I don't know why this thread lead to tweaking stdio -- after all
we only need a solution for the Python tokenizer and not a general
purpose stdio abstraction of text files unless I'm missing something
here...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From just@letterror.com  Fri Apr 13 12:43:25 2001
From: just@letterror.com (Just van Rossum)
Date: Fri, 13 Apr 2001 13:43:25 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <3AD6DE54.ED351E8E@lemburg.com>
Message-ID: <20010413134326-r01010600-bafaee65@213.84.27.177>

M.-A. Lemburg wrote:

> I don't know why this thread lead to tweaking stdio -- after all
> we only need a solution for the Python tokenizer and not a general
> purpose stdio abstraction of text files unless I'm missing something
> here...

Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all,
but then what about all tools that read source files line by line? Eg.
linecache.py, all IDE's, etc. etc. As Tim wrote a while back:

  importing-is-only-the-start-of-the-battle

So no, we don't "only need a solution for the Python tokenizer"...

Just


From aahz@rahul.net  Fri Apr 13 14:13:22 2001
From: aahz@rahul.net (Aahz Maruch)
Date: Fri, 13 Apr 2001 06:13:22 -0700 (PDT)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010413134326-r01010600-bafaee65@213.84.27.177> from "Just van Rossum" at Apr 13, 2001 01:43:25 PM
Message-ID: <20010413131323.6358899C97@waltz.rahul.net>

Just van Rossum wrote:
> M.-A. Lemburg wrote:
> 
>> I don't know why this thread lead to tweaking stdio -- after all
>> we only need a solution for the Python tokenizer and not a general
>> purpose stdio abstraction of text files unless I'm missing something
>> here...
> 
> Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all,
> but then what about all tools that read source files line by line? Eg.
> linecache.py, all IDE's, etc. etc. 

<grin>  I'll repeat my question of yesterday: is there any reason why we
couldn't start with QIO?  I did some checking after I sent that out, and
QIO claims that it can be configured to recognize different kinds of
line endings.  QIO is claimed to be 2-3 times faster than Python 1.5.2;
don't know how that compares to 2.x.

[the previous message was sent to python-dev only; this time I'm
including pythonmac-sig]
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.


From guido@digicool.com  Fri Apr 13 15:52:35 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 09:52:35 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Fri, 13 Apr 2001 06:13:22 MST."
 <20010413131323.6358899C97@waltz.rahul.net>
References: <20010413131323.6358899C97@waltz.rahul.net>
Message-ID: <200104131452.JAA27545@cj20424-a.reston1.va.home.com>

> <grin>  I'll repeat my question of yesterday: is there any reason why we
> couldn't start with QIO?  I did some checking after I sent that out, and
> QIO claims that it can be configured to recognize different kinds of
> line endings.  QIO is claimed to be 2-3 times faster than Python 1.5.2;
> don't know how that compares to 2.x.

>From a one-minute review it looks like as good a start as any!

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


From martin@loewis.home.cs.tu-berlin.de  Fri Apr 13 16:29:23 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 13 Apr 2001 17:29:23 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
Message-ID: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de>

> Sometimes I wonder if going to setup.py to build modules was a
> mistake.  It would be easy to use autoconf to test of the
> RAND_status function exists.  OTOH, its probably not too hard to add
> the smarts to setup.py.

I don't think it was a mistake. First, even though Python had been
using autoconf for years, nobody came up with a complete patch to
autoconfiscate Modules/Setup, or define a different configuration
mechanism. So using setup.py was an improvement over the status quo,
even if not an improvement over some not-implemented technique - which
might have never been implemented.

Furthermore, as Marc-Andr=E9 points out: there is nothing that stops
setup.py/distutils from using the same strategies as autoconf.

Finally, in this specific case, I do think that the best strategy is
to check for the version of OpenSSL. This is against autoconf
philosophy (check for features, not for versions), but since the SSL
support is tied to a specific implementation, rather than an API with
competing implementations, checking the version does no harm and
simplifies the configuration machinery.

Regards,
Martin


From guido@digicool.com  Fri Apr 13 17:39:59 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 11:39:59 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Fri, 13 Apr 2001 17:29:23 +0200."
 <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de>
References: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de>
Message-ID: <200104131639.LAA31088@cj20424-a.reston1.va.home.com>

> I don't think it was a mistake. First, even though Python had been
> using autoconf for years, nobody came up with a complete patch to
> autoconfiscate Modules/Setup, or define a different configuration
> mechanism. So using setup.py was an improvement over the status quo,
> even if not an improvement over some not-implemented technique - which
> might have never been implemented.
> 
> Furthermore, as Marc-André points out: there is nothing that stops
> setup.py/distutils from using the same strategies as autoconf.
> 
> Finally, in this specific case, I do think that the best strategy is
> to check for the version of OpenSSL. This is against autoconf
> philosophy (check for features, not for versions), but since the SSL
> support is tied to a specific implementation, rather than an API with
> competing implementations, checking the version does no harm and
> simplifies the configuration machinery.

So, is this a showstopper issue for the release candidate?  I believe
Neil went on vacation today.  I'd like to have a release out in 6
hours.  Should I try to get this fixed???

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


From moshez@zadka.site.co.il  Fri Apr 13 16:42:39 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Fri, 13 Apr 2001 18:42:39 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131639.LAA31088@cj20424-a.reston1.va.home.com>
References: <200104131639.LAA31088@cj20424-a.reston1.va.home.com>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de>
Message-ID: <E14o5iZ-00015o-00@darjeeling>

On Fri, 13 Apr 2001 11:39:59 -0500, Guido van Rossum <guido@digicool.com> wrote:
 
> So, is this a showstopper issue for the release candidate?  

In my opinion, yes.
Sadly, I don't have the manpower to commit and test this properly,
but it is important.

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez@debian.org  |http://www.{python,debian,gnu}.org


From martin@loewis.home.cs.tu-berlin.de  Fri Apr 13 17:14:27 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 13 Apr 2001 18:14:27 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131639.LAA31088@cj20424-a.reston1.va.home.com> (message
 from Guido van Rossum on Fri, 13 Apr 2001 11:39:59 -0500)
References: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>
Message-ID: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>

> So, is this a showstopper issue for the release candidate?

It will mean that the socket module does not work out-of-the-box on
some Debian systems; that could be fixed by enabling the socket module
in Modules/Setup so that it is built without SSL support.

> I believe Neil went on vacation today.  I'd like to have a release
> out in 6 hours.  Should I try to get this fixed???

How about this patch? I've verified that it works with my OpenSSL
installation (0.9.5a), and, by source code inspection, that it should
work with versions back to 0.9.1c (ie. that OPENSSL_VERSION_NUMBER was
always available through including <openssl/crypto.h>).

The logic about RAND_status being 0 if unknown might be flawed, but
that won't hurt unless SSL support is actually used.

If this won't get into 2.1, I'll put it on SF.

Regards,
Martin

Index: socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.139
diff -u -r1.139 socketmodule.c
--- socketmodule.c	2001/03/18 17:11:56	1.139
+++ socketmodule.c	2001/04/13 15:56:04
@@ -195,6 +195,13 @@
 #include "openssl/ssl.h"
 #include "openssl/err.h"
 #include "openssl/rand.h"
+
+#if OPENSSL_VERSION_NUMBER < 0x0090510fL
+/* RAND_status was added in OpenSSL 0.9.5. If it is not available,
+   we assume that seeding the RNG is necessary every time. */
+#define RAND_status()	0
+#endif
+
 #endif /* USE_SSL */
 
 #if defined(MS_WINDOWS) || defined(__BEOS__)


From moshez@zadka.site.co.il  Fri Apr 13 17:20:42 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Fri, 13 Apr 2001 19:20:42 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>
References: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>
Message-ID: <E14o6JO-0001EI-00@darjeeling>

On Fri, 13 Apr 2001, "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> wrote:

> How about this patch? I've verified that it works with my OpenSSL
> installation (0.9.5a), and, by source code inspection, that it should
> work with versions back to 0.9.1c (ie. that OPENSSL_VERSION_NUMBER was
> always available through including <openssl/crypto.h>).
> 
> The logic about RAND_status being 0 if unknown might be flawed, but
> that won't hurt unless SSL support is actually used.

No, this seems like a worse cure then the cause...
Why not put the whole if (RAND_status()) thing under the ifdef?
It was only added in 2.1, so at least we would be no worse off then in 2.0
> 
> If this won't get into 2.1, I'll put it on SF.
> 
> Regards,
> Martin
> 
> Index: socketmodule.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
> retrieving revision 1.139
> diff -u -r1.139 socketmodule.c
> --- socketmodule.c	2001/03/18 17:11:56	1.139
> +++ socketmodule.c	2001/04/13 15:56:04
> @@ -195,6 +195,13 @@
>  #include "openssl/ssl.h"
>  #include "openssl/err.h"
>  #include "openssl/rand.h"
> +
> +#if OPENSSL_VERSION_NUMBER < 0x0090510fL
> +/* RAND_status was added in OpenSSL 0.9.5. If it is not available,
> +   we assume that seeding the RNG is necessary every time. */
> +#define RAND_status()	0
> +#endif
> +
>  #endif /* USE_SSL */
>  
>  #if defined(MS_WINDOWS) || defined(__BEOS__)
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> 
> 
-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez@debian.org  |http://www.{python,debian,gnu}.org


From guido@digicool.com  Fri Apr 13 18:34:13 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 12:34:13 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Fri, 13 Apr 2001 18:14:27 +0200."
 <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>
References: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>
 <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>
Message-ID: <200104131734.MAA32326@cj20424-a.reston1.va.home.com>

> > So, is this a showstopper issue for the release candidate?
> 
> It will mean that the socket module does not work out-of-the-box on
> some Debian systems; that could be fixed by enabling the socket module
> in Modules/Setup so that it is built without SSL support.
> 
> > I believe Neil went on vacation today.  I'd like to have a release
> > out in 6 hours.  Should I try to get this fixed???
> 
> How about this patch? I've verified that it works with my OpenSSL
> installation (0.9.5a), and, by source code inspection, that it should
> work with versions back to 0.9.1c (ie. that OPENSSL_VERSION_NUMBER was
> always available through including <openssl/crypto.h>).
> 
> The logic about RAND_status being 0 if unknown might be flawed, but
> that won't hurt unless SSL support is actually used.
> 
> If this won't get into 2.1, I'll put it on SF.

Thanks, I think I'll add that.  It looks harmless.  (Famous last
words. :-)

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


From guido@digicool.com  Fri Apr 13 18:39:59 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 12:39:59 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Fri, 13 Apr 2001 19:20:42 +0300."
 <E14o6JO-0001EI-00@darjeeling>
References: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>
 <E14o6JO-0001EI-00@darjeeling>
Message-ID: <200104131739.MAA01976@cj20424-a.reston1.va.home.com>

> No, this seems like a worse cure then the cause...
> Why not put the whole if (RAND_status()) thing under the ifdef?
> It was only added in 2.1, so at least we would be no worse off then in 2.0

Moshe, please mail me a specific patch.  I don't know the code well
enough to guess what you mean!

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


From martin@loewis.home.cs.tu-berlin.de  Fri Apr 13 18:33:26 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 13 Apr 2001 19:33:26 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <E14o6JO-0001EI-00@darjeeling> (message from Moshe Zadka on Fri,
 13 Apr 2001 19:20:42 +0300)
References: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>
Message-ID: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>

> No, this seems like a worse cure then the cause...

Can you elaborate? It cures the problem of the socket module not being
loadable...

> Why not put the whole if (RAND_status()) thing under the ifdef?  It
> was only added in 2.1, so at least we would be no worse off then in
> 2.0

AFAICT, under my patch, when using OpenSSL on a system with EGD, it
will do the right thing. On a system with /dev/random, it will produce
a runtime warning, then add insecure entropy - in addition to the
secure entropy already obtained from /dev/random.

Under what I think is your patch, it will do the right thing on a
system with /dev/random. On a system with EGD, it will fail because of
the missing entropy.

Regards,
Martin


From jeremy@digicool.com  Fri Apr 13 18:44:04 2001
From: jeremy@digicool.com (Jeremy Hylton)
Date: Fri, 13 Apr 2001 13:44:04 -0400 (EDT)
Subject: [Python-Dev] compileall.py and make install
Message-ID: <15063.15076.601471.476713@slothrop.digicool.com>

There are two related problems that I'd like to fix for the release
candidate.  One is that compileall.py basically ignores compiler
errors.  It's clear that the code intends to return with a non-zero
exit status if there are compilation errors, but it doesn't do that
currently.

If I fix just this problem, make install will start to fail because
there are six files in the test directory that contain intentional
SyntaxErrors; in one case, it's necessary that the SyntaxError be
raised through import.

I'd like to fix compileall.py and add an optional argument that tells
it to skip files that match a regular expression.  Then I'll rename
all the offending files so that they are named badsyntax_XXX and fix
the Makefile so that it installs them but does not compile them.

This is going to cause two problems for developers.  First, you'll
need to manually delete the files with the old names from the install
lib directory.  (I'll rename nocaret.py to badsyntax_nocaret.py, but,
if you've already done an install, you'll also have a nocaret.py in
the lib directory.)

The compileall script also traverses into site-packages.  If you have
compilation errors in code that you've installed into site-packages,
then make install will fail. 

I'm not sure what to do about this.  During development, at least, it
is probably helpful for make install to walk into site-packages and
fail if the new version of Python breaks existing code.  On the other
hand, it could be a big pain that you can't install Python just
because you previously installed a buggy Python library.  Of course,
you could just remove the broken code.

I think it's a net gain to make these changes.  Is anyone more
concerned that me about the possible breakage?

Jeremy





From fdrake@acm.org  Fri Apr 13 19:02:55 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 13 Apr 2001 14:02:55 -0400 (EDT)
Subject: [Python-Dev] Docs are frozen.
Message-ID: <15063.16207.884585.823138@beowolf.digicool.com>

  The documentation tree is frozen for Python 2.1c1.  All further
changes should be submitted via the SourceForge patch manager until
Python 2.1 has been released.
  Thanks!


  -Fred

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



From chrishbarker@home.net  Fri Apr 13 19:20:32 2001
From: chrishbarker@home.net (Chris Barker)
Date: Fri, 13 Apr 2001 11:20:32 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
References: <20010413114324-r01010600-54b4467f@213.84.27.177> <3AD6DE54.ED351E8E@lemburg.com>
Message-ID: <3AD74370.2EF0614C@home.net>

"M.-A. Lemburg" wrote:
> Please write the results of this discussion up as a PEP. PEPs don't
> necessarily have to provide an implementation of what is covered;
> it sometimes simply suffices to start out with a summary of the
> discussions that have been going on. Then someone may pick up the
> threads from there and possibly find a solution which will then
> get implemented.

Just, I second that. I really think this is a very useful improvement to
Python, I'd I'd really like to see it happen. I am probably even more
out of my depth than you when it comes to suggesting impimentation, but
I'd be glad to help with any parts of a PEP that I can.

Guido van Rossum wrote:
> > <grin>  I'll repeat my question of yesterday: is there any reason why we
> > couldn't start with QIO?  I did some checking after I sent that out, and
> > QIO claims that it can be configured to recognize different kinds of
> > line endings.  QIO is claimed to be 2-3 times faster than Python 1.5.2;
> > don't know how that compares to 2.x.
> 
> >From a one-minute review it looks like as good a start as any!

Great! I have to say that it really seemed that someone must have
produced an open source solution to this problem somewhere, and it turns
out there is something Python related already.

-Chris


-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker@home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------


From fdrake@beowolf.digicool.com  Fri Apr 13 19:15:38 2001
From: fdrake@beowolf.digicool.com (Fred Drake)
Date: Fri, 13 Apr 2001 14:15:38 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010413181538.7BA3F28A06@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/

Final documentation for Python 2.1c1.



From guido@digicool.com  Fri Apr 13 20:45:51 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 14:45:51 -0500
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: Your message of "Fri, 13 Apr 2001 13:44:04 -0400."
 <15063.15076.601471.476713@slothrop.digicool.com>
References: <15063.15076.601471.476713@slothrop.digicool.com>
Message-ID: <200104131945.OAA09964@cj20424-a.reston1.va.home.com>

> There are two related problems that I'd like to fix for the release
> candidate.  One is that compileall.py basically ignores compiler
> errors.  It's clear that the code intends to return with a non-zero
> exit status if there are compilation errors, but it doesn't do that
> currently.
> 
> If I fix just this problem, make install will start to fail because
> there are six files in the test directory that contain intentional
> SyntaxErrors; in one case, it's necessary that the SyntaxError be
> raised through import.
> 
> I'd like to fix compileall.py and add an optional argument that tells
> it to skip files that match a regular expression.  Then I'll rename
> all the offending files so that they are named badsyntax_XXX and fix
> the Makefile so that it installs them but does not compile them.
> 
> This is going to cause two problems for developers.  First, you'll
> need to manually delete the files with the old names from the install
> lib directory.  (I'll rename nocaret.py to badsyntax_nocaret.py, but,
> if you've already done an install, you'll also have a nocaret.py in
> the lib directory.)
> 
> The compileall script also traverses into site-packages.  If you have
> compilation errors in code that you've installed into site-packages,
> then make install will fail. 
> 
> I'm not sure what to do about this.  During development, at least, it
> is probably helpful for make install to walk into site-packages and
> fail if the new version of Python breaks existing code.  On the other
> hand, it could be a big pain that you can't install Python just
> because you previously installed a buggy Python library.  Of course,
> you could just remove the broken code.
> 
> I think it's a net gain to make these changes.  Is anyone more
> concerned that me about the possible breakage?

-1 for getting this in the 2.1 release.  +1 for fixing this soon
after.  I'm beginning to see the point of branching off for releases!

I'm not sure what advantage there is to compileall.py returning a
non-zero exit code, and I clearly see the risk of doing it so close to
the release.  I have about three hours to send the release candidate
out, I want to do some more testing, *and* I want to have the night
off... :-)

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


From jeremy@digicool.com  Fri Apr 13 19:48:34 2001
From: jeremy@digicool.com (Jeremy Hylton)
Date: Fri, 13 Apr 2001 14:48:34 -0400 (EDT)
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: <15063.15076.601471.476713@slothrop.digicool.com>
References: <15063.15076.601471.476713@slothrop.digicool.com>
Message-ID: <15063.18946.598247.129409@slothrop.digicool.com>

A brief historical analysis of the situation

In the olden days, py_compile.py did not catch SyntaxErrors.  If
compileall.py used py_compile.py to compile a file and it failed,
it would print an error message but continue working. 

When Python 1.5.2 was released, py_compile was updated to catch the
exceptions on its own.

About six months later, well before 2.0, a change was made to
compileall to exit with non-zero status if it caught a syntax error.
This change apparently had no effect, because compileall never saw
syntax errors.

Jeremy

 



From jeremy@digicool.com  Fri Apr 13 19:52:44 2001
From: jeremy@digicool.com (Jeremy Hylton)
Date: Fri, 13 Apr 2001 14:52:44 -0400 (EDT)
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: <200104131945.OAA09964@cj20424-a.reston1.va.home.com>
References: <15063.15076.601471.476713@slothrop.digicool.com>
 <200104131945.OAA09964@cj20424-a.reston1.va.home.com>
Message-ID: <15063.19196.236720.410550@slothrop.digicool.com>

>>>>> "GvR" == Guido van Rossum <guido@digicool.com> writes:

  GvR> -1 for getting this in the 2.1 release.  +1 for fixing this
  GvR> soon after.  I'm beginning to see the point of branching off
  GvR> for releases!

Okay.

Jeremy



From guido@digicool.com  Fri Apr 13 21:05:39 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 15:05:39 -0500
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: Your message of "Fri, 13 Apr 2001 14:48:34 -0400."
 <15063.18946.598247.129409@slothrop.digicool.com>
References: <15063.15076.601471.476713@slothrop.digicool.com>
 <15063.18946.598247.129409@slothrop.digicool.com>
Message-ID: <200104132005.PAA10142@cj20424-a.reston1.va.home.com>

> A brief historical analysis of the situation
> 
> In the olden days, py_compile.py did not catch SyntaxErrors.  If
> compileall.py used py_compile.py to compile a file and it failed,
> it would print an error message but continue working. 
> 
> When Python 1.5.2 was released, py_compile was updated to catch the
> exceptions on its own.
> 
> About six months later, well before 2.0, a change was made to
> compileall to exit with non-zero status if it caught a syntax error.
> This change apparently had no effect, because compileall never saw
> syntax errors.

Hm.  That change was never tested, apparently. :-(

This means that even if we fix py_compile.py after 2.1 is released, we
risk breaking existing usage.  Not clear whether that should matter
much though.

But definitely not a risk I want to take in 2.1.

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


From guido@python.org  Fri Apr 13 23:18:40 2001
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Apr 2001 17:18:40 -0500
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
Message-ID: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>

Python 2.1 is almost ready.  We've built a release candidate -- a
version that should become the final version, barring any last-minute
showstopper bugs (which will of course be fixed before releasing the
final version).  Thanks to all who helped!

Please download the release candidate and use it on your favorite
platform.  For more info:

    http://www.python.org/2.1/

There's not much new since 2.1b2: we mostly fixed bugs and added
documentation.  Some things that *did* change visibly:

  - Ping added an interactive help browser to pydoc. (Very cool!  Try it!)

  - Eric Raymond extended the pstats module with a simple interactive
    statistics browser, invoked when the module is run as a script.

  - An updated python-mode.el version 4.0 which integrates Ken
    Manheimer's pdbtrack.el.  This makes debugging Python code via pdb
    much nicer in XEmacs and Emacs.  When stepping through your program
    with pdb, in either the shell window or the *Python* window, the
    source file and line will be tracked by an arrow.

  - After a public outcry, assignment to __debug__ is no longer illegal;
    instead, a warning is issued.  It will become illegal in 2.2.

  - New port: SCO Unixware 7, by Billy G. Allie.

  - Updated the RISCOS port.

We expect to release the final version on Tuesday morning, April 17.

Enjoy!

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


From paul@pfdubois.com  Fri Apr 13 22:47:45 2001
From: paul@pfdubois.com (Paul F. Dubois)
Date: Fri, 13 Apr 2001 14:47:45 -0700
Subject: [Python-Dev] Complex detection
Message-ID: <ADEOIFHFONCLEEPKCACCKECECIAA.paul@pfdubois.com>

My understanding is that Python can be built without complex numbers to
satisfy the needs of the Python-on-a-wristwatch crowd. Is there a run-time
way to tell? For example, using an imaginary literal causes an error? If so,
what kind?

I'm finishing the reference implementation for PEP 242 and want to allow for
this possibility.



From ping@lfw.org  Fri Apr 13 23:28:20 2001
From: ping@lfw.org (Ka-Ping Yee)
Date: Fri, 13 Apr 2001 17:28:20 -0500 (CDT)
Subject: [Python-Dev] Complex detection
In-Reply-To: <ADEOIFHFONCLEEPKCACCKECECIAA.paul@pfdubois.com>
Message-ID: <Pine.LNX.4.10.10104131727180.21723-100000@server1.lfw.org>

On Fri, 13 Apr 2001, Paul F. Dubois wrote:
> My understanding is that Python can be built without complex numbers to
> satisfy the needs of the Python-on-a-wristwatch crowd. Is there a run-time
> way to tell? For example, using an imaginary literal causes an error? If so,
> what kind?

This is just a guess, but check hasattr(__builtins__, 'complex') perhaps?
That's what i would do.


-- ?!ng



From tim.one@home.com  Fri Apr 13 23:39:46 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 13 Apr 2001 18:39:46 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010413134326-r01010600-bafaee65@213.84.27.177>
Message-ID: <LNBBLJKPBEHFEDALKOLCIECBJMAA.tim.one@home.com>

[MAL]
> I don't know why this thread lead to tweaking stdio -- after all
> we only need a solution for the Python tokenizer ...

[Just]
> Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is
> great and all,> but then what about all tools that read source
> files line by line? ...

Note that this is why the topic needs a PEP:  nothing here is new; the same
debates reoccur every time it comes up.

[Aahz]
> ...
> QIO claims that it can be configured to recognize different
> kinds of line endings.

It can be, yes, but in the same sense as Awk/Perl paragraph mode:  you can
tell it to consider any string (not just single character) as meaning "end of
the line", but it's a *fixed* string per invocation.  What people want *here*
is more the ability to recognize the regular expression

    \r\n?|\n

as ending a line, and QIO can't do that directly (as currently written).  And
MAL probably wants Unicode line-end detection:

    http://www.unicode.org/unicode/reports/tr13/

> QIO is claimed to be 2-3 times faster than Python 1.5.2; don't
> know how that compares to 2.x.

The bulk of that was due to QIO avoiding per-character thread locks.  2.1
avoids them too, so most of QIO's speed advantage should be gone now.  But
QIO's internals could certainly be faster than they are (this is obscure
because QIO.readline() has so many optional behaviors that the maze of
if-tests makes it hard to see the speed-crucial bits; studying Perl's
line-reading code is a better model, because Perl's speed-crucial inner loop
has no non-essential operations -- Perl makes the *surrounding* code sort out
the optional bits, instead of bogging down the loop with them).



From tim.one@home.com  Fri Apr 13 23:48:22 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 13 Apr 2001 18:48:22 -0400
Subject: [Python-Dev] Complex detection
In-Reply-To: <ADEOIFHFONCLEEPKCACCKECECIAA.paul@pfdubois.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKECEJMAA.tim.one@home.com>

[Paul F. Dubois]
> My understanding is that Python can be built without complex numbers
> to satisfy the needs of the Python-on-a-wristwatch crowd. Is there a
> run-time way to tell? For example, using an imaginary literal causes
> an error? If so, what kind?

You can find out by compiling with WITHOUT_COMPLEX #define'd.  PythonLabs
never does this, so no guarantee it even works.  I'm not going to bother
starting now, either <wink>.  Based on skimming the code, I expect

try:
    eval("1j")
    with_complex = 1
except SyntaxError:
    with_complex = 0

would do the trick, but no guarantee.



From m.favas@per.dem.csiro.au  Sat Apr 14 01:59:34 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 08:59:34 +0800
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
Message-ID: <3AD7A0F6.7673FDD3@per.dem.csiro.au>

FreeBSD 4.2-20010225-STABLE, gcc 2.95.2

./python Lib/test/test_zipfile.py
Traceback (most recent call last):
  File "Lib/test/test_zipfile.py", line 35, in ?
    zipTest(file, zipfile.ZIP_STORED, writtenData)
  File "Lib/test/test_zipfile.py", line 18, in zipTest
    zip.close()
  File "/home/mark/src/python/CVS/python/dist/src/Lib/zipfile.py", line
471, in close
    self.fp.flush()
IOError: [Errno 9] Bad file descriptor

Looks like FreeBSD objects to doing a flush() on a file opened for
reading. The self.fp.flush() call should probably be part of the
preceding if-block relating to files opened in "a" or "w' mode.
-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From moshez@zadka.site.co.il  Sat Apr 14 01:58:38 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Sat, 14 Apr 2001 03:58:38 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>
Message-ID: <E14oEOc-0001si-00@darjeeling>

"competing patch" attached at end.

On Fri, 13 Apr 2001, "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> wrote:
> > No, this seems like a worse cure then the cause...
> 
> Can you elaborate? It cures the problem of the socket module not being
> loadable...

You're right, it was a bad choice of words.
 
> AFAICT, under my patch, when using OpenSSL on a system with EGD, it
> will do the right thing. On a system with /dev/random, it will produce
> a runtime warning, then add insecure entropy - in addition to the
> secure entropy already obtained from /dev/random.
> 
> Under what I think is your patch, it will do the right thing on a
> system with /dev/random. On a system with EGD, it will fail because of
> the missing entropy.

Correct on both. My "worse" is: it would print a warning about using
an insecure method on systems with /dev/random but without an EGD,
even though it is secure. Note that the EGD stuff is new with 2.1,
so losing that is not a step backwards from 2.0. Printing a wrong warning
is a step backwards, so in that sense my patch is more conservative.
 
After further contemplation, none of these is a pure win.
It's up to Guido if he wants to use my patch instead of Martin's
for 2.1final
-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez@debian.org  |http://www.{python,debian,gnu}.org


*** Modules/socketmodule.c	Sun Mar 18 18:38:50 2001
--- new	Sat Apr 14 03:53:20 2001
***************
*** 2545,2550 ****
--- 2545,2551 ----
  	if (PyDict_SetItemString(d, "SSLType",
  				 (PyObject *)&SSL_Type) != 0)
  		return;
+ #if OPENSSL_VERSION_NUMBER < 0x0090510fL
  	if (RAND_status() == 0) {
  #ifdef USE_EGD
  		char random_device[MAXPATHLEN+1];
***************
*** 2571,2576 ****
--- 2572,2578 ----
  		RAND_seed(random_string, sizeof(random_string));
  #endif /* USE_EGD */
  	}
+ #endif /* OPENSSL_VERSION_NUMBER < 0x0090510fL */
  #endif /* USE_SSL */
  	PyDict_SetItemString(d, "error", PySocket_Error);
  	PySocketSock_Type.ob_type = &PyType_Type;


From m.favas@per.dem.csiro.au  Sat Apr 14 02:07:29 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 09:07:29 +0800
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
Message-ID: <3AD7A2D1.B04928AE@per.dem.csiro.au>

SunOS asafoetida 5.8, gcc 2.95.2

"make test" fails on running test_asynchat.py for the second time. The
traceback is:

Exception in thread Thread-1:
Traceback (most recent call last):
  File
"/export/home/mark/src/python/CVS/python/dist/src/Lib/threading.py",
line 378, in __bootstrap
    self.run()
  File "Lib/test/test_asynchat.py", line 12, in run
    sock.bind((HOST, PORT))
error: (125, 'Address already in use')

Traceback (most recent call last):
  File "Lib/test/test_asynchat.py", line 56, in ?
    main()
  File "Lib/test/test_asynchat.py", line 51, in main
    c = echo_client()
  File "Lib/test/test_asynchat.py", line 32, in __init__
    self.connect((HOST, PORT))
  File
"/export/home/mark/src/python/CVS/python/dist/src/Lib/asyncore.py", line
308, in connect
    raise socket.error, why
socket.error: (146, 'Connection refused')

Looks like Solaris takes a while to shut sockets down? (This is not a
slow box, btw.) Or is there an option to not have the socket linger?

Also, test_sunaudiodev fails, since setup.py tests only whether the
platform is a Sun, not whether there is a /dev/audio as well. Servers
don't have a /dev/audio. This is clearly a minor nit - I did log a bug
against this some time ago.

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From m.favas@per.dem.csiro.au  Sat Apr 14 02:12:29 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 09:12:29 +0800
Subject: [Python-Dev] 2.1c1: "make test" core dumps on SGI Irix
Message-ID: <3AD7A3FD.CBEB9510@per.dem.csiro.au>

IRIX64 dodo 6.5 07201607 IP35, MIPSpro Compilers: Version 7.30

"make test" core dumps with no output from any test completed. Running
them one-by-one reveals that the (first?) core dump is in
test___all__.py.
python Lib/test/test___all__.py
Bus error (core dumped)

dbx where gives: (chopped)
>  0 float_mul(0x100ce7dc, 0x103523d8, 0x8, 0x100b5d70, 0x10050000, 0x103523d8, 0x100b5d70, 0x100b5ce8) ["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/floatobject.c":382, 0x1004f098]
   1 binary_op1(0x100ce7dc, 0x103523d8, 0x0, 0x100b5d70, 0x10050000,
0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/abstract.c":337,
0x1003bfec]
   2 binary_op(0x100ce7dc, 0x103523d8, 0x8, 0x0, 0x10050000, 0x103523d8,
0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/abstract.c":373,
0x1003c200]
   3 PyNumber_Multiply(0x100ce7dc, 0x103523d8, 0x8, 0x100b5d70,
0x10050000, 0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/abstract.c":544,
0x1003c934]
   4 eval_code2(0x101bea78, 0x0, 0x0, 0x0, 0x103ffad7, 0x0, 0x0, 0x0)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/ceval.c":945,
0x10035cb4]
   5 PyEval_EvalCode(0x100ce7dc, 0x103523d8, 0x8, 0x100b5d70,
0x10050000, 0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/ceval.c":341,
0x10032818]
   6 PyImport_ExecCodeModuleEx(0x7fff1168, 0x0, 0x0, 0x100b5d70,
0x10050000, 0x103523d8, 0x0, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/import.c":490,
0x1000d904]
   7 load_source_module(0x0, 0x7fff0840, 0x0, 0x100b5d70, 0x10050000,
0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/import.c":754,
0x1000e0f0]
More (n if no)?

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From esr@thyrsus.com  Sat Apr 14 02:41:39 2001
From: esr@thyrsus.com (Eric S. Raymond)
Date: Fri, 13 Apr 2001 21:41:39 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Apr 13, 2001 at 05:18:40PM -0500
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>
Message-ID: <20010413214139.A3800@thyrsus.com>

Guido van Rossum <guido@python.org>:
>   - Eric Raymond extended the pstats module with a simple interactive
>     statistics browser, invoked when the module is run as a script.

...which I tested by using it to speed-tune the crap out of CML2, dropping the
configurator's startup time from over 15 seconds to about 2 :-).

CML2 has been officially accepted for inclusion in the Linux kernel, BTW.
Linus himself quashed the anti-Python grumbling from some of the more
conservative types on lkml by uttering the ukase "Python is not an issue."
It's scheduled to go in sometime in the 2.5.1 to 2.5.2 series.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
        -- G. Kleck, "Policy Lessons from Recent Gun Control Research,"


From guido@digicool.com  Sat Apr 14 03:42:28 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 21:42:28 -0500
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:07:29 +0800."
 <3AD7A2D1.B04928AE@per.dem.csiro.au>
References: <3AD7A2D1.B04928AE@per.dem.csiro.au>
Message-ID: <200104140242.VAA11020@cj20424-a.reston1.va.home.com>

> SunOS asafoetida 5.8, gcc 2.95.2
> 
> "make test" fails on running test_asynchat.py for the second time. The
> traceback is:
> 
> Exception in thread Thread-1:
> Traceback (most recent call last):
>   File
> "/export/home/mark/src/python/CVS/python/dist/src/Lib/threading.py",
> line 378, in __bootstrap
>     self.run()
>   File "Lib/test/test_asynchat.py", line 12, in run
>     sock.bind((HOST, PORT))
> error: (125, 'Address already in use')
> 
> Traceback (most recent call last):
>   File "Lib/test/test_asynchat.py", line 56, in ?
>     main()
>   File "Lib/test/test_asynchat.py", line 51, in main
>     c = echo_client()
>   File "Lib/test/test_asynchat.py", line 32, in __init__
>     self.connect((HOST, PORT))
>   File
> "/export/home/mark/src/python/CVS/python/dist/src/Lib/asyncore.py", line
> 308, in connect
>     raise socket.error, why
> socket.error: (146, 'Connection refused')
> 
> Looks like Solaris takes a while to shut sockets down? (This is not a
> slow box, btw.) Or is there an option to not have the socket linger?

Dunno, but there *is* an option to allow reusing a socket.

> Also, test_sunaudiodev fails, since setup.py tests only whether the
> platform is a Sun, not whether there is a /dev/audio as well. Servers
> don't have a /dev/audio. This is clearly a minor nit - I did log a bug
> against this some time ago.

Compiling on a server doesn't mean you'll run on a server only.  But
the test should mark itself as "skipped" when /dev/audio doesn't
exist.  I don't know how easy that is.

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


From guido@digicool.com  Sat Apr 14 03:43:07 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 21:43:07 -0500
Subject: [Python-Dev] 2.1c1: "make test" core dumps on SGI Irix
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:12:29 +0800."
 <3AD7A3FD.CBEB9510@per.dem.csiro.au>
References: <3AD7A3FD.CBEB9510@per.dem.csiro.au>
Message-ID: <200104140243.VAA11034@cj20424-a.reston1.va.home.com>

> IRIX64 dodo 6.5 07201607 IP35, MIPSpro Compilers: Version 7.30
> 
> "make test" core dumps with no output from any test completed. Running
> them one-by-one reveals that the (first?) core dump is in
> test___all__.py.
> python Lib/test/test___all__.py
> Bus error (core dumped)

Try compiling without -O?

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


From fdrake@acm.org  Sat Apr 14 02:49:51 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 13 Apr 2001 21:49:51 -0400 (EDT)
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
In-Reply-To: <200104140242.VAA11020@cj20424-a.reston1.va.home.com>
References: <3AD7A2D1.B04928AE@per.dem.csiro.au>
 <200104140242.VAA11020@cj20424-a.reston1.va.home.com>
Message-ID: <15063.44223.710582.338422@cj42289-a.reston1.va.home.com>

--k6y/EtxsEc
Content-Type: text/plain; charset=us-ascii
Content-Description: message body and .signature
Content-Transfer-Encoding: 7bit


Guido van Rossum writes:
 > Compiling on a server doesn't mean you'll run on a server only.  But
 > the test should mark itself as "skipped" when /dev/audio doesn't
 > exist.  I don't know how easy that is.

Mark,
  Please try the following patch to Lib/test/test_sunaudiodev.py and
let us know how that works for you.


  -Fred

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


--k6y/EtxsEc
Content-Type: text/plain
Content-Description: test_sunaudiodev.py patch
Content-Disposition: inline;
	filename="patch"
Content-Transfer-Encoding: 7bit

Index: test_sunaudiodev.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_sunaudiodev.py,v
retrieving revision 1.9
diff -c -r1.9 test_sunaudiodev.py
*** test_sunaudiodev.py	2001/01/17 21:51:36	1.9
--- test_sunaudiodev.py	2001/04/14 01:47:49
***************
*** 1,6 ****
! from test_support import verbose, findfile, TestFailed
  import sunaudiodev
  import os
  
  def play_sound_file(path):
      fp = open(path, 'r')
--- 1,14 ----
! from test_support import verbose, findfile, TestFailed, TestSkipped
  import sunaudiodev
  import os
+ 
+ try:
+     audiodev = os.environ["AUDIODEV"]
+ except KeyError:
+     audiodev = "/dev/audio"
+ 
+ if not os.path.exists(audiodev):
+     raise TestSkipped("no audio device dound!")
  
  def play_sound_file(path):
      fp = open(path, 'r')

--k6y/EtxsEc--



From m.favas@per.dem.csiro.au  Sat Apr 14 03:13:44 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 10:13:44 +0800
Subject: [Python-Dev] 2.1c1: test_sunaudiodev fails on Sun servers
References: <3AD7A2D1.B04928AE@per.dem.csiro.au>
 <200104140242.VAA11020@cj20424-a.reston1.va.home.com> <15063.44223.710582.338422@cj42289-a.reston1.va.home.com>
Message-ID: <3AD7B258.7ED22029@per.dem.csiro.au>

Fred,

Yes, that works for me (perhaps we could change "dound" to "found"
though <wink>).

M

"Fred L. Drake, Jr." wrote:
> 
> Guido van Rossum writes:
>  > Compiling on a server doesn't mean you'll run on a server only.  But
>  > the test should mark itself as "skipped" when /dev/audio doesn't
>  > exist.  I don't know how easy that is.
> 
> Mark,
>   Please try the following patch to Lib/test/test_sunaudiodev.py and
> let us know how that works for you.
> 
>   -Fred
> 
> --
> Fred L. Drake, Jr.  <fdrake at acm.org>
> PythonLabs at Digital Creations
> 
>   ------------------------------------------------------------------------
> Index: test_sunaudiodev.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/test/test_sunaudiodev.py,v
> retrieving revision 1.9
> diff -c -r1.9 test_sunaudiodev.py
> *** test_sunaudiodev.py 2001/01/17 21:51:36     1.9
> --- test_sunaudiodev.py 2001/04/14 01:47:49
> ***************
> *** 1,6 ****
> ! from test_support import verbose, findfile, TestFailed
>   import sunaudiodev
>   import os
> 
>   def play_sound_file(path):
>       fp = open(path, 'r')
> --- 1,14 ----
> ! from test_support import verbose, findfile, TestFailed, TestSkipped
>   import sunaudiodev
>   import os
> +
> + try:
> +     audiodev = os.environ["AUDIODEV"]
> + except KeyError:
> +     audiodev = "/dev/audio"
> +
> + if not os.path.exists(audiodev):
> +     raise TestSkipped("no audio device dound!")
> 
>   def play_sound_file(path):
>       fp = open(path, 'r')

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From Jason.Tishler@dothill.com  Sat Apr 14 03:25:01 2001
From: Jason.Tishler@dothill.com (Jason Tishler)
Date: Fri, 13 Apr 2001 22:25:01 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
Message-ID: <20010413222501.D5606@dothill.com>

I configured as follows:

    configure --with-threads=no

When I run the regression tests I get the following:

    test test_threadedtempfile crashed -- exceptions.AttributeError: 'threading' module has no attribute 'Event'

Should this test only be run if Python is built with thread support?

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com


From m.favas@per.dem.csiro.au  Sat Apr 14 03:45:41 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 10:45:41 +0800
Subject: [Python-Dev] 2.1c1: "make test" core dumps on SGI Irix
References: <3AD7A3FD.CBEB9510@per.dem.csiro.au> <200104140243.VAA11034@cj20424-a.reston1.va.home.com>
Message-ID: <3AD7B9D5.CCE64D03@per.dem.csiro.au>

Recompiling floatobject.c without optimization makes the bus error
during "make test" go away. Perhaps the SGI section in the README could
be updated here - it only mentions a possible problem with
complexobject.c and Numeric.

"make test" now fails on:

test_largefile
test test_largefile crashed -- exceptions.IOError: [Errno 22] Invalid
argument

and

test_locale
test test_locale crashed -- exceptions.ValueError: unpack sequence of
wrong size

and

test_zlib
*** Termination code 9 (bu21)

More details:

python Lib/test/test_largefile.py
create large file via seek (may be sparse file) ...
Traceback (most recent call last):
  File "Lib/test/test_largefile.py", line 63, in ?
    f.flush()
IOError: [Errno 22] Invalid argument


python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ...
Traceback (most recent call last):
  File "Lib/test/test_locale.py", line 29, in ?
    testformat("%f", 1024, grouping=1, output='1,024.000000')
  File "Lib/test/test_locale.py", line 18, in testformat
    result = locale.format(formatstr, value, grouping = grouping)
  File "/tmp_mnt/home/solo/mark/python/Python-2.1c1/Lib/locale.py", line
137, in format
    fields[0],seps=_group(fields[0])
ValueError: unpack sequence of wrong size


python Lib/test/test_zlib.py
0xe5c1a120 0x43b6aa94
0xbd602f7 0xbd602f7
expecting Bad compression level
expecting Invalid initialization option
expecting Invalid initialization option
normal compression/decompression succeeded
compress/decompression obj succeeded
decompress with init options succeeded
decompressobj with init options succeeded
Killed

Recompiling _everything_ without optimization produces no change. I have
no time to poke around further at the moment - later this afternoon...

M

Guido van Rossum wrote:
> 
> > IRIX64 dodo 6.5 07201607 IP35, MIPSpro Compilers: Version 7.30
> >
> > "make test" core dumps with no output from any test completed. Running
> > them one-by-one reveals that the (first?) core dump is in
> > test___all__.py.
> > python Lib/test/test___all__.py
> > Bus error (core dumped)
> 
> Try compiling without -O?
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From fdrake@acm.org  Sat Apr 14 04:11:54 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 13 Apr 2001 23:11:54 -0400 (EDT)
Subject: [Python-Dev] 2.1c1: test_sunaudiodev fails on Sun servers
In-Reply-To: <3AD7B258.7ED22029@per.dem.csiro.au>
References: <3AD7A2D1.B04928AE@per.dem.csiro.au>
 <200104140242.VAA11020@cj20424-a.reston1.va.home.com>
 <15063.44223.710582.338422@cj42289-a.reston1.va.home.com>
 <3AD7B258.7ED22029@per.dem.csiro.au>
Message-ID: <15063.49146.634503.336638@cj42289-a.reston1.va.home.com>

Mark Favas writes:
 > Yes, that works for me (perhaps we could change "dound" to "found"
 > though <wink>).

  Hey, you'll have to file a formal bug report on SF for that!  ;-)
Ok, this is checked in.  If everyone who can build with the
sunaudiodev module would test this, I'd really appreciate any feedback
on this!


  -Fred

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



From gherman@darwin.in-berlin.de  Sat Apr 14 07:25:17 2001
From: gherman@darwin.in-berlin.de (Dinu Gherman)
Date: Sat, 14 Apr 2001 08:25:17 +0200
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
Message-ID: <3AD7ED4D.58597DFD@darwin.in-berlin.de>

> Examples
> 
>     Here is an example of an interactive session exhibiting the
>     expected behaviour of this feature.
> 
>         >>> "12345 John Doe" / "%5d %8s"
>         (12345, 'John Doe')
>         >>> "12 34 56 7.890" / "%d %d %d %f"
>         (12, 34, 56, 7.8899999999999997)
>         >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
>         {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
>         >>> "1 2" / "%d %d %d"
>         Traceback (innermost last):
>           File "<stdin>", line 1, in ?
>         TypeError: not all arguments filled
 

Kind of late to jump in, but this is the nature of this list.

I'd like to support Peter's proposal for having *some* kind 
of inverse mechanism to string formatting using '%'. Now, that
doesn't mean anything, of course, but no matter what the syn-
tax would look like: I'd prefer having that feature over not
having it and I'll give an example below.

Reminding you of a thread I triggered a while ago (that went 
slightly astray) which was, kind of, received with suspicion,
I notice that it matches quite nicely with Peter's (more ge-
neral) idea. Here's the thread's summary:

  Grouping function for string module?          
http://mail.python.org/pipermail/python-list/1999-September/011875.html

Combining this I'd like to see something like the following 
(again, maybe with a different syntax):

    >>> "1010000011110101" / "%4s%4s%4s%4s"
    ('1010', '0000', '1111', '0101')
    >>> "10100000111101" / "%4s%4s%4s%4s"
    ('1010', '0000', '1111', '01')

or even:

    >>> "1010000011110101" / ("%4s" * 4)
    ('1010', '0000', '1111', '0101')

;-)

Regards and Happy Easter (will be away for a week)!

Dinu

-- 
Dinu C. Gherman
ReportLab Consultant - http://www.reportlab.com
................................................................
"The only possible values [for quality] are 'excellent' and 'in-
sanely excellent', depending on whether lives are at stake or 
not. Otherwise you don't enjoy your work, you don't work well, 
and the project goes down the drain." 
                    (Kent Beck, "Extreme Programming Explained")


From tim.one@home.com  Sat Apr 14 08:50:32 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 14 Apr 2001 03:50:32 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <20010413222501.D5606@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEDDJMAA.tim.one@home.com>

[Jason Tishler]
> I configured as follows:
>
>     configure --with-threads=no
>
> When I run the regression tests I get the following:
>
>     test test_threadedtempfile crashed --
> exceptions.AttributeError: 'threading' module has no attribute 'Event'
>
> Should this test only be run if Python is built with thread support?

Yes, it should be run only when there's thread support (well, actually,
regrtest.py will *try* it regardless, but ... see what follows).

The first thing test_threadedtempfile does is

    import threading

and I *expect* that to die with an ImportError when there's no thread
suppport, due to threading.py trying to do

    import thread

early on.  regrtest.py looks out for ImportErrors, and I expect it to say

    test test_threadedtempfile skipped --  No module named thread

in your situation.

So the question is why you're not getting an ImportError on "import thread"
(try it an interactive Python to make sure that's the cause).  Why you're not
getting an ImportError I'll have to leave to someone who understands the Unix
config process.

OTOH, the threading module you are importing is damaged, else threading.Event
would have existed.  So perhaps there's a deeper problem here than just a
config thing.  First let us know what happens when you try "import thread" on
its own.



From mwh21@cam.ac.uk  Sat Apr 14 11:05:07 2001
From: mwh21@cam.ac.uk (Michael Hudson)
Date: Sat, 14 Apr 2001 11:05:07 +0100 (BST)
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEDDJMAA.tim.one@home.com>
Message-ID: <Pine.LNX.4.10.10104141059210.19675-100000@localhost.localdomain>

On Sat, 14 Apr 2001, Tim Peters wrote:

> So the question is why you're not getting an ImportError on "import
> thread" (try it an interactive Python to make sure that's the cause).  
> Why you're not getting an ImportError I'll have to leave to someone
> who understands the Unix config process.

That one's easy: a testcase earlier has tried to "import threading";
*that* import died with an ImportError when threading tried to import
"thread", and then the "import threading" in
test_threadtempfileorwhatever.py gets the half finished module object that
had been constructed when "import thread" blew up for the first time.

Maybe modules should be removed from sys.modules when they fail to be
imported due to an exception?

Cheers,
M.




From tim.one@home.com  Sat Apr 14 11:16:50 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 14 Apr 2001 06:16:50 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <Pine.LNX.4.10.10104141059210.19675-100000@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEDKJMAA.tim.one@home.com>

I'm sure Michael is right; tried to send email about that before, but never
saw it come across; the same problem was reported recently by someone else on
SF:

http://sourceforge.net/tracker/?func=detail&atid=105470&
    aid=416089&group_id=5470

(although SF appears dead now too!).

[Michael Hudson]
> ...
> Maybe modules should be removed from sys.modules when they fail to be
> imported due to an exception?

As I said in the phantom email nobody saw <wink>, this isn't the first time
we've been screwed by this in the test suite (e.g., look near the top of
test___all__.py for evidence of the last time I wrestled with this).  But I'm
pretty sure Guido explicitly declined to do what you suggest, although I
can't recall why now.

sleep-now-argue-tomorrow-ly y'rs  - tim



From guido@digicool.com  Sat Apr 14 15:05:29 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 09:05:29 -0500
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: Your message of "Fri, 13 Apr 2001 21:41:39 -0400."
 <20010413214139.A3800@thyrsus.com>
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>
 <20010413214139.A3800@thyrsus.com>
Message-ID: <200104141405.JAA12126@cj20424-a.reston1.va.home.com>

> >   - Eric Raymond extended the pstats module with a simple interactive
> >     statistics browser, invoked when the module is run as a script.
> 
> ...which I tested by using it to speed-tune the crap out of CML2, dropping the
> configurator's startup time from over 15 seconds to about 2 :-).
> 
> CML2 has been officially accepted for inclusion in the Linux kernel, BTW.
> Linus himself quashed the anti-Python grumbling from some of the more
> conservative types on lkml by uttering the ukase "Python is not an issue."
> It's scheduled to go in sometime in the 2.5.1 to 2.5.2 series.

Congratulations are in order, Eric!

I guess a more positive endorsement of Python from Linus will be out
of the question for now... :-)

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



From Jason.Tishler@dothill.com  Sat Apr 14 14:59:28 2001
From: Jason.Tishler@dothill.com (Jason Tishler)
Date: Sat, 14 Apr 2001 09:59:28 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEDJJMAA.tim.one@home.com>; from tim.one@home.com on Sat, Apr 14, 2001 at 06:01:07AM -0400
References: <20010413222501.D5606@dothill.com> <LNBBLJKPBEHFEDALKOLCKEDJJMAA.tim.one@home.com>
Message-ID: <20010414095928.A5743@dothill.com>

Tim,

On Sat, Apr 14, 2001 at 06:01:07AM -0400, Tim Peters wrote:
> I bet this fresh SF bug report explains it:
> 
> http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416089&group_id=5470

Bingo!  See the following:

    $ ./python
    Python 2.1c1 (#1, Apr 13 2001, 21:47:33) 
    [GCC 2.95.3-2 (cygwin special)] on cygwin_nt-4.01
    Type "copyright", "credits" or "license" for more information.
    >>> import threading
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
      File "/home/jt/src/Python-2.1c1/Lib/threading.py", line 5, in ?
        import thread
    ImportError: No module named thread
    >>> import threading
    >>>

> Instead they deliver a, umm, bogus module object <wink>.  I've
> never liked this behavior -- but probably can't change it for 2.1 final.  It
> won't be the first time we've needed to worm around it in the test suite
> either ...

Oh well, there is always 2.2...

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com


From esr@thyrsus.com  Sat Apr 14 15:10:55 2001
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 10:10:55 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <200104141405.JAA12126@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 09:05:29AM -0500
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com> <20010413214139.A3800@thyrsus.com> <200104141405.JAA12126@cj20424-a.reston1.va.home.com>
Message-ID: <20010414101055.A8625@thyrsus.com>

Guido van Rossum <guido@digicool.com>:
> > CML2 has been officially accepted for inclusion in the Linux kernel, BTW.
> 
> Congratulations are in order, Eric!

It wouldn't have happened without your signoff on including the curses
module and friends in the 2.0 standard libraries.

Eric's clever plan, if you haven't guessed already, was to use Python
and the Linux kernel tree to goose the evolution of both projects,
using the requirements from each one to overcome the resistance
of the more conservative people in the other camp.  

And, while the major reason I made Python 2.x a prerequisite for CML2
was to shrink its footprint in the kernel tree, it was not absent from
my mind that doing so would put salutary pressure on the Linux distros
to upgrade to 2.x sooner than they might have otherwise.

> I guess a more positive endorsement of Python from Linus will be out
> of the question for now... :-)

For now.  But...the *next* step in the sinister master plan, after
CML2 is in, involves replacing all the Perl and awk and Tcl in the
kernel tree with Python.  The conservatives on lkml who objected to
adding Python to the build-prerequisites list are going to find that
their own arguments for mimimal external dependencies actually support
this move.

OK, so I'm going to rewrite all the (non-bash) kernel support scripts.
In the process, I'm going to make that codebase cleaner, smaller,
better documented, and more featureful.  Give me six months after CML2
goes in and I *will* have Linus and the lkml crowd making approving
noises about Python.  Count on it.

At that point, we'll have seized a major piece of the high ground, with
knock-on effects on Python's acceptance level everywhere.  Which was
*also* part of the plan, exactly dual to the effect on Linux of making 
kernel configuration so easy your Aunt Tillie could do it.

There is one implication of this scenario for Python development
itself -- that it's time to take a serious swing at eliminating our
dependency on Tcl for GUIs.  Whether we do this by adding wxPython to
the core or in some other way I don't care, but it would strengthen my
hand with the lkml crowd considerably if Python no longer had that
dependency.

Sometime in there, you and I gotta find time to PEP the Python library reorg,
too...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The danger (where there is any) from armed citizens, is only to the
*government*, not to *society*; and as long as they have nothing to
revenge in the government (which they cannot have while it is in their
own hands) there are many advantages in their being accustomed to the 
use of arms, and no possible disadvantage.
        -- Joel Barlow, "Advice to the Privileged Orders", 1792-93


From jeremy@digicool.com  Sat Apr 14 15:32:28 2001
From: jeremy@digicool.com (Jeremy Hylton)
Date: Sat, 14 Apr 2001 10:32:28 -0400 (EDT)
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <20010413214139.A3800@thyrsus.com>
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>
 <20010413214139.A3800@thyrsus.com>
Message-ID: <15064.24444.322307.549038@slothrop.digicool.com>

>>>>> "ESR" == Eric S Raymond <esr@thyrsus.com> writes:

  ESR> Guido van Rossum <guido@python.org>:
  >> - Eric Raymond extended the pstats module with a simple
  >>   interactive
  >> statistics browser, invoked when the module is run as a script.

  ESR> ...which I tested by using it to speed-tune the crap out of
  ESR> CML2, dropping the configurator's startup time from over 15
  ESR> seconds to about 2 :-).

Please take a look at the bug report I filed on SF.  The
ProfileBrowser seems to have a lot of bugs.  The first several times I
tried it, it crashed with uncaught exceptions.  As an example, the
strip command tries to call a strip_order() method, which isn't
defined anywhere in the module.

Perhaps there should be a test suite for the code.  Otherwise, it's
hard to tell if it works, since it was checked in the day of the
release candidate.

Jeremy



From aahz@rahul.net  Sat Apr 14 15:39:48 2001
From: aahz@rahul.net (Aahz Maruch)
Date: Sat, 14 Apr 2001 07:39:48 -0700 (PDT)
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <20010414101055.A8625@thyrsus.com> from "Eric S. Raymond" at Apr 14, 2001 10:10:55 AM
Message-ID: <20010414143948.2018F99C85@waltz.rahul.net>

Eric S. Raymond wrote:
> 
> And, while the major reason I made Python 2.x a prerequisite for CML2
> was to shrink its footprint in the kernel tree, it was not absent from
> my mind that doing so would put salutary pressure on the Linux distros
> to upgrade to 2.x sooner than they might have otherwise.

Sounds good.  OTOH, due to the GPL issue with 2.0 itself, this will
likely require either 2.0.1 or 2.1; I'll have a small preference for
2.0.1 myself.  I've been holding off on the next round of PEP6 (bugfix
release process) until after the 2.1 release.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.


From esr@thyrsus.com  Sat Apr 14 15:53:15 2001
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 10:53:15 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <15064.24444.322307.549038@slothrop.digicool.com>; from jeremy@digicool.com on Sat, Apr 14, 2001 at 10:32:28AM -0400
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com> <20010413214139.A3800@thyrsus.com> <15064.24444.322307.549038@slothrop.digicool.com>
Message-ID: <20010414105315.A9299@thyrsus.com>

Jeremy Hylton <jeremy@digicool.com>:
> Please take a look at the bug report I filed on SF. 

I'll do so.

> Perhaps there should be a test suite for the code.  Otherwise, it's
> hard to tell if it works, since it was checked in the day of the
> release candidate.

It was working enough for me to get practical use out of it, anway.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No one is bound to obey an unconstitutional law and no courts are bound
to enforce it.  
	-- 16 Am. Jur. Sec. 177 late 2d, Sec 256


From esr@thyrsus.com  Sat Apr 14 16:21:33 2001
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 11:21:33 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <20010414105315.A9299@thyrsus.com>; from esr@thyrsus.com on Sat, Apr 14, 2001 at 10:53:15AM -0400
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com> <20010413214139.A3800@thyrsus.com> <15064.24444.322307.549038@slothrop.digicool.com> <20010414105315.A9299@thyrsus.com>
Message-ID: <20010414112133.A9594@thyrsus.com>

Eric S. Raymond <esr@thyrsus.com>:
> Jeremy Hylton <jeremy@digicool.com>:
> > Please take a look at the bug report I filed on SF. 
> 
> I'll do so.
> 
> > Perhaps there should be a test suite for the code.  Otherwise, it's
> > hard to tell if it works, since it was checked in the day of the
> > release candidate.
> 
> It was working enough for me to get practical use out of it, anway.

Trust Jeremy to find one of the only two methods I forgot to test after
refactoring the browser to use the self.generic method.  Should now be
fixed in CVS; I have to go fight a different fire now, but I'll 
double-check all the methods this afternoon.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Among the many misdeeds of British rule in India, history will look
upon the Act depriving a whole nation of arms as the blackest."
        -- Mohandas Ghandhi, An Autobiography, pg 446


From guido@digicool.com  Sat Apr 14 18:27:09 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 12:27:09 -0500
Subject: [Python-Dev] make clean and make clobber semantics
Message-ID: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>

I just noticed for the first time that the semantics of "make clean"
and "make clobber" have changed.  "make clean" used to remove the .so
files too, AFAIK, but no longer does so.  "make clean" used to leave
the configuration files lying around, but now seems to remove at least
some of them.

One of the consequences of all this is that, after "make clean",
another "make" doesn't rebuild the extensions, because setup.py finds
that the .so files are still there and decides not to rebuild the
missing .o's.

Another consequence is that after "make clobber" you have to rerun the
configure script (or say "make recheck").  This takes almost as long
as the rest of the build...

In other words, "make clean" doesn't go far enough, and "make clobber"
goes too far, for what I seem to want most often (recompile every C
source file).

Can someone suggest a fix?

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


From mal@lemburg.com  Sat Apr 14 17:43:20 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 14 Apr 2001 18:43:20 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
References: <20010413134326-r01010600-bafaee65@213.84.27.177>
Message-ID: <3AD87E28.CCC894AC@lemburg.com>

Just van Rossum wrote:
> 
> M.-A. Lemburg wrote:
> 
> > I don't know why this thread lead to tweaking stdio -- after all
> > we only need a solution for the Python tokenizer and not a general
> > purpose stdio abstraction of text files unless I'm missing something
> > here...
> 
> Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all,
> but then what about all tools that read source files line by line? Eg.
> linecache.py, all IDE's, etc. etc. As Tim wrote a while back:
> 
>   importing-is-only-the-start-of-the-battle
> 
> So no, we don't "only need a solution for the Python tokenizer"...

See... that's why we need a PEP on these things ;-)

Seriously, I thought that you were only talking about being
able to work on Python code from different platforms in a network
(e.g. code is shared by a Windows box and development takes place
on a Mac).

Now it seems that you want to go for the full Monty :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From guido@digicool.com  Sat Apr 14 18:47:51 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 12:47:51 -0500
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
In-Reply-To: Your message of "Sat, 14 Apr 2001 08:59:34 +0800."
 <3AD7A0F6.7673FDD3@per.dem.csiro.au>
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au>
Message-ID: <200104141747.MAA21913@cj20424-a.reston1.va.home.com>

> FreeBSD 4.2-20010225-STABLE, gcc 2.95.2
> 
> ./python Lib/test/test_zipfile.py
> Traceback (most recent call last):
>   File "Lib/test/test_zipfile.py", line 35, in ?
>     zipTest(file, zipfile.ZIP_STORED, writtenData)
>   File "Lib/test/test_zipfile.py", line 18, in zipTest
>     zip.close()
>   File "/home/mark/src/python/CVS/python/dist/src/Lib/zipfile.py", line
> 471, in close
>     self.fp.flush()
> IOError: [Errno 9] Bad file descriptor
> 
> Looks like FreeBSD objects to doing a flush() on a file opened for
> reading. The self.fp.flush() call should probably be part of the
> preceding if-block relating to files opened in "a" or "w' mode.

You're right.  I've fixed this.

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


From nas@python.ca  Sat Apr 14 17:52:45 2001
From: nas@python.ca (Neil Schemenauer)
Date: Sat, 14 Apr 2001 09:52:45 -0700
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 12:27:09PM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>
Message-ID: <20010414095245.A7402@glacier.fnational.com>

Guido van Rossum wrote:
> Can someone suggest a fix?

I think adding something like:

    find . -name '*.so' -exec rm -f {} ';'

to the clean target would work.  You sould remove the Module/*.so
pattern in the clobber target and fix the comments as well.

One more thing Guido, can you touch Include/graminit.h and
Python/graminit.c before making the tarball?  

  Neil


From mal@lemburg.com  Sat Apr 14 18:02:09 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 14 Apr 2001 19:02:09 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
References: <LNBBLJKPBEHFEDALKOLCIECBJMAA.tim.one@home.com>
Message-ID: <3AD88291.8A82378@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > I don't know why this thread lead to tweaking stdio -- after all
> > we only need a solution for the Python tokenizer ...
> 
> [Just]
> > Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is
> > great and all,> but then what about all tools that read source
> > files line by line? ...
> 
> Note that this is why the topic needs a PEP:  nothing here is new; the same
> debates reoccur every time it comes up.

Right.
 
> [Aahz]
> > ...
> > QIO claims that it can be configured to recognize different
> > kinds of line endings.
> 
> It can be, yes, but in the same sense as Awk/Perl paragraph mode:  you can
> tell it to consider any string (not just single character) as meaning "end of
> the line", but it's a *fixed* string per invocation.  What people want *here*
> is more the ability to recognize the regular expression
> 
>     \r\n?|\n
> 
> as ending a line, and QIO can't do that directly (as currently written).  And
> MAL probably wants Unicode line-end detection:
> 
>     http://www.unicode.org/unicode/reports/tr13/

Right ;-)
 
> > QIO is claimed to be 2-3 times faster than Python 1.5.2; don't
> > know how that compares to 2.x.
> 
> The bulk of that was due to QIO avoiding per-character thread locks.  2.1
> avoids them too, so most of QIO's speed advantage should be gone now.  But
> QIO's internals could certainly be faster than they are (this is obscure
> because QIO.readline() has so many optional behaviors that the maze of
> if-tests makes it hard to see the speed-crucial bits; studying Perl's
> line-reading code is a better model, because Perl's speed-crucial inner loop
> has no non-essential operations -- Perl makes the *surrounding* code sort out
> the optional bits, instead of bogging down the loop with them).

Just curious: for the applications which Just has in mind,
reading source code line-by-line is not really needed. Wouldn't
it suffice to read the whole file, split it into lines and then
let the tools process the resulting list of lines ?

Maybe a naive approach, but one which will most certainly work
on all platforms without having to replace stdio...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From just@letterror.com  Sat Apr 14 18:24:44 2001
From: just@letterror.com (Just van Rossum)
Date: Sat, 14 Apr 2001 19:24:44 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line   conversion?
In-Reply-To: <3AD87E28.CCC894AC@lemburg.com>
Message-ID: <20010414192445-r01010600-f8273ce6@213.84.27.177>

M.-A. Lemburg wrote:

> > So no, we don't "only need a solution for the Python tokenizer"...
> 
> See... that's why we need a PEP on these things ;-)

Agreed. I'll try to write one, once I'm feeling better: having the flu doesn't
seem to help focussing on actual content...

Just


From guido@digicool.com  Sat Apr 14 19:38:09 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 13:38:09 -0500
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:52:45 MST."
 <20010414095245.A7402@glacier.fnational.com>
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>
 <20010414095245.A7402@glacier.fnational.com>
Message-ID: <200104141838.NAA23079@cj20424-a.reston1.va.home.com>

> I think adding something like:
> 
>     find . -name '*.so' -exec rm -f {} ';'
> 
> to the clean target would work.  You sould remove the Module/*.so
> pattern in the clobber target and fix the comments as well.

Will do.

> One more thing Guido, can you touch Include/graminit.h and
> Python/graminit.c before making the tarball?  

Why?

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


From just@letterror.com  Sat Apr 14 18:54:54 2001
From: just@letterror.com (Just van Rossum)
Date: Sat, 14 Apr 2001 19:54:54 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line   conversion?
In-Reply-To: <3AD88291.8A82378@lemburg.com>
Message-ID: <20010414195455-r01010600-bf420a02@213.84.27.177>

M.-A. Lemburg wrote:

> Just curious: for the applications which Just has in mind,
> reading source code line-by-line is not really needed. Wouldn't
> it suffice to read the whole file, split it into lines and then
> let the tools process the resulting list of lines ?
> 
> Maybe a naive approach, but one which will most certainly work
> on all platforms without having to replace stdio...

The point is to let existing tools work with all line end conventions *without*
changing the tools. Whether this means replacing stdio I still don't know
<wink>, but it sure means changing the behavior of the Python file object in
text mode.

Just


From paulp@ActiveState.com  Sat Apr 14 19:07:51 2001
From: paulp@ActiveState.com (Paul Prescod)
Date: Sat, 14 Apr 2001 11:07:51 -0700
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au> <200104141747.MAA21913@cj20424-a.reston1.va.home.com>
Message-ID: <3AD891F7.1361C560@ActiveState.com>

Do all of these little tweaks mean that we will have another release
candidate or will we just decide that they are low-risk enough not to
worry about? Ideally, the only change from the relcand to final would be
release notes and version numbers...

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook


From guido@digicool.com  Sat Apr 14 20:41:50 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 14:41:50 -0500
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
In-Reply-To: Your message of "Sat, 14 Apr 2001 11:07:51 MST."
 <3AD891F7.1361C560@ActiveState.com>
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au> <200104141747.MAA21913@cj20424-a.reston1.va.home.com>
 <3AD891F7.1361C560@ActiveState.com>
Message-ID: <200104141941.OAA30229@cj20424-a.reston1.va.home.com>

> Do all of these little tweaks mean that we will have another release
> candidate or will we just decide that they are low-risk enough not to
> worry about? Ideally, the only change from the relcand to final would be
> release notes and version numbers...

I don't think we need another release candidate.

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


From paul@pfdubois.com  Sat Apr 14 19:36:27 2001
From: paul@pfdubois.com (Paul F. Dubois)
Date: Sat, 14 Apr 2001 11:36:27 -0700
Subject: [Python-Dev] 2.1c1 OK with Numeric -- and a testing question
Message-ID: <ADEOIFHFONCLEEPKCACCEECMCIAA.paul@pfdubois.com>

I built Numeric with 2.1c1 (on Windows) and it passes all our tests.

I intend to convert the Numeric tests to use PyUnit at some point. Is there
a recommended example? I converted the MA test suite by just reading the
PyUnit web page and I have the feeling I'm missing something. I made it work
but it wasn't any nicer than my existing test when I got done. (ANYTHING is
more elegant than the existing Numeric test).




From esr@thyrsus.com  Sat Apr 14 19:47:39 2001
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 14:47:39 -0400
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
In-Reply-To: <200104141941.OAA30229@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 02:41:50PM -0500
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au> <200104141747.MAA21913@cj20424-a.reston1.va.home.com> <3AD891F7.1361C560@ActiveState.com> <200104141941.OAA30229@cj20424-a.reston1.va.home.com>
Message-ID: <20010414144739.A11425@thyrsus.com>

Guido van Rossum <guido@digicool.com>:
> > Do all of these little tweaks mean that we will have another release
> > candidate or will we just decide that they are low-risk enough not to
> > worry about? Ideally, the only change from the relcand to final would be
> > release notes and version numbers...
> 
> I don't think we need another release candidate.

I've fixed my loose end.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Good intentions will always be pleaded for every assumption of
authority. It is hardly too strong to say that the Constitution was
made to guard the people against the dangers of good intentions. There
are men in all ages who mean to govern well, but they mean to
govern. They promise to be good masters, but they mean to be masters.
	-- Daniel Webster


From fdrake@beowolf.digicool.com  Sat Apr 14 21:09:33 2001
From: fdrake@beowolf.digicool.com (Fred Drake)
Date: Sat, 14 Apr 2001 16:09:33 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010414200933.0218628A09@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


Final Python 2.1 documentation.



From nas@python.ca  Sat Apr 14 21:18:08 2001
From: nas@python.ca (Neil Schemenauer)
Date: Sat, 14 Apr 2001 13:18:08 -0700
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104141838.NAA23079@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 01:38:09PM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com> <20010414095245.A7402@glacier.fnational.com> <200104141838.NAA23079@cj20424-a.reston1.va.home.com>
Message-ID: <20010414131808.A7702@glacier.fnational.com>

Guido van Rossum wrote:
> > One more thing Guido, can you touch Include/graminit.h and
> > Python/graminit.c before making the tarball?  
> 
> Why?

So that those files are not rebuilt.  If the source directory is
read-only then make will fail to build those files.  Its a very
minor issue.

  Neil


From tim.one@home.com  Sat Apr 14 21:35:58 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 14 Apr 2001 16:35:58 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <200104141421.JAA16441@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com>

[Michael Hudson]
> Maybe modules should be removed from sys.modules when they fail to be
> imported due to an exception?

[Guido]
> This has been suggested before, but *in general* this is not a good
> idea.  For example, you want to debug the remains of the failed
> module.

Ya, I've heard you say something like that before, but haven't understood
what it meant.  That is, I've never had, or been able to picture, a case
where having a module object in an incomplete and unknown state is actually
of use.  OTOH, I've certainly burned my share of time recovering from that
importing a broken module only fails the first time.  It's like Python only
raised an exception the first time somebody tried to open a particular
non-existent file for reading, but the second time it returned a file object
that may or may not fail in use, and may or may not work correctly when it
doesn't fail, depending on what you do with it.

> However, the test suite can easily guard against this, e.g. by
> inserting "import thread" before "import threading" whereever it
> occurs.

So how come a failed attempt to import thread doesn't leave a bogus module
object in sys.modules["thread"] too <0.9 wink>?  This is obscure stuff.  Is
"debugging the remains" of sufficient use to make up for the conceptual
complications?



From guido@digicool.com  Sun Apr 15 01:59:16 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 19:59:16 -0500
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: Your message of "Sat, 14 Apr 2001 16:35:58 -0400."
 <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com>
Message-ID: <200104150059.TAA30951@cj20424-a.reston1.va.home.com>

> [Michael Hudson]
> > Maybe modules should be removed from sys.modules when they fail to be
> > imported due to an exception?
> 
> [Guido]
> > This has been suggested before, but *in general* this is not a good
> > idea.  For example, you want to debug the remains of the failed
> > module.

[Tim]
> Ya, I've heard you say something like that before, but haven't understood
> what it meant.  That is, I've never had, or been able to picture, a case
> where having a module object in an incomplete and unknown state is actually
> of use.  OTOH, I've certainly burned my share of time recovering from that
> importing a broken module only fails the first time.  It's like Python only
> raised an exception the first time somebody tried to open a particular
> non-existent file for reading, but the second time it returned a file object
> that may or may not fail in use, and may or may not work correctly when it
> doesn't fail, depending on what you do with it.

Maybe.  It could be that the deep reason is mostly that the
implementation doesn't have the information available to decide what
to delete.

> > However, the test suite can easily guard against this, e.g. by
> > inserting "import thread" before "import threading" whereever it
> > occurs.
> 
> So how come a failed attempt to import thread doesn't leave a bogus module
> object in sys.modules["thread"] too <0.9 wink>?  This is obscure stuff.  Is
> "debugging the remains" of sufficient use to make up for the conceptual
> complications?

I'll think about this over the weekend.  I know people have tried to
convince me of changing this before, and I've tried to listen, but
I've never changed it, so I guess there must be a good reason.  It's
worth trying to remember what it is!

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


From guido@digicool.com  Sun Apr 15 02:47:22 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 20:47:22 -0500
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:07:29 +0800."
 <3AD7A2D1.B04928AE@per.dem.csiro.au>
References: <3AD7A2D1.B04928AE@per.dem.csiro.au>
Message-ID: <200104150147.UAA31288@cj20424-a.reston1.va.home.com>

> SunOS asafoetida 5.8, gcc 2.95.2
> 
> "make test" fails on running test_asynchat.py for the second time. The
> traceback is:
> 
[...]
> 
> Looks like Solaris takes a while to shut sockets down? (This is not a
> slow box, btw.) Or is there an option to not have the socket linger?

I see.  I've added a call to set the SO_REUSEADDR option in the server
thread.  This solves the problem on the SF compile farm Solaris box.

> Also, test_sunaudiodev fails, since setup.py tests only whether the
> platform is a Sun, not whether there is a /dev/audio as well. Servers
> don't have a /dev/audio. This is clearly a minor nit - I did log a bug
> against this some time ago.

Fred fixed this.

Thanks for these reports!

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


From guido@digicool.com  Sun Apr 15 02:57:00 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 20:57:00 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Sat, 14 Apr 2001 03:58:38 +0300."
 <E14oEOc-0001si-00@darjeeling>
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>
 <E14oEOc-0001si-00@darjeeling>
Message-ID: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>

[Martin]
> > AFAICT, under my patch, when using OpenSSL on a system with EGD, it
> > will do the right thing. On a system with /dev/random, it will produce
> > a runtime warning, then add insecure entropy - in addition to the
> > secure entropy already obtained from /dev/random.
> > 
> > Under what I think is your patch, it will do the right thing on a
> > system with /dev/random. On a system with EGD, it will fail because of
> > the missing entropy.

[Moshe]
> Correct on both. My "worse" is: it would print a warning about using
> an insecure method on systems with /dev/random but without an EGD,
> even though it is secure.

And indeed it does when I tried it on SF's Solaris 8 box, which has
OpenSSL installed and /dev/random.

Even worse (in my view), the error message is as soon as the socket
module is imported!  This is bad, because most uses of socket aren't
interested in its SSl capabilities!

> Note that the EGD stuff is new with 2.1,
> so losing that is not a step backwards from 2.0. Printing a wrong warning
> is a step backwards, so in that sense my patch is more conservative.
>  
> After further contemplation, none of these is a pure win.
> It's up to Guido if he wants to use my patch instead of Martin's
> for 2.1final

I don't like either one.

> *** Modules/socketmodule.c	Sun Mar 18 18:38:50 2001
> --- new	Sat Apr 14 03:53:20 2001
> ***************
> *** 2545,2550 ****
> --- 2545,2551 ----
>   	if (PyDict_SetItemString(d, "SSLType",
>   				 (PyObject *)&SSL_Type) != 0)
>   		return;
> + #if OPENSSL_VERSION_NUMBER < 0x0090510fL

Don't you have this backwards?

>   	if (RAND_status() == 0) {
>   #ifdef USE_EGD
>   		char random_device[MAXPATHLEN+1];
> ***************
> *** 2571,2576 ****
> --- 2572,2578 ----
>   		RAND_seed(random_string, sizeof(random_string));
>   #endif /* USE_EGD */
>   	}
> + #endif /* OPENSSL_VERSION_NUMBER < 0x0090510fL */
>   #endif /* USE_SSL */
>   	PyDict_SetItemString(d, "error", PySocket_Error);
>   	PySocketSock_Type.ob_type = &PyType_Type;

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


From guido@digicool.com  Sun Apr 15 03:17:27 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 21:17:27 -0500
Subject: [Python-Dev] test_fcntl on Solaris 8
Message-ID: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>

While testing Python 2.1 on SF's Solaris 8 box, I noticed that it
hangs forever in test_fcntl, on this line:

  rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata)

Why could this be?  Could it be that the NFS lock server is stuck?

But I could also note that this test is pretty silly.  It has all this
platform-specific cruft to do a locking operation the hard way, while
the fcntl module supplies two operations (flock() and lockf()) that
could be used instead!

(Unfortunately, using lockf() I get the same behavior -- not
surprising, since the C code does the same thing that the Python code
was doing. :-( )

Should I update the test, or declare the machine broken?  (I *think* I
recall that the tests succeeded yesterday.)

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


From m.favas@per.dem.csiro.au  Sun Apr 15 04:18:39 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 11:18:39 +0800
Subject: [Python-Dev] Re: test_fcntl on Solaris 8
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>
Message-ID: <3AD9130F.3986FCDA@per.dem.csiro.au>

On my Solaris 8 box test_fcntl succeeds just fine (just tried it again),
with no hangs or hesitations - on the other hand, it's not using any NFS
filesystems, so that could be the problem with the SF box. So declare
the box broken... 

I'd be inclined to update the test anyway, since most people who want to
lock files will use the supplied flock()/lockf() rather than doing it
the hard way - so if the fcntl test locks files, it should use the
generic locking functions.

Guido van Rossum wrote:
> 
> While testing Python 2.1 on SF's Solaris 8 box, I noticed that it
> hangs forever in test_fcntl, on this line:
> 
>   rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata)
> 
> Why could this be?  Could it be that the NFS lock server is stuck?
> 
> But I could also note that this test is pretty silly.  It has all this
> platform-specific cruft to do a locking operation the hard way, while
> the fcntl module supplies two operations (flock() and lockf()) that
> could be used instead!
> 
> (Unfortunately, using lockf() I get the same behavior -- not
> surprising, since the C code does the same thing that the Python code
> was doing. :-( )
> 
> Should I update the test, or declare the machine broken?  (I *think* I
> recall that the tests succeeded yesterday.)
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From m.favas@per.dem.csiro.au  Sun Apr 15 04:34:46 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 11:34:46 +0800
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
Message-ID: <3AD916D6.49FE7B47@per.dem.csiro.au>

[Guido]
> [Moshe]
>> Correct on both. My "worse" is: it would print a warning about using
>> an insecure method on systems with /dev/random but without an EGD,
>> even though it is secure.

> And indeed it does when I tried it on SF's Solaris 8 box, which has
> OpenSSL installed and /dev/random.

Interesting - there's no /dev/random on my Solaris 8 boxes...

> Even worse (in my view), the error message is as soon as the socket
> module is imported!  This is bad, because most uses of socket aren't
>interested in its SSl capabilities!

Quite agree - I've got OpenSSL on my Tru64 box (no /dev/random either)
and it's annoying to get this warning whenever I "import socket". If the
OpenSSL bits don't themselves warn about insecure methods, I'd prefer if
Python didn't take it upon itself to nag <wink>.

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From guido@digicool.com  Sun Apr 15 05:40:40 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 23:40:40 -0500
Subject: [Python-Dev] Re: test_fcntl on Solaris 8
In-Reply-To: Your message of "Sun, 15 Apr 2001 11:18:39 +0800."
 <3AD9130F.3986FCDA@per.dem.csiro.au>
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>
 <3AD9130F.3986FCDA@per.dem.csiro.au>
Message-ID: <200104150440.XAA31778@cj20424-a.reston1.va.home.com>

> On my Solaris 8 box test_fcntl succeeds just fine (just tried it again),
> with no hangs or hesitations - on the other hand, it's not using any NFS
> filesystems, so that could be the problem with the SF box. So declare
> the box broken... 

Thanks!

> I'd be inclined to update the test anyway, since most people who want to
> lock files will use the supplied flock()/lockf() rather than doing it
> the hard way - so if the fcntl test locks files, it should use the
> generic locking functions.

I agree, but I'd rather do that after 2.1.  Who knows what problem I
might introduce in the test (I really don't know these calls very
well).

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


From m.favas@per.dem.csiro.au  Sun Apr 15 06:15:39 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 13:15:39 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
Message-ID: <3AD92E7B.E6CC7EE7@per.dem.csiro.au>

Further investigations withe current CVS 2.1c1 (and everything compiled
without optimization) on a large multi=processor Irix 6.5 box with SGI's
MIPSpro 7.30 compiler:

The previously reported failure of test_largefile was due to running
"make test" on an NFS-mounted filesystem from a box that didn't support
large files. Works on a local filesystem.

The previously reported failure of test_zlib looks as though it is due
to Irix supplying as standard zlib version 1.0.4, whereas the zlib
module requires at least version 1.1.3. This won't be the only platform
where an incompatible zlib is system-supplied and built by default. An
autoconf test for the right version seems indicated (unless setup.py can
just extract the version string from <wherever>/zlib.h - it's there as
#define ZLIB_VERSION "1.0.4" on Irix, and #define ZLIB_VERSION "1.1.3"
on Solaris 8 (both in /usr/include)).


Tests still failing under Irix:

python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ...
Traceback (most recent call last):
  File "Lib/test/test_locale.py", line 29, in ?
    testformat("%f", 1024, grouping=1, output='1,024.000000')
  File "Lib/test/test_locale.py", line 18, in testformat
    result = locale.format(formatstr, value, grouping = grouping)
  File "/var/tmp/mark/src/Lib/locale.py", line 137, in format
    fields[0],seps=_group(fields[0])
ValueError: unpack sequence of wrong size


-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From guido@digicool.com  Sun Apr 15 07:33:25 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 01:33:25 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Sun, 15 Apr 2001 13:15:39 +0800."
 <3AD92E7B.E6CC7EE7@per.dem.csiro.au>
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au>
Message-ID: <200104150633.BAA02770@cj20424-a.reston1.va.home.com>

[Mark Favas]
> Further investigations withe current CVS 2.1c1 (and everything compiled
> without optimization) on a large multi=processor Irix 6.5 box with SGI's
> MIPSpro 7.30 compiler:
> 
> The previously reported failure of test_largefile was due to running
> "make test" on an NFS-mounted filesystem from a box that didn't support
> large files. Works on a local filesystem.
> 
> The previously reported failure of test_zlib looks as though it is due
> to Irix supplying as standard zlib version 1.0.4, whereas the zlib
> module requires at least version 1.1.3. This won't be the only platform
> where an incompatible zlib is system-supplied and built by default. An
> autoconf test for the right version seems indicated (unless setup.py can
> just extract the version string from <wherever>/zlib.h - it's there as
> #define ZLIB_VERSION "1.0.4" on Irix, and #define ZLIB_VERSION "1.1.3"
> on Solaris 8 (both in /usr/include)).

I'll leave that to Andrew, I have no understanding of setup.py.
(Unfortunately Andrew seems out of town. :-( )

> Tests still failing under Irix:
> 
> python Lib/test/test_locale.py
> '%f' % 1024 =? '1,024.000000' ...
> Traceback (most recent call last):
>   File "Lib/test/test_locale.py", line 29, in ?
>     testformat("%f", 1024, grouping=1, output='1,024.000000')
>   File "Lib/test/test_locale.py", line 18, in testformat
>     result = locale.format(formatstr, value, grouping = grouping)
>   File "/var/tmp/mark/src/Lib/locale.py", line 137, in format
>     fields[0],seps=_group(fields[0])
> ValueError: unpack sequence of wrong size

Can you find out what at this point the value of
localeconv()['grouping'] is?  The only way this can happen, I think,
is for that to be a false value -- then _group() returns a single
string value instead of a tuple.  This seems to be a bug in _group()
-- the only place that uses it (format()) always assumes it returns a
tuple of two elements.

I'm not sure what the intention was...

Martin, can you suggest a way out here?

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


From m.favas@per.dem.csiro.au  Sun Apr 15 06:37:35 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 13:37:35 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
Message-ID: <3AD9339F.44C7FC05@per.dem.csiro.au>

Guido van Rossum wrote:
> 
> > Tests still failing under Irix:
> >
> > python Lib/test/test_locale.py
> > '%f' % 1024 =? '1,024.000000' ...
> > Traceback (most recent call last):
> >   File "Lib/test/test_locale.py", line 29, in ?
> >     testformat("%f", 1024, grouping=1, output='1,024.000000')
> >   File "Lib/test/test_locale.py", line 18, in testformat
> >     result = locale.format(formatstr, value, grouping = grouping)
> >   File "/var/tmp/mark/src/Lib/locale.py", line 137, in format
> >     fields[0],seps=_group(fields[0])
> > ValueError: unpack sequence of wrong size
> 
> Can you find out what at this point the value of
> localeconv()['grouping'] is?  The only way this can happen, I think,
> is for that to be a false value -- then _group() returns a single
> string value instead of a tuple.  This seems to be a bug in _group()
> -- the only place that uses it (format()) always assumes it returns a
> tuple of two elements.

localeconv()['grouping'] is "[]" at this point...

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From pychecker@metaslash.com  Sun Apr 15 08:38:34 2001
From: pychecker@metaslash.com (Neal Norwitz)
Date: Sun, 15 Apr 2001 03:38:34 -0400
Subject: [Python-Dev] Python 2.1 RC - PyChecker
References: <mailman.987196706.7970.python-list@python.org>
Message-ID: <3AD94FFA.7D930EF0@metaslash.com>

I've run the CVS version of PyChecker (http://pychecker.sourceforge.net)
against Python 2.1 RC1.  Below are the real or possible problems I found.

Some of the "not used" could be real errors, most are not.
All "uses named arguments" can be safely ignored.
"No global"s are definitely problems AFAICT (except 1 which can't be reached).

Neal
--

MimeWriter.py:108 Function (addheader) uses named arguments
MimeWriter.py:117 Function (startbody) uses named arguments
StringIO.py:187 Local variable (here) not used
UserString.py:137 Base class (UserString.UserString) __init__() not called
aifc.py:181 Local variable (math) not used
asynchat.py:99 No method (collect_incoming_data) found
asynchat.py:112 No method (found_terminator) found
	(2 methods documented, but should add method and raise exception?)
asyncore.py:155 Local variable (l) not used
audiodev.py:214 No global (BUFFERSIZE) found
bdb.py:220 Local variable (bp) not used
cgi.py:743 Base class (UserDict.UserDict) __init__() not called
cgi.py:843 Local variable (traceback) not used
chunk.py:109 No attribute (chunk_size) found
	(should be chunksize)
fileinput.py:292 Function (input) uses named arguments
getpass.py:29 Local variable (getpass) not used
gopherlib.py:172 Local variable (port) not used
gzip.py:276 Local variable (orig_size) not used
ihooks.py:494 Function (import_it) uses named arguments
ihooks.py:498 Function (import_it) uses named arguments
imaplib.py:1019 No global (j) found
locale.py:273 No global (l) found
	(can't be reach, but could remove last else and always raise error)
mailbox.py:21 No attribute (stop) found
mailbox.py:23 No attribute (start) found
mailbox.py:29 No method (_search_start) found
mailbox.py:34 No method (_search_end) found
	(_search_*() used in subclasses, add method and raise exception?)
mailbox.py:106 No method (_isrealfromline) found
mailbox.py:260 Local variable (time) not used
mhlib.py:651 Local variable (messages) not used
netrc.py:13 No global (file) found
	(should be filename)
nturl2path.py:45 Local variable (string) not used
pstats.py:188 Local variable (std_list) not used
pyclbr.py:206 Local variable (imports) not used
pydoc.py:170 Base class (exceptions.Exception) __init__() not called
rfc822.py:607 Local variable (expectaddrspec) not used
robotparser.py:234 Local variable (sys) not used
sgmllib.py:178 No global (SGMLParserError) found
	(should be SGMLParseError?)
shlex.py:99 Local variable (tok) not used
smtpd.py:312 No global (UnimplementedError) found
smtpd.py:375 Local variable (paths) not used
sndhdr.py:87 Local variable (hdr_size) not used
sndhdr.py:134 Local variable (style) not used
sre_parse.py:286 Local variable (here) not used
threading.py:547 Local variable (random) not used
threading.py:611 Local variable (time) not used
token.py:85 Local variable (string) not used
unittest.py:675 Local variable (opts) not used
urllib.py:1147 Local variable (x) not used
urllib2.py:450 No global (error_302_dict) found
	(needs req.?)
urllib2.py:630 No attribute (parent) found
urllib2.py:1053 No global (OpenerDirectory) found
urlparse.py:58 Local variable (path) not used
webbrowser.py:77 No global (ret) found


From moshez@zadka.site.co.il  Sun Apr 15 12:29:31 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Sun, 15 Apr 2001 14:29:31 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>
References: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>, <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>
 <E14oEOc-0001si-00@darjeeling>
Message-ID: <E14okih-0004J3-00@darjeeling>

On Sat, 14 Apr 2001 20:57:00 -0500, Guido van Rossum <guido@digicool.com> wrote:

> Even worse (in my view), the error message is as soon as the socket
> module is imported!  This is bad, because most uses of socket aren't
> interested in its SSl capabilities!

Yeah, well, for 2.2 I'm planning to have a suggestion for redoing the
SSL support in Python, which is currently brain damaged in many ways,
and this is one.

> I don't like either one.

Mine at least has the property that we're no worse off then 2.0

> > + #if OPENSSL_VERSION_NUMBER < 0x0090510fL
> 
> Don't you have this backwards?

Yes, sorry.

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez@debian.org  |http://www.{python,debian,gnu}.org


From guido@digicool.com  Sun Apr 15 14:34:38 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 08:34:38 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Sun, 15 Apr 2001 14:29:31 +0300."
 <E14okih-0004J3-00@darjeeling>
References: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>, <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling> <E14oEOc-0001si-00@darjeeling>
 <E14okih-0004J3-00@darjeeling>
Message-ID: <200104151334.IAA09030@cj20424-a.reston1.va.home.com>

> > Even worse (in my view), the error message is as soon as the socket
> > module is imported!  This is bad, because most uses of socket aren't
> > interested in its SSl capabilities!
> 
> Yeah, well, for 2.2 I'm planning to have a suggestion for redoing the
> SSL support in Python, which is currently brain damaged in many ways,
> and this is one.

So why even bother adding the EGD support?

> > I don't like either one.
> 
> Mine at least has the property that we're no worse off then 2.0

Except that it still has a chance of issuing a warning!  I'm very
tempted to rip out all code added by your patch.

> > > + #if OPENSSL_VERSION_NUMBER < 0x0090510fL
> > 
> > Don't you have this backwards?
> 
> Yes, sorry.

I've had it.  I'm ripping out that patch.  People who want EGD support
desperate enough can download the patch from SF.

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


From guido@digicool.com  Sun Apr 15 14:48:35 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 08:48:35 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Sun, 15 Apr 2001 13:37:35 +0800."
 <3AD9339F.44C7FC05@per.dem.csiro.au>
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
 <3AD9339F.44C7FC05@per.dem.csiro.au>
Message-ID: <200104151348.IAA09108@cj20424-a.reston1.va.home.com>

> localeconv()['grouping'] is "[]" at this point...

It is looking like either the _locale.c module is not working right or
the platform's implementation of the en_US locals is broken.  I'm
afraid that only you will be able to make the determination. :-(

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


From m.favas@per.dem.csiro.au  Sun Apr 15 14:08:11 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 21:08:11 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
Message-ID: <3AD99D3B.A5441B0B@per.dem.csiro.au>

Guido van Rossum wrote:
> 
> [Mark Favas]
> >
> > The previously reported failure of test_zlib looks as though it is due
> > to Irix supplying as standard zlib version 1.0.4, whereas the zlib
> > module requires at least version 1.1.3. This won't be the only platform
> > where an incompatible zlib is system-supplied and built by default. An
> > autoconf test for the right version seems indicated (unless setup.py can
> > just extract the version string from <wherever>/zlib.h - it's there as
> > #define ZLIB_VERSION "1.0.4" on Irix, and #define ZLIB_VERSION "1.1.3"
> > on Solaris 8 (both in /usr/include)).
> 
> I'll leave that to Andrew, I have no understanding of setup.py.
> (Unfortunately Andrew seems out of town. :-( )

A patch to setup.py that works on the SGI where the version of zlib.h in
/usr/include is too low, and also works on my Tru64 box where the
version in /usr/local/include is just right follows:
(I'll also submit this to sourceforge.)

*** setup.py.orig       Sun Apr 15 20:59:34 2001
--- setup.py    Sun Apr 15 21:00:53 2001
***************
*** 449,457 ****
          # Andrew Kuchling's zlib module.
          # This require zlib 1.1.3 (or later).
          # See http://www.cdrom.com/pub/infozip/zlib/
!         if (self.compiler.find_library_file(lib_dirs, 'z')):
!             exts.append( Extension('zlib', ['zlibmodule.c'],
!                                    libraries = ['z']) )
  
          # Interface to the Expat XML parser
          #
--- 449,471 ----
          # Andrew Kuchling's zlib module.
          # This require zlib 1.1.3 (or later).
          # See http://www.cdrom.com/pub/infozip/zlib/
!         zlib_inc = find_file('zlib.h', [], inc_dirs)
!         if zlib_inc is not None:
!             zlib_h = zlib_inc[0] + '/zlib.h'
!             version = '"0.0.0"'
!             version_req = '"1.1.3"'
!             fp = open(zlib_h)
!             while 1:
!                 line = fp.readline()
!                 if not line:
!                     break
!                 if line.find('#define ZLIB_VERSION', 0) == 0:
!                     version = line.split()[2]
!                     break
!             if version >= version_req:
!                 if (self.compiler.find_library_file(lib_dirs, 'z')):
!                     exts.append( Extension('zlib', ['zlibmodule.c'],
!                                            libraries = ['z']) )
  
          # Interface to the Expat XML parser
          #

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From guido@digicool.com  Sun Apr 15 17:18:46 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 11:18:46 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Sun, 15 Apr 2001 21:08:11 +0800."
 <3AD99D3B.A5441B0B@per.dem.csiro.au>
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
 <3AD99D3B.A5441B0B@per.dem.csiro.au>
Message-ID: <200104151618.LAA10062@cj20424-a.reston1.va.home.com>

> A patch to setup.py that works on the SGI where the version of zlib.h in
> /usr/include is too low, and also works on my Tru64 box where the
> version in /usr/local/include is just right follows:

Thanks, Mark.  It works for me!

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


From thomas@xs4all.net  Sun Apr 15 16:31:08 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 17:31:08 +0200
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <200104150059.TAA30951@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 07:59:16PM -0500
References: <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com> <200104150059.TAA30951@cj20424-a.reston1.va.home.com>
Message-ID: <20010415173108.M2820@xs4all.nl>

On Sat, Apr 14, 2001 at 07:59:16PM -0500, Guido van Rossum wrote:

> [Tim]
> > [..] I've never had, or been able to picture, a case where having a
> > module object in an incomplete and unknown state is actually of use. 
> > OTOH, I've certainly burned my share of time recovering from that
> > importing a broken module only fails the first time.  It's like Python
> > only raised an exception the first time somebody tried to open a
> > particular non-existent file for reading, but the second time it
> > returned a file object that may or may not fail in use, and may or may
> > not work correctly when it doesn't fail, depending on what you do with
> > it.

> Maybe. 

Wouldn't the right place for the half-broken, import-failed module be in the
traceback object ? In fact, isn't it already *in* the traceback object ? :)

> It could be that the deep reason is mostly that the
> implementation doesn't have the information available to decide what
> to delete.

Deep magic can be added. Deep magic should be added, IMHO, unless ...

> I'll think about this over the weekend.  I know people have tried to
> convince me of changing this before, and I've tried to listen, but
> I've never changed it, so I guess there must be a good reason.  It's
> worth trying to remember what it is!

... you come up with a real reason for it to be as it is ;)

Happy-easter-for-those-of-you-with-permanent-'net-connections-*snif*-ly y'rs,
-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas@xs4all.net  Sun Apr 15 16:38:41 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 17:38:41 +0200
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 12:27:09PM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>
Message-ID: <20010415173841.N2820@xs4all.nl>

On Sat, Apr 14, 2001 at 12:27:09PM -0500, Guido van Rossum wrote:

> Another consequence is that after "make clobber" you have to rerun the
> configure script (or say "make recheck").  This takes almost as long
> as the rest of the build...

So don't do that. Run 'config.status' instead: it'll recreate your config
files (Makefile.pre, config.h, Setup.config) from cached info. It won't
rebuild everything, but it rebuilds config.h, which is what 'make clobber'
removes that breaks building.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From guido@digicool.com  Sun Apr 15 17:47:32 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 11:47:32 -0500
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: Your message of "Sun, 15 Apr 2001 17:38:41 +0200."
 <20010415173841.N2820@xs4all.nl>
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>
 <20010415173841.N2820@xs4all.nl>
Message-ID: <200104151647.LAA10237@cj20424-a.reston1.va.home.com>

> > Another consequence is that after "make clobber" you have to rerun the
> > configure script (or say "make recheck").  This takes almost as long
> > as the rest of the build...
> 
> So don't do that. Run 'config.status' instead: it'll recreate your config
> files (Makefile.pre, config.h, Setup.config) from cached info. It won't
> rebuild everything, but it rebuilds config.h, which is what 'make clobber'
> removes that breaks building.

Well, my issue is that before Neil "fixed" the Makefile, after a "make
clobber" a "make" would do the job.  Now, there's a dependency on
config.h but the Makefile doesn't know how to make that file.

Maybe it should.

But I've "fixed" it by adding a line to the clean target that removes
the .so files, so I don't have to use "make clobber".

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


From thomas@xs4all.net  Sun Apr 15 17:03:08 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 18:03:08 +0200
Subject: [Python-Dev] test_fcntl on Solaris 8
In-Reply-To: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 09:17:27PM -0500
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>
Message-ID: <20010415180307.P2820@xs4all.nl>

On Sat, Apr 14, 2001 at 09:17:27PM -0500, Guido van Rossum wrote:

> While testing Python 2.1 on SF's Solaris 8 box, I noticed that it
> hangs forever in test_fcntl, on this line:

>   rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata)

> Why could this be?  Could it be that the NFS lock server is stuck?

It could very well be that. NFS (version 2 or 3) locking is really, really
dumb. Not just the act of locking over NFS, but the whole protocol for
locking over NFS. If you consider that NFS is meant to be stateless, you can
quickly realize how locking (as well as the concept of 'open files' and what
should happen when you delete open files) do not fit well with NFS. There
are some other braindeadisms with NFS locking, though: it's not possible to
break a lock. If a machine is locking a file, and the machine goes down, the
lock stays in effect until the machine is back up. And 'a machine' is
identified with an ipaddress, so if it gets a new IP, tough. If it stays
down indefinately, tough.

And then there's the implementation side. I have yet to find an NFS server
or client that deals sanely with locks either way. Either they're too
lenient (not very often) or too strict, or they just don't talk well with
the other side. If you want to do locking over NFS, don't use lockf or
flock, use the link/stat lock method (see Mailman's LockFile module for a
somewhat expanded implementation of sane locking over NFS.)

On the plus side, there's a lot of work being done on NFSv4, which should
fix almost every design error made in NFSv2/3. Including the locking ;)

In any case, the problem on the SF Solaris box could be one of two things: a
hanging lock, in which case renaming/removing the testfile should fix it, or
a communication problem between the Solaris box and the NFS server. The
latter is pretty likely the case if the NFS server is Linux, which is pretty
likely with Sourceforge. You can doublecheck by using a testfile on another
filesystem, which isn't NFS-mounted (like /tmp.)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From gward@python.net  Sun Apr 15 17:24:29 2001
From: gward@python.net (Greg Ward)
Date: Sun, 15 Apr 2001 12:24:29 -0400
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <3AD7ED4D.58597DFD@darwin.in-berlin.de>; from gherman@darwin.in-berlin.de on Sat, Apr 14, 2001 at 08:25:17AM +0200
References: <3AD7ED4D.58597DFD@darwin.in-berlin.de>
Message-ID: <20010415122429.A539@gerg.ca>

On 14 April 2001, Dinu Gherman said:
> I'd like to support Peter's proposal for having *some* kind 
> of inverse mechanism to string formatting using '%'. Now, that
> doesn't mean anything, of course, but no matter what the syn-
> tax would look like: I'd prefer having that feature over not
> having it and I'll give an example below.

But we already have one: re.match (and friends).  Regexes are vastly
more powerful, predictable, reliable, and (to me at least)
comprehensible than scanf() format strings.  I've never understood how
scanf() works, and I don't see a great burning need to add scanf() to
Python.

Adding syntactic sugar for scanf() in the form of overloading "/" seems
like a *really* bad idea, too.  ("%" is a nice operator because printf()
format strings use "%" a lot, not because formatting a string has
anything remotely to do with modulo arithmetic.)  If scanf() really
needs to be in Python, write Modules/scanfmodule.c, build it by default,
and be done with it.  Or *maybe* make it a string method, if enough
people think it's useful.

        Greg
-- 
Greg Ward - just another Python hacker                  gward@python.net
http://starship.python.net/~gward/
When you make your mark in the world, watch out for guys with erasers.


From thomas@xs4all.net  Sun Apr 15 17:36:43 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 18:36:43 +0200
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104151647.LAA10237@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sun, Apr 15, 2001 at 11:47:32AM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com> <20010415173841.N2820@xs4all.nl> <200104151647.LAA10237@cj20424-a.reston1.va.home.com>
Message-ID: <20010415183642.Q2820@xs4all.nl>

On Sun, Apr 15, 2001 at 11:47:32AM -0500, Guido van Rossum wrote:
> > > Another consequence is that after "make clobber" you have to rerun the
> > > configure script (or say "make recheck").  This takes almost as long
> > > as the rest of the build...
> > 
> > So don't do that. Run 'config.status' instead: it'll recreate your config
> > files (Makefile.pre, config.h, Setup.config) from cached info. It won't
> > rebuild everything, but it rebuilds config.h, which is what 'make clobber'
> > removes that breaks building.

> Well, my issue is that before Neil "fixed" the Makefile, after a "make
> clobber" a "make" would do the job.  Now, there's a dependency on
> config.h but the Makefile doesn't know how to make that file.

I know, I was just pointing out you don't have to wait for 'configure' to do
its uncached magic, even if you lose config.h. Some projects do have a
dependency for 'config.h' that just calls config.status, by the way. (and if
config.status is missing, they just call configure or tell you to run
configure manually.)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From guido@digicool.com  Sun Apr 15 18:45:08 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 12:45:08 -0500
Subject: [Python-Dev] test_fcntl on Solaris 8
In-Reply-To: Your message of "Sun, 15 Apr 2001 18:03:08 +0200."
 <20010415180307.P2820@xs4all.nl>
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>
 <20010415180307.P2820@xs4all.nl>
Message-ID: <200104151745.MAA10389@cj20424-a.reston1.va.home.com>

> In any case, the problem on the SF Solaris box could be one of two things: a
> hanging lock, in which case renaming/removing the testfile should fix it, or
> a communication problem between the Solaris box and the NFS server. The
> latter is pretty likely the case if the NFS server is Linux, which is pretty
> likely with Sourceforge. You can doublecheck by using a testfile on another
> filesystem, which isn't NFS-mounted (like /tmp.)

Thanks.  This makes me feel much better.  The test runs fine with a
test file on /tmp.  Removing the test file doesn't help at all, so I'm
guessing that the communication with the lock server is broken.

I'll remove it from my list of showstopper issues.  This list now
has test_locale on Irix, and the issue with SSL and EGD.  My
prediction: the locale problem on Irix is a platform bug, and I'll
remove the EGD patch altogether from socketmodule.c.

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


From thomas@xs4all.net  Sun Apr 15 19:56:47 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 20:56:47 +0200
Subject: [Python-Dev] 2.1c1 on BSDI
Message-ID: <20010415205647.R2820@xs4all.nl>


For the record :) Python 2.1c1 performs as expected on BSDI 4.1 and 4.0.1.
That is, there are some crashes, but those were there in 2.0 and 1.5.2 as
well, for the most part, and are test-specific errors in general. We've been
using 2.1b2 (actually slightly newer) on development machines, where it is
used for various tools, and I haven't encountered many bugs yet.

BSDI 4.0.1 still needs to disable threads, but that's a platform bug, not a
Python one.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From tim.one@home.com  Sun Apr 15 20:11:30 2001
From: tim.one@home.com (Tim Peters)
Date: Sun, 15 Apr 2001 15:11:30 -0400
Subject: [Python-Dev] Showstopper
Message-ID: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>

We've got a showstopper bug involving gc and dicts.  It's not brand new, but
was probably introduced when we fiddled PyDict_Next() to stop the dict
resizing problems plaguing Jeremy.

Cut to the chase:

1. dict_items() is called.  The dict has 22 of 32 slots filled.

2. PyList_New(22) creates the result list.

3. dict_items() loops through the dict looking for active entries.
   It does *not* use PyDict_Next, but a loop of the form

       	for (i = 0, j = 0; i < mp->ma_size; i++) {

4. When it finds an active entry, it calls PyTuple_New(2) to
   create the entry's (key, value) result tuple.

5. At the end, PyTuple_New() calls PyObject_GC_Init(), which
   calls _PyGC_Insert().

6. _PyGC_Insert() decides it's time for a collection.

7. The dict dict_items() is iterating over (remember step #1 <wink>?)
   is one of the objects gc traverses.  gc dict traversal *does* use
   PyDict_Next.

8. 22 of 32 slots filled is exactly at the dict resize point, so
   the PyDict_Next() invoked by gc traversal grows the dict.

9. So, back to step #1, dict_item()'s

           	for (i = 0, j = 0; i < mp->ma_size; i++) {

   loop now goes up to 64 instead of the original 32, and, because
   of the internal dict reshuffling, *can* (depending on the exact
   data content of the dict) see values again that it already
   saw before the dict got rearranged.

10. As a result, the later

			PyList_SetItem(v, j, item);

   inside the loop can eventually pass values for j too large for
   the list.

11. PyList_SetItem() sets a "list assignment index out of range"
    error string, but nobody pays ttention to that, and dict_items()
    proceeds to trigger the error multiple times.

12. The value returned by dict_items() is wrong, containing
    some duplicate (key, value) pairs, and missing others.

13. The eval loop goes around a few more times, until it finally
    hits a bytecode that notices the pending exception.  Then (I
    finally got lucky here!) IndexError finally pops up on a line
    where an IndexError doesn't make sense.

I have a test case that reliably triggers this bug, but was unable to whittle
it below 100+ Kb of code + data files.  So trust me about the details above
(they're clear enough!).



From mwh21@cam.ac.uk  Sun Apr 15 21:03:10 2001
From: mwh21@cam.ac.uk (Michael Hudson)
Date: Sun, 15 Apr 2001 21:03:10 +0100 (BST)
Subject: [Python-Dev] Showstopper
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>
Message-ID: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>

On Sun, 15 Apr 2001, Tim Peters wrote:

> We've got a showstopper bug involving gc and dicts.  It's not brand
> new, but was probably introduced when we fiddled PyDict_Next() to stop
> the dict resizing problems plaguing Jeremy.

Crap.

Two ideas suggest themselves: (1) don't have the resize check in
PyDict_Next (it could be in PyDict_SetItem instead, though the fact that
this is safe is delicate to say the least) (2) don't use PyDict_Next in
dict_traverse.

OTOH, the GC runs __del__ methods, right?  So what if a __del__ method
mutates the dictionary that .items() is being called on?  If allocating
memory can execute arbitrary Python code, I dread to think how many bugs
of this form are hiding in Python (actually it's only allocating
containers that's the worry, but still...).  On the third hand, I can't
trigger one deliberately, so maybe I'm talking nonsense.

To fix items/keys/values, you could build up the list of tuples first,
check you still have the right amount, then fill them in.

not-sure-this-is-helping-ly y'rs
M.



From nas@python.ca  Sun Apr 15 22:07:30 2001
From: nas@python.ca (Neil Schemenauer)
Date: Sun, 15 Apr 2001 14:07:30 -0700
Subject: [Python-Dev] Showstopper
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>; from tim.one@home.com on Sun, Apr 15, 2001 at 03:11:30PM -0400
References: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>
Message-ID: <20010415140730.B21716@glacier.fnational.com>

Tim Peters wrote:
> I have a test case that reliably triggers this bug, but was unable to whittle
> it below 100+ Kb of code + data files.  So trust me about the details above
> (they're clear enough!).

The details are all to clear to me.  :-( Can you get me the test
case somehow?  I'm thinking about how to fix this right now but I
don't think its going to be easy.

  Neil


From tim.one@home.com  Sun Apr 15 22:17:23 2001
From: tim.one@home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:17:23 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEHLJMAA.tim.one@home.com>

Guido & I talked out A Plan, and he's going to implement it while I take a
nap.  Outline:

1. It sucks that PyDict_Next() can resize a dict.  And while staring
   at all this in the debugger, it was plain appalling that the mere
   act of doing gc ran around turning empty dicts into non-empty
   ones because of it (not a bug, just irksome waste).

2. It sucks that PyDict_SetItem() can resize a dict even when
   the number of active slots doesn't change.

The plan for addressing those:

A. Rip out the PyDict_Next() resizing hack.

B. In PyDict_SetItem(), first look at the number of free slots,
   and resize the dict if it would be impossible to add a new
   active slot (I *suspect* this can be reduced to making a minimal
   dict when the incoming dict is empty).
   Remember the number of used slots.
   Do the insert.
   Look at the number of used slots now:  do "the usual" resize
   logic if and only the number of used slots changed across
   the insert call.

That much should suffice to stop Jeremy's old bugs, and the bug I bumped into
here.

It's not enough, though.  Allocating a tuple (or any other gc'ed type) can
still cause gc to run, then gc can delete __del__-free cycles, then deleting
those can cause objects with __del__ methods to become unreachable too, and
then any Python code whatsoever can run, incl. but not limited to code that
dicts, and also incl. allowing other threads to run.

So code inside dict methods can't assume much of anything across container
allocations, even after fixing all the bugs we've bumped into so far.  So at
least dict_items() and dict_popitem() remain unsafe after these changes,
although we don't have a concrete test case to prove that and it would be
mondo difficult to create one.  Nevertheless, Python users are effective
proof of the million monkeys hypothesis <wink>.  These remaining problems
require case-by-case analysis and rewriting.

could-be-the-biggest-one-line-fix-in-history-ly y'rs  - tim



From guido@digicool.com  Sun Apr 15 23:19:40 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 17:19:40 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 14:07:30 MST."
 <20010415140730.B21716@glacier.fnational.com>
References: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>
 <20010415140730.B21716@glacier.fnational.com>
Message-ID: <200104152219.RAA11099@cj20424-a.reston1.va.home.com>

> Tim Peters wrote:
> > I have a test case that reliably triggers this bug, but was unable to whittle
> > it below 100+ Kb of code + data files.  So trust me about the details above
> > (they're clear enough!).
> 
> The details are all to clear to me.  :-( Can you get me the test
> case somehow?  I'm thinking about how to fix this right now but I
> don't think its going to be easy.

Don't worry, Tim & I have got it all worked out.  I'll explain later.

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


From tim.one@home.com  Sun Apr 15 22:17:30 2001
From: tim.one@home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:17:30 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>

[Guido, see last point, about dict.keys()/.values()]

[Michael Hudson]
> Crap.

An accurate summary <wink>.

> Two ideas suggest themselves: (1) don't have the resize check in
> PyDict_Next (it could be in PyDict_SetItem instead, though the fact
> that this is safe is delicate to say the least) (2) don't use
> PyDict_Next in dict_traverse.

See preceding crossed-in-the-mail msg.

> OTOH, the GC runs __del__ methods, right?  So what if a __del__ method
> mutates the dictionary that .items() is being called on?  If
> allocating memory can execute arbitrary Python code,

Right.

> I dread to think how many bugs of this form are hiding in Python
> (actually it's only allocating containers that's the worry, but
> still...).

I did too at first, but it appears to be tractable:  allocating containers
"in the middle" of something else is actually rare.  OTOH, listobject.c
eventually grew a faux "immutable list type", after an endless sequence of
hacks failed to stop all cases in which list.sort() could be tricked into
blowing up by writing devious comparison functions that mutated the list in
"just the right way" during the sort.  Today you get an exception if you try
to mutate a list while it's being sorted, and that worked great (I confess
I'm much fonder of it than Guido is, though).

I think we can stop disasters in the dict code, but also expect "odd
behavior" will be possible; e.g., that dict.items() may return a list with
duplicate keys if code is insane enough to mutate the dict during a __del__
method (or in another thread:  once we execute __del__, we're executing
Python code, and the eval loop will let other threads in).

> On the third hand, I can't trigger one deliberately, so maybe
> I'm talking nonsense.

I expect these are very difficult to trigger.

> To fix items/keys/values, you could build up the list of tuples first,
> check you still have the right amount, then fill them in.

Yes, that's one of the things Guido intends to do, although we only talked
about dict_items().  keys() and values() don't allocate any tuples.  They do
allocate a result list at the start, but-- sigh! --you're right that
mp->ma_used may change "during" the initial

    v = PyList_New(mp->ma_used);

> not-sure-this-is-helping-ly y'rs

it-was-depressing-so-it-must-be-helpful<wink>-ly y'rs  - tim



From nas@python.ca  Sun Apr 15 22:20:23 2001
From: nas@python.ca (Neil Schemenauer)
Date: Sun, 15 Apr 2001 14:20:23 -0700
Subject: [Python-Dev] Showstopper
In-Reply-To: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>; from mwh21@cam.ac.uk on Sun, Apr 15, 2001 at 09:03:10PM +0100
References: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com> <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>
Message-ID: <20010415142023.C21716@glacier.fnational.com>

Michael Hudson wrote:
> Two ideas suggest themselves: (1) don't have the resize check
> in PyDict_Next (it could be in PyDict_SetItem instead, though
> the fact that this is safe is delicate to say the least) (2)
> don't use PyDict_Next in dict_traverse.

There is a collector lock in gcmodule.  We could expose methods
for locking and unlocking it.  I'm not sure if that's the right
solution though.

> OTOH, the GC runs __del__ methods, right?

Yes.

> If allocating memory can execute arbitrary Python code, I dread
> to think how many bugs of this form are hiding in Python

I think this is the crux of the problem.  There is probably more
code that does not expect that to happen.  We can fix this
problem without too much trouble but how many more hard to find
ones will be left?  Am I being paranoid?

  Neil


From nas@python.ca  Sun Apr 15 22:30:59 2001
From: nas@python.ca (Neil Schemenauer)
Date: Sun, 15 Apr 2001 14:30:59 -0700
Subject: [Python-Dev] Showstopper
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>; from tim.one@home.com on Sun, Apr 15, 2001 at 05:17:30PM -0400
References: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain> <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>
Message-ID: <20010415143059.D21716@glacier.fnational.com>

Tim Peters wrote:
> allocating containers "in the middle" of something else is
> actually rare.

It looks like you and Guido are working on a solution to avoid
doing this.  Wouldn't it be better to change the GC so that it
was okay to do that?  Specifically, I'm thinking of making
collection only happen between opcodes.  Perhaps that is too
large of a change to make before the release.

  Neil


From guido@digicool.com  Sun Apr 15 23:40:13 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 17:40:13 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 14:30:59 MST."
 <20010415143059.D21716@glacier.fnational.com>
References: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain> <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>
 <20010415143059.D21716@glacier.fnational.com>
Message-ID: <200104152240.RAA11336@cj20424-a.reston1.va.home.com>

> Tim Peters wrote:
> > allocating containers "in the middle" of something else is
> > actually rare.
> 
> It looks like you and Guido are working on a solution to avoid
> doing this.  Wouldn't it be better to change the GC so that it
> was okay to do that?  Specifically, I'm thinking of making
> collection only happen between opcodes.  Perhaps that is too
> large of a change to make before the release.
> 
>   Neil

Yes, I'd rather not touch the GC code this late in the game if we can
avoid it.

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


From tim.one@home.com  Sun Apr 15 22:44:42 2001
From: tim.one@home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:44:42 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <20010415142023.C21716@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEHOJMAA.tim.one@home.com>

[Neil Schemenauer]
> ...
> Am I being paranoid?

Yes, but paranoia is the right attitude to have here -- embrace your
paranoia, and celebrate the Holy Adrenalin <wink>.



From tim.one@home.com  Sun Apr 15 22:44:52 2001
From: tim.one@home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:44:52 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <20010415143059.D21716@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEHOJMAA.tim.one@home.com>

[Tim]
> allocating containers "in the middle" of something else is
> actually rare.

[Neil Schemenauer]
> It looks like you and Guido are working on a solution to avoid
> doing this.  Wouldn't it be better to change the GC so that it
> was okay to do that?  Specifically, I'm thinking of making
> collection only happen between opcodes.  Perhaps that is too
> large of a change to make before the release.

Changing PyDict_Next() and PyDict_SetItem() to avoid gratuitous reshuffling
is a worthy goal regardless (merely traversing a dict simply "should not"
resize it, and has caused problems independent of gc), so I'm solidly +1 on
those.

Loops using PyDict_Next() to mutate values of existing keys can also cause
__del__ methods to execute (because of decref'ing the old values), so there
are non-gc vulnerabilities there too we haven't really addressed -- and then
even switching to "between opcodes" gc wouldn't stop the problems unique to
gc (since __del__ methods go back to the eval loop).

But "between opcodes" sounds like a promising idea to me to short-circuit the
mass of other potential problems that can't be triggered by just decref'ing
things.  Where's the PEP <wink>?



From guido@digicool.com  Sun Apr 15 23:51:07 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 17:51:07 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 17:44:52 -0400."
 <LNBBLJKPBEHFEDALKOLCGEHOJMAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCGEHOJMAA.tim.one@home.com>
Message-ID: <200104152251.RAA11485@cj20424-a.reston1.va.home.com>

> Loops using PyDict_Next() to mutate values of existing keys can also
> cause __del__ methods to execute (because of decref'ing the old
> values), so there are non-gc vulnerabilities there too we haven't
> really addressed -- and then even switching to "between opcodes" gc
> wouldn't stop the problems unique to gc (since __del__ methods go
> back to the eval loop).

And it's not just __del__.  Lookup operations can invoke arbitrary
Python code for the key comparison, which could mutate the dict (or
let another thread run that mutates the dict).

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


From guido@digicool.com  Mon Apr 16 00:19:55 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 18:19:55 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 17:17:30 -0400."
 <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>
Message-ID: <200104152319.SAA11860@cj20424-a.reston1.va.home.com>

I've checked in what I think is a complete fix, but I wouldn't mind
some extra eyes -- I'm in a bit of a rush to head out for dinner now.

But Tim, please take a nap first! :-)

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


From guido@digicool.com  Mon Apr 16 00:25:16 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 18:25:16 -0500
Subject: [Python-Dev] 2nd release candidate?
Message-ID: <200104152325.SAA11875@cj20424-a.reston1.va.home.com>

I'd like to issue a 2nd release candidate late tonight, and then
change *nothing* between 2.1c2 and the final release Tuesday.

The only thing I still need to change before making the 2nd release
candidate is to rip out Moshe's EGD patch for the socket module, which
has too many problems IMO.

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


From tim.one@home.com  Mon Apr 16 00:05:25 2001
From: tim.one@home.com (Tim Peters)
Date: Sun, 15 Apr 2001 19:05:25 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <200104152319.SAA11860@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEIBJMAA.tim.one@home.com>

[Guido]
> I've checked in what I think is a complete fix, but I wouldn't mind
> some extra eyes -- I'm in a bit of a rush to head out for dinner now.
>
> But Tim, please take a nap first! :-)

Heh.  I'm working on it.

Initial bleary-eyeballing turned up one vulnerability remaining, in
dict_popitem():   allocating the result tuple *could* conceivably empty the
dict, in which case the search loop will never terminate.  So I'd move the
"empty?" test after the allocation, like so (untested!):

	/* Allocate the result tuple first.  Believe it or not,
	 * this allocation could trigger a garbage collection which
	 * could resize the dict, which would invalidate the pointer
	 * (ep) into the dict calculated below, or clear the dict.
	 * So we have to do this first.
	 */
	res = PyTuple_New(2);
	if (res == NULL)
		return NULL;
	if (mp->ma_used == 0) {
		PyErr_SetString(PyExc_KeyError,
				"popitem(): dictionary is empty");
		Py_DECREF(res);
		return NULL;
	}

In practice (well, mine), .popitem() is never called on an empty dict, so I
don't at all mind allocating a tuple just to throw it away immediately if the
dict is empty.

zzzzzzzzzzzzzingly y'rs  - tim


PS:  Another release candidate is a prudent idea.  I'll be up again in 1.5
hours.



From guido@digicool.com  Mon Apr 16 02:11:05 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 20:11:05 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 19:05:25 -0400."
 <LNBBLJKPBEHFEDALKOLCOEIBJMAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCOEIBJMAA.tim.one@home.com>
Message-ID: <200104160111.UAA12240@cj20424-a.reston1.va.home.com>

> 	/* Allocate the result tuple first.  Believe it or not,
> 	 * this allocation could trigger a garbage collection which
> 	 * could resize the dict, which would invalidate the pointer
> 	 * (ep) into the dict calculated below, or clear the dict.
> 	 * So we have to do this first.
> 	 */
> 	res = PyTuple_New(2);
> 	if (res == NULL)
> 		return NULL;
> 	if (mp->ma_used == 0) {
> 		PyErr_SetString(PyExc_KeyError,
> 				"popitem(): dictionary is empty");
> 		Py_DECREF(res);
> 		return NULL;
> 	}

Good catch -- checked in now!

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


From guido@digicool.com  Mon Apr 16 02:36:26 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 20:36:26 -0500
Subject: [Python-Dev] NO MORE CHECKINS PLEASE
Message-ID: <200104160136.UAA12834@cj20424-a.reston1.va.home.com>

I'm building another release candidate.  Release later tonight.

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


From jafo@tummy.com  Mon Apr 16 01:41:21 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Sun, 15 Apr 2001 18:41:21 -0600
Subject: [Python-Dev] 2.1c1 RPMs (was: Re: ANNOUNCE: A Python 2.1 release candidate!)
In-Reply-To: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Apr 13, 2001 at 05:18:40PM -0500
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>
Message-ID: <20010415184121.A15535@tummy.com>

On Fri, Apr 13, 2001 at 05:18:40PM -0500, Guido van Rossum wrote:
>Python 2.1 is almost ready.  We've built a release candidate -- a
>version that should become the final version, barring any last-minute

I've built a set of RPMs against 2.1c1, they're available at the same
bat-place:

   ftp://ftp.tummy.com/pub/tummy/RPMS/SRPMS/python2-2.1c1-1tummy.src.rpm

and binaries for RedHat/KRUD 7.0 under:

   ftp://ftp.tummy.com/pub/tummy/RPMS/binaries-KRUD-7.0-i386

   python2-2.1c1-1tummy.i386.rpm
   python2-devel-2.1c1-1tummy.i386.rpm
   python2-tkinter-2.1c1-1tummy.i386.rpm

Enjoy,
Sean
-- 
 Program *INTO* a language, not *IN* it.
                 -- David Gries
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python


From guido@python.org  Mon Apr 16 04:44:59 2001
From: guido@python.org (Guido van Rossum)
Date: Sun, 15 Apr 2001 22:44:59 -0500
Subject: [Python-Dev] ANNOUNCE: A *second* Python 2.1 release candidate!
Message-ID: <200104160344.WAA18937@cj20424-a.reston1.va.home.com>

We found and fixed a rare but serious bug in the dictionary code, and
fixed enough small nits to warrant a second release candidate for
Python 2.1 -- the final release is still planned for Tuesday, April
17.

Please download the release candidate and try it on your favorite
platform.  For more info:

    http://www.python.org/2.1/

Enjoy!

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


From m.favas@per.dem.csiro.au  Mon Apr 16 04:02:51 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Mon, 16 Apr 2001 11:02:51 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
 <3AD9339F.44C7FC05@per.dem.csiro.au> <200104151348.IAA09108@cj20424-a.reston1.va.home.com>
Message-ID: <3ADA60DB.25854811@per.dem.csiro.au>

Yes, the SGI appears not to return a grouping ([3, 0] is expected) for
the en_US locale (the rest of it looks OK).

However, there is still a bug in Lib/locale.py - the code currently
tries to allow for the possibility that an empty grouping may be
returned from localeconv() (and there must be some locales where this is
correct):

def _group(s):
    conv=localeconv()
    grouping=conv['grouping']
    if not grouping:return s

The code calling _group() assumes that the object returned will always
be a tuple, and hence the above will cause a traceback when localeconv()
returns an empty grouping. The correct code should be:

def _group(s):
    conv=localeconv()
    grouping=conv['grouping']
    if not grouping:return (s, 0)

test_locale will still fail on the SGI, but now because of a bug in the
platform implementation of the en_US locale, rather than a bug in the
Python locale.py code. It's better than a traceback.

BTW, mail to Martin doesn't seem to be getting through.

Guido van Rossum wrote:
> 
> > localeconv()['grouping'] is "[]" at this point...
> 
> It is looking like either the _locale.c module is not working right or
> the platform's implementation of the en_US locals is broken.  I'm
> afraid that only you will be able to make the determination. :-(
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From pychecker@metaslash.com  Mon Apr 16 15:42:24 2001
From: pychecker@metaslash.com (Neal Norwitz)
Date: Mon, 16 Apr 2001 10:42:24 -0400
Subject: [Python-Dev] Python 2.1 RC1 - PyCheckered Tools
Message-ID: <3ADB04D0.87576CE4@metaslash.com>

Here's the problems I found with PyChecker (http://pychecker.sourceforge.net)
against the Python 2.1 RC1 Tools.

Is there any reason that bgen source is Tools/bgen/bgen?

Neal
--

bgen/bgenOutput.py:87 No global (Error) found
bgen/bgenType.py:30 Invalid arguments to (getargsArgs), got 0, expected 1
bgen/bgenType.py:79 Invalid arguments to (mkvalueArgs), got 0, expected 1
bgen/scantools.py:402 No attribute (comment1) found
bgen/scantools.py:403 No attribute (comment1) found
bgen/scantools.py:404 No attribute (comment2) found
bgen/scantools.py:405 No attribute (comment2) found
bgen/scantools.py:406 No attribute (sym) found
bgen/scantools.py:409 No attribute (head) found
bgen/scantools.py:417 No attribute (sym) found
bgen/scantools.py:426 No attribute (tail) found
bgen/scantools.py:428 No attribute (comment1) found
bgen/scantools.py:429 No attribute (comment1) found
bgen/scantools.py:430 No attribute (comment2) found
bgen/scantools.py:431 No attribute (comment2) found
bgen/scantools.py:436 No attribute (whole) found
bgen/scantools.py:439 No attribute (whole) found
bgen/scantools.py:475 No attribute (asplit) found
bgen/scantools.py:478 No attribute (asplit) found
	(seems most names are xxx_pat, not xxx)

idle/BrowserControl.py:103 No global (_os) found
	(should be os)
idle/BrowserControl.py:149 No global (traceback) found
	(need to import)
idle/SearchDialogBase.py:34 No attribute (default_command) found
idle/SearchDialogBase.py:127 Local variable (f) not used
idle/UndoDelegator.py:29 No method (unbind) found
	(also at lines, 30, 31)
idle/UndoDelegator.py:34 No method (bind) found
	(also at lines, 35, 36)
idle/UndoDelegator.py:139 No method (bell) found
	(also at line 150)
idle/WidgetRedirector.py:33 No global (dict) found
	(should be self.dict)
idle/eventparse.py:1 Imported module (getopt) not used in any function

freeze/checkextensions_win32.py:62 No global (mapFileName) found
	(should be defaultMapName)
freeze/checkextensions_win32.py:121 No global (modules) found
	(should be module)
freeze/makeconfig.py:33 No global (sys) found
freeze/modulefinder.py:67 Local variable (i) not used
	(can do print "  " * self.indent, just a warning)

faqwiz/faqwiz.py:245 No attribute (last_changed_date) found
faqwiz/faqwiz.py:306 No attribute (last_changed_date) found
faqwiz/faqwiz.py:324 Local variable (okprog) not used
faqwiz/faqwiz.py:455 No global (constants) found

pynche/ListViewer.py:165 Local variable (height) not used
pynche/StripViewer.py:294 Local variable (tclcmd) not used
pynche/StripViewer.py:405 No attribute (_StripViewer__gentypevar) found
	(member commented out)
pynche/TextViewer.py:104 Local variable (val) not used

webchecker/webchecker.py:192 Function (load_pickle) uses named arguments


From fdrake@acm.org  Mon Apr 16 16:05:58 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Mon, 16 Apr 2001 11:05:58 -0400 (EDT)
Subject: [Python-Dev] Python 2.1 RC1 - PyCheckered Tools
In-Reply-To: <3ADB04D0.87576CE4@metaslash.com>
References: <3ADB04D0.87576CE4@metaslash.com>
Message-ID: <15067.2646.801856.69602@cj42289-a.reston1.va.home.com>

Neal Norwitz writes:
 > idle/BrowserControl.py:103 No global (_os) found
 > 	(should be os)
 > idle/BrowserControl.py:149 No global (traceback) found
 > 	(need to import)

  The BrowserControl module will be removed for the next release,
since IDLE prefers the webbrowser module, which was added to the
standard library as of Python 2.0.


  -Fred

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



From guido@digicool.com  Mon Apr 16 18:07:36 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 16 Apr 2001 12:07:36 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Mon, 16 Apr 2001 11:02:51 +0800."
 <3ADA60DB.25854811@per.dem.csiro.au>
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com> <3AD9339F.44C7FC05@per.dem.csiro.au> <200104151348.IAA09108@cj20424-a.reston1.va.home.com>
 <3ADA60DB.25854811@per.dem.csiro.au>
Message-ID: <200104161707.MAA21086@cj20424-a.reston1.va.home.com>

> Yes, the SGI appears not to return a grouping ([3, 0] is expected) for
> the en_US locale (the rest of it looks OK).
> 
> However, there is still a bug in Lib/locale.py - the code currently
> tries to allow for the possibility that an empty grouping may be
> returned from localeconv() (and there must be some locales where this is
> correct):
> 
> def _group(s):
>     conv=localeconv()
>     grouping=conv['grouping']
>     if not grouping:return s
> 
> The code calling _group() assumes that the object returned will always
> be a tuple, and hence the above will cause a traceback when localeconv()
> returns an empty grouping. The correct code should be:
> 
> def _group(s):
>     conv=localeconv()
>     grouping=conv['grouping']
>     if not grouping:return (s, 0)
> 
> test_locale will still fail on the SGI, but now because of a bug in the
> platform implementation of the en_US locale, rather than a bug in the
> Python locale.py code. It's better than a traceback.

Thanks.  I've checked this in now.

> BTW, mail to Martin doesn't seem to be getting through.

I think it's his home machine, and I suspect he's taken a long weekend
off (Monday after Easter is a holiday in most European countries).

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


From pychecker@metaslash.com  Mon Apr 16 18:52:25 2001
From: pychecker@metaslash.com (Neal Norwitz)
Date: Mon, 16 Apr 2001 13:52:25 -0400
Subject: [Python-Dev] Python 2.1 RC1 - symtable.py problems
Message-ID: <3ADB3159.476A73CD@metaslash.com>

Sorry, I didn't get this in the first batch.  PyChecker crashed on symtable.py and I didn't fix it until now.

/home/neal/local/lib/python2.1/symtable.py:100 Invalid arguments to (bool), got 0, expected 1
/home/neal/local/lib/python2.1/symtable.py:193 No attribute (flag) found
	(should be __flags?)
/home/neal/local/lib/python2.1/symtable.py:196 No global (DEF_STARSTAR) found
	(should be DEF_DOUBLESTAR?)

Neal


From barry@digicool.com  Mon Apr 16 18:56:06 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Mon, 16 Apr 2001 13:56:06 -0400
Subject: [Python-Dev] Python 2.1 RC1 - PyCheckered Tools
References: <3ADB04D0.87576CE4@metaslash.com>
Message-ID: <15067.12854.219081.458580@anthem.wooz.org>

>>>>> "NN" == Neal Norwitz <neal@metaslash.com> writes:

    | pynche/ListViewer.py:165 Local variable (height) not used
    | pynche/StripViewer.py:294 Local variable (tclcmd) not used
    | pynche/StripViewer.py:405 No attribute (_StripViewer__gentypevar) found
    | 	(member commented out)
    | pynche/TextViewer.py:104 Local variable (val) not used

Thanks.  I've fixed these in my working copy but won't check them in
until Python 2.1 final is out the door.

-Barry


From loewis@informatik.hu-berlin.de  Tue Apr 17 09:34:34 2001
From: loewis@informatik.hu-berlin.de (Martin von Loewis)
Date: Tue, 17 Apr 2001 10:34:34 +0200 (MEST)
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
Message-ID: <200104170834.KAA29092@pandora.informatik.hu-berlin.de>

> def _group(s):
>     conv=localeconv()
>     grouping=conv['grouping']
>     if not grouping:return (s, 0)

Yes, that change is right.

> BTW, mail to Martin doesn't seem to be getting through.

Unfortunately, cs.tu-berlin.de seems to have router problems :-(

Regards,
Martin


From guido@digicool.com  Tue Apr 17 15:29:44 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 09:29:44 -0500
Subject: [Python-Dev] ANNOUNCE: Python 2.1 final release
Message-ID: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>

Yes, the *final* release of Python 2.1 is now available.  Thanks again
for all who helped!  Go here for downloads and information:

    http://www.python.org/2.1/

As a reminder, here's a list of some of the big new features in 2.1
(news since 2.0 was released in October 2000):

- nested scopes and __future__ directives
- rich comparisons and new coercion model
- warnings framework
- new build process (Unix)
- weak references
- function attributes
- unittest and doctest modules for automated testing
- ports to several new platforms, including Cygwin and RISCOS

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


From guido@digicool.com  Tue Apr 17 16:51:16 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 10:51:16 -0500
Subject: [Python-Dev] Python 2.1.1 and 2.2 release planning
Message-ID: <200104171551.KAA28713@cj20424-a.reston1.va.home.com>

Now that 2.1 is out, I've created a CVS branch for the Python 2.1.1
bugfix release.  Its name is "release21-maint" (I had no choice in the
name, I'm mimicking the name that Moshe chose for the 2.0.1 branch).

Anything that should go into 2.1.1 ought to be checked into this
branch as well as into the trunk.  Let's tentatively shoot for a 2.1.1
release about a month for now.  This ought to be a very conservative
bugfix release; the key goal is stability of the 2.1 platform, not
releasing features that missed the 2.1 deadline.

Anything that smells of a feature or a new API (even if it is
introduced to fix a design bug!) ought to go into the trunk, where it
will be released as part of 2.2.  I am aiming for a 2.2 release in
October 2001.

In the future, I'd like to create a branch for each release (alpha,
beta or candidate).  These branches will branch of the trunk just
before the release is planned.  That way, instead of declaring a
checkin moratorium on the trunk, I can create a branch, and checkins
on the trunk won't bother me (or whoever is the release manager).

Thanks to all the last-minute bug reporters and fixers!

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


From pychecker@metaslash.com  Tue Apr 17 17:11:02 2001
From: pychecker@metaslash.com (Neal Norwitz)
Date: Tue, 17 Apr 2001 12:11:02 -0400
Subject: [Python-Dev] PyChecker 0.3 release
Message-ID: <3ADC6B16.8F90B777@metaslash.com>

I have released PyChecker 0.3 to SourceForge.
	Web Page:     http://pychecker.sourceforge.net/
	Project Page: http://sourceforge.net/projects/pychecker/

I'd like to thank everyone for all the feedback so far, it's been great!
In particular, Barry Scott has been very helpful.

The CHANGELOG and current command line options are included below.
The TODO list has gotten longer (see the web page or download).

As always, feedback, suggestions, complaints, etc are encouraged.

Neal
--

Here's the CHANGELOG:

Version 0.3     - 17 April 2001
  * Fix some checker crashes (oops)
  * Add warnings for code complexity (lines/branches/returns per func)
  * Add more configuration options
  * Don't produce spurious warning for:  x(y, { 'a': 'b' })
  * Fix warnings that indicate they are from a base class file,
    rather than real file
  * Fix warnings for **kwArgs not allowed, but using named args
  * Add config option for warning when using attribute as a function
        (off by default, old behaviour was on)

Version 0.2.5   - 12 April 2001
  * Add back support for Python 1.5.2 (again)
        (I sure like 2.0 more with the [ for ] and string methods.)
  * Add new warning for unused local variables
  * Add command line switches


Here's the current list of command line options:

Options:           Change warning for ... [default value]
  -s, --doc          turn off all warnings for no doc strings
  -m, --moduledoc    no module doc strings [on]
  -c, --classdoc     no class doc strings [on]
  -f, --funcdoc      no function/method doc strings [off]

  -i, --import       unused imports [on]
  -l, --local        unused local variables, except tuples [on]
  -t, --tuple        all unused local variables, including tuples [off]
  -v, --var          all unused module variables [off]
  -p, --privatevar   unused private module variables [on]
  -n, --namedargs    functions called with named arguments (like keywords) [on]
  -a, --initattr     Attributes (members) must be defined in __init__() [off]
  -I, --initsubclass Subclass.__init__() not defined [off]
  -A, --callattr     Calling data members as functions [off]

  -b, --blacklist    ignore warnings from the list of modules [['Tkinter']]
  -L, --maxlines     maximum lines in a function [200]
  -B, --maxbranches  maximum branches in a function [50]
  -R, --maxreturns   maximum returns in a function [10]

  -P, --printparse   print internal checker parse structures [off]
  -d, --debug        turn on debugging for checker [off]


From barry@digicool.com  Tue Apr 17 17:23:26 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 12:23:26 -0400
Subject: [Python-Dev] Python 2.1 PEPs
Message-ID: <15068.28158.342537.431634@anthem.wooz.org>

Now that Python 2.1 is officially out the door, it's time to do some
spring cleaning on the PEPs.  I'm currently processing the latest
batch of PEP requests, and I'm going to create a Python 2.2 release
schedule PEP.  It's time to make an update pass through PEP 0 too.

Here are the following PEPs that are marked as "Active for Python
2.1", along with a small commentary about changing their status.  PEP
authors, please take a close look at your Python 2.1 PEPs and make any
final revisions that are necessary.  Let me know if you disagree with
my proposed disposition of the PEP.  Note: individual PEP owners
should update their own PEPs; I will take care of noodging you and
updating PEP 0.  If you are unable to make commits to the PEPs, send
the updated text to me and I'll commit them.

 I    42  pep-0042.txt  Small Feature Requests                 Hylton

The perennial PEP, this will be moved to the "Python 2.2 Current"
category.  It should be updated if necessary.

 S   205  pep-0205.txt  Weak References                        Drake

Fred should do an update pass to reflect Python 2.1 Reality
(e.g. weakref.mapping()).  This PEP should then be marked as Final and
moved to the Finished PEPs category.

  I   226  pep-0226.txt  Python 2.1 Release Schedule            Hylton

This PEP should get a final pass (no need for "tentative"s any more!),
marked as Final and moved to the Finished category.

  S   227  pep-0227.txt  Statically Nested Scopes               Hylton

Jeremy, please make sure this is up-to-date w.r.t. Python 2.1 Reality,
then mark it as Final and I'll move it to the Finished category.

  S   229  pep-0229.txt  Using Distutils to Build Python        Kuchling

Andrew, same deal with this PEP...

  S   233  pep-0233.txt  Python Online Help                     Prescod

What is up with this PEP?  Progress on this seems to have stalled, so
I propose marking it "Deferred" and moving it out of the active PEP
category (to where, I'm not yet sure).

  S   235  pep-0235.txt  Import on Case-Insensitive Platforms   Peters

I think this one's done, so it should be marked as Final and moved to
the Finished PEPs category.  Tim should make any final edits
necessary.

  S   236  pep-0236.txt  Back to the __future__                 Peters

Same for this one, Tim...

  S   243  pep-0243.txt  Module Repository Upload Mechanism     Reifschneider

This isn't strictly tied to the Python 2.1 release, so I propose to
simply shuffle it over to the "Active for Python 2.2" category.

Cheers,
-Barry


From guido@digicool.com  Tue Apr 17 17:37:25 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 12:37:25 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 12:23:26 EDT."
 <15068.28158.342537.431634@anthem.wooz.org>
References: <15068.28158.342537.431634@anthem.wooz.org>
Message-ID: <200104171637.f3HGbPg32707@odiug.digicool.com>

>   I   226  pep-0226.txt  Python 2.1 Release Schedule            Hylton
> 
> This PEP should get a final pass (no need for "tentative"s any more!),
> marked as Final and moved to the Finished category.

Could we recycle this PEP number for the 2.1.1 release schedule (see
my previous post here)?  That seems easier than having a new PEP for
each micro-release.

>   S   227  pep-0227.txt  Statically Nested Scopes               Hylton
> 
> Jeremy, please make sure this is up-to-date w.r.t. Python 2.1 Reality,
> then mark it as Final and I'll move it to the Finished category.

I have promised Jeremy a bunch of updates to this.  I'll get on it.

>   S   229  pep-0229.txt  Using Distutils to Build Python        Kuchling
> 
> Andrew, same deal with this PEP...
> 
>   S   233  pep-0233.txt  Python Online Help                     Prescod
> 
> What is up with this PEP?  Progress on this seems to have stalled, so
> I propose marking it "Deferred" and moving it out of the active PEP
> category (to where, I'm not yet sure).

Superseded by pydoc, I imagine.  Working code beats ambitious plans
every time :-)

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


From paulp@ActiveState.com  Tue Apr 17 17:58:43 2001
From: paulp@ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 09:58:43 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
Message-ID: <3ADC7643.9AF12AB3@ActiveState.com>

"Barry A. Warsaw" wrote:
> 
>...
> 
>   S   233  pep-0233.txt  Python Online Help                     Prescod
> 
> What is up with this PEP?  Progress on this seems to have stalled, so
> I propose marking it "Deferred" and moving it out of the active PEP
> category (to where, I'm not yet sure).

Ping asked to take over the code because he wanted to do it with Pydoc.
He didn't do the online help part. I'm not sure if he thought I was
going to do that part or if he just didn't get to it. Either way, it is
less than a weekend's work to add pydoc to the interactive shell (and
thus make it "online help") so I can do it in the next few weeks.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook


From guido@digicool.com  Tue Apr 17 17:59:29 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 12:59:29 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 09:58:43 PDT."
 <3ADC7643.9AF12AB3@ActiveState.com>
References: <15068.28158.342537.431634@anthem.wooz.org>
 <3ADC7643.9AF12AB3@ActiveState.com>
Message-ID: <200104171659.f3HGxTa00465@odiug.digicool.com>

> Ping asked to take over the code because he wanted to do it with Pydoc.
> He didn't do the online help part. I'm not sure if he thought I was
> going to do that part or if he just didn't get to it. Either way, it is
> less than a weekend's work to add pydoc to the interactive shell (and
> thus make it "online help") so I can do it in the next few weeks.

Actually, "from pydoc import help" already works; after that you can
type "help" or "help(module)" etc.  Or is "online help" more than
that?

Ping pointed out (in private email) that adding pydoc.help to
__builtin__ in site.py is the wrong thing to do because pydoc is large
and it would slow down startup too much.  He recommended to add a
small bootstrap function instead that imports and invokes pydoc.help
instead.

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


From barry@digicool.com  Tue Apr 17 18:06:18 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 13:06:18 -0400
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
 <200104171637.f3HGbPg32707@odiug.digicool.com>
Message-ID: <15068.30730.709186.27733@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido@digicool.com> writes:

    GvR> Could we recycle this PEP number for the 2.1.1 release
    GvR> schedule (see my previous post here)?  That seems easier than
    GvR> having a new PEP for each micro-release.

PEP numbers are a plentiful resource!  I'd prefer to give it a new PEP
number.

    >> S 227 pep-0227.txt Statically Nested Scopes Hylton

    GvR> I have promised Jeremy a bunch of updates to this.  I'll get
    GvR> on it.

Excellent, thanks.

    GvR> Superseded by pydoc, I imagine.  Working code beats ambitious
    GvR> plans every time :-)

>>>>> "PP" == Paul Prescod <paulp@ActiveState.com> writes:

    PP> Ping asked to take over the code because he wanted to do it
    PP> with Pydoc.  He didn't do the online help part. I'm not sure
    PP> if he thought I was going to do that part or if he just didn't
    PP> get to it. Either way, it is less than a weekend's work to add
    PP> pydoc to the interactive shell (and thus make it "online
    PP> help") so I can do it in the next few weeks.

    GvR> Actually, "from pydoc import help" already works; after that
    GvR> you can type "help" or "help(module)" etc.  Or is "online
    GvR> help" more than that?

So Paul, what should be done about PEP 233?  Move it to "active for
Python 2.2"?

-Barry


From paulp@ActiveState.com  Tue Apr 17 18:28:15 2001
From: paulp@ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 10:28:15 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
 <3ADC7643.9AF12AB3@ActiveState.com> <200104171659.f3HGxTa00465@odiug.digicool.com>
Message-ID: <3ADC7D2F.F0096D9F@ActiveState.com>

Guido van Rossum wrote:
> 
>...
> 
> Actually, "from pydoc import help" already works; after that you can
> type "help" or "help(module)" etc.  Or is "online help" more than
> that?

No, that looks like it is basically what you want. I didn't envision
help as a totally separate "mode" but I'm not picky.

> Ping pointed out (in private email) that adding pydoc.help to
> __builtin__ in site.py is the wrong thing to do because pydoc is large
> and it would slow down startup too much.  He recommended to add a
> small bootstrap function instead that imports and invokes pydoc.help
> instead.

Right, but the bootstrap was always part of the proposal! Now that
you've pointed out the impressive online help facility in pydoc it seems
that the only thing we need to make it exactly what I envisioned is a
few lines of code. I'm sorry I didn't figure that out last week!

All it would take now is

class help:
   def __repr__(self):
      import pydoc
      __builtins__.help = pydoc.help
      repr(__builtins__.help)

But hindsight is 20/20.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook


From thomas@xs4all.net  Tue Apr 17 18:50:41 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Tue, 17 Apr 2001 19:50:41 +0200
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <3ADC7D2F.F0096D9F@ActiveState.com>; from paulp@ActiveState.com on Tue, Apr 17, 2001 at 10:28:15AM -0700
References: <15068.28158.342537.431634@anthem.wooz.org> <3ADC7643.9AF12AB3@ActiveState.com> <200104171659.f3HGxTa00465@odiug.digicool.com> <3ADC7D2F.F0096D9F@ActiveState.com>
Message-ID: <20010417195041.T2820@xs4all.nl>

On Tue, Apr 17, 2001 at 10:28:15AM -0700, Paul Prescod wrote:

> All it would take now is
> 
> class help:
>    def __repr__(self):
>       import pydoc
>       __builtins__.help = pydoc.help
>       repr(__builtins__.help)

> But hindsight is 20/20.

You realize this isn't going to work, right ? The 'help' class will shadow
the 'help' builtin.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From paulp@ActiveState.com  Tue Apr 17 19:33:56 2001
From: paulp@ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 11:33:56 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
 <200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org>
Message-ID: <3ADC8C94.548514E3@ActiveState.com>

"Barry A. Warsaw" wrote:
> 
> 
> So Paul, what should be done about PEP 233?  Move it to "active for
> Python 2.2"?

Move it to "implemented." We can haggle about details but most of the
features I'd hoped for are implemented thanks to Ping!

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook


From ping@lfw.org  Tue Apr 17 20:13:36 2001
From: ping@lfw.org (Ka-Ping Yee)
Date: Tue, 17 Apr 2001 12:13:36 -0700 (PDT)
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <3ADC7D2F.F0096D9F@ActiveState.com>
Message-ID: <Pine.LNX.4.10.10104171207230.454-100000@skuld.kingmanhall.org>

On Tue, 17 Apr 2001, Paul Prescod wrote:
> Right, but the bootstrap was always part of the proposal!

Right.

> All it would take now is
> 
> class help:
>    def __repr__(self):
>       import pydoc
>       __builtins__.help = pydoc.help
>       repr(__builtins__.help)

Yes, pretty much.  I suggested something to that effect on Friday
night.  (Guido decided it was too late in the game to change site.py
at that point.)  Here was my proposed addition to site.py:

    # Define the built-in object "help" to provide interactive help.
    class Helper:
        def __repr__(self):
            import inspect
            if inspect.stack()[1][3] == '?': # not called from a function
                self()
                return ''
            return '<Helper instance>'
        def __call__(self, arg=None):
            import pydoc
            pydoc.help(arg)
    __builtin__.help = Helper()

Why the strange check involving inspect.stack()?
inspect.stack()[1][3] is the co_name of the parent frame.
If we check that the __repr__ is not being requested by a
function call, everything works perfectly in IDLE as well
as the plain interpreter, and the helper object is still safe
to pass around.  Nothing breaks even if you say help(help).

The above few lines are a reasonable addition to sitecustomize.py
if you happen to be setting up a local installation of Python.


-- ?!ng

"If I have seen farther than others, it is because I was standing on a
really big heap of midgets."
    -- K. Eric Drexler






From paulp@ActiveState.com  Tue Apr 17 19:58:42 2001
From: paulp@ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 11:58:42 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org> <3ADC7643.9AF12AB3@ActiveState.com> <200104171659.f3HGxTa00465@odiug.digicool.com> <3ADC7D2F.F0096D9F@ActiveState.com> <20010417195041.T2820@xs4all.nl>
Message-ID: <3ADC9262.928F1398@ActiveState.com>

Thomas Wouters wrote:
> 
> On Tue, Apr 17, 2001 at 10:28:15AM -0700, Paul Prescod wrote:
> 
> > All it would take now is
> >
> > class help:
> >    def __repr__(self):
> >       import pydoc
> >       __builtins__.help = pydoc.help
> >       repr(__builtins__.help)
> 
> > But hindsight is 20/20.
> 
> You realize this isn't going to work, right ? The 'help' class will shadow
> the 'help' builtin.

We do not have to call the class "help" nor to define it in the __main__
or __builtins__ context. Or were you getting at something deeper?

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook


From Jason.Tishler@dothill.com  Tue Apr 17 20:12:19 2001
From: Jason.Tishler@dothill.com (Jason Tishler)
Date: Tue, 17 Apr 2001 15:12:19 -0400
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 17, 2001 at 09:29:44AM -0500
References: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>
Message-ID: <20010417151219.T275@dothill.com>

On Tue, Apr 17, 2001 at 09:29:44AM -0500, Guido van Rossum wrote:
> - ports to several new platforms, including Cygwin and RISCOS

I have contributed Python to the standard Cygwin distribution.  Cygwin
Python is located in the contrib/python directory on the Cygwin mirrors.
Cygwin's setup.exe will automatically install Cygwin Python the next
time one installs or updates from a mirror.

If interested, see the following for a copy of the announcement:

    http://www.cygwin.com/ml/cygwin/2001-04/msg01074.html

I kindly request that people post to python-list@python.org or
cygwin@sources.redhat.com as appropriate instead of emailing me
directly.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com


From dubois1@llnl.gov  Tue Apr 17 20:05:25 2001
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Tue, 17 Apr 2001 12:05:25 -0700
Subject: [Python-Dev] PEP 0242 Numeric kinds updated
Message-ID: <01041712272103.11576@almanac>

I have updated the text of PEP 0242 about Numeric kinds. This proposal is=
 now
complete and a reference implementation has been created.=20

See http://python.sourceforge.net/peps/pep-0242.html

As part of this reference implementation I was considering adding a 32-bi=
t
float scalar floating-point object to the kinds module. This object would=
 then
be accessible via the kinds module although there would be no correspondi=
ng
literal notation. For example:

import kinds
f loat32=3D kinds.float_kind(5,30)
x =3D float32(3.14159)

would on all platforms I know about create x as such an object, which may=
 be of
interest to those attempting to conserve space in certain applications of
Numeric.

Comments on the PEP and this point are requested.




From martin@loewis.home.cs.tu-berlin.de  Tue Apr 17 20:27:13 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 17 Apr 2001 21:27:13 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104150157.UAA31334@cj20424-a.reston1.va.home.com> (message
 from Guido van Rossum on Sat, 14 Apr 2001 20:57:00 -0500)
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>
 <E14oEOc-0001si-00@darjeeling> <200104150157.UAA31334@cj20424-a.reston1.va.home.com>
Message-ID: <200104171927.f3HJRDP01133@mira.informatik.hu-berlin.de>

> And indeed it does when I tried it on SF's Solaris 8 box, which has
> OpenSSL installed and /dev/random.

This has caused Moshe's curiosity, and mine, as Solaris 8,
out-of-the-box, does not offer a /dev/random. I found two options:
There is a third-party patch:

http://www.cosy.sbg.ac.at/~andi/

which apparently works for all Solaris versions out there.

There is also a Sun patch, 105710-01, which supposedly uses a
user-space demon (just as EGD), see

http://devrandom.net/lists/archives/2000/11/OpenSSL-Users/0244.html

As explained, this is part of the SUNWski package.

Are you using one of these methods, or is there another option for
getting a 'true' /dev/random?

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Tue Apr 17 20:29:28 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 17 Apr 2001 21:29:28 +0200
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: <200104150633.BAA02770@cj20424-a.reston1.va.home.com> (message
 from Guido van Rossum on Sun, 15 Apr 2001 01:33:25 -0500)
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
Message-ID: <200104171929.f3HJTSi01162@mira.informatik.hu-berlin.de>

> I'm not sure what the intention was...
> 
> Martin, can you suggest a way out here?

In addition to the patch that already was applied, the test case can
be made more robust, by checking whether the en_US locale has the
right grouping value (and either fail or accept different results if
it doesn't).

Regards,
Martin


From guido@digicool.com  Tue Apr 17 23:14:27 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:14:27 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Tue, 17 Apr 2001 21:27:13 +0200."
 <200104171927.f3HJRDP01133@mira.informatik.hu-berlin.de>
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling> <E14oEOc-0001si-00@darjeeling> <200104150157.UAA31334@cj20424-a.reston1.va.home.com>
 <200104171927.f3HJRDP01133@mira.informatik.hu-berlin.de>
Message-ID: <200104172214.RAA29373@cj20424-a.reston1.va.home.com>

[I wrote]
> > And indeed it does when I tried it on SF's Solaris 8 box, which has
> > OpenSSL installed and /dev/random.

[Martin replied]
> This has caused Moshe's curiosity, and mine, as Solaris 8,
> out-of-the-box, does not offer a /dev/random. I found two options:
> There is a third-party patch:
> 
> http://www.cosy.sbg.ac.at/~andi/
> 
> which apparently works for all Solaris versions out there.
> 
> There is also a Sun patch, 105710-01, which supposedly uses a
> user-space demon (just as EGD), see
> 
> http://devrandom.net/lists/archives/2000/11/OpenSSL-Users/0244.html
> 
> As explained, this is part of the SUNWski package.
> 
> Are you using one of these methods, or is there another option for
> getting a 'true' /dev/random?

Sorry, I must've confused myself.  I was logged in on several
different SF CF hosts, and now I can't find a /dev/random on its
Solaris host, so I presume that it was never there and that I saw it
on one of the other hosts there.

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


From guido@digicool.com  Tue Apr 17 23:17:45 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:17:45 -0500
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: Your message of "Tue, 17 Apr 2001 15:12:19 -0400."
 <20010417151219.T275@dothill.com>
References: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>
 <20010417151219.T275@dothill.com>
Message-ID: <200104172217.RAA29433@cj20424-a.reston1.va.home.com>

> I have contributed Python to the standard Cygwin distribution.  Cygwin
> Python is located in the contrib/python directory on the Cygwin mirrors.
> Cygwin's setup.exe will automatically install Cygwin Python the next
> time one installs or updates from a mirror.
> 
> If interested, see the following for a copy of the announcement:
> 
>     http://www.cygwin.com/ml/cygwin/2001-04/msg01074.html

Thanks, Jason!!!  Your efforts are much appreciated.  Keep up the good
work!

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


From guido@digicool.com  Tue Apr 17 23:20:26 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:20:26 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 12:13:36 MST."
 <Pine.LNX.4.10.10104171207230.454-100000@skuld.kingmanhall.org>
References: <Pine.LNX.4.10.10104171207230.454-100000@skuld.kingmanhall.org>
Message-ID: <200104172220.RAA29454@cj20424-a.reston1.va.home.com>

> Why the strange check involving inspect.stack()?
> inspect.stack()[1][3] is the co_name of the parent frame.
> If we check that the __repr__ is not being requested by a
> function call, everything works perfectly in IDLE as well
> as the plain interpreter, and the helper object is still safe
> to pass around.  Nothing breaks even if you say help(help).

This is one of the reasons why I didn't want to add this to the 2.1
release at such a late point.  I have no easy way to verify that this
is always true, and in fact I have no idea what inspect.stack()[1][3]
means. :-(

I just add "from pydoc import help" to my $PYTHONSTARTUP file.

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


From guido@digicool.com  Tue Apr 17 23:23:20 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:23:20 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 13:06:18 -0400."
 <15068.30730.709186.27733@anthem.wooz.org>
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com>
 <15068.30730.709186.27733@anthem.wooz.org>
Message-ID: <200104172223.RAA29490@cj20424-a.reston1.va.home.com>

>     GvR> Could we recycle this PEP number for the 2.1.1 release
>     GvR> schedule (see my previous post here)?  That seems easier than
>     GvR> having a new PEP for each micro-release.
> 
> PEP numbers are a plentiful resource!  I'd prefer to give it a new PEP
> number.

One day I'm going to argue that anything limited to 4 digits can't
possibly be called "plentiful", but not this millennium. :-)

I didn't mean to save a PEP number -- I just meant to keep the 2.1
followup releases together.  I explained this to Barry over lunch and
he agrees now.

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


From barry@digicool.com  Tue Apr 17 23:16:08 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 18:16:08 -0400
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
 <200104171637.f3HGbPg32707@odiug.digicool.com>
 <15068.30730.709186.27733@anthem.wooz.org>
 <200104172223.RAA29490@cj20424-a.reston1.va.home.com>
Message-ID: <15068.49320.780995.520582@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido@digicool.com> writes:

    GvR> One day I'm going to argue that anything limited to 4 digits
    GvR> can't possibly be called "plentiful", but not this
    GvR> millennium. :-)

Just as plentiful as 32-bit IP addresses, oil reserves, and 640KB of
main memory... oh wait. :)

    GvR> I didn't mean to save a PEP number -- I just meant to keep
    GvR> the 2.1 followup releases together.  I explained this to
    GvR> Barry over lunch and he agrees now.

Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
PEP 226.

-Barry


From barry@digicool.com  Tue Apr 17 23:17:34 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 18:17:34 -0400
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
 <200104171637.f3HGbPg32707@odiug.digicool.com>
 <15068.30730.709186.27733@anthem.wooz.org>
 <3ADC8C94.548514E3@ActiveState.com>
Message-ID: <15068.49406.441111.15203@anthem.wooz.org>

>>>>> "PP" == Paul Prescod <paulp@ActiveState.com> writes:

    >>   So Paul, what should be done about PEP 233?  Move it to
    >> "active for Python 2.2"?

    PP> Move it to "implemented." We can haggle about details but most
    PP> of the features I'd hoped for are implemented thanks to Ping!

Can you please update the text of PEP 233 to reflect Current (or
near-Current) Reality?

Thanks,
-Barry


From guido@digicool.com  Wed Apr 18 00:49:07 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 18:49:07 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 18:16:08 -0400."
 <15068.49320.780995.520582@anthem.wooz.org>
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org> <200104172223.RAA29490@cj20424-a.reston1.va.home.com>
 <15068.49320.780995.520582@anthem.wooz.org>
Message-ID: <200104172349.SAA00877@cj20424-a.reston1.va.home.com>

>     GvR> I didn't mean to save a PEP number -- I just meant to keep
>     GvR> the 2.1 followup releases together.  I explained this to
>     GvR> Barry over lunch and he agrees now.
> 
> Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
> PEP 226.

OK.  So we need a 2.2.1 Czar.  Any volunteers?

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


From jafo@tummy.com  Wed Apr 18 03:03:52 2001
From: jafo@tummy.com (Sean Reifschneider)
Date: Tue, 17 Apr 2001 20:03:52 -0600
Subject: [Python-Dev] Re: ANNOUNCE: Python 2.1 final release
In-Reply-To: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 17, 2001 at 09:29:44AM -0500
References: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>
Message-ID: <20010417200352.A28871@tummy.com>

On Tue, Apr 17, 2001 at 09:29:44AM -0500, Guido van Rossum wrote:
>Yes, the *final* release of Python 2.1 is now available.  Thanks again

I've updated my set of RPMs against 2.1.  I've similarly upgraded my 2.1
beta announcement to 2.1 final, and am including it below.  Changes in this
version are:

   Upgrade to 2.1 final.
   Binary and package name is "python2" by default.  Comment out the first
         (non-comment) line of the .spec file to build "python".
   Fixes the path to python2 in pydoc based on the above.
   Uses "--with-pymalloc" when configuring.
   Included Tony Seward's patch to fix the expat module's header path.
   Split out devel and tkinter packages.

Enjoy,
Sean
======================
Shy of RPMs because of library or other dependancy problems with most of
the RPMs you pick up?  The cure, in my experience is to pick up an SRPM.
All you need to do to build a binary package tailored to your system is run
"rpm --rebuild <packagename>.src.rpm".

The Source RPM and binaries for RedHat and KRUD 7.0 are at:

   ftp://ftp.tummy.com/pub/tummy/RPMS/SRPMS/python2-2.1-1tummy.src.rpm

   ftp://ftp.tummy.com/pub/tummy/RPMS/binaries-KRUD-7.0-i386/

You'll also need the following to build the SRPMSs:

   ftp://ftp.tummy.com/pub/tummy/RPMS/SRPMS/expat-1.1-3tummy.src.rpm

(Note, KRUD is our RedHat-based distribution with all errata applied.
Binaries should work on a stock RedHat 7.0 system, particularly if you have
the errata applied).

Again, this one builds the executable as "python2", and can be installed
along-side your normal Python on the system.  Want to check out a great new
feature?  Type "pydoc string" or "pydoc -g" from your shell.

Download the SRPM from above, and most users can install a binary built
against exactly the set of packages on their system by doing:

   rpm --rebuild expat-1.1-3tummy.src.rpm
   rpm -i /usr/src/redhat/RPMS/i386/expat*-1.1-3tummy.i386.rpm
   rpm --rebuild python-2.1b2-1tummy.src.rpm
   rpm -i /usr/src/redhat/RPMS/i386/python*2.1b1-1tummy.i386.rpm

Enjoy,
Sean
-- 
 The structure of a system reflects the structure of the organization that
 built it.  -- Richard E. Fairley
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python


From ping@lfw.org  Wed Apr 18 00:04:53 2001
From: ping@lfw.org (Ka-Ping Yee)
Date: Tue, 17 Apr 2001 16:04:53 -0700 (PDT)
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <200104172220.RAA29454@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org>

On Tue, 17 Apr 2001, Guido van Rossum wrote:
> This is one of the reasons why I didn't want to add this to the 2.1
> release at such a late point.  I have no easy way to verify that this
> is always true, and in fact I have no idea what inspect.stack()[1][3]
> means. :-(

Would you have preferred to write

    sys._getframe().f_back.f_code.co_name

?  It's the same thing.


-- ?!ng

"If I have seen farther than others, it is because I was standing on a
really big heap of midgets."
    -- K. Eric Drexler



From guido@digicool.com  Wed Apr 18 07:01:57 2001
From: guido@digicool.com (Guido van Rossum)
Date: Wed, 18 Apr 2001 01:01:57 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 16:04:53 MST."
 <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org>
References: <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org>
Message-ID: <200104180601.BAA13715@cj20424-a.reston1.va.home.com>

> On Tue, 17 Apr 2001, Guido van Rossum wrote:
> > This is one of the reasons why I didn't want to add this to the 2.1
> > release at such a late point.  I have no easy way to verify that this
> > is always true, and in fact I have no idea what inspect.stack()[1][3]
> > means. :-(
> 
> Would you have preferred to write
> 
>     sys._getframe().f_back.f_code.co_name
> 
> ?  It's the same thing.

Well, that clears up one mystery.  The rest of your explanation of why
this is correct (as opposed to why this works in the two cases you've
tried :-) is still completely opaque to me...

>     # Define the built-in object "help" to provide interactive help.
>     class Helper:
>         def __repr__(self):
>             import inspect
>             if inspect.stack()[1][3] == '?': # not called from a function
>                 self()
>                 return ''
>             return '<Helper instance>'
>         def __call__(self, arg=None):
>             import pydoc
>             pydoc.help(arg)
>     __builtin__.help = Helper()
> 
> Why the strange check involving inspect.stack()?
> inspect.stack()[1][3] is the co_name of the parent frame.
> If we check that the __repr__ is not being requested by a
> function call, everything works perfectly in IDLE as well
> as the plain interpreter, and the helper object is still safe
> to pass around.  Nothing breaks even if you say help(help).

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


From tim.one@home.com  Wed Apr 18 09:55:34 2001
From: tim.one@home.com (Tim Peters)
Date: Wed, 18 Apr 2001 04:55:34 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <200104172223.RAA29490@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEPGJMAA.tim.one@home.com>

[Guido]
> ...
> I didn't mean to save a PEP number -- I just meant to keep the 2.1
> followup releases together.  I explained this to Barry over lunch and
> he agrees now.

I added a "[bugfix release dates go here]" marker to PEP 226 to remind him
<wink>.  Jeremy (he's still listed as the author) may want to clear out the
"Open issues for Python 2.0 beta 2" section.



From thomas@xs4all.net  Wed Apr 18 10:56:21 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 18 Apr 2001 11:56:21 +0200
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <200104172349.SAA00877@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 17, 2001 at 06:49:07PM -0500
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org> <200104172223.RAA29490@cj20424-a.reston1.va.home.com> <15068.49320.780995.520582@anthem.wooz.org> <200104172349.SAA00877@cj20424-a.reston1.va.home.com>
Message-ID: <20010418115621.U2820@xs4all.nl>

On Tue, Apr 17, 2001 at 06:49:07PM -0500, Guido van Rossum wrote:
> >     GvR> I didn't mean to save a PEP number -- I just meant to keep
> >     GvR> the 2.1 followup releases together.  I explained this to
> >     GvR> Barry over lunch and he agrees now.
> > 
> > Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
> > PEP 226.

> OK.  So we need a 2.2.1 Czar.  Any volunteers?

I assume you mean a 2.1.x Czar :) I'm willing to do it, given that it
doesn't require much attention *now* (except checking the checkin messages,
which I do anyway) and I fully expect to be able to free all the time I need
in a few weeks anyway. But I'm perfectly happy with Moshe or someone else
doing it, too.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From tim.one@home.com  Wed Apr 18 11:14:33 2001
From: tim.one@home.com (Tim Peters)
Date: Wed, 18 Apr 2001 06:14:33 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <15068.28158.342537.431634@anthem.wooz.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEPLJMAA.tim.one@home.com>

>   S   236  pep-0236.txt  Back to the __future__                 Peters
>
> Same for this one, Tim...

Part of the initial text in this should (as PEP 236 itself says) move into
PEP 5, but other than that it reflects 2.1's reality.  PEP 5 is Paul's.
Happy to move stuff into PEP 5 for him, but the instant I do that you just
*know* Guido will force me to change all sorts of things in PEP 5 that Paul
would vehemently disown <wink>.



From paulp@ActiveState.com  Wed Apr 18 11:35:22 2001
From: paulp@ActiveState.com (Paul Prescod)
Date: Wed, 18 Apr 2001 03:35:22 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <LNBBLJKPBEHFEDALKOLCGEPLJMAA.tim.one@home.com>
Message-ID: <3ADD6DEA.9FEED09A@ActiveState.com>

Tim Peters wrote:
> 
> >   S   236  pep-0236.txt  Back to the __future__                 Peters
> >
> > Same for this one, Tim...
> 
> Part of the initial text in this should (as PEP 236 itself says) move into
> PEP 5, but other than that it reflects 2.1's reality.  PEP 5 is Paul's.
> Happy to move stuff into PEP 5 for him, but the instant I do that you just
> *know* Guido will force me to change all sorts of things in PEP 5 that Paul
> would vehemently disown <wink>.

If you want to work out a clear status for PEP 5's process, you're
welcome to take it over!
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook


From guido@digicool.com  Tue Apr 17 15:29:44 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 09:29:44 -0500
Subject: [Python-Dev] ANNOUNCE: Python 2.1 final release
Message-ID: <mailman.987518161.9928.clpa-moderators@python.org>

Yes, the *final* release of Python 2.1 is now available.  Thanks again
for all who helped!  Go here for downloads and information:

    http://www.python.org/2.1/

As a reminder, here's a list of some of the big new features in 2.1
(news since 2.0 was released in October 2000):

- nested scopes and __future__ directives
- rich comparisons and new coercion model
- warnings framework
- new build process (Unix)
- weak references
- function attributes
- unittest and doctest modules for automated testing
- ports to several new platforms, including Cygwin and RISCOS

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



From guido@digicool.com  Wed Apr 18 16:04:15 2001
From: guido@digicool.com (Guido van Rossum)
Date: Wed, 18 Apr 2001 10:04:15 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Wed, 18 Apr 2001 11:56:21 +0200."
 <20010418115621.U2820@xs4all.nl>
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org> <200104172223.RAA29490@cj20424-a.reston1.va.home.com> <15068.49320.780995.520582@anthem.wooz.org> <200104172349.SAA00877@cj20424-a.reston1.va.home.com>
 <20010418115621.U2820@xs4all.nl>
Message-ID: <200104181504.KAA15504@cj20424-a.reston1.va.home.com>

> > > Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
> > > PEP 226.
> 
> > OK.  So we need a 2.2.1 Czar.  Any volunteers?
> 
> I assume you mean a 2.1.x Czar :)

Yes. :-)

> I'm willing to do it, given that it
> doesn't require much attention *now* (except checking the checkin messages,
> which I do anyway) and I fully expect to be able to free all the time I need
> in a few weeks anyway. But I'm perfectly happy with Moshe or someone else
> doing it, too.

Excellent.  I'd say let's divide labor here -- piling it all on Moshe
isn't fair.  You & Moshe can have a race who gets the first bugfix
release out! :-)

PEP 226 is all yours!

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


From jeremy@digicool.com  Wed Apr 18 15:07:31 2001
From: jeremy@digicool.com (Jeremy Hylton)
Date: Wed, 18 Apr 2001 10:07:31 -0400 (EDT)
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org>
References: <200104172220.RAA29454@cj20424-a.reston1.va.home.com>
 <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org>
Message-ID: <15069.40867.126819.564289@slothrop.digicool.com>

>>>>> "KPY" == Ka-Ping Yee <ping@lfw.org> writes:

  KPY> On Tue, 17 Apr 2001, Guido van Rossum wrote:
  >> This is one of the reasons why I didn't want to add this to the
  >> 2.1 release at such a late point.  I have no easy way to verify
  >> that this is always true, and in fact I have no idea what
  >> inspect.stack()[1][3] means. :-(

  KPY> Would you have preferred to write

  KPY>     sys._getframe().f_back.f_code.co_name

  KPY> ?  It's the same thing.

It's certainly clearer that inspect.stack()[1][3].  Does the existence
of the inspect module imply that we need to maintain its interface?
If we did, then we have some weird limits on the order of things in
stack frames.

Jeremy



From thomas.heller@ion-tof.com  Wed Apr 18 16:32:58 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 17:32:58 +0200
Subject: [Python-Dev] buffer interface (again)
Message-ID: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>

I would like to use (again) the buffer interface,
and I have some suggestions/questions.

- Only extension types can implement the buffer interface,
no way for a python class. Maybe a magic method __buffer__(self)
could be invented for this purpose?

- Why does the builtin function buffer() always return
readonly buffers, even for read/write objects? Shouldn't
there also be a readwrite_buffer() function, or should
buffer() return read/write buffers for read/write objects?

- My bug report 216405 on sourceforge is still open
(well, it is marked as closed, but it went into PEP 42)
http://sourceforge.net/tracker/index.php?func=detail&aid=216405&group_id=5470&atid=105470

Regards,

Thomas



From guido@digicool.com  Wed Apr 18 17:45:49 2001
From: guido@digicool.com (Guido van Rossum)
Date: Wed, 18 Apr 2001 11:45:49 -0500
Subject: [Python-Dev] buffer interface (again)
In-Reply-To: Your message of "Wed, 18 Apr 2001 17:32:58 +0200."
 <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>
Message-ID: <200104181645.LAA16566@cj20424-a.reston1.va.home.com>

> I would like to use (again) the buffer interface,
> and I have some suggestions/questions.
> 
> - Only extension types can implement the buffer interface,
> no way for a python class. Maybe a magic method __buffer__(self)
> could be invented for this purpose?

How could it be made safe?  The buffer interface makes raw memory
addresses available.  Letting a Python class decide on what addresses
to use opens a big hole for abuse.

> - Why does the builtin function buffer() always return
> readonly buffers, even for read/write objects? Shouldn't
> there also be a readwrite_buffer() function, or should
> buffer() return read/write buffers for read/write objects?

It's a lifetime issue.  You can hold on to the object returned by
buffer() long after the actual memory it points to is recycled for
some other purpose, and while *reading* that memory is not such a big
deal (assuming it is still part of your address space, you'll just get
garbage), allowing it to be *written* is again an invitation to
disaster.

> - My bug report 216405 on sourceforge is still open
> (well, it is marked as closed, but it went into PEP 42)
> http://sourceforge.net/tracker/index.php?func=detail&aid=216405&group_id=5470&atid=105470

I still feel that your bug report is based on the wrong assumption
about what the buffer API should do.

Thomas, please first explain what you want to *do* with the buffer
interface.  Some of the buffer API was a mistake.  It *appears* to be
an interface for allocating and managing buffers, while in actuality
it is only intended to provide access to buffered data that is managed
by some C code.  You're probably better off using the array module to
manage buffers.

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


From thomas.heller@ion-tof.com  Wed Apr 18 16:49:55 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 17:49:55 +0200
Subject: [Python-Dev] Case sensitive import on windows
Message-ID: <03ac01c0c81f$36e45950$e000a8c0@thomasnotebook>

I tried to find out what had changed between 2.0 and 2.1.
Consider the following files in the current directory:

Spam.py
spam/__init__.py

Using python 2.0:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: Case mismatch for module name Spam
(filename spam)
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>

Using python 2.1:

Python 2.1c2 (#14, Apr 15 2001, 21:29:05) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: NULL result without error in call_object
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>

Seems like a bug to me...

Thomas



From thomas.heller@ion-tof.com  Wed Apr 18 17:06:12 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 18:06:12 +0200
Subject: [Python-Dev] buffer interface (again)
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>  <200104181645.LAA16566@cj20424-a.reston1.va.home.com>
Message-ID: <03d101c0c821$7d13cee0$e000a8c0@thomasnotebook>

[no need to cc me directly]
> > I would like to use (again) the buffer interface,
> > and I have some suggestions/questions.
> > 
> > - Only extension types can implement the buffer interface,
> > no way for a python class. Maybe a magic method __buffer__(self)
> > could be invented for this purpose?
> 
> How could it be made safe?  The buffer interface makes raw memory
> addresses available.  Letting a Python class decide on what addresses
> to use opens a big hole for abuse.
class C:
    ...
    def __buffer__(self):
        # self.my_buffer is an object exposing the buffer interface
        return buffer(self.my_buffer)
or:
        return self.my_buffer
> 
> > - Why does the builtin function buffer() always return
> > readonly buffers, even for read/write objects? Shouldn't
> > there also be a readwrite_buffer() function, or should
> > buffer() return read/write buffers for read/write objects?
> 
> It's a lifetime issue.  You can hold on to the object returned by
> buffer() long after the actual memory it points to is recycled for
> some other purpose, and while *reading* that memory is not such a big
> deal (assuming it is still part of your address space, you'll just get
> garbage), allowing it to be *written* is again an invitation to
> disaster.
Lifetimes are managed by refcounts, so it's a refcount issue,
at least as long as every object exposing the buffer interface
_guarantees_ that the memory address and size does not change.
(Which does not seem the case for array objects).

> 
> > - My bug report 216405 on sourceforge is still open
> > (well, it is marked as closed, but it went into PEP 42)
> > http://sourceforge.net/tracker/index.php?func=detail&aid=216405&group_id=5470&atid=105470
> 
> I still feel that your bug report is based on the wrong assumption
> about what the buffer API should do.
I only tried to fix the refcount issue.

> 
> Thomas, please first explain what you want to *do* with the buffer
> interface.  Some of the buffer API was a mistake.  It *appears* to be
> an interface for allocating and managing buffers, while in actuality
> it is only intended to provide access to buffered data that is managed
> by some C code.  You're probably better off using the array module to
> manage buffers.

I want to expose memory blocks to C, wrapped in python objects/classes.
These memory blocks could come from builtin python types: strings,
unicode strings, array objects, mmap'd files, ...

Thomas



From Barrett@stsci.edu  Wed Apr 18 16:22:12 2001
From: Barrett@stsci.edu (Paul Barrett)
Date: Wed, 18 Apr 2001 11:22:12 -0400
Subject: [Python-Dev] buffer interface (again)
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>  <200104181645.LAA16566@cj20424-a.reston1.va.home.com> <03d101c0c821$7d13cee0$e000a8c0@thomasnotebook>
Message-ID: <3ADDB124.A34D3D45@STScI.Edu>

Thomas Heller wrote:
> 
> Lifetimes are managed by refcounts, so it's a refcount issue,
> at least as long as every object exposing the buffer interface
> _guarantees_ that the memory address and size does not change.
> (Which does not seem the case for array objects).
> 
> >
> > Thomas, please first explain what you want to *do* with the buffer
> > interface.  Some of the buffer API was a mistake.  It *appears* to be
> > an interface for allocating and managing buffers, while in actuality
> > it is only intended to provide access to buffered data that is managed
> > by some C code.  You're probably better off using the array module to
> > manage buffers.
> 
> I want to expose memory blocks to C, wrapped in python objects/classes.
> These memory blocks could come from builtin python types: strings,
> unicode strings, array objects, mmap'd files, ...

If you are talking about a memory object, then I'm in agreement with
you, Thomas.

I'd like to see a memory object that allocates and deallocates blocks
of memory and exports a pointer to its memory.  It could also set
privileges such are read/write, etc.  Its interface would be
identical, or at least similar, to the mmap object, so that they could
be easily interchanged.

-- 
Dr. Paul Barrett       Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Group
FAX:   410-338-4767    Baltimore, MD 21218


From thomas.heller@ion-tof.com  Wed Apr 18 17:36:26 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 18:36:26 +0200
Subject: [Python-Dev] Case sensitive import on windows
References: <03ac01c0c81f$36e45950$e000a8c0@thomasnotebook>
Message-ID: <048101c0c825$b678a940$e000a8c0@thomasnotebook>

I'v submitted a bug report on SF, my message could not
be delivered to guido.


http://sourceforge.net/tracker/index.php?func=detail&aid=417093&group_id=5470&atid=105470

Thomas

Failed to deliver to '<guido@mail.digicool.com>'
LOCAL module(account guido) reports:
 file is not found





From barry@wooz.org  Wed Apr 18 17:42:26 2001
From: barry@wooz.org (Barry A. Warsaw)
Date: Wed, 18 Apr 2001 12:42:26 -0400
Subject: [Python-Dev] Case sensitive import on windows
References: <03ac01c0c81f$36e45950$e000a8c0@thomasnotebook>
 <048101c0c825$b678a940$e000a8c0@thomasnotebook>
Message-ID: <15069.50162.410986.49812@anthem.wooz.org>

Mail to anybody@digicool.com is broken at the moment.  I'm trying to
reach people by phone, but I'd be surprised if the sa's don't know
about it.  I hope this will be a short-lived outage.

-Barry


From thomas.heller@ion-tof.com  Wed Apr 18 17:42:59 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 18:42:59 +0200
Subject: [Python-Dev] buffer interface (again)
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>  <200104181645.LAA16566@cj20424-a.reston1.va.home.com> <03d101c0c821$7d13cee0$e000a8c0@thomasnotebook> <3ADDB124.A34D3D45@STScI.Edu>
Message-ID: <04b101c0c826$a0818890$e000a8c0@thomasnotebook>

> 
> I'd like to see a memory object that allocates and deallocates blocks
> of memory and exports a pointer to its memory.  It could also set
> privileges such are read/write, etc

It's all there, in bufferobject.c.
Except that the functions are not exposed to python...

Thomas



From aahz@panix.com  Wed Apr 18 20:07:20 2001
From: aahz@panix.com (aahz@panix.com)
Date: Wed, 18 Apr 2001 15:07:20 -0400 (EDT)
Subject: [Python-Dev] PEP 6 revision
Message-ID: <200104181907.PAA28941@panix3.panix.com>

[posted to c.l.py.announce and c.l.py; followups to c.l.py; cc'd to
python-dev]

[Barry, please update Post-History]

Okay, here's the next version of PEP 6:

PEP: 6
Title: Bugfix Releases
Version: $Revision: 1.3 $
Author: aahz@pobox.com (Aahz)
Status: Draft
Type: Informational
Created: 15-Mar-2001
Post-History: 15-Mar-2001

Abstract

    Python has historically had only a single fork of development, with
    releases having the combined purpose of adding new features and
    delivering bug fixes (these kinds of releases will be referred to as
    "feature releases").  This PEP describes how to fork off patch
    releases of old versions for the primary purpose of fixing bugs.

    This PEP is not, repeat NOT, a guarantee of the existence of patch
    releases; it only specifies a procedure to be followed if patch
    releases are desired by enough of the Python community willing to do
    the work.


Motivation

    With the move to SourceForge, Python development has accelerated.
    There is a sentiment among part of the community that there was too
    much acceleration, and many people are uncomfortable with upgrading
    to new versions to get bug fixes when so many features have been
    added, sometimes late in the development cycle.

    One solution for this issue is to maintain the previous feature
    release, providing bugfixes until the next feature release.  This
    should make Python more attractive for enterprise development, where
    Python may need to be installed on hundreds or thousands of machines.


Prohibitions

    Patch releases are required to adhere to the following restrictions:

    1. There must be zero syntax changes.  All .pyc and .pyo files must
        work (no regeneration needed) with all patch releases forked off
        from a feature release.

    2. There must be zero pickle changes.

    3. There must be no incompatible C API changes.  All extensions must
        continue to work without recompiling in all patch releases in the
        same fork as a feature release.

    Breaking any of these prohibitions requires a BDFL proclamation (and
    a prominent warning in the release notes).


Version Numbers

    Starting with Python 2.0, all feature releases are required to have
    a version number the form X.Y; patch releases will always be of the
    form X.Y.Z.

    The current feature release under development is referred to as
    release N; the just-released feature version is referred to as N-1.


Procedure

    The process for managing patch releases is modeled in part on the
    Tcl system [1].

    The Patch Czar is the counterpart to the BDFL for patch releases.
    However, the BDFL and designated appointees retain veto power over
    individual patches.

    As individual patches get contributed to the feature release fork,
    each patch contributor is requested to consider whether the patch is
    a bugfix suitable for inclusion in a patch release.  If the patch is
    considered suitable, the patch contributor will mail the SourceForge
    patch (bugfix?) number to the maintainers' mailing list.

    In addition, anyone from the Python community is free to suggest
    patches for inclusion.  Patches may be submitted specifically for
    patch releases; they should follow the guidelines in PEP 3 [2].

    The Patch Czar decides when there are a sufficient number of patches
    to warrant a release.  The release gets packaged up, including a
    Windows installer, and made public.  If any new bugs are found, they
    must be fixed immediately and a new patch release publicized (with an
    incremented version number).

    Patch releases are expected to occur at an interval of roughly one
    month.  In general, only the N-1 release will be under active
    maintenance at any time.


Patch Czar History

    Moshe Zadka (moshez@zadka.site.co.il) is the Patch Czar for 2.0.1.


Issues To Be Resolved

    What is the equivalent of python-dev for people who are responsible
    for maintaining Python?  (Aahz proposes either python-patch or
    python-maint, hosted at either python.org or xs4all.net.)

    Does SourceForge make it possible to maintain both separate and
    combined bug lists for multiple forks?  If not, how do we mark bugs
    fixed in different forks?  (Simplest is to simply generate a new bug
    for each fork that it gets fixed in, referring back to the main bug
    number for details.)


History

    This PEP started life as a proposal on comp.lang.python.  The
    original version suggested a single patch for the N-1 release to be
    released concurrently with the N release.  The original version also
    argued for sticking with a strict bugfix policy.

    Following feedback from the BDFL and others, the draft PEP was
    written containing an expanded patch release cycle that permitted
    any previous feature release to obtain patches and also relaxed the
    strict bugfix requirement (mainly due to the example of PEP 235 [3],
    which could be argued as either a bugfix or a feature).

    Discussion then mostly moved to python-dev, where BDFL finally
    issued a proclamation basing the Python patch release process on
    Tcl's, which essentially returned to the original proposal in terms
    of being only the N-1 release and only bugfixes, but allowing
    multiple patch releases until release N is published.


References

    [1] http://dev.scriptics.com:8080/cgi-bin/tct/tip/28.html
    [2] http://python.sourceforge.net/peps/pep-0003.html
    [3] http://python.sourceforge.net/peps/pep-0235.html


Copyright

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
-- 
                      --- Aahz  <*>  (Copyright 2001 by aahz@pobox.com)

Androgynous poly kinky vanilla queer het Pythonista   http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

"If we had some ham, we could have ham & eggs, if we had some eggs." --RH


From m.favas@per.dem.csiro.au  Wed Apr 18 21:13:09 2001
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Thu, 19 Apr 2001 04:13:09 +0800
Subject: [Python-Dev] 2.2a0: latest unicode change breaks test_unicodedata
Message-ID: <3ADDF555.13C627F8@per.dem.csiro.au>

In a change from 2.1 (final) to 2.2a0 - test_unicodedata now fails the
methods test:

test test_unicodedata failed -- Writing:
'00c22b40a906a1a738012676c9feaedfc6be20
d9', expected: '6c7a7c02657b69d0fdd7a7d174f573194bba2e18'

python Lib/test/test_unicodedata.py 
Testing Unicode Database...
Methods: 00c22b40a906a1a738012676c9feaedfc6be20d9
Functions: 4db70de42a8f2de6236242949579fe0e80e7c34a
API: ok

(Tru64 Unix, Compaq C)

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From tim.one@home.com  Wed Apr 18 22:20:59 2001
From: tim.one@home.com (Tim Peters)
Date: Wed, 18 Apr 2001 17:20:59 -0400
Subject: [Python-Dev] 2.2a0: latest unicode change breaks test_unicodedata
In-Reply-To: <3ADDF555.13C627F8@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEBNJNAA.tim.one@home.com>

[Mark Favas]
> In a change from 2.1 (final) to 2.2a0 - test_unicodedata now fails the
> methods test:
>
> test test_unicodedata failed -- Writing:
> '00c22b40a906a1a738012676c9feaedfc6be20
> d9', expected: '6c7a7c02657b69d0fdd7a7d174f573194bba2e18'
> ...
> (Tru64 Unix, Compaq C)

Reproduced identically on Windows (guess *everything* isn't the fault of
Compaq's compiler <wink>).  I assume this has something to do with the very
recent Unicode "optimization" patch.

Mystery:  since running the test suite before committing the change would
have caught this, how did the bug get into the CVS tree?  Since it appears
test_unicodedata is skipped under Unix when building the quicktest target, is
this due to people mechanically using quicktest instead of test?  Then that's
a second optimization bug <0.6 wink>.



From mal@lemburg.com  Wed Apr 18 23:51:11 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 00:51:11 +0200
Subject: [Python-Dev] Importing DLLs on Windows
Message-ID: <3ADE1A5F.F574B613@lemburg.com>

Python or Windows seems to have trouble importing DLLs when
inside packages. I'm working on an extension which pulls in a
DLL gmp31.dll which lives inside a package dir mx/Number/mxNumber
along side the Python wrapper extension mxNumber.pyd.

Currently, I'm using this code in the subpackage's __init__.py:

# On Windows we also distribute the GMP DLL (in the win32 subdir). To
# have Win32 find the DLL we need to be explicit about the path in
# sys.path though. This trick works for all startup directories
# *except* \PythonXX (for some reason this fails), but is not thread
# safe...
import sys, os
if sys.platform[:3] == 'win':
    abspath = os.path.abspath(__path__[0])
    sys.path.insert(0, abspath)
    from mxNumber import *
    sys.path.remove(abspath)

else:
    from mxNumber import *


I don't have any clue why the import works from everywhere *except*
the Python21 install directory... anyone does ?

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From tim.one@home.com  Thu Apr 19 00:05:39 2001
From: tim.one@home.com (Tim Peters)
Date: Wed, 18 Apr 2001 19:05:39 -0400
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <20010417151219.T275@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGECIJNAA.tim.one@home.com>

[Jason Tishler]
> I have contributed Python to the standard Cygwin distribution.
> ...
> Cygwin's setup.exe will automatically install Cygwin Python the next
> time one installs or updates from a mirror.

tim@CJ569191-B ~
$ type python
python is /usr/bin/python

tim@CJ569191-B ~
$ python -c "print 'Good show!'"
Good show!

tim@CJ569191-B ~
$

I have nothing to add to what Cygwin Python said <wink>.

hard-to-believe-any-real-program-runs-on-a-win98se-box-ly y'rs  - tim



From skip@pobox.com (Skip Montanaro)  Thu Apr 19 09:24:20 2001
From: skip@pobox.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 19 Apr 2001 03:24:20 -0500 (CDT)
Subject: [Python-Dev] tickling version numbers during release
Message-ID: <15070.41140.642307.450172@beluga.mojam.com>

It seems like there is always a flurry of checkins associated with bumping
version numbers whenever a release is impending.  Wouldn't it make sense to
stuff the version number into a file somewhere then add a make target to the
makefile to update the relevant files and check them into cvs?

Skip


From Jason.Tishler@dothill.com  Thu Apr 19 15:07:27 2001
From: Jason.Tishler@dothill.com (Jason Tishler)
Date: Thu, 19 Apr 2001 10:07:27 -0400
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECIJNAA.tim.one@home.com>; from tim.one@home.com on Wed, Apr 18, 2001 at 07:05:39PM -0400
References: <20010417151219.T275@dothill.com> <LNBBLJKPBEHFEDALKOLCGECIJNAA.tim.one@home.com>
Message-ID: <20010419100727.G394@dothill.com>

On Wed, Apr 18, 2001 at 07:05:39PM -0400, Tim Peters wrote:
> hard-to-believe-any-real-program-runs-on-a-win98se-box-ly y'rs  - tim

Hmm...  Maybe we should take up a collection and buy Tim a copy of
Windows 2000 -- at least then he will have a better chance of deluding
himself into thinking that he is using a "real" operating system. :,)

Anyway, I do appreciate Guido and Tim's acknowledge of my efforts on
the Cygwin Python port.  It's been fun and I learned a lot of new things.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com


From trentm@ActiveState.com  Thu Apr 19 15:53:26 2001
From: trentm@ActiveState.com (Trent Mick)
Date: Thu, 19 Apr 2001 07:53:26 -0700
Subject: [Python-Dev] tickling version numbers during release
In-Reply-To: <15070.41140.642307.450172@beluga.mojam.com>; from skip@pobox.com on Thu, Apr 19, 2001 at 03:24:20AM -0500
References: <15070.41140.642307.450172@beluga.mojam.com>
Message-ID: <20010419075326.F30408@ActiveState.com>

On Thu, Apr 19, 2001 at 03:24:20AM -0500, Skip Montanaro wrote:
> It seems like there is always a flurry of checkins associated with bumping
> version numbers whenever a release is impending.  Wouldn't it make sense to
> stuff the version number into a file somewhere then add a make target to the
> makefile to update the relevant files and check them into cvs?

Or preferably have the version number in only *one* place in one file in CVS
then (1) have autoconf massage template files to insert the version number
where needed or (2) have those files that need the version number *include*
it from pyac_config.h.

...except we are not using any auto configuration tool on Windows. Damn.

Trent

-- 
Trent Mick
TrentM@ActiveState.com


From guido@digicool.com  Thu Apr 19 16:09:47 2001
From: guido@digicool.com (Guido van Rossum)
Date: Thu, 19 Apr 2001 11:09:47 -0400
Subject: [Python-Dev] tickling version numbers during release
In-Reply-To: Your message of "Thu, 19 Apr 2001 03:24:20 CDT."
 <15070.41140.642307.450172@beluga.mojam.com>
References: <15070.41140.642307.450172@beluga.mojam.com>
Message-ID: <200104191509.f3JF9ng02487@odiug.pythonlabs.org>

> It seems like there is always a flurry of checkins associated with bumping
> version numbers whenever a release is impending.  Wouldn't it make sense to
> stuff the version number into a file somewhere then add a make target to the
> makefile to update the relevant files and check them into cvs?

Is it worth spending the time to write a script that gets run only
once per revision?  (The bump from 2.1 to 2.2 causes many more
checkins than e.g. from 2.1 to 2.1.1 or from 2.1a1 to 2.1b1.)

It won't reduce the nubmer of checkins -- the files that have the
versions really must have the versions, and we do what we can to
minimize the dependencies (e.g. the VERSION variable in configure.in
gets propagated to the Makefile).

Like Knuth says in his explanation of how "The Art Of Computer
Programming" is typeset, the start of a new chapter is such a major
event that there's no macro for it -- he types it in himself.  (Most
other typing is done by typists of course.)

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


From mal@lemburg.com  Thu Apr 19 20:04:41 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 21:04:41 +0200
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, Floats)
Message-ID: <3ADF36C9.1D9AA305@lemburg.com>

As you all know, Moshe Zadka has been pushing for a new rational number
type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I though, but well, it's done now ;-)

The wrapper is called mx.Number and provides access to three
numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision

Prerequisites:
--------------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
i = Integer("1231231231231231231231231")

The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


Questions:
----------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From mwh21@cam.ac.uk  Thu Apr 19 21:04:57 2001
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 19 Apr 2001 21:04:57 +0100
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, Floats)
In-Reply-To: "M.-A. Lemburg"'s message of "Thu, 19 Apr 2001 21:04:41 +0200"
References: <3ADF36C9.1D9AA305@lemburg.com>
Message-ID: <m3g0f4r6za.fsf@atrus.jesus.cam.ac.uk>

Before I d/l and take a look...

"M.-A. Lemburg" <mal@lemburg.com> writes:

> (e.g. Integer(2) + "3" works as one would expect ;-).

So it raises an exception?  Seriously, that's what *I'd* expect, and
if it's not what your package does, I beg you to reconsider.

Cheers,
M.

-- 
  Good? Bad? Strap him into the IETF-approved witch-dunking
  apparatus immediately!                        -- NTK now, 21/07/2000



From mal@lemburg.com  Thu Apr 19 21:25:50 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 22:25:50 +0200
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational,
 Floats)
References: <3ADF36C9.1D9AA305@lemburg.com> <m3g0f4r6za.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <3ADF49CE.10EF2A5D@lemburg.com>

Michael Hudson wrote:
> 
> Before I d/l and take a look...
> 
> "M.-A. Lemburg" <mal@lemburg.com> writes:
> 
> > (e.g. Integer(2) + "3" works as one would expect ;-).
> 
> So it raises an exception?  Seriously, that's what *I'd* expect, and
> if it's not what your package does, I beg you to reconsider.

Integer(2) + "3" gives you Integer(5). This is a side-effect
of how the implementation converts arbitrary objects into ones
usable for coercion: Integer(2) + "3" is interpreted as 
Integer(2) + Integer("3") which gives Integer(2) + Integer(3).

After having played with it for a while, I must say, that I
kind of like it :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From mwh21@cam.ac.uk  Thu Apr 19 22:46:51 2001
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 19 Apr 2001 22:46:51 +0100
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0252.txt,NONE,1.1 pep-0000.txt,1.87,1.88
In-Reply-To: Guido van Rossum's message of "Thu, 19 Apr 2001 14:27:27 -0700"
References: <E14qLxX-0006pt-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <m3d7a8r29g.fsf@atrus.jesus.cam.ac.uk>

Guido van Rossum <gvanrossum@users.sourceforge.net> writes:

[snip]
> Author: guido@python.org (Jeremy Hylton)

Eh?

[snop]



From guido@digicool.com  Fri Apr 20 05:29:45 2001
From: guido@digicool.com (Guido van Rossum)
Date: Thu, 19 Apr 2001 23:29:45 -0500
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
Message-ID: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>

I've got a fairly complete implementation of iterators along the lines
of Ping's PEP (slightly updated).  This is available for inspection
through CVS: just check out the CVS branch of python/dist/src named
"iter-branch" from SourceForge:

  cvs checkout -r iter-branch -d <directory> python/src/dist

(This branch was forked off the trunk around the time of version
2.1b1, so it's not up to date with Python 2.1, but it's good enough to
show off iterators.)

My question is: should I just merge this code onto the trunk (making
it part of 2.2), or should we review the design more before committing
to this implementation?

Brief overview of what I've got implemented:

- There is a new built-in operation, spelled as iter(obj) in Python
  and as PyObject_GetIter(obj) in C; it calls the tp_iter slot in
  obj's type.  This returns an iterator, which can be any object that
  implements the iterator protocol.  The iterator protocol defines one
  method, next(), which returns the next value or raises the new
  StopIteration exception.

- For backwards compatibility, if obj's type does not have a valid
  tp_iter slot, iter(obj) and PyObject_GetIter(obj) create a sequence
  iterator that iterates over a sequence.

- "for x in S: B" is implemented roughly as

  __iter = iter(S)
  while 1:
    try:
      x = __iter.next()
    except StopIteration:
      break
    B

  (except that the semantics of break when there's an else clause are
  not different from what this Python code would do).

- The test "key in dict" is implemented as "dict.has_key(key)".  (This
  was done by implementing the sq_contains slot.

- iter(dict) returns an iterator that iterates over the keys of dict
  without creating a list of keys first.  This means that "for key in
  dict" has the same effect as "for key in dict.keys()" as long as the
  loop body doesn't modify the dictionary (assignment to existing keys
  is okay).

- There's an operation to create an iterator from a function and a
  sentinel value.  This is spelled as iter(function, sentinel).  For
  example,

    for line in iter(sys.stdin.readline, ""):
      ...

  is an efficient loop over the lines of stdin.

- But even cooler is this, which is totally equivalent:

    for line in sys.stdin:
      ...

- Not yet implemented, but part of the plan, is to use iterators for
  all other implicit loops, like map/reduce/filter, min/max, and the
  "in" test for sequences that don't define sq_contains.

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


From tim.one@home.com  Fri Apr 20 08:15:30 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 20 Apr 2001 03:15:30 -0400
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEHDJNAA.tim.one@home.com>

[Guido]
> I've got a fairly complete implementation of iterators along the lines
> of Ping's PEP (slightly updated).
> ...
> My question is: should I just merge this code onto the trunk (making
> it part of 2.2), or should we review the design more before committing
> to this implementation?

My answer is both!  *Most* of what you described is no longer controversial;
2.2 is mondo pre-alpha (so we're not "stuck" with anything you check in now);
and it's much more convenient (for me - heh) to try out if it's in the
regular build tree.  I bet Greg Wilson would like it for his Set PEP work
too, as abusing the __getitem__ protocol for set iteration is giving him
headaches.  WRT what may still be controversial points, there's no substitute
for trying a thing.

> ...
> - The test "key in dict" is implemented as "dict.has_key(key)".  (This
>   was done by implementing the sq_contains slot.

That's probably controversial, but also easy to rip out (sounds approximately
self-contained) if the peasants storm your castle with flaming dungballs
<wink>.

> - iter(dict) returns an iterator that iterates over the keys of dict
>   without creating a list of keys first.  This means that "for key in
>   dict" has the same effect as "for key in dict.keys()" as long as
>   the loop body doesn't modify the dictionary (assignment to existing
>   keys is okay).

Ditto.

> - There's an operation to create an iterator from a function and a
>   sentinel value.  This is spelled as iter(function, sentinel).  For
>   example,
>
>     for line in iter(sys.stdin.readline, ""):
>       ...
>
>   is an efficient loop over the lines of stdin.
>
> - But even cooler is this, which is totally equivalent:
>
>     for line in sys.stdin:
>       ...

Here you're going to be hoisted on your own petard (Jeremy can explain that
one <wink>):  if

    for x in dict:

has to iterate over keys because

    if x in dict:

tests for keys, then shouldn't

    if line in sys.stdin:

also check sys.stdin for the presence of line?  Not according to me, but it's
a not wholly unreasonable question.

> - Not yet implemented, but part of the plan, is to use iterators for
>   all other implicit loops, like map/reduce/filter, min/max, and the
>   "in" test for sequences that don't define sq_contains.

Check it into the trunk and people can help out with that stuff.

+0.9.



From thomas@xs4all.net  Fri Apr 20 09:37:33 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 20 Apr 2001 10:37:33 +0200
Subject: [python-iter] RE: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEHDJNAA.tim.one@home.com>; from tim.one@home.com on Fri, Apr 20, 2001 at 03:15:30AM -0400
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCCEHDJNAA.tim.one@home.com>
Message-ID: <20010420103733.D10318@xs4all.nl>

On Fri, Apr 20, 2001 at 03:15:30AM -0400, Tim Peters wrote:
> [Guido]
> > I've got a fairly complete implementation of iterators along the lines
> > of Ping's PEP (slightly updated).
> > ...
> > My question is: should I just merge this code onto the trunk (making
> > it part of 2.2), or should we review the design more before committing
> > to this implementation?

> My answer is both!  *Most* of what you described is no longer controversial;
> 2.2 is mondo pre-alpha (so we're not "stuck" with anything you check in now);
> and it's much more convenient (for me - heh) to try out if it's in the
> regular build tree.  I bet Greg Wilson would like it for his Set PEP work
> too, as abusing the __getitem__ protocol for set iteration is giving him
> headaches.  WRT what may still be controversial points, there's no substitute
> for trying a thing.

I don't totally agree. Removing something from the trunk is not as easy as
not adding it ;) But I agree that, since the *concept* of iterators, and the
basic implementation, all are good things, they should be checked in. I
still don't like:

> > ...
> > - The test "key in dict" is implemented as "dict.has_key(key)".  (This
> >   was done by implementing the sq_contains slot.

> That's probably controversial, but also easy to rip out (sounds approximately
> self-contained) if the peasants storm your castle with flaming dungballs
> <wink>.

Fetchez-la-vache!-ly y'rs

(Oh, now I get it... Iterators are Guido's wooden rabbit, with 'key-in-dict'
hidden inside... I just hope it's Sir Bedevere that's building it ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From mal@lemburg.com  Fri Apr 20 10:02:09 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 20 Apr 2001 11:02:09 +0200
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>
Message-ID: <3ADFFB11.AECF3438@lemburg.com>

Guido van Rossum wrote:
> 
> Brief overview of what I've got implemented:
> 
> - There is a new built-in operation, spelled as iter(obj) in Python
>   and as PyObject_GetIter(obj) in C; it calls the tp_iter slot in
>   obj's type.  This returns an iterator, which can be any object that
>   implements the iterator protocol.  The iterator protocol defines one
>   method, next(), which returns the next value or raises the new
>   StopIteration exception.

Could we also have a C slot for .next() ? (Python function calls
are way too expensive for these things, IMHO)

Will there be a __iter__() method for Python instances to implement ?

> - For backwards compatibility, if obj's type does not have a valid
>   tp_iter slot, iter(obj) and PyObject_GetIter(obj) create a sequence
>   iterator that iterates over a sequence.
> 
> - "for x in S: B" is implemented roughly as
> 
>   __iter = iter(S)
>   while 1:
>     try:
>       x = __iter.next()
>     except StopIteration:
>       break
>     B
> 
>   (except that the semantics of break when there's an else clause are
>   not different from what this Python code would do).
> 
> - The test "key in dict" is implemented as "dict.has_key(key)".  (This
>   was done by implementing the sq_contains slot.

Cool :)
 
> - iter(dict) returns an iterator that iterates over the keys of dict
>   without creating a list of keys first.  This means that "for key in
>   dict" has the same effect as "for key in dict.keys()" as long as the
>   loop body doesn't modify the dictionary (assignment to existing keys
>   is okay).
>
> - There's an operation to create an iterator from a function and a
>   sentinel value.  This is spelled as iter(function, sentinel).  For
>   example,
> 
>     for line in iter(sys.stdin.readline, ""):
>       ...
> 
>   is an efficient loop over the lines of stdin.

Hmm, I guess you have to compare each function output to the
sentinel then, right ? This can be very expensive.

Wouldn't an exception base class also do the trick as sentinel ? The 
iterator would then stop when an exception is raised by the
function which matches the sentinel exception.
 
> - But even cooler is this, which is totally equivalent:
> 
>     for line in sys.stdin:
>       ...
> 
> - Not yet implemented, but part of the plan, is to use iterators for
>   all other implicit loops, like map/reduce/filter, min/max, and the
>   "in" test for sequences that don't define sq_contains.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From thomas@xs4all.net  Fri Apr 20 10:26:38 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 20 Apr 2001 11:26:38 +0200
Subject: [Python-iterators] Re: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <3ADFFB11.AECF3438@lemburg.com>; from mal@lemburg.com on Fri, Apr 20, 2001 at 11:02:09AM +0200
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <3ADFFB11.AECF3438@lemburg.com>
Message-ID: <20010420112638.F10318@xs4all.nl>

On Fri, Apr 20, 2001 at 11:02:09AM +0200, M.-A. Lemburg wrote:

> > - There's an operation to create an iterator from a function and a
> >   sentinel value.  This is spelled as iter(function, sentinel).  For
> >   example,
> > 
> >     for line in iter(sys.stdin.readline, ""):
> >       ...
> > 
> >   is an efficient loop over the lines of stdin.

> Hmm, I guess you have to compare each function output to the
> sentinel then, right ? This can be very expensive.

> Wouldn't an exception base class also do the trick as sentinel ? The 
> iterator would then stop when an exception is raised by the
> function which matches the sentinel exception.

The sentinel method is for use with existing functions, that return a
sentinel value (like "" or None or whatever.) Comparing to those is not
terribly expensive, asside from the burden of running a single compare in
the inner loop. Rewriting those functions to raise an exception instead
would be, well, somewhat silly -- if you're rewriting them anyway, why not
just make an iterator out of them ?

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas@xs4all.net  Fri Apr 20 10:35:12 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 20 Apr 2001 11:35:12 +0200
Subject: [Python-Dev] off-topic, sorry ;)
Message-ID: <20010420113512.G10318@xs4all.nl>

My batch of PythonLabs T-Shirts arrived yesterday (thanx, by the way,
Melissa!) but there was something twilight-zonish about the box that I just
had to share ;) My colleague Scott took delivery of the box, and knew
without looking at the sender or description that it was something Python
related. It had this sticker on it:

http://www.xs4all.nl/~thomas/SPAM.jpg

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From mal@lemburg.com  Fri Apr 20 11:10:10 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 20 Apr 2001 12:10:10 +0200
Subject: [Python-iterators] Re: [Python-Dev] Shall I start adding iterators
 to Python 2.2?
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <3ADFFB11.AECF3438@lemburg.com> <20010420112638.F10318@xs4all.nl>
Message-ID: <3AE00B02.5EFCB6F@lemburg.com>

Thomas Wouters wrote:
> 
> On Fri, Apr 20, 2001 at 11:02:09AM +0200, M.-A. Lemburg wrote:
> 
> > > - There's an operation to create an iterator from a function and a
> > >   sentinel value.  This is spelled as iter(function, sentinel).  For
> > >   example,
> > >
> > >     for line in iter(sys.stdin.readline, ""):
> > >       ...
> > >
> > >   is an efficient loop over the lines of stdin.
> 
> > Hmm, I guess you have to compare each function output to the
> > sentinel then, right ? This can be very expensive.
> 
> > Wouldn't an exception base class also do the trick as sentinel ? The
> > iterator would then stop when an exception is raised by the
> > function which matches the sentinel exception.
> 
> The sentinel method is for use with existing functions, that return a
> sentinel value (like "" or None or whatever.) Comparing to those is not
> terribly expensive, asside from the burden of running a single compare in
> the inner loop. Rewriting those functions to raise an exception instead
> would be, well, somewhat silly -- if you're rewriting them anyway, why not
> just make an iterator out of them ?

I wasn't clear enough: I was proposing to also allow exception
classes as sentinel which are then not compared with the result
of the function, but instead with any exceptions raised by the
function. This would be an additional method of recognizing the
end-of-iteration to the standard return value comparison.

The reasoning is the you may want to use e.g. a C function (hard
to rewrite as iterator) as iterator which currently works along 
these lines:

while 1:
    try:
        x = datasource()
    except EndOfData:
        break
    print x

You could then rewrite this as:

for x in iter(datasource, EndOfData):
   print x

BTW, how does iter() recognize that it is supposed to look
for a sentinel ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From mal@lemburg.com  Thu Apr 19 20:04:41 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 21:04:41 +0200
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, Floats)
Message-ID: <mailman.987707135.9028.python-list@python.org>

As you all know, Moshe Zadka has been pushing for a new rational number
type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I though, but well, it's done now ;-)

The wrapper is called mx.Number and provides access to three
numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision

Prerequisites:
--------------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
i = Integer("1231231231231231231231231")

The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


Questions:
----------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From Greg.Wilson@baltimore.com  Fri Apr 20 13:55:24 2001
From: Greg.Wilson@baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 08:55:24 -0400
Subject: [Python-Dev] configuration "feature"
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com>

I just checked out a fresh copy of Python from Sourceforge
on a Solaris 5.8 machine, and typed:

    ./configure -with-cxx

rather than

    ./configure -with-cxx=g++

It generates a makefile with "CXX=yes", so "make" produces:

    bash-2.03$ make
    yes -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H
\
        -o Modules/ccpython.o ./Modules/ccpython.cc
    make: yes: Command not found

:-)

Greg


From mwh21@cam.ac.uk  Fri Apr 20 14:13:03 2001
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 20 Apr 2001 14:13:03 +0100
Subject: [Python-Dev] configuration "feature"
In-Reply-To: Greg Wilson's message of "Fri, 20 Apr 2001 08:55:24 -0400"
References: <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com>
Message-ID: <m3ae5bpvds.fsf@atrus.jesus.cam.ac.uk>

Greg Wilson <Greg.Wilson@baltimore.com> writes:

> I just checked out a fresh copy of Python from Sourceforge
> on a Solaris 5.8 machine, and typed:
> 
>     ./configure -with-cxx
> 
> rather than
> 
>     ./configure -with-cxx=g++
> 
> It generates a makefile with "CXX=yes", so "make" produces:
> 
>     bash-2.03$ make
>     yes -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H
> \
>         -o Modules/ccpython.o ./Modules/ccpython.cc
>     make: yes: Command not found
> 
> :-)

Teehee.  Try it on a linux box though; there is a /usr/bin/yes, and it
doesn't do anything too helpful...

Cheers,
M.

-- 
  [Perl] combines all the  worst aspects of C and Lisp:  a billion
  different sublanguages in one monolithic executable. It combines
  the power of C with the readability of PostScript.
                                                     -- Jamie Zawinski



From guido@digicool.com  Fri Apr 20 15:55:54 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 09:55:54 -0500
Subject: [Python-Dev] configuration "feature"
In-Reply-To: Your message of "Fri, 20 Apr 2001 08:55:24 -0400."
 <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com>
References: <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com>
Message-ID: <200104201455.JAA05644@cj20424-a.reston1.va.home.com>

> I just checked out a fresh copy of Python from Sourceforge
> on a Solaris 5.8 machine, and typed:
> 
>     ./configure -with-cxx
> 
> rather than
> 
>     ./configure -with-cxx=g++
> 
> It generates a makefile with "CXX=yes", so "make" produces:
> 
>     bash-2.03$ make
>     yes -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H
> \
>         -o Modules/ccpython.o ./Modules/ccpython.cc
>     make: yes: Command not found
> 
> :-)

Use the SourceForge bug tracker, please!

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


From guido@digicool.com  Fri Apr 20 16:41:32 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 10:41:32 -0500
Subject: [Python-iterators] Re: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: Your message of "Fri, 20 Apr 2001 11:26:38 +0200."
 <20010420112638.F10318@xs4all.nl>
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <3ADFFB11.AECF3438@lemburg.com>
 <20010420112638.F10318@xs4all.nl>
Message-ID: <200104201541.KAA06089@cj20424-a.reston1.va.home.com>

I've redirected replies to python-iterators@lists.sourceforge.net.
The archives work now:

http://www.geocrawler.com/lists/3/SourceForge/9283/0/

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


From thomas.heller@ion-tof.com  Fri Apr 20 16:05:42 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 17:05:42 +0200
Subject: [Python-Dev] Class Methods
Message-ID: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>

There are some signs :-) that Python's object
model is going to be revised even _before_
Python 3000.

Is someone willing to join me fighting
for class methods (I mean 'real' class-methods
in the Smalltalk style here, _not_ static
methods like in Java or C++).

Thomas



From jeremy@digicool.com  Fri Apr 20 16:14:16 2001
From: jeremy@digicool.com (Jeremy Hylton)
Date: Fri, 20 Apr 2001 11:14:16 -0400 (EDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
Message-ID: <15072.21064.298318.393753@slothrop.digicool.com>

>>>>> "TH" == Thomas Heller <thomas.heller@ion-tof.com> writes:

  TH> There are some signs :-) that Python's object model is going to
  TH> be revised even _before_ Python 3000.

  TH> Is someone willing to join me fighting for class methods (I mean
  TH> 'real' class-methods in the Smalltalk style here, _not_ static
  TH> methods like in Java or C++).

The idea sounds good in the abstract.  Class are objects and objects
ought to have methods that implement their behavior.  How does that
very vague idea turn into something real?  No clue.  You start
fighting and let's see where it goes :-).

Jeremy



From guido@digicool.com  Fri Apr 20 17:26:01 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 11:26:01 -0500
Subject: [Python-Dev] Class Methods
In-Reply-To: Your message of "Fri, 20 Apr 2001 17:05:42 +0200."
 <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
Message-ID: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>

> There are some signs :-) that Python's object
> model is going to be revised even _before_
> Python 3000.

Well, the official policy on this is now that Py3K is just a slogan,
and that all the real work will be introduced gradually. :-)

> Is someone willing to join me fighting
> for class methods (I mean 'real' class-methods
> in the Smalltalk style here, _not_ static
> methods like in Java or C++).

I will fight class methods to the death. :-)

Seriously, I think you'll find an ally in Jim Fulton, who basically
told me (since he's sort of my boss :-) to get on with this work.  I
think it can work as follows:

Let x be an object, C its class, and M C's class.  So,

  x.__class__ is C
  C.__class__ is M

Then x's methods are described in C.__dict__, and C's methods are
described in M.__dict__.

The problem is that if you write C.spam, there could be two spams: one
in C.__dict__, one in M.__dict__.  Which one to use?  How does
Smalltalk resolve this?  The problem is that for backwards
compatibility, at lease, C.spam must be the unbound version of x.spam,
because currently x.spam(...) can always also be written as
C.spam(x, ...).

For regular methods it may be possible to avoid this simply by
choosing non-conflicting names, but I seem to recall that Jim wanted
to use class methods with certain special names (like __init__ or
__getattr__?), and I have no idea how to do this without dropping the
idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
solution?

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


From mal@lemburg.com  Fri Apr 20 16:24:29 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 20 Apr 2001 17:24:29 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com>
Message-ID: <3AE054AD.9A8D07D@lemburg.com>

Jeremy Hylton wrote:
> 
> >>>>> "TH" == Thomas Heller <thomas.heller@ion-tof.com> writes:
> 
>   TH> There are some signs :-) that Python's object model is going to
>   TH> be revised even _before_ Python 3000.
> 
>   TH> Is someone willing to join me fighting for class methods (I mean
>   TH> 'real' class-methods in the Smalltalk style here, _not_ static
>   TH> methods like in Java or C++).
> 
> The idea sounds good in the abstract.  Class are objects and objects
> ought to have methods that implement their behavior.  How does that
> very vague idea turn into something real?  No clue.  You start
> fighting and let's see where it goes :-).

Here's something to start the fight ;-) ...

1) What would you do with class methods that you cannot do with
   e.g. globals and functions ?

2) How would you determine which methods are class-only methods and
   which are one usable by instances ?

3) If you don't like globals (see 1), wouldn't it be possible to
   store the state you want to manipulate using class methods
   in some other context object ?

My impression is that class methods are not really needed and
would only make optimizing Python harder... but that's maybe just 
me ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From fdrake@acm.org  Fri Apr 20 16:34:41 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 20 Apr 2001 11:34:41 -0400 (EDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
 <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <15072.22289.218618.462955@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > __getattr__?), and I have no idea how to do this without dropping the
 > idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
 > solution?

  Can that be dropped and still allow subclasses to extend a method
offered by the base class?  I think making the two different would
break an enormous amount of code.


  -Fred

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



From thomas.heller@ion-tof.com  Fri Apr 20 16:40:21 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 17:40:21 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com>
Message-ID: <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>

> Here's something to start the fight ;-) ...
> 
> 1) What would you do with class methods that you cannot do with
>    e.g. globals and functions ?

I will write up a concrete example I have and post it later.

Look into the motivation for the Prototype Pattern in the GOF
book, or even better in the discussion of this pattern in the
'Design Pattern Smalltalk Companion' book.

This pattern is not needed if classes are 'first class' objects.

> 
> 2) How would you determine which methods are class-only methods and
>    which are one usable by instances ?
This is one of the issues which has to be resolved. I have no proposal
at the moment. (Maybe function attributes can help here?)

> 
> 3) If you don't like globals (see 1), wouldn't it be possible to
>    store the state you want to manipulate using class methods
>    in some other context object ?
I want the class methods (for example) to create and manipulate
this 'context object'. This object, however, belongs into the class...

What I want to avoid is

  class X(...):
      ....
  initialize(X)

> 
> My impression is that class methods are not really needed and
> would only make optimizing Python harder... but that's maybe just 
> me ;-)
Unfortunately not, I fear.

Thomas



From guido@digicool.com  Fri Apr 20 17:52:18 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 11:52:18 -0500
Subject: [Python-Dev] Class Methods
In-Reply-To: Your message of "Fri, 20 Apr 2001 17:40:21 +0200."
 <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com>
 <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>
Message-ID: <200104201652.LAA06554@cj20424-a.reston1.va.home.com>

> Look into the motivation for the Prototype Pattern in the GOF
> book, or even better in the discussion of this pattern in the
> 'Design Pattern Smalltalk Companion' book.

I imagine many of us (including yours truly :-) don't recall that in
enough detail and/or don't have the book handy to look it up, so would
you please do us a favor and explain this in a bit more detail?

> This pattern is not needed if classes are 'first class' objects.

Depending on what you mean by the 'first class' phrase (which means
something different to everyone), Python classes are already as first
class as they get.  E.g. they are tangible objects and you can pass
them around and store them in variables.

> What I want to avoid is
> 
>   class X(...):
>       ....
>   initialize(X)

What would initialize(X) do that you can't write in the class body?

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


From thomas.heller@ion-tof.com  Fri Apr 20 16:59:12 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 17:59:12 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>  <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <031b01c0c9b2$d79bfda0$e000a8c0@thomasnotebook>

> > Is someone willing to join me fighting
> > for class methods (I mean 'real' class-methods
> > in the Smalltalk style here, _not_ static
> > methods like in Java or C++).
> 
> I will fight class methods to the death. :-)
Ouch :-)

> 
> Seriously, I think you'll find an ally in Jim Fulton,
So there _is_ some hope.

>  who basically
> told me (since he's sort of my boss :-) to get on with this work.

This must be the reason that ExtensionClass provides them:
You can implement them in C, and override them in python
subclasses.

Thomas



From thomas.heller@ion-tof.com  Fri Apr 20 17:07:23 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 18:07:23 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com>              <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>  <200104201652.LAA06554@cj20424-a.reston1.va.home.com>
Message-ID: <034901c0c9b3$fcaa6bd0$e000a8c0@thomasnotebook>

> > Look into the motivation for the Prototype Pattern in the GOF
> > book, or even better in the discussion of this pattern in the
> > 'Design Pattern Smalltalk Companion' book.
> 
> I imagine many of us (including yours truly :-) don't recall that in
> enough detail and/or don't have the book handy to look it up, so would
> you please do us a favor and explain this in a bit more detail?
> 
This is a valid request, but please wait for my larger example.
I'm referring to this because I have not been good at explaining
the things I want...

All in all:

I'm not really ready to start the fight _now_, I was just
looking for some help...

Thomas

PS: I find it strange that everyone so far seems to be against it.



From barry@digicool.com  Fri Apr 20 17:13:07 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 20 Apr 2001 12:13:07 -0400
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>
Message-ID: <15072.24595.478099.658273@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido@digicool.com> writes:

    GvR> My question is: should I just merge this code onto the trunk
    GvR> (making it part of 2.2), or should we review the design more
    GvR> before committing to this implementation?

I would definitely like to play with this stuff so I'd be generally +1
at committing your changes to the trunk.  Let me make two comments.

First, Ping or Guido should update the PEP, especially to describe the
`non-controversial' parts (using .next(), StopIteration -- where's
this exception in the hierarchy, btw?).  You should also update the
Open Issues section.

Second, I'm still not totally comfortable with the "for keys:values in
dict" part of the proposal, especially with the elaboration of letting
either keys or values be missing.  An alternative, which I sure has
been raised, but which isn't in the PEP, is to allow an alternative
pseudo-keyword in the `in' position.  For example, allow "over" which
has the semantics when used with a dict of iterating over keys.items()
and when iterating over a sequence has the semantics of iterating over
zip(range(len(a)), a).  Thus only this would be allowed:

    for key, value over dict:

    for index, item over seq:

I think it would be fine if you don't support optional untupling parts
in the target.

-Barry


From barry@digicool.com  Fri Apr 20 17:36:26 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 20 Apr 2001 12:36:26 -0400
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
 <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <15072.25994.247806.815084@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido@digicool.com> writes:

    GvR> Let x be an object, C its class, and M C's class.  So,

    |   x.__class__ is C
    |   C.__class__ is M

    GvR> Then x's methods are described in C.__dict__, and C's methods
    GvR> are described in M.__dict__.

    GvR> The problem is that if you write C.spam, there could be two
    GvR> spams: one in C.__dict__, one in M.__dict__.  Which one to
    GvR> use?

If you use naming to generally distinguish, and have a lookup chain
that first found it in C.__dict__ and then looked in M.__dict__, you
could control what happens when the name is in both dicts by using a
more explicit lookup, e.g. C.__dict__['meth']
vs. C.__class__.__dict__['meth']

But maybe that's too ugly.
    
    GvR> How does Smalltalk resolve this?

I don't remember, but I do remember that ObjC had the same concepts,
and it used a distinguishing marker on the method definition to say
whether the method was a class method (`+') or instance method (`-'),
e.g.

    + void some_class_method ...
    - void an_instance_method

Another question: presumably when I write

    class Foo: pass

Foo is implicitly given the built-in metaclass M, but say I wanted to
define a class Foo with a different metaclass, how would I spell this?
I think at one point I suggested a semi-ugly syntactic hack, where
`class' was actually a namespace and you could add new metaclasses to
it.  So you could write something like

    class.WeirdClass Foo: pass

and now Foo's metaclass would be WeirdClass.

waiting-for-the-bottom-turtle-to-burp-ly y'rs,
-Barry


From jeremy@digicool.com  Fri Apr 20 18:00:09 2001
From: jeremy@digicool.com (Jeremy Hylton)
Date: Fri, 20 Apr 2001 13:00:09 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/ref ref3.tex,1.64,1.65 ref5.tex,1.43,1.44
In-Reply-To: <E14qe7G-0002AU-00@usw-pr-cvs1.sourceforge.net>
References: <E14qe7G-0002AU-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <15072.27417.366789.977575@slothrop.digicool.com>

>>>>> "GvR" == Guido van Rossum <gvanrossum@users.sourceforge.net> writes:

  GvR> Log Message: Implement, test and document "key in dict" and
  GvR> "key not in dict".

  GvR> I know some people don't like this -- if it's really
  GvR> controversial, I'll take it out again.  (If it's only Alex
  GvR> Martelli who doesn't like it, that doesn't count as "real
  GvR> controversial" though. :-)

I don't like it either, because it's only clear when it's spelled "for
key in dict".  It's pretty confusing when it's spelled "for val in
dict" or even "for x in dict".

But I'm willing to give it a try for a while.

Jeremy



From aahz@rahul.net  Fri Apr 20 18:08:53 2001
From: aahz@rahul.net (Aahz Maruch)
Date: Fri, 20 Apr 2001 10:08:53 -0700 (PDT)
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <15072.24595.478099.658273@anthem.wooz.org> from "Barry A. Warsaw" at Apr 20, 2001 12:13:07 PM
Message-ID: <20010420170853.ECA2C99C80@waltz.rahul.net>

Barry A. Warsaw wrote:
> 
> Second, I'm still not totally comfortable with the "for keys:values in
> dict" part of the proposal, especially with the elaboration of letting
> either keys or values be missing.  An alternative, which I sure has
> been raised, but which isn't in the PEP, is to allow an alternative
> pseudo-keyword in the `in' position.  For example, allow "over" which
> has the semantics when used with a dict of iterating over keys.items()
> and when iterating over a sequence has the semantics of iterating over
> zip(range(len(a)), a).  Thus only this would be allowed:
> 
>     for key, value over dict:
> 
>     for index, item over seq:

+1 from me, particularly the part about getting rid of "keys:values"; I
just see little advantage to using anything other than a tuple.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6       <*>       http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.


From Rainer Deyke" <root@rainerdeyke.com  Fri Apr 20 18:34:08 2001
From: Rainer Deyke" <root@rainerdeyke.com (Rainer Deyke)
Date: Fri, 20 Apr 2001 11:34:08 -0600
Subject: [Python-Dev] Re: Class Methods
References: <mailman.987779255.16686.python-list@python.org>
Message-ID: <027801c0c9c0$2e9081a0$070110ac@deyke.net>

"Thomas Heller" <thomas.heller@ion-tof.com> wrote in message
news:mailman.987779255.16686.python-list@python.org...
> There are some signs :-) that Python's object
> model is going to be revised even _before_
> Python 3000.
>
> Is someone willing to join me fighting
> for class methods (I mean 'real' class-methods
> in the Smalltalk style here, _not_ static
> methods like in Java or C++).

I posted this in another thread, but I think it bears repeating here.


I consider classes/instances a special case of namespaces: one which allows
(multiple) instantiation and inheritance.  In actual pratice not all of the
classes I design are designed for multiple instantiation, or instantiation
at all for that matter.  What I would like to see is a separation of
concerns ("Does this namespace have __special__ attributes for operator
overloading?" inpdependent from "Does this namespace require
instantiation?") followed by a culling of irrelevant features ("Don't want
operator overloading?  Don't name your function '__add__' then.").  The
resulting programming language might look something like this:

namespace A: # Create a named unique object
  pass
namespace B(A): # Similar to 'from ... import', but done through linking
                # instead of copying
class C(A): # 'class' = namespace that requires/supports instantiation
            # class inherits from namespace => functions in namespace
            # are treated as "static" functions
  pass
namespace D(C()): # namespace inherits from instance of class
  pass


The module itself would be a 'namespace' object.  Overall, I think this has
the potential of creating a much simpler and more regular language.
Separate keywords for 'class' and 'namespace' might even turn out to be
unnecessary.


In this context, class methods would either be automatically included, or
turn out to be truly redundant, or both.


--
Rainer Deyke (root@rainerdeyke.com)
Shareware computer games           -           http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor




From tim.one@home.com  Fri Apr 20 18:44:40 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 20 Apr 2001 13:44:40 -0400
Subject: [Python-Dev] Class Methods
In-Reply-To: <034901c0c9b3$fcaa6bd0$e000a8c0@thomasnotebook>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEJBJNAA.tim.one@home.com>

[Thomas Heller]
> ...
> PS: I find it strange that everyone so far seems to be against it.

I didn't get that sense yet.  I did get the sense they're not actively *for*
it yet, and the questions asked so far explain why:  What does it buy us?
What are the current alternatives?  What are the costs (not least of all in
terms of breaking existing code)?  It's a bunch of tradeoffs, and it appears
that few who aren't steeped in Smalltalk's view of the world understand what
the practical *attraction* is.

The same questions get asked even for wholly non-controversial changes, like,
say, adding an optional ">> file" clause to "print" <wink>.

by-default-it's-best-to-resist-everything-ly y'rs  - tim



From michel@digicool.com  Fri Apr 20 18:50:15 2001
From: michel@digicool.com (Michel Pelletier)
Date: Fri, 20 Apr 2001 10:50:15 -0700 (PDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>
Message-ID: <Pine.LNX.4.32.0104201039300.6561-100000@localhost.localdomain>


On Fri, 20 Apr 2001, Thomas Heller wrote:

> > Here's something to start the fight ;-) ...
> >
> > 1) What would you do with class methods that you cannot do with
> >    e.g. globals and functions ?
>
> I will write up a concrete example I have and post it later.

There are a number of reasons why I'm all for Class attributes in general.
For example, right now a class object cannot assert an interface.  Sure,
a class can say:

class Foo:

  __implements__ = Bar  # instances implement Bar

but that is an assertion for the instances, not the *class itself*.
Currently, you have to do the ugly hack:

class Foo:

  __class_implements__ = FooFactory # the class implements
                                    # FooFactory.

We've done things like the above in several places in our underground
component elaboration.  Not having class methods introduces many little
wrinkles in the Python object model that have to be worked around.  I can
imagine, for example, wanting to define an __reduce__, or __init__ for a
class object, which is not possible now.

> Look into the motivation for the Prototype Pattern in the GOF
> book, or even better in the discussion of this pattern in the
> 'Design Pattern Smalltalk Companion' book.
>
> This pattern is not needed if classes are 'first class' objects.
>
> >
> > 2) How would you determine which methods are class-only methods and
> >    which are one usable by instances ?
> This is one of the issues which has to be resolved. I have no proposal
> at the moment. (Maybe function attributes can help here?)

I always thought along the lines of saying Class.instanceAttribute('foo')
in the place of what is now said Class.foo.  This would, of course, break
code, but the warning and back to the future features mitigate most of
that risk.

> >
> > 3) If you don't like globals (see 1), wouldn't it be possible to
> >    store the state you want to manipulate using class methods
> >    in some other context object ?
> I want the class methods (for example) to create and manipulate
> this 'context object'. This object, however, belongs into the class...
>
> What I want to avoid is
>
>   class X(...):
>       ....
>   initialize(X)

Yes! We use this monstrosity a lot in Zope.

-Michel



From Donald Beaudry <donb@abinitio.com>  Fri Apr 20 19:07:09 2001
From: Donald Beaudry <donb@abinitio.com> (Donald Beaudry)
Date: Fri, 20 Apr 2001 14:07:09 -0400
Subject: [Python-Dev] Re: Class Methods
References: <mailman.987779255.16686.python-list@python.org> <027801c0c9c0$2e9081a0$070110ac@deyke.net>
Message-ID: <200104201807.OAA06589@localhost.localdomain>

"Thomas Heller" <thomas.heller@ion-tof.com> wrote,
> There are some signs :-) that Python's object
> model is going to be revised even _before_
> Python 3000.
>
> Is someone willing to join me fighting
> for class methods (I mean 'real' class-methods
> in the Smalltalk style here, _not_ static
> methods like in Java or C++).

A couple of years ago I did this as an extension module.  It might
still be around (I still use it).  Take a look for something called
objectmodule.  It's actually a mechanism for implementing different
object models from within python.  Beware, class methods are just part
of what it is capable of.

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb@init.com                                      Lexington, MA 02421
                  ...So much code, so little time...





From guido@digicool.com  Fri Apr 20 20:17:29 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 14:17:29 -0500
Subject: [Python-Dev] Re: Class Methods
In-Reply-To: Your message of "Fri, 20 Apr 2001 14:07:09 -0400."
 <200104201807.OAA06589@localhost.localdomain>
References: <mailman.987779255.16686.python-list@python.org> <027801c0c9c0$2e9081a0$070110ac@deyke.net>
 <200104201807.OAA06589@localhost.localdomain>
Message-ID: <200104201917.OAA11851@cj20424-a.reston1.va.home.com>

> A couple of years ago I did this as an extension module.  It might
> still be around (I still use it).  Take a look for something called
> objectmodule.  It's actually a mechanism for implementing different
> object models from within python.  Beware, class methods are just part
> of what it is capable of.

Hi Don!  I still remember some of the stuff you showed me 6.5 years
ago, and some of the ideas my *finally* find their way into Python...
Watch PEP 252!

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


From paul@pfdubois.com  Fri Apr 20 19:09:20 2001
From: paul@pfdubois.com (Paul F. Dubois)
Date: Fri, 20 Apr 2001 11:09:20 -0700
Subject: [Python-Dev] pydoc script
Message-ID: <ADEOIFHFONCLEEPKCACCGEGJCIAA.paul@pfdubois.com>

Ka-Ping,
Your pydoc script can fail because the pydoc executed is not the pydoc (and
therefore the python) in the users' current path if they start it explicitly
with a full path. I suggest a similar trick to this one:

#!/bin/csh -f
unsetenv PYTHONHOME
set bindir = `dirname $0`
set path=(${bindir} $path);rehash #in case of respawns, get our python
exec ${bindir}/python -O -c 'import browser;browser.tk_cdat.main()'




From Greg.Wilson@baltimore.com  Fri Apr 20 20:20:53 2001
From: Greg.Wilson@baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 15:20:53 -0400
Subject: [Python-Dev] string slicing and method consistency
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com>

One of the students in my class at the Space Telescope
Science Institute ("Hubble R Us") last week brought up
an interesting point: if "abbc"[-1] is "c", and if
"abbc".replace("b", "x", 1) is "axbc", then shouldn't
"abbc".replace("b", "x", -1) be "abxc" (i.e. negative
numbers replace the *last* occurrences of the value)?
Same argument for "split", etc.

Turns out that "abbc".replace("b", "x", -1) is "axxc"
(i.e. negative arguments are ignored).  I would have
expected this to raise a ValueError, if anything.  Is
there a reason for this behavior?  Is it worth making
replace, split, etc. interpret negative indices in the
same way as indexing does?

Thanks,
Greg



From ping@lfw.org  Fri Apr 20 20:57:56 2001
From: ping@lfw.org (Ka-Ping Yee)
Date: Fri, 20 Apr 2001 14:57:56 -0500 (CDT)
Subject: [Python-Dev] string slicing and method consistency
In-Reply-To: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com>
Message-ID: <Pine.LNX.4.10.10104201456460.24864-100000@server1.lfw.org>

On Fri, 20 Apr 2001, Greg Wilson wrote:
> Is it worth making
> replace, split, etc. interpret negative indices in the
> same way as indexing does?

I think this would be really cool in particular for split().
(And if it worked for split it would have to work for replace.)


-- ?!ng



From thomas.heller@ion-tof.com  Fri Apr 20 20:37:41 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 21:37:41 +0200
Subject: [Python-Dev] Re: Class Methods
References: <mailman.987779255.16686.python-list@python.org> <027801c0c9c0$2e9081a0$070110ac@deyke.net> <200104201807.OAA06589@localhost.localdomain>
Message-ID: <053901c0c9d1$5d8c2f70$e000a8c0@thomasnotebook>

> A couple of years ago I did this as an extension module.  It might
> still be around (I still use it).  Take a look for something called
> objectmodule.  It's actually a mechanism for implementing different
> object models from within python.  Beware, class methods are just part
> of what it is capable of.
> 
Thanks, Don.

I found it and will look into it.

Thomas



From thomas.heller@ion-tof.com  Fri Apr 20 20:51:28 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 21:51:28 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook><200104201626.LAA06384@cj20424-a.reston1.va.home.com> <15072.25994.247806.815084@anthem.wooz.org>
Message-ID: <055101c0c9d3$4a1b9d20$e000a8c0@thomasnotebook>

> >>>>> "GvR" == Guido van Rossum <guido@digicool.com> writes:
> 
>     GvR> Let x be an object, C its class, and M C's class.  So,
> 
>     |   x.__class__ is C
>     |   C.__class__ is M
> 
>     GvR> Then x's methods are described in C.__dict__, and C's methods
>     GvR> are described in M.__dict__.
> 
>     GvR> The problem is that if you write C.spam, there could be two
>     GvR> spams: one in C.__dict__, one in M.__dict__.  Which one to
>     GvR> use?
> 
[Barry wrote]
> If you use naming to generally distinguish, and have a lookup chain
> that first found it in C.__dict__ and then looked in M.__dict__, you
> could control what happens when the name is in both dicts by using a
> more explicit lookup, e.g. C.__dict__['meth']
> vs. C.__class__.__dict__['meth']
> 

Couldn't be C.__class__.meth be used?

> But maybe that's too ugly.
>     
>     GvR> How does Smalltalk resolve this?
I'm walking on thin ice here (maybe I should better try it out),
but IIRC Smalltalk requires to explicit:

    self class method;
or
    self method;

> Another question: presumably when I write
> 
>     class Foo: pass
> 
> Foo is implicitly given the built-in metaclass M, but say I wanted to
> define a class Foo with a different metaclass, how would I spell this?
> I think at one point I suggested a semi-ugly syntactic hack, where
> `class' was actually a namespace and you could add new metaclasses to
> it.  So you could write something like
> 
>     class.WeirdClass Foo: pass
> 
> and now Foo's metaclass would be WeirdClass.
Thin ice again I'm on here (even more), but I have the impression
that creating a class Point in Smalltalk _automatically_ creates
two classes: Point and PointClass. The latter is normally hidden
(but contains the class methods of Point as instance methods).

Thomas



From Greg.Wilson@baltimore.com  Fri Apr 20 21:07:26 2001
From: Greg.Wilson@baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 16:07:26 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D1E7@nsamcanms1.ca.baltimore.com>

> > Thomas Heller:
> > PS: I find it strange that everyone so far seems to be against it.

> Tim Peters:
> I didn't get that sense yet.  I did get the sense they're not 
> actively *for* it yet, and the questions asked so far explain why:
> What does it buy us?

Greg Wilson:
I'd really like class methods so that my classes can carry their
factory methods around with them, and so that these factories can
be selectively overridden in derived classes.  I have machinery
to do all of this using freestanding functions, but it's clumsy
and error-prone.  Of course, so is a lot of my code... :-)


From michel@digicool.com  Fri Apr 20 21:32:43 2001
From: michel@digicool.com (Michel Pelletier)
Date: Fri, 20 Apr 2001 13:32:43 -0700 (PDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.32.0104201310270.6561-100000@localhost.localdomain>

On Fri, 20 Apr 2001, Guido van Rossum wrote:

> Let x be an object, C its class, and M C's class.  So,
>
>   x.__class__ is C
>   C.__class__ is M
>
> Then x's methods are described in C.__dict__, and C's methods are
> described in M.__dict__.
>
> The problem is that if you write C.spam, there could be two spams: one
> in C.__dict__, one in M.__dict__.  Which one to use?

I think, at the expense of breaking code, M.

> How does
> Smalltalk resolve this?  The problem is that for backwards
> compatibility, at lease, C.spam must be the unbound version of x.spam,
> because currently x.spam(...) can always also be written as
> C.spam(x, ...).

This is the part that choosing M would break.  To get at C's shared
instance attributes you could say something like
C.instanceAttribute('spam')(x, ...).

Yes, it's ugly.  Perhaps someone can think of a more elegant spelling?

> For regular methods it may be possible to avoid this simply by
> choosing non-conflicting names, but I seem to recall that Jim wanted
> to use class methods with certain special names (like __init__ or
> __getattr__?), and I have no idea how to do this without dropping the
> idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
> solution?

I'm not sure which idea you are talking about dropping, the first argument
binding behavior, or the spelling of getting shared instance attributes
from a class (C.spam).  Just asking to make sure, cuz I don't think the
first needs to change, just the spelling.

BTW, you sent me some comments on the Components and Interfaces chapter
of the Zope Developer's Guide where you noted that attributes of interface
objects are not the attributes described by the interface and that this is
"unfamiliar to the typical python programmer", ie:

  interface Hello:

    def hello(name):
      """ say hello to a name """

does not create a 'Hello.hello'.  Instead, you need to say
"Hello.getDescriptionFor('hello')".  If we chose the more familiar
'Hello.hello' then the interface interface would be seriously limited, and
any added functionality would need to be imported from an external module
or be a builtin like isinstance().  Interfaces, like classes, wouldn't be
able to have their own methods.

-Michel










From tim.one@home.com  Fri Apr 20 21:40:27 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 20 Apr 2001 16:40:27 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
In-Reply-To: <930BBCA4CEBBD411BE6500508BB3328F22D1E7@nsamcanms1.ca.baltimore.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com>

[Greg Wilson]
> I'd really like class methods so that my classes can carry their
> factory methods around with them, and so that these factories can
> be selectively overridden in derived classes.

Without a concrete example it's risky to guess, but that sounds more like
class static (in C++ terms) methods to me.  "class methods" in *this* thread
is being used in a Smalltalk sense (because it's Thomas Heller's thread, and
he made clear that he doesn't want C++-style class statics).  And, yes,
without a concrete example, it's risky to guess what that means too <wink>.

expecting-a-long-thread-full-of-misinterpreted-words-ly y'rs  - tim



From guido@digicool.com  Fri Apr 20 22:48:06 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 16:48:06 -0500
Subject: [Python-Dev] string slicing and method consistency
In-Reply-To: Your message of "Fri, 20 Apr 2001 15:20:53 -0400."
 <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com>
References: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com>
Message-ID: <200104202148.QAA13960@cj20424-a.reston1.va.home.com>

[GVW]
> One of the students in my class at the Space Telescope
> Science Institute ("Hubble R Us") last week brought up
> an interesting point: if "abbc"[-1] is "c", and if
> "abbc".replace("b", "x", 1) is "axbc", then shouldn't
> "abbc".replace("b", "x", -1) be "abxc" (i.e. negative
> numbers replace the *last* occurrences of the value)?
> Same argument for "split", etc.
> 
> Turns out that "abbc".replace("b", "x", -1) is "axxc"
> (i.e. negative arguments are ignored).  I would have
> expected this to raise a ValueError, if anything.  Is
> there a reason for this behavior?  Is it worth making
> replace, split, etc. interpret negative indices in the
> same way as indexing does?

Dubious hypergeneralization.  The thing is that this parameter, called
maxsplit, is not really an index -- it's a count.

Implementing this right would be tricky, because you'd really have to
search for matches from the end (in order to make sense if there are
overlapping matches possible, as in "abbbc".replace("bb", "BB", -1)).

Where would this be useful?  Is it ever useful for numbers smaller
than -1?  If all you typically want is replace the last occurrence,
the rfind() method is your friend.

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


From Greg.Wilson@baltimore.com  Fri Apr 20 22:08:31 2001
From: Greg.Wilson@baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 17:08:31 -0400
Subject: [Python-Dev] re: string slicing and method consistency
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D1F5@nsamcanms1.ca.baltimore.com>

> > Greg Wilson:
> > if "abbc"[-1] is "c", and if
> > "abbc".replace("b", "x", 1) is "axbc", then shouldn't
> > "abbc".replace("b", "x", -1) be "abxc" (i.e. negative
> > numbers replace the *last* occurrences of the value)?
> > Same argument for "split", etc.

> Guido van Rossum:
> Dubious hypergeneralization.

Greg Wilson:
Do you have an editor macro set up yet to generate that
phrase? :-)

> Guido van Rossum:
> The thing is that this parameter,
> called maxsplit, is not really an index -- it's a count.

Greg Wilson:
Understood; I'm asking whether changing its name and
interpretation (in a way that doesn't break any existing
code) would be worthwhile:

    >>> path = "/some/long/path/to/file.html"
    >>> main, parent, file = path.split("/", -2)
    >>> main
    "/some/long/path"
    >>> parent
    "to"
    >>> file
    "file.html"

> > Greg Wilson:
> > Turns out that "abbc".replace("b", "x", -1) is "axxc"
> > (i.e. negative arguments are ignored).  I would have
> > expected this to raise a ValueError, if anything.  Is
> > there a reason for this behavior?

Greg Wilson again:
Question still stands --- if these are counts, then shouldn't
negative values raise exceptions?

Thanks,
Greg


From guido@digicool.com  Fri Apr 20 23:19:50 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 17:19:50 -0500
Subject: [Python-Dev] re: string slicing and method consistency
In-Reply-To: Your message of "Fri, 20 Apr 2001 17:08:31 -0400."
 <930BBCA4CEBBD411BE6500508BB3328F22D1F5@nsamcanms1.ca.baltimore.com>
References: <930BBCA4CEBBD411BE6500508BB3328F22D1F5@nsamcanms1.ca.baltimore.com>
Message-ID: <200104202219.RAA14666@cj20424-a.reston1.va.home.com>

> > Guido van Rossum:
> > Dubious hypergeneralization.
> 
> Greg Wilson:
> Do you have an editor macro set up yet to generate that
> phrase? :-)

No, I actually know how to spell that. :-)

> Greg Wilson:
> Understood; I'm asking whether changing its name and
> interpretation (in a way that doesn't break any existing
> code) would be worthwhile:
> 
>     >>> path = "/some/long/path/to/file.html"
>     >>> main, parent, file = path.split("/", -2)
>     >>> main
>     "/some/long/path"
>     >>> parent
>     "to"
>     >>> file
>     "file.html"

OK, that's an example.  It's only so-so, because you should be using
os.path.split() anyway.  It's done best as follows:

  temp, file = os.path.split(path)
  main, parent = os.path.split(temp)

> > > Greg Wilson:
> > > Turns out that "abbc".replace("b", "x", -1) is "axxc"
> > > (i.e. negative arguments are ignored).  I would have
> > > expected this to raise a ValueError, if anything.  Is
> > > there a reason for this behavior?
> 
> Greg Wilson again:
> Question still stands --- if these are counts, then shouldn't
> negative values raise exceptions?

Given that it's documented with the name "maxsplit", it's not
unreasonable that -1 is treated the same as 0.

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


From Donald Beaudry <donb@abinitio.com>  Fri Apr 20 22:19:56 2001
From: Donald Beaudry <donb@abinitio.com> (Donald Beaudry)
Date: Fri, 20 Apr 2001 17:19:56 -0400
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook><200104201626.LAA06384@cj20424-a.reston1.va.home.com> <15072.25994.247806.815084@anthem.wooz.org> <055101c0c9d3$4a1b9d20$e000a8c0@thomasnotebook>
Message-ID: <200104202119.RAA08382@localhost.localdomain>

"Thomas Heller" <thomas.heller@ion-tof.com> wrote,
> > >>>>> "GvR" == Guido van Rossum <guido@digicool.com> writes:
> > 
> >     GvR> Let x be an object, C its class, and M C's class.  So,
> > 
> >     |   x.__class__ is C
> >     |   C.__class__ is M
> > 
> >     GvR> Then x's methods are described in C.__dict__, and C's methods
> >     GvR> are described in M.__dict__.
> > 
> >     GvR> The problem is that if you write C.spam, there could be two
> >     GvR> spams: one in C.__dict__, one in M.__dict__.  Which one to
> >     GvR> use?

In my 'objectmodule' I adopted a concept which I refer to as the
"unbound instance".  That is, I invented an object which is used as a
proxy for accessing instance attributes.  It looks like an instance
but only for the purposes of attribute access.  Now, since this object
will only return "unbound method objects" when accessing a method (as
opposed to the "bound method object" you would get when accessing a
method from a real instance) I thought the name was at least slightly
appropriate.  In short, each class defined by the objectmodule has a
special attribute '_' which is the "unbound instance" for that class.
This unbound instance is used to resolve the name ambiguity.  Now,
consider this:

    import object

    class foo(object.base):
        def frob(self):
            print "I've been frobbed", self

        class __class__:
            def frob(cl):
                print "No, I've been frobbed", cl


    >>> f = foo()
    >>> x = f.frob
    >>> # x is the instance frob method bound to f
    >>> y = foo.frob
    >>> # y is the class frob method bound to foo
    >>> z = foo._.frob
    >>> # z is the instance frob method but is not bound to any instance
    >>> huh = foo.__class__._.frob
    >>> # huh is the class frob method but is not bound to any class
    >>>        

> Thin ice again I'm on here (even more), but I have the impression
> that creating a class Point in Smalltalk _automatically_ creates two
> classes: Point and PointClass. The latter is normally hidden (but
> contains the class methods of Point as instance methods).

That's the way I remember it too.  And, (if I recall correctly) in
SmallTalk (unlike CLOS), you have no control over the meta-class.  In
the example above, like in SmallTalk, the name of foo.__class__ is
determined automatically.  In this case it is 'foo_class'.  However,
unlike SmallTalk, the above example could be extended to include a
'class __class__:' definition under the existing 'class __class__:'.
The name generated by this construct would, of course, be
'foo_class_class'.  Lather, Rinse, repeat...

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb@init.com                                      Lexington, MA 02421
                      ...Will hack for sushi...


From moshez@zadka.site.co.il  Sat Apr 21 01:32:57 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Sat, 21 Apr 2001 03:32:57 +0300
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
References: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>, <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
Message-ID: <E14qlKb-0005G4-00@darjeeling>

On Fri, 20 Apr 2001 11:26:01 -0500, Guido van Rossum <guido@digicool.com> wrote:
 
> For regular methods it may be possible to avoid this simply by
> choosing non-conflicting names, but I seem to recall that Jim wanted
> to use class methods with certain special names (like __init__ or
> __getattr__?), and I have no idea how to do this without dropping the
> idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
> solution?

class A:

    def __init__(self):
        self.spam = 1

class B:

    def __init__(self):
        A.__init__(self)
        self.eggs = 2

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez@debian.org  |http://www.{python,debian,gnu}.org


From Jason.Tishler@dothill.com  Sat Apr 21 01:50:58 2001
From: Jason.Tishler@dothill.com (Jason Tishler)
Date: Fri, 20 Apr 2001 20:50:58 -0400
Subject: [Python-Dev] Re: Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <Pine.LNX.4.21.0104201933470.11150-100000@clarkevans.com>; from cce@clarkevans.com on Fri, Apr 20, 2001 at 07:37:01PM -0500
References: <20010417151219.T275@dothill.com> <Pine.LNX.4.21.0104201933470.11150-100000@clarkevans.com>
Message-ID: <20010420205058.A1403@dothill.com>

On Fri, Apr 20, 2001 at 07:37:01PM -0500, Clark C. Evans wrote:
> On Tue, 17 Apr 2001, Jason Tishler wrote:
> > I have contributed Python to the standard Cygwin distribution.  Cygwin
> > Python is located in the contrib/python directory on the Cygwin mirrors.
> > Cygwin's setup.exe will automatically install Cygwin Python the next
> > time one installs or updates from a mirror.
> 
> This is interesting.  From what I understand, if you link
> against cygwin.dll, the software must be released under
> the GPL.  Thus, is the licensing debate over?  Do you
> have the right to re-license python under the GPL? Or am
> I missing something fundmental here? 
> 
> $ objdump -p python2.1.exe | grep DLL
>  vma:            Hint    Time      Forward  DLL       First
>         DLL Name: KERNEL32.dll
>         DLL Name: cygwin1.dll
>         DLL Name: libpython2.1.dll
> 
> Sorry to bring this up... I'm just curious.

Clark brings up a valid point.  Did I screw up from a licensing point
of view?

I found the following on the Python web site:

    However, we expect that Python 2.0 and later versions, released by
    BeOpen PythonLabs, will be released under a GPL-compatible license.

IANAL, any guidance regarding this matter would be greatly appreciated.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com


From tim.one@home.com  Sat Apr 21 02:32:05 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 20 Apr 2001 21:32:05 -0400
Subject: [Python-Dev] Re: Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <20010420205058.A1403@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOELBJNAA.tim.one@home.com>

[Clark C. Evans]
> This is interesting.  From what I understand, if you link
> against cygwin.dll, the software must be released under
> the GPL.  Thus, is the licensing debate over?  Do you
> have the right to re-license python under the GPL? Or am
> I missing something fundmental here?

[Jason Tishler]
> Clark brings up a valid point.  Did I screw up from a licensing point
> of view?
>
> I found the following on the Python web site:
>
>   However, we expect that Python 2.0 and later versions, released
>   by BeOpen PythonLabs, will be released under a GPL-compatible
>   license.

According to CNRI's and BeOpen's lawyers, it was; according to the FSF's Eben
Moglen, it was not.

> IANAL,

Ditto, and I'm worn out trying to divine the FSF's position.  Since you're in
no danger of violating *our* license, I'm afraid we're the wrong people to
ask.  If you can get a straight answer out of the FSF, more power to you.

> any guidance regarding this matter would be greatly appreciated.

In this specific case, you may be able to cut it short:

    http://www.cygwin.com/licensing.html

According to that, they use the GPL, but ammend it according to GPL section
10:

    In accordance with section 10 of the GPL, Cygnus permits
    programs whose sources are distributed under a license that
    complies with the Open Source definition to be linked with
    libcygwin.a without libcygwin.a itself causing the resulting
    program to be covered by the GNU GPL.

    This means that you can port an Open Source(tm) application
    to cygwin, and distribute that executable as if it didn't
    include a copy of libcygwin.a linked into it. Note that this
    does not apply to the cygwin DLL itself. If you distribute a
    (possibly modified) version of the DLL you must adhere to the
    terms of the GPL, i.e., you must provide sources for the cygwin
    DLL.

There's no controversy over whether all Python licenses to date are Open
Source -- they are.  There's also no problem from the POV of the *Python*
license if you want to relicense Cygwin Python under the GPL.  Fine by us!
The only relevant party with a complaint against you *may* be the FSF.




From tim.one@home.com  Sat Apr 21 08:51:09 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 21 Apr 2001 03:51:09 -0400
Subject: [Python-Dev] Importing DLLs on Windows
In-Reply-To: <3ADE1A5F.F574B613@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMAJNAA.tim.one@home.com>

Sorry for the delay -- I had a hard time understanding what this writeup
meant, so had to download the package and try it.

[M.-A. Lemburg]
> Python or Windows seems to have trouble importing DLLs when
> inside packages. I'm working on an extension which pulls in a
> DLL gmp31.dll which lives inside a package dir mx/Number/mxNumber
> along side the Python wrapper extension mxNumber.pyd.

Concretely, I have these files now, under my Python 2.1 installation
directory:

C:\Python21>dir/b/on mx\Number\mxNumber
gmp31.dll
mxNumber.pyd
mxNumber.h
test.py
__init__.py

C:\Python21>

> Currently, I'm using this code in the subpackage's __init__.py:

And by "the subpackage" here I believe you mean the tail-end mxNumber
directory, previously called "a package".  IOW, you're talking specifically
about

    \Python21\mx\Number\mxNumber\__init__.py

If you meant something else, scream.

> # On Windows we also distribute the GMP DLL (in the win32 subdir). To
> # have Win32 find the DLL we need to be explicit about the path in
> # sys.path though. This trick works for all startup directories
> # *except* \PythonXX (for some reason this fails), but is not thread
> # safe...
> import sys, os
> if sys.platform[:3] == 'win':
>     abspath = os.path.abspath(__path__[0])
>     sys.path.insert(0, abspath)
>     from mxNumber import *
>     sys.path.remove(abspath)
>
> else:
>     from mxNumber import *

> I don't have any clue why the import works

Which import are you talking about?  Please show exactly what you do that
fails -- I haven't been able to find any problem here.  For example, I
replaced

    \Python21\mx\Number\mxNumber\__init__.py

which contains the code you showed above, with this two-liner:

from mxNumber import *
from mxNumber import __version__

Having done that, here's a shell session started in the installation
directory, and after a reboot "just to make sure":

C:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> from mx.Number import *
>>> Integer(928349238479328749L)**2
861832308585149602001042573617905001
>>>

So nothing failed.  What do *you* do that fails?  Here's another session
started from a "random" directory:

C:\Code>\python21\python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> from mx.Number import *
>>> Integer(92387498327493243879L)**2
8535449847212566935021074270390170966641
>>>

Same thing.

> from everywhere *except* the Python21 install directory...

It would more helpful to name a specific directory than to make an untrue
claim <wink -- but you didn't try every directory other than Python21, and
the specific directories you actually did try may be important>.

BTW, it's a mondo cool package!  I had a lot of fun with it.  But then I was
able to, since I stopped trying to guess what your problem was <wink>.
What's up?  I was running Win98SE in the above, but that shouldn't make a
difference.  Perhaps, during development, you left crap sitting around in
your installation directory that's confusing your attempts to import things?
If not, please be very explicit about what you do that fails, and what
"fails" means (crash, ImportError, Windows error box, ...?).



From tim.one@home.com  Sat Apr 21 10:51:42 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 21 Apr 2001 05:51:42 -0400
Subject: [Python-Dev] Suirprise!
Message-ID: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com>

I just stared at this a long time:

>>> 'a' in 'a'  # fine
1
>>> 'a' in 'a' == 1  # what?
0
>>> 'a' in 'b'  # fine
0
>>> 'a' in 'b' == 0  # what?
0
>>>

It's "correct".  I've been using Python longer than Guido <wink>, and I'm
amazed this is the first time I got bit by this!  Here's a hint:

>>> 'a' in 'a' == 'a'
1
>>>

thank-god-for-dis.dis-ly y'rs  - tim



From martin@loewis.home.cs.tu-berlin.de  Sat Apr 21 10:51:56 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 21 Apr 2001 11:51:56 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
Message-ID: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de>

Currently, a number of routines assume that the result of
PyUnicode_FromUnicode can be modified, i.e. they mutate the resulting
unicode object. Look at unicodeobject.c:fixup for an example, and
assume that fixfct is fixtitle (*).

This is different from PyString_FromStringAndSize, whose result can be
only modified if the str argument is NULL.

These routines broke after I applied my caching patch, since now
PyUnicode_FromUnicode may return an existing string.

Is that difference intentional? My feeling is that it is an error to
modify a unicode object, unless it is known not to be initialized.

Regards,
Martin

P.S. This was actually the first failure case when running
test_unicodedata under my patch.


From mal@lemburg.com  Sat Apr 21 11:35:00 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 12:35:00 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEMAJNAA.tim.one@home.com>
Message-ID: <3AE16254.FFE9ADF7@lemburg.com>

Tim Peters wrote:
> 
> Sorry for the delay -- I had a hard time understanding what this writeup
> meant, so had to download the package and try it.

Oh, sorry that I wasn't clear enough. Referring to the mxNumber
package, I am seeing this situation:

# This works... (note the start directory)

C:\WINDOWS>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>

# This doesn't.... (from the Python install directory)

D:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "d:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "d:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
    from mxNumber import *
ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser Anwendung notwen
dige Bibliothekdateien kann nicht gefunden werden.
>>>

# OTOH, this works.... (one level below the Python install directory)

D:\Python21>cd mx

D:\Python21\mx>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>>
 
> [M.-A. Lemburg]
> > Python or Windows seems to have trouble importing DLLs when
> > inside packages. I'm working on an extension which pulls in a
> > DLL gmp31.dll which lives inside a package dir mx/Number/mxNumber
> > along side the Python wrapper extension mxNumber.pyd.
> 
> Concretely, I have these files now, under my Python 2.1 installation
> directory:
> 
> C:\Python21>dir/b/on mx\Number\mxNumber
> gmp31.dll
> mxNumber.pyd
> mxNumber.h
> test.py
> __init__.py
> 
> C:\Python21>
> 
> > Currently, I'm using this code in the subpackage's __init__.py:
> 
> And by "the subpackage" here I believe you mean the tail-end mxNumber
> directory, previously called "a package".  IOW, you're talking specifically
> about
> 
>     \Python21\mx\Number\mxNumber\__init__.py

Right.
 
> If you meant something else, scream.
>
> > # On Windows we also distribute the GMP DLL (in the win32 subdir). To
> > # have Win32 find the DLL we need to be explicit about the path in
> > # sys.path though. This trick works for all startup directories
> > # *except* \PythonXX (for some reason this fails), but is not thread
> > # safe...
> > import sys, os
> > if sys.platform[:3] == 'win':
> >     abspath = os.path.abspath(__path__[0])
> >     sys.path.insert(0, abspath)
> >     from mxNumber import *
> >     sys.path.remove(abspath)
> >
> > else:
> >     from mxNumber import *
> 
> > I don't have any clue why the import works
> 
> Which import are you talking about?  Please show exactly what you do that
> fails -- I haven't been able to find any problem here.  For example, I
> replaced
> 
>     \Python21\mx\Number\mxNumber\__init__.py
> 
> which contains the code you showed above, with this two-liner:
> 
> from mxNumber import *
> from mxNumber import __version__
> 
> Having done that, here's a shell session started in the installation
> directory, and after a reboot "just to make sure":
> 
> C:\Python21>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> from mx.Number import *
> >>> Integer(928349238479328749L)**2
> 861832308585149602001042573617905001
> >>>
> 
> So nothing failed. 

Hmm, you are right, it does work for me too (I wonder why I
thought it failed without the sys.path tweaking... probably
just tested from the Python install dir):

C:\WINDOWS>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>
C:\WINDOWS>d:

D:\Python21\mx>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>
D:\Python21\mx>cd ..

D:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "d:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "d:\python21\mx\Number\mxNumber\__init__.py", line 11, in ?
    from mxNumber import *
ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser Anwendung notwen
dige Bibliothekdateien kann nicht gefunden werden.
>>>

> What do *you* do that fails?  Here's another session
> started from a "random" directory:
> 
> C:\Code>\python21\python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> from mx.Number import *
> >>> Integer(92387498327493243879L)**2
> 8535449847212566935021074270390170966641
> >>>
> 
> Same thing.
> 
> > from everywhere *except* the Python21 install directory...
> 
> It would more helpful to name a specific directory than to make an untrue
> claim <wink -- but you didn't try every directory other than Python21, and
> the specific directories you actually did try may be important>.

Ok, ok ;-)

Please try starting Python from your Python install dir and
then do the import. BTW, I'm doing this on Windows 95 in case
this matters (which I'm sure it does :-/).
 
> BTW, it's a mondo cool package!  I had a lot of fun with it. 

Thanks :)

> But then I was
> able to, since I stopped trying to guess what your problem was <wink>.
> What's up?  I was running Win98SE in the above, but that shouldn't make a
> difference.  Perhaps, during development, you left crap sitting around in
> your installation directory that's confusing your attempts to import things?
> If not, please be very explicit about what you do that fails, and what
> "fails" means (crash, ImportError, Windows error box, ...?).

"fail" means that Python cannot find the gmp31.dll sitting right
next to the mxNumber.pyd in the same directory. This should normally
work, but somehow doesn't when Python is started from the install
dir:

>>> import mx.Number
import mx # directory mx
# trying mx\__init__.pyd
# trying mx\__init__.dll
# trying mx\__init__.py
# mx\__init__.pyc matches mx\__init__.py
import mx # precompiled from mx\__init__.pyc
import mx.Number # directory mx\Number
# trying mx\Number\__init__.pyd
# trying mx\Number\__init__.dll
# trying mx\Number\__init__.py
# mx\Number\__init__.pyc matches mx\Number\__init__.py
import mx.Number # precompiled from mx\Number\__init__.pyc
# trying mx\Number\Number.pyd
# trying mx\Number\Number.dll
# trying mx\Number\Number.py
# mx\Number\Number.pyc matches mx\Number\Number.py
import mx.Number.Number # precompiled from mx\Number\Number.pyc
import mx.Number.mxNumber # directory mx\Number\mxNumber
# trying mx\Number\mxNumber\__init__.pyd
# trying mx\Number\mxNumber\__init__.dll
# trying mx\Number\mxNumber\__init__.py
# mx\Number\mxNumber\__init__.pyc matches mx\Number\mxNumber\__init__.py
import mx.Number.mxNumber # precompiled from mx\Number\mxNumber\__init__.pyc
# trying mx\Number\mxNumber\mxNumber.pyd
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "d:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "d:\python21\mx\Number\mxNumber\__init__.py", line 11, in ?
    from mxNumber import *
ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser Anwendung notwen
dige Bibliothekdateien kann nicht gefunden werden.
>>>

>From C:\WINDOWS there's no problem:

import mx # directory d:\python21\mx
# trying d:\python21\mx\__init__.pyd
# trying d:\python21\mx\__init__.dll
# trying d:\python21\mx\__init__.py
# d:\python21\mx\__init__.pyc matches d:\python21\mx\__init__.py
import mx # precompiled from d:\python21\mx\__init__.pyc
import mx.Number # directory d:\python21\mx\Number
# trying d:\python21\mx\Number\__init__.pyd
# trying d:\python21\mx\Number\__init__.dll
# trying d:\python21\mx\Number\__init__.py
# d:\python21\mx\Number\__init__.pyc matches d:\python21\mx\Number\__init__.py
import mx.Number # precompiled from d:\python21\mx\Number\__init__.pyc
# trying d:\python21\mx\Number\Number.pyd
# trying d:\python21\mx\Number\Number.dll
# trying d:\python21\mx\Number\Number.py
# d:\python21\mx\Number\Number.pyc matches d:\python21\mx\Number\Number.py
import mx.Number.Number # precompiled from d:\python21\mx\Number\Number.pyc
import mx.Number.mxNumber # directory d:\python21\mx\Number\mxNumber
# trying d:\python21\mx\Number\mxNumber\__init__.pyd
# trying d:\python21\mx\Number\mxNumber\__init__.dll
# trying d:\python21\mx\Number\mxNumber\__init__.py
# d:\python21\mx\Number\mxNumber\__init__.pyc matches d:\python21\mx\Number\mxNu
mber\__init__.py
import mx.Number.mxNumber # precompiled from d:\python21\mx\Number\mxNumber\__in
it__.pyc
# trying d:\python21\mx\Number\mxNumber\mxNumber.pyd
import mx.Number.mxNumber.mxNumber # dynamically loaded from d:\python21\mx\Numb
er\mxNumber\mxNumber.pyd
>>>

Could this have something to do with absolute search paths (these
work) vs. relative ones (these don't) ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From guido@digicool.com  Sat Apr 21 12:42:09 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 21 Apr 2001 06:42:09 -0500
Subject: [Python-Dev] Suirprise!
In-Reply-To: Your message of "Sat, 21 Apr 2001 05:51:42 -0400."
 <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com>
Message-ID: <200104211142.GAA17114@cj20424-a.reston1.va.home.com>

> I just stared at this a long time:
> 
> >>> 'a' in 'a'  # fine
> 1
> >>> 'a' in 'a' == 1  # what?
> 0
> >>> 'a' in 'b'  # fine
> 0
> >>> 'a' in 'b' == 0  # what?
> 0
> >>>
> 
> It's "correct".  I've been using Python longer than Guido <wink>, and I'm
> amazed this is the first time I got bit by this!  Here's a hint:
> 
> >>> 'a' in 'a' == 'a'
> 1
> >>>
> 
> thank-god-for-dis.dis-ly y'rs  - tim

Yeah, I ran into the same when converting some has_key() tests to
using 'in'.  I guess it's not very common since nobody in their right
minds should want to compare the result of an 'in' test to anything
else.  The has_key() tests did something like "assert d.has_key(k)==1"
and the mindless translation of that is "assert k in d == 1"...

Didn't-need-dis-though-ly y'rs,

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


From mal@lemburg.com  Sat Apr 21 11:43:10 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 12:43:10 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de>
Message-ID: <3AE1643E.28E41AC2@lemburg.com>

"Martin v. Loewis" wrote:
> 
> Currently, a number of routines assume that the result of
> PyUnicode_FromUnicode can be modified, i.e. they mutate the resulting
> unicode object. Look at unicodeobject.c:fixup for an example, and
> assume that fixfct is fixtitle (*).

This is true for the APIs in unicodeobject.c: as long as the newly
created object hasn't "left" the Unicode implementation, the APIs
in there are free to modify the otherwise immutable object.
 
> This is different from PyString_FromStringAndSize, whose result can be
> only modified if the str argument is NULL.
> 
> These routines broke after I applied my caching patch, since now
> PyUnicode_FromUnicode may return an existing string.
> 
> Is that difference intentional? My feeling is that it is an error to
> modify a unicode object, unless it is known not to be initialized.

It is an error, but only for code outside the implementation, i.e.
programs using the public API may only modify the contents when
calling PyUnicode_FromUnicode() with NULL as u argument.

Sorry for not remembering this when reviewing your patch on SF.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From paulp@ActiveState.com  Sat Apr 21 11:48:08 2001
From: paulp@ActiveState.com (Paul Prescod)
Date: Sat, 21 Apr 2001 03:48:08 -0700
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com>
Message-ID: <3AE16568.79763FDD@ActiveState.com>

Tim Peters wrote:
> 
>...
> 
> >>> 'a' in 'a' == 'a'
> 1
> >>>
> 
> thank-god-for-dis.dis-ly y'rs  - tim

[potential spoilers below]

No, thank Jeremy for Compiler:

Module(None, 
    Stmt(
        [
            Printnl(
                [
                    Compare(Const('a'), 
                        [
                            ('in', Const('abcde')), 
                            ('==', Const('abcde'))
                        ]
                    )
                ], 
                None
            )
        ]
    )
)

It still took a look at the ref manual for me to figure it out.

It looks like dubious hypergeneralization to me! <0.7 wink> Seriously,
does this "feature" ever make sense to apply to the in operator?

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook


From Jason.Tishler@dothill.com  Sat Apr 21 12:43:12 2001
From: Jason.Tishler@dothill.com (Jason Tishler)
Date: Sat, 21 Apr 2001 07:43:12 -0400
Subject: [Python-Dev] Re: Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOELBJNAA.tim.one@home.com>; from tim.one@home.com on Fri, Apr 20, 2001 at 09:32:05PM -0400
References: <20010420205058.A1403@dothill.com> <LNBBLJKPBEHFEDALKOLCOELBJNAA.tim.one@home.com>
Message-ID: <20010421074312.B351@dothill.com>

Tim,

Thanks for your assessment of the situation.  I'm forwarding your
email to the Cygwin list to see what they have to say.  Your help is
much appreciated.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com


From martin@loewis.home.cs.tu-berlin.de  Sat Apr 21 13:07:14 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 21 Apr 2001 14:07:14 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
In-Reply-To: <3AE1643E.28E41AC2@lemburg.com> (mal@lemburg.com)
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com>
Message-ID: <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de>

> This is true for the APIs in unicodeobject.c: as long as the newly
> created object hasn't "left" the Unicode implementation, the APIs
> in there are free to modify the otherwise immutable object.

That means that PyUnicode_FromUnicode does give a guarantee to return
a fresh object, right?

Then I cannot understand why it only gives this guarantee to callers
inside unicodeobject.c, and not to other callers...

Regards,
Martin


From mal@lemburg.com  Sat Apr 21 14:15:00 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 15:15:00 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com> <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de>
Message-ID: <3AE187D4.FBF0AD3E@lemburg.com>

"Martin v. Loewis" wrote:
> 
> > This is true for the APIs in unicodeobject.c: as long as the newly
> > created object hasn't "left" the Unicode implementation, the APIs
> > in there are free to modify the otherwise immutable object.
> 
> That means that PyUnicode_FromUnicode does give a guarantee to return
> a fresh object, right?

Let's put it this way: the internals in unicodeobject.c are
allowed to modify the contents of the object even if it was
prefilled with data that came from an initializer. External
caller are not allowed to do this though unless u is set to
NULL (just like in the corresponding string call).
 
> Then I cannot understand why it only gives this guarantee to callers
> inside unicodeobject.c, and not to other callers...

Because I want to reserve the right to change the semantics
*inside* unicodeobject.c at some later point. Note that currently
no caching of Unicode objects takes place, but this could change
in the future and indeed your patch starts into this direction.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From martin@loewis.home.cs.tu-berlin.de  Sat Apr 21 14:25:45 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 21 Apr 2001 15:25:45 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
In-Reply-To: <3AE187D4.FBF0AD3E@lemburg.com> (mal@lemburg.com)
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com> <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de> <3AE187D4.FBF0AD3E@lemburg.com>
Message-ID: <200104211325.f3LDPjh16199@mira.informatik.hu-berlin.de>

> Because I want to reserve the right to change the semantics
> *inside* unicodeobject.c at some later point. Note that currently
> no caching of Unicode objects takes place, but this could change
> in the future and indeed your patch starts into this direction.

So would you accept a patch that corrects all calls to
PyUnicode_FromUnicode which modify the result they get, without having
passed a NULL str argument?

Regards,
Martin


From mal@lemburg.com  Sat Apr 21 14:37:53 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 15:37:53 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com> <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de> <3AE187D4.FBF0AD3E@lemburg.com> <200104211325.f3LDPjh16199@mira.informatik.hu-berlin.de>
Message-ID: <3AE18D31.FDA78CD4@lemburg.com>

"Martin v. Loewis" wrote:
> 
> > Because I want to reserve the right to change the semantics
> > *inside* unicodeobject.c at some later point. Note that currently
> > no caching of Unicode objects takes place, but this could change
> > in the future and indeed your patch starts into this direction.
> 
> So would you accept a patch that corrects all calls to
> PyUnicode_FromUnicode which modify the result they get, without having
> passed a NULL str argument?

Yes :)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From barry@digicool.com  Sat Apr 21 16:57:57 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Sat, 21 Apr 2001 11:57:57 -0400
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com>
Message-ID: <15073.44549.140970.32646@anthem.wooz.org>

>>>>> "TP" == Tim Peters <tim.one@home.com> writes:

    TP> It's "correct".  I've been using Python longer than Guido
    TP> <wink>, and I'm amazed this is the first time I got bit by
    TP> this!  Here's a hint:

Oh, that is twisted! :)

Let's throw in some parentheses just to confuse people even more:

>>> 'a' in 'a' == 'a'
1
>>> ('a' in 'a') == 'a'
0
>>> 'a' in ('a' == 'a')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in' or 'not in' needs sequence right argument
>>> 'a' in 'a' == 1
0
>>> ('a' in 'a') == 1
1
>>> 'a' in ('a' == 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in' or 'not in' needs sequence right argument

>>>>> "PP" == Paul Prescod <paulp@ActiveState.com> writes:

    PP> It looks like dubious hypergeneralization to me! <0.7 wink>
    PP> Seriously, does this "feature" ever make sense to apply to the
    PP> in operator?

I don't know; I wonder if "normal" people think of `in' as a chainable
comparison operator or not.  You're not suggesting to change this are
you?

gotta-leave-something-`in'-there-for-job-security-ly y'rs,
-Barry


From gmcm@hypernet.com  Sat Apr 21 18:25:15 2001
From: gmcm@hypernet.com (Gordon McMillan)
Date: Sat, 21 Apr 2001 13:25:15 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <15073.44549.140970.32646@anthem.wooz.org>
Message-ID: <3AE18A3B.24053.47CCB799@localhost>

> >>>>> "TP" == Tim Peters <tim.one@home.com> writes:
> 
>     TP> It's "correct".  I've been using Python longer than Guido
>     TP> <wink>, and I'm amazed this is the first time I got bit
>     by TP> this!  Here's a hint:

[Barry]
> Oh, that is twisted! :)
> 
> Let's throw in some parentheses just to confuse people even more:
...
> gotta-leave-something-`in'-there-for-job-security-ly y'rs,

You're safely employed for years:

>>> 'a' in 'abc' == 1
0
>>> 'a' in 'abc' == 'a'
0
>>> 'a' in 'abc' == 'a' in 'abc'
0

but-a-raise-is-out-of-the-question-ly y'rs

- Gordon


From python-list@python.org  Sat Apr 21 23:56:30 2001
From: python-list@python.org (Tim Peters)
Date: Sat, 21 Apr 2001 18:56:30 -0400
Subject: [Python-Dev] Iterators, generators and 2.2 (was RE: do...until wisdom needed...)
In-Reply-To: <slrn9e33tr.a5m.neelk@alum.mit.edu>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENMJNAA.tim.one@home.com>

[Aahz]
> Generators (called "iterators") are going to be 2.2.  They'll be
> more powerful that Icon's generators; it's not clear whether they'll
> be a full-fledged substitute for coroutines.

[Neelakantan Krishnaswami]
> {\mr_burns Excellent.}
>
> Is this the iterator idea that Ping posted about a couple of months
> back? What is the PEP number for this? I'm curious how the existing
> iteration protocol will interact with the new iterators.

This is getting confused.  Iterators != generators (sorry, Aahz! it's more
involved than that).

Aahz gave you the PEP number for iterators, and last night Guido checked an
initial implementation into the 2.2 CVS tree.  In Python terms, "for" setup
looks for an __iter__ method first, and if it doesn't find it but does find
__getitem__, builds a lightweight iterator around the __getitem__ method
instead.  So the "for" loop works only with iterators now, but there's an
adapter providing iterators by magic for old sequence objects that don't know
about iterators:

C:\Code\python\dist\src\PCbuild>python
Python 2.2a0 (#16, Apr 20 2001, 23:16:12) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> def f(s):
...     for i in s:
...         print i
...
>>> from dis import dis
>>> dis(f)
          0 SET_LINENO               1

          3 SET_LINENO               2
          6 SETUP_LOOP              25 (to 34)
          9 LOAD_FAST                0 (s)
         12 GET_ITER

    >>   13 SET_LINENO               2
         16 FOR_ITER                14
         19 STORE_FAST               1 (i)

         22 SET_LINENO               3
         25 LOAD_FAST                1 (i)
         28 PRINT_ITEM
         29 PRINT_NEWLINE
         30 JUMP_ABSOLUTE           13
         33 POP_BLOCK
    >>   34 LOAD_CONST               0 (None)
         37 RETURN_VALUE
>>>

The backward compatibility layer described above is hiding in the new
GET_ITER opcode.  Of course builtin lists (and so on) define the iterator
slot directly now, so GET_ITER simply returns their iterator directly.  Loops
are less complicated (internally) now, and run significantly faster.
User-defined types and classes no longer *need* to (ab)use __getitem__ to
implement iteration (which is of particular interest to Greg Wilson right
now, who is implementing a Set class and doesn't *want* to define __getitem__
because it's semantically senseless).

None of that should be controversial in the least.  More controversial is
that iteration over dict keys has been tentatively added (and note that this
is another thing made *possible* by breaking the old connection between
__getitem__ and iteration):

>>> dict = {"one": 1, "two": 2}
>>> for k in dict:
...     print k
...
one
two
>>>

This is significantly faster, and unboundedly more memory-efficient, than
doing "for k in dict.keys()".

The dict.__contains__ slot was also filled in, so that "k in dict" is
synonymous with "dict.has_key(k)", but again runs significantly faster:

>>> "one" in dict
1
>>> "three" in dict
0
>>>

File objects have also grown iterators, so that, e.g.,

    for line in sys.stdin:
        print line

now works.

Iterators can be explicitly materialized too, via the new iter() builltin
function, and invoked apart from the "for" protocol:

>>> i1 = iter(dict)
>>> i1
<dictionary-iterator object at 0079A250>
>>> dir(i1)
['next']
>>> print i1.next.__doc__
it.next() -- get the next value, or raise StopIteration
>>> i2 = iter(dict)
>>> i1.next()
'one'
>>> i2.next()
'one'
>>> i1.next()
'two'
>>> i2.next()
'two'
>>> i1.next()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
StopIteration
>>>

Note that this allows a simple memory-efficient implementation of parallel
sequence iteration too.  For example, this program:

class zipiter:
    def __init__(self, seq1, *moreseqs):
        seqs = [seq1]
        seqs.extend(list(moreseqs))
        self.seqs = seqs

    def __iter__(self):
        self.iters = [iter(seq) for seq in self.seqs]
        return self

    def next(self):
        return [i.next() for i in self.iters]

for i, j, k in zipiter([1, 2, 3], "abc", (5., 6., 7., 8.)):
    print i, j, k

prints

1 a 5.0
2 b 6.0
3 c 7.0


Now all that is just iteration in a thoroughly conventional sense.  There is
no support here for generators or coroutines or microthreads, except in the
sense that breaking the iteration==__getitem__ connection makes it easier to
think about *how* generators may be implemented, and having an explicit
iterator object "should" make it possible to go beyond Icon's notion of
generators (which can only be driven implicitly by control context).

Neil Schemenauer is currently thinking hard about that "in his spare time",
but there's no guarantee anything will come of it in 2.2.  Iterators are a
sure thing, though (not least because they're already implemented!).

not-only-implemented-but-feel-exactly-right-ly y'rs  - tim



From fdrake@beowolf.digicool.com  Sun Apr 22 07:08:22 2001
From: fdrake@beowolf.digicool.com (Fred Drake)
Date: Sun, 22 Apr 2001 02:08:22 -0400 (EDT)
Subject: [Python-Dev] [maintenance doc updates]
Message-ID: <20010422060822.A3E4428A0B@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/maint-docs/

First attempt to push maintenance docs to the SourceForge site.



From fdrake@beowolf.digicool.com  Sun Apr 22 07:12:15 2001
From: fdrake@beowolf.digicool.com (Fred Drake)
Date: Sun, 22 Apr 2001 02:12:15 -0400 (EDT)
Subject: [Python-Dev] [maintenance doc updates]
Message-ID: <20010422061215.5C87D28A0B@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/maint-docs/

Second attempt to push maintenance docs to the SourceForge site.



From fdrake@beowolf.digicool.com  Sun Apr 22 07:15:52 2001
From: fdrake@beowolf.digicool.com (Fred Drake)
Date: Sun, 22 Apr 2001 02:15:52 -0400 (EDT)
Subject: [Python-Dev] [maintenance doc updates]
Message-ID: <20010422061552.5A99628A0B@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/maint-docs/

Third attempt to push maintenance docs to the SourceForge site.

Sheesh!



From Greg.Wilson@baltimore.com  Sun Apr 22 13:19:22 2001
From: Greg.Wilson@baltimore.com (Greg Wilson)
Date: Sun, 22 Apr 2001 08:19:22 -0400
Subject: [Python-Dev] re: string slicing and method consistency
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D21B@nsamcanms1.ca.baltimore.com>

> > > Greg Wilson:
> > > if "abbc"[-1] is "c", and if
> > > "abbc".replace("b", "x", 1) is "axbc", then shouldn't
> > > "abbc".replace("b", "x", -1) be "abxc" (i.e. negative
> > > numbers replace the *last* occurrences of the value)?
> > > Same argument for "split", etc.
> >     >>> path = "/some/long/path/to/file.html"
> >     >>> main, parent, file = path.split("/", -2)
> >     >>> main
> >     "/some/long/path"
> >     >>> parent
> >     "to"
> >     >>> file
> >     "file.html"

> > Guido van Rossum:
> OK, that's an example.  It's only so-so, because you should be using
> os.path.split() anyway.  It's done best as follows:
> 
>   temp, file = os.path.split(path)
>   main, parent = os.path.split(temp)

Greg Wilson:
Or "main, parent, file = os.path.split(path, -2)" :-)

> > Greg Wilson again:
> > Question still stands --- if these are counts, then shouldn't
> > negative values raise exceptions?
> 
> Given that it's documented with the name "maxsplit", it's not
> unreasonable that -1 is treated the same as 0.

Greg Wilson:
But it isn't:

>>> print sys.version
2.2a0 (#2, Apr 20 2001, 12:53:03)
[GCC 2.95.2 19991024 (release)]
>>> "abbc".replace("b", "x", 0)
'abbc'
>>> "abbc".replace("b", "x", -1)
'axxc'

Thanks,
Greg


From tim.one@home.com  Mon Apr 23 00:19:19 2001
From: tim.one@home.com (Tim Peters)
Date: Sun, 22 Apr 2001 19:19:19 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <200104211142.GAA17114@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEACJOAA.tim.one@home.com>

[Tim, 'a' in 'a' == 1, etc]

[Guido]
> Yeah, I ran into the same when converting some has_key() tests to
> using 'in'.

Bingo!  Same here, but after adding __iter__ and __contains__ to UserDict.py,
then fiddling test_userdict.py to match.

> I guess it's not very common since nobody in their right minds should
> want to compare the result of an 'in' test to anything else.  The
> has_key() tests did something like "assert d.has_key(k)==1"
> and the mindless translation of that is "assert k in d == 1"...

You'd think so <wink>.  It was subtler in the first I bumped into,
translating something like

    assert d1.has_key(k) == d2.has_key(k)

The problem in

    assert k in d1 == k in d2

is, I think, harder to spot.  That is, you may well be in your right might if
you want to compare the result of an 'in' test to the result of *another*
'in' test!

Even stranger,

    assert k in d1 != k in d2

succeeds if and only if k is in both d1 and d2 (assuming d1 is a dict and k
isn't).  I'm going to use that a lot in my code, because it's one less
character than typing

    assert k in d1 and k in d2

Heh heh.

*something*-about-this-may-not-be-ideal-ly y'rs  - tim



From paulp@ActiveState.com  Mon Apr 23 00:52:43 2001
From: paulp@ActiveState.com (Paul Prescod)
Date: Sun, 22 Apr 2001 16:52:43 -0700
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com> <15073.44549.140970.32646@anthem.wooz.org>
Message-ID: <3AE36ECB.EABBCF46@ActiveState.com>

"Barry A. Warsaw" wrote:
> 
>...
> >>>>> "PP" == Paul Prescod <paulp@ActiveState.com> writes:
> 
>     PP> It looks like dubious hypergeneralization to me! <0.7 wink>
>     PP> Seriously, does this "feature" ever make sense to apply to the
>     PP> in operator?
> 
> I don't know; I wonder if "normal" people think of `in' as a chainable
> comparison operator or not.  

If Tim, Guido, you and I are so completely out of sync with normal
people that they will immediately intuit what we had to think hard
about, we're in deep doo-doo!

> You're not suggesting to change this are
> you?

I suggest a compile-time warning and then eventually we would make "in"
non-chainable. Perhaps it should even have a different precedence than
the other comparison operators. Tim's example looks reasonable to me:

assert k in d1 == k in d2

And it would never, ever make sense to say:

assert k in (d1==k) in d2

So why not interpret it the way that any normal human would:

assert (k in d1) == (k in d2)

I think that this is a subtle flaw in Python that just took a long time
to manifest itself...

And what about "1 is None == 2 is None"? If you saw that in a program
(last week!) what would you have expected it to evalute to? Precedence
levels exist to make code easier to read!
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook


From tim.one@home.com  Mon Apr 23 01:11:51 2001
From: tim.one@home.com (Tim Peters)
Date: Sun, 22 Apr 2001 20:11:51 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <3AE36ECB.EABBCF46@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEAEJOAA.tim.one@home.com>

[Paul Prescod]
> If Tim, Guido, you and I are so completely out of sync with normal
> people that they will immediately intuit what we had to think hard
> about, we're in deep doo-doo!

Na, we're not, they are:  they're *never* gonna figure it out <wink>.

> I suggest a compile-time warning and then eventually we would make "in"
> non-chainable.

An incompatible language change would, I think, need to go thru the
__future__ (however spelled) business.

> Perhaps it should even have a different precedence than the other
> comparison operators. Tim's example looks reasonable to me:
>
> assert k in d1 == k in d2

It *used* to look reasonable to me too <wink>.

> And it would never, ever make sense to say:
>
> assert k in (d1==k) in d2

Thin ice, there.  __eq__ and __contains__ are both user-definable now, and
there is no limit to how perverse ex-APL'ers can get with this stuff.

> So why not interpret it the way that any normal human would:
>
> assert (k in d1) == (k in d2)

That sounds best to me, but may be too much a bother.  For example, it's not
a stretch at all anymore to believe that someone *is* using

    a in b in c

now deliberately for its

    (a in b) and (b in c)

meaning.  Perfectly natural if, e.g., you use __contains__ to implement an
"is subset of" relation.  If we have to keep chaining for "in", then having
two distinct levels of chaining operators is bound to harbor its own odd
corners.

    x == y in d

I have no idea what that *should* mean, but having gone thru recent related
pain I'm very clear now on what it *does* mean.

> I think that this is a subtle flaw in Python that just took a long time
> to manifest itself...

You can thank Digital Creations for that, too.  They're keeping Guido so busy
that he doesn't have enough time to cloud our minds anymore.  Makes you
wonder how many other surprises he's been hiding from us <wink>!



From paulp@ActiveState.com  Mon Apr 23 04:04:21 2001
From: paulp@ActiveState.com (Paul Prescod)
Date: Sun, 22 Apr 2001 20:04:21 -0700
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCOEAEJOAA.tim.one@home.com>
Message-ID: <3AE39BB5.3B2E276C@ActiveState.com>

Tim Peters wrote:
> 
>...
> 
> > I suggest a compile-time warning and then eventually we would make "in"
> > non-chainable.
> 
> An incompatible language change would, I think, need to go thru the
> __future__ (however spelled) business.

???

My understanding was that __future__ was a way of sneaking in a cool
feature earlier than it would have been possible to deploy it given
strict gradual evolution contraints. But disallowing confusing uses of
"in" is not a feature and nobody is in a big hurry to see it happen. I
wouldn't mind waiting a year or two until everyone has had a chance to
clean up their code.

> ...
> For example, it's not
> a stretch at all anymore to believe that someone *is* using
> 
>     a in b in c
> 
> now deliberately for its
> 
>     (a in b) and (b in c)
> 
> meaning.  Perfectly natural if, e.g., you use __contains__ to implement an
> "is subset of" relation.  

The following grammar would preserve it and outlaw confusing cases:

comparison: in_comparison | is_comparison | math_comparison
math_comparison: expr (math_comp_op expr)*
in_comparison: expr ('in' | 'not' 'in' expr)*
is_comparison: expr ('is' | 'is' 'not' expr)*
math_comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook


From greg@cosc.canterbury.ac.nz  Mon Apr 23 06:27:14 2001
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 23 Apr 2001 17:27:14 +1200 (NZST)
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <200104230527.RAA14279@s454.cosc.canterbury.ac.nz>

Guido:

> The problem is that if you write C.spam, there could be two spams: one
> in C.__dict__, one in M.__dict__.  Which one to use?  How does
> Smalltalk resolve this?

The problem doesn't arise in Smalltalk, because method calls and
instance variable accesses are completely different things and are
handled by quite separate syntaxes and mechanisms.

Python creates problems for itself here by confusing instance
variables of the class with metadata about the instance's methods,
and keeping them both in the same namespace.

Thomas Heller <thomas.heller@ion-tof.com>:

> I'm walking on thin ice here (maybe I should better try it out),
> but IIRC Smalltalk requires to explicit:
> 
>     self class method;
> or
>     self method;

No, to call a class method in Smalltalk, you just send a message 
to the class itself rather than an instance. There's no difference
in the message sending syntax.

> Thin ice again I'm on here (even more), but I have the impression
> that creating a class Point in Smalltalk _automatically_ creates
> two classes: Point and PointClass. The latter is normally hidden
> (but contains the class methods of Point as instance methods).

Yes. You don't normally get a choice about what the metaclass is,
although no doubt you could reach under the covers and manually
construct your own metaclass and instantiate it if you wanted.

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 Apr 23 06:33:20 2001
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 23 Apr 2001 17:33:20 +1200 (NZST)
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com>
Message-ID: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz>

Tim Peters <tim.one@home.com>:

> "class methods" in *this* thread
> is being used in a Smalltalk sense (because it's Thomas Heller's thread, and
> he made clear that he doesn't want C++-style class statics).

It sounds like he wants not just class methods, but to
unify classes and instances the way they are in Smalltalk.

That's not necessary *just* to get class methods. For
instance, suppose you could write

  class Foo:

    def ftang(class c, x, y, z);
      ...

where the 'class' keyword in the argument list would say
that it is to be a class method. That special form of the
def statement would create an 'unbound class method'
object, whose first argument would be filled in with the
class object when Foo.ftang was accessed.

Hmmm... might write a PEP on 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 tim.one@home.com  Mon Apr 23 06:41:08 2001
From: tim.one@home.com (Tim Peters)
Date: Mon, 23 Apr 2001 01:41:08 -0400
Subject: [Python-Dev] Importing DLLs on Windows
In-Reply-To: <3AE16254.FFE9ADF7@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com>

[MAL]
> Oh, sorry that I wasn't clear enough.

Me neither (see below).

> Referring to the mxNumber package, I am seeing this situation:
>
> # This works... (note the start directory)
>
> C:\WINDOWS>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> >>> print mx.Number.Float(3.141)
> 3.14100000000000001421e+0
> >>>
>
> # This doesn't.... (from the Python install directory)
>
> D:\Python21>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "d:\python21\mx\Number\__init__.py", line 9, in ?
>     from Number import *
>   File "d:\python21\mx\Number\Number.py", line 11, in ?
>     from mxNumber import *
>   File "d:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
>     from mxNumber import *
> ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser
> Anwendung notwen dige Bibliothekdateien kann nicht gefunden werden.
> >>>

Well, there's your problem:  looks some German hackers got into your machine
and screwed up the OS <wink>.

Now let me clarify what I wrote before:  when I said I couldn't provoke a
problem, I meant ANY problem.  It didn't matter whether I used the
__init__.py you shipped, or used the two-liner I posted, and it didn't matter
whether I started Python 2.1 from the install directory or from C:\Code
(etc).  Nothing failed no matter what I tried.

The only thing I see different in what you did above is that your Python
install directory is on a different drive (D: instead of C:).  I only have
one drive here, so I can't do a good job of simulating that.  Best I can do
here is fake it via the DOS subst command:

K:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> from mx.Number import *
>>>

Still no problem.  What happens if you install Python onto your C: drive
instead?  And if that does work for you, is it because of the C: drive, or
because you left some old development work on your D: drive that's confusing
things?

Do you have confirmation of your problem from anyone else?  Or are you the
only one who has bumped into it?

> ...
> Please try starting Python from your Python install dir and
> then do the import.

I already had, in the last msg.  And again above.

> BTW, I'm doing this on Windows 95 in case this matters (which I'm
> sure it does :-/).

Possibly, but can't say.  We need more data.

BTW, do you understand what your code does <0.7 wink>?  That is, there are
packages, modules *and* DLLs with the same base name, and "import *"
everywhere.  I've always stayed so far away from import end cases that I have
no idea what the rules are supposed to be when you live on the edge.  That
may have something to do with this too, although I can't see how (although
since I don't know what the rules are, that's a guess too!).



From tim.one@home.com  Mon Apr 23 07:05:17 2001
From: tim.one@home.com (Tim Peters)
Date: Mon, 23 Apr 2001 02:05:17 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <3AE39BB5.3B2E276C@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEAPJOAA.tim.one@home.com>

>> An incompatible language change would, I think, need to go thru the
>> __future__ (however spelled) business.

[Paul]
> ???
>
> My understanding was that __future__ was a way of sneaking in a cool
> feature earlier than it would have been possible to deploy it given
> strict gradual evolution contraints.

That's not what PEP 236 says.  __future__ is about *incompatible* language
changes, period.  "Cool" has nothing to do with it.  If you're making
something illegal that used to work, that's an incompatible change, and
people get at least one release cycle in which it continues to work without
change but with warnings.  They can also ask for future behavior early via
using an explicit future-statement in the module.  Although in this case I
guess the "future behavior" is just to turn the wng msg into a SyntaxError,
in which case the __future__ machinery does seem like overkill.

> But disallowing confusing uses of "in" is not a feature

PEP 236 is about incompatible changes, not features.  It so happens that the
first use (nested scopes) was a new feature that *could* break old code, so
was both a new feature and an incompatible change.

> and nobody is in a big hurry to see it happen. I wouldn't mind
> waiting a year or two until everyone has had a chance to
> clean up their code.

I'd rather not nag people at all if this is the only time it's come up in a
decade <wink>.  We've all got too much to do.

> ...
> The following grammar would preserve it [chaining "in"] and outlaw
> confusing cases:
>
> comparison: in_comparison | is_comparison | math_comparison
> math_comparison: expr (math_comp_op expr)*
> in_comparison: expr ('in' | 'not' 'in' expr)*
> is_comparison: expr ('is' | 'is' 'not' expr)*
> math_comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='

Did you try that grammar?  I'm skeptical that it works, since at first glance
the comparison production appears to require arbitrary lookahead to determine
which xxx_comparison case obtains.  But if so, I'm sure it can be repaired.
Whether it *should* be is a different matter I'll leave to Guido to Pronounce
on.



From mal@lemburg.com  Mon Apr 23 09:48:17 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 23 Apr 2001 10:48:17 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com>
Message-ID: <3AE3EC50.3A850757@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > Oh, sorry that I wasn't clear enough.
> 
> Me neither (see below).
> 
> > Referring to the mxNumber package, I am seeing this situation:
> >
> > # This works... (note the start directory)
> >
> > C:\WINDOWS>python
> > Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> > Type "copyright", "credits" or "license" for more information.
> > >>> import mx.Number
> > >>> print mx.Number.Float(3.141)
> > 3.14100000000000001421e+0
> > >>>
> >
> > # This doesn't.... (from the Python install directory)
> >
> > D:\Python21>python
> > Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> > Type "copyright", "credits" or "license" for more information.
> > >>> import mx.Number
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> >   File "d:\python21\mx\Number\__init__.py", line 9, in ?
> >     from Number import *
> >   File "d:\python21\mx\Number\Number.py", line 11, in ?
> >     from mxNumber import *
> >   File "d:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
> >     from mxNumber import *
> > ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser
> > Anwendung notwen dige Bibliothekdateien kann nicht gefunden werden.
> > >>>
> 
> Well, there's your problem:  looks some German hackers got into your machine
> and screwed up the OS <wink>.

Could be...
 
> Now let me clarify what I wrote before:  when I said I couldn't provoke a
> problem, I meant ANY problem.  It didn't matter whether I used the
> __init__.py you shipped, or used the two-liner I posted, and it didn't matter
> whether I started Python 2.1 from the install directory or from C:\Code
> (etc).  Nothing failed no matter what I tried.

OK. I tried the same on a Win98 box with a fresh Python and
mxNumber install -- and found no problems either; which leaves
me rather clueless about where the failures on my Win95 box 
originate. 

Could someone else with a Win95 box perhaps test this ?

Thanks anyway for hanging on,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From thomas.heller@ion-tof.com  Mon Apr 23 09:58:56 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Mon, 23 Apr 2001 10:58:56 +0200
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
References: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz>
Message-ID: <02a701c0cbd3$a21f9290$e000a8c0@thomasnotebook>

> Tim Peters <tim.one@home.com>:
> 
> > "class methods" in *this* thread
> > is being used in a Smalltalk sense (because it's Thomas Heller's thread, and
> > he made clear that he doesn't want C++-style class statics).

Well, I shouldn't have talked about C++ static methods, because
I'm not too familiar with them.

Here's what I want:

Assume C is a class with a class-method mth,
and D is 'class D(C): pass'.

C.mth() should call this method, which in turn (automatically)
receives C itself as the first parameter.
D.mth() should call this method, which in turn (automatically)
receives D itself as the first parameter.

> 
> It sounds like he wants not just class methods, but to
> unify classes and instances the way they are in Smalltalk.

The metaclass approach is one solution, not neccessarily
the best.
> 
> That's not necessary *just* to get class methods. For
> instance, suppose you could write
> 
>   class Foo:
> 
>     def ftang(class c, x, y, z);
>       ...
> 
> where the 'class' keyword in the argument list would say
> that it is to be a class method. That special form of the
> def statement would create an 'unbound class method'
> object, whose first argument would be filled in with the
> class object when Foo.ftang was accessed.

Donald Beaudry's objectmodule uses the metaclass hook to provide
class methods. I like the resulting syntax very much: He uses an
'inner class' with the special name '__class__' to specify class
methods:

class Object(object.base):
    class __class__:
        def class_method(self):
            pass
    def normal_method(self):
        pass

If I understand correctly (objectmodule does not run under
1.5.2 or later), an instance of __class__ will become
the metaclass of Object, and __class__'s methods will
become class methods of Object.

I've played a little bit with metaclasses in pure python
(it is faster this way), and have an implementation with the
same syntax where __class__ is never instantiated, and simply
acts as a function container.

Addendum: Additionaly to class methods, I would like to
have 'magic' class methods, maybe named __class_init__
and __class_getattr__. Easy to guess what they should do...

> 
> Hmmm... might write a PEP on that!
> 
Me too.


Thomas



From jack@oratrix.nl  Mon Apr 23 10:16:44 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 23 Apr 2001 11:16:44 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
In-Reply-To: Message by "Tim Peters" <tim.one@home.com> ,
 Thu, 12 Apr 2001 21:00:08 -0400 , <LNBBLJKPBEHFEDALKOLCAENKJLAA.tim.one@home.com>
Message-ID: <20010423091644.AB453312BA0@snelboot.oratrix.nl>

> [Steven D. Majewski]
> > Has anybody looked at sfio ?
> > ...
> > http://www.research.att.com/sw/tools/sfio/
> 
> Did just now.  Only runs on Unix boxes, so would be a heavyweight way to
> solve line-end problems across platforms that don't have any <wink>.

But purely by chance I know that Matthias Neeracher, who has written the GUSI 
unix-emulation package that MacPython uses to do socket IO and select and 
such, is an SFIO fan, and there's all sorts of hooks in GUSI to allow use of 
SFIO. So I think that there's a good chance that sfio is okay for MacPython.

I've just dug out the 1991 usenix article, I'll read through it shortly.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From thomas@xs4all.net  Mon Apr 23 12:09:02 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 23 Apr 2001 13:09:02 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/ref ref3.tex,1.64,1.65 ref5.tex,1.43,1.44
In-Reply-To: <15072.27417.366789.977575@slothrop.digicool.com>; from jeremy@digicool.com on Fri, Apr 20, 2001 at 01:00:09PM -0400
References: <E14qe7G-0002AU-00@usw-pr-cvs1.sourceforge.net> <15072.27417.366789.977575@slothrop.digicool.com>
Message-ID: <20010423130902.A16486@xs4all.nl>

On Fri, Apr 20, 2001 at 01:00:09PM -0400, Jeremy Hylton wrote:
> >>>>> "GvR" == Guido van Rossum <gvanrossum@users.sourceforge.net> writes:

>   GvR> Log Message: Implement, test and document "key in dict" and
>   GvR> "key not in dict".

>   GvR> I know some people don't like this -- if it's really
>   GvR> controversial, I'll take it out again.  (If it's only Alex
>   GvR> Martelli who doesn't like it, that doesn't count as "real
>   GvR> controversial" though. :-)

> I don't like it either, because it's only clear when it's spelled "for
> key in dict".  It's pretty confusing when it's spelled "for val in
> dict" or even "for x in dict".

> But I'm willing to give it a try for a while.

Same here (don't like right now, can live with it even though my own
experiments w/ innocent colleagues lead me to believe it's not the best
thing to do ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas@xs4all.net  Mon Apr 23 13:28:52 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 23 Apr 2001 14:28:52 +0200
Subject: [Python-Dev] Suirprise!
In-Reply-To: <3AE39BB5.3B2E276C@ActiveState.com>; from paulp@ActiveState.com on Sun, Apr 22, 2001 at 08:04:21PM -0700
References: <LNBBLJKPBEHFEDALKOLCOEAEJOAA.tim.one@home.com> <3AE39BB5.3B2E276C@ActiveState.com>
Message-ID: <20010423142852.B16486@xs4all.nl>

On Sun, Apr 22, 2001 at 08:04:21PM -0700, Paul Prescod wrote:

> The following grammar would preserve it and outlaw confusing cases:

> comparison: in_comparison | is_comparison | math_comparison
> math_comparison: expr (math_comp_op expr)*
> in_comparison: expr ('in' | 'not' 'in' expr)*
> is_comparison: expr ('is' | 'is' 'not' expr)*
> math_comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='

Won't work. Python's parser can't handle it. I also don't think the grammar
really matters that much -- it's the compiler that does the actual chaining,
it could decide not to chain and force a specific order, if it really wanted
to. And generate warnings and all that :)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From fdrake@acm.org  Mon Apr 23 13:40:44 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Mon, 23 Apr 2001 08:40:44 -0400 (EDT)
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
In-Reply-To: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz>
References: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com>
 <200104230533.RAA14282@s454.cosc.canterbury.ac.nz>
Message-ID: <15076.8908.65608.249318@cj42289-a.reston1.va.home.com>

Greg Ewing writes:
 >   class Foo:
 > 
 >     def ftang(class c, x, y, z);
 >       ...

  I like this syntax better that the others.  While it requires that a
single namespace is used for class and normal methods, I think that is
a good thing -- we don't *want* overlapping sets of names!


  -Fred

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



From thomas@xs4all.net  Mon Apr 23 13:44:40 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 23 Apr 2001 14:44:40 +0200
Subject: [Python-Dev] keyword-only arguments (was Re: string slicing and method consistency)
In-Reply-To: <200104202148.QAA13960@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Fri, Apr 20, 2001 at 04:48:06PM -0500
References: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com> <200104202148.QAA13960@cj20424-a.reston1.va.home.com>
Message-ID: <20010423144440.C16486@xs4all.nl>

On Fri, Apr 20, 2001 at 04:48:06PM -0500, Guido van Rossum wrote:
> [GVW]

> > Turns out that "abbc".replace("b", "x", -1) is "axxc"
> > (i.e. negative arguments are ignored).  I would have
> > expected this to raise a ValueError, if anything.  Is
> > there a reason for this behavior?  Is it worth making
> > replace, split, etc. interpret negative indices in the
> > same way as indexing does?
> 
> Dubious hypergeneralization.  The thing is that this parameter, called
> maxsplit, is not really an index -- it's a count.

Wouldn't it be nice if we could force particular arguments to be used as
keyword arguments only ? :) I remember this coming up a few times on
python-list, but I never quite understood why this isn't done. Syntax
doesn't seem too much of a problem ('def split(s, sep, **, maxsplit=0)'
comes to mind, and a new marker for PyArg_ParseTuple, like "**") and now
that we have warnings and __future__, we could phase it in even for oft-used
things such as string.split().

Even if it's deemed dubious hypergeneralization (look ma, no macro ;) it's
worth writing a PEP about, right ?

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas.heller@ion-tof.com  Mon Apr 23 14:04:37 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Mon, 23 Apr 2001 15:04:37 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com> <3AE3EC50.3A850757@lemburg.com>
Message-ID: <03ee01c0cbf5$f3963f30$e000a8c0@thomasnotebook>

I see the same Behaviour as Marc-Andre: Traceback in Win95 (running under VMWare,
running under Win2k).

C:\WINDOWS>\python21\python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>
>>>
>>>
>>> quit
'Use Ctrl-Z plus Return to exit.'
>>>
C:\WINDOWS>cd \python21

C:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "c:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "c:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
    from mxNumber import *
ImportError: DLL load failed: One of the library files needed to run this applic
ation cannot be found.
>>>
C:\Python21>ver

Windows 95. [Version 4.00.950]


C:\Python21>


Marc-Andre, what about other python versions?

Thomas



From guido@digicool.com  Mon Apr 23 15:36:44 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 23 Apr 2001 09:36:44 -0500
Subject: [Python-Dev] keyword-only arguments (was Re: string slicing and method consistency)
In-Reply-To: Your message of "Mon, 23 Apr 2001 14:44:40 +0200."
 <20010423144440.C16486@xs4all.nl>
References: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com> <200104202148.QAA13960@cj20424-a.reston1.va.home.com>
 <20010423144440.C16486@xs4all.nl>
Message-ID: <200104231436.JAA00321@cj20424-a.reston1.va.home.com>

> Wouldn't it be nice if we could force particular arguments to be used as
> keyword arguments only ? :)

You could do this manually using **kwds (or its C equivalent), but it
gets ugly.

> I remember this coming up a few times on
> python-list, but I never quite understood why this isn't done. Syntax
> doesn't seem too much of a problem ('def split(s, sep, **, maxsplit=0)'
> comes to mind, and a new marker for PyArg_ParseTuple, like "**") and now
> that we have warnings and __future__, we could phase it in even for oft-used
> things such as string.split().
> 
> Even if it's deemed dubious hypergeneralization (look ma, no macro ;) it's
> worth writing a PEP about, right ?

Sure.  My main problem with it is that I doubt how often it is useful,
compared to the cost of adding the syntax and new code generation
necessary.  I don't think that ** is the right separator, but I don't
have a better suggestion.

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


From mal@lemburg.com  Mon Apr 23 14:40:50 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 23 Apr 2001 15:40:50 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com> <3AE3EC50.3A850757@lemburg.com> <03ee01c0cbf5$f3963f30$e000a8c0@thomasnotebook>
Message-ID: <3AE430E2.A81CEBDA@lemburg.com>

Thomas Heller wrote:
> 
> I see the same Behaviour as Marc-Andre: Traceback in Win95 (running under VMWare,
> running under Win2k).
> 
> C:\WINDOWS>\python21\python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> >>> print mx.Number.Float(3.141)
> 3.14100000000000001421e+0
> >>>
> >>>
> >>>
> >>> quit
> 'Use Ctrl-Z plus Return to exit.'
> >>>
> C:\WINDOWS>cd \python21
> 
> C:\Python21>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "c:\python21\mx\Number\__init__.py", line 9, in ?
>     from Number import *
>   File "c:\python21\mx\Number\Number.py", line 11, in ?
>     from mxNumber import *
>   File "c:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
>     from mxNumber import *
> ImportError: DLL load failed: One of the library files needed to run this applic
> ation cannot be found.
> >>>
> C:\Python21>ver
> 
> Windows 95. [Version 4.00.950]
> 
> C:\Python21>
> 
> Marc-Andre, what about other python versions?

mxNumber needs Python 2.1, so I have no way of testing it under
Python 2.0. Both imports work on Winows 98SE, so I guess this
has something to do with Win95 no handling imports using relative
paths correctly (if you run Python with -vv you'll see that
Python searches using relative paths when started from C:\Python21).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From nas@python.ca  Mon Apr 23 16:12:18 2001
From: nas@python.ca (Neil Schemenauer)
Date: Mon, 23 Apr 2001 08:12:18 -0700
Subject: [Python-Dev] ineffective optimization: method tables
Message-ID: <20010423081218.A9952@glacier.fnational.com>

Well, I wasted a fair amount of my time for no apparent gain.
The idea was to have function pointer tables indexed by type that
could be used for common operations.  First, how to do we index
things by type?  Here's my solution:

    #define PyType_UNKNOWN 0
    #define PyType_NONE 1
    #define PyType_INT 2

    #define PyType_Ord(t) ((t)->tp_ord)
    #define PyObject_TypeOrd(o) PyType_Ord((o)->ob_type)

Here is an example of methods for PyObject_IsTrue:

    int
    int_istrue(PyObject *v)
    {
        return ((PyIntObject *)v)->ob_ival != 0;
    }

    int
    none_istrue(PyObject *v)
    {
        return 0;
    }

    inquiry istrue_table[] =  {
           PyObject_IsTrue,        /* PyType_UNKNOWN */
           none_istrue,            /* PyType_NONE */
           int_istrue,             /* PyType_INT */
    };

    #define PyObject_IS_TRUE(v) istrue_table[PyObject_TypeOrd(v)](v)

There is a patch at:

    http://arctrix.com/nas/python/method_table1.diff

I did have 2-D tables for binary operations but since they were
quite sparse I took them out in favor of arrays and case
statements.  Unfortunately, all my benchmarks show this patch to
be ineffective in terms of speeding up the interpreter.  Anyone
know why?

  Neil


From guido@digicool.com  Mon Apr 23 16:21:02 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 23 Apr 2001 11:21:02 -0400
Subject: [Python-Dev] ineffective optimization: method tables
In-Reply-To: Your message of "Mon, 23 Apr 2001 08:12:18 PDT."
 <20010423081218.A9952@glacier.fnational.com>
References: <20010423081218.A9952@glacier.fnational.com>
Message-ID: <200104231521.f3NFL8h15693@odiug.digicool.com>

> Well, I wasted a fair amount of my time for no apparent gain.
[...]
> Unfortunately, all my benchmarks show this patch to
> be ineffective in terms of speeding up the interpreter.  Anyone
> know why?

Probably you're optimizing something that is already quite fast.
While your code saves a C call and a few tests, those kind of
operations are rarely what slows down Python these days.  My suspicion
is that most of the the time goes into (1) allocating and deallocating
objects, and (b) calling methods...

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


From Samuele Pedroni <pedroni@inf.ethz.ch>  Mon Apr 23 16:35:48 2001
From: Samuele Pedroni <pedroni@inf.ethz.ch> (Samuele Pedroni)
Date: Mon, 23 Apr 2001 17:35:48 +0200 (MET DST)
Subject: [Python-Dev] ineffective optimization: method tables
Message-ID: <200104231535.RAA12700@core.inf.ethz.ch>

Hi.

[Neil Schemenauer]
> I did have 2-D tables for binary operations but since they were
> quite sparse I took them out in favor of arrays and case
> statements.  Unfortunately, all my benchmarks show this patch to
> be ineffective in terms of speeding up the interpreter.  Anyone
> know why?
I just noticed that your changes add a 1 more call price also were there was
no such price (int + int, etc), do not know if that matters ...

regards.



From dsh8290@rit.edu  Mon Apr 23 18:11:54 2001
From: dsh8290@rit.edu (D-Man)
Date: Mon, 23 Apr 2001 13:11:54 -0400
Subject: [Python-Dev] Class Methods
In-Reply-To: <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>; from thomas.heller@ion-tof.com on Fri, Apr 20, 2001 at 05:40:21PM +0200
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com> <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>
Message-ID: <20010423131154.A13119@harmony.cs.rit.edu>

On Fri, Apr 20, 2001 at 05:40:21PM +0200, Thomas Heller wrote:
| I want the class methods (for example) to create and manipulate
| this 'context object'. This object, however, belongs into the class...
| 
| What I want to avoid is
| 
|   class X(...):
|       ....
|   initialize(X)

Here is a different approach to consider :

class X :
    def __class_init__( class_X ) :
        initialize( class_X )


The idea here is to provide a "magic" method in the class that the
interpreter calls as soon as the class object exists.  The first
(only) argument is the class object, which can be named as desired
(analogous to 'self').  The main problem here is clients aren't
prevented from calling this method, and they really shouldn't.

-D



From martin@loewis.home.cs.tu-berlin.de  Mon Apr 23 18:45:18 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 23 Apr 2001 19:45:18 +0200
Subject: [Python-Dev] 'iter' as a function name
Message-ID: <200104231745.f3NHjIN02434@mira.informatik.hu-berlin.de>

I should probably be silent on the issue of picking names for things,
but I feel that 'iter' is an unfortunte choice for a function name: it
is an abbreviated word. Now, you could argue that there is plenty of
precedent for that in Python, but some of these are also
confusing. Just today, I asked colleague what he thought 'repr' might
do, and he had no clue.

Anyway, I've been browsing dictionaries somewhat, and here are a few
proposals, taking a well-known dictionary as an argument:

harp(sys.modules)      # or harp_on(sys.modules)?
traverse(sys.modules)  # not shorter than iterate, though...
narrate(sys.modules)

Of course, spelling-out "iterate" would be just as fine.

Just my 0.02EUR,

Martin


From Donald Beaudry <donb@abinitio.com>  Mon Apr 23 19:12:36 2001
From: Donald Beaudry <donb@abinitio.com> (Donald Beaudry)
Date: Mon, 23 Apr 2001 14:12:36 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
References: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz> <02a701c0cbd3$a21f9290$e000a8c0@thomasnotebook>
Message-ID: <200104231812.OAA08354@localhost.localdomain>

"Thomas Heller" <thomas.heller@ion-tof.com> wrote,
> Donald Beaudry's objectmodule uses the metaclass hook to provide
> class methods. I like the resulting syntax very much:

Thank you.  I like it too, especially because MyClass.__class__
returns what *I* would expect ;) and the source reflects that too.

> If I understand correctly (objectmodule does not run under 1.5.2 or
> later), an instance of __class__ will become the metaclass of
> Object, and __class__'s methods will become class methods of Object.

That's correct.  I currently use objectmodule on 1.5.2.  I would not
be surprised if it doesnt work on newer versions though as I have
never tried it there.  Perhaps you found an out-of-date version, or
perhaps I never sent out a newer version.  Regardless, I'd be happy to
get you a version that works with 1.5.2 (or upload one somewhere for
more public consumption)

> I've played a little bit with metaclasses in pure python (it is
> faster this way), and have an implementation with the same syntax
> where __class__ is never instantiated, and simply acts as a function
> container.

Ah but with the object module, it does get instantiated.  In fact,
__class__ is derived (implicitly) from the __class__ of the containing
base class. Inheritance works as expected.

> Addendum: Additionaly to class methods, I would like to
> have 'magic' class methods, maybe named __class_init__
> and __class_getattr__. Easy to guess what they should do...

Objectmodule provides for that as well.  Just define __init__,
__getattr__, etc., inside the __class__ definition.  There is even and
__new__ which is responsible for controling the "memory allocation" of
instances.  This is useful for, amoung other things, singletons.

> > Hmmm... might write a PEP on that!
> > 
> Me too.

...gone are the days when a simple email to Guido was all it took to
get a proposal going ;)

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb@init.com                                      Lexington, MA 02421
                  ...So much code, so little time...



From Donald Beaudry <donb@abinitio.com>  Mon Apr 23 19:22:03 2001
From: Donald Beaudry <donb@abinitio.com> (Donald Beaudry)
Date: Mon, 23 Apr 2001 14:22:03 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
References: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com> <200104230533.RAA14282@s454.cosc.canterbury.ac.nz> <15076.8908.65608.249318@cj42289-a.reston1.va.home.com>
Message-ID: <200104231822.OAA08502@localhost.localdomain>

"Fred L. Drake, Jr." <fdrake@acm.org> wrote,
> 
> Greg Ewing writes:
>  >   class Foo:
>  > 
>  >     def ftang(class c, x, y, z);
>  >       ...
> 
>   I like this syntax better that the others.  While it requires that a
> single namespace is used for class and normal methods, I think that is
> a good thing -- we don't *want* overlapping sets of names!

But... we have overlaping names!  __init__ is just one example.
Further, that only works for methods.  How should class attributes be
distinguished?  Perhaps you dont want them.

Should a decision be made to go down this road, a big choice lies
ahead.  Are class objects "special" or are they simply instances of a
different class?  Because I didnt want to make a whole pile of
decisions regarding the "specialness" of class objects, I chose to
make the one decision that class object's only distinction from other
objects is that they are instances of a different class.  This is,
afterall, how all objects are distinguished.

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb@init.com                                      Lexington, MA 02421
                      ...Will hack for sushi...


From thomas.heller@ion-tof.com  Mon Apr 23 19:27:10 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Mon, 23 Apr 2001 20:27:10 +0200
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
References: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz> <02a701c0cbd3$a21f9290$e000a8c0@thomasnotebook> <200104231812.OAA08354@localhost.localdomain>
Message-ID: <08bd01c0cc23$02cdb050$e000a8c0@thomasnotebook>

> "Thomas Heller" <thomas.heller@ion-tof.com> wrote,
> > Donald Beaudry's objectmodule uses the metaclass hook to provide
> > class methods. I like the resulting syntax very much:
> 
> Thank you.  I like it too, especially because MyClass.__class__
> returns what *I* would expect ;) and the source reflects that too.
> 
> > If I understand correctly (objectmodule does not run under 1.5.2 or
> > later), an instance of __class__ will become the metaclass of
> > Object, and __class__'s methods will become class methods of Object.
> 
> That's correct.  I currently use objectmodule on 1.5.2.  I would not
> be surprised if it doesnt work on newer versions though as I have
> never tried it there.  Perhaps you found an out-of-date version, or
> perhaps I never sent out a newer version.  Regardless, I'd be happy to
> get you a version that works with 1.5.2 (or upload one somewhere for
> more public consumption)

Sure I would be interested: Please send it.
Thanks for the description, I've (eagerly) read everything I found
in objectmodule-0.9.tar.gz - except I found that it would be easier
to step in a debugger through the c-code, which turned out to fail.

BTW: I just exchanged a couple of emails with Just van Rossum,
who had something very similar to yours (but you may know this already).
He pointed me to some discussions in '98 in the types-sig archives.

He proposed an additional hook in ceval.c (which would probably break
objectmodule). I've attached his proposed patch below.

Thomas

+       /*      __BEGIN__ of Just's Hook
+
+               Guido's metahook is defined as follows:
+                       - if one of the bases has a __class__ attribute (but is
+                         itself not a class!), call that thing with (name,
+                         bases, methods)
+               In addition I propose almost the opposite:
+                       - if the "methods" dict (__dict__ from the Python
+                         perspective) has a __class__ key, call that thing with
+                         (name, bases, methods)
+
+               This means that metaclasses are not special anymore, and
+               you have to specify a metaclass *explicitly* to get meta
+               behaviour. Example:
+
+                       class Foo:
+                               __class__ = MyMetaClass
+
+               as apposed to
+
+                       MyMeta = MyMetaClass("MyMeta", (), {})
+
+                       class Foo(MyMeta): pass
+
+               as it is with Guido's hook.
+
+               Reasons for this new hook:
+                       - Guido's hook abuses inheritance syntax, making it
+                         impossible to inherit from metaclasses without special
+                         trickery.
+                       - implementing Meta stuff seems cleaner. Or maybe it's
+                         just me...
+
+               At first I thought Guido's hook would not be compatible with
+               mine, but they work together beautifully: inheritance works
+               just like you would expect.
+       */
+       {
+               PyObject *callable = NULL;
+               callable = PyDict_GetItemString(methods, "__class__");
+               if (callable) {
+                       PyObject *args;
+                       PyObject *newclass = NULL;
+                       PyDict_DelItemString(methods, "__class__");
+                       args = Py_BuildValue(
+                               "(OOO)", name, bases, methods);
+                       if (args != NULL) {
+                               newclass = PyEval_CallObject(
+                                       callable, args);
+                               Py_DECREF(args);
+                       }
+                       return newclass;
+               } else {
+                       PyErr_Clear();
+               }
+       }
+       /*      __END__ of Just's Hook */
        n = PyTuple_Size(bases);
        for (i = 0; i < n; i++) {
                PyObject *base = PyTuple_GET_ITEM(bases, i);
                if (!PyClass_Check(base)) {
                        /* Call the base's *type*, if it is callable.



From pychecker@metaslash.com  Mon Apr 23 20:46:29 2001
From: pychecker@metaslash.com (Neal Norwitz)
Date: Mon, 23 Apr 2001 15:46:29 -0400
Subject: [Python-Dev] PyChecker 0.4 - new release
Message-ID: <3AE48695.EE89C468@metaslash.com>

I've released a new version of PyChecker, the source code checking tool.

The most notable change is support for .pycheckrc file to specify
your own defaults.  There were also a few new warnings added and
some bug fixes.

Here's the CHANGELOG:

  * Add .pycheckrc file processing to specify options (like on command line)
  * Add new warning if module.Attribute doesn't exist
  * Add new warning:  Module (%s) re-imported locally
  * Add glob'ing support for windows
  * Handle apply(BaseClass.__init__(self, args))
  * Fix command line handling so you can pass module, package, or filename
  * Fix **kwArgs warning if named parameter is not first
  * Don't exit from checker when import checker from interpreter

PyChecker is available on Source Forge:
    Web page:           http://pychecker.sourceforge.net/
    Project page:       http://sourceforge.net/projects/pychecker/

Neal


From martin@loewis.home.cs.tu-berlin.de  Tue Apr 24 07:24:09 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 24 Apr 2001 08:24:09 +0200
Subject: [Python-Dev] ineffective optimization: method tables
Message-ID: <200104240624.f3O6O9001146@mira.informatik.hu-berlin.de>

> Unfortunately, all my benchmarks show this patch to be ineffective
> in terms of speeding up the interpreter.  Anyone know why?

I guess because you took PyObject_IsTrue. After profiling some
application, I found that this is a frequent function, so I thought it
should be optimized.

I then found that most of the time, it gets Py_True, Py_False, or
Py_None as an argument, so I checked for identity with these objects.
Indeed, that covered the majority of the calls - but with no
significant speed gain when special-cased.

So I think I agree with Guido: even as these functions are frequently
called, this is not where the time is consumed.

Regards,
Martin


From skip@pobox.com (Skip Montanaro)  Tue Apr 24 14:17:24 2001
From: skip@pobox.com (Skip Montanaro) (skip@pobox.com (Skip Montanaro))
Date: Tue, 24 Apr 2001 08:17:24 -0500 (CDT)
Subject: [Python-Dev] tickling version numbers during release
In-Reply-To: <20010419075326.F30408@ActiveState.com>
References: <15070.41140.642307.450172@beluga.mojam.com>
 <20010419075326.F30408@ActiveState.com>
Message-ID: <15077.31972.989862.905462@beluga.mojam.com>

    Trent> Or preferably have the version number in only *one* place in one
    Trent> file in CVS then (1) have autoconf massage template files to
    Trent> insert the version number where needed or (2) have those files
    Trent> that need the version number *include* it from pyac_config.h.

    Trent> ...except we are not using any auto configuration tool on
    Trent> Windows. Damn.

That's not necessary.  I think if you have one file in CVS that contains the
version then you can update other CVS-resident files that want to have the
version also.  You just have to do that from an autoconf-compatible machine.

Skip




From thelink <electro-owner@ml.poplist.fr>  Tue Apr 24 15:21:54 2001
From: thelink <electro-owner@ml.poplist.fr> (thelink)
Date: Tue, 24 Apr 2001 16:21:54 +0200
Subject: [Python-Dev] WWW.090000900.COM GAGNEZ 1 AN DE COMMUNICATIONS GSM ! WIN 1 JAAR GRATIS
 GSM-GEBRUIK !
Message-ID: <007601c0ccc9$e9f7d540$01fea8c0@jctubiermont.brutele.be>

This is a multi-part message in MIME format.

------=_NextPart_000_006E_01C0CCDA.AD2CB8E0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_006F_01C0CCDA.AD2CB8E0"

------=_NextPart_001_006F_01C0CCDA.AD2CB8E0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

--{  Liste h=E9berg=E9e par PoPList  }------{  http://www.poplist.fr/  }--
--{  Voir  en   bas  de  ce  mail les  options  de  d=E9sabonnement  }--
______________________________________________________________________


GAGNEZ 1 AN DE COMMUNICATIONS GSM GRATUITES !
WIN 1 JAAR GRATIS GSM-GEBRUIK !

=20=20=20=20=20=20=20

TELECHARGEZ PAR SMS 1500 LOGOS et SONNERIES AU TARIF LE PLUS BAS ( 30 bef /=
 unite ) !
DOWNLOAD PER SMS 1500 LOGOS en RINGTONES AAN HET LAAGSTE TARIEF ( 30 bef / =
stuk ) !
http://www.090000900.com

$


Pour vous d=E9sabonner, rendez-vous simplement sur cette page :
->  <http://cgi.poplist.fr/@/u/electro/python-dev@python.org>

------=_NextPart_001_006F_01C0CCDA.AD2CB8E0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff><DIV ALIGN=3D"LEFT">
<TABLE BORDER=3D"0" CELLPADDING=3D"2" CELLSPACING=3D"0">
    <TR>
        <TD ALIGN=3D"LEFT">
	    <FONT FACE=3D"Verdana,Arial,Helvetica" SIZE=3D"2">
	    <NOBR>--{&nbsp;&nbsp;Liste h=E9berg=E9e par PoPList&nbsp;&nbsp;}------=
--{&nbsp;&nbsp;<A HREF=3D"http://www.poplist.fr/">http://www.poplist.fr/</A=
>&nbsp;&nbsp;}--</NOBR><BR>
	    <NOBR>--{&nbsp;&nbsp;&nbsp;&nbsp;Voir&nbsp;&nbsp;en&nbsp;&nbsp;&nbsp;b=
as&nbsp;&nbsp;de&nbsp;&nbsp;&nbsp;ce&nbsp;&nbsp;mail&nbsp;&nbsp;les&nbsp;&n=
bsp;options&nbsp;&nbsp;de&nbsp;&nbsp;d=E9sabonnement&nbsp;&nbsp;}--</NOBR>
	    </FONT>
	</TD>
    </TR>
    <TR>
        <TD><HR SIZE=3D"1" ALIGN=3D"CENTER" WIDTH=3D"100%" NOSHADE></TD>
    </TR>
    <TR><TD>&nbsp;<BR></TD></TR>
</TABLE>
</DIV>


<DIV align=3Dcenter><FONT color=3D#000000><FONT size=3D4><FONT=20
face=3D"Times New Roman">GAGNEZ 1 AN DE COMMUNICATIONS GSM GRATUITES=20
!</FONT></FONT></FONT><FONT face=3D"Times New Roman"><FONT=20
size=3D4></FONT></FONT></DIV>
<DIV align=3Dcenter><FONT color=3D#000000><FONT size=3D4><FONT=20
face=3D"Times New Roman"></FONT></FONT></FONT><FONT face=3D"Times New Roman=
"><FONT=20
size=3D4>WIN 1 JAAR GRATIS GSM-GEBRUIK !</FONT></FONT><FONT size=3D1></FONT=
></DIV>
<DIV align=3Dcenter><FONT size=3D1></FONT>&nbsp;</DIV>
<DIV align=3Dcenter><A href=3D"http://www.090000900.com"><IMG=20
src=3D"cid:006201c0ccc9$e9718e40$01fea8c0@jctubiermont.brutele.be"></A><FON=
T=20
color=3D#000000 size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><FONT =
size=3D1><A=20
href=3D"http://www.090000900.com"><IMG=20
src=3D"cid:006401c0ccc9$e98b7ee0$01fea8c0@jctubiermont.brutele.be"></A></FO=
NT></DIV>
<DIV align=3Dcenter><FONT face=3D"Times New Roman" size=3D4></FONT><FONT fa=
ce=3D""=20
size=3D3></FONT>&nbsp;</DIV>
<DIV align=3Dcenter><FONT color=3D#000000><FONT face=3D"Times New Roman"><F=
ONT=20
size=3D3>TELECHARGEZ PAR SMS 1500 LOGOS et SONNERIES AU TARIF LE PLUS BAS (=
 30 bef=20
/ unite ) !</FONT></FONT></FONT><FONT size=3D3><FONT=20
face=3D"Times New Roman"></FONT></FONT></DIV>
<DIV align=3Dcenter><FONT color=3D#000000><FONT face=3D"Times New Roman"><F=
ONT=20
size=3D3></FONT></FONT></FONT><FONT size=3D3><FONT face=3D"Times New Roman"=
>DOWNLOAD=20
PER SMS 1500 LOGOS en RINGTONES AAN HET LAAGSTE TARIEF ( 30 bef / stuk )=20
!</FONT></FONT><FONT face=3D"Times New Roman" size=3D5></FONT></DIV>
<DIV align=3Dcenter><FONT color=3D#000000 size=3D1><A=20
href=3D"http://www.090000900.com"><FONT face=3D"Times New Roman"=20
size=3D5>http://www.090000900.com</FONT></A></FONT></DIV>
<DIV align=3Dcenter><FONT color=3D#000000 size=3D1></FONT>&nbsp;</DIV>

<DIV><FONT color=3D#000000 size=3D1>$</FONT></DIV><DIV ALIGN=3D"LEFT">
<TABLE BORDER=3D"0" CELLPADDING=3D"2" CELLSPACING=3D"0">
    <TR><TD>&nbsp;<BR></TD></TR>
    <TR>
        <TD ALIGN=3D"LEFT">
<FONT FACE=3D"Verdana,Arial,Helvetica" SIZE=3D"2">
Pour vous d=E9sabonner, rendez-vous simplement sur cette page&nbsp;:<BR>
&lt;<A HREF=3D"http://cgi.poplist.fr/@/u/electro/python-dev@python.org">
http://cgi.poplist.fr/@/u/electro/python-dev@python.org</A>&gt;
</FONT>
	</TD>
    </TR>
</TABLE>
</DIV>
</BODY></HTML>

------=_NextPart_001_006F_01C0CCDA.AD2CB8E0--

------=_NextPart_000_006E_01C0CCDA.AD2CB8E0
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Id: <006201c0ccc9$e9718e40$01fea8c0@jctubiermont.brutele.be>

R0lGODlhgACAAMQWAPSpi4Y2a5FKeapmk/KPaP7+/uxeJvnSw7FJUO1pNM1S
Or2Tr+94Sfe/qPjn49Gzx+RbK/z089/L2Prf1OldKP3v6f///wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQFZAAW
ACwAAAAAgACAAAAF/2AgjmRpnmiqrmzrvnAsz3Rt33iu73zv/zSIcAihUIjG
4nGYZCaXRCTTOV1Cp0JrFvrENqvRsBRlKJvP6LR6zW673/B4nIKiyO/4vH4P
h9T5gIGCg2Z+J3aEiYqLaoYmiIyRkoGOJZCTmIAMAAcOEREOBwAMd5Ukl5mp
cgwHBQUREwedEa4NpH1/qrpvCQCvBwQJZwkErREAwm6mI6i7ugkMBAAEDA0F
EwRtBA4FAG/LIs1x0LfOBuTJbAQNtK7u2W4ME93KuWsE+PnSwQAVE+V3elE7
s2mUm37/2CSwVkDUugIVrsFrw8ATwDTgAogz466jK2muLsYhUOsMyQIT1//4
ipASjbUD5axJ+9RSDckDbTJuLNOgZ8QIPRv0esUAWjozDESWOdmAIACDw4qa
8VVh4tGTBxpkI9nUAIEIFY6uaaW0jM42CdK2+pfWgLUInRxgM0NgQoUKwNIw
JSiLVLGsDuTCo5oNwAShZRLM63hg3kRf3tyQjNzInsK1Md1FhOiXliyILffS
pVVYsysHpStEi0iZ5LGkDBOaucsLLpuzbhJgNsMwWG/F9NwWQEy35GiUBgCQ
HnosucRWxJ1TXjj8qLWyZ+zetrxG97XMEfx+THBaVkQHAEUvJZ2cFikGr7yt
jCibZ3iT1c/4qpmm1fZDvOzGE1FejefKJ2DhlZ7/ceshp1wB78XnnDsTWHdf
cdE5xx8a/q2BG1oCCnffScG44o0wbeE3nEnsPRhhc7440EBE0flCHHUZXvdG
YP89EuB3vBFIoneoJTUNGljlE02L7hkAH4wFoNdbccPh0wqQs4WVW0M9WvJj
fW+Jh9w2HlG2lEfdfOVgSE5KuFJS81wInDtAtfJYcG1A1uUpvADQADJ09SRM
NbaUUY0sf15EaFC2EPqeoOf0tFVPfjWQ15lAHckAXMJ8pSVaE1xYGYDmqGJN
oQNOQ9MbNubEXamSUNfQNG9J9MZX6LlKKqyprNNOR2beE9GGhbzKa6zRTLMJ
RICq0Qt79ex6rDlkOgDV/znSzIMaLtJO68yzByLoSgXXRuujt7wSY6ksDoll
rpfoxrvHh/LWGwe99ua7JzMGXCHGvwAHLPDABBdssMBm/aEAAgw37PDDEEcs
8cQUV2zxxRhPDIEBZykAxMcgv7BxxyGXbLIJIyt88sompwygxyzHDITLPsIs
88070OylzTj3bIPOfPLs89AxAM2v0EQnzYLR4RiAtNJQn8C0Rk5HbXUKU9vx
9NVWZ10112CL4PXWYSc9dtlgn82CAGyzDUTbbcMAt9shq62CAAPknbcAL+i9
twp+/+1C4APwnQLhiBuONccqp4A34YqzEHjkJTweuAuW+w044okvTjIKmftN
+f/meo8+Quh5Y4446ZxPjoLdJbReeN+iH9655LefIHvuJMAuAuquD177CcCn
vkLxA9guetucS834y5XvPrvwpYPe+trXo0B49Jej/HzNJEgveAvBmzD58Mrz
Hn73JIQ+ut3Il4979bqLzr729mtev/7tyy/29ztb3/IgRzv6cW9vobvbAPkX
u/v9zn8BgJ3lDIc60+HPgAL8GwRH4LoNbu+A4xuB7+j2wA1eMIQc1N8H92e8
FWbQeKdzoQgBGLTjEZB6KAxAAnXowBjqb4cNXB7bmue9zznuhuRDXwrp5z4W
Tq+JQRTf9ErgOxNUsIA5LJ8MRaBFJXJRilOkIg2PZkP/EzqRckAMwBbTuEUw
WjCCY2wa2UroRdaFUY1KhOISQ6jHL+7ujf8zovXMaD4vgvGOh6Tc9pD4ujhS
bY48JGQUwxi/1fkQjJNMHh7r2DtHaq2MnDxhGA85PlKOsnuoU0EVQZjD9J0y
kXuUYuRWyEgxCpJ4tbSj4tw3tyGicnK9TGUsNelHDHbylpsUHyCTOcUt0rGF
PSwmDJlJzEgy8JiNe+EfV9BFY15Sg6HUowxzCUdkwlKXz7yjNvuYyWGyspoz
NKcbuTk8Zw7TntIkZhu3WMVzutJw+LSm+lgJ0B5eEZvQy6TsANlEdr4zlOnU
pDOFGc9s+iCgaCuiRXng0Ix6/26jOqCoR5fmya9xlJwjdR4ycdDRlDqPDgnt
geVcKrJ+gTSky6RpJw1wU53GbGM8jalPcQbUng71ZEUV6lF/WgajLrVuTVXq
U5EaVfBNlalBtepVV5ZUrW61ZVUN4FepmlWxjrVkXTXrWUGW1hquFapl5RME
MkbXutr1rnjVWFj5pK++ssFYfvUrYAOrr8ES1l6GPay8uIMPd1FkIKmIBnZg
ZY8HuQImBjCGGWgxAUNx4zQpIYkDyhCjVJ3kHZxAFGUq4g7UoAklHbFWGVwx
2wI4iV2iSMaVLptZLvV2Irl4Eq1wYoDPZgM+tDUALaYBAAeIhU1XEgY3ohGl
p8gnSv8HoEVXlisN5z6lFaKYRnVdZIDk0tY1nbiGMKDzlGxcyb3I2Su/nEPc
M7jjuudN7liQ8w7yRKBA9ZXOOUhzEjXoCcCkpYd5bXuTMrTCG3Y6w5VwEmH5
Ns05x0hJlLhkDAghVyuOhQx85iFenDR4KsGxxihqEQz9BOfEKi6vbWWMYOd0
tsIOvgaEcJyLBPxqWzfhBnlCgZzdNgdJsxpOkr1xWnoc2BcUphNlDozeOAlj
wTUu8G5n/ODh8HhXm/gshG6i4uHs5xyGuS8a/Lufa0RYtO0VMH3RvJjgUDm2
8MDyibVs5sjYyRNfPheL0tQNX3zkwIaaR4DLoGjbzmMeZwrY8JNXhBRFJzgy
N1lJMvTsW9H+VsIoiVF84zpfDhW6G8gtwFCCBeU0GLqzhibuiS9dBm6w2rd3
jnJXOE3cU33aDHby8UfMkAtOMJcoerI0ZLbBXGipqCmGxvR4jy2KtXjFWjOJ
b67bxN8Z59daYertn57yaUMDl1SWjRIpYqynTIv5yGs2Ebfh0eRTnwYxzZUy
iqVN3Fab97+nhcsttmzbCCP33IJ2EmTjIFlVNJwPMU5EYhUbkFg4lg8Tp7gc
Lg6IjGucVx7/eKnIIPK+vvXkKE+5yle+gxAAACH5BAUKABYALAsANQBpACIA
AAXgoCWOZGmeaGoFgaq2I+zOdG2rwl3mNp/6L6DuJhsJU0XRkbQcOp9QZ7MX
HU5n11O2yi0ljbOv8scs77roNBlM26rZUrML6H4/hXULHkWv9e1hUGImf1SA
WiSDfIl+codvhW2OcHqPanmEhkoyR5iXUJ6UlmqDW4qZo5CTc6tnqVV5SbGu
a6+2mpWht1igtJW/u7U1nDpFkcHIvHC6yahxlJgC0tOE1Hetwk1Tx77Nu9ze
J6er48vYzXl7jYiiwGPJzL3t4uEo5Uiu4M5o8fWj9/6QAQxIsGCzgQZtwehn
MAQAIfkEBQoAFgAsCQAnAG8APgAABf9gII5kaY5Cqp5s674wq850Gsf0re98
Wf+CnqkmLBpPQOIxkFs6jcnZUvms7qKrY9PKxWGDUGl3/PqCi1uyeogNZ9dw
0td9jtvNwrQdju+J93dzfm+AcYJXhIV8bTBZf4qLUS5Eej6VclSNmWxmSS2H
Mpcom5OkmJ0/oaBIokypXqajqKadmo+Wr2VAn7OkqLY2vLmlw7hSv7LIwonJ
safFz8HNub2isZK6u6rMjK7Vt97MIjmt49ic3OeU1dF10eHuxjbWld3e07Xm
4vD60qyO4Pr5E6inzjeAAZs4U3hpkz15qdr42kLvT8M0q/DVywjvTMU3Fw/+
O9eO1iOThCb/fhvpaZu2ae3Q+VPJDl3HgRAL6kx3a+NKYwRx5sTZa2hLmPme
BY0n82RRjSQ7Lk0o7SUxjE+nHiUIlehMaCxTZr0JisrDexpvDIuojlywtRS3
drUa1uPHt3cNxqVLlmNMri6DLNwLkm/fsxCbXZ0XECbgvqwOO3M82e9jJWcZ
Kwv8uG45swzlHmQac7JWYHiPlZ2l1jSkkkIluw76ujXYzrMN1za6jGm507t7
N+Y3EvXv13KBboPVL3jgffqyDYq9Ozkb6TyGI7duyVZ26Ntvd8euQ7si7tfJ
w6J+Hv34q+XBtxefHr5t0pDc1+993znw+Nmwp5R/+kW22Hr4AVLgIT/CJdic
cwuq8hwwEOrWHy6yHFidhfFVZRF05kVCnwshAAAh+QQFCgAWACwJACcAbwA+
AAAF/6AljmRpnqKArmzrvrClxug82nSut/ju/8CgMNbrDY88pHJ5NC6dzKgP
qqNKrysrS4uNcrndMBJswpHF6LR6nWS7d+f3FBuXw+qogF5mpwMDFnt/LICA
IoYviIeEJIVDios3iYEtiII7kCWZNE57mzmOeT+Ohp+HpaGmkpqeI5Bal6at
lKqulK6yoi49m5l4NLUmgrm0hZeTi3rHJAJUip+pyyvKxi6kwXmlOZ2WotUx
ltSMp0fYzJq41uiV5LYn4T7Pc42R3sDdtNPp58Ap87fQboF6pypWCSs4EP1a
5amXu2vWtLlbFwrIlzbt6GXcJyzZu48S6xHhtBBex48b2f/RMzdkYSVptuTl
W1cFhiInsGgeM4hu1qmQMQOxRFhDx7JUwpR1BBrRGMssQl89Eik0KMqoOykW
E7KJ6NV8FXfKlInrqEeBRfnxQTvy5M9xkLAFZFqT3FNdPdlO3KtR2zNScFZt
DZLJKdaseZViFckTo7+y0O5qrPr1od6UE2EuqRhP80rL7PBRpuJysphqntHi
C0X64GMsJrMlA6wvZOy2ZDj3o8qqV0GO8EqrkywZ4Ki3l1l18dXnROs3wr1s
K9Psl2LBzXe9KOKaUfE10cuolZ39XxAuSsNL/wEmjvo0XttzKt9kO3bH5V3W
OfM+zMX59AVYXx/P3dEWgAK+ZqApEv3lV9cW9DVYoIIJdleheAn+4pWFzl14
X0s3NOPhgYGFyJ19H47IQggAIfkEBXgAFgAsCQApAG8AOwAABf9gII5kaQZC
qqZn675w7K40Lb+1cO98X+Y5HykoLBpPQKJQeWwak7ZlzUl9QlXFaXXbu6oG
izApvBiMBOQAOMwiL8biLVlHWr9bZDPczaYNCoBngAUSIwuAEgJ/gHQSg3oB
g1yOBZAilJUniwUPJZiDBREDNI8imxEjD4APipKXg50irlWUlgKgdyWqg3Sv
oIOiWJR3h7wiDoALrYG+jLLMtICWxREFDifV1QW5AbUpC9rKbavN2yi8ywUj
n7GzOGGWJ7UkjhHzdavk69Iqu4ksi65FwqUGUYpN+wg5c9diADJzL+6d41SM
W4Bdi1AlHPXNIItbjBb5C1CMVbqEFQf/qntRLBkMiRUXFSKRrZu0jQfDYQnw
EEwyScMOzqqVDeTKFrsGWTQh0ZsxU+RKJpwg4WEojnR2hZFWq6dQaLUqUmLp
YCtEF/dAahyWymXGhL8iiGNBchUlNNIAOfgylB+isTNEpIx4sy6hAQN2xQoQ
DnEpmwo9roBKCNm1YpRMnvRlZtdDGYPRFv70S8emXxDDKo3CGFSngMn4gr15
+ihLl4QzGUVtriVqgd4oRWCdFKI2fl+P3rNq20XoFvMwI0asmGey6ZvMeBOg
TXMv33owDZddgMU93zDCUJKgzIW2zrgpVwKkESVkji054jOGV3I6FRId9xJq
8ZDwiFG9PGON/z6GIHKfCg/9U8Ig1yQ3138pwMQQUwS6wEsxApHgWXzyCbBd
Ou3VMd0KK3pBFxclgAijFy24eAWMYzy2BY0m2MgjjqrIheONPf74I4wpzghF
kVpMNkQSOEb5JJQ/aIHCTlUyIeWORJ7B2pVYZmnlllV06WWYYL7I5JdkOmFm
mmrCiUMNC0jAHh18JIhGGWrwwUYcatTzwFI3vMmmnHPm9IsZcUEilW+ILCIY
IsgMJwWVZyaYqQwQcqJDHNIM4MhMF9GHgmPbTMcMMncgdikQYmoqgpMwdFSe
psxIKosDjkBSmK4MZrHklLLOiuYMh0ho4EqHCPTHoJyM8CszlDjwQP+BhWK6
KRLH1jgqGnayp9JjqpRhjbSZFLSSQ675YGi3xsZJWCItvaHXVSNUY26609oG
xntdDLttFLTGoMo/JprDCKvyKfWMHroOQSKn2sarw5EwLMKRI/aqs4gOB4eh
ikD9miLIWRRXDCfGMIwcBsPUEtKaHiDpUPItZS1gWbEzqLzym7UWJwGj6+YV
ok0dQxxIYqAkwgPQP0Nd40GjbIkYz4nCuqaNTxfcZrY+rxyrvFlj/fXUYa9Q
552zPlDNBNcKBugcxILLNkl89JnHCHbwqbch7bGBtx5z+LEAK2vgfYeioIxS
D1sq0dHTlAMcd9Mvl/0yE6SdJIsu0dqZs8j/hR1NgPRANAuADCt4G6ZCe0a9
YZQtKaz+6R3XuXrItSnt7lMlnj+M+umOeMdXIYe80eusxWja/GSbdO6wl82b
UNikd3BcV/bbBD/8TRwfMl4NfyBvzvIoeM/3IHcKZVmpDFMvs/UUBc4JYhFY
mjwK+np/eSbFqwZW/CCz/aEvYcgL1xt8E4zkIQMk+/PSqEiiwHFlAlLE0Fxd
SPW/0FUDYeSLlgHThUDDQARcBkmeKg5WvidNsF4DKUPVkhUGAdblIazzXybA
tw19wUp0FzyKAA62D4vsAi/m0lcLvUTEVyQtRxk031b0N7/vAbB7VwmCuERl
hjrtpxHbeNHIEqaMq0f8IUSyAeMTG3QHIo5QejMBCeiQJoAJEEILVVPDrGzh
Mp1tY4WHi83yHEEyIfbDGi9TGCHC5RNesWV/GpOJHzXCQ2WMzklnrEsntGcs
oYHBKnJJgR27GK2BZKo/kbIg8EAhpO2JwI3HcYAeKpmhLPaihSOEBIvyuMcB
ki1Wp+LlFq6GNq2Zgg40i4fXTgmvU56tmFoCW7HCZrFffk1qKVMTNg/1zKhZ
8wUhAAAh+QQFMgAWACwKAEcAbAAaAAAF3WAgjGRgmuR4rmeasnAsz3TNujj6
3vuMC7agcBj77XorpC9HbDqLRpVIqZPWfs9sNiqlVoFBpnYs5LZKUOtVTG6n
jWfwe8h227/YKv5Ld93/eH5xU2Z9aIBuXHKEimo2dYhbUTyNjmtekUSKlJWL
l4eZT5tJnZY0gqFOo6SgjK2fnqllhayxrrZLr7KwkIwyqGGYu7+Tabmmx7jD
MKuUp7rJy8FwxMquhsjScdTG0bPQ2oHChJ/Y1tK01bDf2ejp3d684W+9zs/g
te3D79XKeff6dvHrlywgsHnNaIQAACH5BAV4ABYALAcATgByACsAAAX/oCWO
5GKey2At0lOm4gDLS2wKAroIYq6vMItPqOP5irqaTwVkkp5QUmFKLdQcU+fU
IVpYVwWJCOsaVAsRlbnqknwta/jZIVifBXN5wWVxO6OAIwMDDwUTg3IRbxZU
NV6OYRaFdHISg25lWYM8bjV6lYNYO5d7iFMpiHYqfoGtJZFde7CMilyPYJZZ
MbBemQVPnbu/ZmK4I8EiuoJoe30Ff66AXsUWE89TPIxhVrfT1p5yDiYRaXon
IshxxEKYx4tTDzdyE4oDrNGt07sRzp5ZBeK+eFH0axkbHnamoHuj7kyEbP1G
nFETptCDe/ik8QpDCJZCMgLDuKFGjJSYNYOY/6RTaMaBIgkQIyazsgnUFIwZ
oeirdqYAD4VeROFCuavYmjoKSawcxlHZQnBOK0kC+CynxpOnTAhNiiWkmEIP
pYLxGUcpQ5aRgpqFWnUZ1qhWR+jbCcZFUi9eRSjKFEGCm0hr/Pod++DBXqkC
FIFDpk2wpXVT28Z9JeabQTwFLSg2NjbFmQcIe8aiAlPswGyMew6CRXSy69dx
a8KeTbu27du4c+vezbu379/AgwsfTry48ePIkytfzry58+fQo0ufTr269evY
s2vfzr279+gGwlsNb0A4+efk01s4L4J9evbtDSQAACCB+PUMLDRoQOD9/AYW
EJBAewwAsF9/5M13wP8B/NnnXnnrlffefRNGCOGE6lko4YPvPWEAA2gwcB4B
ipBTwAH2BVgBGiKgGGCJiqD4oTUmBtghhRtWqON5FXrI448QAvJhARU4+CEW
AMxYAIAMVCBCAgzwJx8/AFjAgDUAAjhBfhYkGd+G8Vn4pZgjqIdhkBpqiGEU
QxZJXpUTOEgAiwCceGF4cJI3Z5wAHsCAkWPiSCaQJJy5pqHi9VgoiG6Gl6WD
XEa5pHwMVGrAAZOGxygByUwAoJE/hsmhml/eiOihihJIpIMDdhkhiL9gmiQA
E0zgJ6YWMkCOgA2sOIWMD4qKY47DdljmqfCl+UR+Ra6XAID1aToFAQ1MSoDM
NQFiCqC0FfSXAAEA4JpksBEOmuh9pWZ4LLI+oikCswPiuaScaMw3qZUTWFnt
Ae3N6YCI4iXA75jlljtqssiiSuyay1rQbHgkRoAgpgeUB5CICVhDAIgRALyv
lSK2qF+agp6pZo4nm4oyolFwWYEDDsyKxgH5diwfgBUsOK0BVUZAM5GV0mOr
NRVwGarBPe5ILMEZJfuEwLXWWuW3B7zcAJcWUP3yAQJmTUDVDlyddbiKVCB2
IE5312oUCaxNQttQtO02m2l/R5y7s4UAACH5BAUyABYALBEATgBdAAwAAAVZ
oCAGgTiSaKqapuq+cCzPJWvbdIrnfJ/fwFbv5isadUGgj3hs8pLJ4c5JjUGD
S1Z164qSlFIhd+z9Tn/aMRe6Sj/daiobKUbX48dr9z47441zbXxWcH9ZUSEA
IfkEBXgAFgAsCgBKAGwALgAABf+gJYrCMAhjqq5s675wLM+LU9yFs6DiIP2D
1E8STA0ek5tkp1oMhwvm6Pl7LIq9YdH3WwiBK+fNsUw9cOjbFoe1sFOL9C3i
HcXlhQgWf3vwBm8WgDg8bmpwEXhEFnd5VhJKI4MFbYGMOBE/aFiNcnoifH09
gZMFdYaUdmgTEjZ5QUmvkn6SlqhFAokFEiO5Y6o3wAUPoDd1ApCHk2uYPJa6
E1g+RTi8LsspgY1t2yKNQnPFprXGgqRpddq2KphtKtgjgcnW2aKXwVM44qeT
XvCDrhyIKxJrwotkY6ys6GfCRCAcxFS4svYtX4595Mb9U3Jm3EN7LUphOmUu
VKp+KxD/etO30h6OYwhRbDQW6Q1KQQ0betOVJmLJUEFugsPXKU0EZ6HqzCxg
wZUPZS9FdKwG5wHPQz+tROkm1CLTe5728PG59N6DZEGjgo20EGFEeAMtCFCb
YmLLXVWkiCPTpU3ZuXnQ/jwWxS4LwLtGYY3blG29YXdf0F14Dt9UrLp8ipjn
AqLiVPGwdozwTm3FFpNLY530WXS4obysFAKr1FblcRaPRu5cLuRtr6C7zpu0
RMyYP7YXN9KK8NRpFqmN/L4L2sLUJQMW6JJwOY0DacmrIxsLhyXq3izKjuDZ
BqEcYgusotExG+6tJq7GuHu+InpGZl/dtV9+fZAklwmzzXAN/4IKNuigDCWY
8OCEFFZo4YUYZqjhhhx26OGHIIYo4ogklmjiiSimqOKKLLbo4oswxijjjDTW
aOONOOao444ZAuCjjwyI4CMBFgAgggEWEAAAkQYYwMCQCRTpo5RTJgDAAQcA
kACSSgLQ5JNedvkjkVZiCUCQJhpF5AEFGHmACFEC0GaTcjKVBwFs2snUma64
YQEDBtRJgAEEFHBAoGkQkEAsOBBZ4g0E4FmAQWy66YaRcnopZwRLAjBBlEpC
SgADbDZgQAJsHlrnoYWqWkADkSoqpwMMWGlkml8VylSlFrwZQQRWMpUApBY0
iWSTuorAwA2A/snspkm2WmSbKbBpkP+K+MzaK7VvJuFjm8kWayyyN9BZLpKG
fEtpq4jCOuq0k56JohxrcjutA5nW+SeWWZJbgLkTNFnMtwDY4CaiOBi5KBoN
nDjGnSLw+qakleq7bMT+mvsvujcQLGeqSOYw5AgENKDLrSTekIDBEdsbaQ5M
hYvooYSeq6vAyxYQqpYR2FDsxy2sbCiuSTK7raWDxqLlpT8bmnGTiQyKaASI
ahrMzCmgKUISDT/6VapH95okwlZzeqXTNW88tY+JWO1lzq5GwG/BETRwdgFa
j4hPzpK6qXOTBtPJkwNMGjJunXl4iai4DTiNeMcm40A4j0cy8K4KAqcQaeYp
GAuD5XlPGAIAIfkEBTIAFgAsCgBKAGwAEwAABamgIIpBaQajcK5nOrJwLM90
7N5lar816vbAoNB3I+V4LF2vOGw6TUUlUSat4Z7YYBTJ+xFVwGt2PNuCjyqz
MVwlu6HmlrpNE7/fcfl8vfTe3Wore3RUfn9jgXqDQoaHT4mKZ2iEhUiOj3mK
MHZWlJd9W5uWkYyen3WhopKCpkmtp6pRO6usfJ2jsLdMs2WvcLi5lbK8wrTF
wWzDxMJavsGZy7O2x8i9qTIhACH5BAV4ABYALBcASABSADAAAAX/4CKN0hCc
qEgKLEtKCyqro/zG8klL8+svptyiQCwEbcVCi5Xk5QKSpKz5hEpR0aS24DgG
hkXvKUtcCqhPcmFadObUyO32CCaKrUUz+n097eNEgHJFEQI6SXdqem1VcCh/
WH14dgOVD1oxAnVGaVJLkGOSoJNrkUVCVJqInaefjKyBj698p6axKGeem4lX
LaOOfrOCwzlaLLuwpb7CtqXBRG7EobUoA0kOx00+EhG9TMzTtwG/ksAnl0UP
2YNyJ8vQjaLgpIIL9gsOWgPr7Fq4ufCSsQlIS5wadur49aP2jaC0cfPMHZQj
YckmIJUyAmtYIFqzgR3jUSO15cECM8gK/zrj6DGcM4gOPzYboCaTxVUq/5Eb
udOglAHdwqDEKY2lSHE9XzrahO1mGIHuABaIUCUfT0JVy/WxSiShQl4MBQS1
k0MqVRRjOckwK80aohYpiwpQUwIXXRnooB2Z+0diE7hEZQZQCG3EFhyHtJA4
/NBtkZOqnuYc3GIixWTsPJoTkHfqV6hmLP99wrdfxcmUxSY5ucsQMTNfuDZB
XAUfRdoynQo147rKvxa4Btzb55u0cHvEi5flvSQ1bOXPlUufDp05cOfNi/Om
zr17VOu9wWvP7r18detrWXzvvZy8+ffp0ctAQL++/fv48+vfz7+/f/sGBCjg
gAQWaOCBCCao4P+CDDbo4IMQRijhhBRWaOGFGGao4YYcdujhhxkSQEACHjIw
1YDdMEAgAQcQcYCKBgDAhYBJRABAgAAcoCMABAgIwFgvdphPjwYQUMAEK04F
AAATkGiAVTASsWQ+N7Y4QYsF3GiijQQ0cICHMjYQYANZEtgNkQKaOEGZBhAR
oJFfttijkREkIOOXIBqwZYApDmgkkgTKKCOgbsZYQJwFEDmkjFzmOSScgR5a
YD5PFqCii1j2KGeALQKQwFgOoMmhoGRWqSMDdxJo4peltknIjQZsGmuZqHIF
I4dqdkOiji+mOqCMSSBJBANncpqosbC+2U2yHK4pqapEOBkglUum6KZGjA4Y
26OJlhLY6YfAMiuglSI2oOa4WRZK5awNALBujjwyeiuu0RpoJyHL+nhooXQm
gOWRsP5YhAPz5nlgAiJuyAABBTMYAgAh+QQFMgAWACwJAC8AbQAyAAAF/2Ag
jmRZCmhqrmzrvjCbznRs0oKt7/yL1z1gb0jU/WZBYXHJPB1RSVVzOn1CeUqq
NnrEZrfgmDW3+4bPrbFXim6nrWWke75SG+X0/Ah+Z+vzfDBPf3R2LmN+hFuG
dYh4ilqMTo5mkESSe5Q/llWBJJqDnEuYoJ6ia12fiJmmpzaMqY8Bra6Cnpsi
srmptWKGOKqJrMC9tqG7iZWzuMWHgcTDZDLMzY3HX8rIutXR0NvbN9Dc3UJm
4JPnxb/C2q/Zvbfsy1fG6a7r9OH5Pu+n+GRA7AWTB+/YvByr+uxrBgtUHIGW
TJV6SFCUpFLS6i2sdXGiwowFDWrbR00jN1Lf+lYNBHmPViWV0arROvimor6N
nDC1q8nSmU1CM2ny7Dntpx6dO4vitLZUUVChPD+GLHmTn9GDRIE+RWa1aTeO
Iot2zbqSLKCwSod6xdqSVz21Ztla3DoiBAA7

------=_NextPart_000_006E_01C0CCDA.AD2CB8E0
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Id: <006401c0ccc9$e98b7ee0$01fea8c0@jctubiermont.brutele.be>

R0lGODlhgACAALMNALdLTOzBuq9tmfKPaOxeJZVSfoU1aoU2aoU2a+xfJoY2
a+xeJv///////wAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQFZAANACwA
AAAAgACAAAAE/1DJSau9OOvNu/9gKI5kaZ5oqq5s677kIs90bd94ru987/+Y
WSI3lBVrBOHROEw4ibolsyZ9OqtUW1FaC2aNt21SRnguxuUrzbouC89fJc68
eI6Zy+273rwvvEduQwR+TW9FhFqDYEdNS4lgPYE0Y2xieXWZZGwzXniHdHwJ
gjqFmqCnmoiCjYh8M26Zeq88oTJBiJyGh3Kisr67N0mNcJlJfpuwxjuWsGzD
sU+eg3SOxJGi1mSfwa/Retq0a6mnowMDAQzqDAED1W/DR153W6NZ9nWJo9fi
43RlkOzZO8boFb8rhBKgWxegYTp17RJS2ncHUKtfyeRYcTJM2D4owf/UGGSE
71QaJwMgusOzkMFKYKkAUYKXzwayKUIqFcPYh4u/MJEUnjuXrl29NSnZ0Zt0
6wKtk/eUnHMUjdY1nTiZTYUVy0jLdeoGUDm6UKygjp2cEqQytO3UogPQFBSD
9ByedmJ5zkjZbk+lh3gfshN7hW6dpHn3ZJo2MwHYx+fUcUH2LmmAWIj7CXlI
WAvcTOkiu/wl8jA7fGibWpgCSYZDhg0TPFSohlXiRQssCyGqjXamzL5Ms4vI
d0hSNSVjhQ5e0akhtIVnXwHM2SvgzkUsD0RH3OFn2WEXONzyePhoGXy3YUM/
2tYQmXPA9x0iGCxKiNVp6G6CWGH50cf1d5//S0SptI9jDFA2ETsz0QAfL3XM
BlpY4LmEYABOFGVHbhAVk1l/1XGmIR/FGTEiH8t9tNMQ6pxhiDxOLbOKi5+5
JhmHFsK2Dh26kYEYAZkhKFZSKm3GQGH+Yahfe1jYWJMNnmCDT0tqVNfff315
BVEaOA4pmX+j1adkE8vBUZwZKcWVUQ3p+KRaBfG5KF9iEl7J4CgAbWEZlx+G
JySYgDlS1Ekn2qhmKla0qIyDMbK2S4X4WEkhXO4YdYRlQ4HpznFdiicZZxxh
2lKWZ3x5kRCnuYmLJmeZONiER3YJJljuGEIkQ322Fx6IYQ1Tn3lxGWehNgCx
dxtOQRT7ohXcOdJs/4QR5eadXRt511ClRjWbYbaxKXQtfyp5iSGY9ZhBXqx5
FGHRSOZiIhJlSIakiC/xwORThq8aChxJYJTYzXvOcWXSWOotY8yGSkhxRyXL
PjIOJdd9RSrBOB4lRZSoPJzVxmB0FYeUtmixzXNf0ZrTIUD2ukOUpZHWhkA/
TWEHUxsXklBqSMCBklsQnTqgmrN00SgejpCzRknuBV1SVoE8erQkWoZVK0qC
HfrkLKuy5swODMciV8hAIbE0UFze5Ox/67hzTLlF/zG0zGsxjAlOKj4tC3J3
K/aF0xSLwt205oa92NB9UMGwRnPY20veLzfInMia+WWGglW9ScF6/2jMj/9J
L6pXtJvk6AJU4GC3nFwxCamrFimQz80HZayThlscCrOayxlfcxKPK4+6YhCM
q/0g/PDEF2+8D7gAoPzyzDfv/PPQRy/99NRXb730aQUPwAEHKHAAAgYgcIAB
ChjAvQLiS/A9+N0bYD4C3pP/Pvnovy8B/POb/z335O9fPgLiY9/4ANi/+vWP
e+ArX/gkID8Eru986AMgAL0HvuzBSQYEBN/7uhfB7+mvfBQMn/gGOD4OmpCA
3lOfBz9oPhE6cH0EXKAHBchADZ5vfeaLYALdxz0YMnCFFrxcArYXvhyqL4Aa
BGD32hc/8MEPgfnDnwcp6D0mdg9+8EOfAts3vvj/gbCH5HPi/f7HvgwOsH9Y
dCIHeaiAIE6gDgBQYhrdFz4cHjCB5bvi/UY4AfqFsIsRXOAH+1g/DaqviOKr
YwPrSED+nc997EOjE9WYR/S5UQIzoGQVOyhBMIZxgiMMZQ7lh0UI7k+E7stj
EcdXxComEIUBVOATFfg/Vp6Pj7PUnwmpeMk2DtGJYZQhMNOYyEnG0pGStB8L
pzjGJZ4xi/tboh+/CEn8hZGJNnSkBDt4SAkOTntZJGUPnxjN9KHPfxTMoBEb
eUsxstGV6eNgKbk4wB+m8Ip1PGMJF0jJCXpxn2203Btl8L0U0pGLSExhAQQg
gIU6tAClLCIjmznOVoay/4sIlKIPXUi/avpQj1pkZQYpWEISIrCXMgBAAWfI
0nMqYKEMjWlMCwDFZ45Ql4nEJx8L8NKe8rQAdHxiUK2ZQg3QsYVnzAD/fOm2
1QwRndBEKPlgKlOZ0rR9kAxpCaXIzSxStaoCoIA0PQjGA3y1qhAtqgQBeNaY
VtEA37zgAoQ5TS1KAKxgpen/cpjED64QmBPA60z9+b8fFvSlgm1oOmdYvrYy
VI8oXQARJ4nG8zk2r2vdX/qumU8sFlUBiWXoORWpwBZONbS15CP3HAtU/EV2
e0zk4TYvm1ce2k+Jow2gMrVIW9HOUI5I/F5vw3pRAl4WgpFdAALVGr7hovV9
uP985DvXuM3QMhSo9VsfFRM4XFfmEXysTR8CUPpUKIoQsdZ97g3dmcJ4HtSQ
6RUAFulXUDMOl6YJPOVlZxlXIcbRk92Lb17be78HTiC2MUSvdUlK1gOLL76q
zChrCwpXgDlVuRQ2gHMFi18S3u+TIc2qFgUMVFa68oqrTW9as4i+y9KSvHGk
5YY5nF0jYhSr8kwlaAVcVKSOEgEb9iL7WBvC1+JvxoltrRRTqV1AjrCLSK6f
Qf3Z3PhCFH8pFCwg+zvQBTgRyRzeZmZreE4uMhCvl8XuA20IXh7TF8hofiuX
MSlZ7Qo4yQbO7wRlS9kA55XIMQxmQWd85f0dt6AwFiT/bXlq3atWtI5U/KgE
iCzYE5v3tG6u7oDDOOeAermHO0ar+nqr5DVSmI81nGClQ/1c9qkwfUhO6/hc
3EUjm/OrPHV1o6vYPnbW0rzwq/QBOFxPZ8qPw5XW34QD+FoI3rWh1awiqQtr
alYaUZiAdvEmu5hK1oa5oMmmc1PlqsIKKLKIjVYiIyF5zVOyj8OYzusUHQg/
xyq4qvED9Peavclj9vrZeMayeHdYRiOGm9VW5XZOJx1nGptVyxPs9BniqNtX
BrfFoaXpeUOZU0ciUNvhS2yNx/lwebuYfBAvX3IjqMU77tkA6UZiThMZyCeH
GZIunqQ9WavhZAMafs3WrBwl/8pKUi+3pLcMJm6JzcE0gzqcMEfz+ESO8Jjy
r8LjvpxkEQlJZ94TAem+Z1L1J0fhJpuOVXerOf0Z3p7jFeBV5a9AxT32Hcov
jLsu4N3vjseQx1ngVC8tD3kOd6umnacMlLhkAynlRt4643YFYePVGmw0b9N8
aZbyGMPL8Lc7doFMTR4tRXzxqCdZlbhVX3uLmPkKZN7ZlR8wCJE94AEmt4fy
BDUI3Wd0lyJyq1pk651Rq24Ptr3Nf8YrClFKgDjm0H+ehW/GPW5I4Icx7cMf
bCLfR+T+xVqazea6Zj/ZPaPfNJoY/SCYIe/1e8/0isiPbws97QkJolKFXs87
ipU4zv8yrh+1vRZvhndIhEZ2/CZDJBd8bvdtjgdd+eRn2Xd6xVRyokZzppde
Wpd1XdZRGeVPELRrLIZMjCQ+/wd59OV+13VEvGdlffRaHLVx+CNBu/ZHp7RY
CxiBqwZ6RHZIUwdhiDZ3vvRfJjYBP9VT2DdTRYh4qPRkRzhpPvWESRZLKKhY
XYdxjQZDt1dORxiBLlVMcCZ1IThfZvd3FERkGQVu6bVUr6VDCYSDlaZBiPSF
YPV1aiRHtKV6U6iEKDSFhvc+LmhLAuiGosVJ9BN4WeRZgER1YaRtj9RFGKhF
K2dCECiIbtVAhsZ0UnZ19ZR5OaRvJrWFVDg+ihdjV8eHXEj/RtxHbDjVSfN3
h3nUfTrGQaCIWxI3RMHHQZSIb5BWiMLWhTdVWk1YQicHjLwIbyN0e/FDPyX4
dsN0g1V1VBMUW6B2euUXZ9DFa3KIVyVEf2qhUnuFcrlYiV3njDOFgAhVU+To
VpOIb4F0XutYVQ4EYzGUReGodv0DjsyIYgB1WLN3dmaoe66WZp51e/HkekZY
hE+YkEXYQJJHhEYIaUsUSS20h4iHkAx0kEaYTuzmbBiJeE9ka+0VSU9mRrVk
QGe4hOckhUk0RjFoSIz0TPZTX7sHSt+1Z/WlW3yViZAIhBMnRdGIkw6ESF0Y
koh4kRcJYlSERgW0WdeHUNUXPydU/3wYNU9HV0w/xHzKlUGRlJILl033uESy
ZE8w9GNfGUISdUjuWGMS+WRBaWxv9l0M9Hs5lGibFFQ8ZG1nJEKI6JR7hHRn
CEIxqFPbqEMbNEax+ICV5WOql1PzA5je02wiKU2ctVTbyD8Wl0sTEFz8lF0x
pF07VG43SZUuN4L+A2rt5kPzxY3B42WN2YgCZEh7ZWDSNHlciXsG9EUs1pJ6
uUVExXEqyEkZtUE3pZdrBXQ8WWfmVWaFZVHuqGO+KVumJIsLx4YCBJZ7yFcb
xFf2B0oPNEPzh3sHJYvJJWbd2YiWqWOFpVrzd423RGHctkHAlk4190T5dZYm
hVRC5Z6dZf+d3GNktlVRlZQ/ejeVGcWZOkefXDlPBnWXE5WS2CQ/lnZ1LzmW
SSSR5wNjekQ/9amhGkpz/bdHeMRV7CZIRLdK4AlplMVr8sSU2weagnaYWuk+
yXU9NFqjNnqjOBo9ydUPy/I7SyM3uaMTCsI2HWMK5aAZOsERV5MxfbMuqlAN
uMElkLM4dsMFrsMJ60GlMgM6UwolhOM4wUE3c4OlRlOmXfoUYroLfiAReKI3
RmMGFtE2hQMSJHEUGJEDN6E5PNo7ZCAXzvAIWMERXJA1vmMExRIzxbMWBWM6
Wuo5NgETn8A6q/AREqGB4iYHJxEvQrERmpowyLEzckMNnFoYTDD/FaFQGKbK
qURTD6bKMTLRCkTSFyVTK30SACTCEAPSM3VAIRxiq2JCq2AxJmkAJPVRKzsS
IRRSIT2Tpw8yHfhhFHBRJ1uSHhXSEEeCGAsxLmWSHkVhrRiCrQ3hGYNRJmkz
K2LBGWkiEsAjV0hxI7c6JhpCJElSMYtQFEYwKe3BrcMSFieCCcAhELhKJHGR
IqR6MUMzrPa6BRoyIDgyGAyysJkQHsiKIRJbHKFBLtfRDTiCF25wKwRQNZ5C
IJvDkzgzIr6SKjjSq6ERJhZCAxI7J6GRBPr6GtqKK68DLriqsi5RFAxyK1nS
ppG1FIUiH9nRInzBF6dRKATwshqyrQ8b/6x5wR1powUSkzLe6rC26i2CIaWM
4lR5sLAnOyZJ0asI8rRKErFM0rT5arYLqye8KiehMhtHiyunYSb9cQO4QA3s
EStacrbxmrQd0rb0kSp/UrGA6w69Yg0dMqpnYLE5IjWEe6/t4aWrSRKUAq3j
SiHFsR/h8q0qoSEfy689c7GOWyBHsiFHuydqexlHGxpUYhiWGlAXoawWMqtl
wBdl0LbFmjI2i6y4Ch5eYh60Egy3UrcXa6+I8asG0RwXBgo7w6mtmg0IcTet
SgiZshSpSi8AYb1qow83u6lyIwqEML7PuxHI8jZ6KzCqMBLMMBk7wQ2Y0Co9
aqZHOjC10LVwMoi93qAxrFCm4fsciFK/7HIqoeMThWAFRmo7fkCoswMysmA2
HcGlbRAFEVw0WGGoykAPUVEKGMyTVrq+WgAvd2O+jzCye5AHeao3Gsu++VAv
YKo6lZsnAmw3QQEHh1PD/NIIBOEGUloaijo5mEMMbYPBDQwDRnzESJzESrzE
TNzETvzEUBzFJhABACH5BAUKAA0ALAkAJwBwAEAAAAT/sMlJq5UItcz1/WAo
jpTmdVVGktymrnAsb25bIoo3T0qvNL6dcFjpAX8+4/E3xAElSqJUiEwmj9Lq
dcqdIZfM6tD67ZpX1mUBPFZGz/CQ0a1lygrrNS/OB83JW31UBQqEhIIUPXkN
i4RvJIsTa3ZEBxR6cJSJmpJHOiGREpGcQqGhMY2MIkymZTCnmGewloJveQJG
nx+nqntdsarAkMHBwlCiFY4iwqa9U3qpO5jGF5SjpJ3EsbHY0snEqJ28e7Cu
l8jOkeND08530O5+Fmu4P7rwvcDT3a/oyOvLzq37EW0SKXzt2pmBh89fQHDU
JBiQkwNIs3zfHEpR+O9ONnCJ//Bow3IBobhs/EYUUiiS40OMER9t8nAxj76P
z0BE1ImTFyttQeY5jBaPHUaCMIf5A7jSgoAnAh0qeHoOmcwV2+Lt5MlI5Elf
2gzugmKEKLeUoDB2/erH67aLT4TVm+coiEyFuWZkzaiR66SoPBiu7QbILI9A
Sn0mHdEwbkZFH0iJuZoOiznGl4xtLWl18bGOjGRaSnLoJ8crlMc2dgtybN+E
FvfKrFPlplVAmPcKlbQZ70c8SjYDCgPamV3EnFtXVU4X5wF1/wQfKvInJGBl
tJWuTY7TtTuTy0NbOJ6oNbcnWnS6zEjUb4WJjSv7EcNzPdTUv713d605+tLp
h2FTiP9Wn6XxmVD4cIIUQF/1V5l9Bc52HVToGZjWSLD0tVtRai0nTFCc6Ubd
H7qMRGBxW0H4E1vGWFgBVdABCAaIF8IF0Us7FYSTi8mIOB4ZCKpl0l7UCDYe
h/tVV02D4m3CY1XgwaZheA1MBKWJGgXlBk0bVgMkk0J2lyJb5Kj2I2p1YPnX
iPTxlYpNbxbX5ZJY7hhFHgNux9YXYVgYY2BIGILUfldScxdzpNnIi6Hp8RUO
Pla6SSdAZ5XVU1TSkYWYlKsQuaGhQY5D2lKeialpcKBtNqF3XgXYKneHyWem
kRX2YKWPmE0pq5MExfmhD0PW2dAaE30JElrs6XnlpMkBgyrpkqlmY1AZzagq
bY0f2SWKjiMWqmZ+M64IYX2gRYqOs2lKGuCg8V3bmLHjynPptteGG1e1TpLa
EXTSiqUIv9ZK6mAvW9DIHHpF3CdJGQxTR+ExyEYG8ZEIn+oicQo+fCZJq6SL
SMfpIReZwWxGTNzHaKDJMcj8ZKdSmyiPzMbKHdPMK8le4hzzugXHIHKsOidM
1s4X4ABk0DIT1id+DEfMB20/g6zx0KhRFHXMxz2ZssG4HZiCx0RbnIbTJf9A
y9E280y2GcNdPYIHf/R5atpuhF3el/jZrffeKyRAgt8SLMB3A4BTUPgOEQAA
IfkEBQoADQAsCQAnAHAAQAAABP+wyUmrrUXmy7v/ILeNWhl+Slqoyum+8NQq
K61qbXyReu+LJt7ml2tkMoifUodIko5G0w+6rCp50eESa+2eqEeatMf1mj1F
rPZ6boOgz3GIVqhnz7NGLuWm2NZrMUcCgVNGhHcvdYuMHnBUco5GdoeLXUd2
kF+EnAWIH56hiSGMnRqERVeAUYqMloV6d6GfBQagFJZZlD+2oY2ab52moIiU
sDK6dZ1aqVOBwG+Zr7eVE8eTlYSDrlVDv6xf1riKkbiik1qzK1a5JdCOj5gd
0tpRthgakJna74LWmaPeiBPlqcMndzsw0drFsJkOeecCRtOVL1CLOHKEaPK2
i02Qadf/xknpCOTUM2zKRnT0xg4gvlYQ+Z2EiE2kyijFUoIzRLCiPFLiKnLa
MRSUvpJRHMKgieFgNEwcSbpjiovW1Cz1uu2siC7kSAH/yhUay/Drtn6kHlnw
OuGetA3FtjaIS0WpkCDiwJZQ6iguBqhsveXEGPTlBQMsBS/KCoWviEc5jHVy
HNYYnJ3xwnHElhVfEqBY8QEWaHKcPLcTrFq4iGMrv4OX58iCpS7tz2oRp3Yu
mQ4dv8LkQv/tGmte0MhvwyJcRwFB7Kq+RIl5LhCTw21OH9+uNoZtuYGVwYek
850VN0liIR49Vgazt8gPt5sTdk29jIhxcr8s8Hnt2ZlymdOe/3/tAKFfPjUV
l6BxzWyDTiRo6bHMgiJVuANKY/lVQnbgwcPdSsARaA1d5kkT4EgGriJRiGvl
lEWDd9jl4jQLsjSPiS3G5OBat5xDHYoE7ojQg/IZxt5JCF6IVC5hXAiLKTjq
CE4hbv1o2mW0hSMeb/f4VFpNPUElgV0d8igBfRRaw4cfV8LRDGsBPrGeMVMG
UuU7qP0yTIVYmkWRkjzCQWJify5pj5mpvTIWZnokBoYkqxCm5gqJ8WOXlQhC
sudAaaQUm3pi8gCfLycGOgkiMErR5T9WnVfYbTtuVAxsSV1VqgV+ScWVrhbW
JloOs/rok31AMuoCQO3Z2MCqjKqka+xmyCrkKxe9MelPQHemmVE2SH5p0kI0
NamGgC6wphOiB+Y3m2iVgYQZiewW+tBvz4hpZr0cBuHUtKEmAgi4/uiUQRoj
qlhtdIhi6KVLWyqHbL5olCiXokrCBVW+leai10DW9rrQQ2AaO7G/NXaLKF9r
EHxrH+iVh9SN13rHMl4DvkzasTOfACemNxsY3MA5gzZkCM5pKfPKQZO8wQFL
aalZ0h2M6rJAKJsn9NFmwFcmyMat6GR/UNu0E2UtV3CAsh4gNnXSGm0hA8GS
Vhz2vSaADcPOYrOIjAlk94ER1nMHLjgHC1CQAAiHD35GBAAh+QQFCgANACwJ
ACcAcABAAAAE/7DJSaudpTR9u/9g6GnZRp5i2iBUoahwDCMazdoFu8kdx/HA
4CWj+Ll8uiAJ8xI6ec1NUbp8So41qzZ2mhqfvq0YSjxOd8LweA3KYHdVWZRN
FxXPZjVvqTHUxUkWJRhSaClecIZWL3yKdlBXkVV+HwdDDQIcc3SbIY0anYSJ
XyFzfHFbnzGhjhQGjZIwcT8SrKutQKoSlD2ZkbiCLRsCiWuqthW2tJdqy8kV
VajIssBcoxOhYc1tjrpPm96lI9RUgU3L0b7YWqjPKd4uPZLEZ7vB6ITO7A2M
1RbKnj7VywfNxK91QQz0a8fPnghQxXbYykQMRa1uGGEJ4UVBwUKJ4v/kfYh2
sQFHkA35zUIz7SGVlP/ewalHIpvBg7VokSygLmIQZBpBAPRUEacwfaOKCrF0
7UPLa3gQtvCFVGFHlYSoKoK45SPSjqxoMiumzyMcnSTU6YHhlR/TknBHvhSG
UFtPD+dEGiK1KNZXqYSixGHFUBSGMJn0DILpsmZBd3JROfOo7S+2EkQkfalJ
K9A4xleDdgj1om0wNEjLcBvihprj0SpEX8BDUVPMKwNjaVaU24Ify6Ub2SJ9
8WNBPoFYrCXI+2A8mVwfu0YJkA+xS600aPVZ5IRlfyVlXwUtzPiV7T3MnsaZ
l8rTRJ36QR4bvRPf1HPHGmbyRt53gn8Rd1T/dkbl85Z0xYBjCFA+0TXfPSjF
dRNqe+hmVHD7rUOYc1DN5uGAOjWIlT88raWgCfGBSCFLF5wEIGh5lTiVXnIx
l150FppyDyKwuURhNDbVKM1pRFRXiF80HieRTYv9lZmFGsk3wkCCQahkYRKO
ltd1sh0xk5d0DYbdYoa9VlpDZ4a2YT/qQUOVdiy2cEcy+JRHYxNV3nYmhliS
x40RDHG2FU6BEnkRkO8VxOSS8qAXF49IWoQkhzWm8IqIgK1GVnZ3oGBET/gJ
gs9y5NDHT3WJjWejkj9GdF+bI75nHChJzEEYSavixhUsIYJmW4F9auonktno
SAs43WWzHTynGSvD10qqCmmjPk82het60zango61BCKcodfaZJ+DTQ06J0GJ
KrfXg6JiASmwo7agDXYmUbHZPhNw9C00ydq4SW9wYQaZH7wkq4+LIVDC0cL1
urhZdw89J9R//En8hydbWfyBum1QfJiUF09MaGylyhRyxBD/gPBsANMLwqVg
njySwbjJ0vLHJXiWpMxEGuyxnF91GnNkPP85NBcaD1jIgYLckSgdPkAshNRg
CUpmBUwFG3IY/aZxdBl4vKDzL0nzHI27aUR1r72fgVcHmGgXLffcWxAQg910
sxEBACH5BAUKAA0ALAkAJgBwAEEAAAT/sMlJq73l6s2755kUTuNnkk15rmyr
FYZLIUVWy3hOKamd/j4dJaQSGle+pISnIzKPUA8tpcjwQtWoSMs1+bK/5rZL
fhGBYeHoWW43wFeUS8F224fb4Px9qd+jIypEMSY8flqGfIkriY0gj4Vvi0VC
hnSKLJaaOVWEHJZ8FYcyl410oxqOi30WJZSikksVVlGll6GRoLYHGHKznha6
t2tQt6a4H8KYLRnAoo6sxaWxqx2q1F47MMHTtrComZjd4N/Yt5B4zkzjeEvk
uZLr08ni1IeUeu6bi37nOt7Lqn0Sx49FCV3xYo1Zd8SYQ3ceQCmSuCFfuXkC
IepA8FAWxYgT/+Up/GADwYRVll7JqmSsnr8Nqgp0a9UrDUSKTM7U8njy1DJr
CWe+bFcBGMAxs4i2QPgEIUho+4gWoTQsn0qbJmKwOxkyoi2G1Hh1oPqCZpir
QBP2XAtSEi1lFU/YAHM1TjifyLy9U3hOIh0EBgKZrYm18NlM8vo5hRlUJLa4
GgILClZzLr2mqXgO/HkzEdq4U/UNAXPClOKOjGd6bOQqzavPx57IvJGsYCqw
MDexMqTSH2nDXOfphG1v9yZnXOsFV0sYlkosj8d8vqlI7I5ruZWrvbfBJJpP
iU9asfgN2u2R0XSXQ+phetdeaFte8i7BpFBUR6+jP9xWKfakwGli2v8peiFD
2TEHpkUCeZl9tMVv1tjGD4EDzbPeZnI9qJpZr+yjDErx9EPQbkidUYd7qxnI
xxkqUMhGgRittMNEnCVnEDoEjSJTZvbQsSNUAjaIjTqDWcGGTuzNiFtZVDnG
lItNKWCURoZY19yMo+34nU0ToiMSXilltNgz7xWVJBYnAtGaHF9BNkZgW9Gj
UXpL0OdmjUmmRqN5ImDmIHhQcuPTfAAmKdBspcXGXB48WRihZod8aadSSiaF
D1K6DYpLixPuRd1QBTZg5Zn6pKkkfuHR2Ccxjnqg1Z5Y9uVpcqb+yNlbDLWK
hipDRZirfovigWR+K/Yk0UFrqYfVf/AsmSy9ekhyg8wgTpbH1LRUmLMHgb6N
6V2HLVHqkIi8KqRTeLMC62ycS0QLa4OqoekSnn71ChSCnx7Jn7x/MniXHCoQ
ki4sJxkgMJ5bopgnfEgs/MedkWR448NjuQYcxGVdPBjFkOwo06z+ogDhbYhq
yXFSdLEwasUyZpwCchwPl8NVQaCocBmTiTGpyx3DbIdsD95cKE1KDCQ0GeO5
K8NrVaQMTsgPC1aJVcuqFBgVR0NR8xtZn+z11xIkAPbYEkQAACH5BAV4AA0A
LAkAJgBwAEEAAAT/sMlJq6VFgny7/2DYbVYGNJyormzrushLKXJte+kd5hKv
/8DboZIxBI8fWm854fhYzokSSS11ntWsdnvBcpEpX8G4Ogy/aOKHQ1YhEIcp
8n0wDhFt1R1uhsdscg0GBQICAQIFNHcHhYUVb4WHiRIKjU2ODZWNjQV3BnmU
CqKPBgd+QzSNf5mEmA2WHwIMs7QBDTFxtZSZsrSzARm9DAISAbM9vrQCCAp4
FpW/OW98zbfCxJTGDLavv02ZUsIB48em0N4SCAW15MMotTTayLXbBdMGq+ra
24Gmb5kGFOzjJmgfNnRdoklg1EnBkH3uDhTQFgabMAYZ5L0b5s+MKTMK/4xU
ghhgVYM4b0r9gUjm3LZu7mZM0EbwIx0Dv37B6RUg0LxfBjSuG+bwlqlPNGIM
9QWMwlFBdWD24oAAIjGE6WbO6oSHWSleswxte6Nt2QWe9XrNA0YVjkMyEw/R
rBDnKB+K6ARu+9ULGwpwEmh1alUo0QF58g6HRbGJ2FByYhn8HHcIahyoCgoE
U/gInCljAXC+ZLytLNYK3qr6QhT0Zd8GFGF66wtaaDKOMeAYMUnTJBxw+Pqq
xlhsW1+sKQ4INmCo9+PIJcuiaBdAYtihajcewlQqakgKPHMgzbST71xCYUEv
prC7tWR86IcNTwasLDPNtKRO9LW2u9tq+OQxl/9T+AgSA0S6wOYaUxgYgY99
qehEE2XXYeUNdrJJph0fZtyi228T8FRBdyo9RhlFCMhS2UAzOKiOYHj0JSIx
PA3n12yLKcCfEXxxEhIqpTDXDl9KFOjRazG8BhoxBmEwASTsRBnTK6DJNqRk
GMomyFKrnXRSShnCI4EddexnCx8NeCNdmqf98VtkuuRHgXT7MbXZaEtNcNtY
KQXIyJ4EMXNkNHwgINiSxY12gT9JurJCioh4KIggbTDzFiXT9HlKV9OkA6Zl
uuHzTxwhibqbF4t2WkMnLIjah6r3BBngBynhoZIZt/YByhUioOrkC5f5EZKb
duDRxxkd5OaVrbpm8uP/D76uoYetut3hKSp1qNrBU+TpJgiANOwqgk9M7EIu
DM588hGyrzJqigeFnvQVJZ5kC4QP4YL0jQv6GoXsLS7uFlUHAXXkLR2oZHLZ
qh/U8VFmv4aAq6h+5BHHJycdJW46fRhVlIHqfoSqF2K0WGpKT6CKT0dGWdCn
qcxsK4qtKo1J6TT/quCFHAGd9KMR0VYwrEN9WkCGOZ9ekNvKLY8ZQ0AYq5BZ
DololkEOqgCNCMSvYGN1D5otMQYKNGgmSqS/3lcY2GP/hcjXIRqmiQSYRCKA
EuI41iXdBrlXT3xMbtVaT2aqRuMwQ6FnizGJiFPQSySpOF2CixmTYU/dtKO4
/yEpGONYimmFDvlWCmL0mIKNI17hMsZAw9bVFBUSluyLu+O5gnLVvgwiSboj
CyJT0s1PKfs54zlPkWlWFk+tCfAn8OktHt176ag4TCnjQAm8LTzKlZ5kS1Kl
4ua1/KFid2k2paDspe11t/u1qWbP7+lThsg4Qy1UTO63zNL7IXgyDjkoYyWL
+K4epcEc7Va2Dls8ZBgqqo3qqGMMwzFHddAxVO2aoRTPbUUgPXme5ExxDOPI
KRL16MbhZOcX4ZUkKYzjEUY8aELgsU92qAOdDYWTPc8VBS0cmYUpxrcNI0hu
HCJKR+Iu2A7abUcrcqGdWKZnpvT9bipXNCFxxuK5/f9koDTNgeD5jBGcIi7p
dseoEhJBcyfjXC5ENNmdMjJSH9sBA3HZo1+Tfvc82ABDSL/Anz6iE5oUjeMW
TaSSLVQEp6YYERZdg+QtwpYpq5nCHqsgxCQdYrYMuMVqRdDMIDSjFN1QMmxL
yIc6MIDKV4RIiSj4w8Y80AyHvMVhBePgX3rwh7q85VwWMFi3ckaijuQsBF6x
Qhk89K5CfcIkI2rGHlAigjc4hFH/mEAdAuIHZ6ihAz+qRg1q5i9MfWIQLrOm
s24hE3DQYBTgiNlvqvHOrLjzD6PwVTbXIEn7naQVrCrM05BlNw5sAiC8uBth
GkMMTQQDEQxdaKTiUpkKVGb/bY76Bpy2uJpzmEUnu+GbL1wiOP3Qp0rNY9NF
SuiL+KxJeMPwXBf3VRyIQnQ0BhyLiOyFHVWMr0qlq84NFQeW99licydhHO88
BykLjA49LQTPNh72pyfaozc0MVLm0lHG6jSQGRT6A075xFT/DXIMytFQZpbk
lxRwUTK/g+ZmShIJ/ATycd9rnbpUszhDBIZCK7zdfiIEDGjcrXXvAAYc1CNH
vjg1NLKAaheYap+4AIVCMmWAH4pTOwiuJiOePepYS9I8QzHgE3HphGKQGJxE
UuCtOkyb5KpoDRVVxXsxxUgzJYe7BtKvdLRoxiwI24y4BvCPigFYbqiUwhDR
6G3qyCNC4lSoyd5aThvyk+oBt2fazYlFedwYn+HYVDb8BcZ0msHE7cDmiMIQ
ImUX3Etu5ctd0KR0S2HaXuaYqjjTwpApwiVOAzlAkshhYCuMW+8VmnO15oTX
Ea1gjA+aU4i1Nng7TjhEUz1E4QzMjTFoM4SII4FEtI1BE5BSXtC+GQUQXC0N
Lo6YDFbchFkqDcZHOCaOd1wuHtC4CzYOAzDDABgepwwFNsZBO8fJ4x1k4chU
a7KUv0lTZYKzylOmcpa3zGUgJKDLQIgAACH5BAUyAA0ALAkARwBwABwAAAT/
EKFGqTIHnVrRpQZifFRRVMrUKGkzho3mhtI3Ku5mrOm+ejODcKjC0EqnhglZ
aLkUpqUio8GVLpLJIXPZRU/NaU8UysRkmVuoyxWztjxPmZXa4jBda1QJNr13
B1BRbi8VJhgiVFUeX3xmHlmFIxs1PQdqF1saVDkiUzcaIhOJHoF8jYMSgEsm
kFaGTRVUGw2XB1+pFymia4hnb4G6W1sYtLVCaRRmLnJTFiy4rH60I6xTnhK0
flZYtJuCX592aZe1IiuXoYFy7DCywTBwOetFgdF94hbWU+Mbg7J0QAQycM+S
BiGqEh3b5SmYLU4WQiC8QykFHWoI+jRSIs6fFE2m/zhM64BBmSpwg4Ztcnhk
Ij0WCIe8OngQB5Ba6S7hsHdqj4Vg0FKFY2FIzMQ1HlhM2NMkmyougaJmQmYL
yw2pQt5YjLGzaho8fU5xbIMjnEY/Rd0cS6rD3r50VUbQHGJkB9sezGBiATaw
Ew5xBMXi0ruhrM+eSSJ+qnVmB7JXStD9xOmDCDotpEJ6imEsmASTHIIZGr1i
iDcOqFOXUK0asjLWsGPLnk17Re3YrmMnvs27t+/fsS8JqTAcBWsdn1GrGHWM
M2hmOs5syJDuHW3LsPe+CocTTjZjIqeNwwOwofB0cmtlop5Ioh1Eo+zsRvIj
U24Um9Yg3vFpgtKbsIxky/8L1KiUxYC6zCNRDcVcI1EXQxzWUx4IsZbNC9Uk
EUsd/FGXWjia0JHgD/QQA6EVeFTBDx7TIZTUDUugNk0pyaW2GAcZ7XFHN1fJ
GCM35ahCVw0gWDGMXSt509cTxJAhiGp+PFZGa+XYl2GMXEAiBwfgcERDHbtw
NcxOm3Siw3DDcEYCSP4FNR9H6jnImnuaOIbLPKG4Eh4Y/FwD03R1lDPJMyWl
Y1FhyCgzhj4bFcUVTCqgBkwc3ICY1DWaoOCTiC8aKQY5iQq5lnoTvKACCcY1
CoJdf/iQWnvdJZfSHcVks+cJFvWwhkXsOOnDXApdw9UIFLgCFhNcDsdrcTay
RxVvI3ssIkYWz0z4QgtvNJPGtGcemokq6DjDAxUoSagSpu7MWYcWGZZQji3q
uaphK4nYIA6KEhE7Qw2mGKFMhbFCq6pfXYjim2v3ceCqBcA1LKnDvr2ZMGsT
Q2yxbBVfrPHGHHfMpccgh9xbxiKXTEEEACH5BAV4AA0ALAwARwBoADEAAAT/
sMkpFZWmqW3vFFdXadvEdZw5riNSlUhJcq5nX0HABGAj6ECR5Mco9nS9ApAh
sOR2PB9TkpMCm8NcYTgtMAW7cOBGnhR1Oyk0kJko1yBFkcENp8/zAnjc0L2f
UwpoAi5oBV48gDk1ZTZpDUZePSF7F3sMW4gNmjpUX1N9DAhgIJVvO05nmpuP
jI0Xj0h7AgJbbkg4TGl7emmyWpWhobW4pDtbS6ukrq+wfEBeeRRvkxJ3Y9Fn
IGhnUkeYYHMBBQh+fsNiXAFCzRSxTIi0QtQU4eGHdt+0su9Wx5tAgAwbpI5Z
O2vPPlWbUO6Rpznwjj0qoo6Up4a0poQTF6rXI0S2/w66g3IsXI4ArqLtu9eL
xw6MoVx+YoLGm0pSh8xhisZnmUhY4ggRkVaPm0AEGNNEO6Uq1JxaFvecG4hJ
QTBeP+vRYrjp0CF2CPRs7eHCKzkNh8KaZSS2QIZDFQ7VaqM2rAWvbgxmnba3
LwUEB8q0EanXr4LCfhMrXnwQMeNmSCXUiPx4b1u0tBYqgGu2s4XNmUJ3tlRg
s4ADethVbrZxCjdQDdm8JglCyRhSs/moiwZz9cFZP5oELJJpkJ6AvWoXwbhv
x9YPEcdM9d0M1y06Hf31sDgMIEru3OsxkSMdE/Vmcui0pWZIkK5x3jzV7mQ9
PPRavkSdfxXNqiqjhBiQ3/8W4HXxUoELxbeDATqotl8IRWwGzRJjhIWHRvB0
Z1t38V2gxDaloPRgI9ZpQR88UglESmC48IagB6MQmEmCI3p4hiGd3EMcPuBk
aJJA9YEiHjGiTFcjjKfwUE4UJ1WRRUZkbbROh/ZxQQxKWhxJhgsGGIAUM7Yw
slkDLgQ2Ajl0UeaYC5Fl4JiWf13w5oNzwilBSJLZqedPg+3p55+ABirooIQW
auihiCaq6KKMNuroQQtEKmkDki6QAKUSLECpppM2kEAAA1BKgKYSDJDDAJdS
YCqonpK6KqoNEOBpH6emmmmkl456K6m6YoppAp1augABwGo6qqTHUlqssrbS
AWz/ArI6c+kCA0AkAbChWpMGtWYUke2mlQorKrDMRirBqAkUq2mx6uJ67KTp
pissp9k+e0G6QFgKSQD4onopA6iGugMBQAxAgKnRgourueDKyu6lzwqLLsMT
qHtrrgvLqywkmTYg8LQCe9yHrLiakWm1s+5gKwXyRmtsq+aqOy2554JLwcLD
2kzsuzFXi52n0oEMial9zJruBAFI6vMAPu8A6wToJnvtsfJKOm2411KsbLD6
WgqtxZYWkeqn18b6L9K0ljqB1wl4SzZHUIebM67tfh3rvF1rvbXL5lY66t8J
+Dx20GoDTIXHYxg+MrkUWco0GropbDWyODMcKbHDzksBw8/XAsuzsDOLjTa/
lIZ8uCffFlstq8qa6lCsnhb7Od7LXny5uBXjDu/kffus6tCUSiey4f/CCnCk
QAQeKrH7rk2q5H1XnvPFEFcNOt3L2lt12XjwKzAfAOPLceKoQo5G+XQk/jP0
0LIdu7ztgp6q1wRgXj/bk5ZcKQXCt64btP6bQKj0RZ+vEW1fK/Ma3dbVt6PF
r2oJrB2nLNUrkvmqYp1zWbymtbbYbW5dDqSb0S4gN1JxymYWU1jCjrSyP0Vr
hWWIAAAh+QQFMgANACwUAEcAVQAcAAAE//C0SVEzyBjKZ+kStWHbpCHWdZSX
WXFWqY2YuaLHoRS8iWa5Dm/4aehSp8PPqFAaFBcE1GhpKq7BhkJaukJzV4NO
A1UYiCogirMjfpTbCepJZ6KuQJk5h+DHnE1aW04ZalYaHgVhIR1iPWxcUIUN
XJQhWDpTOTliUTFiGRtKc1ITYxODiZhmKaY6RRRNYhJONxIYsn19UzUkUkFg
rEZws3J1w6oYwRxjsB5QnSsYkysrcRlTsn44rCfQR1uaYl0pPFZbGTDYHOab
fcEhc7hHSDRPgX3KT5RN73qdglSd6iAoDgVzOObAuRRCGicf93TouIAlHL9Z
AEOFUESk4iAWlP/EtBmCZdqYVKE0OJRi5YI3M6wwjVFZysi4RB2f2GplY2QP
KxK/iJzB8latXSsoJjSFR4quFLumDDmoRSLAWFJ6FJEAFJoXOFhEKFFCRc6u
mhjJ8qnAiOAUgnDjyp1bVi5PurHkFgCJt6/fv4ADU2gruDDBpEZsGIZ7Z0PW
R4M77RnnjlIfmxRVIhYrsRDfxWNlaXFjimWYimeH2fMikme1JpxqLBZR8pdP
RfyqySNaCuYsTj+yyJnJVfjsO8x2qLKcKmQKMFT4ADTzeZey6LNLW/jF0g3s
flewq6bINbyKz9Q3aUmXvR8fQN69CBpxuaoFh9OGf64z1ODsWThM49OBenic
QGAMa9QxFkQEVVKDRdnZgUp3DZBEBzpfVOKEHTOhMlEHLUlGGGiH4KIVDwp1
o40kJ5BhUxcfMpPEJmRFCAYoGUylCGyDwVTTEfoIgkSNHESkzEMRasFcjKiY
UgE0lAzGDxLmvQVXcVFamWRebGwpmJZeKtllmGQWBmaZYUYAACH5BAV4AA0A
LBoARwBKADIAAAT/sMnZVBFYzIwLtYJHZYrSSVdxZYXJGlQsx0bA3Ewg2bg2
FTZfA4gLYHINRJB3CxRwNwFiRv0IcoJgI3iaKLSV4OX2ZRwDiCvrabShq3Cl
uXFlbOcyou9p35nZWkEKU2xDOSJwMyZzbFlNOh9gVwEwZTo8b3UBOnyOb4kz
chp8d5uQP5I5CkmTdDcibpuGRYigMYujSGAwXjYirX65ThJqPzlgtjKicpdm
oxR6Q3IefNSHwSoqOaLJMmW0ckW8Q0xOmlEor360SJO13QZZmyFD8vNTEmmm
TghA8yJK6JEzFcJIvWHdKCBYuDCfsgkMI0JsKGEQvgpTDPRLgs/DxYQg/0OK
HEmypEk4JUoksaBoVQWXKV+uXJWSZoWbXmoOspnswj86BH2YMGhvXhYPXzQc
LWrEJbkQWfQV+FiFCI+CUCBZVVJuE6MbruRlHYHlBgJ0oCwtpAe2ATo+eMTc
GSVrksZiH91tmpasLSojjqDmQBI2mCEdxQrHYHMWjS9bheRh9aqjMdcpYLQQ
cQVJDdUnUvY+BkVKE5EmucygS6y5HR7Pi5HkqMHgHRUF6tj4q0MMypzMc3Aj
Jgw7Bj16F5ItCmDhEBddzialiXuoVeLE0IzUkHK0JxPnds69IRJtVo9SvQVu
wOILGag0XTAQY1ExRQoJBnyGICTwfow0U8l3Af9VIBF40oEhGYjggpAx6CA8
D0Yo4YQUVmjhhRhmqOGGHHbo4YcgirTAiAtQQOKJE5S4AAEoqpgAiSku8CKM
CSUwgCkDJJBAAwQMcGMAOZa4xQANyHjjizfm2COQCyQJJJA2NnBjAzraCGUC
TyaZwJKb+EjlAL4B2SMUW0gAZg4EJHDDizjo6FaOPEjAQI524CAllmuqmZWN
vjGQZhM6eunWnDteIiVYRK65ACaLznnonUSqKSWRE4AZgI43EJkjnpdOeiih
VPrRaZNujWkHkTa4CSiYfvAopKUv7rBjDnz28WWmO+5IJSZQlrIjqQzwKeeZ
RdpQqR1NZiqlnMu6ASzmlY9syiuln+IAJ61FzuqjHbEEq60f19apA6uD6iDk
pWdaK+V3OUpgpbVu/Jrotsu22eiNgxXJqo+R9qEss5jOKeiXTFDL45n4jpoo
AW4FQAATbAabKK3OpvkovhPES2yKFOip6Y6mfkrkw1vwGQCwwd6L5ZvJXunm
rZBO4HGVUZqZ6Zle0YrnMXlaGqq7C6zJ7Mnf0Sq0Gw8jke4jTCOxcw4G44vE
ij8iKcsWQK6b9Y/7YL3jj1rvug+QUm+iK49UvuyujgQwLEGaZ1eZtts/05x2
qLrm6u7aNMOd9tlw6Ep3iB1TEAEAIfkEBTIADQAsIABHAD4AHAAABP+wIaNM
KS3fopDK2VSBmWEgaHVkilq1HdV6JHl45qVd7QqaCJ/koLjJTg3TrQc7EGej
miTYUeg2hRsJRSkVO57Y4ai6OVFj40eaXh2uOulkUtKyik+Kuz1dGYxSDURa
RFg8NUY+RgiCJ25VBg0Vc4KDeYFfkRUYhohAIX+RFChJX3U3jFQnJoGNQRJd
Gyw2TmsnjCFFUy2gkRlEQUitJ1UzDViSW3+Mg7qhkWm2TEQmTMNhiVZYvCHU
HWMTJn+/Yb3ELxI9gSgTY5qGHCBfTn8VQNzLvoOrYOm6gaH+rbEhbx83SQfb
gXhljMivJK0iSpxIsaLFixgztgqipV4gJ3X3TsGqBG2VBEEQF4Zq50cemBEe
kAkqIkpFKCcr2CUZ80LJmIVlisyJ5MEMzZiyKoVpIQOYQ46SxMHwCIKeJXdD
miJxeEwHsZ+wWN2aKQonOGZbVAX00aFGPUOTPODi8gvkMkF0yEr5NglnKi1V
lmjTgUfoh7tD3HQp1wjsD3tm26o7owYZjGJRcQ3aWRKXI18/Ftfr4jNriqTF
wiHENSnJYjtD5XyAuaYoGLktLFMYhY21GofUcgl5vO+Jj3rUiHHaQHeSHn3h
VNMUPrAOELNCao1LgqGruj4v5gJzNLP2dhLVpuOUWF2j+/ft38u/GH++/Yj1
78+PAAAh+QQFeAANACwYAEcATQAyAAAE/7BJJZu6qtDKRSmGBE5XgzTaZmUc
VbQVhZXTZzUBowdvkeuMF+enE+CCKEZAIvjxUEReQQAMCDLKBjWQCSyhQGPO
q/yMvRxtsSlGbtWMpu6z+yHOayWCGi+UfUpNAXcMJzlGehUnEmNpOT16h4xx
CFlHAlRGW348fINKBpJDQXtlY5hpnjwUp2MGZUxlc35Bh4CYeltxXrcfHwqP
ajxEV6lAcUfHn0jCgGSDnrNlmXWAUz/WzbZCqXKDtpmVT811HoReT1uluKZx
CnyAkx5oafVvwZyERpfWL4aUizhN6bPj0iRaz8wo8bKPEcOCkt7w8UaHgYEQ
8jpkyeQMgTN4Uf96EHEnoVSVf5CM7HEiwKOXRbEaJlmSSdgJQAtVmCjpEUFP
e/tC/EQhxOMHnyIKwCSaRsVRE0p5+qpHtWqapVazat3KtavXr2DDKtIptmwL
GRQQkO06BVMPTKhiYPIIF+4UDSiKYXpX1wOHu3f53vAqZ8c7ZULg8akyhpW7
OceKjLq1ZW1WWnChBRL1wwM7uIkk6eAbqFiFR5nUfRV1Og6uL0p0iLC06dIr
BrPHTeZoqau+tp4XSs6Ej3aiTK+++NDd+jAumVxthVnc58hAI5xicbHeQPZM
bq2vZ18d5wBl4S1xFhyv+lAl3FCYMwlgwIcZ6FsrX0q9cSE89pY8clv/buCJ
gJ1Kfn0FzA55LHGIe79ZgtMPFugQgkD1HMLfEgVqtRJD12iCzjg+tESPS2P4
Q881azURYolmKXJVjDRiRWNJN5Zlo1gd5uhjWBj9KOSQRBZp5JFIJqnkkkw2
6eSTUEYp5ZRU3rjAAglgeSWWAzSQAAFXNjBAAg0QkKUECQygZgJnSjBmA1im
mSaaCxDwJp0LoCmml1lemWWWBHCwZZxsLjAAbn+SycCYhZK5hGwD1HloBVhy
oMSYXUqgw5h5flFBpH0OmqcEfn7pJyM4XNnlooMm4KCafC6QAw58dveoEoEW
tKmhuDkYQKRXEhBom6RuGWigXjbiKq2hdsfA/5mlyoYblpuKieihAaiK6Bhs
Ulrnmch62yebxx767LLAbsktmllimwOo76aJqLN/4qZmr2qKCmaYaYgabKWL
TppolrMC+qWrAStRaQWbzhlAvXt6KiaZW4YaLqn7Vqzor0o4ukQCvYYJsbzn
OrsDm5mS2V2qOBCRaZ2iUhXqn+Y2PKuXjIyKMnzOjrlpwRuTCfKeNP9wccWC
5pmol1hS+CbKKnsZaNO9OqHovYvKC6fWFPc5Br98dlusllhmjDCuw2658q8D
/Aq0uehubKeurL7btptx+gl2mcYSW2ammW4N9jG2jlstq+auSjibIyHqr9+k
wrl3nmuWKfmobsK6Zxfke8I6KuCbYywmrBnnqbZXF1dZT+oRAAAh+QQFMgAN
ACwMADAAZwAzAAAE/7A1dY4yBxnJVfmcZBkkoiAihkrnah4qghxhLambrTcy
xfUgyafAUhhfvpsnKLpoLJoNxkJrGDRFDAlW3V2NmF0NpuJ8g8OChjIbXTrp
kEyWqSsmsyvNtDrmKV01egYXJGIhUFccFktEDUNbMosrLGkFd2QwPy4wMygZ
dzxlh6JzGTOkViZsVaBDj0NHOTpGlpgxOiQYRow5c5RiJzFsqT1bVSpxkHPB
lpcTU6FjJ1S6yJ5twCHCvCapVoDEDXXOH7soRhRbEyAfPoQWE9SS6W5XfSoV
kjp1ooykfk7l0NcoDTwaXNKtaleA0Lh+M2Tx4KPuyw2BYFIBQnUoCgqKRf/K
XVIHjhCFWmlOpBNmhRGMcFskPqzARlsuLrN29DKxjlu5C2+u6Hlpa5cTnmR8
vDDZphUhm4dGQA2RDxAUJUScYZuU0NaTU8Aiqjox7kK8shm+bUp7aMoXoS9P
Zk1D540VEgUfweJ1qguxQnvuDcyjJ4mNFrqEBaIaScu9cQgYQlKnz4IzDnGs
ZiiB8IUEJJ87LeU4prI+Q4dVSMMFRMirVUQl18gc0ay3NqHuuTjqqQI/uHx3
0FF0A94LNK/GlWWiVp6iMHdIl/i8yIjymwMBAbTB5Xrz7yzAix9Pvrz58+jT
q1/Pvr379/Djy59Pv779+/jz69/Pw4xQu4d5NtH/DVjQMN1FORlI1Q936WKG
Nzmd585jU/AUoTsnqbKBJ6GxsYETgMFWzz881SZCL4uZB8lmYJ2F2RCg4IEC
IVKc1INiJtFo2nCbqXPEZho8oZ47Le2hiQgvOtKBJEHa9hlfoWi2gWiZRKGP
DMS1hyFNhbGV5CWaUPGEHliMQyYUIAr1AhU7ZWMWFGWiRyRuvJg1WyyfEIal
kODMAQ8vFZriRAlgoLkKSekR6YcWpIUQSwV10KTOPl/ACYZQeN1BzSBssNLJ
S0M6UghPqVySZ54nneVYBWHUmOFddZaIyZGbhVrnprA5mtIdjwFlZhRbRCJN
FFS9wdcIwgJqKzw8gKVF/yW2TBCPdsh+4WEgVMiBCi8yYoKlHu6FghOodyL5
6pGdWodHTo16V2t3D7XB3w7SzGvvvfiOMdV9ivgWBn/GaBrHIlqYpQWkTGpC
I2CdUEUTkFLoZ0cnBT3Dw0omQQGnmYWYZBY1DltVwr7xZVxpxVFy8a0uPRj4
BqS6QYoIYAdFWF8PNaD8JEdBnvhGNv92zJ0TCKdI3ykqgaKzmNb18xB0SufW
sCBT0BQnfpF6Qki0R2QErrRYrLNPHjYN6gbJ8V0pGsqreIRHblhC0xuB/25D
Yw/eSNzC2xWX1EI34pZJTSEsjDB0S2DvR8WojcCCpVTw/OsRXmYqYqMNnEGa
Viu99o0g0CsjyVzWU+IKk4c8K+Rz2KQw5ztBzvNy7vrr+8ke++yu2457cxEA
ADs=

------=_NextPart_000_006E_01C0CCDA.AD2CB8E0--



From gmcm@hypernet.com  Wed Apr 25 16:21:18 2001
From: gmcm@hypernet.com (Gordon McMillan)
Date: Wed, 25 Apr 2001 11:21:18 -0400
Subject: [Python-Dev] Attn: Christian Tismer (apologies to others)
Message-ID: <3AE6B32E.22730.5BF4AC97@localhost>

Sorry to blast everybody with this.

Christian, your mail server is getting a new HD. You can reach 
Jean-Claude at jcwippler@hotmail.com.

- Gordon


From michel@digicool.com  Wed Apr 25 21:08:01 2001
From: michel@digicool.com (Michel Pelletier)
Date: Wed, 25 Apr 2001 13:08:01 -0700 (PDT)
Subject: [Python-Dev] PEP 245 Prototype
Message-ID: <Pine.LNX.4.32.0104242341190.17366-100000@localhost.localdomain>

I have created a prototype of PEP 245 based on the Mobius Python library.
This prototype requires no changes to Python 2.x.

I have also updated PEP 245 to reflect using the prototype.  Refer to the
'doc' directory for the revised PEP.  The prototype can be downloaded
from:

http://www.zope.org/Members/michel/InterfacesPEP/Interface.tgz

It contains four directories and a README that should get you started.
Please follow up any comments specific to the PEP onto the
type-sig@python.org list.

Thanks,

-Michel




From mal@lemburg.com  Wed Apr 25 22:15:58 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 25 Apr 2001 23:15:58 +0200
Subject: [Python-Dev] ANN: mxNumber -- Experimental Number Types, Version 0.2.0
Message-ID: <3AE73E8E.E9152718@lemburg.com>

ANNOUNCING

			mxNumber - Version 0.2.0

                Python Interface to GNU MP Number Types


INTRODUCTION
------------

As you all know, Moshe Zadka has been pushing for a new rational
number type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I thought, but well, it's done now.

There's still no web-page for this package, so I'm providing the
needed information in this posting.


WHAT'S NEW ?
------------

The 0.2.0 release is an alpha release. Everything is still in flux, so
expect bugs, strange behaviour etc.

Still, the package provides some interesting insights into the issues
you run into when dealing with computational representations of
numbers. For now, you should consider the package a pure fun-package
and playground for experiments.

New in this release are a parser for rational strings (formats "1/2"
and "3 1/3"), plus a new constructor FareyRational() which was
inspired by an algorithm written by Scott David Daniels and posted to
the Python Cookbook; see
    http://www.activestate.com/ASPN/Python/Cookbook/Recipe/52317

The FareyRational() constructor allows you to convert floating point
numbers to rationals, e.g. 1.3333 to 4/3.


INTERFACE
---------

The package is part of the eGenix.com EXPERIMENTAL package and called
mx.Number. It provides access to three numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision
4. FareyRational(value, maxden)
                       -- calculate the best rational represenation 
                          n/d of value such that d < maxden

DOWNLOADS
---------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
r3 = FareyRational(1.33333, 1000)
i = Integer("1231231231231231231231231")


The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


QUESTIONS
---------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From mal@lemburg.com  Wed Apr 25 22:15:58 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 25 Apr 2001 23:15:58 +0200
Subject: [Python-Dev] ANN: mxNumber -- Experimental Number Types, Version 0.2.0
Message-ID: <mailman.988234202.22353.clpa-moderators@python.org>

ANNOUNCING

			mxNumber - Version 0.2.0

                Python Interface to GNU MP Number Types


INTRODUCTION
------------

As you all know, Moshe Zadka has been pushing for a new rational
number type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I thought, but well, it's done now.

There's still no web-page for this package, so I'm providing the
needed information in this posting.


WHAT'S NEW ?
------------

The 0.2.0 release is an alpha release. Everything is still in flux, so
expect bugs, strange behaviour etc.

Still, the package provides some interesting insights into the issues
you run into when dealing with computational representations of
numbers. For now, you should consider the package a pure fun-package
and playground for experiments.

New in this release are a parser for rational strings (formats "1/2"
and "3 1/3"), plus a new constructor FareyRational() which was
inspired by an algorithm written by Scott David Daniels and posted to
the Python Cookbook; see
    http://www.activestate.com/ASPN/Python/Cookbook/Recipe/52317

The FareyRational() constructor allows you to convert floating point
numbers to rationals, e.g. 1.3333 to 4/3.


INTERFACE
---------

The package is part of the eGenix.com EXPERIMENTAL package and called
mx.Number. It provides access to three numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision
4. FareyRational(value, maxden)
                       -- calculate the best rational represenation 
                          n/d of value such that d < maxden

DOWNLOADS
---------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
r3 = FareyRational(1.33333, 1000)
i = Integer("1231231231231231231231231")


The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


QUESTIONS
---------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From MarkH@ActiveState.com  Thu Apr 26 15:10:36 2001
From: MarkH@ActiveState.com (Mark Hammond)
Date: Fri, 27 Apr 2001 00:10:36 +1000
Subject: [Python-Dev] buffer interface (again)
In-Reply-To: <04b101c0c826$a0818890$e000a8c0@thomasnotebook>
Message-ID: <LCEPIIGDJPKCOIHOBJEPAEMMDKAA.MarkH@ActiveState.com>

> From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On
> Behalf Of Thomas Heller
> Sent: Thursday, 19 April 2001 2:43 AM

Better late than never!

> > I'd like to see a memory object that allocates and deallocates blocks
> > of memory and exports a pointer to its memory.  It could also set
> > privileges such are read/write, etc
>
> It's all there, in bufferobject.c.
> Except that the functions are not exposed to python...

I'm with Thomas too.  I could have used this a number of times, and have
even resorted to simple methods in my own .pyd files that wrap these APIs -
eg, win32file.AllocateReadBuffer() used for overlapped IO.

So while I think Thomas' bug is valid, I also understand we have to somehow
handle the issue the array module has.

Mark.



From MarkH@ActiveState.com  Thu Apr 26 15:26:39 2001
From: MarkH@ActiveState.com (Mark Hammond)
Date: Fri, 27 Apr 2001 00:26:39 +1000
Subject: [Python-Dev] Unicode and the Windows file system.
In-Reply-To: <LCEPIIGDJPKCOIHOBJEPOEKKDGAA.MarkH@ActiveState.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPIEMMDKAA.MarkH@ActiveState.com>

Now that 2.1 is out the door, how do we feel about getting these Unicode
changes in?

Mark.

> -----Original Message-----
> From: Mark Hammond [mailto:MarkH@ActiveState.com]
> Sent: Thursday, 22 March 2001 4:16 PM
> To: python-dev@python.org
> Subject: RE: [Python-Dev] Unicode and the Windows file system.
>
>
> I have submitted patch #410465 for this.
>
> http://sourceforge.net/tracker/?func=detail&aid=410465&group_id=54
> 70&atid=305470
>
> Comments are in the patch, so I won't repeat them here, but I
> would appreciate a few reviews on the code.  Particularly, my
> addition of a new format to PyArg_ParseTuple and the resulting
> extra string copy may raise a few eye-brows.
>
> I've even managed to include the new test file and its output in
> the patch, so it will hopefully apply cleanly and run a full test
> if you want to try it.
>
> Thanks,
>
> Mark.



From fredrik@effbot.org  Thu Apr 26 19:47:29 2001
From: fredrik@effbot.org (Fredrik Lundh)
Date: Thu, 26 Apr 2001 20:47:29 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid>

> In the re-Module which come with Python version 2.0
> (Nov 28 11:10 re.py) the created MatchObjects cannot be
> copied with a deepcopy(). Switching back to the old
> "pre.py" as proposed in "re.py" makes everything work
> ok.

thought I'd check this one with python-dev before marking
it as "won't fix".  I cannot see any reason why anyone would
even attempt to deepcopy match objects...

(cannot see any reason why anyone would use deepcopy for
anything, but that's another story)

Cheers /F



From martin@loewis.home.cs.tu-berlin.de  Thu Apr 26 21:28:17 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 26 Apr 2001 22:28:17 +0200
Subject: [Python-Dev] [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de>

> thought I'd check this one with python-dev before marking it as
> "won't fix".  I cannot see any reason why anyone would even attempt
> to deepcopy match objects...

What's wrong with patch #419070, which fixes the bug? Like any other
immutable object, deepcopying a match object means returning it.

Regards,
Martin


From fredrik@effbot.org  Thu Apr 26 21:50:38 2001
From: fredrik@effbot.org (Fredrik Lundh)
Date: Thu, 26 Apr 2001 22:50:38 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de>
Message-ID: <014b01c0ce92$8da742b0$e46940d5@hagrid>

Martin v. Loewis wrote:
> What's wrong with patch #419070, which fixes the bug? Like any other
> immutable object, deepcopying a match object means returning it.

what makes you think a match object is immutable?

import array, sre

a = array.array("c", "abcde")
m = sre.search("bcd", a)
print m.group(0)

Cheers /F



From martin@loewis.home.cs.tu-berlin.de  Thu Apr 26 22:12:45 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 26 Apr 2001 23:12:45 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <014b01c0ce92$8da742b0$e46940d5@hagrid> (fredrik@effbot.org)
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de> <014b01c0ce92$8da742b0$e46940d5@hagrid>
Message-ID: <200104262112.f3QLCjd02333@mira.informatik.hu-berlin.de>

> what makes you think a match object is immutable?

Because you cannot modify their state.

> import array, sre
> 
> a = array.array("c", "abcde")
> m = sre.search("bcd", a)
> print m.group(0)

a1 = m.group(0)
a1[0]='z'
print m.group(0)

So you'd have to modify a, to modify m.group(0). To catch this case,
you might want to do

def copy_match(m):
  g = m.group(0)
  if copy(g) is not g:
    raise KeyError    # will be re-raised as copy.Error
  return g

That will restore backwards compatibility with pre, which is what the
submitter of the bug requested.

Regards,
Martin


From fredrik@effbot.org  Thu Apr 26 22:48:59 2001
From: fredrik@effbot.org (Fredrik Lundh)
Date: Thu, 26 Apr 2001 23:48:59 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de> <014b01c0ce92$8da742b0$e46940d5@hagrid> <200104262112.f3QLCjd02333@mira.informatik.hu-berlin.de>
Message-ID: <018f01c0ce9a$b49c6e10$e46940d5@hagrid>

Martin v. Loewis wrote:
> Because you cannot modify their state.

same thing as tuples: you cannot modify the tuples, but you
can modify their members.  as its name implies, deepcopy can
deal with tuples...

> So you'd have to modify a, to modify m.group(0). To catch this case,
> you might want to do
> 
> def copy_match(m):
>   g = m.group(0)
>   if copy(g) is not g:
>     raise KeyError    # will be re-raised as copy.Error
>   return g
> 
> That will restore backwards compatibility with pre, which is what the
> submitter of the bug requested.

which means that deepcopy sometimes work on match objects, and
sometimes doesn't.  *that* sounds like a bug to me.

frankly, I don't think the original problem is a bug at all -- I think someone's
abusing a CPython 1.5.2 implementation detail.  it's not documented to work,
it's not in the test suite, and it's not exactly the only thing in there that cannot
be deepcopied...

introducing broken behaviour to deal with someone's broken program sounds
like a rather lousy idea -- and a dangerous precedent.  user code shouldn't
depend on accidental implementation details.

Cheers /F



From fredrik@effbot.org  Thu Apr 26 23:08:47 2001
From: fredrik@effbot.org (Fredrik Lundh)
Date: Fri, 27 Apr 2001 00:08:47 +0200
Subject: [Python-Dev] anyone have an Irix box?
Message-ID: <01ad01c0ce9d$790ac470$e46940d5@hagrid>

SRE doesn't work at all under Irix8/gcc, according to this report
https://sourceforge.net/tracker/?func=detail&aid=233790&group_id=5470&atid=105470

unfortunately, the submitter didn't provide any contact info, and
hasn't bothered to follow up with more details.  and I still don't
have a working SGI box.

any ideas how to deal with this?

Cheers /F



From tim.one@home.com  Fri Apr 27 00:21:24 2001
From: tim.one@home.com (Tim Peters)
Date: Thu, 26 Apr 2001 19:21:24 -0400
Subject: [Python-Dev] anyone have an Irix box?
In-Reply-To: <01ad01c0ce9d$790ac470$e46940d5@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCIENLJOAA.tim.one@home.com>

> SRE doesn't work at all under Irix8/gcc, according to this report
> https://sourceforge.net/tracker/?func=detail&aid=233790&group_id=54
> 70&atid=105470
>
> unfortunately, the submitter didn't provide any contact info, and
> hasn't bothered to follow up with more details.  and I still don't
> have a working SGI box.
>
> any ideas how to deal with this?

The first guess on an SGI box is usually the last:  recompile w/o
optimization.  But if they're *really* using gcc that's probably not
relevant.

In the latter case Guido knows what to do.  But he's not going to tell you
before you tell him how to close the 517 HP-UX thread bugs assigned to him
first <0.9 wink>.



From mwh21@cam.ac.uk  Fri Apr 27 00:45:05 2001
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 27 Apr 2001 00:45:05 +0100
Subject: [Python-Dev] anyone have an Irix box?
In-Reply-To: "Fredrik Lundh"'s message of "Fri, 27 Apr 2001 00:08:47 +0200"
References: <01ad01c0ce9d$790ac470$e46940d5@hagrid>
Message-ID: <m3sniv2pku.fsf@atrus.jesus.cam.ac.uk>

"Fredrik Lundh" <fredrik@effbot.org> writes:

> SRE doesn't work at all under Irix8/gcc, according to this report
> https://sourceforge.net/tracker/?func=detail&aid=233790&group_id=5470&atid=105470
> 
> unfortunately, the submitter didn't provide any contact info, and
> hasn't bothered to follow up with more details.  and I still don't
> have a working SGI box.
> 
> any ideas how to deal with this?

Quinn Dunkan (quinn at dinar.ugcs.caltech.edu) has/had an Irix box he
could test stuff on (I tried to help him sort some readline stuff out
once but got nowhere).  I'm sure he would run make test and email you
the output if you asked nicely.  While not ideal, if it works for him
it would give you more justification in closing the report unless the
OP comes up with some more info.

Cheers,
M.

-- 
  Just put the user directories on a 486 with deadrat7.1 and turn the
  Octane into the afforementioned beer fridge and keep it in your
  office. The lusers won't notice the difference, except that you're
  more cheery during office hours.              -- Pim van Riezen, asr



From tim.one@home.com  Fri Apr 27 00:52:55 2001
From: tim.one@home.com (Tim Peters)
Date: Thu, 26 Apr 2001 19:52:55 -0400
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com>

[/F]
> thought I'd check this one with python-dev before marking
> it as "won't fix".  I cannot see any reason why anyone would
> even attempt to deepcopy match objects...

Likely just because they're part of other objects, like bound to instance
attributes, or members of lists.  No matter how deep they're buried, someone
trying to deepcopy a container will eventually need to deepcopy them too.

> (cannot see any reason why anyone would use deepcopy for
> anything, but that's another story)

It's a std way to get a clone of an object, and when you don't want mutations
of the clone to have any effect on the original (or vice versa).  Perhaps if
I call it the Clone Pattern, people will assume that makes it a good thing
and cut that part of the debate mercifully short <wink>.

It's *nice* to supply a deepcopy operation whenever it's doable with
reasonable effort.  I agree you're not required to in this case -- but it
would still be "nice", if that's feasible.



From martin@loewis.home.cs.tu-berlin.de  Fri Apr 27 06:07:56 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 27 Apr 2001 07:07:56 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <018f01c0ce9a$b49c6e10$e46940d5@hagrid> (fredrik@effbot.org)
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de> <014b01c0ce92$8da742b0$e46940d5@hagrid> <200104262112.f3QLCjd02333@mira.informatik.hu-berlin.de> <018f01c0ce9a$b49c6e10$e46940d5@hagrid>
Message-ID: <200104270507.f3R57uG01297@mira.informatik.hu-berlin.de>

> which means that deepcopy sometimes work on match objects, and
> sometimes doesn't.  *that* sounds like a bug to me.

So I'll provide documentation; that will make it a feature. arrays
cannot be copied either - for no good reason, AFAICT. Given that they
cannot be copied, it is not surprising that match objects referring to
array objects cannot be deepcopied.

The "sometimes works, sometimes doesn't" aspect of deepcopy holds for
any container object:

class X:pass
x = X()
x.values = [1,2,3]
y = copy.deepcopy(x)                # succeeds
x1 = X()
x1.values = array.array("i",[1,2,3])
y1 = copy.deepcopy(x1)              # fails

> frankly, I don't think the original problem is a bug at all -- I
> think someone's abusing a CPython 1.5.2 implementation detail.

It is not abuse. There was no indication in the documentation that
there might be a problem. He probably has a match object as an
instance attribute, and wants to copy the instance. He does not care
whether the match object is shared across copies. He only wants the
instance copying to succeed - which it does in Python 1.5, whereas it
fails in 2.0.

> it's not documented to work, it's not in the test suite, and it's
> not exactly the only thing in there that cannot be deepcopied...

The documentation says

# This version does not copy types like module, class, function,
# method, stack trace, stack frame, file, socket, window, array, or
# any similar types.

So is a match object of "any similar type" or not? Next time, somebody
breaks copying tuples, and claims that tuples are certainly similar to
arrays... There is no indication whatsoever that copying match objects
is not supported - even though the documentation does give a list of
types that are not supported.

> introducing broken behaviour to deal with someone's broken program sounds
> like a rather lousy idea -- and a dangerous precedent.  user code shouldn't
> depend on accidental implementation details.

As I said: the user reading the 1.5 documentation had no way to tell
that it was an "accidental implementation detail". The user reading
the 2.0 documentation had no way to tell that this detail had been
changed. So there clearly is a bug here.

If you want to reject my patch, fine. But at a minimum, there should
be documentation changes to deal with the problem.

Regards,
Martin


From thomas.heller@ion-tof.com  Fri Apr 27 08:53:09 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 27 Apr 2001 09:53:09 +0200
Subject: [Python-Dev] Memory management question
Message-ID: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook>

I'm trying to port Don Beaudry's objectmodule to Python 2.0
and encountered the following problem. Here is a part from Don's code:

  co = (MetaClassObject*) PyClass_New(NULL, methods, name);
  co = PyObject_Realloc(co, sizeof (MetaClassObject));

As you see, he is trying to achive cheap code reuse.
This code does not work.

I have tracked it down to the following sample, which does also not
work. In the debug version on windows, the PyObject_REALLOC
fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)

 op = PyObject_NEW(PyClassObject, &PyClass_Type);
 op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);

Should the above work or am I doing something wrong?

Regards,

Thomas



From fredrik@pythonware.com  Fri Apr 27 10:06:37 2001
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 27 Apr 2001 11:06:37 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com>
Message-ID: <00e801c0cef9$5e142150$0900a8c0@spiff>

tim wrote:
> It's a std way to get a clone of an object, and when you don't want mutations
> of the clone to have any effect on the original (or vice versa).  Perhaps if
> I call it the Clone Pattern, people will assume that makes it a good thing
> and cut that part of the debate mercifully short <wink>.

which leads to a followup question: the current approach
seems to be to hack the copy.py file for each and every
type.  imo, that's rather unpythonic, and also introduces
lots of unnecessary module dependencies.

time to add a __clone__ slot?

or could someone who knows what he's doing here address
this comment in copy.py:

    # XXX need to support copy_reg here too...

Cheers /F




From mal@lemburg.com  Fri Apr 27 10:20:59 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Apr 2001 11:20:59 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not
 deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com> <00e801c0cef9$5e142150$0900a8c0@spiff>
Message-ID: <3AE939FB.D14B2F9B@lemburg.com>

Fredrik Lundh wrote:
> 
> tim wrote:
> > It's a std way to get a clone of an object, and when you don't want mutations
> > of the clone to have any effect on the original (or vice versa).  Perhaps if
> > I call it the Clone Pattern, people will assume that makes it a good thing
> > and cut that part of the debate mercifully short <wink>.
> 
> which leads to a followup question: the current approach
> seems to be to hack the copy.py file for each and every
> type.  imo, that's rather unpythonic, and also introduces
> lots of unnecessary module dependencies.
> 
> time to add a __clone__ slot?
> 
> or could someone who knows what he's doing here address
> this comment in copy.py:
> 
>     # XXX need to support copy_reg here too...

All you have to do is implement the copy protocol (ie. .copy())
for the type/class in question.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


From fredrik@pythonware.com  Fri Apr 27 10:51:23 2001
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 27 Apr 2001 11:51:23 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not  deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com> <00e801c0cef9$5e142150$0900a8c0@spiff> <3AE939FB.D14B2F9B@lemburg.com>
Message-ID: <010e01c0ceff$9f8cc8c0$0900a8c0@spiff>

mal wrote:
> > time to add a __clone__ slot?
> >
> > or could someone who knows what he's doing here address
> > this comment in copy.py:
> >
> >     # XXX need to support copy_reg here too...
>
> All you have to do is implement the copy protocol (ie. .copy())
> for the type/class in question.

cannot find any support for that in the copy module (not in 2.0, at least)

but another reading revealed support for __copy__ and __deepcopy__
methods in at least 1.5.2 and later.  intriguing...

Cheers /F




From mal@lemburg.com  Fri Apr 27 10:57:13 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Apr 2001 11:57:13 +0200
Subject: [Python-Dev] Memory management question
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook>
Message-ID: <3AE94279.DBF73856@lemburg.com>

Thomas Heller wrote:
> 
> I'm trying to port Don Beaudry's objectmodule to Python 2.0
> and encountered the following problem. Here is a part from Don's code:
> 
>   co = (MetaClassObject*) PyClass_New(NULL, methods, name);
>   co = PyObject_Realloc(co, sizeof (MetaClassObject));
> 
> As you see, he is trying to achive cheap code reuse.
> This code does not work.
> 
> I have tracked it down to the following sample, which does also not
> work. In the debug version on windows, the PyObject_REALLOC
> fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)
> 
>  op = PyObject_NEW(PyClassObject, &PyClass_Type);
>  op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);
> 
> Should the above work or am I doing something wrong?

Wouldn't it be safer to first create a MetaClassObject and then
let the standard ClassObject initialize it ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From mal@lemburg.com  Fri Apr 27 11:14:41 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Apr 2001 12:14:41 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not
 deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com> <00e801c0cef9$5e142150$0900a8c0@spiff> <3AE939FB.D14B2F9B@lemburg.com> <010e01c0ceff$9f8cc8c0$0900a8c0@spiff>
Message-ID: <3AE94691.972F02D7@lemburg.com>

Fredrik Lundh wrote:
> 
> mal wrote:
> > > time to add a __clone__ slot?
> > >
> > > or could someone who knows what he's doing here address
> > > this comment in copy.py:
> > >
> > >     # XXX need to support copy_reg here too...
> >
> > All you have to do is implement the copy protocol (ie. .copy())
> > for the type/class in question.
> 
> cannot find any support for that in the copy module (not in 2.0, at least)
> 
> but another reading revealed support for __copy__ and __deepcopy__
> methods in at least 1.5.2 and later.  intriguing...

You're right... the two methods are named __copy__ and __deepcopy__.
Both should return either copies of the object or simply new reference
in case the object's are immutable.

I've implemented these in mxDateTime and that was all it took to
get the copy module happy (at least in Python 1.5.2).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From guido@digicool.com  Fri Apr 27 14:30:31 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 08:30:31 -0500
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: Your message of "Thu, 26 Apr 2001 20:47:29 +0200."
 <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid>
References: <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid>
Message-ID: <200104271330.IAA20006@cj20424-a.reston1.va.home.com>

[Sorry, this bounced -- my new work mail isn't set up right yet]

> > In the re-Module which come with Python version 2.0
> > (Nov 28 11:10 re.py) the created MatchObjects cannot be
> > copied with a deepcopy(). Switching back to the old
> > "pre.py" as proposed in "re.py" makes everything work
> > ok.
> 
> thought I'd check this one with python-dev before marking
> it as "won't fix".  I cannot see any reason why anyone would
> even attempt to deepcopy match objects...
> 
> (cannot see any reason why anyone would use deepcopy for
> anything, but that's another story)

Why don't you ask what they were doing?  They cared enough to figure a
workaround *and* report a bug.  I think they deserve a better answer
than Won't Fix.

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


From guido@digicool.com  Fri Apr 27 16:42:50 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 10:42:50 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 09:53:09 +0200."
 <03e301c0ceef$1b297020$e000a8c0@thomasnotebook>
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook>
Message-ID: <200104271542.KAA20312@cj20424-a.reston1.va.home.com>

> I have tracked it down to the following sample, which does also not
> work. In the debug version on windows, the PyObject_REALLOC
> fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)
> 
>  op = PyObject_NEW(PyClassObject, &PyClass_Type);
>  op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);
> 
> Should the above work or am I doing something wrong?

Probably this doesn't work because of the GC header.  The 'op' pointer
does not point to the start of the allocated memory block.
PyObject_NEW and friends know about this, but PyObject_REALLOC
doesn't.  That's what the assertion is trying to tell you.

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


From thomas.heller@ion-tof.com  Fri Apr 27 15:58:27 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 27 Apr 2001 16:58:27 +0200
Subject: [Python-Dev] Memory management question
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook>  <200104271542.KAA20312@cj20424-a.reston1.va.home.com>
Message-ID: <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook>

> > I have tracked it down to the following sample, which does also not
> > work. In the debug version on windows, the PyObject_REALLOC
> > fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)
> > 
> >  op = PyObject_NEW(PyClassObject, &PyClass_Type);
> >  op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);
> > 
> > Should the above work or am I doing something wrong?
> 
> Probably this doesn't work because of the GC header.  The 'op' pointer
> does not point to the start of the allocated memory block.
> PyObject_NEW and friends know about this, but PyObject_REALLOC
> doesn't.  That's what the assertion is trying to tell you.
Yes, I've also trakced it down to this.

I assume, PyObject_NEW is a friend of PyObject_DEL, and
so are PyObject_MALLOC, PyObject_REALLOC, and PyObject_FREE - 
but the relationship between the first and the second category
is somewhat cooler...

Is there any (official) way to realloc the memory returned by
PyObject_NEW ?

(Always pushing the apis beyond their limits :-)

Thomas



From guido@digicool.com  Fri Apr 27 17:39:46 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 11:39:46 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 16:58:27 +0200."
 <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook>
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com>
 <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook>
Message-ID: <200104271639.LAA20790@cj20424-a.reston1.va.home.com>

> Is there any (official) way to realloc the memory returned by
> PyObject_NEW ?

Not if the object participates in GC.

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


From thomas.heller@ion-tof.com  Fri Apr 27 16:56:34 2001
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 27 Apr 2001 17:56:34 +0200
Subject: [Python-Dev] Memory management question
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com>              <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook>  <200104271639.LAA20790@cj20424-a.reston1.va.home.com>
Message-ID: <038701c0cf32$a29bfc60$e000a8c0@thomasnotebook>

> > Is there any (official) way to realloc the memory returned by
> > PyObject_NEW ?
> 
> Not if the object participates in GC.

I'll shut up after this one:

Would a PyObject_RESIZE function/macro make sense?

Thomas



From guido@digicool.com  Fri Apr 27 18:01:37 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 12:01:37 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 17:56:34 +0200."
 <038701c0cf32$a29bfc60$e000a8c0@thomasnotebook>
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com> <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> <200104271639.LAA20790@cj20424-a.reston1.va.home.com>
 <038701c0cf32$a29bfc60$e000a8c0@thomasnotebook>
Message-ID: <200104271701.MAA21256@cj20424-a.reston1.va.home.com>

> I'll shut up after this one:
> 
> Would a PyObject_RESIZE function/macro make sense?
> 
> Thomas

Not for anybody else besides you, I think.

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


From Greg.Wilson@baltimore.com  Fri Apr 27 18:26:52 2001
From: Greg.Wilson@baltimore.com (Greg Wilson)
Date: Fri, 27 Apr 2001 13:26:52 -0400
Subject: [Python-Dev] FW: how will you be writing code 10 years from now?
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F27AF41@nsamcanms1.ca.baltimore.com>

The following is a webcast from a (preliminary non-official) meeting on
C++0x (C++, the next generation). Could be a bit of foreshadowing on how
things will develop (or prove to be giant red herring if they decide not to
follow any of these ideas)

http://technetcast.ddj.com/tnc_play_stream.html?stream_id=560


From moshez@zadka.site.co.il  Fri Apr 27 18:50:13 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Fri, 27 Apr 2001 20:50:13 +0300
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <00e801c0cef9$5e142150$0900a8c0@spiff>
References: <00e801c0cef9$5e142150$0900a8c0@spiff>, <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com>
Message-ID: <E14tCNh-0003Dj-00@darjeeling>

On Fri, 27 Apr 2001, "Fredrik Lundh" <fredrik@pythonware.com> wrote:

> time to add a __clone__ slot?

It's called __setstate__ and __getstate__, I think?
Don't these have an appropriate C-level slots?

>     # XXX need to support copy_reg here too...

I think it's talking about having copy be the same (but without the
middle man) as Unpickle.loads(Pickle.dumps(o)) (which is a perfect
copy.deepcopy, if a bit wasteful.

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez@debian.org  |http://www.{python,debian,gnu}.org


From nas@python.ca  Fri Apr 27 19:10:23 2001
From: nas@python.ca (Neil Schemenauer)
Date: Fri, 27 Apr 2001 11:10:23 -0700
Subject: [Python-Dev] Memory management question
In-Reply-To: <200104271639.LAA20790@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Fri, Apr 27, 2001 at 11:39:46AM -0500
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com> <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> <200104271639.LAA20790@cj20424-a.reston1.va.home.com>
Message-ID: <20010427111023.A23210@glacier.fnational.com>

Guido van Rossum wrote:
> > Is there any (official) way to realloc the memory returned by
> > PyObject_NEW ?
> 
> Not if the object participates in GC.

I going to see if I can fix this for 2.2.  My current thinking is
that there should be memory management APIs for GC objects,
something like:

    PyObject_GC_New()
    PyObject_GC_NewVar()
    PyObject_GC_Realloc()
    PyObject_GC_Del()

The non-GC APIs would no longer have to check the type flags
which would be a bit of a speed win.  The _AS_GC, _FROM_GC macros
would not have to be used as much and the GC implementation would
have more freedom about how to allocate things.

  Neil


From guido@digicool.com  Fri Apr 27 20:14:20 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 14:14:20 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 11:10:23 MST."
 <20010427111023.A23210@glacier.fnational.com>
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com> <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> <200104271639.LAA20790@cj20424-a.reston1.va.home.com>
 <20010427111023.A23210@glacier.fnational.com>
Message-ID: <200104271914.OAA24467@cj20424-a.reston1.va.home.com>

> I going to see if I can fix this for 2.2.  My current thinking is
> that there should be memory management APIs for GC objects,
> something like:
> 
>     PyObject_GC_New()
>     PyObject_GC_NewVar()
>     PyObject_GC_Realloc()
>     PyObject_GC_Del()
> 
> The non-GC APIs would no longer have to check the type flags
> which would be a bit of a speed win.  The _AS_GC, _FROM_GC macros
> would not have to be used as much and the GC implementation would
> have more freedom about how to allocate things.

Looks good!

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


From tim.one@home.com  Fri Apr 27 19:58:03 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 27 Apr 2001 14:58:03 -0400
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <00e801c0cef9$5e142150$0900a8c0@spiff>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEAIJPAA.tim.one@home.com>

[Fredrik Lundh]
> which leads to a followup question: the current approach
> seems to be to hack the copy.py file for each and every
> type.  imo, that's rather unpythonic, and also introduces
> lots of unnecessary module dependencies.
>
> time to add a __clone__ slot?

Note that classes can supply custom cloners via defining __copy__ and
__deepcopy__ methods, without changing copy.py.

A __clone__ slot for *types* would need to address the shallow vs deep
question too, along with the other __getinitargs__, __getstate__,
__setstate__ gimmicks.  How many slots does that add up to?  I leave it to
the PEP author to count them <wink>.

The copy.py protocols kinda grew up with pickle.py's, and together still have
the flavor (to my tongue) of a prototype caught late in midstream.  That is,
it feels like they're not quite finished yet.

> or could someone who knows what he's doing here address
> this comment in copy.py:
>
>     # XXX need to support copy_reg here too...

copy_reg is one of the pickle.py facilities that copy.py "should use" too;
it's a registration database that tells pickle what to do about objects of
types pickle doesn't understand directly (so *could* also be directly
relevant to cloning objects of types copy.py doesn't understand directly --
depending).



From martin@loewis.home.cs.tu-berlin.de  Fri Apr 27 20:10:14 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 27 Apr 2001 21:10:14 +0200
Subject: [Python-Dev] SF changing directory structure
Message-ID: <200104271910.f3RJAE301849@mira.informatik.hu-berlin.de>

As some of you may have noticed, the Python web pages are now in
/home/groups/p/py/python on SourceForge; the symbolic link
/home/groups/python will be removed shortly.

There might be still a number of files that refer to the old location,
atleast htdocs/sf-faq.html, and perhaps crontabs. Whoever is in charge
of these should probably update them.

Regards,
Martin




From tim.one@home.com  Fri Apr 27 20:57:12 2001
From: tim.one@home.com (Tim Peters)
Date: Fri, 27 Apr 2001 15:57:12 -0400
Subject: [Python-Dev] SF changing directory structure
In-Reply-To: <200104271910.f3RJAE301849@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEAPJPAA.tim.one@home.com>

[Martin v. Loewis]
> /home/groups/p/py/python on SourceForge; the symbolic link
> /home/groups/python will be removed shortly.

Phooey.  Thanks for the warning!  I sure didn't know about it.

> There might be still a number of files that refer to the old location,
> atleast htdocs/sf-faq.html, and perhaps crontabs. Whoever is in charge
> of these should probably update them.

Nobody is in charge:  if you know of a problem, please fix it.  All the HTML
stuff is under CVS control, and all Python project members have commit access
for it, same as for everything else in the Python source tree; it's just
under the nondist branch instead of the dist branch.



From tim.one@home.com  Sat Apr 28 08:24:48 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 28 Apr 2001 03:24:48 -0400
Subject: [Python-Dev] Iterators, map, xreadlines and docs
Message-ID: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>

A confused user on c.l.py reported that while

    for x in file.xreadlines():

works fine,

    map(whatever, file.xreadlines())

blows up with

    TypeError: argument 2 to map() must be a sequence object

The docs say both contexts require "a sequence", so this is baffling to them.

It's apparently because map() internally insists that the sq_length slot be
non-null (but it's null in the xreadlines object), despite that map() doesn't
use it for anything other than *guessing* a result size (it keeps going until
IndexError is raised regardless of what len() returns, growing or shrinking
the preallocated result list as needed).

I think that's a bug in map().  Anyone disagree?

If so, fine, map() has to be changed to work with iterators anyway <wink>.

How are we going to identify all the places that need to become
iterator-aware, get all the code changed, and update the docs to match?  In
effect, a bunch of docs for arguments need to say, in some words or other,
that the args must implement the iterator interface or protocol.  I think
it's essential that we define the latter only once.  But the docs don't
really define any interfaces/protocols now, so it's unclear where to put
that.

Fred, Pronounce.  Better sooner than later, else I bet a bunch of code
changes will get checked in without appropriate doc changes, and the 2.2 docs
won't match the code.



From martin@loewis.home.cs.tu-berlin.de  Sat Apr 28 08:28:35 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 28 Apr 2001 09:28:35 +0200
Subject: [Python-Dev] SF changing directory structure
Message-ID: <200104280728.f3S7SZ801219@mira.informatik.hu-berlin.de>

> Nobody is in charge: if you know of a problem, please fix it.  All
> the HTML stuff is under CVS control, and all Python project members
> have commit access for it, same as for everything else in the Python
> source tree; it's just under the nondist branch instead of the dist
> branch.

Ok, changed in CVS. Is the answer to SF-FAQ question 1.3 still
correct? That modified files have to manually uploaded to SF? That
answer does not mention nondist/sf-html at all...

Regards,
Martin


From tim.one@home.com  Sat Apr 28 08:48:50 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 28 Apr 2001 03:48:50 -0400
Subject: [Python-Dev] RE: SF changing directory structure
In-Reply-To: <200104280728.f3S7SZ801219@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCKECLJPAA.tim.one@home.com>

[Martin v. Loewis]
> Ok, changed in CVS.

Thank you!

> Is the answer to SF-FAQ question 1.3 still correct?
> That modified files have to manually uploaded to SF?

AFAIK, yes.  I didn't write the question or the answer, though, and don't
believe I read that part of the FAQ before.  /F's pep2html.py script is used
to generate the HTML form of PEPs, and its -i (install) option never worked
for me on Windows, so I've always done that bit by hand.

Indeed, your changes didn't *show up* via the SF interface before I (just)
did

scp sf-faq.html \
    tim_one@shell.sourceforge.net:/home/groups/p/py/python/htdocs/

> That answer does not mention nondist/sf-html at all...

It apparently doesn't mention a lot of things.  But I'm not going to change
it since I don't have a clear understanding of how this stuff works; I only
know what I do by hand that works in the end.



From moshez@zadka.site.co.il  Sat Apr 28 10:07:43 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Sat, 28 Apr 2001 12:07:43 +0300
Subject: [Python-Dev] Iterators, map, xreadlines and docs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
Message-ID: <E14tQhb-0004Dd-00@darjeeling>

On Sat, 28 Apr 2001 03:24:48 -0400, "Tim Peters" <tim.one@home.com> wrote:

> A confused user on c.l.py reported that while
> 
>     for x in file.xreadlines():
> 
> works fine,
> 
>     map(whatever, file.xreadlines())
> 
> blows up with
> 
>     TypeError: argument 2 to map() must be a sequence object
...
> I think that's a bug in map().  Anyone disagree?

I agree...but when we talked about it in c.l.py, I said that and you
said map() should be deprecated. Why the sudden change of heart?
why shouldn't it be changed to

[whatever(x) for x in file.xreadlines()]?

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez@debian.org  |http://www.{python,debian,gnu}.org


From tim.one@home.com  Sat Apr 28 10:17:33 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 28 Apr 2001 05:17:33 -0400
Subject: [Python-Dev] Iterators, map, xreadlines and docs
In-Reply-To: <E14tQhb-0004Dd-00@darjeeling>
Message-ID: <LNBBLJKPBEHFEDALKOLCGECNJPAA.tim.one@home.com>

> ...
>> I think that's a bug in map().  Anyone disagree?

[Moshe]
> I agree...but when we talked about it in c.l.py, I said that and you
> said map() should be deprecated. Why the sudden change of heart?

This doesn't ring a bell.  I don't even recall *seeing* a msg from you in the
.xreadlines() vs map() thread ...

> why shouldn't it be changed to
>
> [whatever(x) for x in file.xreadlines()]?

I'm not keen to eradicate map() from the face of the Earth regardless, and
until it *is* deprecated (if ever), it's supported.  But this is all moot
since I already checked in the map() fix.

How to deal with the iterator docs is still an important issue.



From moshez@zadka.site.co.il  Sat Apr 28 11:14:33 2001
From: moshez@zadka.site.co.il (Moshe Zadka)
Date: Sat, 28 Apr 2001 13:14:33 +0300
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.198,2.199
In-Reply-To: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>
References: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <E14tRkH-0004KU-00@darjeeling>

On Sat, 28 Apr 2001, Tim Peters <tim_one@users.sourceforge.net> wrote:

> Modified Files:
> 	bltinmodule.c 
> Log Message:
> Fix buglet reported on c.l.py:  map(fnc, file.xreadlines()) blows up.
> Also a 2.1 bugfix candidate (am I supposed to do something with those?).
> Took away map()'s insistence that sequences support __len__, and cleaned
> up the convoluted code that made it *look* like it really cared about
> __len__ (in fact the old ->len field was only *used* as a flag bit, as
> the main loop only looked at its sign bit, setting the field to -1 when
> IndexError got raised; renamed the field to ->saw_IndexError instead).

Can anyone give me his opinion about whether 2.0.1 should have this
bug fix? It's not just for file.xreadlines(): the older fileinput.fileinput()
is hurt by this as well...

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez@debian.org  |http://www.{python,debian,gnu}.org


From fdrake@acm.org  Sat Apr 28 13:50:54 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Sat, 28 Apr 2001 08:50:54 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.198,2.199
In-Reply-To: <E14tRkH-0004KU-00@darjeeling>
References: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>
 <E14tRkH-0004KU-00@darjeeling>
Message-ID: <15082.48302.168082.219299@cj42289-a.reston1.va.home.com>

Moshe Zadka writes:
 > Can anyone give me his opinion about whether 2.0.1 should have this
 > bug fix? It's not just for file.xreadlines(): the older
 > fileinput.fileinput() is hurt by this as well...

  I don't know about 2.0.1, but 2.1.1 definately should.


  -Fred

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



From guido@digicool.com  Sat Apr 28 18:11:13 2001
From: guido@digicool.com (Guido van Rossum)
Date: Sat, 28 Apr 2001 12:11:13 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.198,2.199
In-Reply-To: Your message of "Sat, 28 Apr 2001 13:14:33 +0300."
 <E14tRkH-0004KU-00@darjeeling>
References: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>
 <E14tRkH-0004KU-00@darjeeling>
Message-ID: <200104281711.MAA29948@cj20424-a.reston1.va.home.com>

> Can anyone give me his opinion about whether 2.0.1 should have this
> bug fix? It's not just for file.xreadlines(): the older fileinput.fileinput()
> is hurt by this as well...

I wouldn't bother -- 2.0.1 doesn't need to be better than 2.1.

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


From fdrake@acm.org  Sun Apr 29 02:41:04 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Sat, 28 Apr 2001 21:41:04 -0400 (EDT)
Subject: [Python-Dev] Re: Iterators, map, xreadlines and docs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
Message-ID: <15083.28976.418924.738526@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > effect, a bunch of docs for arguments need to say, in some words or other,
 > that the args must implement the iterator interface or protocol.  I think
 > it's essential that we define the latter only once.  But the docs don't
 > really define any interfaces/protocols now, so it's unclear where to put
 > that.

  Won't there be at least one standard iterator object defined for
lists, etc.?  That could be described in the built-in types section
(as with files, lists, etc.) of the Library Reference.  That will be
used as the definition of the iterator protocol in the same way the
file object description there is referred to from places that want
file or file-like objects.
  I think we need some re-organization of the built-in types section
to separate abstract protocols from specific implementations, but
that's an orthagonal aspect and can be handled at the same time as the
rest of the built-in types.
  Specific changes for places that accept iterators should be made as
the code is changed, as usual.  Please describe the changes clearly in
checkin messages so iterator related changes don't propogate to the
maintenance branch.


  -Fred

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



From MarkH@ActiveState.com  Sun Apr 29 03:14:43 2001
From: MarkH@ActiveState.com (Mark Hammond)
Date: Sun, 29 Apr 2001 12:14:43 +1000
Subject: [Python-Dev] Slight wart in __all__
Message-ID: <LCEPIIGDJPKCOIHOBJEPKEBEDLAA.MarkH@ActiveState.com>

I just got caught out by this:

"""
def foo():
    pass

__all__ = [foo]
"""

Then at the interactive prompt:

>>> from foo import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: attribute name must be string


The problem is that __all__ contains a function object rather than a string
object.  I had to use the debugger to determine why I was getting the
failure :(  All you 2.1 veterans will immediately pick that it should read
'__all__ = ["foo"]'

Looking at the __all__ code:

		if (skip_leading_underscores &&
		    PyString_Check(name) &&
		    PyString_AS_STRING(name)[0] == '_')
		{
			Py_DECREF(name);
			continue;
		}
		value = PyObject_GetAttr(v, name);

PyObject_GetAttr explicitly handles string and unicode objects.  However,
code here won't like Unicode that much :)

Would it make sense to a explicitly raise a more meaningful exception here
if __all__ doesnt contain strings?



From tim.one@home.com  Sun Apr 29 04:17:47 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 28 Apr 2001 23:17:47 -0400
Subject: [Python-Dev] RE: Iterators, map, xreadlines and docs
In-Reply-To: <15083.28976.418924.738526@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEEAJPAA.tim.one@home.com>

[Fred]
>   Won't there be at least one standard iterator object defined for
> lists, etc.?

>>> iter([])
<iterator object at 00792640>

>>> iter({})
<dictionary-iterator object at 00793A40>

>>> iter(())
<iterator object at 00792640>

>>> import sys
>>> iter(sys.stdin)
<callable-iterator object at 00793FE0>

>>> class C:
...     def __iter__(self): return self
...
>>> iter(C())
<__main__.C instance at 007938EC>
>>>

What do those have in common?  Objects and types are the wrong way to
approach this one:  it's really of no interest that, e.g., iter(list) and
iter(dict) return objects of different types; what *is* interesting is that
iter(whatever) returns *an* object that conforms to the iterator protocol (or
"implements the iterator interface" -- all the same to me).  You can give
*examples* of builtin iterator types that conform to the protocol, but the
protocol needs to be defined for its own sake first.  The protocol is
fundamental, and is neither an object nor a type.

> That could be described in the built-in types section (as with
> files, lists, etc.) of the Library Reference.  That will be used
> as the definition of the iterator protocol in the same way the
> file object description there is referred to from places that want
> file or file-like objects.

"file-like objects" is the bad doc experience I'm hoping we don't repeat.
The phrase "file-like object" is indeed used freely in the docs, but it's not
(AFAICT) *defined* anywhere, and doesn't even appear in the index.  Besides,
the notion that "file-like object" refers to section

    Buitin-in Types, Exceptions and Functions ->
     Other Built-in Types ->
      File Objects

was news to me.  I see the individual method descriptions there sometimes
refer to "file-like objects", and other times "objects implementing a
file-like interface".  The latter phrase appears uniquely in the description
of .readlines(), and may be the clearest explanation in the docs of wtf
"file-like object" means.  If so, it shouldn't be buried in the bowels of one
method description.

>   I think we need some re-organization of the built-in types section
> to separate abstract protocols from specific implementations,

Yes.

> but that's an orthagonal aspect and can be handled at the same
> time as the rest of the built-in types.

I assume you're thinking of creating a new "Iterator Objects" section under
"Other Built-in Types"?  That would work for me if it *started* with a
description of the iterator interface/protocol.

There's a twist, though:  iterators need to be defined already in the
Language Reference manual (we can't explain for-loops without them anymore).

>   Specific changes for places that accept iterators should be made as
> the code is changed, as usual.  Please describe the changes clearly in
> checkin messages so iterator related changes don't propogate to the
> maintenance branch.

We need an example to build on -- this is too abstract for me (which is
saying something <wink>).

For example, today we have:

    list(sequence)
        Return a list whose items are the same and in the same order as
        sequence's items. If sequence is already a list, a copy is made
        and returned, similar to sequence[:]. For instance, list('abc')
        returns returns ['a', 'b', 'c'] and list( (1, 2, 3) )
        returns [1, 2, 3].

list() doesn't yet work with iterators, but surely will.  What do we want the
docs to say after it changes?  Should it be implicit or explicit that
"sequence" now means "sequence or sequence-like object"?  Where is the
connection between "sequence-like object" and "iterable" explained?  Perhaps
what's really needed is s/sequence/iterable/ in this description.  But then
where is "iterable" defined?

Solve this once and the rest should follow easily.  But solving it the first
time doesn't look easy to me.  That's why I'm bugging you now.



From mal@lemburg.com  Mon Apr 30 11:19:53 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 12:19:53 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
Message-ID: <3AED3C49.ACDD40E@lemburg.com>

Rebooting the thread...

While testing mxNumber, I discovered what looks like a bug in
Win95: both Thomas Heller and I are seeing a problem with 
Python 2.1 when importing extension modules which rely on other 
DLLs as library.

Interestingly, the problem only shows up when starting Python
from the installation directory. Looking at the imports using
python -vv shows that in this situation, Python tries to import
modules, packages, extensions etc. using *relative* paths.

Now, under Win98 there is no problem, but Win95 doesn't seem
to like these relative imports when it comes to .pyd files
which reference DLLs in the same directory. It doesn't have
any problems when Python is started outside the installation
dir, since in that case Python uses absolute paths for importing
modules and extensions.

Would it be hard to tweak Python into always using absolute search
paths during module import ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From guido@digicool.com  Mon Apr 30 14:21:49 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 30 Apr 2001 08:21:49 -0500
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: Your message of "Mon, 30 Apr 2001 12:19:53 +0200."
 <3AED3C49.ACDD40E@lemburg.com>
References: <3AED3C49.ACDD40E@lemburg.com>
Message-ID: <200104301321.IAA07476@cj20424-a.reston1.va.home.com>

> Would it be hard to tweak Python into always using absolute search
> paths during module import ?

I resist doing this *in general* because absolute paths don't always
mean the right thing on all platforms (and aren't always obtainable),
but I agree that for Windows this can and should be done.

The easiest way I can think of is for PC/getpathp.py to tweak the path
entries to be absolute pathnames.  A single getcwd() call should
suffice.

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


From MarkH@ActiveState.com  Mon Apr 30 13:23:23 2001
From: MarkH@ActiveState.com (Mark Hammond)
Date: Mon, 30 Apr 2001 22:23:23 +1000
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: <3AED3C49.ACDD40E@lemburg.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPIEBNDLAA.MarkH@ActiveState.com>

> Interestingly, the problem only shows up when starting Python
> from the installation directory. Looking at the imports using
> python -vv shows that in this situation, Python tries to import
> modules, packages, extensions etc. using *relative* paths.

I'm not quite with you here.  Are you saying both Win98 and 95 use relative
paths, but only Win95 has the problem, or that only Win95 sees relative
paths?

My Win98 box uses absolute paths for all imports when using -vv

> Would it be hard to tweak Python into always using absolute search
> paths during module import ?

Where are the relative paths coming from?  If we can determine that, we can
determine how hard it would be to fix ;-)

Mark.



From mal@lemburg.com  Mon Apr 30 13:53:21 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 14:53:21 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
References: <LCEPIIGDJPKCOIHOBJEPIEBNDLAA.MarkH@ActiveState.com>
Message-ID: <3AED6041.A3E3AE7B@lemburg.com>

Mark Hammond wrote:
> 
> > Interestingly, the problem only shows up when starting Python
> > from the installation directory. Looking at the imports using
> > python -vv shows that in this situation, Python tries to import
> > modules, packages, extensions etc. using *relative* paths.
> 
> I'm not quite with you here.  Are you saying both Win98 and 95 use relative
> paths, but only Win95 has the problem, or that only Win95 sees relative
> paths?

Both are using relative paths, but only Win95 has a problem with not
finding the DLL needed by a PYD file in a subpackage:

abc/
    __init__.py
    mxABC.pyd
    mamba.dll

mxABC.pyd needs mamba.dll.
 
> My Win98 box uses absolute paths for all imports when using -vv

Are you sure ? Please CD to the C:\Python21 dir and then try
to import and installed package (say mx.Tools from egenix-mx-base).
You should be seeing relative paths with -vv.
 
> > Would it be hard to tweak Python into always using absolute search
> > paths during module import ?
> 
> Where are the relative paths coming from?  If we can determine that, we can
> determine how hard it would be to fix ;-)

The relative paths come from the import logic: the current dir
is scanned first and if the package is found in that directory,
all subsequent lookups are done using relative paths.

While this is prefectly OK, Win95 seems to have a problem with
importing extensions using these relative paths. I think we could
solve the problem by making the pathname which is passed to
LoadLibraryEx() in dynload_win.c absolute.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From mal@lemburg.com  Mon Apr 30 13:54:54 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 14:54:54 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
References: <3AED3C49.ACDD40E@lemburg.com> <200104301321.IAA07476@cj20424-a.reston1.va.home.com>
Message-ID: <3AED609E.A7D9B454@lemburg.com>

Guido van Rossum wrote:
> 
> > Would it be hard to tweak Python into always using absolute search
> > paths during module import ?
> 
> I resist doing this *in general* because absolute paths don't always
> mean the right thing on all platforms (and aren't always obtainable),
> but I agree that for Windows this can and should be done.

I have only run into the problem with Win95, so yes, doing this
for Windows only should be OK (and even there it's probably only
needed for importing PYD files).
 
> The easiest way I can think of is for PC/getpathp.py to tweak the path
> entries to be absolute pathnames.  A single getcwd() call should
> suffice.

I'd rather keep the changes in dynload_win.c if that's possible.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From guido@digicool.com  Mon Apr 30 14:57:56 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 30 Apr 2001 08:57:56 -0500
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: Your message of "Mon, 30 Apr 2001 14:54:54 +0200."
 <3AED609E.A7D9B454@lemburg.com>
References: <3AED3C49.ACDD40E@lemburg.com> <200104301321.IAA07476@cj20424-a.reston1.va.home.com>
 <3AED609E.A7D9B454@lemburg.com>
Message-ID: <200104301357.IAA07564@cj20424-a.reston1.va.home.com>

> I'd rather keep the changes in dynload_win.c if that's possible.

Fine with me.

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


From MarkH@ActiveState.com  Mon Apr 30 14:01:33 2001
From: MarkH@ActiveState.com (Mark Hammond)
Date: Mon, 30 Apr 2001 23:01:33 +1000
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: <3AED6041.A3E3AE7B@lemburg.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPIEBODLAA.MarkH@ActiveState.com>

> abc/
>     __init__.py
>     mxABC.pyd
>     mamba.dll
>
> mxABC.pyd needs mamba.dll.
>
> > My Win98 box uses absolute paths for all imports when using -vv
>
> Are you sure ? Please CD to the C:\Python21 dir and then try

Right - I am with you now...

> importing extensions using these relative paths. I think we could
> solve the problem by making the pathname which is passed to
> LoadLibraryEx() in dynload_win.c absolute.

Just calling GetFullPathName() before the LoadLibEx() would seem a
reasonable and appropriate patch.  Keeps it a long way from the "*in
general*" Guido was concerned about, and sounds low-risk to me!

Ahh - Guido just OK'd it, so go for it ;-)

Mark.



From mal@lemburg.com  Mon Apr 30 15:10:16 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 16:10:16 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
References: <LCEPIIGDJPKCOIHOBJEPIEBODLAA.MarkH@ActiveState.com>
Message-ID: <3AED7248.B7386B83@lemburg.com>

Mark Hammond wrote:
> 
> > abc/
> >     __init__.py
> >     mxABC.pyd
> >     mamba.dll
> >
> > mxABC.pyd needs mamba.dll.
> >
> > > My Win98 box uses absolute paths for all imports when using -vv
> >
> > Are you sure ? Please CD to the C:\Python21 dir and then try
> 
> Right - I am with you now...
> 
> > importing extensions using these relative paths. I think we could
> > solve the problem by making the pathname which is passed to
> > LoadLibraryEx() in dynload_win.c absolute.
> 
> Just calling GetFullPathName() before the LoadLibEx() would seem a
> reasonable and appropriate patch.  Keeps it a long way from the "*in
> general*" Guido was concerned about, and sounds low-risk to me!
> 
> Ahh - Guido just OK'd it, so go for it ;-)

Here's a stab at a patch. Could you review it and test it ? I
don't have enough knowledge of win32 for this...

dynload_win.c:
...
#ifdef MS_WIN32
	{
		HINSTANCE hDLL;
		char pathbuf[260];
		LPTSTR *dummy;
		
		if (strchr(pathname, '\\') == NULL &&
		    strchr(pathname, '/') == NULL)
		{
			/* Prefix bare filename with ".\" */
			char *p = pathbuf;
			*p = '\0';
			_getcwd(pathbuf, sizeof pathbuf);
			if (*p != '\0' && p[1] == ':')
				p += 2;
			sprintf(p, ".\\%-.255s", pathname);
			pathname = pathbuf;
		}
		/* Convert to full pathname; we ignore errors to maintain
		   b/w compatibility here. */
		if (GetFullPathName(pathname,
				    sizeof(pathbuf),
				    pathbuf,
				    &dummy))
		    pathname = pathbuf;
		/* Look for dependent DLLs in directory of pathname first */
		/* XXX This call doesn't exist in Windows CE */
		if (pathname)
		    hDLL = LoadLibraryEx(pathname, NULL,
					 LOAD_WITH_ALTERED_SEARCH_PATH);
		if (hDLL == NULL) {
			char errBuf[256];
			unsigned int errorCode;
...

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/


From michel@digicool.com  Mon Apr 30 19:39:38 2001
From: michel@digicool.com (Michel Pelletier)
Date: Mon, 30 Apr 2001 11:39:38 -0700 (PDT)
Subject: [Python-Dev] RE: Iterators, map, xreadlines and docs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEEAJPAA.tim.one@home.com>
Message-ID: <Pine.LNX.4.21.0104301049590.7346-100000@localhost.localdomain>

On Sat, 28 Apr 2001, Tim Peters wrote:

> What do those have in common?  Objects and types are the wrong way to
> approach this one:  it's really of no interest that, e.g., iter(list) and
> iter(dict) return objects of different types; what *is* interesting is that
> iter(whatever) returns *an* object that conforms to the iterator protocol (or
> "implements the iterator interface" -- all the same to me).  

I have added a notional iter interface to the PEP 245 prototype and will
be making another release of it later tonight.

> "file-like objects" is the bad doc experience I'm hoping we don't repeat.
> The phrase "file-like object" is indeed used freely in the docs, but it's not
> (AFAICT) *defined* anywhere, and doesn't even appear in the index.  Besides,
> the notion that "file-like object" refers to section
> 
>     Buitin-in Types, Exceptions and Functions ->
>      Other Built-in Types ->
>       File Objects
> 
> was news to me.  I see the individual method descriptions there sometimes
> refer to "file-like objects", and other times "objects implementing a
> file-like interface".  The latter phrase appears uniquely in the description
> of .readlines(), and may be the clearest explanation in the docs of wtf
> "file-like object" means.  If so, it shouldn't be buried in the bowels of one
> method description.

245 takes a couple stabs at File interfaces, trying to satisfy the
bare-bones kind of file, a Python File, StringI, StringO etc...

> >   I think we need some re-organization of the built-in types section
> > to separate abstract protocols from specific implementations,
> 
> Yes.

FYI, 245 defines the following interfaces.  Some of them may be wrong,
I took most of this straight from the Pydocs and stuff done by Jim:

  Mutable
  
  Comparable

  Orderable(Comparable)

  Hashable
  
  Hashkey(Comparable, Hashable)

  Membership

  Mapping

  Sized

  MutableMapping(Mutable)    

  Sequence(Mapping)

  Sequential(Sequential)

  Type

  Null

  String(Sequence, Sized)

  Tuple(Sequence, Sized)

  List(Mapping, MutableMapping, Sequence, Sized)

  Dictionary(Mapping, MutableMapping, Sized)

  File - and the various specific file functionality

  Module

  Class

  Function

  InstanceMethod

  Exception

  Number - Real, Compex, Exact, others....

Here are some examples from the current prototype.  The primary
utility function from PEP 245 is 'does':

    Python 2.1 (#1, Apr 22 2001, 06:33:07) 
    [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
    Type "copyright", "credits" or "license" for more information.
    >>> from Interface import does

'does' can be used two ways.  The first way is to pass imp an object
and it will return the interfaces that the object implements:

    >>> does({})
    [<Interface Dictionary at 82e288c>]
    >>> does([])
    [<Interface List at 82c71f4>]
    >>> does(sys.stdin)
    [<Interface PyFile at 8261e54>]
    >>> def f(): pass
    ...
    >>> does(f)
    [<Interface Function at 82ff134>]

Here, we see that a dictionary and a list do the 'Dictionary' and
'List' interfaces respectively, and that files and functions also
implement interfaces.  'does' can also be used with another argument,
to ask whether the object implements a certain interface:

    >>> from Interface.Protocols import Mapping, Sequence, Mutable
    >>> from Interface.File import File
    >>> does({}, Mapping)
    1
    >>> does([], Sequence)
    1
    >>> does((), Mutable)
    0
    >>> does({}, Dictionary)
    1
    >>> does(sys.stdin, File)
    1

Note that PEP 245 requires NO changes to Python.  You can download it
now and try this stuff out.

-Michel





From michel@digicool.com  Mon Apr 30 20:48:25 2001
From: michel@digicool.com (Michel Pelletier)
Date: Mon, 30 Apr 2001 12:48:25 -0700 (PDT)
Subject: [Python-Dev] RE: Iterators, map, xreadlines and docs
In-Reply-To: <Pine.LNX.4.21.0104301049590.7346-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0104301247450.7346-100000@localhost.localdomain>

On Mon, 30 Apr 2001, Michel Pelletier wrote:

> On Sat, 28 Apr 2001, Tim Peters wrote:
> 
> I have added a notional iter interface to the PEP 245 prototype and will
> be making another release of it later tonight.

I forgot to mention that you can get the previous release (without
iter) here:

http://www.zope.org/Members/michel/InterfacesPEP/Interface.tgz

-Michel



From tim.one at home.com  Sun Apr  1 06:27:48 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 31 Mar 2001 23:27:48 -0500
Subject: [Python-Dev] nano-threads?
In-Reply-To: <20010326210824.B17390@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>

[Neil Schemenauer
 Tuesday, March 27, 2001 12:08 AM
]
> Here are some silly bits of code implementing single frame
> coroutines and threads using my frame suspend/resume patch.
> ...
> If your sick of such postings on python-dev flame me privately
> and I will stop.

Since the postings stopped there, did someone flame you?  I'm projecting my
own situtation onto everyone else, namely that this is interesting but I
can't make time for it now.  If you're still playing with this, though, I
hope you do continue to let Python-Dev know how it's going!

the-archives-house-many-wonders-ly y'rs  - tim




From fredrik at pythonware.com  Sun Apr  1 11:38:42 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 1 Apr 2001 11:38:42 +0200
Subject: [Python-Dev] nano-threads?
References: <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>
Message-ID: <044d01c0ba8f$8c0e4910$e46940d5@hagrid>

tim wrote:
> > If your sick of such postings on python-dev flame me privately
> > and I will stop.
> 
> Since the postings stopped there, did someone flame you?

well, I threatened to flame Neil if he stopped working on this...

Sorry /F




From fdrake at acm.org  Sun Apr  1 17:55:48 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sun, 1 Apr 2001 11:55:48 -0400 (EDT)
Subject: [Python-Dev] Parro-DL -- new documentation project
Message-ID: <15047.20356.586507.158341@beowolf.pythonlabs.org>

Announcing a new joint documentation effort...


                                  Parro-DL

                        Parrot Documentation Language


With the public announcement of the development of Parrot (see
http://use.perl.org/article.pl?sid=01/03/31/206248 and
http://www.python.org/parrot.htm), a new documentation effort is being
initiated to provide developer information on the new language and its
libraries.

Guido van Rossum and Larry Wall, joint creators of the new language,
are both aware of the significance of quality documentation in the
adoption of Parrot.  Shortly after the decision to create Parrot, they
enlisted Fred Drake and Tom Christiansen to begin work on the
documentation system for Parrot.  The two advocates of language and
library documentation have collaborated privately for the past six
months to design a new markup language that can be embedded into the
language or used indepentently, similar to POD, but which allows
richer semantic markup similar to the LaTeX-based markup used by the
Python documentation project.

Drake and Christiansen expect to release the reference manual for the
new markup language, call Parro-DL (for "Parrot Documentation
Language") within two weeks.  The specification, which weighs in at
about 150 typeset pages, was written in Parro-DL and is processed by
new tools written using an early prototype interpreter for the Parrot
language.  The specification includes information on syntax,
linguistic integration, and processing expectations.  ISO
standardization is expected to be complete in 3rd quarter of 2006.

Drake and Christiansen are joining their efforts to organize a
documentation project dedicated to producing free documentation for
Parrot to avoid a monopoly on the reference documentation by the
technical publisher O'Reilly.  The effort will be subsidized by their
new joint venture, Iterpolated Documentation Systems.  Offices for the
new firm will be located in Chicago.  Drake's separation from
PythonLabs came as a surprise to his colleagues there.



  -Fred

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




From nas at python.ca  Sun Apr  1 19:51:50 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sun, 1 Apr 2001 10:51:50 -0700
Subject: [Python-Dev] nano-threads?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>; from tim.one@home.com on Sat, Mar 31, 2001 at 11:27:48PM -0500
References: <20010326210824.B17390@glacier.fnational.com> <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>
Message-ID: <20010401105150.A9246@glacier.fnational.com>

Tim Peters wrote:
> Since the postings stopped there, did someone flame you?

No.

> I'm projecting my own situtation onto everyone else, namely
> that this is interesting but I can't make time for it now.

I got that impression.  I'll try to provoke some interest after
2.1 is released.  For now, I'm spending my spare time studying
stackless (among other things).

> If you're still playing with this, though, I hope you do
> continue to let Python-Dev know how it's going!

Okay.

  Neil



From jeremy at alum.mit.edu  Sun Apr  1 21:00:57 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Sun, 1 Apr 2001 15:00:57 -0400 (EDT)
Subject: [Python-Dev] Perl and Python to begin joint development
Message-ID: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>

[FYI:  This press release was also sent to c.l.py.a.  Dan and I expect
to have the release schedule PEP ready soon.  And, yes, that's Parrot
Enhancement Proposal (PEP). --jeremy]

04/01/2001
SEBASTOPOL, CA

Perl and Python to begin joint development

Larry Wall, the creator of Perl, and Guido van Rossum, creator of
Python, today announced that their respective projects are about to
begin a period of joint development. 

According to the language designers, the idea surfaced at last year's
Open Source Convention - "We at the Perl Conference were aware of a need
for a new direction for Perl and for its community, and that's why we
announced the work on Perl 6," said an excited Wall. "At the same time,
Guido was thinking very hard about Python 2.0 and where it was going,
and we got together and started talking about helping each other out."

Initially, the pair planned to have their development communities
working together for mutual benefit. van Rossum cited some of the
technical reasons for the collaboration: "Perl's highly powerful regular
expression engine would be integrated into Python, and would benefit us
greatly; in return, we've got a number of things right that Perl could
gain from, such as signal handling and robust software engineering."

However, as both designers talked about the changes their languages were
going through, they came to the conclusion that they had much to share
at the language level as well as the interpreter level. According to
Larry Wall, "Perl's always been about taking the best features of all
the other languages available; it's perfectly natural for us to
integrate the best features of Python too."

The specifications for the combined language, called Parrot, will be
documented in the forthcoming book "Programming Parrot In A Nutshell",
to be published by O'Reilly and Associates. In the meantime, the Python
Software Foundation is said to be making arrangements to merge with Yet
Another Society. YAS president Kevin Lenzo was delighted at the move:
"It's a natural extension of what YAS was set up to facilitate -
collaboration and communication between programming communities."

Parrot development will begin with the merger of the Py3K development
team with the Perl 6 internals working group; Jeremy Hylton and Dan
Sugalski will be the joint development leads.

Larry Wall and Guido van Rossum both accepted positions at the Vancouver,
Canada development company ActiveState. A spokesman for ActiveState said
that the company was obviously very pleased with the decision, but
denied that ActiveState had influenced it in any way.



From jeremy at alum.mit.edu  Sun Apr  1 21:27:34 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Sun, 1 Apr 2001 15:27:34 -0400 (EDT)
Subject: [Python-Dev] Re: Perl and Python to begin joint development
In-Reply-To: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>
References: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <15047.33062.39302.211557@w221.z064000254.bwi-md.dsl.cnc.net>

It seems that the folks at O'Reilly are working overtime this weekend.
The Parrot book announcement, which I didn't expect to see until
mid-week, is already available at http://www.ora.com.

You can also read an interview with Guido and Larry Wall at
http://www.perl.com.

Barry should be checking in PEP 250 (Parrot Release Schedule) as soon
as he converts it from POD to the PEP format.  

Jeremy



From barry at digicool.com  Mon Apr  2 04:39:40 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Sun, 1 Apr 2001 22:39:40 -0400
Subject: [Python-Dev] Re: Perl and Python to begin joint development
References: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>
	<15047.33062.39302.211557@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <15047.58988.606995.260675@anthem.wooz.org>

>>>>> "JH" == Jeremy Hylton <jeremy at alum.mit.edu> writes:

    JH> Barry should be checking in PEP 250 (Parrot Release Schedule)
    JH> as soon as he converts it from POD to the PEP format.

Sorry, I think that's going to be PEP 0401 instead.

-Barry



From Paul.Moore at uk.origin-it.com  Mon Apr  2 11:09:07 2001
From: Paul.Moore at uk.origin-it.com (Moore, Paul)
Date: Mon, 2 Apr 2001 10:09:07 +0100 
Subject: [Python-Dev] PEP: Use site-packages on all platforms
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADDB@ukrux002.rundc.uk.origin-it.com>

From: Guido van Rossum [mailto:guido at digicool.com]
> 
> I think this is a good idea.  Submit the PEP to Barry!

Done.

> I doubt that we can introduce this into Python 2.1 this late in the
> release cycle.  Would that be a problem?

I thought as much. I can't see it being a major issue. My only concern (as
noted in the PEP) is that with distutils becoming more commonly used, there
will be more and more packages installed using distutils, and so ending up
in the directory which distutils uses by default. The longer it is before
the change is made, the more of a mixed setup people will have. But then
again, (a) the change is backward-compatible, and (b) extension modules will
need recompiling (and reinstalling) anyway. So no, 2.2 seems OK.

Hmm, that does raise one issue - if people rebuild and reinstall after the
change, the reinstall won't overwrite the old version. As a consequence,
there will be an old version on sys.path, with the potential for a crash...
Of course, people should uninstall before reinstalling, so it shouldn't be a
problem. Making distutils search for old versions would be possible, but it
seems like major overkill...

I'll assume this is for 2.2, and that the reinstall-not-overwriting problem
isn't an issue. I'll note the details in the PEP.

Paul.



From thomas.heller at ion-tof.com  Mon Apr  2 19:02:11 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Mon, 2 Apr 2001 19:02:11 +0200
Subject: [Python-Dev] Making types behave like classes
References: <3ABBF553.274D535@ActiveState.com>
Message-ID: <052a01c0bb96$a8b1b180$e000a8c0@thomasnotebook>

> These are some half-baked ideas about getting classes and types to look
> more similar.

Somewhat different thoughts:

Which limitations are there in python as a consequence
of the type/class split?

In python code itself, it is not too bad. Instead of deriving
from builtin types, you can always delegate to them.

In c-code, the situation is worse, on the other hand,
ExtensionClass comes to rescue. Write the base class in C,
subclass in python.

The worst limitation is in the most useful builtin object:
the dictionary. One can use or derive from UserDict,
but one cannot pass UserDict instances or other homegrown dict
lookalikes to exec, you cannot use them as class or instance
dictionaries.

If this limitation would be removed, you could implement your
own rules in namespaces: readonly, case insentitive, whatever.
One could even implement a mapping object in a C extension,
and use it in the aforementioned ways.

IMO this limitation would be easy to remove:
The current PyDict_* API could be implemented in terms of
the PyMapping_ and PyObject_ protocol, using different code
depending on the outcome of an additional PyDict_Check() test.

The performance hit would be rather small.

Thomas




From pf at artcom-gmbh.de  Tue Apr  3 01:19:33 2001
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 3 Apr 2001 01:19:33 +0200 (MEST)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
Message-ID: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de>

At the moment it is very silent on Python-dev.  I guess you guys are
all out hunting dead parrots, which escaped from the cages on April 1st. ;-)

So this might be the right moment to present a possibly bad idea (TM).
see below.
Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen, Germany)

PEP: XXXX
Title: String Scanning
Version: $Revision$
Author: pf at artcom-gmbh.de (Peter Funk)
Status: Not yet Draft
Type: Standards Track
Python-Version: 2.2 
Created: 02-Apr-2001
Post-History:

Abstract

    This document proposes a string scanning feature for Python to
    allow easier string parsing.  The suggested syntax change is to
    allow the use of the division '/' operator for string operands
    as counterpart to the already existing '%' string interpolation
    operator.  In current Python this raises an exception: 'TypeError:
    bad operand type(s) for /'.  With the proposed enhancement the
    expression string1 / format2 should either return a simple value,
    a tuple of values or a dictionary depending on the content of
    the right operand (aka. format) string.


Copyright

    This document is in the public domain.


Specification

    The feature should mimic the behaviour of the scanf function
    well known to C programmers.  For any format string sf and any
    matching input string si the following pseudo condition should 
    be true:

        string.split( sf % (si / sf) ) == string.split( si )

    That is modulo any differences in white space the result of the
    string interpolation using the intermediate result from the string
    scanning operation should look similar to original input string.

    All conversions are introduced by the % (percent sign) character.  
    The format string may also contain other characters.  White space 
    (such as blanks, tabs, or newlines) in the format string match any  
    amount of white space, including none, in the input.  Everything
    else matches only itself.  Scanning stops when an input character  
    does not match such a format character.  Scanning also stops when 
    an input conversion cannot be made (see below).


Examples

    Here is an example of an interactive session exhibiting the
    expected behaviour of this feature.

        >>> "12345 John Doe" / "%5d %8s"
        (12345, 'John Doe')
        >>> "12 34 56 7.890" / "%d %d %d %f"
        (12, 34, 56, 7.8899999999999997)
        >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
        {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
        >>> "1 2" / "%d %d %d"
        Traceback (innermost last):
          File "<stdin>", line 1, in ?
        TypeError: not all arguments filled


Discussion

    This should fix the assymetry between arithmetic types and strings.
    It should also make the life easier for C programmers migrating to
    Python (see FAQ 4.33).  Those poor souls are acustomed to scanf
    as the counterpart of printf and usually feel uneasy to convert
    to string slitting, slicing or the syntax of regular expressions.


Security Issues

    There should be no security issues.


Implementation

    There is no implementation yet.  This is just an idea.
   


Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:




From guido at digicool.com  Tue Apr  3 03:43:24 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 02 Apr 2001 20:43:24 -0500
Subject: [Python-Dev] Python9 footage on www.technetcast.com
Message-ID: <200104030143.UAA04839@cj20424-a.reston1.va.home.com>

Dr. Dobb's technetcast is playing audio and video footage from
Python9: video of a brief interview with me, and (coming up next?)
audio from the two keynotes (Bruce Eckel's and mine).  Go to

    www.technetcast.com

(RealAudio support required, I believe.)

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



From guido at digicool.com  Tue Apr  3 03:51:06 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 02 Apr 2001 20:51:06 -0500
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: Your message of "Tue, 03 Apr 2001 01:19:33 +0200."
             <m14kDbi-000CnFC@artcom0.artcom-gmbh.de> 
References: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de> 
Message-ID: <200104030151.UAA04918@cj20424-a.reston1.va.home.com>

Peter, if you can do a prototype implementation (in Python would be
best), the idea might be received better.

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



From paulp at ActiveState.com  Tue Apr  3 03:06:49 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Mon, 02 Apr 2001 18:06:49 -0700
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
References: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <3AC92229.A5566E6A@ActiveState.com>

Peter Funk wrote:
> 
> 
>         >>> "12345 John Doe" / "%5d %8s"
>         (12345, 'John Doe')
>         >>> "12 34 56 7.890" / "%d %d %d %f"
>         (12, 34, 56, 7.8899999999999997)
>         >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
>         {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
>         >>> "1 2" / "%d %d %d"
>         Traceback (innermost last):
>           File "<stdin>", line 1, in ?
>         TypeError: not all arguments filled

I would prefer "foo".scanf("%5d %8s") or maybe "parse" or "parseformats"
or something like that. I know that punctuation abuse leads inexorably
to further punctuation abuse but the cycle must stop somewhere. It's too
late for "%" but let's save "/" while we still can!
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From thomas at xs4all.net  Tue Apr  3 09:09:28 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Tue, 3 Apr 2001 09:09:28 +0200
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <3AC92229.A5566E6A@ActiveState.com>; from paulp@ActiveState.com on Mon, Apr 02, 2001 at 06:06:49PM -0700
References: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de> <3AC92229.A5566E6A@ActiveState.com>
Message-ID: <20010403090928.A2820@xs4all.nl>

On Mon, Apr 02, 2001 at 06:06:49PM -0700, Paul Prescod wrote:
> Peter Funk wrote:

> >         >>> "12345 John Doe" / "%5d %8s"
> >         (12345, 'John Doe')
> >         >>> "12 34 56 7.890" / "%d %d %d %f"
> >         (12, 34, 56, 7.8899999999999997)
> >         >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
> >         {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
> >         >>> "1 2" / "%d %d %d"
> >         Traceback (innermost last):
> >           File "<stdin>", line 1, in ?
> >         TypeError: not all arguments filled

> I would prefer "foo".scanf("%5d %8s") or maybe "parse" or "parseformats"
> or something like that. I know that punctuation abuse leads inexorably
> to further punctuation abuse but the cycle must stop somewhere. It's too
> late for "%" but let's save "/" while we still can!

Agreed, on both issues. We don't have 'printf', lets not use something as
inexplicable as 'scanf'!

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From pf at artcom-gmbh.de  Tue Apr  3 10:35:02 2001
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 3 Apr 2001 10:35:02 +0200 (MEST)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <200104030151.UAA04918@cj20424-a.reston1.va.home.com> from Guido van Rossum at "Apr 2, 2001  8:51: 6 pm"
Message-ID: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>

Guido van Rossum:
> Peter, if you can do a prototype implementation (in Python would be
> best), the idea might be received better.

I believe a strawman derived from the UserString class could be done
in pure Python.  But I'm sorry: I've no time for this during April.

I'm also not sure, whether this is really a worthwile effort and whether
I should champion this idea further.  From Pauls response I got the
impression that people already consider the '%' string interpolation
operator as a language wart rather than an elegant feature.

I however often like the infix notation better.  
That may be a matter of taste.  Imagine we would have to write:
	"%5d %20s %s\n".printf((num, name, adr))
instead of
	"%5d %20s %s\n" % (num, name, adr)
I'm happy, that this is not the case in todays Python.

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen, Germany)




From guido at digicool.com  Tue Apr  3 14:12:50 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 03 Apr 2001 07:12:50 -0500
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: Your message of "Tue, 03 Apr 2001 10:35:02 +0200."
             <m14kMHG-000CnFC@artcom0.artcom-gmbh.de> 
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de> 
Message-ID: <200104031212.HAA06304@cj20424-a.reston1.va.home.com>

> > Peter, if you can do a prototype implementation (in Python would be
> > best), the idea might be received better.
> 
> I believe a strawman derived from the UserString class could be done
> in pure Python.  But I'm sorry: I've no time for this during April.

Oh well, maybe someone else will like the idea.

> I'm also not sure, whether this is really a worthwile effort and whether
> I should champion this idea further.  From Pauls response I got the
> impression that people already consider the '%' string interpolation
> operator as a language wart rather than an elegant feature.

Well, that was one response.  Besides, it's easy to factor out two
separate design decisions: (1) a string scanning mechanism that takes
two strings (a format and an input string) and returns one or more
values extracted from the input string according to the rules set by
the format string, and (2) how to spell this: scanf(format, input) or
format/input or input/format or whatever.

> I however often like the infix notation better.  

See my two examples above for a concern: already I cannot recall
whether your PEP proposes format/input or input/format.  That's a bad
sign for either spelling. :-)

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



From pf at artcom-gmbh.de  Tue Apr  3 13:44:00 2001
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 3 Apr 2001 13:44:00 +0200 (MEST)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <200104031212.HAA06304@cj20424-a.reston1.va.home.com> from Guido van Rossum at "Apr 3, 2001  7:12:50 am"
Message-ID: <m14kPE8-000CnFC@artcom0.artcom-gmbh.de>

Guido van Rossum:
[...]
> Well, that was one response.  Besides, it's easy to factor out two
> separate design decisions: (1) a string scanning mechanism that takes
> two strings (a format and an input string) and returns one or more
> values extracted from the input string according to the rules set by
> the format string, and (2) how to spell this: scanf(format, input) or
> format/input or input/format or whatever.
> 
> > I however often like the infix notation better.  
> 
> See my two examples above for a concern: already I cannot recall
> whether your PEP proposes format/input or input/format.  That's a bad
> sign for either spelling. :-)

Hmmm.... May be I've stressed the analogy to arithmetic a bit to far:

If the string interpolation operator were '*' instead of '%'
then you could think of "multiplying" a format string with one
or more values gives a result string which than represents some kind of
"product".  Taking this result string now as input to the scanning
operation is some kind of "division" reverting the previous string
interpolation operation.  From that POV it would be pretty obvious,
that "dividing" the input string by the format string as denominator
returns the values previously formatted into it.

But since the string interpolation operator is '%' the analogy from
multiplication to formatting is obviously not at all that obvious.  :-(

Regards, Peter




From michel at digicool.com  Tue Apr  3 19:54:24 2001
From: michel at digicool.com (Michel Pelletier)
Date: Tue, 3 Apr 2001 10:54:24 -0700 (PDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.LNX.4.32.0104031052400.11179-100000@localhost.localdomain>

On Tue, 3 Apr 2001, Peter Funk wrote:

> I'm also not sure, whether this is really a worthwile effort and whether
> I should champion this idea further.  From Pauls response I got the
> impression that people already consider the '%' string interpolation
> operator as a language wart rather than an elegant feature.

It is one seriously useful wart!

> I however often like the infix notation better.
> That may be a matter of taste.  Imagine we would have to write:
> 	"%5d %20s %s\n".printf((num, name, adr))
> instead of
> 	"%5d %20s %s\n" % (num, name, adr)
> I'm happy, that this is not the case in todays Python.

Agreed.  I like your proposal.

-Michel




From paul at pfdubois.com  Wed Apr  4 01:22:32 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Tue, 3 Apr 2001 16:22:32 -0700
Subject: [Python-Dev] Re: s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <E14kTFV-0001wa-00@mail.python.org>
Message-ID: <ADEOIFHFONCLEEPKCACCMEKACHAA.paul@pfdubois.com>

Well, as usual I have a complete lack of aesthetic judgment because *I*
thought it was a great idea.

I could just picture my scientists parsing input lines from data files with
it. A similar feature in Basis is heavily used.

Then again, I *love* s % f. See, I'm totally sick.




From paulp at ActiveState.com  Wed Apr  4 01:45:54 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Tue, 03 Apr 2001 16:45:54 -0700
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <3ACA60B2.6B09B36D@ActiveState.com>

Peter Funk wrote:
> 
> ...
> 
> I however often like the infix notation better.
> That may be a matter of taste.  Imagine we would have to write:
>         "%5d %20s %s\n".printf((num, name, adr))
> instead of
>         "%5d %20s %s\n" % (num, name, adr)
> I'm happy, that this is not the case in todays Python.

Either way it is infix (as opposed to prefix or postfix). The question
is whether it is an infix *operator* or a method.

I believe that the only thing aesthetically wrong with this:

"%5d %20s %s\n".insert(num, name, adr)

is that people are not "used" to seeing method invocations on literal
strings. But then new Python programmers are not used to seeing people
divide or mod strings either!

And the nice thing about using a method name is that you can look method
names up in the indexes of books easily and even guess the meaning of
them from their English meanings. Symbols are (IMHO) best reserved for
usages where their meanings are already set by real-world convention.
(i.e. 5+3!)

If some other language convinces millions of programmers that string
division is natural then we could follow suit but I'd rather not lead
the way.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From tim.one at home.com  Wed Apr  4 02:05:50 2001
From: tim.one at home.com (Tim Peters)
Date: Tue, 3 Apr 2001 20:05:50 -0400
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>

[Peter Funk]
> I believe a strawman derived from the UserString class could be done
> in pure Python.  But I'm sorry: I've no time for this during April.

sscanf for Python gets reinvented like clockwork; e.g., see

ftp://ftp.python.org/pub/python/
    contrib-09-Dec-1999/Misc/sscanfmodule.README

for 1995's version of this crusade.

> I'm also not sure, whether this is really a worthwile effort and
> whether I should champion this idea further.  From Pauls response I
> got the impression that people already consider the '%' string
> interpolation operator as a language wart rather than an elegant
> feature.

Not me!  Infix "%" is great.  But while "%" was mnemonic for the heavy use of
"%" in format strings, "/" doesn't say anything to me.  Combine that with the
relative infrequency of sscanf vs sprintf calls (in C code, Perl code, or (I
sure suspect) in Python code too), and I'm -1 on infix "/" for sscanf.

Making it a method of the format string would be fine (why the format string?
because capturing a bound method object like

    parse3d = "%d %d %d".whatever

would be darned useful, but the other way wouldn't be).

Finally, since .scanf() is a rotten method name (like .join() before it, it
doesn't make clear which operand is scanned and which format), try something
like format.scanning(string) instead.

language-design-is-easy<wink>-ly y'rs  - tim




From jeremy at alum.mit.edu  Wed Apr  4 03:17:42 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue, 3 Apr 2001 21:17:42 -0400 (EDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
	<LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
Message-ID: <15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "TP" == Tim Peters <tim.one at home.com> writes:

  TP> Making it a method of the format string would be fine (why the
  TP> format string?  because capturing a bound method object like

  TP>     parse3d = "%d %d %d".whatever

  TP> would be darned useful, but the other way wouldn't be).

  TP> Finally, since .scanf() is a rotten method name (like .join()
  TP> before it, it doesn't make clear which operand is scanned and
  TP> which format), try something like format.scanning(string)
  TP> instead.

My preference would be to have a separate module with the necessary
support.  It sure would be easy to add to the language.

I imagine something like this:

import fileinput
import scanf

fmt = scanf.Format("%d %d %d")
for line in fileinput.intput():
    mo = fmt.scan(line)
    if mo:
        print mo.group(1, 2, 3)

Jeremy



From skip at pobox.com  Wed Apr  4 03:19:50 2001
From: skip at pobox.com (Skip Montanaro)
Date: Tue, 3 Apr 2001 20:19:50 -0500 (CDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
	<LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
Message-ID: <15050.30390.69707.3375@beluga.mojam.com>

    Tim> Finally, since .scanf() is a rotten method name (like .join()
    Tim> before it, it doesn't make clear which operand is scanned and which
    Tim> format), try something like format.scanning(string) instead.

Hmmm... If method names are the way to go, I'd much rather we found a more
active verb name than "scanning".  How about "extract" or "slice"?  Even
simply "scan" sounds better to me.

Back to the infix operator idea, I agree with Peter on the one hand that
there's a certain symmetry to using infix "/" and with the opposing camp
that the only reason "%" works for emitting strings is the use of C's %
format character.  "*" sort of suggests exploding... ;-)

Skip






From skip at pobox.com  Wed Apr  4 03:22:10 2001
From: skip at pobox.com (Skip Montanaro)
Date: Tue, 3 Apr 2001 20:22:10 -0500 (CDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
	<LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
	<15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <15050.30530.466650.219047@beluga.mojam.com>

    Jeremy> I imagine something like this:

    Jeremy> import fileinput
    Jeremy> import scanf

    ...

Placing the functionality in a module is fine as well, but again, "scanf"
only means something if you've programmed in C before.  I suspect there are
college students graduating from CS departments now who have used C++ but
not C and wouldn't have the slightest idea what "scanf" means.

Skip



From jeremy at alum.mit.edu  Wed Apr  4 03:39:28 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue, 3 Apr 2001 21:39:28 -0400 (EDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <15050.30530.466650.219047@beluga.mojam.com>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
	<LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
	<15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>
	<15050.30530.466650.219047@beluga.mojam.com>
Message-ID: <15050.31568.301926.504672@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "SM" == Skip Montanaro <skip at pobox.com> writes:

  Jeremy> I imagine something like this:

  Jeremy> import fileinput import scanf

  SM>     ...

  SM> Placing the functionality in a module is fine as well, but
  SM> again, "scanf" only means something if you've programmed in C
  SM> before.  I suspect there are college students graduating from CS
  SM> departments now who have used C++ but not C and wouldn't have
  SM> the slightest idea what "scanf" means.

I don't care much about the name.  scanf is fine with me ("scan with
format") but so is "scan" -- or "parrot."

I do care about it being based on a module rather than a builtin
operator or a string method.  I see scanf-based scanning as roughly
equivalent to regular expressions, which live happily in a module.

If we're going to add a scan method to strings, I can imagine people
wanting "\d+".re_match() and "\d+".re_search() methods on strings,
too. 

Jeremy



From Jason.Tishler at dothill.com  Wed Apr  4 16:20:11 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Wed, 4 Apr 2001 10:20:11 -0400
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
Message-ID: <20010404102011.L63@dothill.com>

Recently significant pthreads support has been added to Cygwin.  When I
attempted to build a Cygwin Python with threads, I got the following
compilation error:

    gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Python/pythonrun.o Python/pythonrun.c
    In file included from /usr/include/signal.h:8,
                     from Python/pythonrun.c:21:
    /usr/include/sys/signal.h:162: parse error before `thread'

Cygwin's sys/signal has the following at line 162:

    #if defined(_POSIX_THREADS)
    int _EXFUN(pthread_kill, (pthread_t thread, int sig));
    #endif

The author of the recent Cygwin pthreads enhancements states that
_POSIX_THREADS is a kernel level #define and should not be defined in
user level code.  Please see the following for his reasoning:

    http://sources.redhat.com/ml/cygwin/2001-03/msg01693.html

Unfortunately, I am not knowledgeable is this area.  Can someone please
confirm or refute the above claim?

If it is concluded that Python should not #define _POSIX_THREADS, then I
am willing to generate a patch to substitute _POSIX_THREADS with a more
benign symbol in the less than 20 occurrences that my grep-ing found.
Any suggestions on what to call this new symbol?

Will such a patch be considered this late in the release cycle?  Or,
should I hold off until after 2.1 final?  If the patch is accepted into
2.1, then users can get a Cygwin Python with thread support without
having to wait for 2.2 or working off of CVS.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From Jason.Tishler at dothill.com  Wed Apr  4 19:34:46 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Wed, 4 Apr 2001 13:34:46 -0400
Subject: [Python-Dev] Re: Case-sensitive import
In-Reply-To: <20010228151728.Q449@dothill.com>; from Jason.Tishler@dothill.com on Wed, Feb 28, 2001 at 03:17:28PM -0500
References: <20010228120229.M449@dothill.com> <LNBBLJKPBEHFEDALKOLCMELLJCAA.tim.one@home.com> <20010228151728.Q449@dothill.com>
Message-ID: <20010404133446.T63@dothill.com>

Tim,

On Wed, Feb 28, 2001 at 03:17:28PM -0500, Jason Tishler wrote:
> On Wed, Feb 28, 2001 at 12:36:45PM -0500, Tim Peters wrote:
> > Jason, about this:
> > 
> >     However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will
> >     require one to configure with:
> > 
> >         CC='gcc -mwin32' configure ...
> > 
> > How can we make that info *useful* to people?
> 
> I have posted to the Cygwin mailing list and C.L.P regarding my original
> 2.0 patches.  I have also continue to post to Cygwin regarding 2.1a1 and
> 2.1a2.  I intended to do likewise for 2.1b1, etc.
> 
> > The target audience for the
> > Cygwin port probably doesn't search Python-Dev or the Python patches
> > database.
> 
> Agreed -- the above was only offered to the curious Python-Dev person
> and not for archival purposes.
> 
> > So it would be good if you thought about uploading an
> > informational patch to README and Misc/NEWS briefly telling Cygwin folks
> > what they need to know.  If you do, I'll look for it and check it in.
> 
> I will submit a patch to README to add a Cygwin section to "Platform
> specific notes".  Unfortunately, I don't think that I can squeeze it in
> by 2.1b1.  If not, then I will submit it for the next release (2.1b2 or 2.1
> final).  I also don't mind waiting for the Cygwin gcc stuff to settle
> down too.  I know...excuses, excuses...

As promised:

    http://sourceforge.net/tracker/index.php?func=detail&aid=413750&group_id=5470&atid=305470

Note that the following goofiness:

    CC='gcc -mwin32' configure ...

is no longer needed.

Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From m.favas at per.dem.csiro.au  Wed Apr  4 21:19:44 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Thu, 05 Apr 2001 03:19:44 +0800
Subject: [Python-Dev] Little hits add up...
Message-ID: <3ACB73D0.DD94C59F@per.dem.csiro.au>

Since it's a quiet time on python-dev at the moment <grin>, I thought
I'd just toss this bedraggled parrot in...
Every now and then, the comment arises "this <enhancement X> should only
incur a small performance hit". I just ran one of my apps under 1.5.2+
and 2.1b2. The little hits along the way have here added up to a 26%
slowdown. Around the time 2.0 was released, there was a brief thread
along the lines of "let's get 2.0 out the door, and tune it up in 2.1 -
there's some low-hanging fruit about". Any chance we could get someone
like Christian and Tim wound up on looking at performance issues,
however briefly <wink>? (I know, they don't have time - I just
remembered the old days on c.l.py when they'd try to outdo each other
with weird and wonderful optimizations.) This is not a flame at 2.x, BTW
- 2.x is a good thing! (BTW, gc.disable() improved things by 3%.)
-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From nas at python.ca  Wed Apr  4 21:34:15 2001
From: nas at python.ca (Neil Schemenauer)
Date: Wed, 4 Apr 2001 12:34:15 -0700
Subject: [Python-Dev] Little hits add up...
In-Reply-To: <3ACB73D0.DD94C59F@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Thu, Apr 05, 2001 at 03:19:44AM +0800
References: <3ACB73D0.DD94C59F@per.dem.csiro.au>
Message-ID: <20010404123415.A15008@glacier.fnational.com>

Mark Favas wrote:
>(BTW, gc.disable() improved things by 3%.)

I am extremely happy that number is so small. :-)

  Neil



From nas at python.ca  Wed Apr  4 22:56:17 2001
From: nas at python.ca (Neil Schemenauer)
Date: Wed, 4 Apr 2001 13:56:17 -0700
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: <E14ks3t-0001ut-00@usw-sf-web3.sourceforge.net>; from noreply@sourceforge.net on Wed, Apr 04, 2001 at 11:31:21AM -0700
References: <E14ks3t-0001ut-00@usw-sf-web3.sourceforge.net>
Message-ID: <20010404135617.B15146@glacier.fnational.com>

Tim writes:
> Assigned to me; deleted patch 4958 (Jason, whenever you try 
> to change something, it generally won't work unless you add 
> a comment at the same time -- don't know whether that's 
> what actually happened to you, but that's my best guess).

Jason Tishler writes:
> I *did add a comment!  I always do!
> 
> I'm using Netscape again, may be I should only use IE
> whenever I submit SF patches.  Sigh...

Is it a browser issue or is it that only people on the project
can delete things?

  Neil



From tim.one at home.com  Wed Apr  4 23:28:58 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 4 Apr 2001 17:28:58 -0400
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: <20010404135617.B15146@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>

[Neil Schemenauer]
> Is it a browser issue or is it that only people on the project
> can delete things?

I don't know.  Another possibility to consider is that perhaps only project
Admins can delete things (which I am, but Jason isn't -- can you delete
things, Neil?).




From nas at python.ca  Thu Apr  5 00:28:37 2001
From: nas at python.ca (Neil Schemenauer)
Date: Wed, 4 Apr 2001 15:28:37 -0700
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>; from tim.one@home.com on Wed, Apr 04, 2001 at 05:28:58PM -0400
References: <20010404135617.B15146@glacier.fnational.com> <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>
Message-ID: <20010404152837.A15443@glacier.fnational.com>

Tim Peters wrote:
> [Neil Schemenauer]
> > Is it a browser issue or is it that only people on the project
> > can delete things?
> 
> I don't know.  Another possibility to consider is that perhaps only project
> Admins can delete things (which I am, but Jason isn't -- can you delete
> things, Neil?).

With Netscape Communicator 4.76 on Linux I can attach a file
without entering a comment.  I can also delete a file without
entering a comment.  This works when using a Squid 2.2.5 proxy
and when using a direct connection.

  Neil



From tim.one at home.com  Thu Apr  5 02:44:17 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 4 Apr 2001 20:44:17 -0400
Subject: [Python-Dev] Little hits add up...
In-Reply-To: <3ACB73D0.DD94C59F@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEENJKAA.tim.one@home.com>

[Mark Favas]
> Since it's a quiet time on python-dev at the moment <grin>, I thought
> I'd just toss this bedraggled parrot in...
> Every now and then, the comment arises "this <enhancement X> should only
> incur a small performance hit". I just ran one of my apps under 1.5.2+
> and 2.1b2. The little hits along the way have here added up to a 26%
> slowdown.

How do you know it is in fact "the little bits" and not one specific bit?
For example, I recall that line-at-a-time input was dozens of times slower
(relatively speaking) on your box than on anyone else's box.  Not enough info
here, and especially not when you say (emphasis added) "I just ran ONE of my
apps ...".  Perhaps that app does something unique?  Or perhaps that app does
something common that's uniquely slow on your box?  Or ...

> Around the time 2.0 was released, there was a brief thread along the
> lines of "let's get 2.0 out the door, and tune it up in 2.1 - there's
> some low-hanging fruit about".

Heh heh.  I remember that too.  Good followup <wink>.

> Any chance we could get someone like Christian and Tim wound up on
> looking at performance issues, however briefly <wink>? (I know, they
> don't have time -

No chance for Tim.  I have no spare work time or spare spare time left.  And
AFAIK, PythonLabs has no plans to do any performance tuning.  If you identify
a specific new choke point, though, then repairing it should be a focused
low-effort job.  I doubt you're seeing an accumulation of small slowdowns
adding to 26% anyway -- there's really nothing we've done that should have an
ubiquitous effect other than adding cyclic gc (but you said later that gc
only accounted for 3% in your app).

Hmm.  One other:  the new comparison code is both very complex and very
cleanly written.  As a result, I've worn my finger numb stepping through it
in a debugger:  if your app is doing oodles of comparisions, I wouldn't be
surprised to see it losing 20% to layers and layers of function calls trying
to figure out *how* to compare things.

> I just remembered the old days on c.l.py when they'd try to outdo each
> other with weird and wonderful optimizations.)

Recall that none of those got into the distribution, though.  Guido doesn't
like weird and wonderful optimizations in the Python source code.  And,
indeed, many of those eventually succumbed to the *obvious* ways to write
them in C (e.g., converting an MD5 digest to a string of hex digits -- 2.0
added an md5.hex_digest() method to solve that directly, and
binascii.hexlify() for the general case).

> This is not a flame at 2.x, BTW - 2.x is a good thing!

You're not fooling me, Mark.  I've known from the start that this is just
another thinly veiled attack on 2.1's __future__ statement <wink>.

first-find-out-where-it's-slower-ly y'rs  - tim




From tim.one at home.com  Thu Apr  5 08:23:26 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 5 Apr 2001 02:23:26 -0400
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <20010404102011.L63@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>

[Jason Tishler, passing on someone's objection to Python #define'ing
 _POSIX_THREADS sometimes]

Right or wrong, it's too late to change this for 2.1 (IMO).  Thread support
across platforms is very touchy, because so poorly standardized and
implemented across vendors, and fiddling with *any* of that support code is
very dangerous.  Can you swear that Python never #define'ing _POSIX_THREADS
on its own won't break threading on some other platform?  If not, changing it
needs *lots* of lead time for x-platform testing.

> ...
> The author of the recent Cygwin pthreads enhancements states that
> _POSIX_THREADS is a kernel level #define and should not be defined in
> user level code.  Please see the following for his reasoning:
>
>     http://sources.redhat.com/ml/cygwin/2001-03/msg01693.html
>
> Unfortunately, I am not knowledgeable is this area.  Can someone please
> confirm or refute the above claim?

At heart, the claim was based on little more than "I said so", as far as I
could see.  What does the POSIX pthreads standard say?  I haven't had an
employer willing to buy me a copy of that (expensive) document since 1992, so
I can't say (and POSIX stds are not available for online browsing).

He's certainly right that _POSIX_THREADS "is _NOT_ a userland symbol".  *All*
identifiers beginning with an underscore and followed by another underscore
or an uppercase letter are reserved names in std C, for use by the
implementation (incl. system libraries).  But lots of stuff violates that
rule, so I'm afraid it's not a killer argument in practice (although it's a
*good* argument!).

BTW, it's safe to remove this from thread.c:

#ifdef __ksr__
#define _POSIX_THREADS
#endif

I probably put that in around '93, but there are no more KSR machines
anymore -- that I know of.  I won't even make that change for 2.1 at this
late stage.

for-all-i-know-mac-os-x-#defines-__ksr__-ly y'rs  - tim




From fredrik at pythonware.com  Thu Apr  5 09:37:01 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 5 Apr 2001 09:37:01 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
References: <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>
Message-ID: <015201c0bda3$368aaa30$e46940d5@hagrid>

tim wrote:
> At heart, the claim was based on little more than "I said so", as far as I
> could see.  What does the POSIX pthreads standard say?

the SUSv2 spec says:

    "On XSI-conformant systems, _POSIX_THREADS,
    _POSIX_THREAD_ATTR_STACKADDR, _POSIX_THREAD_ATTR_STACKSIZE
    and _POSIX_THREAD_PROCESS_SHARED are always defined"

which doesn't say much about what the POSIX standard says,
of course...

fwiw, regarding the pthread.h file, it also says:

    "An interpretation request has been filed with IEEE PASC
    concerning requirements for visibility of symbols in this
    header"

which implies that the specification doesn't always "say so" ;-)

Cheers /F




From m.favas at per.dem.csiro.au  Thu Apr  5 12:42:03 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Thu, 05 Apr 2001 18:42:03 +0800
Subject: [Python-Dev] Late enhancements breaks termios build
Message-ID: <3ACC4BFB.7143EF4D@per.dem.csiro.au>

In the past day or so, extra functionaility has been added to the CVS
version of the termios module. This breaks the compilation of termios.c
on Tru64 Unix, as a number of the new constants collide with macros of
the same name defined in /usr/include/sys/ioctl.h - so the #ifdef
NEW_THING succeeds, but with incompatible values from ioctl.h, rather
than compatible values from termios.h. I thought we were at the "fix
bugs" stage, rather than the "it'd be nice to add this" <wink>. Yes,
I'll file a bug report - sorry for the interruption.

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From fdrake at acm.org  Thu Apr  5 13:11:01 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 5 Apr 2001 07:11:01 -0400 (EDT)
Subject: [Python-Dev] Late enhancements breaks termios build
In-Reply-To: <3ACC4BFB.7143EF4D@per.dem.csiro.au>
References: <3ACC4BFB.7143EF4D@per.dem.csiro.au>
Message-ID: <15052.21189.904560.185718@cj42289-a.reston1.va.home.com>

Mark Favas writes:
 > than compatible values from termios.h. I thought we were at the "fix
 > bugs" stage, rather than the "it'd be nice to add this" <wink>. Yes,
 > I'll file a bug report - sorry for the interruption.

  Gosh, it sounded like a bug to me.  Can you tell me which file on
Tru64 defines the right constants?
  Please assign the bug report to me -- it's my mess.  Sorry!  ;-(


  -Fred

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




From thomas at xs4all.net  Thu Apr  5 19:53:39 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 5 Apr 2001 19:53:39 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>; from tim.one@home.com on Thu, Apr 05, 2001 at 02:23:26AM -0400
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>
Message-ID: <20010405195338.C2820@xs4all.nl>

On Thu, Apr 05, 2001 at 02:23:26AM -0400, Tim Peters wrote:

> [Jason Tishler, passing on someone's objection to Python #define'ing
>  _POSIX_THREADS sometimes]

> Right or wrong, it's too late to change this for 2.1 (IMO).  Thread support
> across platforms is very touchy, because so poorly standardized and
> implemented across vendors, and fiddling with *any* of that support code is
> very dangerous.  Can you swear that Python never #define'ing _POSIX_THREADS
> on its own won't break threading on some other platform?  If not, changing it
> needs *lots* of lead time for x-platform testing.

We could define _POSIX_THREADS only if it isn't already defined. Or better
yet, defined PY_POSIX_THREADS, have the Python source itself just trigger
off of that, and #define _POSIX_THREADS somewhere in pyport.h,
PY_POSIX_THREADS is defined and _POSIX_THREADS is not.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From Jason.Tishler at dothill.com  Thu Apr  5 20:40:59 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Thu, 5 Apr 2001 14:40:59 -0400
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <20010405195338.C2820@xs4all.nl>; from thomas@xs4all.net on Thu, Apr 05, 2001 at 07:53:39PM +0200
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com> <20010405195338.C2820@xs4all.nl>
Message-ID: <20010405144059.C402@dothill.com>

Thomas,

On Thu, Apr 05, 2001 at 07:53:39PM +0200, Thomas Wouters wrote:
> On Thu, Apr 05, 2001 at 02:23:26AM -0400, Tim Peters wrote:
> > [Jason Tishler, passing on someone's objection to Python #define'ing
> >  _POSIX_THREADS sometimes]
> >
> > Right or wrong, it's too late to change this for 2.1 (IMO).  Thread support
> > across platforms is very touchy, because so poorly standardized and
> > implemented across vendors, and fiddling with *any* of that support code is
> > very dangerous.  Can you swear that Python never #define'ing _POSIX_THREADS
> > on its own won't break threading on some other platform?  If not, changing
> > it needs *lots* of lead time for x-platform testing.
> 
> We could define _POSIX_THREADS only if it isn't already defined. Or better
> yet, defined PY_POSIX_THREADS, have the Python source itself just trigger
> off of that, and #define _POSIX_THREADS somewhere in pyport.h,
> PY_POSIX_THREADS is defined and _POSIX_THREADS is not.

I was thinking of something like the above, but not with as much
understanding as you already have.  Would you be willing to submit such
a patch for consideration *after* 2.1 final?

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From guido at digicool.com  Fri Apr  6 00:06:22 2001
From: guido at digicool.com (Guido van Rossum)
Date: Thu, 05 Apr 2001 17:06:22 -0500
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: Your message of "Wed, 04 Apr 2001 15:28:37 MST."
             <20010404152837.A15443@glacier.fnational.com> 
References: <20010404135617.B15146@glacier.fnational.com> <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>  
            <20010404152837.A15443@glacier.fnational.com> 
Message-ID: <200104052206.RAA11393@cj20424-a.reston1.va.home.com>

> Tim Peters wrote:
> > [Neil Schemenauer]
> > > Is it a browser issue or is it that only people on the project
> > > can delete things?
> > 
> > I don't know.  Another possibility to consider is that perhaps only project
> > Admins can delete things (which I am, but Jason isn't -- can you delete
> > things, Neil?).
> 
> With Netscape Communicator 4.76 on Linux I can attach a file
> without entering a comment.  I can also delete a file without
> entering a comment.  This works when using a Squid 2.2.5 proxy
> and when using a direct connection.
> 
>   Neil

There's a tiny checkbox next to the file upload entry box.  If you
don't check the checkbox, the upload is ignored.  (God knows why they
added this feature -- it's not like it's easy to upload a file by
mistake. :-)

Could it be that those users who complain they can't upload didn't
check the box?

Other random theories: maybe it works differently when not logged in?
Certainly you can't delete a file when you're not logged in.

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




From thomas at xs4all.net  Thu Apr  5 23:27:12 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 5 Apr 2001 23:27:12 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <20010405144059.C402@dothill.com>; from Jason.Tishler@dothill.com on Thu, Apr 05, 2001 at 02:40:59PM -0400
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com> <20010405195338.C2820@xs4all.nl> <20010405144059.C402@dothill.com>
Message-ID: <20010405232712.D2820@xs4all.nl>

On Thu, Apr 05, 2001 at 02:40:59PM -0400, Jason Tishler wrote:

> > We could define _POSIX_THREADS only if it isn't already defined. Or better
> > yet, defined PY_POSIX_THREADS, have the Python source itself just trigger
> > off of that, and #define _POSIX_THREADS somewhere in pyport.h,
> > PY_POSIX_THREADS is defined and _POSIX_THREADS is not.

> I was thinking of something like the above, but not with as much
> understanding as you already have.  Would you be willing to submit such
> a patch for consideration *after* 2.1 final?

Actually, I think the above should go in *before* 2.1 final. It won't break
anything new, and it fixes some warnings and possible some problems.
Because:

- if _POSIX_THREADS is not already defined, nothing changes
- if _POSIX_THREADS is already defined, to the same value as we are defining
  it to, nothing changes
- if _POSIX_THREADS is already defined, but to a different value than Python
  wants to define it to, it used to break and starts working now. There is
  nothing that depends on the actual value of _POSIX_THREADS in Python right
  now (because it doesn't *have* a value.)

Unfortunately, I lack the time to write the patch and test it. I'm busy
moving, redecorating the house I'm half moved into, lack any kind of
connectivity at home (*@#$&*! cable and DSL companies), and have several
projects at work that *need* my 80h/week attention (each one) the next few
of months at least. Python (and Mailman, btw, Barry) are *slightly* on the
back burner right now.

But if someone does write a patch, I can make the time to test it on the
BSDI and FreeBSD machines I have (asside from the Linux machines everyone
and their dog has, nowadays :)

Jetlagged-at-Apachecon-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From claird at starbase.neosoft.com  Fri Apr  6 00:36:46 2001
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Thu, 5 Apr 2001 17:36:46 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
Message-ID: <200104052236.RAA52963@starbase.neosoft.com>

Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).

Successful installation requires
  ./configure --with-cxx=gcc
  sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
  mv /tmp/Makefile Makefile

The result of a plain configure is
  loading cache ./config.cache
  checking MACHDEP... osf1V4
  checking for --without-gcc...
  checking for --with-cxx=<compiler>... no
  checking for c++... c++
  checking whether the C++ compiler (c++  ) works... no
  configure: error: installation or configuration problem: C++ compiler cannot create executables.       

If I leave the Makefile unaltered, I see
  gcc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Modules/ccpython.o ./
  Modules/ccpython.cc
  gcc: 1500: No such file or directory
  cc1plus: Invalid option `-Olimit'
  make: *** [Modules/ccpython.o] Error 1 

Yes, there's probably a way to configure this in one line.
I think this is a better explanation, for now.

Do I need to figure out the correct patch to configure.in,
or is there a specialist who takes responsibility for that?



From claird at starbase.neosoft.com  Fri Apr  6 00:51:13 2001
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Thu, 5 Apr 2001 17:51:13 -0500 (CDT)
Subject: [Python-Dev] A kind of configuration question
Message-ID: <200104052251.RAA53506@starbase.neosoft.com>

Why's there no Win* executable pydoc?

Let me know if I should ask this elsewhere.  In part,
I think I'm searching for larger generalizations that
I'm particularizing with this specific instance.

A Unix-side installation-from-source provides, along
with much else, an executable /usr/local/bin/pydoc,
whose content is simply
  #!/usr/bin/env python

  import pydoc
  pydoc.cli()    
As near as I can tell, installation of the 2.1 Python
binaries for Win* gives no corresponding executable or
"shortcut" for that (those) platform(s).  Is it intended
generally to provide homologous facilities for each of
Unix and Win* (and MacOS)?  Is ... well, how should I
think about this?

I wrote Ka-Ping Yee (the pydoc lord--right?) earlier in
the day.  I've received no response.



From ping at lfw.org  Thu Apr  5 18:29:36 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Thu, 5 Apr 2001 09:29:36 -0700 (PDT)
Subject: [Python-Dev] Re: A kind of configuration question
In-Reply-To: <200104052251.RAA53506@starbase.neosoft.com>
Message-ID: <Pine.LNX.4.10.10104050927340.474-100000@skuld.kingmanhall.org>

On Thu, 5 Apr 2001, Cameron Laird wrote:
> Why's there no Win* executable pydoc?

There is.  There's a shortcut to pydoc.pyw on the Start Menu.

> I wrote Ka-Ping Yee (the pydoc lord--right?) earlier in
> the day.  I've received no response.

I'm at the CHI 2001 conference in Seattle right now; e-mail
checking frequency is down to less than 50 uHz. :)


-- ?!ng




From nas at python.ca  Fri Apr  6 02:50:31 2001
From: nas at python.ca (Neil Schemenauer)
Date: Thu, 5 Apr 2001 17:50:31 -0700
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <200104052236.RAA52963@starbase.neosoft.com>; from claird@starbase.neosoft.com on Thu, Apr 05, 2001 at 05:36:46PM -0500
References: <200104052236.RAA52963@starbase.neosoft.com>
Message-ID: <20010405175031.A17937@glacier.fnational.com>

Cameron Laird wrote:
> Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).
> 
> Successful installation requires
>   ./configure --with-cxx=gcc
>   sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
>   mv /tmp/Makefile Makefile

Can you send me the output from configure?  Also, try
--without-cxx instead.  Finally, an easier work around is:

    OPT=-O ./configure --with-cxx=gcc

Can someone tell me why with-cxx is the default?  It pissed me off
more than a few times when I was on a machine without a working C++
compiler.
 
  Neil



From fredrik at pythonware.com  Fri Apr  6 08:18:05 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 6 Apr 2001 08:18:05 +0200
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
References: <200104052236.RAA52963@starbase.neosoft.com>
Message-ID: <07ee01c0be61$5ab63690$e46940d5@hagrid>

Cameron Laird wrote:

> Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).
> 
> Successful installation requires
>   ./configure --with-cxx=gcc
>   sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
>   mv /tmp/Makefile Makefile

umm.  isn't there an -Olimit test in the configure script?

did you run configure with "cc" first, and forgot to remove the
cache files?

it would be nice if Python didn't default to "gcc" on the axp.
"cc" is standard, and creates much better code on the AXP.

Cheers /F




From fredrik at pythonware.com  Fri Apr  6 08:07:41 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 6 Apr 2001 08:07:41 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com> <20010405195338.C2820@xs4all.nl> <20010405144059.C402@dothill.com> <20010405232712.D2820@xs4all.nl>
Message-ID: <07ed01c0be61$5a4e4d00$e46940d5@hagrid>

thomas wrote:
> Actually, I think the above should go in *before* 2.1 final. It won't break
> anything new, and it fixes some warnings and possible some problems.
> Because:
> 
> - if _POSIX_THREADS is not already defined, nothing changes
> - if _POSIX_THREADS is already defined, to the same value as we are defining
>   it to, nothing changes
> - if _POSIX_THREADS is already defined, but to a different value than Python
>   wants to define it to, it used to break and starts working now. There is
>   nothing that depends on the actual value of _POSIX_THREADS in Python right
>   now (because it doesn't *have* a value.)

on the other hand, cygwin is the only platform that has reported
problems with this, and your solution doesn't address their problem.
(which is that Python assumes that a system that has pthread_create
in a library is a fully compliant POSIX thread system)

the right thing to do appears to be to let configure compile and
link a program that uses *all* pthread features needed, and define
_POSIX_THREAD (or better, PY_POSIX_THREADS) only if that
works...

Cheers /F




From tim.one at home.com  Fri Apr  6 10:46:54 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 04:46:54 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
Message-ID: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>

Jim Fulton bumped into a gross problem in the 2.1b2 asynchat.py today,
introduced by conversion to string methods (one change got the order of
.find() arguments backwards).

This is embarrassing (or should be <wink>), because it meant asynchat.py
really had no chance of working at all!  And if Jim hadn't bumped into it, we
would have shipped it this way for 2.1 final next week.

I haven't used those modules myself, so don't know whether this request is
reasonable:  could someone please whip up an at least minimal standard test
case for these modules?  So long as it runs on at least one of {Windows,
Linux}, we'd catch problems like this almost instantly.  As is, AFAICT we
don't even import asynchat (the "import asynchat" line in test_sundry.py is
commented out but no reason is given for that -- anyone know why?).

don't-everyone-volunteer-at-once-ly y'rs  - tim




From jack at oratrix.nl  Fri Apr  6 10:50:24 2001
From: jack at oratrix.nl (Jack Jansen)
Date: Fri, 06 Apr 2001 10:50:24 +0200
Subject: [Python-Dev] Re: [Pythonmac-SIG] __builtins__ a dictionary or a module?
In-Reply-To: Message by Jonathan Wight <JWight@bigfoot.com> ,
	     Thu, 05 Apr 2001 01:38:31 -0500 , <B6F17D15.194B8%JWight@bigfoot.com> 
Message-ID: <20010406085024.7548A312BA0@snelboot.oratrix.nl>

Python-devvers, can anyone help with this behaviour?

> If I run Just's Python IDE and run the same code it tells mes that
> __builtins__ is a module.
> 
> And finally if I run the following code from within the Interactive console
> contained in standard 'code.py' file I get told __builtins__ is a
> dictionary.
> 
> So what is it? Is __builtins__ a module or a dictionary? I know that they're
> essentially the same thing, but it unnerves me to have the same code produce
> different results in different platforms.

Well, I've narrowed down the difference to the exec statement:
>>> exec "print type(__builtins__)"
<type 'module'>
>>> exec "print type(__builtins__)" in {}
<type 'dictionary'>

Can anyone explain what is going on here?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 





From Paul.Moore at uk.origin-it.com  Fri Apr  6 10:55:38 2001
From: Paul.Moore at uk.origin-it.com (Moore, Paul)
Date: Fri, 6 Apr 2001 09:55:38 +0100 
Subject: [Python-Dev] A kind of configuration question 
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFC@ukrux002.rundc.uk.origin-it.com>

On Thu, 5 Apr 2001, Cameron Laird wrote:
> Why's there no Win* executable pydoc?

There's an issue on Windows, because there are two types of executable
(console and GUI). I've raised a bug report on this (407300), but the action
taken was to remove the pydoc script (as opposed to the module) from the
Windows installer, although there is still a start menu entry.

The problem is that pydoc does two things - first, it starts a web server
(with a small GUI control interface). This script needs to be run as a GUI
command, to avoid an unnecessary console window. This is what the entry on
the start menu does. The other thing is to support the command line usage
"pydoc XXX". For this, I believe there should be a console command. A small
"pydoc.bat" as follows would provide this functionality:

--- pydoc.bat ---
@echo off
if "%1"=="" pythonw -c "import pydoc; pydoc.cli()"
if NOT "%1"=="" python -c "import pydoc; pydoc.cli()" %1 %2 %3 %4 %5 %6 %7
%8 %9
---

I do the test on %1 so that if the command is called without any arguments,
it uses pythonw to spawn the GUI webserver, whereas with arguments it does
the command line stuff.

Paul Moore



From tim.one at home.com  Fri Apr  6 11:06:02 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 05:06:02 -0400
Subject: [Python-Dev] Re: [Pythonmac-SIG] __builtins__ a dictionary or a module?
In-Reply-To: <20010406085024.7548A312BA0@snelboot.oratrix.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEJCJKAA.tim.one@home.com>

Please read this the right way <wink>:  it's none of your business whether
__builtins__ is a module or a dictionary.  __builtin__ (no trailing 's') is a
module, but __builtins__ is a module attribute that can be either a module or
a dictionary, depending on what Python feels like doing.  Which it decides to
do is an internal implementation detail of no material consequence to correct
Python code.

More info on why the two choices exist-- and documentation that __builtins__
*can* be either a dict or a module --can be found in the "Code blocks,
execution frames, and namespaces" setion of the Language Reference manual.

BTW, the primary reason __builtins__ is a module when bringing up a native
command-line shell (I know that doesn't apply on a Mac Classic) is simply so
that if a curious user types

    >>> __builtins__

they get

    <module '__builtin__' (built-in)>

instead of a giant dict dump.  The primary use for making __builtins__ a dict
is to support restricted execution modes.




From tim.one at home.com  Fri Apr  6 11:25:16 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 05:25:16 -0400
Subject: [Python-Dev] A kind of configuration question 
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFC@ukrux002.rundc.uk.origin-it.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEJDJKAA.tim.one@home.com>

[Moore, Paul]
> There's an issue on Windows, because there are two types of executable
> (console and GUI). I've raised a bug report on this (407300), but
> the action taken was to remove the pydoc script (as opposed to the
> module) from the Windows installer, although there is still a start
> menu entry.

Paul, that action had nothing to do with your bug report.  Ping managed to
break AMK's pydoc script on Windows the morning of 2.1b2 release day, and
that left the Windows installer installing a non-functional Start menu link
for pydoc.  Unfortunately, I didn't discover that until after the 2.1b2 code
base was frozen.  Fortunately, Ping had also checked in a new pydoc.pyw
script (under Tools/scripts/) that *did* work on Windows, so *after* the last
second I simply changed the Start menu link to point to that instead, and
stopped copying AMK's no-longer-worked-on-Windows Tools/scripts/pydoc script
to the installation directory.  And I don't know why Guido copied AMK's pydoc
script to the Windows install directory to begin with, since (as your bug
report pointed out) it was a nearly useless thing on Windows even before it
got broken.

> ...
> The other thing is to support the command line usage "pydoc XXX".

Given that Win9x systems come with feeble cmdline shells (they're 50 lines
max, and no way to scroll back), I have no interest in pretending to support
pydoc's cmdline usage under Windows DOS boxes.  Writing a cmdline script to
drive pydoc is a trivial exercise for any knowledgable Windows user who wants
that, while the non-knowledgable should learn to use pydoc from within IDLE
or PythonWin or PythonWorks or ... instead (all of which provide a *capable*
Python shell under all flavors of Windows).




From Paul.Moore at uk.origin-it.com  Fri Apr  6 12:18:45 2001
From: Paul.Moore at uk.origin-it.com (Moore, Paul)
Date: Fri, 6 Apr 2001 11:18:45 +0100 
Subject: [Python-Dev] A kind of configuration question 
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com>

>[Moore, Paul]
>> There's an issue on Windows, because there are two types of executable
>> (console and GUI). I've raised a bug report on this (407300), but
>> the action taken was to remove the pydoc script (as opposed to the
>> module) from the Windows installer, although there is still a start
>> menu entry.
>
>Paul, that action had nothing to do with your bug report.  Ping managed to
>break AMK's pydoc script on Windows the morning of 2.1b2 release day, and
>that left the Windows installer installing a non-functional Start menu link
>for pydoc.

Oh. Sorry about that - I seem to have misread your comments from when you
reclosed the bug. I read them as "I've removed the scripts, so your bug no
longer applies", rather than "the script needed to be removed, so ths issue
has gone away". I apologise if I sounded critical. I do still think that
being able to type "pydoc MODULE" at the command line would be very nice,
and I feel that my batch file does this in a simple way. I'd be disappointed
if it wasn't included in 2.1 (the whole pydoc suite appeared quite late, so
minor fixes like this do get pushed up to the wire, but that doesn't
necessarily mean they should be discarded as "too late"), but if it is
deemed too late for that, could it be put into 2.2?

On a related note, has anything happened on my other bug report (406280)? At
the very least, using tempfilepager instead of pipepager as a workaround
would be sensible. Leaving things broken makes no real sense. This is a
patch:

--- pydoc.py.orig	Fri Mar 23 12:42:06 2001
+++ pydoc.py	Fri Apr 06 10:56:02 2001
@@ -910,7 +910,10 @@
     if not sys.stdin.isatty() or not sys.stdout.isatty():
         return plainpager
     if os.environ.has_key('PAGER'):
-        return lambda a: pipepager(a, os.environ['PAGER'])
+        if sys.platform == 'win32':
+            return lambda a: tempfilepager(a, os.environ['PAGER'])
+        else:
+            return lambda a: pipepager(a, os.environ['PAGER'])
     if sys.platform == 'win32':
         return lambda a: tempfilepager(a, 'more <')
     if hasattr(os, 'system') and os.system('less 2>/dev/null') == 0:

>> ...
>> The other thing is to support the command line usage "pydoc XXX".
>
>Given that Win9x systems come with feeble cmdline shells (they're 50 lines
>max, and no way to scroll back), I have no interest in pretending to
support
>pydoc's cmdline usage under Windows DOS boxes.

Given that Windows NT/2000 command line shells are fine, and reasonably
capable (including command history both at the prompt and within
applications, whatever size you like, and scrolling buffers), refusing to
support them just because 9x (which frankly is a dying environment for
developers) is pathetic, is not a very helpful stance to take. I've supplied
two low-impact patches which make pydoc work on the Windows NT command line.
Sure, I can apply them manually to my installation, but why not make them
available to everyone?

frustrated-ly y'rs,
Paul.



From jim at digicool.com  Fri Apr  6 14:04:12 2001
From: jim at digicool.com (Jim Fulton)
Date: Fri, 06 Apr 2001 08:04:12 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
Message-ID: <3ACDB0BC.2533D8C2@digicool.com>

Tim Peters wrote:
> 
> Jim Fulton bumped into a gross problem in the 2.1b2 asynchat.py today,
> introduced by conversion to string methods (one change got the order of
> .find() arguments backwards).
> 
> This is embarrassing (or should be <wink>), because it meant asynchat.py
> really had no chance of working at all!  And if Jim hadn't bumped into it, we
> would have shipped it this way for 2.1 final next week.
> 
> I haven't used those modules myself, so don't know whether this request is
> reasonable:  could someone please whip up an at least minimal standard test
> case for these modules?  So long as it runs on at least one of {Windows,
> Linux}, we'd catch problems like this almost instantly.  As is, AFAICT we
> don't even import asynchat (the "import asynchat" line in test_sundry.py is
> commented out but no reason is given for that -- anyone know why?).

Do we have test cases for other networking code? This seems a kinda
hard, though I haven't given it much thought.  I imagine one would
want some sort of faux sockets to support this.  Library modules
would need to be written so thier sockets could be passed in...

I've got a more basic question. Should asynchat *really* be in the standard
library?  Is it really used by anything but medusa? (There is another
module in the standard distribution that uses it, but it's unclear
whether anyone is using it. The Author isn't.)

Jim

--
Jim Fulton           mailto:jim at digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.



From guido at digicool.com  Fri Apr  6 17:02:03 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 06 Apr 2001 10:02:03 -0500
Subject: [Python-Dev] A kind of configuration question
In-Reply-To: Your message of "Fri, 06 Apr 2001 11:18:45 +0100."
             <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com> 
References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com> 
Message-ID: <200104061502.KAA14238@cj20424-a.reston1.va.home.com>

> On a related note, has anything happened on my other bug report (406280)? At
> the very least, using tempfilepager instead of pipepager as a workaround
> would be sensible. Leaving things broken makes no real sense. This is a
> patch:

What's broken?  After "from pydoc import help" I can use help(...)
just fine, both in the command line version (where it invokes some
pager) and in IDLE (where it just scrolls off the window, but IDLE has
infinite scroll-back so that's no problem).  This is on Win98se with
Python 2.1b2.
 
> Given that Windows NT/2000 command line shells are fine, and reasonably
> capable (including command history both at the prompt and within
> applications, whatever size you like, and scrolling buffers), refusing to
> support them just because 9x (which frankly is a dying environment for
> developers) is pathetic, is not a very helpful stance to take. I've supplied
> two low-impact patches which make pydoc work on the Windows NT command line.
> Sure, I can apply them manually to my installation, but why not make them
> available to everyone?

We seem to disagree on how Windows users use their system.  You seem
to be a command line user on Windows.  Both Tim & me are more
mouse-based users, and neither of us spends a lot of time in the
command line, so we don't see the point of adding yet another thing to
the distribution.  It is my expectation that *most* Windows users (and
developers) are like Tim & me, not like you, so we don't feel (if I
may channel Tim for a change :-) that this would benefit most users.

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



From fredrik at effbot.org  Fri Apr  6 16:20:08 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Fri, 6 Apr 2001 16:20:08 +0200
Subject: [Python-Dev] A kind of configuration question
References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com>  <200104061502.KAA14238@cj20424-a.reston1.va.home.com>
Message-ID: <0a8201c0bea4$b24cb760$e46940d5@hagrid>

> It is my expectation that *most* Windows users (and developers)
> are like Tim & me

no, we're not.

(no real windows developer use 98SE these days.  and just's
brother cannot possibly be a typical user of anything ;-)

I'm +0 on a pydoc command, but even if it's not added to the
standard distribution, I'm +1 on making sure pydoc works in case
someone wants to add a batchfile shortcut themselves.

Cheers /F




From jeremy at digicool.com  Fri Apr  6 16:13:43 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 6 Apr 2001 10:13:43 -0400 (EDT)
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
Message-ID: <15053.53015.996756.656235@slothrop.digicool.com>

>>>>> "TP" == Tim Peters <tim.one at home.com> writes:

  TP> Jim Fulton bumped into a gross problem in the 2.1b2 asynchat.py
  TP> today, introduced by conversion to string methods (one change
  TP> got the order of .find() arguments backwards).

  TP> This is embarrassing (or should be <wink>), because it meant
  TP> asynchat.py really had no chance of working at all!  And if Jim
  TP> hadn't bumped into it, we would have shipped it this way for 2.1
  TP> final next week.

This leads to the natural question:  Are there other modules that we
changed for string methods that don't have test suites?  If this
problem happened once, it could have happened twice.

Jeremy




From aahz at rahul.net  Fri Apr  6 16:26:08 2001
From: aahz at rahul.net (Aahz Maruch)
Date: Fri, 6 Apr 2001 07:26:08 -0700 (PDT)
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: <3ACDB0BC.2533D8C2@digicool.com> from "Jim Fulton" at Apr 06, 2001 08:04:12 AM
Message-ID: <20010406142608.DD66299CA0@waltz.rahul.net>

Jim Fulton wrote:
> 
> I've got a more basic question. Should asynchat *really* be in the standard
> library?  Is it really used by anything but medusa? (There is another
> module in the standard distribution that uses it, but it's unclear
> whether anyone is using it. The Author isn't.)

asynchat should probably be in the Tools directory, but my former
employer used asyncore (stand-alone, in addition to Medusa) and I was
quite happy when it went into the standard library.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.



From claird at starbase.neosoft.com  Fri Apr  6 16:37:27 2001
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Fri, 6 Apr 2001 09:37:27 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <20010405175031.A17937@glacier.fnational.com>
Message-ID: <200104061437.JAA79762@starbase.neosoft.com>

	From nas at arctrix.com  Thu Apr  5 19:51:35 2001
			.
			.
			.
	Can you send me the output from configure?  Also, try
	--without-cxx instead.  Finally, an easier work around is:
			.
			.
			.
Oops!  Sorry, everybody;
  configure --without-cxx
(which my notes say I'd earlier tried, with unsatisfying
results) appears indeed to be the minimal invocation in
my environment to yield a happy conclusion.

We're carrying on some of this in private correspondence.
While I remain uncertain about python-dev folkways, I'll
report more conclusions as I judge them of general interest.



From fredrik at effbot.org  Fri Apr  6 16:47:45 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Fri, 6 Apr 2001 16:47:45 +0200
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <20010406142608.DD66299CA0@waltz.rahul.net>
Message-ID: <0ac301c0bea8$8cef9ab0$e46940d5@hagrid>

jim wrote:
> I've got a more basic question. Should asynchat *really* be in the standard
> library?  Is it really used by anything but medusa?

yes.

Cheers /F




From claird at starbase.neosoft.com  Fri Apr  6 16:49:48 2001
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Fri, 6 Apr 2001 09:49:48 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <07ee01c0be61$5ab63690$e46940d5@hagrid>
Message-ID: <200104061449.JAA80212@starbase.neosoft.com>

	From fredrik at pythonware.com  Fri Apr  6 01:53:58 2001
			.
			.
			.
	> Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).
	> 
	> Successful installation requires
	>   ./configure --with-cxx=gcc
	>   sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
	>   mv /tmp/Makefile Makefile

	umm.  isn't there an -Olimit test in the configure script?

	did you run configure with "cc" first, and forgot to remove the
	cache files?
			.
			.
			.
Yes.  No.
  make distclean
  configure
  make
gives
  ...
  gcc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Modules/ccpython.o ./Modules/ccpython.cc
  gcc: 1500: No such file or directory
  cc1plus: Invalid option `-Olimit'
  make: *** [Modules/ccpython.o] Error 1   

Should I track this down, or do we have a specialist
on-hand in autoconfig?  I find it like sendmail.cf; I
can read and write, but never understand the *meaning*
of what others have done, just its syntax.  So, yes, I
can see the -Olimit test in configure.in, but it's
likely to take me a while to figure out what's wrong
with it.



From claird at starbase.neosoft.com  Fri Apr  6 16:50:56 2001
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Fri, 6 Apr 2001 09:50:56 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <07ee01c0be61$5ab63690$e46940d5@hagrid>
Message-ID: <200104061450.JAA80284@starbase.neosoft.com>

	From fredrik at pythonware.com  Fri Apr  6 01:53:58 2001
			.
			.
			.
	it would be nice if Python didn't default to "gcc" on the axp.
	"cc" is standard, and creates much better code on the AXP.

	Cheers /F
Me, too.



From barry at digicool.com  Fri Apr  6 17:01:46 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Fri, 6 Apr 2001 11:01:46 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
	<3ACDB0BC.2533D8C2@digicool.com>
Message-ID: <15053.55898.791123.146656@anthem.wooz.org>

>>>>> "JF" == Jim Fulton <jim at digicool.com> writes:

    JF> I've got a more basic question. Should asynchat *really* be in
    JF> the standard library?  Is it really used by anything but
    JF> medusa? (There is another module in the standard distribution
    JF> that uses it, but it's unclear whether anyone is using it. The
    JF> Author isn't.)

That'd be me.  I wrote smtpd.py a long while ago, got approval from
Guido to add it to the standard library, then forgot about it until
around the 2.1a1 time frame.  smtpd.py itself is probably useful to
only a handful of people (and maybe that hand belongs to a shop
teacher), so I wouldn't be offended if it and async* were moved to
Tools -- eventually.  It is, of course, much too late to do this for
Py2.1.

-Barry



From barry at digicool.com  Fri Apr  6 17:04:57 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Fri, 6 Apr 2001 11:04:57 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
	<3ACDB0BC.2533D8C2@digicool.com>
Message-ID: <15053.56089.93466.30362@anthem.wooz.org>

Oh, one other thing.  Last time I traded email with Sam Rushing
(almost a year ago, and I'm not even sure if he's on python-dev), he
was moving toward a coroutine based Medusa and away from async* based.

-Barry



From jim at digicool.com  Fri Apr  6 17:20:46 2001
From: jim at digicool.com (Jim Fulton)
Date: Fri, 06 Apr 2001 11:20:46 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <20010406142608.DD66299CA0@waltz.rahul.net>
Message-ID: <3ACDDECE.E4E7806E@digicool.com>

Aahz Maruch wrote:
> 
> Jim Fulton wrote:
> >
> > I've got a more basic question. Should asynchat *really* be in the standard
> > library?  Is it really used by anything but medusa? (There is another
> > module in the standard distribution that uses it, but it's unclear
> > whether anyone is using it. The Author isn't.)
> 
> asynchat should probably be in the Tools directory, but my former
> employer used asyncore (stand-alone, in addition to Medusa) and I was
> quite happy when it went into the standard library.

I was only talking about asynchat. :)

Jim

--
Jim Fulton           mailto:jim at digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org



From jim at digicool.com  Fri Apr  6 17:22:49 2001
From: jim at digicool.com (Jim Fulton)
Date: Fri, 06 Apr 2001 11:22:49 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
		<3ACDB0BC.2533D8C2@digicool.com> <15053.56089.93466.30362@anthem.wooz.org>
Message-ID: <3ACDDF49.A641466E@digicool.com>

"Barry A. Warsaw" wrote:
> 
> Oh, one other thing.  Last time I traded email with Sam Rushing
> (almost a year ago, and I'm not even sure if he's on python-dev), he
> was moving toward a coroutine based Medusa and away from async* based.

I don't think that was medusa. I tink it was something else.

Jim

--
Jim Fulton           mailto:jim at digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org



From barry at digicool.com  Fri Apr  6 17:34:54 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Fri, 6 Apr 2001 11:34:54 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
	<3ACDB0BC.2533D8C2@digicool.com>
	<15053.56089.93466.30362@anthem.wooz.org>
	<3ACDDF49.A641466E@digicool.com>
Message-ID: <15053.57886.530944.174828@anthem.wooz.org>

>>>>> "JF" == Jim Fulton <jim at digicool.com> writes:

    JF> I don't think that was medusa. I tink it was something else.

Sam called it the "next generation medusa". :)



From guido at digicool.com  Fri Apr  6 19:52:16 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 06 Apr 2001 12:52:16 -0500
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: Your message of "Fri, 06 Apr 2001 04:46:54 -0400."
             <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com> 
Message-ID: <200104061752.MAA15185@cj20424-a.reston1.va.home.com>

> I haven't used those modules myself, so don't know whether this request is
> reasonable:  could someone please whip up an at least minimal standard test
> case for these modules?  So long as it runs on at least one of {Windows,
> Linux}, we'd catch problems like this almost instantly.  As is, AFAICT we
> don't even import asynchat (the "import asynchat" line in test_sundry.py is
> commented out but no reason is given for that -- anyone know why?).

I just checked in a testcase for asynchat that also tests asyncore.

It works on Windows98se and Linux Red Hat 6.2, at least.  Enjoy!

I guess the line from test_sundry.py can now be deleted -- ditto for
the import of asyncore.

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



From tim.one at home.com  Fri Apr  6 21:00:06 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 15:00:06 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: <200104061752.MAA15185@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEKNJKAA.tim.one@home.com>

[Guido]
> I just checked in a testcase for asynchat that also tests asyncore.

Excellent -- thank you!

> ...
> I guess the line from test_sundry.py can now be deleted -- ditto for
> the import of asyncore.

Done.




From tim.one at home.com  Sat Apr  7 00:27:53 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 18:27:53 -0400
Subject: [Python-Dev] A kind of configuration question
In-Reply-To: <200104061502.KAA14238@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIELMJKAA.tim.one@home.com>

[Guido, to Paul Moore]
> ...
> We seem to disagree on how Windows users use their system.  You seem
> to be a command line user on Windows.  Both Tim & me are more
> mouse-based users, and neither of us spends a lot of time in the
> command line, so we don't see the point of adding yet another thing to
> the distribution.  It is my expectation that *most* Windows users (and
> developers) are like Tim & me, not like you, so we don't feel (if I
> may channel Tim for a change :-) that this would benefit most users.

Well, when playing Windows developer I spend most of my life in a DOS box.
But when playing Windows developer, I also have no need for anyone to write a
trivial .bat file for me, and indeed would probably write my own anyway to
cater to that, e.g., I can set up useful cmdline associations for Python on
Win2K but not Win9X.  Is there *any* Windows developer out there too lame to
do this for themself?  I doubt it.

Does it hurt to include a little .bat file anyway?  YES!  Most Python users
on Windows are not Windows developers, and unlike Paul I'm going to spend a
fair chunk of my life on the Tutor and Help lists trying to explain to the
vast majority *why* the pydoc.bat file in the install directory is useless to
them on their Win9X boxes.  BTW, I use Win9X deliberately at home, partly
because that's what my sisters use, and partly to keep my sympathy high for
all of Python's thousands of Win9X sufferers.

If you want to supply pydoc .bat files, fine, work out a minimal set with
Ping and submit a patch to put them in the Tools/scripts/ directory.  One of
them has to be suitable for linking to directly from the pydoc Start menu
item, but beyond that if they're out of sight they're out of mind so I don't
much care.  I actively want to keep them *out* of the main installation
directory, because newbies want to know about *every* file in that directory,
and there's nothing positive we can tell them about a pydoc.bat file under
their Win9X systems (unless all it does is bring up a GUI).  It's no accident
that Python doesn't ship with any .bat files today.

no-need-to-bend-over-backwards-to-help-people-who-don't-need-help-ly y'rs
    - tim




From tim.one at home.com  Sat Apr  7 00:42:22 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 18:42:22 -0400
Subject: [Python-Dev] A kind of configuration question
In-Reply-To: <0a8201c0bea4$b24cb760$e46940d5@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELNJKAA.tim.one@home.com>

[/F]
> I'm +0 on a pydoc command, but even if it's not added to the
> standard distribution, I'm +1 on making sure pydoc works in case
> someone wants to add a batchfile shortcut themselves.

Can you be more specific?  AMK's Tools/scripts/pydoc works on Windows,
although from a Win9x shell the text modes are more frustrating than useful,
and if you use "python" to start it instead of "pythonw" and ask for a GUI
mode, you're subject to Tk freezing the DOS box (etc) from time to time.  So
does pydoc "work" now or not in your view?  If not, what does "work" mean?

The Windows installer currently creates a Start menu item pointing to Ping's
Tools/scripts/pydoc.pyw program instead, which works fine, and just executes
pydoc.gui().




From fdrake at cj42289-a.reston1.va.home.com  Sat Apr  7 07:45:43 2001
From: fdrake at cj42289-a.reston1.va.home.com (Fred Drake)
Date: Sat,  7 Apr 2001 01:45:43 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010407054543.226DD2879A@cj42289-a.reston1.va.home.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


Lots of small fixes, but also the first installment of the unittest
documentation.




From jack at oratrix.nl  Sat Apr  7 14:00:15 2001
From: jack at oratrix.nl (Jack Jansen)
Date: Sat, 07 Apr 2001 14:00:15 +0200
Subject: [Python-Dev] Import hook to do end-of-line conversion?
Message-ID: <20010407120021.5503DEA11D@oratrix.oratrix.nl>

[Oops, try again]

There's talk on the PythonMac-SIG to create an import hook that would
read modules with either \r, \n or \r\n newlines and convert them to
the local convention before feeding them to the rest of the import
machinery. The reason this has become interesting is the mixed
unixness/macness of MacOSX, where such an import hook could be used to
share a Python tree between MacPython and bsd-Python. They would only
need a different site.py (probably), living somehwere near the head of
sys.path, that would be in local end of line convention and enable the
hook.

However, it seem that such a module would have a much more general
scope, for instance if you're accessing samba partitions from windows,
or other foreign file systems, etc.

Does this sound like a good idea? And (even better:-) has anyone done
this already? Would it be of enough interest to include it in the
core Lib?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | ++++ see http://www.xs4all.nl/~tank/ ++++



From fredrik at pythonware.com  Sat Apr  7 18:25:52 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sat, 7 Apr 2001 18:25:52 +0200
Subject: [Python-Dev] Import hook to do end-of-line conversion?
References: <20010407120021.5503DEA11D@oratrix.oratrix.nl>
Message-ID: <004c01c0bf7f$6b64e4e0$e46940d5@hagrid>

jack wrote:
> There's talk on the PythonMac-SIG to create an import hook that would
> read modules with either \r, \n or \r\n newlines and convert them to
> the local convention before feeding them to the rest of the import
> machinery.

why not fix the compiler instead?

Cheers /F




From gstein at lyra.org  Sat Apr  7 18:21:14 2001
From: gstein at lyra.org (Greg Stein)
Date: Sat, 7 Apr 2001 09:21:14 -0700
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <004c01c0bf7f$6b64e4e0$e46940d5@hagrid>; from fredrik@pythonware.com on Sat, Apr 07, 2001 at 06:25:52PM +0200
References: <20010407120021.5503DEA11D@oratrix.oratrix.nl> <004c01c0bf7f$6b64e4e0$e46940d5@hagrid>
Message-ID: <20010407092114.E31832@lyra.org>

On Sat, Apr 07, 2001 at 06:25:52PM +0200, Fredrik Lundh wrote:
> jack wrote:
> > There's talk on the PythonMac-SIG to create an import hook that would
> > read modules with either \r, \n or \r\n newlines and convert them to
> > the local convention before feeding them to the rest of the import
> > machinery.
> 
> why not fix the compiler instead?

Exactly. That is where the correct fix should go. The compile can/should
recognize all types of newlines as the NEWLINE token.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From just at letterror.com  Sat Apr  7 18:40:02 2001
From: just at letterror.com (Just van Rossum)
Date: Sat,  7 Apr 2001 18:40:02 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <20010407092114.E31832@lyra.org>
Message-ID: <20010407184003-r01010600-1327fbb2@213.84.27.177>

Greg Stein wrote:

> On Sat, Apr 07, 2001 at 06:25:52PM +0200, Fredrik Lundh wrote:
> > jack wrote:
> > > There's talk on the PythonMac-SIG to create an import hook that would
> > > read modules with either \r, \n or \r\n newlines and convert them to
> > > the local convention before feeding them to the rest of the import
> > > machinery.
> > 
> > why not fix the compiler instead?
> 
> Exactly. That is where the correct fix should go. The compile can/should
> recognize all types of newlines as the NEWLINE token.

The same goes for file objects in text mode...

Just



From fredrik at pythonware.com  Sat Apr  7 18:54:28 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sat, 7 Apr 2001 18:54:28 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
References: <20010407184003-r01010600-1327fbb2@213.84.27.177>
Message-ID: <00b901c0bf83$69b1e0e0$e46940d5@hagrid>

Just wrote:
> > > why not fix the compiler instead?
> > 
> > Exactly. That is where the correct fix should go. The compile can/should
> > recognize all types of newlines as the NEWLINE token.
> 
> The same goes for file objects in text mode...

probably -- but changing can break stuff (in theory, at least), and
may require a PEP.  changing the compiler is more of a bugfix, really...

Cheers /F




From just at letterror.com  Sat Apr  7 19:26:26 2001
From: just at letterror.com (Just van Rossum)
Date: Sat,  7 Apr 2001 19:26:26 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <00b901c0bf83$69b1e0e0$e46940d5@hagrid>
Message-ID: <20010407192627-r01010600-b0457661@213.84.27.177>

Fredrik Lundh wrote:

> Just wrote:
> > > > why not fix the compiler instead?
> > > 
> > > Exactly. That is where the correct fix should go. The compile can/should
> > > recognize all types of newlines as the NEWLINE token.
> > 
> > The same goes for file objects in text mode...
> 
> probably -- but changing can break stuff (in theory, at least), and
> may require a PEP.  changing the compiler is more of a bugfix, really...

But if we only fix the compiler, we'll get complaints that other things
don't work, eg. bogus tracebacks due to a non-fixed linecache.py, broken IDE's,
etc.

Btw. I can't seem to think of any examples that would break after such a change.
I mean, who would depend on a \n text file with embedded \r's?

Just



From paul at pfdubois.com  Sat Apr  7 19:33:57 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Sat, 7 Apr 2001 10:33:57 -0700
Subject: [Python-Dev] Progress report on PEP 242
Message-ID: <ADEOIFHFONCLEEPKCACCCENICHAA.paul@pfdubois.com>

If I understand correctly I need to supply a reference implementation for
PEP 242.

I have made considerable progress on this:

C:\Paul\Numerical\Packages\kinds>python
Python 2.1b2 (#12, Mar 23 2001, 14:01:30) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import kinds
>>> f=kinds.float_kind(5,100)
>>> f.max
1.7976931348623157e+308
>>> f.min
2.2250738585072014e-308
>>> f.epsilon
2.2204460492503131e-016
>>> f.radix
0.3010299956639812
>>> f.epsilonbyradix
1.1102230246251565e-016
>>> 10.0**f.radix
2.0    # in case you were wondering...
>>> f(7)
7.0
>>>

These five attributes are the standard ones computed by routines such as
d1mach.
(See netlib.org, search for d1mach).

These attributes I made up:

f.name ('Float' in this case)
f.typecode ('d' in this case, a typecode suitable for modules array or
Numeric

I haven't updated the PEP itself with the comments I got, but it essentially
amounts to fixing the section on coercion, which I mainly realized I don't
really have to deal with.




From guido at digicool.com  Sat Apr  7 20:43:45 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 07 Apr 2001 13:43:45 -0500
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Sat, 07 Apr 2001 14:00:15 +0200."
             <20010407120021.5503DEA11D@oratrix.oratrix.nl> 
References: <20010407120021.5503DEA11D@oratrix.oratrix.nl> 
Message-ID: <200104071843.NAA23537@cj20424-a.reston1.va.home.com>

> There's talk on the PythonMac-SIG to create an import hook that would
> read modules with either \r, \n or \r\n newlines and convert them to
> the local convention before feeding them to the rest of the import
> machinery. The reason this has become interesting is the mixed
> unixness/macness of MacOSX, where such an import hook could be used to
> share a Python tree between MacPython and bsd-Python. They would only
> need a different site.py (probably), living somehwere near the head of
> sys.path, that would be in local end of line convention and enable the
> hook.
> 
> However, it seem that such a module would have a much more general
> scope, for instance if you're accessing samba partitions from windows,
> or other foreign file systems, etc.
> 
> Does this sound like a good idea? And (even better:-) has anyone done
> this already? Would it be of enough interest to include it in the
> core Lib?

I know that it's too late for 2.1, but for 2.2, I think we can do
better: like Java, the import mechanism should accept all three line
ending conventions on all platforms!  It would also be nice if opening
a file in text mode did this transformation, but alas, that would
probably require more work on the file object than I care for.  But
import should be doable!

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



From guido at digicool.com  Sat Apr  7 20:57:10 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 07 Apr 2001 13:57:10 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Sat, 07 Apr 2001 19:26:26 +0200."
             <20010407192627-r01010600-b0457661@213.84.27.177> 
References: <20010407192627-r01010600-b0457661@213.84.27.177> 
Message-ID: <200104071857.NAA23651@cj20424-a.reston1.va.home.com>

> > > The same goes for file objects in text mode...

Yes.

> > probably -- but changing can break stuff (in theory, at least), and
> > may require a PEP.  changing the compiler is more of a bugfix, really...

Yes.

> But if we only fix the compiler, we'll get complaints that other
> things don't work, eg. bogus tracebacks due to a non-fixed
> linecache.py, broken IDE's, etc.

Yes.

> Btw. I can't seem to think of any examples that would break after
> such a change.  I mean, who would depend on a \n text file with
> embedded \r's?

On Unix, currently, tell() always give you a number that exactly
matches the number of characters you've read since the beginning of
the file.  This would no longer be true.  In general, code written on
Unix with no expectation to ever leave Unix, can currently be sloppy
about using binary mode, and open binary files in text mode.  Such
code could break.  I'm sure there's plenty such code around (none
written by me :-).

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




From tim.one at home.com  Sat Apr  7 23:15:30 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 7 Apr 2001 17:15:30 -0400
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104071843.NAA23537@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIENFJKAA.tim.one@home.com>

As Guido said, Java defines that source-code lines end with any of LF, CR, or
CRLF, and that needn't even be consistent across lines.

If source files are opened in C binary mode, this is easy enough to do but
puts all the burden for line-end detection on Python.

Opening source files in C text mode doesn't solve the problem either.  For
example, if you open a source file with CR endings in Windows C text mode,
Windows thinks the entire file is "one line".  I expect the same is true if
CR files are opened in Unix text mode.

So, in the end, binary mode appears to be better (more uniform code).  But
then what happens under oddball systems like OpenVMS, which seem to use
radically different file structures for text and binary data?  I've no idea
what happens if you try to open a text file in binary mode under those.

[Guido]
> ...
> It would also be nice if opening a file in text mode did this
> transformation, but alas, that would probably require more work
> on the file object than I care for.

Well, Python source files aren't *just* read by "the compiler" in Python.
For example, assorted tools in the std library analyze Python source files
via opening as ordinary (Python) text files, and the runtime traceback
mechanism opens Python source files in (C) text mode too.  For that stuff to
work correctly regardless of line ends is lots of work in lots of places.  In
the end I bet it would be easier to replace all direct references to C
textfile operations with a "Python text file" abstraction layer.

importing-is-only-the-start-of-the-battle-ly y'rs  - tim




From tim.one at home.com  Sat Apr  7 23:27:35 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 7 Apr 2001 17:27:35 -0400
Subject: [Python-Dev] FW: PyChecker - a python source code bug finder
Message-ID: <LNBBLJKPBEHFEDALKOLCCENHJKAA.tim.one@home.com>

Way cool!  Check this out.  I picked 4 of the problems Neal found "at
random", and all appear to still exist under current CVS.  How about everyone
take their favorite module and fix it?

Thank you, Neal!

-----Original Message-----
From: python-list-admin at python.org
[mailto:python-list-admin at python.org]On Behalf Of Neal Norwitz
Sent: Saturday, April 07, 2001 2:28 PM
To: python-announce-list at python.org; python-list at python.org
Subject: PyChecker - a python source code bug finder



PyChecker is a python source code checking tool to help you find common bugs.
It is meant to find problems that are typically caught by a compiler. Because
of the dynamic nature of python, some warnings may be incorrect; however,
spurious warnings should be fairly infrequent.

Types of problems that can currently, be found include:

    * No doc strings in modules, classes, functions, and methods
    * self not the first parameter to a method
    * Wrong number of parameters passed to functions/methods
    * No global found (e.g., using a module without importing it)
    * Global not used (module or variable)

PyChecker currently runs on Python 2.0.  If there's interest, it can be back
ported to Python 1.5.2.

I have run PyChecker against Python 2.1b2a, the following are problems found
in the standard python modules:

    ### Warnings
        codeop.py:3 Imported module (sys) not used
        codeop.py:4 Imported module (traceback) not used
        fileinput.py:292 Function (input) doesn't require named arguments
        multifile.py:30 Imported module (sys) not used
        pipes.py:62 Imported module (sys) not used
        urllib.py:598 Function (quote) doesn't require named arguments
        urllib.py:611 Function (quote) doesn't require named arguments
        string.py:190 Variable (_StringType) not used
        tabnanny.py:15 Imported module (string) not used
                        imported again @ 241 and used there

    ### Errors:
        audiodev.py:214 No global (BUFFERSIZE) found
        bdb.py:111 No method (do_clear) found
        chunk.py:109 No attribute (chunk_size) found
			should be chunksize
        locale.py:253 No global (l) found
        netrc.py:13 No global (file) found
        pydoc.py:1070 No global (DocImportError) found
        pydoc.py:1070 No global (filename) found


PyChecker is available on Source Forge:
    web page:		http://pychecker.sourceforge.net/
    project page:	http://sourceforge.net/projects/pychecker/

Enjoy!  Feedback is greatly appreciated.

Neal
--
pychecker at metaslash.com

--
http://mail.python.org/mailman/listinfo/python-list




From tim.one at home.com  Sun Apr  8 08:41:55 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 8 Apr 2001 02:41:55 -0400
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <ADEOIFHFONCLEEPKCACCCENICHAA.paul@pfdubois.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com>

[Paul F. Dubois]
> If I understand correctly I need to supply a reference implementation
> for PEP 242.

Somebody does, but not necessarily you.

> I have made considerable progress on this:

Cool!  I'm glad it was you <wink>.

> C:\Paul\Numerical\Packages\kinds>python
> Python 2.1b2 (#12, Mar 23 2001, 14:01:30) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import kinds
> >>> f=kinds.float_kind(5,100)
> >>> f.max
> 1.7976931348623157e+308

What type of float is the result?  Is that defined?  Of the same float kind
as requested?  Or of some fixed float kind?  Or does/can it vary across
attributes?

> >>> f.min
> 2.2250738585072014e-308

Is it customary to ignore the existence of denorms?  All the same to me, but
since that's not the smallest positive non-zero double on a 754 box, the name
"min" is a fiction.  If it's a *useful* fiction, fine.

> >>> f.epsilon
> 2.2204460492503131e-016
> >>> f.radix
> 0.3010299956639812

I expect that, if you really try, you can think of a better name <wink -- but
log10radix would make a lot more sense here; + see below>.

> >>> f.epsilonbyradix
> 1.1102230246251565e-016
>
> These five attributes are the standard ones computed by routines such
> as d1mach.
> (See netlib.org, search for d1mach).

There are several.  Most are Fortran routines that ask you to first uncomment
the correct section of hard-coded DATA stmts for the platform you're running
on.  I trust you're using a dynamic approach.

Question:  are these attributes useful enough in the absence of the model
parameters from I1MACH?  That is, D1MACH exposes an idealized floating point
model approximating machine reality, parameterized by a base (radix), number
of digits, and minimum and maximum exponents.  Those four are all integers,
so were traditionally exposed via I1MACH instead (at I1MACH indices 10, 14,
15 and 16).  I expect people would find it useful if you exposed those as
attributes too, i.e. hypothetically continuing the above:

>>> f.radix  # assuming existing f.radix renamed
2
>>> f.numdigits
53
>>> f.emin
-1021
>>> f.emax
1024
>>>

Then the explanation of what the other attributes *mean* is easy, relating
them directly to the idealized f.p. model D1MACH is based on:

f.log10radix = log10(f.radix)
f.epsilon = f.radix ** (1-f.numdigits)
f.epsilonbyradix = f.radix ** -f.numdigits
f.min = f.radix ** (f.emin - 1)
f.max = f.radix**f.emax * (1 - f.epsilonbyradix)

(That last one isn't numerically correct, but mathematically; in code you'd
have to write it

    math.ldexp(1.0 - f.epsilonbyradix, f.emax)

and assuming f.radix is 2).  Note that exposing this stuff also makes clearer
why f.min doesn't tell the hardware's notion of truth for 754 boxes.

> These attributes I made up:
>
> f.name ('Float' in this case)

Since you're extending Python's floating type system with precision & range
parameters, I'd much rather see this one called 'double', since you're
obviously using a box with IEEE-754 doubles here, and all C implementations I
know of call this a double too; I expect that 99+% of all F77 implementations
also call this one double.  In addition, I expect you'll soon deal with IEEE
singles too, and then the question "single or double?" makes clear sense, but
"single or float?" is just baffling.

> f.typecode ('d' in this case, a typecode suitable for modules array or
> Numeric

Yet another reason to start f.name with "d", right?  Right <wink>.




From jim at interet.com  Sun Apr  8 15:50:23 2001
From: jim at interet.com (James C. Ahlstrom)
Date: Sun, 08 Apr 2001 09:50:23 -0400
Subject: [Python-Dev] Problems with zipfile.py
Message-ID: <3AD06C9F.848B0A98@interet.com>

The zipfile module seems to have been well received, and
I have the impression that many people are using it.  But
I have been getting complaints that it won't read ZIP files
created by InfoZip.  At first I thought this was a problem
with incompatible zlib compression versions, but now I have
found the problem.

It turns out that InfoZip's Wiz version 5.02 (and maybe other
InfoZip versions) creates ZIP files with an incorrect value
for "extra data length" in the central directory, but the correct
value in the file header.  The "extra data" is before the compressed
file data, and so this causes the file data offset to be off slightly
thus causing complaints from the zlib decompressor.  I changed
zipfile.py to use the file header value, and it fixes the problem.

I also added a new method restore(self, name, fileobject) which
was suggested some time ago by MAL.  It writes to an open file
or any other object with a write() method.  It avoids the need
to read the whole file into memory.

I also changed the "raise" statements to use the "zipfile.error"
exception.  This agrees with the documentation, but previously
zipfile raised a variety of exceptions.  This also fixes the
complaint that "BadZipfile" should be spelled "BadZipFile".

The new changed zipfile.py is available from
            ftp://ftp.interet.com/pub/zipfile.py
and is currently being tested by a user.  Please take a look.

JimA



From guido at digicool.com  Sun Apr  8 17:23:36 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 08 Apr 2001 10:23:36 -0500
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: Your message of "Sun, 08 Apr 2001 02:41:55 -0400."
             <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com> 
Message-ID: <200104081523.KAA31118@cj20424-a.reston1.va.home.com>

I don't know if it answers all the questions one could ask about a
floating point implementation, but long ago my esteemed Dutch
colleague Steven Pemberton (ABC project lead, these days chair of the
W3C XHTML working group) wrote a C program, "enquire.c", that attempts
to figure out lots of machine details.  It might help finding the
properties of floats and doubles without assuming IEEE-754.

http://www.cwi.nl/~steven/enquire.html

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



From fdrake at acm.org  Sun Apr  8 17:21:27 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sun, 8 Apr 2001 11:21:27 -0400 (EDT)
Subject: [Python-Dev] Problems with zipfile.py
In-Reply-To: <3AD06C9F.848B0A98@interet.com>
References: <3AD06C9F.848B0A98@interet.com>
Message-ID: <15056.33271.519639.865010@cj42289-a.reston1.va.home.com>

James C. Ahlstrom writes:
 > It turns out that InfoZip's Wiz version 5.02 (and maybe other
 > InfoZip versions) creates ZIP files with an incorrect value
 > for "extra data length" in the central directory, but the correct
 > value in the file header.  The "extra data" is before the compressed
 > file data, and so this causes the file data offset to be off slightly
 > thus causing complaints from the zlib decompressor.  I changed
 > zipfile.py to use the file header value, and it fixes the problem.

  This was fixed by a patch from Jens Quade in CVS revision 1.7 of
zipfile.py.

 > I also added a new method restore(self, name, fileobject) which
 > was suggested some time ago by MAL.  It writes to an open file
 > or any other object with a write() method.  It avoids the need
 > to read the whole file into memory.

  Cool!  I'll try to look at this Monday, but I'm not sure it should
go in for Python 2.1 -- it is a new feature, and we're supposed to be
in a feature freeze.

 > I also changed the "raise" statements to use the "zipfile.error"
 > exception.  This agrees with the documentation, but previously
 > zipfile raised a variety of exceptions.  This also fixes the
 > complaint that "BadZipfile" should be spelled "BadZipFile".

  I think the exceptions situation has been cleaned up as well.  You
might want to take a look at the version in Python CVS (soon to be
Python 2.1) to see what else has changed (most substantially, Itamar
Shtull-Trauring added support for loading ZIP files from open file
objects).


  -Fred

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




From paul at pfdubois.com  Sun Apr  8 17:31:53 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Sun, 8 Apr 2001 08:31:53 -0700
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com>
Message-ID: <ADEOIFHFONCLEEPKCACCAEOFCHAA.paul@pfdubois.com>

Thank you for your excellent critique of my example. I will consider your
comments carefully.

The standard C library defines some constants in math.h that give the
required information. I think the right thing to do is simply include all of
those using names that make an identifiable connection to the standard
quantities (I had five of them, but there are more). This begs the question
of what to do if you are implementing Python over something other than C but
the definitions in the standard C library are clear, so in principle this
can be done.

The default Python floating point kind would be the one used to return the
(floating) attributes when queried, since I can't rely on their being any
other such kind; i.e., a C double.

Naming is going to be confusing no matter what we do. We're starting with
Python "float" == C "double" == Numeric Float == typecode 'd'. We're
doomed...





From tim.one at home.com  Sun Apr  8 21:32:34 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 8 Apr 2001 15:32:34 -0400
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <200104081523.KAA31118@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEPAJKAA.tim.one@home.com>

[Guido, on
   http://www.cwi.nl/~steven/enquire.html
]

Yup, we used that program back in my KSR days!  Looks like the source code
has grown by a factor of ~6 since then.  One of the most recent change log
entries is scary:

   5.1  Length 88739; Sep 1998
	...
	Speeded up search for max char (first 32 bit char machine
      turned up...)

The Python source code is going to be delighted with 32-bit chars.

assuming-they-went-out-of-business-already<0.7-wink>-ly y'rs  - tim




From greg at cosc.canterbury.ac.nz  Mon Apr  9 03:26:47 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 09 Apr 2001 13:26:47 +1200 (NZST)
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <20010407120021.5503DEA11D@oratrix.oratrix.nl>
Message-ID: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz>

Jack Jansen <jack at oratrix.nl>:

> read modules with either \r, \n or \r\n newlines
> Does this sound like a good idea?

YES! It's always annoyed me that the Mac (seemingly without
good reason) complains about sources with \n line endings.
I have often shuttled code between Mac and Unix systems
during development, and having to do \r/\n translations
every time is a royal pain.

> Would it be of enough interest to include it in the
> core Lib?

I'd vote for building it right into the interpreter! Is
there any reason why anyone would want *not* to have it?

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



From tim.one at home.com  Mon Apr  9 07:00:18 2001
From: tim.one at home.com (Tim Peters)
Date: Mon, 9 Apr 2001 01:00:18 -0400
Subject: [Python-Dev] A kind of configuration question 
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFC@ukrux002.rundc.uk.origin-it.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEABJLAA.tim.one@home.com>

[Moore, Paul]
> ...
> --- pydoc.bat ---
> @echo off
> if "%1"=="" pythonw -c "import pydoc; pydoc.cli()"
> if NOT "%1"=="" python -c "import pydoc; pydoc.cli()" %1 %2 %3 %4 ...
> ---
>
> I do the test on %1 so that if the command is called without any
> arguments, it uses pythonw to spawn the GUI webserver, whereas with
> arguments it does the command line stuff.

FYI, that's what appears to have gotten broken the morning of the 2.1b2
release.  If you do

    pythonw -c "import pydoc; pydoc.cli()"

then or today, "nothing happens" (actually, a usage blurb gets printed to
stdout, but under pythonw that's effectively /dev/null).

If you're determined to write .bat scripts <wink>, now you want

    pythonw -c "import pydoc; pydoc.gui()"

or

    pythonw -c "import pydoc; pydoc.cli()" -g

instead.




From tim.one at home.com  Mon Apr  9 08:36:24 2001
From: tim.one at home.com (Tim Peters)
Date: Mon, 9 Apr 2001 02:36:24 -0400
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <ADEOIFHFONCLEEPKCACCAEOFCHAA.paul@pfdubois.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEADJLAA.tim.one@home.com>

[Paul F. Dubois]
> The standard C library defines some constants in math.h that give
> the required information. I think the right thing to do is simply
> include all of those using names that make an identifiable connection
> to the standard quantities (I had five of them, but there are more).

It's in float.h in C.  Suggest looking at the new C99 std, since they did a
better job of defining these things than C89.  Luckily, they use the same
idealized model as R1MACH/D1MACH/I1MACH (in particular, they also view the
radix point as being "to the left" of all digits, so they agree on min and
max exponents).  float.h doesn't have an equivalent to your epsilonoverradix,
though).

> This begs the question of what to do if you are implementing Python
> over something other than C but the definitions in the standard C
> library are clear, so in principle this can be done.

Since virtually all boxes on Earth use IEEE-754 f.p. now, it's not like
there's a lot of variety they'll need to contend with (and, e.g., the Java
language spec requires 754 arithmetic specifically, so Jython's life can be
hardcoded).

> The default Python floating point kind would be the one used to
> return the (floating) attributes when queried, since I can't rely
> on their being any other such kind; i.e., a C double.

Hmm.  On second thought, if I do

    f = kinds.float_kind(m, n)

and it doesn't raise an exception, then surely the kind of float f() creates
*must* exist in this implementation.  Yes?  In that case f.min and f.max
(etc) can be of exactly the kind f() returns.  If you stick to C double, then
e.g. if I implement (say) IEEE double-extended, the kind object k building
such beasts couldn't return anything sensible for k.max and k.min, because C
double doesn't have enough precision or range to represent the max and min
(or epsilon or ...) double-extended values.  But a double-extended float can.

> Naming is going to be confusing no matter what we do. We're starting
> with Python "float" == C "double" == Numeric Float == typecode 'd'.
> We're doomed...

You can break that here, though.  Are these kinds utterly distinct types, or
merely different flavors of a single float type?  I assumed the latter (BTW,
the PEP really isn't clear about how kinds work in Python's type system), in
which case there's no problem saying that (for example)

    float_kind(1, 10)

builds floats of the single flavor,

    float_kind(1, 100)

builds floats of the double flavor, and

    float_kind(1, 1000)

builds floats of the extended or quad flavor.  Etc.  Since there is only one
kind of float in (base; non-NumPy) Python today, the need for distinctions
hasn't arisen.  But once a need arises, it seems downright natural to
continue calling all of them floats, but with a kind qualifier indicating
relative precision and/or range.  Then qualifiers like "single", "double",
"quad", "extended" and "unbounded" make intuitive sense to people, and that's
Good.  "float" implies something about size only to C programmers (much like
"real" implies something about size only to Fortran programmers).






From guido at digicool.com  Mon Apr  9 15:41:22 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 08:41:22 -0500
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Mon, 09 Apr 2001 13:26:47 +1200."
             <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> 
References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> 
Message-ID: <200104091341.IAA00888@cj20424-a.reston1.va.home.com>

> I'd vote for building it right into the interpreter! Is
> there any reason why anyone would want *not* to have it?

No, but (as has been explained) fixing the parser isn't enough -- all
tools dealing with source would have to be fixed.  Or we would have to
write our own C-level file object, which has its own drawbacks.

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



From Paul.Moore at uk.origin-it.com  Mon Apr  9 15:36:34 2001
From: Paul.Moore at uk.origin-it.com (Moore, Paul)
Date: Mon, 9 Apr 2001 14:36:34 +0100 
Subject: [Python-Dev] A kind of configuration question
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AE08@ukrux002.rundc.uk.origin-it.com>

From: Guido van Rossum [mailto:guido at digicool.com]
> > On a related note, has anything happened on my other bug 
> > report (406280)? At the very least, using tempfilepager
> > instead of pipepager as a workaround would be sensible.
> > Leaving things broken makes no real sense. This is a
> > patch:
> 
> What's broken?  After "from pydoc import help" I can use help(...)
> just fine, both in the command line version (where it invokes some
> pager) and in IDLE (where it just scrolls off the window, but IDLE has
> infinite scroll-back so that's no problem).  This is on Win98se with
> Python 2.1b2.

It doesn't work in console version python.exe if you set PAGER in the
environment. I have PAGER set to "less", a much better replacement for
"more". This is on Win2000 SP1.

It works if you leave PAGER unset.

Please can this bug-fix be applied before 2.1 release? It makes it look like
pydoc just "doesn't work", as things stand. And the link to having PAGER set
is obscure, at best.

Paul.



From info at webb2e.com  Mon Apr  9 20:35:09 2001
From: info at webb2e.com (info at webb2e.com)
Date: Mon, 9 Apr 2001 11:35:09 -0700
Subject: [Python-Dev] Free register of online company's profile
Message-ID: <051071035180941MAIL@mail3.chinainfoland.com>

How much are you paying to advertise your business to the world? 

Expose Your service to the world with bold register of online business
profile. Sign up today! 

Introducing WebB2E.com -- your direct link to global information; source
of business, products, education/research, social/culture, entertainment
and travel... 
Additionally you can BUY, SELL or PROMOTE your products and services 
At www.webb2e.com <http://webb2e.com/promo1.asp>  you'll get: 

--Message center (open to the public). 
--Employment center. 
--Sponsorship center. 
--Bulletin board (business and service issue). 
--Flexible Online Office (Business Online Report). 
--Economic news. 
--View thousands of trade leads. 
--Post business propositions. 
--Merchandise marketing (Vast advertising at a low cost). 
--World shopping center. 

.. and much more. Please visit www.webb2e.com
<http://webb2e.com/promo1.asp>  

If you do not want to recieve any more e-mails from WebB2E.com and wish
to be removed from e-mail list please click here
<http://webb2e.net/remove.asp?email=python-dev at python.org> . 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20010409/bcb3f209/attachment.htm>

From chrishbarker at home.net  Mon Apr  9 20:47:25 2001
From: chrishbarker at home.net (Chris Barker)
Date: Mon, 09 Apr 2001 11:47:25 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> <200104091341.IAA00888@cj20424-a.reston1.va.home.com>
Message-ID: <3AD203BD.E544ED0F@home.net>

Guido van Rossum wrote:
> No, but (as has been explained) fixing the parser isn't enough -- all
> tools dealing with source would have to be fixed.  Or we would have to
> write our own C-level file object, which has its own drawbacks.


From guido at digicool.com  Mon Apr  9 22:20:13 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 15:20:13 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Mon, 09 Apr 2001 11:47:25 MST."
             <3AD203BD.E544ED0F@home.net> 
References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> <200104091341.IAA00888@cj20424-a.reston1.va.home.com>  
            <3AD203BD.E544ED0F@home.net> 
Message-ID: <200104092020.PAA02237@cj20424-a.reston1.va.home.com>

> Guido van Rossum wrote:
> > No, but (as has been explained) fixing the parser isn't enough -- all
> > tools dealing with source would have to be fixed.  Or we would have to
> > write our own C-level file object, which has its own drawbacks.
> 
> From what people have posted, it seems clear that having our own C-level
> file object is the only reasonable choice. It would take care of all the
> issues that have been brought up (both code and other text files, etc).
> Even if people have been sloppy and used binary mode for text files
> under *nix, that code would still work with *nix text files, which is
> the only way it works now anyway.
> 
> Given that something like this has been done in numerous places (JAVA,
> MATLAB, ???), It seems likely that there is some code out there that
> could be used. Hopefully there is some without licensing issues (Maybe
> Scilab or Octave, both are MATLAB clones)

I doubt that we could use anything that was done for another language,
because everybody who codes this kind of thing makes it do exactly
what their environment needs, e.g. in terms of error handling API,
functionality, and performance.

> What are the drawbacks?? (besides the below example)

The drawbacks aren't so much technical (I have a pretty good idea of
how to build such a thing), they're political and psychological.
There's the need for supporting the old way of doing things for years,
there's the need for making it easy to convert existing code to the
new way, there's the need to be no slower than the old solution,
there's the need to be at least as portable as the old solution (which
may mean implementing it *on top of* stdio since on some systems
that's all you've got).

> I'm not sure who wrote:
> > what happens under oddball systems like OpenVMS, which seem to use
> > radically different file structures for text and binary data?  I've no idea
> > what happens if you try to open a text file in binary mode under those.
> 
> Would we have to? At the Python level, you would open a text file, and
> get what you expected. The "oddball" port would have to have some
> probably very different code for the C-level file object, but that's
> presumable the case anyway. what happens when you want to read a
> non-native text file on those systems now? So you have to read it as
> binary?
> 
> By the way, does any of this tie in at all with trying to add Perl-like
> speed to processing text files?

It would be one way towards that goal.  But notice that we've already
gotten most of the way there with the recent readline changes in 2.1.

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



From just at letterror.com  Mon Apr  9 22:00:22 2001
From: just at letterror.com (Just van Rossum)
Date: Mon,  9 Apr 2001 22:00:22 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104092020.PAA02237@cj20424-a.reston1.va.home.com>
Message-ID: <20010409220023-r01010600-7dc11706@213.84.27.177>

Proposal for 2.2, outline for a PEP?


1)
The Python file object needs to be modified so that in text mode it can
recognize all major line ending conventions (Unix, Win and Mac).

Reading data:
  - recognize \n, \r and \r\n as line ending, present as \n to Python
Writing data:
  - convert \n to the platform line endings (this is already the case)

This modification should be _optional_, because it may break code under unix
(insert Guido's explanation here), and because it may not support oddball
systems like OpenVMS.

It should be _on_ by default under:
- Windows
- MacPython Classic
- MacPython Carbon
- Unix Python under MacOS X / Darwin

It should probably be off by default on all other systems (I think a
compile-time switch is good enough). Maybe if we advertize the potential
sloppy-unix-code-breakage loud enough we can make the feature mandatory in a
later release, however I don't see a practical way of issuing warnings for the
situation.


2)
I assume there are quite a few places where Python uses raw C text files: these
places should be identified, we should figure out how much work it is to fix
these so they behave just like the Python file object as described above.



Who would like to team up with me to write a decent PEP and maybe an example
implementation?


Just



From nhodgson at bigpond.net.au  Mon Apr  9 22:46:11 2001
From: nhodgson at bigpond.net.au (Neil Hodgson)
Date: Tue, 10 Apr 2001 06:46:11 +1000
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
References: <20010409220023-r01010600-7dc11706@213.84.27.177>
Message-ID: <007401c0c136$f7d1cb10$8119fea9@neil>

Just van Rossum:

> It should probably be off by default on all other systems (I think a
> compile-time switch is good enough). Maybe if we advertize the potential
> sloppy-unix-code-breakage loud enough we can make the feature mandatory in
a
> later release, however I don't see a practical way of issuing warnings for
the
> situation.

    It should be on by default for the Python interpreter reading Python
programs as making it off by default leads to the inability to run programs
written with Windows or Mac tools on Unix which was the problem reported by
'dsavitsk' on comp.lang.python.

   If it is going to be off by default then the error message should include
"Rerun with -f to fix this error".

   Neil





From just at letterror.com  Mon Apr  9 23:07:20 2001
From: just at letterror.com (Just van Rossum)
Date: Mon,  9 Apr 2001 23:07:20 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <007401c0c136$f7d1cb10$8119fea9@neil>
Message-ID: <20010409230721-r01010600-08aa8401@213.84.27.177>

Neil Hodgson wrote:

> Just van Rossum:
> 
> > It should probably be off by default on all other systems (I think a
> > compile-time switch is good enough). Maybe if we advertize the potential
> > sloppy-unix-code-breakage loud enough we can make the feature mandatory in
> > a later release, however I don't see a practical way of issuing warnings for
> > the situation.
> 
>     It should be on by default for the Python interpreter reading Python
> programs as making it off by default leads to the inability to run programs
> written with Windows or Mac tools on Unix which was the problem reported by
> 'dsavitsk' on comp.lang.python.

Yes, but as was mentioned before: this will lead to other problems for which we
wouldn't have a good excuse: any program printing a traceback with the traceback
module will output bogus data if linecache.py will read the source files
incorrectly. And that's just one example. I don't think the two features should
be switchable separately.

Maybe it should be on by default, provided we have a command line switch to to
turn the new behavior *off*, just like there used to be a command line switch to
revert to string based exceptions.

Just



From greg at cosc.canterbury.ac.nz  Tue Apr 10 01:56:09 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 11:56:09 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104071857.NAA23651@cj20424-a.reston1.va.home.com>
Message-ID: <200104092356.LAA12517@s454.cosc.canterbury.ac.nz>

Guido:

> code written on
> Unix with no expectation to ever leave Unix, can currently be sloppy
> about using binary mode

Maybe there should be a third mode, "extremely text mode",
which Python-source-processing utilities (and anything else
which wants to be cross-platform-line-ending-friendly) can
use.

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



From greg at cosc.canterbury.ac.nz  Tue Apr 10 02:21:36 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 12:21:36 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD203BD.E544ED0F@home.net>
Message-ID: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>

Chris Barker <chrishbarker at home.net>:

> Even if people have been sloppy and used binary mode for text files
> under *nix, that code would still work with *nix text files, which is
> the only way it works now anyway.

That's a good point. The only thing that could break is if
you opened a non-Unix file in *text* mode, and then expected
it to behave as though it had been opened in *binary* mode.
I can't imagine any code being screwy enough to do that!

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



From chrishbarker at home.net  Tue Apr 10 02:37:39 2001
From: chrishbarker at home.net (Chris Barker)
Date: Mon, 09 Apr 2001 17:37:39 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <20010409220023-r01010600-7dc11706@213.84.27.177>
Message-ID: <3AD255D3.9872C019@home.net>

Just van Rossum wrote:
> Proposal for 2.2, outline for a PEP?

Thanks, Just, for getting this rolling.

> 1)
> The Python file object needs to be modified so that in text mode it can
> recognize all major line ending conventions (Unix, Win and Mac).
> 
> Reading data:
>   - recognize \n, \r and \r\n as line ending, present as \n to Python
> Writing data:
>   - convert \n to the platform line endings (this is already the case)
> 
> This modification should be _optional_, because it may break code under unix
> (insert Guido's explanation here), and because it may not support oddball
> systems like OpenVMS.
> 
> It should be _on_ by default under:
> - Windows
> - MacPython Classic
> - MacPython Carbon
> - Unix Python under MacOS X / Darwin
> 
> It should probably be off by default on all other systems (I think a
> compile-time switch is good enough). Maybe if we advertize the potential
> sloppy-unix-code-breakage loud enough we can make the feature mandatory in a
> later release, however I don't see a practical way of issuing warnings for the
> situation.

I agree that is should be possible to turn the proposed off, but I still
think it should be on by default, even on *nix systems (which is mostly
what I use, buy the way), as it would only cause a problem for "sloppy"
code anyway. Would it be possible to have it be turned on/off at
runtime, rather than compile time ? It would be pretty awkward to have a
program need a specific version of the interpreter to run. Even a
command line flag could be awkward enough, then only the main program
could specify the flag, and modules might not be compatible.

Another option is for the new version to have another flag or set of
flags to the open command, which would indicate that the file being
opened is "Unix", "Mac", "DOS", or "Any". this would make it easy to
write text files in a non-native format, as well as read them.

Even if we didn't go that far, we could use the "t" flag (analogous to
"b" for binary), to specify the universal text format, and the default
would still be the current, native format. This would keep the "sloppy"
*nix code from breaking, and still give full functionality to new code.

While we are at it, what would get written is something we need to
consider. If we just have the above proposal, reading a file would work
great, it could be on a server with a different line ending format, and
that would be transparent. Writing, on the other hand is an issue. If a
program is running on a windows box, and writing a file on a *nix
server, what kind of line ending should it write? Would it even know
what the native format is on the server? It seems we would need to be
able to specify the line ending format explicitly for writing.

Just a few thoughts, maybe we'll get a PEP out of this after all!

-Chris







-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------



From greg at cosc.canterbury.ac.nz  Tue Apr 10 02:29:42 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 12:29:42 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD203BD.E544ED0F@home.net>
Message-ID: <200104100029.MAA12528@s454.cosc.canterbury.ac.nz>

Disregard what I just said. The problem isn't about reading
text files at all, it's about reading non-text files without
explicitly opening them in binary mode.

I think the trouble is with the idea that if you don't
specify the mode explicitly it defaults to text mode, which
on Unix just happens to be the same as binary mode.

Could we change that so binary mode is the default on
Unix, and if you want any line ending translation, you
have to specify text mode explicitly? Is there any standard
which says that text mode must be the default?

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



From chrishbarker at home.net  Tue Apr 10 02:47:34 2001
From: chrishbarker at home.net (Chris Barker)
Date: Mon, 09 Apr 2001 17:47:34 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>
Message-ID: <3AD25826.8C95D0AB@home.net>

Greg Ewing wrote:
> Chris Barker <chrishbarker at home.net>:
> > Even if people have been sloppy and used binary mode for text files
> > under *nix, that code would still work with *nix text files, which is
> > the only way it works now anyway.
> 
> That's a good point. The only thing that could break is if
> you opened a non-Unix file in *text* mode, and then expected
> it to behave as though it had been opened in *binary* mode.
> I can't imagine any code being screwy enough to do that!

Actually, I thought about it more, and of course, Guido is right. On
*nix, if you open a binary file in text mode, it works just fine, as
there is no difference. However, under the proposed scheme, the text
mode would translate "\r" into "\n", messing up your binary data. It
would also do it only with a couple of particular byte values, so it
might not be obvious that anything is wrong right away.

I've done that myself, by mistake. I wrote a little tool that used FTP
to transfer some binary files. It worked fine under Linux, but then I
tried to run it on the Mac, and the files got corrupted. It took me WAY
too long to figure out that I had read the file in text mode.
Personally, I've always thought it was unfortunate that the default was
text mode, rather than binary, or even better, there could be no
default: you have to specify either "b" or "t", then there would be no
room for confusion.

-Chris

-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------



From greg at cosc.canterbury.ac.nz  Tue Apr 10 03:07:28 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 13:07:28 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD255D3.9872C019@home.net>
Message-ID: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz>

Chris Barker <chrishbarker at home.net>:

> If a program is running on a windows box, and writing a file on a *nix
> server, what kind of line ending should it write? Would it even know
> what the native format is on the server? It seems we would need to be
> able to specify the line ending format explicitly for writing.

Yes, I think that's the best that can be done. To do any better
would require all file servers to be aware of the text/binary
distinction and be willing to translate, and for there to be
some way for the Python file object to communicate to the OS
which mode is intended. Neither of these things are true in
general.

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



From greg at cosc.canterbury.ac.nz  Tue Apr 10 03:18:25 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 13:18:25 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD25826.8C95D0AB@home.net>
Message-ID: <200104100118.NAA12540@s454.cosc.canterbury.ac.nz>

Chris Barker <chrishbarker at home.net>:

> It took me WAY
> too long to figure out that I had read the file in text mode.

My favourite way of falling into that trap involves AUFS
(the Appleshare Unix File Server). You're browsing the web
on a Unix box and come across a juicy-looking Stuffit file.
You download it into your AUFS directory, hop over to the
Mac and feed it to Stuffit Expander, which promptly throws
a wobbly.

"Shazbot," you mutter, "it got corrupted in the download
somehow." You try a couple more times, with the same result.
You're just about to write to the web site maintainer telling
them that their file is corrupt, when it dawns on you that:

(a) AUFS performs CR/LF translation on files whose Mac
type code is 'TEXT';

(b) Unix-created files default to type 'TEXT'.

(Sorry, not really Python-related. Pretend you've implemented
your Stuffit expander in Python...)

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



From guido at digicool.com  Tue Apr 10 04:32:51 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:32:51 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Tue, 10 Apr 2001 12:21:36 +1200."
             <200104100021.MAA12524@s454.cosc.canterbury.ac.nz> 
References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz> 
Message-ID: <200104100232.VAA03655@cj20424-a.reston1.va.home.com>

> Chris Barker <chrishbarker at home.net>:
> 
> > Even if people have been sloppy and used binary mode for text files
> > under *nix, that code would still work with *nix text files, which is
> > the only way it works now anyway.
> 
> That's a good point. The only thing that could break is if
> you opened a non-Unix file in *text* mode, and then expected
> it to behave as though it had been opened in *binary* mode.
> I can't imagine any code being screwy enough to do that!

Actually, that *is* the scenario I'm worried about.  Someone can open
a GIF file in text mode today on a Unix platform and it'll just work
(until they port the program to another platform, that is. ;-).  So
Unix weenies haven't had much of an incentive (or warning) about using
binary mode properlu.

In text translation mode, if there happen to be bytes with values 0x0d
in the file, they will be mangled.

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



From guido at digicool.com  Tue Apr 10 04:33:53 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:33:53 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Tue, 10 Apr 2001 12:29:42 +1200."
             <200104100029.MAA12528@s454.cosc.canterbury.ac.nz> 
References: <200104100029.MAA12528@s454.cosc.canterbury.ac.nz> 
Message-ID: <200104100233.VAA03669@cj20424-a.reston1.va.home.com>

> Disregard what I just said. The problem isn't about reading
> text files at all, it's about reading non-text files without
> explicitly opening them in binary mode.

What I said. :-)

> I think the trouble is with the idea that if you don't
> specify the mode explicitly it defaults to text mode, which
> on Unix just happens to be the same as binary mode.
> 
> Could we change that so binary mode is the default on
> Unix, and if you want any line ending translation, you
> have to specify text mode explicitly? Is there any standard
> which says that text mode must be the default?

It's pretty clear that the default is text mode.  But we could add a
new mode character, 't', to force text mode on.

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



From guido at digicool.com  Tue Apr 10 04:39:36 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:39:36 -0500
Subject: [Python-Dev] Release schedule heads up
Message-ID: <200104100239.VAA03697@cj20424-a.reston1.va.home.com>

We're planning the release candidate for 2.1 early this Friday (the
13th :-).  We need to have all changes ready early Thursday.

Then we plan to release the final version Monday the 16th, complete
with a press release and all!

The final release should be identical to the release candidate if all
goes well.

Between now and Thursday, only the most important bugs should be
fixed.  For anything else, please hold off till after 2.1final is
released!

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



From guido at digicool.com  Tue Apr 10 04:41:54 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:41:54 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Tue, 10 Apr 2001 13:07:28 +1200."
             <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> 
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> 
Message-ID: <200104100241.VAA03714@cj20424-a.reston1.va.home.com>

> > If a program is running on a windows box, and writing a file on a *nix
> > server, what kind of line ending should it write? Would it even know
> > what the native format is on the server? It seems we would need to be
> > able to specify the line ending format explicitly for writing.
> 
> Yes, I think that's the best that can be done. To do any better
> would require all file servers to be aware of the text/binary
> distinction and be willing to translate, and for there to be
> some way for the Python file object to communicate to the OS
> which mode is intended. Neither of these things are true in
> general.

You might need to be able to specify a specific line ending format,
but there should also be a default -- and it should be the default
appropriate to the OS.  So, \n on Unix, \r\n on Windows, \r on Mac
running in "Mac mode", and \n on MacOS X running in "Unix mode".

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



From jwblist at olympus.net  Tue Apr 10 08:47:44 2001
From: jwblist at olympus.net (John W Baxter)
Date: Mon, 9 Apr 2001 23:47:44 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do
 end-of-line conversion?
In-Reply-To: <200104100241.VAA03714@cj20424-a.reston1.va.home.com>
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz>
 <200104100241.VAA03714@cj20424-a.reston1.va.home.com>
Message-ID: <p05100903b6f85ba98f1b@[207.149.192.229]>

At 21:41 -0500 4/9/01, Guido van Rossum wrote:
>You might need to be able to specify a specific line ending format,
>but there should also be a default -- and it should be the default
>appropriate to the OS.  So, \n on Unix, \r\n on Windows, \r on Mac
>running in "Mac mode", and \n on MacOS X running in "Unix mode".

Is it the same in Mac OS X when reading a file from a UFS volume as from an
HFS(+) volume?

Only if the underlying libraries make it so.  (Typing in Mac OS X, but I
don't have any UFS volumes lying around.)

It's a little scary to contemplate that reading two different files, which
happen to be on the same disk spindle, will behave differently for the file
on the HFS+ volume than for the file on the UFS volume.  [There are perhaps
similar issues for our Linux friends who mount Windows volumes.]

What ever happened to "move text files to another system using FTP in ASCII
mode?"  Ah, yes...it probably died of Unicode.

  --John (there may no be any answers for this) Baxter
-- 
John Baxter   jwblist at olympus.net      Port Ludlow, WA, USA



From moshez at zadka.site.co.il  Tue Apr 10 08:52:11 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Tue, 10 Apr 2001 09:52:11 +0300
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>
References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>
Message-ID: <E14ms0Z-0000kP-00@darjeeling>

On Tue, 10 Apr 2001, Greg Ewing <greg at cosc.canterbury.ac.nz> wrote:
 
> That's a good point. The only thing that could break is if
> you opened a non-Unix file in *text* mode, and then expected
> it to behave as though it had been opened in *binary* mode.
> I can't imagine any code being screwy enough to do that!

Then you've got another thing coming. Most UNIXers aren't aware
that the 'b' modifier exists: open(file) opens the file, whether
it is text or binary.
-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From ping at lfw.org  Tue Apr 10 13:32:32 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 04:32:32 -0700 (PDT)
Subject: [Python-Dev] SocketServer and UserDict patches
Message-ID: <Pine.LNX.4.10.10104100406540.26105-100000@localhost>

Hello all,

I'd like to call your attention to two small patches that i would
like to check in for the 2.1 RC.  They're small, but they correct
breakages that i think are worth fixing.

1.  UserDict.get(), .update(), and .setdefault()

https://sourceforge.net/tracker/?func=detail&aid=413171&group_id=5470&atid=305470

    These three methods are currently implemented by calling the
    underlying object's .get(), .update(), or .setdefault() method.
    This is bad because a UserDict that overrides __getitem__ now
    will have an inconsistent or failing get() method.

    A glaring example of this is cgi.SvFormContentDict.  For such
    an object x, x['spam'] returns a single item but x.get('spam')
    returns a list of one item!

    Instead, these three methods should be implemented in terms of
    the object's own __getitem__, __setitem__, and has_key methods.
    This patch makes this change.


2.  SocketServer.StreamRequestHandler

https://sourceforge.net/tracker/?func=detail&aid=415111&group_id=5470&atid=305470

    The setup() method here duplicates the socket twice (once to
    make a read-only file, once to make a write-only file).  That
    yields three descriptors, but finish() closes only two.  This
    causes my browser to hang indefinitely waiting for the socket
    to close when SimpleHTTPServer is used to deliver a small page.

    This patch adds self.connection.close() to setup() so that
    there are just two descriptors to worry about.



-- ?!ng

"All models are wrong; some models are useful."
    -- George Box





From ping at lfw.org  Tue Apr 10 12:45:55 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 03:45:55 -0700 (PDT)
Subject: [Python-Dev] distutils.sys: None in sys.modules
Message-ID: <Pine.LNX.4.10.10104100337350.12232-100000@skuld.kingmanhall.org>

When i import distutils.util, i get:

    >>> sys.modules.keys()
    ['os', 'distutils.sys', 'distutils.os', 'exceptions', 'posix', 'distutils.spawn', 're', 'sre_constants', 'distutils.errors', 'string', 'signal', 'sre', 'posixpath', 'sre_parse', '_sre', 'os.path', 'distutils.string', 'readline', 'distutils.util', 'distutils.re', '__main__', 'distutils.dep_util', 'types', 'sys', '__builtin__', 'site', 'UserDict', 'distutils', 'sre_compile', 'copy_reg', 'stat', 'distutils.distutils']

What are 'distutils.sys', 'distutils.os', 'distutils.string',
'distutils.re', 'distutils.distutils' doing in there?  (The
sys.modules dictionary maps all these keys to None.)


-- ?!ng

"All models are wrong; some models are useful."
    -- George Box




From mal at lemburg.com  Tue Apr 10 13:43:32 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Apr 2001 13:43:32 +0200
Subject: [Python-Dev] distutils.sys: None in sys.modules
References: <Pine.LNX.4.10.10104100337350.12232-100000@skuld.kingmanhall.org>
Message-ID: <3AD2F1E4.2B61D2CD@lemburg.com>

Ka-Ping Yee wrote:
> 
> When i import distutils.util, i get:
> 
>     >>> sys.modules.keys()
>     ['os', 'distutils.sys', 'distutils.os', 'exceptions', 'posix', 'distutils.spawn', 're', 'sre_constants', 'distutils.errors', 'string', 'signal', 'sre', 'posixpath', 'sre_parse', '_sre', 'os.path', 'distutils.string', 'readline', 'distutils.util', 'distutils.re', '__main__', 'distutils.dep_util', 'types', 'sys', '__builtin__', 'site', 'UserDict', 'distutils', 'sre_compile', 'copy_reg', 'stat', 'distutils.distutils']
> 
> What are 'distutils.sys', 'distutils.os', 'distutils.string',
> 'distutils.re', 'distutils.distutils' doing in there? 

These are loaded by site.py for the case where you run Python
from the installation directory on Posix systems.

> (The
> sys.modules dictionary maps all these keys to None.)

This basically means that the corresponding modules have already
been loaded at top-level.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From ping at lfw.org  Tue Apr 10 13:55:28 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 04:55:28 -0700 (PDT)
Subject: [Python-Dev] distutils.sys: None in sys.modules
In-Reply-To: <3AD2F1E4.2B61D2CD@lemburg.com>
Message-ID: <Pine.LNX.4.10.10104100447510.26105-100000@localhost>

On Tue, 10 Apr 2001, M.-A. Lemburg wrote:
> > What are 'distutils.sys', 'distutils.os', 'distutils.string',
> > 'distutils.re', 'distutils.distutils' doing in there? 
> > (The sys.modules dictionary maps all these keys to None.)
> 
> This basically means that the corresponding modules have already
> been loaded at top-level.

But there's no 'sys' module in the distutils package.
If there were one, it would be called 'distutils.sys'
everywhere, even within the distutils package, since
we decided that packages would always use absolute
module paths, right?

This behaviour seems quite confusing to me:

    localhost[1]% ls -al foo
    total 9
    drwxr-xr-x   2 ping     users        1024 Apr 10 04:50 ./
    drwxr-xr-x  12 ping     users        5120 Apr 10 04:49 ../
    -rw-r--r--   1 ping     users           0 Apr 10 04:49 __init__.py
    -rw-r--r--   1 ping     users         106 Apr 10 04:50 __init__.pyc
    -rw-r--r--   1 ping     users          50 Apr 10 04:50 sys.py
    -rw-r--r--   1 ping     users         216 Apr 10 04:50 sys.pyc
    localhost[2]% cat foo/sys.py
    import sys, os

    print 'here is foo.sys'

    blah = 1
    localhost[3]% python -S
    Python 2.1b2 (#28, Apr 10 2001, 02:49:05) 
    [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
    Type "copyright", "credits" or "license" for more information.
    >>> import sys, foo
    >>> sys.modules.keys()
    ['__main__', '__builtin__', 'sys', 'foo', 'signal', 'exceptions']
    >>> import foo.sys
    here is foo.sys
    >>> sys.modules.keys()
    ['os.path', 'os', 'foo', 'foo.sys', 'exceptions', '__main__', 'foo.os', 'posix', 'sys', '__builtin__', 'signal', 'UserDict', 'posixpath', 'stat']
    >>> sys.modules['foo.os']
    >>> sys.modules['foo.sys']
    <module 'foo.sys' from '/home/ping/python/foo/sys.py'>
    >>> import foo.os
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ImportError: no module named 'os' could be found
    >>> import foo.sys

At this point sys.modules['foo.sys'] is a real module, as it should
be, but sys.modules['foo.os'] is None.  I don't see why 'foo.os'
should be present at all.


-- ?!ng

"All models are wrong; some models are useful."
    -- George Box




From gmcm at hypernet.com  Tue Apr 10 14:02:42 2001
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 10 Apr 2001 08:02:42 -0400
Subject: [Python-Dev] distutils.sys: None in sys.modules
In-Reply-To: <Pine.LNX.4.10.10104100337350.12232-100000@skuld.kingmanhall.org>
Message-ID: <3AD2BE22.26211.DFF74CD@localhost>

[Ka-Ping]
> 
> What are 'distutils.sys', 'distutils.os', 'distutils.string',
> 'distutils.re', 'distutils.distutils' doing in there?  (The
> sys.modules dictionary maps all these keys to None.)

Relative imports come first. Their failure is recorded so the 
next module in the package importing the same name doesn't 
go hunting for it on disk all over again.



- Gordon



From mal at lemburg.com  Tue Apr 10 14:06:47 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Apr 2001 14:06:47 +0200
Subject: [Python-Dev] distutils.sys: None in sys.modules
References: <Pine.LNX.4.10.10104100447510.26105-100000@localhost>
Message-ID: <3AD2F757.B1258004@lemburg.com>

Ka-Ping Yee wrote:
> 
> On Tue, 10 Apr 2001, M.-A. Lemburg wrote:
> > > What are 'distutils.sys', 'distutils.os', 'distutils.string',
> > > 'distutils.re', 'distutils.distutils' doing in there?
> > > (The sys.modules dictionary maps all these keys to None.)
> >
> > This basically means that the corresponding modules have already
> > been loaded at top-level.
> 
> But there's no 'sys' module in the distutils package.

The None entry is used to cache the import miss. Please see
Python/import.c for details (function mark_miss).

> If there were one, it would be called 'distutils.sys'
> everywhere, even within the distutils package, since
> we decided that packages would always use absolute
> module paths, right?
> 
> This behaviour seems quite confusing to me:
> 
>     localhost[1]% ls -al foo
>     total 9
>     drwxr-xr-x   2 ping     users        1024 Apr 10 04:50 ./
>     drwxr-xr-x  12 ping     users        5120 Apr 10 04:49 ../
>     -rw-r--r--   1 ping     users           0 Apr 10 04:49 __init__.py
>     -rw-r--r--   1 ping     users         106 Apr 10 04:50 __init__.pyc
>     -rw-r--r--   1 ping     users          50 Apr 10 04:50 sys.py
>     -rw-r--r--   1 ping     users         216 Apr 10 04:50 sys.pyc
>     localhost[2]% cat foo/sys.py
>     import sys, os
> 
>     print 'here is foo.sys'
> 
>     blah = 1
>     localhost[3]% python -S
>     Python 2.1b2 (#28, Apr 10 2001, 02:49:05)
>     [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
>     Type "copyright", "credits" or "license" for more information.
>     >>> import sys, foo
>     >>> sys.modules.keys()
>     ['__main__', '__builtin__', 'sys', 'foo', 'signal', 'exceptions']
>     >>> import foo.sys
>     here is foo.sys
>     >>> sys.modules.keys()
>     ['os.path', 'os', 'foo', 'foo.sys', 'exceptions', '__main__', 'foo.os', 'posix', 'sys', '__builtin__', 'signal', 'UserDict', 'posixpath', 'stat']
>     >>> sys.modules['foo.os']
>     >>> sys.modules['foo.sys']
>     <module 'foo.sys' from '/home/ping/python/foo/sys.py'>
>     >>> import foo.os
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>     ImportError: no module named 'os' could be found
>     >>> import foo.sys
> 
> At this point sys.modules['foo.sys'] is a real module, as it should
> be, but sys.modules['foo.os'] is None.  I don't see why 'foo.os'
> should be present at all.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From thomas at xs4all.net  Tue Apr 10 14:54:06 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Tue, 10 Apr 2001 14:54:06 +0200
Subject: [Python-Dev] INSTALL_PROGRAM
Message-ID: <20010410145406.I2820@xs4all.nl>

I just noticed that INSTALL_PROGRAM is defined as just INSTALL (either the
system "install" or the install-sh script, with possibly -c as argument)
without a -m argument (to set the mode.) INSTALL_DATA does have a -m
argument, to set the mode for all 'data' files to 644 explicitly.
INSTALL_PROGRAM gets called not just for the python executable, but also for
all files in Lib/ that have their executable bit set. Because
INSTALL_PROGRAM does not set the mode, the files (potentially, depending on
the install program/script in question) are subject to the umask and/or the
original file mode.

I've already screwed up my Python installation on a couple of BSDI boxes
twice, before I realized what the problem was :) What about we set the mode
for executables to 755 explicitly ? Distutils seems to do the right thing,
right now, but I'm pretty sure it was screwed up before. What logic does
distutils use to figure these things out ?

(There is also INSTALL_SCRIPT, but that doesn't seem to be used anywhere.)
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at digicool.com  Tue Apr 10 15:58:39 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 08:58:39 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Mon, 09 Apr 2001 23:47:44 MST."
             <p05100903b6f85ba98f1b@[207.149.192.229]> 
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> <200104100241.VAA03714@cj20424-a.reston1.va.home.com>  
            <p05100903b6f85ba98f1b@[207.149.192.229]> 
Message-ID: <200104101358.IAA05924@cj20424-a.reston1.va.home.com>

[me]
> >You might need to be able to specify a specific line ending format,
> >but there should also be a default -- and it should be the default
> >appropriate to the OS.  So, \n on Unix, \r\n on Windows, \r on Mac
> >running in "Mac mode", and \n on MacOS X running in "Unix mode".

[JW Baxter]
> Is it the same in Mac OS X when reading a file from a UFS volume as from an
> HFS(+) volume?

I'm not sure that the volume from which you're *reading* could or
should have any influence on the default delimiter used for *writing*.
The volume you're *writing* to might, if it's easy to determine -- but
personally, I'd be happy with a default set at compile time.

> Only if the underlying libraries make it so.  (Typing in Mac OS X, but I
> don't have any UFS volumes lying around.)
> 
> It's a little scary to contemplate that reading two different files, which
> happen to be on the same disk spindle, will behave differently for the file
> on the HFS+ volume than for the file on the UFS volume.  [There are perhaps
> similar issues for our Linux friends who mount Windows volumes.]

Anyway, disk spindles are the wrong abstraction level to consider
here.  Who cares about what spindle your files are on?

> What ever happened to "move text files to another system using FTP in ASCII
> mode?"  Ah, yes...it probably died of Unicode.

No, obviously it's cross-platform disk sharing.  The first time this
came up was when it became possible to mount Unix volumes on NT boxes
many years ago, and that's when Python's parser (eventually) grew the
habit of silently ignoring a \r just before a \n in a source file.

It's a sign of how backward the Mac world is that the problem only now
pops up for the Mac. :-)

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



From guido at digicool.com  Tue Apr 10 16:19:33 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 09:19:33 -0500
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: Your message of "Tue, 10 Apr 2001 04:32:32 MST."
             <Pine.LNX.4.10.10104100406540.26105-100000@localhost> 
References: <Pine.LNX.4.10.10104100406540.26105-100000@localhost> 
Message-ID: <200104101419.JAA06049@cj20424-a.reston1.va.home.com>

> I'd like to call your attention to two small patches that i would
> like to check in for the 2.1 RC.  They're small, but they correct
> breakages that i think are worth fixing.
> 
> 1.  UserDict.get(), .update(), and .setdefault()
> 
> https://sourceforge.net/tracker/?func=detail&aid=413171&group_id=5470&atid=305470
> 
>     These three methods are currently implemented by calling the
>     underlying object's .get(), .update(), or .setdefault() method.
>     This is bad because a UserDict that overrides __getitem__ now
>     will have an inconsistent or failing get() method.

I agree with the gist of this -- it should have been done the way you
propose.

>     A glaring example of this is cgi.SvFormContentDict.  For such
>     an object x, x['spam'] returns a single item but x.get('spam')
>     returns a list of one item!

But can you guarantee that fixing this so late in the release cycle
won't break anybody's code?

>     Instead, these three methods should be implemented in terms of
>     the object's own __getitem__, __setitem__, and has_key methods.
>     This patch makes this change.

I'm reluctant (-0) to making this change now.

> 
> 2.  SocketServer.StreamRequestHandler
> 
> https://sourceforge.net/tracker/?func=detail&aid=415111&group_id=5470&atid=305470
> 
>     The setup() method here duplicates the socket twice (once to
>     make a read-only file, once to make a write-only file).  That
>     yields three descriptors, but finish() closes only two.  This
>     causes my browser to hang indefinitely waiting for the socket
>     to close when SimpleHTTPServer is used to deliver a small page.
> 
>     This patch adds self.connection.close() to setup() so that
>     there are just two descriptors to worry about.

I don't think this is the right solution.  A principle I like very
much to keep my head clear about closing files is "whoever opens it
closes it".  The request/connection socket is created by a different
class, so should really be closed there.

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



From just at letterror.com  Tue Apr 10 15:20:41 2001
From: just at letterror.com (Just van Rossum)
Date: Tue, 10 Apr 2001 15:20:41 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104101358.IAA05924@cj20424-a.reston1.va.home.com>
Message-ID: <20010410152043-r01010600-eda55263@213.84.27.177>

Guido van Rossum wrote:

> It's a sign of how backward the Mac world is that the problem only now
> pops up for the Mac. :-)

I know I shouldn't bite, but I find this a very childish remark, Guido! It's
also not true... Here's an excerpt from a private thread between me, Jack and
Guido. It's dated january 8, 1996, I remember I was just learning Python. (I'll
give a translation below.)

"""
> >>     files:
> >>         is het een probleem om Mac *en* Unix files transparant te kunnen
> >>         lezen/executen? (een unix.py file veroorzaakt vreemde
> >>         error...)

(Ik neem aan dat je bedoelt files met '\n' in plaats van '\r' als line
separator.)

> >Hmm, ik weet niet of ik dit een goed idee vindt. Weet je wat: vraag
> >eens wat Guido er van vind (met een cc-tje naar mij).

Geen goed idee, tenzij de C stdio library dit automatisch doet
(kennelijk niet dus).  Het is over het algemeel een kleine moeite dit
bij het file transport recht te trekken (ftp in text mode etc.).
"""

Translation:

"""
[Just]
>>>    files:
>>>        is it a problem to read/execute Mac *and* Unix files transparently?
>>>        (a unix.py file causes a strange error...)

[Guido]
(I take it you mean files with '\n' instead of '\r' as line separator.)

[Jack]
>> Hm, I don't know whether I think this is a good idea. You know what,
>> ask Guido what he thinks (and cc me).

[Guido]
Not a good idea, unless the C stdio library does this automatically (apparently
it doesn't). In general it's a small effort to correct this during the file
transport (ftp in text mode etc.).
"""


So it's not that the problem wasn't there, it was just not taken very seriously
at the time...

Just



From guido at digicool.com  Tue Apr 10 16:23:21 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 09:23:21 -0500
Subject: [Python-Dev] distutils.sys: None in sys.modules
In-Reply-To: Your message of "Tue, 10 Apr 2001 04:55:28 MST."
             <Pine.LNX.4.10.10104100447510.26105-100000@localhost> 
References: <Pine.LNX.4.10.10104100447510.26105-100000@localhost> 
Message-ID: <200104101423.JAA06087@cj20424-a.reston1.va.home.com>

> At this point sys.modules['foo.sys'] is a real module, as it should
> be, but sys.modules['foo.os'] is None.  I don't see why 'foo.os'
> should be present at all.

See Gordon's reply (I think Marc-Andre was off base on this one):
sys.modules['foo.sys'] is set to None to prevent every "import sys" in
submodules of the foo package to hit the disk looking for foo/sys.py.

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



From jeremy at digicool.com  Tue Apr 10 17:33:42 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Tue, 10 Apr 2001 11:33:42 -0400 (EDT)
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: <200104101419.JAA06049@cj20424-a.reston1.va.home.com>
References: <Pine.LNX.4.10.10104100406540.26105-100000@localhost>
	<200104101419.JAA06049@cj20424-a.reston1.va.home.com>
Message-ID: <15059.10198.788558.316692@slothrop.digicool.com>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

  >> A glaring example of this is cgi.SvFormContentDict.  For such an
  >> object x, x['spam'] returns a single item but x.get('spam')
  >> returns a list of one item!

  GvR> But can you guarantee that fixing this so late in the release
  GvR> cycle won't break anybody's code?

  >> Instead, these three methods should be implemented in terms of
  >> the object's own __getitem__, __setitem__, and has_key methods.
  >> This patch makes this change.

  GvR> I'm reluctant (-0) to making this change now.

I with you, Guido.  The cgi model is complicated and widely used.
That combination means that it would be easy for users to get the
impression that x['spam'] and x.get('spam') work the way they do
intentionally.  I'm not comfortable changing the behavior of the model
without a beta release.

Jeremy




From chrishbarker at home.net  Tue Apr 10 20:13:56 2001
From: chrishbarker at home.net (Chris Barker)
Date: Tue, 10 Apr 2001 11:13:56 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> <200104100241.VAA03714@cj20424-a.reston1.va.home.com>  
	            <p05100903b6f85ba98f1b@[207.149.192.229]> <200104101358.IAA05924@cj20424-a.reston1.va.home.com>
Message-ID: <3AD34D64.7F66DF52@home.net>

Guido van Rossum wrote:
> No, obviously it's cross-platform disk sharing.  The first time this
> came up was when it became possible to mount Unix volumes on NT boxes

I'm sure it came up before that, I know it has for me, and I don't
happen to do any cross platform disk sharing. It is just a little more
soluble if you aren't doing disk sharing.

> many years ago, and that's when Python's parser (eventually) grew the
> habit of silently ignoring a \r just before a \n in a source file.

It can do that? I had no idea. Probably because I work on the Mac and
Linux almost exclusively, and hardly ever encounter a Windows box.
 
> It's a sign of how backward the Mac world is that the problem only now
> pops up for the Mac. :-)

Actually it's a sign of how *nix/Windows focused Python is. It's sad to
see that someone thought to fix the problem for *nix/Windows, and didn't
even consider the Mac (as Just pointed out the problem has been know for
a long time). Frankly, it's also a symptom the the isolationist attitude
of a lot of Mac users/developers. and Don't get me started on the spaces
vs tabs thing!


Just,

Are you planning on putting together a PEP from all of this? I'd really
like to see this happen!

-Chris




-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------



From barry at digicool.com  Tue Apr 10 20:32:35 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Tue, 10 Apr 2001 14:32:35 -0400
Subject: [Python-Dev] SocketServer and UserDict patches
References: <Pine.LNX.4.10.10104100406540.26105-100000@localhost>
	<200104101419.JAA06049@cj20424-a.reston1.va.home.com>
	<15059.10198.788558.316692@slothrop.digicool.com>
Message-ID: <15059.20931.149158.432871@anthem.wooz.org>

>>>>> "JH" == Jeremy Hylton <jeremy at digicool.com> writes:

    JH> I with you, Guido.  The cgi model is complicated and widely
    JH> used.  That combination means that it would be easy for users
    JH> to get the impression that x['spam'] and x.get('spam') work
    JH> the way they do intentionally.  I'm not comfortable changing
    JH> the behavior of the model without a beta release.

I'd be reluctant to change the cgi module's behavior /at all/ at this
point.  As broken as cgi.py is (and it is pretty broken), I think
you'll break a lot of code by changing its quirky API.  Better to
design a new API and write a new module.

-Barry



From ping at lfw.org  Tue Apr 10 21:46:08 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 12:46:08 -0700 (PDT)
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: <200104101419.JAA06049@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10104101006250.641-100000@skuld.kingmanhall.org>

On Tue, 10 Apr 2001, Guido van Rossum wrote:
> > 1.  UserDict.get(), .update(), and .setdefault()
[...]
> I agree with the gist of this -- it should have been done the way you
> propose.
[...]
> But can you guarantee that fixing this so late in the release cycle
> won't break anybody's code?

Right, obviously i can't.  Here are some thoughts:
(Nonetheless i do agree it's a bit late to notice this.)

    1.  All the standard tests pass with this change (though
        of course that's a small sample).

    2.  It's hard to imagine someone's code depending on this
        particular bug (i think i can justify calling it a bug).
        Anyone who wrote a UserDict-derived class that actually
        intended to use "get" most likely had to work around it
        anyway, to get any reasonable sort of result.

    3.  Would you consider allowing the addition of a get()
        method just to cgi.SvFormContentDict to fix its behaviour?
        (The broken get() behaviour was present for this particular
        class in 2.0 but not in 1.5.2.)


> > 2.  SocketServer.StreamRequestHandler
[...]
> I don't think this is the right solution.  A principle I like very
> much to keep my head clear about closing files is "whoever opens it
> closes it".  The request/connection socket is created by a different
> class, so should really be closed there.

Good point.  How about adding to BaseServer.handle_request instead?

    def handle_request(self):
        """Handle one request, possibly blocking."""
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                self.process_request(request, client_address)
            except:
                self.handle_error(request, client_address)
  +     request.close()

I forgot to mention that this is a testable and observable fix
(Netscape gets stuck in Linux and IE gets stuck in Win2K without
the fix, and both work properly when i make this fix.)

Note that this makes explicit the division of responsibilities
that, if the request handler wants to continue dealing with the
request connection after its constructor returns (as in the
case of the forking and threading variants), it must duplicate
its own copy of the file descriptor (which it already does).
I think this is good, as then each file descriptor can be
associated with a clear owner.


-- ?!ng

"Don't worry about people stealing an idea.  If it's original, you'll
have to jam it down their throats."
    -- Howard Aiken




From guido at digicool.com  Tue Apr 10 22:45:35 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 15:45:35 -0500
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: Your message of "Tue, 10 Apr 2001 12:46:08 MST."
             <Pine.LNX.4.10.10104101006250.641-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10104101006250.641-100000@skuld.kingmanhall.org> 
Message-ID: <200104102045.PAA07295@cj20424-a.reston1.va.home.com>

> On Tue, 10 Apr 2001, Guido van Rossum wrote:
> > > 1.  UserDict.get(), .update(), and .setdefault()
> [...]
> > I agree with the gist of this -- it should have been done the way you
> > propose.
> [...]
> > But can you guarantee that fixing this so late in the release cycle
> > won't break anybody's code?
> 
> Right, obviously i can't.  Here are some thoughts:
> (Nonetheless i do agree it's a bit late to notice this.)
> 
>     1.  All the standard tests pass with this change (though
>         of course that's a small sample).
> 
>     2.  It's hard to imagine someone's code depending on this
>         particular bug (i think i can justify calling it a bug).
>         Anyone who wrote a UserDict-derived class that actually
>         intended to use "get" most likely had to work around it
>         anyway, to get any reasonable sort of result.
> 
>     3.  Would you consider allowing the addition of a get()
>         method just to cgi.SvFormContentDict to fix its behaviour?
>         (The broken get() behaviour was present for this particular
>         class in 2.0 but not in 1.5.2.)

Let's just fix this after releasing 2.1, OK?  As you say, it's
unlikely that this affects anybody one way or the other, and right now
I'm for stability in favor of fixing warts (believe me, I have a few
other favorite warts that I won't fix before releasing 2.1 :-).

> 
> > > 2.  SocketServer.StreamRequestHandler
> [...]
> > I don't think this is the right solution.  A principle I like very
> > much to keep my head clear about closing files is "whoever opens it
> > closes it".  The request/connection socket is created by a different
> > class, so should really be closed there.
> 
> Good point.  How about adding to BaseServer.handle_request instead?
> 
>     def handle_request(self):
>         """Handle one request, possibly blocking."""
>         try:
>             request, client_address = self.get_request()
>         except socket.error:
>             return
>         if self.verify_request(request, client_address):
>             try:
>                 self.process_request(request, client_address)
>             except:
>                 self.handle_error(request, client_address)
>   +     request.close()

Alas, this is still at the wrong level.  The get_request() method is
overridable (e.g. by the UDPServer class) and the request that it
returns may not have a close method.  The best I can come up with is
to add an empty method self.close_request(request) to the base class,
call it in handle_request(), and override it to call request.close()
in the TCPServer class.

> I forgot to mention that this is a testable and observable fix
> (Netscape gets stuck in Linux and IE gets stuck in Win2K without
> the fix, and both work properly when i make this fix.)

I believe you -- I've noticed weird slownesses when using
SimpleHTTPServer.

> Note that this makes explicit the division of responsibilities
> that, if the request handler wants to continue dealing with the
> request connection after its constructor returns (as in the
> case of the forking and threading variants), it must duplicate
> its own copy of the file descriptor (which it already does).
> I think this is good, as then each file descriptor can be
> associated with a clear owner.

No argument there!

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



From guido at digicool.com  Tue Apr 10 23:47:08 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 16:47:08 -0500
Subject: [Python-Dev] SourceForge search-by-ID implemented
Message-ID: <200104102147.QAA07642@cj20424-a.reston1.va.home.com>

I received the email below from the friendly folks at SourceForge --
you can now search bugs and patches by number.  Cool!

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

------- Forwarded Message

Date:    Tue, 10 Apr 2001 19:45:55 +0300
From:    Paul Sokolovsky <pfalcon at sourceforge.net>
To:      Guido van Rossum <guido at python.org>
Subject: Fwd: [alexandria - Feature Requests] ANN: search artifacts (bugs etc.)
	   by #

Hello Guido,

      I would like to notify that another of your feature requests
for SourceForge has been done. Sorry that it took so much time -
search is one of the most straining parts of the site, and there was a
marathory for any changes to it...

This is a forwarded message
From: noreply at sourceforge.net <noreply at sourceforge.net>
To: noreply at sourceforge.net <noreply at sourceforge.net>
Subject: [alexandria - Feature Requests] ANN: search artifacts (bugs etc.) by #

===8<==============Original message text===============

Read and respond to this message at:
http://sourceforge.net/forum/message.php?msg_id=137990
By: pfalcon

There were many request to allow to display bugs, support requests, etc. by
their number, having typed it into search box. Finally, it's here. By typing
digit sequence, optionally preceeded by #, you'll get that item (in addition
to items where that string present literally, of course).


Enjoy!



______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge and visit:
http://sourceforge.net/forum/monitor.php?forum_id=4


===8<===========End of original message text===========



- --
Paul Sokolovsky,        http://sourceforge.net/users/pfalcon
SourceForge developer   http://sourceforge.net


------- End of Forwarded Message




From nas at python.ca  Tue Apr 10 23:08:55 2001
From: nas at python.ca (Neil Schemenauer)
Date: Tue, 10 Apr 2001 14:08:55 -0700
Subject: [Python-Dev] SourceForge search-by-ID implemented
In-Reply-To: <200104102147.QAA07642@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 10, 2001 at 04:47:08PM -0500
References: <200104102147.QAA07642@cj20424-a.reston1.va.home.com>
Message-ID: <20010410140854.B31183@glacier.fnational.com>

Guido van Rossum wrote:
> I received the email below from the friendly folks at SourceForge --
> you can now search bugs and patches by number.  Cool!

Yah!  This reminds me of something the Debian bug tracking system
does that is really cool.  If you include the string "Fixes: #123"
in the changelog the bug system will notice and close the bug for
you.

I don't think SourceForge should implement this feature.
Instead, some ambitious person could write a script that watches
the CVS checkin list and interact with the sourceforge site.  The
script could also add a comment to the bug logging who fixed it
and the versions of the files changed.  That information is
probably useful when trying to bugfix release.

  Neil



From ping at lfw.org  Wed Apr 11 03:06:36 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 18:06:36 -0700 (PDT)
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: <200104102045.PAA07295@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10104101746580.641-100000@skuld.kingmanhall.org>

On Tue, 10 Apr 2001, Guido van Rossum wrote:
> > > > 1.  UserDict.get(), .update(), and .setdefault()
[...]
> Let's just fix this after releasing 2.1, OK?

Okay.

> As you say, it's
> unlikely that this affects anybody one way or the other

True, it is largely about people writing *new* scripts conveniently.

> > > > 2.  SocketServer.StreamRequestHandler
[...]
> Alas, this is still at the wrong level.  The get_request() method is
> overridable (e.g. by the UDPServer class) and the request that it
> returns may not have a close method.  The best I can come up with is
> to add an empty method self.close_request(request) to the base class,
> call it in handle_request(), and override it to call request.close()
> in the TCPServer class.

Yes, i agree that's a good division of responsibilities.  See the
updated patch.  I think it would be nice if it could go in, but it's
up to you if you want to accept it.


-- ?!ng

"Don't worry about people stealing an idea.  If it's original, you'll
have to jam it down their throats."
    -- Howard Aiken





From guido at digicool.com  Wed Apr 11 05:29:31 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 22:29:31 -0500
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: Your message of "Tue, 10 Apr 2001 18:06:36 MST."
             <Pine.LNX.4.10.10104101746580.641-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10104101746580.641-100000@skuld.kingmanhall.org> 
Message-ID: <200104110329.WAA11332@cj20424-a.reston1.va.home.com>

> > > > > 2.  SocketServer.StreamRequestHandler
> [...]
> > Alas, this is still at the wrong level.  The get_request() method is
> > overridable (e.g. by the UDPServer class) and the request that it
> > returns may not have a close method.  The best I can come up with is
> > to add an empty method self.close_request(request) to the base class,
> > call it in handle_request(), and override it to call request.close()
> > in the TCPServer class.
> 
> Yes, i agree that's a good division of responsibilities.  See the
> updated patch.  I think it would be nice if it could go in, but it's
> up to you if you want to accept it.

I've accepted this and assigned it to you.  That means that *you*
should check it in!  (This is so that the CVS logs show the author of
the patch.)

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



From tim.one at home.com  Wed Apr 11 06:20:42 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 11 Apr 2001 00:20:42 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <3AD34D64.7F66DF52@home.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEGKJLAA.tim.one@home.com>

[Guido]
>> ...
>> that's when Python's parser (eventually) grew the habit of
>> silently ignoring a \r just before a \n in a source file.

[Chris Barker]
> It can do that? I had no idea. Probably because I work on the Mac and
> Linux almost exclusively, and hardly ever encounter a Windows box.

>> It's a sign of how backward the Mac world is that the problem only
>> now pops up for the Mac. :-)

> Actually it's a sign of how *nix/Windows focused Python is. It's sad
> to see that someone thought to fix the problem for *nix/Windows, and
> didn't even consider the Mac (as Just pointed out the problem has
> been know for a long time).

This is a reversal of history.  The code to ignore
    \r
when seeing
    \r\n
originally (1995) applied to *all* platforms.  I don't know why, but Jack
submitted a patch to disable this behavior only when "#ifdef macintosh", in
revision 2.29 of Parser/tokenizer.c, about 4 years ago.  The #ifdef
introduced then still exists today; 3 lines introduced by that patch start
with XXX here for clarity (appropriately defined <wink>):

XXX #ifndef macintosh
			/* replace "\r\n" with "\n" */
XXX			/* For Mac we leave the \r, giving a syntax error */
			pt = tok->inp - 2;
			if (pt >= tok->buf && *pt == '\r') {
				*pt++ = '\n';
				*pt = '\0';
				tok->inp = pt;
			}
XXX #endif

I have no idea what Mac C libraries return for text-mode reads.  They must
convert \r to \n, right?  In which case I guess any \r remaining *should* be
"an error" (but where would it come from, if the C library converts all \r
thingies?).  Do they leave \n alone?  Etc:  submit a patch that makes the
code above "work", and I'm sure it would be accepted, but a non-Mac person
can't guess what's needed.

As to "considering the Mac", guilty as charged:  I don't know anything about
it.  What's to consider?  How often do you consider the impact of chnages on,
say, OpenVMS?  Same thing, provided you're as ignorant of it as I am of your
system.

> Frankly, it's also a symptom the the isolationist attitude of a
> lot of Mac users/developers. and Don't get me started on the spaces
> vs tabs thing!

The std for distributed Python code is 4-space indents, no hard tab
characters.  So there's nothing left there to get started on <wink>.

it's-not-that-we-don't-want-to-"fix"-macs-it's-that-we-don't-know-
    how-macs-work-or-what-"fix"-*means*-to-a-macizoid-ly y'rs  - tim




From just at letterror.com  Wed Apr 11 12:03:27 2001
From: just at letterror.com (Just van Rossum)
Date: Wed, 11 Apr 2001 12:03:27 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEGKJLAA.tim.one@home.com>
Message-ID: <20010411120330-r01010600-75da8509@213.84.27.177>

Tim Peters wrote:

> This is a reversal of history.  The code to ignore
>     \r
> when seeing
>     \r\n
> originally (1995) applied to *all* platforms.  I don't know why, but Jack
> submitted a patch to disable this behavior only when "#ifdef macintosh", in
> revision 2.29 of Parser/tokenizer.c, about 4 years ago.  The #ifdef
> introduced then still exists today; 3 lines introduced by that patch start
> with XXX here for clarity (appropriately defined <wink>):

Interesting, I didn't know that. Jack's on holiday now, so he won't be able to
comment for a while.

> I have no idea what Mac C libraries return for text-mode reads.  They must
> convert \r to \n, right? 

Yes.

> In which case I guess any \r remaining *should* be
> "an error" (but where would it come from, if the C library converts all \r
> thingies?).  Do they leave \n alone? 

Nope: \r's get translated to \n and for whatever reason \n's get translated to
\r... So when opening a unix file on the Mac, it will look like it has \r line
endings and when opening a Windows text file on the Mac, it will appear as if it
has \n\r line endings...

> Etc:  submit a patch that makes the
> code above "work", and I'm sure it would be accepted, but a non-Mac person
> can't guess what's needed.

That's probably easy enough -- although would require changing all tokenizer
code that looks for \n to also look for \r, including PyOS_ReadLine(), so it
goes well beyond the snippet you posted. And then there's the Python file
object...

Just



From tim.one at home.com  Thu Apr 12 00:15:01 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 11 Apr 2001 18:15:01 -0400
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Lib/test test_math.py,1.10,1.11 test_fork1.py,1.8,1.9 test_fcntl.py,1.16,1.17
In-Reply-To: <E14nRh0-0003EH-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEJJJLAA.tim.one@home.com>

> Update of /cvsroot/python/python/dist/src/Lib/test
> In directory usw-pr-cvs1:/tmp/cvs-serv12386
>
> Modified Files:
> 	test_math.py test_fork1.py test_fcntl.py
> Log Message:
> Unixware 7 support by Billy G. Allie (SF patch 413011)
> ...
> ***************
> *** 36,40 ****
>   testit('atan2(-1, 0)', math.atan2(-1, 0), -math.pi/2)
>   testit('atan2(-1, 1)', math.atan2(-1, 1), -math.pi/4)
> ! testit('atan2(0, 1)', math.atan2(0, 1), 0)
>   testit('atan2(1, 1)', math.atan2(1, 1), math.pi/4)
>   testit('atan2(1, 0)', math.atan2(1, 0), math.pi/2)
> --- 37,44 ----
>   testit('atan2(-1, 0)', math.atan2(-1, 0), -math.pi/2)
>   testit('atan2(-1, 1)', math.atan2(-1, 1), -math.pi/4)
> ! if sys.platform in ['unixware7']:
> !     testit('atan2(0, 1)', math.atan2(0, 1), math.pi)
> ! else:
> !     testit('atan2(0, 1)', math.atan2(0, 1), 0)
>   testit('atan2(1, 1)', math.atan2(1, 1), math.pi/4)
>   testit('atan2(1, 0)', math.atan2(1, 0), math.pi/2)

atan2(0, 1) should be 0 on *all* platforms.  It's too bad if the original
test fails on unixware7, but if it does it means their libm's atan2() is
buggy.  C99 spells this out in excruciating detail.  C89 isn't as clear, but
is clear enough:

    The atan2(y, x) function computes the principal value of the
    arc tangent of y/x, using the signs of both arguments to
    determine the quadrant of the return value.  A domain
    error may occur if both arguments are 0.

IOW, atan2 returns the angle with x-axis made by a unit vector from the
origin to the point (x, y).  The point (1, 0) lies on the x axis, pointing to
the right, so is at an angle of 0.  The only question is whether it should be
+0 or -0, and while C99 spells that out too, Python's test doesn't
distinguish those cases so we don't have to answer that here.

So, if nobody leaps to defend unixware7, I'm going to revert that part of the
patch.




From mwh21 at cam.ac.uk  Thu Apr 12 00:31:48 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 11 Apr 2001 23:31:48 +0100
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/plat-unixware7 FCNTL.py,NONE,1.1 IN.py,NONE,1.1 SOCKET.py,NONE,1.1 STROPTS.py,NONE,1.1 TERMIOS.py,NONE,1.1 regen,NONE,1.1
In-Reply-To: Guido van Rossum's message of "Wed, 11 Apr 2001 13:54:46 -0700"
References: <E14nRdW-00032q-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <m3ae5nrru3.fsf@atrus.jesus.cam.ac.uk>

Guido van Rossum <gvanrossum at users.sourceforge.net> writes:

> Update of /cvsroot/python/python/dist/src/Lib/plat-unixware7
> In directory usw-pr-cvs1:/tmp/cvs-serv11682
> 
> Added Files:
> 	FCNTL.py IN.py SOCKET.py STROPTS.py TERMIOS.py regen 

Ehh... I didn't think we did TERMIOS.py or SOCKET.py any more?

Cheers,
M.




From greg at cosc.canterbury.ac.nz  Thu Apr 12 01:44:01 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Apr 2001 11:44:01 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do
In-Reply-To: <20010411120330-r01010600-75da8509@213.84.27.177>
Message-ID: <200104112344.LAA12806@s454.cosc.canterbury.ac.nz>

end-of-line conversion?

Just van Rossum <just at letterror.com>:
> Tim Peters wrote:
> > I have no idea what Mac C libraries return for text-mode reads.  They must
> > convert \r to \n, right? 
> Yes.

Unless you're using the MPW compiler, which swaps the meanings
of \r and \n in the source instead!

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



From tim.one at home.com  Thu Apr 12 02:14:19 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 11 Apr 2001 20:14:19 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010411120330-r01010600-75da8509@213.84.27.177>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com>

[Just van Rossum]
> Nope: \r's get translated to \n and for whatever reason \n's get
> translated to \r... So when opening a unix file on the Mac, it
> will look like it has \r line endings and when opening a Windows
> text file on the Mac, it will appear as if it has \n\r line endings...

Then it's probably a Good Thing Jack disabled this code, since it wouldn't
have done anything useful on a Mac anyway (for Python to ever see \r\n the
source file would have had to contain \n\r, which is nobody's text file
convention).

>> Etc:  submit a patch that makes the code above "work", and I'm
>> sure it would be accepted, but a non-Mac person can't guess
>> what's needed.

> That's probably easy enough -- although would require changing all
> tokenizer code that looks for \n to also look for \r, including
> PyOS_ReadLine(), so it goes well beyond the snippet you posted.

No, there's nothing wrong with the tokenizer code:  it's coded in C, and the
C text convention is that lines end with \n, period.  Reliance on that
convention is ubiquitous -- and properly so.  What we need instead are
platform-specific implementations of fgets() functionality, which deliver
lines containing \n where and only where the platform Python is supposed to
believe a line ends.  Then nothing else in the parser needs to be touched
(and, indeed, the current \r\n mini-hack could be thrown away).

> And then there's the Python file object...

Different issue.  If this ever gets that far, note that the crunch to speed
up line-at-a-time file input ended up *requiring* use of the native fgets()
on Windows, as that was the only way on that platform to avoid having the OS
do layers of expensive multithreading locks for each character read.  So
there's no efficient way in general to get Windows to recognize \r line
endings short of implementing our own stdio from the ground up.  On other
platforms, fileobject.c's get_line() reads one character at a time, and I
expect its test for "is this an EOL char?" could be liberalized at reasonable
cost.

OTOH, how does the new-fangled Mac OS fit into all this?  Perhaps, for
compatibility, their C libraries already recognize both Unix and Mac Classic
line conventions, and deliver plain \n endings for both?  Or did they blow
that part too <wink>?




From guido at digicool.com  Thu Apr 12 04:21:36 2001
From: guido at digicool.com (Guido van Rossum)
Date: Wed, 11 Apr 2001 21:21:36 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Wed, 11 Apr 2001 20:14:19 -0400."
             <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com> 
Message-ID: <200104120221.VAA14315@cj20424-a.reston1.va.home.com>

> Different issue.  If this ever gets that far, note that the crunch
> to speed up line-at-a-time file input ended up *requiring* use of
> the native fgets() on Windows, as that was the only way on that
> platform to avoid having the OS do layers of expensive
> multithreading locks for each character read.  So there's no
> efficient way in general to get Windows to recognize \r line endings
> short of implementing our own stdio from the ground up.  On other
> platforms, fileobject.c's get_line() reads one character at a time,
> and I expect its test for "is this an EOL char?" could be
> liberalized at reasonable cost.

I expect that the right solution here is indeed to write our own
stdio-like library from the ground up.  That can solve any number of
problems: telling how many characters are buffered (so you don't have
to use unbuffered mode when using select or poll),
platform-independent line end recognition, and super-efficient
readline() to boot.

But it's a lot of work, and won't be compatible with existing
extensions that use FILE* (not too many I believe).

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



From guido at digicool.com  Thu Apr 12 04:46:21 2001
From: guido at digicool.com (Guido van Rossum)
Date: Wed, 11 Apr 2001 21:46:21 -0500
Subject: [Python-Dev] Proposed patch to cgi.py for 2.1 -- please review!
Message-ID: <200104120246.VAA14451@cj20424-a.reston1.va.home.com>

I'd like some feedback on the patch below to cgi.py.  For background,
read SF bug #231249:

  http://sourceforge.net/tracker/?func=detail&aid=231249&group_id=5470&atid=105470

The problem is that when a POST request is received with a
Content-type of multipart/form-data, an anonymous temporary file is
created and kept open for each part -- whether or not it is a
file-upload!  For forms with many fields, this can use up more file
descriptors than the server is allowed to have.  There's no way to
tell whether a particular part is a file or not; the filename are
optional and the input field type is not available here.  My solution
uses a StringIO and transparently switches to a temporary file object
when a part grows larger than 1000 characters.

Question: does this look like it could break anything?  I know the cgi
module is used a lot so any change in semantics, however subtle, could
potentially cause problems for some poor soul out there...

(It could break code if someone tries to use the fileno() on a field
object's file attribute.)

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

Index: cgi.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/cgi.py,v
retrieving revision 1.63
diff -c -r1.63 cgi.py
*** cgi.py	2001/03/19 13:40:44	1.63
--- cgi.py	2001/04/11 20:18:20
***************
*** 633,644 ****
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.file = self.make_file('')
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
--- 633,652 ----
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.file = self.__file = StringIO()
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
+     def __write(self, line):
+         if self.__file is not None:
+             if self.__file.tell() + len(line) > 1000:
+                 self.file = self.make_file('')
+                 self.file.write(self.__file.getvalue())
+                 self.__file = None
+         self.file.write(line)
+ 
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
***************
*** 646,652 ****
              if not line:
                  self.done = -1
                  break
!             self.file.write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
--- 654,660 ----
              if not line:
                  self.done = -1
                  break
!             self.__write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
***************
*** 674,680 ****
                  line = line[:-1]
              else:
                  delim = ""
!             self.file.write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""
--- 682,688 ----
                  line = line[:-1]
              else:
                  delim = ""
!             self.__write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""



From greg at cosc.canterbury.ac.nz  Thu Apr 12 05:02:39 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Apr 2001 15:02:39 +1200 (NZST)
Subject: [Python-Dev] Proposed patch to cgi.py for 2.1 -- please review!
In-Reply-To: <200104120246.VAA14451@cj20424-a.reston1.va.home.com>
Message-ID: <200104120302.PAA12841@s454.cosc.canterbury.ac.nz>

Guido:

> (It could break code if someone tries to use the fileno() on a field
> object's file attribute.)

Switch to a real file when someone accesses the file attribute?

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



From fdrake at beowolf.digicool.com  Thu Apr 12 06:39:34 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Thu, 12 Apr 2001 00:39:34 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010412043934.B61E12879C@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


Almost to Python 2.1 release candidate 1 status.  This includes a variety
of small updates and a good bit more documentation on the PyUnit version
that will be included with the final release (new text essentially 
converted from Steve Purcell's HTML docs).




From jeremy at digicool.com  Thu Apr 12 07:08:00 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Thu, 12 Apr 2001 01:08:00 -0400 (EDT)
Subject: [Python-Dev] make install produces compiler warnings
Message-ID: <15061.14384.617116.153973@slothrop.digicool.com>

I just noticed that a make install prints out a bunch of warnings
about .py files it is compiling.  Many of the errors are in files that
I included in Lib/test that are designed to trigger errors or warnings
about future statements.  Rather than stuff all the different bogus
code examples into strings and pass them to exec, I placed them in
files that are imported by test_future.py.  nocaret.py is a similar
file used to test the exceptions printed for SyntaxErrors.

I think tokenize_tests.py is doing the same thing, but it isn't my
fault :-).

Here's the full list of output to stderr:

  File "/usr/local/lib/python2.1/test/nocaret.py", line 2
    [x for x in x] = x
SyntaxError: can't assign to list comprehension
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future3.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future4.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future5.py, line 4)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future6.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future7.py, line 3)
SyntaxError: duplicate argument 'rest' in function definition (tokenize_tests.py, line 147)
  File "/usr/local/lib/python2.1/test/nocaret.py", line 2
    [x for x in x] = x
SyntaxError: can't assign to list comprehension
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future3.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future4.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future5.py, line 4)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future6.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future7.py, line 3)
SyntaxError: duplicate argument 'rest' in function definition (tokenize_tests.py, line 147)
warning: install: modules installed to '/usr/local/lib/python2.1/lib-dynload/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself

Should we do something to quiet these warnings?  I never noticed them
before since there's *so much* noise produced by make install.

Jeremy




From tim.one at home.com  Thu Apr 12 07:30:28 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 12 Apr 2001 01:30:28 -0400
Subject: [Python-Dev] make install produces compiler warnings
In-Reply-To: <15061.14384.617116.153973@slothrop.digicool.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOELBJLAA.tim.one@home.com>

[Jeremy]
> I just noticed that a make install prints out a bunch of warnings
> about .py files it is compiling.

Yes, JimF noticed that within the last week too, and it threw him off track
(me too).  Meant to mention it.  Of course it's not a problem on Windows --
no make there to make make problems <wink>.

Irrelevantly, the damaged files test_future.py is trying to import should not
have been named with a "test_" prefix (maybe a "bad_" prefix instead), and
then there would have been no need to add them to the NOTTEST list in
regrtest.py either.

Could the Unix makefile be taught not to compile the supposed-to-fail .py
files?  Would that be easier if all the supposed-to-fail files were renamed
to something other than test_*.py?




From tim.one at home.com  Thu Apr 12 08:41:20 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 12 Apr 2001 02:41:20 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104120221.VAA14315@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCELFJLAA.tim.one@home.com>

[Guido]
> I expect that the right solution here is indeed to write our own
> stdio-like library from the ground up.  That can solve any number of
> problems: telling how many characters are buffered (so you don't have
> to use unbuffered mode when using select or poll), platform-
> independent line end recognition, and super-efficient readline()
> to boot.

We also have the old

    http://sourceforge.net/tracker/?group_id=5470&
        atid=105470&func=detail&aid=210821

complaining that use of FILE* in our C API can make it impossible to (in that
fellow's case) write an app in Borland C++ on Windows that tries to use those
API functions (cuz Borland's FILE* is incompatible with MS's FILE*).  I'm not
sure the best solution to *that* is to give them a FILE* that's incompatible
with everyone's, though <wink>>

> But it's a lot of work, and won't be compatible with existing
> extensions that use FILE* (not too many I believe).

I'm more concerned about the "lot of work" part, with which I agree.

OTOH, Plauger's book "The Standard C Library" contains source code for every
library required by C89.  He reported that implementing libm took him twice
as long as everything else combined.  But those who haven't written a libm
will be prone to take a wrong lesson from that <wink>.

it's-not-that-i/o-is-easy-despite-that-his-libm-code-isn't-production-
    quality-ly y'rs  - tim




From just at letterror.com  Thu Apr 12 10:03:33 2001
From: just at letterror.com (Just van Rossum)
Date: Thu, 12 Apr 2001 10:03:33 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com>
Message-ID: <20010412100334-r01010600-5b54bb95@213.84.27.177>

Tim Peters wrote:

> No, there's nothing wrong with the tokenizer code:  it's coded in C, and the
> C text convention is that lines end with \n, period.  Reliance on that
> convention is ubiquitous -- and properly so. 

I don't get it: why would a thin layer on top of stdio be bad? Seems much less
work than reimplementing stdio.

Just



From mwh21 at cam.ac.uk  Thu Apr 12 12:43:19 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: Thu, 12 Apr 2001 11:43:19 +0100 (BST)
Subject: [Python-Dev] python-dev summary, 2001-03-19 - 2001-04-12
Message-ID: <Pine.LNX.4.10.10104121142060.1820-100000@localhost.localdomain>

 This is a summary of traffic on the python-dev mailing list between
 Mar 29 and Apr 11 (inclusive) 2001.  It is intended to inform the
 wider Python community of ongoing developments.  To comment, just
 post to python-list at python.org or comp.lang.python in the usual
 way. Give your posting a meaningful subject line, and if it's about a
 PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep
 iteration) All python-dev members are interested in seeing ideas
 discussed by the community, so don't hesitate to take a stance on a
 PEP if you have an opinion.

 This is the fifth summary written by Michael Hudson.
 Summaries are archived at:

  <http://starship.python.net/crew/mwh/summaries/>

   Posting distribution (with apologies to mbm)

   Number of articles in summary: 166

    25 |                                                 [|]    
       |                                 [|]             [|]    
       |                                 [|]             [|]    
       |                                 [|]             [|]    
    20 |     [|]                         [|]             [|]    
       |     [|]                         [|]             [|]    
       |     [|]                         [|]             [|]    
       |     [|]                         [|]             [|]    
    15 |     [|]                         [|]         [|] [|]    
       |     [|]                         [|]         [|] [|]    
       |     [|]                         [|]         [|] [|]    
       |     [|]             [|]     [|] [|]         [|] [|]    
    10 |     [|]             [|]     [|] [|] [|]     [|] [|]    
       |     [|]             [|]     [|] [|] [|]     [|] [|]    
       |     [|]             [|]     [|] [|] [|]     [|] [|]    
       |     [|]             [|] [|] [|] [|] [|]     [|] [|] [|]
     5 |     [|]     [|]     [|] [|] [|] [|] [|] [|] [|] [|] [|]
       |     [|]     [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
       | [|] [|]     [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
       | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
     0 +-003-022-002-006-005-013-007-013-026-012-006-017-027-007
        Thu 29| Sat 31| Mon 02| Wed 04| Fri 06| Sun 08| Tue 10|
            Fri 30  Sun 01  Tue 03  Thu 05  Sat 07  Mon 09  Wed 11

 Not much traffic this fortnight.  As ever, lots of bug-fixing for
 2.1.  If all goes to plan, I won't be able to say that in the next
 summary!


    * Assigning to __debug__ *

 About 2 weeks ago, changes were checked in that made assignments to
 the magic variable __debug__ SyntaxErrors.  Martin von Loewis pointed
 out that this would probably break code, and thus not be well
 received:

  <http://mail.python.org/pipermail/python-dev/2001-March/013995.html>

 There was general agreement, and it was decided that the error would
 be reduced to a warning.  Code to this effect has now been checked
 in.


    * Inverse string interpolation *

 Peter Funk posted a proposal for using the "/" operator on strings as
 a kind of dual to "%", i.e. be to "%" what "scanf" is to "printf" in
 C:

  <http://mail.python.org/pipermail/python-dev/2001-April/014027.html>

 There was muted approval for the idea, but less so for the spelling.
 Of course "scanf" isn't much better unless you've programmed in C...
 It's possible that this functionality will be somewhere in Python 2.2
 (though builtin, module, infix operator or string method is still to
 be decided, and it might be conditional on someone coming up with a
 good name!).


    * Line endings *

 A recurring theme (with a pretty long period) cropped up again: that
 of line endings in Python source code.  The thread stars here:

  <http://mail.python.org/pipermail/python-dev/2001-April/014090.html>

 At present, one cannot import a file with Unix line endings on the
 Macintosh.  While it would be relatively straightforward to bodge the
 compiler into accepting any of \n, \r or \r\n as a line terminator,
 this would not entirely solve the problem; for instance linecache.py
 in the standard library would need to be fixed.

 One option would be to implement a wrapper around file objects that
 would make .readline() work with all line endings.  However, this
 would be entertainingly difficult to get right on all platforms...

 You author hopes resolution is near, but admits to being slightly
 confused about the details!


    * Release schedule *

 A release candidate for Python 2.1 should be released tomorrow (the
 13th), and if all goes well, the final release will be on Monday (the
 16th).  Fingers crossed everyone!

Cheers,
M.




From guido at digicool.com  Thu Apr 12 20:47:12 2001
From: guido at digicool.com (Guido van Rossum)
Date: Thu, 12 Apr 2001 13:47:12 -0500
Subject: [Python-Dev] Proposed patch to cgi.py for 2.1 -- please review!
In-Reply-To: Your message of "Thu, 12 Apr 2001 15:02:39 +1200."
             <200104120302.PAA12841@s454.cosc.canterbury.ac.nz> 
References: <200104120302.PAA12841@s454.cosc.canterbury.ac.nz> 
Message-ID: <200104121847.NAA20986@cj20424-a.reston1.va.home.com>

> > (It could break code if someone tries to use the fileno() on a field
> > object's file attribute.)
> 
> Switch to a real file when someone accesses the file attribute?

Hm.  I can do that, but I'm less happy about the resulting mess. :-(

Here's the patch.  I think I'get back to this post-2.1...

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

Index: cgi.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/cgi.py,v
retrieving revision 1.63
diff -c -r1.63 cgi.py
*** cgi.py	2001/03/19 13:40:44	1.63
--- cgi.py	2001/04/12 16:45:50
***************
*** 509,515 ****
                  raise ValueError, 'Maximum content length exceeded'
          self.length = clen
  
!         self.list = self.file = None
          self.done = 0
          if ctype == 'application/x-www-form-urlencoded':
              self.read_urlencoded()
--- 509,515 ----
                  raise ValueError, 'Maximum content length exceeded'
          self.length = clen
  
!         self.list = self.__file = None
          self.done = 0
          if ctype == 'application/x-www-form-urlencoded':
              self.read_urlencoded()
***************
*** 524,531 ****
--- 524,537 ----
                  `self.name`, `self.filename`, `self.value`)
  
      def __getattr__(self, name):
+         if name == 'file':
+             self.file = self.__file_incarnate()
+             self.file.seek(0)
+             return self.file
          if name != 'value':
              raise AttributeError, name
+         if self.__file:
+             return self.__file.getvalue()
          if self.file:
              self.file.seek(0)
              value = self.file.read()
***************
*** 614,620 ****
              self.skip_lines()
          else:
              self.read_lines()
!         self.file.seek(0)
  
      bufsize = 8*1024            # I/O buffering size for copy to file
  
--- 620,627 ----
              self.skip_lines()
          else:
              self.read_lines()
!         if not self.__file:
!             self.file.seek(0)
  
      bufsize = 8*1024            # I/O buffering size for copy to file
  
***************
*** 633,644 ****
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.file = self.make_file('')
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
--- 640,665 ----
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.__file = StringIO()
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
+     def __file_incarnate(self):
+         file = self.make_file('')
+         file.write(self.__file.getvalue())
+         self.__file = None
+         return file
+ 
+     def __write(self, line):
+         if self.__file is not None:
+             if self.__file.tell() + len(line) <= 1000:
+                 self.__file.write(line)
+                 return
+             self.file = self.__file_incarnate()
+         self.file.write(line)
+ 
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
***************
*** 646,652 ****
              if not line:
                  self.done = -1
                  break
!             self.file.write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
--- 667,673 ----
              if not line:
                  self.done = -1
                  break
!             self.__write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
***************
*** 674,680 ****
                  line = line[:-1]
              else:
                  delim = ""
!             self.file.write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""
--- 695,701 ----
                  line = line[:-1]
              else:
                  delim = ""
!             self.__write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""



From guido at digicool.com  Fri Apr 13 00:37:09 2001
From: guido at digicool.com (Guido van Rossum)
Date: Thu, 12 Apr 2001 17:37:09 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Thu, 12 Apr 2001 10:03:33 +0200."
             <20010412100334-r01010600-5b54bb95@213.84.27.177> 
References: <20010412100334-r01010600-5b54bb95@213.84.27.177> 
Message-ID: <200104122237.RAA21755@cj20424-a.reston1.va.home.com>

> I don't get it: why would a thin layer on top of stdio be bad? Seems
> much less work than reimplementing stdio.

Because by layering stuff you lose performance.  Example: fgets() is
often implemented in a way that is faster than you can ever do
yourself with portable code.  (Because fgets() can peek in the buffer
and see if there's a \n somewhere ahead, using memcmp() -- and if this
succeeds, it can use memcpy().  You can't do that yourself - only the
stdio implementation can.  And this is not a hypothetical situation --
Tim used fgets() for a significant speed-up of readline() in 2.1.

But if we want to use our own line end convention, we can't use
fgets() any more, so we lose big.

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



From nas at python.ca  Thu Apr 12 23:39:37 2001
From: nas at python.ca (Neil Schemenauer)
Date: Thu, 12 Apr 2001 14:39:37 -0700
Subject: [Python-Dev] Problem with SSL and socketmodule on Debian Potato?
Message-ID: <20010412143937.A3784@glacier.fnational.com>

Fresh CVS tree:

Python 2.1c1 (#2, Apr 12 2001, 17:23:20) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/scratch/nascheme/py_cvs/dist/src/Lib/socket.py", line 41, in ?
    from _socket import *
ImportError: /scratch/nascheme/py_cvs/dist/src/linux/build/lib.linux-i686-2.1/_socket.so: undefined symbol: RAND_status

socketmodule is linked thusly:

gcc -shared build/temp.linux-i686-2.1/socketmodule.o -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-i686-2.1/_socket.so

The SSL package is:

    libssl09-dev 0.9.4-5

I've no time to dig into the details right now but I should have
time tonight.  I will be gone on holiday tomorrow.

  Neil



From martin at loewis.home.cs.tu-berlin.de  Thu Apr 12 23:59:58 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 12 Apr 2001 23:59:58 +0200
Subject: [Python-Dev] Problem with SSL and socketmodule on Debian Potato?
Message-ID: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de>

> ImportError:
> /scratch/nascheme/py_cvs/dist/src/linux/build/lib.linux-i686-2.1/_socket.so:
> undefined symbol: RAND_status

That symbol should be defined in libcrypto.so (it is on my SuSE
system); so that may be a problem with the Debian libssl package. SuSE
ships openssl-0.9.5a-54.

It appears that RAND_status was indeed added between 0.9.4 and
0.9.5. A test for OPENSSL_VERSION_NUMBER would probably help; in
0.9.5a, it has the value of 0x0090581fL.

Regards,
Martin



From sdm7g at Virginia.EDU  Fri Apr 13 00:08:50 2001
From: sdm7g at Virginia.EDU (Steven D. Majewski)
Date: Thu, 12 Apr 2001 18:08:50 -0400 (EDT)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
In-Reply-To: <200104122237.RAA21755@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.NXT.4.21.0104121755170.227-100000@localhost.virginia.edu>

[ re: various remarks about layering on stdio ] 

Has anybody looked at sfio ? 

I used it long ago for other reasons -- for a while the distribution 
seemed to have disappeared from att ( or maybe I just couldn't find
it on netlib ), but I just did a google search and found that there
is a new distribution: sfio2000: 

http://www.research.att.com/sw/tools/sfio/

I haven't looked at the package or the code for a LONG time & I 
don't know how portable it is, but it has some nice features and
advantages -- if you're at the point of considering rewriting 
stdio it might be worth looking at. 

-- Steve Majewski





From nas at python.ca  Fri Apr 13 02:41:19 2001
From: nas at python.ca (Neil Schemenauer)
Date: Thu, 12 Apr 2001 17:41:19 -0700
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Apr 12, 2001 at 11:59:58PM +0200
References: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de>
Message-ID: <20010412174118.A4120@glacier.fnational.com>

Martin v. Loewis wrote:
> It appears that RAND_status was indeed added between 0.9.4 and
> 0.9.5. A test for OPENSSL_VERSION_NUMBER would probably help; in
> 0.9.5a, it has the value of 0x0090581fL.

Right.  From my RAND_status man page:

       RAND_seed() and RAND_screen() are available in all
       versions of SSLeay and OpenSSL. RAND_add() and
       RAND_status() have been added in OpenSSL 0.9.5,
       RAND_event() in OpenSSL 0.9.5a.

The Debian libssl09-dev package does not work while
libssl096-dev does.  Both are available in the current stable
version of Debian (Potato).  We should patch socketmodule or add
a note to the README.

Sometimes I wonder if going to setup.py to build modules was a
mistake.  It would be easy to use autoconf to test of the
RAND_status function exists.  OTOH, its probably not too hard to
add the smarts to setup.py.

  Neil



From m.favas at per.dem.csiro.au  Fri Apr 13 02:43:57 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Apr 2001 08:43:57 +0800
Subject: [Python-Dev] 2.1c1: test_format failing?
Message-ID: <3AD64BCD.DD91216E@per.dem.csiro.au>

A couple of additions to test_format.py between April 12 and 13 now
cause the test to fail on Tru64 Unix (with Compaq's C compiler). Has
anyone else noticed errors with the test? The failures when running the
test standalone are:

'%#o' % 0 =? '0' ... no
u'%#o' % 0 =? '0' ... no

and from "make test":

test_format
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == '00' != '0'",
expected: ''

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From aahz at rahul.net  Fri Apr 13 02:54:56 2001
From: aahz at rahul.net (Aahz Maruch)
Date: Thu, 12 Apr 2001 17:54:56 -0700 (PDT)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
In-Reply-To: <Pine.NXT.4.21.0104121755170.227-100000@localhost.virginia.edu> from "Steven D. Majewski" at Apr 12, 2001 06:08:50 PM
Message-ID: <20010413005457.432DD99C86@waltz.rahul.net>

Steven D. Majewski wrote:
> 
> [ re: various remarks about layering on stdio ] 
> 
> Has anybody looked at sfio ? 

That reminds me of QIO, the stdio replacement in INN, which has already
been ported to Python.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.



From tim.one at home.com  Fri Apr 13 03:00:08 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 12 Apr 2001 21:00:08 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <Pine.NXT.4.21.0104121755170.227-100000@localhost.virginia.edu>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENKJLAA.tim.one@home.com>

[Steven D. Majewski]
> Has anybody looked at sfio ?
> ...
> http://www.research.att.com/sw/tools/sfio/

Did just now.  Only runs on Unix boxes, so would be a heavyweight way to
solve line-end problems across platforms that don't have any <wink>.
Possible to run it on Windows, but only on top of the commercial UWIN Unix
emulation package (http://www.research.att.com/sw/tools/uwin/).  They didn't
mention Macs at all.  The papers should be worth reading for anyone intending
to tackle this, though.




From tim.one at home.com  Fri Apr 13 03:17:09 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 12 Apr 2001 21:17:09 -0400
Subject: [Python-Dev] 2.1c1: test_format failing?
In-Reply-To: <3AD64BCD.DD91216E@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCEENLJLAA.tim.one@home.com>

[Mark Favas]
> A couple of additions to test_format.py between April 12 and 13 now
> cause the test to fail on Tru64 Unix (with Compaq's C compiler). Has
> anyone else noticed errors with the test? The failures when runnin
> the test standalone are:
>
> '%#o' % 0 =? '0' ... no
> u'%#o' % 0 =? '0' ... no
> ...
> But instead we got: "'%#o' % 0 == '00' != '0'"

Please run this C program:

#include <stdio.h>
void main() {
    printf("%#o\n", 0);
}

Does it print 00?  It *should* print 0:

    # The result is converted to an ??alternative form??. For
      o conversion, it increases the precision, if and only if
      necessary, to force the first digit of the result to be a
      zero (if the value and precision are both 0, a single 0 is
      printed). ...

In the test program, the value and precision are both 0, so a single '0' must
be the result (else your platform C is buggy).

Please let us know what happens.  Does anyone else get 00 from the above?




From m.favas at per.dem.csiro.au  Fri Apr 13 03:43:19 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Apr 2001 09:43:19 +0800
Subject: [Python-Dev] 2.1c1: test_format failing?
References: <LNBBLJKPBEHFEDALKOLCEENLJLAA.tim.one@home.com>
Message-ID: <3AD659B7.8F24082F@per.dem.csiro.au>

I've tried the test program on a few of my Tru64 boxes (with different
versions of the OS and different versions of the compiler) and all print
"00".


Tim Peters wrote:
> 
> [Mark Favas]
> > A couple of additions to test_format.py between April 12 and 13 now
> > cause the test to fail on Tru64 Unix (with Compaq's C compiler). Has
> > anyone else noticed errors with the test? The failures when runnin
> > the test standalone are:
> >
> > '%#o' % 0 =? '0' ... no
> > u'%#o' % 0 =? '0' ... no
> > ...
> > But instead we got: "'%#o' % 0 == '00' != '0'"
> 
> Please run this C program:
> 
> #include <stdio.h>
> void main() {
>     printf("%#o\n", 0);
> }
> 
> Does it print 00?  It *should* print 0:
> 
>     # The result is converted to an ??alternative form??. For
>       o conversion, it increases the precision, if and only if
>       necessary, to force the first digit of the result to be a
>       zero (if the value and precision are both 0, a single 0 is
>       printed). ...
> 
> In the test program, the value and precision are both 0, so a single '0' must
> be the result (else your platform C is buggy).
> 
> Please let us know what happens.  Does anyone else get 00 from the above?

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From tim.one at home.com  Fri Apr 13 04:51:56 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 12 Apr 2001 22:51:56 -0400
Subject: [Python-Dev] 2.1c1: test_format failing?
In-Reply-To: <3AD659B7.8F24082F@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEOFJLAA.tim.one@home.com>

[Mark Favas]
> I've tried the test program on a few of my Tru64 boxes (with different
> versions of the OS and different versions of the compiler) and all
> print "00".

Then that's why Python '%#o' % 0 also returns "00" (formats of short ints use
the platform sprintf).  As far as I'm concerned, then, this is a
long-standing bug in Compaq's C (the blurb I quoted before was verbatim from
the C standard, and addressed this specific case).

I expect you'll find that '%#o' % 0L returns "0" even on your box, because
Python does its own formats on long ints.

As time goes on, and we eradicate the differences between ints and longs, I
expect we'll end up using the Python long int format code all the time.

Before then, I'm disinclined to add more code to the short int case trying to
worm around platform C bugs, unless at least one other platform is found
where

#include <stdio.h>
void main() {
    printf("%#o\n", 0);
}

prints 00.

BTW, what does this print for you (just changing "o" to "x")?

#include <stdio.h>
void main() {
    printf("%#x\n", 0);
}

If they print 0x0 for that (they're supposed to print 0), current CVS Python
will assert-fail in debug mode on '%#x' % 0.




From m.favas at per.dem.csiro.au  Fri Apr 13 05:43:29 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Apr 2001 11:43:29 +0800
Subject: [Python-Dev] 2.1c1: test_format failing?
References: <LNBBLJKPBEHFEDALKOLCAEOFJLAA.tim.one@home.com>
Message-ID: <3AD675E1.C93AFE56@per.dem.csiro.au>

Responses interpolated below...

[Tim Peters]
> 
> [Mark Favas]
> > I've tried the test program on a few of my Tru64 boxes (with different
> > versions of the OS and different versions of the compiler) and all
> > print "00".
> 
> Then that's why Python '%#o' % 0 also returns "00" (formats of short ints use
> the platform sprintf).  As far as I'm concerned, then, this is a
> long-standing bug in Compaq's C (the blurb I quoted before was verbatim from
> the C standard, and addressed this specific case).
> 
> I expect you'll find that '%#o' % 0L returns "0" even on your box, because
> Python does its own formats on long ints.

It does indeed.


> 
> As time goes on, and we eradicate the differences between ints and longs, I
> expect we'll end up using the Python long int format code all the time.
> 
> Before then, I'm disinclined to add more code to the short int case trying to
> worm around platform C bugs, unless at least one other platform is found
> where
> 
> #include <stdio.h>
> void main() {
>     printf("%#o\n", 0);
> }
> 
> prints 00.

I've just tried Solaris 2.5.1, Solaris 8, FreeBSD 4.2 and even(!) Irix
6.5 - all produce "0" - :( or :) depending on your POV.


> 
> BTW, what does this print for you (just changing "o" to "x")?
> 
> #include <stdio.h>
> void main() {
>     printf("%#x\n", 0);
> }
> 
> If they print 0x0 for that (they're supposed to print 0), current CVS Python
> will assert-fail in debug mode on '%#x' % 0.

This produces "0"

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From fdrake at beowolf.digicool.com  Fri Apr 13 07:10:02 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Fri, 13 Apr 2001 01:10:02 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010413051002.795BD2879C@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


More description and explanation in the unittest documentation; update to
match the final code and decisions from the pyunit-interest mailing list.

Added information on urllib.FancyURLopener's handling of basic 
authentication and how to change the prompting behavior.

Added documentation for the ColorPicker module for the Macintosh.




From rushing at nightmare.com  Fri Apr 13 07:45:14 2001
From: rushing at nightmare.com (Sam Rushing)
Date: Thu, 12 Apr 2001 22:45:14 -0700
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
		<3ACDB0BC.2533D8C2@digicool.com> <15053.56089.93466.30362@anthem.wooz.org>
Message-ID: <3AD6926A.12C937B@nightmare.com>

"Barry A. Warsaw" wrote:

> Oh, one other thing.  Last time I traded email with Sam Rushing
> (almost a year ago, and I'm not even sure if he's on python-dev), he
> was moving toward a coroutine based Medusa and away from async* based.

One of the reasons I originally offered them into the distribution was
that those two modules were always distributed under a standard python
license, while the rest of medusa was still 'commercial'.  Since that's
no longer the case, there's less of a reason to have it in the standard
lib.  [But I think there are a lot of async* users out there...]

Coupla other points:

  1) there are folks (myself included) that would like to see a new
design for asyncore and asynchat, one that doesn't require the expensive
polling of objects and that can have lots of its underbelly parts
replaced with C when necessary.  A totally new 'official' facility that
was aware of and could take advantage of the features of /dev/poll,
kqueue, rtsig, etc.. would be way cool.  I don't think that backward
compatibility would be all that important, since most software uses
async* in a 'shallow' way rather than a 'deep' way - it's be easy to
recode to a newer more efficient API.

  2) it'll be a while before anything polished will be along to obsolete
async*/medusa.  I'm currently working with kqueue and stackless
coroutines but don't know when/if I might be able to release the code.
Such a beast will be radically different from medusa, and would certainly
have a new name...  it's almost more of a 'python-level user-threading
package' (like uthread) than a replacement for async*.

-Sam





From tim.one at home.com  Fri Apr 13 09:12:05 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 13 Apr 2001 03:12:05 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010412100334-r01010600-5b54bb95@213.84.27.177>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEONJLAA.tim.one@home.com>

[Tim]
> No, there's nothing wrong with the tokenizer code:  it's coded
> in C, and the C text convention is that lines end with \n, period.
> Reliance on that convention is ubiquitous -- and properly so.

[Just van Rossum]
> I don't get it: why would a thin layer on top of stdio be bad?
> Seems much less work than reimplementing stdio.

What does that question have to do with the snippet you quoted?  In context,
that snippet was saying that if you did write a small layer on top of stdio,
one that just made \n show up when and only when you think Python should
believe a line ends, then nothing in the tokenizer would need to change
(except to call that layer instead of fgets()), and even the tokenizer's
current \r\n mini-hack could be thrown away.

If that's all you want, that's all it takes.  If you want more than just
that, you need more than just that (but I see Guido already explained that,
and I explained too why the Windows Python cannot recognize \r endings with
reasonable speed for *general* use short of building our own stdio -- but I
don't really much care how fast the compiler runs, if all you want is the
same limited level of hack afforded by the existing one-shot \r\n tokenizer
trick -- and the compiler isn't using the *general*-case fileobject.c
get_line() anyway).

you-pay-for-what-you-want-and-the-more-you-want-the-more-you'll-pay-ly
    y'rs  - tim




From tim.one at home.com  Fri Apr 13 09:40:47 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 13 Apr 2001 03:40:47 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104122237.RAA21755@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEOOJLAA.tim.one@home.com>

[Guido]
> ...
> But if we want to use our own line end convention, we can't use
> fgets() any more, so we lose big.

Well, people said "we couldn't" use fgets() for get_line() either, because
Python strings can contain embedded nulls but fgets() doesn't tell you how
many bytes it read and makes up null bytes of its own.  But I have 200 lines
of excruciating code in fileobject.c that proved them excruciatingly wrong
<wink>.  The same kind of excruciating crap could almost certainly be used to
search for alternative line endings on top of fgets() too.  We would have to
layer our own buffer on top of the hidden platform buffer to get away with
this, because while fgets() will stop at the first \n it sees, there's no way
to ask it to stop at any other character (so in general fgets() would
"over-read" when looking for a non-native line-end, and we'd have to save the
excess in our own buffer).

Hard to say how much that would cost.  I think it surprised everyone (incl.
me!) that even with all the extra buffer-filling and buffer-searching the
fgets() hackery does, that method was at worst a wash with the
getc_unlocked() method on all platforms tried.

In any case, the fgets() hack is only *needed* on Windows, so every other
platform could just make get_line()'s character-at-a-time loop search for
more end conditions.  This can't be impossible <wink>.

s/\r\n?/\n/g-ly y'rs  - tim




From mal at lemburg.com  Fri Apr 13 10:24:18 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 13 Apr 2001 10:24:18 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
References: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de> <20010412174118.A4120@glacier.fnational.com>
Message-ID: <3AD6B7B2.18C3788D@lemburg.com>

Neil Schemenauer wrote:
> 
> Martin v. Loewis wrote:
> > It appears that RAND_status was indeed added between 0.9.4 and
> > 0.9.5. A test for OPENSSL_VERSION_NUMBER would probably help; in
> > 0.9.5a, it has the value of 0x0090581fL.
> 
> Right.  From my RAND_status man page:
> 
>        RAND_seed() and RAND_screen() are available in all
>        versions of SSLeay and OpenSSL. RAND_add() and
>        RAND_status() have been added in OpenSSL 0.9.5,
>        RAND_event() in OpenSSL 0.9.5a.
> 
> The Debian libssl09-dev package does not work while
> libssl096-dev does.  Both are available in the current stable
> version of Debian (Potato).  We should patch socketmodule or add
> a note to the README.
> 
> Sometimes I wonder if going to setup.py to build modules was a
> mistake.  It would be easy to use autoconf to test of the
> RAND_status function exists.  OTOH, its probably not too hard to
> add the smarts to setup.py.

distutils has the machinery for this built-in, but it's not
really ready for prime-time yet. See the mxSetup.py file in my
egenix-mx-base source archive for some auto-conf style code
built on top of the basic tools available in distutils.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From just at letterror.com  Fri Apr 13 11:43:21 2001
From: just at letterror.com (Just van Rossum)
Date: Fri, 13 Apr 2001 11:43:21 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEOOJLAA.tim.one@home.com>
Message-ID: <20010413114324-r01010600-54b4467f@213.84.27.177>

I understand now that I simply don't have enough clue about the implementation
to even try to be involved with this. Unless it makes sense to have a PEP that
doesn't touch the implementation at all (doubtful, IMHO), I'll take back my
offer to write one. I still think it's an important issue, but it's simply
beyond what I can deal with.

To solve the issues on MacOS X, maybe it's enough to hack the Carbon version of
stdio so it can handle unix text files. That way we can simply settle for unix
line ending if sharing code between BSD Python and Carbon Python is desired. At
the same time this would allow using CVS under Darwin for MacPython sources,
which is something I look forward to...

Just



From mal at lemburg.com  Fri Apr 13 13:09:09 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 13 Apr 2001 13:09:09 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <20010413114324-r01010600-54b4467f@213.84.27.177>
Message-ID: <3AD6DE54.ED351E8E@lemburg.com>

Just van Rossum wrote:
> 
> I understand now that I simply don't have enough clue about the implementation
> to even try to be involved with this. Unless it makes sense to have a PEP that
> doesn't touch the implementation at all (doubtful, IMHO), I'll take back my
> offer to write one. I still think it's an important issue, but it's simply
> beyond what I can deal with.

Please write the results of this discussion up as a PEP. PEPs don't
necessarily have to provide an implementation of what is covered;
it sometimes simply suffices to start out with a summary of the
discussions that have been going on. Then someone may pick up the
threads from there and possibly find a solution which will then
get implemented.
 
> To solve the issues on MacOS X, maybe it's enough to hack the Carbon version of
> stdio so it can handle unix text files. That way we can simply settle for unix
> line ending if sharing code between BSD Python and Carbon Python is desired. At
> the same time this would allow using CVS under Darwin for MacPython sources,
> which is something I look forward to...

AFAIR, this discussion was about handling line endings in Python
source code. There have been discussions about turning the tokenizer
into a Unicode based machine. We could then use the Unicode tools
to do line separations.

I don't know why this thread lead to tweaking stdio -- after all
we only need a solution for the Python tokenizer and not a general
purpose stdio abstraction of text files unless I'm missing something
here...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From just at letterror.com  Fri Apr 13 13:43:25 2001
From: just at letterror.com (Just van Rossum)
Date: Fri, 13 Apr 2001 13:43:25 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <3AD6DE54.ED351E8E@lemburg.com>
Message-ID: <20010413134326-r01010600-bafaee65@213.84.27.177>

M.-A. Lemburg wrote:

> I don't know why this thread lead to tweaking stdio -- after all
> we only need a solution for the Python tokenizer and not a general
> purpose stdio abstraction of text files unless I'm missing something
> here...

Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all,
but then what about all tools that read source files line by line? Eg.
linecache.py, all IDE's, etc. etc. As Tim wrote a while back:

  importing-is-only-the-start-of-the-battle

So no, we don't "only need a solution for the Python tokenizer"...

Just



From aahz at rahul.net  Fri Apr 13 15:13:22 2001
From: aahz at rahul.net (Aahz Maruch)
Date: Fri, 13 Apr 2001 06:13:22 -0700 (PDT)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010413134326-r01010600-bafaee65@213.84.27.177> from "Just van Rossum" at Apr 13, 2001 01:43:25 PM
Message-ID: <20010413131323.6358899C97@waltz.rahul.net>

Just van Rossum wrote:
> M.-A. Lemburg wrote:
> 
>> I don't know why this thread lead to tweaking stdio -- after all
>> we only need a solution for the Python tokenizer and not a general
>> purpose stdio abstraction of text files unless I'm missing something
>> here...
> 
> Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all,
> but then what about all tools that read source files line by line? Eg.
> linecache.py, all IDE's, etc. etc. 

<grin>  I'll repeat my question of yesterday: is there any reason why we
couldn't start with QIO?  I did some checking after I sent that out, and
QIO claims that it can be configured to recognize different kinds of
line endings.  QIO is claimed to be 2-3 times faster than Python 1.5.2;
don't know how that compares to 2.x.

[the previous message was sent to python-dev only; this time I'm
including pythonmac-sig]
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.



From guido at digicool.com  Fri Apr 13 16:52:35 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 09:52:35 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Fri, 13 Apr 2001 06:13:22 MST."
             <20010413131323.6358899C97@waltz.rahul.net> 
References: <20010413131323.6358899C97@waltz.rahul.net> 
Message-ID: <200104131452.JAA27545@cj20424-a.reston1.va.home.com>

> <grin>  I'll repeat my question of yesterday: is there any reason why we
> couldn't start with QIO?  I did some checking after I sent that out, and
> QIO claims that it can be configured to recognize different kinds of
> line endings.  QIO is claimed to be 2-3 times faster than Python 1.5.2;
> don't know how that compares to 2.x.


From martin at loewis.home.cs.tu-berlin.de  Fri Apr 13 17:29:23 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 13 Apr 2001 17:29:23 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
Message-ID: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de>

> Sometimes I wonder if going to setup.py to build modules was a
> mistake.  It would be easy to use autoconf to test of the
> RAND_status function exists.  OTOH, its probably not too hard to add
> the smarts to setup.py.

I don't think it was a mistake. First, even though Python had been
using autoconf for years, nobody came up with a complete patch to
autoconfiscate Modules/Setup, or define a different configuration
mechanism. So using setup.py was an improvement over the status quo,
even if not an improvement over some not-implemented technique - which
might have never been implemented.

Furthermore, as Marc-Andr? points out: there is nothing that stops
setup.py/distutils from using the same strategies as autoconf.

Finally, in this specific case, I do think that the best strategy is
to check for the version of OpenSSL. This is against autoconf
philosophy (check for features, not for versions), but since the SSL
support is tied to a specific implementation, rather than an API with
competing implementations, checking the version does no harm and
simplifies the configuration machinery.

Regards,
Martin



From guido at digicool.com  Fri Apr 13 18:39:59 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 11:39:59 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Fri, 13 Apr 2001 17:29:23 +0200."
             <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> 
References: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> 
Message-ID: <200104131639.LAA31088@cj20424-a.reston1.va.home.com>

> I don't think it was a mistake. First, even though Python had been
> using autoconf for years, nobody came up with a complete patch to
> autoconfiscate Modules/Setup, or define a different configuration
> mechanism. So using setup.py was an improvement over the status quo,
> even if not an improvement over some not-implemented technique - which
> might have never been implemented.
> 
> Furthermore, as Marc-Andr? points out: there is nothing that stops
> setup.py/distutils from using the same strategies as autoconf.
> 
> Finally, in this specific case, I do think that the best strategy is
> to check for the version of OpenSSL. This is against autoconf
> philosophy (check for features, not for versions), but since the SSL
> support is tied to a specific implementation, rather than an API with
> competing implementations, checking the version does no harm and
> simplifies the configuration machinery.

So, is this a showstopper issue for the release candidate?  I believe
Neil went on vacation today.  I'd like to have a release out in 6
hours.  Should I try to get this fixed???

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



From moshez at zadka.site.co.il  Fri Apr 13 17:42:39 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Fri, 13 Apr 2001 18:42:39 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131639.LAA31088@cj20424-a.reston1.va.home.com>
References: <200104131639.LAA31088@cj20424-a.reston1.va.home.com>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de>
Message-ID: <E14o5iZ-00015o-00@darjeeling>

On Fri, 13 Apr 2001 11:39:59 -0500, Guido van Rossum <guido at digicool.com> wrote:
 
> So, is this a showstopper issue for the release candidate?  

In my opinion, yes.
Sadly, I don't have the manpower to commit and test this properly,
but it is important.

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From martin at loewis.home.cs.tu-berlin.de  Fri Apr 13 18:14:27 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 13 Apr 2001 18:14:27 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131639.LAA31088@cj20424-a.reston1.va.home.com> (message
	from Guido van Rossum on Fri, 13 Apr 2001 11:39:59 -0500)
References: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>
Message-ID: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>

> So, is this a showstopper issue for the release candidate?

It will mean that the socket module does not work out-of-the-box on
some Debian systems; that could be fixed by enabling the socket module
in Modules/Setup so that it is built without SSL support.

> I believe Neil went on vacation today.  I'd like to have a release
> out in 6 hours.  Should I try to get this fixed???

How about this patch? I've verified that it works with my OpenSSL
installation (0.9.5a), and, by source code inspection, that it should
work with versions back to 0.9.1c (ie. that OPENSSL_VERSION_NUMBER was
always available through including <openssl/crypto.h>).

The logic about RAND_status being 0 if unknown might be flawed, but
that won't hurt unless SSL support is actually used.

If this won't get into 2.1, I'll put it on SF.

Regards,
Martin

Index: socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.139
diff -u -r1.139 socketmodule.c
--- socketmodule.c	2001/03/18 17:11:56	1.139
+++ socketmodule.c	2001/04/13 15:56:04
@@ -195,6 +195,13 @@
 #include "openssl/ssl.h"
 #include "openssl/err.h"
 #include "openssl/rand.h"
+
+#if OPENSSL_VERSION_NUMBER < 0x0090510fL
+/* RAND_status was added in OpenSSL 0.9.5. If it is not available,
+   we assume that seeding the RNG is necessary every time. */
+#define RAND_status()	0
+#endif
+
 #endif /* USE_SSL */
 
 #if defined(MS_WINDOWS) || defined(__BEOS__)



From moshez at zadka.site.co.il  Fri Apr 13 18:20:42 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Fri, 13 Apr 2001 19:20:42 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>
References: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>
Message-ID: <E14o6JO-0001EI-00@darjeeling>

On Fri, 13 Apr 2001, "Martin v. Loewis" <martin at loewis.home.cs.tu-berlin.de> wrote:

> How about this patch? I've verified that it works with my OpenSSL
> installation (0.9.5a), and, by source code inspection, that it should
> work with versions back to 0.9.1c (ie. that OPENSSL_VERSION_NUMBER was
> always available through including <openssl/crypto.h>).
> 
> The logic about RAND_status being 0 if unknown might be flawed, but
> that won't hurt unless SSL support is actually used.

No, this seems like a worse cure then the cause...
Why not put the whole if (RAND_status()) thing under the ifdef?
It was only added in 2.1, so at least we would be no worse off then in 2.0
> 
> If this won't get into 2.1, I'll put it on SF.
> 
> Regards,
> Martin
> 
> Index: socketmodule.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
> retrieving revision 1.139
> diff -u -r1.139 socketmodule.c
> --- socketmodule.c	2001/03/18 17:11:56	1.139
> +++ socketmodule.c	2001/04/13 15:56:04
> @@ -195,6 +195,13 @@
>  #include "openssl/ssl.h"
>  #include "openssl/err.h"
>  #include "openssl/rand.h"
> +
> +#if OPENSSL_VERSION_NUMBER < 0x0090510fL
> +/* RAND_status was added in OpenSSL 0.9.5. If it is not available,
> +   we assume that seeding the RNG is necessary every time. */
> +#define RAND_status()	0
> +#endif
> +
>  #endif /* USE_SSL */
>  
>  #if defined(MS_WINDOWS) || defined(__BEOS__)
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> 
> 
-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From guido at digicool.com  Fri Apr 13 19:34:13 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 12:34:13 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Fri, 13 Apr 2001 18:14:27 +0200."
             <200104131614.f3DGER730511@mira.informatik.hu-berlin.de> 
References: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>  
            <200104131614.f3DGER730511@mira.informatik.hu-berlin.de> 
Message-ID: <200104131734.MAA32326@cj20424-a.reston1.va.home.com>

> > So, is this a showstopper issue for the release candidate?
> 
> It will mean that the socket module does not work out-of-the-box on
> some Debian systems; that could be fixed by enabling the socket module
> in Modules/Setup so that it is built without SSL support.
> 
> > I believe Neil went on vacation today.  I'd like to have a release
> > out in 6 hours.  Should I try to get this fixed???
> 
> How about this patch? I've verified that it works with my OpenSSL
> installation (0.9.5a), and, by source code inspection, that it should
> work with versions back to 0.9.1c (ie. that OPENSSL_VERSION_NUMBER was
> always available through including <openssl/crypto.h>).
> 
> The logic about RAND_status being 0 if unknown might be flawed, but
> that won't hurt unless SSL support is actually used.
> 
> If this won't get into 2.1, I'll put it on SF.

Thanks, I think I'll add that.  It looks harmless.  (Famous last
words. :-)

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



From guido at digicool.com  Fri Apr 13 19:39:59 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 12:39:59 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Fri, 13 Apr 2001 19:20:42 +0300."
             <E14o6JO-0001EI-00@darjeeling> 
References: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>  
            <E14o6JO-0001EI-00@darjeeling> 
Message-ID: <200104131739.MAA01976@cj20424-a.reston1.va.home.com>

> No, this seems like a worse cure then the cause...
> Why not put the whole if (RAND_status()) thing under the ifdef?
> It was only added in 2.1, so at least we would be no worse off then in 2.0

Moshe, please mail me a specific patch.  I don't know the code well
enough to guess what you mean!

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



From martin at loewis.home.cs.tu-berlin.de  Fri Apr 13 19:33:26 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 13 Apr 2001 19:33:26 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <E14o6JO-0001EI-00@darjeeling> (message from Moshe Zadka on Fri,
	13 Apr 2001 19:20:42 +0300)
References: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>
Message-ID: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>

> No, this seems like a worse cure then the cause...

Can you elaborate? It cures the problem of the socket module not being
loadable...

> Why not put the whole if (RAND_status()) thing under the ifdef?  It
> was only added in 2.1, so at least we would be no worse off then in
> 2.0

AFAICT, under my patch, when using OpenSSL on a system with EGD, it
will do the right thing. On a system with /dev/random, it will produce
a runtime warning, then add insecure entropy - in addition to the
secure entropy already obtained from /dev/random.

Under what I think is your patch, it will do the right thing on a
system with /dev/random. On a system with EGD, it will fail because of
the missing entropy.

Regards,
Martin



From jeremy at digicool.com  Fri Apr 13 19:44:04 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 13 Apr 2001 13:44:04 -0400 (EDT)
Subject: [Python-Dev] compileall.py and make install
Message-ID: <15063.15076.601471.476713@slothrop.digicool.com>

There are two related problems that I'd like to fix for the release
candidate.  One is that compileall.py basically ignores compiler
errors.  It's clear that the code intends to return with a non-zero
exit status if there are compilation errors, but it doesn't do that
currently.

If I fix just this problem, make install will start to fail because
there are six files in the test directory that contain intentional
SyntaxErrors; in one case, it's necessary that the SyntaxError be
raised through import.

I'd like to fix compileall.py and add an optional argument that tells
it to skip files that match a regular expression.  Then I'll rename
all the offending files so that they are named badsyntax_XXX and fix
the Makefile so that it installs them but does not compile them.

This is going to cause two problems for developers.  First, you'll
need to manually delete the files with the old names from the install
lib directory.  (I'll rename nocaret.py to badsyntax_nocaret.py, but,
if you've already done an install, you'll also have a nocaret.py in
the lib directory.)

The compileall script also traverses into site-packages.  If you have
compilation errors in code that you've installed into site-packages,
then make install will fail. 

I'm not sure what to do about this.  During development, at least, it
is probably helpful for make install to walk into site-packages and
fail if the new version of Python breaks existing code.  On the other
hand, it could be a big pain that you can't install Python just
because you previously installed a buggy Python library.  Of course,
you could just remove the broken code.

I think it's a net gain to make these changes.  Is anyone more
concerned that me about the possible breakage?

Jeremy






From fdrake at acm.org  Fri Apr 13 20:02:55 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 13 Apr 2001 14:02:55 -0400 (EDT)
Subject: [Python-Dev] Docs are frozen.
Message-ID: <15063.16207.884585.823138@beowolf.digicool.com>

  The documentation tree is frozen for Python 2.1c1.  All further
changes should be submitted via the SourceForge patch manager until
Python 2.1 has been released.
  Thanks!


  -Fred

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




From chrishbarker at home.net  Fri Apr 13 20:20:32 2001
From: chrishbarker at home.net (Chris Barker)
Date: Fri, 13 Apr 2001 11:20:32 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <20010413114324-r01010600-54b4467f@213.84.27.177> <3AD6DE54.ED351E8E@lemburg.com>
Message-ID: <3AD74370.2EF0614C@home.net>

"M.-A. Lemburg" wrote:
> Please write the results of this discussion up as a PEP. PEPs don't
> necessarily have to provide an implementation of what is covered;
> it sometimes simply suffices to start out with a summary of the
> discussions that have been going on. Then someone may pick up the
> threads from there and possibly find a solution which will then
> get implemented.

Just, I second that. I really think this is a very useful improvement to
Python, I'd I'd really like to see it happen. I am probably even more
out of my depth than you when it comes to suggesting impimentation, but
I'd be glad to help with any parts of a PEP that I can.

Guido van Rossum wrote:
> > <grin>  I'll repeat my question of yesterday: is there any reason why we
> > couldn't start with QIO?  I did some checking after I sent that out, and
> > QIO claims that it can be configured to recognize different kinds of
> > line endings.  QIO is claimed to be 2-3 times faster than Python 1.5.2;
> > don't know how that compares to 2.x.
> 
> >From a one-minute review it looks like as good a start as any!

Great! I have to say that it really seemed that someone must have
produced an open source solution to this problem somewhere, and it turns
out there is something Python related already.

-Chris


-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------



From fdrake at beowolf.digicool.com  Fri Apr 13 20:15:38 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Fri, 13 Apr 2001 14:15:38 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010413181538.7BA3F28A06@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/

Final documentation for Python 2.1c1.




From guido at digicool.com  Fri Apr 13 21:45:51 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 14:45:51 -0500
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: Your message of "Fri, 13 Apr 2001 13:44:04 -0400."
             <15063.15076.601471.476713@slothrop.digicool.com> 
References: <15063.15076.601471.476713@slothrop.digicool.com> 
Message-ID: <200104131945.OAA09964@cj20424-a.reston1.va.home.com>

> There are two related problems that I'd like to fix for the release
> candidate.  One is that compileall.py basically ignores compiler
> errors.  It's clear that the code intends to return with a non-zero
> exit status if there are compilation errors, but it doesn't do that
> currently.
> 
> If I fix just this problem, make install will start to fail because
> there are six files in the test directory that contain intentional
> SyntaxErrors; in one case, it's necessary that the SyntaxError be
> raised through import.
> 
> I'd like to fix compileall.py and add an optional argument that tells
> it to skip files that match a regular expression.  Then I'll rename
> all the offending files so that they are named badsyntax_XXX and fix
> the Makefile so that it installs them but does not compile them.
> 
> This is going to cause two problems for developers.  First, you'll
> need to manually delete the files with the old names from the install
> lib directory.  (I'll rename nocaret.py to badsyntax_nocaret.py, but,
> if you've already done an install, you'll also have a nocaret.py in
> the lib directory.)
> 
> The compileall script also traverses into site-packages.  If you have
> compilation errors in code that you've installed into site-packages,
> then make install will fail. 
> 
> I'm not sure what to do about this.  During development, at least, it
> is probably helpful for make install to walk into site-packages and
> fail if the new version of Python breaks existing code.  On the other
> hand, it could be a big pain that you can't install Python just
> because you previously installed a buggy Python library.  Of course,
> you could just remove the broken code.
> 
> I think it's a net gain to make these changes.  Is anyone more
> concerned that me about the possible breakage?

-1 for getting this in the 2.1 release.  +1 for fixing this soon
after.  I'm beginning to see the point of branching off for releases!

I'm not sure what advantage there is to compileall.py returning a
non-zero exit code, and I clearly see the risk of doing it so close to
the release.  I have about three hours to send the release candidate
out, I want to do some more testing, *and* I want to have the night
off... :-)

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



From jeremy at digicool.com  Fri Apr 13 20:48:34 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 13 Apr 2001 14:48:34 -0400 (EDT)
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: <15063.15076.601471.476713@slothrop.digicool.com>
References: <15063.15076.601471.476713@slothrop.digicool.com>
Message-ID: <15063.18946.598247.129409@slothrop.digicool.com>

A brief historical analysis of the situation

In the olden days, py_compile.py did not catch SyntaxErrors.  If
compileall.py used py_compile.py to compile a file and it failed,
it would print an error message but continue working. 

When Python 1.5.2 was released, py_compile was updated to catch the
exceptions on its own.

About six months later, well before 2.0, a change was made to
compileall to exit with non-zero status if it caught a syntax error.
This change apparently had no effect, because compileall never saw
syntax errors.

Jeremy

 




From jeremy at digicool.com  Fri Apr 13 20:52:44 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 13 Apr 2001 14:52:44 -0400 (EDT)
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: <200104131945.OAA09964@cj20424-a.reston1.va.home.com>
References: <15063.15076.601471.476713@slothrop.digicool.com>
	<200104131945.OAA09964@cj20424-a.reston1.va.home.com>
Message-ID: <15063.19196.236720.410550@slothrop.digicool.com>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

  GvR> -1 for getting this in the 2.1 release.  +1 for fixing this
  GvR> soon after.  I'm beginning to see the point of branching off
  GvR> for releases!

Okay.

Jeremy




From guido at digicool.com  Fri Apr 13 22:05:39 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 15:05:39 -0500
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: Your message of "Fri, 13 Apr 2001 14:48:34 -0400."
             <15063.18946.598247.129409@slothrop.digicool.com> 
References: <15063.15076.601471.476713@slothrop.digicool.com>  
            <15063.18946.598247.129409@slothrop.digicool.com> 
Message-ID: <200104132005.PAA10142@cj20424-a.reston1.va.home.com>

> A brief historical analysis of the situation
> 
> In the olden days, py_compile.py did not catch SyntaxErrors.  If
> compileall.py used py_compile.py to compile a file and it failed,
> it would print an error message but continue working. 
> 
> When Python 1.5.2 was released, py_compile was updated to catch the
> exceptions on its own.
> 
> About six months later, well before 2.0, a change was made to
> compileall to exit with non-zero status if it caught a syntax error.
> This change apparently had no effect, because compileall never saw
> syntax errors.

Hm.  That change was never tested, apparently. :-(

This means that even if we fix py_compile.py after 2.1 is released, we
risk breaking existing usage.  Not clear whether that should matter
much though.

But definitely not a risk I want to take in 2.1.

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



From guido at python.org  Sat Apr 14 00:18:40 2001
From: guido at python.org (Guido van Rossum)
Date: Fri, 13 Apr 2001 17:18:40 -0500
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
Message-ID: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>

Python 2.1 is almost ready.  We've built a release candidate -- a
version that should become the final version, barring any last-minute
showstopper bugs (which will of course be fixed before releasing the
final version).  Thanks to all who helped!

Please download the release candidate and use it on your favorite
platform.  For more info:

    http://www.python.org/2.1/

There's not much new since 2.1b2: we mostly fixed bugs and added
documentation.  Some things that *did* change visibly:

  - Ping added an interactive help browser to pydoc. (Very cool!  Try it!)

  - Eric Raymond extended the pstats module with a simple interactive
    statistics browser, invoked when the module is run as a script.

  - An updated python-mode.el version 4.0 which integrates Ken
    Manheimer's pdbtrack.el.  This makes debugging Python code via pdb
    much nicer in XEmacs and Emacs.  When stepping through your program
    with pdb, in either the shell window or the *Python* window, the
    source file and line will be tracked by an arrow.

  - After a public outcry, assignment to __debug__ is no longer illegal;
    instead, a warning is issued.  It will become illegal in 2.2.

  - New port: SCO Unixware 7, by Billy G. Allie.

  - Updated the RISCOS port.

We expect to release the final version on Tuesday morning, April 17.

Enjoy!

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



From paul at pfdubois.com  Fri Apr 13 23:47:45 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Fri, 13 Apr 2001 14:47:45 -0700
Subject: [Python-Dev] Complex detection
Message-ID: <ADEOIFHFONCLEEPKCACCKECECIAA.paul@pfdubois.com>

My understanding is that Python can be built without complex numbers to
satisfy the needs of the Python-on-a-wristwatch crowd. Is there a run-time
way to tell? For example, using an imaginary literal causes an error? If so,
what kind?

I'm finishing the reference implementation for PEP 242 and want to allow for
this possibility.




From ping at lfw.org  Sat Apr 14 00:28:20 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Fri, 13 Apr 2001 17:28:20 -0500 (CDT)
Subject: [Python-Dev] Complex detection
In-Reply-To: <ADEOIFHFONCLEEPKCACCKECECIAA.paul@pfdubois.com>
Message-ID: <Pine.LNX.4.10.10104131727180.21723-100000@server1.lfw.org>

On Fri, 13 Apr 2001, Paul F. Dubois wrote:
> My understanding is that Python can be built without complex numbers to
> satisfy the needs of the Python-on-a-wristwatch crowd. Is there a run-time
> way to tell? For example, using an imaginary literal causes an error? If so,
> what kind?

This is just a guess, but check hasattr(__builtins__, 'complex') perhaps?
That's what i would do.


-- ?!ng




From tim.one at home.com  Sat Apr 14 00:39:46 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 13 Apr 2001 18:39:46 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010413134326-r01010600-bafaee65@213.84.27.177>
Message-ID: <LNBBLJKPBEHFEDALKOLCIECBJMAA.tim.one@home.com>

[MAL]
> I don't know why this thread lead to tweaking stdio -- after all
> we only need a solution for the Python tokenizer ...

[Just]
> Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is
> great and all,> but then what about all tools that read source
> files line by line? ...

Note that this is why the topic needs a PEP:  nothing here is new; the same
debates reoccur every time it comes up.

[Aahz]
> ...
> QIO claims that it can be configured to recognize different
> kinds of line endings.

It can be, yes, but in the same sense as Awk/Perl paragraph mode:  you can
tell it to consider any string (not just single character) as meaning "end of
the line", but it's a *fixed* string per invocation.  What people want *here*
is more the ability to recognize the regular expression

    \r\n?|\n

as ending a line, and QIO can't do that directly (as currently written).  And
MAL probably wants Unicode line-end detection:

    http://www.unicode.org/unicode/reports/tr13/

> QIO is claimed to be 2-3 times faster than Python 1.5.2; don't
> know how that compares to 2.x.

The bulk of that was due to QIO avoiding per-character thread locks.  2.1
avoids them too, so most of QIO's speed advantage should be gone now.  But
QIO's internals could certainly be faster than they are (this is obscure
because QIO.readline() has so many optional behaviors that the maze of
if-tests makes it hard to see the speed-crucial bits; studying Perl's
line-reading code is a better model, because Perl's speed-crucial inner loop
has no non-essential operations -- Perl makes the *surrounding* code sort out
the optional bits, instead of bogging down the loop with them).




From tim.one at home.com  Sat Apr 14 00:48:22 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 13 Apr 2001 18:48:22 -0400
Subject: [Python-Dev] Complex detection
In-Reply-To: <ADEOIFHFONCLEEPKCACCKECECIAA.paul@pfdubois.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKECEJMAA.tim.one@home.com>

[Paul F. Dubois]
> My understanding is that Python can be built without complex numbers
> to satisfy the needs of the Python-on-a-wristwatch crowd. Is there a
> run-time way to tell? For example, using an imaginary literal causes
> an error? If so, what kind?

You can find out by compiling with WITHOUT_COMPLEX #define'd.  PythonLabs
never does this, so no guarantee it even works.  I'm not going to bother
starting now, either <wink>.  Based on skimming the code, I expect

try:
    eval("1j")
    with_complex = 1
except SyntaxError:
    with_complex = 0

would do the trick, but no guarantee.




From m.favas at per.dem.csiro.au  Sat Apr 14 02:59:34 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 08:59:34 +0800
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
Message-ID: <3AD7A0F6.7673FDD3@per.dem.csiro.au>

FreeBSD 4.2-20010225-STABLE, gcc 2.95.2

./python Lib/test/test_zipfile.py
Traceback (most recent call last):
  File "Lib/test/test_zipfile.py", line 35, in ?
    zipTest(file, zipfile.ZIP_STORED, writtenData)
  File "Lib/test/test_zipfile.py", line 18, in zipTest
    zip.close()
  File "/home/mark/src/python/CVS/python/dist/src/Lib/zipfile.py", line
471, in close
    self.fp.flush()
IOError: [Errno 9] Bad file descriptor

Looks like FreeBSD objects to doing a flush() on a file opened for
reading. The self.fp.flush() call should probably be part of the
preceding if-block relating to files opened in "a" or "w' mode.
-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From moshez at zadka.site.co.il  Sat Apr 14 02:58:38 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Sat, 14 Apr 2001 03:58:38 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>
Message-ID: <E14oEOc-0001si-00@darjeeling>

"competing patch" attached at end.

On Fri, 13 Apr 2001, "Martin v. Loewis" <martin at loewis.home.cs.tu-berlin.de> wrote:
> > No, this seems like a worse cure then the cause...
> 
> Can you elaborate? It cures the problem of the socket module not being
> loadable...

You're right, it was a bad choice of words.
 
> AFAICT, under my patch, when using OpenSSL on a system with EGD, it
> will do the right thing. On a system with /dev/random, it will produce
> a runtime warning, then add insecure entropy - in addition to the
> secure entropy already obtained from /dev/random.
> 
> Under what I think is your patch, it will do the right thing on a
> system with /dev/random. On a system with EGD, it will fail because of
> the missing entropy.

Correct on both. My "worse" is: it would print a warning about using
an insecure method on systems with /dev/random but without an EGD,
even though it is secure. Note that the EGD stuff is new with 2.1,
so losing that is not a step backwards from 2.0. Printing a wrong warning
is a step backwards, so in that sense my patch is more conservative.
 
After further contemplation, none of these is a pure win.
It's up to Guido if he wants to use my patch instead of Martin's
for 2.1final
-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org


*** Modules/socketmodule.c	Sun Mar 18 18:38:50 2001
--- new	Sat Apr 14 03:53:20 2001
***************
*** 2545,2550 ****
--- 2545,2551 ----
  	if (PyDict_SetItemString(d, "SSLType",
  				 (PyObject *)&SSL_Type) != 0)
  		return;
+ #if OPENSSL_VERSION_NUMBER < 0x0090510fL
  	if (RAND_status() == 0) {
  #ifdef USE_EGD
  		char random_device[MAXPATHLEN+1];
***************
*** 2571,2576 ****
--- 2572,2578 ----
  		RAND_seed(random_string, sizeof(random_string));
  #endif /* USE_EGD */
  	}
+ #endif /* OPENSSL_VERSION_NUMBER < 0x0090510fL */
  #endif /* USE_SSL */
  	PyDict_SetItemString(d, "error", PySocket_Error);
  	PySocketSock_Type.ob_type = &PyType_Type;



From m.favas at per.dem.csiro.au  Sat Apr 14 03:07:29 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 09:07:29 +0800
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
Message-ID: <3AD7A2D1.B04928AE@per.dem.csiro.au>

SunOS asafoetida 5.8, gcc 2.95.2

"make test" fails on running test_asynchat.py for the second time. The
traceback is:

Exception in thread Thread-1:
Traceback (most recent call last):
  File
"/export/home/mark/src/python/CVS/python/dist/src/Lib/threading.py",
line 378, in __bootstrap
    self.run()
  File "Lib/test/test_asynchat.py", line 12, in run
    sock.bind((HOST, PORT))
error: (125, 'Address already in use')

Traceback (most recent call last):
  File "Lib/test/test_asynchat.py", line 56, in ?
    main()
  File "Lib/test/test_asynchat.py", line 51, in main
    c = echo_client()
  File "Lib/test/test_asynchat.py", line 32, in __init__
    self.connect((HOST, PORT))
  File
"/export/home/mark/src/python/CVS/python/dist/src/Lib/asyncore.py", line
308, in connect
    raise socket.error, why
socket.error: (146, 'Connection refused')

Looks like Solaris takes a while to shut sockets down? (This is not a
slow box, btw.) Or is there an option to not have the socket linger?

Also, test_sunaudiodev fails, since setup.py tests only whether the
platform is a Sun, not whether there is a /dev/audio as well. Servers
don't have a /dev/audio. This is clearly a minor nit - I did log a bug
against this some time ago.

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From m.favas at per.dem.csiro.au  Sat Apr 14 03:12:29 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 09:12:29 +0800
Subject: [Python-Dev] 2.1c1: "make test" core dumps on SGI Irix
Message-ID: <3AD7A3FD.CBEB9510@per.dem.csiro.au>

IRIX64 dodo 6.5 07201607 IP35, MIPSpro Compilers: Version 7.30

"make test" core dumps with no output from any test completed. Running
them one-by-one reveals that the (first?) core dump is in
test___all__.py.
python Lib/test/test___all__.py
Bus error (core dumped)

dbx where gives: (chopped)
>  0 float_mul(0x100ce7dc, 0x103523d8, 0x8, 0x100b5d70, 0x10050000, 0x103523d8, 0x100b5d70, 0x100b5ce8) ["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/floatobject.c":382, 0x1004f098]
   1 binary_op1(0x100ce7dc, 0x103523d8, 0x0, 0x100b5d70, 0x10050000,
0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/abstract.c":337,
0x1003bfec]
   2 binary_op(0x100ce7dc, 0x103523d8, 0x8, 0x0, 0x10050000, 0x103523d8,
0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/abstract.c":373,
0x1003c200]
   3 PyNumber_Multiply(0x100ce7dc, 0x103523d8, 0x8, 0x100b5d70,
0x10050000, 0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/abstract.c":544,
0x1003c934]
   4 eval_code2(0x101bea78, 0x0, 0x0, 0x0, 0x103ffad7, 0x0, 0x0, 0x0)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/ceval.c":945,
0x10035cb4]
   5 PyEval_EvalCode(0x100ce7dc, 0x103523d8, 0x8, 0x100b5d70,
0x10050000, 0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/ceval.c":341,
0x10032818]
   6 PyImport_ExecCodeModuleEx(0x7fff1168, 0x0, 0x0, 0x100b5d70,
0x10050000, 0x103523d8, 0x0, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/import.c":490,
0x1000d904]
   7 load_source_module(0x0, 0x7fff0840, 0x0, 0x100b5d70, 0x10050000,
0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/import.c":754,
0x1000e0f0]
More (n if no)?

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From esr at thyrsus.com  Sat Apr 14 03:41:39 2001
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 13 Apr 2001 21:41:39 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Apr 13, 2001 at 05:18:40PM -0500
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>
Message-ID: <20010413214139.A3800@thyrsus.com>

Guido van Rossum <guido at python.org>:
>   - Eric Raymond extended the pstats module with a simple interactive
>     statistics browser, invoked when the module is run as a script.

...which I tested by using it to speed-tune the crap out of CML2, dropping the
configurator's startup time from over 15 seconds to about 2 :-).

CML2 has been officially accepted for inclusion in the Linux kernel, BTW.
Linus himself quashed the anti-Python grumbling from some of the more
conservative types on lkml by uttering the ukase "Python is not an issue."
It's scheduled to go in sometime in the 2.5.1 to 2.5.2 series.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
        -- G. Kleck, "Policy Lessons from Recent Gun Control Research,"



From guido at digicool.com  Sat Apr 14 04:42:28 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 21:42:28 -0500
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:07:29 +0800."
             <3AD7A2D1.B04928AE@per.dem.csiro.au> 
References: <3AD7A2D1.B04928AE@per.dem.csiro.au> 
Message-ID: <200104140242.VAA11020@cj20424-a.reston1.va.home.com>

> SunOS asafoetida 5.8, gcc 2.95.2
> 
> "make test" fails on running test_asynchat.py for the second time. The
> traceback is:
> 
> Exception in thread Thread-1:
> Traceback (most recent call last):
>   File
> "/export/home/mark/src/python/CVS/python/dist/src/Lib/threading.py",
> line 378, in __bootstrap
>     self.run()
>   File "Lib/test/test_asynchat.py", line 12, in run
>     sock.bind((HOST, PORT))
> error: (125, 'Address already in use')
> 
> Traceback (most recent call last):
>   File "Lib/test/test_asynchat.py", line 56, in ?
>     main()
>   File "Lib/test/test_asynchat.py", line 51, in main
>     c = echo_client()
>   File "Lib/test/test_asynchat.py", line 32, in __init__
>     self.connect((HOST, PORT))
>   File
> "/export/home/mark/src/python/CVS/python/dist/src/Lib/asyncore.py", line
> 308, in connect
>     raise socket.error, why
> socket.error: (146, 'Connection refused')
> 
> Looks like Solaris takes a while to shut sockets down? (This is not a
> slow box, btw.) Or is there an option to not have the socket linger?

Dunno, but there *is* an option to allow reusing a socket.

> Also, test_sunaudiodev fails, since setup.py tests only whether the
> platform is a Sun, not whether there is a /dev/audio as well. Servers
> don't have a /dev/audio. This is clearly a minor nit - I did log a bug
> against this some time ago.

Compiling on a server doesn't mean you'll run on a server only.  But
the test should mark itself as "skipped" when /dev/audio doesn't
exist.  I don't know how easy that is.

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



From guido at digicool.com  Sat Apr 14 04:43:07 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 21:43:07 -0500
Subject: [Python-Dev] 2.1c1: "make test" core dumps on SGI Irix
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:12:29 +0800."
             <3AD7A3FD.CBEB9510@per.dem.csiro.au> 
References: <3AD7A3FD.CBEB9510@per.dem.csiro.au> 
Message-ID: <200104140243.VAA11034@cj20424-a.reston1.va.home.com>

> IRIX64 dodo 6.5 07201607 IP35, MIPSpro Compilers: Version 7.30
> 
> "make test" core dumps with no output from any test completed. Running
> them one-by-one reveals that the (first?) core dump is in
> test___all__.py.
> python Lib/test/test___all__.py
> Bus error (core dumped)

Try compiling without -O?

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



From fdrake at acm.org  Sat Apr 14 03:49:51 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 13 Apr 2001 21:49:51 -0400 (EDT)
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
In-Reply-To: <200104140242.VAA11020@cj20424-a.reston1.va.home.com>
References: <3AD7A2D1.B04928AE@per.dem.csiro.au>
	<200104140242.VAA11020@cj20424-a.reston1.va.home.com>
Message-ID: <15063.44223.710582.338422@cj42289-a.reston1.va.home.com>


Guido van Rossum writes:
 > Compiling on a server doesn't mean you'll run on a server only.  But
 > the test should mark itself as "skipped" when /dev/audio doesn't
 > exist.  I don't know how easy that is.

Mark,
  Please try the following patch to Lib/test/test_sunaudiodev.py and
let us know how that works for you.


  -Fred

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
URL: <http://mail.python.org/pipermail/python-dev/attachments/20010413/04f04cfa/attachment.txt>

From m.favas at per.dem.csiro.au  Sat Apr 14 04:13:44 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 10:13:44 +0800
Subject: [Python-Dev] 2.1c1: test_sunaudiodev fails on Sun servers 
References: <3AD7A2D1.B04928AE@per.dem.csiro.au>
		<200104140242.VAA11020@cj20424-a.reston1.va.home.com> <15063.44223.710582.338422@cj42289-a.reston1.va.home.com>
Message-ID: <3AD7B258.7ED22029@per.dem.csiro.au>

Fred,

Yes, that works for me (perhaps we could change "dound" to "found"
though <wink>).

M

"Fred L. Drake, Jr." wrote:
> 
> Guido van Rossum writes:
>  > Compiling on a server doesn't mean you'll run on a server only.  But
>  > the test should mark itself as "skipped" when /dev/audio doesn't
>  > exist.  I don't know how easy that is.
> 
> Mark,
>   Please try the following patch to Lib/test/test_sunaudiodev.py and
> let us know how that works for you.
> 
>   -Fred
> 
> --
> Fred L. Drake, Jr.  <fdrake at acm.org>
> PythonLabs at Digital Creations
> 
>   ------------------------------------------------------------------------
> Index: test_sunaudiodev.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/test/test_sunaudiodev.py,v
> retrieving revision 1.9
> diff -c -r1.9 test_sunaudiodev.py
> *** test_sunaudiodev.py 2001/01/17 21:51:36     1.9
> --- test_sunaudiodev.py 2001/04/14 01:47:49
> ***************
> *** 1,6 ****
> ! from test_support import verbose, findfile, TestFailed
>   import sunaudiodev
>   import os
> 
>   def play_sound_file(path):
>       fp = open(path, 'r')
> --- 1,14 ----
> ! from test_support import verbose, findfile, TestFailed, TestSkipped
>   import sunaudiodev
>   import os
> +
> + try:
> +     audiodev = os.environ["AUDIODEV"]
> + except KeyError:
> +     audiodev = "/dev/audio"
> +
> + if not os.path.exists(audiodev):
> +     raise TestSkipped("no audio device dound!")
> 
>   def play_sound_file(path):
>       fp = open(path, 'r')

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From Jason.Tishler at dothill.com  Sat Apr 14 04:25:01 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Fri, 13 Apr 2001 22:25:01 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
Message-ID: <20010413222501.D5606@dothill.com>

I configured as follows:

    configure --with-threads=no

When I run the regression tests I get the following:

    test test_threadedtempfile crashed -- exceptions.AttributeError: 'threading' module has no attribute 'Event'

Should this test only be run if Python is built with thread support?

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From m.favas at per.dem.csiro.au  Sat Apr 14 04:45:41 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 10:45:41 +0800
Subject: [Python-Dev] 2.1c1: "make test" core dumps on SGI Irix
References: <3AD7A3FD.CBEB9510@per.dem.csiro.au> <200104140243.VAA11034@cj20424-a.reston1.va.home.com>
Message-ID: <3AD7B9D5.CCE64D03@per.dem.csiro.au>

Recompiling floatobject.c without optimization makes the bus error
during "make test" go away. Perhaps the SGI section in the README could
be updated here - it only mentions a possible problem with
complexobject.c and Numeric.

"make test" now fails on:

test_largefile
test test_largefile crashed -- exceptions.IOError: [Errno 22] Invalid
argument

and

test_locale
test test_locale crashed -- exceptions.ValueError: unpack sequence of
wrong size

and

test_zlib
*** Termination code 9 (bu21)

More details:

python Lib/test/test_largefile.py
create large file via seek (may be sparse file) ...
Traceback (most recent call last):
  File "Lib/test/test_largefile.py", line 63, in ?
    f.flush()
IOError: [Errno 22] Invalid argument


python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ...
Traceback (most recent call last):
  File "Lib/test/test_locale.py", line 29, in ?
    testformat("%f", 1024, grouping=1, output='1,024.000000')
  File "Lib/test/test_locale.py", line 18, in testformat
    result = locale.format(formatstr, value, grouping = grouping)
  File "/tmp_mnt/home/solo/mark/python/Python-2.1c1/Lib/locale.py", line
137, in format
    fields[0],seps=_group(fields[0])
ValueError: unpack sequence of wrong size


python Lib/test/test_zlib.py
0xe5c1a120 0x43b6aa94
0xbd602f7 0xbd602f7
expecting Bad compression level
expecting Invalid initialization option
expecting Invalid initialization option
normal compression/decompression succeeded
compress/decompression obj succeeded
decompress with init options succeeded
decompressobj with init options succeeded
Killed

Recompiling _everything_ without optimization produces no change. I have
no time to poke around further at the moment - later this afternoon...

M

Guido van Rossum wrote:
> 
> > IRIX64 dodo 6.5 07201607 IP35, MIPSpro Compilers: Version 7.30
> >
> > "make test" core dumps with no output from any test completed. Running
> > them one-by-one reveals that the (first?) core dump is in
> > test___all__.py.
> > python Lib/test/test___all__.py
> > Bus error (core dumped)
> 
> Try compiling without -O?
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From fdrake at acm.org  Sat Apr 14 05:11:54 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 13 Apr 2001 23:11:54 -0400 (EDT)
Subject: [Python-Dev] 2.1c1: test_sunaudiodev fails on Sun servers 
In-Reply-To: <3AD7B258.7ED22029@per.dem.csiro.au>
References: <3AD7A2D1.B04928AE@per.dem.csiro.au>
	<200104140242.VAA11020@cj20424-a.reston1.va.home.com>
	<15063.44223.710582.338422@cj42289-a.reston1.va.home.com>
	<3AD7B258.7ED22029@per.dem.csiro.au>
Message-ID: <15063.49146.634503.336638@cj42289-a.reston1.va.home.com>

Mark Favas writes:
 > Yes, that works for me (perhaps we could change "dound" to "found"
 > though <wink>).

  Hey, you'll have to file a formal bug report on SF for that!  ;-)
Ok, this is checked in.  If everyone who can build with the
sunaudiodev module would test this, I'd really appreciate any feedback
on this!


  -Fred

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




From gherman at darwin.in-berlin.de  Sat Apr 14 08:25:17 2001
From: gherman at darwin.in-berlin.de (Dinu Gherman)
Date: Sat, 14 Apr 2001 08:25:17 +0200
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
Message-ID: <3AD7ED4D.58597DFD@darwin.in-berlin.de>

> Examples
> 
>     Here is an example of an interactive session exhibiting the
>     expected behaviour of this feature.
> 
>         >>> "12345 John Doe" / "%5d %8s"
>         (12345, 'John Doe')
>         >>> "12 34 56 7.890" / "%d %d %d %f"
>         (12, 34, 56, 7.8899999999999997)
>         >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
>         {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
>         >>> "1 2" / "%d %d %d"
>         Traceback (innermost last):
>           File "<stdin>", line 1, in ?
>         TypeError: not all arguments filled
 

Kind of late to jump in, but this is the nature of this list.

I'd like to support Peter's proposal for having *some* kind 
of inverse mechanism to string formatting using '%'. Now, that
doesn't mean anything, of course, but no matter what the syn-
tax would look like: I'd prefer having that feature over not
having it and I'll give an example below.

Reminding you of a thread I triggered a while ago (that went 
slightly astray) which was, kind of, received with suspicion,
I notice that it matches quite nicely with Peter's (more ge-
neral) idea. Here's the thread's summary:

  Grouping function for string module?          
http://mail.python.org/pipermail/python-list/1999-September/011875.html

Combining this I'd like to see something like the following 
(again, maybe with a different syntax):

    >>> "1010000011110101" / "%4s%4s%4s%4s"
    ('1010', '0000', '1111', '0101')
    >>> "10100000111101" / "%4s%4s%4s%4s"
    ('1010', '0000', '1111', '01')

or even:

    >>> "1010000011110101" / ("%4s" * 4)
    ('1010', '0000', '1111', '0101')

;-)

Regards and Happy Easter (will be away for a week)!

Dinu

-- 
Dinu C. Gherman
ReportLab Consultant - http://www.reportlab.com
................................................................
"The only possible values [for quality] are 'excellent' and 'in-
sanely excellent', depending on whether lives are at stake or 
not. Otherwise you don't enjoy your work, you don't work well, 
and the project goes down the drain." 
                    (Kent Beck, "Extreme Programming Explained")



From tim.one at home.com  Sat Apr 14 09:50:32 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 14 Apr 2001 03:50:32 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <20010413222501.D5606@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEDDJMAA.tim.one@home.com>

[Jason Tishler]
> I configured as follows:
>
>     configure --with-threads=no
>
> When I run the regression tests I get the following:
>
>     test test_threadedtempfile crashed --
> exceptions.AttributeError: 'threading' module has no attribute 'Event'
>
> Should this test only be run if Python is built with thread support?

Yes, it should be run only when there's thread support (well, actually,
regrtest.py will *try* it regardless, but ... see what follows).

The first thing test_threadedtempfile does is

    import threading

and I *expect* that to die with an ImportError when there's no thread
suppport, due to threading.py trying to do

    import thread

early on.  regrtest.py looks out for ImportErrors, and I expect it to say

    test test_threadedtempfile skipped --  No module named thread

in your situation.

So the question is why you're not getting an ImportError on "import thread"
(try it an interactive Python to make sure that's the cause).  Why you're not
getting an ImportError I'll have to leave to someone who understands the Unix
config process.

OTOH, the threading module you are importing is damaged, else threading.Event
would have existed.  So perhaps there's a deeper problem here than just a
config thing.  First let us know what happens when you try "import thread" on
its own.




From mwh21 at cam.ac.uk  Sat Apr 14 12:05:07 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: Sat, 14 Apr 2001 11:05:07 +0100 (BST)
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEDDJMAA.tim.one@home.com>
Message-ID: <Pine.LNX.4.10.10104141059210.19675-100000@localhost.localdomain>

On Sat, 14 Apr 2001, Tim Peters wrote:

> So the question is why you're not getting an ImportError on "import
> thread" (try it an interactive Python to make sure that's the cause).  
> Why you're not getting an ImportError I'll have to leave to someone
> who understands the Unix config process.

That one's easy: a testcase earlier has tried to "import threading";
*that* import died with an ImportError when threading tried to import
"thread", and then the "import threading" in
test_threadtempfileorwhatever.py gets the half finished module object that
had been constructed when "import thread" blew up for the first time.

Maybe modules should be removed from sys.modules when they fail to be
imported due to an exception?

Cheers,
M.





From tim.one at home.com  Sat Apr 14 12:16:50 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 14 Apr 2001 06:16:50 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <Pine.LNX.4.10.10104141059210.19675-100000@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEDKJMAA.tim.one@home.com>

I'm sure Michael is right; tried to send email about that before, but never
saw it come across; the same problem was reported recently by someone else on
SF:

http://sourceforge.net/tracker/?func=detail&atid=105470&
    aid=416089&group_id=5470

(although SF appears dead now too!).

[Michael Hudson]
> ...
> Maybe modules should be removed from sys.modules when they fail to be
> imported due to an exception?

As I said in the phantom email nobody saw <wink>, this isn't the first time
we've been screwed by this in the test suite (e.g., look near the top of
test___all__.py for evidence of the last time I wrestled with this).  But I'm
pretty sure Guido explicitly declined to do what you suggest, although I
can't recall why now.

sleep-now-argue-tomorrow-ly y'rs  - tim




From guido at digicool.com  Sat Apr 14 16:05:29 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 09:05:29 -0500
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: Your message of "Fri, 13 Apr 2001 21:41:39 -0400."
             <20010413214139.A3800@thyrsus.com> 
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>  
            <20010413214139.A3800@thyrsus.com> 
Message-ID: <200104141405.JAA12126@cj20424-a.reston1.va.home.com>

> >   - Eric Raymond extended the pstats module with a simple interactive
> >     statistics browser, invoked when the module is run as a script.
> 
> ...which I tested by using it to speed-tune the crap out of CML2, dropping the
> configurator's startup time from over 15 seconds to about 2 :-).
> 
> CML2 has been officially accepted for inclusion in the Linux kernel, BTW.
> Linus himself quashed the anti-Python grumbling from some of the more
> conservative types on lkml by uttering the ukase "Python is not an issue."
> It's scheduled to go in sometime in the 2.5.1 to 2.5.2 series.

Congratulations are in order, Eric!

I guess a more positive endorsement of Python from Linus will be out
of the question for now... :-)

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




From Jason.Tishler at dothill.com  Sat Apr 14 15:59:28 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Sat, 14 Apr 2001 09:59:28 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEDJJMAA.tim.one@home.com>; from tim.one@home.com on Sat, Apr 14, 2001 at 06:01:07AM -0400
References: <20010413222501.D5606@dothill.com> <LNBBLJKPBEHFEDALKOLCKEDJJMAA.tim.one@home.com>
Message-ID: <20010414095928.A5743@dothill.com>

Tim,

On Sat, Apr 14, 2001 at 06:01:07AM -0400, Tim Peters wrote:
> I bet this fresh SF bug report explains it:
> 
> http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416089&group_id=5470

Bingo!  See the following:

    $ ./python
    Python 2.1c1 (#1, Apr 13 2001, 21:47:33) 
    [GCC 2.95.3-2 (cygwin special)] on cygwin_nt-4.01
    Type "copyright", "credits" or "license" for more information.
    >>> import threading
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
      File "/home/jt/src/Python-2.1c1/Lib/threading.py", line 5, in ?
        import thread
    ImportError: No module named thread
    >>> import threading
    >>>

> Instead they deliver a, umm, bogus module object <wink>.  I've
> never liked this behavior -- but probably can't change it for 2.1 final.  It
> won't be the first time we've needed to worm around it in the test suite
> either ...

Oh well, there is always 2.2...

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From esr at thyrsus.com  Sat Apr 14 16:10:55 2001
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 10:10:55 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <200104141405.JAA12126@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 09:05:29AM -0500
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com> <20010413214139.A3800@thyrsus.com> <200104141405.JAA12126@cj20424-a.reston1.va.home.com>
Message-ID: <20010414101055.A8625@thyrsus.com>

Guido van Rossum <guido at digicool.com>:
> > CML2 has been officially accepted for inclusion in the Linux kernel, BTW.
> 
> Congratulations are in order, Eric!

It wouldn't have happened without your signoff on including the curses
module and friends in the 2.0 standard libraries.

Eric's clever plan, if you haven't guessed already, was to use Python
and the Linux kernel tree to goose the evolution of both projects,
using the requirements from each one to overcome the resistance
of the more conservative people in the other camp.  

And, while the major reason I made Python 2.x a prerequisite for CML2
was to shrink its footprint in the kernel tree, it was not absent from
my mind that doing so would put salutary pressure on the Linux distros
to upgrade to 2.x sooner than they might have otherwise.

> I guess a more positive endorsement of Python from Linus will be out
> of the question for now... :-)

For now.  But...the *next* step in the sinister master plan, after
CML2 is in, involves replacing all the Perl and awk and Tcl in the
kernel tree with Python.  The conservatives on lkml who objected to
adding Python to the build-prerequisites list are going to find that
their own arguments for mimimal external dependencies actually support
this move.

OK, so I'm going to rewrite all the (non-bash) kernel support scripts.
In the process, I'm going to make that codebase cleaner, smaller,
better documented, and more featureful.  Give me six months after CML2
goes in and I *will* have Linus and the lkml crowd making approving
noises about Python.  Count on it.

At that point, we'll have seized a major piece of the high ground, with
knock-on effects on Python's acceptance level everywhere.  Which was
*also* part of the plan, exactly dual to the effect on Linux of making 
kernel configuration so easy your Aunt Tillie could do it.

There is one implication of this scenario for Python development
itself -- that it's time to take a serious swing at eliminating our
dependency on Tcl for GUIs.  Whether we do this by adding wxPython to
the core or in some other way I don't care, but it would strengthen my
hand with the lkml crowd considerably if Python no longer had that
dependency.

Sometime in there, you and I gotta find time to PEP the Python library reorg,
too...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The danger (where there is any) from armed citizens, is only to the
*government*, not to *society*; and as long as they have nothing to
revenge in the government (which they cannot have while it is in their
own hands) there are many advantages in their being accustomed to the 
use of arms, and no possible disadvantage.
        -- Joel Barlow, "Advice to the Privileged Orders", 1792-93



From jeremy at digicool.com  Sat Apr 14 16:32:28 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Sat, 14 Apr 2001 10:32:28 -0400 (EDT)
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <20010413214139.A3800@thyrsus.com>
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>
	<20010413214139.A3800@thyrsus.com>
Message-ID: <15064.24444.322307.549038@slothrop.digicool.com>

>>>>> "ESR" == Eric S Raymond <esr at thyrsus.com> writes:

  ESR> Guido van Rossum <guido at python.org>:
  >> - Eric Raymond extended the pstats module with a simple
  >>   interactive
  >> statistics browser, invoked when the module is run as a script.

  ESR> ...which I tested by using it to speed-tune the crap out of
  ESR> CML2, dropping the configurator's startup time from over 15
  ESR> seconds to about 2 :-).

Please take a look at the bug report I filed on SF.  The
ProfileBrowser seems to have a lot of bugs.  The first several times I
tried it, it crashed with uncaught exceptions.  As an example, the
strip command tries to call a strip_order() method, which isn't
defined anywhere in the module.

Perhaps there should be a test suite for the code.  Otherwise, it's
hard to tell if it works, since it was checked in the day of the
release candidate.

Jeremy




From aahz at rahul.net  Sat Apr 14 16:39:48 2001
From: aahz at rahul.net (Aahz Maruch)
Date: Sat, 14 Apr 2001 07:39:48 -0700 (PDT)
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <20010414101055.A8625@thyrsus.com> from "Eric S. Raymond" at Apr 14, 2001 10:10:55 AM
Message-ID: <20010414143948.2018F99C85@waltz.rahul.net>

Eric S. Raymond wrote:
> 
> And, while the major reason I made Python 2.x a prerequisite for CML2
> was to shrink its footprint in the kernel tree, it was not absent from
> my mind that doing so would put salutary pressure on the Linux distros
> to upgrade to 2.x sooner than they might have otherwise.

Sounds good.  OTOH, due to the GPL issue with 2.0 itself, this will
likely require either 2.0.1 or 2.1; I'll have a small preference for
2.0.1 myself.  I've been holding off on the next round of PEP6 (bugfix
release process) until after the 2.1 release.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.



From esr at thyrsus.com  Sat Apr 14 16:53:15 2001
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 10:53:15 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <15064.24444.322307.549038@slothrop.digicool.com>; from jeremy@digicool.com on Sat, Apr 14, 2001 at 10:32:28AM -0400
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com> <20010413214139.A3800@thyrsus.com> <15064.24444.322307.549038@slothrop.digicool.com>
Message-ID: <20010414105315.A9299@thyrsus.com>

Jeremy Hylton <jeremy at digicool.com>:
> Please take a look at the bug report I filed on SF. 

I'll do so.

> Perhaps there should be a test suite for the code.  Otherwise, it's
> hard to tell if it works, since it was checked in the day of the
> release candidate.

It was working enough for me to get practical use out of it, anway.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No one is bound to obey an unconstitutional law and no courts are bound
to enforce it.  
	-- 16 Am. Jur. Sec. 177 late 2d, Sec 256



From esr at thyrsus.com  Sat Apr 14 17:21:33 2001
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 11:21:33 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <20010414105315.A9299@thyrsus.com>; from esr@thyrsus.com on Sat, Apr 14, 2001 at 10:53:15AM -0400
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com> <20010413214139.A3800@thyrsus.com> <15064.24444.322307.549038@slothrop.digicool.com> <20010414105315.A9299@thyrsus.com>
Message-ID: <20010414112133.A9594@thyrsus.com>

Eric S. Raymond <esr at thyrsus.com>:
> Jeremy Hylton <jeremy at digicool.com>:
> > Please take a look at the bug report I filed on SF. 
> 
> I'll do so.
> 
> > Perhaps there should be a test suite for the code.  Otherwise, it's
> > hard to tell if it works, since it was checked in the day of the
> > release candidate.
> 
> It was working enough for me to get practical use out of it, anway.

Trust Jeremy to find one of the only two methods I forgot to test after
refactoring the browser to use the self.generic method.  Should now be
fixed in CVS; I have to go fight a different fire now, but I'll 
double-check all the methods this afternoon.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Among the many misdeeds of British rule in India, history will look
upon the Act depriving a whole nation of arms as the blackest."
        -- Mohandas Ghandhi, An Autobiography, pg 446



From guido at digicool.com  Sat Apr 14 19:27:09 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 12:27:09 -0500
Subject: [Python-Dev] make clean and make clobber semantics
Message-ID: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>

I just noticed for the first time that the semantics of "make clean"
and "make clobber" have changed.  "make clean" used to remove the .so
files too, AFAIK, but no longer does so.  "make clean" used to leave
the configuration files lying around, but now seems to remove at least
some of them.

One of the consequences of all this is that, after "make clean",
another "make" doesn't rebuild the extensions, because setup.py finds
that the .so files are still there and decides not to rebuild the
missing .o's.

Another consequence is that after "make clobber" you have to rerun the
configure script (or say "make recheck").  This takes almost as long
as the rest of the build...

In other words, "make clean" doesn't go far enough, and "make clobber"
goes too far, for what I seem to want most often (recompile every C
source file).

Can someone suggest a fix?

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



From mal at lemburg.com  Sat Apr 14 18:43:20 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 14 Apr 2001 18:43:20 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  
 conversion?
References: <20010413134326-r01010600-bafaee65@213.84.27.177>
Message-ID: <3AD87E28.CCC894AC@lemburg.com>

Just van Rossum wrote:
> 
> M.-A. Lemburg wrote:
> 
> > I don't know why this thread lead to tweaking stdio -- after all
> > we only need a solution for the Python tokenizer and not a general
> > purpose stdio abstraction of text files unless I'm missing something
> > here...
> 
> Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all,
> but then what about all tools that read source files line by line? Eg.
> linecache.py, all IDE's, etc. etc. As Tim wrote a while back:
> 
>   importing-is-only-the-start-of-the-battle
> 
> So no, we don't "only need a solution for the Python tokenizer"...

See... that's why we need a PEP on these things ;-)

Seriously, I thought that you were only talking about being
able to work on Python code from different platforms in a network
(e.g. code is shared by a Windows box and development takes place
on a Mac).

Now it seems that you want to go for the full Monty :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at digicool.com  Sat Apr 14 19:47:51 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 12:47:51 -0500
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
In-Reply-To: Your message of "Sat, 14 Apr 2001 08:59:34 +0800."
             <3AD7A0F6.7673FDD3@per.dem.csiro.au> 
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au> 
Message-ID: <200104141747.MAA21913@cj20424-a.reston1.va.home.com>

> FreeBSD 4.2-20010225-STABLE, gcc 2.95.2
> 
> ./python Lib/test/test_zipfile.py
> Traceback (most recent call last):
>   File "Lib/test/test_zipfile.py", line 35, in ?
>     zipTest(file, zipfile.ZIP_STORED, writtenData)
>   File "Lib/test/test_zipfile.py", line 18, in zipTest
>     zip.close()
>   File "/home/mark/src/python/CVS/python/dist/src/Lib/zipfile.py", line
> 471, in close
>     self.fp.flush()
> IOError: [Errno 9] Bad file descriptor
> 
> Looks like FreeBSD objects to doing a flush() on a file opened for
> reading. The self.fp.flush() call should probably be part of the
> preceding if-block relating to files opened in "a" or "w' mode.

You're right.  I've fixed this.

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



From nas at python.ca  Sat Apr 14 18:52:45 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sat, 14 Apr 2001 09:52:45 -0700
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 12:27:09PM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>
Message-ID: <20010414095245.A7402@glacier.fnational.com>

Guido van Rossum wrote:
> Can someone suggest a fix?

I think adding something like:

    find . -name '*.so' -exec rm -f {} ';'

to the clean target would work.  You sould remove the Module/*.so
pattern in the clobber target and fix the comments as well.

One more thing Guido, can you touch Include/graminit.h and
Python/graminit.c before making the tarball?  

  Neil



From mal at lemburg.com  Sat Apr 14 19:02:09 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 14 Apr 2001 19:02:09 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  
 conversion?
References: <LNBBLJKPBEHFEDALKOLCIECBJMAA.tim.one@home.com>
Message-ID: <3AD88291.8A82378@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > I don't know why this thread lead to tweaking stdio -- after all
> > we only need a solution for the Python tokenizer ...
> 
> [Just]
> > Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is
> > great and all,> but then what about all tools that read source
> > files line by line? ...
> 
> Note that this is why the topic needs a PEP:  nothing here is new; the same
> debates reoccur every time it comes up.

Right.
 
> [Aahz]
> > ...
> > QIO claims that it can be configured to recognize different
> > kinds of line endings.
> 
> It can be, yes, but in the same sense as Awk/Perl paragraph mode:  you can
> tell it to consider any string (not just single character) as meaning "end of
> the line", but it's a *fixed* string per invocation.  What people want *here*
> is more the ability to recognize the regular expression
> 
>     \r\n?|\n
> 
> as ending a line, and QIO can't do that directly (as currently written).  And
> MAL probably wants Unicode line-end detection:
> 
>     http://www.unicode.org/unicode/reports/tr13/

Right ;-)
 
> > QIO is claimed to be 2-3 times faster than Python 1.5.2; don't
> > know how that compares to 2.x.
> 
> The bulk of that was due to QIO avoiding per-character thread locks.  2.1
> avoids them too, so most of QIO's speed advantage should be gone now.  But
> QIO's internals could certainly be faster than they are (this is obscure
> because QIO.readline() has so many optional behaviors that the maze of
> if-tests makes it hard to see the speed-crucial bits; studying Perl's
> line-reading code is a better model, because Perl's speed-crucial inner loop
> has no non-essential operations -- Perl makes the *surrounding* code sort out
> the optional bits, instead of bogging down the loop with them).

Just curious: for the applications which Just has in mind,
reading source code line-by-line is not really needed. Wouldn't
it suffice to read the whole file, split it into lines and then
let the tools process the resulting list of lines ?

Maybe a naive approach, but one which will most certainly work
on all platforms without having to replace stdio...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From just at letterror.com  Sat Apr 14 19:24:44 2001
From: just at letterror.com (Just van Rossum)
Date: Sat, 14 Apr 2001 19:24:44 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line   conversion?
In-Reply-To: <3AD87E28.CCC894AC@lemburg.com>
Message-ID: <20010414192445-r01010600-f8273ce6@213.84.27.177>

M.-A. Lemburg wrote:

> > So no, we don't "only need a solution for the Python tokenizer"...
> 
> See... that's why we need a PEP on these things ;-)

Agreed. I'll try to write one, once I'm feeling better: having the flu doesn't
seem to help focussing on actual content...

Just



From guido at digicool.com  Sat Apr 14 20:38:09 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 13:38:09 -0500
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:52:45 MST."
             <20010414095245.A7402@glacier.fnational.com> 
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>  
            <20010414095245.A7402@glacier.fnational.com> 
Message-ID: <200104141838.NAA23079@cj20424-a.reston1.va.home.com>

> I think adding something like:
> 
>     find . -name '*.so' -exec rm -f {} ';'
> 
> to the clean target would work.  You sould remove the Module/*.so
> pattern in the clobber target and fix the comments as well.

Will do.

> One more thing Guido, can you touch Include/graminit.h and
> Python/graminit.c before making the tarball?  

Why?

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



From just at letterror.com  Sat Apr 14 19:54:54 2001
From: just at letterror.com (Just van Rossum)
Date: Sat, 14 Apr 2001 19:54:54 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line   conversion?
In-Reply-To: <3AD88291.8A82378@lemburg.com>
Message-ID: <20010414195455-r01010600-bf420a02@213.84.27.177>

M.-A. Lemburg wrote:

> Just curious: for the applications which Just has in mind,
> reading source code line-by-line is not really needed. Wouldn't
> it suffice to read the whole file, split it into lines and then
> let the tools process the resulting list of lines ?
> 
> Maybe a naive approach, but one which will most certainly work
> on all platforms without having to replace stdio...

The point is to let existing tools work with all line end conventions *without*
changing the tools. Whether this means replacing stdio I still don't know
<wink>, but it sure means changing the behavior of the Python file object in
text mode.

Just



From paulp at ActiveState.com  Sat Apr 14 20:07:51 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Sat, 14 Apr 2001 11:07:51 -0700
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au> <200104141747.MAA21913@cj20424-a.reston1.va.home.com>
Message-ID: <3AD891F7.1361C560@ActiveState.com>

Do all of these little tweaks mean that we will have another release
candidate or will we just decide that they are low-risk enough not to
worry about? Ideally, the only change from the relcand to final would be
release notes and version numbers...

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From guido at digicool.com  Sat Apr 14 21:41:50 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 14:41:50 -0500
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
In-Reply-To: Your message of "Sat, 14 Apr 2001 11:07:51 MST."
             <3AD891F7.1361C560@ActiveState.com> 
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au> <200104141747.MAA21913@cj20424-a.reston1.va.home.com>  
            <3AD891F7.1361C560@ActiveState.com> 
Message-ID: <200104141941.OAA30229@cj20424-a.reston1.va.home.com>

> Do all of these little tweaks mean that we will have another release
> candidate or will we just decide that they are low-risk enough not to
> worry about? Ideally, the only change from the relcand to final would be
> release notes and version numbers...

I don't think we need another release candidate.

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



From paul at pfdubois.com  Sat Apr 14 20:36:27 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Sat, 14 Apr 2001 11:36:27 -0700
Subject: [Python-Dev] 2.1c1 OK with Numeric -- and a testing question
Message-ID: <ADEOIFHFONCLEEPKCACCEECMCIAA.paul@pfdubois.com>

I built Numeric with 2.1c1 (on Windows) and it passes all our tests.

I intend to convert the Numeric tests to use PyUnit at some point. Is there
a recommended example? I converted the MA test suite by just reading the
PyUnit web page and I have the feeling I'm missing something. I made it work
but it wasn't any nicer than my existing test when I got done. (ANYTHING is
more elegant than the existing Numeric test).





From esr at thyrsus.com  Sat Apr 14 20:47:39 2001
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 14:47:39 -0400
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
In-Reply-To: <200104141941.OAA30229@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 02:41:50PM -0500
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au> <200104141747.MAA21913@cj20424-a.reston1.va.home.com> <3AD891F7.1361C560@ActiveState.com> <200104141941.OAA30229@cj20424-a.reston1.va.home.com>
Message-ID: <20010414144739.A11425@thyrsus.com>

Guido van Rossum <guido at digicool.com>:
> > Do all of these little tweaks mean that we will have another release
> > candidate or will we just decide that they are low-risk enough not to
> > worry about? Ideally, the only change from the relcand to final would be
> > release notes and version numbers...
> 
> I don't think we need another release candidate.

I've fixed my loose end.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Good intentions will always be pleaded for every assumption of
authority. It is hardly too strong to say that the Constitution was
made to guard the people against the dangers of good intentions. There
are men in all ages who mean to govern well, but they mean to
govern. They promise to be good masters, but they mean to be masters.
	-- Daniel Webster



From fdrake at beowolf.digicool.com  Sat Apr 14 22:09:33 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Sat, 14 Apr 2001 16:09:33 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010414200933.0218628A09@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


Final Python 2.1 documentation.




From nas at python.ca  Sat Apr 14 22:18:08 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sat, 14 Apr 2001 13:18:08 -0700
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104141838.NAA23079@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 01:38:09PM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com> <20010414095245.A7402@glacier.fnational.com> <200104141838.NAA23079@cj20424-a.reston1.va.home.com>
Message-ID: <20010414131808.A7702@glacier.fnational.com>

Guido van Rossum wrote:
> > One more thing Guido, can you touch Include/graminit.h and
> > Python/graminit.c before making the tarball?  
> 
> Why?

So that those files are not rebuilt.  If the source directory is
read-only then make will fail to build those files.  Its a very
minor issue.

  Neil



From tim.one at home.com  Sat Apr 14 22:35:58 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 14 Apr 2001 16:35:58 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <200104141421.JAA16441@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com>

[Michael Hudson]
> Maybe modules should be removed from sys.modules when they fail to be
> imported due to an exception?

[Guido]
> This has been suggested before, but *in general* this is not a good
> idea.  For example, you want to debug the remains of the failed
> module.

Ya, I've heard you say something like that before, but haven't understood
what it meant.  That is, I've never had, or been able to picture, a case
where having a module object in an incomplete and unknown state is actually
of use.  OTOH, I've certainly burned my share of time recovering from that
importing a broken module only fails the first time.  It's like Python only
raised an exception the first time somebody tried to open a particular
non-existent file for reading, but the second time it returned a file object
that may or may not fail in use, and may or may not work correctly when it
doesn't fail, depending on what you do with it.

> However, the test suite can easily guard against this, e.g. by
> inserting "import thread" before "import threading" whereever it
> occurs.

So how come a failed attempt to import thread doesn't leave a bogus module
object in sys.modules["thread"] too <0.9 wink>?  This is obscure stuff.  Is
"debugging the remains" of sufficient use to make up for the conceptual
complications?




From guido at digicool.com  Sun Apr 15 02:59:16 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 19:59:16 -0500
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: Your message of "Sat, 14 Apr 2001 16:35:58 -0400."
             <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com> 
Message-ID: <200104150059.TAA30951@cj20424-a.reston1.va.home.com>

> [Michael Hudson]
> > Maybe modules should be removed from sys.modules when they fail to be
> > imported due to an exception?
> 
> [Guido]
> > This has been suggested before, but *in general* this is not a good
> > idea.  For example, you want to debug the remains of the failed
> > module.

[Tim]
> Ya, I've heard you say something like that before, but haven't understood
> what it meant.  That is, I've never had, or been able to picture, a case
> where having a module object in an incomplete and unknown state is actually
> of use.  OTOH, I've certainly burned my share of time recovering from that
> importing a broken module only fails the first time.  It's like Python only
> raised an exception the first time somebody tried to open a particular
> non-existent file for reading, but the second time it returned a file object
> that may or may not fail in use, and may or may not work correctly when it
> doesn't fail, depending on what you do with it.

Maybe.  It could be that the deep reason is mostly that the
implementation doesn't have the information available to decide what
to delete.

> > However, the test suite can easily guard against this, e.g. by
> > inserting "import thread" before "import threading" whereever it
> > occurs.
> 
> So how come a failed attempt to import thread doesn't leave a bogus module
> object in sys.modules["thread"] too <0.9 wink>?  This is obscure stuff.  Is
> "debugging the remains" of sufficient use to make up for the conceptual
> complications?

I'll think about this over the weekend.  I know people have tried to
convince me of changing this before, and I've tried to listen, but
I've never changed it, so I guess there must be a good reason.  It's
worth trying to remember what it is!

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



From guido at digicool.com  Sun Apr 15 03:47:22 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 20:47:22 -0500
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:07:29 +0800."
             <3AD7A2D1.B04928AE@per.dem.csiro.au> 
References: <3AD7A2D1.B04928AE@per.dem.csiro.au> 
Message-ID: <200104150147.UAA31288@cj20424-a.reston1.va.home.com>

> SunOS asafoetida 5.8, gcc 2.95.2
> 
> "make test" fails on running test_asynchat.py for the second time. The
> traceback is:
> 
[...]
> 
> Looks like Solaris takes a while to shut sockets down? (This is not a
> slow box, btw.) Or is there an option to not have the socket linger?

I see.  I've added a call to set the SO_REUSEADDR option in the server
thread.  This solves the problem on the SF compile farm Solaris box.

> Also, test_sunaudiodev fails, since setup.py tests only whether the
> platform is a Sun, not whether there is a /dev/audio as well. Servers
> don't have a /dev/audio. This is clearly a minor nit - I did log a bug
> against this some time ago.

Fred fixed this.

Thanks for these reports!

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



From guido at digicool.com  Sun Apr 15 03:57:00 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 20:57:00 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Sat, 14 Apr 2001 03:58:38 +0300."
             <E14oEOc-0001si-00@darjeeling> 
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>  
            <E14oEOc-0001si-00@darjeeling> 
Message-ID: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>

[Martin]
> > AFAICT, under my patch, when using OpenSSL on a system with EGD, it
> > will do the right thing. On a system with /dev/random, it will produce
> > a runtime warning, then add insecure entropy - in addition to the
> > secure entropy already obtained from /dev/random.
> > 
> > Under what I think is your patch, it will do the right thing on a
> > system with /dev/random. On a system with EGD, it will fail because of
> > the missing entropy.

[Moshe]
> Correct on both. My "worse" is: it would print a warning about using
> an insecure method on systems with /dev/random but without an EGD,
> even though it is secure.

And indeed it does when I tried it on SF's Solaris 8 box, which has
OpenSSL installed and /dev/random.

Even worse (in my view), the error message is as soon as the socket
module is imported!  This is bad, because most uses of socket aren't
interested in its SSl capabilities!

> Note that the EGD stuff is new with 2.1,
> so losing that is not a step backwards from 2.0. Printing a wrong warning
> is a step backwards, so in that sense my patch is more conservative.
>  
> After further contemplation, none of these is a pure win.
> It's up to Guido if he wants to use my patch instead of Martin's
> for 2.1final

I don't like either one.

> *** Modules/socketmodule.c	Sun Mar 18 18:38:50 2001
> --- new	Sat Apr 14 03:53:20 2001
> ***************
> *** 2545,2550 ****
> --- 2545,2551 ----
>   	if (PyDict_SetItemString(d, "SSLType",
>   				 (PyObject *)&SSL_Type) != 0)
>   		return;
> + #if OPENSSL_VERSION_NUMBER < 0x0090510fL

Don't you have this backwards?

>   	if (RAND_status() == 0) {
>   #ifdef USE_EGD
>   		char random_device[MAXPATHLEN+1];
> ***************
> *** 2571,2576 ****
> --- 2572,2578 ----
>   		RAND_seed(random_string, sizeof(random_string));
>   #endif /* USE_EGD */
>   	}
> + #endif /* OPENSSL_VERSION_NUMBER < 0x0090510fL */
>   #endif /* USE_SSL */
>   	PyDict_SetItemString(d, "error", PySocket_Error);
>   	PySocketSock_Type.ob_type = &PyType_Type;

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



From guido at digicool.com  Sun Apr 15 04:17:27 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 21:17:27 -0500
Subject: [Python-Dev] test_fcntl on Solaris 8
Message-ID: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>

While testing Python 2.1 on SF's Solaris 8 box, I noticed that it
hangs forever in test_fcntl, on this line:

  rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata)

Why could this be?  Could it be that the NFS lock server is stuck?

But I could also note that this test is pretty silly.  It has all this
platform-specific cruft to do a locking operation the hard way, while
the fcntl module supplies two operations (flock() and lockf()) that
could be used instead!

(Unfortunately, using lockf() I get the same behavior -- not
surprising, since the C code does the same thing that the Python code
was doing. :-( )

Should I update the test, or declare the machine broken?  (I *think* I
recall that the tests succeeded yesterday.)

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



From m.favas at per.dem.csiro.au  Sun Apr 15 05:18:39 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 11:18:39 +0800
Subject: [Python-Dev] Re: test_fcntl on Solaris 8
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>
Message-ID: <3AD9130F.3986FCDA@per.dem.csiro.au>

On my Solaris 8 box test_fcntl succeeds just fine (just tried it again),
with no hangs or hesitations - on the other hand, it's not using any NFS
filesystems, so that could be the problem with the SF box. So declare
the box broken... 

I'd be inclined to update the test anyway, since most people who want to
lock files will use the supplied flock()/lockf() rather than doing it
the hard way - so if the fcntl test locks files, it should use the
generic locking functions.

Guido van Rossum wrote:
> 
> While testing Python 2.1 on SF's Solaris 8 box, I noticed that it
> hangs forever in test_fcntl, on this line:
> 
>   rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata)
> 
> Why could this be?  Could it be that the NFS lock server is stuck?
> 
> But I could also note that this test is pretty silly.  It has all this
> platform-specific cruft to do a locking operation the hard way, while
> the fcntl module supplies two operations (flock() and lockf()) that
> could be used instead!
> 
> (Unfortunately, using lockf() I get the same behavior -- not
> surprising, since the C code does the same thing that the Python code
> was doing. :-( )
> 
> Should I update the test, or declare the machine broken?  (I *think* I
> recall that the tests succeeded yesterday.)
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From m.favas at per.dem.csiro.au  Sun Apr 15 05:34:46 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 11:34:46 +0800
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
Message-ID: <3AD916D6.49FE7B47@per.dem.csiro.au>

[Guido]
> [Moshe]
>> Correct on both. My "worse" is: it would print a warning about using
>> an insecure method on systems with /dev/random but without an EGD,
>> even though it is secure.

> And indeed it does when I tried it on SF's Solaris 8 box, which has
> OpenSSL installed and /dev/random.

Interesting - there's no /dev/random on my Solaris 8 boxes...

> Even worse (in my view), the error message is as soon as the socket
> module is imported!  This is bad, because most uses of socket aren't
>interested in its SSl capabilities!

Quite agree - I've got OpenSSL on my Tru64 box (no /dev/random either)
and it's annoying to get this warning whenever I "import socket". If the
OpenSSL bits don't themselves warn about insecure methods, I'd prefer if
Python didn't take it upon itself to nag <wink>.

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From guido at digicool.com  Sun Apr 15 06:40:40 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 23:40:40 -0500
Subject: [Python-Dev] Re: test_fcntl on Solaris 8
In-Reply-To: Your message of "Sun, 15 Apr 2001 11:18:39 +0800."
             <3AD9130F.3986FCDA@per.dem.csiro.au> 
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>  
            <3AD9130F.3986FCDA@per.dem.csiro.au> 
Message-ID: <200104150440.XAA31778@cj20424-a.reston1.va.home.com>

> On my Solaris 8 box test_fcntl succeeds just fine (just tried it again),
> with no hangs or hesitations - on the other hand, it's not using any NFS
> filesystems, so that could be the problem with the SF box. So declare
> the box broken... 

Thanks!

> I'd be inclined to update the test anyway, since most people who want to
> lock files will use the supplied flock()/lockf() rather than doing it
> the hard way - so if the fcntl test locks files, it should use the
> generic locking functions.

I agree, but I'd rather do that after 2.1.  Who knows what problem I
might introduce in the test (I really don't know these calls very
well).

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



From m.favas at per.dem.csiro.au  Sun Apr 15 07:15:39 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 13:15:39 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
Message-ID: <3AD92E7B.E6CC7EE7@per.dem.csiro.au>

Further investigations withe current CVS 2.1c1 (and everything compiled
without optimization) on a large multi=processor Irix 6.5 box with SGI's
MIPSpro 7.30 compiler:

The previously reported failure of test_largefile was due to running
"make test" on an NFS-mounted filesystem from a box that didn't support
large files. Works on a local filesystem.

The previously reported failure of test_zlib looks as though it is due
to Irix supplying as standard zlib version 1.0.4, whereas the zlib
module requires at least version 1.1.3. This won't be the only platform
where an incompatible zlib is system-supplied and built by default. An
autoconf test for the right version seems indicated (unless setup.py can
just extract the version string from <wherever>/zlib.h - it's there as
#define ZLIB_VERSION "1.0.4" on Irix, and #define ZLIB_VERSION "1.1.3"
on Solaris 8 (both in /usr/include)).


Tests still failing under Irix:

python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ...
Traceback (most recent call last):
  File "Lib/test/test_locale.py", line 29, in ?
    testformat("%f", 1024, grouping=1, output='1,024.000000')
  File "Lib/test/test_locale.py", line 18, in testformat
    result = locale.format(formatstr, value, grouping = grouping)
  File "/var/tmp/mark/src/Lib/locale.py", line 137, in format
    fields[0],seps=_group(fields[0])
ValueError: unpack sequence of wrong size


-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From guido at digicool.com  Sun Apr 15 08:33:25 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 01:33:25 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Sun, 15 Apr 2001 13:15:39 +0800."
             <3AD92E7B.E6CC7EE7@per.dem.csiro.au> 
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> 
Message-ID: <200104150633.BAA02770@cj20424-a.reston1.va.home.com>

[Mark Favas]
> Further investigations withe current CVS 2.1c1 (and everything compiled
> without optimization) on a large multi=processor Irix 6.5 box with SGI's
> MIPSpro 7.30 compiler:
> 
> The previously reported failure of test_largefile was due to running
> "make test" on an NFS-mounted filesystem from a box that didn't support
> large files. Works on a local filesystem.
> 
> The previously reported failure of test_zlib looks as though it is due
> to Irix supplying as standard zlib version 1.0.4, whereas the zlib
> module requires at least version 1.1.3. This won't be the only platform
> where an incompatible zlib is system-supplied and built by default. An
> autoconf test for the right version seems indicated (unless setup.py can
> just extract the version string from <wherever>/zlib.h - it's there as
> #define ZLIB_VERSION "1.0.4" on Irix, and #define ZLIB_VERSION "1.1.3"
> on Solaris 8 (both in /usr/include)).

I'll leave that to Andrew, I have no understanding of setup.py.
(Unfortunately Andrew seems out of town. :-( )

> Tests still failing under Irix:
> 
> python Lib/test/test_locale.py
> '%f' % 1024 =? '1,024.000000' ...
> Traceback (most recent call last):
>   File "Lib/test/test_locale.py", line 29, in ?
>     testformat("%f", 1024, grouping=1, output='1,024.000000')
>   File "Lib/test/test_locale.py", line 18, in testformat
>     result = locale.format(formatstr, value, grouping = grouping)
>   File "/var/tmp/mark/src/Lib/locale.py", line 137, in format
>     fields[0],seps=_group(fields[0])
> ValueError: unpack sequence of wrong size

Can you find out what at this point the value of
localeconv()['grouping'] is?  The only way this can happen, I think,
is for that to be a false value -- then _group() returns a single
string value instead of a tuple.  This seems to be a bug in _group()
-- the only place that uses it (format()) always assumes it returns a
tuple of two elements.

I'm not sure what the intention was...

Martin, can you suggest a way out here?

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



From m.favas at per.dem.csiro.au  Sun Apr 15 07:37:35 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 13:37:35 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
Message-ID: <3AD9339F.44C7FC05@per.dem.csiro.au>

Guido van Rossum wrote:
> 
> > Tests still failing under Irix:
> >
> > python Lib/test/test_locale.py
> > '%f' % 1024 =? '1,024.000000' ...
> > Traceback (most recent call last):
> >   File "Lib/test/test_locale.py", line 29, in ?
> >     testformat("%f", 1024, grouping=1, output='1,024.000000')
> >   File "Lib/test/test_locale.py", line 18, in testformat
> >     result = locale.format(formatstr, value, grouping = grouping)
> >   File "/var/tmp/mark/src/Lib/locale.py", line 137, in format
> >     fields[0],seps=_group(fields[0])
> > ValueError: unpack sequence of wrong size
> 
> Can you find out what at this point the value of
> localeconv()['grouping'] is?  The only way this can happen, I think,
> is for that to be a false value -- then _group() returns a single
> string value instead of a tuple.  This seems to be a bug in _group()
> -- the only place that uses it (format()) always assumes it returns a
> tuple of two elements.

localeconv()['grouping'] is "[]" at this point...

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From neal at metaslash.com  Sun Apr 15 09:38:34 2001
From: neal at metaslash.com (Neal Norwitz)
Date: Sun, 15 Apr 2001 03:38:34 -0400
Subject: [Python-Dev] Python 2.1 RC - PyChecker
References: <mailman.987196706.7970.python-list@python.org>
Message-ID: <3AD94FFA.7D930EF0@metaslash.com>

I've run the CVS version of PyChecker (http://pychecker.sourceforge.net)
against Python 2.1 RC1.  Below are the real or possible problems I found.

Some of the "not used" could be real errors, most are not.
All "uses named arguments" can be safely ignored.
"No global"s are definitely problems AFAICT (except 1 which can't be reached).

Neal
--

MimeWriter.py:108 Function (addheader) uses named arguments
MimeWriter.py:117 Function (startbody) uses named arguments
StringIO.py:187 Local variable (here) not used
UserString.py:137 Base class (UserString.UserString) __init__() not called
aifc.py:181 Local variable (math) not used
asynchat.py:99 No method (collect_incoming_data) found
asynchat.py:112 No method (found_terminator) found
	(2 methods documented, but should add method and raise exception?)
asyncore.py:155 Local variable (l) not used
audiodev.py:214 No global (BUFFERSIZE) found
bdb.py:220 Local variable (bp) not used
cgi.py:743 Base class (UserDict.UserDict) __init__() not called
cgi.py:843 Local variable (traceback) not used
chunk.py:109 No attribute (chunk_size) found
	(should be chunksize)
fileinput.py:292 Function (input) uses named arguments
getpass.py:29 Local variable (getpass) not used
gopherlib.py:172 Local variable (port) not used
gzip.py:276 Local variable (orig_size) not used
ihooks.py:494 Function (import_it) uses named arguments
ihooks.py:498 Function (import_it) uses named arguments
imaplib.py:1019 No global (j) found
locale.py:273 No global (l) found
	(can't be reach, but could remove last else and always raise error)
mailbox.py:21 No attribute (stop) found
mailbox.py:23 No attribute (start) found
mailbox.py:29 No method (_search_start) found
mailbox.py:34 No method (_search_end) found
	(_search_*() used in subclasses, add method and raise exception?)
mailbox.py:106 No method (_isrealfromline) found
mailbox.py:260 Local variable (time) not used
mhlib.py:651 Local variable (messages) not used
netrc.py:13 No global (file) found
	(should be filename)
nturl2path.py:45 Local variable (string) not used
pstats.py:188 Local variable (std_list) not used
pyclbr.py:206 Local variable (imports) not used
pydoc.py:170 Base class (exceptions.Exception) __init__() not called
rfc822.py:607 Local variable (expectaddrspec) not used
robotparser.py:234 Local variable (sys) not used
sgmllib.py:178 No global (SGMLParserError) found
	(should be SGMLParseError?)
shlex.py:99 Local variable (tok) not used
smtpd.py:312 No global (UnimplementedError) found
smtpd.py:375 Local variable (paths) not used
sndhdr.py:87 Local variable (hdr_size) not used
sndhdr.py:134 Local variable (style) not used
sre_parse.py:286 Local variable (here) not used
threading.py:547 Local variable (random) not used
threading.py:611 Local variable (time) not used
token.py:85 Local variable (string) not used
unittest.py:675 Local variable (opts) not used
urllib.py:1147 Local variable (x) not used
urllib2.py:450 No global (error_302_dict) found
	(needs req.?)
urllib2.py:630 No attribute (parent) found
urllib2.py:1053 No global (OpenerDirectory) found
urlparse.py:58 Local variable (path) not used
webbrowser.py:77 No global (ret) found



From moshez at zadka.site.co.il  Sun Apr 15 13:29:31 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Sun, 15 Apr 2001 14:29:31 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>
References: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>, <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>  
            <E14oEOc-0001si-00@darjeeling>
Message-ID: <E14okih-0004J3-00@darjeeling>

On Sat, 14 Apr 2001 20:57:00 -0500, Guido van Rossum <guido at digicool.com> wrote:

> Even worse (in my view), the error message is as soon as the socket
> module is imported!  This is bad, because most uses of socket aren't
> interested in its SSl capabilities!

Yeah, well, for 2.2 I'm planning to have a suggestion for redoing the
SSL support in Python, which is currently brain damaged in many ways,
and this is one.

> I don't like either one.

Mine at least has the property that we're no worse off then 2.0

> > + #if OPENSSL_VERSION_NUMBER < 0x0090510fL
> 
> Don't you have this backwards?

Yes, sorry.

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From guido at digicool.com  Sun Apr 15 15:34:38 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 08:34:38 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Sun, 15 Apr 2001 14:29:31 +0300."
             <E14okih-0004J3-00@darjeeling> 
References: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>, <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling> <E14oEOc-0001si-00@darjeeling>  
            <E14okih-0004J3-00@darjeeling> 
Message-ID: <200104151334.IAA09030@cj20424-a.reston1.va.home.com>

> > Even worse (in my view), the error message is as soon as the socket
> > module is imported!  This is bad, because most uses of socket aren't
> > interested in its SSl capabilities!
> 
> Yeah, well, for 2.2 I'm planning to have a suggestion for redoing the
> SSL support in Python, which is currently brain damaged in many ways,
> and this is one.

So why even bother adding the EGD support?

> > I don't like either one.
> 
> Mine at least has the property that we're no worse off then 2.0

Except that it still has a chance of issuing a warning!  I'm very
tempted to rip out all code added by your patch.

> > > + #if OPENSSL_VERSION_NUMBER < 0x0090510fL
> > 
> > Don't you have this backwards?
> 
> Yes, sorry.

I've had it.  I'm ripping out that patch.  People who want EGD support
desperate enough can download the patch from SF.

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



From guido at digicool.com  Sun Apr 15 15:48:35 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 08:48:35 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Sun, 15 Apr 2001 13:37:35 +0800."
             <3AD9339F.44C7FC05@per.dem.csiro.au> 
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>  
            <3AD9339F.44C7FC05@per.dem.csiro.au> 
Message-ID: <200104151348.IAA09108@cj20424-a.reston1.va.home.com>

> localeconv()['grouping'] is "[]" at this point...

It is looking like either the _locale.c module is not working right or
the platform's implementation of the en_US locals is broken.  I'm
afraid that only you will be able to make the determination. :-(

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



From m.favas at per.dem.csiro.au  Sun Apr 15 15:08:11 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 21:08:11 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
Message-ID: <3AD99D3B.A5441B0B@per.dem.csiro.au>

Guido van Rossum wrote:
> 
> [Mark Favas]
> >
> > The previously reported failure of test_zlib looks as though it is due
> > to Irix supplying as standard zlib version 1.0.4, whereas the zlib
> > module requires at least version 1.1.3. This won't be the only platform
> > where an incompatible zlib is system-supplied and built by default. An
> > autoconf test for the right version seems indicated (unless setup.py can
> > just extract the version string from <wherever>/zlib.h - it's there as
> > #define ZLIB_VERSION "1.0.4" on Irix, and #define ZLIB_VERSION "1.1.3"
> > on Solaris 8 (both in /usr/include)).
> 
> I'll leave that to Andrew, I have no understanding of setup.py.
> (Unfortunately Andrew seems out of town. :-( )

A patch to setup.py that works on the SGI where the version of zlib.h in
/usr/include is too low, and also works on my Tru64 box where the
version in /usr/local/include is just right follows:
(I'll also submit this to sourceforge.)

*** setup.py.orig       Sun Apr 15 20:59:34 2001
--- setup.py    Sun Apr 15 21:00:53 2001
***************
*** 449,457 ****
          # Andrew Kuchling's zlib module.
          # This require zlib 1.1.3 (or later).
          # See http://www.cdrom.com/pub/infozip/zlib/
!         if (self.compiler.find_library_file(lib_dirs, 'z')):
!             exts.append( Extension('zlib', ['zlibmodule.c'],
!                                    libraries = ['z']) )
  
          # Interface to the Expat XML parser
          #
--- 449,471 ----
          # Andrew Kuchling's zlib module.
          # This require zlib 1.1.3 (or later).
          # See http://www.cdrom.com/pub/infozip/zlib/
!         zlib_inc = find_file('zlib.h', [], inc_dirs)
!         if zlib_inc is not None:
!             zlib_h = zlib_inc[0] + '/zlib.h'
!             version = '"0.0.0"'
!             version_req = '"1.1.3"'
!             fp = open(zlib_h)
!             while 1:
!                 line = fp.readline()
!                 if not line:
!                     break
!                 if line.find('#define ZLIB_VERSION', 0) == 0:
!                     version = line.split()[2]
!                     break
!             if version >= version_req:
!                 if (self.compiler.find_library_file(lib_dirs, 'z')):
!                     exts.append( Extension('zlib', ['zlibmodule.c'],
!                                            libraries = ['z']) )
  
          # Interface to the Expat XML parser
          #

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From guido at digicool.com  Sun Apr 15 18:18:46 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 11:18:46 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Sun, 15 Apr 2001 21:08:11 +0800."
             <3AD99D3B.A5441B0B@per.dem.csiro.au> 
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>  
            <3AD99D3B.A5441B0B@per.dem.csiro.au> 
Message-ID: <200104151618.LAA10062@cj20424-a.reston1.va.home.com>

> A patch to setup.py that works on the SGI where the version of zlib.h in
> /usr/include is too low, and also works on my Tru64 box where the
> version in /usr/local/include is just right follows:

Thanks, Mark.  It works for me!

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



From thomas at xs4all.net  Sun Apr 15 17:31:08 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 17:31:08 +0200
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <200104150059.TAA30951@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 07:59:16PM -0500
References: <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com> <200104150059.TAA30951@cj20424-a.reston1.va.home.com>
Message-ID: <20010415173108.M2820@xs4all.nl>

On Sat, Apr 14, 2001 at 07:59:16PM -0500, Guido van Rossum wrote:

> [Tim]
> > [..] I've never had, or been able to picture, a case where having a
> > module object in an incomplete and unknown state is actually of use. 
> > OTOH, I've certainly burned my share of time recovering from that
> > importing a broken module only fails the first time.  It's like Python
> > only raised an exception the first time somebody tried to open a
> > particular non-existent file for reading, but the second time it
> > returned a file object that may or may not fail in use, and may or may
> > not work correctly when it doesn't fail, depending on what you do with
> > it.

> Maybe. 

Wouldn't the right place for the half-broken, import-failed module be in the
traceback object ? In fact, isn't it already *in* the traceback object ? :)

> It could be that the deep reason is mostly that the
> implementation doesn't have the information available to decide what
> to delete.

Deep magic can be added. Deep magic should be added, IMHO, unless ...

> I'll think about this over the weekend.  I know people have tried to
> convince me of changing this before, and I've tried to listen, but
> I've never changed it, so I guess there must be a good reason.  It's
> worth trying to remember what it is!

... you come up with a real reason for it to be as it is ;)

Happy-easter-for-those-of-you-with-permanent-'net-connections-*snif*-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Sun Apr 15 17:38:41 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 17:38:41 +0200
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 12:27:09PM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>
Message-ID: <20010415173841.N2820@xs4all.nl>

On Sat, Apr 14, 2001 at 12:27:09PM -0500, Guido van Rossum wrote:

> Another consequence is that after "make clobber" you have to rerun the
> configure script (or say "make recheck").  This takes almost as long
> as the rest of the build...

So don't do that. Run 'config.status' instead: it'll recreate your config
files (Makefile.pre, config.h, Setup.config) from cached info. It won't
rebuild everything, but it rebuilds config.h, which is what 'make clobber'
removes that breaks building.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at digicool.com  Sun Apr 15 18:47:32 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 11:47:32 -0500
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: Your message of "Sun, 15 Apr 2001 17:38:41 +0200."
             <20010415173841.N2820@xs4all.nl> 
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>  
            <20010415173841.N2820@xs4all.nl> 
Message-ID: <200104151647.LAA10237@cj20424-a.reston1.va.home.com>

> > Another consequence is that after "make clobber" you have to rerun the
> > configure script (or say "make recheck").  This takes almost as long
> > as the rest of the build...
> 
> So don't do that. Run 'config.status' instead: it'll recreate your config
> files (Makefile.pre, config.h, Setup.config) from cached info. It won't
> rebuild everything, but it rebuilds config.h, which is what 'make clobber'
> removes that breaks building.

Well, my issue is that before Neil "fixed" the Makefile, after a "make
clobber" a "make" would do the job.  Now, there's a dependency on
config.h but the Makefile doesn't know how to make that file.

Maybe it should.

But I've "fixed" it by adding a line to the clean target that removes
the .so files, so I don't have to use "make clobber".

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



From thomas at xs4all.net  Sun Apr 15 18:03:08 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 18:03:08 +0200
Subject: [Python-Dev] test_fcntl on Solaris 8
In-Reply-To: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 09:17:27PM -0500
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>
Message-ID: <20010415180307.P2820@xs4all.nl>

On Sat, Apr 14, 2001 at 09:17:27PM -0500, Guido van Rossum wrote:

> While testing Python 2.1 on SF's Solaris 8 box, I noticed that it
> hangs forever in test_fcntl, on this line:

>   rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata)

> Why could this be?  Could it be that the NFS lock server is stuck?

It could very well be that. NFS (version 2 or 3) locking is really, really
dumb. Not just the act of locking over NFS, but the whole protocol for
locking over NFS. If you consider that NFS is meant to be stateless, you can
quickly realize how locking (as well as the concept of 'open files' and what
should happen when you delete open files) do not fit well with NFS. There
are some other braindeadisms with NFS locking, though: it's not possible to
break a lock. If a machine is locking a file, and the machine goes down, the
lock stays in effect until the machine is back up. And 'a machine' is
identified with an ipaddress, so if it gets a new IP, tough. If it stays
down indefinately, tough.

And then there's the implementation side. I have yet to find an NFS server
or client that deals sanely with locks either way. Either they're too
lenient (not very often) or too strict, or they just don't talk well with
the other side. If you want to do locking over NFS, don't use lockf or
flock, use the link/stat lock method (see Mailman's LockFile module for a
somewhat expanded implementation of sane locking over NFS.)

On the plus side, there's a lot of work being done on NFSv4, which should
fix almost every design error made in NFSv2/3. Including the locking ;)

In any case, the problem on the SF Solaris box could be one of two things: a
hanging lock, in which case renaming/removing the testfile should fix it, or
a communication problem between the Solaris box and the NFS server. The
latter is pretty likely the case if the NFS server is Linux, which is pretty
likely with Sourceforge. You can doublecheck by using a testfile on another
filesystem, which isn't NFS-mounted (like /tmp.)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From gward at python.net  Sun Apr 15 18:24:29 2001
From: gward at python.net (Greg Ward)
Date: Sun, 15 Apr 2001 12:24:29 -0400
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <3AD7ED4D.58597DFD@darwin.in-berlin.de>; from gherman@darwin.in-berlin.de on Sat, Apr 14, 2001 at 08:25:17AM +0200
References: <3AD7ED4D.58597DFD@darwin.in-berlin.de>
Message-ID: <20010415122429.A539@gerg.ca>

On 14 April 2001, Dinu Gherman said:
> I'd like to support Peter's proposal for having *some* kind 
> of inverse mechanism to string formatting using '%'. Now, that
> doesn't mean anything, of course, but no matter what the syn-
> tax would look like: I'd prefer having that feature over not
> having it and I'll give an example below.

But we already have one: re.match (and friends).  Regexes are vastly
more powerful, predictable, reliable, and (to me at least)
comprehensible than scanf() format strings.  I've never understood how
scanf() works, and I don't see a great burning need to add scanf() to
Python.

Adding syntactic sugar for scanf() in the form of overloading "/" seems
like a *really* bad idea, too.  ("%" is a nice operator because printf()
format strings use "%" a lot, not because formatting a string has
anything remotely to do with modulo arithmetic.)  If scanf() really
needs to be in Python, write Modules/scanfmodule.c, build it by default,
and be done with it.  Or *maybe* make it a string method, if enough
people think it's useful.

        Greg
-- 
Greg Ward - just another Python hacker                  gward at python.net
http://starship.python.net/~gward/
When you make your mark in the world, watch out for guys with erasers.



From thomas at xs4all.net  Sun Apr 15 18:36:43 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 18:36:43 +0200
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104151647.LAA10237@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sun, Apr 15, 2001 at 11:47:32AM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com> <20010415173841.N2820@xs4all.nl> <200104151647.LAA10237@cj20424-a.reston1.va.home.com>
Message-ID: <20010415183642.Q2820@xs4all.nl>

On Sun, Apr 15, 2001 at 11:47:32AM -0500, Guido van Rossum wrote:
> > > Another consequence is that after "make clobber" you have to rerun the
> > > configure script (or say "make recheck").  This takes almost as long
> > > as the rest of the build...
> > 
> > So don't do that. Run 'config.status' instead: it'll recreate your config
> > files (Makefile.pre, config.h, Setup.config) from cached info. It won't
> > rebuild everything, but it rebuilds config.h, which is what 'make clobber'
> > removes that breaks building.

> Well, my issue is that before Neil "fixed" the Makefile, after a "make
> clobber" a "make" would do the job.  Now, there's a dependency on
> config.h but the Makefile doesn't know how to make that file.

I know, I was just pointing out you don't have to wait for 'configure' to do
its uncached magic, even if you lose config.h. Some projects do have a
dependency for 'config.h' that just calls config.status, by the way. (and if
config.status is missing, they just call configure or tell you to run
configure manually.)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at digicool.com  Sun Apr 15 19:45:08 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 12:45:08 -0500
Subject: [Python-Dev] test_fcntl on Solaris 8
In-Reply-To: Your message of "Sun, 15 Apr 2001 18:03:08 +0200."
             <20010415180307.P2820@xs4all.nl> 
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>  
            <20010415180307.P2820@xs4all.nl> 
Message-ID: <200104151745.MAA10389@cj20424-a.reston1.va.home.com>

> In any case, the problem on the SF Solaris box could be one of two things: a
> hanging lock, in which case renaming/removing the testfile should fix it, or
> a communication problem between the Solaris box and the NFS server. The
> latter is pretty likely the case if the NFS server is Linux, which is pretty
> likely with Sourceforge. You can doublecheck by using a testfile on another
> filesystem, which isn't NFS-mounted (like /tmp.)

Thanks.  This makes me feel much better.  The test runs fine with a
test file on /tmp.  Removing the test file doesn't help at all, so I'm
guessing that the communication with the lock server is broken.

I'll remove it from my list of showstopper issues.  This list now
has test_locale on Irix, and the issue with SSL and EGD.  My
prediction: the locale problem on Irix is a platform bug, and I'll
remove the EGD patch altogether from socketmodule.c.

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



From thomas at xs4all.net  Sun Apr 15 20:56:47 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 20:56:47 +0200
Subject: [Python-Dev] 2.1c1 on BSDI
Message-ID: <20010415205647.R2820@xs4all.nl>


For the record :) Python 2.1c1 performs as expected on BSDI 4.1 and 4.0.1.
That is, there are some crashes, but those were there in 2.0 and 1.5.2 as
well, for the most part, and are test-specific errors in general. We've been
using 2.1b2 (actually slightly newer) on development machines, where it is
used for various tools, and I haven't encountered many bugs yet.

BSDI 4.0.1 still needs to disable threads, but that's a platform bug, not a
Python one.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From tim.one at home.com  Sun Apr 15 21:11:30 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 15:11:30 -0400
Subject: [Python-Dev] Showstopper
Message-ID: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>

We've got a showstopper bug involving gc and dicts.  It's not brand new, but
was probably introduced when we fiddled PyDict_Next() to stop the dict
resizing problems plaguing Jeremy.

Cut to the chase:

1. dict_items() is called.  The dict has 22 of 32 slots filled.

2. PyList_New(22) creates the result list.

3. dict_items() loops through the dict looking for active entries.
   It does *not* use PyDict_Next, but a loop of the form

       	for (i = 0, j = 0; i < mp->ma_size; i++) {

4. When it finds an active entry, it calls PyTuple_New(2) to
   create the entry's (key, value) result tuple.

5. At the end, PyTuple_New() calls PyObject_GC_Init(), which
   calls _PyGC_Insert().

6. _PyGC_Insert() decides it's time for a collection.

7. The dict dict_items() is iterating over (remember step #1 <wink>?)
   is one of the objects gc traverses.  gc dict traversal *does* use
   PyDict_Next.

8. 22 of 32 slots filled is exactly at the dict resize point, so
   the PyDict_Next() invoked by gc traversal grows the dict.

9. So, back to step #1, dict_item()'s

           	for (i = 0, j = 0; i < mp->ma_size; i++) {

   loop now goes up to 64 instead of the original 32, and, because
   of the internal dict reshuffling, *can* (depending on the exact
   data content of the dict) see values again that it already
   saw before the dict got rearranged.

10. As a result, the later

			PyList_SetItem(v, j, item);

   inside the loop can eventually pass values for j too large for
   the list.

11. PyList_SetItem() sets a "list assignment index out of range"
    error string, but nobody pays ttention to that, and dict_items()
    proceeds to trigger the error multiple times.

12. The value returned by dict_items() is wrong, containing
    some duplicate (key, value) pairs, and missing others.

13. The eval loop goes around a few more times, until it finally
    hits a bytecode that notices the pending exception.  Then (I
    finally got lucky here!) IndexError finally pops up on a line
    where an IndexError doesn't make sense.

I have a test case that reliably triggers this bug, but was unable to whittle
it below 100+ Kb of code + data files.  So trust me about the details above
(they're clear enough!).




From mwh21 at cam.ac.uk  Sun Apr 15 22:03:10 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: Sun, 15 Apr 2001 21:03:10 +0100 (BST)
Subject: [Python-Dev] Showstopper
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>
Message-ID: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>

On Sun, 15 Apr 2001, Tim Peters wrote:

> We've got a showstopper bug involving gc and dicts.  It's not brand
> new, but was probably introduced when we fiddled PyDict_Next() to stop
> the dict resizing problems plaguing Jeremy.

Crap.

Two ideas suggest themselves: (1) don't have the resize check in
PyDict_Next (it could be in PyDict_SetItem instead, though the fact that
this is safe is delicate to say the least) (2) don't use PyDict_Next in
dict_traverse.

OTOH, the GC runs __del__ methods, right?  So what if a __del__ method
mutates the dictionary that .items() is being called on?  If allocating
memory can execute arbitrary Python code, I dread to think how many bugs
of this form are hiding in Python (actually it's only allocating
containers that's the worry, but still...).  On the third hand, I can't
trigger one deliberately, so maybe I'm talking nonsense.

To fix items/keys/values, you could build up the list of tuples first,
check you still have the right amount, then fill them in.

not-sure-this-is-helping-ly y'rs
M.




From nas at python.ca  Sun Apr 15 23:07:30 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sun, 15 Apr 2001 14:07:30 -0700
Subject: [Python-Dev] Showstopper
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>; from tim.one@home.com on Sun, Apr 15, 2001 at 03:11:30PM -0400
References: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>
Message-ID: <20010415140730.B21716@glacier.fnational.com>

Tim Peters wrote:
> I have a test case that reliably triggers this bug, but was unable to whittle
> it below 100+ Kb of code + data files.  So trust me about the details above
> (they're clear enough!).

The details are all to clear to me.  :-( Can you get me the test
case somehow?  I'm thinking about how to fix this right now but I
don't think its going to be easy.

  Neil



From tim.one at home.com  Sun Apr 15 23:17:23 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:17:23 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEHLJMAA.tim.one@home.com>

Guido & I talked out A Plan, and he's going to implement it while I take a
nap.  Outline:

1. It sucks that PyDict_Next() can resize a dict.  And while staring
   at all this in the debugger, it was plain appalling that the mere
   act of doing gc ran around turning empty dicts into non-empty
   ones because of it (not a bug, just irksome waste).

2. It sucks that PyDict_SetItem() can resize a dict even when
   the number of active slots doesn't change.

The plan for addressing those:

A. Rip out the PyDict_Next() resizing hack.

B. In PyDict_SetItem(), first look at the number of free slots,
   and resize the dict if it would be impossible to add a new
   active slot (I *suspect* this can be reduced to making a minimal
   dict when the incoming dict is empty).
   Remember the number of used slots.
   Do the insert.
   Look at the number of used slots now:  do "the usual" resize
   logic if and only the number of used slots changed across
   the insert call.

That much should suffice to stop Jeremy's old bugs, and the bug I bumped into
here.

It's not enough, though.  Allocating a tuple (or any other gc'ed type) can
still cause gc to run, then gc can delete __del__-free cycles, then deleting
those can cause objects with __del__ methods to become unreachable too, and
then any Python code whatsoever can run, incl. but not limited to code that
dicts, and also incl. allowing other threads to run.

So code inside dict methods can't assume much of anything across container
allocations, even after fixing all the bugs we've bumped into so far.  So at
least dict_items() and dict_popitem() remain unsafe after these changes,
although we don't have a concrete test case to prove that and it would be
mondo difficult to create one.  Nevertheless, Python users are effective
proof of the million monkeys hypothesis <wink>.  These remaining problems
require case-by-case analysis and rewriting.

could-be-the-biggest-one-line-fix-in-history-ly y'rs  - tim




From guido at digicool.com  Mon Apr 16 00:19:40 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 17:19:40 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 14:07:30 MST."
             <20010415140730.B21716@glacier.fnational.com> 
References: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>  
            <20010415140730.B21716@glacier.fnational.com> 
Message-ID: <200104152219.RAA11099@cj20424-a.reston1.va.home.com>

> Tim Peters wrote:
> > I have a test case that reliably triggers this bug, but was unable to whittle
> > it below 100+ Kb of code + data files.  So trust me about the details above
> > (they're clear enough!).
> 
> The details are all to clear to me.  :-( Can you get me the test
> case somehow?  I'm thinking about how to fix this right now but I
> don't think its going to be easy.

Don't worry, Tim & I have got it all worked out.  I'll explain later.

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



From tim.one at home.com  Sun Apr 15 23:17:30 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:17:30 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>

[Guido, see last point, about dict.keys()/.values()]

[Michael Hudson]
> Crap.

An accurate summary <wink>.

> Two ideas suggest themselves: (1) don't have the resize check in
> PyDict_Next (it could be in PyDict_SetItem instead, though the fact
> that this is safe is delicate to say the least) (2) don't use
> PyDict_Next in dict_traverse.

See preceding crossed-in-the-mail msg.

> OTOH, the GC runs __del__ methods, right?  So what if a __del__ method
> mutates the dictionary that .items() is being called on?  If
> allocating memory can execute arbitrary Python code,

Right.

> I dread to think how many bugs of this form are hiding in Python
> (actually it's only allocating containers that's the worry, but
> still...).

I did too at first, but it appears to be tractable:  allocating containers
"in the middle" of something else is actually rare.  OTOH, listobject.c
eventually grew a faux "immutable list type", after an endless sequence of
hacks failed to stop all cases in which list.sort() could be tricked into
blowing up by writing devious comparison functions that mutated the list in
"just the right way" during the sort.  Today you get an exception if you try
to mutate a list while it's being sorted, and that worked great (I confess
I'm much fonder of it than Guido is, though).

I think we can stop disasters in the dict code, but also expect "odd
behavior" will be possible; e.g., that dict.items() may return a list with
duplicate keys if code is insane enough to mutate the dict during a __del__
method (or in another thread:  once we execute __del__, we're executing
Python code, and the eval loop will let other threads in).

> On the third hand, I can't trigger one deliberately, so maybe
> I'm talking nonsense.

I expect these are very difficult to trigger.

> To fix items/keys/values, you could build up the list of tuples first,
> check you still have the right amount, then fill them in.

Yes, that's one of the things Guido intends to do, although we only talked
about dict_items().  keys() and values() don't allocate any tuples.  They do
allocate a result list at the start, but-- sigh! --you're right that
mp->ma_used may change "during" the initial

    v = PyList_New(mp->ma_used);

> not-sure-this-is-helping-ly y'rs

it-was-depressing-so-it-must-be-helpful<wink>-ly y'rs  - tim




From nas at python.ca  Sun Apr 15 23:20:23 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sun, 15 Apr 2001 14:20:23 -0700
Subject: [Python-Dev] Showstopper
In-Reply-To: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>; from mwh21@cam.ac.uk on Sun, Apr 15, 2001 at 09:03:10PM +0100
References: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com> <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>
Message-ID: <20010415142023.C21716@glacier.fnational.com>

Michael Hudson wrote:
> Two ideas suggest themselves: (1) don't have the resize check
> in PyDict_Next (it could be in PyDict_SetItem instead, though
> the fact that this is safe is delicate to say the least) (2)
> don't use PyDict_Next in dict_traverse.

There is a collector lock in gcmodule.  We could expose methods
for locking and unlocking it.  I'm not sure if that's the right
solution though.

> OTOH, the GC runs __del__ methods, right?

Yes.

> If allocating memory can execute arbitrary Python code, I dread
> to think how many bugs of this form are hiding in Python

I think this is the crux of the problem.  There is probably more
code that does not expect that to happen.  We can fix this
problem without too much trouble but how many more hard to find
ones will be left?  Am I being paranoid?

  Neil



From nas at python.ca  Sun Apr 15 23:30:59 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sun, 15 Apr 2001 14:30:59 -0700
Subject: [Python-Dev] Showstopper
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>; from tim.one@home.com on Sun, Apr 15, 2001 at 05:17:30PM -0400
References: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain> <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>
Message-ID: <20010415143059.D21716@glacier.fnational.com>

Tim Peters wrote:
> allocating containers "in the middle" of something else is
> actually rare.

It looks like you and Guido are working on a solution to avoid
doing this.  Wouldn't it be better to change the GC so that it
was okay to do that?  Specifically, I'm thinking of making
collection only happen between opcodes.  Perhaps that is too
large of a change to make before the release.

  Neil



From guido at digicool.com  Mon Apr 16 00:40:13 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 17:40:13 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 14:30:59 MST."
             <20010415143059.D21716@glacier.fnational.com> 
References: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain> <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>  
            <20010415143059.D21716@glacier.fnational.com> 
Message-ID: <200104152240.RAA11336@cj20424-a.reston1.va.home.com>

> Tim Peters wrote:
> > allocating containers "in the middle" of something else is
> > actually rare.
> 
> It looks like you and Guido are working on a solution to avoid
> doing this.  Wouldn't it be better to change the GC so that it
> was okay to do that?  Specifically, I'm thinking of making
> collection only happen between opcodes.  Perhaps that is too
> large of a change to make before the release.
> 
>   Neil

Yes, I'd rather not touch the GC code this late in the game if we can
avoid it.

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



From tim.one at home.com  Sun Apr 15 23:44:42 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:44:42 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <20010415142023.C21716@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEHOJMAA.tim.one@home.com>

[Neil Schemenauer]
> ...
> Am I being paranoid?

Yes, but paranoia is the right attitude to have here -- embrace your
paranoia, and celebrate the Holy Adrenalin <wink>.




From tim.one at home.com  Sun Apr 15 23:44:52 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:44:52 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <20010415143059.D21716@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEHOJMAA.tim.one@home.com>

[Tim]
> allocating containers "in the middle" of something else is
> actually rare.

[Neil Schemenauer]
> It looks like you and Guido are working on a solution to avoid
> doing this.  Wouldn't it be better to change the GC so that it
> was okay to do that?  Specifically, I'm thinking of making
> collection only happen between opcodes.  Perhaps that is too
> large of a change to make before the release.

Changing PyDict_Next() and PyDict_SetItem() to avoid gratuitous reshuffling
is a worthy goal regardless (merely traversing a dict simply "should not"
resize it, and has caused problems independent of gc), so I'm solidly +1 on
those.

Loops using PyDict_Next() to mutate values of existing keys can also cause
__del__ methods to execute (because of decref'ing the old values), so there
are non-gc vulnerabilities there too we haven't really addressed -- and then
even switching to "between opcodes" gc wouldn't stop the problems unique to
gc (since __del__ methods go back to the eval loop).

But "between opcodes" sounds like a promising idea to me to short-circuit the
mass of other potential problems that can't be triggered by just decref'ing
things.  Where's the PEP <wink>?




From guido at digicool.com  Mon Apr 16 00:51:07 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 17:51:07 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 17:44:52 -0400."
             <LNBBLJKPBEHFEDALKOLCGEHOJMAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCGEHOJMAA.tim.one@home.com> 
Message-ID: <200104152251.RAA11485@cj20424-a.reston1.va.home.com>

> Loops using PyDict_Next() to mutate values of existing keys can also
> cause __del__ methods to execute (because of decref'ing the old
> values), so there are non-gc vulnerabilities there too we haven't
> really addressed -- and then even switching to "between opcodes" gc
> wouldn't stop the problems unique to gc (since __del__ methods go
> back to the eval loop).

And it's not just __del__.  Lookup operations can invoke arbitrary
Python code for the key comparison, which could mutate the dict (or
let another thread run that mutates the dict).

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



From guido at digicool.com  Mon Apr 16 01:19:55 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 18:19:55 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 17:17:30 -0400."
             <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com> 
Message-ID: <200104152319.SAA11860@cj20424-a.reston1.va.home.com>

I've checked in what I think is a complete fix, but I wouldn't mind
some extra eyes -- I'm in a bit of a rush to head out for dinner now.

But Tim, please take a nap first! :-)

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



From guido at digicool.com  Mon Apr 16 01:25:16 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 18:25:16 -0500
Subject: [Python-Dev] 2nd release candidate?
Message-ID: <200104152325.SAA11875@cj20424-a.reston1.va.home.com>

I'd like to issue a 2nd release candidate late tonight, and then
change *nothing* between 2.1c2 and the final release Tuesday.

The only thing I still need to change before making the 2nd release
candidate is to rip out Moshe's EGD patch for the socket module, which
has too many problems IMO.

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



From tim.one at home.com  Mon Apr 16 01:05:25 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 19:05:25 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <200104152319.SAA11860@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEIBJMAA.tim.one@home.com>

[Guido]
> I've checked in what I think is a complete fix, but I wouldn't mind
> some extra eyes -- I'm in a bit of a rush to head out for dinner now.
>
> But Tim, please take a nap first! :-)

Heh.  I'm working on it.

Initial bleary-eyeballing turned up one vulnerability remaining, in
dict_popitem():   allocating the result tuple *could* conceivably empty the
dict, in which case the search loop will never terminate.  So I'd move the
"empty?" test after the allocation, like so (untested!):

	/* Allocate the result tuple first.  Believe it or not,
	 * this allocation could trigger a garbage collection which
	 * could resize the dict, which would invalidate the pointer
	 * (ep) into the dict calculated below, or clear the dict.
	 * So we have to do this first.
	 */
	res = PyTuple_New(2);
	if (res == NULL)
		return NULL;
	if (mp->ma_used == 0) {
		PyErr_SetString(PyExc_KeyError,
				"popitem(): dictionary is empty");
		Py_DECREF(res);
		return NULL;
	}

In practice (well, mine), .popitem() is never called on an empty dict, so I
don't at all mind allocating a tuple just to throw it away immediately if the
dict is empty.

zzzzzzzzzzzzzingly y'rs  - tim


PS:  Another release candidate is a prudent idea.  I'll be up again in 1.5
hours.




From guido at digicool.com  Mon Apr 16 03:11:05 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 20:11:05 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 19:05:25 -0400."
             <LNBBLJKPBEHFEDALKOLCOEIBJMAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCOEIBJMAA.tim.one@home.com> 
Message-ID: <200104160111.UAA12240@cj20424-a.reston1.va.home.com>

> 	/* Allocate the result tuple first.  Believe it or not,
> 	 * this allocation could trigger a garbage collection which
> 	 * could resize the dict, which would invalidate the pointer
> 	 * (ep) into the dict calculated below, or clear the dict.
> 	 * So we have to do this first.
> 	 */
> 	res = PyTuple_New(2);
> 	if (res == NULL)
> 		return NULL;
> 	if (mp->ma_used == 0) {
> 		PyErr_SetString(PyExc_KeyError,
> 				"popitem(): dictionary is empty");
> 		Py_DECREF(res);
> 		return NULL;
> 	}

Good catch -- checked in now!

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



From guido at digicool.com  Mon Apr 16 03:36:26 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 20:36:26 -0500
Subject: [Python-Dev] NO MORE CHECKINS PLEASE
Message-ID: <200104160136.UAA12834@cj20424-a.reston1.va.home.com>

I'm building another release candidate.  Release later tonight.

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



From jafo at tummy.com  Mon Apr 16 02:41:21 2001
From: jafo at tummy.com (Sean Reifschneider)
Date: Sun, 15 Apr 2001 18:41:21 -0600
Subject: [Python-Dev] 2.1c1 RPMs (was: Re: ANNOUNCE: A Python 2.1 release candidate!)
In-Reply-To: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Apr 13, 2001 at 05:18:40PM -0500
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>
Message-ID: <20010415184121.A15535@tummy.com>

On Fri, Apr 13, 2001 at 05:18:40PM -0500, Guido van Rossum wrote:
>Python 2.1 is almost ready.  We've built a release candidate -- a
>version that should become the final version, barring any last-minute

I've built a set of RPMs against 2.1c1, they're available at the same
bat-place:

   ftp://ftp.tummy.com/pub/tummy/RPMS/SRPMS/python2-2.1c1-1tummy.src.rpm

and binaries for RedHat/KRUD 7.0 under:

   ftp://ftp.tummy.com/pub/tummy/RPMS/binaries-KRUD-7.0-i386

   python2-2.1c1-1tummy.i386.rpm
   python2-devel-2.1c1-1tummy.i386.rpm
   python2-tkinter-2.1c1-1tummy.i386.rpm

Enjoy,
Sean
-- 
 Program *INTO* a language, not *IN* it.
                 -- David Gries
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python



From guido at python.org  Mon Apr 16 05:44:59 2001
From: guido at python.org (Guido van Rossum)
Date: Sun, 15 Apr 2001 22:44:59 -0500
Subject: [Python-Dev] ANNOUNCE: A *second* Python 2.1 release candidate!
Message-ID: <200104160344.WAA18937@cj20424-a.reston1.va.home.com>

We found and fixed a rare but serious bug in the dictionary code, and
fixed enough small nits to warrant a second release candidate for
Python 2.1 -- the final release is still planned for Tuesday, April
17.

Please download the release candidate and try it on your favorite
platform.  For more info:

    http://www.python.org/2.1/

Enjoy!

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



From m.favas at per.dem.csiro.au  Mon Apr 16 05:02:51 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Mon, 16 Apr 2001 11:02:51 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>  
	            <3AD9339F.44C7FC05@per.dem.csiro.au> <200104151348.IAA09108@cj20424-a.reston1.va.home.com>
Message-ID: <3ADA60DB.25854811@per.dem.csiro.au>

Yes, the SGI appears not to return a grouping ([3, 0] is expected) for
the en_US locale (the rest of it looks OK).

However, there is still a bug in Lib/locale.py - the code currently
tries to allow for the possibility that an empty grouping may be
returned from localeconv() (and there must be some locales where this is
correct):

def _group(s):
    conv=localeconv()
    grouping=conv['grouping']
    if not grouping:return s

The code calling _group() assumes that the object returned will always
be a tuple, and hence the above will cause a traceback when localeconv()
returns an empty grouping. The correct code should be:

def _group(s):
    conv=localeconv()
    grouping=conv['grouping']
    if not grouping:return (s, 0)

test_locale will still fail on the SGI, but now because of a bug in the
platform implementation of the en_US locale, rather than a bug in the
Python locale.py code. It's better than a traceback.

BTW, mail to Martin doesn't seem to be getting through.

Guido van Rossum wrote:
> 
> > localeconv()['grouping'] is "[]" at this point...
> 
> It is looking like either the _locale.c module is not working right or
> the platform's implementation of the en_US locals is broken.  I'm
> afraid that only you will be able to make the determination. :-(
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From neal at metaslash.com  Mon Apr 16 16:42:24 2001
From: neal at metaslash.com (Neal Norwitz)
Date: Mon, 16 Apr 2001 10:42:24 -0400
Subject: [Python-Dev] Python 2.1 RC1 - PyCheckered Tools
Message-ID: <3ADB04D0.87576CE4@metaslash.com>

Here's the problems I found with PyChecker (http://pychecker.sourceforge.net)
against the Python 2.1 RC1 Tools.

Is there any reason that bgen source is Tools/bgen/bgen?

Neal
--

bgen/bgenOutput.py:87 No global (Error) found
bgen/bgenType.py:30 Invalid arguments to (getargsArgs), got 0, expected 1
bgen/bgenType.py:79 Invalid arguments to (mkvalueArgs), got 0, expected 1
bgen/scantools.py:402 No attribute (comment1) found
bgen/scantools.py:403 No attribute (comment1) found
bgen/scantools.py:404 No attribute (comment2) found
bgen/scantools.py:405 No attribute (comment2) found
bgen/scantools.py:406 No attribute (sym) found
bgen/scantools.py:409 No attribute (head) found
bgen/scantools.py:417 No attribute (sym) found
bgen/scantools.py:426 No attribute (tail) found
bgen/scantools.py:428 No attribute (comment1) found
bgen/scantools.py:429 No attribute (comment1) found
bgen/scantools.py:430 No attribute (comment2) found
bgen/scantools.py:431 No attribute (comment2) found
bgen/scantools.py:436 No attribute (whole) found
bgen/scantools.py:439 No attribute (whole) found
bgen/scantools.py:475 No attribute (asplit) found
bgen/scantools.py:478 No attribute (asplit) found
	(seems most names are xxx_pat, not xxx)

idle/BrowserControl.py:103 No global (_os) found
	(should be os)
idle/BrowserControl.py:149 No global (traceback) found
	(need to import)
idle/SearchDialogBase.py:34 No attribute (default_command) found
idle/SearchDialogBase.py:127 Local variable (f) not used
idle/UndoDelegator.py:29 No method (unbind) found
	(also at lines, 30, 31)
idle/UndoDelegator.py:34 No method (bind) found
	(also at lines, 35, 36)
idle/UndoDelegator.py:139 No method (bell) found
	(also at line 150)
idle/WidgetRedirector.py:33 No global (dict) found
	(should be self.dict)
idle/eventparse.py:1 Imported module (getopt) not used in any function

freeze/checkextensions_win32.py:62 No global (mapFileName) found
	(should be defaultMapName)
freeze/checkextensions_win32.py:121 No global (modules) found
	(should be module)
freeze/makeconfig.py:33 No global (sys) found
freeze/modulefinder.py:67 Local variable (i) not used
	(can do print "  " * self.indent, just a warning)

faqwiz/faqwiz.py:245 No attribute (last_changed_date) found
faqwiz/faqwiz.py:306 No attribute (last_changed_date) found
faqwiz/faqwiz.py:324 Local variable (okprog) not used
faqwiz/faqwiz.py:455 No global (constants) found

pynche/ListViewer.py:165 Local variable (height) not used
pynche/StripViewer.py:294 Local variable (tclcmd) not used
pynche/StripViewer.py:405 No attribute (_StripViewer__gentypevar) found
	(member commented out)
pynche/TextViewer.py:104 Local variable (val) not used

webchecker/webchecker.py:192 Function (load_pickle) uses named arguments



From fdrake at acm.org  Mon Apr 16 17:05:58 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 16 Apr 2001 11:05:58 -0400 (EDT)
Subject: [Python-Dev] Python 2.1 RC1 - PyCheckered Tools
In-Reply-To: <3ADB04D0.87576CE4@metaslash.com>
References: <3ADB04D0.87576CE4@metaslash.com>
Message-ID: <15067.2646.801856.69602@cj42289-a.reston1.va.home.com>

Neal Norwitz writes:
 > idle/BrowserControl.py:103 No global (_os) found
 > 	(should be os)
 > idle/BrowserControl.py:149 No global (traceback) found
 > 	(need to import)

  The BrowserControl module will be removed for the next release,
since IDLE prefers the webbrowser module, which was added to the
standard library as of Python 2.0.


  -Fred

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




From guido at digicool.com  Mon Apr 16 19:07:36 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 16 Apr 2001 12:07:36 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Mon, 16 Apr 2001 11:02:51 +0800."
             <3ADA60DB.25854811@per.dem.csiro.au> 
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com> <3AD9339F.44C7FC05@per.dem.csiro.au> <200104151348.IAA09108@cj20424-a.reston1.va.home.com>  
            <3ADA60DB.25854811@per.dem.csiro.au> 
Message-ID: <200104161707.MAA21086@cj20424-a.reston1.va.home.com>

> Yes, the SGI appears not to return a grouping ([3, 0] is expected) for
> the en_US locale (the rest of it looks OK).
> 
> However, there is still a bug in Lib/locale.py - the code currently
> tries to allow for the possibility that an empty grouping may be
> returned from localeconv() (and there must be some locales where this is
> correct):
> 
> def _group(s):
>     conv=localeconv()
>     grouping=conv['grouping']
>     if not grouping:return s
> 
> The code calling _group() assumes that the object returned will always
> be a tuple, and hence the above will cause a traceback when localeconv()
> returns an empty grouping. The correct code should be:
> 
> def _group(s):
>     conv=localeconv()
>     grouping=conv['grouping']
>     if not grouping:return (s, 0)
> 
> test_locale will still fail on the SGI, but now because of a bug in the
> platform implementation of the en_US locale, rather than a bug in the
> Python locale.py code. It's better than a traceback.

Thanks.  I've checked this in now.

> BTW, mail to Martin doesn't seem to be getting through.

I think it's his home machine, and I suspect he's taken a long weekend
off (Monday after Easter is a holiday in most European countries).

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



From neal at metaslash.com  Mon Apr 16 19:52:25 2001
From: neal at metaslash.com (Neal Norwitz)
Date: Mon, 16 Apr 2001 13:52:25 -0400
Subject: [Python-Dev] Python 2.1 RC1 - symtable.py problems
Message-ID: <3ADB3159.476A73CD@metaslash.com>

Sorry, I didn't get this in the first batch.  PyChecker crashed on symtable.py and I didn't fix it until now.

/home/neal/local/lib/python2.1/symtable.py:100 Invalid arguments to (bool), got 0, expected 1
/home/neal/local/lib/python2.1/symtable.py:193 No attribute (flag) found
	(should be __flags?)
/home/neal/local/lib/python2.1/symtable.py:196 No global (DEF_STARSTAR) found
	(should be DEF_DOUBLESTAR?)

Neal



From barry at digicool.com  Mon Apr 16 19:56:06 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Mon, 16 Apr 2001 13:56:06 -0400
Subject: [Python-Dev] Python 2.1 RC1 - PyCheckered Tools
References: <3ADB04D0.87576CE4@metaslash.com>
Message-ID: <15067.12854.219081.458580@anthem.wooz.org>

>>>>> "NN" == Neal Norwitz <neal at metaslash.com> writes:

    | pynche/ListViewer.py:165 Local variable (height) not used
    | pynche/StripViewer.py:294 Local variable (tclcmd) not used
    | pynche/StripViewer.py:405 No attribute (_StripViewer__gentypevar) found
    | 	(member commented out)
    | pynche/TextViewer.py:104 Local variable (val) not used

Thanks.  I've fixed these in my working copy but won't check them in
until Python 2.1 final is out the door.

-Barry



From loewis at informatik.hu-berlin.de  Tue Apr 17 10:34:34 2001
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Tue, 17 Apr 2001 10:34:34 +0200 (MEST)
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
Message-ID: <200104170834.KAA29092@pandora.informatik.hu-berlin.de>

> def _group(s):
>     conv=localeconv()
>     grouping=conv['grouping']
>     if not grouping:return (s, 0)

Yes, that change is right.

> BTW, mail to Martin doesn't seem to be getting through.

Unfortunately, cs.tu-berlin.de seems to have router problems :-(

Regards,
Martin



From guido at digicool.com  Tue Apr 17 16:29:44 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 09:29:44 -0500
Subject: [Python-Dev] ANNOUNCE: Python 2.1 final release
Message-ID: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>

Yes, the *final* release of Python 2.1 is now available.  Thanks again
for all who helped!  Go here for downloads and information:

    http://www.python.org/2.1/

As a reminder, here's a list of some of the big new features in 2.1
(news since 2.0 was released in October 2000):

- nested scopes and __future__ directives
- rich comparisons and new coercion model
- warnings framework
- new build process (Unix)
- weak references
- function attributes
- unittest and doctest modules for automated testing
- ports to several new platforms, including Cygwin and RISCOS

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



From guido at digicool.com  Tue Apr 17 17:51:16 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 10:51:16 -0500
Subject: [Python-Dev] Python 2.1.1 and 2.2 release planning
Message-ID: <200104171551.KAA28713@cj20424-a.reston1.va.home.com>

Now that 2.1 is out, I've created a CVS branch for the Python 2.1.1
bugfix release.  Its name is "release21-maint" (I had no choice in the
name, I'm mimicking the name that Moshe chose for the 2.0.1 branch).

Anything that should go into 2.1.1 ought to be checked into this
branch as well as into the trunk.  Let's tentatively shoot for a 2.1.1
release about a month for now.  This ought to be a very conservative
bugfix release; the key goal is stability of the 2.1 platform, not
releasing features that missed the 2.1 deadline.

Anything that smells of a feature or a new API (even if it is
introduced to fix a design bug!) ought to go into the trunk, where it
will be released as part of 2.2.  I am aiming for a 2.2 release in
October 2001.

In the future, I'd like to create a branch for each release (alpha,
beta or candidate).  These branches will branch of the trunk just
before the release is planned.  That way, instead of declaring a
checkin moratorium on the trunk, I can create a branch, and checkins
on the trunk won't bother me (or whoever is the release manager).

Thanks to all the last-minute bug reporters and fixers!

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



From neal at metaslash.com  Tue Apr 17 18:11:02 2001
From: neal at metaslash.com (Neal Norwitz)
Date: Tue, 17 Apr 2001 12:11:02 -0400
Subject: [Python-Dev] PyChecker 0.3 release
Message-ID: <3ADC6B16.8F90B777@metaslash.com>

I have released PyChecker 0.3 to SourceForge.
	Web Page:     http://pychecker.sourceforge.net/
	Project Page: http://sourceforge.net/projects/pychecker/

I'd like to thank everyone for all the feedback so far, it's been great!
In particular, Barry Scott has been very helpful.

The CHANGELOG and current command line options are included below.
The TODO list has gotten longer (see the web page or download).

As always, feedback, suggestions, complaints, etc are encouraged.

Neal
--

Here's the CHANGELOG:

Version 0.3     - 17 April 2001
  * Fix some checker crashes (oops)
  * Add warnings for code complexity (lines/branches/returns per func)
  * Add more configuration options
  * Don't produce spurious warning for:  x(y, { 'a': 'b' })
  * Fix warnings that indicate they are from a base class file,
    rather than real file
  * Fix warnings for **kwArgs not allowed, but using named args
  * Add config option for warning when using attribute as a function
        (off by default, old behaviour was on)

Version 0.2.5   - 12 April 2001
  * Add back support for Python 1.5.2 (again)
        (I sure like 2.0 more with the [ for ] and string methods.)
  * Add new warning for unused local variables
  * Add command line switches


Here's the current list of command line options:

Options:           Change warning for ... [default value]
  -s, --doc          turn off all warnings for no doc strings
  -m, --moduledoc    no module doc strings [on]
  -c, --classdoc     no class doc strings [on]
  -f, --funcdoc      no function/method doc strings [off]

  -i, --import       unused imports [on]
  -l, --local        unused local variables, except tuples [on]
  -t, --tuple        all unused local variables, including tuples [off]
  -v, --var          all unused module variables [off]
  -p, --privatevar   unused private module variables [on]
  -n, --namedargs    functions called with named arguments (like keywords) [on]
  -a, --initattr     Attributes (members) must be defined in __init__() [off]
  -I, --initsubclass Subclass.__init__() not defined [off]
  -A, --callattr     Calling data members as functions [off]

  -b, --blacklist    ignore warnings from the list of modules [['Tkinter']]
  -L, --maxlines     maximum lines in a function [200]
  -B, --maxbranches  maximum branches in a function [50]
  -R, --maxreturns   maximum returns in a function [10]

  -P, --printparse   print internal checker parse structures [off]
  -d, --debug        turn on debugging for checker [off]



From barry at digicool.com  Tue Apr 17 18:23:26 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 12:23:26 -0400
Subject: [Python-Dev] Python 2.1 PEPs
Message-ID: <15068.28158.342537.431634@anthem.wooz.org>

Now that Python 2.1 is officially out the door, it's time to do some
spring cleaning on the PEPs.  I'm currently processing the latest
batch of PEP requests, and I'm going to create a Python 2.2 release
schedule PEP.  It's time to make an update pass through PEP 0 too.

Here are the following PEPs that are marked as "Active for Python
2.1", along with a small commentary about changing their status.  PEP
authors, please take a close look at your Python 2.1 PEPs and make any
final revisions that are necessary.  Let me know if you disagree with
my proposed disposition of the PEP.  Note: individual PEP owners
should update their own PEPs; I will take care of noodging you and
updating PEP 0.  If you are unable to make commits to the PEPs, send
the updated text to me and I'll commit them.

 I    42  pep-0042.txt  Small Feature Requests                 Hylton

The perennial PEP, this will be moved to the "Python 2.2 Current"
category.  It should be updated if necessary.

 S   205  pep-0205.txt  Weak References                        Drake

Fred should do an update pass to reflect Python 2.1 Reality
(e.g. weakref.mapping()).  This PEP should then be marked as Final and
moved to the Finished PEPs category.

  I   226  pep-0226.txt  Python 2.1 Release Schedule            Hylton

This PEP should get a final pass (no need for "tentative"s any more!),
marked as Final and moved to the Finished category.

  S   227  pep-0227.txt  Statically Nested Scopes               Hylton

Jeremy, please make sure this is up-to-date w.r.t. Python 2.1 Reality,
then mark it as Final and I'll move it to the Finished category.

  S   229  pep-0229.txt  Using Distutils to Build Python        Kuchling

Andrew, same deal with this PEP...

  S   233  pep-0233.txt  Python Online Help                     Prescod

What is up with this PEP?  Progress on this seems to have stalled, so
I propose marking it "Deferred" and moving it out of the active PEP
category (to where, I'm not yet sure).

  S   235  pep-0235.txt  Import on Case-Insensitive Platforms   Peters

I think this one's done, so it should be marked as Final and moved to
the Finished PEPs category.  Tim should make any final edits
necessary.

  S   236  pep-0236.txt  Back to the __future__                 Peters

Same for this one, Tim...

  S   243  pep-0243.txt  Module Repository Upload Mechanism     Reifschneider

This isn't strictly tied to the Python 2.1 release, so I propose to
simply shuffle it over to the "Active for Python 2.2" category.

Cheers,
-Barry



From guido at digicool.com  Tue Apr 17 18:37:25 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 12:37:25 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 12:23:26 EDT."
             <15068.28158.342537.431634@anthem.wooz.org> 
References: <15068.28158.342537.431634@anthem.wooz.org> 
Message-ID: <200104171637.f3HGbPg32707@odiug.digicool.com>

>   I   226  pep-0226.txt  Python 2.1 Release Schedule            Hylton
> 
> This PEP should get a final pass (no need for "tentative"s any more!),
> marked as Final and moved to the Finished category.

Could we recycle this PEP number for the 2.1.1 release schedule (see
my previous post here)?  That seems easier than having a new PEP for
each micro-release.

>   S   227  pep-0227.txt  Statically Nested Scopes               Hylton
> 
> Jeremy, please make sure this is up-to-date w.r.t. Python 2.1 Reality,
> then mark it as Final and I'll move it to the Finished category.

I have promised Jeremy a bunch of updates to this.  I'll get on it.

>   S   229  pep-0229.txt  Using Distutils to Build Python        Kuchling
> 
> Andrew, same deal with this PEP...
> 
>   S   233  pep-0233.txt  Python Online Help                     Prescod
> 
> What is up with this PEP?  Progress on this seems to have stalled, so
> I propose marking it "Deferred" and moving it out of the active PEP
> category (to where, I'm not yet sure).

Superseded by pydoc, I imagine.  Working code beats ambitious plans
every time :-)

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



From paulp at ActiveState.com  Tue Apr 17 18:58:43 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 09:58:43 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
Message-ID: <3ADC7643.9AF12AB3@ActiveState.com>

"Barry A. Warsaw" wrote:
> 
>...
> 
>   S   233  pep-0233.txt  Python Online Help                     Prescod
> 
> What is up with this PEP?  Progress on this seems to have stalled, so
> I propose marking it "Deferred" and moving it out of the active PEP
> category (to where, I'm not yet sure).

Ping asked to take over the code because he wanted to do it with Pydoc.
He didn't do the online help part. I'm not sure if he thought I was
going to do that part or if he just didn't get to it. Either way, it is
less than a weekend's work to add pydoc to the interactive shell (and
thus make it "online help") so I can do it in the next few weeks.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From guido at digicool.com  Tue Apr 17 18:59:29 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 12:59:29 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 09:58:43 PDT."
             <3ADC7643.9AF12AB3@ActiveState.com> 
References: <15068.28158.342537.431634@anthem.wooz.org>  
            <3ADC7643.9AF12AB3@ActiveState.com> 
Message-ID: <200104171659.f3HGxTa00465@odiug.digicool.com>

> Ping asked to take over the code because he wanted to do it with Pydoc.
> He didn't do the online help part. I'm not sure if he thought I was
> going to do that part or if he just didn't get to it. Either way, it is
> less than a weekend's work to add pydoc to the interactive shell (and
> thus make it "online help") so I can do it in the next few weeks.

Actually, "from pydoc import help" already works; after that you can
type "help" or "help(module)" etc.  Or is "online help" more than
that?

Ping pointed out (in private email) that adding pydoc.help to
__builtin__ in site.py is the wrong thing to do because pydoc is large
and it would slow down startup too much.  He recommended to add a
small bootstrap function instead that imports and invokes pydoc.help
instead.

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



From barry at digicool.com  Tue Apr 17 19:06:18 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 13:06:18 -0400
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
	<200104171637.f3HGbPg32707@odiug.digicool.com>
Message-ID: <15068.30730.709186.27733@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

    GvR> Could we recycle this PEP number for the 2.1.1 release
    GvR> schedule (see my previous post here)?  That seems easier than
    GvR> having a new PEP for each micro-release.

PEP numbers are a plentiful resource!  I'd prefer to give it a new PEP
number.

    >> S 227 pep-0227.txt Statically Nested Scopes Hylton

    GvR> I have promised Jeremy a bunch of updates to this.  I'll get
    GvR> on it.

Excellent, thanks.

    GvR> Superseded by pydoc, I imagine.  Working code beats ambitious
    GvR> plans every time :-)

>>>>> "PP" == Paul Prescod <paulp at ActiveState.com> writes:

    PP> Ping asked to take over the code because he wanted to do it
    PP> with Pydoc.  He didn't do the online help part. I'm not sure
    PP> if he thought I was going to do that part or if he just didn't
    PP> get to it. Either way, it is less than a weekend's work to add
    PP> pydoc to the interactive shell (and thus make it "online
    PP> help") so I can do it in the next few weeks.

    GvR> Actually, "from pydoc import help" already works; after that
    GvR> you can type "help" or "help(module)" etc.  Or is "online
    GvR> help" more than that?

So Paul, what should be done about PEP 233?  Move it to "active for
Python 2.2"?

-Barry



From paulp at ActiveState.com  Tue Apr 17 19:28:15 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 10:28:15 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>  
	            <3ADC7643.9AF12AB3@ActiveState.com> <200104171659.f3HGxTa00465@odiug.digicool.com>
Message-ID: <3ADC7D2F.F0096D9F@ActiveState.com>

Guido van Rossum wrote:
> 
>...
> 
> Actually, "from pydoc import help" already works; after that you can
> type "help" or "help(module)" etc.  Or is "online help" more than
> that?

No, that looks like it is basically what you want. I didn't envision
help as a totally separate "mode" but I'm not picky.

> Ping pointed out (in private email) that adding pydoc.help to
> __builtin__ in site.py is the wrong thing to do because pydoc is large
> and it would slow down startup too much.  He recommended to add a
> small bootstrap function instead that imports and invokes pydoc.help
> instead.

Right, but the bootstrap was always part of the proposal! Now that
you've pointed out the impressive online help facility in pydoc it seems
that the only thing we need to make it exactly what I envisioned is a
few lines of code. I'm sorry I didn't figure that out last week!

All it would take now is

class help:
   def __repr__(self):
      import pydoc
      __builtins__.help = pydoc.help
      repr(__builtins__.help)

But hindsight is 20/20.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From thomas at xs4all.net  Tue Apr 17 19:50:41 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Tue, 17 Apr 2001 19:50:41 +0200
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <3ADC7D2F.F0096D9F@ActiveState.com>; from paulp@ActiveState.com on Tue, Apr 17, 2001 at 10:28:15AM -0700
References: <15068.28158.342537.431634@anthem.wooz.org> <3ADC7643.9AF12AB3@ActiveState.com> <200104171659.f3HGxTa00465@odiug.digicool.com> <3ADC7D2F.F0096D9F@ActiveState.com>
Message-ID: <20010417195041.T2820@xs4all.nl>

On Tue, Apr 17, 2001 at 10:28:15AM -0700, Paul Prescod wrote:

> All it would take now is
> 
> class help:
>    def __repr__(self):
>       import pydoc
>       __builtins__.help = pydoc.help
>       repr(__builtins__.help)

> But hindsight is 20/20.

You realize this isn't going to work, right ? The 'help' class will shadow
the 'help' builtin.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From paulp at ActiveState.com  Tue Apr 17 20:33:56 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 11:33:56 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
		<200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org>
Message-ID: <3ADC8C94.548514E3@ActiveState.com>

"Barry A. Warsaw" wrote:
> 
> 
> So Paul, what should be done about PEP 233?  Move it to "active for
> Python 2.2"?

Move it to "implemented." We can haggle about details but most of the
features I'd hoped for are implemented thanks to Ping!

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From ping at lfw.org  Tue Apr 17 21:13:36 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 17 Apr 2001 12:13:36 -0700 (PDT)
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <3ADC7D2F.F0096D9F@ActiveState.com>
Message-ID: <Pine.LNX.4.10.10104171207230.454-100000@skuld.kingmanhall.org>

On Tue, 17 Apr 2001, Paul Prescod wrote:
> Right, but the bootstrap was always part of the proposal!

Right.

> All it would take now is
> 
> class help:
>    def __repr__(self):
>       import pydoc
>       __builtins__.help = pydoc.help
>       repr(__builtins__.help)

Yes, pretty much.  I suggested something to that effect on Friday
night.  (Guido decided it was too late in the game to change site.py
at that point.)  Here was my proposed addition to site.py:

    # Define the built-in object "help" to provide interactive help.
    class Helper:
        def __repr__(self):
            import inspect
            if inspect.stack()[1][3] == '?': # not called from a function
                self()
                return ''
            return '<Helper instance>'
        def __call__(self, arg=None):
            import pydoc
            pydoc.help(arg)
    __builtin__.help = Helper()

Why the strange check involving inspect.stack()?
inspect.stack()[1][3] is the co_name of the parent frame.
If we check that the __repr__ is not being requested by a
function call, everything works perfectly in IDLE as well
as the plain interpreter, and the helper object is still safe
to pass around.  Nothing breaks even if you say help(help).

The above few lines are a reasonable addition to sitecustomize.py
if you happen to be setting up a local installation of Python.


-- ?!ng

"If I have seen farther than others, it is because I was standing on a
really big heap of midgets."
    -- K. Eric Drexler







From paulp at ActiveState.com  Tue Apr 17 20:58:42 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 11:58:42 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org> <3ADC7643.9AF12AB3@ActiveState.com> <200104171659.f3HGxTa00465@odiug.digicool.com> <3ADC7D2F.F0096D9F@ActiveState.com> <20010417195041.T2820@xs4all.nl>
Message-ID: <3ADC9262.928F1398@ActiveState.com>

Thomas Wouters wrote:
> 
> On Tue, Apr 17, 2001 at 10:28:15AM -0700, Paul Prescod wrote:
> 
> > All it would take now is
> >
> > class help:
> >    def __repr__(self):
> >       import pydoc
> >       __builtins__.help = pydoc.help
> >       repr(__builtins__.help)
> 
> > But hindsight is 20/20.
> 
> You realize this isn't going to work, right ? The 'help' class will shadow
> the 'help' builtin.

We do not have to call the class "help" nor to define it in the __main__
or __builtins__ context. Or were you getting at something deeper?

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From Jason.Tishler at dothill.com  Tue Apr 17 21:12:19 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Tue, 17 Apr 2001 15:12:19 -0400
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 17, 2001 at 09:29:44AM -0500
References: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>
Message-ID: <20010417151219.T275@dothill.com>

On Tue, Apr 17, 2001 at 09:29:44AM -0500, Guido van Rossum wrote:
> - ports to several new platforms, including Cygwin and RISCOS

I have contributed Python to the standard Cygwin distribution.  Cygwin
Python is located in the contrib/python directory on the Cygwin mirrors.
Cygwin's setup.exe will automatically install Cygwin Python the next
time one installs or updates from a mirror.

If interested, see the following for a copy of the announcement:

    http://www.cygwin.com/ml/cygwin/2001-04/msg01074.html

I kindly request that people post to python-list at python.org or
cygwin at sources.redhat.com as appropriate instead of emailing me
directly.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From dubois1 at llnl.gov  Tue Apr 17 21:05:25 2001
From: dubois1 at llnl.gov (Paul F. Dubois)
Date: Tue, 17 Apr 2001 12:05:25 -0700
Subject: [Python-Dev] PEP 0242 Numeric kinds updated
Message-ID: <01041712272103.11576@almanac>

I have updated the text of PEP 0242 about Numeric kinds. This proposal is now
complete and a reference implementation has been created. 

See http://python.sourceforge.net/peps/pep-0242.html

As part of this reference implementation I was considering adding a 32-bit
float scalar floating-point object to the kinds module. This object would then
be accessible via the kinds module although there would be no corresponding
literal notation. For example:

import kinds
f loat32= kinds.float_kind(5,30)
x = float32(3.14159)

would on all platforms I know about create x as such an object, which may be of
interest to those attempting to conserve space in certain applications of
Numeric.

Comments on the PEP and this point are requested.





From martin at loewis.home.cs.tu-berlin.de  Tue Apr 17 21:27:13 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 17 Apr 2001 21:27:13 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104150157.UAA31334@cj20424-a.reston1.va.home.com> (message
	from Guido van Rossum on Sat, 14 Apr 2001 20:57:00 -0500)
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>  
            <E14oEOc-0001si-00@darjeeling> <200104150157.UAA31334@cj20424-a.reston1.va.home.com>
Message-ID: <200104171927.f3HJRDP01133@mira.informatik.hu-berlin.de>

> And indeed it does when I tried it on SF's Solaris 8 box, which has
> OpenSSL installed and /dev/random.

This has caused Moshe's curiosity, and mine, as Solaris 8,
out-of-the-box, does not offer a /dev/random. I found two options:
There is a third-party patch:

http://www.cosy.sbg.ac.at/~andi/

which apparently works for all Solaris versions out there.

There is also a Sun patch, 105710-01, which supposedly uses a
user-space demon (just as EGD), see

http://devrandom.net/lists/archives/2000/11/OpenSSL-Users/0244.html

As explained, this is part of the SUNWski package.

Are you using one of these methods, or is there another option for
getting a 'true' /dev/random?

Regards,
Martin



From martin at loewis.home.cs.tu-berlin.de  Tue Apr 17 21:29:28 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 17 Apr 2001 21:29:28 +0200
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: <200104150633.BAA02770@cj20424-a.reston1.va.home.com> (message
	from Guido van Rossum on Sun, 15 Apr 2001 01:33:25 -0500)
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
Message-ID: <200104171929.f3HJTSi01162@mira.informatik.hu-berlin.de>

> I'm not sure what the intention was...
> 
> Martin, can you suggest a way out here?

In addition to the patch that already was applied, the test case can
be made more robust, by checking whether the en_US locale has the
right grouping value (and either fail or accept different results if
it doesn't).

Regards,
Martin



From guido at digicool.com  Wed Apr 18 00:14:27 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:14:27 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Tue, 17 Apr 2001 21:27:13 +0200."
             <200104171927.f3HJRDP01133@mira.informatik.hu-berlin.de> 
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling> <E14oEOc-0001si-00@darjeeling> <200104150157.UAA31334@cj20424-a.reston1.va.home.com>  
            <200104171927.f3HJRDP01133@mira.informatik.hu-berlin.de> 
Message-ID: <200104172214.RAA29373@cj20424-a.reston1.va.home.com>

[I wrote]
> > And indeed it does when I tried it on SF's Solaris 8 box, which has
> > OpenSSL installed and /dev/random.

[Martin replied]
> This has caused Moshe's curiosity, and mine, as Solaris 8,
> out-of-the-box, does not offer a /dev/random. I found two options:
> There is a third-party patch:
> 
> http://www.cosy.sbg.ac.at/~andi/
> 
> which apparently works for all Solaris versions out there.
> 
> There is also a Sun patch, 105710-01, which supposedly uses a
> user-space demon (just as EGD), see
> 
> http://devrandom.net/lists/archives/2000/11/OpenSSL-Users/0244.html
> 
> As explained, this is part of the SUNWski package.
> 
> Are you using one of these methods, or is there another option for
> getting a 'true' /dev/random?

Sorry, I must've confused myself.  I was logged in on several
different SF CF hosts, and now I can't find a /dev/random on its
Solaris host, so I presume that it was never there and that I saw it
on one of the other hosts there.

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



From guido at digicool.com  Wed Apr 18 00:17:45 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:17:45 -0500
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: Your message of "Tue, 17 Apr 2001 15:12:19 -0400."
             <20010417151219.T275@dothill.com> 
References: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>  
            <20010417151219.T275@dothill.com> 
Message-ID: <200104172217.RAA29433@cj20424-a.reston1.va.home.com>

> I have contributed Python to the standard Cygwin distribution.  Cygwin
> Python is located in the contrib/python directory on the Cygwin mirrors.
> Cygwin's setup.exe will automatically install Cygwin Python the next
> time one installs or updates from a mirror.
> 
> If interested, see the following for a copy of the announcement:
> 
>     http://www.cygwin.com/ml/cygwin/2001-04/msg01074.html

Thanks, Jason!!!  Your efforts are much appreciated.  Keep up the good
work!

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



From guido at digicool.com  Wed Apr 18 00:20:26 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:20:26 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 12:13:36 MST."
             <Pine.LNX.4.10.10104171207230.454-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10104171207230.454-100000@skuld.kingmanhall.org> 
Message-ID: <200104172220.RAA29454@cj20424-a.reston1.va.home.com>

> Why the strange check involving inspect.stack()?
> inspect.stack()[1][3] is the co_name of the parent frame.
> If we check that the __repr__ is not being requested by a
> function call, everything works perfectly in IDLE as well
> as the plain interpreter, and the helper object is still safe
> to pass around.  Nothing breaks even if you say help(help).

This is one of the reasons why I didn't want to add this to the 2.1
release at such a late point.  I have no easy way to verify that this
is always true, and in fact I have no idea what inspect.stack()[1][3]
means. :-(

I just add "from pydoc import help" to my $PYTHONSTARTUP file.

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



From guido at digicool.com  Wed Apr 18 00:23:20 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:23:20 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 13:06:18 -0400."
             <15068.30730.709186.27733@anthem.wooz.org> 
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com>  
            <15068.30730.709186.27733@anthem.wooz.org> 
Message-ID: <200104172223.RAA29490@cj20424-a.reston1.va.home.com>

>     GvR> Could we recycle this PEP number for the 2.1.1 release
>     GvR> schedule (see my previous post here)?  That seems easier than
>     GvR> having a new PEP for each micro-release.
> 
> PEP numbers are a plentiful resource!  I'd prefer to give it a new PEP
> number.

One day I'm going to argue that anything limited to 4 digits can't
possibly be called "plentiful", but not this millennium. :-)

I didn't mean to save a PEP number -- I just meant to keep the 2.1
followup releases together.  I explained this to Barry over lunch and
he agrees now.

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



From barry at digicool.com  Wed Apr 18 00:16:08 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 18:16:08 -0400
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
	<200104171637.f3HGbPg32707@odiug.digicool.com>
	<15068.30730.709186.27733@anthem.wooz.org>
	<200104172223.RAA29490@cj20424-a.reston1.va.home.com>
Message-ID: <15068.49320.780995.520582@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

    GvR> One day I'm going to argue that anything limited to 4 digits
    GvR> can't possibly be called "plentiful", but not this
    GvR> millennium. :-)

Just as plentiful as 32-bit IP addresses, oil reserves, and 640KB of
main memory... oh wait. :)

    GvR> I didn't mean to save a PEP number -- I just meant to keep
    GvR> the 2.1 followup releases together.  I explained this to
    GvR> Barry over lunch and he agrees now.

Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
PEP 226.

-Barry



From barry at digicool.com  Wed Apr 18 00:17:34 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 18:17:34 -0400
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
	<200104171637.f3HGbPg32707@odiug.digicool.com>
	<15068.30730.709186.27733@anthem.wooz.org>
	<3ADC8C94.548514E3@ActiveState.com>
Message-ID: <15068.49406.441111.15203@anthem.wooz.org>

>>>>> "PP" == Paul Prescod <paulp at ActiveState.com> writes:

    >>   So Paul, what should be done about PEP 233?  Move it to
    >> "active for Python 2.2"?

    PP> Move it to "implemented." We can haggle about details but most
    PP> of the features I'd hoped for are implemented thanks to Ping!

Can you please update the text of PEP 233 to reflect Current (or
near-Current) Reality?

Thanks,
-Barry



From guido at digicool.com  Wed Apr 18 01:49:07 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 18:49:07 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 18:16:08 -0400."
             <15068.49320.780995.520582@anthem.wooz.org> 
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org> <200104172223.RAA29490@cj20424-a.reston1.va.home.com>  
            <15068.49320.780995.520582@anthem.wooz.org> 
Message-ID: <200104172349.SAA00877@cj20424-a.reston1.va.home.com>

>     GvR> I didn't mean to save a PEP number -- I just meant to keep
>     GvR> the 2.1 followup releases together.  I explained this to
>     GvR> Barry over lunch and he agrees now.
> 
> Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
> PEP 226.

OK.  So we need a 2.2.1 Czar.  Any volunteers?

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



From jafo at tummy.com  Wed Apr 18 04:03:52 2001
From: jafo at tummy.com (Sean Reifschneider)
Date: Tue, 17 Apr 2001 20:03:52 -0600
Subject: [Python-Dev] Re: ANNOUNCE: Python 2.1 final release
In-Reply-To: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 17, 2001 at 09:29:44AM -0500
References: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>
Message-ID: <20010417200352.A28871@tummy.com>

On Tue, Apr 17, 2001 at 09:29:44AM -0500, Guido van Rossum wrote:
>Yes, the *final* release of Python 2.1 is now available.  Thanks again

I've updated my set of RPMs against 2.1.  I've similarly upgraded my 2.1
beta announcement to 2.1 final, and am including it below.  Changes in this
version are:

   Upgrade to 2.1 final.
   Binary and package name is "python2" by default.  Comment out the first
         (non-comment) line of the .spec file to build "python".
   Fixes the path to python2 in pydoc based on the above.
   Uses "--with-pymalloc" when configuring.
   Included Tony Seward's patch to fix the expat module's header path.
   Split out devel and tkinter packages.

Enjoy,
Sean
======================
Shy of RPMs because of library or other dependancy problems with most of
the RPMs you pick up?  The cure, in my experience is to pick up an SRPM.
All you need to do to build a binary package tailored to your system is run
"rpm --rebuild <packagename>.src.rpm".

The Source RPM and binaries for RedHat and KRUD 7.0 are at:

   ftp://ftp.tummy.com/pub/tummy/RPMS/SRPMS/python2-2.1-1tummy.src.rpm

   ftp://ftp.tummy.com/pub/tummy/RPMS/binaries-KRUD-7.0-i386/

You'll also need the following to build the SRPMSs:

   ftp://ftp.tummy.com/pub/tummy/RPMS/SRPMS/expat-1.1-3tummy.src.rpm

(Note, KRUD is our RedHat-based distribution with all errata applied.
Binaries should work on a stock RedHat 7.0 system, particularly if you have
the errata applied).

Again, this one builds the executable as "python2", and can be installed
along-side your normal Python on the system.  Want to check out a great new
feature?  Type "pydoc string" or "pydoc -g" from your shell.

Download the SRPM from above, and most users can install a binary built
against exactly the set of packages on their system by doing:

   rpm --rebuild expat-1.1-3tummy.src.rpm
   rpm -i /usr/src/redhat/RPMS/i386/expat*-1.1-3tummy.i386.rpm
   rpm --rebuild python-2.1b2-1tummy.src.rpm
   rpm -i /usr/src/redhat/RPMS/i386/python*2.1b1-1tummy.i386.rpm

Enjoy,
Sean
-- 
 The structure of a system reflects the structure of the organization that
 built it.  -- Richard E. Fairley
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python



From ping at lfw.org  Wed Apr 18 01:04:53 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 17 Apr 2001 16:04:53 -0700 (PDT)
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <200104172220.RAA29454@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org>

On Tue, 17 Apr 2001, Guido van Rossum wrote:
> This is one of the reasons why I didn't want to add this to the 2.1
> release at such a late point.  I have no easy way to verify that this
> is always true, and in fact I have no idea what inspect.stack()[1][3]
> means. :-(

Would you have preferred to write

    sys._getframe().f_back.f_code.co_name

?  It's the same thing.


-- ?!ng

"If I have seen farther than others, it is because I was standing on a
really big heap of midgets."
    -- K. Eric Drexler




From guido at digicool.com  Wed Apr 18 08:01:57 2001
From: guido at digicool.com (Guido van Rossum)
Date: Wed, 18 Apr 2001 01:01:57 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 16:04:53 MST."
             <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org> 
Message-ID: <200104180601.BAA13715@cj20424-a.reston1.va.home.com>

> On Tue, 17 Apr 2001, Guido van Rossum wrote:
> > This is one of the reasons why I didn't want to add this to the 2.1
> > release at such a late point.  I have no easy way to verify that this
> > is always true, and in fact I have no idea what inspect.stack()[1][3]
> > means. :-(
> 
> Would you have preferred to write
> 
>     sys._getframe().f_back.f_code.co_name
> 
> ?  It's the same thing.

Well, that clears up one mystery.  The rest of your explanation of why
this is correct (as opposed to why this works in the two cases you've
tried :-) is still completely opaque to me...

>     # Define the built-in object "help" to provide interactive help.
>     class Helper:
>         def __repr__(self):
>             import inspect
>             if inspect.stack()[1][3] == '?': # not called from a function
>                 self()
>                 return ''
>             return '<Helper instance>'
>         def __call__(self, arg=None):
>             import pydoc
>             pydoc.help(arg)
>     __builtin__.help = Helper()
> 
> Why the strange check involving inspect.stack()?
> inspect.stack()[1][3] is the co_name of the parent frame.
> If we check that the __repr__ is not being requested by a
> function call, everything works perfectly in IDLE as well
> as the plain interpreter, and the helper object is still safe
> to pass around.  Nothing breaks even if you say help(help).

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



From tim.one at home.com  Wed Apr 18 10:55:34 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 18 Apr 2001 04:55:34 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <200104172223.RAA29490@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEPGJMAA.tim.one@home.com>

[Guido]
> ...
> I didn't mean to save a PEP number -- I just meant to keep the 2.1
> followup releases together.  I explained this to Barry over lunch and
> he agrees now.

I added a "[bugfix release dates go here]" marker to PEP 226 to remind him
<wink>.  Jeremy (he's still listed as the author) may want to clear out the
"Open issues for Python 2.0 beta 2" section.




From thomas at xs4all.net  Wed Apr 18 11:56:21 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 18 Apr 2001 11:56:21 +0200
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <200104172349.SAA00877@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 17, 2001 at 06:49:07PM -0500
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org> <200104172223.RAA29490@cj20424-a.reston1.va.home.com> <15068.49320.780995.520582@anthem.wooz.org> <200104172349.SAA00877@cj20424-a.reston1.va.home.com>
Message-ID: <20010418115621.U2820@xs4all.nl>

On Tue, Apr 17, 2001 at 06:49:07PM -0500, Guido van Rossum wrote:
> >     GvR> I didn't mean to save a PEP number -- I just meant to keep
> >     GvR> the 2.1 followup releases together.  I explained this to
> >     GvR> Barry over lunch and he agrees now.
> > 
> > Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
> > PEP 226.

> OK.  So we need a 2.2.1 Czar.  Any volunteers?

I assume you mean a 2.1.x Czar :) I'm willing to do it, given that it
doesn't require much attention *now* (except checking the checkin messages,
which I do anyway) and I fully expect to be able to free all the time I need
in a few weeks anyway. But I'm perfectly happy with Moshe or someone else
doing it, too.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From tim.one at home.com  Wed Apr 18 12:14:33 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 18 Apr 2001 06:14:33 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <15068.28158.342537.431634@anthem.wooz.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEPLJMAA.tim.one@home.com>

>   S   236  pep-0236.txt  Back to the __future__                 Peters
>
> Same for this one, Tim...

Part of the initial text in this should (as PEP 236 itself says) move into
PEP 5, but other than that it reflects 2.1's reality.  PEP 5 is Paul's.
Happy to move stuff into PEP 5 for him, but the instant I do that you just
*know* Guido will force me to change all sorts of things in PEP 5 that Paul
would vehemently disown <wink>.




From paulp at ActiveState.com  Wed Apr 18 12:35:22 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Wed, 18 Apr 2001 03:35:22 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <LNBBLJKPBEHFEDALKOLCGEPLJMAA.tim.one@home.com>
Message-ID: <3ADD6DEA.9FEED09A@ActiveState.com>

Tim Peters wrote:
> 
> >   S   236  pep-0236.txt  Back to the __future__                 Peters
> >
> > Same for this one, Tim...
> 
> Part of the initial text in this should (as PEP 236 itself says) move into
> PEP 5, but other than that it reflects 2.1's reality.  PEP 5 is Paul's.
> Happy to move stuff into PEP 5 for him, but the instant I do that you just
> *know* Guido will force me to change all sorts of things in PEP 5 that Paul
> would vehemently disown <wink>.

If you want to work out a clear status for PEP 5's process, you're
welcome to take it over!
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From guido at digicool.com  Tue Apr 17 16:29:44 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 09:29:44 -0500
Subject: [Python-Dev] ANNOUNCE: Python 2.1 final release
Message-ID: <mailman.987518161.9928.clpa-moderators@python.org>

Yes, the *final* release of Python 2.1 is now available.  Thanks again
for all who helped!  Go here for downloads and information:

    http://www.python.org/2.1/

As a reminder, here's a list of some of the big new features in 2.1
(news since 2.0 was released in October 2000):

- nested scopes and __future__ directives
- rich comparisons and new coercion model
- warnings framework
- new build process (Unix)
- weak references
- function attributes
- unittest and doctest modules for automated testing
- ports to several new platforms, including Cygwin and RISCOS

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




From guido at digicool.com  Wed Apr 18 17:04:15 2001
From: guido at digicool.com (Guido van Rossum)
Date: Wed, 18 Apr 2001 10:04:15 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Wed, 18 Apr 2001 11:56:21 +0200."
             <20010418115621.U2820@xs4all.nl> 
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org> <200104172223.RAA29490@cj20424-a.reston1.va.home.com> <15068.49320.780995.520582@anthem.wooz.org> <200104172349.SAA00877@cj20424-a.reston1.va.home.com>  
            <20010418115621.U2820@xs4all.nl> 
Message-ID: <200104181504.KAA15504@cj20424-a.reston1.va.home.com>

> > > Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
> > > PEP 226.
> 
> > OK.  So we need a 2.2.1 Czar.  Any volunteers?
> 
> I assume you mean a 2.1.x Czar :)

Yes. :-)

> I'm willing to do it, given that it
> doesn't require much attention *now* (except checking the checkin messages,
> which I do anyway) and I fully expect to be able to free all the time I need
> in a few weeks anyway. But I'm perfectly happy with Moshe or someone else
> doing it, too.

Excellent.  I'd say let's divide labor here -- piling it all on Moshe
isn't fair.  You & Moshe can have a race who gets the first bugfix
release out! :-)

PEP 226 is all yours!

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



From jeremy at digicool.com  Wed Apr 18 16:07:31 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Wed, 18 Apr 2001 10:07:31 -0400 (EDT)
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org>
References: <200104172220.RAA29454@cj20424-a.reston1.va.home.com>
	<Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org>
Message-ID: <15069.40867.126819.564289@slothrop.digicool.com>

>>>>> "KPY" == Ka-Ping Yee <ping at lfw.org> writes:

  KPY> On Tue, 17 Apr 2001, Guido van Rossum wrote:
  >> This is one of the reasons why I didn't want to add this to the
  >> 2.1 release at such a late point.  I have no easy way to verify
  >> that this is always true, and in fact I have no idea what
  >> inspect.stack()[1][3] means. :-(

  KPY> Would you have preferred to write

  KPY>     sys._getframe().f_back.f_code.co_name

  KPY> ?  It's the same thing.

It's certainly clearer that inspect.stack()[1][3].  Does the existence
of the inspect module imply that we need to maintain its interface?
If we did, then we have some weird limits on the order of things in
stack frames.

Jeremy




From thomas.heller at ion-tof.com  Wed Apr 18 17:32:58 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 17:32:58 +0200
Subject: [Python-Dev] buffer interface (again)
Message-ID: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>

I would like to use (again) the buffer interface,
and I have some suggestions/questions.

- Only extension types can implement the buffer interface,
no way for a python class. Maybe a magic method __buffer__(self)
could be invented for this purpose?

- Why does the builtin function buffer() always return
readonly buffers, even for read/write objects? Shouldn't
there also be a readwrite_buffer() function, or should
buffer() return read/write buffers for read/write objects?

- My bug report 216405 on sourceforge is still open
(well, it is marked as closed, but it went into PEP 42)
http://sourceforge.net/tracker/index.php?func=detail&aid=216405&group_id=5470&atid=105470

Regards,

Thomas




From guido at digicool.com  Wed Apr 18 18:45:49 2001
From: guido at digicool.com (Guido van Rossum)
Date: Wed, 18 Apr 2001 11:45:49 -0500
Subject: [Python-Dev] buffer interface (again)
In-Reply-To: Your message of "Wed, 18 Apr 2001 17:32:58 +0200."
             <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook> 
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook> 
Message-ID: <200104181645.LAA16566@cj20424-a.reston1.va.home.com>

> I would like to use (again) the buffer interface,
> and I have some suggestions/questions.
> 
> - Only extension types can implement the buffer interface,
> no way for a python class. Maybe a magic method __buffer__(self)
> could be invented for this purpose?

How could it be made safe?  The buffer interface makes raw memory
addresses available.  Letting a Python class decide on what addresses
to use opens a big hole for abuse.

> - Why does the builtin function buffer() always return
> readonly buffers, even for read/write objects? Shouldn't
> there also be a readwrite_buffer() function, or should
> buffer() return read/write buffers for read/write objects?

It's a lifetime issue.  You can hold on to the object returned by
buffer() long after the actual memory it points to is recycled for
some other purpose, and while *reading* that memory is not such a big
deal (assuming it is still part of your address space, you'll just get
garbage), allowing it to be *written* is again an invitation to
disaster.

> - My bug report 216405 on sourceforge is still open
> (well, it is marked as closed, but it went into PEP 42)
> http://sourceforge.net/tracker/index.php?func=detail&aid=216405&group_id=5470&atid=105470

I still feel that your bug report is based on the wrong assumption
about what the buffer API should do.

Thomas, please first explain what you want to *do* with the buffer
interface.  Some of the buffer API was a mistake.  It *appears* to be
an interface for allocating and managing buffers, while in actuality
it is only intended to provide access to buffered data that is managed
by some C code.  You're probably better off using the array module to
manage buffers.

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



From thomas.heller at ion-tof.com  Wed Apr 18 17:49:55 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 17:49:55 +0200
Subject: [Python-Dev] Case sensitive import on windows
Message-ID: <03ac01c0c81f$36e45950$e000a8c0@thomasnotebook>

I tried to find out what had changed between 2.0 and 2.1.
Consider the following files in the current directory:

Spam.py
spam/__init__.py

Using python 2.0:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: Case mismatch for module name Spam
(filename spam)
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>

Using python 2.1:

Python 2.1c2 (#14, Apr 15 2001, 21:29:05) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: NULL result without error in call_object
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>

Seems like a bug to me...

Thomas




From thomas.heller at ion-tof.com  Wed Apr 18 18:06:12 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 18:06:12 +0200
Subject: [Python-Dev] buffer interface (again)
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>  <200104181645.LAA16566@cj20424-a.reston1.va.home.com>
Message-ID: <03d101c0c821$7d13cee0$e000a8c0@thomasnotebook>

[no need to cc me directly]
> > I would like to use (again) the buffer interface,
> > and I have some suggestions/questions.
> > 
> > - Only extension types can implement the buffer interface,
> > no way for a python class. Maybe a magic method __buffer__(self)
> > could be invented for this purpose?
> 
> How could it be made safe?  The buffer interface makes raw memory
> addresses available.  Letting a Python class decide on what addresses
> to use opens a big hole for abuse.
class C:
    ...
    def __buffer__(self):
        # self.my_buffer is an object exposing the buffer interface
        return buffer(self.my_buffer)
or:
        return self.my_buffer
> 
> > - Why does the builtin function buffer() always return
> > readonly buffers, even for read/write objects? Shouldn't
> > there also be a readwrite_buffer() function, or should
> > buffer() return read/write buffers for read/write objects?
> 
> It's a lifetime issue.  You can hold on to the object returned by
> buffer() long after the actual memory it points to is recycled for
> some other purpose, and while *reading* that memory is not such a big
> deal (assuming it is still part of your address space, you'll just get
> garbage), allowing it to be *written* is again an invitation to
> disaster.
Lifetimes are managed by refcounts, so it's a refcount issue,
at least as long as every object exposing the buffer interface
_guarantees_ that the memory address and size does not change.
(Which does not seem the case for array objects).

> 
> > - My bug report 216405 on sourceforge is still open
> > (well, it is marked as closed, but it went into PEP 42)
> > http://sourceforge.net/tracker/index.php?func=detail&aid=216405&group_id=5470&atid=105470
> 
> I still feel that your bug report is based on the wrong assumption
> about what the buffer API should do.
I only tried to fix the refcount issue.

> 
> Thomas, please first explain what you want to *do* with the buffer
> interface.  Some of the buffer API was a mistake.  It *appears* to be
> an interface for allocating and managing buffers, while in actuality
> it is only intended to provide access to buffered data that is managed
> by some C code.  You're probably better off using the array module to
> manage buffers.

I want to expose memory blocks to C, wrapped in python objects/classes.
These memory blocks could come from builtin python types: strings,
unicode strings, array objects, mmap'd files, ...

Thomas




From Barrett at stsci.edu  Wed Apr 18 17:22:12 2001
From: Barrett at stsci.edu (Paul Barrett)
Date: Wed, 18 Apr 2001 11:22:12 -0400
Subject: [Python-Dev] buffer interface (again)
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>  <200104181645.LAA16566@cj20424-a.reston1.va.home.com> <03d101c0c821$7d13cee0$e000a8c0@thomasnotebook>
Message-ID: <3ADDB124.A34D3D45@STScI.Edu>

Thomas Heller wrote:
> 
> Lifetimes are managed by refcounts, so it's a refcount issue,
> at least as long as every object exposing the buffer interface
> _guarantees_ that the memory address and size does not change.
> (Which does not seem the case for array objects).
> 
> >
> > Thomas, please first explain what you want to *do* with the buffer
> > interface.  Some of the buffer API was a mistake.  It *appears* to be
> > an interface for allocating and managing buffers, while in actuality
> > it is only intended to provide access to buffered data that is managed
> > by some C code.  You're probably better off using the array module to
> > manage buffers.
> 
> I want to expose memory blocks to C, wrapped in python objects/classes.
> These memory blocks could come from builtin python types: strings,
> unicode strings, array objects, mmap'd files, ...

If you are talking about a memory object, then I'm in agreement with
you, Thomas.

I'd like to see a memory object that allocates and deallocates blocks
of memory and exports a pointer to its memory.  It could also set
privileges such are read/write, etc.  Its interface would be
identical, or at least similar, to the mmap object, so that they could
be easily interchanged.

-- 
Dr. Paul Barrett       Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Group
FAX:   410-338-4767    Baltimore, MD 21218



From thomas.heller at ion-tof.com  Wed Apr 18 18:36:26 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 18:36:26 +0200
Subject: [Python-Dev] Case sensitive import on windows
References: <03ac01c0c81f$36e45950$e000a8c0@thomasnotebook>
Message-ID: <048101c0c825$b678a940$e000a8c0@thomasnotebook>

I'v submitted a bug report on SF, my message could not
be delivered to guido.


http://sourceforge.net/tracker/index.php?func=detail&aid=417093&group_id=5470&atid=105470

Thomas

Failed to deliver to '<guido at mail.digicool.com>'
LOCAL module(account guido) reports:
 file is not found






From barry at wooz.org  Wed Apr 18 18:42:26 2001
From: barry at wooz.org (Barry A. Warsaw)
Date: Wed, 18 Apr 2001 12:42:26 -0400
Subject: [Python-Dev] Case sensitive import on windows
References: <03ac01c0c81f$36e45950$e000a8c0@thomasnotebook>
	<048101c0c825$b678a940$e000a8c0@thomasnotebook>
Message-ID: <15069.50162.410986.49812@anthem.wooz.org>

Mail to anybody at digicool.com is broken at the moment.  I'm trying to
reach people by phone, but I'd be surprised if the sa's don't know
about it.  I hope this will be a short-lived outage.

-Barry



From thomas.heller at ion-tof.com  Wed Apr 18 18:42:59 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 18:42:59 +0200
Subject: [Python-Dev] buffer interface (again)
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>  <200104181645.LAA16566@cj20424-a.reston1.va.home.com> <03d101c0c821$7d13cee0$e000a8c0@thomasnotebook> <3ADDB124.A34D3D45@STScI.Edu>
Message-ID: <04b101c0c826$a0818890$e000a8c0@thomasnotebook>

> 
> I'd like to see a memory object that allocates and deallocates blocks
> of memory and exports a pointer to its memory.  It could also set
> privileges such are read/write, etc

It's all there, in bufferobject.c.
Except that the functions are not exposed to python...

Thomas




From aahz at panix.com  Wed Apr 18 21:07:20 2001
From: aahz at panix.com (aahz at panix.com)
Date: Wed, 18 Apr 2001 15:07:20 -0400 (EDT)
Subject: [Python-Dev] PEP 6 revision
Message-ID: <200104181907.PAA28941@panix3.panix.com>

[posted to c.l.py.announce and c.l.py; followups to c.l.py; cc'd to
python-dev]

[Barry, please update Post-History]

Okay, here's the next version of PEP 6:

PEP: 6
Title: Bugfix Releases
Version: $Revision: 1.3 $
Author: aahz at pobox.com (Aahz)
Status: Draft
Type: Informational
Created: 15-Mar-2001
Post-History: 15-Mar-2001

Abstract

    Python has historically had only a single fork of development, with
    releases having the combined purpose of adding new features and
    delivering bug fixes (these kinds of releases will be referred to as
    "feature releases").  This PEP describes how to fork off patch
    releases of old versions for the primary purpose of fixing bugs.

    This PEP is not, repeat NOT, a guarantee of the existence of patch
    releases; it only specifies a procedure to be followed if patch
    releases are desired by enough of the Python community willing to do
    the work.


Motivation

    With the move to SourceForge, Python development has accelerated.
    There is a sentiment among part of the community that there was too
    much acceleration, and many people are uncomfortable with upgrading
    to new versions to get bug fixes when so many features have been
    added, sometimes late in the development cycle.

    One solution for this issue is to maintain the previous feature
    release, providing bugfixes until the next feature release.  This
    should make Python more attractive for enterprise development, where
    Python may need to be installed on hundreds or thousands of machines.


Prohibitions

    Patch releases are required to adhere to the following restrictions:

    1. There must be zero syntax changes.  All .pyc and .pyo files must
        work (no regeneration needed) with all patch releases forked off
        from a feature release.

    2. There must be zero pickle changes.

    3. There must be no incompatible C API changes.  All extensions must
        continue to work without recompiling in all patch releases in the
        same fork as a feature release.

    Breaking any of these prohibitions requires a BDFL proclamation (and
    a prominent warning in the release notes).


Version Numbers

    Starting with Python 2.0, all feature releases are required to have
    a version number the form X.Y; patch releases will always be of the
    form X.Y.Z.

    The current feature release under development is referred to as
    release N; the just-released feature version is referred to as N-1.


Procedure

    The process for managing patch releases is modeled in part on the
    Tcl system [1].

    The Patch Czar is the counterpart to the BDFL for patch releases.
    However, the BDFL and designated appointees retain veto power over
    individual patches.

    As individual patches get contributed to the feature release fork,
    each patch contributor is requested to consider whether the patch is
    a bugfix suitable for inclusion in a patch release.  If the patch is
    considered suitable, the patch contributor will mail the SourceForge
    patch (bugfix?) number to the maintainers' mailing list.

    In addition, anyone from the Python community is free to suggest
    patches for inclusion.  Patches may be submitted specifically for
    patch releases; they should follow the guidelines in PEP 3 [2].

    The Patch Czar decides when there are a sufficient number of patches
    to warrant a release.  The release gets packaged up, including a
    Windows installer, and made public.  If any new bugs are found, they
    must be fixed immediately and a new patch release publicized (with an
    incremented version number).

    Patch releases are expected to occur at an interval of roughly one
    month.  In general, only the N-1 release will be under active
    maintenance at any time.


Patch Czar History

    Moshe Zadka (moshez at zadka.site.co.il) is the Patch Czar for 2.0.1.


Issues To Be Resolved

    What is the equivalent of python-dev for people who are responsible
    for maintaining Python?  (Aahz proposes either python-patch or
    python-maint, hosted at either python.org or xs4all.net.)

    Does SourceForge make it possible to maintain both separate and
    combined bug lists for multiple forks?  If not, how do we mark bugs
    fixed in different forks?  (Simplest is to simply generate a new bug
    for each fork that it gets fixed in, referring back to the main bug
    number for details.)


History

    This PEP started life as a proposal on comp.lang.python.  The
    original version suggested a single patch for the N-1 release to be
    released concurrently with the N release.  The original version also
    argued for sticking with a strict bugfix policy.

    Following feedback from the BDFL and others, the draft PEP was
    written containing an expanded patch release cycle that permitted
    any previous feature release to obtain patches and also relaxed the
    strict bugfix requirement (mainly due to the example of PEP 235 [3],
    which could be argued as either a bugfix or a feature).

    Discussion then mostly moved to python-dev, where BDFL finally
    issued a proclamation basing the Python patch release process on
    Tcl's, which essentially returned to the original proposal in terms
    of being only the N-1 release and only bugfixes, but allowing
    multiple patch releases until release N is published.


References

    [1] http://dev.scriptics.com:8080/cgi-bin/tct/tip/28.html
    [2] http://python.sourceforge.net/peps/pep-0003.html
    [3] http://python.sourceforge.net/peps/pep-0235.html


Copyright

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
-- 
                      --- Aahz  <*>  (Copyright 2001 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het Pythonista   http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

"If we had some ham, we could have ham & eggs, if we had some eggs." --RH



From m.favas at per.dem.csiro.au  Wed Apr 18 22:13:09 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Thu, 19 Apr 2001 04:13:09 +0800
Subject: [Python-Dev] 2.2a0: latest unicode change breaks test_unicodedata
Message-ID: <3ADDF555.13C627F8@per.dem.csiro.au>

In a change from 2.1 (final) to 2.2a0 - test_unicodedata now fails the
methods test:

test test_unicodedata failed -- Writing:
'00c22b40a906a1a738012676c9feaedfc6be20
d9', expected: '6c7a7c02657b69d0fdd7a7d174f573194bba2e18'

python Lib/test/test_unicodedata.py 
Testing Unicode Database...
Methods: 00c22b40a906a1a738012676c9feaedfc6be20d9
Functions: 4db70de42a8f2de6236242949579fe0e80e7c34a
API: ok

(Tru64 Unix, Compaq C)

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From tim.one at home.com  Wed Apr 18 23:20:59 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 18 Apr 2001 17:20:59 -0400
Subject: [Python-Dev] 2.2a0: latest unicode change breaks test_unicodedata
In-Reply-To: <3ADDF555.13C627F8@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEBNJNAA.tim.one@home.com>

[Mark Favas]
> In a change from 2.1 (final) to 2.2a0 - test_unicodedata now fails the
> methods test:
>
> test test_unicodedata failed -- Writing:
> '00c22b40a906a1a738012676c9feaedfc6be20
> d9', expected: '6c7a7c02657b69d0fdd7a7d174f573194bba2e18'
> ...
> (Tru64 Unix, Compaq C)

Reproduced identically on Windows (guess *everything* isn't the fault of
Compaq's compiler <wink>).  I assume this has something to do with the very
recent Unicode "optimization" patch.

Mystery:  since running the test suite before committing the change would
have caught this, how did the bug get into the CVS tree?  Since it appears
test_unicodedata is skipped under Unix when building the quicktest target, is
this due to people mechanically using quicktest instead of test?  Then that's
a second optimization bug <0.6 wink>.




From mal at lemburg.com  Thu Apr 19 00:51:11 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 00:51:11 +0200
Subject: [Python-Dev] Importing DLLs on Windows
Message-ID: <3ADE1A5F.F574B613@lemburg.com>

Python or Windows seems to have trouble importing DLLs when
inside packages. I'm working on an extension which pulls in a
DLL gmp31.dll which lives inside a package dir mx/Number/mxNumber
along side the Python wrapper extension mxNumber.pyd.

Currently, I'm using this code in the subpackage's __init__.py:

# On Windows we also distribute the GMP DLL (in the win32 subdir). To
# have Win32 find the DLL we need to be explicit about the path in
# sys.path though. This trick works for all startup directories
# *except* \PythonXX (for some reason this fails), but is not thread
# safe...
import sys, os
if sys.platform[:3] == 'win':
    abspath = os.path.abspath(__path__[0])
    sys.path.insert(0, abspath)
    from mxNumber import *
    sys.path.remove(abspath)

else:
    from mxNumber import *


I don't have any clue why the import works from everywhere *except*
the Python21 install directory... anyone does ?

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From tim.one at home.com  Thu Apr 19 01:05:39 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 18 Apr 2001 19:05:39 -0400
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <20010417151219.T275@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGECIJNAA.tim.one@home.com>

[Jason Tishler]
> I have contributed Python to the standard Cygwin distribution.
> ...
> Cygwin's setup.exe will automatically install Cygwin Python the next
> time one installs or updates from a mirror.

tim at CJ569191-B ~
$ type python
python is /usr/bin/python

tim at CJ569191-B ~
$ python -c "print 'Good show!'"
Good show!

tim at CJ569191-B ~
$

I have nothing to add to what Cygwin Python said <wink>.

hard-to-believe-any-real-program-runs-on-a-win98se-box-ly y'rs  - tim




From skip at pobox.com  Thu Apr 19 10:24:20 2001
From: skip at pobox.com (Skip Montanaro)
Date: Thu, 19 Apr 2001 03:24:20 -0500 (CDT)
Subject: [Python-Dev] tickling version numbers during release
Message-ID: <15070.41140.642307.450172@beluga.mojam.com>

It seems like there is always a flurry of checkins associated with bumping
version numbers whenever a release is impending.  Wouldn't it make sense to
stuff the version number into a file somewhere then add a make target to the
makefile to update the relevant files and check them into cvs?

Skip



From Jason.Tishler at dothill.com  Thu Apr 19 16:07:27 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Thu, 19 Apr 2001 10:07:27 -0400
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECIJNAA.tim.one@home.com>; from tim.one@home.com on Wed, Apr 18, 2001 at 07:05:39PM -0400
References: <20010417151219.T275@dothill.com> <LNBBLJKPBEHFEDALKOLCGECIJNAA.tim.one@home.com>
Message-ID: <20010419100727.G394@dothill.com>

On Wed, Apr 18, 2001 at 07:05:39PM -0400, Tim Peters wrote:
> hard-to-believe-any-real-program-runs-on-a-win98se-box-ly y'rs  - tim

Hmm...  Maybe we should take up a collection and buy Tim a copy of
Windows 2000 -- at least then he will have a better chance of deluding
himself into thinking that he is using a "real" operating system. :,)

Anyway, I do appreciate Guido and Tim's acknowledge of my efforts on
the Cygwin Python port.  It's been fun and I learned a lot of new things.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From trentm at ActiveState.com  Thu Apr 19 16:53:26 2001
From: trentm at ActiveState.com (Trent Mick)
Date: Thu, 19 Apr 2001 07:53:26 -0700
Subject: [Python-Dev] tickling version numbers during release
In-Reply-To: <15070.41140.642307.450172@beluga.mojam.com>; from skip@pobox.com on Thu, Apr 19, 2001 at 03:24:20AM -0500
References: <15070.41140.642307.450172@beluga.mojam.com>
Message-ID: <20010419075326.F30408@ActiveState.com>

On Thu, Apr 19, 2001 at 03:24:20AM -0500, Skip Montanaro wrote:
> It seems like there is always a flurry of checkins associated with bumping
> version numbers whenever a release is impending.  Wouldn't it make sense to
> stuff the version number into a file somewhere then add a make target to the
> makefile to update the relevant files and check them into cvs?

Or preferably have the version number in only *one* place in one file in CVS
then (1) have autoconf massage template files to insert the version number
where needed or (2) have those files that need the version number *include*
it from pyac_config.h.

...except we are not using any auto configuration tool on Windows. Damn.

Trent

-- 
Trent Mick
TrentM at ActiveState.com



From guido at digicool.com  Thu Apr 19 17:09:47 2001
From: guido at digicool.com (Guido van Rossum)
Date: Thu, 19 Apr 2001 11:09:47 -0400
Subject: [Python-Dev] tickling version numbers during release
In-Reply-To: Your message of "Thu, 19 Apr 2001 03:24:20 CDT."
             <15070.41140.642307.450172@beluga.mojam.com> 
References: <15070.41140.642307.450172@beluga.mojam.com> 
Message-ID: <200104191509.f3JF9ng02487@odiug.pythonlabs.org>

> It seems like there is always a flurry of checkins associated with bumping
> version numbers whenever a release is impending.  Wouldn't it make sense to
> stuff the version number into a file somewhere then add a make target to the
> makefile to update the relevant files and check them into cvs?

Is it worth spending the time to write a script that gets run only
once per revision?  (The bump from 2.1 to 2.2 causes many more
checkins than e.g. from 2.1 to 2.1.1 or from 2.1a1 to 2.1b1.)

It won't reduce the nubmer of checkins -- the files that have the
versions really must have the versions, and we do what we can to
minimize the dependencies (e.g. the VERSION variable in configure.in
gets propagated to the Makefile).

Like Knuth says in his explanation of how "The Art Of Computer
Programming" is typeset, the start of a new chapter is such a major
event that there's no macro for it -- he types it in himself.  (Most
other typing is done by typists of course.)

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



From mal at lemburg.com  Thu Apr 19 21:04:41 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 21:04:41 +0200
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, Floats)
Message-ID: <3ADF36C9.1D9AA305@lemburg.com>

As you all know, Moshe Zadka has been pushing for a new rational number
type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I though, but well, it's done now ;-)

The wrapper is called mx.Number and provides access to three
numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision

Prerequisites:
--------------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
i = Integer("1231231231231231231231231")

The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


Questions:
----------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From mwh21 at cam.ac.uk  Thu Apr 19 22:04:57 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 19 Apr 2001 21:04:57 +0100
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, Floats)
In-Reply-To: "M.-A. Lemburg"'s message of "Thu, 19 Apr 2001 21:04:41 +0200"
References: <3ADF36C9.1D9AA305@lemburg.com>
Message-ID: <m3g0f4r6za.fsf@atrus.jesus.cam.ac.uk>

Before I d/l and take a look...

"M.-A. Lemburg" <mal at lemburg.com> writes:

> (e.g. Integer(2) + "3" works as one would expect ;-).

So it raises an exception?  Seriously, that's what *I'd* expect, and
if it's not what your package does, I beg you to reconsider.

Cheers,
M.

-- 
  Good? Bad? Strap him into the IETF-approved witch-dunking
  apparatus immediately!                        -- NTK now, 21/07/2000




From mal at lemburg.com  Thu Apr 19 22:25:50 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 22:25:50 +0200
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, 
 Floats)
References: <3ADF36C9.1D9AA305@lemburg.com> <m3g0f4r6za.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <3ADF49CE.10EF2A5D@lemburg.com>

Michael Hudson wrote:
> 
> Before I d/l and take a look...
> 
> "M.-A. Lemburg" <mal at lemburg.com> writes:
> 
> > (e.g. Integer(2) + "3" works as one would expect ;-).
> 
> So it raises an exception?  Seriously, that's what *I'd* expect, and
> if it's not what your package does, I beg you to reconsider.

Integer(2) + "3" gives you Integer(5). This is a side-effect
of how the implementation converts arbitrary objects into ones
usable for coercion: Integer(2) + "3" is interpreted as 
Integer(2) + Integer("3") which gives Integer(2) + Integer(3).

After having played with it for a while, I must say, that I
kind of like it :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From mwh21 at cam.ac.uk  Thu Apr 19 23:46:51 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 19 Apr 2001 22:46:51 +0100
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0252.txt,NONE,1.1 pep-0000.txt,1.87,1.88
In-Reply-To: Guido van Rossum's message of "Thu, 19 Apr 2001 14:27:27 -0700"
References: <E14qLxX-0006pt-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <m3d7a8r29g.fsf@atrus.jesus.cam.ac.uk>

Guido van Rossum <gvanrossum at users.sourceforge.net> writes:

[snip]
> Author: guido at python.org (Jeremy Hylton)

Eh?

[snop]




From guido at digicool.com  Fri Apr 20 06:29:45 2001
From: guido at digicool.com (Guido van Rossum)
Date: Thu, 19 Apr 2001 23:29:45 -0500
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
Message-ID: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>

I've got a fairly complete implementation of iterators along the lines
of Ping's PEP (slightly updated).  This is available for inspection
through CVS: just check out the CVS branch of python/dist/src named
"iter-branch" from SourceForge:

  cvs checkout -r iter-branch -d <directory> python/src/dist

(This branch was forked off the trunk around the time of version
2.1b1, so it's not up to date with Python 2.1, but it's good enough to
show off iterators.)

My question is: should I just merge this code onto the trunk (making
it part of 2.2), or should we review the design more before committing
to this implementation?

Brief overview of what I've got implemented:

- There is a new built-in operation, spelled as iter(obj) in Python
  and as PyObject_GetIter(obj) in C; it calls the tp_iter slot in
  obj's type.  This returns an iterator, which can be any object that
  implements the iterator protocol.  The iterator protocol defines one
  method, next(), which returns the next value or raises the new
  StopIteration exception.

- For backwards compatibility, if obj's type does not have a valid
  tp_iter slot, iter(obj) and PyObject_GetIter(obj) create a sequence
  iterator that iterates over a sequence.

- "for x in S: B" is implemented roughly as

  __iter = iter(S)
  while 1:
    try:
      x = __iter.next()
    except StopIteration:
      break
    B

  (except that the semantics of break when there's an else clause are
  not different from what this Python code would do).

- The test "key in dict" is implemented as "dict.has_key(key)".  (This
  was done by implementing the sq_contains slot.

- iter(dict) returns an iterator that iterates over the keys of dict
  without creating a list of keys first.  This means that "for key in
  dict" has the same effect as "for key in dict.keys()" as long as the
  loop body doesn't modify the dictionary (assignment to existing keys
  is okay).

- There's an operation to create an iterator from a function and a
  sentinel value.  This is spelled as iter(function, sentinel).  For
  example,

    for line in iter(sys.stdin.readline, ""):
      ...

  is an efficient loop over the lines of stdin.

- But even cooler is this, which is totally equivalent:

    for line in sys.stdin:
      ...

- Not yet implemented, but part of the plan, is to use iterators for
  all other implicit loops, like map/reduce/filter, min/max, and the
  "in" test for sequences that don't define sq_contains.

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



From tim.one at home.com  Fri Apr 20 09:15:30 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 20 Apr 2001 03:15:30 -0400
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEHDJNAA.tim.one@home.com>

[Guido]
> I've got a fairly complete implementation of iterators along the lines
> of Ping's PEP (slightly updated).
> ...
> My question is: should I just merge this code onto the trunk (making
> it part of 2.2), or should we review the design more before committing
> to this implementation?

My answer is both!  *Most* of what you described is no longer controversial;
2.2 is mondo pre-alpha (so we're not "stuck" with anything you check in now);
and it's much more convenient (for me - heh) to try out if it's in the
regular build tree.  I bet Greg Wilson would like it for his Set PEP work
too, as abusing the __getitem__ protocol for set iteration is giving him
headaches.  WRT what may still be controversial points, there's no substitute
for trying a thing.

> ...
> - The test "key in dict" is implemented as "dict.has_key(key)".  (This
>   was done by implementing the sq_contains slot.

That's probably controversial, but also easy to rip out (sounds approximately
self-contained) if the peasants storm your castle with flaming dungballs
<wink>.

> - iter(dict) returns an iterator that iterates over the keys of dict
>   without creating a list of keys first.  This means that "for key in
>   dict" has the same effect as "for key in dict.keys()" as long as
>   the loop body doesn't modify the dictionary (assignment to existing
>   keys is okay).

Ditto.

> - There's an operation to create an iterator from a function and a
>   sentinel value.  This is spelled as iter(function, sentinel).  For
>   example,
>
>     for line in iter(sys.stdin.readline, ""):
>       ...
>
>   is an efficient loop over the lines of stdin.
>
> - But even cooler is this, which is totally equivalent:
>
>     for line in sys.stdin:
>       ...

Here you're going to be hoisted on your own petard (Jeremy can explain that
one <wink>):  if

    for x in dict:

has to iterate over keys because

    if x in dict:

tests for keys, then shouldn't

    if line in sys.stdin:

also check sys.stdin for the presence of line?  Not according to me, but it's
a not wholly unreasonable question.

> - Not yet implemented, but part of the plan, is to use iterators for
>   all other implicit loops, like map/reduce/filter, min/max, and the
>   "in" test for sequences that don't define sq_contains.

Check it into the trunk and people can help out with that stuff.

+0.9.




From thomas at xs4all.net  Fri Apr 20 10:37:33 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 20 Apr 2001 10:37:33 +0200
Subject: [python-iter] RE: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEHDJNAA.tim.one@home.com>; from tim.one@home.com on Fri, Apr 20, 2001 at 03:15:30AM -0400
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCCEHDJNAA.tim.one@home.com>
Message-ID: <20010420103733.D10318@xs4all.nl>

On Fri, Apr 20, 2001 at 03:15:30AM -0400, Tim Peters wrote:
> [Guido]
> > I've got a fairly complete implementation of iterators along the lines
> > of Ping's PEP (slightly updated).
> > ...
> > My question is: should I just merge this code onto the trunk (making
> > it part of 2.2), or should we review the design more before committing
> > to this implementation?

> My answer is both!  *Most* of what you described is no longer controversial;
> 2.2 is mondo pre-alpha (so we're not "stuck" with anything you check in now);
> and it's much more convenient (for me - heh) to try out if it's in the
> regular build tree.  I bet Greg Wilson would like it for his Set PEP work
> too, as abusing the __getitem__ protocol for set iteration is giving him
> headaches.  WRT what may still be controversial points, there's no substitute
> for trying a thing.

I don't totally agree. Removing something from the trunk is not as easy as
not adding it ;) But I agree that, since the *concept* of iterators, and the
basic implementation, all are good things, they should be checked in. I
still don't like:

> > ...
> > - The test "key in dict" is implemented as "dict.has_key(key)".  (This
> >   was done by implementing the sq_contains slot.

> That's probably controversial, but also easy to rip out (sounds approximately
> self-contained) if the peasants storm your castle with flaming dungballs
> <wink>.

Fetchez-la-vache!-ly y'rs

(Oh, now I get it... Iterators are Guido's wooden rabbit, with 'key-in-dict'
hidden inside... I just hope it's Sir Bedevere that's building it ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From mal at lemburg.com  Fri Apr 20 11:02:09 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 20 Apr 2001 11:02:09 +0200
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>
Message-ID: <3ADFFB11.AECF3438@lemburg.com>

Guido van Rossum wrote:
> 
> Brief overview of what I've got implemented:
> 
> - There is a new built-in operation, spelled as iter(obj) in Python
>   and as PyObject_GetIter(obj) in C; it calls the tp_iter slot in
>   obj's type.  This returns an iterator, which can be any object that
>   implements the iterator protocol.  The iterator protocol defines one
>   method, next(), which returns the next value or raises the new
>   StopIteration exception.

Could we also have a C slot for .next() ? (Python function calls
are way too expensive for these things, IMHO)

Will there be a __iter__() method for Python instances to implement ?

> - For backwards compatibility, if obj's type does not have a valid
>   tp_iter slot, iter(obj) and PyObject_GetIter(obj) create a sequence
>   iterator that iterates over a sequence.
> 
> - "for x in S: B" is implemented roughly as
> 
>   __iter = iter(S)
>   while 1:
>     try:
>       x = __iter.next()
>     except StopIteration:
>       break
>     B
> 
>   (except that the semantics of break when there's an else clause are
>   not different from what this Python code would do).
> 
> - The test "key in dict" is implemented as "dict.has_key(key)".  (This
>   was done by implementing the sq_contains slot.

Cool :)
 
> - iter(dict) returns an iterator that iterates over the keys of dict
>   without creating a list of keys first.  This means that "for key in
>   dict" has the same effect as "for key in dict.keys()" as long as the
>   loop body doesn't modify the dictionary (assignment to existing keys
>   is okay).
>
> - There's an operation to create an iterator from a function and a
>   sentinel value.  This is spelled as iter(function, sentinel).  For
>   example,
> 
>     for line in iter(sys.stdin.readline, ""):
>       ...
> 
>   is an efficient loop over the lines of stdin.

Hmm, I guess you have to compare each function output to the
sentinel then, right ? This can be very expensive.

Wouldn't an exception base class also do the trick as sentinel ? The 
iterator would then stop when an exception is raised by the
function which matches the sentinel exception.
 
> - But even cooler is this, which is totally equivalent:
> 
>     for line in sys.stdin:
>       ...
> 
> - Not yet implemented, but part of the plan, is to use iterators for
>   all other implicit loops, like map/reduce/filter, min/max, and the
>   "in" test for sequences that don't define sq_contains.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From thomas at xs4all.net  Fri Apr 20 11:26:38 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 20 Apr 2001 11:26:38 +0200
Subject: [Python-iterators] Re: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <3ADFFB11.AECF3438@lemburg.com>; from mal@lemburg.com on Fri, Apr 20, 2001 at 11:02:09AM +0200
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <3ADFFB11.AECF3438@lemburg.com>
Message-ID: <20010420112638.F10318@xs4all.nl>

On Fri, Apr 20, 2001 at 11:02:09AM +0200, M.-A. Lemburg wrote:

> > - There's an operation to create an iterator from a function and a
> >   sentinel value.  This is spelled as iter(function, sentinel).  For
> >   example,
> > 
> >     for line in iter(sys.stdin.readline, ""):
> >       ...
> > 
> >   is an efficient loop over the lines of stdin.

> Hmm, I guess you have to compare each function output to the
> sentinel then, right ? This can be very expensive.

> Wouldn't an exception base class also do the trick as sentinel ? The 
> iterator would then stop when an exception is raised by the
> function which matches the sentinel exception.

The sentinel method is for use with existing functions, that return a
sentinel value (like "" or None or whatever.) Comparing to those is not
terribly expensive, asside from the burden of running a single compare in
the inner loop. Rewriting those functions to raise an exception instead
would be, well, somewhat silly -- if you're rewriting them anyway, why not
just make an iterator out of them ?

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Fri Apr 20 11:35:12 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 20 Apr 2001 11:35:12 +0200
Subject: [Python-Dev] off-topic, sorry ;)
Message-ID: <20010420113512.G10318@xs4all.nl>

My batch of PythonLabs T-Shirts arrived yesterday (thanx, by the way,
Melissa!) but there was something twilight-zonish about the box that I just
had to share ;) My colleague Scott took delivery of the box, and knew
without looking at the sender or description that it was something Python
related. It had this sticker on it:

http://www.xs4all.nl/~thomas/SPAM.jpg

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From mal at lemburg.com  Fri Apr 20 12:10:10 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 20 Apr 2001 12:10:10 +0200
Subject: [Python-iterators] Re: [Python-Dev] Shall I start adding iterators 
 to Python 2.2?
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <3ADFFB11.AECF3438@lemburg.com> <20010420112638.F10318@xs4all.nl>
Message-ID: <3AE00B02.5EFCB6F@lemburg.com>

Thomas Wouters wrote:
> 
> On Fri, Apr 20, 2001 at 11:02:09AM +0200, M.-A. Lemburg wrote:
> 
> > > - There's an operation to create an iterator from a function and a
> > >   sentinel value.  This is spelled as iter(function, sentinel).  For
> > >   example,
> > >
> > >     for line in iter(sys.stdin.readline, ""):
> > >       ...
> > >
> > >   is an efficient loop over the lines of stdin.
> 
> > Hmm, I guess you have to compare each function output to the
> > sentinel then, right ? This can be very expensive.
> 
> > Wouldn't an exception base class also do the trick as sentinel ? The
> > iterator would then stop when an exception is raised by the
> > function which matches the sentinel exception.
> 
> The sentinel method is for use with existing functions, that return a
> sentinel value (like "" or None or whatever.) Comparing to those is not
> terribly expensive, asside from the burden of running a single compare in
> the inner loop. Rewriting those functions to raise an exception instead
> would be, well, somewhat silly -- if you're rewriting them anyway, why not
> just make an iterator out of them ?

I wasn't clear enough: I was proposing to also allow exception
classes as sentinel which are then not compared with the result
of the function, but instead with any exceptions raised by the
function. This would be an additional method of recognizing the
end-of-iteration to the standard return value comparison.

The reasoning is the you may want to use e.g. a C function (hard
to rewrite as iterator) as iterator which currently works along 
these lines:

while 1:
    try:
        x = datasource()
    except EndOfData:
        break
    print x

You could then rewrite this as:

for x in iter(datasource, EndOfData):
   print x

BTW, how does iter() recognize that it is supposed to look
for a sentinel ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From mal at lemburg.com  Thu Apr 19 21:04:41 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 21:04:41 +0200
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, Floats)
Message-ID: <mailman.987707135.9028.python-list@python.org>

As you all know, Moshe Zadka has been pushing for a new rational number
type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I though, but well, it's done now ;-)

The wrapper is called mx.Number and provides access to three
numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision

Prerequisites:
--------------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
i = Integer("1231231231231231231231231")

The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


Questions:
----------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/




From Greg.Wilson at baltimore.com  Fri Apr 20 14:55:24 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 08:55:24 -0400
Subject: [Python-Dev] configuration "feature"
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com>

I just checked out a fresh copy of Python from Sourceforge
on a Solaris 5.8 machine, and typed:

    ./configure -with-cxx

rather than

    ./configure -with-cxx=g++

It generates a makefile with "CXX=yes", so "make" produces:

    bash-2.03$ make
    yes -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H
\
        -o Modules/ccpython.o ./Modules/ccpython.cc
    make: yes: Command not found

:-)

Greg



From mwh21 at cam.ac.uk  Fri Apr 20 15:13:03 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 20 Apr 2001 14:13:03 +0100
Subject: [Python-Dev] configuration "feature"
In-Reply-To: Greg Wilson's message of "Fri, 20 Apr 2001 08:55:24 -0400"
References: <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com>
Message-ID: <m3ae5bpvds.fsf@atrus.jesus.cam.ac.uk>

Greg Wilson <Greg.Wilson at baltimore.com> writes:

> I just checked out a fresh copy of Python from Sourceforge
> on a Solaris 5.8 machine, and typed:
> 
>     ./configure -with-cxx
> 
> rather than
> 
>     ./configure -with-cxx=g++
> 
> It generates a makefile with "CXX=yes", so "make" produces:
> 
>     bash-2.03$ make
>     yes -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H
> \
>         -o Modules/ccpython.o ./Modules/ccpython.cc
>     make: yes: Command not found
> 
> :-)

Teehee.  Try it on a linux box though; there is a /usr/bin/yes, and it
doesn't do anything too helpful...

Cheers,
M.

-- 
  [Perl] combines all the  worst aspects of C and Lisp:  a billion
  different sublanguages in one monolithic executable. It combines
  the power of C with the readability of PostScript.
                                                     -- Jamie Zawinski




From guido at digicool.com  Fri Apr 20 16:55:54 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 09:55:54 -0500
Subject: [Python-Dev] configuration "feature"
In-Reply-To: Your message of "Fri, 20 Apr 2001 08:55:24 -0400."
             <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com> 
References: <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com> 
Message-ID: <200104201455.JAA05644@cj20424-a.reston1.va.home.com>

> I just checked out a fresh copy of Python from Sourceforge
> on a Solaris 5.8 machine, and typed:
> 
>     ./configure -with-cxx
> 
> rather than
> 
>     ./configure -with-cxx=g++
> 
> It generates a makefile with "CXX=yes", so "make" produces:
> 
>     bash-2.03$ make
>     yes -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H
> \
>         -o Modules/ccpython.o ./Modules/ccpython.cc
>     make: yes: Command not found
> 
> :-)

Use the SourceForge bug tracker, please!

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



From guido at digicool.com  Fri Apr 20 17:41:32 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 10:41:32 -0500
Subject: [Python-iterators] Re: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: Your message of "Fri, 20 Apr 2001 11:26:38 +0200."
             <20010420112638.F10318@xs4all.nl> 
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <3ADFFB11.AECF3438@lemburg.com>  
            <20010420112638.F10318@xs4all.nl> 
Message-ID: <200104201541.KAA06089@cj20424-a.reston1.va.home.com>

I've redirected replies to python-iterators at lists.sourceforge.net.
The archives work now:

http://www.geocrawler.com/lists/3/SourceForge/9283/0/

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



From thomas.heller at ion-tof.com  Fri Apr 20 17:05:42 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 17:05:42 +0200
Subject: [Python-Dev] Class Methods
Message-ID: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>

There are some signs :-) that Python's object
model is going to be revised even _before_
Python 3000.

Is someone willing to join me fighting
for class methods (I mean 'real' class-methods
in the Smalltalk style here, _not_ static
methods like in Java or C++).

Thomas




From jeremy at digicool.com  Fri Apr 20 17:14:16 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 20 Apr 2001 11:14:16 -0400 (EDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
Message-ID: <15072.21064.298318.393753@slothrop.digicool.com>

>>>>> "TH" == Thomas Heller <thomas.heller at ion-tof.com> writes:

  TH> There are some signs :-) that Python's object model is going to
  TH> be revised even _before_ Python 3000.

  TH> Is someone willing to join me fighting for class methods (I mean
  TH> 'real' class-methods in the Smalltalk style here, _not_ static
  TH> methods like in Java or C++).

The idea sounds good in the abstract.  Class are objects and objects
ought to have methods that implement their behavior.  How does that
very vague idea turn into something real?  No clue.  You start
fighting and let's see where it goes :-).

Jeremy




From guido at digicool.com  Fri Apr 20 18:26:01 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 11:26:01 -0500
Subject: [Python-Dev] Class Methods
In-Reply-To: Your message of "Fri, 20 Apr 2001 17:05:42 +0200."
             <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> 
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> 
Message-ID: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>

> There are some signs :-) that Python's object
> model is going to be revised even _before_
> Python 3000.

Well, the official policy on this is now that Py3K is just a slogan,
and that all the real work will be introduced gradually. :-)

> Is someone willing to join me fighting
> for class methods (I mean 'real' class-methods
> in the Smalltalk style here, _not_ static
> methods like in Java or C++).

I will fight class methods to the death. :-)

Seriously, I think you'll find an ally in Jim Fulton, who basically
told me (since he's sort of my boss :-) to get on with this work.  I
think it can work as follows:

Let x be an object, C its class, and M C's class.  So,

  x.__class__ is C
  C.__class__ is M

Then x's methods are described in C.__dict__, and C's methods are
described in M.__dict__.

The problem is that if you write C.spam, there could be two spams: one
in C.__dict__, one in M.__dict__.  Which one to use?  How does
Smalltalk resolve this?  The problem is that for backwards
compatibility, at lease, C.spam must be the unbound version of x.spam,
because currently x.spam(...) can always also be written as
C.spam(x, ...).

For regular methods it may be possible to avoid this simply by
choosing non-conflicting names, but I seem to recall that Jim wanted
to use class methods with certain special names (like __init__ or
__getattr__?), and I have no idea how to do this without dropping the
idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
solution?

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



From mal at lemburg.com  Fri Apr 20 17:24:29 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 20 Apr 2001 17:24:29 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com>
Message-ID: <3AE054AD.9A8D07D@lemburg.com>

Jeremy Hylton wrote:
> 
> >>>>> "TH" == Thomas Heller <thomas.heller at ion-tof.com> writes:
> 
>   TH> There are some signs :-) that Python's object model is going to
>   TH> be revised even _before_ Python 3000.
> 
>   TH> Is someone willing to join me fighting for class methods (I mean
>   TH> 'real' class-methods in the Smalltalk style here, _not_ static
>   TH> methods like in Java or C++).
> 
> The idea sounds good in the abstract.  Class are objects and objects
> ought to have methods that implement their behavior.  How does that
> very vague idea turn into something real?  No clue.  You start
> fighting and let's see where it goes :-).

Here's something to start the fight ;-) ...

1) What would you do with class methods that you cannot do with
   e.g. globals and functions ?

2) How would you determine which methods are class-only methods and
   which are one usable by instances ?

3) If you don't like globals (see 1), wouldn't it be possible to
   store the state you want to manipulate using class methods
   in some other context object ?

My impression is that class methods are not really needed and
would only make optimizing Python harder... but that's maybe just 
me ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at acm.org  Fri Apr 20 17:34:41 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 20 Apr 2001 11:34:41 -0400 (EDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
	<200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <15072.22289.218618.462955@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > __getattr__?), and I have no idea how to do this without dropping the
 > idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
 > solution?

  Can that be dropped and still allow subclasses to extend a method
offered by the base class?  I think making the two different would
break an enormous amount of code.


  -Fred

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




From thomas.heller at ion-tof.com  Fri Apr 20 17:40:21 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 17:40:21 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com>
Message-ID: <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>

> Here's something to start the fight ;-) ...
> 
> 1) What would you do with class methods that you cannot do with
>    e.g. globals and functions ?

I will write up a concrete example I have and post it later.

Look into the motivation for the Prototype Pattern in the GOF
book, or even better in the discussion of this pattern in the
'Design Pattern Smalltalk Companion' book.

This pattern is not needed if classes are 'first class' objects.

> 
> 2) How would you determine which methods are class-only methods and
>    which are one usable by instances ?
This is one of the issues which has to be resolved. I have no proposal
at the moment. (Maybe function attributes can help here?)

> 
> 3) If you don't like globals (see 1), wouldn't it be possible to
>    store the state you want to manipulate using class methods
>    in some other context object ?
I want the class methods (for example) to create and manipulate
this 'context object'. This object, however, belongs into the class...

What I want to avoid is

  class X(...):
      ....
  initialize(X)

> 
> My impression is that class methods are not really needed and
> would only make optimizing Python harder... but that's maybe just 
> me ;-)
Unfortunately not, I fear.

Thomas




From guido at digicool.com  Fri Apr 20 18:52:18 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 11:52:18 -0500
Subject: [Python-Dev] Class Methods
In-Reply-To: Your message of "Fri, 20 Apr 2001 17:40:21 +0200."
             <030101c0c9b0$3578a520$e000a8c0@thomasnotebook> 
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com>  
            <030101c0c9b0$3578a520$e000a8c0@thomasnotebook> 
Message-ID: <200104201652.LAA06554@cj20424-a.reston1.va.home.com>

> Look into the motivation for the Prototype Pattern in the GOF
> book, or even better in the discussion of this pattern in the
> 'Design Pattern Smalltalk Companion' book.

I imagine many of us (including yours truly :-) don't recall that in
enough detail and/or don't have the book handy to look it up, so would
you please do us a favor and explain this in a bit more detail?

> This pattern is not needed if classes are 'first class' objects.

Depending on what you mean by the 'first class' phrase (which means
something different to everyone), Python classes are already as first
class as they get.  E.g. they are tangible objects and you can pass
them around and store them in variables.

> What I want to avoid is
> 
>   class X(...):
>       ....
>   initialize(X)

What would initialize(X) do that you can't write in the class body?

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



From thomas.heller at ion-tof.com  Fri Apr 20 17:59:12 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 17:59:12 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>  <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <031b01c0c9b2$d79bfda0$e000a8c0@thomasnotebook>

> > Is someone willing to join me fighting
> > for class methods (I mean 'real' class-methods
> > in the Smalltalk style here, _not_ static
> > methods like in Java or C++).
> 
> I will fight class methods to the death. :-)
Ouch :-)

> 
> Seriously, I think you'll find an ally in Jim Fulton,
So there _is_ some hope.

>  who basically
> told me (since he's sort of my boss :-) to get on with this work.

This must be the reason that ExtensionClass provides them:
You can implement them in C, and override them in python
subclasses.

Thomas




From thomas.heller at ion-tof.com  Fri Apr 20 18:07:23 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 18:07:23 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com>              <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>  <200104201652.LAA06554@cj20424-a.reston1.va.home.com>
Message-ID: <034901c0c9b3$fcaa6bd0$e000a8c0@thomasnotebook>

> > Look into the motivation for the Prototype Pattern in the GOF
> > book, or even better in the discussion of this pattern in the
> > 'Design Pattern Smalltalk Companion' book.
> 
> I imagine many of us (including yours truly :-) don't recall that in
> enough detail and/or don't have the book handy to look it up, so would
> you please do us a favor and explain this in a bit more detail?
> 
This is a valid request, but please wait for my larger example.
I'm referring to this because I have not been good at explaining
the things I want...

All in all:

I'm not really ready to start the fight _now_, I was just
looking for some help...

Thomas

PS: I find it strange that everyone so far seems to be against it.




From barry at digicool.com  Fri Apr 20 18:13:07 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Fri, 20 Apr 2001 12:13:07 -0400
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>
Message-ID: <15072.24595.478099.658273@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

    GvR> My question is: should I just merge this code onto the trunk
    GvR> (making it part of 2.2), or should we review the design more
    GvR> before committing to this implementation?

I would definitely like to play with this stuff so I'd be generally +1
at committing your changes to the trunk.  Let me make two comments.

First, Ping or Guido should update the PEP, especially to describe the
`non-controversial' parts (using .next(), StopIteration -- where's
this exception in the hierarchy, btw?).  You should also update the
Open Issues section.

Second, I'm still not totally comfortable with the "for keys:values in
dict" part of the proposal, especially with the elaboration of letting
either keys or values be missing.  An alternative, which I sure has
been raised, but which isn't in the PEP, is to allow an alternative
pseudo-keyword in the `in' position.  For example, allow "over" which
has the semantics when used with a dict of iterating over keys.items()
and when iterating over a sequence has the semantics of iterating over
zip(range(len(a)), a).  Thus only this would be allowed:

    for key, value over dict:

    for index, item over seq:

I think it would be fine if you don't support optional untupling parts
in the target.

-Barry



From barry at digicool.com  Fri Apr 20 18:36:26 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Fri, 20 Apr 2001 12:36:26 -0400
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
	<200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <15072.25994.247806.815084@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

    GvR> Let x be an object, C its class, and M C's class.  So,

    |   x.__class__ is C
    |   C.__class__ is M

    GvR> Then x's methods are described in C.__dict__, and C's methods
    GvR> are described in M.__dict__.

    GvR> The problem is that if you write C.spam, there could be two
    GvR> spams: one in C.__dict__, one in M.__dict__.  Which one to
    GvR> use?

If you use naming to generally distinguish, and have a lookup chain
that first found it in C.__dict__ and then looked in M.__dict__, you
could control what happens when the name is in both dicts by using a
more explicit lookup, e.g. C.__dict__['meth']
vs. C.__class__.__dict__['meth']

But maybe that's too ugly.
    
    GvR> How does Smalltalk resolve this?

I don't remember, but I do remember that ObjC had the same concepts,
and it used a distinguishing marker on the method definition to say
whether the method was a class method (`+') or instance method (`-'),
e.g.

    + void some_class_method ...
    - void an_instance_method

Another question: presumably when I write

    class Foo: pass

Foo is implicitly given the built-in metaclass M, but say I wanted to
define a class Foo with a different metaclass, how would I spell this?
I think at one point I suggested a semi-ugly syntactic hack, where
`class' was actually a namespace and you could add new metaclasses to
it.  So you could write something like

    class.WeirdClass Foo: pass

and now Foo's metaclass would be WeirdClass.

waiting-for-the-bottom-turtle-to-burp-ly y'rs,
-Barry



From jeremy at digicool.com  Fri Apr 20 19:00:09 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 20 Apr 2001 13:00:09 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/ref ref3.tex,1.64,1.65 ref5.tex,1.43,1.44
In-Reply-To: <E14qe7G-0002AU-00@usw-pr-cvs1.sourceforge.net>
References: <E14qe7G-0002AU-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <15072.27417.366789.977575@slothrop.digicool.com>

>>>>> "GvR" == Guido van Rossum <gvanrossum at users.sourceforge.net> writes:

  GvR> Log Message: Implement, test and document "key in dict" and
  GvR> "key not in dict".

  GvR> I know some people don't like this -- if it's really
  GvR> controversial, I'll take it out again.  (If it's only Alex
  GvR> Martelli who doesn't like it, that doesn't count as "real
  GvR> controversial" though. :-)

I don't like it either, because it's only clear when it's spelled "for
key in dict".  It's pretty confusing when it's spelled "for val in
dict" or even "for x in dict".

But I'm willing to give it a try for a while.

Jeremy




From aahz at rahul.net  Fri Apr 20 19:08:53 2001
From: aahz at rahul.net (Aahz Maruch)
Date: Fri, 20 Apr 2001 10:08:53 -0700 (PDT)
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <15072.24595.478099.658273@anthem.wooz.org> from "Barry A. Warsaw" at Apr 20, 2001 12:13:07 PM
Message-ID: <20010420170853.ECA2C99C80@waltz.rahul.net>

Barry A. Warsaw wrote:
> 
> Second, I'm still not totally comfortable with the "for keys:values in
> dict" part of the proposal, especially with the elaboration of letting
> either keys or values be missing.  An alternative, which I sure has
> been raised, but which isn't in the PEP, is to allow an alternative
> pseudo-keyword in the `in' position.  For example, allow "over" which
> has the semantics when used with a dict of iterating over keys.items()
> and when iterating over a sequence has the semantics of iterating over
> zip(range(len(a)), a).  Thus only this would be allowed:
> 
>     for key, value over dict:
> 
>     for index, item over seq:

+1 from me, particularly the part about getting rid of "keys:values"; I
just see little advantage to using anything other than a tuple.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6       <*>       http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.



From root at rainerdeyke.com  Fri Apr 20 19:34:08 2001
From: root at rainerdeyke.com (Rainer Deyke)
Date: Fri, 20 Apr 2001 11:34:08 -0600
Subject: [Python-Dev] Re: Class Methods
References: <mailman.987779255.16686.python-list@python.org>
Message-ID: <027801c0c9c0$2e9081a0$070110ac@deyke.net>

"Thomas Heller" <thomas.heller at ion-tof.com> wrote in message
news:mailman.987779255.16686.python-list at python.org...
> There are some signs :-) that Python's object
> model is going to be revised even _before_
> Python 3000.
>
> Is someone willing to join me fighting
> for class methods (I mean 'real' class-methods
> in the Smalltalk style here, _not_ static
> methods like in Java or C++).

I posted this in another thread, but I think it bears repeating here.


I consider classes/instances a special case of namespaces: one which allows
(multiple) instantiation and inheritance.  In actual pratice not all of the
classes I design are designed for multiple instantiation, or instantiation
at all for that matter.  What I would like to see is a separation of
concerns ("Does this namespace have __special__ attributes for operator
overloading?" inpdependent from "Does this namespace require
instantiation?") followed by a culling of irrelevant features ("Don't want
operator overloading?  Don't name your function '__add__' then.").  The
resulting programming language might look something like this:

namespace A: # Create a named unique object
  pass
namespace B(A): # Similar to 'from ... import', but done through linking
                # instead of copying
class C(A): # 'class' = namespace that requires/supports instantiation
            # class inherits from namespace => functions in namespace
            # are treated as "static" functions
  pass
namespace D(C()): # namespace inherits from instance of class
  pass


The module itself would be a 'namespace' object.  Overall, I think this has
the potential of creating a much simpler and more regular language.
Separate keywords for 'class' and 'namespace' might even turn out to be
unnecessary.


In this context, class methods would either be automatically included, or
turn out to be truly redundant, or both.


--
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games           -           http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor





From tim.one at home.com  Fri Apr 20 19:44:40 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 20 Apr 2001 13:44:40 -0400
Subject: [Python-Dev] Class Methods
In-Reply-To: <034901c0c9b3$fcaa6bd0$e000a8c0@thomasnotebook>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEJBJNAA.tim.one@home.com>

[Thomas Heller]
> ...
> PS: I find it strange that everyone so far seems to be against it.

I didn't get that sense yet.  I did get the sense they're not actively *for*
it yet, and the questions asked so far explain why:  What does it buy us?
What are the current alternatives?  What are the costs (not least of all in
terms of breaking existing code)?  It's a bunch of tradeoffs, and it appears
that few who aren't steeped in Smalltalk's view of the world understand what
the practical *attraction* is.

The same questions get asked even for wholly non-controversial changes, like,
say, adding an optional ">> file" clause to "print" <wink>.

by-default-it's-best-to-resist-everything-ly y'rs  - tim




From michel at digicool.com  Fri Apr 20 19:50:15 2001
From: michel at digicool.com (Michel Pelletier)
Date: Fri, 20 Apr 2001 10:50:15 -0700 (PDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>
Message-ID: <Pine.LNX.4.32.0104201039300.6561-100000@localhost.localdomain>


On Fri, 20 Apr 2001, Thomas Heller wrote:

> > Here's something to start the fight ;-) ...
> >
> > 1) What would you do with class methods that you cannot do with
> >    e.g. globals and functions ?
>
> I will write up a concrete example I have and post it later.

There are a number of reasons why I'm all for Class attributes in general.
For example, right now a class object cannot assert an interface.  Sure,
a class can say:

class Foo:

  __implements__ = Bar  # instances implement Bar

but that is an assertion for the instances, not the *class itself*.
Currently, you have to do the ugly hack:

class Foo:

  __class_implements__ = FooFactory # the class implements
                                    # FooFactory.

We've done things like the above in several places in our underground
component elaboration.  Not having class methods introduces many little
wrinkles in the Python object model that have to be worked around.  I can
imagine, for example, wanting to define an __reduce__, or __init__ for a
class object, which is not possible now.

> Look into the motivation for the Prototype Pattern in the GOF
> book, or even better in the discussion of this pattern in the
> 'Design Pattern Smalltalk Companion' book.
>
> This pattern is not needed if classes are 'first class' objects.
>
> >
> > 2) How would you determine which methods are class-only methods and
> >    which are one usable by instances ?
> This is one of the issues which has to be resolved. I have no proposal
> at the moment. (Maybe function attributes can help here?)

I always thought along the lines of saying Class.instanceAttribute('foo')
in the place of what is now said Class.foo.  This would, of course, break
code, but the warning and back to the future features mitigate most of
that risk.

> >
> > 3) If you don't like globals (see 1), wouldn't it be possible to
> >    store the state you want to manipulate using class methods
> >    in some other context object ?
> I want the class methods (for example) to create and manipulate
> this 'context object'. This object, however, belongs into the class...
>
> What I want to avoid is
>
>   class X(...):
>       ....
>   initialize(X)

Yes! We use this monstrosity a lot in Zope.

-Michel




From donb at abinitio.com  Fri Apr 20 20:07:09 2001
From: donb at abinitio.com (Donald Beaudry)
Date: Fri, 20 Apr 2001 14:07:09 -0400
Subject: [Python-Dev] Re: Class Methods 
References: <mailman.987779255.16686.python-list@python.org> <027801c0c9c0$2e9081a0$070110ac@deyke.net>
Message-ID: <200104201807.OAA06589@localhost.localdomain>

"Thomas Heller" <thomas.heller at ion-tof.com> wrote,
> There are some signs :-) that Python's object
> model is going to be revised even _before_
> Python 3000.
>
> Is someone willing to join me fighting
> for class methods (I mean 'real' class-methods
> in the Smalltalk style here, _not_ static
> methods like in Java or C++).

A couple of years ago I did this as an extension module.  It might
still be around (I still use it).  Take a look for something called
objectmodule.  It's actually a mechanism for implementing different
object models from within python.  Beware, class methods are just part
of what it is capable of.

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb at init.com                                      Lexington, MA 02421
                  ...So much code, so little time...






From guido at digicool.com  Fri Apr 20 21:17:29 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 14:17:29 -0500
Subject: [Python-Dev] Re: Class Methods
In-Reply-To: Your message of "Fri, 20 Apr 2001 14:07:09 -0400."
             <200104201807.OAA06589@localhost.localdomain> 
References: <mailman.987779255.16686.python-list@python.org> <027801c0c9c0$2e9081a0$070110ac@deyke.net>  
            <200104201807.OAA06589@localhost.localdomain> 
Message-ID: <200104201917.OAA11851@cj20424-a.reston1.va.home.com>

> A couple of years ago I did this as an extension module.  It might
> still be around (I still use it).  Take a look for something called
> objectmodule.  It's actually a mechanism for implementing different
> object models from within python.  Beware, class methods are just part
> of what it is capable of.

Hi Don!  I still remember some of the stuff you showed me 6.5 years
ago, and some of the ideas my *finally* find their way into Python...
Watch PEP 252!

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



From paul at pfdubois.com  Fri Apr 20 20:09:20 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Fri, 20 Apr 2001 11:09:20 -0700
Subject: [Python-Dev] pydoc script
Message-ID: <ADEOIFHFONCLEEPKCACCGEGJCIAA.paul@pfdubois.com>

Ka-Ping,
Your pydoc script can fail because the pydoc executed is not the pydoc (and
therefore the python) in the users' current path if they start it explicitly
with a full path. I suggest a similar trick to this one:

#!/bin/csh -f
unsetenv PYTHONHOME
set bindir = `dirname $0`
set path=(${bindir} $path);rehash #in case of respawns, get our python
exec ${bindir}/python -O -c 'import browser;browser.tk_cdat.main()'





From Greg.Wilson at baltimore.com  Fri Apr 20 21:20:53 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 15:20:53 -0400
Subject: [Python-Dev] string slicing and method consistency
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com>

One of the students in my class at the Space Telescope
Science Institute ("Hubble R Us") last week brought up
an interesting point: if "abbc"[-1] is "c", and if
"abbc".replace("b", "x", 1) is "axbc", then shouldn't
"abbc".replace("b", "x", -1) be "abxc" (i.e. negative
numbers replace the *last* occurrences of the value)?
Same argument for "split", etc.

Turns out that "abbc".replace("b", "x", -1) is "axxc"
(i.e. negative arguments are ignored).  I would have
expected this to raise a ValueError, if anything.  Is
there a reason for this behavior?  Is it worth making
replace, split, etc. interpret negative indices in the
same way as indexing does?

Thanks,
Greg




From ping at lfw.org  Fri Apr 20 21:57:56 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Fri, 20 Apr 2001 14:57:56 -0500 (CDT)
Subject: [Python-Dev] string slicing and method consistency
In-Reply-To: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com>
Message-ID: <Pine.LNX.4.10.10104201456460.24864-100000@server1.lfw.org>

On Fri, 20 Apr 2001, Greg Wilson wrote:
> Is it worth making
> replace, split, etc. interpret negative indices in the
> same way as indexing does?

I think this would be really cool in particular for split().
(And if it worked for split it would have to work for replace.)


-- ?!ng




From thomas.heller at ion-tof.com  Fri Apr 20 21:37:41 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 21:37:41 +0200
Subject: [Python-Dev] Re: Class Methods 
References: <mailman.987779255.16686.python-list@python.org> <027801c0c9c0$2e9081a0$070110ac@deyke.net> <200104201807.OAA06589@localhost.localdomain>
Message-ID: <053901c0c9d1$5d8c2f70$e000a8c0@thomasnotebook>

> A couple of years ago I did this as an extension module.  It might
> still be around (I still use it).  Take a look for something called
> objectmodule.  It's actually a mechanism for implementing different
> object models from within python.  Beware, class methods are just part
> of what it is capable of.
> 
Thanks, Don.

I found it and will look into it.

Thomas




From thomas.heller at ion-tof.com  Fri Apr 20 21:51:28 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 21:51:28 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook><200104201626.LAA06384@cj20424-a.reston1.va.home.com> <15072.25994.247806.815084@anthem.wooz.org>
Message-ID: <055101c0c9d3$4a1b9d20$e000a8c0@thomasnotebook>

> >>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:
> 
>     GvR> Let x be an object, C its class, and M C's class.  So,
> 
>     |   x.__class__ is C
>     |   C.__class__ is M
> 
>     GvR> Then x's methods are described in C.__dict__, and C's methods
>     GvR> are described in M.__dict__.
> 
>     GvR> The problem is that if you write C.spam, there could be two
>     GvR> spams: one in C.__dict__, one in M.__dict__.  Which one to
>     GvR> use?
> 
[Barry wrote]
> If you use naming to generally distinguish, and have a lookup chain
> that first found it in C.__dict__ and then looked in M.__dict__, you
> could control what happens when the name is in both dicts by using a
> more explicit lookup, e.g. C.__dict__['meth']
> vs. C.__class__.__dict__['meth']
> 

Couldn't be C.__class__.meth be used?

> But maybe that's too ugly.
>     
>     GvR> How does Smalltalk resolve this?
I'm walking on thin ice here (maybe I should better try it out),
but IIRC Smalltalk requires to explicit:

    self class method;
or
    self method;

> Another question: presumably when I write
> 
>     class Foo: pass
> 
> Foo is implicitly given the built-in metaclass M, but say I wanted to
> define a class Foo with a different metaclass, how would I spell this?
> I think at one point I suggested a semi-ugly syntactic hack, where
> `class' was actually a namespace and you could add new metaclasses to
> it.  So you could write something like
> 
>     class.WeirdClass Foo: pass
> 
> and now Foo's metaclass would be WeirdClass.
Thin ice again I'm on here (even more), but I have the impression
that creating a class Point in Smalltalk _automatically_ creates
two classes: Point and PointClass. The latter is normally hidden
(but contains the class methods of Point as instance methods).

Thomas




From Greg.Wilson at baltimore.com  Fri Apr 20 22:07:26 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 16:07:26 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D1E7@nsamcanms1.ca.baltimore.com>

> > Thomas Heller:
> > PS: I find it strange that everyone so far seems to be against it.

> Tim Peters:
> I didn't get that sense yet.  I did get the sense they're not 
> actively *for* it yet, and the questions asked so far explain why:
> What does it buy us?

Greg Wilson:
I'd really like class methods so that my classes can carry their
factory methods around with them, and so that these factories can
be selectively overridden in derived classes.  I have machinery
to do all of this using freestanding functions, but it's clumsy
and error-prone.  Of course, so is a lot of my code... :-)



From michel at digicool.com  Fri Apr 20 22:32:43 2001
From: michel at digicool.com (Michel Pelletier)
Date: Fri, 20 Apr 2001 13:32:43 -0700 (PDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.32.0104201310270.6561-100000@localhost.localdomain>

On Fri, 20 Apr 2001, Guido van Rossum wrote:

> Let x be an object, C its class, and M C's class.  So,
>
>   x.__class__ is C
>   C.__class__ is M
>
> Then x's methods are described in C.__dict__, and C's methods are
> described in M.__dict__.
>
> The problem is that if you write C.spam, there could be two spams: one
> in C.__dict__, one in M.__dict__.  Which one to use?

I think, at the expense of breaking code, M.

> How does
> Smalltalk resolve this?  The problem is that for backwards
> compatibility, at lease, C.spam must be the unbound version of x.spam,
> because currently x.spam(...) can always also be written as
> C.spam(x, ...).

This is the part that choosing M would break.  To get at C's shared
instance attributes you could say something like
C.instanceAttribute('spam')(x, ...).

Yes, it's ugly.  Perhaps someone can think of a more elegant spelling?

> For regular methods it may be possible to avoid this simply by
> choosing non-conflicting names, but I seem to recall that Jim wanted
> to use class methods with certain special names (like __init__ or
> __getattr__?), and I have no idea how to do this without dropping the
> idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
> solution?

I'm not sure which idea you are talking about dropping, the first argument
binding behavior, or the spelling of getting shared instance attributes
from a class (C.spam).  Just asking to make sure, cuz I don't think the
first needs to change, just the spelling.

BTW, you sent me some comments on the Components and Interfaces chapter
of the Zope Developer's Guide where you noted that attributes of interface
objects are not the attributes described by the interface and that this is
"unfamiliar to the typical python programmer", ie:

  interface Hello:

    def hello(name):
      """ say hello to a name """

does not create a 'Hello.hello'.  Instead, you need to say
"Hello.getDescriptionFor('hello')".  If we chose the more familiar
'Hello.hello' then the interface interface would be seriously limited, and
any added functionality would need to be imported from an external module
or be a builtin like isinstance().  Interfaces, like classes, wouldn't be
able to have their own methods.

-Michel











From tim.one at home.com  Fri Apr 20 22:40:27 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 20 Apr 2001 16:40:27 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
In-Reply-To: <930BBCA4CEBBD411BE6500508BB3328F22D1E7@nsamcanms1.ca.baltimore.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com>

[Greg Wilson]
> I'd really like class methods so that my classes can carry their
> factory methods around with them, and so that these factories can
> be selectively overridden in derived classes.

Without a concrete example it's risky to guess, but that sounds more like
class static (in C++ terms) methods to me.  "class methods" in *this* thread
is being used in a Smalltalk sense (because it's Thomas Heller's thread, and
he made clear that he doesn't want C++-style class statics).  And, yes,
without a concrete example, it's risky to guess what that means too <wink>.

expecting-a-long-thread-full-of-misinterpreted-words-ly y'rs  - tim




From guido at digicool.com  Fri Apr 20 23:48:06 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 16:48:06 -0500
Subject: [Python-Dev] string slicing and method consistency
In-Reply-To: Your message of "Fri, 20 Apr 2001 15:20:53 -0400."
             <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com> 
References: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com> 
Message-ID: <200104202148.QAA13960@cj20424-a.reston1.va.home.com>

[GVW]
> One of the students in my class at the Space Telescope
> Science Institute ("Hubble R Us") last week brought up
> an interesting point: if "abbc"[-1] is "c", and if
> "abbc".replace("b", "x", 1) is "axbc", then shouldn't
> "abbc".replace("b", "x", -1) be "abxc" (i.e. negative
> numbers replace the *last* occurrences of the value)?
> Same argument for "split", etc.
> 
> Turns out that "abbc".replace("b", "x", -1) is "axxc"
> (i.e. negative arguments are ignored).  I would have
> expected this to raise a ValueError, if anything.  Is
> there a reason for this behavior?  Is it worth making
> replace, split, etc. interpret negative indices in the
> same way as indexing does?

Dubious hypergeneralization.  The thing is that this parameter, called
maxsplit, is not really an index -- it's a count.

Implementing this right would be tricky, because you'd really have to
search for matches from the end (in order to make sense if there are
overlapping matches possible, as in "abbbc".replace("bb", "BB", -1)).

Where would this be useful?  Is it ever useful for numbers smaller
than -1?  If all you typically want is replace the last occurrence,
the rfind() method is your friend.

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



From Greg.Wilson at baltimore.com  Fri Apr 20 23:08:31 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 17:08:31 -0400
Subject: [Python-Dev] re: string slicing and method consistency
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D1F5@nsamcanms1.ca.baltimore.com>

> > Greg Wilson:
> > if "abbc"[-1] is "c", and if
> > "abbc".replace("b", "x", 1) is "axbc", then shouldn't
> > "abbc".replace("b", "x", -1) be "abxc" (i.e. negative
> > numbers replace the *last* occurrences of the value)?
> > Same argument for "split", etc.

> Guido van Rossum:
> Dubious hypergeneralization.

Greg Wilson:
Do you have an editor macro set up yet to generate that
phrase? :-)

> Guido van Rossum:
> The thing is that this parameter,
> called maxsplit, is not really an index -- it's a count.

Greg Wilson:
Understood; I'm asking whether changing its name and
interpretation (in a way that doesn't break any existing
code) would be worthwhile:

    >>> path = "/some/long/path/to/file.html"
    >>> main, parent, file = path.split("/", -2)
    >>> main
    "/some/long/path"
    >>> parent
    "to"
    >>> file
    "file.html"

> > Greg Wilson:
> > Turns out that "abbc".replace("b", "x", -1) is "axxc"
> > (i.e. negative arguments are ignored).  I would have
> > expected this to raise a ValueError, if anything.  Is
> > there a reason for this behavior?

Greg Wilson again:
Question still stands --- if these are counts, then shouldn't
negative values raise exceptions?

Thanks,
Greg



From guido at digicool.com  Sat Apr 21 00:19:50 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 17:19:50 -0500
Subject: [Python-Dev] re: string slicing and method consistency
In-Reply-To: Your message of "Fri, 20 Apr 2001 17:08:31 -0400."
             <930BBCA4CEBBD411BE6500508BB3328F22D1F5@nsamcanms1.ca.baltimore.com> 
References: <930BBCA4CEBBD411BE6500508BB3328F22D1F5@nsamcanms1.ca.baltimore.com> 
Message-ID: <200104202219.RAA14666@cj20424-a.reston1.va.home.com>

> > Guido van Rossum:
> > Dubious hypergeneralization.
> 
> Greg Wilson:
> Do you have an editor macro set up yet to generate that
> phrase? :-)

No, I actually know how to spell that. :-)

> Greg Wilson:
> Understood; I'm asking whether changing its name and
> interpretation (in a way that doesn't break any existing
> code) would be worthwhile:
> 
>     >>> path = "/some/long/path/to/file.html"
>     >>> main, parent, file = path.split("/", -2)
>     >>> main
>     "/some/long/path"
>     >>> parent
>     "to"
>     >>> file
>     "file.html"

OK, that's an example.  It's only so-so, because you should be using
os.path.split() anyway.  It's done best as follows:

  temp, file = os.path.split(path)
  main, parent = os.path.split(temp)

> > > Greg Wilson:
> > > Turns out that "abbc".replace("b", "x", -1) is "axxc"
> > > (i.e. negative arguments are ignored).  I would have
> > > expected this to raise a ValueError, if anything.  Is
> > > there a reason for this behavior?
> 
> Greg Wilson again:
> Question still stands --- if these are counts, then shouldn't
> negative values raise exceptions?

Given that it's documented with the name "maxsplit", it's not
unreasonable that -1 is treated the same as 0.

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



From donb at abinitio.com  Fri Apr 20 23:19:56 2001
From: donb at abinitio.com (Donald Beaudry)
Date: Fri, 20 Apr 2001 17:19:56 -0400
Subject: [Python-Dev] Class Methods 
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook><200104201626.LAA06384@cj20424-a.reston1.va.home.com> <15072.25994.247806.815084@anthem.wooz.org> <055101c0c9d3$4a1b9d20$e000a8c0@thomasnotebook>
Message-ID: <200104202119.RAA08382@localhost.localdomain>

"Thomas Heller" <thomas.heller at ion-tof.com> wrote,
> > >>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:
> > 
> >     GvR> Let x be an object, C its class, and M C's class.  So,
> > 
> >     |   x.__class__ is C
> >     |   C.__class__ is M
> > 
> >     GvR> Then x's methods are described in C.__dict__, and C's methods
> >     GvR> are described in M.__dict__.
> > 
> >     GvR> The problem is that if you write C.spam, there could be two
> >     GvR> spams: one in C.__dict__, one in M.__dict__.  Which one to
> >     GvR> use?

In my 'objectmodule' I adopted a concept which I refer to as the
"unbound instance".  That is, I invented an object which is used as a
proxy for accessing instance attributes.  It looks like an instance
but only for the purposes of attribute access.  Now, since this object
will only return "unbound method objects" when accessing a method (as
opposed to the "bound method object" you would get when accessing a
method from a real instance) I thought the name was at least slightly
appropriate.  In short, each class defined by the objectmodule has a
special attribute '_' which is the "unbound instance" for that class.
This unbound instance is used to resolve the name ambiguity.  Now,
consider this:

    import object

    class foo(object.base):
        def frob(self):
            print "I've been frobbed", self

        class __class__:
            def frob(cl):
                print "No, I've been frobbed", cl


    >>> f = foo()
    >>> x = f.frob
    >>> # x is the instance frob method bound to f
    >>> y = foo.frob
    >>> # y is the class frob method bound to foo
    >>> z = foo._.frob
    >>> # z is the instance frob method but is not bound to any instance
    >>> huh = foo.__class__._.frob
    >>> # huh is the class frob method but is not bound to any class
    >>>        

> Thin ice again I'm on here (even more), but I have the impression
> that creating a class Point in Smalltalk _automatically_ creates two
> classes: Point and PointClass. The latter is normally hidden (but
> contains the class methods of Point as instance methods).

That's the way I remember it too.  And, (if I recall correctly) in
SmallTalk (unlike CLOS), you have no control over the meta-class.  In
the example above, like in SmallTalk, the name of foo.__class__ is
determined automatically.  In this case it is 'foo_class'.  However,
unlike SmallTalk, the above example could be extended to include a
'class __class__:' definition under the existing 'class __class__:'.
The name generated by this construct would, of course, be
'foo_class_class'.  Lather, Rinse, repeat...

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb at init.com                                      Lexington, MA 02421
                      ...Will hack for sushi...



From moshez at zadka.site.co.il  Sat Apr 21 02:32:57 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Sat, 21 Apr 2001 03:32:57 +0300
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
References: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>, <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
Message-ID: <E14qlKb-0005G4-00@darjeeling>

On Fri, 20 Apr 2001 11:26:01 -0500, Guido van Rossum <guido at digicool.com> wrote:
 
> For regular methods it may be possible to avoid this simply by
> choosing non-conflicting names, but I seem to recall that Jim wanted
> to use class methods with certain special names (like __init__ or
> __getattr__?), and I have no idea how to do this without dropping the
> idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
> solution?

class A:

    def __init__(self):
        self.spam = 1

class B:

    def __init__(self):
        A.__init__(self)
        self.eggs = 2

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From Jason.Tishler at dothill.com  Sat Apr 21 02:50:58 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Fri, 20 Apr 2001 20:50:58 -0400
Subject: [Python-Dev] Re: Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <Pine.LNX.4.21.0104201933470.11150-100000@clarkevans.com>; from cce@clarkevans.com on Fri, Apr 20, 2001 at 07:37:01PM -0500
References: <20010417151219.T275@dothill.com> <Pine.LNX.4.21.0104201933470.11150-100000@clarkevans.com>
Message-ID: <20010420205058.A1403@dothill.com>

On Fri, Apr 20, 2001 at 07:37:01PM -0500, Clark C. Evans wrote:
> On Tue, 17 Apr 2001, Jason Tishler wrote:
> > I have contributed Python to the standard Cygwin distribution.  Cygwin
> > Python is located in the contrib/python directory on the Cygwin mirrors.
> > Cygwin's setup.exe will automatically install Cygwin Python the next
> > time one installs or updates from a mirror.
> 
> This is interesting.  From what I understand, if you link
> against cygwin.dll, the software must be released under
> the GPL.  Thus, is the licensing debate over?  Do you
> have the right to re-license python under the GPL? Or am
> I missing something fundmental here? 
> 
> $ objdump -p python2.1.exe | grep DLL
>  vma:            Hint    Time      Forward  DLL       First
>         DLL Name: KERNEL32.dll
>         DLL Name: cygwin1.dll
>         DLL Name: libpython2.1.dll
> 
> Sorry to bring this up... I'm just curious.

Clark brings up a valid point.  Did I screw up from a licensing point
of view?

I found the following on the Python web site:

    However, we expect that Python 2.0 and later versions, released by
    BeOpen PythonLabs, will be released under a GPL-compatible license.

IANAL, any guidance regarding this matter would be greatly appreciated.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From tim.one at home.com  Sat Apr 21 03:32:05 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 20 Apr 2001 21:32:05 -0400
Subject: [Python-Dev] Re: Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <20010420205058.A1403@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOELBJNAA.tim.one@home.com>

[Clark C. Evans]
> This is interesting.  From what I understand, if you link
> against cygwin.dll, the software must be released under
> the GPL.  Thus, is the licensing debate over?  Do you
> have the right to re-license python under the GPL? Or am
> I missing something fundmental here?

[Jason Tishler]
> Clark brings up a valid point.  Did I screw up from a licensing point
> of view?
>
> I found the following on the Python web site:
>
>   However, we expect that Python 2.0 and later versions, released
>   by BeOpen PythonLabs, will be released under a GPL-compatible
>   license.

According to CNRI's and BeOpen's lawyers, it was; according to the FSF's Eben
Moglen, it was not.

> IANAL,

Ditto, and I'm worn out trying to divine the FSF's position.  Since you're in
no danger of violating *our* license, I'm afraid we're the wrong people to
ask.  If you can get a straight answer out of the FSF, more power to you.

> any guidance regarding this matter would be greatly appreciated.

In this specific case, you may be able to cut it short:

    http://www.cygwin.com/licensing.html

According to that, they use the GPL, but ammend it according to GPL section
10:

    In accordance with section 10 of the GPL, Cygnus permits
    programs whose sources are distributed under a license that
    complies with the Open Source definition to be linked with
    libcygwin.a without libcygwin.a itself causing the resulting
    program to be covered by the GNU GPL.

    This means that you can port an Open Source(tm) application
    to cygwin, and distribute that executable as if it didn't
    include a copy of libcygwin.a linked into it. Note that this
    does not apply to the cygwin DLL itself. If you distribute a
    (possibly modified) version of the DLL you must adhere to the
    terms of the GPL, i.e., you must provide sources for the cygwin
    DLL.

There's no controversy over whether all Python licenses to date are Open
Source -- they are.  There's also no problem from the POV of the *Python*
license if you want to relicense Cygwin Python under the GPL.  Fine by us!
The only relevant party with a complaint against you *may* be the FSF.





From tim.one at home.com  Sat Apr 21 09:51:09 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 21 Apr 2001 03:51:09 -0400
Subject: [Python-Dev] Importing DLLs on Windows
In-Reply-To: <3ADE1A5F.F574B613@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMAJNAA.tim.one@home.com>

Sorry for the delay -- I had a hard time understanding what this writeup
meant, so had to download the package and try it.

[M.-A. Lemburg]
> Python or Windows seems to have trouble importing DLLs when
> inside packages. I'm working on an extension which pulls in a
> DLL gmp31.dll which lives inside a package dir mx/Number/mxNumber
> along side the Python wrapper extension mxNumber.pyd.

Concretely, I have these files now, under my Python 2.1 installation
directory:

C:\Python21>dir/b/on mx\Number\mxNumber
gmp31.dll
mxNumber.pyd
mxNumber.h
test.py
__init__.py

C:\Python21>

> Currently, I'm using this code in the subpackage's __init__.py:

And by "the subpackage" here I believe you mean the tail-end mxNumber
directory, previously called "a package".  IOW, you're talking specifically
about

    \Python21\mx\Number\mxNumber\__init__.py

If you meant something else, scream.

> # On Windows we also distribute the GMP DLL (in the win32 subdir). To
> # have Win32 find the DLL we need to be explicit about the path in
> # sys.path though. This trick works for all startup directories
> # *except* \PythonXX (for some reason this fails), but is not thread
> # safe...
> import sys, os
> if sys.platform[:3] == 'win':
>     abspath = os.path.abspath(__path__[0])
>     sys.path.insert(0, abspath)
>     from mxNumber import *
>     sys.path.remove(abspath)
>
> else:
>     from mxNumber import *

> I don't have any clue why the import works

Which import are you talking about?  Please show exactly what you do that
fails -- I haven't been able to find any problem here.  For example, I
replaced

    \Python21\mx\Number\mxNumber\__init__.py

which contains the code you showed above, with this two-liner:

from mxNumber import *
from mxNumber import __version__

Having done that, here's a shell session started in the installation
directory, and after a reboot "just to make sure":

C:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> from mx.Number import *
>>> Integer(928349238479328749L)**2
861832308585149602001042573617905001
>>>

So nothing failed.  What do *you* do that fails?  Here's another session
started from a "random" directory:

C:\Code>\python21\python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> from mx.Number import *
>>> Integer(92387498327493243879L)**2
8535449847212566935021074270390170966641
>>>

Same thing.

> from everywhere *except* the Python21 install directory...

It would more helpful to name a specific directory than to make an untrue
claim <wink -- but you didn't try every directory other than Python21, and
the specific directories you actually did try may be important>.

BTW, it's a mondo cool package!  I had a lot of fun with it.  But then I was
able to, since I stopped trying to guess what your problem was <wink>.
What's up?  I was running Win98SE in the above, but that shouldn't make a
difference.  Perhaps, during development, you left crap sitting around in
your installation directory that's confusing your attempts to import things?
If not, please be very explicit about what you do that fails, and what
"fails" means (crash, ImportError, Windows error box, ...?).




From tim.one at home.com  Sat Apr 21 11:51:42 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 21 Apr 2001 05:51:42 -0400
Subject: [Python-Dev] Suirprise!
Message-ID: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com>

I just stared at this a long time:

>>> 'a' in 'a'  # fine
1
>>> 'a' in 'a' == 1  # what?
0
>>> 'a' in 'b'  # fine
0
>>> 'a' in 'b' == 0  # what?
0
>>>

It's "correct".  I've been using Python longer than Guido <wink>, and I'm
amazed this is the first time I got bit by this!  Here's a hint:

>>> 'a' in 'a' == 'a'
1
>>>

thank-god-for-dis.dis-ly y'rs  - tim




From martin at loewis.home.cs.tu-berlin.de  Sat Apr 21 11:51:56 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 21 Apr 2001 11:51:56 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
Message-ID: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de>

Currently, a number of routines assume that the result of
PyUnicode_FromUnicode can be modified, i.e. they mutate the resulting
unicode object. Look at unicodeobject.c:fixup for an example, and
assume that fixfct is fixtitle (*).

This is different from PyString_FromStringAndSize, whose result can be
only modified if the str argument is NULL.

These routines broke after I applied my caching patch, since now
PyUnicode_FromUnicode may return an existing string.

Is that difference intentional? My feeling is that it is an error to
modify a unicode object, unless it is known not to be initialized.

Regards,
Martin

P.S. This was actually the first failure case when running
test_unicodedata under my patch.



From mal at lemburg.com  Sat Apr 21 12:35:00 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 12:35:00 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEMAJNAA.tim.one@home.com>
Message-ID: <3AE16254.FFE9ADF7@lemburg.com>

Tim Peters wrote:
> 
> Sorry for the delay -- I had a hard time understanding what this writeup
> meant, so had to download the package and try it.

Oh, sorry that I wasn't clear enough. Referring to the mxNumber
package, I am seeing this situation:

# This works... (note the start directory)

C:\WINDOWS>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>

# This doesn't.... (from the Python install directory)

D:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "d:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "d:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
    from mxNumber import *
ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser Anwendung notwen
dige Bibliothekdateien kann nicht gefunden werden.
>>>

# OTOH, this works.... (one level below the Python install directory)

D:\Python21>cd mx

D:\Python21\mx>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>>
 
> [M.-A. Lemburg]
> > Python or Windows seems to have trouble importing DLLs when
> > inside packages. I'm working on an extension which pulls in a
> > DLL gmp31.dll which lives inside a package dir mx/Number/mxNumber
> > along side the Python wrapper extension mxNumber.pyd.
> 
> Concretely, I have these files now, under my Python 2.1 installation
> directory:
> 
> C:\Python21>dir/b/on mx\Number\mxNumber
> gmp31.dll
> mxNumber.pyd
> mxNumber.h
> test.py
> __init__.py
> 
> C:\Python21>
> 
> > Currently, I'm using this code in the subpackage's __init__.py:
> 
> And by "the subpackage" here I believe you mean the tail-end mxNumber
> directory, previously called "a package".  IOW, you're talking specifically
> about
> 
>     \Python21\mx\Number\mxNumber\__init__.py

Right.
 
> If you meant something else, scream.
>
> > # On Windows we also distribute the GMP DLL (in the win32 subdir). To
> > # have Win32 find the DLL we need to be explicit about the path in
> > # sys.path though. This trick works for all startup directories
> > # *except* \PythonXX (for some reason this fails), but is not thread
> > # safe...
> > import sys, os
> > if sys.platform[:3] == 'win':
> >     abspath = os.path.abspath(__path__[0])
> >     sys.path.insert(0, abspath)
> >     from mxNumber import *
> >     sys.path.remove(abspath)
> >
> > else:
> >     from mxNumber import *
> 
> > I don't have any clue why the import works
> 
> Which import are you talking about?  Please show exactly what you do that
> fails -- I haven't been able to find any problem here.  For example, I
> replaced
> 
>     \Python21\mx\Number\mxNumber\__init__.py
> 
> which contains the code you showed above, with this two-liner:
> 
> from mxNumber import *
> from mxNumber import __version__
> 
> Having done that, here's a shell session started in the installation
> directory, and after a reboot "just to make sure":
> 
> C:\Python21>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> from mx.Number import *
> >>> Integer(928349238479328749L)**2
> 861832308585149602001042573617905001
> >>>
> 
> So nothing failed. 

Hmm, you are right, it does work for me too (I wonder why I
thought it failed without the sys.path tweaking... probably
just tested from the Python install dir):

C:\WINDOWS>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>
C:\WINDOWS>d:

D:\Python21\mx>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>
D:\Python21\mx>cd ..

D:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "d:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "d:\python21\mx\Number\mxNumber\__init__.py", line 11, in ?
    from mxNumber import *
ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser Anwendung notwen
dige Bibliothekdateien kann nicht gefunden werden.
>>>

> What do *you* do that fails?  Here's another session
> started from a "random" directory:
> 
> C:\Code>\python21\python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> from mx.Number import *
> >>> Integer(92387498327493243879L)**2
> 8535449847212566935021074270390170966641
> >>>
> 
> Same thing.
> 
> > from everywhere *except* the Python21 install directory...
> 
> It would more helpful to name a specific directory than to make an untrue
> claim <wink -- but you didn't try every directory other than Python21, and
> the specific directories you actually did try may be important>.

Ok, ok ;-)

Please try starting Python from your Python install dir and
then do the import. BTW, I'm doing this on Windows 95 in case
this matters (which I'm sure it does :-/).
 
> BTW, it's a mondo cool package!  I had a lot of fun with it. 

Thanks :)

> But then I was
> able to, since I stopped trying to guess what your problem was <wink>.
> What's up?  I was running Win98SE in the above, but that shouldn't make a
> difference.  Perhaps, during development, you left crap sitting around in
> your installation directory that's confusing your attempts to import things?
> If not, please be very explicit about what you do that fails, and what
> "fails" means (crash, ImportError, Windows error box, ...?).

"fail" means that Python cannot find the gmp31.dll sitting right
next to the mxNumber.pyd in the same directory. This should normally
work, but somehow doesn't when Python is started from the install
dir:

>>> import mx.Number
import mx # directory mx
# trying mx\__init__.pyd
# trying mx\__init__.dll
# trying mx\__init__.py
# mx\__init__.pyc matches mx\__init__.py
import mx # precompiled from mx\__init__.pyc
import mx.Number # directory mx\Number
# trying mx\Number\__init__.pyd
# trying mx\Number\__init__.dll
# trying mx\Number\__init__.py
# mx\Number\__init__.pyc matches mx\Number\__init__.py
import mx.Number # precompiled from mx\Number\__init__.pyc
# trying mx\Number\Number.pyd
# trying mx\Number\Number.dll
# trying mx\Number\Number.py
# mx\Number\Number.pyc matches mx\Number\Number.py
import mx.Number.Number # precompiled from mx\Number\Number.pyc
import mx.Number.mxNumber # directory mx\Number\mxNumber
# trying mx\Number\mxNumber\__init__.pyd
# trying mx\Number\mxNumber\__init__.dll
# trying mx\Number\mxNumber\__init__.py
# mx\Number\mxNumber\__init__.pyc matches mx\Number\mxNumber\__init__.py
import mx.Number.mxNumber # precompiled from mx\Number\mxNumber\__init__.pyc
# trying mx\Number\mxNumber\mxNumber.pyd
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "d:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "d:\python21\mx\Number\mxNumber\__init__.py", line 11, in ?
    from mxNumber import *
ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser Anwendung notwen
dige Bibliothekdateien kann nicht gefunden werden.
>>>


From guido at digicool.com  Sat Apr 21 13:42:09 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 21 Apr 2001 06:42:09 -0500
Subject: [Python-Dev] Suirprise!
In-Reply-To: Your message of "Sat, 21 Apr 2001 05:51:42 -0400."
             <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com> 
Message-ID: <200104211142.GAA17114@cj20424-a.reston1.va.home.com>

> I just stared at this a long time:
> 
> >>> 'a' in 'a'  # fine
> 1
> >>> 'a' in 'a' == 1  # what?
> 0
> >>> 'a' in 'b'  # fine
> 0
> >>> 'a' in 'b' == 0  # what?
> 0
> >>>
> 
> It's "correct".  I've been using Python longer than Guido <wink>, and I'm
> amazed this is the first time I got bit by this!  Here's a hint:
> 
> >>> 'a' in 'a' == 'a'
> 1
> >>>
> 
> thank-god-for-dis.dis-ly y'rs  - tim

Yeah, I ran into the same when converting some has_key() tests to
using 'in'.  I guess it's not very common since nobody in their right
minds should want to compare the result of an 'in' test to anything
else.  The has_key() tests did something like "assert d.has_key(k)==1"
and the mindless translation of that is "assert k in d == 1"...

Didn't-need-dis-though-ly y'rs,

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



From mal at lemburg.com  Sat Apr 21 12:43:10 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 12:43:10 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de>
Message-ID: <3AE1643E.28E41AC2@lemburg.com>

"Martin v. Loewis" wrote:
> 
> Currently, a number of routines assume that the result of
> PyUnicode_FromUnicode can be modified, i.e. they mutate the resulting
> unicode object. Look at unicodeobject.c:fixup for an example, and
> assume that fixfct is fixtitle (*).

This is true for the APIs in unicodeobject.c: as long as the newly
created object hasn't "left" the Unicode implementation, the APIs
in there are free to modify the otherwise immutable object.
 
> This is different from PyString_FromStringAndSize, whose result can be
> only modified if the str argument is NULL.
> 
> These routines broke after I applied my caching patch, since now
> PyUnicode_FromUnicode may return an existing string.
> 
> Is that difference intentional? My feeling is that it is an error to
> modify a unicode object, unless it is known not to be initialized.

It is an error, but only for code outside the implementation, i.e.
programs using the public API may only modify the contents when
calling PyUnicode_FromUnicode() with NULL as u argument.

Sorry for not remembering this when reviewing your patch on SF.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From paulp at ActiveState.com  Sat Apr 21 12:48:08 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Sat, 21 Apr 2001 03:48:08 -0700
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com>
Message-ID: <3AE16568.79763FDD@ActiveState.com>

Tim Peters wrote:
> 
>...
> 
> >>> 'a' in 'a' == 'a'
> 1
> >>>
> 
> thank-god-for-dis.dis-ly y'rs  - tim

[potential spoilers below]

No, thank Jeremy for Compiler:

Module(None, 
    Stmt(
        [
            Printnl(
                [
                    Compare(Const('a'), 
                        [
                            ('in', Const('abcde')), 
                            ('==', Const('abcde'))
                        ]
                    )
                ], 
                None
            )
        ]
    )
)

It still took a look at the ref manual for me to figure it out.

It looks like dubious hypergeneralization to me! <0.7 wink> Seriously,
does this "feature" ever make sense to apply to the in operator?

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From Jason.Tishler at dothill.com  Sat Apr 21 13:43:12 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Sat, 21 Apr 2001 07:43:12 -0400
Subject: [Python-Dev] Re: Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOELBJNAA.tim.one@home.com>; from tim.one@home.com on Fri, Apr 20, 2001 at 09:32:05PM -0400
References: <20010420205058.A1403@dothill.com> <LNBBLJKPBEHFEDALKOLCOELBJNAA.tim.one@home.com>
Message-ID: <20010421074312.B351@dothill.com>

Tim,

Thanks for your assessment of the situation.  I'm forwarding your
email to the Cygwin list to see what they have to say.  Your help is
much appreciated.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From martin at loewis.home.cs.tu-berlin.de  Sat Apr 21 14:07:14 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 21 Apr 2001 14:07:14 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
In-Reply-To: <3AE1643E.28E41AC2@lemburg.com> (mal@lemburg.com)
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com>
Message-ID: <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de>

> This is true for the APIs in unicodeobject.c: as long as the newly
> created object hasn't "left" the Unicode implementation, the APIs
> in there are free to modify the otherwise immutable object.

That means that PyUnicode_FromUnicode does give a guarantee to return
a fresh object, right?

Then I cannot understand why it only gives this guarantee to callers
inside unicodeobject.c, and not to other callers...

Regards,
Martin



From mal at lemburg.com  Sat Apr 21 15:15:00 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 15:15:00 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com> <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de>
Message-ID: <3AE187D4.FBF0AD3E@lemburg.com>

"Martin v. Loewis" wrote:
> 
> > This is true for the APIs in unicodeobject.c: as long as the newly
> > created object hasn't "left" the Unicode implementation, the APIs
> > in there are free to modify the otherwise immutable object.
> 
> That means that PyUnicode_FromUnicode does give a guarantee to return
> a fresh object, right?

Let's put it this way: the internals in unicodeobject.c are
allowed to modify the contents of the object even if it was
prefilled with data that came from an initializer. External
caller are not allowed to do this though unless u is set to
NULL (just like in the corresponding string call).
 
> Then I cannot understand why it only gives this guarantee to callers
> inside unicodeobject.c, and not to other callers...

Because I want to reserve the right to change the semantics
*inside* unicodeobject.c at some later point. Note that currently
no caching of Unicode objects takes place, but this could change
in the future and indeed your patch starts into this direction.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From martin at loewis.home.cs.tu-berlin.de  Sat Apr 21 15:25:45 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 21 Apr 2001 15:25:45 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
In-Reply-To: <3AE187D4.FBF0AD3E@lemburg.com> (mal@lemburg.com)
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com> <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de> <3AE187D4.FBF0AD3E@lemburg.com>
Message-ID: <200104211325.f3LDPjh16199@mira.informatik.hu-berlin.de>

> Because I want to reserve the right to change the semantics
> *inside* unicodeobject.c at some later point. Note that currently
> no caching of Unicode objects takes place, but this could change
> in the future and indeed your patch starts into this direction.

So would you accept a patch that corrects all calls to
PyUnicode_FromUnicode which modify the result they get, without having
passed a NULL str argument?

Regards,
Martin



From mal at lemburg.com  Sat Apr 21 15:37:53 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 15:37:53 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com> <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de> <3AE187D4.FBF0AD3E@lemburg.com> <200104211325.f3LDPjh16199@mira.informatik.hu-berlin.de>
Message-ID: <3AE18D31.FDA78CD4@lemburg.com>

"Martin v. Loewis" wrote:
> 
> > Because I want to reserve the right to change the semantics
> > *inside* unicodeobject.c at some later point. Note that currently
> > no caching of Unicode objects takes place, but this could change
> > in the future and indeed your patch starts into this direction.
> 
> So would you accept a patch that corrects all calls to
> PyUnicode_FromUnicode which modify the result they get, without having
> passed a NULL str argument?

Yes :)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From barry at digicool.com  Sat Apr 21 17:57:57 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Sat, 21 Apr 2001 11:57:57 -0400
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com>
Message-ID: <15073.44549.140970.32646@anthem.wooz.org>

>>>>> "TP" == Tim Peters <tim.one at home.com> writes:

    TP> It's "correct".  I've been using Python longer than Guido
    TP> <wink>, and I'm amazed this is the first time I got bit by
    TP> this!  Here's a hint:

Oh, that is twisted! :)

Let's throw in some parentheses just to confuse people even more:

>>> 'a' in 'a' == 'a'
1
>>> ('a' in 'a') == 'a'
0
>>> 'a' in ('a' == 'a')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in' or 'not in' needs sequence right argument
>>> 'a' in 'a' == 1
0
>>> ('a' in 'a') == 1
1
>>> 'a' in ('a' == 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in' or 'not in' needs sequence right argument

>>>>> "PP" == Paul Prescod <paulp at ActiveState.com> writes:

    PP> It looks like dubious hypergeneralization to me! <0.7 wink>
    PP> Seriously, does this "feature" ever make sense to apply to the
    PP> in operator?

I don't know; I wonder if "normal" people think of `in' as a chainable
comparison operator or not.  You're not suggesting to change this are
you?

gotta-leave-something-`in'-there-for-job-security-ly y'rs,
-Barry



From gmcm at hypernet.com  Sat Apr 21 19:25:15 2001
From: gmcm at hypernet.com (Gordon McMillan)
Date: Sat, 21 Apr 2001 13:25:15 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <15073.44549.140970.32646@anthem.wooz.org>
Message-ID: <3AE18A3B.24053.47CCB799@localhost>

> >>>>> "TP" == Tim Peters <tim.one at home.com> writes:
> 
>     TP> It's "correct".  I've been using Python longer than Guido
>     TP> <wink>, and I'm amazed this is the first time I got bit
>     by TP> this!  Here's a hint:

[Barry]
> Oh, that is twisted! :)
> 
> Let's throw in some parentheses just to confuse people even more:
...
> gotta-leave-something-`in'-there-for-job-security-ly y'rs,

You're safely employed for years:

>>> 'a' in 'abc' == 1
0
>>> 'a' in 'abc' == 'a'
0
>>> 'a' in 'abc' == 'a' in 'abc'
0

but-a-raise-is-out-of-the-question-ly y'rs

- Gordon



From tim.one at home.com  Sun Apr 22 00:56:30 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 21 Apr 2001 18:56:30 -0400
Subject: [Python-Dev] Iterators, generators and 2.2 (was RE: do...until wisdom needed...)
In-Reply-To: <slrn9e33tr.a5m.neelk@alum.mit.edu>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENMJNAA.tim.one@home.com>

[Aahz]
> Generators (called "iterators") are going to be 2.2.  They'll be
> more powerful that Icon's generators; it's not clear whether they'll
> be a full-fledged substitute for coroutines.

[Neelakantan Krishnaswami]
> {\mr_burns Excellent.}
>
> Is this the iterator idea that Ping posted about a couple of months
> back? What is the PEP number for this? I'm curious how the existing
> iteration protocol will interact with the new iterators.

This is getting confused.  Iterators != generators (sorry, Aahz! it's more
involved than that).

Aahz gave you the PEP number for iterators, and last night Guido checked an
initial implementation into the 2.2 CVS tree.  In Python terms, "for" setup
looks for an __iter__ method first, and if it doesn't find it but does find
__getitem__, builds a lightweight iterator around the __getitem__ method
instead.  So the "for" loop works only with iterators now, but there's an
adapter providing iterators by magic for old sequence objects that don't know
about iterators:

C:\Code\python\dist\src\PCbuild>python
Python 2.2a0 (#16, Apr 20 2001, 23:16:12) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> def f(s):
...     for i in s:
...         print i
...
>>> from dis import dis
>>> dis(f)
          0 SET_LINENO               1

          3 SET_LINENO               2
          6 SETUP_LOOP              25 (to 34)
          9 LOAD_FAST                0 (s)
         12 GET_ITER

    >>   13 SET_LINENO               2
         16 FOR_ITER                14
         19 STORE_FAST               1 (i)

         22 SET_LINENO               3
         25 LOAD_FAST                1 (i)
         28 PRINT_ITEM
         29 PRINT_NEWLINE
         30 JUMP_ABSOLUTE           13
         33 POP_BLOCK
    >>   34 LOAD_CONST               0 (None)
         37 RETURN_VALUE
>>>

The backward compatibility layer described above is hiding in the new
GET_ITER opcode.  Of course builtin lists (and so on) define the iterator
slot directly now, so GET_ITER simply returns their iterator directly.  Loops
are less complicated (internally) now, and run significantly faster.
User-defined types and classes no longer *need* to (ab)use __getitem__ to
implement iteration (which is of particular interest to Greg Wilson right
now, who is implementing a Set class and doesn't *want* to define __getitem__
because it's semantically senseless).

None of that should be controversial in the least.  More controversial is
that iteration over dict keys has been tentatively added (and note that this
is another thing made *possible* by breaking the old connection between
__getitem__ and iteration):

>>> dict = {"one": 1, "two": 2}
>>> for k in dict:
...     print k
...
one
two
>>>

This is significantly faster, and unboundedly more memory-efficient, than
doing "for k in dict.keys()".

The dict.__contains__ slot was also filled in, so that "k in dict" is
synonymous with "dict.has_key(k)", but again runs significantly faster:

>>> "one" in dict
1
>>> "three" in dict
0
>>>

File objects have also grown iterators, so that, e.g.,

    for line in sys.stdin:
        print line

now works.

Iterators can be explicitly materialized too, via the new iter() builltin
function, and invoked apart from the "for" protocol:

>>> i1 = iter(dict)
>>> i1
<dictionary-iterator object at 0079A250>
>>> dir(i1)
['next']
>>> print i1.next.__doc__
it.next() -- get the next value, or raise StopIteration
>>> i2 = iter(dict)
>>> i1.next()
'one'
>>> i2.next()
'one'
>>> i1.next()
'two'
>>> i2.next()
'two'
>>> i1.next()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
StopIteration
>>>

Note that this allows a simple memory-efficient implementation of parallel
sequence iteration too.  For example, this program:

class zipiter:
    def __init__(self, seq1, *moreseqs):
        seqs = [seq1]
        seqs.extend(list(moreseqs))
        self.seqs = seqs

    def __iter__(self):
        self.iters = [iter(seq) for seq in self.seqs]
        return self

    def next(self):
        return [i.next() for i in self.iters]

for i, j, k in zipiter([1, 2, 3], "abc", (5., 6., 7., 8.)):
    print i, j, k

prints

1 a 5.0
2 b 6.0
3 c 7.0


Now all that is just iteration in a thoroughly conventional sense.  There is
no support here for generators or coroutines or microthreads, except in the
sense that breaking the iteration==__getitem__ connection makes it easier to
think about *how* generators may be implemented, and having an explicit
iterator object "should" make it possible to go beyond Icon's notion of
generators (which can only be driven implicitly by control context).

Neil Schemenauer is currently thinking hard about that "in his spare time",
but there's no guarantee anything will come of it in 2.2.  Iterators are a
sure thing, though (not least because they're already implemented!).

not-only-implemented-but-feel-exactly-right-ly y'rs  - tim




From fdrake at beowolf.digicool.com  Sun Apr 22 08:08:22 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Sun, 22 Apr 2001 02:08:22 -0400 (EDT)
Subject: [Python-Dev] [maintenance doc updates]
Message-ID: <20010422060822.A3E4428A0B@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/maint-docs/

First attempt to push maintenance docs to the SourceForge site.




From fdrake at beowolf.digicool.com  Sun Apr 22 08:12:15 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Sun, 22 Apr 2001 02:12:15 -0400 (EDT)
Subject: [Python-Dev] [maintenance doc updates]
Message-ID: <20010422061215.5C87D28A0B@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/maint-docs/

Second attempt to push maintenance docs to the SourceForge site.




From fdrake at beowolf.digicool.com  Sun Apr 22 08:15:52 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Sun, 22 Apr 2001 02:15:52 -0400 (EDT)
Subject: [Python-Dev] [maintenance doc updates]
Message-ID: <20010422061552.5A99628A0B@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/maint-docs/

Third attempt to push maintenance docs to the SourceForge site.

Sheesh!




From Greg.Wilson at baltimore.com  Sun Apr 22 14:19:22 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Sun, 22 Apr 2001 08:19:22 -0400
Subject: [Python-Dev] re: string slicing and method consistency
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D21B@nsamcanms1.ca.baltimore.com>

> > > Greg Wilson:
> > > if "abbc"[-1] is "c", and if
> > > "abbc".replace("b", "x", 1) is "axbc", then shouldn't
> > > "abbc".replace("b", "x", -1) be "abxc" (i.e. negative
> > > numbers replace the *last* occurrences of the value)?
> > > Same argument for "split", etc.
> >     >>> path = "/some/long/path/to/file.html"
> >     >>> main, parent, file = path.split("/", -2)
> >     >>> main
> >     "/some/long/path"
> >     >>> parent
> >     "to"
> >     >>> file
> >     "file.html"

> > Guido van Rossum:
> OK, that's an example.  It's only so-so, because you should be using
> os.path.split() anyway.  It's done best as follows:
> 
>   temp, file = os.path.split(path)
>   main, parent = os.path.split(temp)

Greg Wilson:
Or "main, parent, file = os.path.split(path, -2)" :-)

> > Greg Wilson again:
> > Question still stands --- if these are counts, then shouldn't
> > negative values raise exceptions?
> 
> Given that it's documented with the name "maxsplit", it's not
> unreasonable that -1 is treated the same as 0.

Greg Wilson:
But it isn't:

>>> print sys.version
2.2a0 (#2, Apr 20 2001, 12:53:03)
[GCC 2.95.2 19991024 (release)]
>>> "abbc".replace("b", "x", 0)
'abbc'
>>> "abbc".replace("b", "x", -1)
'axxc'

Thanks,
Greg



From tim.one at home.com  Mon Apr 23 01:19:19 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 22 Apr 2001 19:19:19 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <200104211142.GAA17114@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEACJOAA.tim.one@home.com>

[Tim, 'a' in 'a' == 1, etc]

[Guido]
> Yeah, I ran into the same when converting some has_key() tests to
> using 'in'.

Bingo!  Same here, but after adding __iter__ and __contains__ to UserDict.py,
then fiddling test_userdict.py to match.

> I guess it's not very common since nobody in their right minds should
> want to compare the result of an 'in' test to anything else.  The
> has_key() tests did something like "assert d.has_key(k)==1"
> and the mindless translation of that is "assert k in d == 1"...

You'd think so <wink>.  It was subtler in the first I bumped into,
translating something like

    assert d1.has_key(k) == d2.has_key(k)

The problem in

    assert k in d1 == k in d2

is, I think, harder to spot.  That is, you may well be in your right might if
you want to compare the result of an 'in' test to the result of *another*
'in' test!

Even stranger,

    assert k in d1 != k in d2

succeeds if and only if k is in both d1 and d2 (assuming d1 is a dict and k
isn't).  I'm going to use that a lot in my code, because it's one less
character than typing

    assert k in d1 and k in d2

Heh heh.

*something*-about-this-may-not-be-ideal-ly y'rs  - tim




From paulp at ActiveState.com  Mon Apr 23 01:52:43 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Sun, 22 Apr 2001 16:52:43 -0700
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com> <15073.44549.140970.32646@anthem.wooz.org>
Message-ID: <3AE36ECB.EABBCF46@ActiveState.com>

"Barry A. Warsaw" wrote:
> 
>...
> >>>>> "PP" == Paul Prescod <paulp at ActiveState.com> writes:
> 
>     PP> It looks like dubious hypergeneralization to me! <0.7 wink>
>     PP> Seriously, does this "feature" ever make sense to apply to the
>     PP> in operator?
> 
> I don't know; I wonder if "normal" people think of `in' as a chainable
> comparison operator or not.  

If Tim, Guido, you and I are so completely out of sync with normal
people that they will immediately intuit what we had to think hard
about, we're in deep doo-doo!

> You're not suggesting to change this are
> you?

I suggest a compile-time warning and then eventually we would make "in"
non-chainable. Perhaps it should even have a different precedence than
the other comparison operators. Tim's example looks reasonable to me:

assert k in d1 == k in d2

And it would never, ever make sense to say:

assert k in (d1==k) in d2

So why not interpret it the way that any normal human would:

assert (k in d1) == (k in d2)

I think that this is a subtle flaw in Python that just took a long time
to manifest itself...

And what about "1 is None == 2 is None"? If you saw that in a program
(last week!) what would you have expected it to evalute to? Precedence
levels exist to make code easier to read!
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From tim.one at home.com  Mon Apr 23 02:11:51 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 22 Apr 2001 20:11:51 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <3AE36ECB.EABBCF46@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEAEJOAA.tim.one@home.com>

[Paul Prescod]
> If Tim, Guido, you and I are so completely out of sync with normal
> people that they will immediately intuit what we had to think hard
> about, we're in deep doo-doo!

Na, we're not, they are:  they're *never* gonna figure it out <wink>.

> I suggest a compile-time warning and then eventually we would make "in"
> non-chainable.

An incompatible language change would, I think, need to go thru the
__future__ (however spelled) business.

> Perhaps it should even have a different precedence than the other
> comparison operators. Tim's example looks reasonable to me:
>
> assert k in d1 == k in d2

It *used* to look reasonable to me too <wink>.

> And it would never, ever make sense to say:
>
> assert k in (d1==k) in d2

Thin ice, there.  __eq__ and __contains__ are both user-definable now, and
there is no limit to how perverse ex-APL'ers can get with this stuff.

> So why not interpret it the way that any normal human would:
>
> assert (k in d1) == (k in d2)

That sounds best to me, but may be too much a bother.  For example, it's not
a stretch at all anymore to believe that someone *is* using

    a in b in c

now deliberately for its

    (a in b) and (b in c)

meaning.  Perfectly natural if, e.g., you use __contains__ to implement an
"is subset of" relation.  If we have to keep chaining for "in", then having
two distinct levels of chaining operators is bound to harbor its own odd
corners.

    x == y in d

I have no idea what that *should* mean, but having gone thru recent related
pain I'm very clear now on what it *does* mean.

> I think that this is a subtle flaw in Python that just took a long time
> to manifest itself...

You can thank Digital Creations for that, too.  They're keeping Guido so busy
that he doesn't have enough time to cloud our minds anymore.  Makes you
wonder how many other surprises he's been hiding from us <wink>!




From paulp at ActiveState.com  Mon Apr 23 05:04:21 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Sun, 22 Apr 2001 20:04:21 -0700
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCOEAEJOAA.tim.one@home.com>
Message-ID: <3AE39BB5.3B2E276C@ActiveState.com>

Tim Peters wrote:
> 
>...
> 
> > I suggest a compile-time warning and then eventually we would make "in"
> > non-chainable.
> 
> An incompatible language change would, I think, need to go thru the
> __future__ (however spelled) business.

???

My understanding was that __future__ was a way of sneaking in a cool
feature earlier than it would have been possible to deploy it given
strict gradual evolution contraints. But disallowing confusing uses of
"in" is not a feature and nobody is in a big hurry to see it happen. I
wouldn't mind waiting a year or two until everyone has had a chance to
clean up their code.

> ...
> For example, it's not
> a stretch at all anymore to believe that someone *is* using
> 
>     a in b in c
> 
> now deliberately for its
> 
>     (a in b) and (b in c)
> 
> meaning.  Perfectly natural if, e.g., you use __contains__ to implement an
> "is subset of" relation.  

The following grammar would preserve it and outlaw confusing cases:

comparison: in_comparison | is_comparison | math_comparison
math_comparison: expr (math_comp_op expr)*
in_comparison: expr ('in' | 'not' 'in' expr)*
is_comparison: expr ('is' | 'is' 'not' expr)*
math_comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From greg at cosc.canterbury.ac.nz  Mon Apr 23 07:27:14 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 23 Apr 2001 17:27:14 +1200 (NZST)
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <200104230527.RAA14279@s454.cosc.canterbury.ac.nz>

Guido:

> The problem is that if you write C.spam, there could be two spams: one
> in C.__dict__, one in M.__dict__.  Which one to use?  How does
> Smalltalk resolve this?

The problem doesn't arise in Smalltalk, because method calls and
instance variable accesses are completely different things and are
handled by quite separate syntaxes and mechanisms.

Python creates problems for itself here by confusing instance
variables of the class with metadata about the instance's methods,
and keeping them both in the same namespace.

Thomas Heller <thomas.heller at ion-tof.com>:

> I'm walking on thin ice here (maybe I should better try it out),
> but IIRC Smalltalk requires to explicit:
> 
>     self class method;
> or
>     self method;

No, to call a class method in Smalltalk, you just send a message 
to the class itself rather than an instance. There's no difference
in the message sending syntax.

> Thin ice again I'm on here (even more), but I have the impression
> that creating a class Point in Smalltalk _automatically_ creates
> two classes: Point and PointClass. The latter is normally hidden
> (but contains the class methods of Point as instance methods).

Yes. You don't normally get a choice about what the metaclass is,
although no doubt you could reach under the covers and manually
construct your own metaclass and instantiate it if you wanted.

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



From greg at cosc.canterbury.ac.nz  Mon Apr 23 07:33:20 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 23 Apr 2001 17:33:20 +1200 (NZST)
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com>
Message-ID: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz>

Tim Peters <tim.one at home.com>:

> "class methods" in *this* thread
> is being used in a Smalltalk sense (because it's Thomas Heller's thread, and
> he made clear that he doesn't want C++-style class statics).

It sounds like he wants not just class methods, but to
unify classes and instances the way they are in Smalltalk.

That's not necessary *just* to get class methods. For
instance, suppose you could write

  class Foo:

    def ftang(class c, x, y, z);
      ...

where the 'class' keyword in the argument list would say
that it is to be a class method. That special form of the
def statement would create an 'unbound class method'
object, whose first argument would be filled in with the
class object when Foo.ftang was accessed.

Hmmm... might write a PEP on that!

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



From tim.one at home.com  Mon Apr 23 07:41:08 2001
From: tim.one at home.com (Tim Peters)
Date: Mon, 23 Apr 2001 01:41:08 -0400
Subject: [Python-Dev] Importing DLLs on Windows
In-Reply-To: <3AE16254.FFE9ADF7@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com>

[MAL]
> Oh, sorry that I wasn't clear enough.

Me neither (see below).

> Referring to the mxNumber package, I am seeing this situation:
>
> # This works... (note the start directory)
>
> C:\WINDOWS>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> >>> print mx.Number.Float(3.141)
> 3.14100000000000001421e+0
> >>>
>
> # This doesn't.... (from the Python install directory)
>
> D:\Python21>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "d:\python21\mx\Number\__init__.py", line 9, in ?
>     from Number import *
>   File "d:\python21\mx\Number\Number.py", line 11, in ?
>     from mxNumber import *
>   File "d:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
>     from mxNumber import *
> ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser
> Anwendung notwen dige Bibliothekdateien kann nicht gefunden werden.
> >>>

Well, there's your problem:  looks some German hackers got into your machine
and screwed up the OS <wink>.

Now let me clarify what I wrote before:  when I said I couldn't provoke a
problem, I meant ANY problem.  It didn't matter whether I used the
__init__.py you shipped, or used the two-liner I posted, and it didn't matter
whether I started Python 2.1 from the install directory or from C:\Code
(etc).  Nothing failed no matter what I tried.

The only thing I see different in what you did above is that your Python
install directory is on a different drive (D: instead of C:).  I only have
one drive here, so I can't do a good job of simulating that.  Best I can do
here is fake it via the DOS subst command:

K:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> from mx.Number import *
>>>

Still no problem.  What happens if you install Python onto your C: drive
instead?  And if that does work for you, is it because of the C: drive, or
because you left some old development work on your D: drive that's confusing
things?

Do you have confirmation of your problem from anyone else?  Or are you the
only one who has bumped into it?

> ...
> Please try starting Python from your Python install dir and
> then do the import.

I already had, in the last msg.  And again above.

> BTW, I'm doing this on Windows 95 in case this matters (which I'm
> sure it does :-/).

Possibly, but can't say.  We need more data.

BTW, do you understand what your code does <0.7 wink>?  That is, there are
packages, modules *and* DLLs with the same base name, and "import *"
everywhere.  I've always stayed so far away from import end cases that I have
no idea what the rules are supposed to be when you live on the edge.  That
may have something to do with this too, although I can't see how (although
since I don't know what the rules are, that's a guess too!).




From tim.one at home.com  Mon Apr 23 08:05:17 2001
From: tim.one at home.com (Tim Peters)
Date: Mon, 23 Apr 2001 02:05:17 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <3AE39BB5.3B2E276C@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEAPJOAA.tim.one@home.com>

>> An incompatible language change would, I think, need to go thru the
>> __future__ (however spelled) business.

[Paul]
> ???
>
> My understanding was that __future__ was a way of sneaking in a cool
> feature earlier than it would have been possible to deploy it given
> strict gradual evolution contraints.

That's not what PEP 236 says.  __future__ is about *incompatible* language
changes, period.  "Cool" has nothing to do with it.  If you're making
something illegal that used to work, that's an incompatible change, and
people get at least one release cycle in which it continues to work without
change but with warnings.  They can also ask for future behavior early via
using an explicit future-statement in the module.  Although in this case I
guess the "future behavior" is just to turn the wng msg into a SyntaxError,
in which case the __future__ machinery does seem like overkill.

> But disallowing confusing uses of "in" is not a feature

PEP 236 is about incompatible changes, not features.  It so happens that the
first use (nested scopes) was a new feature that *could* break old code, so
was both a new feature and an incompatible change.

> and nobody is in a big hurry to see it happen. I wouldn't mind
> waiting a year or two until everyone has had a chance to
> clean up their code.

I'd rather not nag people at all if this is the only time it's come up in a
decade <wink>.  We've all got too much to do.

> ...
> The following grammar would preserve it [chaining "in"] and outlaw
> confusing cases:
>
> comparison: in_comparison | is_comparison | math_comparison
> math_comparison: expr (math_comp_op expr)*
> in_comparison: expr ('in' | 'not' 'in' expr)*
> is_comparison: expr ('is' | 'is' 'not' expr)*
> math_comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='

Did you try that grammar?  I'm skeptical that it works, since at first glance
the comparison production appears to require arbitrary lookahead to determine
which xxx_comparison case obtains.  But if so, I'm sure it can be repaired.
Whether it *should* be is a different matter I'll leave to Guido to Pronounce
on.




From mal at lemburg.com  Mon Apr 23 10:48:17 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 23 Apr 2001 10:48:17 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com>
Message-ID: <3AE3EC50.3A850757@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > Oh, sorry that I wasn't clear enough.
> 
> Me neither (see below).
> 
> > Referring to the mxNumber package, I am seeing this situation:
> >
> > # This works... (note the start directory)
> >
> > C:\WINDOWS>python
> > Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> > Type "copyright", "credits" or "license" for more information.
> > >>> import mx.Number
> > >>> print mx.Number.Float(3.141)
> > 3.14100000000000001421e+0
> > >>>
> >
> > # This doesn't.... (from the Python install directory)
> >
> > D:\Python21>python
> > Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> > Type "copyright", "credits" or "license" for more information.
> > >>> import mx.Number
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> >   File "d:\python21\mx\Number\__init__.py", line 9, in ?
> >     from Number import *
> >   File "d:\python21\mx\Number\Number.py", line 11, in ?
> >     from mxNumber import *
> >   File "d:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
> >     from mxNumber import *
> > ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser
> > Anwendung notwen dige Bibliothekdateien kann nicht gefunden werden.
> > >>>
> 
> Well, there's your problem:  looks some German hackers got into your machine
> and screwed up the OS <wink>.

Could be...
 
> Now let me clarify what I wrote before:  when I said I couldn't provoke a
> problem, I meant ANY problem.  It didn't matter whether I used the
> __init__.py you shipped, or used the two-liner I posted, and it didn't matter
> whether I started Python 2.1 from the install directory or from C:\Code
> (etc).  Nothing failed no matter what I tried.

OK. I tried the same on a Win98 box with a fresh Python and
mxNumber install -- and found no problems either; which leaves
me rather clueless about where the failures on my Win95 box 
originate. 

Could someone else with a Win95 box perhaps test this ?

Thanks anyway for hanging on,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From thomas.heller at ion-tof.com  Mon Apr 23 10:58:56 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Mon, 23 Apr 2001 10:58:56 +0200
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
References: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz>
Message-ID: <02a701c0cbd3$a21f9290$e000a8c0@thomasnotebook>

> Tim Peters <tim.one at home.com>:
> 
> > "class methods" in *this* thread
> > is being used in a Smalltalk sense (because it's Thomas Heller's thread, and
> > he made clear that he doesn't want C++-style class statics).

Well, I shouldn't have talked about C++ static methods, because
I'm not too familiar with them.

Here's what I want:

Assume C is a class with a class-method mth,
and D is 'class D(C): pass'.

C.mth() should call this method, which in turn (automatically)
receives C itself as the first parameter.
D.mth() should call this method, which in turn (automatically)
receives D itself as the first parameter.

> 
> It sounds like he wants not just class methods, but to
> unify classes and instances the way they are in Smalltalk.

The metaclass approach is one solution, not neccessarily
the best.
> 
> That's not necessary *just* to get class methods. For
> instance, suppose you could write
> 
>   class Foo:
> 
>     def ftang(class c, x, y, z);
>       ...
> 
> where the 'class' keyword in the argument list would say
> that it is to be a class method. That special form of the
> def statement would create an 'unbound class method'
> object, whose first argument would be filled in with the
> class object when Foo.ftang was accessed.

Donald Beaudry's objectmodule uses the metaclass hook to provide
class methods. I like the resulting syntax very much: He uses an
'inner class' with the special name '__class__' to specify class
methods:

class Object(object.base):
    class __class__:
        def class_method(self):
            pass
    def normal_method(self):
        pass

If I understand correctly (objectmodule does not run under
1.5.2 or later), an instance of __class__ will become
the metaclass of Object, and __class__'s methods will
become class methods of Object.

I've played a little bit with metaclasses in pure python
(it is faster this way), and have an implementation with the
same syntax where __class__ is never instantiated, and simply
acts as a function container.

Addendum: Additionaly to class methods, I would like to
have 'magic' class methods, maybe named __class_init__
and __class_getattr__. Easy to guess what they should do...

> 
> Hmmm... might write a PEP on that!
> 
Me too.


Thomas




From jack at oratrix.nl  Mon Apr 23 11:16:44 2001
From: jack at oratrix.nl (Jack Jansen)
Date: Mon, 23 Apr 2001 11:16:44 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
In-Reply-To: Message by "Tim Peters" <tim.one@home.com> ,
	     Thu, 12 Apr 2001 21:00:08 -0400 , <LNBBLJKPBEHFEDALKOLCAENKJLAA.tim.one@home.com> 
Message-ID: <20010423091644.AB453312BA0@snelboot.oratrix.nl>

> [Steven D. Majewski]
> > Has anybody looked at sfio ?
> > ...
> > http://www.research.att.com/sw/tools/sfio/
> 
> Did just now.  Only runs on Unix boxes, so would be a heavyweight way to
> solve line-end problems across platforms that don't have any <wink>.

But purely by chance I know that Matthias Neeracher, who has written the GUSI 
unix-emulation package that MacPython uses to do socket IO and select and 
such, is an SFIO fan, and there's all sorts of hooks in GUSI to allow use of 
SFIO. So I think that there's a good chance that sfio is okay for MacPython.

I've just dug out the 1991 usenix article, I'll read through it shortly.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 





From thomas at xs4all.net  Mon Apr 23 13:09:02 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Mon, 23 Apr 2001 13:09:02 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/ref ref3.tex,1.64,1.65 ref5.tex,1.43,1.44
In-Reply-To: <15072.27417.366789.977575@slothrop.digicool.com>; from jeremy@digicool.com on Fri, Apr 20, 2001 at 01:00:09PM -0400
References: <E14qe7G-0002AU-00@usw-pr-cvs1.sourceforge.net> <15072.27417.366789.977575@slothrop.digicool.com>
Message-ID: <20010423130902.A16486@xs4all.nl>

On Fri, Apr 20, 2001 at 01:00:09PM -0400, Jeremy Hylton wrote:
> >>>>> "GvR" == Guido van Rossum <gvanrossum at users.sourceforge.net> writes:

>   GvR> Log Message: Implement, test and document "key in dict" and
>   GvR> "key not in dict".

>   GvR> I know some people don't like this -- if it's really
>   GvR> controversial, I'll take it out again.  (If it's only Alex
>   GvR> Martelli who doesn't like it, that doesn't count as "real
>   GvR> controversial" though. :-)

> I don't like it either, because it's only clear when it's spelled "for
> key in dict".  It's pretty confusing when it's spelled "for val in
> dict" or even "for x in dict".

> But I'm willing to give it a try for a while.

Same here (don't like right now, can live with it even though my own
experiments w/ innocent colleagues lead me to believe it's not the best
thing to do ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Mon Apr 23 14:28:52 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Mon, 23 Apr 2001 14:28:52 +0200
Subject: [Python-Dev] Suirprise!
In-Reply-To: <3AE39BB5.3B2E276C@ActiveState.com>; from paulp@ActiveState.com on Sun, Apr 22, 2001 at 08:04:21PM -0700
References: <LNBBLJKPBEHFEDALKOLCOEAEJOAA.tim.one@home.com> <3AE39BB5.3B2E276C@ActiveState.com>
Message-ID: <20010423142852.B16486@xs4all.nl>

On Sun, Apr 22, 2001 at 08:04:21PM -0700, Paul Prescod wrote:

> The following grammar would preserve it and outlaw confusing cases:

> comparison: in_comparison | is_comparison | math_comparison
> math_comparison: expr (math_comp_op expr)*
> in_comparison: expr ('in' | 'not' 'in' expr)*
> is_comparison: expr ('is' | 'is' 'not' expr)*
> math_comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='

Won't work. Python's parser can't handle it. I also don't think the grammar
really matters that much -- it's the compiler that does the actual chaining,
it could decide not to chain and force a specific order, if it really wanted
to. And generate warnings and all that :)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From fdrake at acm.org  Mon Apr 23 14:40:44 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 23 Apr 2001 08:40:44 -0400 (EDT)
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
In-Reply-To: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz>
References: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com>
	<200104230533.RAA14282@s454.cosc.canterbury.ac.nz>
Message-ID: <15076.8908.65608.249318@cj42289-a.reston1.va.home.com>

Greg Ewing writes:
 >   class Foo:
 > 
 >     def ftang(class c, x, y, z);
 >       ...

  I like this syntax better that the others.  While it requires that a
single namespace is used for class and normal methods, I think that is
a good thing -- we don't *want* overlapping sets of names!


  -Fred

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




From thomas at xs4all.net  Mon Apr 23 14:44:40 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Mon, 23 Apr 2001 14:44:40 +0200
Subject: [Python-Dev] keyword-only arguments (was Re: string slicing and method consistency)
In-Reply-To: <200104202148.QAA13960@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Fri, Apr 20, 2001 at 04:48:06PM -0500
References: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com> <200104202148.QAA13960@cj20424-a.reston1.va.home.com>
Message-ID: <20010423144440.C16486@xs4all.nl>

On Fri, Apr 20, 2001 at 04:48:06PM -0500, Guido van Rossum wrote:
> [GVW]

> > Turns out that "abbc".replace("b", "x", -1) is "axxc"
> > (i.e. negative arguments are ignored).  I would have
> > expected this to raise a ValueError, if anything.  Is
> > there a reason for this behavior?  Is it worth making
> > replace, split, etc. interpret negative indices in the
> > same way as indexing does?
> 
> Dubious hypergeneralization.  The thing is that this parameter, called
> maxsplit, is not really an index -- it's a count.

Wouldn't it be nice if we could force particular arguments to be used as
keyword arguments only ? :) I remember this coming up a few times on
python-list, but I never quite understood why this isn't done. Syntax
doesn't seem too much of a problem ('def split(s, sep, **, maxsplit=0)'
comes to mind, and a new marker for PyArg_ParseTuple, like "**") and now
that we have warnings and __future__, we could phase it in even for oft-used
things such as string.split().

Even if it's deemed dubious hypergeneralization (look ma, no macro ;) it's
worth writing a PEP about, right ?

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas.heller at ion-tof.com  Mon Apr 23 15:04:37 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Mon, 23 Apr 2001 15:04:37 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com> <3AE3EC50.3A850757@lemburg.com>
Message-ID: <03ee01c0cbf5$f3963f30$e000a8c0@thomasnotebook>

I see the same Behaviour as Marc-Andre: Traceback in Win95 (running under VMWare,
running under Win2k).

C:\WINDOWS>\python21\python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>
>>>
>>>
>>> quit
'Use Ctrl-Z plus Return to exit.'
>>>
C:\WINDOWS>cd \python21

C:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "c:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "c:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
    from mxNumber import *
ImportError: DLL load failed: One of the library files needed to run this applic
ation cannot be found.
>>>
C:\Python21>ver

Windows 95. [Version 4.00.950]


C:\Python21>


Marc-Andre, what about other python versions?

Thomas




From guido at digicool.com  Mon Apr 23 16:36:44 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 23 Apr 2001 09:36:44 -0500
Subject: [Python-Dev] keyword-only arguments (was Re: string slicing and method consistency)
In-Reply-To: Your message of "Mon, 23 Apr 2001 14:44:40 +0200."
             <20010423144440.C16486@xs4all.nl> 
References: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com> <200104202148.QAA13960@cj20424-a.reston1.va.home.com>  
            <20010423144440.C16486@xs4all.nl> 
Message-ID: <200104231436.JAA00321@cj20424-a.reston1.va.home.com>

> Wouldn't it be nice if we could force particular arguments to be used as
> keyword arguments only ? :)

You could do this manually using **kwds (or its C equivalent), but it
gets ugly.

> I remember this coming up a few times on
> python-list, but I never quite understood why this isn't done. Syntax
> doesn't seem too much of a problem ('def split(s, sep, **, maxsplit=0)'
> comes to mind, and a new marker for PyArg_ParseTuple, like "**") and now
> that we have warnings and __future__, we could phase it in even for oft-used
> things such as string.split().
> 
> Even if it's deemed dubious hypergeneralization (look ma, no macro ;) it's
> worth writing a PEP about, right ?

Sure.  My main problem with it is that I doubt how often it is useful,
compared to the cost of adding the syntax and new code generation
necessary.  I don't think that ** is the right separator, but I don't
have a better suggestion.

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



From mal at lemburg.com  Mon Apr 23 15:40:50 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 23 Apr 2001 15:40:50 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com> <3AE3EC50.3A850757@lemburg.com> <03ee01c0cbf5$f3963f30$e000a8c0@thomasnotebook>
Message-ID: <3AE430E2.A81CEBDA@lemburg.com>

Thomas Heller wrote:
> 
> I see the same Behaviour as Marc-Andre: Traceback in Win95 (running under VMWare,
> running under Win2k).
> 
> C:\WINDOWS>\python21\python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> >>> print mx.Number.Float(3.141)
> 3.14100000000000001421e+0
> >>>
> >>>
> >>>
> >>> quit
> 'Use Ctrl-Z plus Return to exit.'
> >>>
> C:\WINDOWS>cd \python21
> 
> C:\Python21>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "c:\python21\mx\Number\__init__.py", line 9, in ?
>     from Number import *
>   File "c:\python21\mx\Number\Number.py", line 11, in ?
>     from mxNumber import *
>   File "c:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
>     from mxNumber import *
> ImportError: DLL load failed: One of the library files needed to run this applic
> ation cannot be found.
> >>>
> C:\Python21>ver
> 
> Windows 95. [Version 4.00.950]
> 
> C:\Python21>
> 
> Marc-Andre, what about other python versions?

mxNumber needs Python 2.1, so I have no way of testing it under
Python 2.0. Both imports work on Winows 98SE, so I guess this
has something to do with Win95 no handling imports using relative
paths correctly (if you run Python with -vv you'll see that
Python searches using relative paths when started from C:\Python21).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From nas at python.ca  Mon Apr 23 17:12:18 2001
From: nas at python.ca (Neil Schemenauer)
Date: Mon, 23 Apr 2001 08:12:18 -0700
Subject: [Python-Dev] ineffective optimization: method tables
Message-ID: <20010423081218.A9952@glacier.fnational.com>

Well, I wasted a fair amount of my time for no apparent gain.
The idea was to have function pointer tables indexed by type that
could be used for common operations.  First, how to do we index
things by type?  Here's my solution:

    #define PyType_UNKNOWN 0
    #define PyType_NONE 1
    #define PyType_INT 2

    #define PyType_Ord(t) ((t)->tp_ord)
    #define PyObject_TypeOrd(o) PyType_Ord((o)->ob_type)

Here is an example of methods for PyObject_IsTrue:

    int
    int_istrue(PyObject *v)
    {
        return ((PyIntObject *)v)->ob_ival != 0;
    }

    int
    none_istrue(PyObject *v)
    {
        return 0;
    }

    inquiry istrue_table[] =  {
           PyObject_IsTrue,        /* PyType_UNKNOWN */
           none_istrue,            /* PyType_NONE */
           int_istrue,             /* PyType_INT */
    };

    #define PyObject_IS_TRUE(v) istrue_table[PyObject_TypeOrd(v)](v)

There is a patch at:

    http://arctrix.com/nas/python/method_table1.diff

I did have 2-D tables for binary operations but since they were
quite sparse I took them out in favor of arrays and case
statements.  Unfortunately, all my benchmarks show this patch to
be ineffective in terms of speeding up the interpreter.  Anyone
know why?

  Neil



From guido at digicool.com  Mon Apr 23 17:21:02 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 23 Apr 2001 11:21:02 -0400
Subject: [Python-Dev] ineffective optimization: method tables
In-Reply-To: Your message of "Mon, 23 Apr 2001 08:12:18 PDT."
             <20010423081218.A9952@glacier.fnational.com> 
References: <20010423081218.A9952@glacier.fnational.com> 
Message-ID: <200104231521.f3NFL8h15693@odiug.digicool.com>

> Well, I wasted a fair amount of my time for no apparent gain.
[...]
> Unfortunately, all my benchmarks show this patch to
> be ineffective in terms of speeding up the interpreter.  Anyone
> know why?

Probably you're optimizing something that is already quite fast.
While your code saves a C call and a few tests, those kind of
operations are rarely what slows down Python these days.  My suspicion
is that most of the the time goes into (1) allocating and deallocating
objects, and (b) calling methods...

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



From pedroni at inf.ethz.ch  Mon Apr 23 17:35:48 2001
From: pedroni at inf.ethz.ch (Samuele Pedroni)
Date: Mon, 23 Apr 2001 17:35:48 +0200 (MET DST)
Subject: [Python-Dev] ineffective optimization: method tables
Message-ID: <200104231535.RAA12700@core.inf.ethz.ch>

Hi.

[Neil Schemenauer]
> I did have 2-D tables for binary operations but since they were
> quite sparse I took them out in favor of arrays and case
> statements.  Unfortunately, all my benchmarks show this patch to
> be ineffective in terms of speeding up the interpreter.  Anyone
> know why?
I just noticed that your changes add a 1 more call price also were there was
no such price (int + int, etc), do not know if that matters ...

regards.




From dsh8290 at rit.edu  Mon Apr 23 19:11:54 2001
From: dsh8290 at rit.edu (D-Man)
Date: Mon, 23 Apr 2001 13:11:54 -0400
Subject: [Python-Dev] Class Methods
In-Reply-To: <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>; from thomas.heller@ion-tof.com on Fri, Apr 20, 2001 at 05:40:21PM +0200
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com> <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>
Message-ID: <20010423131154.A13119@harmony.cs.rit.edu>

On Fri, Apr 20, 2001 at 05:40:21PM +0200, Thomas Heller wrote:
| I want the class methods (for example) to create and manipulate
| this 'context object'. This object, however, belongs into the class...
| 
| What I want to avoid is
| 
|   class X(...):
|       ....
|   initialize(X)

Here is a different approach to consider :

class X :
    def __class_init__( class_X ) :
        initialize( class_X )


The idea here is to provide a "magic" method in the class that the
interpreter calls as soon as the class object exists.  The first
(only) argument is the class object, which can be named as desired
(analogous to 'self').  The main problem here is clients aren't
prevented from calling this method, and they really shouldn't.

-D




From martin at loewis.home.cs.tu-berlin.de  Mon Apr 23 19:45:18 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 23 Apr 2001 19:45:18 +0200
Subject: [Python-Dev] 'iter' as a function name
Message-ID: <200104231745.f3NHjIN02434@mira.informatik.hu-berlin.de>

I should probably be silent on the issue of picking names for things,
but I feel that 'iter' is an unfortunte choice for a function name: it
is an abbreviated word. Now, you could argue that there is plenty of
precedent for that in Python, but some of these are also
confusing. Just today, I asked colleague what he thought 'repr' might
do, and he had no clue.

Anyway, I've been browsing dictionaries somewhat, and here are a few
proposals, taking a well-known dictionary as an argument:

harp(sys.modules)      # or harp_on(sys.modules)?
traverse(sys.modules)  # not shorter than iterate, though...
narrate(sys.modules)

Of course, spelling-out "iterate" would be just as fine.

Just my 0.02EUR,

Martin



From donb at abinitio.com  Mon Apr 23 20:12:36 2001
From: donb at abinitio.com (Donald Beaudry)
Date: Mon, 23 Apr 2001 14:12:36 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs 
References: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz> <02a701c0cbd3$a21f9290$e000a8c0@thomasnotebook>
Message-ID: <200104231812.OAA08354@localhost.localdomain>

"Thomas Heller" <thomas.heller at ion-tof.com> wrote,
> Donald Beaudry's objectmodule uses the metaclass hook to provide
> class methods. I like the resulting syntax very much:

Thank you.  I like it too, especially because MyClass.__class__
returns what *I* would expect ;) and the source reflects that too.

> If I understand correctly (objectmodule does not run under 1.5.2 or
> later), an instance of __class__ will become the metaclass of
> Object, and __class__'s methods will become class methods of Object.

That's correct.  I currently use objectmodule on 1.5.2.  I would not
be surprised if it doesnt work on newer versions though as I have
never tried it there.  Perhaps you found an out-of-date version, or
perhaps I never sent out a newer version.  Regardless, I'd be happy to
get you a version that works with 1.5.2 (or upload one somewhere for
more public consumption)

> I've played a little bit with metaclasses in pure python (it is
> faster this way), and have an implementation with the same syntax
> where __class__ is never instantiated, and simply acts as a function
> container.

Ah but with the object module, it does get instantiated.  In fact,
__class__ is derived (implicitly) from the __class__ of the containing
base class. Inheritance works as expected.

> Addendum: Additionaly to class methods, I would like to
> have 'magic' class methods, maybe named __class_init__
> and __class_getattr__. Easy to guess what they should do...

Objectmodule provides for that as well.  Just define __init__,
__getattr__, etc., inside the __class__ definition.  There is even and
__new__ which is responsible for controling the "memory allocation" of
instances.  This is useful for, amoung other things, singletons.

> > Hmmm... might write a PEP on that!
> > 
> Me too.

...gone are the days when a simple email to Guido was all it took to
get a proposal going ;)

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb at init.com                                      Lexington, MA 02421
                  ...So much code, so little time...




From donb at abinitio.com  Mon Apr 23 20:22:03 2001
From: donb at abinitio.com (Donald Beaudry)
Date: Mon, 23 Apr 2001 14:22:03 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs 
References: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com> <200104230533.RAA14282@s454.cosc.canterbury.ac.nz> <15076.8908.65608.249318@cj42289-a.reston1.va.home.com>
Message-ID: <200104231822.OAA08502@localhost.localdomain>

"Fred L. Drake, Jr." <fdrake at acm.org> wrote,
> 
> Greg Ewing writes:
>  >   class Foo:
>  > 
>  >     def ftang(class c, x, y, z);
>  >       ...
> 
>   I like this syntax better that the others.  While it requires that a
> single namespace is used for class and normal methods, I think that is
> a good thing -- we don't *want* overlapping sets of names!

But... we have overlaping names!  __init__ is just one example.
Further, that only works for methods.  How should class attributes be
distinguished?  Perhaps you dont want them.

Should a decision be made to go down this road, a big choice lies
ahead.  Are class objects "special" or are they simply instances of a
different class?  Because I didnt want to make a whole pile of
decisions regarding the "specialness" of class objects, I chose to
make the one decision that class object's only distinction from other
objects is that they are instances of a different class.  This is,
afterall, how all objects are distinguished.

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb at init.com                                      Lexington, MA 02421
                      ...Will hack for sushi...



From thomas.heller at ion-tof.com  Mon Apr 23 20:27:10 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Mon, 23 Apr 2001 20:27:10 +0200
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs 
References: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz> <02a701c0cbd3$a21f9290$e000a8c0@thomasnotebook> <200104231812.OAA08354@localhost.localdomain>
Message-ID: <08bd01c0cc23$02cdb050$e000a8c0@thomasnotebook>

> "Thomas Heller" <thomas.heller at ion-tof.com> wrote,
> > Donald Beaudry's objectmodule uses the metaclass hook to provide
> > class methods. I like the resulting syntax very much:
> 
> Thank you.  I like it too, especially because MyClass.__class__
> returns what *I* would expect ;) and the source reflects that too.
> 
> > If I understand correctly (objectmodule does not run under 1.5.2 or
> > later), an instance of __class__ will become the metaclass of
> > Object, and __class__'s methods will become class methods of Object.
> 
> That's correct.  I currently use objectmodule on 1.5.2.  I would not
> be surprised if it doesnt work on newer versions though as I have
> never tried it there.  Perhaps you found an out-of-date version, or
> perhaps I never sent out a newer version.  Regardless, I'd be happy to
> get you a version that works with 1.5.2 (or upload one somewhere for
> more public consumption)

Sure I would be interested: Please send it.
Thanks for the description, I've (eagerly) read everything I found
in objectmodule-0.9.tar.gz - except I found that it would be easier
to step in a debugger through the c-code, which turned out to fail.

BTW: I just exchanged a couple of emails with Just van Rossum,
who had something very similar to yours (but you may know this already).
He pointed me to some discussions in '98 in the types-sig archives.

He proposed an additional hook in ceval.c (which would probably break
objectmodule). I've attached his proposed patch below.

Thomas

+       /*      __BEGIN__ of Just's Hook
+
+               Guido's metahook is defined as follows:
+                       - if one of the bases has a __class__ attribute (but is
+                         itself not a class!), call that thing with (name,
+                         bases, methods)
+               In addition I propose almost the opposite:
+                       - if the "methods" dict (__dict__ from the Python
+                         perspective) has a __class__ key, call that thing with
+                         (name, bases, methods)
+
+               This means that metaclasses are not special anymore, and
+               you have to specify a metaclass *explicitly* to get meta
+               behaviour. Example:
+
+                       class Foo:
+                               __class__ = MyMetaClass
+
+               as apposed to
+
+                       MyMeta = MyMetaClass("MyMeta", (), {})
+
+                       class Foo(MyMeta): pass
+
+               as it is with Guido's hook.
+
+               Reasons for this new hook:
+                       - Guido's hook abuses inheritance syntax, making it
+                         impossible to inherit from metaclasses without special
+                         trickery.
+                       - implementing Meta stuff seems cleaner. Or maybe it's
+                         just me...
+
+               At first I thought Guido's hook would not be compatible with
+               mine, but they work together beautifully: inheritance works
+               just like you would expect.
+       */
+       {
+               PyObject *callable = NULL;
+               callable = PyDict_GetItemString(methods, "__class__");
+               if (callable) {
+                       PyObject *args;
+                       PyObject *newclass = NULL;
+                       PyDict_DelItemString(methods, "__class__");
+                       args = Py_BuildValue(
+                               "(OOO)", name, bases, methods);
+                       if (args != NULL) {
+                               newclass = PyEval_CallObject(
+                                       callable, args);
+                               Py_DECREF(args);
+                       }
+                       return newclass;
+               } else {
+                       PyErr_Clear();
+               }
+       }
+       /*      __END__ of Just's Hook */
        n = PyTuple_Size(bases);
        for (i = 0; i < n; i++) {
                PyObject *base = PyTuple_GET_ITEM(bases, i);
                if (!PyClass_Check(base)) {
                        /* Call the base's *type*, if it is callable.




From neal at metaslash.com  Mon Apr 23 21:46:29 2001
From: neal at metaslash.com (Neal Norwitz)
Date: Mon, 23 Apr 2001 15:46:29 -0400
Subject: [Python-Dev] PyChecker 0.4 - new release
Message-ID: <3AE48695.EE89C468@metaslash.com>

I've released a new version of PyChecker, the source code checking tool.

The most notable change is support for .pycheckrc file to specify
your own defaults.  There were also a few new warnings added and
some bug fixes.

Here's the CHANGELOG:

  * Add .pycheckrc file processing to specify options (like on command line)
  * Add new warning if module.Attribute doesn't exist
  * Add new warning:  Module (%s) re-imported locally
  * Add glob'ing support for windows
  * Handle apply(BaseClass.__init__(self, args))
  * Fix command line handling so you can pass module, package, or filename
  * Fix **kwArgs warning if named parameter is not first
  * Don't exit from checker when import checker from interpreter

PyChecker is available on Source Forge:
    Web page:           http://pychecker.sourceforge.net/
    Project page:       http://sourceforge.net/projects/pychecker/

Neal



From martin at loewis.home.cs.tu-berlin.de  Tue Apr 24 08:24:09 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 24 Apr 2001 08:24:09 +0200
Subject: [Python-Dev] ineffective optimization: method tables
Message-ID: <200104240624.f3O6O9001146@mira.informatik.hu-berlin.de>

> Unfortunately, all my benchmarks show this patch to be ineffective
> in terms of speeding up the interpreter.  Anyone know why?

I guess because you took PyObject_IsTrue. After profiling some
application, I found that this is a frequent function, so I thought it
should be optimized.

I then found that most of the time, it gets Py_True, Py_False, or
Py_None as an argument, so I checked for identity with these objects.
Indeed, that covered the majority of the calls - but with no
significant speed gain when special-cased.

So I think I agree with Guido: even as these functions are frequently
called, this is not where the time is consumed.

Regards,
Martin



From skip at pobox.com  Tue Apr 24 15:17:24 2001
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 24 Apr 2001 08:17:24 -0500 (CDT)
Subject: [Python-Dev] tickling version numbers during release
In-Reply-To: <20010419075326.F30408@ActiveState.com>
References: <15070.41140.642307.450172@beluga.mojam.com>
	<20010419075326.F30408@ActiveState.com>
Message-ID: <15077.31972.989862.905462@beluga.mojam.com>

    Trent> Or preferably have the version number in only *one* place in one
    Trent> file in CVS then (1) have autoconf massage template files to
    Trent> insert the version number where needed or (2) have those files
    Trent> that need the version number *include* it from pyac_config.h.

    Trent> ...except we are not using any auto configuration tool on
    Trent> Windows. Damn.

That's not necessary.  I think if you have one file in CVS that contains the
version then you can update other CVS-resident files that want to have the
version also.  You just have to do that from an autoconf-compatible machine.

Skip





From electro-owner at ml.poplist.fr  Tue Apr 24 16:21:54 2001
From: electro-owner at ml.poplist.fr (thelink)
Date: Tue, 24 Apr 2001 16:21:54 +0200
Subject: [Python-Dev] WWW.090000900.COM GAGNEZ 1 AN DE COMMUNICATIONS GSM ! WIN 1 JAAR GRATIS
 GSM-GEBRUIK !
Message-ID: <007601c0ccc9$e9f7d540$01fea8c0@jctubiermont.brutele.be>

--{  Liste h?berg?e par PoPList  }------{  http://www.poplist.fr/  }--
--{  Voir  en   bas  de  ce  mail les  options  de  d?sabonnement  }--
______________________________________________________________________


GAGNEZ 1 AN DE COMMUNICATIONS GSM GRATUITES !
WIN 1 JAAR GRATIS GSM-GEBRUIK !

       

TELECHARGEZ PAR SMS 1500 LOGOS et SONNERIES AU TARIF LE PLUS BAS ( 30 bef / unite ) !
DOWNLOAD PER SMS 1500 LOGOS en RINGTONES AAN HET LAAGSTE TARIEF ( 30 bef / stuk ) !
http://www.090000900.com

$


Pour vous d?sabonner, rendez-vous simplement sur cette page :
->  <http://cgi.poplist.fr/@/u/electro/python-dev at python.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20010424/c29ac32b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9072 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20010424/c29ac32b/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 16877 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20010424/c29ac32b/attachment-0001.gif>

From gmcm at hypernet.com  Wed Apr 25 17:21:18 2001
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 25 Apr 2001 11:21:18 -0400
Subject: [Python-Dev] Attn: Christian Tismer (apologies to others)
Message-ID: <3AE6B32E.22730.5BF4AC97@localhost>

Sorry to blast everybody with this.

Christian, your mail server is getting a new HD. You can reach 
Jean-Claude at jcwippler at hotmail.com.

- Gordon



From michel at digicool.com  Wed Apr 25 22:08:01 2001
From: michel at digicool.com (Michel Pelletier)
Date: Wed, 25 Apr 2001 13:08:01 -0700 (PDT)
Subject: [Python-Dev] PEP 245 Prototype
Message-ID: <Pine.LNX.4.32.0104242341190.17366-100000@localhost.localdomain>

I have created a prototype of PEP 245 based on the Mobius Python library.
This prototype requires no changes to Python 2.x.

I have also updated PEP 245 to reflect using the prototype.  Refer to the
'doc' directory for the revised PEP.  The prototype can be downloaded
from:

http://www.zope.org/Members/michel/InterfacesPEP/Interface.tgz

It contains four directories and a README that should get you started.
Please follow up any comments specific to the PEP onto the
type-sig at python.org list.

Thanks,

-Michel





From mal at lemburg.com  Wed Apr 25 23:15:58 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 25 Apr 2001 23:15:58 +0200
Subject: [Python-Dev] ANN: mxNumber -- Experimental Number Types, Version 0.2.0
Message-ID: <3AE73E8E.E9152718@lemburg.com>

ANNOUNCING

			mxNumber - Version 0.2.0

                Python Interface to GNU MP Number Types


INTRODUCTION
------------

As you all know, Moshe Zadka has been pushing for a new rational
number type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I thought, but well, it's done now.

There's still no web-page for this package, so I'm providing the
needed information in this posting.


WHAT'S NEW ?
------------

The 0.2.0 release is an alpha release. Everything is still in flux, so
expect bugs, strange behaviour etc.

Still, the package provides some interesting insights into the issues
you run into when dealing with computational representations of
numbers. For now, you should consider the package a pure fun-package
and playground for experiments.

New in this release are a parser for rational strings (formats "1/2"
and "3 1/3"), plus a new constructor FareyRational() which was
inspired by an algorithm written by Scott David Daniels and posted to
the Python Cookbook; see
    http://www.activestate.com/ASPN/Python/Cookbook/Recipe/52317

The FareyRational() constructor allows you to convert floating point
numbers to rationals, e.g. 1.3333 to 4/3.


INTERFACE
---------

The package is part of the eGenix.com EXPERIMENTAL package and called
mx.Number. It provides access to three numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision
4. FareyRational(value, maxden)
                       -- calculate the best rational represenation 
                          n/d of value such that d < maxden

DOWNLOADS
---------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
r3 = FareyRational(1.33333, 1000)
i = Integer("1231231231231231231231231")


The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


QUESTIONS
---------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From mal at lemburg.com  Wed Apr 25 23:15:58 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 25 Apr 2001 23:15:58 +0200
Subject: [Python-Dev] ANN: mxNumber -- Experimental Number Types, Version 0.2.0
Message-ID: <mailman.988234202.22353.clpa-moderators@python.org>

ANNOUNCING

			mxNumber - Version 0.2.0

                Python Interface to GNU MP Number Types


INTRODUCTION
------------

As you all know, Moshe Zadka has been pushing for a new rational
number type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I thought, but well, it's done now.

There's still no web-page for this package, so I'm providing the
needed information in this posting.


WHAT'S NEW ?
------------

The 0.2.0 release is an alpha release. Everything is still in flux, so
expect bugs, strange behaviour etc.

Still, the package provides some interesting insights into the issues
you run into when dealing with computational representations of
numbers. For now, you should consider the package a pure fun-package
and playground for experiments.

New in this release are a parser for rational strings (formats "1/2"
and "3 1/3"), plus a new constructor FareyRational() which was
inspired by an algorithm written by Scott David Daniels and posted to
the Python Cookbook; see
    http://www.activestate.com/ASPN/Python/Cookbook/Recipe/52317

The FareyRational() constructor allows you to convert floating point
numbers to rationals, e.g. 1.3333 to 4/3.


INTERFACE
---------

The package is part of the eGenix.com EXPERIMENTAL package and called
mx.Number. It provides access to three numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision
4. FareyRational(value, maxden)
                       -- calculate the best rational represenation 
                          n/d of value such that d < maxden

DOWNLOADS
---------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
r3 = FareyRational(1.33333, 1000)
i = Integer("1231231231231231231231231")


The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


QUESTIONS
---------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/




From MarkH at ActiveState.com  Thu Apr 26 16:10:36 2001
From: MarkH at ActiveState.com (Mark Hammond)
Date: Fri, 27 Apr 2001 00:10:36 +1000
Subject: [Python-Dev] buffer interface (again)
In-Reply-To: <04b101c0c826$a0818890$e000a8c0@thomasnotebook>
Message-ID: <LCEPIIGDJPKCOIHOBJEPAEMMDKAA.MarkH@ActiveState.com>

> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Thomas Heller
> Sent: Thursday, 19 April 2001 2:43 AM

Better late than never!

> > I'd like to see a memory object that allocates and deallocates blocks
> > of memory and exports a pointer to its memory.  It could also set
> > privileges such are read/write, etc
>
> It's all there, in bufferobject.c.
> Except that the functions are not exposed to python...

I'm with Thomas too.  I could have used this a number of times, and have
even resorted to simple methods in my own .pyd files that wrap these APIs -
eg, win32file.AllocateReadBuffer() used for overlapped IO.

So while I think Thomas' bug is valid, I also understand we have to somehow
handle the issue the array module has.

Mark.




From MarkH at ActiveState.com  Thu Apr 26 16:26:39 2001
From: MarkH at ActiveState.com (Mark Hammond)
Date: Fri, 27 Apr 2001 00:26:39 +1000
Subject: [Python-Dev] Unicode and the Windows file system.
In-Reply-To: <LCEPIIGDJPKCOIHOBJEPOEKKDGAA.MarkH@ActiveState.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPIEMMDKAA.MarkH@ActiveState.com>

Now that 2.1 is out the door, how do we feel about getting these Unicode
changes in?

Mark.

> -----Original Message-----
> From: Mark Hammond [mailto:MarkH at ActiveState.com]
> Sent: Thursday, 22 March 2001 4:16 PM
> To: python-dev at python.org
> Subject: RE: [Python-Dev] Unicode and the Windows file system.
>
>
> I have submitted patch #410465 for this.
>
> http://sourceforge.net/tracker/?func=detail&aid=410465&group_id=54
> 70&atid=305470
>
> Comments are in the patch, so I won't repeat them here, but I
> would appreciate a few reviews on the code.  Particularly, my
> addition of a new format to PyArg_ParseTuple and the resulting
> extra string copy may raise a few eye-brows.
>
> I've even managed to include the new test file and its output in
> the patch, so it will hopefully apply cleanly and run a full test
> if you want to try it.
>
> Thanks,
>
> Mark.




From fredrik at effbot.org  Thu Apr 26 20:47:29 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Thu, 26 Apr 2001 20:47:29 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid>

> In the re-Module which come with Python version 2.0
> (Nov 28 11:10 re.py) the created MatchObjects cannot be
> copied with a deepcopy(). Switching back to the old
> "pre.py" as proposed in "re.py" makes everything work
> ok.

thought I'd check this one with python-dev before marking
it as "won't fix".  I cannot see any reason why anyone would
even attempt to deepcopy match objects...

(cannot see any reason why anyone would use deepcopy for
anything, but that's another story)

Cheers /F




From martin at loewis.home.cs.tu-berlin.de  Thu Apr 26 22:28:17 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 26 Apr 2001 22:28:17 +0200
Subject: [Python-Dev] [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de>

> thought I'd check this one with python-dev before marking it as
> "won't fix".  I cannot see any reason why anyone would even attempt
> to deepcopy match objects...

What's wrong with patch #419070, which fixes the bug? Like any other
immutable object, deepcopying a match object means returning it.

Regards,
Martin



From fredrik at effbot.org  Thu Apr 26 22:50:38 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Thu, 26 Apr 2001 22:50:38 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de>
Message-ID: <014b01c0ce92$8da742b0$e46940d5@hagrid>

Martin v. Loewis wrote:
> What's wrong with patch #419070, which fixes the bug? Like any other
> immutable object, deepcopying a match object means returning it.

what makes you think a match object is immutable?

import array, sre

a = array.array("c", "abcde")
m = sre.search("bcd", a)
print m.group(0)

Cheers /F




From martin at loewis.home.cs.tu-berlin.de  Thu Apr 26 23:12:45 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 26 Apr 2001 23:12:45 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <014b01c0ce92$8da742b0$e46940d5@hagrid> (fredrik@effbot.org)
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de> <014b01c0ce92$8da742b0$e46940d5@hagrid>
Message-ID: <200104262112.f3QLCjd02333@mira.informatik.hu-berlin.de>

> what makes you think a match object is immutable?

Because you cannot modify their state.

> import array, sre
> 
> a = array.array("c", "abcde")
> m = sre.search("bcd", a)
> print m.group(0)

a1 = m.group(0)
a1[0]='z'
print m.group(0)

So you'd have to modify a, to modify m.group(0). To catch this case,
you might want to do

def copy_match(m):
  g = m.group(0)
  if copy(g) is not g:
    raise KeyError    # will be re-raised as copy.Error
  return g

That will restore backwards compatibility with pre, which is what the
submitter of the bug requested.

Regards,
Martin



From fredrik at effbot.org  Thu Apr 26 23:48:59 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Thu, 26 Apr 2001 23:48:59 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de> <014b01c0ce92$8da742b0$e46940d5@hagrid> <200104262112.f3QLCjd02333@mira.informatik.hu-berlin.de>
Message-ID: <018f01c0ce9a$b49c6e10$e46940d5@hagrid>

Martin v. Loewis wrote:
> Because you cannot modify their state.

same thing as tuples: you cannot modify the tuples, but you
can modify their members.  as its name implies, deepcopy can
deal with tuples...

> So you'd have to modify a, to modify m.group(0). To catch this case,
> you might want to do
> 
> def copy_match(m):
>   g = m.group(0)
>   if copy(g) is not g:
>     raise KeyError    # will be re-raised as copy.Error
>   return g
> 
> That will restore backwards compatibility with pre, which is what the
> submitter of the bug requested.

which means that deepcopy sometimes work on match objects, and
sometimes doesn't.  *that* sounds like a bug to me.

frankly, I don't think the original problem is a bug at all -- I think someone's
abusing a CPython 1.5.2 implementation detail.  it's not documented to work,
it's not in the test suite, and it's not exactly the only thing in there that cannot
be deepcopied...

introducing broken behaviour to deal with someone's broken program sounds
like a rather lousy idea -- and a dangerous precedent.  user code shouldn't
depend on accidental implementation details.

Cheers /F




From fredrik at effbot.org  Fri Apr 27 00:08:47 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Fri, 27 Apr 2001 00:08:47 +0200
Subject: [Python-Dev] anyone have an Irix box?
Message-ID: <01ad01c0ce9d$790ac470$e46940d5@hagrid>

SRE doesn't work at all under Irix8/gcc, according to this report
https://sourceforge.net/tracker/?func=detail&aid=233790&group_id=5470&atid=105470

unfortunately, the submitter didn't provide any contact info, and
hasn't bothered to follow up with more details.  and I still don't
have a working SGI box.

any ideas how to deal with this?

Cheers /F




From tim.one at home.com  Fri Apr 27 01:21:24 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 26 Apr 2001 19:21:24 -0400
Subject: [Python-Dev] anyone have an Irix box?
In-Reply-To: <01ad01c0ce9d$790ac470$e46940d5@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCIENLJOAA.tim.one@home.com>

> SRE doesn't work at all under Irix8/gcc, according to this report
> https://sourceforge.net/tracker/?func=detail&aid=233790&group_id=54
> 70&atid=105470
>
> unfortunately, the submitter didn't provide any contact info, and
> hasn't bothered to follow up with more details.  and I still don't
> have a working SGI box.
>
> any ideas how to deal with this?

The first guess on an SGI box is usually the last:  recompile w/o
optimization.  But if they're *really* using gcc that's probably not
relevant.

In the latter case Guido knows what to do.  But he's not going to tell you
before you tell him how to close the 517 HP-UX thread bugs assigned to him
first <0.9 wink>.




From mwh21 at cam.ac.uk  Fri Apr 27 01:45:05 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 27 Apr 2001 00:45:05 +0100
Subject: [Python-Dev] anyone have an Irix box?
In-Reply-To: "Fredrik Lundh"'s message of "Fri, 27 Apr 2001 00:08:47 +0200"
References: <01ad01c0ce9d$790ac470$e46940d5@hagrid>
Message-ID: <m3sniv2pku.fsf@atrus.jesus.cam.ac.uk>

"Fredrik Lundh" <fredrik at effbot.org> writes:

> SRE doesn't work at all under Irix8/gcc, according to this report
> https://sourceforge.net/tracker/?func=detail&aid=233790&group_id=5470&atid=105470
> 
> unfortunately, the submitter didn't provide any contact info, and
> hasn't bothered to follow up with more details.  and I still don't
> have a working SGI box.
> 
> any ideas how to deal with this?

Quinn Dunkan (quinn at dinar.ugcs.caltech.edu) has/had an Irix box he
could test stuff on (I tried to help him sort some readline stuff out
once but got nowhere).  I'm sure he would run make test and email you
the output if you asked nicely.  While not ideal, if it works for him
it would give you more justification in closing the report unless the
OP comes up with some more info.

Cheers,
M.

-- 
  Just put the user directories on a 486 with deadrat7.1 and turn the
  Octane into the afforementioned beer fridge and keep it in your
  office. The lusers won't notice the difference, except that you're
  more cheery during office hours.              -- Pim van Riezen, asr




From tim.one at home.com  Fri Apr 27 01:52:55 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 26 Apr 2001 19:52:55 -0400
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com>

[/F]
> thought I'd check this one with python-dev before marking
> it as "won't fix".  I cannot see any reason why anyone would
> even attempt to deepcopy match objects...

Likely just because they're part of other objects, like bound to instance
attributes, or members of lists.  No matter how deep they're buried, someone
trying to deepcopy a container will eventually need to deepcopy them too.

> (cannot see any reason why anyone would use deepcopy for
> anything, but that's another story)

It's a std way to get a clone of an object, and when you don't want mutations
of the clone to have any effect on the original (or vice versa).  Perhaps if
I call it the Clone Pattern, people will assume that makes it a good thing
and cut that part of the debate mercifully short <wink>.

It's *nice* to supply a deepcopy operation whenever it's doable with
reasonable effort.  I agree you're not required to in this case -- but it
would still be "nice", if that's feasible.




From martin at loewis.home.cs.tu-berlin.de  Fri Apr 27 07:07:56 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 27 Apr 2001 07:07:56 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <018f01c0ce9a$b49c6e10$e46940d5@hagrid> (fredrik@effbot.org)
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de> <014b01c0ce92$8da742b0$e46940d5@hagrid> <200104262112.f3QLCjd02333@mira.informatik.hu-berlin.de> <018f01c0ce9a$b49c6e10$e46940d5@hagrid>
Message-ID: <200104270507.f3R57uG01297@mira.informatik.hu-berlin.de>

> which means that deepcopy sometimes work on match objects, and
> sometimes doesn't.  *that* sounds like a bug to me.

So I'll provide documentation; that will make it a feature. arrays
cannot be copied either - for no good reason, AFAICT. Given that they
cannot be copied, it is not surprising that match objects referring to
array objects cannot be deepcopied.

The "sometimes works, sometimes doesn't" aspect of deepcopy holds for
any container object:

class X:pass
x = X()
x.values = [1,2,3]
y = copy.deepcopy(x)                # succeeds
x1 = X()
x1.values = array.array("i",[1,2,3])
y1 = copy.deepcopy(x1)              # fails

> frankly, I don't think the original problem is a bug at all -- I
> think someone's abusing a CPython 1.5.2 implementation detail.

It is not abuse. There was no indication in the documentation that
there might be a problem. He probably has a match object as an
instance attribute, and wants to copy the instance. He does not care
whether the match object is shared across copies. He only wants the
instance copying to succeed - which it does in Python 1.5, whereas it
fails in 2.0.

> it's not documented to work, it's not in the test suite, and it's
> not exactly the only thing in there that cannot be deepcopied...

The documentation says

# This version does not copy types like module, class, function,
# method, stack trace, stack frame, file, socket, window, array, or
# any similar types.

So is a match object of "any similar type" or not? Next time, somebody
breaks copying tuples, and claims that tuples are certainly similar to
arrays... There is no indication whatsoever that copying match objects
is not supported - even though the documentation does give a list of
types that are not supported.

> introducing broken behaviour to deal with someone's broken program sounds
> like a rather lousy idea -- and a dangerous precedent.  user code shouldn't
> depend on accidental implementation details.

As I said: the user reading the 1.5 documentation had no way to tell
that it was an "accidental implementation detail". The user reading
the 2.0 documentation had no way to tell that this detail had been
changed. So there clearly is a bug here.

If you want to reject my patch, fine. But at a minimum, there should
be documentation changes to deal with the problem.

Regards,
Martin



From thomas.heller at ion-tof.com  Fri Apr 27 09:53:09 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 27 Apr 2001 09:53:09 +0200
Subject: [Python-Dev] Memory management question
Message-ID: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook>

I'm trying to port Don Beaudry's objectmodule to Python 2.0
and encountered the following problem. Here is a part from Don's code:

  co = (MetaClassObject*) PyClass_New(NULL, methods, name);
  co = PyObject_Realloc(co, sizeof (MetaClassObject));

As you see, he is trying to achive cheap code reuse.
This code does not work.

I have tracked it down to the following sample, which does also not
work. In the debug version on windows, the PyObject_REALLOC
fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)

 op = PyObject_NEW(PyClassObject, &PyClass_Type);
 op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);

Should the above work or am I doing something wrong?

Regards,

Thomas




From fredrik at pythonware.com  Fri Apr 27 11:06:37 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 27 Apr 2001 11:06:37 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com>
Message-ID: <00e801c0cef9$5e142150$0900a8c0@spiff>

tim wrote:
> It's a std way to get a clone of an object, and when you don't want mutations
> of the clone to have any effect on the original (or vice versa).  Perhaps if
> I call it the Clone Pattern, people will assume that makes it a good thing
> and cut that part of the debate mercifully short <wink>.

which leads to a followup question: the current approach
seems to be to hack the copy.py file for each and every
type.  imo, that's rather unpythonic, and also introduces
lots of unnecessary module dependencies.

time to add a __clone__ slot?

or could someone who knows what he's doing here address
this comment in copy.py:

    # XXX need to support copy_reg here too...

Cheers /F





From mal at lemburg.com  Fri Apr 27 11:20:59 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Apr 2001 11:20:59 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not 
 deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com> <00e801c0cef9$5e142150$0900a8c0@spiff>
Message-ID: <3AE939FB.D14B2F9B@lemburg.com>

Fredrik Lundh wrote:
> 
> tim wrote:
> > It's a std way to get a clone of an object, and when you don't want mutations
> > of the clone to have any effect on the original (or vice versa).  Perhaps if
> > I call it the Clone Pattern, people will assume that makes it a good thing
> > and cut that part of the debate mercifully short <wink>.
> 
> which leads to a followup question: the current approach
> seems to be to hack the copy.py file for each and every
> type.  imo, that's rather unpythonic, and also introduces
> lots of unnecessary module dependencies.
> 
> time to add a __clone__ slot?
> 
> or could someone who knows what he's doing here address
> this comment in copy.py:
> 
>     # XXX need to support copy_reg here too...

All you have to do is implement the copy protocol (ie. .copy())
for the type/class in question.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From fredrik at pythonware.com  Fri Apr 27 11:51:23 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 27 Apr 2001 11:51:23 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not  deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com> <00e801c0cef9$5e142150$0900a8c0@spiff> <3AE939FB.D14B2F9B@lemburg.com>
Message-ID: <010e01c0ceff$9f8cc8c0$0900a8c0@spiff>

mal wrote:
> > time to add a __clone__ slot?
> >
> > or could someone who knows what he's doing here address
> > this comment in copy.py:
> >
> >     # XXX need to support copy_reg here too...
>
> All you have to do is implement the copy protocol (ie. .copy())
> for the type/class in question.

cannot find any support for that in the copy module (not in 2.0, at least)

but another reading revealed support for __copy__ and __deepcopy__
methods in at least 1.5.2 and later.  intriguing...

Cheers /F





From mal at lemburg.com  Fri Apr 27 11:57:13 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Apr 2001 11:57:13 +0200
Subject: [Python-Dev] Memory management question
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook>
Message-ID: <3AE94279.DBF73856@lemburg.com>

Thomas Heller wrote:
> 
> I'm trying to port Don Beaudry's objectmodule to Python 2.0
> and encountered the following problem. Here is a part from Don's code:
> 
>   co = (MetaClassObject*) PyClass_New(NULL, methods, name);
>   co = PyObject_Realloc(co, sizeof (MetaClassObject));
> 
> As you see, he is trying to achive cheap code reuse.
> This code does not work.
> 
> I have tracked it down to the following sample, which does also not
> work. In the debug version on windows, the PyObject_REALLOC
> fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)
> 
>  op = PyObject_NEW(PyClassObject, &PyClass_Type);
>  op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);
> 
> Should the above work or am I doing something wrong?

Wouldn't it be safer to first create a MetaClassObject and then
let the standard ClassObject initialize it ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From mal at lemburg.com  Fri Apr 27 12:14:41 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Apr 2001 12:14:41 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not  
 deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com> <00e801c0cef9$5e142150$0900a8c0@spiff> <3AE939FB.D14B2F9B@lemburg.com> <010e01c0ceff$9f8cc8c0$0900a8c0@spiff>
Message-ID: <3AE94691.972F02D7@lemburg.com>

Fredrik Lundh wrote:
> 
> mal wrote:
> > > time to add a __clone__ slot?
> > >
> > > or could someone who knows what he's doing here address
> > > this comment in copy.py:
> > >
> > >     # XXX need to support copy_reg here too...
> >
> > All you have to do is implement the copy protocol (ie. .copy())
> > for the type/class in question.
> 
> cannot find any support for that in the copy module (not in 2.0, at least)
> 
> but another reading revealed support for __copy__ and __deepcopy__
> methods in at least 1.5.2 and later.  intriguing...

You're right... the two methods are named __copy__ and __deepcopy__.
Both should return either copies of the object or simply new reference
in case the object's are immutable.

I've implemented these in mxDateTime and that was all it took to
get the copy module happy (at least in Python 1.5.2).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From guido at digicool.com  Fri Apr 27 15:30:31 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 08:30:31 -0500
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: Your message of "Thu, 26 Apr 2001 20:47:29 +0200."
             <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid> 
References: <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid> 
Message-ID: <200104271330.IAA20006@cj20424-a.reston1.va.home.com>

[Sorry, this bounced -- my new work mail isn't set up right yet]

> > In the re-Module which come with Python version 2.0
> > (Nov 28 11:10 re.py) the created MatchObjects cannot be
> > copied with a deepcopy(). Switching back to the old
> > "pre.py" as proposed in "re.py" makes everything work
> > ok.
> 
> thought I'd check this one with python-dev before marking
> it as "won't fix".  I cannot see any reason why anyone would
> even attempt to deepcopy match objects...
> 
> (cannot see any reason why anyone would use deepcopy for
> anything, but that's another story)

Why don't you ask what they were doing?  They cared enough to figure a
workaround *and* report a bug.  I think they deserve a better answer
than Won't Fix.

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



From guido at digicool.com  Fri Apr 27 17:42:50 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 10:42:50 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 09:53:09 +0200."
             <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> 
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> 
Message-ID: <200104271542.KAA20312@cj20424-a.reston1.va.home.com>

> I have tracked it down to the following sample, which does also not
> work. In the debug version on windows, the PyObject_REALLOC
> fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)
> 
>  op = PyObject_NEW(PyClassObject, &PyClass_Type);
>  op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);
> 
> Should the above work or am I doing something wrong?

Probably this doesn't work because of the GC header.  The 'op' pointer
does not point to the start of the allocated memory block.
PyObject_NEW and friends know about this, but PyObject_REALLOC
doesn't.  That's what the assertion is trying to tell you.

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



From thomas.heller at ion-tof.com  Fri Apr 27 16:58:27 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 27 Apr 2001 16:58:27 +0200
Subject: [Python-Dev] Memory management question
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook>  <200104271542.KAA20312@cj20424-a.reston1.va.home.com>
Message-ID: <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook>

> > I have tracked it down to the following sample, which does also not
> > work. In the debug version on windows, the PyObject_REALLOC
> > fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)
> > 
> >  op = PyObject_NEW(PyClassObject, &PyClass_Type);
> >  op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);
> > 
> > Should the above work or am I doing something wrong?
> 
> Probably this doesn't work because of the GC header.  The 'op' pointer
> does not point to the start of the allocated memory block.
> PyObject_NEW and friends know about this, but PyObject_REALLOC
> doesn't.  That's what the assertion is trying to tell you.
Yes, I've also trakced it down to this.

I assume, PyObject_NEW is a friend of PyObject_DEL, and
so are PyObject_MALLOC, PyObject_REALLOC, and PyObject_FREE - 
but the relationship between the first and the second category
is somewhat cooler...

Is there any (official) way to realloc the memory returned by
PyObject_NEW ?

(Always pushing the apis beyond their limits :-)

Thomas




From guido at digicool.com  Fri Apr 27 18:39:46 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 11:39:46 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 16:58:27 +0200."
             <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> 
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com>  
            <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> 
Message-ID: <200104271639.LAA20790@cj20424-a.reston1.va.home.com>

> Is there any (official) way to realloc the memory returned by
> PyObject_NEW ?

Not if the object participates in GC.

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



From thomas.heller at ion-tof.com  Fri Apr 27 17:56:34 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 27 Apr 2001 17:56:34 +0200
Subject: [Python-Dev] Memory management question
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com>              <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook>  <200104271639.LAA20790@cj20424-a.reston1.va.home.com>
Message-ID: <038701c0cf32$a29bfc60$e000a8c0@thomasnotebook>

> > Is there any (official) way to realloc the memory returned by
> > PyObject_NEW ?
> 
> Not if the object participates in GC.

I'll shut up after this one:

Would a PyObject_RESIZE function/macro make sense?

Thomas




From guido at digicool.com  Fri Apr 27 19:01:37 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 12:01:37 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 17:56:34 +0200."
             <038701c0cf32$a29bfc60$e000a8c0@thomasnotebook> 
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com> <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> <200104271639.LAA20790@cj20424-a.reston1.va.home.com>  
            <038701c0cf32$a29bfc60$e000a8c0@thomasnotebook> 
Message-ID: <200104271701.MAA21256@cj20424-a.reston1.va.home.com>

> I'll shut up after this one:
> 
> Would a PyObject_RESIZE function/macro make sense?
> 
> Thomas

Not for anybody else besides you, I think.

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



From Greg.Wilson at baltimore.com  Fri Apr 27 19:26:52 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Fri, 27 Apr 2001 13:26:52 -0400
Subject: [Python-Dev] FW: how will you be writing code 10 years from now?
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F27AF41@nsamcanms1.ca.baltimore.com>

The following is a webcast from a (preliminary non-official) meeting on
C++0x (C++, the next generation). Could be a bit of foreshadowing on how
things will develop (or prove to be giant red herring if they decide not to
follow any of these ideas)

http://technetcast.ddj.com/tnc_play_stream.html?stream_id=560



From moshez at zadka.site.co.il  Fri Apr 27 19:50:13 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Fri, 27 Apr 2001 20:50:13 +0300
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <00e801c0cef9$5e142150$0900a8c0@spiff>
References: <00e801c0cef9$5e142150$0900a8c0@spiff>, <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com>
Message-ID: <E14tCNh-0003Dj-00@darjeeling>

On Fri, 27 Apr 2001, "Fredrik Lundh" <fredrik at pythonware.com> wrote:

> time to add a __clone__ slot?

It's called __setstate__ and __getstate__, I think?
Don't these have an appropriate C-level slots?

>     # XXX need to support copy_reg here too...

I think it's talking about having copy be the same (but without the
middle man) as Unpickle.loads(Pickle.dumps(o)) (which is a perfect
copy.deepcopy, if a bit wasteful.

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From nas at python.ca  Fri Apr 27 20:10:23 2001
From: nas at python.ca (Neil Schemenauer)
Date: Fri, 27 Apr 2001 11:10:23 -0700
Subject: [Python-Dev] Memory management question
In-Reply-To: <200104271639.LAA20790@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Fri, Apr 27, 2001 at 11:39:46AM -0500
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com> <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> <200104271639.LAA20790@cj20424-a.reston1.va.home.com>
Message-ID: <20010427111023.A23210@glacier.fnational.com>

Guido van Rossum wrote:
> > Is there any (official) way to realloc the memory returned by
> > PyObject_NEW ?
> 
> Not if the object participates in GC.

I going to see if I can fix this for 2.2.  My current thinking is
that there should be memory management APIs for GC objects,
something like:

    PyObject_GC_New()
    PyObject_GC_NewVar()
    PyObject_GC_Realloc()
    PyObject_GC_Del()

The non-GC APIs would no longer have to check the type flags
which would be a bit of a speed win.  The _AS_GC, _FROM_GC macros
would not have to be used as much and the GC implementation would
have more freedom about how to allocate things.

  Neil



From guido at digicool.com  Fri Apr 27 21:14:20 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 14:14:20 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 11:10:23 MST."
             <20010427111023.A23210@glacier.fnational.com> 
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com> <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> <200104271639.LAA20790@cj20424-a.reston1.va.home.com>  
            <20010427111023.A23210@glacier.fnational.com> 
Message-ID: <200104271914.OAA24467@cj20424-a.reston1.va.home.com>

> I going to see if I can fix this for 2.2.  My current thinking is
> that there should be memory management APIs for GC objects,
> something like:
> 
>     PyObject_GC_New()
>     PyObject_GC_NewVar()
>     PyObject_GC_Realloc()
>     PyObject_GC_Del()
> 
> The non-GC APIs would no longer have to check the type flags
> which would be a bit of a speed win.  The _AS_GC, _FROM_GC macros
> would not have to be used as much and the GC implementation would
> have more freedom about how to allocate things.

Looks good!

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



From tim.one at home.com  Fri Apr 27 20:58:03 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 27 Apr 2001 14:58:03 -0400
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <00e801c0cef9$5e142150$0900a8c0@spiff>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEAIJPAA.tim.one@home.com>

[Fredrik Lundh]
> which leads to a followup question: the current approach
> seems to be to hack the copy.py file for each and every
> type.  imo, that's rather unpythonic, and also introduces
> lots of unnecessary module dependencies.
>
> time to add a __clone__ slot?

Note that classes can supply custom cloners via defining __copy__ and
__deepcopy__ methods, without changing copy.py.

A __clone__ slot for *types* would need to address the shallow vs deep
question too, along with the other __getinitargs__, __getstate__,
__setstate__ gimmicks.  How many slots does that add up to?  I leave it to
the PEP author to count them <wink>.

The copy.py protocols kinda grew up with pickle.py's, and together still have
the flavor (to my tongue) of a prototype caught late in midstream.  That is,
it feels like they're not quite finished yet.

> or could someone who knows what he's doing here address
> this comment in copy.py:
>
>     # XXX need to support copy_reg here too...

copy_reg is one of the pickle.py facilities that copy.py "should use" too;
it's a registration database that tells pickle what to do about objects of
types pickle doesn't understand directly (so *could* also be directly
relevant to cloning objects of types copy.py doesn't understand directly --
depending).




From martin at loewis.home.cs.tu-berlin.de  Fri Apr 27 21:10:14 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 27 Apr 2001 21:10:14 +0200
Subject: [Python-Dev] SF changing directory structure
Message-ID: <200104271910.f3RJAE301849@mira.informatik.hu-berlin.de>

As some of you may have noticed, the Python web pages are now in
/home/groups/p/py/python on SourceForge; the symbolic link
/home/groups/python will be removed shortly.

There might be still a number of files that refer to the old location,
atleast htdocs/sf-faq.html, and perhaps crontabs. Whoever is in charge
of these should probably update them.

Regards,
Martin





From tim.one at home.com  Fri Apr 27 21:57:12 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 27 Apr 2001 15:57:12 -0400
Subject: [Python-Dev] SF changing directory structure
In-Reply-To: <200104271910.f3RJAE301849@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEAPJPAA.tim.one@home.com>

[Martin v. Loewis]
> /home/groups/p/py/python on SourceForge; the symbolic link
> /home/groups/python will be removed shortly.

Phooey.  Thanks for the warning!  I sure didn't know about it.

> There might be still a number of files that refer to the old location,
> atleast htdocs/sf-faq.html, and perhaps crontabs. Whoever is in charge
> of these should probably update them.

Nobody is in charge:  if you know of a problem, please fix it.  All the HTML
stuff is under CVS control, and all Python project members have commit access
for it, same as for everything else in the Python source tree; it's just
under the nondist branch instead of the dist branch.




From tim.one at home.com  Sat Apr 28 09:24:48 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 28 Apr 2001 03:24:48 -0400
Subject: [Python-Dev] Iterators, map, xreadlines and docs
Message-ID: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>

A confused user on c.l.py reported that while

    for x in file.xreadlines():

works fine,

    map(whatever, file.xreadlines())

blows up with

    TypeError: argument 2 to map() must be a sequence object

The docs say both contexts require "a sequence", so this is baffling to them.

It's apparently because map() internally insists that the sq_length slot be
non-null (but it's null in the xreadlines object), despite that map() doesn't
use it for anything other than *guessing* a result size (it keeps going until
IndexError is raised regardless of what len() returns, growing or shrinking
the preallocated result list as needed).

I think that's a bug in map().  Anyone disagree?

If so, fine, map() has to be changed to work with iterators anyway <wink>.

How are we going to identify all the places that need to become
iterator-aware, get all the code changed, and update the docs to match?  In
effect, a bunch of docs for arguments need to say, in some words or other,
that the args must implement the iterator interface or protocol.  I think
it's essential that we define the latter only once.  But the docs don't
really define any interfaces/protocols now, so it's unclear where to put
that.

Fred, Pronounce.  Better sooner than later, else I bet a bunch of code
changes will get checked in without appropriate doc changes, and the 2.2 docs
won't match the code.




From martin at loewis.home.cs.tu-berlin.de  Sat Apr 28 09:28:35 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 28 Apr 2001 09:28:35 +0200
Subject: [Python-Dev] SF changing directory structure
Message-ID: <200104280728.f3S7SZ801219@mira.informatik.hu-berlin.de>

> Nobody is in charge: if you know of a problem, please fix it.  All
> the HTML stuff is under CVS control, and all Python project members
> have commit access for it, same as for everything else in the Python
> source tree; it's just under the nondist branch instead of the dist
> branch.

Ok, changed in CVS. Is the answer to SF-FAQ question 1.3 still
correct? That modified files have to manually uploaded to SF? That
answer does not mention nondist/sf-html at all...

Regards,
Martin



From tim.one at home.com  Sat Apr 28 09:48:50 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 28 Apr 2001 03:48:50 -0400
Subject: [Python-Dev] RE: SF changing directory structure
In-Reply-To: <200104280728.f3S7SZ801219@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCKECLJPAA.tim.one@home.com>

[Martin v. Loewis]
> Ok, changed in CVS.

Thank you!

> Is the answer to SF-FAQ question 1.3 still correct?
> That modified files have to manually uploaded to SF?

AFAIK, yes.  I didn't write the question or the answer, though, and don't
believe I read that part of the FAQ before.  /F's pep2html.py script is used
to generate the HTML form of PEPs, and its -i (install) option never worked
for me on Windows, so I've always done that bit by hand.

Indeed, your changes didn't *show up* via the SF interface before I (just)
did

scp sf-faq.html \
    tim_one at shell.sourceforge.net:/home/groups/p/py/python/htdocs/

> That answer does not mention nondist/sf-html at all...

It apparently doesn't mention a lot of things.  But I'm not going to change
it since I don't have a clear understanding of how this stuff works; I only
know what I do by hand that works in the end.




From moshez at zadka.site.co.il  Sat Apr 28 11:07:43 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Sat, 28 Apr 2001 12:07:43 +0300
Subject: [Python-Dev] Iterators, map, xreadlines and docs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
Message-ID: <E14tQhb-0004Dd-00@darjeeling>

On Sat, 28 Apr 2001 03:24:48 -0400, "Tim Peters" <tim.one at home.com> wrote:

> A confused user on c.l.py reported that while
> 
>     for x in file.xreadlines():
> 
> works fine,
> 
>     map(whatever, file.xreadlines())
> 
> blows up with
> 
>     TypeError: argument 2 to map() must be a sequence object
...
> I think that's a bug in map().  Anyone disagree?

I agree...but when we talked about it in c.l.py, I said that and you
said map() should be deprecated. Why the sudden change of heart?
why shouldn't it be changed to

[whatever(x) for x in file.xreadlines()]?

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From tim.one at home.com  Sat Apr 28 11:17:33 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 28 Apr 2001 05:17:33 -0400
Subject: [Python-Dev] Iterators, map, xreadlines and docs
In-Reply-To: <E14tQhb-0004Dd-00@darjeeling>
Message-ID: <LNBBLJKPBEHFEDALKOLCGECNJPAA.tim.one@home.com>

> ...
>> I think that's a bug in map().  Anyone disagree?

[Moshe]
> I agree...but when we talked about it in c.l.py, I said that and you
> said map() should be deprecated. Why the sudden change of heart?

This doesn't ring a bell.  I don't even recall *seeing* a msg from you in the
.xreadlines() vs map() thread ...

> why shouldn't it be changed to
>
> [whatever(x) for x in file.xreadlines()]?

I'm not keen to eradicate map() from the face of the Earth regardless, and
until it *is* deprecated (if ever), it's supported.  But this is all moot
since I already checked in the map() fix.

How to deal with the iterator docs is still an important issue.




From moshez at zadka.site.co.il  Sat Apr 28 12:14:33 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Sat, 28 Apr 2001 13:14:33 +0300
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.198,2.199
In-Reply-To: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>
References: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <E14tRkH-0004KU-00@darjeeling>

On Sat, 28 Apr 2001, Tim Peters <tim_one at users.sourceforge.net> wrote:

> Modified Files:
> 	bltinmodule.c 
> Log Message:
> Fix buglet reported on c.l.py:  map(fnc, file.xreadlines()) blows up.
> Also a 2.1 bugfix candidate (am I supposed to do something with those?).
> Took away map()'s insistence that sequences support __len__, and cleaned
> up the convoluted code that made it *look* like it really cared about
> __len__ (in fact the old ->len field was only *used* as a flag bit, as
> the main loop only looked at its sign bit, setting the field to -1 when
> IndexError got raised; renamed the field to ->saw_IndexError instead).

Can anyone give me his opinion about whether 2.0.1 should have this
bug fix? It's not just for file.xreadlines(): the older fileinput.fileinput()
is hurt by this as well...

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From fdrake at acm.org  Sat Apr 28 14:50:54 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sat, 28 Apr 2001 08:50:54 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.198,2.199
In-Reply-To: <E14tRkH-0004KU-00@darjeeling>
References: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>
	<E14tRkH-0004KU-00@darjeeling>
Message-ID: <15082.48302.168082.219299@cj42289-a.reston1.va.home.com>

Moshe Zadka writes:
 > Can anyone give me his opinion about whether 2.0.1 should have this
 > bug fix? It's not just for file.xreadlines(): the older
 > fileinput.fileinput() is hurt by this as well...

  I don't know about 2.0.1, but 2.1.1 definately should.


  -Fred

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




From guido at digicool.com  Sat Apr 28 19:11:13 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 28 Apr 2001 12:11:13 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.198,2.199
In-Reply-To: Your message of "Sat, 28 Apr 2001 13:14:33 +0300."
             <E14tRkH-0004KU-00@darjeeling> 
References: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>  
            <E14tRkH-0004KU-00@darjeeling> 
Message-ID: <200104281711.MAA29948@cj20424-a.reston1.va.home.com>

> Can anyone give me his opinion about whether 2.0.1 should have this
> bug fix? It's not just for file.xreadlines(): the older fileinput.fileinput()
> is hurt by this as well...

I wouldn't bother -- 2.0.1 doesn't need to be better than 2.1.

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



From fdrake at acm.org  Sun Apr 29 03:41:04 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sat, 28 Apr 2001 21:41:04 -0400 (EDT)
Subject: [Python-Dev] Re: Iterators, map, xreadlines and docs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
Message-ID: <15083.28976.418924.738526@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > effect, a bunch of docs for arguments need to say, in some words or other,
 > that the args must implement the iterator interface or protocol.  I think
 > it's essential that we define the latter only once.  But the docs don't
 > really define any interfaces/protocols now, so it's unclear where to put
 > that.

  Won't there be at least one standard iterator object defined for
lists, etc.?  That could be described in the built-in types section
(as with files, lists, etc.) of the Library Reference.  That will be
used as the definition of the iterator protocol in the same way the
file object description there is referred to from places that want
file or file-like objects.
  I think we need some re-organization of the built-in types section
to separate abstract protocols from specific implementations, but
that's an orthagonal aspect and can be handled at the same time as the
rest of the built-in types.
  Specific changes for places that accept iterators should be made as
the code is changed, as usual.  Please describe the changes clearly in
checkin messages so iterator related changes don't propogate to the
maintenance branch.


  -Fred

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




From MarkH at ActiveState.com  Sun Apr 29 04:14:43 2001
From: MarkH at ActiveState.com (Mark Hammond)
Date: Sun, 29 Apr 2001 12:14:43 +1000
Subject: [Python-Dev] Slight wart in __all__
Message-ID: <LCEPIIGDJPKCOIHOBJEPKEBEDLAA.MarkH@ActiveState.com>

I just got caught out by this:

"""
def foo():
    pass

__all__ = [foo]
"""

Then at the interactive prompt:

>>> from foo import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: attribute name must be string


The problem is that __all__ contains a function object rather than a string
object.  I had to use the debugger to determine why I was getting the
failure :(  All you 2.1 veterans will immediately pick that it should read
'__all__ = ["foo"]'

Looking at the __all__ code:

		if (skip_leading_underscores &&
		    PyString_Check(name) &&
		    PyString_AS_STRING(name)[0] == '_')
		{
			Py_DECREF(name);
			continue;
		}
		value = PyObject_GetAttr(v, name);

PyObject_GetAttr explicitly handles string and unicode objects.  However,
code here won't like Unicode that much :)

Would it make sense to a explicitly raise a more meaningful exception here
if __all__ doesnt contain strings?




From tim.one at home.com  Sun Apr 29 05:17:47 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 28 Apr 2001 23:17:47 -0400
Subject: [Python-Dev] RE: Iterators, map, xreadlines and docs
In-Reply-To: <15083.28976.418924.738526@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEEAJPAA.tim.one@home.com>

[Fred]
>   Won't there be at least one standard iterator object defined for
> lists, etc.?

>>> iter([])
<iterator object at 00792640>

>>> iter({})
<dictionary-iterator object at 00793A40>

>>> iter(())
<iterator object at 00792640>

>>> import sys
>>> iter(sys.stdin)
<callable-iterator object at 00793FE0>

>>> class C:
...     def __iter__(self): return self
...
>>> iter(C())
<__main__.C instance at 007938EC>
>>>

What do those have in common?  Objects and types are the wrong way to
approach this one:  it's really of no interest that, e.g., iter(list) and
iter(dict) return objects of different types; what *is* interesting is that
iter(whatever) returns *an* object that conforms to the iterator protocol (or
"implements the iterator interface" -- all the same to me).  You can give
*examples* of builtin iterator types that conform to the protocol, but the
protocol needs to be defined for its own sake first.  The protocol is
fundamental, and is neither an object nor a type.

> That could be described in the built-in types section (as with
> files, lists, etc.) of the Library Reference.  That will be used
> as the definition of the iterator protocol in the same way the
> file object description there is referred to from places that want
> file or file-like objects.

"file-like objects" is the bad doc experience I'm hoping we don't repeat.
The phrase "file-like object" is indeed used freely in the docs, but it's not
(AFAICT) *defined* anywhere, and doesn't even appear in the index.  Besides,
the notion that "file-like object" refers to section

    Buitin-in Types, Exceptions and Functions ->
     Other Built-in Types ->
      File Objects

was news to me.  I see the individual method descriptions there sometimes
refer to "file-like objects", and other times "objects implementing a
file-like interface".  The latter phrase appears uniquely in the description
of .readlines(), and may be the clearest explanation in the docs of wtf
"file-like object" means.  If so, it shouldn't be buried in the bowels of one
method description.

>   I think we need some re-organization of the built-in types section
> to separate abstract protocols from specific implementations,

Yes.

> but that's an orthagonal aspect and can be handled at the same
> time as the rest of the built-in types.

I assume you're thinking of creating a new "Iterator Objects" section under
"Other Built-in Types"?  That would work for me if it *started* with a
description of the iterator interface/protocol.

There's a twist, though:  iterators need to be defined already in the
Language Reference manual (we can't explain for-loops without them anymore).

>   Specific changes for places that accept iterators should be made as
> the code is changed, as usual.  Please describe the changes clearly in
> checkin messages so iterator related changes don't propogate to the
> maintenance branch.

We need an example to build on -- this is too abstract for me (which is
saying something <wink>).

For example, today we have:

    list(sequence)
        Return a list whose items are the same and in the same order as
        sequence's items. If sequence is already a list, a copy is made
        and returned, similar to sequence[:]. For instance, list('abc')
        returns returns ['a', 'b', 'c'] and list( (1, 2, 3) )
        returns [1, 2, 3].

list() doesn't yet work with iterators, but surely will.  What do we want the
docs to say after it changes?  Should it be implicit or explicit that
"sequence" now means "sequence or sequence-like object"?  Where is the
connection between "sequence-like object" and "iterable" explained?  Perhaps
what's really needed is s/sequence/iterable/ in this description.  But then
where is "iterable" defined?

Solve this once and the rest should follow easily.  But solving it the first
time doesn't look easy to me.  That's why I'm bugging you now.




From mal at lemburg.com  Mon Apr 30 12:19:53 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 12:19:53 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
Message-ID: <3AED3C49.ACDD40E@lemburg.com>

Rebooting the thread...

While testing mxNumber, I discovered what looks like a bug in
Win95: both Thomas Heller and I are seeing a problem with 
Python 2.1 when importing extension modules which rely on other 
DLLs as library.

Interestingly, the problem only shows up when starting Python
from the installation directory. Looking at the imports using
python -vv shows that in this situation, Python tries to import
modules, packages, extensions etc. using *relative* paths.

Now, under Win98 there is no problem, but Win95 doesn't seem
to like these relative imports when it comes to .pyd files
which reference DLLs in the same directory. It doesn't have
any problems when Python is started outside the installation
dir, since in that case Python uses absolute paths for importing
modules and extensions.

Would it be hard to tweak Python into always using absolute search
paths during module import ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From guido at digicool.com  Mon Apr 30 15:21:49 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 30 Apr 2001 08:21:49 -0500
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: Your message of "Mon, 30 Apr 2001 12:19:53 +0200."
             <3AED3C49.ACDD40E@lemburg.com> 
References: <3AED3C49.ACDD40E@lemburg.com> 
Message-ID: <200104301321.IAA07476@cj20424-a.reston1.va.home.com>

> Would it be hard to tweak Python into always using absolute search
> paths during module import ?

I resist doing this *in general* because absolute paths don't always
mean the right thing on all platforms (and aren't always obtainable),
but I agree that for Windows this can and should be done.

The easiest way I can think of is for PC/getpathp.py to tweak the path
entries to be absolute pathnames.  A single getcwd() call should
suffice.

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



From MarkH at ActiveState.com  Mon Apr 30 14:23:23 2001
From: MarkH at ActiveState.com (Mark Hammond)
Date: Mon, 30 Apr 2001 22:23:23 +1000
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: <3AED3C49.ACDD40E@lemburg.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPIEBNDLAA.MarkH@ActiveState.com>

> Interestingly, the problem only shows up when starting Python
> from the installation directory. Looking at the imports using
> python -vv shows that in this situation, Python tries to import
> modules, packages, extensions etc. using *relative* paths.

I'm not quite with you here.  Are you saying both Win98 and 95 use relative
paths, but only Win95 has the problem, or that only Win95 sees relative
paths?

My Win98 box uses absolute paths for all imports when using -vv

> Would it be hard to tweak Python into always using absolute search
> paths during module import ?

Where are the relative paths coming from?  If we can determine that, we can
determine how hard it would be to fix ;-)

Mark.




From mal at lemburg.com  Mon Apr 30 14:53:21 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 14:53:21 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
References: <LCEPIIGDJPKCOIHOBJEPIEBNDLAA.MarkH@ActiveState.com>
Message-ID: <3AED6041.A3E3AE7B@lemburg.com>

Mark Hammond wrote:
> 
> > Interestingly, the problem only shows up when starting Python
> > from the installation directory. Looking at the imports using
> > python -vv shows that in this situation, Python tries to import
> > modules, packages, extensions etc. using *relative* paths.
> 
> I'm not quite with you here.  Are you saying both Win98 and 95 use relative
> paths, but only Win95 has the problem, or that only Win95 sees relative
> paths?

Both are using relative paths, but only Win95 has a problem with not
finding the DLL needed by a PYD file in a subpackage:

abc/
    __init__.py
    mxABC.pyd
    mamba.dll

mxABC.pyd needs mamba.dll.
 
> My Win98 box uses absolute paths for all imports when using -vv

Are you sure ? Please CD to the C:\Python21 dir and then try
to import and installed package (say mx.Tools from egenix-mx-base).
You should be seeing relative paths with -vv.
 
> > Would it be hard to tweak Python into always using absolute search
> > paths during module import ?
> 
> Where are the relative paths coming from?  If we can determine that, we can
> determine how hard it would be to fix ;-)

The relative paths come from the import logic: the current dir
is scanned first and if the package is found in that directory,
all subsequent lookups are done using relative paths.

While this is prefectly OK, Win95 seems to have a problem with
importing extensions using these relative paths. I think we could
solve the problem by making the pathname which is passed to
LoadLibraryEx() in dynload_win.c absolute.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From mal at lemburg.com  Mon Apr 30 14:54:54 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 14:54:54 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
References: <3AED3C49.ACDD40E@lemburg.com> <200104301321.IAA07476@cj20424-a.reston1.va.home.com>
Message-ID: <3AED609E.A7D9B454@lemburg.com>

Guido van Rossum wrote:
> 
> > Would it be hard to tweak Python into always using absolute search
> > paths during module import ?
> 
> I resist doing this *in general* because absolute paths don't always
> mean the right thing on all platforms (and aren't always obtainable),
> but I agree that for Windows this can and should be done.

I have only run into the problem with Win95, so yes, doing this
for Windows only should be OK (and even there it's probably only
needed for importing PYD files).
 
> The easiest way I can think of is for PC/getpathp.py to tweak the path
> entries to be absolute pathnames.  A single getcwd() call should
> suffice.

I'd rather keep the changes in dynload_win.c if that's possible.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From guido at digicool.com  Mon Apr 30 15:57:56 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 30 Apr 2001 08:57:56 -0500
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: Your message of "Mon, 30 Apr 2001 14:54:54 +0200."
             <3AED609E.A7D9B454@lemburg.com> 
References: <3AED3C49.ACDD40E@lemburg.com> <200104301321.IAA07476@cj20424-a.reston1.va.home.com>  
            <3AED609E.A7D9B454@lemburg.com> 
Message-ID: <200104301357.IAA07564@cj20424-a.reston1.va.home.com>

> I'd rather keep the changes in dynload_win.c if that's possible.

Fine with me.

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



From MarkH at ActiveState.com  Mon Apr 30 15:01:33 2001
From: MarkH at ActiveState.com (Mark Hammond)
Date: Mon, 30 Apr 2001 23:01:33 +1000
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: <3AED6041.A3E3AE7B@lemburg.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPIEBODLAA.MarkH@ActiveState.com>

> abc/
>     __init__.py
>     mxABC.pyd
>     mamba.dll
>
> mxABC.pyd needs mamba.dll.
>
> > My Win98 box uses absolute paths for all imports when using -vv
>
> Are you sure ? Please CD to the C:\Python21 dir and then try

Right - I am with you now...

> importing extensions using these relative paths. I think we could
> solve the problem by making the pathname which is passed to
> LoadLibraryEx() in dynload_win.c absolute.

Just calling GetFullPathName() before the LoadLibEx() would seem a
reasonable and appropriate patch.  Keeps it a long way from the "*in
general*" Guido was concerned about, and sounds low-risk to me!

Ahh - Guido just OK'd it, so go for it ;-)

Mark.




From mal at lemburg.com  Mon Apr 30 16:10:16 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 16:10:16 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
References: <LCEPIIGDJPKCOIHOBJEPIEBODLAA.MarkH@ActiveState.com>
Message-ID: <3AED7248.B7386B83@lemburg.com>

Mark Hammond wrote:
> 
> > abc/
> >     __init__.py
> >     mxABC.pyd
> >     mamba.dll
> >
> > mxABC.pyd needs mamba.dll.
> >
> > > My Win98 box uses absolute paths for all imports when using -vv
> >
> > Are you sure ? Please CD to the C:\Python21 dir and then try
> 
> Right - I am with you now...
> 
> > importing extensions using these relative paths. I think we could
> > solve the problem by making the pathname which is passed to
> > LoadLibraryEx() in dynload_win.c absolute.
> 
> Just calling GetFullPathName() before the LoadLibEx() would seem a
> reasonable and appropriate patch.  Keeps it a long way from the "*in
> general*" Guido was concerned about, and sounds low-risk to me!
> 
> Ahh - Guido just OK'd it, so go for it ;-)

Here's a stab at a patch. Could you review it and test it ? I
don't have enough knowledge of win32 for this...

dynload_win.c:
...
#ifdef MS_WIN32
	{
		HINSTANCE hDLL;
		char pathbuf[260];
		LPTSTR *dummy;
		
		if (strchr(pathname, '\\') == NULL &&
		    strchr(pathname, '/') == NULL)
		{
			/* Prefix bare filename with ".\" */
			char *p = pathbuf;
			*p = '\0';
			_getcwd(pathbuf, sizeof pathbuf);
			if (*p != '\0' && p[1] == ':')
				p += 2;
			sprintf(p, ".\\%-.255s", pathname);
			pathname = pathbuf;
		}
		/* Convert to full pathname; we ignore errors to maintain
		   b/w compatibility here. */
		if (GetFullPathName(pathname,
				    sizeof(pathbuf),
				    pathbuf,
				    &dummy))
		    pathname = pathbuf;
		/* Look for dependent DLLs in directory of pathname first */
		/* XXX This call doesn't exist in Windows CE */
		if (pathname)
		    hDLL = LoadLibraryEx(pathname, NULL,
					 LOAD_WITH_ALTERED_SEARCH_PATH);
		if (hDLL == NULL) {
			char errBuf[256];
			unsigned int errorCode;
...

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From michel at digicool.com  Mon Apr 30 20:39:38 2001
From: michel at digicool.com (Michel Pelletier)
Date: Mon, 30 Apr 2001 11:39:38 -0700 (PDT)
Subject: [Python-Dev] RE: Iterators, map, xreadlines and docs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEEAJPAA.tim.one@home.com>
Message-ID: <Pine.LNX.4.21.0104301049590.7346-100000@localhost.localdomain>

On Sat, 28 Apr 2001, Tim Peters wrote:

> What do those have in common?  Objects and types are the wrong way to
> approach this one:  it's really of no interest that, e.g., iter(list) and
> iter(dict) return objects of different types; what *is* interesting is that
> iter(whatever) returns *an* object that conforms to the iterator protocol (or
> "implements the iterator interface" -- all the same to me).  

I have added a notional iter interface to the PEP 245 prototype and will
be making another release of it later tonight.

> "file-like objects" is the bad doc experience I'm hoping we don't repeat.
> The phrase "file-like object" is indeed used freely in the docs, but it's not
> (AFAICT) *defined* anywhere, and doesn't even appear in the index.  Besides,
> the notion that "file-like object" refers to section
> 
>     Buitin-in Types, Exceptions and Functions ->
>      Other Built-in Types ->
>       File Objects
> 
> was news to me.  I see the individual method descriptions there sometimes
> refer to "file-like objects", and other times "objects implementing a
> file-like interface".  The latter phrase appears uniquely in the description
> of .readlines(), and may be the clearest explanation in the docs of wtf
> "file-like object" means.  If so, it shouldn't be buried in the bowels of one
> method description.

245 takes a couple stabs at File interfaces, trying to satisfy the
bare-bones kind of file, a Python File, StringI, StringO etc...

> >   I think we need some re-organization of the built-in types section
> > to separate abstract protocols from specific implementations,
> 
> Yes.

FYI, 245 defines the following interfaces.  Some of them may be wrong,
I took most of this straight from the Pydocs and stuff done by Jim:

  Mutable
  
  Comparable

  Orderable(Comparable)

  Hashable
  
  Hashkey(Comparable, Hashable)

  Membership

  Mapping

  Sized

  MutableMapping(Mutable)    

  Sequence(Mapping)

  Sequential(Sequential)

  Type

  Null

  String(Sequence, Sized)

  Tuple(Sequence, Sized)

  List(Mapping, MutableMapping, Sequence, Sized)

  Dictionary(Mapping, MutableMapping, Sized)

  File - and the various specific file functionality

  Module

  Class

  Function

  InstanceMethod

  Exception

  Number - Real, Compex, Exact, others....

Here are some examples from the current prototype.  The primary
utility function from PEP 245 is 'does':

    Python 2.1 (#1, Apr 22 2001, 06:33:07) 
    [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
    Type "copyright", "credits" or "license" for more information.
    >>> from Interface import does

'does' can be used two ways.  The first way is to pass imp an object
and it will return the interfaces that the object implements:

    >>> does({})
    [<Interface Dictionary at 82e288c>]
    >>> does([])
    [<Interface List at 82c71f4>]
    >>> does(sys.stdin)
    [<Interface PyFile at 8261e54>]
    >>> def f(): pass
    ...
    >>> does(f)
    [<Interface Function at 82ff134>]

Here, we see that a dictionary and a list do the 'Dictionary' and
'List' interfaces respectively, and that files and functions also
implement interfaces.  'does' can also be used with another argument,
to ask whether the object implements a certain interface:

    >>> from Interface.Protocols import Mapping, Sequence, Mutable
    >>> from Interface.File import File
    >>> does({}, Mapping)
    1
    >>> does([], Sequence)
    1
    >>> does((), Mutable)
    0
    >>> does({}, Dictionary)
    1
    >>> does(sys.stdin, File)
    1

Note that PEP 245 requires NO changes to Python.  You can download it
now and try this stuff out.

-Michel






From michel at digicool.com  Mon Apr 30 21:48:25 2001
From: michel at digicool.com (Michel Pelletier)
Date: Mon, 30 Apr 2001 12:48:25 -0700 (PDT)
Subject: [Python-Dev] RE: Iterators, map, xreadlines and docs
In-Reply-To: <Pine.LNX.4.21.0104301049590.7346-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0104301247450.7346-100000@localhost.localdomain>

On Mon, 30 Apr 2001, Michel Pelletier wrote:

> On Sat, 28 Apr 2001, Tim Peters wrote:
> 
> I have added a notional iter interface to the PEP 245 prototype and will
> be making another release of it later tonight.

I forgot to mention that you can get the previous release (without
iter) here:

http://www.zope.org/Members/michel/InterfacesPEP/Interface.tgz

-Michel




From tim.one at home.com  Sun Apr  1 06:27:48 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 31 Mar 2001 23:27:48 -0500
Subject: [Python-Dev] nano-threads?
In-Reply-To: <20010326210824.B17390@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>

[Neil Schemenauer
 Tuesday, March 27, 2001 12:08 AM
]
> Here are some silly bits of code implementing single frame
> coroutines and threads using my frame suspend/resume patch.
> ...
> If your sick of such postings on python-dev flame me privately
> and I will stop.

Since the postings stopped there, did someone flame you?  I'm projecting my
own situtation onto everyone else, namely that this is interesting but I
can't make time for it now.  If you're still playing with this, though, I
hope you do continue to let Python-Dev know how it's going!

the-archives-house-many-wonders-ly y'rs  - tim




From fredrik at pythonware.com  Sun Apr  1 11:38:42 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 1 Apr 2001 11:38:42 +0200
Subject: [Python-Dev] nano-threads?
References: <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>
Message-ID: <044d01c0ba8f$8c0e4910$e46940d5@hagrid>

tim wrote:
> > If your sick of such postings on python-dev flame me privately
> > and I will stop.
> 
> Since the postings stopped there, did someone flame you?

well, I threatened to flame Neil if he stopped working on this...

Sorry /F




From fdrake at acm.org  Sun Apr  1 17:55:48 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sun, 1 Apr 2001 11:55:48 -0400 (EDT)
Subject: [Python-Dev] Parro-DL -- new documentation project
Message-ID: <15047.20356.586507.158341@beowolf.pythonlabs.org>

Announcing a new joint documentation effort...


                                  Parro-DL

                        Parrot Documentation Language


With the public announcement of the development of Parrot (see
http://use.perl.org/article.pl?sid=01/03/31/206248 and
http://www.python.org/parrot.htm), a new documentation effort is being
initiated to provide developer information on the new language and its
libraries.

Guido van Rossum and Larry Wall, joint creators of the new language,
are both aware of the significance of quality documentation in the
adoption of Parrot.  Shortly after the decision to create Parrot, they
enlisted Fred Drake and Tom Christiansen to begin work on the
documentation system for Parrot.  The two advocates of language and
library documentation have collaborated privately for the past six
months to design a new markup language that can be embedded into the
language or used indepentently, similar to POD, but which allows
richer semantic markup similar to the LaTeX-based markup used by the
Python documentation project.

Drake and Christiansen expect to release the reference manual for the
new markup language, call Parro-DL (for "Parrot Documentation
Language") within two weeks.  The specification, which weighs in at
about 150 typeset pages, was written in Parro-DL and is processed by
new tools written using an early prototype interpreter for the Parrot
language.  The specification includes information on syntax,
linguistic integration, and processing expectations.  ISO
standardization is expected to be complete in 3rd quarter of 2006.

Drake and Christiansen are joining their efforts to organize a
documentation project dedicated to producing free documentation for
Parrot to avoid a monopoly on the reference documentation by the
technical publisher O'Reilly.  The effort will be subsidized by their
new joint venture, Iterpolated Documentation Systems.  Offices for the
new firm will be located in Chicago.  Drake's separation from
PythonLabs came as a surprise to his colleagues there.



  -Fred

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




From nas at python.ca  Sun Apr  1 19:51:50 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sun, 1 Apr 2001 10:51:50 -0700
Subject: [Python-Dev] nano-threads?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>; from tim.one@home.com on Sat, Mar 31, 2001 at 11:27:48PM -0500
References: <20010326210824.B17390@glacier.fnational.com> <LNBBLJKPBEHFEDALKOLCMEJBJJAA.tim.one@home.com>
Message-ID: <20010401105150.A9246@glacier.fnational.com>

Tim Peters wrote:
> Since the postings stopped there, did someone flame you?

No.

> I'm projecting my own situtation onto everyone else, namely
> that this is interesting but I can't make time for it now.

I got that impression.  I'll try to provoke some interest after
2.1 is released.  For now, I'm spending my spare time studying
stackless (among other things).

> If you're still playing with this, though, I hope you do
> continue to let Python-Dev know how it's going!

Okay.

  Neil



From jeremy at alum.mit.edu  Sun Apr  1 21:00:57 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Sun, 1 Apr 2001 15:00:57 -0400 (EDT)
Subject: [Python-Dev] Perl and Python to begin joint development
Message-ID: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>

[FYI:  This press release was also sent to c.l.py.a.  Dan and I expect
to have the release schedule PEP ready soon.  And, yes, that's Parrot
Enhancement Proposal (PEP). --jeremy]

04/01/2001
SEBASTOPOL, CA

Perl and Python to begin joint development

Larry Wall, the creator of Perl, and Guido van Rossum, creator of
Python, today announced that their respective projects are about to
begin a period of joint development. 

According to the language designers, the idea surfaced at last year's
Open Source Convention - "We at the Perl Conference were aware of a need
for a new direction for Perl and for its community, and that's why we
announced the work on Perl 6," said an excited Wall. "At the same time,
Guido was thinking very hard about Python 2.0 and where it was going,
and we got together and started talking about helping each other out."

Initially, the pair planned to have their development communities
working together for mutual benefit. van Rossum cited some of the
technical reasons for the collaboration: "Perl's highly powerful regular
expression engine would be integrated into Python, and would benefit us
greatly; in return, we've got a number of things right that Perl could
gain from, such as signal handling and robust software engineering."

However, as both designers talked about the changes their languages were
going through, they came to the conclusion that they had much to share
at the language level as well as the interpreter level. According to
Larry Wall, "Perl's always been about taking the best features of all
the other languages available; it's perfectly natural for us to
integrate the best features of Python too."

The specifications for the combined language, called Parrot, will be
documented in the forthcoming book "Programming Parrot In A Nutshell",
to be published by O'Reilly and Associates. In the meantime, the Python
Software Foundation is said to be making arrangements to merge with Yet
Another Society. YAS president Kevin Lenzo was delighted at the move:
"It's a natural extension of what YAS was set up to facilitate -
collaboration and communication between programming communities."

Parrot development will begin with the merger of the Py3K development
team with the Perl 6 internals working group; Jeremy Hylton and Dan
Sugalski will be the joint development leads.

Larry Wall and Guido van Rossum both accepted positions at the Vancouver,
Canada development company ActiveState. A spokesman for ActiveState said
that the company was obviously very pleased with the decision, but
denied that ActiveState had influenced it in any way.



From jeremy at alum.mit.edu  Sun Apr  1 21:27:34 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Sun, 1 Apr 2001 15:27:34 -0400 (EDT)
Subject: [Python-Dev] Re: Perl and Python to begin joint development
In-Reply-To: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>
References: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <15047.33062.39302.211557@w221.z064000254.bwi-md.dsl.cnc.net>

It seems that the folks at O'Reilly are working overtime this weekend.
The Parrot book announcement, which I didn't expect to see until
mid-week, is already available at http://www.ora.com.

You can also read an interview with Guido and Larry Wall at
http://www.perl.com.

Barry should be checking in PEP 250 (Parrot Release Schedule) as soon
as he converts it from POD to the PEP format.  

Jeremy



From barry at digicool.com  Mon Apr  2 04:39:40 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Sun, 1 Apr 2001 22:39:40 -0400
Subject: [Python-Dev] Re: Perl and Python to begin joint development
References: <15047.31465.562153.891933@w221.z064000254.bwi-md.dsl.cnc.net>
	<15047.33062.39302.211557@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <15047.58988.606995.260675@anthem.wooz.org>

>>>>> "JH" == Jeremy Hylton <jeremy at alum.mit.edu> writes:

    JH> Barry should be checking in PEP 250 (Parrot Release Schedule)
    JH> as soon as he converts it from POD to the PEP format.

Sorry, I think that's going to be PEP 0401 instead.

-Barry



From Paul.Moore at uk.origin-it.com  Mon Apr  2 11:09:07 2001
From: Paul.Moore at uk.origin-it.com (Moore, Paul)
Date: Mon, 2 Apr 2001 10:09:07 +0100 
Subject: [Python-Dev] PEP: Use site-packages on all platforms
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADDB@ukrux002.rundc.uk.origin-it.com>

From: Guido van Rossum [mailto:guido at digicool.com]
> 
> I think this is a good idea.  Submit the PEP to Barry!

Done.

> I doubt that we can introduce this into Python 2.1 this late in the
> release cycle.  Would that be a problem?

I thought as much. I can't see it being a major issue. My only concern (as
noted in the PEP) is that with distutils becoming more commonly used, there
will be more and more packages installed using distutils, and so ending up
in the directory which distutils uses by default. The longer it is before
the change is made, the more of a mixed setup people will have. But then
again, (a) the change is backward-compatible, and (b) extension modules will
need recompiling (and reinstalling) anyway. So no, 2.2 seems OK.

Hmm, that does raise one issue - if people rebuild and reinstall after the
change, the reinstall won't overwrite the old version. As a consequence,
there will be an old version on sys.path, with the potential for a crash...
Of course, people should uninstall before reinstalling, so it shouldn't be a
problem. Making distutils search for old versions would be possible, but it
seems like major overkill...

I'll assume this is for 2.2, and that the reinstall-not-overwriting problem
isn't an issue. I'll note the details in the PEP.

Paul.



From thomas.heller at ion-tof.com  Mon Apr  2 19:02:11 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Mon, 2 Apr 2001 19:02:11 +0200
Subject: [Python-Dev] Making types behave like classes
References: <3ABBF553.274D535@ActiveState.com>
Message-ID: <052a01c0bb96$a8b1b180$e000a8c0@thomasnotebook>

> These are some half-baked ideas about getting classes and types to look
> more similar.

Somewhat different thoughts:

Which limitations are there in python as a consequence
of the type/class split?

In python code itself, it is not too bad. Instead of deriving
from builtin types, you can always delegate to them.

In c-code, the situation is worse, on the other hand,
ExtensionClass comes to rescue. Write the base class in C,
subclass in python.

The worst limitation is in the most useful builtin object:
the dictionary. One can use or derive from UserDict,
but one cannot pass UserDict instances or other homegrown dict
lookalikes to exec, you cannot use them as class or instance
dictionaries.

If this limitation would be removed, you could implement your
own rules in namespaces: readonly, case insentitive, whatever.
One could even implement a mapping object in a C extension,
and use it in the aforementioned ways.

IMO this limitation would be easy to remove:
The current PyDict_* API could be implemented in terms of
the PyMapping_ and PyObject_ protocol, using different code
depending on the outcome of an additional PyDict_Check() test.

The performance hit would be rather small.

Thomas




From pf at artcom-gmbh.de  Tue Apr  3 01:19:33 2001
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 3 Apr 2001 01:19:33 +0200 (MEST)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
Message-ID: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de>

At the moment it is very silent on Python-dev.  I guess you guys are
all out hunting dead parrots, which escaped from the cages on April 1st. ;-)

So this might be the right moment to present a possibly bad idea (TM).
see below.
Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen, Germany)

PEP: XXXX
Title: String Scanning
Version: $Revision$
Author: pf at artcom-gmbh.de (Peter Funk)
Status: Not yet Draft
Type: Standards Track
Python-Version: 2.2 
Created: 02-Apr-2001
Post-History:

Abstract

    This document proposes a string scanning feature for Python to
    allow easier string parsing.  The suggested syntax change is to
    allow the use of the division '/' operator for string operands
    as counterpart to the already existing '%' string interpolation
    operator.  In current Python this raises an exception: 'TypeError:
    bad operand type(s) for /'.  With the proposed enhancement the
    expression string1 / format2 should either return a simple value,
    a tuple of values or a dictionary depending on the content of
    the right operand (aka. format) string.


Copyright

    This document is in the public domain.


Specification

    The feature should mimic the behaviour of the scanf function
    well known to C programmers.  For any format string sf and any
    matching input string si the following pseudo condition should 
    be true:

        string.split( sf % (si / sf) ) == string.split( si )

    That is modulo any differences in white space the result of the
    string interpolation using the intermediate result from the string
    scanning operation should look similar to original input string.

    All conversions are introduced by the % (percent sign) character.  
    The format string may also contain other characters.  White space 
    (such as blanks, tabs, or newlines) in the format string match any  
    amount of white space, including none, in the input.  Everything
    else matches only itself.  Scanning stops when an input character  
    does not match such a format character.  Scanning also stops when 
    an input conversion cannot be made (see below).


Examples

    Here is an example of an interactive session exhibiting the
    expected behaviour of this feature.

        >>> "12345 John Doe" / "%5d %8s"
        (12345, 'John Doe')
        >>> "12 34 56 7.890" / "%d %d %d %f"
        (12, 34, 56, 7.8899999999999997)
        >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
        {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
        >>> "1 2" / "%d %d %d"
        Traceback (innermost last):
          File "<stdin>", line 1, in ?
        TypeError: not all arguments filled


Discussion

    This should fix the assymetry between arithmetic types and strings.
    It should also make the life easier for C programmers migrating to
    Python (see FAQ 4.33).  Those poor souls are acustomed to scanf
    as the counterpart of printf and usually feel uneasy to convert
    to string slitting, slicing or the syntax of regular expressions.


Security Issues

    There should be no security issues.


Implementation

    There is no implementation yet.  This is just an idea.
   


Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:




From guido at digicool.com  Tue Apr  3 03:43:24 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 02 Apr 2001 20:43:24 -0500
Subject: [Python-Dev] Python9 footage on www.technetcast.com
Message-ID: <200104030143.UAA04839@cj20424-a.reston1.va.home.com>

Dr. Dobb's technetcast is playing audio and video footage from
Python9: video of a brief interview with me, and (coming up next?)
audio from the two keynotes (Bruce Eckel's and mine).  Go to

    www.technetcast.com

(RealAudio support required, I believe.)

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



From guido at digicool.com  Tue Apr  3 03:51:06 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 02 Apr 2001 20:51:06 -0500
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: Your message of "Tue, 03 Apr 2001 01:19:33 +0200."
             <m14kDbi-000CnFC@artcom0.artcom-gmbh.de> 
References: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de> 
Message-ID: <200104030151.UAA04918@cj20424-a.reston1.va.home.com>

Peter, if you can do a prototype implementation (in Python would be
best), the idea might be received better.

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



From paulp at ActiveState.com  Tue Apr  3 03:06:49 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Mon, 02 Apr 2001 18:06:49 -0700
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
References: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <3AC92229.A5566E6A@ActiveState.com>

Peter Funk wrote:
> 
> 
>         >>> "12345 John Doe" / "%5d %8s"
>         (12345, 'John Doe')
>         >>> "12 34 56 7.890" / "%d %d %d %f"
>         (12, 34, 56, 7.8899999999999997)
>         >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
>         {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
>         >>> "1 2" / "%d %d %d"
>         Traceback (innermost last):
>           File "<stdin>", line 1, in ?
>         TypeError: not all arguments filled

I would prefer "foo".scanf("%5d %8s") or maybe "parse" or "parseformats"
or something like that. I know that punctuation abuse leads inexorably
to further punctuation abuse but the cycle must stop somewhere. It's too
late for "%" but let's save "/" while we still can!
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From thomas at xs4all.net  Tue Apr  3 09:09:28 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Tue, 3 Apr 2001 09:09:28 +0200
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <3AC92229.A5566E6A@ActiveState.com>; from paulp@ActiveState.com on Mon, Apr 02, 2001 at 06:06:49PM -0700
References: <m14kDbi-000CnFC@artcom0.artcom-gmbh.de> <3AC92229.A5566E6A@ActiveState.com>
Message-ID: <20010403090928.A2820@xs4all.nl>

On Mon, Apr 02, 2001 at 06:06:49PM -0700, Paul Prescod wrote:
> Peter Funk wrote:

> >         >>> "12345 John Doe" / "%5d %8s"
> >         (12345, 'John Doe')
> >         >>> "12 34 56 7.890" / "%d %d %d %f"
> >         (12, 34, 56, 7.8899999999999997)
> >         >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
> >         {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
> >         >>> "1 2" / "%d %d %d"
> >         Traceback (innermost last):
> >           File "<stdin>", line 1, in ?
> >         TypeError: not all arguments filled

> I would prefer "foo".scanf("%5d %8s") or maybe "parse" or "parseformats"
> or something like that. I know that punctuation abuse leads inexorably
> to further punctuation abuse but the cycle must stop somewhere. It's too
> late for "%" but let's save "/" while we still can!

Agreed, on both issues. We don't have 'printf', lets not use something as
inexplicable as 'scanf'!

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From pf at artcom-gmbh.de  Tue Apr  3 10:35:02 2001
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 3 Apr 2001 10:35:02 +0200 (MEST)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <200104030151.UAA04918@cj20424-a.reston1.va.home.com> from Guido van Rossum at "Apr 2, 2001  8:51: 6 pm"
Message-ID: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>

Guido van Rossum:
> Peter, if you can do a prototype implementation (in Python would be
> best), the idea might be received better.

I believe a strawman derived from the UserString class could be done
in pure Python.  But I'm sorry: I've no time for this during April.

I'm also not sure, whether this is really a worthwile effort and whether
I should champion this idea further.  From Pauls response I got the
impression that people already consider the '%' string interpolation
operator as a language wart rather than an elegant feature.

I however often like the infix notation better.  
That may be a matter of taste.  Imagine we would have to write:
	"%5d %20s %s\n".printf((num, name, adr))
instead of
	"%5d %20s %s\n" % (num, name, adr)
I'm happy, that this is not the case in todays Python.

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen, Germany)




From guido at digicool.com  Tue Apr  3 14:12:50 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 03 Apr 2001 07:12:50 -0500
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: Your message of "Tue, 03 Apr 2001 10:35:02 +0200."
             <m14kMHG-000CnFC@artcom0.artcom-gmbh.de> 
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de> 
Message-ID: <200104031212.HAA06304@cj20424-a.reston1.va.home.com>

> > Peter, if you can do a prototype implementation (in Python would be
> > best), the idea might be received better.
> 
> I believe a strawman derived from the UserString class could be done
> in pure Python.  But I'm sorry: I've no time for this during April.

Oh well, maybe someone else will like the idea.

> I'm also not sure, whether this is really a worthwile effort and whether
> I should champion this idea further.  From Pauls response I got the
> impression that people already consider the '%' string interpolation
> operator as a language wart rather than an elegant feature.

Well, that was one response.  Besides, it's easy to factor out two
separate design decisions: (1) a string scanning mechanism that takes
two strings (a format and an input string) and returns one or more
values extracted from the input string according to the rules set by
the format string, and (2) how to spell this: scanf(format, input) or
format/input or input/format or whatever.

> I however often like the infix notation better.  

See my two examples above for a concern: already I cannot recall
whether your PEP proposes format/input or input/format.  That's a bad
sign for either spelling. :-)

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



From pf at artcom-gmbh.de  Tue Apr  3 13:44:00 2001
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 3 Apr 2001 13:44:00 +0200 (MEST)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <200104031212.HAA06304@cj20424-a.reston1.va.home.com> from Guido van Rossum at "Apr 3, 2001  7:12:50 am"
Message-ID: <m14kPE8-000CnFC@artcom0.artcom-gmbh.de>

Guido van Rossum:
[...]
> Well, that was one response.  Besides, it's easy to factor out two
> separate design decisions: (1) a string scanning mechanism that takes
> two strings (a format and an input string) and returns one or more
> values extracted from the input string according to the rules set by
> the format string, and (2) how to spell this: scanf(format, input) or
> format/input or input/format or whatever.
> 
> > I however often like the infix notation better.  
> 
> See my two examples above for a concern: already I cannot recall
> whether your PEP proposes format/input or input/format.  That's a bad
> sign for either spelling. :-)

Hmmm.... May be I've stressed the analogy to arithmetic a bit to far:

If the string interpolation operator were '*' instead of '%'
then you could think of "multiplying" a format string with one
or more values gives a result string which than represents some kind of
"product".  Taking this result string now as input to the scanning
operation is some kind of "division" reverting the previous string
interpolation operation.  From that POV it would be pretty obvious,
that "dividing" the input string by the format string as denominator
returns the values previously formatted into it.

But since the string interpolation operator is '%' the analogy from
multiplication to formatting is obviously not at all that obvious.  :-(

Regards, Peter




From michel at digicool.com  Tue Apr  3 19:54:24 2001
From: michel at digicool.com (Michel Pelletier)
Date: Tue, 3 Apr 2001 10:54:24 -0700 (PDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.LNX.4.32.0104031052400.11179-100000@localhost.localdomain>

On Tue, 3 Apr 2001, Peter Funk wrote:

> I'm also not sure, whether this is really a worthwile effort and whether
> I should champion this idea further.  From Pauls response I got the
> impression that people already consider the '%' string interpolation
> operator as a language wart rather than an elegant feature.

It is one seriously useful wart!

> I however often like the infix notation better.
> That may be a matter of taste.  Imagine we would have to write:
> 	"%5d %20s %s\n".printf((num, name, adr))
> instead of
> 	"%5d %20s %s\n" % (num, name, adr)
> I'm happy, that this is not the case in todays Python.

Agreed.  I like your proposal.

-Michel




From paul at pfdubois.com  Wed Apr  4 01:22:32 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Tue, 3 Apr 2001 16:22:32 -0700
Subject: [Python-Dev] Re: s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <E14kTFV-0001wa-00@mail.python.org>
Message-ID: <ADEOIFHFONCLEEPKCACCMEKACHAA.paul@pfdubois.com>

Well, as usual I have a complete lack of aesthetic judgment because *I*
thought it was a great idea.

I could just picture my scientists parsing input lines from data files with
it. A similar feature in Basis is heavily used.

Then again, I *love* s % f. See, I'm totally sick.




From paulp at ActiveState.com  Wed Apr  4 01:45:54 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Tue, 03 Apr 2001 16:45:54 -0700
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <3ACA60B2.6B09B36D@ActiveState.com>

Peter Funk wrote:
> 
> ...
> 
> I however often like the infix notation better.
> That may be a matter of taste.  Imagine we would have to write:
>         "%5d %20s %s\n".printf((num, name, adr))
> instead of
>         "%5d %20s %s\n" % (num, name, adr)
> I'm happy, that this is not the case in todays Python.

Either way it is infix (as opposed to prefix or postfix). The question
is whether it is an infix *operator* or a method.

I believe that the only thing aesthetically wrong with this:

"%5d %20s %s\n".insert(num, name, adr)

is that people are not "used" to seeing method invocations on literal
strings. But then new Python programmers are not used to seeing people
divide or mod strings either!

And the nice thing about using a method name is that you can look method
names up in the indexes of books easily and even guess the meaning of
them from their English meanings. Symbols are (IMHO) best reserved for
usages where their meanings are already set by real-world convention.
(i.e. 5+3!)

If some other language convinces millions of programmers that string
division is natural then we could follow suit but I'd rather not lead
the way.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From tim.one at home.com  Wed Apr  4 02:05:50 2001
From: tim.one at home.com (Tim Peters)
Date: Tue, 3 Apr 2001 20:05:50 -0400
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>

[Peter Funk]
> I believe a strawman derived from the UserString class could be done
> in pure Python.  But I'm sorry: I've no time for this during April.

sscanf for Python gets reinvented like clockwork; e.g., see

ftp://ftp.python.org/pub/python/
    contrib-09-Dec-1999/Misc/sscanfmodule.README

for 1995's version of this crusade.

> I'm also not sure, whether this is really a worthwile effort and
> whether I should champion this idea further.  From Pauls response I
> got the impression that people already consider the '%' string
> interpolation operator as a language wart rather than an elegant
> feature.

Not me!  Infix "%" is great.  But while "%" was mnemonic for the heavy use of
"%" in format strings, "/" doesn't say anything to me.  Combine that with the
relative infrequency of sscanf vs sprintf calls (in C code, Perl code, or (I
sure suspect) in Python code too), and I'm -1 on infix "/" for sscanf.

Making it a method of the format string would be fine (why the format string?
because capturing a bound method object like

    parse3d = "%d %d %d".whatever

would be darned useful, but the other way wouldn't be).

Finally, since .scanf() is a rotten method name (like .join() before it, it
doesn't make clear which operand is scanned and which format), try something
like format.scanning(string) instead.

language-design-is-easy<wink>-ly y'rs  - tim




From jeremy at alum.mit.edu  Wed Apr  4 03:17:42 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue, 3 Apr 2001 21:17:42 -0400 (EDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
	<LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
Message-ID: <15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "TP" == Tim Peters <tim.one at home.com> writes:

  TP> Making it a method of the format string would be fine (why the
  TP> format string?  because capturing a bound method object like

  TP>     parse3d = "%d %d %d".whatever

  TP> would be darned useful, but the other way wouldn't be).

  TP> Finally, since .scanf() is a rotten method name (like .join()
  TP> before it, it doesn't make clear which operand is scanned and
  TP> which format), try something like format.scanning(string)
  TP> instead.

My preference would be to have a separate module with the necessary
support.  It sure would be easy to add to the language.

I imagine something like this:

import fileinput
import scanf

fmt = scanf.Format("%d %d %d")
for line in fileinput.intput():
    mo = fmt.scan(line)
    if mo:
        print mo.group(1, 2, 3)

Jeremy



From skip at pobox.com  Wed Apr  4 03:19:50 2001
From: skip at pobox.com (Skip Montanaro)
Date: Tue, 3 Apr 2001 20:19:50 -0500 (CDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
	<LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
Message-ID: <15050.30390.69707.3375@beluga.mojam.com>

    Tim> Finally, since .scanf() is a rotten method name (like .join()
    Tim> before it, it doesn't make clear which operand is scanned and which
    Tim> format), try something like format.scanning(string) instead.

Hmmm... If method names are the way to go, I'd much rather we found a more
active verb name than "scanning".  How about "extract" or "slice"?  Even
simply "scan" sounds better to me.

Back to the infix operator idea, I agree with Peter on the one hand that
there's a certain symmetry to using infix "/" and with the opposing camp
that the only reason "%" works for emitting strings is the use of C's %
format character.  "*" sort of suggests exploding... ;-)

Skip






From skip at pobox.com  Wed Apr  4 03:22:10 2001
From: skip at pobox.com (Skip Montanaro)
Date: Tue, 3 Apr 2001 20:22:10 -0500 (CDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
	<LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
	<15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <15050.30530.466650.219047@beluga.mojam.com>

    Jeremy> I imagine something like this:

    Jeremy> import fileinput
    Jeremy> import scanf

    ...

Placing the functionality in a module is fine as well, but again, "scanf"
only means something if you've programmed in C before.  I suspect there are
college students graduating from CS departments now who have used C++ but
not C and wouldn't have the slightest idea what "scanf" means.

Skip



From jeremy at alum.mit.edu  Wed Apr  4 03:39:28 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue, 3 Apr 2001 21:39:28 -0400 (EDT)
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <15050.30530.466650.219047@beluga.mojam.com>
References: <m14kMHG-000CnFC@artcom0.artcom-gmbh.de>
	<LNBBLJKPBEHFEDALKOLCOEBBJKAA.tim.one@home.com>
	<15050.30262.961140.616905@w221.z064000254.bwi-md.dsl.cnc.net>
	<15050.30530.466650.219047@beluga.mojam.com>
Message-ID: <15050.31568.301926.504672@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "SM" == Skip Montanaro <skip at pobox.com> writes:

  Jeremy> I imagine something like this:

  Jeremy> import fileinput import scanf

  SM>     ...

  SM> Placing the functionality in a module is fine as well, but
  SM> again, "scanf" only means something if you've programmed in C
  SM> before.  I suspect there are college students graduating from CS
  SM> departments now who have used C++ but not C and wouldn't have
  SM> the slightest idea what "scanf" means.

I don't care much about the name.  scanf is fine with me ("scan with
format") but so is "scan" -- or "parrot."

I do care about it being based on a module rather than a builtin
operator or a string method.  I see scanf-based scanning as roughly
equivalent to regular expressions, which live happily in a module.

If we're going to add a scan method to strings, I can imagine people
wanting "\d+".re_match() and "\d+".re_search() methods on strings,
too. 

Jeremy



From Jason.Tishler at dothill.com  Wed Apr  4 16:20:11 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Wed, 4 Apr 2001 10:20:11 -0400
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
Message-ID: <20010404102011.L63@dothill.com>

Recently significant pthreads support has been added to Cygwin.  When I
attempted to build a Cygwin Python with threads, I got the following
compilation error:

    gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Python/pythonrun.o Python/pythonrun.c
    In file included from /usr/include/signal.h:8,
                     from Python/pythonrun.c:21:
    /usr/include/sys/signal.h:162: parse error before `thread'

Cygwin's sys/signal has the following at line 162:

    #if defined(_POSIX_THREADS)
    int _EXFUN(pthread_kill, (pthread_t thread, int sig));
    #endif

The author of the recent Cygwin pthreads enhancements states that
_POSIX_THREADS is a kernel level #define and should not be defined in
user level code.  Please see the following for his reasoning:

    http://sources.redhat.com/ml/cygwin/2001-03/msg01693.html

Unfortunately, I am not knowledgeable is this area.  Can someone please
confirm or refute the above claim?

If it is concluded that Python should not #define _POSIX_THREADS, then I
am willing to generate a patch to substitute _POSIX_THREADS with a more
benign symbol in the less than 20 occurrences that my grep-ing found.
Any suggestions on what to call this new symbol?

Will such a patch be considered this late in the release cycle?  Or,
should I hold off until after 2.1 final?  If the patch is accepted into
2.1, then users can get a Cygwin Python with thread support without
having to wait for 2.2 or working off of CVS.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From Jason.Tishler at dothill.com  Wed Apr  4 19:34:46 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Wed, 4 Apr 2001 13:34:46 -0400
Subject: [Python-Dev] Re: Case-sensitive import
In-Reply-To: <20010228151728.Q449@dothill.com>; from Jason.Tishler@dothill.com on Wed, Feb 28, 2001 at 03:17:28PM -0500
References: <20010228120229.M449@dothill.com> <LNBBLJKPBEHFEDALKOLCMELLJCAA.tim.one@home.com> <20010228151728.Q449@dothill.com>
Message-ID: <20010404133446.T63@dothill.com>

Tim,

On Wed, Feb 28, 2001 at 03:17:28PM -0500, Jason Tishler wrote:
> On Wed, Feb 28, 2001 at 12:36:45PM -0500, Tim Peters wrote:
> > Jason, about this:
> > 
> >     However, using the next Cygwin gcc (i.e., 2.95.2-8 or later) will
> >     require one to configure with:
> > 
> >         CC='gcc -mwin32' configure ...
> > 
> > How can we make that info *useful* to people?
> 
> I have posted to the Cygwin mailing list and C.L.P regarding my original
> 2.0 patches.  I have also continue to post to Cygwin regarding 2.1a1 and
> 2.1a2.  I intended to do likewise for 2.1b1, etc.
> 
> > The target audience for the
> > Cygwin port probably doesn't search Python-Dev or the Python patches
> > database.
> 
> Agreed -- the above was only offered to the curious Python-Dev person
> and not for archival purposes.
> 
> > So it would be good if you thought about uploading an
> > informational patch to README and Misc/NEWS briefly telling Cygwin folks
> > what they need to know.  If you do, I'll look for it and check it in.
> 
> I will submit a patch to README to add a Cygwin section to "Platform
> specific notes".  Unfortunately, I don't think that I can squeeze it in
> by 2.1b1.  If not, then I will submit it for the next release (2.1b2 or 2.1
> final).  I also don't mind waiting for the Cygwin gcc stuff to settle
> down too.  I know...excuses, excuses...

As promised:

    http://sourceforge.net/tracker/index.php?func=detail&aid=413750&group_id=5470&atid=305470

Note that the following goofiness:

    CC='gcc -mwin32' configure ...

is no longer needed.

Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From m.favas at per.dem.csiro.au  Wed Apr  4 21:19:44 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Thu, 05 Apr 2001 03:19:44 +0800
Subject: [Python-Dev] Little hits add up...
Message-ID: <3ACB73D0.DD94C59F@per.dem.csiro.au>

Since it's a quiet time on python-dev at the moment <grin>, I thought
I'd just toss this bedraggled parrot in...
Every now and then, the comment arises "this <enhancement X> should only
incur a small performance hit". I just ran one of my apps under 1.5.2+
and 2.1b2. The little hits along the way have here added up to a 26%
slowdown. Around the time 2.0 was released, there was a brief thread
along the lines of "let's get 2.0 out the door, and tune it up in 2.1 -
there's some low-hanging fruit about". Any chance we could get someone
like Christian and Tim wound up on looking at performance issues,
however briefly <wink>? (I know, they don't have time - I just
remembered the old days on c.l.py when they'd try to outdo each other
with weird and wonderful optimizations.) This is not a flame at 2.x, BTW
- 2.x is a good thing! (BTW, gc.disable() improved things by 3%.)
-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From nas at python.ca  Wed Apr  4 21:34:15 2001
From: nas at python.ca (Neil Schemenauer)
Date: Wed, 4 Apr 2001 12:34:15 -0700
Subject: [Python-Dev] Little hits add up...
In-Reply-To: <3ACB73D0.DD94C59F@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Thu, Apr 05, 2001 at 03:19:44AM +0800
References: <3ACB73D0.DD94C59F@per.dem.csiro.au>
Message-ID: <20010404123415.A15008@glacier.fnational.com>

Mark Favas wrote:
>(BTW, gc.disable() improved things by 3%.)

I am extremely happy that number is so small. :-)

  Neil



From nas at python.ca  Wed Apr  4 22:56:17 2001
From: nas at python.ca (Neil Schemenauer)
Date: Wed, 4 Apr 2001 13:56:17 -0700
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: <E14ks3t-0001ut-00@usw-sf-web3.sourceforge.net>; from noreply@sourceforge.net on Wed, Apr 04, 2001 at 11:31:21AM -0700
References: <E14ks3t-0001ut-00@usw-sf-web3.sourceforge.net>
Message-ID: <20010404135617.B15146@glacier.fnational.com>

Tim writes:
> Assigned to me; deleted patch 4958 (Jason, whenever you try 
> to change something, it generally won't work unless you add 
> a comment at the same time -- don't know whether that's 
> what actually happened to you, but that's my best guess).

Jason Tishler writes:
> I *did add a comment!  I always do!
> 
> I'm using Netscape again, may be I should only use IE
> whenever I submit SF patches.  Sigh...

Is it a browser issue or is it that only people on the project
can delete things?

  Neil



From tim.one at home.com  Wed Apr  4 23:28:58 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 4 Apr 2001 17:28:58 -0400
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: <20010404135617.B15146@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>

[Neil Schemenauer]
> Is it a browser issue or is it that only people on the project
> can delete things?

I don't know.  Another possibility to consider is that perhaps only project
Admins can delete things (which I am, but Jason isn't -- can you delete
things, Neil?).




From nas at python.ca  Thu Apr  5 00:28:37 2001
From: nas at python.ca (Neil Schemenauer)
Date: Wed, 4 Apr 2001 15:28:37 -0700
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>; from tim.one@home.com on Wed, Apr 04, 2001 at 05:28:58PM -0400
References: <20010404135617.B15146@glacier.fnational.com> <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>
Message-ID: <20010404152837.A15443@glacier.fnational.com>

Tim Peters wrote:
> [Neil Schemenauer]
> > Is it a browser issue or is it that only people on the project
> > can delete things?
> 
> I don't know.  Another possibility to consider is that perhaps only project
> Admins can delete things (which I am, but Jason isn't -- can you delete
> things, Neil?).

With Netscape Communicator 4.76 on Linux I can attach a file
without entering a comment.  I can also delete a file without
entering a comment.  This works when using a Squid 2.2.5 proxy
and when using a direct connection.

  Neil



From tim.one at home.com  Thu Apr  5 02:44:17 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 4 Apr 2001 20:44:17 -0400
Subject: [Python-Dev] Little hits add up...
In-Reply-To: <3ACB73D0.DD94C59F@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEENJKAA.tim.one@home.com>

[Mark Favas]
> Since it's a quiet time on python-dev at the moment <grin>, I thought
> I'd just toss this bedraggled parrot in...
> Every now and then, the comment arises "this <enhancement X> should only
> incur a small performance hit". I just ran one of my apps under 1.5.2+
> and 2.1b2. The little hits along the way have here added up to a 26%
> slowdown.

How do you know it is in fact "the little bits" and not one specific bit?
For example, I recall that line-at-a-time input was dozens of times slower
(relatively speaking) on your box than on anyone else's box.  Not enough info
here, and especially not when you say (emphasis added) "I just ran ONE of my
apps ...".  Perhaps that app does something unique?  Or perhaps that app does
something common that's uniquely slow on your box?  Or ...

> Around the time 2.0 was released, there was a brief thread along the
> lines of "let's get 2.0 out the door, and tune it up in 2.1 - there's
> some low-hanging fruit about".

Heh heh.  I remember that too.  Good followup <wink>.

> Any chance we could get someone like Christian and Tim wound up on
> looking at performance issues, however briefly <wink>? (I know, they
> don't have time -

No chance for Tim.  I have no spare work time or spare spare time left.  And
AFAIK, PythonLabs has no plans to do any performance tuning.  If you identify
a specific new choke point, though, then repairing it should be a focused
low-effort job.  I doubt you're seeing an accumulation of small slowdowns
adding to 26% anyway -- there's really nothing we've done that should have an
ubiquitous effect other than adding cyclic gc (but you said later that gc
only accounted for 3% in your app).

Hmm.  One other:  the new comparison code is both very complex and very
cleanly written.  As a result, I've worn my finger numb stepping through it
in a debugger:  if your app is doing oodles of comparisions, I wouldn't be
surprised to see it losing 20% to layers and layers of function calls trying
to figure out *how* to compare things.

> I just remembered the old days on c.l.py when they'd try to outdo each
> other with weird and wonderful optimizations.)

Recall that none of those got into the distribution, though.  Guido doesn't
like weird and wonderful optimizations in the Python source code.  And,
indeed, many of those eventually succumbed to the *obvious* ways to write
them in C (e.g., converting an MD5 digest to a string of hex digits -- 2.0
added an md5.hex_digest() method to solve that directly, and
binascii.hexlify() for the general case).

> This is not a flame at 2.x, BTW - 2.x is a good thing!

You're not fooling me, Mark.  I've known from the start that this is just
another thinly veiled attack on 2.1's __future__ statement <wink>.

first-find-out-where-it's-slower-ly y'rs  - tim




From tim.one at home.com  Thu Apr  5 08:23:26 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 5 Apr 2001 02:23:26 -0400
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <20010404102011.L63@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>

[Jason Tishler, passing on someone's objection to Python #define'ing
 _POSIX_THREADS sometimes]

Right or wrong, it's too late to change this for 2.1 (IMO).  Thread support
across platforms is very touchy, because so poorly standardized and
implemented across vendors, and fiddling with *any* of that support code is
very dangerous.  Can you swear that Python never #define'ing _POSIX_THREADS
on its own won't break threading on some other platform?  If not, changing it
needs *lots* of lead time for x-platform testing.

> ...
> The author of the recent Cygwin pthreads enhancements states that
> _POSIX_THREADS is a kernel level #define and should not be defined in
> user level code.  Please see the following for his reasoning:
>
>     http://sources.redhat.com/ml/cygwin/2001-03/msg01693.html
>
> Unfortunately, I am not knowledgeable is this area.  Can someone please
> confirm or refute the above claim?

At heart, the claim was based on little more than "I said so", as far as I
could see.  What does the POSIX pthreads standard say?  I haven't had an
employer willing to buy me a copy of that (expensive) document since 1992, so
I can't say (and POSIX stds are not available for online browsing).

He's certainly right that _POSIX_THREADS "is _NOT_ a userland symbol".  *All*
identifiers beginning with an underscore and followed by another underscore
or an uppercase letter are reserved names in std C, for use by the
implementation (incl. system libraries).  But lots of stuff violates that
rule, so I'm afraid it's not a killer argument in practice (although it's a
*good* argument!).

BTW, it's safe to remove this from thread.c:

#ifdef __ksr__
#define _POSIX_THREADS
#endif

I probably put that in around '93, but there are no more KSR machines
anymore -- that I know of.  I won't even make that change for 2.1 at this
late stage.

for-all-i-know-mac-os-x-#defines-__ksr__-ly y'rs  - tim




From fredrik at pythonware.com  Thu Apr  5 09:37:01 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 5 Apr 2001 09:37:01 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
References: <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>
Message-ID: <015201c0bda3$368aaa30$e46940d5@hagrid>

tim wrote:
> At heart, the claim was based on little more than "I said so", as far as I
> could see.  What does the POSIX pthreads standard say?

the SUSv2 spec says:

    "On XSI-conformant systems, _POSIX_THREADS,
    _POSIX_THREAD_ATTR_STACKADDR, _POSIX_THREAD_ATTR_STACKSIZE
    and _POSIX_THREAD_PROCESS_SHARED are always defined"

which doesn't say much about what the POSIX standard says,
of course...

fwiw, regarding the pthread.h file, it also says:

    "An interpretation request has been filed with IEEE PASC
    concerning requirements for visibility of symbols in this
    header"

which implies that the specification doesn't always "say so" ;-)

Cheers /F




From m.favas at per.dem.csiro.au  Thu Apr  5 12:42:03 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Thu, 05 Apr 2001 18:42:03 +0800
Subject: [Python-Dev] Late enhancements breaks termios build
Message-ID: <3ACC4BFB.7143EF4D@per.dem.csiro.au>

In the past day or so, extra functionaility has been added to the CVS
version of the termios module. This breaks the compilation of termios.c
on Tru64 Unix, as a number of the new constants collide with macros of
the same name defined in /usr/include/sys/ioctl.h - so the #ifdef
NEW_THING succeeds, but with incompatible values from ioctl.h, rather
than compatible values from termios.h. I thought we were at the "fix
bugs" stage, rather than the "it'd be nice to add this" <wink>. Yes,
I'll file a bug report - sorry for the interruption.

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From fdrake at acm.org  Thu Apr  5 13:11:01 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 5 Apr 2001 07:11:01 -0400 (EDT)
Subject: [Python-Dev] Late enhancements breaks termios build
In-Reply-To: <3ACC4BFB.7143EF4D@per.dem.csiro.au>
References: <3ACC4BFB.7143EF4D@per.dem.csiro.au>
Message-ID: <15052.21189.904560.185718@cj42289-a.reston1.va.home.com>

Mark Favas writes:
 > than compatible values from termios.h. I thought we were at the "fix
 > bugs" stage, rather than the "it'd be nice to add this" <wink>. Yes,
 > I'll file a bug report - sorry for the interruption.

  Gosh, it sounded like a bug to me.  Can you tell me which file on
Tru64 defines the right constants?
  Please assign the bug report to me -- it's my mess.  Sorry!  ;-(


  -Fred

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




From thomas at xs4all.net  Thu Apr  5 19:53:39 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 5 Apr 2001 19:53:39 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>; from tim.one@home.com on Thu, Apr 05, 2001 at 02:23:26AM -0400
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com>
Message-ID: <20010405195338.C2820@xs4all.nl>

On Thu, Apr 05, 2001 at 02:23:26AM -0400, Tim Peters wrote:

> [Jason Tishler, passing on someone's objection to Python #define'ing
>  _POSIX_THREADS sometimes]

> Right or wrong, it's too late to change this for 2.1 (IMO).  Thread support
> across platforms is very touchy, because so poorly standardized and
> implemented across vendors, and fiddling with *any* of that support code is
> very dangerous.  Can you swear that Python never #define'ing _POSIX_THREADS
> on its own won't break threading on some other platform?  If not, changing it
> needs *lots* of lead time for x-platform testing.

We could define _POSIX_THREADS only if it isn't already defined. Or better
yet, defined PY_POSIX_THREADS, have the Python source itself just trigger
off of that, and #define _POSIX_THREADS somewhere in pyport.h,
PY_POSIX_THREADS is defined and _POSIX_THREADS is not.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From Jason.Tishler at dothill.com  Thu Apr  5 20:40:59 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Thu, 5 Apr 2001 14:40:59 -0400
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <20010405195338.C2820@xs4all.nl>; from thomas@xs4all.net on Thu, Apr 05, 2001 at 07:53:39PM +0200
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com> <20010405195338.C2820@xs4all.nl>
Message-ID: <20010405144059.C402@dothill.com>

Thomas,

On Thu, Apr 05, 2001 at 07:53:39PM +0200, Thomas Wouters wrote:
> On Thu, Apr 05, 2001 at 02:23:26AM -0400, Tim Peters wrote:
> > [Jason Tishler, passing on someone's objection to Python #define'ing
> >  _POSIX_THREADS sometimes]
> >
> > Right or wrong, it's too late to change this for 2.1 (IMO).  Thread support
> > across platforms is very touchy, because so poorly standardized and
> > implemented across vendors, and fiddling with *any* of that support code is
> > very dangerous.  Can you swear that Python never #define'ing _POSIX_THREADS
> > on its own won't break threading on some other platform?  If not, changing
> > it needs *lots* of lead time for x-platform testing.
> 
> We could define _POSIX_THREADS only if it isn't already defined. Or better
> yet, defined PY_POSIX_THREADS, have the Python source itself just trigger
> off of that, and #define _POSIX_THREADS somewhere in pyport.h,
> PY_POSIX_THREADS is defined and _POSIX_THREADS is not.

I was thinking of something like the above, but not with as much
understanding as you already have.  Would you be willing to submit such
a patch for consideration *after* 2.1 final?

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From guido at digicool.com  Fri Apr  6 00:06:22 2001
From: guido at digicool.com (Guido van Rossum)
Date: Thu, 05 Apr 2001 17:06:22 -0500
Subject: [Python-Dev] SF wierdness [Cygwin entry for README file]
In-Reply-To: Your message of "Wed, 04 Apr 2001 15:28:37 MST."
             <20010404152837.A15443@glacier.fnational.com> 
References: <20010404135617.B15146@glacier.fnational.com> <LNBBLJKPBEHFEDALKOLCOEECJKAA.tim.one@home.com>  
            <20010404152837.A15443@glacier.fnational.com> 
Message-ID: <200104052206.RAA11393@cj20424-a.reston1.va.home.com>

> Tim Peters wrote:
> > [Neil Schemenauer]
> > > Is it a browser issue or is it that only people on the project
> > > can delete things?
> > 
> > I don't know.  Another possibility to consider is that perhaps only project
> > Admins can delete things (which I am, but Jason isn't -- can you delete
> > things, Neil?).
> 
> With Netscape Communicator 4.76 on Linux I can attach a file
> without entering a comment.  I can also delete a file without
> entering a comment.  This works when using a Squid 2.2.5 proxy
> and when using a direct connection.
> 
>   Neil

There's a tiny checkbox next to the file upload entry box.  If you
don't check the checkbox, the upload is ignored.  (God knows why they
added this feature -- it's not like it's easy to upload a file by
mistake. :-)

Could it be that those users who complain they can't upload didn't
check the box?

Other random theories: maybe it works differently when not logged in?
Certainly you can't delete a file when you're not logged in.

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




From thomas at xs4all.net  Thu Apr  5 23:27:12 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 5 Apr 2001 23:27:12 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
In-Reply-To: <20010405144059.C402@dothill.com>; from Jason.Tishler@dothill.com on Thu, Apr 05, 2001 at 02:40:59PM -0400
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com> <20010405195338.C2820@xs4all.nl> <20010405144059.C402@dothill.com>
Message-ID: <20010405232712.D2820@xs4all.nl>

On Thu, Apr 05, 2001 at 02:40:59PM -0400, Jason Tishler wrote:

> > We could define _POSIX_THREADS only if it isn't already defined. Or better
> > yet, defined PY_POSIX_THREADS, have the Python source itself just trigger
> > off of that, and #define _POSIX_THREADS somewhere in pyport.h,
> > PY_POSIX_THREADS is defined and _POSIX_THREADS is not.

> I was thinking of something like the above, but not with as much
> understanding as you already have.  Would you be willing to submit such
> a patch for consideration *after* 2.1 final?

Actually, I think the above should go in *before* 2.1 final. It won't break
anything new, and it fixes some warnings and possible some problems.
Because:

- if _POSIX_THREADS is not already defined, nothing changes
- if _POSIX_THREADS is already defined, to the same value as we are defining
  it to, nothing changes
- if _POSIX_THREADS is already defined, but to a different value than Python
  wants to define it to, it used to break and starts working now. There is
  nothing that depends on the actual value of _POSIX_THREADS in Python right
  now (because it doesn't *have* a value.)

Unfortunately, I lack the time to write the patch and test it. I'm busy
moving, redecorating the house I'm half moved into, lack any kind of
connectivity at home (*@#$&*! cable and DSL companies), and have several
projects at work that *need* my 80h/week attention (each one) the next few
of months at least. Python (and Mailman, btw, Barry) are *slightly* on the
back burner right now.

But if someone does write a patch, I can make the time to test it on the
BSDI and FreeBSD machines I have (asside from the Linux machines everyone
and their dog has, nowadays :)

Jetlagged-at-Apachecon-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From claird at starbase.neosoft.com  Fri Apr  6 00:36:46 2001
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Thu, 5 Apr 2001 17:36:46 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
Message-ID: <200104052236.RAA52963@starbase.neosoft.com>

Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).

Successful installation requires
  ./configure --with-cxx=gcc
  sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
  mv /tmp/Makefile Makefile

The result of a plain configure is
  loading cache ./config.cache
  checking MACHDEP... osf1V4
  checking for --without-gcc...
  checking for --with-cxx=<compiler>... no
  checking for c++... c++
  checking whether the C++ compiler (c++  ) works... no
  configure: error: installation or configuration problem: C++ compiler cannot create executables.       

If I leave the Makefile unaltered, I see
  gcc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Modules/ccpython.o ./
  Modules/ccpython.cc
  gcc: 1500: No such file or directory
  cc1plus: Invalid option `-Olimit'
  make: *** [Modules/ccpython.o] Error 1 

Yes, there's probably a way to configure this in one line.
I think this is a better explanation, for now.

Do I need to figure out the correct patch to configure.in,
or is there a specialist who takes responsibility for that?



From claird at starbase.neosoft.com  Fri Apr  6 00:51:13 2001
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Thu, 5 Apr 2001 17:51:13 -0500 (CDT)
Subject: [Python-Dev] A kind of configuration question
Message-ID: <200104052251.RAA53506@starbase.neosoft.com>

Why's there no Win* executable pydoc?

Let me know if I should ask this elsewhere.  In part,
I think I'm searching for larger generalizations that
I'm particularizing with this specific instance.

A Unix-side installation-from-source provides, along
with much else, an executable /usr/local/bin/pydoc,
whose content is simply
  #!/usr/bin/env python

  import pydoc
  pydoc.cli()    
As near as I can tell, installation of the 2.1 Python
binaries for Win* gives no corresponding executable or
"shortcut" for that (those) platform(s).  Is it intended
generally to provide homologous facilities for each of
Unix and Win* (and MacOS)?  Is ... well, how should I
think about this?

I wrote Ka-Ping Yee (the pydoc lord--right?) earlier in
the day.  I've received no response.



From ping at lfw.org  Thu Apr  5 18:29:36 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Thu, 5 Apr 2001 09:29:36 -0700 (PDT)
Subject: [Python-Dev] Re: A kind of configuration question
In-Reply-To: <200104052251.RAA53506@starbase.neosoft.com>
Message-ID: <Pine.LNX.4.10.10104050927340.474-100000@skuld.kingmanhall.org>

On Thu, 5 Apr 2001, Cameron Laird wrote:
> Why's there no Win* executable pydoc?

There is.  There's a shortcut to pydoc.pyw on the Start Menu.

> I wrote Ka-Ping Yee (the pydoc lord--right?) earlier in
> the day.  I've received no response.

I'm at the CHI 2001 conference in Seattle right now; e-mail
checking frequency is down to less than 50 uHz. :)


-- ?!ng




From nas at python.ca  Fri Apr  6 02:50:31 2001
From: nas at python.ca (Neil Schemenauer)
Date: Thu, 5 Apr 2001 17:50:31 -0700
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <200104052236.RAA52963@starbase.neosoft.com>; from claird@starbase.neosoft.com on Thu, Apr 05, 2001 at 05:36:46PM -0500
References: <200104052236.RAA52963@starbase.neosoft.com>
Message-ID: <20010405175031.A17937@glacier.fnational.com>

Cameron Laird wrote:
> Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).
> 
> Successful installation requires
>   ./configure --with-cxx=gcc
>   sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
>   mv /tmp/Makefile Makefile

Can you send me the output from configure?  Also, try
--without-cxx instead.  Finally, an easier work around is:

    OPT=-O ./configure --with-cxx=gcc

Can someone tell me why with-cxx is the default?  It pissed me off
more than a few times when I was on a machine without a working C++
compiler.
 
  Neil



From fredrik at pythonware.com  Fri Apr  6 08:18:05 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 6 Apr 2001 08:18:05 +0200
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
References: <200104052236.RAA52963@starbase.neosoft.com>
Message-ID: <07ee01c0be61$5ab63690$e46940d5@hagrid>

Cameron Laird wrote:

> Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).
> 
> Successful installation requires
>   ./configure --with-cxx=gcc
>   sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
>   mv /tmp/Makefile Makefile

umm.  isn't there an -Olimit test in the configure script?

did you run configure with "cc" first, and forgot to remove the
cache files?

it would be nice if Python didn't default to "gcc" on the axp.
"cc" is standard, and creates much better code on the AXP.

Cheers /F




From fredrik at pythonware.com  Fri Apr  6 08:07:41 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 6 Apr 2001 08:07:41 +0200
Subject: [Python-Dev] Should Python #define _POSIX_THREADS?
References: <20010404102011.L63@dothill.com> <LNBBLJKPBEHFEDALKOLCEEFJJKAA.tim.one@home.com> <20010405195338.C2820@xs4all.nl> <20010405144059.C402@dothill.com> <20010405232712.D2820@xs4all.nl>
Message-ID: <07ed01c0be61$5a4e4d00$e46940d5@hagrid>

thomas wrote:
> Actually, I think the above should go in *before* 2.1 final. It won't break
> anything new, and it fixes some warnings and possible some problems.
> Because:
> 
> - if _POSIX_THREADS is not already defined, nothing changes
> - if _POSIX_THREADS is already defined, to the same value as we are defining
>   it to, nothing changes
> - if _POSIX_THREADS is already defined, but to a different value than Python
>   wants to define it to, it used to break and starts working now. There is
>   nothing that depends on the actual value of _POSIX_THREADS in Python right
>   now (because it doesn't *have* a value.)

on the other hand, cygwin is the only platform that has reported
problems with this, and your solution doesn't address their problem.
(which is that Python assumes that a system that has pthread_create
in a library is a fully compliant POSIX thread system)

the right thing to do appears to be to let configure compile and
link a program that uses *all* pthread features needed, and define
_POSIX_THREAD (or better, PY_POSIX_THREADS) only if that
works...

Cheers /F




From tim.one at home.com  Fri Apr  6 10:46:54 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 04:46:54 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
Message-ID: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>

Jim Fulton bumped into a gross problem in the 2.1b2 asynchat.py today,
introduced by conversion to string methods (one change got the order of
.find() arguments backwards).

This is embarrassing (or should be <wink>), because it meant asynchat.py
really had no chance of working at all!  And if Jim hadn't bumped into it, we
would have shipped it this way for 2.1 final next week.

I haven't used those modules myself, so don't know whether this request is
reasonable:  could someone please whip up an at least minimal standard test
case for these modules?  So long as it runs on at least one of {Windows,
Linux}, we'd catch problems like this almost instantly.  As is, AFAICT we
don't even import asynchat (the "import asynchat" line in test_sundry.py is
commented out but no reason is given for that -- anyone know why?).

don't-everyone-volunteer-at-once-ly y'rs  - tim




From jack at oratrix.nl  Fri Apr  6 10:50:24 2001
From: jack at oratrix.nl (Jack Jansen)
Date: Fri, 06 Apr 2001 10:50:24 +0200
Subject: [Python-Dev] Re: [Pythonmac-SIG] __builtins__ a dictionary or a module?
In-Reply-To: Message by Jonathan Wight <JWight@bigfoot.com> ,
	     Thu, 05 Apr 2001 01:38:31 -0500 , <B6F17D15.194B8%JWight@bigfoot.com> 
Message-ID: <20010406085024.7548A312BA0@snelboot.oratrix.nl>

Python-devvers, can anyone help with this behaviour?

> If I run Just's Python IDE and run the same code it tells mes that
> __builtins__ is a module.
> 
> And finally if I run the following code from within the Interactive console
> contained in standard 'code.py' file I get told __builtins__ is a
> dictionary.
> 
> So what is it? Is __builtins__ a module or a dictionary? I know that they're
> essentially the same thing, but it unnerves me to have the same code produce
> different results in different platforms.

Well, I've narrowed down the difference to the exec statement:
>>> exec "print type(__builtins__)"
<type 'module'>
>>> exec "print type(__builtins__)" in {}
<type 'dictionary'>

Can anyone explain what is going on here?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 





From Paul.Moore at uk.origin-it.com  Fri Apr  6 10:55:38 2001
From: Paul.Moore at uk.origin-it.com (Moore, Paul)
Date: Fri, 6 Apr 2001 09:55:38 +0100 
Subject: [Python-Dev] A kind of configuration question 
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFC@ukrux002.rundc.uk.origin-it.com>

On Thu, 5 Apr 2001, Cameron Laird wrote:
> Why's there no Win* executable pydoc?

There's an issue on Windows, because there are two types of executable
(console and GUI). I've raised a bug report on this (407300), but the action
taken was to remove the pydoc script (as opposed to the module) from the
Windows installer, although there is still a start menu entry.

The problem is that pydoc does two things - first, it starts a web server
(with a small GUI control interface). This script needs to be run as a GUI
command, to avoid an unnecessary console window. This is what the entry on
the start menu does. The other thing is to support the command line usage
"pydoc XXX". For this, I believe there should be a console command. A small
"pydoc.bat" as follows would provide this functionality:

--- pydoc.bat ---
@echo off
if "%1"=="" pythonw -c "import pydoc; pydoc.cli()"
if NOT "%1"=="" python -c "import pydoc; pydoc.cli()" %1 %2 %3 %4 %5 %6 %7
%8 %9
---

I do the test on %1 so that if the command is called without any arguments,
it uses pythonw to spawn the GUI webserver, whereas with arguments it does
the command line stuff.

Paul Moore



From tim.one at home.com  Fri Apr  6 11:06:02 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 05:06:02 -0400
Subject: [Python-Dev] Re: [Pythonmac-SIG] __builtins__ a dictionary or a module?
In-Reply-To: <20010406085024.7548A312BA0@snelboot.oratrix.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEJCJKAA.tim.one@home.com>

Please read this the right way <wink>:  it's none of your business whether
__builtins__ is a module or a dictionary.  __builtin__ (no trailing 's') is a
module, but __builtins__ is a module attribute that can be either a module or
a dictionary, depending on what Python feels like doing.  Which it decides to
do is an internal implementation detail of no material consequence to correct
Python code.

More info on why the two choices exist-- and documentation that __builtins__
*can* be either a dict or a module --can be found in the "Code blocks,
execution frames, and namespaces" setion of the Language Reference manual.

BTW, the primary reason __builtins__ is a module when bringing up a native
command-line shell (I know that doesn't apply on a Mac Classic) is simply so
that if a curious user types

    >>> __builtins__

they get

    <module '__builtin__' (built-in)>

instead of a giant dict dump.  The primary use for making __builtins__ a dict
is to support restricted execution modes.




From tim.one at home.com  Fri Apr  6 11:25:16 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 05:25:16 -0400
Subject: [Python-Dev] A kind of configuration question 
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFC@ukrux002.rundc.uk.origin-it.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEJDJKAA.tim.one@home.com>

[Moore, Paul]
> There's an issue on Windows, because there are two types of executable
> (console and GUI). I've raised a bug report on this (407300), but
> the action taken was to remove the pydoc script (as opposed to the
> module) from the Windows installer, although there is still a start
> menu entry.

Paul, that action had nothing to do with your bug report.  Ping managed to
break AMK's pydoc script on Windows the morning of 2.1b2 release day, and
that left the Windows installer installing a non-functional Start menu link
for pydoc.  Unfortunately, I didn't discover that until after the 2.1b2 code
base was frozen.  Fortunately, Ping had also checked in a new pydoc.pyw
script (under Tools/scripts/) that *did* work on Windows, so *after* the last
second I simply changed the Start menu link to point to that instead, and
stopped copying AMK's no-longer-worked-on-Windows Tools/scripts/pydoc script
to the installation directory.  And I don't know why Guido copied AMK's pydoc
script to the Windows install directory to begin with, since (as your bug
report pointed out) it was a nearly useless thing on Windows even before it
got broken.

> ...
> The other thing is to support the command line usage "pydoc XXX".

Given that Win9x systems come with feeble cmdline shells (they're 50 lines
max, and no way to scroll back), I have no interest in pretending to support
pydoc's cmdline usage under Windows DOS boxes.  Writing a cmdline script to
drive pydoc is a trivial exercise for any knowledgable Windows user who wants
that, while the non-knowledgable should learn to use pydoc from within IDLE
or PythonWin or PythonWorks or ... instead (all of which provide a *capable*
Python shell under all flavors of Windows).




From Paul.Moore at uk.origin-it.com  Fri Apr  6 12:18:45 2001
From: Paul.Moore at uk.origin-it.com (Moore, Paul)
Date: Fri, 6 Apr 2001 11:18:45 +0100 
Subject: [Python-Dev] A kind of configuration question 
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com>

>[Moore, Paul]
>> There's an issue on Windows, because there are two types of executable
>> (console and GUI). I've raised a bug report on this (407300), but
>> the action taken was to remove the pydoc script (as opposed to the
>> module) from the Windows installer, although there is still a start
>> menu entry.
>
>Paul, that action had nothing to do with your bug report.  Ping managed to
>break AMK's pydoc script on Windows the morning of 2.1b2 release day, and
>that left the Windows installer installing a non-functional Start menu link
>for pydoc.

Oh. Sorry about that - I seem to have misread your comments from when you
reclosed the bug. I read them as "I've removed the scripts, so your bug no
longer applies", rather than "the script needed to be removed, so ths issue
has gone away". I apologise if I sounded critical. I do still think that
being able to type "pydoc MODULE" at the command line would be very nice,
and I feel that my batch file does this in a simple way. I'd be disappointed
if it wasn't included in 2.1 (the whole pydoc suite appeared quite late, so
minor fixes like this do get pushed up to the wire, but that doesn't
necessarily mean they should be discarded as "too late"), but if it is
deemed too late for that, could it be put into 2.2?

On a related note, has anything happened on my other bug report (406280)? At
the very least, using tempfilepager instead of pipepager as a workaround
would be sensible. Leaving things broken makes no real sense. This is a
patch:

--- pydoc.py.orig	Fri Mar 23 12:42:06 2001
+++ pydoc.py	Fri Apr 06 10:56:02 2001
@@ -910,7 +910,10 @@
     if not sys.stdin.isatty() or not sys.stdout.isatty():
         return plainpager
     if os.environ.has_key('PAGER'):
-        return lambda a: pipepager(a, os.environ['PAGER'])
+        if sys.platform == 'win32':
+            return lambda a: tempfilepager(a, os.environ['PAGER'])
+        else:
+            return lambda a: pipepager(a, os.environ['PAGER'])
     if sys.platform == 'win32':
         return lambda a: tempfilepager(a, 'more <')
     if hasattr(os, 'system') and os.system('less 2>/dev/null') == 0:

>> ...
>> The other thing is to support the command line usage "pydoc XXX".
>
>Given that Win9x systems come with feeble cmdline shells (they're 50 lines
>max, and no way to scroll back), I have no interest in pretending to
support
>pydoc's cmdline usage under Windows DOS boxes.

Given that Windows NT/2000 command line shells are fine, and reasonably
capable (including command history both at the prompt and within
applications, whatever size you like, and scrolling buffers), refusing to
support them just because 9x (which frankly is a dying environment for
developers) is pathetic, is not a very helpful stance to take. I've supplied
two low-impact patches which make pydoc work on the Windows NT command line.
Sure, I can apply them manually to my installation, but why not make them
available to everyone?

frustrated-ly y'rs,
Paul.



From jim at digicool.com  Fri Apr  6 14:04:12 2001
From: jim at digicool.com (Jim Fulton)
Date: Fri, 06 Apr 2001 08:04:12 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
Message-ID: <3ACDB0BC.2533D8C2@digicool.com>

Tim Peters wrote:
> 
> Jim Fulton bumped into a gross problem in the 2.1b2 asynchat.py today,
> introduced by conversion to string methods (one change got the order of
> .find() arguments backwards).
> 
> This is embarrassing (or should be <wink>), because it meant asynchat.py
> really had no chance of working at all!  And if Jim hadn't bumped into it, we
> would have shipped it this way for 2.1 final next week.
> 
> I haven't used those modules myself, so don't know whether this request is
> reasonable:  could someone please whip up an at least minimal standard test
> case for these modules?  So long as it runs on at least one of {Windows,
> Linux}, we'd catch problems like this almost instantly.  As is, AFAICT we
> don't even import asynchat (the "import asynchat" line in test_sundry.py is
> commented out but no reason is given for that -- anyone know why?).

Do we have test cases for other networking code? This seems a kinda
hard, though I haven't given it much thought.  I imagine one would
want some sort of faux sockets to support this.  Library modules
would need to be written so thier sockets could be passed in...

I've got a more basic question. Should asynchat *really* be in the standard
library?  Is it really used by anything but medusa? (There is another
module in the standard distribution that uses it, but it's unclear
whether anyone is using it. The Author isn't.)

Jim

--
Jim Fulton           mailto:jim at digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.



From guido at digicool.com  Fri Apr  6 17:02:03 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 06 Apr 2001 10:02:03 -0500
Subject: [Python-Dev] A kind of configuration question
In-Reply-To: Your message of "Fri, 06 Apr 2001 11:18:45 +0100."
             <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com> 
References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com> 
Message-ID: <200104061502.KAA14238@cj20424-a.reston1.va.home.com>

> On a related note, has anything happened on my other bug report (406280)? At
> the very least, using tempfilepager instead of pipepager as a workaround
> would be sensible. Leaving things broken makes no real sense. This is a
> patch:

What's broken?  After "from pydoc import help" I can use help(...)
just fine, both in the command line version (where it invokes some
pager) and in IDLE (where it just scrolls off the window, but IDLE has
infinite scroll-back so that's no problem).  This is on Win98se with
Python 2.1b2.
 
> Given that Windows NT/2000 command line shells are fine, and reasonably
> capable (including command history both at the prompt and within
> applications, whatever size you like, and scrolling buffers), refusing to
> support them just because 9x (which frankly is a dying environment for
> developers) is pathetic, is not a very helpful stance to take. I've supplied
> two low-impact patches which make pydoc work on the Windows NT command line.
> Sure, I can apply them manually to my installation, but why not make them
> available to everyone?

We seem to disagree on how Windows users use their system.  You seem
to be a command line user on Windows.  Both Tim & me are more
mouse-based users, and neither of us spends a lot of time in the
command line, so we don't see the point of adding yet another thing to
the distribution.  It is my expectation that *most* Windows users (and
developers) are like Tim & me, not like you, so we don't feel (if I
may channel Tim for a change :-) that this would benefit most users.

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



From fredrik at effbot.org  Fri Apr  6 16:20:08 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Fri, 6 Apr 2001 16:20:08 +0200
Subject: [Python-Dev] A kind of configuration question
References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFF@ukrux002.rundc.uk.origin-it.com>  <200104061502.KAA14238@cj20424-a.reston1.va.home.com>
Message-ID: <0a8201c0bea4$b24cb760$e46940d5@hagrid>

> It is my expectation that *most* Windows users (and developers)
> are like Tim & me

no, we're not.

(no real windows developer use 98SE these days.  and just's
brother cannot possibly be a typical user of anything ;-)

I'm +0 on a pydoc command, but even if it's not added to the
standard distribution, I'm +1 on making sure pydoc works in case
someone wants to add a batchfile shortcut themselves.

Cheers /F




From jeremy at digicool.com  Fri Apr  6 16:13:43 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 6 Apr 2001 10:13:43 -0400 (EDT)
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
Message-ID: <15053.53015.996756.656235@slothrop.digicool.com>

>>>>> "TP" == Tim Peters <tim.one at home.com> writes:

  TP> Jim Fulton bumped into a gross problem in the 2.1b2 asynchat.py
  TP> today, introduced by conversion to string methods (one change
  TP> got the order of .find() arguments backwards).

  TP> This is embarrassing (or should be <wink>), because it meant
  TP> asynchat.py really had no chance of working at all!  And if Jim
  TP> hadn't bumped into it, we would have shipped it this way for 2.1
  TP> final next week.

This leads to the natural question:  Are there other modules that we
changed for string methods that don't have test suites?  If this
problem happened once, it could have happened twice.

Jeremy




From aahz at rahul.net  Fri Apr  6 16:26:08 2001
From: aahz at rahul.net (Aahz Maruch)
Date: Fri, 6 Apr 2001 07:26:08 -0700 (PDT)
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: <3ACDB0BC.2533D8C2@digicool.com> from "Jim Fulton" at Apr 06, 2001 08:04:12 AM
Message-ID: <20010406142608.DD66299CA0@waltz.rahul.net>

Jim Fulton wrote:
> 
> I've got a more basic question. Should asynchat *really* be in the standard
> library?  Is it really used by anything but medusa? (There is another
> module in the standard distribution that uses it, but it's unclear
> whether anyone is using it. The Author isn't.)

asynchat should probably be in the Tools directory, but my former
employer used asyncore (stand-alone, in addition to Medusa) and I was
quite happy when it went into the standard library.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.



From claird at starbase.neosoft.com  Fri Apr  6 16:37:27 2001
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Fri, 6 Apr 2001 09:37:27 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <20010405175031.A17937@glacier.fnational.com>
Message-ID: <200104061437.JAA79762@starbase.neosoft.com>

	From nas at arctrix.com  Thu Apr  5 19:51:35 2001
			.
			.
			.
	Can you send me the output from configure?  Also, try
	--without-cxx instead.  Finally, an easier work around is:
			.
			.
			.
Oops!  Sorry, everybody;
  configure --without-cxx
(which my notes say I'd earlier tried, with unsatisfying
results) appears indeed to be the minimal invocation in
my environment to yield a happy conclusion.

We're carrying on some of this in private correspondence.
While I remain uncertain about python-dev folkways, I'll
report more conclusions as I judge them of general interest.



From fredrik at effbot.org  Fri Apr  6 16:47:45 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Fri, 6 Apr 2001 16:47:45 +0200
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <20010406142608.DD66299CA0@waltz.rahul.net>
Message-ID: <0ac301c0bea8$8cef9ab0$e46940d5@hagrid>

jim wrote:
> I've got a more basic question. Should asynchat *really* be in the standard
> library?  Is it really used by anything but medusa?

yes.

Cheers /F




From claird at starbase.neosoft.com  Fri Apr  6 16:49:48 2001
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Fri, 6 Apr 2001 09:49:48 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <07ee01c0be61$5ab63690$e46940d5@hagrid>
Message-ID: <200104061449.JAA80212@starbase.neosoft.com>

	From fredrik at pythonware.com  Fri Apr  6 01:53:58 2001
			.
			.
			.
	> Host:  Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1).
	> 
	> Successful installation requires
	>   ./configure --with-cxx=gcc
	>   sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile
	>   mv /tmp/Makefile Makefile

	umm.  isn't there an -Olimit test in the configure script?

	did you run configure with "cc" first, and forgot to remove the
	cache files?
			.
			.
			.
Yes.  No.
  make distclean
  configure
  make
gives
  ...
  gcc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Modules/ccpython.o ./Modules/ccpython.cc
  gcc: 1500: No such file or directory
  cc1plus: Invalid option `-Olimit'
  make: *** [Modules/ccpython.o] Error 1   

Should I track this down, or do we have a specialist
on-hand in autoconfig?  I find it like sendmail.cf; I
can read and write, but never understand the *meaning*
of what others have done, just its syntax.  So, yes, I
can see the -Olimit test in configure.in, but it's
likely to take me a while to figure out what's wrong
with it.



From claird at starbase.neosoft.com  Fri Apr  6 16:50:56 2001
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Fri, 6 Apr 2001 09:50:56 -0500 (CDT)
Subject: [Python-Dev] Config problems in 2.1 for Digital Unix
In-Reply-To: <07ee01c0be61$5ab63690$e46940d5@hagrid>
Message-ID: <200104061450.JAA80284@starbase.neosoft.com>

	From fredrik at pythonware.com  Fri Apr  6 01:53:58 2001
			.
			.
			.
	it would be nice if Python didn't default to "gcc" on the axp.
	"cc" is standard, and creates much better code on the AXP.

	Cheers /F
Me, too.



From barry at digicool.com  Fri Apr  6 17:01:46 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Fri, 6 Apr 2001 11:01:46 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
	<3ACDB0BC.2533D8C2@digicool.com>
Message-ID: <15053.55898.791123.146656@anthem.wooz.org>

>>>>> "JF" == Jim Fulton <jim at digicool.com> writes:

    JF> I've got a more basic question. Should asynchat *really* be in
    JF> the standard library?  Is it really used by anything but
    JF> medusa? (There is another module in the standard distribution
    JF> that uses it, but it's unclear whether anyone is using it. The
    JF> Author isn't.)

That'd be me.  I wrote smtpd.py a long while ago, got approval from
Guido to add it to the standard library, then forgot about it until
around the 2.1a1 time frame.  smtpd.py itself is probably useful to
only a handful of people (and maybe that hand belongs to a shop
teacher), so I wouldn't be offended if it and async* were moved to
Tools -- eventually.  It is, of course, much too late to do this for
Py2.1.

-Barry



From barry at digicool.com  Fri Apr  6 17:04:57 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Fri, 6 Apr 2001 11:04:57 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
	<3ACDB0BC.2533D8C2@digicool.com>
Message-ID: <15053.56089.93466.30362@anthem.wooz.org>

Oh, one other thing.  Last time I traded email with Sam Rushing
(almost a year ago, and I'm not even sure if he's on python-dev), he
was moving toward a coroutine based Medusa and away from async* based.

-Barry



From jim at digicool.com  Fri Apr  6 17:20:46 2001
From: jim at digicool.com (Jim Fulton)
Date: Fri, 06 Apr 2001 11:20:46 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <20010406142608.DD66299CA0@waltz.rahul.net>
Message-ID: <3ACDDECE.E4E7806E@digicool.com>

Aahz Maruch wrote:
> 
> Jim Fulton wrote:
> >
> > I've got a more basic question. Should asynchat *really* be in the standard
> > library?  Is it really used by anything but medusa? (There is another
> > module in the standard distribution that uses it, but it's unclear
> > whether anyone is using it. The Author isn't.)
> 
> asynchat should probably be in the Tools directory, but my former
> employer used asyncore (stand-alone, in addition to Medusa) and I was
> quite happy when it went into the standard library.

I was only talking about asynchat. :)

Jim

--
Jim Fulton           mailto:jim at digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org



From jim at digicool.com  Fri Apr  6 17:22:49 2001
From: jim at digicool.com (Jim Fulton)
Date: Fri, 06 Apr 2001 11:22:49 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
		<3ACDB0BC.2533D8C2@digicool.com> <15053.56089.93466.30362@anthem.wooz.org>
Message-ID: <3ACDDF49.A641466E@digicool.com>

"Barry A. Warsaw" wrote:
> 
> Oh, one other thing.  Last time I traded email with Sam Rushing
> (almost a year ago, and I'm not even sure if he's on python-dev), he
> was moving toward a coroutine based Medusa and away from async* based.

I don't think that was medusa. I tink it was something else.

Jim

--
Jim Fulton           mailto:jim at digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org



From barry at digicool.com  Fri Apr  6 17:34:54 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Fri, 6 Apr 2001 11:34:54 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
	<3ACDB0BC.2533D8C2@digicool.com>
	<15053.56089.93466.30362@anthem.wooz.org>
	<3ACDDF49.A641466E@digicool.com>
Message-ID: <15053.57886.530944.174828@anthem.wooz.org>

>>>>> "JF" == Jim Fulton <jim at digicool.com> writes:

    JF> I don't think that was medusa. I tink it was something else.

Sam called it the "next generation medusa". :)



From guido at digicool.com  Fri Apr  6 19:52:16 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 06 Apr 2001 12:52:16 -0500
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: Your message of "Fri, 06 Apr 2001 04:46:54 -0400."
             <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com> 
Message-ID: <200104061752.MAA15185@cj20424-a.reston1.va.home.com>

> I haven't used those modules myself, so don't know whether this request is
> reasonable:  could someone please whip up an at least minimal standard test
> case for these modules?  So long as it runs on at least one of {Windows,
> Linux}, we'd catch problems like this almost instantly.  As is, AFAICT we
> don't even import asynchat (the "import asynchat" line in test_sundry.py is
> commented out but no reason is given for that -- anyone know why?).

I just checked in a testcase for asynchat that also tests asyncore.

It works on Windows98se and Linux Red Hat 6.2, at least.  Enjoy!

I guess the line from test_sundry.py can now be deleted -- ditto for
the import of asyncore.

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



From tim.one at home.com  Fri Apr  6 21:00:06 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 15:00:06 -0400
Subject: [Python-Dev] Test cases for asynchat, asyncore?
In-Reply-To: <200104061752.MAA15185@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEKNJKAA.tim.one@home.com>

[Guido]
> I just checked in a testcase for asynchat that also tests asyncore.

Excellent -- thank you!

> ...
> I guess the line from test_sundry.py can now be deleted -- ditto for
> the import of asyncore.

Done.




From tim.one at home.com  Sat Apr  7 00:27:53 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 18:27:53 -0400
Subject: [Python-Dev] A kind of configuration question
In-Reply-To: <200104061502.KAA14238@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIELMJKAA.tim.one@home.com>

[Guido, to Paul Moore]
> ...
> We seem to disagree on how Windows users use their system.  You seem
> to be a command line user on Windows.  Both Tim & me are more
> mouse-based users, and neither of us spends a lot of time in the
> command line, so we don't see the point of adding yet another thing to
> the distribution.  It is my expectation that *most* Windows users (and
> developers) are like Tim & me, not like you, so we don't feel (if I
> may channel Tim for a change :-) that this would benefit most users.

Well, when playing Windows developer I spend most of my life in a DOS box.
But when playing Windows developer, I also have no need for anyone to write a
trivial .bat file for me, and indeed would probably write my own anyway to
cater to that, e.g., I can set up useful cmdline associations for Python on
Win2K but not Win9X.  Is there *any* Windows developer out there too lame to
do this for themself?  I doubt it.

Does it hurt to include a little .bat file anyway?  YES!  Most Python users
on Windows are not Windows developers, and unlike Paul I'm going to spend a
fair chunk of my life on the Tutor and Help lists trying to explain to the
vast majority *why* the pydoc.bat file in the install directory is useless to
them on their Win9X boxes.  BTW, I use Win9X deliberately at home, partly
because that's what my sisters use, and partly to keep my sympathy high for
all of Python's thousands of Win9X sufferers.

If you want to supply pydoc .bat files, fine, work out a minimal set with
Ping and submit a patch to put them in the Tools/scripts/ directory.  One of
them has to be suitable for linking to directly from the pydoc Start menu
item, but beyond that if they're out of sight they're out of mind so I don't
much care.  I actively want to keep them *out* of the main installation
directory, because newbies want to know about *every* file in that directory,
and there's nothing positive we can tell them about a pydoc.bat file under
their Win9X systems (unless all it does is bring up a GUI).  It's no accident
that Python doesn't ship with any .bat files today.

no-need-to-bend-over-backwards-to-help-people-who-don't-need-help-ly y'rs
    - tim




From tim.one at home.com  Sat Apr  7 00:42:22 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 6 Apr 2001 18:42:22 -0400
Subject: [Python-Dev] A kind of configuration question
In-Reply-To: <0a8201c0bea4$b24cb760$e46940d5@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELNJKAA.tim.one@home.com>

[/F]
> I'm +0 on a pydoc command, but even if it's not added to the
> standard distribution, I'm +1 on making sure pydoc works in case
> someone wants to add a batchfile shortcut themselves.

Can you be more specific?  AMK's Tools/scripts/pydoc works on Windows,
although from a Win9x shell the text modes are more frustrating than useful,
and if you use "python" to start it instead of "pythonw" and ask for a GUI
mode, you're subject to Tk freezing the DOS box (etc) from time to time.  So
does pydoc "work" now or not in your view?  If not, what does "work" mean?

The Windows installer currently creates a Start menu item pointing to Ping's
Tools/scripts/pydoc.pyw program instead, which works fine, and just executes
pydoc.gui().




From fdrake at cj42289-a.reston1.va.home.com  Sat Apr  7 07:45:43 2001
From: fdrake at cj42289-a.reston1.va.home.com (Fred Drake)
Date: Sat,  7 Apr 2001 01:45:43 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010407054543.226DD2879A@cj42289-a.reston1.va.home.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


Lots of small fixes, but also the first installment of the unittest
documentation.




From jack at oratrix.nl  Sat Apr  7 14:00:15 2001
From: jack at oratrix.nl (Jack Jansen)
Date: Sat, 07 Apr 2001 14:00:15 +0200
Subject: [Python-Dev] Import hook to do end-of-line conversion?
Message-ID: <20010407120021.5503DEA11D@oratrix.oratrix.nl>

[Oops, try again]

There's talk on the PythonMac-SIG to create an import hook that would
read modules with either \r, \n or \r\n newlines and convert them to
the local convention before feeding them to the rest of the import
machinery. The reason this has become interesting is the mixed
unixness/macness of MacOSX, where such an import hook could be used to
share a Python tree between MacPython and bsd-Python. They would only
need a different site.py (probably), living somehwere near the head of
sys.path, that would be in local end of line convention and enable the
hook.

However, it seem that such a module would have a much more general
scope, for instance if you're accessing samba partitions from windows,
or other foreign file systems, etc.

Does this sound like a good idea? And (even better:-) has anyone done
this already? Would it be of enough interest to include it in the
core Lib?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | ++++ see http://www.xs4all.nl/~tank/ ++++



From fredrik at pythonware.com  Sat Apr  7 18:25:52 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sat, 7 Apr 2001 18:25:52 +0200
Subject: [Python-Dev] Import hook to do end-of-line conversion?
References: <20010407120021.5503DEA11D@oratrix.oratrix.nl>
Message-ID: <004c01c0bf7f$6b64e4e0$e46940d5@hagrid>

jack wrote:
> There's talk on the PythonMac-SIG to create an import hook that would
> read modules with either \r, \n or \r\n newlines and convert them to
> the local convention before feeding them to the rest of the import
> machinery.

why not fix the compiler instead?

Cheers /F




From gstein at lyra.org  Sat Apr  7 18:21:14 2001
From: gstein at lyra.org (Greg Stein)
Date: Sat, 7 Apr 2001 09:21:14 -0700
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <004c01c0bf7f$6b64e4e0$e46940d5@hagrid>; from fredrik@pythonware.com on Sat, Apr 07, 2001 at 06:25:52PM +0200
References: <20010407120021.5503DEA11D@oratrix.oratrix.nl> <004c01c0bf7f$6b64e4e0$e46940d5@hagrid>
Message-ID: <20010407092114.E31832@lyra.org>

On Sat, Apr 07, 2001 at 06:25:52PM +0200, Fredrik Lundh wrote:
> jack wrote:
> > There's talk on the PythonMac-SIG to create an import hook that would
> > read modules with either \r, \n or \r\n newlines and convert them to
> > the local convention before feeding them to the rest of the import
> > machinery.
> 
> why not fix the compiler instead?

Exactly. That is where the correct fix should go. The compile can/should
recognize all types of newlines as the NEWLINE token.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From just at letterror.com  Sat Apr  7 18:40:02 2001
From: just at letterror.com (Just van Rossum)
Date: Sat,  7 Apr 2001 18:40:02 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <20010407092114.E31832@lyra.org>
Message-ID: <20010407184003-r01010600-1327fbb2@213.84.27.177>

Greg Stein wrote:

> On Sat, Apr 07, 2001 at 06:25:52PM +0200, Fredrik Lundh wrote:
> > jack wrote:
> > > There's talk on the PythonMac-SIG to create an import hook that would
> > > read modules with either \r, \n or \r\n newlines and convert them to
> > > the local convention before feeding them to the rest of the import
> > > machinery.
> > 
> > why not fix the compiler instead?
> 
> Exactly. That is where the correct fix should go. The compile can/should
> recognize all types of newlines as the NEWLINE token.

The same goes for file objects in text mode...

Just



From fredrik at pythonware.com  Sat Apr  7 18:54:28 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sat, 7 Apr 2001 18:54:28 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
References: <20010407184003-r01010600-1327fbb2@213.84.27.177>
Message-ID: <00b901c0bf83$69b1e0e0$e46940d5@hagrid>

Just wrote:
> > > why not fix the compiler instead?
> > 
> > Exactly. That is where the correct fix should go. The compile can/should
> > recognize all types of newlines as the NEWLINE token.
> 
> The same goes for file objects in text mode...

probably -- but changing can break stuff (in theory, at least), and
may require a PEP.  changing the compiler is more of a bugfix, really...

Cheers /F




From just at letterror.com  Sat Apr  7 19:26:26 2001
From: just at letterror.com (Just van Rossum)
Date: Sat,  7 Apr 2001 19:26:26 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <00b901c0bf83$69b1e0e0$e46940d5@hagrid>
Message-ID: <20010407192627-r01010600-b0457661@213.84.27.177>

Fredrik Lundh wrote:

> Just wrote:
> > > > why not fix the compiler instead?
> > > 
> > > Exactly. That is where the correct fix should go. The compile can/should
> > > recognize all types of newlines as the NEWLINE token.
> > 
> > The same goes for file objects in text mode...
> 
> probably -- but changing can break stuff (in theory, at least), and
> may require a PEP.  changing the compiler is more of a bugfix, really...

But if we only fix the compiler, we'll get complaints that other things
don't work, eg. bogus tracebacks due to a non-fixed linecache.py, broken IDE's,
etc.

Btw. I can't seem to think of any examples that would break after such a change.
I mean, who would depend on a \n text file with embedded \r's?

Just



From paul at pfdubois.com  Sat Apr  7 19:33:57 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Sat, 7 Apr 2001 10:33:57 -0700
Subject: [Python-Dev] Progress report on PEP 242
Message-ID: <ADEOIFHFONCLEEPKCACCCENICHAA.paul@pfdubois.com>

If I understand correctly I need to supply a reference implementation for
PEP 242.

I have made considerable progress on this:

C:\Paul\Numerical\Packages\kinds>python
Python 2.1b2 (#12, Mar 23 2001, 14:01:30) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import kinds
>>> f=kinds.float_kind(5,100)
>>> f.max
1.7976931348623157e+308
>>> f.min
2.2250738585072014e-308
>>> f.epsilon
2.2204460492503131e-016
>>> f.radix
0.3010299956639812
>>> f.epsilonbyradix
1.1102230246251565e-016
>>> 10.0**f.radix
2.0    # in case you were wondering...
>>> f(7)
7.0
>>>

These five attributes are the standard ones computed by routines such as
d1mach.
(See netlib.org, search for d1mach).

These attributes I made up:

f.name ('Float' in this case)
f.typecode ('d' in this case, a typecode suitable for modules array or
Numeric

I haven't updated the PEP itself with the comments I got, but it essentially
amounts to fixing the section on coercion, which I mainly realized I don't
really have to deal with.




From guido at digicool.com  Sat Apr  7 20:43:45 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 07 Apr 2001 13:43:45 -0500
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Sat, 07 Apr 2001 14:00:15 +0200."
             <20010407120021.5503DEA11D@oratrix.oratrix.nl> 
References: <20010407120021.5503DEA11D@oratrix.oratrix.nl> 
Message-ID: <200104071843.NAA23537@cj20424-a.reston1.va.home.com>

> There's talk on the PythonMac-SIG to create an import hook that would
> read modules with either \r, \n or \r\n newlines and convert them to
> the local convention before feeding them to the rest of the import
> machinery. The reason this has become interesting is the mixed
> unixness/macness of MacOSX, where such an import hook could be used to
> share a Python tree between MacPython and bsd-Python. They would only
> need a different site.py (probably), living somehwere near the head of
> sys.path, that would be in local end of line convention and enable the
> hook.
> 
> However, it seem that such a module would have a much more general
> scope, for instance if you're accessing samba partitions from windows,
> or other foreign file systems, etc.
> 
> Does this sound like a good idea? And (even better:-) has anyone done
> this already? Would it be of enough interest to include it in the
> core Lib?

I know that it's too late for 2.1, but for 2.2, I think we can do
better: like Java, the import mechanism should accept all three line
ending conventions on all platforms!  It would also be nice if opening
a file in text mode did this transformation, but alas, that would
probably require more work on the file object than I care for.  But
import should be doable!

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



From guido at digicool.com  Sat Apr  7 20:57:10 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 07 Apr 2001 13:57:10 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Sat, 07 Apr 2001 19:26:26 +0200."
             <20010407192627-r01010600-b0457661@213.84.27.177> 
References: <20010407192627-r01010600-b0457661@213.84.27.177> 
Message-ID: <200104071857.NAA23651@cj20424-a.reston1.va.home.com>

> > > The same goes for file objects in text mode...

Yes.

> > probably -- but changing can break stuff (in theory, at least), and
> > may require a PEP.  changing the compiler is more of a bugfix, really...

Yes.

> But if we only fix the compiler, we'll get complaints that other
> things don't work, eg. bogus tracebacks due to a non-fixed
> linecache.py, broken IDE's, etc.

Yes.

> Btw. I can't seem to think of any examples that would break after
> such a change.  I mean, who would depend on a \n text file with
> embedded \r's?

On Unix, currently, tell() always give you a number that exactly
matches the number of characters you've read since the beginning of
the file.  This would no longer be true.  In general, code written on
Unix with no expectation to ever leave Unix, can currently be sloppy
about using binary mode, and open binary files in text mode.  Such
code could break.  I'm sure there's plenty such code around (none
written by me :-).

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




From tim.one at home.com  Sat Apr  7 23:15:30 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 7 Apr 2001 17:15:30 -0400
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104071843.NAA23537@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIENFJKAA.tim.one@home.com>

As Guido said, Java defines that source-code lines end with any of LF, CR, or
CRLF, and that needn't even be consistent across lines.

If source files are opened in C binary mode, this is easy enough to do but
puts all the burden for line-end detection on Python.

Opening source files in C text mode doesn't solve the problem either.  For
example, if you open a source file with CR endings in Windows C text mode,
Windows thinks the entire file is "one line".  I expect the same is true if
CR files are opened in Unix text mode.

So, in the end, binary mode appears to be better (more uniform code).  But
then what happens under oddball systems like OpenVMS, which seem to use
radically different file structures for text and binary data?  I've no idea
what happens if you try to open a text file in binary mode under those.

[Guido]
> ...
> It would also be nice if opening a file in text mode did this
> transformation, but alas, that would probably require more work
> on the file object than I care for.

Well, Python source files aren't *just* read by "the compiler" in Python.
For example, assorted tools in the std library analyze Python source files
via opening as ordinary (Python) text files, and the runtime traceback
mechanism opens Python source files in (C) text mode too.  For that stuff to
work correctly regardless of line ends is lots of work in lots of places.  In
the end I bet it would be easier to replace all direct references to C
textfile operations with a "Python text file" abstraction layer.

importing-is-only-the-start-of-the-battle-ly y'rs  - tim




From tim.one at home.com  Sat Apr  7 23:27:35 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 7 Apr 2001 17:27:35 -0400
Subject: [Python-Dev] FW: PyChecker - a python source code bug finder
Message-ID: <LNBBLJKPBEHFEDALKOLCCENHJKAA.tim.one@home.com>

Way cool!  Check this out.  I picked 4 of the problems Neal found "at
random", and all appear to still exist under current CVS.  How about everyone
take their favorite module and fix it?

Thank you, Neal!

-----Original Message-----
From: python-list-admin at python.org
[mailto:python-list-admin at python.org]On Behalf Of Neal Norwitz
Sent: Saturday, April 07, 2001 2:28 PM
To: python-announce-list at python.org; python-list at python.org
Subject: PyChecker - a python source code bug finder



PyChecker is a python source code checking tool to help you find common bugs.
It is meant to find problems that are typically caught by a compiler. Because
of the dynamic nature of python, some warnings may be incorrect; however,
spurious warnings should be fairly infrequent.

Types of problems that can currently, be found include:

    * No doc strings in modules, classes, functions, and methods
    * self not the first parameter to a method
    * Wrong number of parameters passed to functions/methods
    * No global found (e.g., using a module without importing it)
    * Global not used (module or variable)

PyChecker currently runs on Python 2.0.  If there's interest, it can be back
ported to Python 1.5.2.

I have run PyChecker against Python 2.1b2a, the following are problems found
in the standard python modules:

    ### Warnings
        codeop.py:3 Imported module (sys) not used
        codeop.py:4 Imported module (traceback) not used
        fileinput.py:292 Function (input) doesn't require named arguments
        multifile.py:30 Imported module (sys) not used
        pipes.py:62 Imported module (sys) not used
        urllib.py:598 Function (quote) doesn't require named arguments
        urllib.py:611 Function (quote) doesn't require named arguments
        string.py:190 Variable (_StringType) not used
        tabnanny.py:15 Imported module (string) not used
                        imported again @ 241 and used there

    ### Errors:
        audiodev.py:214 No global (BUFFERSIZE) found
        bdb.py:111 No method (do_clear) found
        chunk.py:109 No attribute (chunk_size) found
			should be chunksize
        locale.py:253 No global (l) found
        netrc.py:13 No global (file) found
        pydoc.py:1070 No global (DocImportError) found
        pydoc.py:1070 No global (filename) found


PyChecker is available on Source Forge:
    web page:		http://pychecker.sourceforge.net/
    project page:	http://sourceforge.net/projects/pychecker/

Enjoy!  Feedback is greatly appreciated.

Neal
--
pychecker at metaslash.com

--
http://mail.python.org/mailman/listinfo/python-list




From tim.one at home.com  Sun Apr  8 08:41:55 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 8 Apr 2001 02:41:55 -0400
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <ADEOIFHFONCLEEPKCACCCENICHAA.paul@pfdubois.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com>

[Paul F. Dubois]
> If I understand correctly I need to supply a reference implementation
> for PEP 242.

Somebody does, but not necessarily you.

> I have made considerable progress on this:

Cool!  I'm glad it was you <wink>.

> C:\Paul\Numerical\Packages\kinds>python
> Python 2.1b2 (#12, Mar 23 2001, 14:01:30) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import kinds
> >>> f=kinds.float_kind(5,100)
> >>> f.max
> 1.7976931348623157e+308

What type of float is the result?  Is that defined?  Of the same float kind
as requested?  Or of some fixed float kind?  Or does/can it vary across
attributes?

> >>> f.min
> 2.2250738585072014e-308

Is it customary to ignore the existence of denorms?  All the same to me, but
since that's not the smallest positive non-zero double on a 754 box, the name
"min" is a fiction.  If it's a *useful* fiction, fine.

> >>> f.epsilon
> 2.2204460492503131e-016
> >>> f.radix
> 0.3010299956639812

I expect that, if you really try, you can think of a better name <wink -- but
log10radix would make a lot more sense here; + see below>.

> >>> f.epsilonbyradix
> 1.1102230246251565e-016
>
> These five attributes are the standard ones computed by routines such
> as d1mach.
> (See netlib.org, search for d1mach).

There are several.  Most are Fortran routines that ask you to first uncomment
the correct section of hard-coded DATA stmts for the platform you're running
on.  I trust you're using a dynamic approach.

Question:  are these attributes useful enough in the absence of the model
parameters from I1MACH?  That is, D1MACH exposes an idealized floating point
model approximating machine reality, parameterized by a base (radix), number
of digits, and minimum and maximum exponents.  Those four are all integers,
so were traditionally exposed via I1MACH instead (at I1MACH indices 10, 14,
15 and 16).  I expect people would find it useful if you exposed those as
attributes too, i.e. hypothetically continuing the above:

>>> f.radix  # assuming existing f.radix renamed
2
>>> f.numdigits
53
>>> f.emin
-1021
>>> f.emax
1024
>>>

Then the explanation of what the other attributes *mean* is easy, relating
them directly to the idealized f.p. model D1MACH is based on:

f.log10radix = log10(f.radix)
f.epsilon = f.radix ** (1-f.numdigits)
f.epsilonbyradix = f.radix ** -f.numdigits
f.min = f.radix ** (f.emin - 1)
f.max = f.radix**f.emax * (1 - f.epsilonbyradix)

(That last one isn't numerically correct, but mathematically; in code you'd
have to write it

    math.ldexp(1.0 - f.epsilonbyradix, f.emax)

and assuming f.radix is 2).  Note that exposing this stuff also makes clearer
why f.min doesn't tell the hardware's notion of truth for 754 boxes.

> These attributes I made up:
>
> f.name ('Float' in this case)

Since you're extending Python's floating type system with precision & range
parameters, I'd much rather see this one called 'double', since you're
obviously using a box with IEEE-754 doubles here, and all C implementations I
know of call this a double too; I expect that 99+% of all F77 implementations
also call this one double.  In addition, I expect you'll soon deal with IEEE
singles too, and then the question "single or double?" makes clear sense, but
"single or float?" is just baffling.

> f.typecode ('d' in this case, a typecode suitable for modules array or
> Numeric

Yet another reason to start f.name with "d", right?  Right <wink>.




From jim at interet.com  Sun Apr  8 15:50:23 2001
From: jim at interet.com (James C. Ahlstrom)
Date: Sun, 08 Apr 2001 09:50:23 -0400
Subject: [Python-Dev] Problems with zipfile.py
Message-ID: <3AD06C9F.848B0A98@interet.com>

The zipfile module seems to have been well received, and
I have the impression that many people are using it.  But
I have been getting complaints that it won't read ZIP files
created by InfoZip.  At first I thought this was a problem
with incompatible zlib compression versions, but now I have
found the problem.

It turns out that InfoZip's Wiz version 5.02 (and maybe other
InfoZip versions) creates ZIP files with an incorrect value
for "extra data length" in the central directory, but the correct
value in the file header.  The "extra data" is before the compressed
file data, and so this causes the file data offset to be off slightly
thus causing complaints from the zlib decompressor.  I changed
zipfile.py to use the file header value, and it fixes the problem.

I also added a new method restore(self, name, fileobject) which
was suggested some time ago by MAL.  It writes to an open file
or any other object with a write() method.  It avoids the need
to read the whole file into memory.

I also changed the "raise" statements to use the "zipfile.error"
exception.  This agrees with the documentation, but previously
zipfile raised a variety of exceptions.  This also fixes the
complaint that "BadZipfile" should be spelled "BadZipFile".

The new changed zipfile.py is available from
            ftp://ftp.interet.com/pub/zipfile.py
and is currently being tested by a user.  Please take a look.

JimA



From guido at digicool.com  Sun Apr  8 17:23:36 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 08 Apr 2001 10:23:36 -0500
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: Your message of "Sun, 08 Apr 2001 02:41:55 -0400."
             <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com> 
Message-ID: <200104081523.KAA31118@cj20424-a.reston1.va.home.com>

I don't know if it answers all the questions one could ask about a
floating point implementation, but long ago my esteemed Dutch
colleague Steven Pemberton (ABC project lead, these days chair of the
W3C XHTML working group) wrote a C program, "enquire.c", that attempts
to figure out lots of machine details.  It might help finding the
properties of floats and doubles without assuming IEEE-754.

http://www.cwi.nl/~steven/enquire.html

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



From fdrake at acm.org  Sun Apr  8 17:21:27 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sun, 8 Apr 2001 11:21:27 -0400 (EDT)
Subject: [Python-Dev] Problems with zipfile.py
In-Reply-To: <3AD06C9F.848B0A98@interet.com>
References: <3AD06C9F.848B0A98@interet.com>
Message-ID: <15056.33271.519639.865010@cj42289-a.reston1.va.home.com>

James C. Ahlstrom writes:
 > It turns out that InfoZip's Wiz version 5.02 (and maybe other
 > InfoZip versions) creates ZIP files with an incorrect value
 > for "extra data length" in the central directory, but the correct
 > value in the file header.  The "extra data" is before the compressed
 > file data, and so this causes the file data offset to be off slightly
 > thus causing complaints from the zlib decompressor.  I changed
 > zipfile.py to use the file header value, and it fixes the problem.

  This was fixed by a patch from Jens Quade in CVS revision 1.7 of
zipfile.py.

 > I also added a new method restore(self, name, fileobject) which
 > was suggested some time ago by MAL.  It writes to an open file
 > or any other object with a write() method.  It avoids the need
 > to read the whole file into memory.

  Cool!  I'll try to look at this Monday, but I'm not sure it should
go in for Python 2.1 -- it is a new feature, and we're supposed to be
in a feature freeze.

 > I also changed the "raise" statements to use the "zipfile.error"
 > exception.  This agrees with the documentation, but previously
 > zipfile raised a variety of exceptions.  This also fixes the
 > complaint that "BadZipfile" should be spelled "BadZipFile".

  I think the exceptions situation has been cleaned up as well.  You
might want to take a look at the version in Python CVS (soon to be
Python 2.1) to see what else has changed (most substantially, Itamar
Shtull-Trauring added support for loading ZIP files from open file
objects).


  -Fred

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




From paul at pfdubois.com  Sun Apr  8 17:31:53 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Sun, 8 Apr 2001 08:31:53 -0700
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEOEJKAA.tim.one@home.com>
Message-ID: <ADEOIFHFONCLEEPKCACCAEOFCHAA.paul@pfdubois.com>

Thank you for your excellent critique of my example. I will consider your
comments carefully.

The standard C library defines some constants in math.h that give the
required information. I think the right thing to do is simply include all of
those using names that make an identifiable connection to the standard
quantities (I had five of them, but there are more). This begs the question
of what to do if you are implementing Python over something other than C but
the definitions in the standard C library are clear, so in principle this
can be done.

The default Python floating point kind would be the one used to return the
(floating) attributes when queried, since I can't rely on their being any
other such kind; i.e., a C double.

Naming is going to be confusing no matter what we do. We're starting with
Python "float" == C "double" == Numeric Float == typecode 'd'. We're
doomed...





From tim.one at home.com  Sun Apr  8 21:32:34 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 8 Apr 2001 15:32:34 -0400
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <200104081523.KAA31118@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEPAJKAA.tim.one@home.com>

[Guido, on
   http://www.cwi.nl/~steven/enquire.html
]

Yup, we used that program back in my KSR days!  Looks like the source code
has grown by a factor of ~6 since then.  One of the most recent change log
entries is scary:

   5.1  Length 88739; Sep 1998
	...
	Speeded up search for max char (first 32 bit char machine
      turned up...)

The Python source code is going to be delighted with 32-bit chars.

assuming-they-went-out-of-business-already<0.7-wink>-ly y'rs  - tim




From greg at cosc.canterbury.ac.nz  Mon Apr  9 03:26:47 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 09 Apr 2001 13:26:47 +1200 (NZST)
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <20010407120021.5503DEA11D@oratrix.oratrix.nl>
Message-ID: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz>

Jack Jansen <jack at oratrix.nl>:

> read modules with either \r, \n or \r\n newlines
> Does this sound like a good idea?

YES! It's always annoyed me that the Mac (seemingly without
good reason) complains about sources with \n line endings.
I have often shuttled code between Mac and Unix systems
during development, and having to do \r/\n translations
every time is a royal pain.

> Would it be of enough interest to include it in the
> core Lib?

I'd vote for building it right into the interpreter! Is
there any reason why anyone would want *not* to have it?

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



From tim.one at home.com  Mon Apr  9 07:00:18 2001
From: tim.one at home.com (Tim Peters)
Date: Mon, 9 Apr 2001 01:00:18 -0400
Subject: [Python-Dev] A kind of configuration question 
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5ADFC@ukrux002.rundc.uk.origin-it.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEABJLAA.tim.one@home.com>

[Moore, Paul]
> ...
> --- pydoc.bat ---
> @echo off
> if "%1"=="" pythonw -c "import pydoc; pydoc.cli()"
> if NOT "%1"=="" python -c "import pydoc; pydoc.cli()" %1 %2 %3 %4 ...
> ---
>
> I do the test on %1 so that if the command is called without any
> arguments, it uses pythonw to spawn the GUI webserver, whereas with
> arguments it does the command line stuff.

FYI, that's what appears to have gotten broken the morning of the 2.1b2
release.  If you do

    pythonw -c "import pydoc; pydoc.cli()"

then or today, "nothing happens" (actually, a usage blurb gets printed to
stdout, but under pythonw that's effectively /dev/null).

If you're determined to write .bat scripts <wink>, now you want

    pythonw -c "import pydoc; pydoc.gui()"

or

    pythonw -c "import pydoc; pydoc.cli()" -g

instead.




From tim.one at home.com  Mon Apr  9 08:36:24 2001
From: tim.one at home.com (Tim Peters)
Date: Mon, 9 Apr 2001 02:36:24 -0400
Subject: [Python-Dev] Progress report on PEP 242
In-Reply-To: <ADEOIFHFONCLEEPKCACCAEOFCHAA.paul@pfdubois.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEADJLAA.tim.one@home.com>

[Paul F. Dubois]
> The standard C library defines some constants in math.h that give
> the required information. I think the right thing to do is simply
> include all of those using names that make an identifiable connection
> to the standard quantities (I had five of them, but there are more).

It's in float.h in C.  Suggest looking at the new C99 std, since they did a
better job of defining these things than C89.  Luckily, they use the same
idealized model as R1MACH/D1MACH/I1MACH (in particular, they also view the
radix point as being "to the left" of all digits, so they agree on min and
max exponents).  float.h doesn't have an equivalent to your epsilonoverradix,
though).

> This begs the question of what to do if you are implementing Python
> over something other than C but the definitions in the standard C
> library are clear, so in principle this can be done.

Since virtually all boxes on Earth use IEEE-754 f.p. now, it's not like
there's a lot of variety they'll need to contend with (and, e.g., the Java
language spec requires 754 arithmetic specifically, so Jython's life can be
hardcoded).

> The default Python floating point kind would be the one used to
> return the (floating) attributes when queried, since I can't rely
> on their being any other such kind; i.e., a C double.

Hmm.  On second thought, if I do

    f = kinds.float_kind(m, n)

and it doesn't raise an exception, then surely the kind of float f() creates
*must* exist in this implementation.  Yes?  In that case f.min and f.max
(etc) can be of exactly the kind f() returns.  If you stick to C double, then
e.g. if I implement (say) IEEE double-extended, the kind object k building
such beasts couldn't return anything sensible for k.max and k.min, because C
double doesn't have enough precision or range to represent the max and min
(or epsilon or ...) double-extended values.  But a double-extended float can.

> Naming is going to be confusing no matter what we do. We're starting
> with Python "float" == C "double" == Numeric Float == typecode 'd'.
> We're doomed...

You can break that here, though.  Are these kinds utterly distinct types, or
merely different flavors of a single float type?  I assumed the latter (BTW,
the PEP really isn't clear about how kinds work in Python's type system), in
which case there's no problem saying that (for example)

    float_kind(1, 10)

builds floats of the single flavor,

    float_kind(1, 100)

builds floats of the double flavor, and

    float_kind(1, 1000)

builds floats of the extended or quad flavor.  Etc.  Since there is only one
kind of float in (base; non-NumPy) Python today, the need for distinctions
hasn't arisen.  But once a need arises, it seems downright natural to
continue calling all of them floats, but with a kind qualifier indicating
relative precision and/or range.  Then qualifiers like "single", "double",
"quad", "extended" and "unbounded" make intuitive sense to people, and that's
Good.  "float" implies something about size only to C programmers (much like
"real" implies something about size only to Fortran programmers).






From guido at digicool.com  Mon Apr  9 15:41:22 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 08:41:22 -0500
Subject: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Mon, 09 Apr 2001 13:26:47 +1200."
             <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> 
References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> 
Message-ID: <200104091341.IAA00888@cj20424-a.reston1.va.home.com>

> I'd vote for building it right into the interpreter! Is
> there any reason why anyone would want *not* to have it?

No, but (as has been explained) fixing the parser isn't enough -- all
tools dealing with source would have to be fixed.  Or we would have to
write our own C-level file object, which has its own drawbacks.

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



From Paul.Moore at uk.origin-it.com  Mon Apr  9 15:36:34 2001
From: Paul.Moore at uk.origin-it.com (Moore, Paul)
Date: Mon, 9 Apr 2001 14:36:34 +0100 
Subject: [Python-Dev] A kind of configuration question
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AE08@ukrux002.rundc.uk.origin-it.com>

From: Guido van Rossum [mailto:guido at digicool.com]
> > On a related note, has anything happened on my other bug 
> > report (406280)? At the very least, using tempfilepager
> > instead of pipepager as a workaround would be sensible.
> > Leaving things broken makes no real sense. This is a
> > patch:
> 
> What's broken?  After "from pydoc import help" I can use help(...)
> just fine, both in the command line version (where it invokes some
> pager) and in IDLE (where it just scrolls off the window, but IDLE has
> infinite scroll-back so that's no problem).  This is on Win98se with
> Python 2.1b2.

It doesn't work in console version python.exe if you set PAGER in the
environment. I have PAGER set to "less", a much better replacement for
"more". This is on Win2000 SP1.

It works if you leave PAGER unset.

Please can this bug-fix be applied before 2.1 release? It makes it look like
pydoc just "doesn't work", as things stand. And the link to having PAGER set
is obscure, at best.

Paul.



From info at webb2e.com  Mon Apr  9 20:35:09 2001
From: info at webb2e.com (info at webb2e.com)
Date: Mon, 9 Apr 2001 11:35:09 -0700
Subject: [Python-Dev] Free register of online company's profile
Message-ID: <051071035180941MAIL@mail3.chinainfoland.com>

How much are you paying to advertise your business to the world? 

Expose Your service to the world with bold register of online business
profile. Sign up today! 

Introducing WebB2E.com -- your direct link to global information; source
of business, products, education/research, social/culture, entertainment
and travel... 
Additionally you can BUY, SELL or PROMOTE your products and services 
At www.webb2e.com <http://webb2e.com/promo1.asp>  you'll get: 

--Message center (open to the public). 
--Employment center. 
--Sponsorship center. 
--Bulletin board (business and service issue). 
--Flexible Online Office (Business Online Report). 
--Economic news. 
--View thousands of trade leads. 
--Post business propositions. 
--Merchandise marketing (Vast advertising at a low cost). 
--World shopping center. 

.. and much more. Please visit www.webb2e.com
<http://webb2e.com/promo1.asp>  

If you do not want to recieve any more e-mails from WebB2E.com and wish
to be removed from e-mail list please click here
<http://webb2e.net/remove.asp?email=python-dev at python.org> . 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20010409/bcb3f209/attachment-0001.htm>

From chrishbarker at home.net  Mon Apr  9 20:47:25 2001
From: chrishbarker at home.net (Chris Barker)
Date: Mon, 09 Apr 2001 11:47:25 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> <200104091341.IAA00888@cj20424-a.reston1.va.home.com>
Message-ID: <3AD203BD.E544ED0F@home.net>

Guido van Rossum wrote:
> No, but (as has been explained) fixing the parser isn't enough -- all
> tools dealing with source would have to be fixed.  Or we would have to
> write our own C-level file object, which has its own drawbacks.


From guido at digicool.com  Mon Apr  9 22:20:13 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 15:20:13 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Mon, 09 Apr 2001 11:47:25 MST."
             <3AD203BD.E544ED0F@home.net> 
References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> <200104091341.IAA00888@cj20424-a.reston1.va.home.com>  
            <3AD203BD.E544ED0F@home.net> 
Message-ID: <200104092020.PAA02237@cj20424-a.reston1.va.home.com>

> Guido van Rossum wrote:
> > No, but (as has been explained) fixing the parser isn't enough -- all
> > tools dealing with source would have to be fixed.  Or we would have to
> > write our own C-level file object, which has its own drawbacks.
> 
> From what people have posted, it seems clear that having our own C-level
> file object is the only reasonable choice. It would take care of all the
> issues that have been brought up (both code and other text files, etc).
> Even if people have been sloppy and used binary mode for text files
> under *nix, that code would still work with *nix text files, which is
> the only way it works now anyway.
> 
> Given that something like this has been done in numerous places (JAVA,
> MATLAB, ???), It seems likely that there is some code out there that
> could be used. Hopefully there is some without licensing issues (Maybe
> Scilab or Octave, both are MATLAB clones)

I doubt that we could use anything that was done for another language,
because everybody who codes this kind of thing makes it do exactly
what their environment needs, e.g. in terms of error handling API,
functionality, and performance.

> What are the drawbacks?? (besides the below example)

The drawbacks aren't so much technical (I have a pretty good idea of
how to build such a thing), they're political and psychological.
There's the need for supporting the old way of doing things for years,
there's the need for making it easy to convert existing code to the
new way, there's the need to be no slower than the old solution,
there's the need to be at least as portable as the old solution (which
may mean implementing it *on top of* stdio since on some systems
that's all you've got).

> I'm not sure who wrote:
> > what happens under oddball systems like OpenVMS, which seem to use
> > radically different file structures for text and binary data?  I've no idea
> > what happens if you try to open a text file in binary mode under those.
> 
> Would we have to? At the Python level, you would open a text file, and
> get what you expected. The "oddball" port would have to have some
> probably very different code for the C-level file object, but that's
> presumable the case anyway. what happens when you want to read a
> non-native text file on those systems now? So you have to read it as
> binary?
> 
> By the way, does any of this tie in at all with trying to add Perl-like
> speed to processing text files?

It would be one way towards that goal.  But notice that we've already
gotten most of the way there with the recent readline changes in 2.1.

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



From just at letterror.com  Mon Apr  9 22:00:22 2001
From: just at letterror.com (Just van Rossum)
Date: Mon,  9 Apr 2001 22:00:22 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104092020.PAA02237@cj20424-a.reston1.va.home.com>
Message-ID: <20010409220023-r01010600-7dc11706@213.84.27.177>

Proposal for 2.2, outline for a PEP?


1)
The Python file object needs to be modified so that in text mode it can
recognize all major line ending conventions (Unix, Win and Mac).

Reading data:
  - recognize \n, \r and \r\n as line ending, present as \n to Python
Writing data:
  - convert \n to the platform line endings (this is already the case)

This modification should be _optional_, because it may break code under unix
(insert Guido's explanation here), and because it may not support oddball
systems like OpenVMS.

It should be _on_ by default under:
- Windows
- MacPython Classic
- MacPython Carbon
- Unix Python under MacOS X / Darwin

It should probably be off by default on all other systems (I think a
compile-time switch is good enough). Maybe if we advertize the potential
sloppy-unix-code-breakage loud enough we can make the feature mandatory in a
later release, however I don't see a practical way of issuing warnings for the
situation.


2)
I assume there are quite a few places where Python uses raw C text files: these
places should be identified, we should figure out how much work it is to fix
these so they behave just like the Python file object as described above.



Who would like to team up with me to write a decent PEP and maybe an example
implementation?


Just



From nhodgson at bigpond.net.au  Mon Apr  9 22:46:11 2001
From: nhodgson at bigpond.net.au (Neil Hodgson)
Date: Tue, 10 Apr 2001 06:46:11 +1000
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
References: <20010409220023-r01010600-7dc11706@213.84.27.177>
Message-ID: <007401c0c136$f7d1cb10$8119fea9@neil>

Just van Rossum:

> It should probably be off by default on all other systems (I think a
> compile-time switch is good enough). Maybe if we advertize the potential
> sloppy-unix-code-breakage loud enough we can make the feature mandatory in
a
> later release, however I don't see a practical way of issuing warnings for
the
> situation.

    It should be on by default for the Python interpreter reading Python
programs as making it off by default leads to the inability to run programs
written with Windows or Mac tools on Unix which was the problem reported by
'dsavitsk' on comp.lang.python.

   If it is going to be off by default then the error message should include
"Rerun with -f to fix this error".

   Neil





From just at letterror.com  Mon Apr  9 23:07:20 2001
From: just at letterror.com (Just van Rossum)
Date: Mon,  9 Apr 2001 23:07:20 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <007401c0c136$f7d1cb10$8119fea9@neil>
Message-ID: <20010409230721-r01010600-08aa8401@213.84.27.177>

Neil Hodgson wrote:

> Just van Rossum:
> 
> > It should probably be off by default on all other systems (I think a
> > compile-time switch is good enough). Maybe if we advertize the potential
> > sloppy-unix-code-breakage loud enough we can make the feature mandatory in
> > a later release, however I don't see a practical way of issuing warnings for
> > the situation.
> 
>     It should be on by default for the Python interpreter reading Python
> programs as making it off by default leads to the inability to run programs
> written with Windows or Mac tools on Unix which was the problem reported by
> 'dsavitsk' on comp.lang.python.

Yes, but as was mentioned before: this will lead to other problems for which we
wouldn't have a good excuse: any program printing a traceback with the traceback
module will output bogus data if linecache.py will read the source files
incorrectly. And that's just one example. I don't think the two features should
be switchable separately.

Maybe it should be on by default, provided we have a command line switch to to
turn the new behavior *off*, just like there used to be a command line switch to
revert to string based exceptions.

Just



From greg at cosc.canterbury.ac.nz  Tue Apr 10 01:56:09 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 11:56:09 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104071857.NAA23651@cj20424-a.reston1.va.home.com>
Message-ID: <200104092356.LAA12517@s454.cosc.canterbury.ac.nz>

Guido:

> code written on
> Unix with no expectation to ever leave Unix, can currently be sloppy
> about using binary mode

Maybe there should be a third mode, "extremely text mode",
which Python-source-processing utilities (and anything else
which wants to be cross-platform-line-ending-friendly) can
use.

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



From greg at cosc.canterbury.ac.nz  Tue Apr 10 02:21:36 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 12:21:36 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD203BD.E544ED0F@home.net>
Message-ID: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>

Chris Barker <chrishbarker at home.net>:

> Even if people have been sloppy and used binary mode for text files
> under *nix, that code would still work with *nix text files, which is
> the only way it works now anyway.

That's a good point. The only thing that could break is if
you opened a non-Unix file in *text* mode, and then expected
it to behave as though it had been opened in *binary* mode.
I can't imagine any code being screwy enough to do that!

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



From chrishbarker at home.net  Tue Apr 10 02:37:39 2001
From: chrishbarker at home.net (Chris Barker)
Date: Mon, 09 Apr 2001 17:37:39 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <20010409220023-r01010600-7dc11706@213.84.27.177>
Message-ID: <3AD255D3.9872C019@home.net>

Just van Rossum wrote:
> Proposal for 2.2, outline for a PEP?

Thanks, Just, for getting this rolling.

> 1)
> The Python file object needs to be modified so that in text mode it can
> recognize all major line ending conventions (Unix, Win and Mac).
> 
> Reading data:
>   - recognize \n, \r and \r\n as line ending, present as \n to Python
> Writing data:
>   - convert \n to the platform line endings (this is already the case)
> 
> This modification should be _optional_, because it may break code under unix
> (insert Guido's explanation here), and because it may not support oddball
> systems like OpenVMS.
> 
> It should be _on_ by default under:
> - Windows
> - MacPython Classic
> - MacPython Carbon
> - Unix Python under MacOS X / Darwin
> 
> It should probably be off by default on all other systems (I think a
> compile-time switch is good enough). Maybe if we advertize the potential
> sloppy-unix-code-breakage loud enough we can make the feature mandatory in a
> later release, however I don't see a practical way of issuing warnings for the
> situation.

I agree that is should be possible to turn the proposed off, but I still
think it should be on by default, even on *nix systems (which is mostly
what I use, buy the way), as it would only cause a problem for "sloppy"
code anyway. Would it be possible to have it be turned on/off at
runtime, rather than compile time ? It would be pretty awkward to have a
program need a specific version of the interpreter to run. Even a
command line flag could be awkward enough, then only the main program
could specify the flag, and modules might not be compatible.

Another option is for the new version to have another flag or set of
flags to the open command, which would indicate that the file being
opened is "Unix", "Mac", "DOS", or "Any". this would make it easy to
write text files in a non-native format, as well as read them.

Even if we didn't go that far, we could use the "t" flag (analogous to
"b" for binary), to specify the universal text format, and the default
would still be the current, native format. This would keep the "sloppy"
*nix code from breaking, and still give full functionality to new code.

While we are at it, what would get written is something we need to
consider. If we just have the above proposal, reading a file would work
great, it could be on a server with a different line ending format, and
that would be transparent. Writing, on the other hand is an issue. If a
program is running on a windows box, and writing a file on a *nix
server, what kind of line ending should it write? Would it even know
what the native format is on the server? It seems we would need to be
able to specify the line ending format explicitly for writing.

Just a few thoughts, maybe we'll get a PEP out of this after all!

-Chris







-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------



From greg at cosc.canterbury.ac.nz  Tue Apr 10 02:29:42 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 12:29:42 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD203BD.E544ED0F@home.net>
Message-ID: <200104100029.MAA12528@s454.cosc.canterbury.ac.nz>

Disregard what I just said. The problem isn't about reading
text files at all, it's about reading non-text files without
explicitly opening them in binary mode.

I think the trouble is with the idea that if you don't
specify the mode explicitly it defaults to text mode, which
on Unix just happens to be the same as binary mode.

Could we change that so binary mode is the default on
Unix, and if you want any line ending translation, you
have to specify text mode explicitly? Is there any standard
which says that text mode must be the default?

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



From chrishbarker at home.net  Tue Apr 10 02:47:34 2001
From: chrishbarker at home.net (Chris Barker)
Date: Mon, 09 Apr 2001 17:47:34 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>
Message-ID: <3AD25826.8C95D0AB@home.net>

Greg Ewing wrote:
> Chris Barker <chrishbarker at home.net>:
> > Even if people have been sloppy and used binary mode for text files
> > under *nix, that code would still work with *nix text files, which is
> > the only way it works now anyway.
> 
> That's a good point. The only thing that could break is if
> you opened a non-Unix file in *text* mode, and then expected
> it to behave as though it had been opened in *binary* mode.
> I can't imagine any code being screwy enough to do that!

Actually, I thought about it more, and of course, Guido is right. On
*nix, if you open a binary file in text mode, it works just fine, as
there is no difference. However, under the proposed scheme, the text
mode would translate "\r" into "\n", messing up your binary data. It
would also do it only with a couple of particular byte values, so it
might not be obvious that anything is wrong right away.

I've done that myself, by mistake. I wrote a little tool that used FTP
to transfer some binary files. It worked fine under Linux, but then I
tried to run it on the Mac, and the files got corrupted. It took me WAY
too long to figure out that I had read the file in text mode.
Personally, I've always thought it was unfortunate that the default was
text mode, rather than binary, or even better, there could be no
default: you have to specify either "b" or "t", then there would be no
room for confusion.

-Chris

-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------



From greg at cosc.canterbury.ac.nz  Tue Apr 10 03:07:28 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 13:07:28 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD255D3.9872C019@home.net>
Message-ID: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz>

Chris Barker <chrishbarker at home.net>:

> If a program is running on a windows box, and writing a file on a *nix
> server, what kind of line ending should it write? Would it even know
> what the native format is on the server? It seems we would need to be
> able to specify the line ending format explicitly for writing.

Yes, I think that's the best that can be done. To do any better
would require all file servers to be aware of the text/binary
distinction and be willing to translate, and for there to be
some way for the Python file object to communicate to the OS
which mode is intended. Neither of these things are true in
general.

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



From greg at cosc.canterbury.ac.nz  Tue Apr 10 03:18:25 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Apr 2001 13:18:25 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <3AD25826.8C95D0AB@home.net>
Message-ID: <200104100118.NAA12540@s454.cosc.canterbury.ac.nz>

Chris Barker <chrishbarker at home.net>:

> It took me WAY
> too long to figure out that I had read the file in text mode.

My favourite way of falling into that trap involves AUFS
(the Appleshare Unix File Server). You're browsing the web
on a Unix box and come across a juicy-looking Stuffit file.
You download it into your AUFS directory, hop over to the
Mac and feed it to Stuffit Expander, which promptly throws
a wobbly.

"Shazbot," you mutter, "it got corrupted in the download
somehow." You try a couple more times, with the same result.
You're just about to write to the web site maintainer telling
them that their file is corrupt, when it dawns on you that:

(a) AUFS performs CR/LF translation on files whose Mac
type code is 'TEXT';

(b) Unix-created files default to type 'TEXT'.

(Sorry, not really Python-related. Pretend you've implemented
your Stuffit expander in Python...)

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



From guido at digicool.com  Tue Apr 10 04:32:51 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:32:51 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Tue, 10 Apr 2001 12:21:36 +1200."
             <200104100021.MAA12524@s454.cosc.canterbury.ac.nz> 
References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz> 
Message-ID: <200104100232.VAA03655@cj20424-a.reston1.va.home.com>

> Chris Barker <chrishbarker at home.net>:
> 
> > Even if people have been sloppy and used binary mode for text files
> > under *nix, that code would still work with *nix text files, which is
> > the only way it works now anyway.
> 
> That's a good point. The only thing that could break is if
> you opened a non-Unix file in *text* mode, and then expected
> it to behave as though it had been opened in *binary* mode.
> I can't imagine any code being screwy enough to do that!

Actually, that *is* the scenario I'm worried about.  Someone can open
a GIF file in text mode today on a Unix platform and it'll just work
(until they port the program to another platform, that is. ;-).  So
Unix weenies haven't had much of an incentive (or warning) about using
binary mode properlu.

In text translation mode, if there happen to be bytes with values 0x0d
in the file, they will be mangled.

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



From guido at digicool.com  Tue Apr 10 04:33:53 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:33:53 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Tue, 10 Apr 2001 12:29:42 +1200."
             <200104100029.MAA12528@s454.cosc.canterbury.ac.nz> 
References: <200104100029.MAA12528@s454.cosc.canterbury.ac.nz> 
Message-ID: <200104100233.VAA03669@cj20424-a.reston1.va.home.com>

> Disregard what I just said. The problem isn't about reading
> text files at all, it's about reading non-text files without
> explicitly opening them in binary mode.

What I said. :-)

> I think the trouble is with the idea that if you don't
> specify the mode explicitly it defaults to text mode, which
> on Unix just happens to be the same as binary mode.
> 
> Could we change that so binary mode is the default on
> Unix, and if you want any line ending translation, you
> have to specify text mode explicitly? Is there any standard
> which says that text mode must be the default?

It's pretty clear that the default is text mode.  But we could add a
new mode character, 't', to force text mode on.

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



From guido at digicool.com  Tue Apr 10 04:39:36 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:39:36 -0500
Subject: [Python-Dev] Release schedule heads up
Message-ID: <200104100239.VAA03697@cj20424-a.reston1.va.home.com>

We're planning the release candidate for 2.1 early this Friday (the
13th :-).  We need to have all changes ready early Thursday.

Then we plan to release the final version Monday the 16th, complete
with a press release and all!

The final release should be identical to the release candidate if all
goes well.

Between now and Thursday, only the most important bugs should be
fixed.  For anything else, please hold off till after 2.1final is
released!

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



From guido at digicool.com  Tue Apr 10 04:41:54 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 09 Apr 2001 21:41:54 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Tue, 10 Apr 2001 13:07:28 +1200."
             <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> 
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> 
Message-ID: <200104100241.VAA03714@cj20424-a.reston1.va.home.com>

> > If a program is running on a windows box, and writing a file on a *nix
> > server, what kind of line ending should it write? Would it even know
> > what the native format is on the server? It seems we would need to be
> > able to specify the line ending format explicitly for writing.
> 
> Yes, I think that's the best that can be done. To do any better
> would require all file servers to be aware of the text/binary
> distinction and be willing to translate, and for there to be
> some way for the Python file object to communicate to the OS
> which mode is intended. Neither of these things are true in
> general.

You might need to be able to specify a specific line ending format,
but there should also be a default -- and it should be the default
appropriate to the OS.  So, \n on Unix, \r\n on Windows, \r on Mac
running in "Mac mode", and \n on MacOS X running in "Unix mode".

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



From jwblist at olympus.net  Tue Apr 10 08:47:44 2001
From: jwblist at olympus.net (John W Baxter)
Date: Mon, 9 Apr 2001 23:47:44 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do
 end-of-line conversion?
In-Reply-To: <200104100241.VAA03714@cj20424-a.reston1.va.home.com>
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz>
 <200104100241.VAA03714@cj20424-a.reston1.va.home.com>
Message-ID: <p05100903b6f85ba98f1b@[207.149.192.229]>

At 21:41 -0500 4/9/01, Guido van Rossum wrote:
>You might need to be able to specify a specific line ending format,
>but there should also be a default -- and it should be the default
>appropriate to the OS.  So, \n on Unix, \r\n on Windows, \r on Mac
>running in "Mac mode", and \n on MacOS X running in "Unix mode".

Is it the same in Mac OS X when reading a file from a UFS volume as from an
HFS(+) volume?

Only if the underlying libraries make it so.  (Typing in Mac OS X, but I
don't have any UFS volumes lying around.)

It's a little scary to contemplate that reading two different files, which
happen to be on the same disk spindle, will behave differently for the file
on the HFS+ volume than for the file on the UFS volume.  [There are perhaps
similar issues for our Linux friends who mount Windows volumes.]

What ever happened to "move text files to another system using FTP in ASCII
mode?"  Ah, yes...it probably died of Unicode.

  --John (there may no be any answers for this) Baxter
-- 
John Baxter   jwblist at olympus.net      Port Ludlow, WA, USA



From moshez at zadka.site.co.il  Tue Apr 10 08:52:11 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Tue, 10 Apr 2001 09:52:11 +0300
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>
References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz>
Message-ID: <E14ms0Z-0000kP-00@darjeeling>

On Tue, 10 Apr 2001, Greg Ewing <greg at cosc.canterbury.ac.nz> wrote:
 
> That's a good point. The only thing that could break is if
> you opened a non-Unix file in *text* mode, and then expected
> it to behave as though it had been opened in *binary* mode.
> I can't imagine any code being screwy enough to do that!

Then you've got another thing coming. Most UNIXers aren't aware
that the 'b' modifier exists: open(file) opens the file, whether
it is text or binary.
-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From ping at lfw.org  Tue Apr 10 13:32:32 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 04:32:32 -0700 (PDT)
Subject: [Python-Dev] SocketServer and UserDict patches
Message-ID: <Pine.LNX.4.10.10104100406540.26105-100000@localhost>

Hello all,

I'd like to call your attention to two small patches that i would
like to check in for the 2.1 RC.  They're small, but they correct
breakages that i think are worth fixing.

1.  UserDict.get(), .update(), and .setdefault()

https://sourceforge.net/tracker/?func=detail&aid=413171&group_id=5470&atid=305470

    These three methods are currently implemented by calling the
    underlying object's .get(), .update(), or .setdefault() method.
    This is bad because a UserDict that overrides __getitem__ now
    will have an inconsistent or failing get() method.

    A glaring example of this is cgi.SvFormContentDict.  For such
    an object x, x['spam'] returns a single item but x.get('spam')
    returns a list of one item!

    Instead, these three methods should be implemented in terms of
    the object's own __getitem__, __setitem__, and has_key methods.
    This patch makes this change.


2.  SocketServer.StreamRequestHandler

https://sourceforge.net/tracker/?func=detail&aid=415111&group_id=5470&atid=305470

    The setup() method here duplicates the socket twice (once to
    make a read-only file, once to make a write-only file).  That
    yields three descriptors, but finish() closes only two.  This
    causes my browser to hang indefinitely waiting for the socket
    to close when SimpleHTTPServer is used to deliver a small page.

    This patch adds self.connection.close() to setup() so that
    there are just two descriptors to worry about.



-- ?!ng

"All models are wrong; some models are useful."
    -- George Box





From ping at lfw.org  Tue Apr 10 12:45:55 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 03:45:55 -0700 (PDT)
Subject: [Python-Dev] distutils.sys: None in sys.modules
Message-ID: <Pine.LNX.4.10.10104100337350.12232-100000@skuld.kingmanhall.org>

When i import distutils.util, i get:

    >>> sys.modules.keys()
    ['os', 'distutils.sys', 'distutils.os', 'exceptions', 'posix', 'distutils.spawn', 're', 'sre_constants', 'distutils.errors', 'string', 'signal', 'sre', 'posixpath', 'sre_parse', '_sre', 'os.path', 'distutils.string', 'readline', 'distutils.util', 'distutils.re', '__main__', 'distutils.dep_util', 'types', 'sys', '__builtin__', 'site', 'UserDict', 'distutils', 'sre_compile', 'copy_reg', 'stat', 'distutils.distutils']

What are 'distutils.sys', 'distutils.os', 'distutils.string',
'distutils.re', 'distutils.distutils' doing in there?  (The
sys.modules dictionary maps all these keys to None.)


-- ?!ng

"All models are wrong; some models are useful."
    -- George Box




From mal at lemburg.com  Tue Apr 10 13:43:32 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Apr 2001 13:43:32 +0200
Subject: [Python-Dev] distutils.sys: None in sys.modules
References: <Pine.LNX.4.10.10104100337350.12232-100000@skuld.kingmanhall.org>
Message-ID: <3AD2F1E4.2B61D2CD@lemburg.com>

Ka-Ping Yee wrote:
> 
> When i import distutils.util, i get:
> 
>     >>> sys.modules.keys()
>     ['os', 'distutils.sys', 'distutils.os', 'exceptions', 'posix', 'distutils.spawn', 're', 'sre_constants', 'distutils.errors', 'string', 'signal', 'sre', 'posixpath', 'sre_parse', '_sre', 'os.path', 'distutils.string', 'readline', 'distutils.util', 'distutils.re', '__main__', 'distutils.dep_util', 'types', 'sys', '__builtin__', 'site', 'UserDict', 'distutils', 'sre_compile', 'copy_reg', 'stat', 'distutils.distutils']
> 
> What are 'distutils.sys', 'distutils.os', 'distutils.string',
> 'distutils.re', 'distutils.distutils' doing in there? 

These are loaded by site.py for the case where you run Python
from the installation directory on Posix systems.

> (The
> sys.modules dictionary maps all these keys to None.)

This basically means that the corresponding modules have already
been loaded at top-level.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From ping at lfw.org  Tue Apr 10 13:55:28 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 04:55:28 -0700 (PDT)
Subject: [Python-Dev] distutils.sys: None in sys.modules
In-Reply-To: <3AD2F1E4.2B61D2CD@lemburg.com>
Message-ID: <Pine.LNX.4.10.10104100447510.26105-100000@localhost>

On Tue, 10 Apr 2001, M.-A. Lemburg wrote:
> > What are 'distutils.sys', 'distutils.os', 'distutils.string',
> > 'distutils.re', 'distutils.distutils' doing in there? 
> > (The sys.modules dictionary maps all these keys to None.)
> 
> This basically means that the corresponding modules have already
> been loaded at top-level.

But there's no 'sys' module in the distutils package.
If there were one, it would be called 'distutils.sys'
everywhere, even within the distutils package, since
we decided that packages would always use absolute
module paths, right?

This behaviour seems quite confusing to me:

    localhost[1]% ls -al foo
    total 9
    drwxr-xr-x   2 ping     users        1024 Apr 10 04:50 ./
    drwxr-xr-x  12 ping     users        5120 Apr 10 04:49 ../
    -rw-r--r--   1 ping     users           0 Apr 10 04:49 __init__.py
    -rw-r--r--   1 ping     users         106 Apr 10 04:50 __init__.pyc
    -rw-r--r--   1 ping     users          50 Apr 10 04:50 sys.py
    -rw-r--r--   1 ping     users         216 Apr 10 04:50 sys.pyc
    localhost[2]% cat foo/sys.py
    import sys, os

    print 'here is foo.sys'

    blah = 1
    localhost[3]% python -S
    Python 2.1b2 (#28, Apr 10 2001, 02:49:05) 
    [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
    Type "copyright", "credits" or "license" for more information.
    >>> import sys, foo
    >>> sys.modules.keys()
    ['__main__', '__builtin__', 'sys', 'foo', 'signal', 'exceptions']
    >>> import foo.sys
    here is foo.sys
    >>> sys.modules.keys()
    ['os.path', 'os', 'foo', 'foo.sys', 'exceptions', '__main__', 'foo.os', 'posix', 'sys', '__builtin__', 'signal', 'UserDict', 'posixpath', 'stat']
    >>> sys.modules['foo.os']
    >>> sys.modules['foo.sys']
    <module 'foo.sys' from '/home/ping/python/foo/sys.py'>
    >>> import foo.os
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ImportError: no module named 'os' could be found
    >>> import foo.sys

At this point sys.modules['foo.sys'] is a real module, as it should
be, but sys.modules['foo.os'] is None.  I don't see why 'foo.os'
should be present at all.


-- ?!ng

"All models are wrong; some models are useful."
    -- George Box




From gmcm at hypernet.com  Tue Apr 10 14:02:42 2001
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 10 Apr 2001 08:02:42 -0400
Subject: [Python-Dev] distutils.sys: None in sys.modules
In-Reply-To: <Pine.LNX.4.10.10104100337350.12232-100000@skuld.kingmanhall.org>
Message-ID: <3AD2BE22.26211.DFF74CD@localhost>

[Ka-Ping]
> 
> What are 'distutils.sys', 'distutils.os', 'distutils.string',
> 'distutils.re', 'distutils.distutils' doing in there?  (The
> sys.modules dictionary maps all these keys to None.)

Relative imports come first. Their failure is recorded so the 
next module in the package importing the same name doesn't 
go hunting for it on disk all over again.



- Gordon



From mal at lemburg.com  Tue Apr 10 14:06:47 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Apr 2001 14:06:47 +0200
Subject: [Python-Dev] distutils.sys: None in sys.modules
References: <Pine.LNX.4.10.10104100447510.26105-100000@localhost>
Message-ID: <3AD2F757.B1258004@lemburg.com>

Ka-Ping Yee wrote:
> 
> On Tue, 10 Apr 2001, M.-A. Lemburg wrote:
> > > What are 'distutils.sys', 'distutils.os', 'distutils.string',
> > > 'distutils.re', 'distutils.distutils' doing in there?
> > > (The sys.modules dictionary maps all these keys to None.)
> >
> > This basically means that the corresponding modules have already
> > been loaded at top-level.
> 
> But there's no 'sys' module in the distutils package.

The None entry is used to cache the import miss. Please see
Python/import.c for details (function mark_miss).

> If there were one, it would be called 'distutils.sys'
> everywhere, even within the distutils package, since
> we decided that packages would always use absolute
> module paths, right?
> 
> This behaviour seems quite confusing to me:
> 
>     localhost[1]% ls -al foo
>     total 9
>     drwxr-xr-x   2 ping     users        1024 Apr 10 04:50 ./
>     drwxr-xr-x  12 ping     users        5120 Apr 10 04:49 ../
>     -rw-r--r--   1 ping     users           0 Apr 10 04:49 __init__.py
>     -rw-r--r--   1 ping     users         106 Apr 10 04:50 __init__.pyc
>     -rw-r--r--   1 ping     users          50 Apr 10 04:50 sys.py
>     -rw-r--r--   1 ping     users         216 Apr 10 04:50 sys.pyc
>     localhost[2]% cat foo/sys.py
>     import sys, os
> 
>     print 'here is foo.sys'
> 
>     blah = 1
>     localhost[3]% python -S
>     Python 2.1b2 (#28, Apr 10 2001, 02:49:05)
>     [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
>     Type "copyright", "credits" or "license" for more information.
>     >>> import sys, foo
>     >>> sys.modules.keys()
>     ['__main__', '__builtin__', 'sys', 'foo', 'signal', 'exceptions']
>     >>> import foo.sys
>     here is foo.sys
>     >>> sys.modules.keys()
>     ['os.path', 'os', 'foo', 'foo.sys', 'exceptions', '__main__', 'foo.os', 'posix', 'sys', '__builtin__', 'signal', 'UserDict', 'posixpath', 'stat']
>     >>> sys.modules['foo.os']
>     >>> sys.modules['foo.sys']
>     <module 'foo.sys' from '/home/ping/python/foo/sys.py'>
>     >>> import foo.os
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>     ImportError: no module named 'os' could be found
>     >>> import foo.sys
> 
> At this point sys.modules['foo.sys'] is a real module, as it should
> be, but sys.modules['foo.os'] is None.  I don't see why 'foo.os'
> should be present at all.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From thomas at xs4all.net  Tue Apr 10 14:54:06 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Tue, 10 Apr 2001 14:54:06 +0200
Subject: [Python-Dev] INSTALL_PROGRAM
Message-ID: <20010410145406.I2820@xs4all.nl>

I just noticed that INSTALL_PROGRAM is defined as just INSTALL (either the
system "install" or the install-sh script, with possibly -c as argument)
without a -m argument (to set the mode.) INSTALL_DATA does have a -m
argument, to set the mode for all 'data' files to 644 explicitly.
INSTALL_PROGRAM gets called not just for the python executable, but also for
all files in Lib/ that have their executable bit set. Because
INSTALL_PROGRAM does not set the mode, the files (potentially, depending on
the install program/script in question) are subject to the umask and/or the
original file mode.

I've already screwed up my Python installation on a couple of BSDI boxes
twice, before I realized what the problem was :) What about we set the mode
for executables to 755 explicitly ? Distutils seems to do the right thing,
right now, but I'm pretty sure it was screwed up before. What logic does
distutils use to figure these things out ?

(There is also INSTALL_SCRIPT, but that doesn't seem to be used anywhere.)
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at digicool.com  Tue Apr 10 15:58:39 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 08:58:39 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Mon, 09 Apr 2001 23:47:44 MST."
             <p05100903b6f85ba98f1b@[207.149.192.229]> 
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> <200104100241.VAA03714@cj20424-a.reston1.va.home.com>  
            <p05100903b6f85ba98f1b@[207.149.192.229]> 
Message-ID: <200104101358.IAA05924@cj20424-a.reston1.va.home.com>

[me]
> >You might need to be able to specify a specific line ending format,
> >but there should also be a default -- and it should be the default
> >appropriate to the OS.  So, \n on Unix, \r\n on Windows, \r on Mac
> >running in "Mac mode", and \n on MacOS X running in "Unix mode".

[JW Baxter]
> Is it the same in Mac OS X when reading a file from a UFS volume as from an
> HFS(+) volume?

I'm not sure that the volume from which you're *reading* could or
should have any influence on the default delimiter used for *writing*.
The volume you're *writing* to might, if it's easy to determine -- but
personally, I'd be happy with a default set at compile time.

> Only if the underlying libraries make it so.  (Typing in Mac OS X, but I
> don't have any UFS volumes lying around.)
> 
> It's a little scary to contemplate that reading two different files, which
> happen to be on the same disk spindle, will behave differently for the file
> on the HFS+ volume than for the file on the UFS volume.  [There are perhaps
> similar issues for our Linux friends who mount Windows volumes.]

Anyway, disk spindles are the wrong abstraction level to consider
here.  Who cares about what spindle your files are on?

> What ever happened to "move text files to another system using FTP in ASCII
> mode?"  Ah, yes...it probably died of Unicode.

No, obviously it's cross-platform disk sharing.  The first time this
came up was when it became possible to mount Unix volumes on NT boxes
many years ago, and that's when Python's parser (eventually) grew the
habit of silently ignoring a \r just before a \n in a source file.

It's a sign of how backward the Mac world is that the problem only now
pops up for the Mac. :-)

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



From guido at digicool.com  Tue Apr 10 16:19:33 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 09:19:33 -0500
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: Your message of "Tue, 10 Apr 2001 04:32:32 MST."
             <Pine.LNX.4.10.10104100406540.26105-100000@localhost> 
References: <Pine.LNX.4.10.10104100406540.26105-100000@localhost> 
Message-ID: <200104101419.JAA06049@cj20424-a.reston1.va.home.com>

> I'd like to call your attention to two small patches that i would
> like to check in for the 2.1 RC.  They're small, but they correct
> breakages that i think are worth fixing.
> 
> 1.  UserDict.get(), .update(), and .setdefault()
> 
> https://sourceforge.net/tracker/?func=detail&aid=413171&group_id=5470&atid=305470
> 
>     These three methods are currently implemented by calling the
>     underlying object's .get(), .update(), or .setdefault() method.
>     This is bad because a UserDict that overrides __getitem__ now
>     will have an inconsistent or failing get() method.

I agree with the gist of this -- it should have been done the way you
propose.

>     A glaring example of this is cgi.SvFormContentDict.  For such
>     an object x, x['spam'] returns a single item but x.get('spam')
>     returns a list of one item!

But can you guarantee that fixing this so late in the release cycle
won't break anybody's code?

>     Instead, these three methods should be implemented in terms of
>     the object's own __getitem__, __setitem__, and has_key methods.
>     This patch makes this change.

I'm reluctant (-0) to making this change now.

> 
> 2.  SocketServer.StreamRequestHandler
> 
> https://sourceforge.net/tracker/?func=detail&aid=415111&group_id=5470&atid=305470
> 
>     The setup() method here duplicates the socket twice (once to
>     make a read-only file, once to make a write-only file).  That
>     yields three descriptors, but finish() closes only two.  This
>     causes my browser to hang indefinitely waiting for the socket
>     to close when SimpleHTTPServer is used to deliver a small page.
> 
>     This patch adds self.connection.close() to setup() so that
>     there are just two descriptors to worry about.

I don't think this is the right solution.  A principle I like very
much to keep my head clear about closing files is "whoever opens it
closes it".  The request/connection socket is created by a different
class, so should really be closed there.

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



From just at letterror.com  Tue Apr 10 15:20:41 2001
From: just at letterror.com (Just van Rossum)
Date: Tue, 10 Apr 2001 15:20:41 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104101358.IAA05924@cj20424-a.reston1.va.home.com>
Message-ID: <20010410152043-r01010600-eda55263@213.84.27.177>

Guido van Rossum wrote:

> It's a sign of how backward the Mac world is that the problem only now
> pops up for the Mac. :-)

I know I shouldn't bite, but I find this a very childish remark, Guido! It's
also not true... Here's an excerpt from a private thread between me, Jack and
Guido. It's dated january 8, 1996, I remember I was just learning Python. (I'll
give a translation below.)

"""
> >>     files:
> >>         is het een probleem om Mac *en* Unix files transparant te kunnen
> >>         lezen/executen? (een unix.py file veroorzaakt vreemde
> >>         error...)

(Ik neem aan dat je bedoelt files met '\n' in plaats van '\r' als line
separator.)

> >Hmm, ik weet niet of ik dit een goed idee vindt. Weet je wat: vraag
> >eens wat Guido er van vind (met een cc-tje naar mij).

Geen goed idee, tenzij de C stdio library dit automatisch doet
(kennelijk niet dus).  Het is over het algemeel een kleine moeite dit
bij het file transport recht te trekken (ftp in text mode etc.).
"""

Translation:

"""
[Just]
>>>    files:
>>>        is it a problem to read/execute Mac *and* Unix files transparently?
>>>        (a unix.py file causes a strange error...)

[Guido]
(I take it you mean files with '\n' instead of '\r' as line separator.)

[Jack]
>> Hm, I don't know whether I think this is a good idea. You know what,
>> ask Guido what he thinks (and cc me).

[Guido]
Not a good idea, unless the C stdio library does this automatically (apparently
it doesn't). In general it's a small effort to correct this during the file
transport (ftp in text mode etc.).
"""


So it's not that the problem wasn't there, it was just not taken very seriously
at the time...

Just



From guido at digicool.com  Tue Apr 10 16:23:21 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 09:23:21 -0500
Subject: [Python-Dev] distutils.sys: None in sys.modules
In-Reply-To: Your message of "Tue, 10 Apr 2001 04:55:28 MST."
             <Pine.LNX.4.10.10104100447510.26105-100000@localhost> 
References: <Pine.LNX.4.10.10104100447510.26105-100000@localhost> 
Message-ID: <200104101423.JAA06087@cj20424-a.reston1.va.home.com>

> At this point sys.modules['foo.sys'] is a real module, as it should
> be, but sys.modules['foo.os'] is None.  I don't see why 'foo.os'
> should be present at all.

See Gordon's reply (I think Marc-Andre was off base on this one):
sys.modules['foo.sys'] is set to None to prevent every "import sys" in
submodules of the foo package to hit the disk looking for foo/sys.py.

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



From jeremy at digicool.com  Tue Apr 10 17:33:42 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Tue, 10 Apr 2001 11:33:42 -0400 (EDT)
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: <200104101419.JAA06049@cj20424-a.reston1.va.home.com>
References: <Pine.LNX.4.10.10104100406540.26105-100000@localhost>
	<200104101419.JAA06049@cj20424-a.reston1.va.home.com>
Message-ID: <15059.10198.788558.316692@slothrop.digicool.com>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

  >> A glaring example of this is cgi.SvFormContentDict.  For such an
  >> object x, x['spam'] returns a single item but x.get('spam')
  >> returns a list of one item!

  GvR> But can you guarantee that fixing this so late in the release
  GvR> cycle won't break anybody's code?

  >> Instead, these three methods should be implemented in terms of
  >> the object's own __getitem__, __setitem__, and has_key methods.
  >> This patch makes this change.

  GvR> I'm reluctant (-0) to making this change now.

I with you, Guido.  The cgi model is complicated and widely used.
That combination means that it would be easy for users to get the
impression that x['spam'] and x.get('spam') work the way they do
intentionally.  I'm not comfortable changing the behavior of the model
without a beta release.

Jeremy




From chrishbarker at home.net  Tue Apr 10 20:13:56 2001
From: chrishbarker at home.net (Chris Barker)
Date: Tue, 10 Apr 2001 11:13:56 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> <200104100241.VAA03714@cj20424-a.reston1.va.home.com>  
	            <p05100903b6f85ba98f1b@[207.149.192.229]> <200104101358.IAA05924@cj20424-a.reston1.va.home.com>
Message-ID: <3AD34D64.7F66DF52@home.net>

Guido van Rossum wrote:
> No, obviously it's cross-platform disk sharing.  The first time this
> came up was when it became possible to mount Unix volumes on NT boxes

I'm sure it came up before that, I know it has for me, and I don't
happen to do any cross platform disk sharing. It is just a little more
soluble if you aren't doing disk sharing.

> many years ago, and that's when Python's parser (eventually) grew the
> habit of silently ignoring a \r just before a \n in a source file.

It can do that? I had no idea. Probably because I work on the Mac and
Linux almost exclusively, and hardly ever encounter a Windows box.
 
> It's a sign of how backward the Mac world is that the problem only now
> pops up for the Mac. :-)

Actually it's a sign of how *nix/Windows focused Python is. It's sad to
see that someone thought to fix the problem for *nix/Windows, and didn't
even consider the Mac (as Just pointed out the problem has been know for
a long time). Frankly, it's also a symptom the the isolationist attitude
of a lot of Mac users/developers. and Don't get me started on the spaces
vs tabs thing!


Just,

Are you planning on putting together a PEP from all of this? I'd really
like to see this happen!

-Chris




-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------



From barry at digicool.com  Tue Apr 10 20:32:35 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Tue, 10 Apr 2001 14:32:35 -0400
Subject: [Python-Dev] SocketServer and UserDict patches
References: <Pine.LNX.4.10.10104100406540.26105-100000@localhost>
	<200104101419.JAA06049@cj20424-a.reston1.va.home.com>
	<15059.10198.788558.316692@slothrop.digicool.com>
Message-ID: <15059.20931.149158.432871@anthem.wooz.org>

>>>>> "JH" == Jeremy Hylton <jeremy at digicool.com> writes:

    JH> I with you, Guido.  The cgi model is complicated and widely
    JH> used.  That combination means that it would be easy for users
    JH> to get the impression that x['spam'] and x.get('spam') work
    JH> the way they do intentionally.  I'm not comfortable changing
    JH> the behavior of the model without a beta release.

I'd be reluctant to change the cgi module's behavior /at all/ at this
point.  As broken as cgi.py is (and it is pretty broken), I think
you'll break a lot of code by changing its quirky API.  Better to
design a new API and write a new module.

-Barry



From ping at lfw.org  Tue Apr 10 21:46:08 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 12:46:08 -0700 (PDT)
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: <200104101419.JAA06049@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10104101006250.641-100000@skuld.kingmanhall.org>

On Tue, 10 Apr 2001, Guido van Rossum wrote:
> > 1.  UserDict.get(), .update(), and .setdefault()
[...]
> I agree with the gist of this -- it should have been done the way you
> propose.
[...]
> But can you guarantee that fixing this so late in the release cycle
> won't break anybody's code?

Right, obviously i can't.  Here are some thoughts:
(Nonetheless i do agree it's a bit late to notice this.)

    1.  All the standard tests pass with this change (though
        of course that's a small sample).

    2.  It's hard to imagine someone's code depending on this
        particular bug (i think i can justify calling it a bug).
        Anyone who wrote a UserDict-derived class that actually
        intended to use "get" most likely had to work around it
        anyway, to get any reasonable sort of result.

    3.  Would you consider allowing the addition of a get()
        method just to cgi.SvFormContentDict to fix its behaviour?
        (The broken get() behaviour was present for this particular
        class in 2.0 but not in 1.5.2.)


> > 2.  SocketServer.StreamRequestHandler
[...]
> I don't think this is the right solution.  A principle I like very
> much to keep my head clear about closing files is "whoever opens it
> closes it".  The request/connection socket is created by a different
> class, so should really be closed there.

Good point.  How about adding to BaseServer.handle_request instead?

    def handle_request(self):
        """Handle one request, possibly blocking."""
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                self.process_request(request, client_address)
            except:
                self.handle_error(request, client_address)
  +     request.close()

I forgot to mention that this is a testable and observable fix
(Netscape gets stuck in Linux and IE gets stuck in Win2K without
the fix, and both work properly when i make this fix.)

Note that this makes explicit the division of responsibilities
that, if the request handler wants to continue dealing with the
request connection after its constructor returns (as in the
case of the forking and threading variants), it must duplicate
its own copy of the file descriptor (which it already does).
I think this is good, as then each file descriptor can be
associated with a clear owner.


-- ?!ng

"Don't worry about people stealing an idea.  If it's original, you'll
have to jam it down their throats."
    -- Howard Aiken




From guido at digicool.com  Tue Apr 10 22:45:35 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 15:45:35 -0500
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: Your message of "Tue, 10 Apr 2001 12:46:08 MST."
             <Pine.LNX.4.10.10104101006250.641-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10104101006250.641-100000@skuld.kingmanhall.org> 
Message-ID: <200104102045.PAA07295@cj20424-a.reston1.va.home.com>

> On Tue, 10 Apr 2001, Guido van Rossum wrote:
> > > 1.  UserDict.get(), .update(), and .setdefault()
> [...]
> > I agree with the gist of this -- it should have been done the way you
> > propose.
> [...]
> > But can you guarantee that fixing this so late in the release cycle
> > won't break anybody's code?
> 
> Right, obviously i can't.  Here are some thoughts:
> (Nonetheless i do agree it's a bit late to notice this.)
> 
>     1.  All the standard tests pass with this change (though
>         of course that's a small sample).
> 
>     2.  It's hard to imagine someone's code depending on this
>         particular bug (i think i can justify calling it a bug).
>         Anyone who wrote a UserDict-derived class that actually
>         intended to use "get" most likely had to work around it
>         anyway, to get any reasonable sort of result.
> 
>     3.  Would you consider allowing the addition of a get()
>         method just to cgi.SvFormContentDict to fix its behaviour?
>         (The broken get() behaviour was present for this particular
>         class in 2.0 but not in 1.5.2.)

Let's just fix this after releasing 2.1, OK?  As you say, it's
unlikely that this affects anybody one way or the other, and right now
I'm for stability in favor of fixing warts (believe me, I have a few
other favorite warts that I won't fix before releasing 2.1 :-).

> 
> > > 2.  SocketServer.StreamRequestHandler
> [...]
> > I don't think this is the right solution.  A principle I like very
> > much to keep my head clear about closing files is "whoever opens it
> > closes it".  The request/connection socket is created by a different
> > class, so should really be closed there.
> 
> Good point.  How about adding to BaseServer.handle_request instead?
> 
>     def handle_request(self):
>         """Handle one request, possibly blocking."""
>         try:
>             request, client_address = self.get_request()
>         except socket.error:
>             return
>         if self.verify_request(request, client_address):
>             try:
>                 self.process_request(request, client_address)
>             except:
>                 self.handle_error(request, client_address)
>   +     request.close()

Alas, this is still at the wrong level.  The get_request() method is
overridable (e.g. by the UDPServer class) and the request that it
returns may not have a close method.  The best I can come up with is
to add an empty method self.close_request(request) to the base class,
call it in handle_request(), and override it to call request.close()
in the TCPServer class.

> I forgot to mention that this is a testable and observable fix
> (Netscape gets stuck in Linux and IE gets stuck in Win2K without
> the fix, and both work properly when i make this fix.)

I believe you -- I've noticed weird slownesses when using
SimpleHTTPServer.

> Note that this makes explicit the division of responsibilities
> that, if the request handler wants to continue dealing with the
> request connection after its constructor returns (as in the
> case of the forking and threading variants), it must duplicate
> its own copy of the file descriptor (which it already does).
> I think this is good, as then each file descriptor can be
> associated with a clear owner.

No argument there!

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



From guido at digicool.com  Tue Apr 10 23:47:08 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 16:47:08 -0500
Subject: [Python-Dev] SourceForge search-by-ID implemented
Message-ID: <200104102147.QAA07642@cj20424-a.reston1.va.home.com>

I received the email below from the friendly folks at SourceForge --
you can now search bugs and patches by number.  Cool!

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

------- Forwarded Message

Date:    Tue, 10 Apr 2001 19:45:55 +0300
From:    Paul Sokolovsky <pfalcon at sourceforge.net>
To:      Guido van Rossum <guido at python.org>
Subject: Fwd: [alexandria - Feature Requests] ANN: search artifacts (bugs etc.)
	   by #

Hello Guido,

      I would like to notify that another of your feature requests
for SourceForge has been done. Sorry that it took so much time -
search is one of the most straining parts of the site, and there was a
marathory for any changes to it...

This is a forwarded message
From: noreply at sourceforge.net <noreply at sourceforge.net>
To: noreply at sourceforge.net <noreply at sourceforge.net>
Subject: [alexandria - Feature Requests] ANN: search artifacts (bugs etc.) by #

===8<==============Original message text===============

Read and respond to this message at:
http://sourceforge.net/forum/message.php?msg_id=137990
By: pfalcon

There were many request to allow to display bugs, support requests, etc. by
their number, having typed it into search box. Finally, it's here. By typing
digit sequence, optionally preceeded by #, you'll get that item (in addition
to items where that string present literally, of course).


Enjoy!



______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge and visit:
http://sourceforge.net/forum/monitor.php?forum_id=4


===8<===========End of original message text===========



- --
Paul Sokolovsky,        http://sourceforge.net/users/pfalcon
SourceForge developer   http://sourceforge.net


------- End of Forwarded Message




From nas at python.ca  Tue Apr 10 23:08:55 2001
From: nas at python.ca (Neil Schemenauer)
Date: Tue, 10 Apr 2001 14:08:55 -0700
Subject: [Python-Dev] SourceForge search-by-ID implemented
In-Reply-To: <200104102147.QAA07642@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 10, 2001 at 04:47:08PM -0500
References: <200104102147.QAA07642@cj20424-a.reston1.va.home.com>
Message-ID: <20010410140854.B31183@glacier.fnational.com>

Guido van Rossum wrote:
> I received the email below from the friendly folks at SourceForge --
> you can now search bugs and patches by number.  Cool!

Yah!  This reminds me of something the Debian bug tracking system
does that is really cool.  If you include the string "Fixes: #123"
in the changelog the bug system will notice and close the bug for
you.

I don't think SourceForge should implement this feature.
Instead, some ambitious person could write a script that watches
the CVS checkin list and interact with the sourceforge site.  The
script could also add a comment to the bug logging who fixed it
and the versions of the files changed.  That information is
probably useful when trying to bugfix release.

  Neil



From ping at lfw.org  Wed Apr 11 03:06:36 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 10 Apr 2001 18:06:36 -0700 (PDT)
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: <200104102045.PAA07295@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10104101746580.641-100000@skuld.kingmanhall.org>

On Tue, 10 Apr 2001, Guido van Rossum wrote:
> > > > 1.  UserDict.get(), .update(), and .setdefault()
[...]
> Let's just fix this after releasing 2.1, OK?

Okay.

> As you say, it's
> unlikely that this affects anybody one way or the other

True, it is largely about people writing *new* scripts conveniently.

> > > > 2.  SocketServer.StreamRequestHandler
[...]
> Alas, this is still at the wrong level.  The get_request() method is
> overridable (e.g. by the UDPServer class) and the request that it
> returns may not have a close method.  The best I can come up with is
> to add an empty method self.close_request(request) to the base class,
> call it in handle_request(), and override it to call request.close()
> in the TCPServer class.

Yes, i agree that's a good division of responsibilities.  See the
updated patch.  I think it would be nice if it could go in, but it's
up to you if you want to accept it.


-- ?!ng

"Don't worry about people stealing an idea.  If it's original, you'll
have to jam it down their throats."
    -- Howard Aiken





From guido at digicool.com  Wed Apr 11 05:29:31 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 10 Apr 2001 22:29:31 -0500
Subject: [Python-Dev] SocketServer and UserDict patches
In-Reply-To: Your message of "Tue, 10 Apr 2001 18:06:36 MST."
             <Pine.LNX.4.10.10104101746580.641-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10104101746580.641-100000@skuld.kingmanhall.org> 
Message-ID: <200104110329.WAA11332@cj20424-a.reston1.va.home.com>

> > > > > 2.  SocketServer.StreamRequestHandler
> [...]
> > Alas, this is still at the wrong level.  The get_request() method is
> > overridable (e.g. by the UDPServer class) and the request that it
> > returns may not have a close method.  The best I can come up with is
> > to add an empty method self.close_request(request) to the base class,
> > call it in handle_request(), and override it to call request.close()
> > in the TCPServer class.
> 
> Yes, i agree that's a good division of responsibilities.  See the
> updated patch.  I think it would be nice if it could go in, but it's
> up to you if you want to accept it.

I've accepted this and assigned it to you.  That means that *you*
should check it in!  (This is so that the CVS logs show the author of
the patch.)

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



From tim.one at home.com  Wed Apr 11 06:20:42 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 11 Apr 2001 00:20:42 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <3AD34D64.7F66DF52@home.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEGKJLAA.tim.one@home.com>

[Guido]
>> ...
>> that's when Python's parser (eventually) grew the habit of
>> silently ignoring a \r just before a \n in a source file.

[Chris Barker]
> It can do that? I had no idea. Probably because I work on the Mac and
> Linux almost exclusively, and hardly ever encounter a Windows box.

>> It's a sign of how backward the Mac world is that the problem only
>> now pops up for the Mac. :-)

> Actually it's a sign of how *nix/Windows focused Python is. It's sad
> to see that someone thought to fix the problem for *nix/Windows, and
> didn't even consider the Mac (as Just pointed out the problem has
> been know for a long time).

This is a reversal of history.  The code to ignore
    \r
when seeing
    \r\n
originally (1995) applied to *all* platforms.  I don't know why, but Jack
submitted a patch to disable this behavior only when "#ifdef macintosh", in
revision 2.29 of Parser/tokenizer.c, about 4 years ago.  The #ifdef
introduced then still exists today; 3 lines introduced by that patch start
with XXX here for clarity (appropriately defined <wink>):

XXX #ifndef macintosh
			/* replace "\r\n" with "\n" */
XXX			/* For Mac we leave the \r, giving a syntax error */
			pt = tok->inp - 2;
			if (pt >= tok->buf && *pt == '\r') {
				*pt++ = '\n';
				*pt = '\0';
				tok->inp = pt;
			}
XXX #endif

I have no idea what Mac C libraries return for text-mode reads.  They must
convert \r to \n, right?  In which case I guess any \r remaining *should* be
"an error" (but where would it come from, if the C library converts all \r
thingies?).  Do they leave \n alone?  Etc:  submit a patch that makes the
code above "work", and I'm sure it would be accepted, but a non-Mac person
can't guess what's needed.

As to "considering the Mac", guilty as charged:  I don't know anything about
it.  What's to consider?  How often do you consider the impact of chnages on,
say, OpenVMS?  Same thing, provided you're as ignorant of it as I am of your
system.

> Frankly, it's also a symptom the the isolationist attitude of a
> lot of Mac users/developers. and Don't get me started on the spaces
> vs tabs thing!

The std for distributed Python code is 4-space indents, no hard tab
characters.  So there's nothing left there to get started on <wink>.

it's-not-that-we-don't-want-to-"fix"-macs-it's-that-we-don't-know-
    how-macs-work-or-what-"fix"-*means*-to-a-macizoid-ly y'rs  - tim




From just at letterror.com  Wed Apr 11 12:03:27 2001
From: just at letterror.com (Just van Rossum)
Date: Wed, 11 Apr 2001 12:03:27 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEGKJLAA.tim.one@home.com>
Message-ID: <20010411120330-r01010600-75da8509@213.84.27.177>

Tim Peters wrote:

> This is a reversal of history.  The code to ignore
>     \r
> when seeing
>     \r\n
> originally (1995) applied to *all* platforms.  I don't know why, but Jack
> submitted a patch to disable this behavior only when "#ifdef macintosh", in
> revision 2.29 of Parser/tokenizer.c, about 4 years ago.  The #ifdef
> introduced then still exists today; 3 lines introduced by that patch start
> with XXX here for clarity (appropriately defined <wink>):

Interesting, I didn't know that. Jack's on holiday now, so he won't be able to
comment for a while.

> I have no idea what Mac C libraries return for text-mode reads.  They must
> convert \r to \n, right? 

Yes.

> In which case I guess any \r remaining *should* be
> "an error" (but where would it come from, if the C library converts all \r
> thingies?).  Do they leave \n alone? 

Nope: \r's get translated to \n and for whatever reason \n's get translated to
\r... So when opening a unix file on the Mac, it will look like it has \r line
endings and when opening a Windows text file on the Mac, it will appear as if it
has \n\r line endings...

> Etc:  submit a patch that makes the
> code above "work", and I'm sure it would be accepted, but a non-Mac person
> can't guess what's needed.

That's probably easy enough -- although would require changing all tokenizer
code that looks for \n to also look for \r, including PyOS_ReadLine(), so it
goes well beyond the snippet you posted. And then there's the Python file
object...

Just



From tim.one at home.com  Thu Apr 12 00:15:01 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 11 Apr 2001 18:15:01 -0400
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Lib/test test_math.py,1.10,1.11 test_fork1.py,1.8,1.9 test_fcntl.py,1.16,1.17
In-Reply-To: <E14nRh0-0003EH-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEJJJLAA.tim.one@home.com>

> Update of /cvsroot/python/python/dist/src/Lib/test
> In directory usw-pr-cvs1:/tmp/cvs-serv12386
>
> Modified Files:
> 	test_math.py test_fork1.py test_fcntl.py
> Log Message:
> Unixware 7 support by Billy G. Allie (SF patch 413011)
> ...
> ***************
> *** 36,40 ****
>   testit('atan2(-1, 0)', math.atan2(-1, 0), -math.pi/2)
>   testit('atan2(-1, 1)', math.atan2(-1, 1), -math.pi/4)
> ! testit('atan2(0, 1)', math.atan2(0, 1), 0)
>   testit('atan2(1, 1)', math.atan2(1, 1), math.pi/4)
>   testit('atan2(1, 0)', math.atan2(1, 0), math.pi/2)
> --- 37,44 ----
>   testit('atan2(-1, 0)', math.atan2(-1, 0), -math.pi/2)
>   testit('atan2(-1, 1)', math.atan2(-1, 1), -math.pi/4)
> ! if sys.platform in ['unixware7']:
> !     testit('atan2(0, 1)', math.atan2(0, 1), math.pi)
> ! else:
> !     testit('atan2(0, 1)', math.atan2(0, 1), 0)
>   testit('atan2(1, 1)', math.atan2(1, 1), math.pi/4)
>   testit('atan2(1, 0)', math.atan2(1, 0), math.pi/2)

atan2(0, 1) should be 0 on *all* platforms.  It's too bad if the original
test fails on unixware7, but if it does it means their libm's atan2() is
buggy.  C99 spells this out in excruciating detail.  C89 isn't as clear, but
is clear enough:

    The atan2(y, x) function computes the principal value of the
    arc tangent of y/x, using the signs of both arguments to
    determine the quadrant of the return value.  A domain
    error may occur if both arguments are 0.

IOW, atan2 returns the angle with x-axis made by a unit vector from the
origin to the point (x, y).  The point (1, 0) lies on the x axis, pointing to
the right, so is at an angle of 0.  The only question is whether it should be
+0 or -0, and while C99 spells that out too, Python's test doesn't
distinguish those cases so we don't have to answer that here.

So, if nobody leaps to defend unixware7, I'm going to revert that part of the
patch.




From mwh21 at cam.ac.uk  Thu Apr 12 00:31:48 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 11 Apr 2001 23:31:48 +0100
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/plat-unixware7 FCNTL.py,NONE,1.1 IN.py,NONE,1.1 SOCKET.py,NONE,1.1 STROPTS.py,NONE,1.1 TERMIOS.py,NONE,1.1 regen,NONE,1.1
In-Reply-To: Guido van Rossum's message of "Wed, 11 Apr 2001 13:54:46 -0700"
References: <E14nRdW-00032q-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <m3ae5nrru3.fsf@atrus.jesus.cam.ac.uk>

Guido van Rossum <gvanrossum at users.sourceforge.net> writes:

> Update of /cvsroot/python/python/dist/src/Lib/plat-unixware7
> In directory usw-pr-cvs1:/tmp/cvs-serv11682
> 
> Added Files:
> 	FCNTL.py IN.py SOCKET.py STROPTS.py TERMIOS.py regen 

Ehh... I didn't think we did TERMIOS.py or SOCKET.py any more?

Cheers,
M.




From greg at cosc.canterbury.ac.nz  Thu Apr 12 01:44:01 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Apr 2001 11:44:01 +1200 (NZST)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do
In-Reply-To: <20010411120330-r01010600-75da8509@213.84.27.177>
Message-ID: <200104112344.LAA12806@s454.cosc.canterbury.ac.nz>

end-of-line conversion?

Just van Rossum <just at letterror.com>:
> Tim Peters wrote:
> > I have no idea what Mac C libraries return for text-mode reads.  They must
> > convert \r to \n, right? 
> Yes.

Unless you're using the MPW compiler, which swaps the meanings
of \r and \n in the source instead!

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



From tim.one at home.com  Thu Apr 12 02:14:19 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 11 Apr 2001 20:14:19 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010411120330-r01010600-75da8509@213.84.27.177>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com>

[Just van Rossum]
> Nope: \r's get translated to \n and for whatever reason \n's get
> translated to \r... So when opening a unix file on the Mac, it
> will look like it has \r line endings and when opening a Windows
> text file on the Mac, it will appear as if it has \n\r line endings...

Then it's probably a Good Thing Jack disabled this code, since it wouldn't
have done anything useful on a Mac anyway (for Python to ever see \r\n the
source file would have had to contain \n\r, which is nobody's text file
convention).

>> Etc:  submit a patch that makes the code above "work", and I'm
>> sure it would be accepted, but a non-Mac person can't guess
>> what's needed.

> That's probably easy enough -- although would require changing all
> tokenizer code that looks for \n to also look for \r, including
> PyOS_ReadLine(), so it goes well beyond the snippet you posted.

No, there's nothing wrong with the tokenizer code:  it's coded in C, and the
C text convention is that lines end with \n, period.  Reliance on that
convention is ubiquitous -- and properly so.  What we need instead are
platform-specific implementations of fgets() functionality, which deliver
lines containing \n where and only where the platform Python is supposed to
believe a line ends.  Then nothing else in the parser needs to be touched
(and, indeed, the current \r\n mini-hack could be thrown away).

> And then there's the Python file object...

Different issue.  If this ever gets that far, note that the crunch to speed
up line-at-a-time file input ended up *requiring* use of the native fgets()
on Windows, as that was the only way on that platform to avoid having the OS
do layers of expensive multithreading locks for each character read.  So
there's no efficient way in general to get Windows to recognize \r line
endings short of implementing our own stdio from the ground up.  On other
platforms, fileobject.c's get_line() reads one character at a time, and I
expect its test for "is this an EOL char?" could be liberalized at reasonable
cost.

OTOH, how does the new-fangled Mac OS fit into all this?  Perhaps, for
compatibility, their C libraries already recognize both Unix and Mac Classic
line conventions, and deliver plain \n endings for both?  Or did they blow
that part too <wink>?




From guido at digicool.com  Thu Apr 12 04:21:36 2001
From: guido at digicool.com (Guido van Rossum)
Date: Wed, 11 Apr 2001 21:21:36 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Wed, 11 Apr 2001 20:14:19 -0400."
             <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com> 
Message-ID: <200104120221.VAA14315@cj20424-a.reston1.va.home.com>

> Different issue.  If this ever gets that far, note that the crunch
> to speed up line-at-a-time file input ended up *requiring* use of
> the native fgets() on Windows, as that was the only way on that
> platform to avoid having the OS do layers of expensive
> multithreading locks for each character read.  So there's no
> efficient way in general to get Windows to recognize \r line endings
> short of implementing our own stdio from the ground up.  On other
> platforms, fileobject.c's get_line() reads one character at a time,
> and I expect its test for "is this an EOL char?" could be
> liberalized at reasonable cost.

I expect that the right solution here is indeed to write our own
stdio-like library from the ground up.  That can solve any number of
problems: telling how many characters are buffered (so you don't have
to use unbuffered mode when using select or poll),
platform-independent line end recognition, and super-efficient
readline() to boot.

But it's a lot of work, and won't be compatible with existing
extensions that use FILE* (not too many I believe).

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



From guido at digicool.com  Thu Apr 12 04:46:21 2001
From: guido at digicool.com (Guido van Rossum)
Date: Wed, 11 Apr 2001 21:46:21 -0500
Subject: [Python-Dev] Proposed patch to cgi.py for 2.1 -- please review!
Message-ID: <200104120246.VAA14451@cj20424-a.reston1.va.home.com>

I'd like some feedback on the patch below to cgi.py.  For background,
read SF bug #231249:

  http://sourceforge.net/tracker/?func=detail&aid=231249&group_id=5470&atid=105470

The problem is that when a POST request is received with a
Content-type of multipart/form-data, an anonymous temporary file is
created and kept open for each part -- whether or not it is a
file-upload!  For forms with many fields, this can use up more file
descriptors than the server is allowed to have.  There's no way to
tell whether a particular part is a file or not; the filename are
optional and the input field type is not available here.  My solution
uses a StringIO and transparently switches to a temporary file object
when a part grows larger than 1000 characters.

Question: does this look like it could break anything?  I know the cgi
module is used a lot so any change in semantics, however subtle, could
potentially cause problems for some poor soul out there...

(It could break code if someone tries to use the fileno() on a field
object's file attribute.)

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

Index: cgi.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/cgi.py,v
retrieving revision 1.63
diff -c -r1.63 cgi.py
*** cgi.py	2001/03/19 13:40:44	1.63
--- cgi.py	2001/04/11 20:18:20
***************
*** 633,644 ****
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.file = self.make_file('')
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
--- 633,652 ----
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.file = self.__file = StringIO()
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
+     def __write(self, line):
+         if self.__file is not None:
+             if self.__file.tell() + len(line) > 1000:
+                 self.file = self.make_file('')
+                 self.file.write(self.__file.getvalue())
+                 self.__file = None
+         self.file.write(line)
+ 
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
***************
*** 646,652 ****
              if not line:
                  self.done = -1
                  break
!             self.file.write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
--- 654,660 ----
              if not line:
                  self.done = -1
                  break
!             self.__write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
***************
*** 674,680 ****
                  line = line[:-1]
              else:
                  delim = ""
!             self.file.write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""
--- 682,688 ----
                  line = line[:-1]
              else:
                  delim = ""
!             self.__write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""



From greg at cosc.canterbury.ac.nz  Thu Apr 12 05:02:39 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Apr 2001 15:02:39 +1200 (NZST)
Subject: [Python-Dev] Proposed patch to cgi.py for 2.1 -- please review!
In-Reply-To: <200104120246.VAA14451@cj20424-a.reston1.va.home.com>
Message-ID: <200104120302.PAA12841@s454.cosc.canterbury.ac.nz>

Guido:

> (It could break code if someone tries to use the fileno() on a field
> object's file attribute.)

Switch to a real file when someone accesses the file attribute?

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



From fdrake at beowolf.digicool.com  Thu Apr 12 06:39:34 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Thu, 12 Apr 2001 00:39:34 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010412043934.B61E12879C@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


Almost to Python 2.1 release candidate 1 status.  This includes a variety
of small updates and a good bit more documentation on the PyUnit version
that will be included with the final release (new text essentially 
converted from Steve Purcell's HTML docs).




From jeremy at digicool.com  Thu Apr 12 07:08:00 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Thu, 12 Apr 2001 01:08:00 -0400 (EDT)
Subject: [Python-Dev] make install produces compiler warnings
Message-ID: <15061.14384.617116.153973@slothrop.digicool.com>

I just noticed that a make install prints out a bunch of warnings
about .py files it is compiling.  Many of the errors are in files that
I included in Lib/test that are designed to trigger errors or warnings
about future statements.  Rather than stuff all the different bogus
code examples into strings and pass them to exec, I placed them in
files that are imported by test_future.py.  nocaret.py is a similar
file used to test the exceptions printed for SyntaxErrors.

I think tokenize_tests.py is doing the same thing, but it isn't my
fault :-).

Here's the full list of output to stderr:

  File "/usr/local/lib/python2.1/test/nocaret.py", line 2
    [x for x in x] = x
SyntaxError: can't assign to list comprehension
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future3.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future4.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future5.py, line 4)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future6.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future7.py, line 3)
SyntaxError: duplicate argument 'rest' in function definition (tokenize_tests.py, line 147)
  File "/usr/local/lib/python2.1/test/nocaret.py", line 2
    [x for x in x] = x
SyntaxError: can't assign to list comprehension
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future3.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future4.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future5.py, line 4)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future6.py, line 3)
SyntaxError: from __future__ imports must occur at the beginning of the file (test_future7.py, line 3)
SyntaxError: duplicate argument 'rest' in function definition (tokenize_tests.py, line 147)
warning: install: modules installed to '/usr/local/lib/python2.1/lib-dynload/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself

Should we do something to quiet these warnings?  I never noticed them
before since there's *so much* noise produced by make install.

Jeremy




From tim.one at home.com  Thu Apr 12 07:30:28 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 12 Apr 2001 01:30:28 -0400
Subject: [Python-Dev] make install produces compiler warnings
In-Reply-To: <15061.14384.617116.153973@slothrop.digicool.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOELBJLAA.tim.one@home.com>

[Jeremy]
> I just noticed that a make install prints out a bunch of warnings
> about .py files it is compiling.

Yes, JimF noticed that within the last week too, and it threw him off track
(me too).  Meant to mention it.  Of course it's not a problem on Windows --
no make there to make make problems <wink>.

Irrelevantly, the damaged files test_future.py is trying to import should not
have been named with a "test_" prefix (maybe a "bad_" prefix instead), and
then there would have been no need to add them to the NOTTEST list in
regrtest.py either.

Could the Unix makefile be taught not to compile the supposed-to-fail .py
files?  Would that be easier if all the supposed-to-fail files were renamed
to something other than test_*.py?




From tim.one at home.com  Thu Apr 12 08:41:20 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 12 Apr 2001 02:41:20 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104120221.VAA14315@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCELFJLAA.tim.one@home.com>

[Guido]
> I expect that the right solution here is indeed to write our own
> stdio-like library from the ground up.  That can solve any number of
> problems: telling how many characters are buffered (so you don't have
> to use unbuffered mode when using select or poll), platform-
> independent line end recognition, and super-efficient readline()
> to boot.

We also have the old

    http://sourceforge.net/tracker/?group_id=5470&
        atid=105470&func=detail&aid=210821

complaining that use of FILE* in our C API can make it impossible to (in that
fellow's case) write an app in Borland C++ on Windows that tries to use those
API functions (cuz Borland's FILE* is incompatible with MS's FILE*).  I'm not
sure the best solution to *that* is to give them a FILE* that's incompatible
with everyone's, though <wink>>

> But it's a lot of work, and won't be compatible with existing
> extensions that use FILE* (not too many I believe).

I'm more concerned about the "lot of work" part, with which I agree.

OTOH, Plauger's book "The Standard C Library" contains source code for every
library required by C89.  He reported that implementing libm took him twice
as long as everything else combined.  But those who haven't written a libm
will be prone to take a wrong lesson from that <wink>.

it's-not-that-i/o-is-easy-despite-that-his-libm-code-isn't-production-
    quality-ly y'rs  - tim




From just at letterror.com  Thu Apr 12 10:03:33 2001
From: just at letterror.com (Just van Rossum)
Date: Thu, 12 Apr 2001 10:03:33 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEKAJLAA.tim.one@home.com>
Message-ID: <20010412100334-r01010600-5b54bb95@213.84.27.177>

Tim Peters wrote:

> No, there's nothing wrong with the tokenizer code:  it's coded in C, and the
> C text convention is that lines end with \n, period.  Reliance on that
> convention is ubiquitous -- and properly so. 

I don't get it: why would a thin layer on top of stdio be bad? Seems much less
work than reimplementing stdio.

Just



From mwh21 at cam.ac.uk  Thu Apr 12 12:43:19 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: Thu, 12 Apr 2001 11:43:19 +0100 (BST)
Subject: [Python-Dev] python-dev summary, 2001-03-19 - 2001-04-12
Message-ID: <Pine.LNX.4.10.10104121142060.1820-100000@localhost.localdomain>

 This is a summary of traffic on the python-dev mailing list between
 Mar 29 and Apr 11 (inclusive) 2001.  It is intended to inform the
 wider Python community of ongoing developments.  To comment, just
 post to python-list at python.org or comp.lang.python in the usual
 way. Give your posting a meaningful subject line, and if it's about a
 PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep
 iteration) All python-dev members are interested in seeing ideas
 discussed by the community, so don't hesitate to take a stance on a
 PEP if you have an opinion.

 This is the fifth summary written by Michael Hudson.
 Summaries are archived at:

  <http://starship.python.net/crew/mwh/summaries/>

   Posting distribution (with apologies to mbm)

   Number of articles in summary: 166

    25 |                                                 [|]    
       |                                 [|]             [|]    
       |                                 [|]             [|]    
       |                                 [|]             [|]    
    20 |     [|]                         [|]             [|]    
       |     [|]                         [|]             [|]    
       |     [|]                         [|]             [|]    
       |     [|]                         [|]             [|]    
    15 |     [|]                         [|]         [|] [|]    
       |     [|]                         [|]         [|] [|]    
       |     [|]                         [|]         [|] [|]    
       |     [|]             [|]     [|] [|]         [|] [|]    
    10 |     [|]             [|]     [|] [|] [|]     [|] [|]    
       |     [|]             [|]     [|] [|] [|]     [|] [|]    
       |     [|]             [|]     [|] [|] [|]     [|] [|]    
       |     [|]             [|] [|] [|] [|] [|]     [|] [|] [|]
     5 |     [|]     [|]     [|] [|] [|] [|] [|] [|] [|] [|] [|]
       |     [|]     [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
       | [|] [|]     [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
       | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
     0 +-003-022-002-006-005-013-007-013-026-012-006-017-027-007
        Thu 29| Sat 31| Mon 02| Wed 04| Fri 06| Sun 08| Tue 10|
            Fri 30  Sun 01  Tue 03  Thu 05  Sat 07  Mon 09  Wed 11

 Not much traffic this fortnight.  As ever, lots of bug-fixing for
 2.1.  If all goes to plan, I won't be able to say that in the next
 summary!


    * Assigning to __debug__ *

 About 2 weeks ago, changes were checked in that made assignments to
 the magic variable __debug__ SyntaxErrors.  Martin von Loewis pointed
 out that this would probably break code, and thus not be well
 received:

  <http://mail.python.org/pipermail/python-dev/2001-March/013995.html>

 There was general agreement, and it was decided that the error would
 be reduced to a warning.  Code to this effect has now been checked
 in.


    * Inverse string interpolation *

 Peter Funk posted a proposal for using the "/" operator on strings as
 a kind of dual to "%", i.e. be to "%" what "scanf" is to "printf" in
 C:

  <http://mail.python.org/pipermail/python-dev/2001-April/014027.html>

 There was muted approval for the idea, but less so for the spelling.
 Of course "scanf" isn't much better unless you've programmed in C...
 It's possible that this functionality will be somewhere in Python 2.2
 (though builtin, module, infix operator or string method is still to
 be decided, and it might be conditional on someone coming up with a
 good name!).


    * Line endings *

 A recurring theme (with a pretty long period) cropped up again: that
 of line endings in Python source code.  The thread stars here:

  <http://mail.python.org/pipermail/python-dev/2001-April/014090.html>

 At present, one cannot import a file with Unix line endings on the
 Macintosh.  While it would be relatively straightforward to bodge the
 compiler into accepting any of \n, \r or \r\n as a line terminator,
 this would not entirely solve the problem; for instance linecache.py
 in the standard library would need to be fixed.

 One option would be to implement a wrapper around file objects that
 would make .readline() work with all line endings.  However, this
 would be entertainingly difficult to get right on all platforms...

 You author hopes resolution is near, but admits to being slightly
 confused about the details!


    * Release schedule *

 A release candidate for Python 2.1 should be released tomorrow (the
 13th), and if all goes well, the final release will be on Monday (the
 16th).  Fingers crossed everyone!

Cheers,
M.




From guido at digicool.com  Thu Apr 12 20:47:12 2001
From: guido at digicool.com (Guido van Rossum)
Date: Thu, 12 Apr 2001 13:47:12 -0500
Subject: [Python-Dev] Proposed patch to cgi.py for 2.1 -- please review!
In-Reply-To: Your message of "Thu, 12 Apr 2001 15:02:39 +1200."
             <200104120302.PAA12841@s454.cosc.canterbury.ac.nz> 
References: <200104120302.PAA12841@s454.cosc.canterbury.ac.nz> 
Message-ID: <200104121847.NAA20986@cj20424-a.reston1.va.home.com>

> > (It could break code if someone tries to use the fileno() on a field
> > object's file attribute.)
> 
> Switch to a real file when someone accesses the file attribute?

Hm.  I can do that, but I'm less happy about the resulting mess. :-(

Here's the patch.  I think I'get back to this post-2.1...

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

Index: cgi.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/cgi.py,v
retrieving revision 1.63
diff -c -r1.63 cgi.py
*** cgi.py	2001/03/19 13:40:44	1.63
--- cgi.py	2001/04/12 16:45:50
***************
*** 509,515 ****
                  raise ValueError, 'Maximum content length exceeded'
          self.length = clen
  
!         self.list = self.file = None
          self.done = 0
          if ctype == 'application/x-www-form-urlencoded':
              self.read_urlencoded()
--- 509,515 ----
                  raise ValueError, 'Maximum content length exceeded'
          self.length = clen
  
!         self.list = self.__file = None
          self.done = 0
          if ctype == 'application/x-www-form-urlencoded':
              self.read_urlencoded()
***************
*** 524,531 ****
--- 524,537 ----
                  `self.name`, `self.filename`, `self.value`)
  
      def __getattr__(self, name):
+         if name == 'file':
+             self.file = self.__file_incarnate()
+             self.file.seek(0)
+             return self.file
          if name != 'value':
              raise AttributeError, name
+         if self.__file:
+             return self.__file.getvalue()
          if self.file:
              self.file.seek(0)
              value = self.file.read()
***************
*** 614,620 ****
              self.skip_lines()
          else:
              self.read_lines()
!         self.file.seek(0)
  
      bufsize = 8*1024            # I/O buffering size for copy to file
  
--- 620,627 ----
              self.skip_lines()
          else:
              self.read_lines()
!         if not self.__file:
!             self.file.seek(0)
  
      bufsize = 8*1024            # I/O buffering size for copy to file
  
***************
*** 633,644 ****
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.file = self.make_file('')
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
--- 640,665 ----
  
      def read_lines(self):
          """Internal: read lines until EOF or outerboundary."""
!         self.__file = StringIO()
          if self.outerboundary:
              self.read_lines_to_outerboundary()
          else:
              self.read_lines_to_eof()
  
+     def __file_incarnate(self):
+         file = self.make_file('')
+         file.write(self.__file.getvalue())
+         self.__file = None
+         return file
+ 
+     def __write(self, line):
+         if self.__file is not None:
+             if self.__file.tell() + len(line) <= 1000:
+                 self.__file.write(line)
+                 return
+             self.file = self.__file_incarnate()
+         self.file.write(line)
+ 
      def read_lines_to_eof(self):
          """Internal: read lines until EOF."""
          while 1:
***************
*** 646,652 ****
              if not line:
                  self.done = -1
                  break
!             self.file.write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
--- 667,673 ----
              if not line:
                  self.done = -1
                  break
!             self.__write(line)
  
      def read_lines_to_outerboundary(self):
          """Internal: read lines until outerboundary."""
***************
*** 674,680 ****
                  line = line[:-1]
              else:
                  delim = ""
!             self.file.write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""
--- 695,701 ----
                  line = line[:-1]
              else:
                  delim = ""
!             self.__write(odelim + line)
  
      def skip_lines(self):
          """Internal: skip lines until outer boundary if defined."""



From guido at digicool.com  Fri Apr 13 00:37:09 2001
From: guido at digicool.com (Guido van Rossum)
Date: Thu, 12 Apr 2001 17:37:09 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Thu, 12 Apr 2001 10:03:33 +0200."
             <20010412100334-r01010600-5b54bb95@213.84.27.177> 
References: <20010412100334-r01010600-5b54bb95@213.84.27.177> 
Message-ID: <200104122237.RAA21755@cj20424-a.reston1.va.home.com>

> I don't get it: why would a thin layer on top of stdio be bad? Seems
> much less work than reimplementing stdio.

Because by layering stuff you lose performance.  Example: fgets() is
often implemented in a way that is faster than you can ever do
yourself with portable code.  (Because fgets() can peek in the buffer
and see if there's a \n somewhere ahead, using memcmp() -- and if this
succeeds, it can use memcpy().  You can't do that yourself - only the
stdio implementation can.  And this is not a hypothetical situation --
Tim used fgets() for a significant speed-up of readline() in 2.1.

But if we want to use our own line end convention, we can't use
fgets() any more, so we lose big.

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



From nas at python.ca  Thu Apr 12 23:39:37 2001
From: nas at python.ca (Neil Schemenauer)
Date: Thu, 12 Apr 2001 14:39:37 -0700
Subject: [Python-Dev] Problem with SSL and socketmodule on Debian Potato?
Message-ID: <20010412143937.A3784@glacier.fnational.com>

Fresh CVS tree:

Python 2.1c1 (#2, Apr 12 2001, 17:23:20) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/scratch/nascheme/py_cvs/dist/src/Lib/socket.py", line 41, in ?
    from _socket import *
ImportError: /scratch/nascheme/py_cvs/dist/src/linux/build/lib.linux-i686-2.1/_socket.so: undefined symbol: RAND_status

socketmodule is linked thusly:

gcc -shared build/temp.linux-i686-2.1/socketmodule.o -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-i686-2.1/_socket.so

The SSL package is:

    libssl09-dev 0.9.4-5

I've no time to dig into the details right now but I should have
time tonight.  I will be gone on holiday tomorrow.

  Neil



From martin at loewis.home.cs.tu-berlin.de  Thu Apr 12 23:59:58 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 12 Apr 2001 23:59:58 +0200
Subject: [Python-Dev] Problem with SSL and socketmodule on Debian Potato?
Message-ID: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de>

> ImportError:
> /scratch/nascheme/py_cvs/dist/src/linux/build/lib.linux-i686-2.1/_socket.so:
> undefined symbol: RAND_status

That symbol should be defined in libcrypto.so (it is on my SuSE
system); so that may be a problem with the Debian libssl package. SuSE
ships openssl-0.9.5a-54.

It appears that RAND_status was indeed added between 0.9.4 and
0.9.5. A test for OPENSSL_VERSION_NUMBER would probably help; in
0.9.5a, it has the value of 0x0090581fL.

Regards,
Martin



From sdm7g at Virginia.EDU  Fri Apr 13 00:08:50 2001
From: sdm7g at Virginia.EDU (Steven D. Majewski)
Date: Thu, 12 Apr 2001 18:08:50 -0400 (EDT)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
 conversion?
In-Reply-To: <200104122237.RAA21755@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.NXT.4.21.0104121755170.227-100000@localhost.virginia.edu>

[ re: various remarks about layering on stdio ] 

Has anybody looked at sfio ? 

I used it long ago for other reasons -- for a while the distribution 
seemed to have disappeared from att ( or maybe I just couldn't find
it on netlib ), but I just did a google search and found that there
is a new distribution: sfio2000: 

http://www.research.att.com/sw/tools/sfio/

I haven't looked at the package or the code for a LONG time & I 
don't know how portable it is, but it has some nice features and
advantages -- if you're at the point of considering rewriting 
stdio it might be worth looking at. 

-- Steve Majewski





From nas at python.ca  Fri Apr 13 02:41:19 2001
From: nas at python.ca (Neil Schemenauer)
Date: Thu, 12 Apr 2001 17:41:19 -0700
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Apr 12, 2001 at 11:59:58PM +0200
References: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de>
Message-ID: <20010412174118.A4120@glacier.fnational.com>

Martin v. Loewis wrote:
> It appears that RAND_status was indeed added between 0.9.4 and
> 0.9.5. A test for OPENSSL_VERSION_NUMBER would probably help; in
> 0.9.5a, it has the value of 0x0090581fL.

Right.  From my RAND_status man page:

       RAND_seed() and RAND_screen() are available in all
       versions of SSLeay and OpenSSL. RAND_add() and
       RAND_status() have been added in OpenSSL 0.9.5,
       RAND_event() in OpenSSL 0.9.5a.

The Debian libssl09-dev package does not work while
libssl096-dev does.  Both are available in the current stable
version of Debian (Potato).  We should patch socketmodule or add
a note to the README.

Sometimes I wonder if going to setup.py to build modules was a
mistake.  It would be easy to use autoconf to test of the
RAND_status function exists.  OTOH, its probably not too hard to
add the smarts to setup.py.

  Neil



From m.favas at per.dem.csiro.au  Fri Apr 13 02:43:57 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Apr 2001 08:43:57 +0800
Subject: [Python-Dev] 2.1c1: test_format failing?
Message-ID: <3AD64BCD.DD91216E@per.dem.csiro.au>

A couple of additions to test_format.py between April 12 and 13 now
cause the test to fail on Tru64 Unix (with Compaq's C compiler). Has
anyone else noticed errors with the test? The failures when running the
test standalone are:

'%#o' % 0 =? '0' ... no
u'%#o' % 0 =? '0' ... no

and from "make test":

test_format
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == '00' != '0'",
expected: ''

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From aahz at rahul.net  Fri Apr 13 02:54:56 2001
From: aahz at rahul.net (Aahz Maruch)
Date: Thu, 12 Apr 2001 17:54:56 -0700 (PDT)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line
In-Reply-To: <Pine.NXT.4.21.0104121755170.227-100000@localhost.virginia.edu> from "Steven D. Majewski" at Apr 12, 2001 06:08:50 PM
Message-ID: <20010413005457.432DD99C86@waltz.rahul.net>

Steven D. Majewski wrote:
> 
> [ re: various remarks about layering on stdio ] 
> 
> Has anybody looked at sfio ? 

That reminds me of QIO, the stdio replacement in INN, which has already
been ported to Python.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.



From tim.one at home.com  Fri Apr 13 03:00:08 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 12 Apr 2001 21:00:08 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <Pine.NXT.4.21.0104121755170.227-100000@localhost.virginia.edu>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENKJLAA.tim.one@home.com>

[Steven D. Majewski]
> Has anybody looked at sfio ?
> ...
> http://www.research.att.com/sw/tools/sfio/

Did just now.  Only runs on Unix boxes, so would be a heavyweight way to
solve line-end problems across platforms that don't have any <wink>.
Possible to run it on Windows, but only on top of the commercial UWIN Unix
emulation package (http://www.research.att.com/sw/tools/uwin/).  They didn't
mention Macs at all.  The papers should be worth reading for anyone intending
to tackle this, though.




From tim.one at home.com  Fri Apr 13 03:17:09 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 12 Apr 2001 21:17:09 -0400
Subject: [Python-Dev] 2.1c1: test_format failing?
In-Reply-To: <3AD64BCD.DD91216E@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCEENLJLAA.tim.one@home.com>

[Mark Favas]
> A couple of additions to test_format.py between April 12 and 13 now
> cause the test to fail on Tru64 Unix (with Compaq's C compiler). Has
> anyone else noticed errors with the test? The failures when runnin
> the test standalone are:
>
> '%#o' % 0 =? '0' ... no
> u'%#o' % 0 =? '0' ... no
> ...
> But instead we got: "'%#o' % 0 == '00' != '0'"

Please run this C program:

#include <stdio.h>
void main() {
    printf("%#o\n", 0);
}

Does it print 00?  It *should* print 0:

    # The result is converted to an ??alternative form??. For
      o conversion, it increases the precision, if and only if
      necessary, to force the first digit of the result to be a
      zero (if the value and precision are both 0, a single 0 is
      printed). ...

In the test program, the value and precision are both 0, so a single '0' must
be the result (else your platform C is buggy).

Please let us know what happens.  Does anyone else get 00 from the above?




From m.favas at per.dem.csiro.au  Fri Apr 13 03:43:19 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Apr 2001 09:43:19 +0800
Subject: [Python-Dev] 2.1c1: test_format failing?
References: <LNBBLJKPBEHFEDALKOLCEENLJLAA.tim.one@home.com>
Message-ID: <3AD659B7.8F24082F@per.dem.csiro.au>

I've tried the test program on a few of my Tru64 boxes (with different
versions of the OS and different versions of the compiler) and all print
"00".


Tim Peters wrote:
> 
> [Mark Favas]
> > A couple of additions to test_format.py between April 12 and 13 now
> > cause the test to fail on Tru64 Unix (with Compaq's C compiler). Has
> > anyone else noticed errors with the test? The failures when runnin
> > the test standalone are:
> >
> > '%#o' % 0 =? '0' ... no
> > u'%#o' % 0 =? '0' ... no
> > ...
> > But instead we got: "'%#o' % 0 == '00' != '0'"
> 
> Please run this C program:
> 
> #include <stdio.h>
> void main() {
>     printf("%#o\n", 0);
> }
> 
> Does it print 00?  It *should* print 0:
> 
>     # The result is converted to an ??alternative form??. For
>       o conversion, it increases the precision, if and only if
>       necessary, to force the first digit of the result to be a
>       zero (if the value and precision are both 0, a single 0 is
>       printed). ...
> 
> In the test program, the value and precision are both 0, so a single '0' must
> be the result (else your platform C is buggy).
> 
> Please let us know what happens.  Does anyone else get 00 from the above?

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From tim.one at home.com  Fri Apr 13 04:51:56 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 12 Apr 2001 22:51:56 -0400
Subject: [Python-Dev] 2.1c1: test_format failing?
In-Reply-To: <3AD659B7.8F24082F@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEOFJLAA.tim.one@home.com>

[Mark Favas]
> I've tried the test program on a few of my Tru64 boxes (with different
> versions of the OS and different versions of the compiler) and all
> print "00".

Then that's why Python '%#o' % 0 also returns "00" (formats of short ints use
the platform sprintf).  As far as I'm concerned, then, this is a
long-standing bug in Compaq's C (the blurb I quoted before was verbatim from
the C standard, and addressed this specific case).

I expect you'll find that '%#o' % 0L returns "0" even on your box, because
Python does its own formats on long ints.

As time goes on, and we eradicate the differences between ints and longs, I
expect we'll end up using the Python long int format code all the time.

Before then, I'm disinclined to add more code to the short int case trying to
worm around platform C bugs, unless at least one other platform is found
where

#include <stdio.h>
void main() {
    printf("%#o\n", 0);
}

prints 00.

BTW, what does this print for you (just changing "o" to "x")?

#include <stdio.h>
void main() {
    printf("%#x\n", 0);
}

If they print 0x0 for that (they're supposed to print 0), current CVS Python
will assert-fail in debug mode on '%#x' % 0.




From m.favas at per.dem.csiro.au  Fri Apr 13 05:43:29 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Apr 2001 11:43:29 +0800
Subject: [Python-Dev] 2.1c1: test_format failing?
References: <LNBBLJKPBEHFEDALKOLCAEOFJLAA.tim.one@home.com>
Message-ID: <3AD675E1.C93AFE56@per.dem.csiro.au>

Responses interpolated below...

[Tim Peters]
> 
> [Mark Favas]
> > I've tried the test program on a few of my Tru64 boxes (with different
> > versions of the OS and different versions of the compiler) and all
> > print "00".
> 
> Then that's why Python '%#o' % 0 also returns "00" (formats of short ints use
> the platform sprintf).  As far as I'm concerned, then, this is a
> long-standing bug in Compaq's C (the blurb I quoted before was verbatim from
> the C standard, and addressed this specific case).
> 
> I expect you'll find that '%#o' % 0L returns "0" even on your box, because
> Python does its own formats on long ints.

It does indeed.


> 
> As time goes on, and we eradicate the differences between ints and longs, I
> expect we'll end up using the Python long int format code all the time.
> 
> Before then, I'm disinclined to add more code to the short int case trying to
> worm around platform C bugs, unless at least one other platform is found
> where
> 
> #include <stdio.h>
> void main() {
>     printf("%#o\n", 0);
> }
> 
> prints 00.

I've just tried Solaris 2.5.1, Solaris 8, FreeBSD 4.2 and even(!) Irix
6.5 - all produce "0" - :( or :) depending on your POV.


> 
> BTW, what does this print for you (just changing "o" to "x")?
> 
> #include <stdio.h>
> void main() {
>     printf("%#x\n", 0);
> }
> 
> If they print 0x0 for that (they're supposed to print 0), current CVS Python
> will assert-fail in debug mode on '%#x' % 0.

This produces "0"

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From fdrake at beowolf.digicool.com  Fri Apr 13 07:10:02 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Fri, 13 Apr 2001 01:10:02 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010413051002.795BD2879C@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


More description and explanation in the unittest documentation; update to
match the final code and decisions from the pyunit-interest mailing list.

Added information on urllib.FancyURLopener's handling of basic 
authentication and how to change the prompting behavior.

Added documentation for the ColorPicker module for the Macintosh.




From rushing at nightmare.com  Fri Apr 13 07:45:14 2001
From: rushing at nightmare.com (Sam Rushing)
Date: Thu, 12 Apr 2001 22:45:14 -0700
Subject: [Python-Dev] Test cases for asynchat, asyncore?
References: <LNBBLJKPBEHFEDALKOLCKEJAJKAA.tim.one@home.com>
		<3ACDB0BC.2533D8C2@digicool.com> <15053.56089.93466.30362@anthem.wooz.org>
Message-ID: <3AD6926A.12C937B@nightmare.com>

"Barry A. Warsaw" wrote:

> Oh, one other thing.  Last time I traded email with Sam Rushing
> (almost a year ago, and I'm not even sure if he's on python-dev), he
> was moving toward a coroutine based Medusa and away from async* based.

One of the reasons I originally offered them into the distribution was
that those two modules were always distributed under a standard python
license, while the rest of medusa was still 'commercial'.  Since that's
no longer the case, there's less of a reason to have it in the standard
lib.  [But I think there are a lot of async* users out there...]

Coupla other points:

  1) there are folks (myself included) that would like to see a new
design for asyncore and asynchat, one that doesn't require the expensive
polling of objects and that can have lots of its underbelly parts
replaced with C when necessary.  A totally new 'official' facility that
was aware of and could take advantage of the features of /dev/poll,
kqueue, rtsig, etc.. would be way cool.  I don't think that backward
compatibility would be all that important, since most software uses
async* in a 'shallow' way rather than a 'deep' way - it's be easy to
recode to a newer more efficient API.

  2) it'll be a while before anything polished will be along to obsolete
async*/medusa.  I'm currently working with kqueue and stackless
coroutines but don't know when/if I might be able to release the code.
Such a beast will be radically different from medusa, and would certainly
have a new name...  it's almost more of a 'python-level user-threading
package' (like uthread) than a replacement for async*.

-Sam





From tim.one at home.com  Fri Apr 13 09:12:05 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 13 Apr 2001 03:12:05 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010412100334-r01010600-5b54bb95@213.84.27.177>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEONJLAA.tim.one@home.com>

[Tim]
> No, there's nothing wrong with the tokenizer code:  it's coded
> in C, and the C text convention is that lines end with \n, period.
> Reliance on that convention is ubiquitous -- and properly so.

[Just van Rossum]
> I don't get it: why would a thin layer on top of stdio be bad?
> Seems much less work than reimplementing stdio.

What does that question have to do with the snippet you quoted?  In context,
that snippet was saying that if you did write a small layer on top of stdio,
one that just made \n show up when and only when you think Python should
believe a line ends, then nothing in the tokenizer would need to change
(except to call that layer instead of fgets()), and even the tokenizer's
current \r\n mini-hack could be thrown away.

If that's all you want, that's all it takes.  If you want more than just
that, you need more than just that (but I see Guido already explained that,
and I explained too why the Windows Python cannot recognize \r endings with
reasonable speed for *general* use short of building our own stdio -- but I
don't really much care how fast the compiler runs, if all you want is the
same limited level of hack afforded by the existing one-shot \r\n tokenizer
trick -- and the compiler isn't using the *general*-case fileobject.c
get_line() anyway).

you-pay-for-what-you-want-and-the-more-you-want-the-more-you'll-pay-ly
    y'rs  - tim




From tim.one at home.com  Fri Apr 13 09:40:47 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 13 Apr 2001 03:40:47 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <200104122237.RAA21755@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEOOJLAA.tim.one@home.com>

[Guido]
> ...
> But if we want to use our own line end convention, we can't use
> fgets() any more, so we lose big.

Well, people said "we couldn't" use fgets() for get_line() either, because
Python strings can contain embedded nulls but fgets() doesn't tell you how
many bytes it read and makes up null bytes of its own.  But I have 200 lines
of excruciating code in fileobject.c that proved them excruciatingly wrong
<wink>.  The same kind of excruciating crap could almost certainly be used to
search for alternative line endings on top of fgets() too.  We would have to
layer our own buffer on top of the hidden platform buffer to get away with
this, because while fgets() will stop at the first \n it sees, there's no way
to ask it to stop at any other character (so in general fgets() would
"over-read" when looking for a non-native line-end, and we'd have to save the
excess in our own buffer).

Hard to say how much that would cost.  I think it surprised everyone (incl.
me!) that even with all the extra buffer-filling and buffer-searching the
fgets() hackery does, that method was at worst a wash with the
getc_unlocked() method on all platforms tried.

In any case, the fgets() hack is only *needed* on Windows, so every other
platform could just make get_line()'s character-at-a-time loop search for
more end conditions.  This can't be impossible <wink>.

s/\r\n?/\n/g-ly y'rs  - tim




From mal at lemburg.com  Fri Apr 13 10:24:18 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 13 Apr 2001 10:24:18 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
References: <200104122159.f3CLxwI02747@mira.informatik.hu-berlin.de> <20010412174118.A4120@glacier.fnational.com>
Message-ID: <3AD6B7B2.18C3788D@lemburg.com>

Neil Schemenauer wrote:
> 
> Martin v. Loewis wrote:
> > It appears that RAND_status was indeed added between 0.9.4 and
> > 0.9.5. A test for OPENSSL_VERSION_NUMBER would probably help; in
> > 0.9.5a, it has the value of 0x0090581fL.
> 
> Right.  From my RAND_status man page:
> 
>        RAND_seed() and RAND_screen() are available in all
>        versions of SSLeay and OpenSSL. RAND_add() and
>        RAND_status() have been added in OpenSSL 0.9.5,
>        RAND_event() in OpenSSL 0.9.5a.
> 
> The Debian libssl09-dev package does not work while
> libssl096-dev does.  Both are available in the current stable
> version of Debian (Potato).  We should patch socketmodule or add
> a note to the README.
> 
> Sometimes I wonder if going to setup.py to build modules was a
> mistake.  It would be easy to use autoconf to test of the
> RAND_status function exists.  OTOH, its probably not too hard to
> add the smarts to setup.py.

distutils has the machinery for this built-in, but it's not
really ready for prime-time yet. See the mxSetup.py file in my
egenix-mx-base source archive for some auto-conf style code
built on top of the basic tools available in distutils.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From just at letterror.com  Fri Apr 13 11:43:21 2001
From: just at letterror.com (Just van Rossum)
Date: Fri, 13 Apr 2001 11:43:21 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEOOJLAA.tim.one@home.com>
Message-ID: <20010413114324-r01010600-54b4467f@213.84.27.177>

I understand now that I simply don't have enough clue about the implementation
to even try to be involved with this. Unless it makes sense to have a PEP that
doesn't touch the implementation at all (doubtful, IMHO), I'll take back my
offer to write one. I still think it's an important issue, but it's simply
beyond what I can deal with.

To solve the issues on MacOS X, maybe it's enough to hack the Carbon version of
stdio so it can handle unix text files. That way we can simply settle for unix
line ending if sharing code between BSD Python and Carbon Python is desired. At
the same time this would allow using CVS under Darwin for MacPython sources,
which is something I look forward to...

Just



From mal at lemburg.com  Fri Apr 13 13:09:09 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 13 Apr 2001 13:09:09 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <20010413114324-r01010600-54b4467f@213.84.27.177>
Message-ID: <3AD6DE54.ED351E8E@lemburg.com>

Just van Rossum wrote:
> 
> I understand now that I simply don't have enough clue about the implementation
> to even try to be involved with this. Unless it makes sense to have a PEP that
> doesn't touch the implementation at all (doubtful, IMHO), I'll take back my
> offer to write one. I still think it's an important issue, but it's simply
> beyond what I can deal with.

Please write the results of this discussion up as a PEP. PEPs don't
necessarily have to provide an implementation of what is covered;
it sometimes simply suffices to start out with a summary of the
discussions that have been going on. Then someone may pick up the
threads from there and possibly find a solution which will then
get implemented.
 
> To solve the issues on MacOS X, maybe it's enough to hack the Carbon version of
> stdio so it can handle unix text files. That way we can simply settle for unix
> line ending if sharing code between BSD Python and Carbon Python is desired. At
> the same time this would allow using CVS under Darwin for MacPython sources,
> which is something I look forward to...

AFAIR, this discussion was about handling line endings in Python
source code. There have been discussions about turning the tokenizer
into a Unicode based machine. We could then use the Unicode tools
to do line separations.

I don't know why this thread lead to tweaking stdio -- after all
we only need a solution for the Python tokenizer and not a general
purpose stdio abstraction of text files unless I'm missing something
here...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From just at letterror.com  Fri Apr 13 13:43:25 2001
From: just at letterror.com (Just van Rossum)
Date: Fri, 13 Apr 2001 13:43:25 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <3AD6DE54.ED351E8E@lemburg.com>
Message-ID: <20010413134326-r01010600-bafaee65@213.84.27.177>

M.-A. Lemburg wrote:

> I don't know why this thread lead to tweaking stdio -- after all
> we only need a solution for the Python tokenizer and not a general
> purpose stdio abstraction of text files unless I'm missing something
> here...

Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all,
but then what about all tools that read source files line by line? Eg.
linecache.py, all IDE's, etc. etc. As Tim wrote a while back:

  importing-is-only-the-start-of-the-battle

So no, we don't "only need a solution for the Python tokenizer"...

Just



From aahz at rahul.net  Fri Apr 13 15:13:22 2001
From: aahz at rahul.net (Aahz Maruch)
Date: Fri, 13 Apr 2001 06:13:22 -0700 (PDT)
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010413134326-r01010600-bafaee65@213.84.27.177> from "Just van Rossum" at Apr 13, 2001 01:43:25 PM
Message-ID: <20010413131323.6358899C97@waltz.rahul.net>

Just van Rossum wrote:
> M.-A. Lemburg wrote:
> 
>> I don't know why this thread lead to tweaking stdio -- after all
>> we only need a solution for the Python tokenizer and not a general
>> purpose stdio abstraction of text files unless I'm missing something
>> here...
> 
> Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all,
> but then what about all tools that read source files line by line? Eg.
> linecache.py, all IDE's, etc. etc. 

<grin>  I'll repeat my question of yesterday: is there any reason why we
couldn't start with QIO?  I did some checking after I sent that out, and
QIO claims that it can be configured to recognize different kinds of
line endings.  QIO is claimed to be 2-3 times faster than Python 1.5.2;
don't know how that compares to 2.x.

[the previous message was sent to python-dev only; this time I'm
including pythonmac-sig]
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.



From guido at digicool.com  Fri Apr 13 16:52:35 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 09:52:35 -0500
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
In-Reply-To: Your message of "Fri, 13 Apr 2001 06:13:22 MST."
             <20010413131323.6358899C97@waltz.rahul.net> 
References: <20010413131323.6358899C97@waltz.rahul.net> 
Message-ID: <200104131452.JAA27545@cj20424-a.reston1.va.home.com>

> <grin>  I'll repeat my question of yesterday: is there any reason why we
> couldn't start with QIO?  I did some checking after I sent that out, and
> QIO claims that it can be configured to recognize different kinds of
> line endings.  QIO is claimed to be 2-3 times faster than Python 1.5.2;
> don't know how that compares to 2.x.


From martin at loewis.home.cs.tu-berlin.de  Fri Apr 13 17:29:23 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 13 Apr 2001 17:29:23 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
Message-ID: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de>

> Sometimes I wonder if going to setup.py to build modules was a
> mistake.  It would be easy to use autoconf to test of the
> RAND_status function exists.  OTOH, its probably not too hard to add
> the smarts to setup.py.

I don't think it was a mistake. First, even though Python had been
using autoconf for years, nobody came up with a complete patch to
autoconfiscate Modules/Setup, or define a different configuration
mechanism. So using setup.py was an improvement over the status quo,
even if not an improvement over some not-implemented technique - which
might have never been implemented.

Furthermore, as Marc-Andr? points out: there is nothing that stops
setup.py/distutils from using the same strategies as autoconf.

Finally, in this specific case, I do think that the best strategy is
to check for the version of OpenSSL. This is against autoconf
philosophy (check for features, not for versions), but since the SSL
support is tied to a specific implementation, rather than an API with
competing implementations, checking the version does no harm and
simplifies the configuration machinery.

Regards,
Martin



From guido at digicool.com  Fri Apr 13 18:39:59 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 11:39:59 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Fri, 13 Apr 2001 17:29:23 +0200."
             <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> 
References: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> 
Message-ID: <200104131639.LAA31088@cj20424-a.reston1.va.home.com>

> I don't think it was a mistake. First, even though Python had been
> using autoconf for years, nobody came up with a complete patch to
> autoconfiscate Modules/Setup, or define a different configuration
> mechanism. So using setup.py was an improvement over the status quo,
> even if not an improvement over some not-implemented technique - which
> might have never been implemented.
> 
> Furthermore, as Marc-Andr? points out: there is nothing that stops
> setup.py/distutils from using the same strategies as autoconf.
> 
> Finally, in this specific case, I do think that the best strategy is
> to check for the version of OpenSSL. This is against autoconf
> philosophy (check for features, not for versions), but since the SSL
> support is tied to a specific implementation, rather than an API with
> competing implementations, checking the version does no harm and
> simplifies the configuration machinery.

So, is this a showstopper issue for the release candidate?  I believe
Neil went on vacation today.  I'd like to have a release out in 6
hours.  Should I try to get this fixed???

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



From moshez at zadka.site.co.il  Fri Apr 13 17:42:39 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Fri, 13 Apr 2001 18:42:39 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131639.LAA31088@cj20424-a.reston1.va.home.com>
References: <200104131639.LAA31088@cj20424-a.reston1.va.home.com>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de>
Message-ID: <E14o5iZ-00015o-00@darjeeling>

On Fri, 13 Apr 2001 11:39:59 -0500, Guido van Rossum <guido at digicool.com> wrote:
 
> So, is this a showstopper issue for the release candidate?  

In my opinion, yes.
Sadly, I don't have the manpower to commit and test this properly,
but it is important.

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From martin at loewis.home.cs.tu-berlin.de  Fri Apr 13 18:14:27 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 13 Apr 2001 18:14:27 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131639.LAA31088@cj20424-a.reston1.va.home.com> (message
	from Guido van Rossum on Fri, 13 Apr 2001 11:39:59 -0500)
References: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>
Message-ID: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>

> So, is this a showstopper issue for the release candidate?

It will mean that the socket module does not work out-of-the-box on
some Debian systems; that could be fixed by enabling the socket module
in Modules/Setup so that it is built without SSL support.

> I believe Neil went on vacation today.  I'd like to have a release
> out in 6 hours.  Should I try to get this fixed???

How about this patch? I've verified that it works with my OpenSSL
installation (0.9.5a), and, by source code inspection, that it should
work with versions back to 0.9.1c (ie. that OPENSSL_VERSION_NUMBER was
always available through including <openssl/crypto.h>).

The logic about RAND_status being 0 if unknown might be flawed, but
that won't hurt unless SSL support is actually used.

If this won't get into 2.1, I'll put it on SF.

Regards,
Martin

Index: socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.139
diff -u -r1.139 socketmodule.c
--- socketmodule.c	2001/03/18 17:11:56	1.139
+++ socketmodule.c	2001/04/13 15:56:04
@@ -195,6 +195,13 @@
 #include "openssl/ssl.h"
 #include "openssl/err.h"
 #include "openssl/rand.h"
+
+#if OPENSSL_VERSION_NUMBER < 0x0090510fL
+/* RAND_status was added in OpenSSL 0.9.5. If it is not available,
+   we assume that seeding the RNG is necessary every time. */
+#define RAND_status()	0
+#endif
+
 #endif /* USE_SSL */
 
 #if defined(MS_WINDOWS) || defined(__BEOS__)



From moshez at zadka.site.co.il  Fri Apr 13 18:20:42 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Fri, 13 Apr 2001 19:20:42 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>
References: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>
Message-ID: <E14o6JO-0001EI-00@darjeeling>

On Fri, 13 Apr 2001, "Martin v. Loewis" <martin at loewis.home.cs.tu-berlin.de> wrote:

> How about this patch? I've verified that it works with my OpenSSL
> installation (0.9.5a), and, by source code inspection, that it should
> work with versions back to 0.9.1c (ie. that OPENSSL_VERSION_NUMBER was
> always available through including <openssl/crypto.h>).
> 
> The logic about RAND_status being 0 if unknown might be flawed, but
> that won't hurt unless SSL support is actually used.

No, this seems like a worse cure then the cause...
Why not put the whole if (RAND_status()) thing under the ifdef?
It was only added in 2.1, so at least we would be no worse off then in 2.0
> 
> If this won't get into 2.1, I'll put it on SF.
> 
> Regards,
> Martin
> 
> Index: socketmodule.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
> retrieving revision 1.139
> diff -u -r1.139 socketmodule.c
> --- socketmodule.c	2001/03/18 17:11:56	1.139
> +++ socketmodule.c	2001/04/13 15:56:04
> @@ -195,6 +195,13 @@
>  #include "openssl/ssl.h"
>  #include "openssl/err.h"
>  #include "openssl/rand.h"
> +
> +#if OPENSSL_VERSION_NUMBER < 0x0090510fL
> +/* RAND_status was added in OpenSSL 0.9.5. If it is not available,
> +   we assume that seeding the RNG is necessary every time. */
> +#define RAND_status()	0
> +#endif
> +
>  #endif /* USE_SSL */
>  
>  #if defined(MS_WINDOWS) || defined(__BEOS__)
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> 
> 
-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From guido at digicool.com  Fri Apr 13 19:34:13 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 12:34:13 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Fri, 13 Apr 2001 18:14:27 +0200."
             <200104131614.f3DGER730511@mira.informatik.hu-berlin.de> 
References: <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>  
            <200104131614.f3DGER730511@mira.informatik.hu-berlin.de> 
Message-ID: <200104131734.MAA32326@cj20424-a.reston1.va.home.com>

> > So, is this a showstopper issue for the release candidate?
> 
> It will mean that the socket module does not work out-of-the-box on
> some Debian systems; that could be fixed by enabling the socket module
> in Modules/Setup so that it is built without SSL support.
> 
> > I believe Neil went on vacation today.  I'd like to have a release
> > out in 6 hours.  Should I try to get this fixed???
> 
> How about this patch? I've verified that it works with my OpenSSL
> installation (0.9.5a), and, by source code inspection, that it should
> work with versions back to 0.9.1c (ie. that OPENSSL_VERSION_NUMBER was
> always available through including <openssl/crypto.h>).
> 
> The logic about RAND_status being 0 if unknown might be flawed, but
> that won't hurt unless SSL support is actually used.
> 
> If this won't get into 2.1, I'll put it on SF.

Thanks, I think I'll add that.  It looks harmless.  (Famous last
words. :-)

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



From guido at digicool.com  Fri Apr 13 19:39:59 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 12:39:59 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Fri, 13 Apr 2001 19:20:42 +0300."
             <E14o6JO-0001EI-00@darjeeling> 
References: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com>  
            <E14o6JO-0001EI-00@darjeeling> 
Message-ID: <200104131739.MAA01976@cj20424-a.reston1.va.home.com>

> No, this seems like a worse cure then the cause...
> Why not put the whole if (RAND_status()) thing under the ifdef?
> It was only added in 2.1, so at least we would be no worse off then in 2.0

Moshe, please mail me a specific patch.  I don't know the code well
enough to guess what you mean!

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



From martin at loewis.home.cs.tu-berlin.de  Fri Apr 13 19:33:26 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 13 Apr 2001 19:33:26 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <E14o6JO-0001EI-00@darjeeling> (message from Moshe Zadka on Fri,
	13 Apr 2001 19:20:42 +0300)
References: <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>
Message-ID: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>

> No, this seems like a worse cure then the cause...

Can you elaborate? It cures the problem of the socket module not being
loadable...

> Why not put the whole if (RAND_status()) thing under the ifdef?  It
> was only added in 2.1, so at least we would be no worse off then in
> 2.0

AFAICT, under my patch, when using OpenSSL on a system with EGD, it
will do the right thing. On a system with /dev/random, it will produce
a runtime warning, then add insecure entropy - in addition to the
secure entropy already obtained from /dev/random.

Under what I think is your patch, it will do the right thing on a
system with /dev/random. On a system with EGD, it will fail because of
the missing entropy.

Regards,
Martin



From jeremy at digicool.com  Fri Apr 13 19:44:04 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 13 Apr 2001 13:44:04 -0400 (EDT)
Subject: [Python-Dev] compileall.py and make install
Message-ID: <15063.15076.601471.476713@slothrop.digicool.com>

There are two related problems that I'd like to fix for the release
candidate.  One is that compileall.py basically ignores compiler
errors.  It's clear that the code intends to return with a non-zero
exit status if there are compilation errors, but it doesn't do that
currently.

If I fix just this problem, make install will start to fail because
there are six files in the test directory that contain intentional
SyntaxErrors; in one case, it's necessary that the SyntaxError be
raised through import.

I'd like to fix compileall.py and add an optional argument that tells
it to skip files that match a regular expression.  Then I'll rename
all the offending files so that they are named badsyntax_XXX and fix
the Makefile so that it installs them but does not compile them.

This is going to cause two problems for developers.  First, you'll
need to manually delete the files with the old names from the install
lib directory.  (I'll rename nocaret.py to badsyntax_nocaret.py, but,
if you've already done an install, you'll also have a nocaret.py in
the lib directory.)

The compileall script also traverses into site-packages.  If you have
compilation errors in code that you've installed into site-packages,
then make install will fail. 

I'm not sure what to do about this.  During development, at least, it
is probably helpful for make install to walk into site-packages and
fail if the new version of Python breaks existing code.  On the other
hand, it could be a big pain that you can't install Python just
because you previously installed a buggy Python library.  Of course,
you could just remove the broken code.

I think it's a net gain to make these changes.  Is anyone more
concerned that me about the possible breakage?

Jeremy






From fdrake at acm.org  Fri Apr 13 20:02:55 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 13 Apr 2001 14:02:55 -0400 (EDT)
Subject: [Python-Dev] Docs are frozen.
Message-ID: <15063.16207.884585.823138@beowolf.digicool.com>

  The documentation tree is frozen for Python 2.1c1.  All further
changes should be submitted via the SourceForge patch manager until
Python 2.1 has been released.
  Thanks!


  -Fred

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




From chrishbarker at home.net  Fri Apr 13 20:20:32 2001
From: chrishbarker at home.net (Chris Barker)
Date: Fri, 13 Apr 2001 11:20:32 -0700
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
References: <20010413114324-r01010600-54b4467f@213.84.27.177> <3AD6DE54.ED351E8E@lemburg.com>
Message-ID: <3AD74370.2EF0614C@home.net>

"M.-A. Lemburg" wrote:
> Please write the results of this discussion up as a PEP. PEPs don't
> necessarily have to provide an implementation of what is covered;
> it sometimes simply suffices to start out with a summary of the
> discussions that have been going on. Then someone may pick up the
> threads from there and possibly find a solution which will then
> get implemented.

Just, I second that. I really think this is a very useful improvement to
Python, I'd I'd really like to see it happen. I am probably even more
out of my depth than you when it comes to suggesting impimentation, but
I'd be glad to help with any parts of a PEP that I can.

Guido van Rossum wrote:
> > <grin>  I'll repeat my question of yesterday: is there any reason why we
> > couldn't start with QIO?  I did some checking after I sent that out, and
> > QIO claims that it can be configured to recognize different kinds of
> > line endings.  QIO is claimed to be 2-3 times faster than Python 1.5.2;
> > don't know how that compares to 2.x.
> 
> >From a one-minute review it looks like as good a start as any!

Great! I have to say that it really seemed that someone must have
produced an open source solution to this problem somewhere, and it turns
out there is something Python related already.

-Chris


-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------



From fdrake at beowolf.digicool.com  Fri Apr 13 20:15:38 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Fri, 13 Apr 2001 14:15:38 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010413181538.7BA3F28A06@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/

Final documentation for Python 2.1c1.




From guido at digicool.com  Fri Apr 13 21:45:51 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 14:45:51 -0500
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: Your message of "Fri, 13 Apr 2001 13:44:04 -0400."
             <15063.15076.601471.476713@slothrop.digicool.com> 
References: <15063.15076.601471.476713@slothrop.digicool.com> 
Message-ID: <200104131945.OAA09964@cj20424-a.reston1.va.home.com>

> There are two related problems that I'd like to fix for the release
> candidate.  One is that compileall.py basically ignores compiler
> errors.  It's clear that the code intends to return with a non-zero
> exit status if there are compilation errors, but it doesn't do that
> currently.
> 
> If I fix just this problem, make install will start to fail because
> there are six files in the test directory that contain intentional
> SyntaxErrors; in one case, it's necessary that the SyntaxError be
> raised through import.
> 
> I'd like to fix compileall.py and add an optional argument that tells
> it to skip files that match a regular expression.  Then I'll rename
> all the offending files so that they are named badsyntax_XXX and fix
> the Makefile so that it installs them but does not compile them.
> 
> This is going to cause two problems for developers.  First, you'll
> need to manually delete the files with the old names from the install
> lib directory.  (I'll rename nocaret.py to badsyntax_nocaret.py, but,
> if you've already done an install, you'll also have a nocaret.py in
> the lib directory.)
> 
> The compileall script also traverses into site-packages.  If you have
> compilation errors in code that you've installed into site-packages,
> then make install will fail. 
> 
> I'm not sure what to do about this.  During development, at least, it
> is probably helpful for make install to walk into site-packages and
> fail if the new version of Python breaks existing code.  On the other
> hand, it could be a big pain that you can't install Python just
> because you previously installed a buggy Python library.  Of course,
> you could just remove the broken code.
> 
> I think it's a net gain to make these changes.  Is anyone more
> concerned that me about the possible breakage?

-1 for getting this in the 2.1 release.  +1 for fixing this soon
after.  I'm beginning to see the point of branching off for releases!

I'm not sure what advantage there is to compileall.py returning a
non-zero exit code, and I clearly see the risk of doing it so close to
the release.  I have about three hours to send the release candidate
out, I want to do some more testing, *and* I want to have the night
off... :-)

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



From jeremy at digicool.com  Fri Apr 13 20:48:34 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 13 Apr 2001 14:48:34 -0400 (EDT)
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: <15063.15076.601471.476713@slothrop.digicool.com>
References: <15063.15076.601471.476713@slothrop.digicool.com>
Message-ID: <15063.18946.598247.129409@slothrop.digicool.com>

A brief historical analysis of the situation

In the olden days, py_compile.py did not catch SyntaxErrors.  If
compileall.py used py_compile.py to compile a file and it failed,
it would print an error message but continue working. 

When Python 1.5.2 was released, py_compile was updated to catch the
exceptions on its own.

About six months later, well before 2.0, a change was made to
compileall to exit with non-zero status if it caught a syntax error.
This change apparently had no effect, because compileall never saw
syntax errors.

Jeremy

 




From jeremy at digicool.com  Fri Apr 13 20:52:44 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 13 Apr 2001 14:52:44 -0400 (EDT)
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: <200104131945.OAA09964@cj20424-a.reston1.va.home.com>
References: <15063.15076.601471.476713@slothrop.digicool.com>
	<200104131945.OAA09964@cj20424-a.reston1.va.home.com>
Message-ID: <15063.19196.236720.410550@slothrop.digicool.com>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

  GvR> -1 for getting this in the 2.1 release.  +1 for fixing this
  GvR> soon after.  I'm beginning to see the point of branching off
  GvR> for releases!

Okay.

Jeremy




From guido at digicool.com  Fri Apr 13 22:05:39 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 15:05:39 -0500
Subject: [Python-Dev] compileall.py and make install
In-Reply-To: Your message of "Fri, 13 Apr 2001 14:48:34 -0400."
             <15063.18946.598247.129409@slothrop.digicool.com> 
References: <15063.15076.601471.476713@slothrop.digicool.com>  
            <15063.18946.598247.129409@slothrop.digicool.com> 
Message-ID: <200104132005.PAA10142@cj20424-a.reston1.va.home.com>

> A brief historical analysis of the situation
> 
> In the olden days, py_compile.py did not catch SyntaxErrors.  If
> compileall.py used py_compile.py to compile a file and it failed,
> it would print an error message but continue working. 
> 
> When Python 1.5.2 was released, py_compile was updated to catch the
> exceptions on its own.
> 
> About six months later, well before 2.0, a change was made to
> compileall to exit with non-zero status if it caught a syntax error.
> This change apparently had no effect, because compileall never saw
> syntax errors.

Hm.  That change was never tested, apparently. :-(

This means that even if we fix py_compile.py after 2.1 is released, we
risk breaking existing usage.  Not clear whether that should matter
much though.

But definitely not a risk I want to take in 2.1.

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



From guido at python.org  Sat Apr 14 00:18:40 2001
From: guido at python.org (Guido van Rossum)
Date: Fri, 13 Apr 2001 17:18:40 -0500
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
Message-ID: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>

Python 2.1 is almost ready.  We've built a release candidate -- a
version that should become the final version, barring any last-minute
showstopper bugs (which will of course be fixed before releasing the
final version).  Thanks to all who helped!

Please download the release candidate and use it on your favorite
platform.  For more info:

    http://www.python.org/2.1/

There's not much new since 2.1b2: we mostly fixed bugs and added
documentation.  Some things that *did* change visibly:

  - Ping added an interactive help browser to pydoc. (Very cool!  Try it!)

  - Eric Raymond extended the pstats module with a simple interactive
    statistics browser, invoked when the module is run as a script.

  - An updated python-mode.el version 4.0 which integrates Ken
    Manheimer's pdbtrack.el.  This makes debugging Python code via pdb
    much nicer in XEmacs and Emacs.  When stepping through your program
    with pdb, in either the shell window or the *Python* window, the
    source file and line will be tracked by an arrow.

  - After a public outcry, assignment to __debug__ is no longer illegal;
    instead, a warning is issued.  It will become illegal in 2.2.

  - New port: SCO Unixware 7, by Billy G. Allie.

  - Updated the RISCOS port.

We expect to release the final version on Tuesday morning, April 17.

Enjoy!

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



From paul at pfdubois.com  Fri Apr 13 23:47:45 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Fri, 13 Apr 2001 14:47:45 -0700
Subject: [Python-Dev] Complex detection
Message-ID: <ADEOIFHFONCLEEPKCACCKECECIAA.paul@pfdubois.com>

My understanding is that Python can be built without complex numbers to
satisfy the needs of the Python-on-a-wristwatch crowd. Is there a run-time
way to tell? For example, using an imaginary literal causes an error? If so,
what kind?

I'm finishing the reference implementation for PEP 242 and want to allow for
this possibility.




From ping at lfw.org  Sat Apr 14 00:28:20 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Fri, 13 Apr 2001 17:28:20 -0500 (CDT)
Subject: [Python-Dev] Complex detection
In-Reply-To: <ADEOIFHFONCLEEPKCACCKECECIAA.paul@pfdubois.com>
Message-ID: <Pine.LNX.4.10.10104131727180.21723-100000@server1.lfw.org>

On Fri, 13 Apr 2001, Paul F. Dubois wrote:
> My understanding is that Python can be built without complex numbers to
> satisfy the needs of the Python-on-a-wristwatch crowd. Is there a run-time
> way to tell? For example, using an imaginary literal causes an error? If so,
> what kind?

This is just a guess, but check hasattr(__builtins__, 'complex') perhaps?
That's what i would do.


-- ?!ng




From tim.one at home.com  Sat Apr 14 00:39:46 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 13 Apr 2001 18:39:46 -0400
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  conversion?
In-Reply-To: <20010413134326-r01010600-bafaee65@213.84.27.177>
Message-ID: <LNBBLJKPBEHFEDALKOLCIECBJMAA.tim.one@home.com>

[MAL]
> I don't know why this thread lead to tweaking stdio -- after all
> we only need a solution for the Python tokenizer ...

[Just]
> Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is
> great and all,> but then what about all tools that read source
> files line by line? ...

Note that this is why the topic needs a PEP:  nothing here is new; the same
debates reoccur every time it comes up.

[Aahz]
> ...
> QIO claims that it can be configured to recognize different
> kinds of line endings.

It can be, yes, but in the same sense as Awk/Perl paragraph mode:  you can
tell it to consider any string (not just single character) as meaning "end of
the line", but it's a *fixed* string per invocation.  What people want *here*
is more the ability to recognize the regular expression

    \r\n?|\n

as ending a line, and QIO can't do that directly (as currently written).  And
MAL probably wants Unicode line-end detection:

    http://www.unicode.org/unicode/reports/tr13/

> QIO is claimed to be 2-3 times faster than Python 1.5.2; don't
> know how that compares to 2.x.

The bulk of that was due to QIO avoiding per-character thread locks.  2.1
avoids them too, so most of QIO's speed advantage should be gone now.  But
QIO's internals could certainly be faster than they are (this is obscure
because QIO.readline() has so many optional behaviors that the maze of
if-tests makes it hard to see the speed-crucial bits; studying Perl's
line-reading code is a better model, because Perl's speed-crucial inner loop
has no non-essential operations -- Perl makes the *surrounding* code sort out
the optional bits, instead of bogging down the loop with them).




From tim.one at home.com  Sat Apr 14 00:48:22 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 13 Apr 2001 18:48:22 -0400
Subject: [Python-Dev] Complex detection
In-Reply-To: <ADEOIFHFONCLEEPKCACCKECECIAA.paul@pfdubois.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKECEJMAA.tim.one@home.com>

[Paul F. Dubois]
> My understanding is that Python can be built without complex numbers
> to satisfy the needs of the Python-on-a-wristwatch crowd. Is there a
> run-time way to tell? For example, using an imaginary literal causes
> an error? If so, what kind?

You can find out by compiling with WITHOUT_COMPLEX #define'd.  PythonLabs
never does this, so no guarantee it even works.  I'm not going to bother
starting now, either <wink>.  Based on skimming the code, I expect

try:
    eval("1j")
    with_complex = 1
except SyntaxError:
    with_complex = 0

would do the trick, but no guarantee.




From m.favas at per.dem.csiro.au  Sat Apr 14 02:59:34 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 08:59:34 +0800
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
Message-ID: <3AD7A0F6.7673FDD3@per.dem.csiro.au>

FreeBSD 4.2-20010225-STABLE, gcc 2.95.2

./python Lib/test/test_zipfile.py
Traceback (most recent call last):
  File "Lib/test/test_zipfile.py", line 35, in ?
    zipTest(file, zipfile.ZIP_STORED, writtenData)
  File "Lib/test/test_zipfile.py", line 18, in zipTest
    zip.close()
  File "/home/mark/src/python/CVS/python/dist/src/Lib/zipfile.py", line
471, in close
    self.fp.flush()
IOError: [Errno 9] Bad file descriptor

Looks like FreeBSD objects to doing a flush() on a file opened for
reading. The self.fp.flush() call should probably be part of the
preceding if-block relating to files opened in "a" or "w' mode.
-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From moshez at zadka.site.co.il  Sat Apr 14 02:58:38 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Sat, 14 Apr 2001 03:58:38 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>
Message-ID: <E14oEOc-0001si-00@darjeeling>

"competing patch" attached at end.

On Fri, 13 Apr 2001, "Martin v. Loewis" <martin at loewis.home.cs.tu-berlin.de> wrote:
> > No, this seems like a worse cure then the cause...
> 
> Can you elaborate? It cures the problem of the socket module not being
> loadable...

You're right, it was a bad choice of words.
 
> AFAICT, under my patch, when using OpenSSL on a system with EGD, it
> will do the right thing. On a system with /dev/random, it will produce
> a runtime warning, then add insecure entropy - in addition to the
> secure entropy already obtained from /dev/random.
> 
> Under what I think is your patch, it will do the right thing on a
> system with /dev/random. On a system with EGD, it will fail because of
> the missing entropy.

Correct on both. My "worse" is: it would print a warning about using
an insecure method on systems with /dev/random but without an EGD,
even though it is secure. Note that the EGD stuff is new with 2.1,
so losing that is not a step backwards from 2.0. Printing a wrong warning
is a step backwards, so in that sense my patch is more conservative.
 
After further contemplation, none of these is a pure win.
It's up to Guido if he wants to use my patch instead of Martin's
for 2.1final
-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org


*** Modules/socketmodule.c	Sun Mar 18 18:38:50 2001
--- new	Sat Apr 14 03:53:20 2001
***************
*** 2545,2550 ****
--- 2545,2551 ----
  	if (PyDict_SetItemString(d, "SSLType",
  				 (PyObject *)&SSL_Type) != 0)
  		return;
+ #if OPENSSL_VERSION_NUMBER < 0x0090510fL
  	if (RAND_status() == 0) {
  #ifdef USE_EGD
  		char random_device[MAXPATHLEN+1];
***************
*** 2571,2576 ****
--- 2572,2578 ----
  		RAND_seed(random_string, sizeof(random_string));
  #endif /* USE_EGD */
  	}
+ #endif /* OPENSSL_VERSION_NUMBER < 0x0090510fL */
  #endif /* USE_SSL */
  	PyDict_SetItemString(d, "error", PySocket_Error);
  	PySocketSock_Type.ob_type = &PyType_Type;



From m.favas at per.dem.csiro.au  Sat Apr 14 03:07:29 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 09:07:29 +0800
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
Message-ID: <3AD7A2D1.B04928AE@per.dem.csiro.au>

SunOS asafoetida 5.8, gcc 2.95.2

"make test" fails on running test_asynchat.py for the second time. The
traceback is:

Exception in thread Thread-1:
Traceback (most recent call last):
  File
"/export/home/mark/src/python/CVS/python/dist/src/Lib/threading.py",
line 378, in __bootstrap
    self.run()
  File "Lib/test/test_asynchat.py", line 12, in run
    sock.bind((HOST, PORT))
error: (125, 'Address already in use')

Traceback (most recent call last):
  File "Lib/test/test_asynchat.py", line 56, in ?
    main()
  File "Lib/test/test_asynchat.py", line 51, in main
    c = echo_client()
  File "Lib/test/test_asynchat.py", line 32, in __init__
    self.connect((HOST, PORT))
  File
"/export/home/mark/src/python/CVS/python/dist/src/Lib/asyncore.py", line
308, in connect
    raise socket.error, why
socket.error: (146, 'Connection refused')

Looks like Solaris takes a while to shut sockets down? (This is not a
slow box, btw.) Or is there an option to not have the socket linger?

Also, test_sunaudiodev fails, since setup.py tests only whether the
platform is a Sun, not whether there is a /dev/audio as well. Servers
don't have a /dev/audio. This is clearly a minor nit - I did log a bug
against this some time ago.

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From m.favas at per.dem.csiro.au  Sat Apr 14 03:12:29 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 09:12:29 +0800
Subject: [Python-Dev] 2.1c1: "make test" core dumps on SGI Irix
Message-ID: <3AD7A3FD.CBEB9510@per.dem.csiro.au>

IRIX64 dodo 6.5 07201607 IP35, MIPSpro Compilers: Version 7.30

"make test" core dumps with no output from any test completed. Running
them one-by-one reveals that the (first?) core dump is in
test___all__.py.
python Lib/test/test___all__.py
Bus error (core dumped)

dbx where gives: (chopped)
>  0 float_mul(0x100ce7dc, 0x103523d8, 0x8, 0x100b5d70, 0x10050000, 0x103523d8, 0x100b5d70, 0x100b5ce8) ["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/floatobject.c":382, 0x1004f098]
   1 binary_op1(0x100ce7dc, 0x103523d8, 0x0, 0x100b5d70, 0x10050000,
0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/abstract.c":337,
0x1003bfec]
   2 binary_op(0x100ce7dc, 0x103523d8, 0x8, 0x0, 0x10050000, 0x103523d8,
0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/abstract.c":373,
0x1003c200]
   3 PyNumber_Multiply(0x100ce7dc, 0x103523d8, 0x8, 0x100b5d70,
0x10050000, 0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Objects/abstract.c":544,
0x1003c934]
   4 eval_code2(0x101bea78, 0x0, 0x0, 0x0, 0x103ffad7, 0x0, 0x0, 0x0)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/ceval.c":945,
0x10035cb4]
   5 PyEval_EvalCode(0x100ce7dc, 0x103523d8, 0x8, 0x100b5d70,
0x10050000, 0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/ceval.c":341,
0x10032818]
   6 PyImport_ExecCodeModuleEx(0x7fff1168, 0x0, 0x0, 0x100b5d70,
0x10050000, 0x103523d8, 0x0, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/import.c":490,
0x1000d904]
   7 load_source_module(0x0, 0x7fff0840, 0x0, 0x100b5d70, 0x10050000,
0x103523d8, 0x100b5d70, 0x100b5ce8)
["/tmp_mnt/home/solo/mark/python/Python-2.1c1/Python/import.c":754,
0x1000e0f0]
More (n if no)?

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From esr at thyrsus.com  Sat Apr 14 03:41:39 2001
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 13 Apr 2001 21:41:39 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Apr 13, 2001 at 05:18:40PM -0500
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>
Message-ID: <20010413214139.A3800@thyrsus.com>

Guido van Rossum <guido at python.org>:
>   - Eric Raymond extended the pstats module with a simple interactive
>     statistics browser, invoked when the module is run as a script.

...which I tested by using it to speed-tune the crap out of CML2, dropping the
configurator's startup time from over 15 seconds to about 2 :-).

CML2 has been officially accepted for inclusion in the Linux kernel, BTW.
Linus himself quashed the anti-Python grumbling from some of the more
conservative types on lkml by uttering the ukase "Python is not an issue."
It's scheduled to go in sometime in the 2.5.1 to 2.5.2 series.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
        -- G. Kleck, "Policy Lessons from Recent Gun Control Research,"



From guido at digicool.com  Sat Apr 14 04:42:28 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 21:42:28 -0500
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:07:29 +0800."
             <3AD7A2D1.B04928AE@per.dem.csiro.au> 
References: <3AD7A2D1.B04928AE@per.dem.csiro.au> 
Message-ID: <200104140242.VAA11020@cj20424-a.reston1.va.home.com>

> SunOS asafoetida 5.8, gcc 2.95.2
> 
> "make test" fails on running test_asynchat.py for the second time. The
> traceback is:
> 
> Exception in thread Thread-1:
> Traceback (most recent call last):
>   File
> "/export/home/mark/src/python/CVS/python/dist/src/Lib/threading.py",
> line 378, in __bootstrap
>     self.run()
>   File "Lib/test/test_asynchat.py", line 12, in run
>     sock.bind((HOST, PORT))
> error: (125, 'Address already in use')
> 
> Traceback (most recent call last):
>   File "Lib/test/test_asynchat.py", line 56, in ?
>     main()
>   File "Lib/test/test_asynchat.py", line 51, in main
>     c = echo_client()
>   File "Lib/test/test_asynchat.py", line 32, in __init__
>     self.connect((HOST, PORT))
>   File
> "/export/home/mark/src/python/CVS/python/dist/src/Lib/asyncore.py", line
> 308, in connect
>     raise socket.error, why
> socket.error: (146, 'Connection refused')
> 
> Looks like Solaris takes a while to shut sockets down? (This is not a
> slow box, btw.) Or is there an option to not have the socket linger?

Dunno, but there *is* an option to allow reusing a socket.

> Also, test_sunaudiodev fails, since setup.py tests only whether the
> platform is a Sun, not whether there is a /dev/audio as well. Servers
> don't have a /dev/audio. This is clearly a minor nit - I did log a bug
> against this some time ago.

Compiling on a server doesn't mean you'll run on a server only.  But
the test should mark itself as "skipped" when /dev/audio doesn't
exist.  I don't know how easy that is.

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



From guido at digicool.com  Sat Apr 14 04:43:07 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 13 Apr 2001 21:43:07 -0500
Subject: [Python-Dev] 2.1c1: "make test" core dumps on SGI Irix
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:12:29 +0800."
             <3AD7A3FD.CBEB9510@per.dem.csiro.au> 
References: <3AD7A3FD.CBEB9510@per.dem.csiro.au> 
Message-ID: <200104140243.VAA11034@cj20424-a.reston1.va.home.com>

> IRIX64 dodo 6.5 07201607 IP35, MIPSpro Compilers: Version 7.30
> 
> "make test" core dumps with no output from any test completed. Running
> them one-by-one reveals that the (first?) core dump is in
> test___all__.py.
> python Lib/test/test___all__.py
> Bus error (core dumped)

Try compiling without -O?

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



From fdrake at acm.org  Sat Apr 14 03:49:51 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 13 Apr 2001 21:49:51 -0400 (EDT)
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
In-Reply-To: <200104140242.VAA11020@cj20424-a.reston1.va.home.com>
References: <3AD7A2D1.B04928AE@per.dem.csiro.au>
	<200104140242.VAA11020@cj20424-a.reston1.va.home.com>
Message-ID: <15063.44223.710582.338422@cj42289-a.reston1.va.home.com>


Guido van Rossum writes:
 > Compiling on a server doesn't mean you'll run on a server only.  But
 > the test should mark itself as "skipped" when /dev/audio doesn't
 > exist.  I don't know how easy that is.

Mark,
  Please try the following patch to Lib/test/test_sunaudiodev.py and
let us know how that works for you.


  -Fred

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
URL: <http://mail.python.org/pipermail/python-dev/attachments/20010413/04f04cfa/attachment-0001.txt>

From m.favas at per.dem.csiro.au  Sat Apr 14 04:13:44 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 10:13:44 +0800
Subject: [Python-Dev] 2.1c1: test_sunaudiodev fails on Sun servers 
References: <3AD7A2D1.B04928AE@per.dem.csiro.au>
		<200104140242.VAA11020@cj20424-a.reston1.va.home.com> <15063.44223.710582.338422@cj42289-a.reston1.va.home.com>
Message-ID: <3AD7B258.7ED22029@per.dem.csiro.au>

Fred,

Yes, that works for me (perhaps we could change "dound" to "found"
though <wink>).

M

"Fred L. Drake, Jr." wrote:
> 
> Guido van Rossum writes:
>  > Compiling on a server doesn't mean you'll run on a server only.  But
>  > the test should mark itself as "skipped" when /dev/audio doesn't
>  > exist.  I don't know how easy that is.
> 
> Mark,
>   Please try the following patch to Lib/test/test_sunaudiodev.py and
> let us know how that works for you.
> 
>   -Fred
> 
> --
> Fred L. Drake, Jr.  <fdrake at acm.org>
> PythonLabs at Digital Creations
> 
>   ------------------------------------------------------------------------
> Index: test_sunaudiodev.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/test/test_sunaudiodev.py,v
> retrieving revision 1.9
> diff -c -r1.9 test_sunaudiodev.py
> *** test_sunaudiodev.py 2001/01/17 21:51:36     1.9
> --- test_sunaudiodev.py 2001/04/14 01:47:49
> ***************
> *** 1,6 ****
> ! from test_support import verbose, findfile, TestFailed
>   import sunaudiodev
>   import os
> 
>   def play_sound_file(path):
>       fp = open(path, 'r')
> --- 1,14 ----
> ! from test_support import verbose, findfile, TestFailed, TestSkipped
>   import sunaudiodev
>   import os
> +
> + try:
> +     audiodev = os.environ["AUDIODEV"]
> + except KeyError:
> +     audiodev = "/dev/audio"
> +
> + if not os.path.exists(audiodev):
> +     raise TestSkipped("no audio device dound!")
> 
>   def play_sound_file(path):
>       fp = open(path, 'r')

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From Jason.Tishler at dothill.com  Sat Apr 14 04:25:01 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Fri, 13 Apr 2001 22:25:01 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
Message-ID: <20010413222501.D5606@dothill.com>

I configured as follows:

    configure --with-threads=no

When I run the regression tests I get the following:

    test test_threadedtempfile crashed -- exceptions.AttributeError: 'threading' module has no attribute 'Event'

Should this test only be run if Python is built with thread support?

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From m.favas at per.dem.csiro.au  Sat Apr 14 04:45:41 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Apr 2001 10:45:41 +0800
Subject: [Python-Dev] 2.1c1: "make test" core dumps on SGI Irix
References: <3AD7A3FD.CBEB9510@per.dem.csiro.au> <200104140243.VAA11034@cj20424-a.reston1.va.home.com>
Message-ID: <3AD7B9D5.CCE64D03@per.dem.csiro.au>

Recompiling floatobject.c without optimization makes the bus error
during "make test" go away. Perhaps the SGI section in the README could
be updated here - it only mentions a possible problem with
complexobject.c and Numeric.

"make test" now fails on:

test_largefile
test test_largefile crashed -- exceptions.IOError: [Errno 22] Invalid
argument

and

test_locale
test test_locale crashed -- exceptions.ValueError: unpack sequence of
wrong size

and

test_zlib
*** Termination code 9 (bu21)

More details:

python Lib/test/test_largefile.py
create large file via seek (may be sparse file) ...
Traceback (most recent call last):
  File "Lib/test/test_largefile.py", line 63, in ?
    f.flush()
IOError: [Errno 22] Invalid argument


python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ...
Traceback (most recent call last):
  File "Lib/test/test_locale.py", line 29, in ?
    testformat("%f", 1024, grouping=1, output='1,024.000000')
  File "Lib/test/test_locale.py", line 18, in testformat
    result = locale.format(formatstr, value, grouping = grouping)
  File "/tmp_mnt/home/solo/mark/python/Python-2.1c1/Lib/locale.py", line
137, in format
    fields[0],seps=_group(fields[0])
ValueError: unpack sequence of wrong size


python Lib/test/test_zlib.py
0xe5c1a120 0x43b6aa94
0xbd602f7 0xbd602f7
expecting Bad compression level
expecting Invalid initialization option
expecting Invalid initialization option
normal compression/decompression succeeded
compress/decompression obj succeeded
decompress with init options succeeded
decompressobj with init options succeeded
Killed

Recompiling _everything_ without optimization produces no change. I have
no time to poke around further at the moment - later this afternoon...

M

Guido van Rossum wrote:
> 
> > IRIX64 dodo 6.5 07201607 IP35, MIPSpro Compilers: Version 7.30
> >
> > "make test" core dumps with no output from any test completed. Running
> > them one-by-one reveals that the (first?) core dump is in
> > test___all__.py.
> > python Lib/test/test___all__.py
> > Bus error (core dumped)
> 
> Try compiling without -O?
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From fdrake at acm.org  Sat Apr 14 05:11:54 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 13 Apr 2001 23:11:54 -0400 (EDT)
Subject: [Python-Dev] 2.1c1: test_sunaudiodev fails on Sun servers 
In-Reply-To: <3AD7B258.7ED22029@per.dem.csiro.au>
References: <3AD7A2D1.B04928AE@per.dem.csiro.au>
	<200104140242.VAA11020@cj20424-a.reston1.va.home.com>
	<15063.44223.710582.338422@cj42289-a.reston1.va.home.com>
	<3AD7B258.7ED22029@per.dem.csiro.au>
Message-ID: <15063.49146.634503.336638@cj42289-a.reston1.va.home.com>

Mark Favas writes:
 > Yes, that works for me (perhaps we could change "dound" to "found"
 > though <wink>).

  Hey, you'll have to file a formal bug report on SF for that!  ;-)
Ok, this is checked in.  If everyone who can build with the
sunaudiodev module would test this, I'd really appreciate any feedback
on this!


  -Fred

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




From gherman at darwin.in-berlin.de  Sat Apr 14 08:25:17 2001
From: gherman at darwin.in-berlin.de (Dinu Gherman)
Date: Sat, 14 Apr 2001 08:25:17 +0200
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
Message-ID: <3AD7ED4D.58597DFD@darwin.in-berlin.de>

> Examples
> 
>     Here is an example of an interactive session exhibiting the
>     expected behaviour of this feature.
> 
>         >>> "12345 John Doe" / "%5d %8s"
>         (12345, 'John Doe')
>         >>> "12 34 56 7.890" / "%d %d %d %f"
>         (12, 34, 56, 7.8899999999999997)
>         >>> "12345 John Doe, Foo Bar" / "%(num)d %(n)s, %(f)s %(b)s"
>         {'n': 'John Doe', 'f': 'Foo', 'b': 'Bar', 'num': 12345}
>         >>> "1 2" / "%d %d %d"
>         Traceback (innermost last):
>           File "<stdin>", line 1, in ?
>         TypeError: not all arguments filled
 

Kind of late to jump in, but this is the nature of this list.

I'd like to support Peter's proposal for having *some* kind 
of inverse mechanism to string formatting using '%'. Now, that
doesn't mean anything, of course, but no matter what the syn-
tax would look like: I'd prefer having that feature over not
having it and I'll give an example below.

Reminding you of a thread I triggered a while ago (that went 
slightly astray) which was, kind of, received with suspicion,
I notice that it matches quite nicely with Peter's (more ge-
neral) idea. Here's the thread's summary:

  Grouping function for string module?          
http://mail.python.org/pipermail/python-list/1999-September/011875.html

Combining this I'd like to see something like the following 
(again, maybe with a different syntax):

    >>> "1010000011110101" / "%4s%4s%4s%4s"
    ('1010', '0000', '1111', '0101')
    >>> "10100000111101" / "%4s%4s%4s%4s"
    ('1010', '0000', '1111', '01')

or even:

    >>> "1010000011110101" / ("%4s" * 4)
    ('1010', '0000', '1111', '0101')

;-)

Regards and Happy Easter (will be away for a week)!

Dinu

-- 
Dinu C. Gherman
ReportLab Consultant - http://www.reportlab.com
................................................................
"The only possible values [for quality] are 'excellent' and 'in-
sanely excellent', depending on whether lives are at stake or 
not. Otherwise you don't enjoy your work, you don't work well, 
and the project goes down the drain." 
                    (Kent Beck, "Extreme Programming Explained")



From tim.one at home.com  Sat Apr 14 09:50:32 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 14 Apr 2001 03:50:32 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <20010413222501.D5606@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEDDJMAA.tim.one@home.com>

[Jason Tishler]
> I configured as follows:
>
>     configure --with-threads=no
>
> When I run the regression tests I get the following:
>
>     test test_threadedtempfile crashed --
> exceptions.AttributeError: 'threading' module has no attribute 'Event'
>
> Should this test only be run if Python is built with thread support?

Yes, it should be run only when there's thread support (well, actually,
regrtest.py will *try* it regardless, but ... see what follows).

The first thing test_threadedtempfile does is

    import threading

and I *expect* that to die with an ImportError when there's no thread
suppport, due to threading.py trying to do

    import thread

early on.  regrtest.py looks out for ImportErrors, and I expect it to say

    test test_threadedtempfile skipped --  No module named thread

in your situation.

So the question is why you're not getting an ImportError on "import thread"
(try it an interactive Python to make sure that's the cause).  Why you're not
getting an ImportError I'll have to leave to someone who understands the Unix
config process.

OTOH, the threading module you are importing is damaged, else threading.Event
would have existed.  So perhaps there's a deeper problem here than just a
config thing.  First let us know what happens when you try "import thread" on
its own.




From mwh21 at cam.ac.uk  Sat Apr 14 12:05:07 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: Sat, 14 Apr 2001 11:05:07 +0100 (BST)
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEDDJMAA.tim.one@home.com>
Message-ID: <Pine.LNX.4.10.10104141059210.19675-100000@localhost.localdomain>

On Sat, 14 Apr 2001, Tim Peters wrote:

> So the question is why you're not getting an ImportError on "import
> thread" (try it an interactive Python to make sure that's the cause).  
> Why you're not getting an ImportError I'll have to leave to someone
> who understands the Unix config process.

That one's easy: a testcase earlier has tried to "import threading";
*that* import died with an ImportError when threading tried to import
"thread", and then the "import threading" in
test_threadtempfileorwhatever.py gets the half finished module object that
had been constructed when "import thread" blew up for the first time.

Maybe modules should be removed from sys.modules when they fail to be
imported due to an exception?

Cheers,
M.





From tim.one at home.com  Sat Apr 14 12:16:50 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 14 Apr 2001 06:16:50 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <Pine.LNX.4.10.10104141059210.19675-100000@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEDKJMAA.tim.one@home.com>

I'm sure Michael is right; tried to send email about that before, but never
saw it come across; the same problem was reported recently by someone else on
SF:

http://sourceforge.net/tracker/?func=detail&atid=105470&
    aid=416089&group_id=5470

(although SF appears dead now too!).

[Michael Hudson]
> ...
> Maybe modules should be removed from sys.modules when they fail to be
> imported due to an exception?

As I said in the phantom email nobody saw <wink>, this isn't the first time
we've been screwed by this in the test suite (e.g., look near the top of
test___all__.py for evidence of the last time I wrestled with this).  But I'm
pretty sure Guido explicitly declined to do what you suggest, although I
can't recall why now.

sleep-now-argue-tomorrow-ly y'rs  - tim




From guido at digicool.com  Sat Apr 14 16:05:29 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 09:05:29 -0500
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: Your message of "Fri, 13 Apr 2001 21:41:39 -0400."
             <20010413214139.A3800@thyrsus.com> 
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>  
            <20010413214139.A3800@thyrsus.com> 
Message-ID: <200104141405.JAA12126@cj20424-a.reston1.va.home.com>

> >   - Eric Raymond extended the pstats module with a simple interactive
> >     statistics browser, invoked when the module is run as a script.
> 
> ...which I tested by using it to speed-tune the crap out of CML2, dropping the
> configurator's startup time from over 15 seconds to about 2 :-).
> 
> CML2 has been officially accepted for inclusion in the Linux kernel, BTW.
> Linus himself quashed the anti-Python grumbling from some of the more
> conservative types on lkml by uttering the ukase "Python is not an issue."
> It's scheduled to go in sometime in the 2.5.1 to 2.5.2 series.

Congratulations are in order, Eric!

I guess a more positive endorsement of Python from Linus will be out
of the question for now... :-)

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




From Jason.Tishler at dothill.com  Sat Apr 14 15:59:28 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Sat, 14 Apr 2001 09:59:28 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEDJJMAA.tim.one@home.com>; from tim.one@home.com on Sat, Apr 14, 2001 at 06:01:07AM -0400
References: <20010413222501.D5606@dothill.com> <LNBBLJKPBEHFEDALKOLCKEDJJMAA.tim.one@home.com>
Message-ID: <20010414095928.A5743@dothill.com>

Tim,

On Sat, Apr 14, 2001 at 06:01:07AM -0400, Tim Peters wrote:
> I bet this fresh SF bug report explains it:
> 
> http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416089&group_id=5470

Bingo!  See the following:

    $ ./python
    Python 2.1c1 (#1, Apr 13 2001, 21:47:33) 
    [GCC 2.95.3-2 (cygwin special)] on cygwin_nt-4.01
    Type "copyright", "credits" or "license" for more information.
    >>> import threading
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
      File "/home/jt/src/Python-2.1c1/Lib/threading.py", line 5, in ?
        import thread
    ImportError: No module named thread
    >>> import threading
    >>>

> Instead they deliver a, umm, bogus module object <wink>.  I've
> never liked this behavior -- but probably can't change it for 2.1 final.  It
> won't be the first time we've needed to worm around it in the test suite
> either ...

Oh well, there is always 2.2...

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From esr at thyrsus.com  Sat Apr 14 16:10:55 2001
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 10:10:55 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <200104141405.JAA12126@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 09:05:29AM -0500
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com> <20010413214139.A3800@thyrsus.com> <200104141405.JAA12126@cj20424-a.reston1.va.home.com>
Message-ID: <20010414101055.A8625@thyrsus.com>

Guido van Rossum <guido at digicool.com>:
> > CML2 has been officially accepted for inclusion in the Linux kernel, BTW.
> 
> Congratulations are in order, Eric!

It wouldn't have happened without your signoff on including the curses
module and friends in the 2.0 standard libraries.

Eric's clever plan, if you haven't guessed already, was to use Python
and the Linux kernel tree to goose the evolution of both projects,
using the requirements from each one to overcome the resistance
of the more conservative people in the other camp.  

And, while the major reason I made Python 2.x a prerequisite for CML2
was to shrink its footprint in the kernel tree, it was not absent from
my mind that doing so would put salutary pressure on the Linux distros
to upgrade to 2.x sooner than they might have otherwise.

> I guess a more positive endorsement of Python from Linus will be out
> of the question for now... :-)

For now.  But...the *next* step in the sinister master plan, after
CML2 is in, involves replacing all the Perl and awk and Tcl in the
kernel tree with Python.  The conservatives on lkml who objected to
adding Python to the build-prerequisites list are going to find that
their own arguments for mimimal external dependencies actually support
this move.

OK, so I'm going to rewrite all the (non-bash) kernel support scripts.
In the process, I'm going to make that codebase cleaner, smaller,
better documented, and more featureful.  Give me six months after CML2
goes in and I *will* have Linus and the lkml crowd making approving
noises about Python.  Count on it.

At that point, we'll have seized a major piece of the high ground, with
knock-on effects on Python's acceptance level everywhere.  Which was
*also* part of the plan, exactly dual to the effect on Linux of making 
kernel configuration so easy your Aunt Tillie could do it.

There is one implication of this scenario for Python development
itself -- that it's time to take a serious swing at eliminating our
dependency on Tcl for GUIs.  Whether we do this by adding wxPython to
the core or in some other way I don't care, but it would strengthen my
hand with the lkml crowd considerably if Python no longer had that
dependency.

Sometime in there, you and I gotta find time to PEP the Python library reorg,
too...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The danger (where there is any) from armed citizens, is only to the
*government*, not to *society*; and as long as they have nothing to
revenge in the government (which they cannot have while it is in their
own hands) there are many advantages in their being accustomed to the 
use of arms, and no possible disadvantage.
        -- Joel Barlow, "Advice to the Privileged Orders", 1792-93



From jeremy at digicool.com  Sat Apr 14 16:32:28 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Sat, 14 Apr 2001 10:32:28 -0400 (EDT)
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <20010413214139.A3800@thyrsus.com>
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>
	<20010413214139.A3800@thyrsus.com>
Message-ID: <15064.24444.322307.549038@slothrop.digicool.com>

>>>>> "ESR" == Eric S Raymond <esr at thyrsus.com> writes:

  ESR> Guido van Rossum <guido at python.org>:
  >> - Eric Raymond extended the pstats module with a simple
  >>   interactive
  >> statistics browser, invoked when the module is run as a script.

  ESR> ...which I tested by using it to speed-tune the crap out of
  ESR> CML2, dropping the configurator's startup time from over 15
  ESR> seconds to about 2 :-).

Please take a look at the bug report I filed on SF.  The
ProfileBrowser seems to have a lot of bugs.  The first several times I
tried it, it crashed with uncaught exceptions.  As an example, the
strip command tries to call a strip_order() method, which isn't
defined anywhere in the module.

Perhaps there should be a test suite for the code.  Otherwise, it's
hard to tell if it works, since it was checked in the day of the
release candidate.

Jeremy




From aahz at rahul.net  Sat Apr 14 16:39:48 2001
From: aahz at rahul.net (Aahz Maruch)
Date: Sat, 14 Apr 2001 07:39:48 -0700 (PDT)
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <20010414101055.A8625@thyrsus.com> from "Eric S. Raymond" at Apr 14, 2001 10:10:55 AM
Message-ID: <20010414143948.2018F99C85@waltz.rahul.net>

Eric S. Raymond wrote:
> 
> And, while the major reason I made Python 2.x a prerequisite for CML2
> was to shrink its footprint in the kernel tree, it was not absent from
> my mind that doing so would put salutary pressure on the Linux distros
> to upgrade to 2.x sooner than they might have otherwise.

Sounds good.  OTOH, due to the GPL issue with 2.0 itself, this will
likely require either 2.0.1 or 2.1; I'll have a small preference for
2.0.1 myself.  I've been holding off on the next round of PEP6 (bugfix
release process) until after the 2.1 release.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6             http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.



From esr at thyrsus.com  Sat Apr 14 16:53:15 2001
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 10:53:15 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <15064.24444.322307.549038@slothrop.digicool.com>; from jeremy@digicool.com on Sat, Apr 14, 2001 at 10:32:28AM -0400
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com> <20010413214139.A3800@thyrsus.com> <15064.24444.322307.549038@slothrop.digicool.com>
Message-ID: <20010414105315.A9299@thyrsus.com>

Jeremy Hylton <jeremy at digicool.com>:
> Please take a look at the bug report I filed on SF. 

I'll do so.

> Perhaps there should be a test suite for the code.  Otherwise, it's
> hard to tell if it works, since it was checked in the day of the
> release candidate.

It was working enough for me to get practical use out of it, anway.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No one is bound to obey an unconstitutional law and no courts are bound
to enforce it.  
	-- 16 Am. Jur. Sec. 177 late 2d, Sec 256



From esr at thyrsus.com  Sat Apr 14 17:21:33 2001
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 11:21:33 -0400
Subject: [Python-Dev] ANNOUNCE: A Python 2.1 release candidate!
In-Reply-To: <20010414105315.A9299@thyrsus.com>; from esr@thyrsus.com on Sat, Apr 14, 2001 at 10:53:15AM -0400
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com> <20010413214139.A3800@thyrsus.com> <15064.24444.322307.549038@slothrop.digicool.com> <20010414105315.A9299@thyrsus.com>
Message-ID: <20010414112133.A9594@thyrsus.com>

Eric S. Raymond <esr at thyrsus.com>:
> Jeremy Hylton <jeremy at digicool.com>:
> > Please take a look at the bug report I filed on SF. 
> 
> I'll do so.
> 
> > Perhaps there should be a test suite for the code.  Otherwise, it's
> > hard to tell if it works, since it was checked in the day of the
> > release candidate.
> 
> It was working enough for me to get practical use out of it, anway.

Trust Jeremy to find one of the only two methods I forgot to test after
refactoring the browser to use the self.generic method.  Should now be
fixed in CVS; I have to go fight a different fire now, but I'll 
double-check all the methods this afternoon.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Among the many misdeeds of British rule in India, history will look
upon the Act depriving a whole nation of arms as the blackest."
        -- Mohandas Ghandhi, An Autobiography, pg 446



From guido at digicool.com  Sat Apr 14 19:27:09 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 12:27:09 -0500
Subject: [Python-Dev] make clean and make clobber semantics
Message-ID: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>

I just noticed for the first time that the semantics of "make clean"
and "make clobber" have changed.  "make clean" used to remove the .so
files too, AFAIK, but no longer does so.  "make clean" used to leave
the configuration files lying around, but now seems to remove at least
some of them.

One of the consequences of all this is that, after "make clean",
another "make" doesn't rebuild the extensions, because setup.py finds
that the .so files are still there and decides not to rebuild the
missing .o's.

Another consequence is that after "make clobber" you have to rerun the
configure script (or say "make recheck").  This takes almost as long
as the rest of the build...

In other words, "make clean" doesn't go far enough, and "make clobber"
goes too far, for what I seem to want most often (recompile every C
source file).

Can someone suggest a fix?

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



From mal at lemburg.com  Sat Apr 14 18:43:20 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 14 Apr 2001 18:43:20 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  
 conversion?
References: <20010413134326-r01010600-bafaee65@213.84.27.177>
Message-ID: <3AD87E28.CCC894AC@lemburg.com>

Just van Rossum wrote:
> 
> M.-A. Lemburg wrote:
> 
> > I don't know why this thread lead to tweaking stdio -- after all
> > we only need a solution for the Python tokenizer and not a general
> > purpose stdio abstraction of text files unless I'm missing something
> > here...
> 
> Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all,
> but then what about all tools that read source files line by line? Eg.
> linecache.py, all IDE's, etc. etc. As Tim wrote a while back:
> 
>   importing-is-only-the-start-of-the-battle
> 
> So no, we don't "only need a solution for the Python tokenizer"...

See... that's why we need a PEP on these things ;-)

Seriously, I thought that you were only talking about being
able to work on Python code from different platforms in a network
(e.g. code is shared by a Windows box and development takes place
on a Mac).

Now it seems that you want to go for the full Monty :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at digicool.com  Sat Apr 14 19:47:51 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 12:47:51 -0500
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
In-Reply-To: Your message of "Sat, 14 Apr 2001 08:59:34 +0800."
             <3AD7A0F6.7673FDD3@per.dem.csiro.au> 
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au> 
Message-ID: <200104141747.MAA21913@cj20424-a.reston1.va.home.com>

> FreeBSD 4.2-20010225-STABLE, gcc 2.95.2
> 
> ./python Lib/test/test_zipfile.py
> Traceback (most recent call last):
>   File "Lib/test/test_zipfile.py", line 35, in ?
>     zipTest(file, zipfile.ZIP_STORED, writtenData)
>   File "Lib/test/test_zipfile.py", line 18, in zipTest
>     zip.close()
>   File "/home/mark/src/python/CVS/python/dist/src/Lib/zipfile.py", line
> 471, in close
>     self.fp.flush()
> IOError: [Errno 9] Bad file descriptor
> 
> Looks like FreeBSD objects to doing a flush() on a file opened for
> reading. The self.fp.flush() call should probably be part of the
> preceding if-block relating to files opened in "a" or "w' mode.

You're right.  I've fixed this.

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



From nas at python.ca  Sat Apr 14 18:52:45 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sat, 14 Apr 2001 09:52:45 -0700
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 12:27:09PM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>
Message-ID: <20010414095245.A7402@glacier.fnational.com>

Guido van Rossum wrote:
> Can someone suggest a fix?

I think adding something like:

    find . -name '*.so' -exec rm -f {} ';'

to the clean target would work.  You sould remove the Module/*.so
pattern in the clobber target and fix the comments as well.

One more thing Guido, can you touch Include/graminit.h and
Python/graminit.c before making the tarball?  

  Neil



From mal at lemburg.com  Sat Apr 14 19:02:09 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 14 Apr 2001 19:02:09 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line  
 conversion?
References: <LNBBLJKPBEHFEDALKOLCIECBJMAA.tim.one@home.com>
Message-ID: <3AD88291.8A82378@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > I don't know why this thread lead to tweaking stdio -- after all
> > we only need a solution for the Python tokenizer ...
> 
> [Just]
> > Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is
> > great and all,> but then what about all tools that read source
> > files line by line? ...
> 
> Note that this is why the topic needs a PEP:  nothing here is new; the same
> debates reoccur every time it comes up.

Right.
 
> [Aahz]
> > ...
> > QIO claims that it can be configured to recognize different
> > kinds of line endings.
> 
> It can be, yes, but in the same sense as Awk/Perl paragraph mode:  you can
> tell it to consider any string (not just single character) as meaning "end of
> the line", but it's a *fixed* string per invocation.  What people want *here*
> is more the ability to recognize the regular expression
> 
>     \r\n?|\n
> 
> as ending a line, and QIO can't do that directly (as currently written).  And
> MAL probably wants Unicode line-end detection:
> 
>     http://www.unicode.org/unicode/reports/tr13/

Right ;-)
 
> > QIO is claimed to be 2-3 times faster than Python 1.5.2; don't
> > know how that compares to 2.x.
> 
> The bulk of that was due to QIO avoiding per-character thread locks.  2.1
> avoids them too, so most of QIO's speed advantage should be gone now.  But
> QIO's internals could certainly be faster than they are (this is obscure
> because QIO.readline() has so many optional behaviors that the maze of
> if-tests makes it hard to see the speed-crucial bits; studying Perl's
> line-reading code is a better model, because Perl's speed-crucial inner loop
> has no non-essential operations -- Perl makes the *surrounding* code sort out
> the optional bits, instead of bogging down the loop with them).

Just curious: for the applications which Just has in mind,
reading source code line-by-line is not really needed. Wouldn't
it suffice to read the whole file, split it into lines and then
let the tools process the resulting list of lines ?

Maybe a naive approach, but one which will most certainly work
on all platforms without having to replace stdio...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From just at letterror.com  Sat Apr 14 19:24:44 2001
From: just at letterror.com (Just van Rossum)
Date: Sat, 14 Apr 2001 19:24:44 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line   conversion?
In-Reply-To: <3AD87E28.CCC894AC@lemburg.com>
Message-ID: <20010414192445-r01010600-f8273ce6@213.84.27.177>

M.-A. Lemburg wrote:

> > So no, we don't "only need a solution for the Python tokenizer"...
> 
> See... that's why we need a PEP on these things ;-)

Agreed. I'll try to write one, once I'm feeling better: having the flu doesn't
seem to help focussing on actual content...

Just



From guido at digicool.com  Sat Apr 14 20:38:09 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 13:38:09 -0500
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:52:45 MST."
             <20010414095245.A7402@glacier.fnational.com> 
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>  
            <20010414095245.A7402@glacier.fnational.com> 
Message-ID: <200104141838.NAA23079@cj20424-a.reston1.va.home.com>

> I think adding something like:
> 
>     find . -name '*.so' -exec rm -f {} ';'
> 
> to the clean target would work.  You sould remove the Module/*.so
> pattern in the clobber target and fix the comments as well.

Will do.

> One more thing Guido, can you touch Include/graminit.h and
> Python/graminit.c before making the tarball?  

Why?

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



From just at letterror.com  Sat Apr 14 19:54:54 2001
From: just at letterror.com (Just van Rossum)
Date: Sat, 14 Apr 2001 19:54:54 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line   conversion?
In-Reply-To: <3AD88291.8A82378@lemburg.com>
Message-ID: <20010414195455-r01010600-bf420a02@213.84.27.177>

M.-A. Lemburg wrote:

> Just curious: for the applications which Just has in mind,
> reading source code line-by-line is not really needed. Wouldn't
> it suffice to read the whole file, split it into lines and then
> let the tools process the resulting list of lines ?
> 
> Maybe a naive approach, but one which will most certainly work
> on all platforms without having to replace stdio...

The point is to let existing tools work with all line end conventions *without*
changing the tools. Whether this means replacing stdio I still don't know
<wink>, but it sure means changing the behavior of the Python file object in
text mode.

Just



From paulp at ActiveState.com  Sat Apr 14 20:07:51 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Sat, 14 Apr 2001 11:07:51 -0700
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au> <200104141747.MAA21913@cj20424-a.reston1.va.home.com>
Message-ID: <3AD891F7.1361C560@ActiveState.com>

Do all of these little tweaks mean that we will have another release
candidate or will we just decide that they are low-risk enough not to
worry about? Ideally, the only change from the relcand to final would be
release notes and version numbers...

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From guido at digicool.com  Sat Apr 14 21:41:50 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 14:41:50 -0500
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
In-Reply-To: Your message of "Sat, 14 Apr 2001 11:07:51 MST."
             <3AD891F7.1361C560@ActiveState.com> 
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au> <200104141747.MAA21913@cj20424-a.reston1.va.home.com>  
            <3AD891F7.1361C560@ActiveState.com> 
Message-ID: <200104141941.OAA30229@cj20424-a.reston1.va.home.com>

> Do all of these little tweaks mean that we will have another release
> candidate or will we just decide that they are low-risk enough not to
> worry about? Ideally, the only change from the relcand to final would be
> release notes and version numbers...

I don't think we need another release candidate.

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



From paul at pfdubois.com  Sat Apr 14 20:36:27 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Sat, 14 Apr 2001 11:36:27 -0700
Subject: [Python-Dev] 2.1c1 OK with Numeric -- and a testing question
Message-ID: <ADEOIFHFONCLEEPKCACCEECMCIAA.paul@pfdubois.com>

I built Numeric with 2.1c1 (on Windows) and it passes all our tests.

I intend to convert the Numeric tests to use PyUnit at some point. Is there
a recommended example? I converted the MA test suite by just reading the
PyUnit web page and I have the feeling I'm missing something. I made it work
but it wasn't any nicer than my existing test when I got done. (ANYTHING is
more elegant than the existing Numeric test).





From esr at thyrsus.com  Sat Apr 14 20:47:39 2001
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 14 Apr 2001 14:47:39 -0400
Subject: [Python-Dev] 2.1c1: test_zipfile fails on FreeBSD
In-Reply-To: <200104141941.OAA30229@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 02:41:50PM -0500
References: <3AD7A0F6.7673FDD3@per.dem.csiro.au> <200104141747.MAA21913@cj20424-a.reston1.va.home.com> <3AD891F7.1361C560@ActiveState.com> <200104141941.OAA30229@cj20424-a.reston1.va.home.com>
Message-ID: <20010414144739.A11425@thyrsus.com>

Guido van Rossum <guido at digicool.com>:
> > Do all of these little tweaks mean that we will have another release
> > candidate or will we just decide that they are low-risk enough not to
> > worry about? Ideally, the only change from the relcand to final would be
> > release notes and version numbers...
> 
> I don't think we need another release candidate.

I've fixed my loose end.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Good intentions will always be pleaded for every assumption of
authority. It is hardly too strong to say that the Constitution was
made to guard the people against the dangers of good intentions. There
are men in all ages who mean to govern well, but they mean to
govern. They promise to be good masters, but they mean to be masters.
	-- Daniel Webster



From fdrake at beowolf.digicool.com  Sat Apr 14 22:09:33 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Sat, 14 Apr 2001 16:09:33 -0400 (EDT)
Subject: [Python-Dev] [development doc updates]
Message-ID: <20010414200933.0218628A09@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/devel-docs/


Final Python 2.1 documentation.




From nas at python.ca  Sat Apr 14 22:18:08 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sat, 14 Apr 2001 13:18:08 -0700
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104141838.NAA23079@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 01:38:09PM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com> <20010414095245.A7402@glacier.fnational.com> <200104141838.NAA23079@cj20424-a.reston1.va.home.com>
Message-ID: <20010414131808.A7702@glacier.fnational.com>

Guido van Rossum wrote:
> > One more thing Guido, can you touch Include/graminit.h and
> > Python/graminit.c before making the tarball?  
> 
> Why?

So that those files are not rebuilt.  If the source directory is
read-only then make will fail to build those files.  Its a very
minor issue.

  Neil



From tim.one at home.com  Sat Apr 14 22:35:58 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 14 Apr 2001 16:35:58 -0400
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <200104141421.JAA16441@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com>

[Michael Hudson]
> Maybe modules should be removed from sys.modules when they fail to be
> imported due to an exception?

[Guido]
> This has been suggested before, but *in general* this is not a good
> idea.  For example, you want to debug the remains of the failed
> module.

Ya, I've heard you say something like that before, but haven't understood
what it meant.  That is, I've never had, or been able to picture, a case
where having a module object in an incomplete and unknown state is actually
of use.  OTOH, I've certainly burned my share of time recovering from that
importing a broken module only fails the first time.  It's like Python only
raised an exception the first time somebody tried to open a particular
non-existent file for reading, but the second time it returned a file object
that may or may not fail in use, and may or may not work correctly when it
doesn't fail, depending on what you do with it.

> However, the test suite can easily guard against this, e.g. by
> inserting "import thread" before "import threading" whereever it
> occurs.

So how come a failed attempt to import thread doesn't leave a bogus module
object in sys.modules["thread"] too <0.9 wink>?  This is obscure stuff.  Is
"debugging the remains" of sufficient use to make up for the conceptual
complications?




From guido at digicool.com  Sun Apr 15 02:59:16 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 19:59:16 -0500
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: Your message of "Sat, 14 Apr 2001 16:35:58 -0400."
             <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com> 
Message-ID: <200104150059.TAA30951@cj20424-a.reston1.va.home.com>

> [Michael Hudson]
> > Maybe modules should be removed from sys.modules when they fail to be
> > imported due to an exception?
> 
> [Guido]
> > This has been suggested before, but *in general* this is not a good
> > idea.  For example, you want to debug the remains of the failed
> > module.

[Tim]
> Ya, I've heard you say something like that before, but haven't understood
> what it meant.  That is, I've never had, or been able to picture, a case
> where having a module object in an incomplete and unknown state is actually
> of use.  OTOH, I've certainly burned my share of time recovering from that
> importing a broken module only fails the first time.  It's like Python only
> raised an exception the first time somebody tried to open a particular
> non-existent file for reading, but the second time it returned a file object
> that may or may not fail in use, and may or may not work correctly when it
> doesn't fail, depending on what you do with it.

Maybe.  It could be that the deep reason is mostly that the
implementation doesn't have the information available to decide what
to delete.

> > However, the test suite can easily guard against this, e.g. by
> > inserting "import thread" before "import threading" whereever it
> > occurs.
> 
> So how come a failed attempt to import thread doesn't leave a bogus module
> object in sys.modules["thread"] too <0.9 wink>?  This is obscure stuff.  Is
> "debugging the remains" of sufficient use to make up for the conceptual
> complications?

I'll think about this over the weekend.  I know people have tried to
convince me of changing this before, and I've tried to listen, but
I've never changed it, so I guess there must be a good reason.  It's
worth trying to remember what it is!

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



From guido at digicool.com  Sun Apr 15 03:47:22 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 20:47:22 -0500
Subject: [Python-Dev] 2.1c1: 2nd test_asynchat fails on Solaris 8
In-Reply-To: Your message of "Sat, 14 Apr 2001 09:07:29 +0800."
             <3AD7A2D1.B04928AE@per.dem.csiro.au> 
References: <3AD7A2D1.B04928AE@per.dem.csiro.au> 
Message-ID: <200104150147.UAA31288@cj20424-a.reston1.va.home.com>

> SunOS asafoetida 5.8, gcc 2.95.2
> 
> "make test" fails on running test_asynchat.py for the second time. The
> traceback is:
> 
[...]
> 
> Looks like Solaris takes a while to shut sockets down? (This is not a
> slow box, btw.) Or is there an option to not have the socket linger?

I see.  I've added a call to set the SO_REUSEADDR option in the server
thread.  This solves the problem on the SF compile farm Solaris box.

> Also, test_sunaudiodev fails, since setup.py tests only whether the
> platform is a Sun, not whether there is a /dev/audio as well. Servers
> don't have a /dev/audio. This is clearly a minor nit - I did log a bug
> against this some time ago.

Fred fixed this.

Thanks for these reports!

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



From guido at digicool.com  Sun Apr 15 03:57:00 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 20:57:00 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Sat, 14 Apr 2001 03:58:38 +0300."
             <E14oEOc-0001si-00@darjeeling> 
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>  
            <E14oEOc-0001si-00@darjeeling> 
Message-ID: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>

[Martin]
> > AFAICT, under my patch, when using OpenSSL on a system with EGD, it
> > will do the right thing. On a system with /dev/random, it will produce
> > a runtime warning, then add insecure entropy - in addition to the
> > secure entropy already obtained from /dev/random.
> > 
> > Under what I think is your patch, it will do the right thing on a
> > system with /dev/random. On a system with EGD, it will fail because of
> > the missing entropy.

[Moshe]
> Correct on both. My "worse" is: it would print a warning about using
> an insecure method on systems with /dev/random but without an EGD,
> even though it is secure.

And indeed it does when I tried it on SF's Solaris 8 box, which has
OpenSSL installed and /dev/random.

Even worse (in my view), the error message is as soon as the socket
module is imported!  This is bad, because most uses of socket aren't
interested in its SSl capabilities!

> Note that the EGD stuff is new with 2.1,
> so losing that is not a step backwards from 2.0. Printing a wrong warning
> is a step backwards, so in that sense my patch is more conservative.
>  
> After further contemplation, none of these is a pure win.
> It's up to Guido if he wants to use my patch instead of Martin's
> for 2.1final

I don't like either one.

> *** Modules/socketmodule.c	Sun Mar 18 18:38:50 2001
> --- new	Sat Apr 14 03:53:20 2001
> ***************
> *** 2545,2550 ****
> --- 2545,2551 ----
>   	if (PyDict_SetItemString(d, "SSLType",
>   				 (PyObject *)&SSL_Type) != 0)
>   		return;
> + #if OPENSSL_VERSION_NUMBER < 0x0090510fL

Don't you have this backwards?

>   	if (RAND_status() == 0) {
>   #ifdef USE_EGD
>   		char random_device[MAXPATHLEN+1];
> ***************
> *** 2571,2576 ****
> --- 2572,2578 ----
>   		RAND_seed(random_string, sizeof(random_string));
>   #endif /* USE_EGD */
>   	}
> + #endif /* OPENSSL_VERSION_NUMBER < 0x0090510fL */
>   #endif /* USE_SSL */
>   	PyDict_SetItemString(d, "error", PySocket_Error);
>   	PySocketSock_Type.ob_type = &PyType_Type;

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



From guido at digicool.com  Sun Apr 15 04:17:27 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 21:17:27 -0500
Subject: [Python-Dev] test_fcntl on Solaris 8
Message-ID: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>

While testing Python 2.1 on SF's Solaris 8 box, I noticed that it
hangs forever in test_fcntl, on this line:

  rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata)

Why could this be?  Could it be that the NFS lock server is stuck?

But I could also note that this test is pretty silly.  It has all this
platform-specific cruft to do a locking operation the hard way, while
the fcntl module supplies two operations (flock() and lockf()) that
could be used instead!

(Unfortunately, using lockf() I get the same behavior -- not
surprising, since the C code does the same thing that the Python code
was doing. :-( )

Should I update the test, or declare the machine broken?  (I *think* I
recall that the tests succeeded yesterday.)

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



From m.favas at per.dem.csiro.au  Sun Apr 15 05:18:39 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 11:18:39 +0800
Subject: [Python-Dev] Re: test_fcntl on Solaris 8
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>
Message-ID: <3AD9130F.3986FCDA@per.dem.csiro.au>

On my Solaris 8 box test_fcntl succeeds just fine (just tried it again),
with no hangs or hesitations - on the other hand, it's not using any NFS
filesystems, so that could be the problem with the SF box. So declare
the box broken... 

I'd be inclined to update the test anyway, since most people who want to
lock files will use the supplied flock()/lockf() rather than doing it
the hard way - so if the fcntl test locks files, it should use the
generic locking functions.

Guido van Rossum wrote:
> 
> While testing Python 2.1 on SF's Solaris 8 box, I noticed that it
> hangs forever in test_fcntl, on this line:
> 
>   rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata)
> 
> Why could this be?  Could it be that the NFS lock server is stuck?
> 
> But I could also note that this test is pretty silly.  It has all this
> platform-specific cruft to do a locking operation the hard way, while
> the fcntl module supplies two operations (flock() and lockf()) that
> could be used instead!
> 
> (Unfortunately, using lockf() I get the same behavior -- not
> surprising, since the C code does the same thing that the Python code
> was doing. :-( )
> 
> Should I update the test, or declare the machine broken?  (I *think* I
> recall that the tests succeeded yesterday.)
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From m.favas at per.dem.csiro.au  Sun Apr 15 05:34:46 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 11:34:46 +0800
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
Message-ID: <3AD916D6.49FE7B47@per.dem.csiro.au>

[Guido]
> [Moshe]
>> Correct on both. My "worse" is: it would print a warning about using
>> an insecure method on systems with /dev/random but without an EGD,
>> even though it is secure.

> And indeed it does when I tried it on SF's Solaris 8 box, which has
> OpenSSL installed and /dev/random.

Interesting - there's no /dev/random on my Solaris 8 boxes...

> Even worse (in my view), the error message is as soon as the socket
> module is imported!  This is bad, because most uses of socket aren't
>interested in its SSl capabilities!

Quite agree - I've got OpenSSL on my Tru64 box (no /dev/random either)
and it's annoying to get this warning whenever I "import socket". If the
OpenSSL bits don't themselves warn about insecure methods, I'd prefer if
Python didn't take it upon itself to nag <wink>.

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From guido at digicool.com  Sun Apr 15 06:40:40 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 14 Apr 2001 23:40:40 -0500
Subject: [Python-Dev] Re: test_fcntl on Solaris 8
In-Reply-To: Your message of "Sun, 15 Apr 2001 11:18:39 +0800."
             <3AD9130F.3986FCDA@per.dem.csiro.au> 
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>  
            <3AD9130F.3986FCDA@per.dem.csiro.au> 
Message-ID: <200104150440.XAA31778@cj20424-a.reston1.va.home.com>

> On my Solaris 8 box test_fcntl succeeds just fine (just tried it again),
> with no hangs or hesitations - on the other hand, it's not using any NFS
> filesystems, so that could be the problem with the SF box. So declare
> the box broken... 

Thanks!

> I'd be inclined to update the test anyway, since most people who want to
> lock files will use the supplied flock()/lockf() rather than doing it
> the hard way - so if the fcntl test locks files, it should use the
> generic locking functions.

I agree, but I'd rather do that after 2.1.  Who knows what problem I
might introduce in the test (I really don't know these calls very
well).

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



From m.favas at per.dem.csiro.au  Sun Apr 15 07:15:39 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 13:15:39 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
Message-ID: <3AD92E7B.E6CC7EE7@per.dem.csiro.au>

Further investigations withe current CVS 2.1c1 (and everything compiled
without optimization) on a large multi=processor Irix 6.5 box with SGI's
MIPSpro 7.30 compiler:

The previously reported failure of test_largefile was due to running
"make test" on an NFS-mounted filesystem from a box that didn't support
large files. Works on a local filesystem.

The previously reported failure of test_zlib looks as though it is due
to Irix supplying as standard zlib version 1.0.4, whereas the zlib
module requires at least version 1.1.3. This won't be the only platform
where an incompatible zlib is system-supplied and built by default. An
autoconf test for the right version seems indicated (unless setup.py can
just extract the version string from <wherever>/zlib.h - it's there as
#define ZLIB_VERSION "1.0.4" on Irix, and #define ZLIB_VERSION "1.1.3"
on Solaris 8 (both in /usr/include)).


Tests still failing under Irix:

python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ...
Traceback (most recent call last):
  File "Lib/test/test_locale.py", line 29, in ?
    testformat("%f", 1024, grouping=1, output='1,024.000000')
  File "Lib/test/test_locale.py", line 18, in testformat
    result = locale.format(formatstr, value, grouping = grouping)
  File "/var/tmp/mark/src/Lib/locale.py", line 137, in format
    fields[0],seps=_group(fields[0])
ValueError: unpack sequence of wrong size


-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From guido at digicool.com  Sun Apr 15 08:33:25 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 01:33:25 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Sun, 15 Apr 2001 13:15:39 +0800."
             <3AD92E7B.E6CC7EE7@per.dem.csiro.au> 
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> 
Message-ID: <200104150633.BAA02770@cj20424-a.reston1.va.home.com>

[Mark Favas]
> Further investigations withe current CVS 2.1c1 (and everything compiled
> without optimization) on a large multi=processor Irix 6.5 box with SGI's
> MIPSpro 7.30 compiler:
> 
> The previously reported failure of test_largefile was due to running
> "make test" on an NFS-mounted filesystem from a box that didn't support
> large files. Works on a local filesystem.
> 
> The previously reported failure of test_zlib looks as though it is due
> to Irix supplying as standard zlib version 1.0.4, whereas the zlib
> module requires at least version 1.1.3. This won't be the only platform
> where an incompatible zlib is system-supplied and built by default. An
> autoconf test for the right version seems indicated (unless setup.py can
> just extract the version string from <wherever>/zlib.h - it's there as
> #define ZLIB_VERSION "1.0.4" on Irix, and #define ZLIB_VERSION "1.1.3"
> on Solaris 8 (both in /usr/include)).

I'll leave that to Andrew, I have no understanding of setup.py.
(Unfortunately Andrew seems out of town. :-( )

> Tests still failing under Irix:
> 
> python Lib/test/test_locale.py
> '%f' % 1024 =? '1,024.000000' ...
> Traceback (most recent call last):
>   File "Lib/test/test_locale.py", line 29, in ?
>     testformat("%f", 1024, grouping=1, output='1,024.000000')
>   File "Lib/test/test_locale.py", line 18, in testformat
>     result = locale.format(formatstr, value, grouping = grouping)
>   File "/var/tmp/mark/src/Lib/locale.py", line 137, in format
>     fields[0],seps=_group(fields[0])
> ValueError: unpack sequence of wrong size

Can you find out what at this point the value of
localeconv()['grouping'] is?  The only way this can happen, I think,
is for that to be a false value -- then _group() returns a single
string value instead of a tuple.  This seems to be a bug in _group()
-- the only place that uses it (format()) always assumes it returns a
tuple of two elements.

I'm not sure what the intention was...

Martin, can you suggest a way out here?

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



From m.favas at per.dem.csiro.au  Sun Apr 15 07:37:35 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 13:37:35 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
Message-ID: <3AD9339F.44C7FC05@per.dem.csiro.au>

Guido van Rossum wrote:
> 
> > Tests still failing under Irix:
> >
> > python Lib/test/test_locale.py
> > '%f' % 1024 =? '1,024.000000' ...
> > Traceback (most recent call last):
> >   File "Lib/test/test_locale.py", line 29, in ?
> >     testformat("%f", 1024, grouping=1, output='1,024.000000')
> >   File "Lib/test/test_locale.py", line 18, in testformat
> >     result = locale.format(formatstr, value, grouping = grouping)
> >   File "/var/tmp/mark/src/Lib/locale.py", line 137, in format
> >     fields[0],seps=_group(fields[0])
> > ValueError: unpack sequence of wrong size
> 
> Can you find out what at this point the value of
> localeconv()['grouping'] is?  The only way this can happen, I think,
> is for that to be a false value -- then _group() returns a single
> string value instead of a tuple.  This seems to be a bug in _group()
> -- the only place that uses it (format()) always assumes it returns a
> tuple of two elements.

localeconv()['grouping'] is "[]" at this point...

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From neal at metaslash.com  Sun Apr 15 09:38:34 2001
From: neal at metaslash.com (Neal Norwitz)
Date: Sun, 15 Apr 2001 03:38:34 -0400
Subject: [Python-Dev] Python 2.1 RC - PyChecker
References: <mailman.987196706.7970.python-list@python.org>
Message-ID: <3AD94FFA.7D930EF0@metaslash.com>

I've run the CVS version of PyChecker (http://pychecker.sourceforge.net)
against Python 2.1 RC1.  Below are the real or possible problems I found.

Some of the "not used" could be real errors, most are not.
All "uses named arguments" can be safely ignored.
"No global"s are definitely problems AFAICT (except 1 which can't be reached).

Neal
--

MimeWriter.py:108 Function (addheader) uses named arguments
MimeWriter.py:117 Function (startbody) uses named arguments
StringIO.py:187 Local variable (here) not used
UserString.py:137 Base class (UserString.UserString) __init__() not called
aifc.py:181 Local variable (math) not used
asynchat.py:99 No method (collect_incoming_data) found
asynchat.py:112 No method (found_terminator) found
	(2 methods documented, but should add method and raise exception?)
asyncore.py:155 Local variable (l) not used
audiodev.py:214 No global (BUFFERSIZE) found
bdb.py:220 Local variable (bp) not used
cgi.py:743 Base class (UserDict.UserDict) __init__() not called
cgi.py:843 Local variable (traceback) not used
chunk.py:109 No attribute (chunk_size) found
	(should be chunksize)
fileinput.py:292 Function (input) uses named arguments
getpass.py:29 Local variable (getpass) not used
gopherlib.py:172 Local variable (port) not used
gzip.py:276 Local variable (orig_size) not used
ihooks.py:494 Function (import_it) uses named arguments
ihooks.py:498 Function (import_it) uses named arguments
imaplib.py:1019 No global (j) found
locale.py:273 No global (l) found
	(can't be reach, but could remove last else and always raise error)
mailbox.py:21 No attribute (stop) found
mailbox.py:23 No attribute (start) found
mailbox.py:29 No method (_search_start) found
mailbox.py:34 No method (_search_end) found
	(_search_*() used in subclasses, add method and raise exception?)
mailbox.py:106 No method (_isrealfromline) found
mailbox.py:260 Local variable (time) not used
mhlib.py:651 Local variable (messages) not used
netrc.py:13 No global (file) found
	(should be filename)
nturl2path.py:45 Local variable (string) not used
pstats.py:188 Local variable (std_list) not used
pyclbr.py:206 Local variable (imports) not used
pydoc.py:170 Base class (exceptions.Exception) __init__() not called
rfc822.py:607 Local variable (expectaddrspec) not used
robotparser.py:234 Local variable (sys) not used
sgmllib.py:178 No global (SGMLParserError) found
	(should be SGMLParseError?)
shlex.py:99 Local variable (tok) not used
smtpd.py:312 No global (UnimplementedError) found
smtpd.py:375 Local variable (paths) not used
sndhdr.py:87 Local variable (hdr_size) not used
sndhdr.py:134 Local variable (style) not used
sre_parse.py:286 Local variable (here) not used
threading.py:547 Local variable (random) not used
threading.py:611 Local variable (time) not used
token.py:85 Local variable (string) not used
unittest.py:675 Local variable (opts) not used
urllib.py:1147 Local variable (x) not used
urllib2.py:450 No global (error_302_dict) found
	(needs req.?)
urllib2.py:630 No attribute (parent) found
urllib2.py:1053 No global (OpenerDirectory) found
urlparse.py:58 Local variable (path) not used
webbrowser.py:77 No global (ret) found



From moshez at zadka.site.co.il  Sun Apr 15 13:29:31 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Sun, 15 Apr 2001 14:29:31 +0300
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>
References: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>, <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>  
            <E14oEOc-0001si-00@darjeeling>
Message-ID: <E14okih-0004J3-00@darjeeling>

On Sat, 14 Apr 2001 20:57:00 -0500, Guido van Rossum <guido at digicool.com> wrote:

> Even worse (in my view), the error message is as soon as the socket
> module is imported!  This is bad, because most uses of socket aren't
> interested in its SSl capabilities!

Yeah, well, for 2.2 I'm planning to have a suggestion for redoing the
SSL support in Python, which is currently brain damaged in many ways,
and this is one.

> I don't like either one.

Mine at least has the property that we're no worse off then 2.0

> > + #if OPENSSL_VERSION_NUMBER < 0x0090510fL
> 
> Don't you have this backwards?

Yes, sorry.

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From guido at digicool.com  Sun Apr 15 15:34:38 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 08:34:38 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Sun, 15 Apr 2001 14:29:31 +0300."
             <E14okih-0004J3-00@darjeeling> 
References: <200104150157.UAA31334@cj20424-a.reston1.va.home.com>, <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling> <E14oEOc-0001si-00@darjeeling>  
            <E14okih-0004J3-00@darjeeling> 
Message-ID: <200104151334.IAA09030@cj20424-a.reston1.va.home.com>

> > Even worse (in my view), the error message is as soon as the socket
> > module is imported!  This is bad, because most uses of socket aren't
> > interested in its SSl capabilities!
> 
> Yeah, well, for 2.2 I'm planning to have a suggestion for redoing the
> SSL support in Python, which is currently brain damaged in many ways,
> and this is one.

So why even bother adding the EGD support?

> > I don't like either one.
> 
> Mine at least has the property that we're no worse off then 2.0

Except that it still has a chance of issuing a warning!  I'm very
tempted to rip out all code added by your patch.

> > > + #if OPENSSL_VERSION_NUMBER < 0x0090510fL
> > 
> > Don't you have this backwards?
> 
> Yes, sorry.

I've had it.  I'm ripping out that patch.  People who want EGD support
desperate enough can download the patch from SF.

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



From guido at digicool.com  Sun Apr 15 15:48:35 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 08:48:35 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Sun, 15 Apr 2001 13:37:35 +0800."
             <3AD9339F.44C7FC05@per.dem.csiro.au> 
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>  
            <3AD9339F.44C7FC05@per.dem.csiro.au> 
Message-ID: <200104151348.IAA09108@cj20424-a.reston1.va.home.com>

> localeconv()['grouping'] is "[]" at this point...

It is looking like either the _locale.c module is not working right or
the platform's implementation of the en_US locals is broken.  I'm
afraid that only you will be able to make the determination. :-(

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



From m.favas at per.dem.csiro.au  Sun Apr 15 15:08:11 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sun, 15 Apr 2001 21:08:11 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
Message-ID: <3AD99D3B.A5441B0B@per.dem.csiro.au>

Guido van Rossum wrote:
> 
> [Mark Favas]
> >
> > The previously reported failure of test_zlib looks as though it is due
> > to Irix supplying as standard zlib version 1.0.4, whereas the zlib
> > module requires at least version 1.1.3. This won't be the only platform
> > where an incompatible zlib is system-supplied and built by default. An
> > autoconf test for the right version seems indicated (unless setup.py can
> > just extract the version string from <wherever>/zlib.h - it's there as
> > #define ZLIB_VERSION "1.0.4" on Irix, and #define ZLIB_VERSION "1.1.3"
> > on Solaris 8 (both in /usr/include)).
> 
> I'll leave that to Andrew, I have no understanding of setup.py.
> (Unfortunately Andrew seems out of town. :-( )

A patch to setup.py that works on the SGI where the version of zlib.h in
/usr/include is too low, and also works on my Tru64 box where the
version in /usr/local/include is just right follows:
(I'll also submit this to sourceforge.)

*** setup.py.orig       Sun Apr 15 20:59:34 2001
--- setup.py    Sun Apr 15 21:00:53 2001
***************
*** 449,457 ****
          # Andrew Kuchling's zlib module.
          # This require zlib 1.1.3 (or later).
          # See http://www.cdrom.com/pub/infozip/zlib/
!         if (self.compiler.find_library_file(lib_dirs, 'z')):
!             exts.append( Extension('zlib', ['zlibmodule.c'],
!                                    libraries = ['z']) )
  
          # Interface to the Expat XML parser
          #
--- 449,471 ----
          # Andrew Kuchling's zlib module.
          # This require zlib 1.1.3 (or later).
          # See http://www.cdrom.com/pub/infozip/zlib/
!         zlib_inc = find_file('zlib.h', [], inc_dirs)
!         if zlib_inc is not None:
!             zlib_h = zlib_inc[0] + '/zlib.h'
!             version = '"0.0.0"'
!             version_req = '"1.1.3"'
!             fp = open(zlib_h)
!             while 1:
!                 line = fp.readline()
!                 if not line:
!                     break
!                 if line.find('#define ZLIB_VERSION', 0) == 0:
!                     version = line.split()[2]
!                     break
!             if version >= version_req:
!                 if (self.compiler.find_library_file(lib_dirs, 'z')):
!                     exts.append( Extension('zlib', ['zlibmodule.c'],
!                                            libraries = ['z']) )
  
          # Interface to the Expat XML parser
          #

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From guido at digicool.com  Sun Apr 15 18:18:46 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 11:18:46 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Sun, 15 Apr 2001 21:08:11 +0800."
             <3AD99D3B.A5441B0B@per.dem.csiro.au> 
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>  
            <3AD99D3B.A5441B0B@per.dem.csiro.au> 
Message-ID: <200104151618.LAA10062@cj20424-a.reston1.va.home.com>

> A patch to setup.py that works on the SGI where the version of zlib.h in
> /usr/include is too low, and also works on my Tru64 box where the
> version in /usr/local/include is just right follows:

Thanks, Mark.  It works for me!

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



From thomas at xs4all.net  Sun Apr 15 17:31:08 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 17:31:08 +0200
Subject: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
In-Reply-To: <200104150059.TAA30951@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 07:59:16PM -0500
References: <LNBBLJKPBEHFEDALKOLCKEENJMAA.tim.one@home.com> <200104150059.TAA30951@cj20424-a.reston1.va.home.com>
Message-ID: <20010415173108.M2820@xs4all.nl>

On Sat, Apr 14, 2001 at 07:59:16PM -0500, Guido van Rossum wrote:

> [Tim]
> > [..] I've never had, or been able to picture, a case where having a
> > module object in an incomplete and unknown state is actually of use. 
> > OTOH, I've certainly burned my share of time recovering from that
> > importing a broken module only fails the first time.  It's like Python
> > only raised an exception the first time somebody tried to open a
> > particular non-existent file for reading, but the second time it
> > returned a file object that may or may not fail in use, and may or may
> > not work correctly when it doesn't fail, depending on what you do with
> > it.

> Maybe. 

Wouldn't the right place for the half-broken, import-failed module be in the
traceback object ? In fact, isn't it already *in* the traceback object ? :)

> It could be that the deep reason is mostly that the
> implementation doesn't have the information available to decide what
> to delete.

Deep magic can be added. Deep magic should be added, IMHO, unless ...

> I'll think about this over the weekend.  I know people have tried to
> convince me of changing this before, and I've tried to listen, but
> I've never changed it, so I guess there must be a good reason.  It's
> worth trying to remember what it is!

... you come up with a real reason for it to be as it is ;)

Happy-easter-for-those-of-you-with-permanent-'net-connections-*snif*-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Sun Apr 15 17:38:41 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 17:38:41 +0200
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 12:27:09PM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>
Message-ID: <20010415173841.N2820@xs4all.nl>

On Sat, Apr 14, 2001 at 12:27:09PM -0500, Guido van Rossum wrote:

> Another consequence is that after "make clobber" you have to rerun the
> configure script (or say "make recheck").  This takes almost as long
> as the rest of the build...

So don't do that. Run 'config.status' instead: it'll recreate your config
files (Makefile.pre, config.h, Setup.config) from cached info. It won't
rebuild everything, but it rebuilds config.h, which is what 'make clobber'
removes that breaks building.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at digicool.com  Sun Apr 15 18:47:32 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 11:47:32 -0500
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: Your message of "Sun, 15 Apr 2001 17:38:41 +0200."
             <20010415173841.N2820@xs4all.nl> 
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com>  
            <20010415173841.N2820@xs4all.nl> 
Message-ID: <200104151647.LAA10237@cj20424-a.reston1.va.home.com>

> > Another consequence is that after "make clobber" you have to rerun the
> > configure script (or say "make recheck").  This takes almost as long
> > as the rest of the build...
> 
> So don't do that. Run 'config.status' instead: it'll recreate your config
> files (Makefile.pre, config.h, Setup.config) from cached info. It won't
> rebuild everything, but it rebuilds config.h, which is what 'make clobber'
> removes that breaks building.

Well, my issue is that before Neil "fixed" the Makefile, after a "make
clobber" a "make" would do the job.  Now, there's a dependency on
config.h but the Makefile doesn't know how to make that file.

Maybe it should.

But I've "fixed" it by adding a line to the clean target that removes
the .so files, so I don't have to use "make clobber".

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



From thomas at xs4all.net  Sun Apr 15 18:03:08 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 18:03:08 +0200
Subject: [Python-Dev] test_fcntl on Solaris 8
In-Reply-To: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sat, Apr 14, 2001 at 09:17:27PM -0500
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>
Message-ID: <20010415180307.P2820@xs4all.nl>

On Sat, Apr 14, 2001 at 09:17:27PM -0500, Guido van Rossum wrote:

> While testing Python 2.1 on SF's Solaris 8 box, I noticed that it
> hangs forever in test_fcntl, on this line:

>   rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata)

> Why could this be?  Could it be that the NFS lock server is stuck?

It could very well be that. NFS (version 2 or 3) locking is really, really
dumb. Not just the act of locking over NFS, but the whole protocol for
locking over NFS. If you consider that NFS is meant to be stateless, you can
quickly realize how locking (as well as the concept of 'open files' and what
should happen when you delete open files) do not fit well with NFS. There
are some other braindeadisms with NFS locking, though: it's not possible to
break a lock. If a machine is locking a file, and the machine goes down, the
lock stays in effect until the machine is back up. And 'a machine' is
identified with an ipaddress, so if it gets a new IP, tough. If it stays
down indefinately, tough.

And then there's the implementation side. I have yet to find an NFS server
or client that deals sanely with locks either way. Either they're too
lenient (not very often) or too strict, or they just don't talk well with
the other side. If you want to do locking over NFS, don't use lockf or
flock, use the link/stat lock method (see Mailman's LockFile module for a
somewhat expanded implementation of sane locking over NFS.)

On the plus side, there's a lot of work being done on NFSv4, which should
fix almost every design error made in NFSv2/3. Including the locking ;)

In any case, the problem on the SF Solaris box could be one of two things: a
hanging lock, in which case renaming/removing the testfile should fix it, or
a communication problem between the Solaris box and the NFS server. The
latter is pretty likely the case if the NFS server is Linux, which is pretty
likely with Sourceforge. You can doublecheck by using a testfile on another
filesystem, which isn't NFS-mounted (like /tmp.)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From gward at python.net  Sun Apr 15 18:24:29 2001
From: gward at python.net (Greg Ward)
Date: Sun, 15 Apr 2001 12:24:29 -0400
Subject: [Python-Dev] s1 == (sf % (s1 / sf))? A bad idea?
In-Reply-To: <3AD7ED4D.58597DFD@darwin.in-berlin.de>; from gherman@darwin.in-berlin.de on Sat, Apr 14, 2001 at 08:25:17AM +0200
References: <3AD7ED4D.58597DFD@darwin.in-berlin.de>
Message-ID: <20010415122429.A539@gerg.ca>

On 14 April 2001, Dinu Gherman said:
> I'd like to support Peter's proposal for having *some* kind 
> of inverse mechanism to string formatting using '%'. Now, that
> doesn't mean anything, of course, but no matter what the syn-
> tax would look like: I'd prefer having that feature over not
> having it and I'll give an example below.

But we already have one: re.match (and friends).  Regexes are vastly
more powerful, predictable, reliable, and (to me at least)
comprehensible than scanf() format strings.  I've never understood how
scanf() works, and I don't see a great burning need to add scanf() to
Python.

Adding syntactic sugar for scanf() in the form of overloading "/" seems
like a *really* bad idea, too.  ("%" is a nice operator because printf()
format strings use "%" a lot, not because formatting a string has
anything remotely to do with modulo arithmetic.)  If scanf() really
needs to be in Python, write Modules/scanfmodule.c, build it by default,
and be done with it.  Or *maybe* make it a string method, if enough
people think it's useful.

        Greg
-- 
Greg Ward - just another Python hacker                  gward at python.net
http://starship.python.net/~gward/
When you make your mark in the world, watch out for guys with erasers.



From thomas at xs4all.net  Sun Apr 15 18:36:43 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 18:36:43 +0200
Subject: [Python-Dev] make clean and make clobber semantics
In-Reply-To: <200104151647.LAA10237@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Sun, Apr 15, 2001 at 11:47:32AM -0500
References: <200104141727.MAA21760@cj20424-a.reston1.va.home.com> <20010415173841.N2820@xs4all.nl> <200104151647.LAA10237@cj20424-a.reston1.va.home.com>
Message-ID: <20010415183642.Q2820@xs4all.nl>

On Sun, Apr 15, 2001 at 11:47:32AM -0500, Guido van Rossum wrote:
> > > Another consequence is that after "make clobber" you have to rerun the
> > > configure script (or say "make recheck").  This takes almost as long
> > > as the rest of the build...
> > 
> > So don't do that. Run 'config.status' instead: it'll recreate your config
> > files (Makefile.pre, config.h, Setup.config) from cached info. It won't
> > rebuild everything, but it rebuilds config.h, which is what 'make clobber'
> > removes that breaks building.

> Well, my issue is that before Neil "fixed" the Makefile, after a "make
> clobber" a "make" would do the job.  Now, there's a dependency on
> config.h but the Makefile doesn't know how to make that file.

I know, I was just pointing out you don't have to wait for 'configure' to do
its uncached magic, even if you lose config.h. Some projects do have a
dependency for 'config.h' that just calls config.status, by the way. (and if
config.status is missing, they just call configure or tell you to run
configure manually.)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at digicool.com  Sun Apr 15 19:45:08 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 12:45:08 -0500
Subject: [Python-Dev] test_fcntl on Solaris 8
In-Reply-To: Your message of "Sun, 15 Apr 2001 18:03:08 +0200."
             <20010415180307.P2820@xs4all.nl> 
References: <200104150217.VAA31392@cj20424-a.reston1.va.home.com>  
            <20010415180307.P2820@xs4all.nl> 
Message-ID: <200104151745.MAA10389@cj20424-a.reston1.va.home.com>

> In any case, the problem on the SF Solaris box could be one of two things: a
> hanging lock, in which case renaming/removing the testfile should fix it, or
> a communication problem between the Solaris box and the NFS server. The
> latter is pretty likely the case if the NFS server is Linux, which is pretty
> likely with Sourceforge. You can doublecheck by using a testfile on another
> filesystem, which isn't NFS-mounted (like /tmp.)

Thanks.  This makes me feel much better.  The test runs fine with a
test file on /tmp.  Removing the test file doesn't help at all, so I'm
guessing that the communication with the lock server is broken.

I'll remove it from my list of showstopper issues.  This list now
has test_locale on Irix, and the issue with SSL and EGD.  My
prediction: the locale problem on Irix is a platform bug, and I'll
remove the EGD patch altogether from socketmodule.c.

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



From thomas at xs4all.net  Sun Apr 15 20:56:47 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 15 Apr 2001 20:56:47 +0200
Subject: [Python-Dev] 2.1c1 on BSDI
Message-ID: <20010415205647.R2820@xs4all.nl>


For the record :) Python 2.1c1 performs as expected on BSDI 4.1 and 4.0.1.
That is, there are some crashes, but those were there in 2.0 and 1.5.2 as
well, for the most part, and are test-specific errors in general. We've been
using 2.1b2 (actually slightly newer) on development machines, where it is
used for various tools, and I haven't encountered many bugs yet.

BSDI 4.0.1 still needs to disable threads, but that's a platform bug, not a
Python one.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From tim.one at home.com  Sun Apr 15 21:11:30 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 15:11:30 -0400
Subject: [Python-Dev] Showstopper
Message-ID: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>

We've got a showstopper bug involving gc and dicts.  It's not brand new, but
was probably introduced when we fiddled PyDict_Next() to stop the dict
resizing problems plaguing Jeremy.

Cut to the chase:

1. dict_items() is called.  The dict has 22 of 32 slots filled.

2. PyList_New(22) creates the result list.

3. dict_items() loops through the dict looking for active entries.
   It does *not* use PyDict_Next, but a loop of the form

       	for (i = 0, j = 0; i < mp->ma_size; i++) {

4. When it finds an active entry, it calls PyTuple_New(2) to
   create the entry's (key, value) result tuple.

5. At the end, PyTuple_New() calls PyObject_GC_Init(), which
   calls _PyGC_Insert().

6. _PyGC_Insert() decides it's time for a collection.

7. The dict dict_items() is iterating over (remember step #1 <wink>?)
   is one of the objects gc traverses.  gc dict traversal *does* use
   PyDict_Next.

8. 22 of 32 slots filled is exactly at the dict resize point, so
   the PyDict_Next() invoked by gc traversal grows the dict.

9. So, back to step #1, dict_item()'s

           	for (i = 0, j = 0; i < mp->ma_size; i++) {

   loop now goes up to 64 instead of the original 32, and, because
   of the internal dict reshuffling, *can* (depending on the exact
   data content of the dict) see values again that it already
   saw before the dict got rearranged.

10. As a result, the later

			PyList_SetItem(v, j, item);

   inside the loop can eventually pass values for j too large for
   the list.

11. PyList_SetItem() sets a "list assignment index out of range"
    error string, but nobody pays ttention to that, and dict_items()
    proceeds to trigger the error multiple times.

12. The value returned by dict_items() is wrong, containing
    some duplicate (key, value) pairs, and missing others.

13. The eval loop goes around a few more times, until it finally
    hits a bytecode that notices the pending exception.  Then (I
    finally got lucky here!) IndexError finally pops up on a line
    where an IndexError doesn't make sense.

I have a test case that reliably triggers this bug, but was unable to whittle
it below 100+ Kb of code + data files.  So trust me about the details above
(they're clear enough!).




From mwh21 at cam.ac.uk  Sun Apr 15 22:03:10 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: Sun, 15 Apr 2001 21:03:10 +0100 (BST)
Subject: [Python-Dev] Showstopper
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>
Message-ID: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>

On Sun, 15 Apr 2001, Tim Peters wrote:

> We've got a showstopper bug involving gc and dicts.  It's not brand
> new, but was probably introduced when we fiddled PyDict_Next() to stop
> the dict resizing problems plaguing Jeremy.

Crap.

Two ideas suggest themselves: (1) don't have the resize check in
PyDict_Next (it could be in PyDict_SetItem instead, though the fact that
this is safe is delicate to say the least) (2) don't use PyDict_Next in
dict_traverse.

OTOH, the GC runs __del__ methods, right?  So what if a __del__ method
mutates the dictionary that .items() is being called on?  If allocating
memory can execute arbitrary Python code, I dread to think how many bugs
of this form are hiding in Python (actually it's only allocating
containers that's the worry, but still...).  On the third hand, I can't
trigger one deliberately, so maybe I'm talking nonsense.

To fix items/keys/values, you could build up the list of tuples first,
check you still have the right amount, then fill them in.

not-sure-this-is-helping-ly y'rs
M.




From nas at python.ca  Sun Apr 15 23:07:30 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sun, 15 Apr 2001 14:07:30 -0700
Subject: [Python-Dev] Showstopper
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>; from tim.one@home.com on Sun, Apr 15, 2001 at 03:11:30PM -0400
References: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>
Message-ID: <20010415140730.B21716@glacier.fnational.com>

Tim Peters wrote:
> I have a test case that reliably triggers this bug, but was unable to whittle
> it below 100+ Kb of code + data files.  So trust me about the details above
> (they're clear enough!).

The details are all to clear to me.  :-( Can you get me the test
case somehow?  I'm thinking about how to fix this right now but I
don't think its going to be easy.

  Neil



From tim.one at home.com  Sun Apr 15 23:17:23 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:17:23 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEHLJMAA.tim.one@home.com>

Guido & I talked out A Plan, and he's going to implement it while I take a
nap.  Outline:

1. It sucks that PyDict_Next() can resize a dict.  And while staring
   at all this in the debugger, it was plain appalling that the mere
   act of doing gc ran around turning empty dicts into non-empty
   ones because of it (not a bug, just irksome waste).

2. It sucks that PyDict_SetItem() can resize a dict even when
   the number of active slots doesn't change.

The plan for addressing those:

A. Rip out the PyDict_Next() resizing hack.

B. In PyDict_SetItem(), first look at the number of free slots,
   and resize the dict if it would be impossible to add a new
   active slot (I *suspect* this can be reduced to making a minimal
   dict when the incoming dict is empty).
   Remember the number of used slots.
   Do the insert.
   Look at the number of used slots now:  do "the usual" resize
   logic if and only the number of used slots changed across
   the insert call.

That much should suffice to stop Jeremy's old bugs, and the bug I bumped into
here.

It's not enough, though.  Allocating a tuple (or any other gc'ed type) can
still cause gc to run, then gc can delete __del__-free cycles, then deleting
those can cause objects with __del__ methods to become unreachable too, and
then any Python code whatsoever can run, incl. but not limited to code that
dicts, and also incl. allowing other threads to run.

So code inside dict methods can't assume much of anything across container
allocations, even after fixing all the bugs we've bumped into so far.  So at
least dict_items() and dict_popitem() remain unsafe after these changes,
although we don't have a concrete test case to prove that and it would be
mondo difficult to create one.  Nevertheless, Python users are effective
proof of the million monkeys hypothesis <wink>.  These remaining problems
require case-by-case analysis and rewriting.

could-be-the-biggest-one-line-fix-in-history-ly y'rs  - tim




From guido at digicool.com  Mon Apr 16 00:19:40 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 17:19:40 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 14:07:30 MST."
             <20010415140730.B21716@glacier.fnational.com> 
References: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com>  
            <20010415140730.B21716@glacier.fnational.com> 
Message-ID: <200104152219.RAA11099@cj20424-a.reston1.va.home.com>

> Tim Peters wrote:
> > I have a test case that reliably triggers this bug, but was unable to whittle
> > it below 100+ Kb of code + data files.  So trust me about the details above
> > (they're clear enough!).
> 
> The details are all to clear to me.  :-( Can you get me the test
> case somehow?  I'm thinking about how to fix this right now but I
> don't think its going to be easy.

Don't worry, Tim & I have got it all worked out.  I'll explain later.

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



From tim.one at home.com  Sun Apr 15 23:17:30 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:17:30 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>

[Guido, see last point, about dict.keys()/.values()]

[Michael Hudson]
> Crap.

An accurate summary <wink>.

> Two ideas suggest themselves: (1) don't have the resize check in
> PyDict_Next (it could be in PyDict_SetItem instead, though the fact
> that this is safe is delicate to say the least) (2) don't use
> PyDict_Next in dict_traverse.

See preceding crossed-in-the-mail msg.

> OTOH, the GC runs __del__ methods, right?  So what if a __del__ method
> mutates the dictionary that .items() is being called on?  If
> allocating memory can execute arbitrary Python code,

Right.

> I dread to think how many bugs of this form are hiding in Python
> (actually it's only allocating containers that's the worry, but
> still...).

I did too at first, but it appears to be tractable:  allocating containers
"in the middle" of something else is actually rare.  OTOH, listobject.c
eventually grew a faux "immutable list type", after an endless sequence of
hacks failed to stop all cases in which list.sort() could be tricked into
blowing up by writing devious comparison functions that mutated the list in
"just the right way" during the sort.  Today you get an exception if you try
to mutate a list while it's being sorted, and that worked great (I confess
I'm much fonder of it than Guido is, though).

I think we can stop disasters in the dict code, but also expect "odd
behavior" will be possible; e.g., that dict.items() may return a list with
duplicate keys if code is insane enough to mutate the dict during a __del__
method (or in another thread:  once we execute __del__, we're executing
Python code, and the eval loop will let other threads in).

> On the third hand, I can't trigger one deliberately, so maybe
> I'm talking nonsense.

I expect these are very difficult to trigger.

> To fix items/keys/values, you could build up the list of tuples first,
> check you still have the right amount, then fill them in.

Yes, that's one of the things Guido intends to do, although we only talked
about dict_items().  keys() and values() don't allocate any tuples.  They do
allocate a result list at the start, but-- sigh! --you're right that
mp->ma_used may change "during" the initial

    v = PyList_New(mp->ma_used);

> not-sure-this-is-helping-ly y'rs

it-was-depressing-so-it-must-be-helpful<wink>-ly y'rs  - tim




From nas at python.ca  Sun Apr 15 23:20:23 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sun, 15 Apr 2001 14:20:23 -0700
Subject: [Python-Dev] Showstopper
In-Reply-To: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>; from mwh21@cam.ac.uk on Sun, Apr 15, 2001 at 09:03:10PM +0100
References: <LNBBLJKPBEHFEDALKOLCAEHGJMAA.tim.one@home.com> <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain>
Message-ID: <20010415142023.C21716@glacier.fnational.com>

Michael Hudson wrote:
> Two ideas suggest themselves: (1) don't have the resize check
> in PyDict_Next (it could be in PyDict_SetItem instead, though
> the fact that this is safe is delicate to say the least) (2)
> don't use PyDict_Next in dict_traverse.

There is a collector lock in gcmodule.  We could expose methods
for locking and unlocking it.  I'm not sure if that's the right
solution though.

> OTOH, the GC runs __del__ methods, right?

Yes.

> If allocating memory can execute arbitrary Python code, I dread
> to think how many bugs of this form are hiding in Python

I think this is the crux of the problem.  There is probably more
code that does not expect that to happen.  We can fix this
problem without too much trouble but how many more hard to find
ones will be left?  Am I being paranoid?

  Neil



From nas at python.ca  Sun Apr 15 23:30:59 2001
From: nas at python.ca (Neil Schemenauer)
Date: Sun, 15 Apr 2001 14:30:59 -0700
Subject: [Python-Dev] Showstopper
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>; from tim.one@home.com on Sun, Apr 15, 2001 at 05:17:30PM -0400
References: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain> <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>
Message-ID: <20010415143059.D21716@glacier.fnational.com>

Tim Peters wrote:
> allocating containers "in the middle" of something else is
> actually rare.

It looks like you and Guido are working on a solution to avoid
doing this.  Wouldn't it be better to change the GC so that it
was okay to do that?  Specifically, I'm thinking of making
collection only happen between opcodes.  Perhaps that is too
large of a change to make before the release.

  Neil



From guido at digicool.com  Mon Apr 16 00:40:13 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 17:40:13 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 14:30:59 MST."
             <20010415143059.D21716@glacier.fnational.com> 
References: <Pine.LNX.4.10.10104152046430.21747-100000@localhost.localdomain> <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com>  
            <20010415143059.D21716@glacier.fnational.com> 
Message-ID: <200104152240.RAA11336@cj20424-a.reston1.va.home.com>

> Tim Peters wrote:
> > allocating containers "in the middle" of something else is
> > actually rare.
> 
> It looks like you and Guido are working on a solution to avoid
> doing this.  Wouldn't it be better to change the GC so that it
> was okay to do that?  Specifically, I'm thinking of making
> collection only happen between opcodes.  Perhaps that is too
> large of a change to make before the release.
> 
>   Neil

Yes, I'd rather not touch the GC code this late in the game if we can
avoid it.

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



From tim.one at home.com  Sun Apr 15 23:44:42 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:44:42 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <20010415142023.C21716@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEHOJMAA.tim.one@home.com>

[Neil Schemenauer]
> ...
> Am I being paranoid?

Yes, but paranoia is the right attitude to have here -- embrace your
paranoia, and celebrate the Holy Adrenalin <wink>.




From tim.one at home.com  Sun Apr 15 23:44:52 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 17:44:52 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <20010415143059.D21716@glacier.fnational.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEHOJMAA.tim.one@home.com>

[Tim]
> allocating containers "in the middle" of something else is
> actually rare.

[Neil Schemenauer]
> It looks like you and Guido are working on a solution to avoid
> doing this.  Wouldn't it be better to change the GC so that it
> was okay to do that?  Specifically, I'm thinking of making
> collection only happen between opcodes.  Perhaps that is too
> large of a change to make before the release.

Changing PyDict_Next() and PyDict_SetItem() to avoid gratuitous reshuffling
is a worthy goal regardless (merely traversing a dict simply "should not"
resize it, and has caused problems independent of gc), so I'm solidly +1 on
those.

Loops using PyDict_Next() to mutate values of existing keys can also cause
__del__ methods to execute (because of decref'ing the old values), so there
are non-gc vulnerabilities there too we haven't really addressed -- and then
even switching to "between opcodes" gc wouldn't stop the problems unique to
gc (since __del__ methods go back to the eval loop).

But "between opcodes" sounds like a promising idea to me to short-circuit the
mass of other potential problems that can't be triggered by just decref'ing
things.  Where's the PEP <wink>?




From guido at digicool.com  Mon Apr 16 00:51:07 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 17:51:07 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 17:44:52 -0400."
             <LNBBLJKPBEHFEDALKOLCGEHOJMAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCGEHOJMAA.tim.one@home.com> 
Message-ID: <200104152251.RAA11485@cj20424-a.reston1.va.home.com>

> Loops using PyDict_Next() to mutate values of existing keys can also
> cause __del__ methods to execute (because of decref'ing the old
> values), so there are non-gc vulnerabilities there too we haven't
> really addressed -- and then even switching to "between opcodes" gc
> wouldn't stop the problems unique to gc (since __del__ methods go
> back to the eval loop).

And it's not just __del__.  Lookup operations can invoke arbitrary
Python code for the key comparison, which could mutate the dict (or
let another thread run that mutates the dict).

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



From guido at digicool.com  Mon Apr 16 01:19:55 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 18:19:55 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 17:17:30 -0400."
             <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCEEHLJMAA.tim.one@home.com> 
Message-ID: <200104152319.SAA11860@cj20424-a.reston1.va.home.com>

I've checked in what I think is a complete fix, but I wouldn't mind
some extra eyes -- I'm in a bit of a rush to head out for dinner now.

But Tim, please take a nap first! :-)

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



From guido at digicool.com  Mon Apr 16 01:25:16 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 18:25:16 -0500
Subject: [Python-Dev] 2nd release candidate?
Message-ID: <200104152325.SAA11875@cj20424-a.reston1.va.home.com>

I'd like to issue a 2nd release candidate late tonight, and then
change *nothing* between 2.1c2 and the final release Tuesday.

The only thing I still need to change before making the 2nd release
candidate is to rip out Moshe's EGD patch for the socket module, which
has too many problems IMO.

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



From tim.one at home.com  Mon Apr 16 01:05:25 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 15 Apr 2001 19:05:25 -0400
Subject: [Python-Dev] Showstopper
In-Reply-To: <200104152319.SAA11860@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEIBJMAA.tim.one@home.com>

[Guido]
> I've checked in what I think is a complete fix, but I wouldn't mind
> some extra eyes -- I'm in a bit of a rush to head out for dinner now.
>
> But Tim, please take a nap first! :-)

Heh.  I'm working on it.

Initial bleary-eyeballing turned up one vulnerability remaining, in
dict_popitem():   allocating the result tuple *could* conceivably empty the
dict, in which case the search loop will never terminate.  So I'd move the
"empty?" test after the allocation, like so (untested!):

	/* Allocate the result tuple first.  Believe it or not,
	 * this allocation could trigger a garbage collection which
	 * could resize the dict, which would invalidate the pointer
	 * (ep) into the dict calculated below, or clear the dict.
	 * So we have to do this first.
	 */
	res = PyTuple_New(2);
	if (res == NULL)
		return NULL;
	if (mp->ma_used == 0) {
		PyErr_SetString(PyExc_KeyError,
				"popitem(): dictionary is empty");
		Py_DECREF(res);
		return NULL;
	}

In practice (well, mine), .popitem() is never called on an empty dict, so I
don't at all mind allocating a tuple just to throw it away immediately if the
dict is empty.

zzzzzzzzzzzzzingly y'rs  - tim


PS:  Another release candidate is a prudent idea.  I'll be up again in 1.5
hours.




From guido at digicool.com  Mon Apr 16 03:11:05 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 20:11:05 -0500
Subject: [Python-Dev] Showstopper
In-Reply-To: Your message of "Sun, 15 Apr 2001 19:05:25 -0400."
             <LNBBLJKPBEHFEDALKOLCOEIBJMAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCOEIBJMAA.tim.one@home.com> 
Message-ID: <200104160111.UAA12240@cj20424-a.reston1.va.home.com>

> 	/* Allocate the result tuple first.  Believe it or not,
> 	 * this allocation could trigger a garbage collection which
> 	 * could resize the dict, which would invalidate the pointer
> 	 * (ep) into the dict calculated below, or clear the dict.
> 	 * So we have to do this first.
> 	 */
> 	res = PyTuple_New(2);
> 	if (res == NULL)
> 		return NULL;
> 	if (mp->ma_used == 0) {
> 		PyErr_SetString(PyExc_KeyError,
> 				"popitem(): dictionary is empty");
> 		Py_DECREF(res);
> 		return NULL;
> 	}

Good catch -- checked in now!

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



From guido at digicool.com  Mon Apr 16 03:36:26 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sun, 15 Apr 2001 20:36:26 -0500
Subject: [Python-Dev] NO MORE CHECKINS PLEASE
Message-ID: <200104160136.UAA12834@cj20424-a.reston1.va.home.com>

I'm building another release candidate.  Release later tonight.

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



From jafo at tummy.com  Mon Apr 16 02:41:21 2001
From: jafo at tummy.com (Sean Reifschneider)
Date: Sun, 15 Apr 2001 18:41:21 -0600
Subject: [Python-Dev] 2.1c1 RPMs (was: Re: ANNOUNCE: A Python 2.1 release candidate!)
In-Reply-To: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Apr 13, 2001 at 05:18:40PM -0500
References: <200104132218.RAA10759@cj20424-a.reston1.va.home.com>
Message-ID: <20010415184121.A15535@tummy.com>

On Fri, Apr 13, 2001 at 05:18:40PM -0500, Guido van Rossum wrote:
>Python 2.1 is almost ready.  We've built a release candidate -- a
>version that should become the final version, barring any last-minute

I've built a set of RPMs against 2.1c1, they're available at the same
bat-place:

   ftp://ftp.tummy.com/pub/tummy/RPMS/SRPMS/python2-2.1c1-1tummy.src.rpm

and binaries for RedHat/KRUD 7.0 under:

   ftp://ftp.tummy.com/pub/tummy/RPMS/binaries-KRUD-7.0-i386

   python2-2.1c1-1tummy.i386.rpm
   python2-devel-2.1c1-1tummy.i386.rpm
   python2-tkinter-2.1c1-1tummy.i386.rpm

Enjoy,
Sean
-- 
 Program *INTO* a language, not *IN* it.
                 -- David Gries
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python



From guido at python.org  Mon Apr 16 05:44:59 2001
From: guido at python.org (Guido van Rossum)
Date: Sun, 15 Apr 2001 22:44:59 -0500
Subject: [Python-Dev] ANNOUNCE: A *second* Python 2.1 release candidate!
Message-ID: <200104160344.WAA18937@cj20424-a.reston1.va.home.com>

We found and fixed a rare but serious bug in the dictionary code, and
fixed enough small nits to warrant a second release candidate for
Python 2.1 -- the final release is still planned for Tuesday, April
17.

Please download the release candidate and try it on your favorite
platform.  For more info:

    http://www.python.org/2.1/

Enjoy!

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



From m.favas at per.dem.csiro.au  Mon Apr 16 05:02:51 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Mon, 16 Apr 2001 11:02:51 +0800
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>  
	            <3AD9339F.44C7FC05@per.dem.csiro.au> <200104151348.IAA09108@cj20424-a.reston1.va.home.com>
Message-ID: <3ADA60DB.25854811@per.dem.csiro.au>

Yes, the SGI appears not to return a grouping ([3, 0] is expected) for
the en_US locale (the rest of it looks OK).

However, there is still a bug in Lib/locale.py - the code currently
tries to allow for the possibility that an empty grouping may be
returned from localeconv() (and there must be some locales where this is
correct):

def _group(s):
    conv=localeconv()
    grouping=conv['grouping']
    if not grouping:return s

The code calling _group() assumes that the object returned will always
be a tuple, and hence the above will cause a traceback when localeconv()
returns an empty grouping. The correct code should be:

def _group(s):
    conv=localeconv()
    grouping=conv['grouping']
    if not grouping:return (s, 0)

test_locale will still fail on the SGI, but now because of a bug in the
platform implementation of the en_US locale, rather than a bug in the
Python locale.py code. It's better than a traceback.

BTW, mail to Martin doesn't seem to be getting through.

Guido van Rossum wrote:
> 
> > localeconv()['grouping'] is "[]" at this point...
> 
> It is looking like either the _locale.c module is not working right or
> the platform's implementation of the en_US locals is broken.  I'm
> afraid that only you will be able to make the determination. :-(
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From neal at metaslash.com  Mon Apr 16 16:42:24 2001
From: neal at metaslash.com (Neal Norwitz)
Date: Mon, 16 Apr 2001 10:42:24 -0400
Subject: [Python-Dev] Python 2.1 RC1 - PyCheckered Tools
Message-ID: <3ADB04D0.87576CE4@metaslash.com>

Here's the problems I found with PyChecker (http://pychecker.sourceforge.net)
against the Python 2.1 RC1 Tools.

Is there any reason that bgen source is Tools/bgen/bgen?

Neal
--

bgen/bgenOutput.py:87 No global (Error) found
bgen/bgenType.py:30 Invalid arguments to (getargsArgs), got 0, expected 1
bgen/bgenType.py:79 Invalid arguments to (mkvalueArgs), got 0, expected 1
bgen/scantools.py:402 No attribute (comment1) found
bgen/scantools.py:403 No attribute (comment1) found
bgen/scantools.py:404 No attribute (comment2) found
bgen/scantools.py:405 No attribute (comment2) found
bgen/scantools.py:406 No attribute (sym) found
bgen/scantools.py:409 No attribute (head) found
bgen/scantools.py:417 No attribute (sym) found
bgen/scantools.py:426 No attribute (tail) found
bgen/scantools.py:428 No attribute (comment1) found
bgen/scantools.py:429 No attribute (comment1) found
bgen/scantools.py:430 No attribute (comment2) found
bgen/scantools.py:431 No attribute (comment2) found
bgen/scantools.py:436 No attribute (whole) found
bgen/scantools.py:439 No attribute (whole) found
bgen/scantools.py:475 No attribute (asplit) found
bgen/scantools.py:478 No attribute (asplit) found
	(seems most names are xxx_pat, not xxx)

idle/BrowserControl.py:103 No global (_os) found
	(should be os)
idle/BrowserControl.py:149 No global (traceback) found
	(need to import)
idle/SearchDialogBase.py:34 No attribute (default_command) found
idle/SearchDialogBase.py:127 Local variable (f) not used
idle/UndoDelegator.py:29 No method (unbind) found
	(also at lines, 30, 31)
idle/UndoDelegator.py:34 No method (bind) found
	(also at lines, 35, 36)
idle/UndoDelegator.py:139 No method (bell) found
	(also at line 150)
idle/WidgetRedirector.py:33 No global (dict) found
	(should be self.dict)
idle/eventparse.py:1 Imported module (getopt) not used in any function

freeze/checkextensions_win32.py:62 No global (mapFileName) found
	(should be defaultMapName)
freeze/checkextensions_win32.py:121 No global (modules) found
	(should be module)
freeze/makeconfig.py:33 No global (sys) found
freeze/modulefinder.py:67 Local variable (i) not used
	(can do print "  " * self.indent, just a warning)

faqwiz/faqwiz.py:245 No attribute (last_changed_date) found
faqwiz/faqwiz.py:306 No attribute (last_changed_date) found
faqwiz/faqwiz.py:324 Local variable (okprog) not used
faqwiz/faqwiz.py:455 No global (constants) found

pynche/ListViewer.py:165 Local variable (height) not used
pynche/StripViewer.py:294 Local variable (tclcmd) not used
pynche/StripViewer.py:405 No attribute (_StripViewer__gentypevar) found
	(member commented out)
pynche/TextViewer.py:104 Local variable (val) not used

webchecker/webchecker.py:192 Function (load_pickle) uses named arguments



From fdrake at acm.org  Mon Apr 16 17:05:58 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 16 Apr 2001 11:05:58 -0400 (EDT)
Subject: [Python-Dev] Python 2.1 RC1 - PyCheckered Tools
In-Reply-To: <3ADB04D0.87576CE4@metaslash.com>
References: <3ADB04D0.87576CE4@metaslash.com>
Message-ID: <15067.2646.801856.69602@cj42289-a.reston1.va.home.com>

Neal Norwitz writes:
 > idle/BrowserControl.py:103 No global (_os) found
 > 	(should be os)
 > idle/BrowserControl.py:149 No global (traceback) found
 > 	(need to import)

  The BrowserControl module will be removed for the next release,
since IDLE prefers the webbrowser module, which was added to the
standard library as of Python 2.0.


  -Fred

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




From guido at digicool.com  Mon Apr 16 19:07:36 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 16 Apr 2001 12:07:36 -0500
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: Your message of "Mon, 16 Apr 2001 11:02:51 +0800."
             <3ADA60DB.25854811@per.dem.csiro.au> 
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com> <3AD9339F.44C7FC05@per.dem.csiro.au> <200104151348.IAA09108@cj20424-a.reston1.va.home.com>  
            <3ADA60DB.25854811@per.dem.csiro.au> 
Message-ID: <200104161707.MAA21086@cj20424-a.reston1.va.home.com>

> Yes, the SGI appears not to return a grouping ([3, 0] is expected) for
> the en_US locale (the rest of it looks OK).
> 
> However, there is still a bug in Lib/locale.py - the code currently
> tries to allow for the possibility that an empty grouping may be
> returned from localeconv() (and there must be some locales where this is
> correct):
> 
> def _group(s):
>     conv=localeconv()
>     grouping=conv['grouping']
>     if not grouping:return s
> 
> The code calling _group() assumes that the object returned will always
> be a tuple, and hence the above will cause a traceback when localeconv()
> returns an empty grouping. The correct code should be:
> 
> def _group(s):
>     conv=localeconv()
>     grouping=conv['grouping']
>     if not grouping:return (s, 0)
> 
> test_locale will still fail on the SGI, but now because of a bug in the
> platform implementation of the en_US locale, rather than a bug in the
> Python locale.py code. It's better than a traceback.

Thanks.  I've checked this in now.

> BTW, mail to Martin doesn't seem to be getting through.

I think it's his home machine, and I suspect he's taken a long weekend
off (Monday after Easter is a holiday in most European countries).

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



From neal at metaslash.com  Mon Apr 16 19:52:25 2001
From: neal at metaslash.com (Neal Norwitz)
Date: Mon, 16 Apr 2001 13:52:25 -0400
Subject: [Python-Dev] Python 2.1 RC1 - symtable.py problems
Message-ID: <3ADB3159.476A73CD@metaslash.com>

Sorry, I didn't get this in the first batch.  PyChecker crashed on symtable.py and I didn't fix it until now.

/home/neal/local/lib/python2.1/symtable.py:100 Invalid arguments to (bool), got 0, expected 1
/home/neal/local/lib/python2.1/symtable.py:193 No attribute (flag) found
	(should be __flags?)
/home/neal/local/lib/python2.1/symtable.py:196 No global (DEF_STARSTAR) found
	(should be DEF_DOUBLESTAR?)

Neal



From barry at digicool.com  Mon Apr 16 19:56:06 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Mon, 16 Apr 2001 13:56:06 -0400
Subject: [Python-Dev] Python 2.1 RC1 - PyCheckered Tools
References: <3ADB04D0.87576CE4@metaslash.com>
Message-ID: <15067.12854.219081.458580@anthem.wooz.org>

>>>>> "NN" == Neal Norwitz <neal at metaslash.com> writes:

    | pynche/ListViewer.py:165 Local variable (height) not used
    | pynche/StripViewer.py:294 Local variable (tclcmd) not used
    | pynche/StripViewer.py:405 No attribute (_StripViewer__gentypevar) found
    | 	(member commented out)
    | pynche/TextViewer.py:104 Local variable (val) not used

Thanks.  I've fixed these in my working copy but won't check them in
until Python 2.1 final is out the door.

-Barry



From loewis at informatik.hu-berlin.de  Tue Apr 17 10:34:34 2001
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Tue, 17 Apr 2001 10:34:34 +0200 (MEST)
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
Message-ID: <200104170834.KAA29092@pandora.informatik.hu-berlin.de>

> def _group(s):
>     conv=localeconv()
>     grouping=conv['grouping']
>     if not grouping:return (s, 0)

Yes, that change is right.

> BTW, mail to Martin doesn't seem to be getting through.

Unfortunately, cs.tu-berlin.de seems to have router problems :-(

Regards,
Martin



From guido at digicool.com  Tue Apr 17 16:29:44 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 09:29:44 -0500
Subject: [Python-Dev] ANNOUNCE: Python 2.1 final release
Message-ID: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>

Yes, the *final* release of Python 2.1 is now available.  Thanks again
for all who helped!  Go here for downloads and information:

    http://www.python.org/2.1/

As a reminder, here's a list of some of the big new features in 2.1
(news since 2.0 was released in October 2000):

- nested scopes and __future__ directives
- rich comparisons and new coercion model
- warnings framework
- new build process (Unix)
- weak references
- function attributes
- unittest and doctest modules for automated testing
- ports to several new platforms, including Cygwin and RISCOS

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



From guido at digicool.com  Tue Apr 17 17:51:16 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 10:51:16 -0500
Subject: [Python-Dev] Python 2.1.1 and 2.2 release planning
Message-ID: <200104171551.KAA28713@cj20424-a.reston1.va.home.com>

Now that 2.1 is out, I've created a CVS branch for the Python 2.1.1
bugfix release.  Its name is "release21-maint" (I had no choice in the
name, I'm mimicking the name that Moshe chose for the 2.0.1 branch).

Anything that should go into 2.1.1 ought to be checked into this
branch as well as into the trunk.  Let's tentatively shoot for a 2.1.1
release about a month for now.  This ought to be a very conservative
bugfix release; the key goal is stability of the 2.1 platform, not
releasing features that missed the 2.1 deadline.

Anything that smells of a feature or a new API (even if it is
introduced to fix a design bug!) ought to go into the trunk, where it
will be released as part of 2.2.  I am aiming for a 2.2 release in
October 2001.

In the future, I'd like to create a branch for each release (alpha,
beta or candidate).  These branches will branch of the trunk just
before the release is planned.  That way, instead of declaring a
checkin moratorium on the trunk, I can create a branch, and checkins
on the trunk won't bother me (or whoever is the release manager).

Thanks to all the last-minute bug reporters and fixers!

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



From neal at metaslash.com  Tue Apr 17 18:11:02 2001
From: neal at metaslash.com (Neal Norwitz)
Date: Tue, 17 Apr 2001 12:11:02 -0400
Subject: [Python-Dev] PyChecker 0.3 release
Message-ID: <3ADC6B16.8F90B777@metaslash.com>

I have released PyChecker 0.3 to SourceForge.
	Web Page:     http://pychecker.sourceforge.net/
	Project Page: http://sourceforge.net/projects/pychecker/

I'd like to thank everyone for all the feedback so far, it's been great!
In particular, Barry Scott has been very helpful.

The CHANGELOG and current command line options are included below.
The TODO list has gotten longer (see the web page or download).

As always, feedback, suggestions, complaints, etc are encouraged.

Neal
--

Here's the CHANGELOG:

Version 0.3     - 17 April 2001
  * Fix some checker crashes (oops)
  * Add warnings for code complexity (lines/branches/returns per func)
  * Add more configuration options
  * Don't produce spurious warning for:  x(y, { 'a': 'b' })
  * Fix warnings that indicate they are from a base class file,
    rather than real file
  * Fix warnings for **kwArgs not allowed, but using named args
  * Add config option for warning when using attribute as a function
        (off by default, old behaviour was on)

Version 0.2.5   - 12 April 2001
  * Add back support for Python 1.5.2 (again)
        (I sure like 2.0 more with the [ for ] and string methods.)
  * Add new warning for unused local variables
  * Add command line switches


Here's the current list of command line options:

Options:           Change warning for ... [default value]
  -s, --doc          turn off all warnings for no doc strings
  -m, --moduledoc    no module doc strings [on]
  -c, --classdoc     no class doc strings [on]
  -f, --funcdoc      no function/method doc strings [off]

  -i, --import       unused imports [on]
  -l, --local        unused local variables, except tuples [on]
  -t, --tuple        all unused local variables, including tuples [off]
  -v, --var          all unused module variables [off]
  -p, --privatevar   unused private module variables [on]
  -n, --namedargs    functions called with named arguments (like keywords) [on]
  -a, --initattr     Attributes (members) must be defined in __init__() [off]
  -I, --initsubclass Subclass.__init__() not defined [off]
  -A, --callattr     Calling data members as functions [off]

  -b, --blacklist    ignore warnings from the list of modules [['Tkinter']]
  -L, --maxlines     maximum lines in a function [200]
  -B, --maxbranches  maximum branches in a function [50]
  -R, --maxreturns   maximum returns in a function [10]

  -P, --printparse   print internal checker parse structures [off]
  -d, --debug        turn on debugging for checker [off]



From barry at digicool.com  Tue Apr 17 18:23:26 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 12:23:26 -0400
Subject: [Python-Dev] Python 2.1 PEPs
Message-ID: <15068.28158.342537.431634@anthem.wooz.org>

Now that Python 2.1 is officially out the door, it's time to do some
spring cleaning on the PEPs.  I'm currently processing the latest
batch of PEP requests, and I'm going to create a Python 2.2 release
schedule PEP.  It's time to make an update pass through PEP 0 too.

Here are the following PEPs that are marked as "Active for Python
2.1", along with a small commentary about changing their status.  PEP
authors, please take a close look at your Python 2.1 PEPs and make any
final revisions that are necessary.  Let me know if you disagree with
my proposed disposition of the PEP.  Note: individual PEP owners
should update their own PEPs; I will take care of noodging you and
updating PEP 0.  If you are unable to make commits to the PEPs, send
the updated text to me and I'll commit them.

 I    42  pep-0042.txt  Small Feature Requests                 Hylton

The perennial PEP, this will be moved to the "Python 2.2 Current"
category.  It should be updated if necessary.

 S   205  pep-0205.txt  Weak References                        Drake

Fred should do an update pass to reflect Python 2.1 Reality
(e.g. weakref.mapping()).  This PEP should then be marked as Final and
moved to the Finished PEPs category.

  I   226  pep-0226.txt  Python 2.1 Release Schedule            Hylton

This PEP should get a final pass (no need for "tentative"s any more!),
marked as Final and moved to the Finished category.

  S   227  pep-0227.txt  Statically Nested Scopes               Hylton

Jeremy, please make sure this is up-to-date w.r.t. Python 2.1 Reality,
then mark it as Final and I'll move it to the Finished category.

  S   229  pep-0229.txt  Using Distutils to Build Python        Kuchling

Andrew, same deal with this PEP...

  S   233  pep-0233.txt  Python Online Help                     Prescod

What is up with this PEP?  Progress on this seems to have stalled, so
I propose marking it "Deferred" and moving it out of the active PEP
category (to where, I'm not yet sure).

  S   235  pep-0235.txt  Import on Case-Insensitive Platforms   Peters

I think this one's done, so it should be marked as Final and moved to
the Finished PEPs category.  Tim should make any final edits
necessary.

  S   236  pep-0236.txt  Back to the __future__                 Peters

Same for this one, Tim...

  S   243  pep-0243.txt  Module Repository Upload Mechanism     Reifschneider

This isn't strictly tied to the Python 2.1 release, so I propose to
simply shuffle it over to the "Active for Python 2.2" category.

Cheers,
-Barry



From guido at digicool.com  Tue Apr 17 18:37:25 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 12:37:25 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 12:23:26 EDT."
             <15068.28158.342537.431634@anthem.wooz.org> 
References: <15068.28158.342537.431634@anthem.wooz.org> 
Message-ID: <200104171637.f3HGbPg32707@odiug.digicool.com>

>   I   226  pep-0226.txt  Python 2.1 Release Schedule            Hylton
> 
> This PEP should get a final pass (no need for "tentative"s any more!),
> marked as Final and moved to the Finished category.

Could we recycle this PEP number for the 2.1.1 release schedule (see
my previous post here)?  That seems easier than having a new PEP for
each micro-release.

>   S   227  pep-0227.txt  Statically Nested Scopes               Hylton
> 
> Jeremy, please make sure this is up-to-date w.r.t. Python 2.1 Reality,
> then mark it as Final and I'll move it to the Finished category.

I have promised Jeremy a bunch of updates to this.  I'll get on it.

>   S   229  pep-0229.txt  Using Distutils to Build Python        Kuchling
> 
> Andrew, same deal with this PEP...
> 
>   S   233  pep-0233.txt  Python Online Help                     Prescod
> 
> What is up with this PEP?  Progress on this seems to have stalled, so
> I propose marking it "Deferred" and moving it out of the active PEP
> category (to where, I'm not yet sure).

Superseded by pydoc, I imagine.  Working code beats ambitious plans
every time :-)

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



From paulp at ActiveState.com  Tue Apr 17 18:58:43 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 09:58:43 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
Message-ID: <3ADC7643.9AF12AB3@ActiveState.com>

"Barry A. Warsaw" wrote:
> 
>...
> 
>   S   233  pep-0233.txt  Python Online Help                     Prescod
> 
> What is up with this PEP?  Progress on this seems to have stalled, so
> I propose marking it "Deferred" and moving it out of the active PEP
> category (to where, I'm not yet sure).

Ping asked to take over the code because he wanted to do it with Pydoc.
He didn't do the online help part. I'm not sure if he thought I was
going to do that part or if he just didn't get to it. Either way, it is
less than a weekend's work to add pydoc to the interactive shell (and
thus make it "online help") so I can do it in the next few weeks.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From guido at digicool.com  Tue Apr 17 18:59:29 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 12:59:29 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 09:58:43 PDT."
             <3ADC7643.9AF12AB3@ActiveState.com> 
References: <15068.28158.342537.431634@anthem.wooz.org>  
            <3ADC7643.9AF12AB3@ActiveState.com> 
Message-ID: <200104171659.f3HGxTa00465@odiug.digicool.com>

> Ping asked to take over the code because he wanted to do it with Pydoc.
> He didn't do the online help part. I'm not sure if he thought I was
> going to do that part or if he just didn't get to it. Either way, it is
> less than a weekend's work to add pydoc to the interactive shell (and
> thus make it "online help") so I can do it in the next few weeks.

Actually, "from pydoc import help" already works; after that you can
type "help" or "help(module)" etc.  Or is "online help" more than
that?

Ping pointed out (in private email) that adding pydoc.help to
__builtin__ in site.py is the wrong thing to do because pydoc is large
and it would slow down startup too much.  He recommended to add a
small bootstrap function instead that imports and invokes pydoc.help
instead.

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



From barry at digicool.com  Tue Apr 17 19:06:18 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 13:06:18 -0400
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
	<200104171637.f3HGbPg32707@odiug.digicool.com>
Message-ID: <15068.30730.709186.27733@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

    GvR> Could we recycle this PEP number for the 2.1.1 release
    GvR> schedule (see my previous post here)?  That seems easier than
    GvR> having a new PEP for each micro-release.

PEP numbers are a plentiful resource!  I'd prefer to give it a new PEP
number.

    >> S 227 pep-0227.txt Statically Nested Scopes Hylton

    GvR> I have promised Jeremy a bunch of updates to this.  I'll get
    GvR> on it.

Excellent, thanks.

    GvR> Superseded by pydoc, I imagine.  Working code beats ambitious
    GvR> plans every time :-)

>>>>> "PP" == Paul Prescod <paulp at ActiveState.com> writes:

    PP> Ping asked to take over the code because he wanted to do it
    PP> with Pydoc.  He didn't do the online help part. I'm not sure
    PP> if he thought I was going to do that part or if he just didn't
    PP> get to it. Either way, it is less than a weekend's work to add
    PP> pydoc to the interactive shell (and thus make it "online
    PP> help") so I can do it in the next few weeks.

    GvR> Actually, "from pydoc import help" already works; after that
    GvR> you can type "help" or "help(module)" etc.  Or is "online
    GvR> help" more than that?

So Paul, what should be done about PEP 233?  Move it to "active for
Python 2.2"?

-Barry



From paulp at ActiveState.com  Tue Apr 17 19:28:15 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 10:28:15 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>  
	            <3ADC7643.9AF12AB3@ActiveState.com> <200104171659.f3HGxTa00465@odiug.digicool.com>
Message-ID: <3ADC7D2F.F0096D9F@ActiveState.com>

Guido van Rossum wrote:
> 
>...
> 
> Actually, "from pydoc import help" already works; after that you can
> type "help" or "help(module)" etc.  Or is "online help" more than
> that?

No, that looks like it is basically what you want. I didn't envision
help as a totally separate "mode" but I'm not picky.

> Ping pointed out (in private email) that adding pydoc.help to
> __builtin__ in site.py is the wrong thing to do because pydoc is large
> and it would slow down startup too much.  He recommended to add a
> small bootstrap function instead that imports and invokes pydoc.help
> instead.

Right, but the bootstrap was always part of the proposal! Now that
you've pointed out the impressive online help facility in pydoc it seems
that the only thing we need to make it exactly what I envisioned is a
few lines of code. I'm sorry I didn't figure that out last week!

All it would take now is

class help:
   def __repr__(self):
      import pydoc
      __builtins__.help = pydoc.help
      repr(__builtins__.help)

But hindsight is 20/20.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From thomas at xs4all.net  Tue Apr 17 19:50:41 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Tue, 17 Apr 2001 19:50:41 +0200
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <3ADC7D2F.F0096D9F@ActiveState.com>; from paulp@ActiveState.com on Tue, Apr 17, 2001 at 10:28:15AM -0700
References: <15068.28158.342537.431634@anthem.wooz.org> <3ADC7643.9AF12AB3@ActiveState.com> <200104171659.f3HGxTa00465@odiug.digicool.com> <3ADC7D2F.F0096D9F@ActiveState.com>
Message-ID: <20010417195041.T2820@xs4all.nl>

On Tue, Apr 17, 2001 at 10:28:15AM -0700, Paul Prescod wrote:

> All it would take now is
> 
> class help:
>    def __repr__(self):
>       import pydoc
>       __builtins__.help = pydoc.help
>       repr(__builtins__.help)

> But hindsight is 20/20.

You realize this isn't going to work, right ? The 'help' class will shadow
the 'help' builtin.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From paulp at ActiveState.com  Tue Apr 17 20:33:56 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 11:33:56 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
		<200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org>
Message-ID: <3ADC8C94.548514E3@ActiveState.com>

"Barry A. Warsaw" wrote:
> 
> 
> So Paul, what should be done about PEP 233?  Move it to "active for
> Python 2.2"?

Move it to "implemented." We can haggle about details but most of the
features I'd hoped for are implemented thanks to Ping!

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From ping at lfw.org  Tue Apr 17 21:13:36 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 17 Apr 2001 12:13:36 -0700 (PDT)
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <3ADC7D2F.F0096D9F@ActiveState.com>
Message-ID: <Pine.LNX.4.10.10104171207230.454-100000@skuld.kingmanhall.org>

On Tue, 17 Apr 2001, Paul Prescod wrote:
> Right, but the bootstrap was always part of the proposal!

Right.

> All it would take now is
> 
> class help:
>    def __repr__(self):
>       import pydoc
>       __builtins__.help = pydoc.help
>       repr(__builtins__.help)

Yes, pretty much.  I suggested something to that effect on Friday
night.  (Guido decided it was too late in the game to change site.py
at that point.)  Here was my proposed addition to site.py:

    # Define the built-in object "help" to provide interactive help.
    class Helper:
        def __repr__(self):
            import inspect
            if inspect.stack()[1][3] == '?': # not called from a function
                self()
                return ''
            return '<Helper instance>'
        def __call__(self, arg=None):
            import pydoc
            pydoc.help(arg)
    __builtin__.help = Helper()

Why the strange check involving inspect.stack()?
inspect.stack()[1][3] is the co_name of the parent frame.
If we check that the __repr__ is not being requested by a
function call, everything works perfectly in IDLE as well
as the plain interpreter, and the helper object is still safe
to pass around.  Nothing breaks even if you say help(help).

The above few lines are a reasonable addition to sitecustomize.py
if you happen to be setting up a local installation of Python.


-- ?!ng

"If I have seen farther than others, it is because I was standing on a
really big heap of midgets."
    -- K. Eric Drexler







From paulp at ActiveState.com  Tue Apr 17 20:58:42 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Tue, 17 Apr 2001 11:58:42 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org> <3ADC7643.9AF12AB3@ActiveState.com> <200104171659.f3HGxTa00465@odiug.digicool.com> <3ADC7D2F.F0096D9F@ActiveState.com> <20010417195041.T2820@xs4all.nl>
Message-ID: <3ADC9262.928F1398@ActiveState.com>

Thomas Wouters wrote:
> 
> On Tue, Apr 17, 2001 at 10:28:15AM -0700, Paul Prescod wrote:
> 
> > All it would take now is
> >
> > class help:
> >    def __repr__(self):
> >       import pydoc
> >       __builtins__.help = pydoc.help
> >       repr(__builtins__.help)
> 
> > But hindsight is 20/20.
> 
> You realize this isn't going to work, right ? The 'help' class will shadow
> the 'help' builtin.

We do not have to call the class "help" nor to define it in the __main__
or __builtins__ context. Or were you getting at something deeper?

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From Jason.Tishler at dothill.com  Tue Apr 17 21:12:19 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Tue, 17 Apr 2001 15:12:19 -0400
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 17, 2001 at 09:29:44AM -0500
References: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>
Message-ID: <20010417151219.T275@dothill.com>

On Tue, Apr 17, 2001 at 09:29:44AM -0500, Guido van Rossum wrote:
> - ports to several new platforms, including Cygwin and RISCOS

I have contributed Python to the standard Cygwin distribution.  Cygwin
Python is located in the contrib/python directory on the Cygwin mirrors.
Cygwin's setup.exe will automatically install Cygwin Python the next
time one installs or updates from a mirror.

If interested, see the following for a copy of the announcement:

    http://www.cygwin.com/ml/cygwin/2001-04/msg01074.html

I kindly request that people post to python-list at python.org or
cygwin at sources.redhat.com as appropriate instead of emailing me
directly.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From dubois1 at llnl.gov  Tue Apr 17 21:05:25 2001
From: dubois1 at llnl.gov (Paul F. Dubois)
Date: Tue, 17 Apr 2001 12:05:25 -0700
Subject: [Python-Dev] PEP 0242 Numeric kinds updated
Message-ID: <01041712272103.11576@almanac>

I have updated the text of PEP 0242 about Numeric kinds. This proposal is now
complete and a reference implementation has been created. 

See http://python.sourceforge.net/peps/pep-0242.html

As part of this reference implementation I was considering adding a 32-bit
float scalar floating-point object to the kinds module. This object would then
be accessible via the kinds module although there would be no corresponding
literal notation. For example:

import kinds
f loat32= kinds.float_kind(5,30)
x = float32(3.14159)

would on all platforms I know about create x as such an object, which may be of
interest to those attempting to conserve space in certain applications of
Numeric.

Comments on the PEP and this point are requested.





From martin at loewis.home.cs.tu-berlin.de  Tue Apr 17 21:27:13 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 17 Apr 2001 21:27:13 +0200
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: <200104150157.UAA31334@cj20424-a.reston1.va.home.com> (message
	from Guido van Rossum on Sat, 14 Apr 2001 20:57:00 -0500)
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling>  
            <E14oEOc-0001si-00@darjeeling> <200104150157.UAA31334@cj20424-a.reston1.va.home.com>
Message-ID: <200104171927.f3HJRDP01133@mira.informatik.hu-berlin.de>

> And indeed it does when I tried it on SF's Solaris 8 box, which has
> OpenSSL installed and /dev/random.

This has caused Moshe's curiosity, and mine, as Solaris 8,
out-of-the-box, does not offer a /dev/random. I found two options:
There is a third-party patch:

http://www.cosy.sbg.ac.at/~andi/

which apparently works for all Solaris versions out there.

There is also a Sun patch, 105710-01, which supposedly uses a
user-space demon (just as EGD), see

http://devrandom.net/lists/archives/2000/11/OpenSSL-Users/0244.html

As explained, this is part of the SUNWski package.

Are you using one of these methods, or is there another option for
getting a 'true' /dev/random?

Regards,
Martin



From martin at loewis.home.cs.tu-berlin.de  Tue Apr 17 21:29:28 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 17 Apr 2001 21:29:28 +0200
Subject: [Python-Dev] 2.1c1 "make test" failures on SGI Irix
In-Reply-To: <200104150633.BAA02770@cj20424-a.reston1.va.home.com> (message
	from Guido van Rossum on Sun, 15 Apr 2001 01:33:25 -0500)
References: <3AD92E7B.E6CC7EE7@per.dem.csiro.au> <200104150633.BAA02770@cj20424-a.reston1.va.home.com>
Message-ID: <200104171929.f3HJTSi01162@mira.informatik.hu-berlin.de>

> I'm not sure what the intention was...
> 
> Martin, can you suggest a way out here?

In addition to the patch that already was applied, the test case can
be made more robust, by checking whether the en_US locale has the
right grouping value (and either fail or accept different results if
it doesn't).

Regards,
Martin



From guido at digicool.com  Wed Apr 18 00:14:27 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:14:27 -0500
Subject: [Python-Dev] Re: Problem with SSL and socketmodule on Debian Potato?
In-Reply-To: Your message of "Tue, 17 Apr 2001 21:27:13 +0200."
             <200104171927.f3HJRDP01133@mira.informatik.hu-berlin.de> 
References: <200104131733.f3DHXQG30886@mira.informatik.hu-berlin.de>, <200104131614.f3DGER730511@mira.informatik.hu-berlin.de>, <200104131529.f3DFTN629541@mira.informatik.hu-berlin.de> <200104131639.LAA31088@cj20424-a.reston1.va.home.com> <E14o6JO-0001EI-00@darjeeling> <E14oEOc-0001si-00@darjeeling> <200104150157.UAA31334@cj20424-a.reston1.va.home.com>  
            <200104171927.f3HJRDP01133@mira.informatik.hu-berlin.de> 
Message-ID: <200104172214.RAA29373@cj20424-a.reston1.va.home.com>

[I wrote]
> > And indeed it does when I tried it on SF's Solaris 8 box, which has
> > OpenSSL installed and /dev/random.

[Martin replied]
> This has caused Moshe's curiosity, and mine, as Solaris 8,
> out-of-the-box, does not offer a /dev/random. I found two options:
> There is a third-party patch:
> 
> http://www.cosy.sbg.ac.at/~andi/
> 
> which apparently works for all Solaris versions out there.
> 
> There is also a Sun patch, 105710-01, which supposedly uses a
> user-space demon (just as EGD), see
> 
> http://devrandom.net/lists/archives/2000/11/OpenSSL-Users/0244.html
> 
> As explained, this is part of the SUNWski package.
> 
> Are you using one of these methods, or is there another option for
> getting a 'true' /dev/random?

Sorry, I must've confused myself.  I was logged in on several
different SF CF hosts, and now I can't find a /dev/random on its
Solaris host, so I presume that it was never there and that I saw it
on one of the other hosts there.

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



From guido at digicool.com  Wed Apr 18 00:17:45 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:17:45 -0500
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: Your message of "Tue, 17 Apr 2001 15:12:19 -0400."
             <20010417151219.T275@dothill.com> 
References: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>  
            <20010417151219.T275@dothill.com> 
Message-ID: <200104172217.RAA29433@cj20424-a.reston1.va.home.com>

> I have contributed Python to the standard Cygwin distribution.  Cygwin
> Python is located in the contrib/python directory on the Cygwin mirrors.
> Cygwin's setup.exe will automatically install Cygwin Python the next
> time one installs or updates from a mirror.
> 
> If interested, see the following for a copy of the announcement:
> 
>     http://www.cygwin.com/ml/cygwin/2001-04/msg01074.html

Thanks, Jason!!!  Your efforts are much appreciated.  Keep up the good
work!

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



From guido at digicool.com  Wed Apr 18 00:20:26 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:20:26 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 12:13:36 MST."
             <Pine.LNX.4.10.10104171207230.454-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10104171207230.454-100000@skuld.kingmanhall.org> 
Message-ID: <200104172220.RAA29454@cj20424-a.reston1.va.home.com>

> Why the strange check involving inspect.stack()?
> inspect.stack()[1][3] is the co_name of the parent frame.
> If we check that the __repr__ is not being requested by a
> function call, everything works perfectly in IDLE as well
> as the plain interpreter, and the helper object is still safe
> to pass around.  Nothing breaks even if you say help(help).

This is one of the reasons why I didn't want to add this to the 2.1
release at such a late point.  I have no easy way to verify that this
is always true, and in fact I have no idea what inspect.stack()[1][3]
means. :-(

I just add "from pydoc import help" to my $PYTHONSTARTUP file.

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



From guido at digicool.com  Wed Apr 18 00:23:20 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 17:23:20 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 13:06:18 -0400."
             <15068.30730.709186.27733@anthem.wooz.org> 
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com>  
            <15068.30730.709186.27733@anthem.wooz.org> 
Message-ID: <200104172223.RAA29490@cj20424-a.reston1.va.home.com>

>     GvR> Could we recycle this PEP number for the 2.1.1 release
>     GvR> schedule (see my previous post here)?  That seems easier than
>     GvR> having a new PEP for each micro-release.
> 
> PEP numbers are a plentiful resource!  I'd prefer to give it a new PEP
> number.

One day I'm going to argue that anything limited to 4 digits can't
possibly be called "plentiful", but not this millennium. :-)

I didn't mean to save a PEP number -- I just meant to keep the 2.1
followup releases together.  I explained this to Barry over lunch and
he agrees now.

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



From barry at digicool.com  Wed Apr 18 00:16:08 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 18:16:08 -0400
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
	<200104171637.f3HGbPg32707@odiug.digicool.com>
	<15068.30730.709186.27733@anthem.wooz.org>
	<200104172223.RAA29490@cj20424-a.reston1.va.home.com>
Message-ID: <15068.49320.780995.520582@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

    GvR> One day I'm going to argue that anything limited to 4 digits
    GvR> can't possibly be called "plentiful", but not this
    GvR> millennium. :-)

Just as plentiful as 32-bit IP addresses, oil reserves, and 640KB of
main memory... oh wait. :)

    GvR> I didn't mean to save a PEP number -- I just meant to keep
    GvR> the 2.1 followup releases together.  I explained this to
    GvR> Barry over lunch and he agrees now.

Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
PEP 226.

-Barry



From barry at digicool.com  Wed Apr 18 00:17:34 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Tue, 17 Apr 2001 18:17:34 -0400
Subject: [Python-Dev] Python 2.1 PEPs
References: <15068.28158.342537.431634@anthem.wooz.org>
	<200104171637.f3HGbPg32707@odiug.digicool.com>
	<15068.30730.709186.27733@anthem.wooz.org>
	<3ADC8C94.548514E3@ActiveState.com>
Message-ID: <15068.49406.441111.15203@anthem.wooz.org>

>>>>> "PP" == Paul Prescod <paulp at ActiveState.com> writes:

    >>   So Paul, what should be done about PEP 233?  Move it to
    >> "active for Python 2.2"?

    PP> Move it to "implemented." We can haggle about details but most
    PP> of the features I'd hoped for are implemented thanks to Ping!

Can you please update the text of PEP 233 to reflect Current (or
near-Current) Reality?

Thanks,
-Barry



From guido at digicool.com  Wed Apr 18 01:49:07 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 18:49:07 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 18:16:08 -0400."
             <15068.49320.780995.520582@anthem.wooz.org> 
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org> <200104172223.RAA29490@cj20424-a.reston1.va.home.com>  
            <15068.49320.780995.520582@anthem.wooz.org> 
Message-ID: <200104172349.SAA00877@cj20424-a.reston1.va.home.com>

>     GvR> I didn't mean to save a PEP number -- I just meant to keep
>     GvR> the 2.1 followup releases together.  I explained this to
>     GvR> Barry over lunch and he agrees now.
> 
> Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
> PEP 226.

OK.  So we need a 2.2.1 Czar.  Any volunteers?

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



From jafo at tummy.com  Wed Apr 18 04:03:52 2001
From: jafo at tummy.com (Sean Reifschneider)
Date: Tue, 17 Apr 2001 20:03:52 -0600
Subject: [Python-Dev] Re: ANNOUNCE: Python 2.1 final release
In-Reply-To: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 17, 2001 at 09:29:44AM -0500
References: <200104171429.JAA23792@cj20424-a.reston1.va.home.com>
Message-ID: <20010417200352.A28871@tummy.com>

On Tue, Apr 17, 2001 at 09:29:44AM -0500, Guido van Rossum wrote:
>Yes, the *final* release of Python 2.1 is now available.  Thanks again

I've updated my set of RPMs against 2.1.  I've similarly upgraded my 2.1
beta announcement to 2.1 final, and am including it below.  Changes in this
version are:

   Upgrade to 2.1 final.
   Binary and package name is "python2" by default.  Comment out the first
         (non-comment) line of the .spec file to build "python".
   Fixes the path to python2 in pydoc based on the above.
   Uses "--with-pymalloc" when configuring.
   Included Tony Seward's patch to fix the expat module's header path.
   Split out devel and tkinter packages.

Enjoy,
Sean
======================
Shy of RPMs because of library or other dependancy problems with most of
the RPMs you pick up?  The cure, in my experience is to pick up an SRPM.
All you need to do to build a binary package tailored to your system is run
"rpm --rebuild <packagename>.src.rpm".

The Source RPM and binaries for RedHat and KRUD 7.0 are at:

   ftp://ftp.tummy.com/pub/tummy/RPMS/SRPMS/python2-2.1-1tummy.src.rpm

   ftp://ftp.tummy.com/pub/tummy/RPMS/binaries-KRUD-7.0-i386/

You'll also need the following to build the SRPMSs:

   ftp://ftp.tummy.com/pub/tummy/RPMS/SRPMS/expat-1.1-3tummy.src.rpm

(Note, KRUD is our RedHat-based distribution with all errata applied.
Binaries should work on a stock RedHat 7.0 system, particularly if you have
the errata applied).

Again, this one builds the executable as "python2", and can be installed
along-side your normal Python on the system.  Want to check out a great new
feature?  Type "pydoc string" or "pydoc -g" from your shell.

Download the SRPM from above, and most users can install a binary built
against exactly the set of packages on their system by doing:

   rpm --rebuild expat-1.1-3tummy.src.rpm
   rpm -i /usr/src/redhat/RPMS/i386/expat*-1.1-3tummy.i386.rpm
   rpm --rebuild python-2.1b2-1tummy.src.rpm
   rpm -i /usr/src/redhat/RPMS/i386/python*2.1b1-1tummy.i386.rpm

Enjoy,
Sean
-- 
 The structure of a system reflects the structure of the organization that
 built it.  -- Richard E. Fairley
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python



From ping at lfw.org  Wed Apr 18 01:04:53 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 17 Apr 2001 16:04:53 -0700 (PDT)
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <200104172220.RAA29454@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org>

On Tue, 17 Apr 2001, Guido van Rossum wrote:
> This is one of the reasons why I didn't want to add this to the 2.1
> release at such a late point.  I have no easy way to verify that this
> is always true, and in fact I have no idea what inspect.stack()[1][3]
> means. :-(

Would you have preferred to write

    sys._getframe().f_back.f_code.co_name

?  It's the same thing.


-- ?!ng

"If I have seen farther than others, it is because I was standing on a
really big heap of midgets."
    -- K. Eric Drexler




From guido at digicool.com  Wed Apr 18 08:01:57 2001
From: guido at digicool.com (Guido van Rossum)
Date: Wed, 18 Apr 2001 01:01:57 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Tue, 17 Apr 2001 16:04:53 MST."
             <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org> 
Message-ID: <200104180601.BAA13715@cj20424-a.reston1.va.home.com>

> On Tue, 17 Apr 2001, Guido van Rossum wrote:
> > This is one of the reasons why I didn't want to add this to the 2.1
> > release at such a late point.  I have no easy way to verify that this
> > is always true, and in fact I have no idea what inspect.stack()[1][3]
> > means. :-(
> 
> Would you have preferred to write
> 
>     sys._getframe().f_back.f_code.co_name
> 
> ?  It's the same thing.

Well, that clears up one mystery.  The rest of your explanation of why
this is correct (as opposed to why this works in the two cases you've
tried :-) is still completely opaque to me...

>     # Define the built-in object "help" to provide interactive help.
>     class Helper:
>         def __repr__(self):
>             import inspect
>             if inspect.stack()[1][3] == '?': # not called from a function
>                 self()
>                 return ''
>             return '<Helper instance>'
>         def __call__(self, arg=None):
>             import pydoc
>             pydoc.help(arg)
>     __builtin__.help = Helper()
> 
> Why the strange check involving inspect.stack()?
> inspect.stack()[1][3] is the co_name of the parent frame.
> If we check that the __repr__ is not being requested by a
> function call, everything works perfectly in IDLE as well
> as the plain interpreter, and the helper object is still safe
> to pass around.  Nothing breaks even if you say help(help).

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



From tim.one at home.com  Wed Apr 18 10:55:34 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 18 Apr 2001 04:55:34 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <200104172223.RAA29490@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEPGJMAA.tim.one@home.com>

[Guido]
> ...
> I didn't mean to save a PEP number -- I just meant to keep the 2.1
> followup releases together.  I explained this to Barry over lunch and
> he agrees now.

I added a "[bugfix release dates go here]" marker to PEP 226 to remind him
<wink>.  Jeremy (he's still listed as the author) may want to clear out the
"Open issues for Python 2.0 beta 2" section.




From thomas at xs4all.net  Wed Apr 18 11:56:21 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 18 Apr 2001 11:56:21 +0200
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <200104172349.SAA00877@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Tue, Apr 17, 2001 at 06:49:07PM -0500
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org> <200104172223.RAA29490@cj20424-a.reston1.va.home.com> <15068.49320.780995.520582@anthem.wooz.org> <200104172349.SAA00877@cj20424-a.reston1.va.home.com>
Message-ID: <20010418115621.U2820@xs4all.nl>

On Tue, Apr 17, 2001 at 06:49:07PM -0500, Guido van Rossum wrote:
> >     GvR> I didn't mean to save a PEP number -- I just meant to keep
> >     GvR> the 2.1 followup releases together.  I explained this to
> >     GvR> Barry over lunch and he agrees now.
> > 
> > Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
> > PEP 226.

> OK.  So we need a 2.2.1 Czar.  Any volunteers?

I assume you mean a 2.1.x Czar :) I'm willing to do it, given that it
doesn't require much attention *now* (except checking the checkin messages,
which I do anyway) and I fully expect to be able to free all the time I need
in a few weeks anyway. But I'm perfectly happy with Moshe or someone else
doing it, too.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From tim.one at home.com  Wed Apr 18 12:14:33 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 18 Apr 2001 06:14:33 -0400
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <15068.28158.342537.431634@anthem.wooz.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEPLJMAA.tim.one@home.com>

>   S   236  pep-0236.txt  Back to the __future__                 Peters
>
> Same for this one, Tim...

Part of the initial text in this should (as PEP 236 itself says) move into
PEP 5, but other than that it reflects 2.1's reality.  PEP 5 is Paul's.
Happy to move stuff into PEP 5 for him, but the instant I do that you just
*know* Guido will force me to change all sorts of things in PEP 5 that Paul
would vehemently disown <wink>.




From paulp at ActiveState.com  Wed Apr 18 12:35:22 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Wed, 18 Apr 2001 03:35:22 -0700
Subject: [Python-Dev] Python 2.1 PEPs
References: <LNBBLJKPBEHFEDALKOLCGEPLJMAA.tim.one@home.com>
Message-ID: <3ADD6DEA.9FEED09A@ActiveState.com>

Tim Peters wrote:
> 
> >   S   236  pep-0236.txt  Back to the __future__                 Peters
> >
> > Same for this one, Tim...
> 
> Part of the initial text in this should (as PEP 236 itself says) move into
> PEP 5, but other than that it reflects 2.1's reality.  PEP 5 is Paul's.
> Happy to move stuff into PEP 5 for him, but the instant I do that you just
> *know* Guido will force me to change all sorts of things in PEP 5 that Paul
> would vehemently disown <wink>.

If you want to work out a clear status for PEP 5's process, you're
welcome to take it over!
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From guido at digicool.com  Tue Apr 17 16:29:44 2001
From: guido at digicool.com (Guido van Rossum)
Date: Tue, 17 Apr 2001 09:29:44 -0500
Subject: [Python-Dev] ANNOUNCE: Python 2.1 final release
Message-ID: <mailman.987518161.9928.clpa-moderators@python.org>

Yes, the *final* release of Python 2.1 is now available.  Thanks again
for all who helped!  Go here for downloads and information:

    http://www.python.org/2.1/

As a reminder, here's a list of some of the big new features in 2.1
(news since 2.0 was released in October 2000):

- nested scopes and __future__ directives
- rich comparisons and new coercion model
- warnings framework
- new build process (Unix)
- weak references
- function attributes
- unittest and doctest modules for automated testing
- ports to several new platforms, including Cygwin and RISCOS

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




From guido at digicool.com  Wed Apr 18 17:04:15 2001
From: guido at digicool.com (Guido van Rossum)
Date: Wed, 18 Apr 2001 10:04:15 -0500
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: Your message of "Wed, 18 Apr 2001 11:56:21 +0200."
             <20010418115621.U2820@xs4all.nl> 
References: <15068.28158.342537.431634@anthem.wooz.org> <200104171637.f3HGbPg32707@odiug.digicool.com> <15068.30730.709186.27733@anthem.wooz.org> <200104172223.RAA29490@cj20424-a.reston1.va.home.com> <15068.49320.780995.520582@anthem.wooz.org> <200104172349.SAA00877@cj20424-a.reston1.va.home.com>  
            <20010418115621.U2820@xs4all.nl> 
Message-ID: <200104181504.KAA15504@cj20424-a.reston1.va.home.com>

> > > Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to
> > > PEP 226.
> 
> > OK.  So we need a 2.2.1 Czar.  Any volunteers?
> 
> I assume you mean a 2.1.x Czar :)

Yes. :-)

> I'm willing to do it, given that it
> doesn't require much attention *now* (except checking the checkin messages,
> which I do anyway) and I fully expect to be able to free all the time I need
> in a few weeks anyway. But I'm perfectly happy with Moshe or someone else
> doing it, too.

Excellent.  I'd say let's divide labor here -- piling it all on Moshe
isn't fair.  You & Moshe can have a race who gets the first bugfix
release out! :-)

PEP 226 is all yours!

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



From jeremy at digicool.com  Wed Apr 18 16:07:31 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Wed, 18 Apr 2001 10:07:31 -0400 (EDT)
Subject: [Python-Dev] Python 2.1 PEPs
In-Reply-To: <Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org>
References: <200104172220.RAA29454@cj20424-a.reston1.va.home.com>
	<Pine.LNX.4.10.10104171603350.454-100000@skuld.kingmanhall.org>
Message-ID: <15069.40867.126819.564289@slothrop.digicool.com>

>>>>> "KPY" == Ka-Ping Yee <ping at lfw.org> writes:

  KPY> On Tue, 17 Apr 2001, Guido van Rossum wrote:
  >> This is one of the reasons why I didn't want to add this to the
  >> 2.1 release at such a late point.  I have no easy way to verify
  >> that this is always true, and in fact I have no idea what
  >> inspect.stack()[1][3] means. :-(

  KPY> Would you have preferred to write

  KPY>     sys._getframe().f_back.f_code.co_name

  KPY> ?  It's the same thing.

It's certainly clearer that inspect.stack()[1][3].  Does the existence
of the inspect module imply that we need to maintain its interface?
If we did, then we have some weird limits on the order of things in
stack frames.

Jeremy




From thomas.heller at ion-tof.com  Wed Apr 18 17:32:58 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 17:32:58 +0200
Subject: [Python-Dev] buffer interface (again)
Message-ID: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>

I would like to use (again) the buffer interface,
and I have some suggestions/questions.

- Only extension types can implement the buffer interface,
no way for a python class. Maybe a magic method __buffer__(self)
could be invented for this purpose?

- Why does the builtin function buffer() always return
readonly buffers, even for read/write objects? Shouldn't
there also be a readwrite_buffer() function, or should
buffer() return read/write buffers for read/write objects?

- My bug report 216405 on sourceforge is still open
(well, it is marked as closed, but it went into PEP 42)
http://sourceforge.net/tracker/index.php?func=detail&aid=216405&group_id=5470&atid=105470

Regards,

Thomas




From guido at digicool.com  Wed Apr 18 18:45:49 2001
From: guido at digicool.com (Guido van Rossum)
Date: Wed, 18 Apr 2001 11:45:49 -0500
Subject: [Python-Dev] buffer interface (again)
In-Reply-To: Your message of "Wed, 18 Apr 2001 17:32:58 +0200."
             <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook> 
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook> 
Message-ID: <200104181645.LAA16566@cj20424-a.reston1.va.home.com>

> I would like to use (again) the buffer interface,
> and I have some suggestions/questions.
> 
> - Only extension types can implement the buffer interface,
> no way for a python class. Maybe a magic method __buffer__(self)
> could be invented for this purpose?

How could it be made safe?  The buffer interface makes raw memory
addresses available.  Letting a Python class decide on what addresses
to use opens a big hole for abuse.

> - Why does the builtin function buffer() always return
> readonly buffers, even for read/write objects? Shouldn't
> there also be a readwrite_buffer() function, or should
> buffer() return read/write buffers for read/write objects?

It's a lifetime issue.  You can hold on to the object returned by
buffer() long after the actual memory it points to is recycled for
some other purpose, and while *reading* that memory is not such a big
deal (assuming it is still part of your address space, you'll just get
garbage), allowing it to be *written* is again an invitation to
disaster.

> - My bug report 216405 on sourceforge is still open
> (well, it is marked as closed, but it went into PEP 42)
> http://sourceforge.net/tracker/index.php?func=detail&aid=216405&group_id=5470&atid=105470

I still feel that your bug report is based on the wrong assumption
about what the buffer API should do.

Thomas, please first explain what you want to *do* with the buffer
interface.  Some of the buffer API was a mistake.  It *appears* to be
an interface for allocating and managing buffers, while in actuality
it is only intended to provide access to buffered data that is managed
by some C code.  You're probably better off using the array module to
manage buffers.

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



From thomas.heller at ion-tof.com  Wed Apr 18 17:49:55 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 17:49:55 +0200
Subject: [Python-Dev] Case sensitive import on windows
Message-ID: <03ac01c0c81f$36e45950$e000a8c0@thomasnotebook>

I tried to find out what had changed between 2.0 and 2.1.
Consider the following files in the current directory:

Spam.py
spam/__init__.py

Using python 2.0:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: Case mismatch for module name Spam
(filename spam)
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>

Using python 2.1:

Python 2.1c2 (#14, Apr 15 2001, 21:29:05) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: NULL result without error in call_object
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>

Seems like a bug to me...

Thomas




From thomas.heller at ion-tof.com  Wed Apr 18 18:06:12 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 18:06:12 +0200
Subject: [Python-Dev] buffer interface (again)
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>  <200104181645.LAA16566@cj20424-a.reston1.va.home.com>
Message-ID: <03d101c0c821$7d13cee0$e000a8c0@thomasnotebook>

[no need to cc me directly]
> > I would like to use (again) the buffer interface,
> > and I have some suggestions/questions.
> > 
> > - Only extension types can implement the buffer interface,
> > no way for a python class. Maybe a magic method __buffer__(self)
> > could be invented for this purpose?
> 
> How could it be made safe?  The buffer interface makes raw memory
> addresses available.  Letting a Python class decide on what addresses
> to use opens a big hole for abuse.
class C:
    ...
    def __buffer__(self):
        # self.my_buffer is an object exposing the buffer interface
        return buffer(self.my_buffer)
or:
        return self.my_buffer
> 
> > - Why does the builtin function buffer() always return
> > readonly buffers, even for read/write objects? Shouldn't
> > there also be a readwrite_buffer() function, or should
> > buffer() return read/write buffers for read/write objects?
> 
> It's a lifetime issue.  You can hold on to the object returned by
> buffer() long after the actual memory it points to is recycled for
> some other purpose, and while *reading* that memory is not such a big
> deal (assuming it is still part of your address space, you'll just get
> garbage), allowing it to be *written* is again an invitation to
> disaster.
Lifetimes are managed by refcounts, so it's a refcount issue,
at least as long as every object exposing the buffer interface
_guarantees_ that the memory address and size does not change.
(Which does not seem the case for array objects).

> 
> > - My bug report 216405 on sourceforge is still open
> > (well, it is marked as closed, but it went into PEP 42)
> > http://sourceforge.net/tracker/index.php?func=detail&aid=216405&group_id=5470&atid=105470
> 
> I still feel that your bug report is based on the wrong assumption
> about what the buffer API should do.
I only tried to fix the refcount issue.

> 
> Thomas, please first explain what you want to *do* with the buffer
> interface.  Some of the buffer API was a mistake.  It *appears* to be
> an interface for allocating and managing buffers, while in actuality
> it is only intended to provide access to buffered data that is managed
> by some C code.  You're probably better off using the array module to
> manage buffers.

I want to expose memory blocks to C, wrapped in python objects/classes.
These memory blocks could come from builtin python types: strings,
unicode strings, array objects, mmap'd files, ...

Thomas




From Barrett at stsci.edu  Wed Apr 18 17:22:12 2001
From: Barrett at stsci.edu (Paul Barrett)
Date: Wed, 18 Apr 2001 11:22:12 -0400
Subject: [Python-Dev] buffer interface (again)
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>  <200104181645.LAA16566@cj20424-a.reston1.va.home.com> <03d101c0c821$7d13cee0$e000a8c0@thomasnotebook>
Message-ID: <3ADDB124.A34D3D45@STScI.Edu>

Thomas Heller wrote:
> 
> Lifetimes are managed by refcounts, so it's a refcount issue,
> at least as long as every object exposing the buffer interface
> _guarantees_ that the memory address and size does not change.
> (Which does not seem the case for array objects).
> 
> >
> > Thomas, please first explain what you want to *do* with the buffer
> > interface.  Some of the buffer API was a mistake.  It *appears* to be
> > an interface for allocating and managing buffers, while in actuality
> > it is only intended to provide access to buffered data that is managed
> > by some C code.  You're probably better off using the array module to
> > manage buffers.
> 
> I want to expose memory blocks to C, wrapped in python objects/classes.
> These memory blocks could come from builtin python types: strings,
> unicode strings, array objects, mmap'd files, ...

If you are talking about a memory object, then I'm in agreement with
you, Thomas.

I'd like to see a memory object that allocates and deallocates blocks
of memory and exports a pointer to its memory.  It could also set
privileges such are read/write, etc.  Its interface would be
identical, or at least similar, to the mmap object, so that they could
be easily interchanged.

-- 
Dr. Paul Barrett       Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Group
FAX:   410-338-4767    Baltimore, MD 21218



From thomas.heller at ion-tof.com  Wed Apr 18 18:36:26 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 18:36:26 +0200
Subject: [Python-Dev] Case sensitive import on windows
References: <03ac01c0c81f$36e45950$e000a8c0@thomasnotebook>
Message-ID: <048101c0c825$b678a940$e000a8c0@thomasnotebook>

I'v submitted a bug report on SF, my message could not
be delivered to guido.


http://sourceforge.net/tracker/index.php?func=detail&aid=417093&group_id=5470&atid=105470

Thomas

Failed to deliver to '<guido at mail.digicool.com>'
LOCAL module(account guido) reports:
 file is not found






From barry at wooz.org  Wed Apr 18 18:42:26 2001
From: barry at wooz.org (Barry A. Warsaw)
Date: Wed, 18 Apr 2001 12:42:26 -0400
Subject: [Python-Dev] Case sensitive import on windows
References: <03ac01c0c81f$36e45950$e000a8c0@thomasnotebook>
	<048101c0c825$b678a940$e000a8c0@thomasnotebook>
Message-ID: <15069.50162.410986.49812@anthem.wooz.org>

Mail to anybody at digicool.com is broken at the moment.  I'm trying to
reach people by phone, but I'd be surprised if the sa's don't know
about it.  I hope this will be a short-lived outage.

-Barry



From thomas.heller at ion-tof.com  Wed Apr 18 18:42:59 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Wed, 18 Apr 2001 18:42:59 +0200
Subject: [Python-Dev] buffer interface (again)
References: <037e01c0c81c$d92a4740$e000a8c0@thomasnotebook>  <200104181645.LAA16566@cj20424-a.reston1.va.home.com> <03d101c0c821$7d13cee0$e000a8c0@thomasnotebook> <3ADDB124.A34D3D45@STScI.Edu>
Message-ID: <04b101c0c826$a0818890$e000a8c0@thomasnotebook>

> 
> I'd like to see a memory object that allocates and deallocates blocks
> of memory and exports a pointer to its memory.  It could also set
> privileges such are read/write, etc

It's all there, in bufferobject.c.
Except that the functions are not exposed to python...

Thomas




From aahz at panix.com  Wed Apr 18 21:07:20 2001
From: aahz at panix.com (aahz at panix.com)
Date: Wed, 18 Apr 2001 15:07:20 -0400 (EDT)
Subject: [Python-Dev] PEP 6 revision
Message-ID: <200104181907.PAA28941@panix3.panix.com>

[posted to c.l.py.announce and c.l.py; followups to c.l.py; cc'd to
python-dev]

[Barry, please update Post-History]

Okay, here's the next version of PEP 6:

PEP: 6
Title: Bugfix Releases
Version: $Revision: 1.3 $
Author: aahz at pobox.com (Aahz)
Status: Draft
Type: Informational
Created: 15-Mar-2001
Post-History: 15-Mar-2001

Abstract

    Python has historically had only a single fork of development, with
    releases having the combined purpose of adding new features and
    delivering bug fixes (these kinds of releases will be referred to as
    "feature releases").  This PEP describes how to fork off patch
    releases of old versions for the primary purpose of fixing bugs.

    This PEP is not, repeat NOT, a guarantee of the existence of patch
    releases; it only specifies a procedure to be followed if patch
    releases are desired by enough of the Python community willing to do
    the work.


Motivation

    With the move to SourceForge, Python development has accelerated.
    There is a sentiment among part of the community that there was too
    much acceleration, and many people are uncomfortable with upgrading
    to new versions to get bug fixes when so many features have been
    added, sometimes late in the development cycle.

    One solution for this issue is to maintain the previous feature
    release, providing bugfixes until the next feature release.  This
    should make Python more attractive for enterprise development, where
    Python may need to be installed on hundreds or thousands of machines.


Prohibitions

    Patch releases are required to adhere to the following restrictions:

    1. There must be zero syntax changes.  All .pyc and .pyo files must
        work (no regeneration needed) with all patch releases forked off
        from a feature release.

    2. There must be zero pickle changes.

    3. There must be no incompatible C API changes.  All extensions must
        continue to work without recompiling in all patch releases in the
        same fork as a feature release.

    Breaking any of these prohibitions requires a BDFL proclamation (and
    a prominent warning in the release notes).


Version Numbers

    Starting with Python 2.0, all feature releases are required to have
    a version number the form X.Y; patch releases will always be of the
    form X.Y.Z.

    The current feature release under development is referred to as
    release N; the just-released feature version is referred to as N-1.


Procedure

    The process for managing patch releases is modeled in part on the
    Tcl system [1].

    The Patch Czar is the counterpart to the BDFL for patch releases.
    However, the BDFL and designated appointees retain veto power over
    individual patches.

    As individual patches get contributed to the feature release fork,
    each patch contributor is requested to consider whether the patch is
    a bugfix suitable for inclusion in a patch release.  If the patch is
    considered suitable, the patch contributor will mail the SourceForge
    patch (bugfix?) number to the maintainers' mailing list.

    In addition, anyone from the Python community is free to suggest
    patches for inclusion.  Patches may be submitted specifically for
    patch releases; they should follow the guidelines in PEP 3 [2].

    The Patch Czar decides when there are a sufficient number of patches
    to warrant a release.  The release gets packaged up, including a
    Windows installer, and made public.  If any new bugs are found, they
    must be fixed immediately and a new patch release publicized (with an
    incremented version number).

    Patch releases are expected to occur at an interval of roughly one
    month.  In general, only the N-1 release will be under active
    maintenance at any time.


Patch Czar History

    Moshe Zadka (moshez at zadka.site.co.il) is the Patch Czar for 2.0.1.


Issues To Be Resolved

    What is the equivalent of python-dev for people who are responsible
    for maintaining Python?  (Aahz proposes either python-patch or
    python-maint, hosted at either python.org or xs4all.net.)

    Does SourceForge make it possible to maintain both separate and
    combined bug lists for multiple forks?  If not, how do we mark bugs
    fixed in different forks?  (Simplest is to simply generate a new bug
    for each fork that it gets fixed in, referring back to the main bug
    number for details.)


History

    This PEP started life as a proposal on comp.lang.python.  The
    original version suggested a single patch for the N-1 release to be
    released concurrently with the N release.  The original version also
    argued for sticking with a strict bugfix policy.

    Following feedback from the BDFL and others, the draft PEP was
    written containing an expanded patch release cycle that permitted
    any previous feature release to obtain patches and also relaxed the
    strict bugfix requirement (mainly due to the example of PEP 235 [3],
    which could be argued as either a bugfix or a feature).

    Discussion then mostly moved to python-dev, where BDFL finally
    issued a proclamation basing the Python patch release process on
    Tcl's, which essentially returned to the original proposal in terms
    of being only the N-1 release and only bugfixes, but allowing
    multiple patch releases until release N is published.


References

    [1] http://dev.scriptics.com:8080/cgi-bin/tct/tip/28.html
    [2] http://python.sourceforge.net/peps/pep-0003.html
    [3] http://python.sourceforge.net/peps/pep-0235.html


Copyright

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
-- 
                      --- Aahz  <*>  (Copyright 2001 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het Pythonista   http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

"If we had some ham, we could have ham & eggs, if we had some eggs." --RH



From m.favas at per.dem.csiro.au  Wed Apr 18 22:13:09 2001
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Thu, 19 Apr 2001 04:13:09 +0800
Subject: [Python-Dev] 2.2a0: latest unicode change breaks test_unicodedata
Message-ID: <3ADDF555.13C627F8@per.dem.csiro.au>

In a change from 2.1 (final) to 2.2a0 - test_unicodedata now fails the
methods test:

test test_unicodedata failed -- Writing:
'00c22b40a906a1a738012676c9feaedfc6be20
d9', expected: '6c7a7c02657b69d0fdd7a7d174f573194bba2e18'

python Lib/test/test_unicodedata.py 
Testing Unicode Database...
Methods: 00c22b40a906a1a738012676c9feaedfc6be20d9
Functions: 4db70de42a8f2de6236242949579fe0e80e7c34a
API: ok

(Tru64 Unix, Compaq C)

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From tim.one at home.com  Wed Apr 18 23:20:59 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 18 Apr 2001 17:20:59 -0400
Subject: [Python-Dev] 2.2a0: latest unicode change breaks test_unicodedata
In-Reply-To: <3ADDF555.13C627F8@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEBNJNAA.tim.one@home.com>

[Mark Favas]
> In a change from 2.1 (final) to 2.2a0 - test_unicodedata now fails the
> methods test:
>
> test test_unicodedata failed -- Writing:
> '00c22b40a906a1a738012676c9feaedfc6be20
> d9', expected: '6c7a7c02657b69d0fdd7a7d174f573194bba2e18'
> ...
> (Tru64 Unix, Compaq C)

Reproduced identically on Windows (guess *everything* isn't the fault of
Compaq's compiler <wink>).  I assume this has something to do with the very
recent Unicode "optimization" patch.

Mystery:  since running the test suite before committing the change would
have caught this, how did the bug get into the CVS tree?  Since it appears
test_unicodedata is skipped under Unix when building the quicktest target, is
this due to people mechanically using quicktest instead of test?  Then that's
a second optimization bug <0.6 wink>.




From mal at lemburg.com  Thu Apr 19 00:51:11 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 00:51:11 +0200
Subject: [Python-Dev] Importing DLLs on Windows
Message-ID: <3ADE1A5F.F574B613@lemburg.com>

Python or Windows seems to have trouble importing DLLs when
inside packages. I'm working on an extension which pulls in a
DLL gmp31.dll which lives inside a package dir mx/Number/mxNumber
along side the Python wrapper extension mxNumber.pyd.

Currently, I'm using this code in the subpackage's __init__.py:

# On Windows we also distribute the GMP DLL (in the win32 subdir). To
# have Win32 find the DLL we need to be explicit about the path in
# sys.path though. This trick works for all startup directories
# *except* \PythonXX (for some reason this fails), but is not thread
# safe...
import sys, os
if sys.platform[:3] == 'win':
    abspath = os.path.abspath(__path__[0])
    sys.path.insert(0, abspath)
    from mxNumber import *
    sys.path.remove(abspath)

else:
    from mxNumber import *


I don't have any clue why the import works from everywhere *except*
the Python21 install directory... anyone does ?

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From tim.one at home.com  Thu Apr 19 01:05:39 2001
From: tim.one at home.com (Tim Peters)
Date: Wed, 18 Apr 2001 19:05:39 -0400
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <20010417151219.T275@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGECIJNAA.tim.one@home.com>

[Jason Tishler]
> I have contributed Python to the standard Cygwin distribution.
> ...
> Cygwin's setup.exe will automatically install Cygwin Python the next
> time one installs or updates from a mirror.

tim at CJ569191-B ~
$ type python
python is /usr/bin/python

tim at CJ569191-B ~
$ python -c "print 'Good show!'"
Good show!

tim at CJ569191-B ~
$

I have nothing to add to what Cygwin Python said <wink>.

hard-to-believe-any-real-program-runs-on-a-win98se-box-ly y'rs  - tim




From skip at pobox.com  Thu Apr 19 10:24:20 2001
From: skip at pobox.com (Skip Montanaro)
Date: Thu, 19 Apr 2001 03:24:20 -0500 (CDT)
Subject: [Python-Dev] tickling version numbers during release
Message-ID: <15070.41140.642307.450172@beluga.mojam.com>

It seems like there is always a flurry of checkins associated with bumping
version numbers whenever a release is impending.  Wouldn't it make sense to
stuff the version number into a file somewhere then add a make target to the
makefile to update the relevant files and check them into cvs?

Skip



From Jason.Tishler at dothill.com  Thu Apr 19 16:07:27 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Thu, 19 Apr 2001 10:07:27 -0400
Subject: [Python-Dev] Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECIJNAA.tim.one@home.com>; from tim.one@home.com on Wed, Apr 18, 2001 at 07:05:39PM -0400
References: <20010417151219.T275@dothill.com> <LNBBLJKPBEHFEDALKOLCGECIJNAA.tim.one@home.com>
Message-ID: <20010419100727.G394@dothill.com>

On Wed, Apr 18, 2001 at 07:05:39PM -0400, Tim Peters wrote:
> hard-to-believe-any-real-program-runs-on-a-win98se-box-ly y'rs  - tim

Hmm...  Maybe we should take up a collection and buy Tim a copy of
Windows 2000 -- at least then he will have a better chance of deluding
himself into thinking that he is using a "real" operating system. :,)

Anyway, I do appreciate Guido and Tim's acknowledge of my efforts on
the Cygwin Python port.  It's been fun and I learned a lot of new things.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From trentm at ActiveState.com  Thu Apr 19 16:53:26 2001
From: trentm at ActiveState.com (Trent Mick)
Date: Thu, 19 Apr 2001 07:53:26 -0700
Subject: [Python-Dev] tickling version numbers during release
In-Reply-To: <15070.41140.642307.450172@beluga.mojam.com>; from skip@pobox.com on Thu, Apr 19, 2001 at 03:24:20AM -0500
References: <15070.41140.642307.450172@beluga.mojam.com>
Message-ID: <20010419075326.F30408@ActiveState.com>

On Thu, Apr 19, 2001 at 03:24:20AM -0500, Skip Montanaro wrote:
> It seems like there is always a flurry of checkins associated with bumping
> version numbers whenever a release is impending.  Wouldn't it make sense to
> stuff the version number into a file somewhere then add a make target to the
> makefile to update the relevant files and check them into cvs?

Or preferably have the version number in only *one* place in one file in CVS
then (1) have autoconf massage template files to insert the version number
where needed or (2) have those files that need the version number *include*
it from pyac_config.h.

...except we are not using any auto configuration tool on Windows. Damn.

Trent

-- 
Trent Mick
TrentM at ActiveState.com



From guido at digicool.com  Thu Apr 19 17:09:47 2001
From: guido at digicool.com (Guido van Rossum)
Date: Thu, 19 Apr 2001 11:09:47 -0400
Subject: [Python-Dev] tickling version numbers during release
In-Reply-To: Your message of "Thu, 19 Apr 2001 03:24:20 CDT."
             <15070.41140.642307.450172@beluga.mojam.com> 
References: <15070.41140.642307.450172@beluga.mojam.com> 
Message-ID: <200104191509.f3JF9ng02487@odiug.pythonlabs.org>

> It seems like there is always a flurry of checkins associated with bumping
> version numbers whenever a release is impending.  Wouldn't it make sense to
> stuff the version number into a file somewhere then add a make target to the
> makefile to update the relevant files and check them into cvs?

Is it worth spending the time to write a script that gets run only
once per revision?  (The bump from 2.1 to 2.2 causes many more
checkins than e.g. from 2.1 to 2.1.1 or from 2.1a1 to 2.1b1.)

It won't reduce the nubmer of checkins -- the files that have the
versions really must have the versions, and we do what we can to
minimize the dependencies (e.g. the VERSION variable in configure.in
gets propagated to the Makefile).

Like Knuth says in his explanation of how "The Art Of Computer
Programming" is typeset, the start of a new chapter is such a major
event that there's no macro for it -- he types it in himself.  (Most
other typing is done by typists of course.)

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



From mal at lemburg.com  Thu Apr 19 21:04:41 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 21:04:41 +0200
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, Floats)
Message-ID: <3ADF36C9.1D9AA305@lemburg.com>

As you all know, Moshe Zadka has been pushing for a new rational number
type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I though, but well, it's done now ;-)

The wrapper is called mx.Number and provides access to three
numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision

Prerequisites:
--------------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
i = Integer("1231231231231231231231231")

The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


Questions:
----------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From mwh21 at cam.ac.uk  Thu Apr 19 22:04:57 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 19 Apr 2001 21:04:57 +0100
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, Floats)
In-Reply-To: "M.-A. Lemburg"'s message of "Thu, 19 Apr 2001 21:04:41 +0200"
References: <3ADF36C9.1D9AA305@lemburg.com>
Message-ID: <m3g0f4r6za.fsf@atrus.jesus.cam.ac.uk>

Before I d/l and take a look...

"M.-A. Lemburg" <mal at lemburg.com> writes:

> (e.g. Integer(2) + "3" works as one would expect ;-).

So it raises an exception?  Seriously, that's what *I'd* expect, and
if it's not what your package does, I beg you to reconsider.

Cheers,
M.

-- 
  Good? Bad? Strap him into the IETF-approved witch-dunking
  apparatus immediately!                        -- NTK now, 21/07/2000




From mal at lemburg.com  Thu Apr 19 22:25:50 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 22:25:50 +0200
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, 
 Floats)
References: <3ADF36C9.1D9AA305@lemburg.com> <m3g0f4r6za.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <3ADF49CE.10EF2A5D@lemburg.com>

Michael Hudson wrote:
> 
> Before I d/l and take a look...
> 
> "M.-A. Lemburg" <mal at lemburg.com> writes:
> 
> > (e.g. Integer(2) + "3" works as one would expect ;-).
> 
> So it raises an exception?  Seriously, that's what *I'd* expect, and
> if it's not what your package does, I beg you to reconsider.

Integer(2) + "3" gives you Integer(5). This is a side-effect
of how the implementation converts arbitrary objects into ones
usable for coercion: Integer(2) + "3" is interpreted as 
Integer(2) + Integer("3") which gives Integer(2) + Integer(3).

After having played with it for a while, I must say, that I
kind of like it :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From mwh21 at cam.ac.uk  Thu Apr 19 23:46:51 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 19 Apr 2001 22:46:51 +0100
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0252.txt,NONE,1.1 pep-0000.txt,1.87,1.88
In-Reply-To: Guido van Rossum's message of "Thu, 19 Apr 2001 14:27:27 -0700"
References: <E14qLxX-0006pt-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <m3d7a8r29g.fsf@atrus.jesus.cam.ac.uk>

Guido van Rossum <gvanrossum at users.sourceforge.net> writes:

[snip]
> Author: guido at python.org (Jeremy Hylton)

Eh?

[snop]




From guido at digicool.com  Fri Apr 20 06:29:45 2001
From: guido at digicool.com (Guido van Rossum)
Date: Thu, 19 Apr 2001 23:29:45 -0500
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
Message-ID: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>

I've got a fairly complete implementation of iterators along the lines
of Ping's PEP (slightly updated).  This is available for inspection
through CVS: just check out the CVS branch of python/dist/src named
"iter-branch" from SourceForge:

  cvs checkout -r iter-branch -d <directory> python/src/dist

(This branch was forked off the trunk around the time of version
2.1b1, so it's not up to date with Python 2.1, but it's good enough to
show off iterators.)

My question is: should I just merge this code onto the trunk (making
it part of 2.2), or should we review the design more before committing
to this implementation?

Brief overview of what I've got implemented:

- There is a new built-in operation, spelled as iter(obj) in Python
  and as PyObject_GetIter(obj) in C; it calls the tp_iter slot in
  obj's type.  This returns an iterator, which can be any object that
  implements the iterator protocol.  The iterator protocol defines one
  method, next(), which returns the next value or raises the new
  StopIteration exception.

- For backwards compatibility, if obj's type does not have a valid
  tp_iter slot, iter(obj) and PyObject_GetIter(obj) create a sequence
  iterator that iterates over a sequence.

- "for x in S: B" is implemented roughly as

  __iter = iter(S)
  while 1:
    try:
      x = __iter.next()
    except StopIteration:
      break
    B

  (except that the semantics of break when there's an else clause are
  not different from what this Python code would do).

- The test "key in dict" is implemented as "dict.has_key(key)".  (This
  was done by implementing the sq_contains slot.

- iter(dict) returns an iterator that iterates over the keys of dict
  without creating a list of keys first.  This means that "for key in
  dict" has the same effect as "for key in dict.keys()" as long as the
  loop body doesn't modify the dictionary (assignment to existing keys
  is okay).

- There's an operation to create an iterator from a function and a
  sentinel value.  This is spelled as iter(function, sentinel).  For
  example,

    for line in iter(sys.stdin.readline, ""):
      ...

  is an efficient loop over the lines of stdin.

- But even cooler is this, which is totally equivalent:

    for line in sys.stdin:
      ...

- Not yet implemented, but part of the plan, is to use iterators for
  all other implicit loops, like map/reduce/filter, min/max, and the
  "in" test for sequences that don't define sq_contains.

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



From tim.one at home.com  Fri Apr 20 09:15:30 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 20 Apr 2001 03:15:30 -0400
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEHDJNAA.tim.one@home.com>

[Guido]
> I've got a fairly complete implementation of iterators along the lines
> of Ping's PEP (slightly updated).
> ...
> My question is: should I just merge this code onto the trunk (making
> it part of 2.2), or should we review the design more before committing
> to this implementation?

My answer is both!  *Most* of what you described is no longer controversial;
2.2 is mondo pre-alpha (so we're not "stuck" with anything you check in now);
and it's much more convenient (for me - heh) to try out if it's in the
regular build tree.  I bet Greg Wilson would like it for his Set PEP work
too, as abusing the __getitem__ protocol for set iteration is giving him
headaches.  WRT what may still be controversial points, there's no substitute
for trying a thing.

> ...
> - The test "key in dict" is implemented as "dict.has_key(key)".  (This
>   was done by implementing the sq_contains slot.

That's probably controversial, but also easy to rip out (sounds approximately
self-contained) if the peasants storm your castle with flaming dungballs
<wink>.

> - iter(dict) returns an iterator that iterates over the keys of dict
>   without creating a list of keys first.  This means that "for key in
>   dict" has the same effect as "for key in dict.keys()" as long as
>   the loop body doesn't modify the dictionary (assignment to existing
>   keys is okay).

Ditto.

> - There's an operation to create an iterator from a function and a
>   sentinel value.  This is spelled as iter(function, sentinel).  For
>   example,
>
>     for line in iter(sys.stdin.readline, ""):
>       ...
>
>   is an efficient loop over the lines of stdin.
>
> - But even cooler is this, which is totally equivalent:
>
>     for line in sys.stdin:
>       ...

Here you're going to be hoisted on your own petard (Jeremy can explain that
one <wink>):  if

    for x in dict:

has to iterate over keys because

    if x in dict:

tests for keys, then shouldn't

    if line in sys.stdin:

also check sys.stdin for the presence of line?  Not according to me, but it's
a not wholly unreasonable question.

> - Not yet implemented, but part of the plan, is to use iterators for
>   all other implicit loops, like map/reduce/filter, min/max, and the
>   "in" test for sequences that don't define sq_contains.

Check it into the trunk and people can help out with that stuff.

+0.9.




From thomas at xs4all.net  Fri Apr 20 10:37:33 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 20 Apr 2001 10:37:33 +0200
Subject: [python-iter] RE: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEHDJNAA.tim.one@home.com>; from tim.one@home.com on Fri, Apr 20, 2001 at 03:15:30AM -0400
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCCEHDJNAA.tim.one@home.com>
Message-ID: <20010420103733.D10318@xs4all.nl>

On Fri, Apr 20, 2001 at 03:15:30AM -0400, Tim Peters wrote:
> [Guido]
> > I've got a fairly complete implementation of iterators along the lines
> > of Ping's PEP (slightly updated).
> > ...
> > My question is: should I just merge this code onto the trunk (making
> > it part of 2.2), or should we review the design more before committing
> > to this implementation?

> My answer is both!  *Most* of what you described is no longer controversial;
> 2.2 is mondo pre-alpha (so we're not "stuck" with anything you check in now);
> and it's much more convenient (for me - heh) to try out if it's in the
> regular build tree.  I bet Greg Wilson would like it for his Set PEP work
> too, as abusing the __getitem__ protocol for set iteration is giving him
> headaches.  WRT what may still be controversial points, there's no substitute
> for trying a thing.

I don't totally agree. Removing something from the trunk is not as easy as
not adding it ;) But I agree that, since the *concept* of iterators, and the
basic implementation, all are good things, they should be checked in. I
still don't like:

> > ...
> > - The test "key in dict" is implemented as "dict.has_key(key)".  (This
> >   was done by implementing the sq_contains slot.

> That's probably controversial, but also easy to rip out (sounds approximately
> self-contained) if the peasants storm your castle with flaming dungballs
> <wink>.

Fetchez-la-vache!-ly y'rs

(Oh, now I get it... Iterators are Guido's wooden rabbit, with 'key-in-dict'
hidden inside... I just hope it's Sir Bedevere that's building it ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From mal at lemburg.com  Fri Apr 20 11:02:09 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 20 Apr 2001 11:02:09 +0200
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>
Message-ID: <3ADFFB11.AECF3438@lemburg.com>

Guido van Rossum wrote:
> 
> Brief overview of what I've got implemented:
> 
> - There is a new built-in operation, spelled as iter(obj) in Python
>   and as PyObject_GetIter(obj) in C; it calls the tp_iter slot in
>   obj's type.  This returns an iterator, which can be any object that
>   implements the iterator protocol.  The iterator protocol defines one
>   method, next(), which returns the next value or raises the new
>   StopIteration exception.

Could we also have a C slot for .next() ? (Python function calls
are way too expensive for these things, IMHO)

Will there be a __iter__() method for Python instances to implement ?

> - For backwards compatibility, if obj's type does not have a valid
>   tp_iter slot, iter(obj) and PyObject_GetIter(obj) create a sequence
>   iterator that iterates over a sequence.
> 
> - "for x in S: B" is implemented roughly as
> 
>   __iter = iter(S)
>   while 1:
>     try:
>       x = __iter.next()
>     except StopIteration:
>       break
>     B
> 
>   (except that the semantics of break when there's an else clause are
>   not different from what this Python code would do).
> 
> - The test "key in dict" is implemented as "dict.has_key(key)".  (This
>   was done by implementing the sq_contains slot.

Cool :)
 
> - iter(dict) returns an iterator that iterates over the keys of dict
>   without creating a list of keys first.  This means that "for key in
>   dict" has the same effect as "for key in dict.keys()" as long as the
>   loop body doesn't modify the dictionary (assignment to existing keys
>   is okay).
>
> - There's an operation to create an iterator from a function and a
>   sentinel value.  This is spelled as iter(function, sentinel).  For
>   example,
> 
>     for line in iter(sys.stdin.readline, ""):
>       ...
> 
>   is an efficient loop over the lines of stdin.

Hmm, I guess you have to compare each function output to the
sentinel then, right ? This can be very expensive.

Wouldn't an exception base class also do the trick as sentinel ? The 
iterator would then stop when an exception is raised by the
function which matches the sentinel exception.
 
> - But even cooler is this, which is totally equivalent:
> 
>     for line in sys.stdin:
>       ...
> 
> - Not yet implemented, but part of the plan, is to use iterators for
>   all other implicit loops, like map/reduce/filter, min/max, and the
>   "in" test for sequences that don't define sq_contains.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From thomas at xs4all.net  Fri Apr 20 11:26:38 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 20 Apr 2001 11:26:38 +0200
Subject: [Python-iterators] Re: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <3ADFFB11.AECF3438@lemburg.com>; from mal@lemburg.com on Fri, Apr 20, 2001 at 11:02:09AM +0200
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <3ADFFB11.AECF3438@lemburg.com>
Message-ID: <20010420112638.F10318@xs4all.nl>

On Fri, Apr 20, 2001 at 11:02:09AM +0200, M.-A. Lemburg wrote:

> > - There's an operation to create an iterator from a function and a
> >   sentinel value.  This is spelled as iter(function, sentinel).  For
> >   example,
> > 
> >     for line in iter(sys.stdin.readline, ""):
> >       ...
> > 
> >   is an efficient loop over the lines of stdin.

> Hmm, I guess you have to compare each function output to the
> sentinel then, right ? This can be very expensive.

> Wouldn't an exception base class also do the trick as sentinel ? The 
> iterator would then stop when an exception is raised by the
> function which matches the sentinel exception.

The sentinel method is for use with existing functions, that return a
sentinel value (like "" or None or whatever.) Comparing to those is not
terribly expensive, asside from the burden of running a single compare in
the inner loop. Rewriting those functions to raise an exception instead
would be, well, somewhat silly -- if you're rewriting them anyway, why not
just make an iterator out of them ?

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Fri Apr 20 11:35:12 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 20 Apr 2001 11:35:12 +0200
Subject: [Python-Dev] off-topic, sorry ;)
Message-ID: <20010420113512.G10318@xs4all.nl>

My batch of PythonLabs T-Shirts arrived yesterday (thanx, by the way,
Melissa!) but there was something twilight-zonish about the box that I just
had to share ;) My colleague Scott took delivery of the box, and knew
without looking at the sender or description that it was something Python
related. It had this sticker on it:

http://www.xs4all.nl/~thomas/SPAM.jpg

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From mal at lemburg.com  Fri Apr 20 12:10:10 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 20 Apr 2001 12:10:10 +0200
Subject: [Python-iterators] Re: [Python-Dev] Shall I start adding iterators 
 to Python 2.2?
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <3ADFFB11.AECF3438@lemburg.com> <20010420112638.F10318@xs4all.nl>
Message-ID: <3AE00B02.5EFCB6F@lemburg.com>

Thomas Wouters wrote:
> 
> On Fri, Apr 20, 2001 at 11:02:09AM +0200, M.-A. Lemburg wrote:
> 
> > > - There's an operation to create an iterator from a function and a
> > >   sentinel value.  This is spelled as iter(function, sentinel).  For
> > >   example,
> > >
> > >     for line in iter(sys.stdin.readline, ""):
> > >       ...
> > >
> > >   is an efficient loop over the lines of stdin.
> 
> > Hmm, I guess you have to compare each function output to the
> > sentinel then, right ? This can be very expensive.
> 
> > Wouldn't an exception base class also do the trick as sentinel ? The
> > iterator would then stop when an exception is raised by the
> > function which matches the sentinel exception.
> 
> The sentinel method is for use with existing functions, that return a
> sentinel value (like "" or None or whatever.) Comparing to those is not
> terribly expensive, asside from the burden of running a single compare in
> the inner loop. Rewriting those functions to raise an exception instead
> would be, well, somewhat silly -- if you're rewriting them anyway, why not
> just make an iterator out of them ?

I wasn't clear enough: I was proposing to also allow exception
classes as sentinel which are then not compared with the result
of the function, but instead with any exceptions raised by the
function. This would be an additional method of recognizing the
end-of-iteration to the standard return value comparison.

The reasoning is the you may want to use e.g. a C function (hard
to rewrite as iterator) as iterator which currently works along 
these lines:

while 1:
    try:
        x = datasource()
    except EndOfData:
        break
    print x

You could then rewrite this as:

for x in iter(datasource, EndOfData):
   print x

BTW, how does iter() recognize that it is supposed to look
for a sentinel ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From mal at lemburg.com  Thu Apr 19 21:04:41 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 19 Apr 2001 21:04:41 +0200
Subject: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, Floats)
Message-ID: <mailman.987707135.9028.python-list@python.org>

As you all know, Moshe Zadka has been pushing for a new rational number
type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I though, but well, it's done now ;-)

The wrapper is called mx.Number and provides access to three
numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision

Prerequisites:
--------------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
i = Integer("1231231231231231231231231")

The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


Questions:
----------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/




From Greg.Wilson at baltimore.com  Fri Apr 20 14:55:24 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 08:55:24 -0400
Subject: [Python-Dev] configuration "feature"
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com>

I just checked out a fresh copy of Python from Sourceforge
on a Solaris 5.8 machine, and typed:

    ./configure -with-cxx

rather than

    ./configure -with-cxx=g++

It generates a makefile with "CXX=yes", so "make" produces:

    bash-2.03$ make
    yes -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H
\
        -o Modules/ccpython.o ./Modules/ccpython.cc
    make: yes: Command not found

:-)

Greg



From mwh21 at cam.ac.uk  Fri Apr 20 15:13:03 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 20 Apr 2001 14:13:03 +0100
Subject: [Python-Dev] configuration "feature"
In-Reply-To: Greg Wilson's message of "Fri, 20 Apr 2001 08:55:24 -0400"
References: <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com>
Message-ID: <m3ae5bpvds.fsf@atrus.jesus.cam.ac.uk>

Greg Wilson <Greg.Wilson at baltimore.com> writes:

> I just checked out a fresh copy of Python from Sourceforge
> on a Solaris 5.8 machine, and typed:
> 
>     ./configure -with-cxx
> 
> rather than
> 
>     ./configure -with-cxx=g++
> 
> It generates a makefile with "CXX=yes", so "make" produces:
> 
>     bash-2.03$ make
>     yes -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H
> \
>         -o Modules/ccpython.o ./Modules/ccpython.cc
>     make: yes: Command not found
> 
> :-)

Teehee.  Try it on a linux box though; there is a /usr/bin/yes, and it
doesn't do anything too helpful...

Cheers,
M.

-- 
  [Perl] combines all the  worst aspects of C and Lisp:  a billion
  different sublanguages in one monolithic executable. It combines
  the power of C with the readability of PostScript.
                                                     -- Jamie Zawinski




From guido at digicool.com  Fri Apr 20 16:55:54 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 09:55:54 -0500
Subject: [Python-Dev] configuration "feature"
In-Reply-To: Your message of "Fri, 20 Apr 2001 08:55:24 -0400."
             <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com> 
References: <930BBCA4CEBBD411BE6500508BB3328F22D13B@nsamcanms1.ca.baltimore.com> 
Message-ID: <200104201455.JAA05644@cj20424-a.reston1.va.home.com>

> I just checked out a fresh copy of Python from Sourceforge
> on a Solaris 5.8 machine, and typed:
> 
>     ./configure -with-cxx
> 
> rather than
> 
>     ./configure -with-cxx=g++
> 
> It generates a makefile with "CXX=yes", so "make" produces:
> 
>     bash-2.03$ make
>     yes -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H
> \
>         -o Modules/ccpython.o ./Modules/ccpython.cc
>     make: yes: Command not found
> 
> :-)

Use the SourceForge bug tracker, please!

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



From guido at digicool.com  Fri Apr 20 17:41:32 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 10:41:32 -0500
Subject: [Python-iterators] Re: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: Your message of "Fri, 20 Apr 2001 11:26:38 +0200."
             <20010420112638.F10318@xs4all.nl> 
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com> <3ADFFB11.AECF3438@lemburg.com>  
            <20010420112638.F10318@xs4all.nl> 
Message-ID: <200104201541.KAA06089@cj20424-a.reston1.va.home.com>

I've redirected replies to python-iterators at lists.sourceforge.net.
The archives work now:

http://www.geocrawler.com/lists/3/SourceForge/9283/0/

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



From thomas.heller at ion-tof.com  Fri Apr 20 17:05:42 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 17:05:42 +0200
Subject: [Python-Dev] Class Methods
Message-ID: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>

There are some signs :-) that Python's object
model is going to be revised even _before_
Python 3000.

Is someone willing to join me fighting
for class methods (I mean 'real' class-methods
in the Smalltalk style here, _not_ static
methods like in Java or C++).

Thomas




From jeremy at digicool.com  Fri Apr 20 17:14:16 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 20 Apr 2001 11:14:16 -0400 (EDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
Message-ID: <15072.21064.298318.393753@slothrop.digicool.com>

>>>>> "TH" == Thomas Heller <thomas.heller at ion-tof.com> writes:

  TH> There are some signs :-) that Python's object model is going to
  TH> be revised even _before_ Python 3000.

  TH> Is someone willing to join me fighting for class methods (I mean
  TH> 'real' class-methods in the Smalltalk style here, _not_ static
  TH> methods like in Java or C++).

The idea sounds good in the abstract.  Class are objects and objects
ought to have methods that implement their behavior.  How does that
very vague idea turn into something real?  No clue.  You start
fighting and let's see where it goes :-).

Jeremy




From guido at digicool.com  Fri Apr 20 18:26:01 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 11:26:01 -0500
Subject: [Python-Dev] Class Methods
In-Reply-To: Your message of "Fri, 20 Apr 2001 17:05:42 +0200."
             <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> 
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> 
Message-ID: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>

> There are some signs :-) that Python's object
> model is going to be revised even _before_
> Python 3000.

Well, the official policy on this is now that Py3K is just a slogan,
and that all the real work will be introduced gradually. :-)

> Is someone willing to join me fighting
> for class methods (I mean 'real' class-methods
> in the Smalltalk style here, _not_ static
> methods like in Java or C++).

I will fight class methods to the death. :-)

Seriously, I think you'll find an ally in Jim Fulton, who basically
told me (since he's sort of my boss :-) to get on with this work.  I
think it can work as follows:

Let x be an object, C its class, and M C's class.  So,

  x.__class__ is C
  C.__class__ is M

Then x's methods are described in C.__dict__, and C's methods are
described in M.__dict__.

The problem is that if you write C.spam, there could be two spams: one
in C.__dict__, one in M.__dict__.  Which one to use?  How does
Smalltalk resolve this?  The problem is that for backwards
compatibility, at lease, C.spam must be the unbound version of x.spam,
because currently x.spam(...) can always also be written as
C.spam(x, ...).

For regular methods it may be possible to avoid this simply by
choosing non-conflicting names, but I seem to recall that Jim wanted
to use class methods with certain special names (like __init__ or
__getattr__?), and I have no idea how to do this without dropping the
idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
solution?

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



From mal at lemburg.com  Fri Apr 20 17:24:29 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 20 Apr 2001 17:24:29 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com>
Message-ID: <3AE054AD.9A8D07D@lemburg.com>

Jeremy Hylton wrote:
> 
> >>>>> "TH" == Thomas Heller <thomas.heller at ion-tof.com> writes:
> 
>   TH> There are some signs :-) that Python's object model is going to
>   TH> be revised even _before_ Python 3000.
> 
>   TH> Is someone willing to join me fighting for class methods (I mean
>   TH> 'real' class-methods in the Smalltalk style here, _not_ static
>   TH> methods like in Java or C++).
> 
> The idea sounds good in the abstract.  Class are objects and objects
> ought to have methods that implement their behavior.  How does that
> very vague idea turn into something real?  No clue.  You start
> fighting and let's see where it goes :-).

Here's something to start the fight ;-) ...

1) What would you do with class methods that you cannot do with
   e.g. globals and functions ?

2) How would you determine which methods are class-only methods and
   which are one usable by instances ?

3) If you don't like globals (see 1), wouldn't it be possible to
   store the state you want to manipulate using class methods
   in some other context object ?

My impression is that class methods are not really needed and
would only make optimizing Python harder... but that's maybe just 
me ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at acm.org  Fri Apr 20 17:34:41 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 20 Apr 2001 11:34:41 -0400 (EDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
	<200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <15072.22289.218618.462955@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > __getattr__?), and I have no idea how to do this without dropping the
 > idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
 > solution?

  Can that be dropped and still allow subclasses to extend a method
offered by the base class?  I think making the two different would
break an enormous amount of code.


  -Fred

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




From thomas.heller at ion-tof.com  Fri Apr 20 17:40:21 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 17:40:21 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com>
Message-ID: <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>

> Here's something to start the fight ;-) ...
> 
> 1) What would you do with class methods that you cannot do with
>    e.g. globals and functions ?

I will write up a concrete example I have and post it later.

Look into the motivation for the Prototype Pattern in the GOF
book, or even better in the discussion of this pattern in the
'Design Pattern Smalltalk Companion' book.

This pattern is not needed if classes are 'first class' objects.

> 
> 2) How would you determine which methods are class-only methods and
>    which are one usable by instances ?
This is one of the issues which has to be resolved. I have no proposal
at the moment. (Maybe function attributes can help here?)

> 
> 3) If you don't like globals (see 1), wouldn't it be possible to
>    store the state you want to manipulate using class methods
>    in some other context object ?
I want the class methods (for example) to create and manipulate
this 'context object'. This object, however, belongs into the class...

What I want to avoid is

  class X(...):
      ....
  initialize(X)

> 
> My impression is that class methods are not really needed and
> would only make optimizing Python harder... but that's maybe just 
> me ;-)
Unfortunately not, I fear.

Thomas




From guido at digicool.com  Fri Apr 20 18:52:18 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 11:52:18 -0500
Subject: [Python-Dev] Class Methods
In-Reply-To: Your message of "Fri, 20 Apr 2001 17:40:21 +0200."
             <030101c0c9b0$3578a520$e000a8c0@thomasnotebook> 
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com>  
            <030101c0c9b0$3578a520$e000a8c0@thomasnotebook> 
Message-ID: <200104201652.LAA06554@cj20424-a.reston1.va.home.com>

> Look into the motivation for the Prototype Pattern in the GOF
> book, or even better in the discussion of this pattern in the
> 'Design Pattern Smalltalk Companion' book.

I imagine many of us (including yours truly :-) don't recall that in
enough detail and/or don't have the book handy to look it up, so would
you please do us a favor and explain this in a bit more detail?

> This pattern is not needed if classes are 'first class' objects.

Depending on what you mean by the 'first class' phrase (which means
something different to everyone), Python classes are already as first
class as they get.  E.g. they are tangible objects and you can pass
them around and store them in variables.

> What I want to avoid is
> 
>   class X(...):
>       ....
>   initialize(X)

What would initialize(X) do that you can't write in the class body?

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



From thomas.heller at ion-tof.com  Fri Apr 20 17:59:12 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 17:59:12 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>  <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <031b01c0c9b2$d79bfda0$e000a8c0@thomasnotebook>

> > Is someone willing to join me fighting
> > for class methods (I mean 'real' class-methods
> > in the Smalltalk style here, _not_ static
> > methods like in Java or C++).
> 
> I will fight class methods to the death. :-)
Ouch :-)

> 
> Seriously, I think you'll find an ally in Jim Fulton,
So there _is_ some hope.

>  who basically
> told me (since he's sort of my boss :-) to get on with this work.

This must be the reason that ExtensionClass provides them:
You can implement them in C, and override them in python
subclasses.

Thomas




From thomas.heller at ion-tof.com  Fri Apr 20 18:07:23 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 18:07:23 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com>              <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>  <200104201652.LAA06554@cj20424-a.reston1.va.home.com>
Message-ID: <034901c0c9b3$fcaa6bd0$e000a8c0@thomasnotebook>

> > Look into the motivation for the Prototype Pattern in the GOF
> > book, or even better in the discussion of this pattern in the
> > 'Design Pattern Smalltalk Companion' book.
> 
> I imagine many of us (including yours truly :-) don't recall that in
> enough detail and/or don't have the book handy to look it up, so would
> you please do us a favor and explain this in a bit more detail?
> 
This is a valid request, but please wait for my larger example.
I'm referring to this because I have not been good at explaining
the things I want...

All in all:

I'm not really ready to start the fight _now_, I was just
looking for some help...

Thomas

PS: I find it strange that everyone so far seems to be against it.




From barry at digicool.com  Fri Apr 20 18:13:07 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Fri, 20 Apr 2001 12:13:07 -0400
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
References: <200104200429.XAA03693@cj20424-a.reston1.va.home.com>
Message-ID: <15072.24595.478099.658273@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

    GvR> My question is: should I just merge this code onto the trunk
    GvR> (making it part of 2.2), or should we review the design more
    GvR> before committing to this implementation?

I would definitely like to play with this stuff so I'd be generally +1
at committing your changes to the trunk.  Let me make two comments.

First, Ping or Guido should update the PEP, especially to describe the
`non-controversial' parts (using .next(), StopIteration -- where's
this exception in the hierarchy, btw?).  You should also update the
Open Issues section.

Second, I'm still not totally comfortable with the "for keys:values in
dict" part of the proposal, especially with the elaboration of letting
either keys or values be missing.  An alternative, which I sure has
been raised, but which isn't in the PEP, is to allow an alternative
pseudo-keyword in the `in' position.  For example, allow "over" which
has the semantics when used with a dict of iterating over keys.items()
and when iterating over a sequence has the semantics of iterating over
zip(range(len(a)), a).  Thus only this would be allowed:

    for key, value over dict:

    for index, item over seq:

I think it would be fine if you don't support optional untupling parts
in the target.

-Barry



From barry at digicool.com  Fri Apr 20 18:36:26 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Fri, 20 Apr 2001 12:36:26 -0400
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
	<200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <15072.25994.247806.815084@anthem.wooz.org>

>>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:

    GvR> Let x be an object, C its class, and M C's class.  So,

    |   x.__class__ is C
    |   C.__class__ is M

    GvR> Then x's methods are described in C.__dict__, and C's methods
    GvR> are described in M.__dict__.

    GvR> The problem is that if you write C.spam, there could be two
    GvR> spams: one in C.__dict__, one in M.__dict__.  Which one to
    GvR> use?

If you use naming to generally distinguish, and have a lookup chain
that first found it in C.__dict__ and then looked in M.__dict__, you
could control what happens when the name is in both dicts by using a
more explicit lookup, e.g. C.__dict__['meth']
vs. C.__class__.__dict__['meth']

But maybe that's too ugly.
    
    GvR> How does Smalltalk resolve this?

I don't remember, but I do remember that ObjC had the same concepts,
and it used a distinguishing marker on the method definition to say
whether the method was a class method (`+') or instance method (`-'),
e.g.

    + void some_class_method ...
    - void an_instance_method

Another question: presumably when I write

    class Foo: pass

Foo is implicitly given the built-in metaclass M, but say I wanted to
define a class Foo with a different metaclass, how would I spell this?
I think at one point I suggested a semi-ugly syntactic hack, where
`class' was actually a namespace and you could add new metaclasses to
it.  So you could write something like

    class.WeirdClass Foo: pass

and now Foo's metaclass would be WeirdClass.

waiting-for-the-bottom-turtle-to-burp-ly y'rs,
-Barry



From jeremy at digicool.com  Fri Apr 20 19:00:09 2001
From: jeremy at digicool.com (Jeremy Hylton)
Date: Fri, 20 Apr 2001 13:00:09 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/ref ref3.tex,1.64,1.65 ref5.tex,1.43,1.44
In-Reply-To: <E14qe7G-0002AU-00@usw-pr-cvs1.sourceforge.net>
References: <E14qe7G-0002AU-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <15072.27417.366789.977575@slothrop.digicool.com>

>>>>> "GvR" == Guido van Rossum <gvanrossum at users.sourceforge.net> writes:

  GvR> Log Message: Implement, test and document "key in dict" and
  GvR> "key not in dict".

  GvR> I know some people don't like this -- if it's really
  GvR> controversial, I'll take it out again.  (If it's only Alex
  GvR> Martelli who doesn't like it, that doesn't count as "real
  GvR> controversial" though. :-)

I don't like it either, because it's only clear when it's spelled "for
key in dict".  It's pretty confusing when it's spelled "for val in
dict" or even "for x in dict".

But I'm willing to give it a try for a while.

Jeremy




From aahz at rahul.net  Fri Apr 20 19:08:53 2001
From: aahz at rahul.net (Aahz Maruch)
Date: Fri, 20 Apr 2001 10:08:53 -0700 (PDT)
Subject: [Python-Dev] Shall I start adding iterators to Python 2.2?
In-Reply-To: <15072.24595.478099.658273@anthem.wooz.org> from "Barry A. Warsaw" at Apr 20, 2001 12:13:07 PM
Message-ID: <20010420170853.ECA2C99C80@waltz.rahul.net>

Barry A. Warsaw wrote:
> 
> Second, I'm still not totally comfortable with the "for keys:values in
> dict" part of the proposal, especially with the elaboration of letting
> either keys or values be missing.  An alternative, which I sure has
> been raised, but which isn't in the PEP, is to allow an alternative
> pseudo-keyword in the `in' position.  For example, allow "over" which
> has the semantics when used with a dict of iterating over keys.items()
> and when iterating over a sequence has the semantics of iterating over
> zip(range(len(a)), a).  Thus only this would be allowed:
> 
>     for key, value over dict:
> 
>     for index, item over seq:

+1 from me, particularly the part about getting rid of "keys:values"; I
just see little advantage to using anything other than a tuple.
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6       <*>       http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.



From root at rainerdeyke.com  Fri Apr 20 19:34:08 2001
From: root at rainerdeyke.com (Rainer Deyke)
Date: Fri, 20 Apr 2001 11:34:08 -0600
Subject: [Python-Dev] Re: Class Methods
References: <mailman.987779255.16686.python-list@python.org>
Message-ID: <027801c0c9c0$2e9081a0$070110ac@deyke.net>

"Thomas Heller" <thomas.heller at ion-tof.com> wrote in message
news:mailman.987779255.16686.python-list at python.org...
> There are some signs :-) that Python's object
> model is going to be revised even _before_
> Python 3000.
>
> Is someone willing to join me fighting
> for class methods (I mean 'real' class-methods
> in the Smalltalk style here, _not_ static
> methods like in Java or C++).

I posted this in another thread, but I think it bears repeating here.


I consider classes/instances a special case of namespaces: one which allows
(multiple) instantiation and inheritance.  In actual pratice not all of the
classes I design are designed for multiple instantiation, or instantiation
at all for that matter.  What I would like to see is a separation of
concerns ("Does this namespace have __special__ attributes for operator
overloading?" inpdependent from "Does this namespace require
instantiation?") followed by a culling of irrelevant features ("Don't want
operator overloading?  Don't name your function '__add__' then.").  The
resulting programming language might look something like this:

namespace A: # Create a named unique object
  pass
namespace B(A): # Similar to 'from ... import', but done through linking
                # instead of copying
class C(A): # 'class' = namespace that requires/supports instantiation
            # class inherits from namespace => functions in namespace
            # are treated as "static" functions
  pass
namespace D(C()): # namespace inherits from instance of class
  pass


The module itself would be a 'namespace' object.  Overall, I think this has
the potential of creating a much simpler and more regular language.
Separate keywords for 'class' and 'namespace' might even turn out to be
unnecessary.


In this context, class methods would either be automatically included, or
turn out to be truly redundant, or both.


--
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games           -           http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor





From tim.one at home.com  Fri Apr 20 19:44:40 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 20 Apr 2001 13:44:40 -0400
Subject: [Python-Dev] Class Methods
In-Reply-To: <034901c0c9b3$fcaa6bd0$e000a8c0@thomasnotebook>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEJBJNAA.tim.one@home.com>

[Thomas Heller]
> ...
> PS: I find it strange that everyone so far seems to be against it.

I didn't get that sense yet.  I did get the sense they're not actively *for*
it yet, and the questions asked so far explain why:  What does it buy us?
What are the current alternatives?  What are the costs (not least of all in
terms of breaking existing code)?  It's a bunch of tradeoffs, and it appears
that few who aren't steeped in Smalltalk's view of the world understand what
the practical *attraction* is.

The same questions get asked even for wholly non-controversial changes, like,
say, adding an optional ">> file" clause to "print" <wink>.

by-default-it's-best-to-resist-everything-ly y'rs  - tim




From michel at digicool.com  Fri Apr 20 19:50:15 2001
From: michel at digicool.com (Michel Pelletier)
Date: Fri, 20 Apr 2001 10:50:15 -0700 (PDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>
Message-ID: <Pine.LNX.4.32.0104201039300.6561-100000@localhost.localdomain>


On Fri, 20 Apr 2001, Thomas Heller wrote:

> > Here's something to start the fight ;-) ...
> >
> > 1) What would you do with class methods that you cannot do with
> >    e.g. globals and functions ?
>
> I will write up a concrete example I have and post it later.

There are a number of reasons why I'm all for Class attributes in general.
For example, right now a class object cannot assert an interface.  Sure,
a class can say:

class Foo:

  __implements__ = Bar  # instances implement Bar

but that is an assertion for the instances, not the *class itself*.
Currently, you have to do the ugly hack:

class Foo:

  __class_implements__ = FooFactory # the class implements
                                    # FooFactory.

We've done things like the above in several places in our underground
component elaboration.  Not having class methods introduces many little
wrinkles in the Python object model that have to be worked around.  I can
imagine, for example, wanting to define an __reduce__, or __init__ for a
class object, which is not possible now.

> Look into the motivation for the Prototype Pattern in the GOF
> book, or even better in the discussion of this pattern in the
> 'Design Pattern Smalltalk Companion' book.
>
> This pattern is not needed if classes are 'first class' objects.
>
> >
> > 2) How would you determine which methods are class-only methods and
> >    which are one usable by instances ?
> This is one of the issues which has to be resolved. I have no proposal
> at the moment. (Maybe function attributes can help here?)

I always thought along the lines of saying Class.instanceAttribute('foo')
in the place of what is now said Class.foo.  This would, of course, break
code, but the warning and back to the future features mitigate most of
that risk.

> >
> > 3) If you don't like globals (see 1), wouldn't it be possible to
> >    store the state you want to manipulate using class methods
> >    in some other context object ?
> I want the class methods (for example) to create and manipulate
> this 'context object'. This object, however, belongs into the class...
>
> What I want to avoid is
>
>   class X(...):
>       ....
>   initialize(X)

Yes! We use this monstrosity a lot in Zope.

-Michel




From donb at abinitio.com  Fri Apr 20 20:07:09 2001
From: donb at abinitio.com (Donald Beaudry)
Date: Fri, 20 Apr 2001 14:07:09 -0400
Subject: [Python-Dev] Re: Class Methods 
References: <mailman.987779255.16686.python-list@python.org> <027801c0c9c0$2e9081a0$070110ac@deyke.net>
Message-ID: <200104201807.OAA06589@localhost.localdomain>

"Thomas Heller" <thomas.heller at ion-tof.com> wrote,
> There are some signs :-) that Python's object
> model is going to be revised even _before_
> Python 3000.
>
> Is someone willing to join me fighting
> for class methods (I mean 'real' class-methods
> in the Smalltalk style here, _not_ static
> methods like in Java or C++).

A couple of years ago I did this as an extension module.  It might
still be around (I still use it).  Take a look for something called
objectmodule.  It's actually a mechanism for implementing different
object models from within python.  Beware, class methods are just part
of what it is capable of.

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb at init.com                                      Lexington, MA 02421
                  ...So much code, so little time...






From guido at digicool.com  Fri Apr 20 21:17:29 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 14:17:29 -0500
Subject: [Python-Dev] Re: Class Methods
In-Reply-To: Your message of "Fri, 20 Apr 2001 14:07:09 -0400."
             <200104201807.OAA06589@localhost.localdomain> 
References: <mailman.987779255.16686.python-list@python.org> <027801c0c9c0$2e9081a0$070110ac@deyke.net>  
            <200104201807.OAA06589@localhost.localdomain> 
Message-ID: <200104201917.OAA11851@cj20424-a.reston1.va.home.com>

> A couple of years ago I did this as an extension module.  It might
> still be around (I still use it).  Take a look for something called
> objectmodule.  It's actually a mechanism for implementing different
> object models from within python.  Beware, class methods are just part
> of what it is capable of.

Hi Don!  I still remember some of the stuff you showed me 6.5 years
ago, and some of the ideas my *finally* find their way into Python...
Watch PEP 252!

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



From paul at pfdubois.com  Fri Apr 20 20:09:20 2001
From: paul at pfdubois.com (Paul F. Dubois)
Date: Fri, 20 Apr 2001 11:09:20 -0700
Subject: [Python-Dev] pydoc script
Message-ID: <ADEOIFHFONCLEEPKCACCGEGJCIAA.paul@pfdubois.com>

Ka-Ping,
Your pydoc script can fail because the pydoc executed is not the pydoc (and
therefore the python) in the users' current path if they start it explicitly
with a full path. I suggest a similar trick to this one:

#!/bin/csh -f
unsetenv PYTHONHOME
set bindir = `dirname $0`
set path=(${bindir} $path);rehash #in case of respawns, get our python
exec ${bindir}/python -O -c 'import browser;browser.tk_cdat.main()'





From Greg.Wilson at baltimore.com  Fri Apr 20 21:20:53 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 15:20:53 -0400
Subject: [Python-Dev] string slicing and method consistency
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com>

One of the students in my class at the Space Telescope
Science Institute ("Hubble R Us") last week brought up
an interesting point: if "abbc"[-1] is "c", and if
"abbc".replace("b", "x", 1) is "axbc", then shouldn't
"abbc".replace("b", "x", -1) be "abxc" (i.e. negative
numbers replace the *last* occurrences of the value)?
Same argument for "split", etc.

Turns out that "abbc".replace("b", "x", -1) is "axxc"
(i.e. negative arguments are ignored).  I would have
expected this to raise a ValueError, if anything.  Is
there a reason for this behavior?  Is it worth making
replace, split, etc. interpret negative indices in the
same way as indexing does?

Thanks,
Greg




From ping at lfw.org  Fri Apr 20 21:57:56 2001
From: ping at lfw.org (Ka-Ping Yee)
Date: Fri, 20 Apr 2001 14:57:56 -0500 (CDT)
Subject: [Python-Dev] string slicing and method consistency
In-Reply-To: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com>
Message-ID: <Pine.LNX.4.10.10104201456460.24864-100000@server1.lfw.org>

On Fri, 20 Apr 2001, Greg Wilson wrote:
> Is it worth making
> replace, split, etc. interpret negative indices in the
> same way as indexing does?

I think this would be really cool in particular for split().
(And if it worked for split it would have to work for replace.)


-- ?!ng




From thomas.heller at ion-tof.com  Fri Apr 20 21:37:41 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 21:37:41 +0200
Subject: [Python-Dev] Re: Class Methods 
References: <mailman.987779255.16686.python-list@python.org> <027801c0c9c0$2e9081a0$070110ac@deyke.net> <200104201807.OAA06589@localhost.localdomain>
Message-ID: <053901c0c9d1$5d8c2f70$e000a8c0@thomasnotebook>

> A couple of years ago I did this as an extension module.  It might
> still be around (I still use it).  Take a look for something called
> objectmodule.  It's actually a mechanism for implementing different
> object models from within python.  Beware, class methods are just part
> of what it is capable of.
> 
Thanks, Don.

I found it and will look into it.

Thomas




From thomas.heller at ion-tof.com  Fri Apr 20 21:51:28 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 20 Apr 2001 21:51:28 +0200
Subject: [Python-Dev] Class Methods
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook><200104201626.LAA06384@cj20424-a.reston1.va.home.com> <15072.25994.247806.815084@anthem.wooz.org>
Message-ID: <055101c0c9d3$4a1b9d20$e000a8c0@thomasnotebook>

> >>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:
> 
>     GvR> Let x be an object, C its class, and M C's class.  So,
> 
>     |   x.__class__ is C
>     |   C.__class__ is M
> 
>     GvR> Then x's methods are described in C.__dict__, and C's methods
>     GvR> are described in M.__dict__.
> 
>     GvR> The problem is that if you write C.spam, there could be two
>     GvR> spams: one in C.__dict__, one in M.__dict__.  Which one to
>     GvR> use?
> 
[Barry wrote]
> If you use naming to generally distinguish, and have a lookup chain
> that first found it in C.__dict__ and then looked in M.__dict__, you
> could control what happens when the name is in both dicts by using a
> more explicit lookup, e.g. C.__dict__['meth']
> vs. C.__class__.__dict__['meth']
> 

Couldn't be C.__class__.meth be used?

> But maybe that's too ugly.
>     
>     GvR> How does Smalltalk resolve this?
I'm walking on thin ice here (maybe I should better try it out),
but IIRC Smalltalk requires to explicit:

    self class method;
or
    self method;

> Another question: presumably when I write
> 
>     class Foo: pass
> 
> Foo is implicitly given the built-in metaclass M, but say I wanted to
> define a class Foo with a different metaclass, how would I spell this?
> I think at one point I suggested a semi-ugly syntactic hack, where
> `class' was actually a namespace and you could add new metaclasses to
> it.  So you could write something like
> 
>     class.WeirdClass Foo: pass
> 
> and now Foo's metaclass would be WeirdClass.
Thin ice again I'm on here (even more), but I have the impression
that creating a class Point in Smalltalk _automatically_ creates
two classes: Point and PointClass. The latter is normally hidden
(but contains the class methods of Point as instance methods).

Thomas




From Greg.Wilson at baltimore.com  Fri Apr 20 22:07:26 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 16:07:26 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D1E7@nsamcanms1.ca.baltimore.com>

> > Thomas Heller:
> > PS: I find it strange that everyone so far seems to be against it.

> Tim Peters:
> I didn't get that sense yet.  I did get the sense they're not 
> actively *for* it yet, and the questions asked so far explain why:
> What does it buy us?

Greg Wilson:
I'd really like class methods so that my classes can carry their
factory methods around with them, and so that these factories can
be selectively overridden in derived classes.  I have machinery
to do all of this using freestanding functions, but it's clumsy
and error-prone.  Of course, so is a lot of my code... :-)



From michel at digicool.com  Fri Apr 20 22:32:43 2001
From: michel at digicool.com (Michel Pelletier)
Date: Fri, 20 Apr 2001 13:32:43 -0700 (PDT)
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.32.0104201310270.6561-100000@localhost.localdomain>

On Fri, 20 Apr 2001, Guido van Rossum wrote:

> Let x be an object, C its class, and M C's class.  So,
>
>   x.__class__ is C
>   C.__class__ is M
>
> Then x's methods are described in C.__dict__, and C's methods are
> described in M.__dict__.
>
> The problem is that if you write C.spam, there could be two spams: one
> in C.__dict__, one in M.__dict__.  Which one to use?

I think, at the expense of breaking code, M.

> How does
> Smalltalk resolve this?  The problem is that for backwards
> compatibility, at lease, C.spam must be the unbound version of x.spam,
> because currently x.spam(...) can always also be written as
> C.spam(x, ...).

This is the part that choosing M would break.  To get at C's shared
instance attributes you could say something like
C.instanceAttribute('spam')(x, ...).

Yes, it's ugly.  Perhaps someone can think of a more elegant spelling?

> For regular methods it may be possible to avoid this simply by
> choosing non-conflicting names, but I seem to recall that Jim wanted
> to use class methods with certain special names (like __init__ or
> __getattr__?), and I have no idea how to do this without dropping the
> idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
> solution?

I'm not sure which idea you are talking about dropping, the first argument
binding behavior, or the spelling of getting shared instance attributes
from a class (C.spam).  Just asking to make sure, cuz I don't think the
first needs to change, just the spelling.

BTW, you sent me some comments on the Components and Interfaces chapter
of the Zope Developer's Guide where you noted that attributes of interface
objects are not the attributes described by the interface and that this is
"unfamiliar to the typical python programmer", ie:

  interface Hello:

    def hello(name):
      """ say hello to a name """

does not create a 'Hello.hello'.  Instead, you need to say
"Hello.getDescriptionFor('hello')".  If we chose the more familiar
'Hello.hello' then the interface interface would be seriously limited, and
any added functionality would need to be imported from an external module
or be a builtin like isinstance().  Interfaces, like classes, wouldn't be
able to have their own methods.

-Michel











From tim.one at home.com  Fri Apr 20 22:40:27 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 20 Apr 2001 16:40:27 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
In-Reply-To: <930BBCA4CEBBD411BE6500508BB3328F22D1E7@nsamcanms1.ca.baltimore.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com>

[Greg Wilson]
> I'd really like class methods so that my classes can carry their
> factory methods around with them, and so that these factories can
> be selectively overridden in derived classes.

Without a concrete example it's risky to guess, but that sounds more like
class static (in C++ terms) methods to me.  "class methods" in *this* thread
is being used in a Smalltalk sense (because it's Thomas Heller's thread, and
he made clear that he doesn't want C++-style class statics).  And, yes,
without a concrete example, it's risky to guess what that means too <wink>.

expecting-a-long-thread-full-of-misinterpreted-words-ly y'rs  - tim




From guido at digicool.com  Fri Apr 20 23:48:06 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 16:48:06 -0500
Subject: [Python-Dev] string slicing and method consistency
In-Reply-To: Your message of "Fri, 20 Apr 2001 15:20:53 -0400."
             <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com> 
References: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com> 
Message-ID: <200104202148.QAA13960@cj20424-a.reston1.va.home.com>

[GVW]
> One of the students in my class at the Space Telescope
> Science Institute ("Hubble R Us") last week brought up
> an interesting point: if "abbc"[-1] is "c", and if
> "abbc".replace("b", "x", 1) is "axbc", then shouldn't
> "abbc".replace("b", "x", -1) be "abxc" (i.e. negative
> numbers replace the *last* occurrences of the value)?
> Same argument for "split", etc.
> 
> Turns out that "abbc".replace("b", "x", -1) is "axxc"
> (i.e. negative arguments are ignored).  I would have
> expected this to raise a ValueError, if anything.  Is
> there a reason for this behavior?  Is it worth making
> replace, split, etc. interpret negative indices in the
> same way as indexing does?

Dubious hypergeneralization.  The thing is that this parameter, called
maxsplit, is not really an index -- it's a count.

Implementing this right would be tricky, because you'd really have to
search for matches from the end (in order to make sense if there are
overlapping matches possible, as in "abbbc".replace("bb", "BB", -1)).

Where would this be useful?  Is it ever useful for numbers smaller
than -1?  If all you typically want is replace the last occurrence,
the rfind() method is your friend.

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



From Greg.Wilson at baltimore.com  Fri Apr 20 23:08:31 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Fri, 20 Apr 2001 17:08:31 -0400
Subject: [Python-Dev] re: string slicing and method consistency
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D1F5@nsamcanms1.ca.baltimore.com>

> > Greg Wilson:
> > if "abbc"[-1] is "c", and if
> > "abbc".replace("b", "x", 1) is "axbc", then shouldn't
> > "abbc".replace("b", "x", -1) be "abxc" (i.e. negative
> > numbers replace the *last* occurrences of the value)?
> > Same argument for "split", etc.

> Guido van Rossum:
> Dubious hypergeneralization.

Greg Wilson:
Do you have an editor macro set up yet to generate that
phrase? :-)

> Guido van Rossum:
> The thing is that this parameter,
> called maxsplit, is not really an index -- it's a count.

Greg Wilson:
Understood; I'm asking whether changing its name and
interpretation (in a way that doesn't break any existing
code) would be worthwhile:

    >>> path = "/some/long/path/to/file.html"
    >>> main, parent, file = path.split("/", -2)
    >>> main
    "/some/long/path"
    >>> parent
    "to"
    >>> file
    "file.html"

> > Greg Wilson:
> > Turns out that "abbc".replace("b", "x", -1) is "axxc"
> > (i.e. negative arguments are ignored).  I would have
> > expected this to raise a ValueError, if anything.  Is
> > there a reason for this behavior?

Greg Wilson again:
Question still stands --- if these are counts, then shouldn't
negative values raise exceptions?

Thanks,
Greg



From guido at digicool.com  Sat Apr 21 00:19:50 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 20 Apr 2001 17:19:50 -0500
Subject: [Python-Dev] re: string slicing and method consistency
In-Reply-To: Your message of "Fri, 20 Apr 2001 17:08:31 -0400."
             <930BBCA4CEBBD411BE6500508BB3328F22D1F5@nsamcanms1.ca.baltimore.com> 
References: <930BBCA4CEBBD411BE6500508BB3328F22D1F5@nsamcanms1.ca.baltimore.com> 
Message-ID: <200104202219.RAA14666@cj20424-a.reston1.va.home.com>

> > Guido van Rossum:
> > Dubious hypergeneralization.
> 
> Greg Wilson:
> Do you have an editor macro set up yet to generate that
> phrase? :-)

No, I actually know how to spell that. :-)

> Greg Wilson:
> Understood; I'm asking whether changing its name and
> interpretation (in a way that doesn't break any existing
> code) would be worthwhile:
> 
>     >>> path = "/some/long/path/to/file.html"
>     >>> main, parent, file = path.split("/", -2)
>     >>> main
>     "/some/long/path"
>     >>> parent
>     "to"
>     >>> file
>     "file.html"

OK, that's an example.  It's only so-so, because you should be using
os.path.split() anyway.  It's done best as follows:

  temp, file = os.path.split(path)
  main, parent = os.path.split(temp)

> > > Greg Wilson:
> > > Turns out that "abbc".replace("b", "x", -1) is "axxc"
> > > (i.e. negative arguments are ignored).  I would have
> > > expected this to raise a ValueError, if anything.  Is
> > > there a reason for this behavior?
> 
> Greg Wilson again:
> Question still stands --- if these are counts, then shouldn't
> negative values raise exceptions?

Given that it's documented with the name "maxsplit", it's not
unreasonable that -1 is treated the same as 0.

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



From donb at abinitio.com  Fri Apr 20 23:19:56 2001
From: donb at abinitio.com (Donald Beaudry)
Date: Fri, 20 Apr 2001 17:19:56 -0400
Subject: [Python-Dev] Class Methods 
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook><200104201626.LAA06384@cj20424-a.reston1.va.home.com> <15072.25994.247806.815084@anthem.wooz.org> <055101c0c9d3$4a1b9d20$e000a8c0@thomasnotebook>
Message-ID: <200104202119.RAA08382@localhost.localdomain>

"Thomas Heller" <thomas.heller at ion-tof.com> wrote,
> > >>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:
> > 
> >     GvR> Let x be an object, C its class, and M C's class.  So,
> > 
> >     |   x.__class__ is C
> >     |   C.__class__ is M
> > 
> >     GvR> Then x's methods are described in C.__dict__, and C's methods
> >     GvR> are described in M.__dict__.
> > 
> >     GvR> The problem is that if you write C.spam, there could be two
> >     GvR> spams: one in C.__dict__, one in M.__dict__.  Which one to
> >     GvR> use?

In my 'objectmodule' I adopted a concept which I refer to as the
"unbound instance".  That is, I invented an object which is used as a
proxy for accessing instance attributes.  It looks like an instance
but only for the purposes of attribute access.  Now, since this object
will only return "unbound method objects" when accessing a method (as
opposed to the "bound method object" you would get when accessing a
method from a real instance) I thought the name was at least slightly
appropriate.  In short, each class defined by the objectmodule has a
special attribute '_' which is the "unbound instance" for that class.
This unbound instance is used to resolve the name ambiguity.  Now,
consider this:

    import object

    class foo(object.base):
        def frob(self):
            print "I've been frobbed", self

        class __class__:
            def frob(cl):
                print "No, I've been frobbed", cl


    >>> f = foo()
    >>> x = f.frob
    >>> # x is the instance frob method bound to f
    >>> y = foo.frob
    >>> # y is the class frob method bound to foo
    >>> z = foo._.frob
    >>> # z is the instance frob method but is not bound to any instance
    >>> huh = foo.__class__._.frob
    >>> # huh is the class frob method but is not bound to any class
    >>>        

> Thin ice again I'm on here (even more), but I have the impression
> that creating a class Point in Smalltalk _automatically_ creates two
> classes: Point and PointClass. The latter is normally hidden (but
> contains the class methods of Point as instance methods).

That's the way I remember it too.  And, (if I recall correctly) in
SmallTalk (unlike CLOS), you have no control over the meta-class.  In
the example above, like in SmallTalk, the name of foo.__class__ is
determined automatically.  In this case it is 'foo_class'.  However,
unlike SmallTalk, the above example could be extended to include a
'class __class__:' definition under the existing 'class __class__:'.
The name generated by this construct would, of course, be
'foo_class_class'.  Lather, Rinse, repeat...

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb at init.com                                      Lexington, MA 02421
                      ...Will hack for sushi...



From moshez at zadka.site.co.il  Sat Apr 21 02:32:57 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Sat, 21 Apr 2001 03:32:57 +0300
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
References: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>, <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook>
Message-ID: <E14qlKb-0005G4-00@darjeeling>

On Fri, 20 Apr 2001 11:26:01 -0500, Guido van Rossum <guido at digicool.com> wrote:
 
> For regular methods it may be possible to avoid this simply by
> choosing non-conflicting names, but I seem to recall that Jim wanted
> to use class methods with certain special names (like __init__ or
> __getattr__?), and I have no idea how to do this without dropping the
> idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
> solution?

class A:

    def __init__(self):
        self.spam = 1

class B:

    def __init__(self):
        A.__init__(self)
        self.eggs = 2

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From Jason.Tishler at dothill.com  Sat Apr 21 02:50:58 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Fri, 20 Apr 2001 20:50:58 -0400
Subject: [Python-Dev] Re: Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <Pine.LNX.4.21.0104201933470.11150-100000@clarkevans.com>; from cce@clarkevans.com on Fri, Apr 20, 2001 at 07:37:01PM -0500
References: <20010417151219.T275@dothill.com> <Pine.LNX.4.21.0104201933470.11150-100000@clarkevans.com>
Message-ID: <20010420205058.A1403@dothill.com>

On Fri, Apr 20, 2001 at 07:37:01PM -0500, Clark C. Evans wrote:
> On Tue, 17 Apr 2001, Jason Tishler wrote:
> > I have contributed Python to the standard Cygwin distribution.  Cygwin
> > Python is located in the contrib/python directory on the Cygwin mirrors.
> > Cygwin's setup.exe will automatically install Cygwin Python the next
> > time one installs or updates from a mirror.
> 
> This is interesting.  From what I understand, if you link
> against cygwin.dll, the software must be released under
> the GPL.  Thus, is the licensing debate over?  Do you
> have the right to re-license python under the GPL? Or am
> I missing something fundmental here? 
> 
> $ objdump -p python2.1.exe | grep DLL
>  vma:            Hint    Time      Forward  DLL       First
>         DLL Name: KERNEL32.dll
>         DLL Name: cygwin1.dll
>         DLL Name: libpython2.1.dll
> 
> Sorry to bring this up... I'm just curious.

Clark brings up a valid point.  Did I screw up from a licensing point
of view?

I found the following on the Python web site:

    However, we expect that Python 2.0 and later versions, released by
    BeOpen PythonLabs, will be released under a GPL-compatible license.

IANAL, any guidance regarding this matter would be greatly appreciated.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From tim.one at home.com  Sat Apr 21 03:32:05 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 20 Apr 2001 21:32:05 -0400
Subject: [Python-Dev] Re: Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <20010420205058.A1403@dothill.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOELBJNAA.tim.one@home.com>

[Clark C. Evans]
> This is interesting.  From what I understand, if you link
> against cygwin.dll, the software must be released under
> the GPL.  Thus, is the licensing debate over?  Do you
> have the right to re-license python under the GPL? Or am
> I missing something fundmental here?

[Jason Tishler]
> Clark brings up a valid point.  Did I screw up from a licensing point
> of view?
>
> I found the following on the Python web site:
>
>   However, we expect that Python 2.0 and later versions, released
>   by BeOpen PythonLabs, will be released under a GPL-compatible
>   license.

According to CNRI's and BeOpen's lawyers, it was; according to the FSF's Eben
Moglen, it was not.

> IANAL,

Ditto, and I'm worn out trying to divine the FSF's position.  Since you're in
no danger of violating *our* license, I'm afraid we're the wrong people to
ask.  If you can get a straight answer out of the FSF, more power to you.

> any guidance regarding this matter would be greatly appreciated.

In this specific case, you may be able to cut it short:

    http://www.cygwin.com/licensing.html

According to that, they use the GPL, but ammend it according to GPL section
10:

    In accordance with section 10 of the GPL, Cygnus permits
    programs whose sources are distributed under a license that
    complies with the Open Source definition to be linked with
    libcygwin.a without libcygwin.a itself causing the resulting
    program to be covered by the GNU GPL.

    This means that you can port an Open Source(tm) application
    to cygwin, and distribute that executable as if it didn't
    include a copy of libcygwin.a linked into it. Note that this
    does not apply to the cygwin DLL itself. If you distribute a
    (possibly modified) version of the DLL you must adhere to the
    terms of the GPL, i.e., you must provide sources for the cygwin
    DLL.

There's no controversy over whether all Python licenses to date are Open
Source -- they are.  There's also no problem from the POV of the *Python*
license if you want to relicense Cygwin Python under the GPL.  Fine by us!
The only relevant party with a complaint against you *may* be the FSF.





From tim.one at home.com  Sat Apr 21 09:51:09 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 21 Apr 2001 03:51:09 -0400
Subject: [Python-Dev] Importing DLLs on Windows
In-Reply-To: <3ADE1A5F.F574B613@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMAJNAA.tim.one@home.com>

Sorry for the delay -- I had a hard time understanding what this writeup
meant, so had to download the package and try it.

[M.-A. Lemburg]
> Python or Windows seems to have trouble importing DLLs when
> inside packages. I'm working on an extension which pulls in a
> DLL gmp31.dll which lives inside a package dir mx/Number/mxNumber
> along side the Python wrapper extension mxNumber.pyd.

Concretely, I have these files now, under my Python 2.1 installation
directory:

C:\Python21>dir/b/on mx\Number\mxNumber
gmp31.dll
mxNumber.pyd
mxNumber.h
test.py
__init__.py

C:\Python21>

> Currently, I'm using this code in the subpackage's __init__.py:

And by "the subpackage" here I believe you mean the tail-end mxNumber
directory, previously called "a package".  IOW, you're talking specifically
about

    \Python21\mx\Number\mxNumber\__init__.py

If you meant something else, scream.

> # On Windows we also distribute the GMP DLL (in the win32 subdir). To
> # have Win32 find the DLL we need to be explicit about the path in
> # sys.path though. This trick works for all startup directories
> # *except* \PythonXX (for some reason this fails), but is not thread
> # safe...
> import sys, os
> if sys.platform[:3] == 'win':
>     abspath = os.path.abspath(__path__[0])
>     sys.path.insert(0, abspath)
>     from mxNumber import *
>     sys.path.remove(abspath)
>
> else:
>     from mxNumber import *

> I don't have any clue why the import works

Which import are you talking about?  Please show exactly what you do that
fails -- I haven't been able to find any problem here.  For example, I
replaced

    \Python21\mx\Number\mxNumber\__init__.py

which contains the code you showed above, with this two-liner:

from mxNumber import *
from mxNumber import __version__

Having done that, here's a shell session started in the installation
directory, and after a reboot "just to make sure":

C:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> from mx.Number import *
>>> Integer(928349238479328749L)**2
861832308585149602001042573617905001
>>>

So nothing failed.  What do *you* do that fails?  Here's another session
started from a "random" directory:

C:\Code>\python21\python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> from mx.Number import *
>>> Integer(92387498327493243879L)**2
8535449847212566935021074270390170966641
>>>

Same thing.

> from everywhere *except* the Python21 install directory...

It would more helpful to name a specific directory than to make an untrue
claim <wink -- but you didn't try every directory other than Python21, and
the specific directories you actually did try may be important>.

BTW, it's a mondo cool package!  I had a lot of fun with it.  But then I was
able to, since I stopped trying to guess what your problem was <wink>.
What's up?  I was running Win98SE in the above, but that shouldn't make a
difference.  Perhaps, during development, you left crap sitting around in
your installation directory that's confusing your attempts to import things?
If not, please be very explicit about what you do that fails, and what
"fails" means (crash, ImportError, Windows error box, ...?).




From tim.one at home.com  Sat Apr 21 11:51:42 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 21 Apr 2001 05:51:42 -0400
Subject: [Python-Dev] Suirprise!
Message-ID: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com>

I just stared at this a long time:

>>> 'a' in 'a'  # fine
1
>>> 'a' in 'a' == 1  # what?
0
>>> 'a' in 'b'  # fine
0
>>> 'a' in 'b' == 0  # what?
0
>>>

It's "correct".  I've been using Python longer than Guido <wink>, and I'm
amazed this is the first time I got bit by this!  Here's a hint:

>>> 'a' in 'a' == 'a'
1
>>>

thank-god-for-dis.dis-ly y'rs  - tim




From martin at loewis.home.cs.tu-berlin.de  Sat Apr 21 11:51:56 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 21 Apr 2001 11:51:56 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
Message-ID: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de>

Currently, a number of routines assume that the result of
PyUnicode_FromUnicode can be modified, i.e. they mutate the resulting
unicode object. Look at unicodeobject.c:fixup for an example, and
assume that fixfct is fixtitle (*).

This is different from PyString_FromStringAndSize, whose result can be
only modified if the str argument is NULL.

These routines broke after I applied my caching patch, since now
PyUnicode_FromUnicode may return an existing string.

Is that difference intentional? My feeling is that it is an error to
modify a unicode object, unless it is known not to be initialized.

Regards,
Martin

P.S. This was actually the first failure case when running
test_unicodedata under my patch.



From mal at lemburg.com  Sat Apr 21 12:35:00 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 12:35:00 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEMAJNAA.tim.one@home.com>
Message-ID: <3AE16254.FFE9ADF7@lemburg.com>

Tim Peters wrote:
> 
> Sorry for the delay -- I had a hard time understanding what this writeup
> meant, so had to download the package and try it.

Oh, sorry that I wasn't clear enough. Referring to the mxNumber
package, I am seeing this situation:

# This works... (note the start directory)

C:\WINDOWS>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>

# This doesn't.... (from the Python install directory)

D:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "d:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "d:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
    from mxNumber import *
ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser Anwendung notwen
dige Bibliothekdateien kann nicht gefunden werden.
>>>

# OTOH, this works.... (one level below the Python install directory)

D:\Python21>cd mx

D:\Python21\mx>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>>
 
> [M.-A. Lemburg]
> > Python or Windows seems to have trouble importing DLLs when
> > inside packages. I'm working on an extension which pulls in a
> > DLL gmp31.dll which lives inside a package dir mx/Number/mxNumber
> > along side the Python wrapper extension mxNumber.pyd.
> 
> Concretely, I have these files now, under my Python 2.1 installation
> directory:
> 
> C:\Python21>dir/b/on mx\Number\mxNumber
> gmp31.dll
> mxNumber.pyd
> mxNumber.h
> test.py
> __init__.py
> 
> C:\Python21>
> 
> > Currently, I'm using this code in the subpackage's __init__.py:
> 
> And by "the subpackage" here I believe you mean the tail-end mxNumber
> directory, previously called "a package".  IOW, you're talking specifically
> about
> 
>     \Python21\mx\Number\mxNumber\__init__.py

Right.
 
> If you meant something else, scream.
>
> > # On Windows we also distribute the GMP DLL (in the win32 subdir). To
> > # have Win32 find the DLL we need to be explicit about the path in
> > # sys.path though. This trick works for all startup directories
> > # *except* \PythonXX (for some reason this fails), but is not thread
> > # safe...
> > import sys, os
> > if sys.platform[:3] == 'win':
> >     abspath = os.path.abspath(__path__[0])
> >     sys.path.insert(0, abspath)
> >     from mxNumber import *
> >     sys.path.remove(abspath)
> >
> > else:
> >     from mxNumber import *
> 
> > I don't have any clue why the import works
> 
> Which import are you talking about?  Please show exactly what you do that
> fails -- I haven't been able to find any problem here.  For example, I
> replaced
> 
>     \Python21\mx\Number\mxNumber\__init__.py
> 
> which contains the code you showed above, with this two-liner:
> 
> from mxNumber import *
> from mxNumber import __version__
> 
> Having done that, here's a shell session started in the installation
> directory, and after a reboot "just to make sure":
> 
> C:\Python21>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> from mx.Number import *
> >>> Integer(928349238479328749L)**2
> 861832308585149602001042573617905001
> >>>
> 
> So nothing failed. 

Hmm, you are right, it does work for me too (I wonder why I
thought it failed without the sys.path tweaking... probably
just tested from the Python install dir):

C:\WINDOWS>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>
C:\WINDOWS>d:

D:\Python21\mx>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>
D:\Python21\mx>cd ..

D:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "d:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "d:\python21\mx\Number\mxNumber\__init__.py", line 11, in ?
    from mxNumber import *
ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser Anwendung notwen
dige Bibliothekdateien kann nicht gefunden werden.
>>>

> What do *you* do that fails?  Here's another session
> started from a "random" directory:
> 
> C:\Code>\python21\python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> from mx.Number import *
> >>> Integer(92387498327493243879L)**2
> 8535449847212566935021074270390170966641
> >>>
> 
> Same thing.
> 
> > from everywhere *except* the Python21 install directory...
> 
> It would more helpful to name a specific directory than to make an untrue
> claim <wink -- but you didn't try every directory other than Python21, and
> the specific directories you actually did try may be important>.

Ok, ok ;-)

Please try starting Python from your Python install dir and
then do the import. BTW, I'm doing this on Windows 95 in case
this matters (which I'm sure it does :-/).
 
> BTW, it's a mondo cool package!  I had a lot of fun with it. 

Thanks :)

> But then I was
> able to, since I stopped trying to guess what your problem was <wink>.
> What's up?  I was running Win98SE in the above, but that shouldn't make a
> difference.  Perhaps, during development, you left crap sitting around in
> your installation directory that's confusing your attempts to import things?
> If not, please be very explicit about what you do that fails, and what
> "fails" means (crash, ImportError, Windows error box, ...?).

"fail" means that Python cannot find the gmp31.dll sitting right
next to the mxNumber.pyd in the same directory. This should normally
work, but somehow doesn't when Python is started from the install
dir:

>>> import mx.Number
import mx # directory mx
# trying mx\__init__.pyd
# trying mx\__init__.dll
# trying mx\__init__.py
# mx\__init__.pyc matches mx\__init__.py
import mx # precompiled from mx\__init__.pyc
import mx.Number # directory mx\Number
# trying mx\Number\__init__.pyd
# trying mx\Number\__init__.dll
# trying mx\Number\__init__.py
# mx\Number\__init__.pyc matches mx\Number\__init__.py
import mx.Number # precompiled from mx\Number\__init__.pyc
# trying mx\Number\Number.pyd
# trying mx\Number\Number.dll
# trying mx\Number\Number.py
# mx\Number\Number.pyc matches mx\Number\Number.py
import mx.Number.Number # precompiled from mx\Number\Number.pyc
import mx.Number.mxNumber # directory mx\Number\mxNumber
# trying mx\Number\mxNumber\__init__.pyd
# trying mx\Number\mxNumber\__init__.dll
# trying mx\Number\mxNumber\__init__.py
# mx\Number\mxNumber\__init__.pyc matches mx\Number\mxNumber\__init__.py
import mx.Number.mxNumber # precompiled from mx\Number\mxNumber\__init__.pyc
# trying mx\Number\mxNumber\mxNumber.pyd
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "d:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "d:\python21\mx\Number\mxNumber\__init__.py", line 11, in ?
    from mxNumber import *
ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser Anwendung notwen
dige Bibliothekdateien kann nicht gefunden werden.
>>>


From guido at digicool.com  Sat Apr 21 13:42:09 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 21 Apr 2001 06:42:09 -0500
Subject: [Python-Dev] Suirprise!
In-Reply-To: Your message of "Sat, 21 Apr 2001 05:51:42 -0400."
             <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com> 
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com> 
Message-ID: <200104211142.GAA17114@cj20424-a.reston1.va.home.com>

> I just stared at this a long time:
> 
> >>> 'a' in 'a'  # fine
> 1
> >>> 'a' in 'a' == 1  # what?
> 0
> >>> 'a' in 'b'  # fine
> 0
> >>> 'a' in 'b' == 0  # what?
> 0
> >>>
> 
> It's "correct".  I've been using Python longer than Guido <wink>, and I'm
> amazed this is the first time I got bit by this!  Here's a hint:
> 
> >>> 'a' in 'a' == 'a'
> 1
> >>>
> 
> thank-god-for-dis.dis-ly y'rs  - tim

Yeah, I ran into the same when converting some has_key() tests to
using 'in'.  I guess it's not very common since nobody in their right
minds should want to compare the result of an 'in' test to anything
else.  The has_key() tests did something like "assert d.has_key(k)==1"
and the mindless translation of that is "assert k in d == 1"...

Didn't-need-dis-though-ly y'rs,

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



From mal at lemburg.com  Sat Apr 21 12:43:10 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 12:43:10 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de>
Message-ID: <3AE1643E.28E41AC2@lemburg.com>

"Martin v. Loewis" wrote:
> 
> Currently, a number of routines assume that the result of
> PyUnicode_FromUnicode can be modified, i.e. they mutate the resulting
> unicode object. Look at unicodeobject.c:fixup for an example, and
> assume that fixfct is fixtitle (*).

This is true for the APIs in unicodeobject.c: as long as the newly
created object hasn't "left" the Unicode implementation, the APIs
in there are free to modify the otherwise immutable object.
 
> This is different from PyString_FromStringAndSize, whose result can be
> only modified if the str argument is NULL.
> 
> These routines broke after I applied my caching patch, since now
> PyUnicode_FromUnicode may return an existing string.
> 
> Is that difference intentional? My feeling is that it is an error to
> modify a unicode object, unless it is known not to be initialized.

It is an error, but only for code outside the implementation, i.e.
programs using the public API may only modify the contents when
calling PyUnicode_FromUnicode() with NULL as u argument.

Sorry for not remembering this when reviewing your patch on SF.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From paulp at ActiveState.com  Sat Apr 21 12:48:08 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Sat, 21 Apr 2001 03:48:08 -0700
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com>
Message-ID: <3AE16568.79763FDD@ActiveState.com>

Tim Peters wrote:
> 
>...
> 
> >>> 'a' in 'a' == 'a'
> 1
> >>>
> 
> thank-god-for-dis.dis-ly y'rs  - tim

[potential spoilers below]

No, thank Jeremy for Compiler:

Module(None, 
    Stmt(
        [
            Printnl(
                [
                    Compare(Const('a'), 
                        [
                            ('in', Const('abcde')), 
                            ('==', Const('abcde'))
                        ]
                    )
                ], 
                None
            )
        ]
    )
)

It still took a look at the ref manual for me to figure it out.

It looks like dubious hypergeneralization to me! <0.7 wink> Seriously,
does this "feature" ever make sense to apply to the in operator?

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From Jason.Tishler at dothill.com  Sat Apr 21 13:43:12 2001
From: Jason.Tishler at dothill.com (Jason Tishler)
Date: Sat, 21 Apr 2001 07:43:12 -0400
Subject: [Python-Dev] Re: Cygwin Python Distribution (was ANNOUNCE: Python 2.1 final release)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOELBJNAA.tim.one@home.com>; from tim.one@home.com on Fri, Apr 20, 2001 at 09:32:05PM -0400
References: <20010420205058.A1403@dothill.com> <LNBBLJKPBEHFEDALKOLCOELBJNAA.tim.one@home.com>
Message-ID: <20010421074312.B351@dothill.com>

Tim,

Thanks for your assessment of the situation.  I'm forwarding your
email to the Cygwin list to see what they have to say.  Your help is
much appreciated.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler at dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com



From martin at loewis.home.cs.tu-berlin.de  Sat Apr 21 14:07:14 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 21 Apr 2001 14:07:14 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
In-Reply-To: <3AE1643E.28E41AC2@lemburg.com> (mal@lemburg.com)
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com>
Message-ID: <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de>

> This is true for the APIs in unicodeobject.c: as long as the newly
> created object hasn't "left" the Unicode implementation, the APIs
> in there are free to modify the otherwise immutable object.

That means that PyUnicode_FromUnicode does give a guarantee to return
a fresh object, right?

Then I cannot understand why it only gives this guarantee to callers
inside unicodeobject.c, and not to other callers...

Regards,
Martin



From mal at lemburg.com  Sat Apr 21 15:15:00 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 15:15:00 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com> <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de>
Message-ID: <3AE187D4.FBF0AD3E@lemburg.com>

"Martin v. Loewis" wrote:
> 
> > This is true for the APIs in unicodeobject.c: as long as the newly
> > created object hasn't "left" the Unicode implementation, the APIs
> > in there are free to modify the otherwise immutable object.
> 
> That means that PyUnicode_FromUnicode does give a guarantee to return
> a fresh object, right?

Let's put it this way: the internals in unicodeobject.c are
allowed to modify the contents of the object even if it was
prefilled with data that came from an initializer. External
caller are not allowed to do this though unless u is set to
NULL (just like in the corresponding string call).
 
> Then I cannot understand why it only gives this guarantee to callers
> inside unicodeobject.c, and not to other callers...

Because I want to reserve the right to change the semantics
*inside* unicodeobject.c at some later point. Note that currently
no caching of Unicode objects takes place, but this could change
in the future and indeed your patch starts into this direction.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From martin at loewis.home.cs.tu-berlin.de  Sat Apr 21 15:25:45 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 21 Apr 2001 15:25:45 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
In-Reply-To: <3AE187D4.FBF0AD3E@lemburg.com> (mal@lemburg.com)
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com> <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de> <3AE187D4.FBF0AD3E@lemburg.com>
Message-ID: <200104211325.f3LDPjh16199@mira.informatik.hu-berlin.de>

> Because I want to reserve the right to change the semantics
> *inside* unicodeobject.c at some later point. Note that currently
> no caching of Unicode objects takes place, but this could change
> in the future and indeed your patch starts into this direction.

So would you accept a patch that corrects all calls to
PyUnicode_FromUnicode which modify the result they get, without having
passed a NULL str argument?

Regards,
Martin



From mal at lemburg.com  Sat Apr 21 15:37:53 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Apr 2001 15:37:53 +0200
Subject: [Python-Dev] Modifying the PyUnicode_FromUnicode result
References: <200104210951.f3L9pue14462@mira.informatik.hu-berlin.de> <3AE1643E.28E41AC2@lemburg.com> <200104211207.f3LC7Et15056@mira.informatik.hu-berlin.de> <3AE187D4.FBF0AD3E@lemburg.com> <200104211325.f3LDPjh16199@mira.informatik.hu-berlin.de>
Message-ID: <3AE18D31.FDA78CD4@lemburg.com>

"Martin v. Loewis" wrote:
> 
> > Because I want to reserve the right to change the semantics
> > *inside* unicodeobject.c at some later point. Note that currently
> > no caching of Unicode objects takes place, but this could change
> > in the future and indeed your patch starts into this direction.
> 
> So would you accept a patch that corrects all calls to
> PyUnicode_FromUnicode which modify the result they get, without having
> passed a NULL str argument?

Yes :)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From barry at digicool.com  Sat Apr 21 17:57:57 2001
From: barry at digicool.com (Barry A. Warsaw)
Date: Sat, 21 Apr 2001 11:57:57 -0400
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com>
Message-ID: <15073.44549.140970.32646@anthem.wooz.org>

>>>>> "TP" == Tim Peters <tim.one at home.com> writes:

    TP> It's "correct".  I've been using Python longer than Guido
    TP> <wink>, and I'm amazed this is the first time I got bit by
    TP> this!  Here's a hint:

Oh, that is twisted! :)

Let's throw in some parentheses just to confuse people even more:

>>> 'a' in 'a' == 'a'
1
>>> ('a' in 'a') == 'a'
0
>>> 'a' in ('a' == 'a')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in' or 'not in' needs sequence right argument
>>> 'a' in 'a' == 1
0
>>> ('a' in 'a') == 1
1
>>> 'a' in ('a' == 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in' or 'not in' needs sequence right argument

>>>>> "PP" == Paul Prescod <paulp at ActiveState.com> writes:

    PP> It looks like dubious hypergeneralization to me! <0.7 wink>
    PP> Seriously, does this "feature" ever make sense to apply to the
    PP> in operator?

I don't know; I wonder if "normal" people think of `in' as a chainable
comparison operator or not.  You're not suggesting to change this are
you?

gotta-leave-something-`in'-there-for-job-security-ly y'rs,
-Barry



From gmcm at hypernet.com  Sat Apr 21 19:25:15 2001
From: gmcm at hypernet.com (Gordon McMillan)
Date: Sat, 21 Apr 2001 13:25:15 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <15073.44549.140970.32646@anthem.wooz.org>
Message-ID: <3AE18A3B.24053.47CCB799@localhost>

> >>>>> "TP" == Tim Peters <tim.one at home.com> writes:
> 
>     TP> It's "correct".  I've been using Python longer than Guido
>     TP> <wink>, and I'm amazed this is the first time I got bit
>     by TP> this!  Here's a hint:

[Barry]
> Oh, that is twisted! :)
> 
> Let's throw in some parentheses just to confuse people even more:
...
> gotta-leave-something-`in'-there-for-job-security-ly y'rs,

You're safely employed for years:

>>> 'a' in 'abc' == 1
0
>>> 'a' in 'abc' == 'a'
0
>>> 'a' in 'abc' == 'a' in 'abc'
0

but-a-raise-is-out-of-the-question-ly y'rs

- Gordon



From tim.one at home.com  Sun Apr 22 00:56:30 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 21 Apr 2001 18:56:30 -0400
Subject: [Python-Dev] Iterators, generators and 2.2 (was RE: do...until wisdom needed...)
In-Reply-To: <slrn9e33tr.a5m.neelk@alum.mit.edu>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENMJNAA.tim.one@home.com>

[Aahz]
> Generators (called "iterators") are going to be 2.2.  They'll be
> more powerful that Icon's generators; it's not clear whether they'll
> be a full-fledged substitute for coroutines.

[Neelakantan Krishnaswami]
> {\mr_burns Excellent.}
>
> Is this the iterator idea that Ping posted about a couple of months
> back? What is the PEP number for this? I'm curious how the existing
> iteration protocol will interact with the new iterators.

This is getting confused.  Iterators != generators (sorry, Aahz! it's more
involved than that).

Aahz gave you the PEP number for iterators, and last night Guido checked an
initial implementation into the 2.2 CVS tree.  In Python terms, "for" setup
looks for an __iter__ method first, and if it doesn't find it but does find
__getitem__, builds a lightweight iterator around the __getitem__ method
instead.  So the "for" loop works only with iterators now, but there's an
adapter providing iterators by magic for old sequence objects that don't know
about iterators:

C:\Code\python\dist\src\PCbuild>python
Python 2.2a0 (#16, Apr 20 2001, 23:16:12) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> def f(s):
...     for i in s:
...         print i
...
>>> from dis import dis
>>> dis(f)
          0 SET_LINENO               1

          3 SET_LINENO               2
          6 SETUP_LOOP              25 (to 34)
          9 LOAD_FAST                0 (s)
         12 GET_ITER

    >>   13 SET_LINENO               2
         16 FOR_ITER                14
         19 STORE_FAST               1 (i)

         22 SET_LINENO               3
         25 LOAD_FAST                1 (i)
         28 PRINT_ITEM
         29 PRINT_NEWLINE
         30 JUMP_ABSOLUTE           13
         33 POP_BLOCK
    >>   34 LOAD_CONST               0 (None)
         37 RETURN_VALUE
>>>

The backward compatibility layer described above is hiding in the new
GET_ITER opcode.  Of course builtin lists (and so on) define the iterator
slot directly now, so GET_ITER simply returns their iterator directly.  Loops
are less complicated (internally) now, and run significantly faster.
User-defined types and classes no longer *need* to (ab)use __getitem__ to
implement iteration (which is of particular interest to Greg Wilson right
now, who is implementing a Set class and doesn't *want* to define __getitem__
because it's semantically senseless).

None of that should be controversial in the least.  More controversial is
that iteration over dict keys has been tentatively added (and note that this
is another thing made *possible* by breaking the old connection between
__getitem__ and iteration):

>>> dict = {"one": 1, "two": 2}
>>> for k in dict:
...     print k
...
one
two
>>>

This is significantly faster, and unboundedly more memory-efficient, than
doing "for k in dict.keys()".

The dict.__contains__ slot was also filled in, so that "k in dict" is
synonymous with "dict.has_key(k)", but again runs significantly faster:

>>> "one" in dict
1
>>> "three" in dict
0
>>>

File objects have also grown iterators, so that, e.g.,

    for line in sys.stdin:
        print line

now works.

Iterators can be explicitly materialized too, via the new iter() builltin
function, and invoked apart from the "for" protocol:

>>> i1 = iter(dict)
>>> i1
<dictionary-iterator object at 0079A250>
>>> dir(i1)
['next']
>>> print i1.next.__doc__
it.next() -- get the next value, or raise StopIteration
>>> i2 = iter(dict)
>>> i1.next()
'one'
>>> i2.next()
'one'
>>> i1.next()
'two'
>>> i2.next()
'two'
>>> i1.next()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
StopIteration
>>>

Note that this allows a simple memory-efficient implementation of parallel
sequence iteration too.  For example, this program:

class zipiter:
    def __init__(self, seq1, *moreseqs):
        seqs = [seq1]
        seqs.extend(list(moreseqs))
        self.seqs = seqs

    def __iter__(self):
        self.iters = [iter(seq) for seq in self.seqs]
        return self

    def next(self):
        return [i.next() for i in self.iters]

for i, j, k in zipiter([1, 2, 3], "abc", (5., 6., 7., 8.)):
    print i, j, k

prints

1 a 5.0
2 b 6.0
3 c 7.0


Now all that is just iteration in a thoroughly conventional sense.  There is
no support here for generators or coroutines or microthreads, except in the
sense that breaking the iteration==__getitem__ connection makes it easier to
think about *how* generators may be implemented, and having an explicit
iterator object "should" make it possible to go beyond Icon's notion of
generators (which can only be driven implicitly by control context).

Neil Schemenauer is currently thinking hard about that "in his spare time",
but there's no guarantee anything will come of it in 2.2.  Iterators are a
sure thing, though (not least because they're already implemented!).

not-only-implemented-but-feel-exactly-right-ly y'rs  - tim




From fdrake at beowolf.digicool.com  Sun Apr 22 08:08:22 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Sun, 22 Apr 2001 02:08:22 -0400 (EDT)
Subject: [Python-Dev] [maintenance doc updates]
Message-ID: <20010422060822.A3E4428A0B@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/maint-docs/

First attempt to push maintenance docs to the SourceForge site.




From fdrake at beowolf.digicool.com  Sun Apr 22 08:12:15 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Sun, 22 Apr 2001 02:12:15 -0400 (EDT)
Subject: [Python-Dev] [maintenance doc updates]
Message-ID: <20010422061215.5C87D28A0B@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/maint-docs/

Second attempt to push maintenance docs to the SourceForge site.




From fdrake at beowolf.digicool.com  Sun Apr 22 08:15:52 2001
From: fdrake at beowolf.digicool.com (Fred Drake)
Date: Sun, 22 Apr 2001 02:15:52 -0400 (EDT)
Subject: [Python-Dev] [maintenance doc updates]
Message-ID: <20010422061552.5A99628A0B@beowolf.digicool.com>

The development version of the documentation has been updated:

	http://python.sourceforge.net/maint-docs/

Third attempt to push maintenance docs to the SourceForge site.

Sheesh!




From Greg.Wilson at baltimore.com  Sun Apr 22 14:19:22 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Sun, 22 Apr 2001 08:19:22 -0400
Subject: [Python-Dev] re: string slicing and method consistency
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F22D21B@nsamcanms1.ca.baltimore.com>

> > > Greg Wilson:
> > > if "abbc"[-1] is "c", and if
> > > "abbc".replace("b", "x", 1) is "axbc", then shouldn't
> > > "abbc".replace("b", "x", -1) be "abxc" (i.e. negative
> > > numbers replace the *last* occurrences of the value)?
> > > Same argument for "split", etc.
> >     >>> path = "/some/long/path/to/file.html"
> >     >>> main, parent, file = path.split("/", -2)
> >     >>> main
> >     "/some/long/path"
> >     >>> parent
> >     "to"
> >     >>> file
> >     "file.html"

> > Guido van Rossum:
> OK, that's an example.  It's only so-so, because you should be using
> os.path.split() anyway.  It's done best as follows:
> 
>   temp, file = os.path.split(path)
>   main, parent = os.path.split(temp)

Greg Wilson:
Or "main, parent, file = os.path.split(path, -2)" :-)

> > Greg Wilson again:
> > Question still stands --- if these are counts, then shouldn't
> > negative values raise exceptions?
> 
> Given that it's documented with the name "maxsplit", it's not
> unreasonable that -1 is treated the same as 0.

Greg Wilson:
But it isn't:

>>> print sys.version
2.2a0 (#2, Apr 20 2001, 12:53:03)
[GCC 2.95.2 19991024 (release)]
>>> "abbc".replace("b", "x", 0)
'abbc'
>>> "abbc".replace("b", "x", -1)
'axxc'

Thanks,
Greg



From tim.one at home.com  Mon Apr 23 01:19:19 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 22 Apr 2001 19:19:19 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <200104211142.GAA17114@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEACJOAA.tim.one@home.com>

[Tim, 'a' in 'a' == 1, etc]

[Guido]
> Yeah, I ran into the same when converting some has_key() tests to
> using 'in'.

Bingo!  Same here, but after adding __iter__ and __contains__ to UserDict.py,
then fiddling test_userdict.py to match.

> I guess it's not very common since nobody in their right minds should
> want to compare the result of an 'in' test to anything else.  The
> has_key() tests did something like "assert d.has_key(k)==1"
> and the mindless translation of that is "assert k in d == 1"...

You'd think so <wink>.  It was subtler in the first I bumped into,
translating something like

    assert d1.has_key(k) == d2.has_key(k)

The problem in

    assert k in d1 == k in d2

is, I think, harder to spot.  That is, you may well be in your right might if
you want to compare the result of an 'in' test to the result of *another*
'in' test!

Even stranger,

    assert k in d1 != k in d2

succeeds if and only if k is in both d1 and d2 (assuming d1 is a dict and k
isn't).  I'm going to use that a lot in my code, because it's one less
character than typing

    assert k in d1 and k in d2

Heh heh.

*something*-about-this-may-not-be-ideal-ly y'rs  - tim




From paulp at ActiveState.com  Mon Apr 23 01:52:43 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Sun, 22 Apr 2001 16:52:43 -0700
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCGEMBJNAA.tim.one@home.com> <15073.44549.140970.32646@anthem.wooz.org>
Message-ID: <3AE36ECB.EABBCF46@ActiveState.com>

"Barry A. Warsaw" wrote:
> 
>...
> >>>>> "PP" == Paul Prescod <paulp at ActiveState.com> writes:
> 
>     PP> It looks like dubious hypergeneralization to me! <0.7 wink>
>     PP> Seriously, does this "feature" ever make sense to apply to the
>     PP> in operator?
> 
> I don't know; I wonder if "normal" people think of `in' as a chainable
> comparison operator or not.  

If Tim, Guido, you and I are so completely out of sync with normal
people that they will immediately intuit what we had to think hard
about, we're in deep doo-doo!

> You're not suggesting to change this are
> you?

I suggest a compile-time warning and then eventually we would make "in"
non-chainable. Perhaps it should even have a different precedence than
the other comparison operators. Tim's example looks reasonable to me:

assert k in d1 == k in d2

And it would never, ever make sense to say:

assert k in (d1==k) in d2

So why not interpret it the way that any normal human would:

assert (k in d1) == (k in d2)

I think that this is a subtle flaw in Python that just took a long time
to manifest itself...

And what about "1 is None == 2 is None"? If you saw that in a program
(last week!) what would you have expected it to evalute to? Precedence
levels exist to make code easier to read!
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From tim.one at home.com  Mon Apr 23 02:11:51 2001
From: tim.one at home.com (Tim Peters)
Date: Sun, 22 Apr 2001 20:11:51 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <3AE36ECB.EABBCF46@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEAEJOAA.tim.one@home.com>

[Paul Prescod]
> If Tim, Guido, you and I are so completely out of sync with normal
> people that they will immediately intuit what we had to think hard
> about, we're in deep doo-doo!

Na, we're not, they are:  they're *never* gonna figure it out <wink>.

> I suggest a compile-time warning and then eventually we would make "in"
> non-chainable.

An incompatible language change would, I think, need to go thru the
__future__ (however spelled) business.

> Perhaps it should even have a different precedence than the other
> comparison operators. Tim's example looks reasonable to me:
>
> assert k in d1 == k in d2

It *used* to look reasonable to me too <wink>.

> And it would never, ever make sense to say:
>
> assert k in (d1==k) in d2

Thin ice, there.  __eq__ and __contains__ are both user-definable now, and
there is no limit to how perverse ex-APL'ers can get with this stuff.

> So why not interpret it the way that any normal human would:
>
> assert (k in d1) == (k in d2)

That sounds best to me, but may be too much a bother.  For example, it's not
a stretch at all anymore to believe that someone *is* using

    a in b in c

now deliberately for its

    (a in b) and (b in c)

meaning.  Perfectly natural if, e.g., you use __contains__ to implement an
"is subset of" relation.  If we have to keep chaining for "in", then having
two distinct levels of chaining operators is bound to harbor its own odd
corners.

    x == y in d

I have no idea what that *should* mean, but having gone thru recent related
pain I'm very clear now on what it *does* mean.

> I think that this is a subtle flaw in Python that just took a long time
> to manifest itself...

You can thank Digital Creations for that, too.  They're keeping Guido so busy
that he doesn't have enough time to cloud our minds anymore.  Makes you
wonder how many other surprises he's been hiding from us <wink>!




From paulp at ActiveState.com  Mon Apr 23 05:04:21 2001
From: paulp at ActiveState.com (Paul Prescod)
Date: Sun, 22 Apr 2001 20:04:21 -0700
Subject: [Python-Dev] Suirprise!
References: <LNBBLJKPBEHFEDALKOLCOEAEJOAA.tim.one@home.com>
Message-ID: <3AE39BB5.3B2E276C@ActiveState.com>

Tim Peters wrote:
> 
>...
> 
> > I suggest a compile-time warning and then eventually we would make "in"
> > non-chainable.
> 
> An incompatible language change would, I think, need to go thru the
> __future__ (however spelled) business.

???

My understanding was that __future__ was a way of sneaking in a cool
feature earlier than it would have been possible to deploy it given
strict gradual evolution contraints. But disallowing confusing uses of
"in" is not a feature and nobody is in a big hurry to see it happen. I
wouldn't mind waiting a year or two until everyone has had a chance to
clean up their code.

> ...
> For example, it's not
> a stretch at all anymore to believe that someone *is* using
> 
>     a in b in c
> 
> now deliberately for its
> 
>     (a in b) and (b in c)
> 
> meaning.  Perfectly natural if, e.g., you use __contains__ to implement an
> "is subset of" relation.  

The following grammar would preserve it and outlaw confusing cases:

comparison: in_comparison | is_comparison | math_comparison
math_comparison: expr (math_comp_op expr)*
in_comparison: expr ('in' | 'not' 'in' expr)*
is_comparison: expr ('is' | 'is' 'not' expr)*
math_comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook



From greg at cosc.canterbury.ac.nz  Mon Apr 23 07:27:14 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 23 Apr 2001 17:27:14 +1200 (NZST)
Subject: [Python-Dev] Class Methods
In-Reply-To: <200104201626.LAA06384@cj20424-a.reston1.va.home.com>
Message-ID: <200104230527.RAA14279@s454.cosc.canterbury.ac.nz>

Guido:

> The problem is that if you write C.spam, there could be two spams: one
> in C.__dict__, one in M.__dict__.  Which one to use?  How does
> Smalltalk resolve this?

The problem doesn't arise in Smalltalk, because method calls and
instance variable accesses are completely different things and are
handled by quite separate syntaxes and mechanisms.

Python creates problems for itself here by confusing instance
variables of the class with metadata about the instance's methods,
and keeping them both in the same namespace.

Thomas Heller <thomas.heller at ion-tof.com>:

> I'm walking on thin ice here (maybe I should better try it out),
> but IIRC Smalltalk requires to explicit:
> 
>     self class method;
> or
>     self method;

No, to call a class method in Smalltalk, you just send a message 
to the class itself rather than an instance. There's no difference
in the message sending syntax.

> Thin ice again I'm on here (even more), but I have the impression
> that creating a class Point in Smalltalk _automatically_ creates
> two classes: Point and PointClass. The latter is normally hidden
> (but contains the class methods of Point as instance methods).

Yes. You don't normally get a choice about what the metaclass is,
although no doubt you could reach under the covers and manually
construct your own metaclass and instantiate it if you wanted.

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



From greg at cosc.canterbury.ac.nz  Mon Apr 23 07:33:20 2001
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 23 Apr 2001 17:33:20 +1200 (NZST)
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com>
Message-ID: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz>

Tim Peters <tim.one at home.com>:

> "class methods" in *this* thread
> is being used in a Smalltalk sense (because it's Thomas Heller's thread, and
> he made clear that he doesn't want C++-style class statics).

It sounds like he wants not just class methods, but to
unify classes and instances the way they are in Smalltalk.

That's not necessary *just* to get class methods. For
instance, suppose you could write

  class Foo:

    def ftang(class c, x, y, z);
      ...

where the 'class' keyword in the argument list would say
that it is to be a class method. That special form of the
def statement would create an 'unbound class method'
object, whose first argument would be filled in with the
class object when Foo.ftang was accessed.

Hmmm... might write a PEP on that!

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



From tim.one at home.com  Mon Apr 23 07:41:08 2001
From: tim.one at home.com (Tim Peters)
Date: Mon, 23 Apr 2001 01:41:08 -0400
Subject: [Python-Dev] Importing DLLs on Windows
In-Reply-To: <3AE16254.FFE9ADF7@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com>

[MAL]
> Oh, sorry that I wasn't clear enough.

Me neither (see below).

> Referring to the mxNumber package, I am seeing this situation:
>
> # This works... (note the start directory)
>
> C:\WINDOWS>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> >>> print mx.Number.Float(3.141)
> 3.14100000000000001421e+0
> >>>
>
> # This doesn't.... (from the Python install directory)
>
> D:\Python21>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "d:\python21\mx\Number\__init__.py", line 9, in ?
>     from Number import *
>   File "d:\python21\mx\Number\Number.py", line 11, in ?
>     from mxNumber import *
>   File "d:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
>     from mxNumber import *
> ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser
> Anwendung notwen dige Bibliothekdateien kann nicht gefunden werden.
> >>>

Well, there's your problem:  looks some German hackers got into your machine
and screwed up the OS <wink>.

Now let me clarify what I wrote before:  when I said I couldn't provoke a
problem, I meant ANY problem.  It didn't matter whether I used the
__init__.py you shipped, or used the two-liner I posted, and it didn't matter
whether I started Python 2.1 from the install directory or from C:\Code
(etc).  Nothing failed no matter what I tried.

The only thing I see different in what you did above is that your Python
install directory is on a different drive (D: instead of C:).  I only have
one drive here, so I can't do a good job of simulating that.  Best I can do
here is fake it via the DOS subst command:

K:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> from mx.Number import *
>>>

Still no problem.  What happens if you install Python onto your C: drive
instead?  And if that does work for you, is it because of the C: drive, or
because you left some old development work on your D: drive that's confusing
things?

Do you have confirmation of your problem from anyone else?  Or are you the
only one who has bumped into it?

> ...
> Please try starting Python from your Python install dir and
> then do the import.

I already had, in the last msg.  And again above.

> BTW, I'm doing this on Windows 95 in case this matters (which I'm
> sure it does :-/).

Possibly, but can't say.  We need more data.

BTW, do you understand what your code does <0.7 wink>?  That is, there are
packages, modules *and* DLLs with the same base name, and "import *"
everywhere.  I've always stayed so far away from import end cases that I have
no idea what the rules are supposed to be when you live on the edge.  That
may have something to do with this too, although I can't see how (although
since I don't know what the rules are, that's a guess too!).




From tim.one at home.com  Mon Apr 23 08:05:17 2001
From: tim.one at home.com (Tim Peters)
Date: Mon, 23 Apr 2001 02:05:17 -0400
Subject: [Python-Dev] Suirprise!
In-Reply-To: <3AE39BB5.3B2E276C@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEAPJOAA.tim.one@home.com>

>> An incompatible language change would, I think, need to go thru the
>> __future__ (however spelled) business.

[Paul]
> ???
>
> My understanding was that __future__ was a way of sneaking in a cool
> feature earlier than it would have been possible to deploy it given
> strict gradual evolution contraints.

That's not what PEP 236 says.  __future__ is about *incompatible* language
changes, period.  "Cool" has nothing to do with it.  If you're making
something illegal that used to work, that's an incompatible change, and
people get at least one release cycle in which it continues to work without
change but with warnings.  They can also ask for future behavior early via
using an explicit future-statement in the module.  Although in this case I
guess the "future behavior" is just to turn the wng msg into a SyntaxError,
in which case the __future__ machinery does seem like overkill.

> But disallowing confusing uses of "in" is not a feature

PEP 236 is about incompatible changes, not features.  It so happens that the
first use (nested scopes) was a new feature that *could* break old code, so
was both a new feature and an incompatible change.

> and nobody is in a big hurry to see it happen. I wouldn't mind
> waiting a year or two until everyone has had a chance to
> clean up their code.

I'd rather not nag people at all if this is the only time it's come up in a
decade <wink>.  We've all got too much to do.

> ...
> The following grammar would preserve it [chaining "in"] and outlaw
> confusing cases:
>
> comparison: in_comparison | is_comparison | math_comparison
> math_comparison: expr (math_comp_op expr)*
> in_comparison: expr ('in' | 'not' 'in' expr)*
> is_comparison: expr ('is' | 'is' 'not' expr)*
> math_comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='

Did you try that grammar?  I'm skeptical that it works, since at first glance
the comparison production appears to require arbitrary lookahead to determine
which xxx_comparison case obtains.  But if so, I'm sure it can be repaired.
Whether it *should* be is a different matter I'll leave to Guido to Pronounce
on.




From mal at lemburg.com  Mon Apr 23 10:48:17 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 23 Apr 2001 10:48:17 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com>
Message-ID: <3AE3EC50.3A850757@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > Oh, sorry that I wasn't clear enough.
> 
> Me neither (see below).
> 
> > Referring to the mxNumber package, I am seeing this situation:
> >
> > # This works... (note the start directory)
> >
> > C:\WINDOWS>python
> > Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> > Type "copyright", "credits" or "license" for more information.
> > >>> import mx.Number
> > >>> print mx.Number.Float(3.141)
> > 3.14100000000000001421e+0
> > >>>
> >
> > # This doesn't.... (from the Python install directory)
> >
> > D:\Python21>python
> > Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> > Type "copyright", "credits" or "license" for more information.
> > >>> import mx.Number
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> >   File "d:\python21\mx\Number\__init__.py", line 9, in ?
> >     from Number import *
> >   File "d:\python21\mx\Number\Number.py", line 11, in ?
> >     from mxNumber import *
> >   File "d:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
> >     from mxNumber import *
> > ImportError: DLL load failed: Ein der fnr die Ausfnhrung dieser
> > Anwendung notwen dige Bibliothekdateien kann nicht gefunden werden.
> > >>>
> 
> Well, there's your problem:  looks some German hackers got into your machine
> and screwed up the OS <wink>.

Could be...
 
> Now let me clarify what I wrote before:  when I said I couldn't provoke a
> problem, I meant ANY problem.  It didn't matter whether I used the
> __init__.py you shipped, or used the two-liner I posted, and it didn't matter
> whether I started Python 2.1 from the install directory or from C:\Code
> (etc).  Nothing failed no matter what I tried.

OK. I tried the same on a Win98 box with a fresh Python and
mxNumber install -- and found no problems either; which leaves
me rather clueless about where the failures on my Win95 box 
originate. 

Could someone else with a Win95 box perhaps test this ?

Thanks anyway for hanging on,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From thomas.heller at ion-tof.com  Mon Apr 23 10:58:56 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Mon, 23 Apr 2001 10:58:56 +0200
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
References: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz>
Message-ID: <02a701c0cbd3$a21f9290$e000a8c0@thomasnotebook>

> Tim Peters <tim.one at home.com>:
> 
> > "class methods" in *this* thread
> > is being used in a Smalltalk sense (because it's Thomas Heller's thread, and
> > he made clear that he doesn't want C++-style class statics).

Well, I shouldn't have talked about C++ static methods, because
I'm not too familiar with them.

Here's what I want:

Assume C is a class with a class-method mth,
and D is 'class D(C): pass'.

C.mth() should call this method, which in turn (automatically)
receives C itself as the first parameter.
D.mth() should call this method, which in turn (automatically)
receives D itself as the first parameter.

> 
> It sounds like he wants not just class methods, but to
> unify classes and instances the way they are in Smalltalk.

The metaclass approach is one solution, not neccessarily
the best.
> 
> That's not necessary *just* to get class methods. For
> instance, suppose you could write
> 
>   class Foo:
> 
>     def ftang(class c, x, y, z);
>       ...
> 
> where the 'class' keyword in the argument list would say
> that it is to be a class method. That special form of the
> def statement would create an 'unbound class method'
> object, whose first argument would be filled in with the
> class object when Foo.ftang was accessed.

Donald Beaudry's objectmodule uses the metaclass hook to provide
class methods. I like the resulting syntax very much: He uses an
'inner class' with the special name '__class__' to specify class
methods:

class Object(object.base):
    class __class__:
        def class_method(self):
            pass
    def normal_method(self):
        pass

If I understand correctly (objectmodule does not run under
1.5.2 or later), an instance of __class__ will become
the metaclass of Object, and __class__'s methods will
become class methods of Object.

I've played a little bit with metaclasses in pure python
(it is faster this way), and have an implementation with the
same syntax where __class__ is never instantiated, and simply
acts as a function container.

Addendum: Additionaly to class methods, I would like to
have 'magic' class methods, maybe named __class_init__
and __class_getattr__. Easy to guess what they should do...

> 
> Hmmm... might write a PEP on that!
> 
Me too.


Thomas




From jack at oratrix.nl  Mon Apr 23 11:16:44 2001
From: jack at oratrix.nl (Jack Jansen)
Date: Mon, 23 Apr 2001 11:16:44 +0200
Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line 
 conversion?
In-Reply-To: Message by "Tim Peters" <tim.one@home.com> ,
	     Thu, 12 Apr 2001 21:00:08 -0400 , <LNBBLJKPBEHFEDALKOLCAENKJLAA.tim.one@home.com> 
Message-ID: <20010423091644.AB453312BA0@snelboot.oratrix.nl>

> [Steven D. Majewski]
> > Has anybody looked at sfio ?
> > ...
> > http://www.research.att.com/sw/tools/sfio/
> 
> Did just now.  Only runs on Unix boxes, so would be a heavyweight way to
> solve line-end problems across platforms that don't have any <wink>.

But purely by chance I know that Matthias Neeracher, who has written the GUSI 
unix-emulation package that MacPython uses to do socket IO and select and 
such, is an SFIO fan, and there's all sorts of hooks in GUSI to allow use of 
SFIO. So I think that there's a good chance that sfio is okay for MacPython.

I've just dug out the 1991 usenix article, I'll read through it shortly.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 





From thomas at xs4all.net  Mon Apr 23 13:09:02 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Mon, 23 Apr 2001 13:09:02 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/ref ref3.tex,1.64,1.65 ref5.tex,1.43,1.44
In-Reply-To: <15072.27417.366789.977575@slothrop.digicool.com>; from jeremy@digicool.com on Fri, Apr 20, 2001 at 01:00:09PM -0400
References: <E14qe7G-0002AU-00@usw-pr-cvs1.sourceforge.net> <15072.27417.366789.977575@slothrop.digicool.com>
Message-ID: <20010423130902.A16486@xs4all.nl>

On Fri, Apr 20, 2001 at 01:00:09PM -0400, Jeremy Hylton wrote:
> >>>>> "GvR" == Guido van Rossum <gvanrossum at users.sourceforge.net> writes:

>   GvR> Log Message: Implement, test and document "key in dict" and
>   GvR> "key not in dict".

>   GvR> I know some people don't like this -- if it's really
>   GvR> controversial, I'll take it out again.  (If it's only Alex
>   GvR> Martelli who doesn't like it, that doesn't count as "real
>   GvR> controversial" though. :-)

> I don't like it either, because it's only clear when it's spelled "for
> key in dict".  It's pretty confusing when it's spelled "for val in
> dict" or even "for x in dict".

> But I'm willing to give it a try for a while.

Same here (don't like right now, can live with it even though my own
experiments w/ innocent colleagues lead me to believe it's not the best
thing to do ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Mon Apr 23 14:28:52 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Mon, 23 Apr 2001 14:28:52 +0200
Subject: [Python-Dev] Suirprise!
In-Reply-To: <3AE39BB5.3B2E276C@ActiveState.com>; from paulp@ActiveState.com on Sun, Apr 22, 2001 at 08:04:21PM -0700
References: <LNBBLJKPBEHFEDALKOLCOEAEJOAA.tim.one@home.com> <3AE39BB5.3B2E276C@ActiveState.com>
Message-ID: <20010423142852.B16486@xs4all.nl>

On Sun, Apr 22, 2001 at 08:04:21PM -0700, Paul Prescod wrote:

> The following grammar would preserve it and outlaw confusing cases:

> comparison: in_comparison | is_comparison | math_comparison
> math_comparison: expr (math_comp_op expr)*
> in_comparison: expr ('in' | 'not' 'in' expr)*
> is_comparison: expr ('is' | 'is' 'not' expr)*
> math_comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='

Won't work. Python's parser can't handle it. I also don't think the grammar
really matters that much -- it's the compiler that does the actual chaining,
it could decide not to chain and force a specific order, if it really wanted
to. And generate warnings and all that :)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From fdrake at acm.org  Mon Apr 23 14:40:44 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 23 Apr 2001 08:40:44 -0400 (EDT)
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs
In-Reply-To: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz>
References: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com>
	<200104230533.RAA14282@s454.cosc.canterbury.ac.nz>
Message-ID: <15076.8908.65608.249318@cj42289-a.reston1.va.home.com>

Greg Ewing writes:
 >   class Foo:
 > 
 >     def ftang(class c, x, y, z);
 >       ...

  I like this syntax better that the others.  While it requires that a
single namespace is used for class and normal methods, I think that is
a good thing -- we don't *want* overlapping sets of names!


  -Fred

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




From thomas at xs4all.net  Mon Apr 23 14:44:40 2001
From: thomas at xs4all.net (Thomas Wouters)
Date: Mon, 23 Apr 2001 14:44:40 +0200
Subject: [Python-Dev] keyword-only arguments (was Re: string slicing and method consistency)
In-Reply-To: <200104202148.QAA13960@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Fri, Apr 20, 2001 at 04:48:06PM -0500
References: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com> <200104202148.QAA13960@cj20424-a.reston1.va.home.com>
Message-ID: <20010423144440.C16486@xs4all.nl>

On Fri, Apr 20, 2001 at 04:48:06PM -0500, Guido van Rossum wrote:
> [GVW]

> > Turns out that "abbc".replace("b", "x", -1) is "axxc"
> > (i.e. negative arguments are ignored).  I would have
> > expected this to raise a ValueError, if anything.  Is
> > there a reason for this behavior?  Is it worth making
> > replace, split, etc. interpret negative indices in the
> > same way as indexing does?
> 
> Dubious hypergeneralization.  The thing is that this parameter, called
> maxsplit, is not really an index -- it's a count.

Wouldn't it be nice if we could force particular arguments to be used as
keyword arguments only ? :) I remember this coming up a few times on
python-list, but I never quite understood why this isn't done. Syntax
doesn't seem too much of a problem ('def split(s, sep, **, maxsplit=0)'
comes to mind, and a new marker for PyArg_ParseTuple, like "**") and now
that we have warnings and __future__, we could phase it in even for oft-used
things such as string.split().

Even if it's deemed dubious hypergeneralization (look ma, no macro ;) it's
worth writing a PEP about, right ?

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas.heller at ion-tof.com  Mon Apr 23 15:04:37 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Mon, 23 Apr 2001 15:04:37 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com> <3AE3EC50.3A850757@lemburg.com>
Message-ID: <03ee01c0cbf5$f3963f30$e000a8c0@thomasnotebook>

I see the same Behaviour as Marc-Andre: Traceback in Win95 (running under VMWare,
running under Win2k).

C:\WINDOWS>\python21\python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
>>> print mx.Number.Float(3.141)
3.14100000000000001421e+0
>>>
>>>
>>>
>>> quit
'Use Ctrl-Z plus Return to exit.'
>>>
C:\WINDOWS>cd \python21

C:\Python21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import mx.Number
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\mx\Number\__init__.py", line 9, in ?
    from Number import *
  File "c:\python21\mx\Number\Number.py", line 11, in ?
    from mxNumber import *
  File "c:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
    from mxNumber import *
ImportError: DLL load failed: One of the library files needed to run this applic
ation cannot be found.
>>>
C:\Python21>ver

Windows 95. [Version 4.00.950]


C:\Python21>


Marc-Andre, what about other python versions?

Thomas




From guido at digicool.com  Mon Apr 23 16:36:44 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 23 Apr 2001 09:36:44 -0500
Subject: [Python-Dev] keyword-only arguments (was Re: string slicing and method consistency)
In-Reply-To: Your message of "Mon, 23 Apr 2001 14:44:40 +0200."
             <20010423144440.C16486@xs4all.nl> 
References: <930BBCA4CEBBD411BE6500508BB3328F22D1D1@nsamcanms1.ca.baltimore.com> <200104202148.QAA13960@cj20424-a.reston1.va.home.com>  
            <20010423144440.C16486@xs4all.nl> 
Message-ID: <200104231436.JAA00321@cj20424-a.reston1.va.home.com>

> Wouldn't it be nice if we could force particular arguments to be used as
> keyword arguments only ? :)

You could do this manually using **kwds (or its C equivalent), but it
gets ugly.

> I remember this coming up a few times on
> python-list, but I never quite understood why this isn't done. Syntax
> doesn't seem too much of a problem ('def split(s, sep, **, maxsplit=0)'
> comes to mind, and a new marker for PyArg_ParseTuple, like "**") and now
> that we have warnings and __future__, we could phase it in even for oft-used
> things such as string.split().
> 
> Even if it's deemed dubious hypergeneralization (look ma, no macro ;) it's
> worth writing a PEP about, right ?

Sure.  My main problem with it is that I doubt how often it is useful,
compared to the cost of adding the syntax and new code generation
necessary.  I don't think that ** is the right separator, but I don't
have a better suggestion.

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



From mal at lemburg.com  Mon Apr 23 15:40:50 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 23 Apr 2001 15:40:50 +0200
Subject: [Python-Dev] Importing DLLs on Windows
References: <LNBBLJKPBEHFEDALKOLCAEALJOAA.tim.one@home.com> <3AE3EC50.3A850757@lemburg.com> <03ee01c0cbf5$f3963f30$e000a8c0@thomasnotebook>
Message-ID: <3AE430E2.A81CEBDA@lemburg.com>

Thomas Heller wrote:
> 
> I see the same Behaviour as Marc-Andre: Traceback in Win95 (running under VMWare,
> running under Win2k).
> 
> C:\WINDOWS>\python21\python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> >>> print mx.Number.Float(3.141)
> 3.14100000000000001421e+0
> >>>
> >>>
> >>>
> >>> quit
> 'Use Ctrl-Z plus Return to exit.'
> >>>
> C:\WINDOWS>cd \python21
> 
> C:\Python21>python
> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import mx.Number
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "c:\python21\mx\Number\__init__.py", line 9, in ?
>     from Number import *
>   File "c:\python21\mx\Number\Number.py", line 11, in ?
>     from mxNumber import *
>   File "c:\python21\mx\Number\mxNumber\__init__.py", line 21, in ?
>     from mxNumber import *
> ImportError: DLL load failed: One of the library files needed to run this applic
> ation cannot be found.
> >>>
> C:\Python21>ver
> 
> Windows 95. [Version 4.00.950]
> 
> C:\Python21>
> 
> Marc-Andre, what about other python versions?

mxNumber needs Python 2.1, so I have no way of testing it under
Python 2.0. Both imports work on Winows 98SE, so I guess this
has something to do with Win95 no handling imports using relative
paths correctly (if you run Python with -vv you'll see that
Python searches using relative paths when started from C:\Python21).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From nas at python.ca  Mon Apr 23 17:12:18 2001
From: nas at python.ca (Neil Schemenauer)
Date: Mon, 23 Apr 2001 08:12:18 -0700
Subject: [Python-Dev] ineffective optimization: method tables
Message-ID: <20010423081218.A9952@glacier.fnational.com>

Well, I wasted a fair amount of my time for no apparent gain.
The idea was to have function pointer tables indexed by type that
could be used for common operations.  First, how to do we index
things by type?  Here's my solution:

    #define PyType_UNKNOWN 0
    #define PyType_NONE 1
    #define PyType_INT 2

    #define PyType_Ord(t) ((t)->tp_ord)
    #define PyObject_TypeOrd(o) PyType_Ord((o)->ob_type)

Here is an example of methods for PyObject_IsTrue:

    int
    int_istrue(PyObject *v)
    {
        return ((PyIntObject *)v)->ob_ival != 0;
    }

    int
    none_istrue(PyObject *v)
    {
        return 0;
    }

    inquiry istrue_table[] =  {
           PyObject_IsTrue,        /* PyType_UNKNOWN */
           none_istrue,            /* PyType_NONE */
           int_istrue,             /* PyType_INT */
    };

    #define PyObject_IS_TRUE(v) istrue_table[PyObject_TypeOrd(v)](v)

There is a patch at:

    http://arctrix.com/nas/python/method_table1.diff

I did have 2-D tables for binary operations but since they were
quite sparse I took them out in favor of arrays and case
statements.  Unfortunately, all my benchmarks show this patch to
be ineffective in terms of speeding up the interpreter.  Anyone
know why?

  Neil



From guido at digicool.com  Mon Apr 23 17:21:02 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 23 Apr 2001 11:21:02 -0400
Subject: [Python-Dev] ineffective optimization: method tables
In-Reply-To: Your message of "Mon, 23 Apr 2001 08:12:18 PDT."
             <20010423081218.A9952@glacier.fnational.com> 
References: <20010423081218.A9952@glacier.fnational.com> 
Message-ID: <200104231521.f3NFL8h15693@odiug.digicool.com>

> Well, I wasted a fair amount of my time for no apparent gain.
[...]
> Unfortunately, all my benchmarks show this patch to
> be ineffective in terms of speeding up the interpreter.  Anyone
> know why?

Probably you're optimizing something that is already quite fast.
While your code saves a C call and a few tests, those kind of
operations are rarely what slows down Python these days.  My suspicion
is that most of the the time goes into (1) allocating and deallocating
objects, and (b) calling methods...

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



From pedroni at inf.ethz.ch  Mon Apr 23 17:35:48 2001
From: pedroni at inf.ethz.ch (Samuele Pedroni)
Date: Mon, 23 Apr 2001 17:35:48 +0200 (MET DST)
Subject: [Python-Dev] ineffective optimization: method tables
Message-ID: <200104231535.RAA12700@core.inf.ethz.ch>

Hi.

[Neil Schemenauer]
> I did have 2-D tables for binary operations but since they were
> quite sparse I took them out in favor of arrays and case
> statements.  Unfortunately, all my benchmarks show this patch to
> be ineffective in terms of speeding up the interpreter.  Anyone
> know why?
I just noticed that your changes add a 1 more call price also were there was
no such price (int + int, etc), do not know if that matters ...

regards.




From dsh8290 at rit.edu  Mon Apr 23 19:11:54 2001
From: dsh8290 at rit.edu (D-Man)
Date: Mon, 23 Apr 2001 13:11:54 -0400
Subject: [Python-Dev] Class Methods
In-Reply-To: <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>; from thomas.heller@ion-tof.com on Fri, Apr 20, 2001 at 05:40:21PM +0200
References: <027401c0c9ab$5e3c88f0$e000a8c0@thomasnotebook> <15072.21064.298318.393753@slothrop.digicool.com> <3AE054AD.9A8D07D@lemburg.com> <030101c0c9b0$3578a520$e000a8c0@thomasnotebook>
Message-ID: <20010423131154.A13119@harmony.cs.rit.edu>

On Fri, Apr 20, 2001 at 05:40:21PM +0200, Thomas Heller wrote:
| I want the class methods (for example) to create and manipulate
| this 'context object'. This object, however, belongs into the class...
| 
| What I want to avoid is
| 
|   class X(...):
|       ....
|   initialize(X)

Here is a different approach to consider :

class X :
    def __class_init__( class_X ) :
        initialize( class_X )


The idea here is to provide a "magic" method in the class that the
interpreter calls as soon as the class object exists.  The first
(only) argument is the class object, which can be named as desired
(analogous to 'self').  The main problem here is clients aren't
prevented from calling this method, and they really shouldn't.

-D




From martin at loewis.home.cs.tu-berlin.de  Mon Apr 23 19:45:18 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 23 Apr 2001 19:45:18 +0200
Subject: [Python-Dev] 'iter' as a function name
Message-ID: <200104231745.f3NHjIN02434@mira.informatik.hu-berlin.de>

I should probably be silent on the issue of picking names for things,
but I feel that 'iter' is an unfortunte choice for a function name: it
is an abbreviated word. Now, you could argue that there is plenty of
precedent for that in Python, but some of these are also
confusing. Just today, I asked colleague what he thought 'repr' might
do, and he had no clue.

Anyway, I've been browsing dictionaries somewhat, and here are a few
proposals, taking a well-known dictionary as an argument:

harp(sys.modules)      # or harp_on(sys.modules)?
traverse(sys.modules)  # not shorter than iterate, though...
narrate(sys.modules)

Of course, spelling-out "iterate" would be just as fine.

Just my 0.02EUR,

Martin



From donb at abinitio.com  Mon Apr 23 20:12:36 2001
From: donb at abinitio.com (Donald Beaudry)
Date: Mon, 23 Apr 2001 14:12:36 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs 
References: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz> <02a701c0cbd3$a21f9290$e000a8c0@thomasnotebook>
Message-ID: <200104231812.OAA08354@localhost.localdomain>

"Thomas Heller" <thomas.heller at ion-tof.com> wrote,
> Donald Beaudry's objectmodule uses the metaclass hook to provide
> class methods. I like the resulting syntax very much:

Thank you.  I like it too, especially because MyClass.__class__
returns what *I* would expect ;) and the source reflects that too.

> If I understand correctly (objectmodule does not run under 1.5.2 or
> later), an instance of __class__ will become the metaclass of
> Object, and __class__'s methods will become class methods of Object.

That's correct.  I currently use objectmodule on 1.5.2.  I would not
be surprised if it doesnt work on newer versions though as I have
never tried it there.  Perhaps you found an out-of-date version, or
perhaps I never sent out a newer version.  Regardless, I'd be happy to
get you a version that works with 1.5.2 (or upload one somewhere for
more public consumption)

> I've played a little bit with metaclasses in pure python (it is
> faster this way), and have an implementation with the same syntax
> where __class__ is never instantiated, and simply acts as a function
> container.

Ah but with the object module, it does get instantiated.  In fact,
__class__ is derived (implicitly) from the __class__ of the containing
base class. Inheritance works as expected.

> Addendum: Additionaly to class methods, I would like to
> have 'magic' class methods, maybe named __class_init__
> and __class_getattr__. Easy to guess what they should do...

Objectmodule provides for that as well.  Just define __init__,
__getattr__, etc., inside the __class__ definition.  There is even and
__new__ which is responsible for controling the "memory allocation" of
instances.  This is useful for, amoung other things, singletons.

> > Hmmm... might write a PEP on that!
> > 
> Me too.

...gone are the days when a simple email to Guido was all it took to
get a proposal going ;)

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb at init.com                                      Lexington, MA 02421
                  ...So much code, so little time...




From donb at abinitio.com  Mon Apr 23 20:22:03 2001
From: donb at abinitio.com (Donald Beaudry)
Date: Mon, 23 Apr 2001 14:22:03 -0400
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs 
References: <LNBBLJKPBEHFEDALKOLCKEKAJNAA.tim.one@home.com> <200104230533.RAA14282@s454.cosc.canterbury.ac.nz> <15076.8908.65608.249318@cj42289-a.reston1.va.home.com>
Message-ID: <200104231822.OAA08502@localhost.localdomain>

"Fred L. Drake, Jr." <fdrake at acm.org> wrote,
> 
> Greg Ewing writes:
>  >   class Foo:
>  > 
>  >     def ftang(class c, x, y, z);
>  >       ...
> 
>   I like this syntax better that the others.  While it requires that a
> single namespace is used for class and normal methods, I think that is
> a good thing -- we don't *want* overlapping sets of names!

But... we have overlaping names!  __init__ is just one example.
Further, that only works for methods.  How should class attributes be
distinguished?  Perhaps you dont want them.

Should a decision be made to go down this road, a big choice lies
ahead.  Are class objects "special" or are they simply instances of a
different class?  Because I didnt want to make a whole pile of
decisions regarding the "specialness" of class objects, I chose to
make the one decision that class object's only distinction from other
objects is that they are instances of a different class.  This is,
afterall, how all objects are distinguished.

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb at init.com                                      Lexington, MA 02421
                      ...Will hack for sushi...



From thomas.heller at ion-tof.com  Mon Apr 23 20:27:10 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Mon, 23 Apr 2001 20:27:10 +0200
Subject: [Python-Dev] RE: Python-Dev digest, Vol 1 #1324 - 16 msgs 
References: <200104230533.RAA14282@s454.cosc.canterbury.ac.nz> <02a701c0cbd3$a21f9290$e000a8c0@thomasnotebook> <200104231812.OAA08354@localhost.localdomain>
Message-ID: <08bd01c0cc23$02cdb050$e000a8c0@thomasnotebook>

> "Thomas Heller" <thomas.heller at ion-tof.com> wrote,
> > Donald Beaudry's objectmodule uses the metaclass hook to provide
> > class methods. I like the resulting syntax very much:
> 
> Thank you.  I like it too, especially because MyClass.__class__
> returns what *I* would expect ;) and the source reflects that too.
> 
> > If I understand correctly (objectmodule does not run under 1.5.2 or
> > later), an instance of __class__ will become the metaclass of
> > Object, and __class__'s methods will become class methods of Object.
> 
> That's correct.  I currently use objectmodule on 1.5.2.  I would not
> be surprised if it doesnt work on newer versions though as I have
> never tried it there.  Perhaps you found an out-of-date version, or
> perhaps I never sent out a newer version.  Regardless, I'd be happy to
> get you a version that works with 1.5.2 (or upload one somewhere for
> more public consumption)

Sure I would be interested: Please send it.
Thanks for the description, I've (eagerly) read everything I found
in objectmodule-0.9.tar.gz - except I found that it would be easier
to step in a debugger through the c-code, which turned out to fail.

BTW: I just exchanged a couple of emails with Just van Rossum,
who had something very similar to yours (but you may know this already).
He pointed me to some discussions in '98 in the types-sig archives.

He proposed an additional hook in ceval.c (which would probably break
objectmodule). I've attached his proposed patch below.

Thomas

+       /*      __BEGIN__ of Just's Hook
+
+               Guido's metahook is defined as follows:
+                       - if one of the bases has a __class__ attribute (but is
+                         itself not a class!), call that thing with (name,
+                         bases, methods)
+               In addition I propose almost the opposite:
+                       - if the "methods" dict (__dict__ from the Python
+                         perspective) has a __class__ key, call that thing with
+                         (name, bases, methods)
+
+               This means that metaclasses are not special anymore, and
+               you have to specify a metaclass *explicitly* to get meta
+               behaviour. Example:
+
+                       class Foo:
+                               __class__ = MyMetaClass
+
+               as apposed to
+
+                       MyMeta = MyMetaClass("MyMeta", (), {})
+
+                       class Foo(MyMeta): pass
+
+               as it is with Guido's hook.
+
+               Reasons for this new hook:
+                       - Guido's hook abuses inheritance syntax, making it
+                         impossible to inherit from metaclasses without special
+                         trickery.
+                       - implementing Meta stuff seems cleaner. Or maybe it's
+                         just me...
+
+               At first I thought Guido's hook would not be compatible with
+               mine, but they work together beautifully: inheritance works
+               just like you would expect.
+       */
+       {
+               PyObject *callable = NULL;
+               callable = PyDict_GetItemString(methods, "__class__");
+               if (callable) {
+                       PyObject *args;
+                       PyObject *newclass = NULL;
+                       PyDict_DelItemString(methods, "__class__");
+                       args = Py_BuildValue(
+                               "(OOO)", name, bases, methods);
+                       if (args != NULL) {
+                               newclass = PyEval_CallObject(
+                                       callable, args);
+                               Py_DECREF(args);
+                       }
+                       return newclass;
+               } else {
+                       PyErr_Clear();
+               }
+       }
+       /*      __END__ of Just's Hook */
        n = PyTuple_Size(bases);
        for (i = 0; i < n; i++) {
                PyObject *base = PyTuple_GET_ITEM(bases, i);
                if (!PyClass_Check(base)) {
                        /* Call the base's *type*, if it is callable.




From neal at metaslash.com  Mon Apr 23 21:46:29 2001
From: neal at metaslash.com (Neal Norwitz)
Date: Mon, 23 Apr 2001 15:46:29 -0400
Subject: [Python-Dev] PyChecker 0.4 - new release
Message-ID: <3AE48695.EE89C468@metaslash.com>

I've released a new version of PyChecker, the source code checking tool.

The most notable change is support for .pycheckrc file to specify
your own defaults.  There were also a few new warnings added and
some bug fixes.

Here's the CHANGELOG:

  * Add .pycheckrc file processing to specify options (like on command line)
  * Add new warning if module.Attribute doesn't exist
  * Add new warning:  Module (%s) re-imported locally
  * Add glob'ing support for windows
  * Handle apply(BaseClass.__init__(self, args))
  * Fix command line handling so you can pass module, package, or filename
  * Fix **kwArgs warning if named parameter is not first
  * Don't exit from checker when import checker from interpreter

PyChecker is available on Source Forge:
    Web page:           http://pychecker.sourceforge.net/
    Project page:       http://sourceforge.net/projects/pychecker/

Neal



From martin at loewis.home.cs.tu-berlin.de  Tue Apr 24 08:24:09 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 24 Apr 2001 08:24:09 +0200
Subject: [Python-Dev] ineffective optimization: method tables
Message-ID: <200104240624.f3O6O9001146@mira.informatik.hu-berlin.de>

> Unfortunately, all my benchmarks show this patch to be ineffective
> in terms of speeding up the interpreter.  Anyone know why?

I guess because you took PyObject_IsTrue. After profiling some
application, I found that this is a frequent function, so I thought it
should be optimized.

I then found that most of the time, it gets Py_True, Py_False, or
Py_None as an argument, so I checked for identity with these objects.
Indeed, that covered the majority of the calls - but with no
significant speed gain when special-cased.

So I think I agree with Guido: even as these functions are frequently
called, this is not where the time is consumed.

Regards,
Martin



From skip at pobox.com  Tue Apr 24 15:17:24 2001
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 24 Apr 2001 08:17:24 -0500 (CDT)
Subject: [Python-Dev] tickling version numbers during release
In-Reply-To: <20010419075326.F30408@ActiveState.com>
References: <15070.41140.642307.450172@beluga.mojam.com>
	<20010419075326.F30408@ActiveState.com>
Message-ID: <15077.31972.989862.905462@beluga.mojam.com>

    Trent> Or preferably have the version number in only *one* place in one
    Trent> file in CVS then (1) have autoconf massage template files to
    Trent> insert the version number where needed or (2) have those files
    Trent> that need the version number *include* it from pyac_config.h.

    Trent> ...except we are not using any auto configuration tool on
    Trent> Windows. Damn.

That's not necessary.  I think if you have one file in CVS that contains the
version then you can update other CVS-resident files that want to have the
version also.  You just have to do that from an autoconf-compatible machine.

Skip





From electro-owner at ml.poplist.fr  Tue Apr 24 16:21:54 2001
From: electro-owner at ml.poplist.fr (thelink)
Date: Tue, 24 Apr 2001 16:21:54 +0200
Subject: [Python-Dev] WWW.090000900.COM GAGNEZ 1 AN DE COMMUNICATIONS GSM ! WIN 1 JAAR GRATIS
 GSM-GEBRUIK !
Message-ID: <007601c0ccc9$e9f7d540$01fea8c0@jctubiermont.brutele.be>

--{  Liste h?berg?e par PoPList  }------{  http://www.poplist.fr/  }--
--{  Voir  en   bas  de  ce  mail les  options  de  d?sabonnement  }--
______________________________________________________________________


GAGNEZ 1 AN DE COMMUNICATIONS GSM GRATUITES !
WIN 1 JAAR GRATIS GSM-GEBRUIK !

       

TELECHARGEZ PAR SMS 1500 LOGOS et SONNERIES AU TARIF LE PLUS BAS ( 30 bef / unite ) !
DOWNLOAD PER SMS 1500 LOGOS en RINGTONES AAN HET LAAGSTE TARIEF ( 30 bef / stuk ) !
http://www.090000900.com

$


Pour vous d?sabonner, rendez-vous simplement sur cette page :
->  <http://cgi.poplist.fr/@/u/electro/python-dev at python.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20010424/c29ac32b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9072 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20010424/c29ac32b/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 16877 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20010424/c29ac32b/attachment-0003.gif>

From gmcm at hypernet.com  Wed Apr 25 17:21:18 2001
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 25 Apr 2001 11:21:18 -0400
Subject: [Python-Dev] Attn: Christian Tismer (apologies to others)
Message-ID: <3AE6B32E.22730.5BF4AC97@localhost>

Sorry to blast everybody with this.

Christian, your mail server is getting a new HD. You can reach 
Jean-Claude at jcwippler at hotmail.com.

- Gordon



From michel at digicool.com  Wed Apr 25 22:08:01 2001
From: michel at digicool.com (Michel Pelletier)
Date: Wed, 25 Apr 2001 13:08:01 -0700 (PDT)
Subject: [Python-Dev] PEP 245 Prototype
Message-ID: <Pine.LNX.4.32.0104242341190.17366-100000@localhost.localdomain>

I have created a prototype of PEP 245 based on the Mobius Python library.
This prototype requires no changes to Python 2.x.

I have also updated PEP 245 to reflect using the prototype.  Refer to the
'doc' directory for the revised PEP.  The prototype can be downloaded
from:

http://www.zope.org/Members/michel/InterfacesPEP/Interface.tgz

It contains four directories and a README that should get you started.
Please follow up any comments specific to the PEP onto the
type-sig at python.org list.

Thanks,

-Michel





From mal at lemburg.com  Wed Apr 25 23:15:58 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 25 Apr 2001 23:15:58 +0200
Subject: [Python-Dev] ANN: mxNumber -- Experimental Number Types, Version 0.2.0
Message-ID: <3AE73E8E.E9152718@lemburg.com>

ANNOUNCING

			mxNumber - Version 0.2.0

                Python Interface to GNU MP Number Types


INTRODUCTION
------------

As you all know, Moshe Zadka has been pushing for a new rational
number type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I thought, but well, it's done now.

There's still no web-page for this package, so I'm providing the
needed information in this posting.


WHAT'S NEW ?
------------

The 0.2.0 release is an alpha release. Everything is still in flux, so
expect bugs, strange behaviour etc.

Still, the package provides some interesting insights into the issues
you run into when dealing with computational representations of
numbers. For now, you should consider the package a pure fun-package
and playground for experiments.

New in this release are a parser for rational strings (formats "1/2"
and "3 1/3"), plus a new constructor FareyRational() which was
inspired by an algorithm written by Scott David Daniels and posted to
the Python Cookbook; see
    http://www.activestate.com/ASPN/Python/Cookbook/Recipe/52317

The FareyRational() constructor allows you to convert floating point
numbers to rationals, e.g. 1.3333 to 4/3.


INTERFACE
---------

The package is part of the eGenix.com EXPERIMENTAL package and called
mx.Number. It provides access to three numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision
4. FareyRational(value, maxden)
                       -- calculate the best rational represenation 
                          n/d of value such that d < maxden

DOWNLOADS
---------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
r3 = FareyRational(1.33333, 1000)
i = Integer("1231231231231231231231231")


The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


QUESTIONS
---------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From mal at lemburg.com  Wed Apr 25 23:15:58 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 25 Apr 2001 23:15:58 +0200
Subject: [Python-Dev] ANN: mxNumber -- Experimental Number Types, Version 0.2.0
Message-ID: <mailman.988234202.22353.clpa-moderators@python.org>

ANNOUNCING

			mxNumber - Version 0.2.0

                Python Interface to GNU MP Number Types


INTRODUCTION
------------

As you all know, Moshe Zadka has been pushing for a new rational
number type recently (at the conference) and also implemented a proof-
of-concept implementation of his rational PEP 239.

Since the GNU Multi-Precision Lib (GMP) already has all these tools
providing what people want most when it comes to numbers (precision
and speed), I thought that wrapping these as Python types would
be a good idea. I know that Alex Martelli has been working
on a similar approach, but that project (gmpy) seems to be inactive.

Anyway, even though the GMP is available for most Unix platforms
and MacOS, there was no relyable port for Windows. This was a show-
stopper for me, so I decided to port GMP to Windows, which was
harder than I thought, but well, it's done now.

There's still no web-page for this package, so I'm providing the
needed information in this posting.


WHAT'S NEW ?
------------

The 0.2.0 release is an alpha release. Everything is still in flux, so
expect bugs, strange behaviour etc.

Still, the package provides some interesting insights into the issues
you run into when dealing with computational representations of
numbers. For now, you should consider the package a pure fun-package
and playground for experiments.

New in this release are a parser for rational strings (formats "1/2"
and "3 1/3"), plus a new constructor FareyRational() which was
inspired by an algorithm written by Scott David Daniels and posted to
the Python Cookbook; see
    http://www.activestate.com/ASPN/Python/Cookbook/Recipe/52317

The FareyRational() constructor allows you to convert floating point
numbers to rationals, e.g. 1.3333 to 4/3.


INTERFACE
---------

The package is part of the eGenix.com EXPERIMENTAL package and called
mx.Number. It provides access to three numerical types:

1. Integer(value)      -- arbitrary precision integers much like Python
                          long only faster
2. Rational(nom,denom) -- rational numbers with Integers as
                          numerator and denominator
3. Float(value[,prec]) -- floating point number with at least
                          prec bits precision
4. FareyRational(value, maxden)
                       -- calculate the best rational represenation 
                          n/d of value such that d < maxden

DOWNLOADS
---------

* GMP 3.1.1
  - Unix:  GMP 3.1.1 must be installed (http://www.swox.com/gmp/)
  - Windows: GMP 3.1.1 is included in the download archives for Windows

* Python 2.1

* Optional: egenix-mx-base package available from
    http://www.lemburg.com/files/python/

* The "egenix-mx-experimental" package which includes mx.Number:

  Source:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.zip
  RPM:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0-1.i386-py2.1.rpm
  Windows installer:
    http://www.lemburg.com/files/python/egenix-mx-experimental-0.2.0.win32-py2.1.exe


Usage is simple:
----------------

from mx.Number import *
f = Float(3.141)
r1 = Rational(3.141)
r2 = Rational(2, 3)
r3 = FareyRational(1.33333, 1000)
i = Integer("1231231231231231231231231")


The coercion model will (someday) look like this:

                     Float
                       ^
                       |
       --------> Python float
      |                ^
      |                |
      |             Rational
      |                ^
      |                |
Python long ----->  Integer
      ^                ^
      |                |
       --------  Python integer

Complex numbers are not integrated into the picture since I
think that they should not be auto-coerced.

Some of these arrows are not implemented yet, others are not shown
(e.g. Integer(2) + "3" works as one would expect ;-).

Note that this is still a very rough version. Feedback is welcome.


QUESTIONS
---------

* What do you think about this coercion model ? Shouldn't we
  have a PEP for this ?

* Please try out the rational type and see if it fits your
  needs -- the results are sometimes surprising (due to the
  IEEE representations of floats); I'm sure this proof of
  concept will raise a few more questions regarding the
  usefulness of switching to rationals for literals like
  1.123.

* This implementation also showed that even though the coercion
  patches have made integraton of numerical types easier, a full
  integration is still hard to achieve. Some issues:

  - string formatting cannot be "overridden" to allow formatting
    of these new types

  - there is no way of providing PyArg_ParseTuple() parser markers
    for the types

  - there is no way to bind the types to a Python literal, e.g.
    by specifying a number literal modifier which is then bound
    to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"),
    2R / 3 -> Rational(2, 3) etc.

Comments ?
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/




From MarkH at ActiveState.com  Thu Apr 26 16:10:36 2001
From: MarkH at ActiveState.com (Mark Hammond)
Date: Fri, 27 Apr 2001 00:10:36 +1000
Subject: [Python-Dev] buffer interface (again)
In-Reply-To: <04b101c0c826$a0818890$e000a8c0@thomasnotebook>
Message-ID: <LCEPIIGDJPKCOIHOBJEPAEMMDKAA.MarkH@ActiveState.com>

> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Thomas Heller
> Sent: Thursday, 19 April 2001 2:43 AM

Better late than never!

> > I'd like to see a memory object that allocates and deallocates blocks
> > of memory and exports a pointer to its memory.  It could also set
> > privileges such are read/write, etc
>
> It's all there, in bufferobject.c.
> Except that the functions are not exposed to python...

I'm with Thomas too.  I could have used this a number of times, and have
even resorted to simple methods in my own .pyd files that wrap these APIs -
eg, win32file.AllocateReadBuffer() used for overlapped IO.

So while I think Thomas' bug is valid, I also understand we have to somehow
handle the issue the array module has.

Mark.




From MarkH at ActiveState.com  Thu Apr 26 16:26:39 2001
From: MarkH at ActiveState.com (Mark Hammond)
Date: Fri, 27 Apr 2001 00:26:39 +1000
Subject: [Python-Dev] Unicode and the Windows file system.
In-Reply-To: <LCEPIIGDJPKCOIHOBJEPOEKKDGAA.MarkH@ActiveState.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPIEMMDKAA.MarkH@ActiveState.com>

Now that 2.1 is out the door, how do we feel about getting these Unicode
changes in?

Mark.

> -----Original Message-----
> From: Mark Hammond [mailto:MarkH at ActiveState.com]
> Sent: Thursday, 22 March 2001 4:16 PM
> To: python-dev at python.org
> Subject: RE: [Python-Dev] Unicode and the Windows file system.
>
>
> I have submitted patch #410465 for this.
>
> http://sourceforge.net/tracker/?func=detail&aid=410465&group_id=54
> 70&atid=305470
>
> Comments are in the patch, so I won't repeat them here, but I
> would appreciate a few reviews on the code.  Particularly, my
> addition of a new format to PyArg_ParseTuple and the resulting
> extra string copy may raise a few eye-brows.
>
> I've even managed to include the new test file and its output in
> the patch, so it will hopefully apply cleanly and run a full test
> if you want to try it.
>
> Thanks,
>
> Mark.




From fredrik at effbot.org  Thu Apr 26 20:47:29 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Thu, 26 Apr 2001 20:47:29 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid>

> In the re-Module which come with Python version 2.0
> (Nov 28 11:10 re.py) the created MatchObjects cannot be
> copied with a deepcopy(). Switching back to the old
> "pre.py" as proposed in "re.py" makes everything work
> ok.

thought I'd check this one with python-dev before marking
it as "won't fix".  I cannot see any reason why anyone would
even attempt to deepcopy match objects...

(cannot see any reason why anyone would use deepcopy for
anything, but that's another story)

Cheers /F




From martin at loewis.home.cs.tu-berlin.de  Thu Apr 26 22:28:17 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 26 Apr 2001 22:28:17 +0200
Subject: [Python-Dev] [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de>

> thought I'd check this one with python-dev before marking it as
> "won't fix".  I cannot see any reason why anyone would even attempt
> to deepcopy match objects...

What's wrong with patch #419070, which fixes the bug? Like any other
immutable object, deepcopying a match object means returning it.

Regards,
Martin



From fredrik at effbot.org  Thu Apr 26 22:50:38 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Thu, 26 Apr 2001 22:50:38 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de>
Message-ID: <014b01c0ce92$8da742b0$e46940d5@hagrid>

Martin v. Loewis wrote:
> What's wrong with patch #419070, which fixes the bug? Like any other
> immutable object, deepcopying a match object means returning it.

what makes you think a match object is immutable?

import array, sre

a = array.array("c", "abcde")
m = sre.search("bcd", a)
print m.group(0)

Cheers /F




From martin at loewis.home.cs.tu-berlin.de  Thu Apr 26 23:12:45 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 26 Apr 2001 23:12:45 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <014b01c0ce92$8da742b0$e46940d5@hagrid> (fredrik@effbot.org)
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de> <014b01c0ce92$8da742b0$e46940d5@hagrid>
Message-ID: <200104262112.f3QLCjd02333@mira.informatik.hu-berlin.de>

> what makes you think a match object is immutable?

Because you cannot modify their state.

> import array, sre
> 
> a = array.array("c", "abcde")
> m = sre.search("bcd", a)
> print m.group(0)

a1 = m.group(0)
a1[0]='z'
print m.group(0)

So you'd have to modify a, to modify m.group(0). To catch this case,
you might want to do

def copy_match(m):
  g = m.group(0)
  if copy(g) is not g:
    raise KeyError    # will be re-raised as copy.Error
  return g

That will restore backwards compatibility with pre, which is what the
submitter of the bug requested.

Regards,
Martin



From fredrik at effbot.org  Thu Apr 26 23:48:59 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Thu, 26 Apr 2001 23:48:59 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de> <014b01c0ce92$8da742b0$e46940d5@hagrid> <200104262112.f3QLCjd02333@mira.informatik.hu-berlin.de>
Message-ID: <018f01c0ce9a$b49c6e10$e46940d5@hagrid>

Martin v. Loewis wrote:
> Because you cannot modify their state.

same thing as tuples: you cannot modify the tuples, but you
can modify their members.  as its name implies, deepcopy can
deal with tuples...

> So you'd have to modify a, to modify m.group(0). To catch this case,
> you might want to do
> 
> def copy_match(m):
>   g = m.group(0)
>   if copy(g) is not g:
>     raise KeyError    # will be re-raised as copy.Error
>   return g
> 
> That will restore backwards compatibility with pre, which is what the
> submitter of the bug requested.

which means that deepcopy sometimes work on match objects, and
sometimes doesn't.  *that* sounds like a bug to me.

frankly, I don't think the original problem is a bug at all -- I think someone's
abusing a CPython 1.5.2 implementation detail.  it's not documented to work,
it's not in the test suite, and it's not exactly the only thing in there that cannot
be deepcopied...

introducing broken behaviour to deal with someone's broken program sounds
like a rather lousy idea -- and a dangerous precedent.  user code shouldn't
depend on accidental implementation details.

Cheers /F




From fredrik at effbot.org  Fri Apr 27 00:08:47 2001
From: fredrik at effbot.org (Fredrik Lundh)
Date: Fri, 27 Apr 2001 00:08:47 +0200
Subject: [Python-Dev] anyone have an Irix box?
Message-ID: <01ad01c0ce9d$790ac470$e46940d5@hagrid>

SRE doesn't work at all under Irix8/gcc, according to this report
https://sourceforge.net/tracker/?func=detail&aid=233790&group_id=5470&atid=105470

unfortunately, the submitter didn't provide any contact info, and
hasn't bothered to follow up with more details.  and I still don't
have a working SGI box.

any ideas how to deal with this?

Cheers /F




From tim.one at home.com  Fri Apr 27 01:21:24 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 26 Apr 2001 19:21:24 -0400
Subject: [Python-Dev] anyone have an Irix box?
In-Reply-To: <01ad01c0ce9d$790ac470$e46940d5@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCIENLJOAA.tim.one@home.com>

> SRE doesn't work at all under Irix8/gcc, according to this report
> https://sourceforge.net/tracker/?func=detail&aid=233790&group_id=54
> 70&atid=105470
>
> unfortunately, the submitter didn't provide any contact info, and
> hasn't bothered to follow up with more details.  and I still don't
> have a working SGI box.
>
> any ideas how to deal with this?

The first guess on an SGI box is usually the last:  recompile w/o
optimization.  But if they're *really* using gcc that's probably not
relevant.

In the latter case Guido knows what to do.  But he's not going to tell you
before you tell him how to close the 517 HP-UX thread bugs assigned to him
first <0.9 wink>.




From mwh21 at cam.ac.uk  Fri Apr 27 01:45:05 2001
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 27 Apr 2001 00:45:05 +0100
Subject: [Python-Dev] anyone have an Irix box?
In-Reply-To: "Fredrik Lundh"'s message of "Fri, 27 Apr 2001 00:08:47 +0200"
References: <01ad01c0ce9d$790ac470$e46940d5@hagrid>
Message-ID: <m3sniv2pku.fsf@atrus.jesus.cam.ac.uk>

"Fredrik Lundh" <fredrik at effbot.org> writes:

> SRE doesn't work at all under Irix8/gcc, according to this report
> https://sourceforge.net/tracker/?func=detail&aid=233790&group_id=5470&atid=105470
> 
> unfortunately, the submitter didn't provide any contact info, and
> hasn't bothered to follow up with more details.  and I still don't
> have a working SGI box.
> 
> any ideas how to deal with this?

Quinn Dunkan (quinn at dinar.ugcs.caltech.edu) has/had an Irix box he
could test stuff on (I tried to help him sort some readline stuff out
once but got nowhere).  I'm sure he would run make test and email you
the output if you asked nicely.  While not ideal, if it works for him
it would give you more justification in closing the report unless the
OP comes up with some more info.

Cheers,
M.

-- 
  Just put the user directories on a 486 with deadrat7.1 and turn the
  Octane into the afforementioned beer fridge and keep it in your
  office. The lusers won't notice the difference, except that you're
  more cheery during office hours.              -- Pim van Riezen, asr




From tim.one at home.com  Fri Apr 27 01:52:55 2001
From: tim.one at home.com (Tim Peters)
Date: Thu, 26 Apr 2001 19:52:55 -0400
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com>

[/F]
> thought I'd check this one with python-dev before marking
> it as "won't fix".  I cannot see any reason why anyone would
> even attempt to deepcopy match objects...

Likely just because they're part of other objects, like bound to instance
attributes, or members of lists.  No matter how deep they're buried, someone
trying to deepcopy a container will eventually need to deepcopy them too.

> (cannot see any reason why anyone would use deepcopy for
> anything, but that's another story)

It's a std way to get a clone of an object, and when you don't want mutations
of the clone to have any effect on the original (or vice versa).  Perhaps if
I call it the Clone Pattern, people will assume that makes it a good thing
and cut that part of the debate mercifully short <wink>.

It's *nice* to supply a deepcopy operation whenever it's doable with
reasonable effort.  I agree you're not required to in this case -- but it
would still be "nice", if that's feasible.




From martin at loewis.home.cs.tu-berlin.de  Fri Apr 27 07:07:56 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 27 Apr 2001 07:07:56 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <018f01c0ce9a$b49c6e10$e46940d5@hagrid> (fredrik@effbot.org)
References: <200104262028.f3QKSHO01810@mira.informatik.hu-berlin.de> <014b01c0ce92$8da742b0$e46940d5@hagrid> <200104262112.f3QLCjd02333@mira.informatik.hu-berlin.de> <018f01c0ce9a$b49c6e10$e46940d5@hagrid>
Message-ID: <200104270507.f3R57uG01297@mira.informatik.hu-berlin.de>

> which means that deepcopy sometimes work on match objects, and
> sometimes doesn't.  *that* sounds like a bug to me.

So I'll provide documentation; that will make it a feature. arrays
cannot be copied either - for no good reason, AFAICT. Given that they
cannot be copied, it is not surprising that match objects referring to
array objects cannot be deepcopied.

The "sometimes works, sometimes doesn't" aspect of deepcopy holds for
any container object:

class X:pass
x = X()
x.values = [1,2,3]
y = copy.deepcopy(x)                # succeeds
x1 = X()
x1.values = array.array("i",[1,2,3])
y1 = copy.deepcopy(x1)              # fails

> frankly, I don't think the original problem is a bug at all -- I
> think someone's abusing a CPython 1.5.2 implementation detail.

It is not abuse. There was no indication in the documentation that
there might be a problem. He probably has a match object as an
instance attribute, and wants to copy the instance. He does not care
whether the match object is shared across copies. He only wants the
instance copying to succeed - which it does in Python 1.5, whereas it
fails in 2.0.

> it's not documented to work, it's not in the test suite, and it's
> not exactly the only thing in there that cannot be deepcopied...

The documentation says

# This version does not copy types like module, class, function,
# method, stack trace, stack frame, file, socket, window, array, or
# any similar types.

So is a match object of "any similar type" or not? Next time, somebody
breaks copying tuples, and claims that tuples are certainly similar to
arrays... There is no indication whatsoever that copying match objects
is not supported - even though the documentation does give a list of
types that are not supported.

> introducing broken behaviour to deal with someone's broken program sounds
> like a rather lousy idea -- and a dangerous precedent.  user code shouldn't
> depend on accidental implementation details.

As I said: the user reading the 1.5 documentation had no way to tell
that it was an "accidental implementation detail". The user reading
the 2.0 documentation had no way to tell that this detail had been
changed. So there clearly is a bug here.

If you want to reject my patch, fine. But at a minimum, there should
be documentation changes to deal with the problem.

Regards,
Martin



From thomas.heller at ion-tof.com  Fri Apr 27 09:53:09 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 27 Apr 2001 09:53:09 +0200
Subject: [Python-Dev] Memory management question
Message-ID: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook>

I'm trying to port Don Beaudry's objectmodule to Python 2.0
and encountered the following problem. Here is a part from Don's code:

  co = (MetaClassObject*) PyClass_New(NULL, methods, name);
  co = PyObject_Realloc(co, sizeof (MetaClassObject));

As you see, he is trying to achive cheap code reuse.
This code does not work.

I have tracked it down to the following sample, which does also not
work. In the debug version on windows, the PyObject_REALLOC
fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)

 op = PyObject_NEW(PyClassObject, &PyClass_Type);
 op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);

Should the above work or am I doing something wrong?

Regards,

Thomas




From fredrik at pythonware.com  Fri Apr 27 11:06:37 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 27 Apr 2001 11:06:37 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com>
Message-ID: <00e801c0cef9$5e142150$0900a8c0@spiff>

tim wrote:
> It's a std way to get a clone of an object, and when you don't want mutations
> of the clone to have any effect on the original (or vice versa).  Perhaps if
> I call it the Clone Pattern, people will assume that makes it a good thing
> and cut that part of the debate mercifully short <wink>.

which leads to a followup question: the current approach
seems to be to hack the copy.py file for each and every
type.  imo, that's rather unpythonic, and also introduces
lots of unnecessary module dependencies.

time to add a __clone__ slot?

or could someone who knows what he's doing here address
this comment in copy.py:

    # XXX need to support copy_reg here too...

Cheers /F





From mal at lemburg.com  Fri Apr 27 11:20:59 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Apr 2001 11:20:59 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not 
 deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com> <00e801c0cef9$5e142150$0900a8c0@spiff>
Message-ID: <3AE939FB.D14B2F9B@lemburg.com>

Fredrik Lundh wrote:
> 
> tim wrote:
> > It's a std way to get a clone of an object, and when you don't want mutations
> > of the clone to have any effect on the original (or vice versa).  Perhaps if
> > I call it the Clone Pattern, people will assume that makes it a good thing
> > and cut that part of the debate mercifully short <wink>.
> 
> which leads to a followup question: the current approach
> seems to be to hack the copy.py file for each and every
> type.  imo, that's rather unpythonic, and also introduces
> lots of unnecessary module dependencies.
> 
> time to add a __clone__ slot?
> 
> or could someone who knows what he's doing here address
> this comment in copy.py:
> 
>     # XXX need to support copy_reg here too...

All you have to do is implement the copy protocol (ie. .copy())
for the type/class in question.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/



From fredrik at pythonware.com  Fri Apr 27 11:51:23 2001
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 27 Apr 2001 11:51:23 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not  deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com> <00e801c0cef9$5e142150$0900a8c0@spiff> <3AE939FB.D14B2F9B@lemburg.com>
Message-ID: <010e01c0ceff$9f8cc8c0$0900a8c0@spiff>

mal wrote:
> > time to add a __clone__ slot?
> >
> > or could someone who knows what he's doing here address
> > this comment in copy.py:
> >
> >     # XXX need to support copy_reg here too...
>
> All you have to do is implement the copy protocol (ie. .copy())
> for the type/class in question.

cannot find any support for that in the copy module (not in 2.0, at least)

but another reading revealed support for __copy__ and __deepcopy__
methods in at least 1.5.2 and later.  intriguing...

Cheers /F





From mal at lemburg.com  Fri Apr 27 11:57:13 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Apr 2001 11:57:13 +0200
Subject: [Python-Dev] Memory management question
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook>
Message-ID: <3AE94279.DBF73856@lemburg.com>

Thomas Heller wrote:
> 
> I'm trying to port Don Beaudry's objectmodule to Python 2.0
> and encountered the following problem. Here is a part from Don's code:
> 
>   co = (MetaClassObject*) PyClass_New(NULL, methods, name);
>   co = PyObject_Realloc(co, sizeof (MetaClassObject));
> 
> As you see, he is trying to achive cheap code reuse.
> This code does not work.
> 
> I have tracked it down to the following sample, which does also not
> work. In the debug version on windows, the PyObject_REALLOC
> fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)
> 
>  op = PyObject_NEW(PyClassObject, &PyClass_Type);
>  op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);
> 
> Should the above work or am I doing something wrong?

Wouldn't it be safer to first create a MetaClassObject and then
let the standard ClassObject initialize it ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From mal at lemburg.com  Fri Apr 27 12:14:41 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Apr 2001 12:14:41 +0200
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not  
 deepcopy()able
References: <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com> <00e801c0cef9$5e142150$0900a8c0@spiff> <3AE939FB.D14B2F9B@lemburg.com> <010e01c0ceff$9f8cc8c0$0900a8c0@spiff>
Message-ID: <3AE94691.972F02D7@lemburg.com>

Fredrik Lundh wrote:
> 
> mal wrote:
> > > time to add a __clone__ slot?
> > >
> > > or could someone who knows what he's doing here address
> > > this comment in copy.py:
> > >
> > >     # XXX need to support copy_reg here too...
> >
> > All you have to do is implement the copy protocol (ie. .copy())
> > for the type/class in question.
> 
> cannot find any support for that in the copy module (not in 2.0, at least)
> 
> but another reading revealed support for __copy__ and __deepcopy__
> methods in at least 1.5.2 and later.  intriguing...

You're right... the two methods are named __copy__ and __deepcopy__.
Both should return either copies of the object or simply new reference
in case the object's are immutable.

I've implemented these in mxDateTime and that was all it took to
get the copy module happy (at least in Python 1.5.2).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From guido at digicool.com  Fri Apr 27 15:30:31 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 08:30:31 -0500
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: Your message of "Thu, 26 Apr 2001 20:47:29 +0200."
             <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid> 
References: <00ef01c0ce81$6cfe6bd0$e46940d5@hagrid> 
Message-ID: <200104271330.IAA20006@cj20424-a.reston1.va.home.com>

[Sorry, this bounced -- my new work mail isn't set up right yet]

> > In the re-Module which come with Python version 2.0
> > (Nov 28 11:10 re.py) the created MatchObjects cannot be
> > copied with a deepcopy(). Switching back to the old
> > "pre.py" as proposed in "re.py" makes everything work
> > ok.
> 
> thought I'd check this one with python-dev before marking
> it as "won't fix".  I cannot see any reason why anyone would
> even attempt to deepcopy match objects...
> 
> (cannot see any reason why anyone would use deepcopy for
> anything, but that's another story)

Why don't you ask what they were doing?  They cared enough to figure a
workaround *and* report a bug.  I think they deserve a better answer
than Won't Fix.

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



From guido at digicool.com  Fri Apr 27 17:42:50 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 10:42:50 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 09:53:09 +0200."
             <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> 
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> 
Message-ID: <200104271542.KAA20312@cj20424-a.reston1.va.home.com>

> I have tracked it down to the following sample, which does also not
> work. In the debug version on windows, the PyObject_REALLOC
> fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)
> 
>  op = PyObject_NEW(PyClassObject, &PyClass_Type);
>  op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);
> 
> Should the above work or am I doing something wrong?

Probably this doesn't work because of the GC header.  The 'op' pointer
does not point to the start of the allocated memory block.
PyObject_NEW and friends know about this, but PyObject_REALLOC
doesn't.  That's what the assertion is trying to tell you.

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



From thomas.heller at ion-tof.com  Fri Apr 27 16:58:27 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 27 Apr 2001 16:58:27 +0200
Subject: [Python-Dev] Memory management question
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook>  <200104271542.KAA20312@cj20424-a.reston1.va.home.com>
Message-ID: <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook>

> > I have tracked it down to the following sample, which does also not
> > work. In the debug version on windows, the PyObject_REALLOC
> > fails with an assertion-error: _CrtIsValidHeapPointer(pUserData)
> > 
> >  op = PyObject_NEW(PyClassObject, &PyClass_Type);
> >  op = PyObject_REALLOC(op, sizeof(PyClassObject) + 20);
> > 
> > Should the above work or am I doing something wrong?
> 
> Probably this doesn't work because of the GC header.  The 'op' pointer
> does not point to the start of the allocated memory block.
> PyObject_NEW and friends know about this, but PyObject_REALLOC
> doesn't.  That's what the assertion is trying to tell you.
Yes, I've also trakced it down to this.

I assume, PyObject_NEW is a friend of PyObject_DEL, and
so are PyObject_MALLOC, PyObject_REALLOC, and PyObject_FREE - 
but the relationship between the first and the second category
is somewhat cooler...

Is there any (official) way to realloc the memory returned by
PyObject_NEW ?

(Always pushing the apis beyond their limits :-)

Thomas




From guido at digicool.com  Fri Apr 27 18:39:46 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 11:39:46 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 16:58:27 +0200."
             <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> 
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com>  
            <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> 
Message-ID: <200104271639.LAA20790@cj20424-a.reston1.va.home.com>

> Is there any (official) way to realloc the memory returned by
> PyObject_NEW ?

Not if the object participates in GC.

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



From thomas.heller at ion-tof.com  Fri Apr 27 17:56:34 2001
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 27 Apr 2001 17:56:34 +0200
Subject: [Python-Dev] Memory management question
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com>              <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook>  <200104271639.LAA20790@cj20424-a.reston1.va.home.com>
Message-ID: <038701c0cf32$a29bfc60$e000a8c0@thomasnotebook>

> > Is there any (official) way to realloc the memory returned by
> > PyObject_NEW ?
> 
> Not if the object participates in GC.

I'll shut up after this one:

Would a PyObject_RESIZE function/macro make sense?

Thomas




From guido at digicool.com  Fri Apr 27 19:01:37 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 12:01:37 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 17:56:34 +0200."
             <038701c0cf32$a29bfc60$e000a8c0@thomasnotebook> 
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com> <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> <200104271639.LAA20790@cj20424-a.reston1.va.home.com>  
            <038701c0cf32$a29bfc60$e000a8c0@thomasnotebook> 
Message-ID: <200104271701.MAA21256@cj20424-a.reston1.va.home.com>

> I'll shut up after this one:
> 
> Would a PyObject_RESIZE function/macro make sense?
> 
> Thomas

Not for anybody else besides you, I think.

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



From Greg.Wilson at baltimore.com  Fri Apr 27 19:26:52 2001
From: Greg.Wilson at baltimore.com (Greg Wilson)
Date: Fri, 27 Apr 2001 13:26:52 -0400
Subject: [Python-Dev] FW: how will you be writing code 10 years from now?
Message-ID: <930BBCA4CEBBD411BE6500508BB3328F27AF41@nsamcanms1.ca.baltimore.com>

The following is a webcast from a (preliminary non-official) meeting on
C++0x (C++, the next generation). Could be a bit of foreshadowing on how
things will develop (or prove to be giant red herring if they decide not to
follow any of these ideas)

http://technetcast.ddj.com/tnc_play_stream.html?stream_id=560



From moshez at zadka.site.co.il  Fri Apr 27 19:50:13 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Fri, 27 Apr 2001 20:50:13 +0300
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <00e801c0cef9$5e142150$0900a8c0@spiff>
References: <00e801c0cef9$5e142150$0900a8c0@spiff>, <LNBBLJKPBEHFEDALKOLCCENNJOAA.tim.one@home.com>
Message-ID: <E14tCNh-0003Dj-00@darjeeling>

On Fri, 27 Apr 2001, "Fredrik Lundh" <fredrik at pythonware.com> wrote:

> time to add a __clone__ slot?

It's called __setstate__ and __getstate__, I think?
Don't these have an appropriate C-level slots?

>     # XXX need to support copy_reg here too...

I think it's talking about having copy be the same (but without the
middle man) as Unpickle.loads(Pickle.dumps(o)) (which is a perfect
copy.deepcopy, if a bit wasteful.

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From nas at python.ca  Fri Apr 27 20:10:23 2001
From: nas at python.ca (Neil Schemenauer)
Date: Fri, 27 Apr 2001 11:10:23 -0700
Subject: [Python-Dev] Memory management question
In-Reply-To: <200104271639.LAA20790@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Fri, Apr 27, 2001 at 11:39:46AM -0500
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com> <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> <200104271639.LAA20790@cj20424-a.reston1.va.home.com>
Message-ID: <20010427111023.A23210@glacier.fnational.com>

Guido van Rossum wrote:
> > Is there any (official) way to realloc the memory returned by
> > PyObject_NEW ?
> 
> Not if the object participates in GC.

I going to see if I can fix this for 2.2.  My current thinking is
that there should be memory management APIs for GC objects,
something like:

    PyObject_GC_New()
    PyObject_GC_NewVar()
    PyObject_GC_Realloc()
    PyObject_GC_Del()

The non-GC APIs would no longer have to check the type flags
which would be a bit of a speed win.  The _AS_GC, _FROM_GC macros
would not have to be used as much and the GC implementation would
have more freedom about how to allocate things.

  Neil



From guido at digicool.com  Fri Apr 27 21:14:20 2001
From: guido at digicool.com (Guido van Rossum)
Date: Fri, 27 Apr 2001 14:14:20 -0500
Subject: [Python-Dev] Memory management question
In-Reply-To: Your message of "Fri, 27 Apr 2001 11:10:23 MST."
             <20010427111023.A23210@glacier.fnational.com> 
References: <03e301c0ceef$1b297020$e000a8c0@thomasnotebook> <200104271542.KAA20312@cj20424-a.reston1.va.home.com> <01f501c0cf2a$848d4240$e000a8c0@thomasnotebook> <200104271639.LAA20790@cj20424-a.reston1.va.home.com>  
            <20010427111023.A23210@glacier.fnational.com> 
Message-ID: <200104271914.OAA24467@cj20424-a.reston1.va.home.com>

> I going to see if I can fix this for 2.2.  My current thinking is
> that there should be memory management APIs for GC objects,
> something like:
> 
>     PyObject_GC_New()
>     PyObject_GC_NewVar()
>     PyObject_GC_Realloc()
>     PyObject_GC_Del()
> 
> The non-GC APIs would no longer have to check the type flags
> which would be a bit of a speed win.  The _AS_GC, _FROM_GC macros
> would not have to be used as much and the GC implementation would
> have more freedom about how to allocate things.

Looks good!

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



From tim.one at home.com  Fri Apr 27 20:58:03 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 27 Apr 2001 14:58:03 -0400
Subject: [Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In-Reply-To: <00e801c0cef9$5e142150$0900a8c0@spiff>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEAIJPAA.tim.one@home.com>

[Fredrik Lundh]
> which leads to a followup question: the current approach
> seems to be to hack the copy.py file for each and every
> type.  imo, that's rather unpythonic, and also introduces
> lots of unnecessary module dependencies.
>
> time to add a __clone__ slot?

Note that classes can supply custom cloners via defining __copy__ and
__deepcopy__ methods, without changing copy.py.

A __clone__ slot for *types* would need to address the shallow vs deep
question too, along with the other __getinitargs__, __getstate__,
__setstate__ gimmicks.  How many slots does that add up to?  I leave it to
the PEP author to count them <wink>.

The copy.py protocols kinda grew up with pickle.py's, and together still have
the flavor (to my tongue) of a prototype caught late in midstream.  That is,
it feels like they're not quite finished yet.

> or could someone who knows what he's doing here address
> this comment in copy.py:
>
>     # XXX need to support copy_reg here too...

copy_reg is one of the pickle.py facilities that copy.py "should use" too;
it's a registration database that tells pickle what to do about objects of
types pickle doesn't understand directly (so *could* also be directly
relevant to cloning objects of types copy.py doesn't understand directly --
depending).




From martin at loewis.home.cs.tu-berlin.de  Fri Apr 27 21:10:14 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 27 Apr 2001 21:10:14 +0200
Subject: [Python-Dev] SF changing directory structure
Message-ID: <200104271910.f3RJAE301849@mira.informatik.hu-berlin.de>

As some of you may have noticed, the Python web pages are now in
/home/groups/p/py/python on SourceForge; the symbolic link
/home/groups/python will be removed shortly.

There might be still a number of files that refer to the old location,
atleast htdocs/sf-faq.html, and perhaps crontabs. Whoever is in charge
of these should probably update them.

Regards,
Martin





From tim.one at home.com  Fri Apr 27 21:57:12 2001
From: tim.one at home.com (Tim Peters)
Date: Fri, 27 Apr 2001 15:57:12 -0400
Subject: [Python-Dev] SF changing directory structure
In-Reply-To: <200104271910.f3RJAE301849@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEAPJPAA.tim.one@home.com>

[Martin v. Loewis]
> /home/groups/p/py/python on SourceForge; the symbolic link
> /home/groups/python will be removed shortly.

Phooey.  Thanks for the warning!  I sure didn't know about it.

> There might be still a number of files that refer to the old location,
> atleast htdocs/sf-faq.html, and perhaps crontabs. Whoever is in charge
> of these should probably update them.

Nobody is in charge:  if you know of a problem, please fix it.  All the HTML
stuff is under CVS control, and all Python project members have commit access
for it, same as for everything else in the Python source tree; it's just
under the nondist branch instead of the dist branch.




From tim.one at home.com  Sat Apr 28 09:24:48 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 28 Apr 2001 03:24:48 -0400
Subject: [Python-Dev] Iterators, map, xreadlines and docs
Message-ID: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>

A confused user on c.l.py reported that while

    for x in file.xreadlines():

works fine,

    map(whatever, file.xreadlines())

blows up with

    TypeError: argument 2 to map() must be a sequence object

The docs say both contexts require "a sequence", so this is baffling to them.

It's apparently because map() internally insists that the sq_length slot be
non-null (but it's null in the xreadlines object), despite that map() doesn't
use it for anything other than *guessing* a result size (it keeps going until
IndexError is raised regardless of what len() returns, growing or shrinking
the preallocated result list as needed).

I think that's a bug in map().  Anyone disagree?

If so, fine, map() has to be changed to work with iterators anyway <wink>.

How are we going to identify all the places that need to become
iterator-aware, get all the code changed, and update the docs to match?  In
effect, a bunch of docs for arguments need to say, in some words or other,
that the args must implement the iterator interface or protocol.  I think
it's essential that we define the latter only once.  But the docs don't
really define any interfaces/protocols now, so it's unclear where to put
that.

Fred, Pronounce.  Better sooner than later, else I bet a bunch of code
changes will get checked in without appropriate doc changes, and the 2.2 docs
won't match the code.




From martin at loewis.home.cs.tu-berlin.de  Sat Apr 28 09:28:35 2001
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 28 Apr 2001 09:28:35 +0200
Subject: [Python-Dev] SF changing directory structure
Message-ID: <200104280728.f3S7SZ801219@mira.informatik.hu-berlin.de>

> Nobody is in charge: if you know of a problem, please fix it.  All
> the HTML stuff is under CVS control, and all Python project members
> have commit access for it, same as for everything else in the Python
> source tree; it's just under the nondist branch instead of the dist
> branch.

Ok, changed in CVS. Is the answer to SF-FAQ question 1.3 still
correct? That modified files have to manually uploaded to SF? That
answer does not mention nondist/sf-html at all...

Regards,
Martin



From tim.one at home.com  Sat Apr 28 09:48:50 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 28 Apr 2001 03:48:50 -0400
Subject: [Python-Dev] RE: SF changing directory structure
In-Reply-To: <200104280728.f3S7SZ801219@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCKECLJPAA.tim.one@home.com>

[Martin v. Loewis]
> Ok, changed in CVS.

Thank you!

> Is the answer to SF-FAQ question 1.3 still correct?
> That modified files have to manually uploaded to SF?

AFAIK, yes.  I didn't write the question or the answer, though, and don't
believe I read that part of the FAQ before.  /F's pep2html.py script is used
to generate the HTML form of PEPs, and its -i (install) option never worked
for me on Windows, so I've always done that bit by hand.

Indeed, your changes didn't *show up* via the SF interface before I (just)
did

scp sf-faq.html \
    tim_one at shell.sourceforge.net:/home/groups/p/py/python/htdocs/

> That answer does not mention nondist/sf-html at all...

It apparently doesn't mention a lot of things.  But I'm not going to change
it since I don't have a clear understanding of how this stuff works; I only
know what I do by hand that works in the end.




From moshez at zadka.site.co.il  Sat Apr 28 11:07:43 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Sat, 28 Apr 2001 12:07:43 +0300
Subject: [Python-Dev] Iterators, map, xreadlines and docs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
Message-ID: <E14tQhb-0004Dd-00@darjeeling>

On Sat, 28 Apr 2001 03:24:48 -0400, "Tim Peters" <tim.one at home.com> wrote:

> A confused user on c.l.py reported that while
> 
>     for x in file.xreadlines():
> 
> works fine,
> 
>     map(whatever, file.xreadlines())
> 
> blows up with
> 
>     TypeError: argument 2 to map() must be a sequence object
...
> I think that's a bug in map().  Anyone disagree?

I agree...but when we talked about it in c.l.py, I said that and you
said map() should be deprecated. Why the sudden change of heart?
why shouldn't it be changed to

[whatever(x) for x in file.xreadlines()]?

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From tim.one at home.com  Sat Apr 28 11:17:33 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 28 Apr 2001 05:17:33 -0400
Subject: [Python-Dev] Iterators, map, xreadlines and docs
In-Reply-To: <E14tQhb-0004Dd-00@darjeeling>
Message-ID: <LNBBLJKPBEHFEDALKOLCGECNJPAA.tim.one@home.com>

> ...
>> I think that's a bug in map().  Anyone disagree?

[Moshe]
> I agree...but when we talked about it in c.l.py, I said that and you
> said map() should be deprecated. Why the sudden change of heart?

This doesn't ring a bell.  I don't even recall *seeing* a msg from you in the
.xreadlines() vs map() thread ...

> why shouldn't it be changed to
>
> [whatever(x) for x in file.xreadlines()]?

I'm not keen to eradicate map() from the face of the Earth regardless, and
until it *is* deprecated (if ever), it's supported.  But this is all moot
since I already checked in the map() fix.

How to deal with the iterator docs is still an important issue.




From moshez at zadka.site.co.il  Sat Apr 28 12:14:33 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Sat, 28 Apr 2001 13:14:33 +0300
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.198,2.199
In-Reply-To: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>
References: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <E14tRkH-0004KU-00@darjeeling>

On Sat, 28 Apr 2001, Tim Peters <tim_one at users.sourceforge.net> wrote:

> Modified Files:
> 	bltinmodule.c 
> Log Message:
> Fix buglet reported on c.l.py:  map(fnc, file.xreadlines()) blows up.
> Also a 2.1 bugfix candidate (am I supposed to do something with those?).
> Took away map()'s insistence that sequences support __len__, and cleaned
> up the convoluted code that made it *look* like it really cared about
> __len__ (in fact the old ->len field was only *used* as a flag bit, as
> the main loop only looked at its sign bit, setting the field to -1 when
> IndexError got raised; renamed the field to ->saw_IndexError instead).

Can anyone give me his opinion about whether 2.0.1 should have this
bug fix? It's not just for file.xreadlines(): the older fileinput.fileinput()
is hurt by this as well...

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org



From fdrake at acm.org  Sat Apr 28 14:50:54 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sat, 28 Apr 2001 08:50:54 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.198,2.199
In-Reply-To: <E14tRkH-0004KU-00@darjeeling>
References: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>
	<E14tRkH-0004KU-00@darjeeling>
Message-ID: <15082.48302.168082.219299@cj42289-a.reston1.va.home.com>

Moshe Zadka writes:
 > Can anyone give me his opinion about whether 2.0.1 should have this
 > bug fix? It's not just for file.xreadlines(): the older
 > fileinput.fileinput() is hurt by this as well...

  I don't know about 2.0.1, but 2.1.1 definately should.


  -Fred

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




From guido at digicool.com  Sat Apr 28 19:11:13 2001
From: guido at digicool.com (Guido van Rossum)
Date: Sat, 28 Apr 2001 12:11:13 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.198,2.199
In-Reply-To: Your message of "Sat, 28 Apr 2001 13:14:33 +0300."
             <E14tRkH-0004KU-00@darjeeling> 
References: <E14tPxo-0001LL-00@usw-pr-cvs1.sourceforge.net>  
            <E14tRkH-0004KU-00@darjeeling> 
Message-ID: <200104281711.MAA29948@cj20424-a.reston1.va.home.com>

> Can anyone give me his opinion about whether 2.0.1 should have this
> bug fix? It's not just for file.xreadlines(): the older fileinput.fileinput()
> is hurt by this as well...

I wouldn't bother -- 2.0.1 doesn't need to be better than 2.1.

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



From fdrake at acm.org  Sun Apr 29 03:41:04 2001
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sat, 28 Apr 2001 21:41:04 -0400 (EDT)
Subject: [Python-Dev] Re: Iterators, map, xreadlines and docs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCGECJJPAA.tim.one@home.com>
Message-ID: <15083.28976.418924.738526@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > effect, a bunch of docs for arguments need to say, in some words or other,
 > that the args must implement the iterator interface or protocol.  I think
 > it's essential that we define the latter only once.  But the docs don't
 > really define any interfaces/protocols now, so it's unclear where to put
 > that.

  Won't there be at least one standard iterator object defined for
lists, etc.?  That could be described in the built-in types section
(as with files, lists, etc.) of the Library Reference.  That will be
used as the definition of the iterator protocol in the same way the
file object description there is referred to from places that want
file or file-like objects.
  I think we need some re-organization of the built-in types section
to separate abstract protocols from specific implementations, but
that's an orthagonal aspect and can be handled at the same time as the
rest of the built-in types.
  Specific changes for places that accept iterators should be made as
the code is changed, as usual.  Please describe the changes clearly in
checkin messages so iterator related changes don't propogate to the
maintenance branch.


  -Fred

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




From MarkH at ActiveState.com  Sun Apr 29 04:14:43 2001
From: MarkH at ActiveState.com (Mark Hammond)
Date: Sun, 29 Apr 2001 12:14:43 +1000
Subject: [Python-Dev] Slight wart in __all__
Message-ID: <LCEPIIGDJPKCOIHOBJEPKEBEDLAA.MarkH@ActiveState.com>

I just got caught out by this:

"""
def foo():
    pass

__all__ = [foo]
"""

Then at the interactive prompt:

>>> from foo import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: attribute name must be string


The problem is that __all__ contains a function object rather than a string
object.  I had to use the debugger to determine why I was getting the
failure :(  All you 2.1 veterans will immediately pick that it should read
'__all__ = ["foo"]'

Looking at the __all__ code:

		if (skip_leading_underscores &&
		    PyString_Check(name) &&
		    PyString_AS_STRING(name)[0] == '_')
		{
			Py_DECREF(name);
			continue;
		}
		value = PyObject_GetAttr(v, name);

PyObject_GetAttr explicitly handles string and unicode objects.  However,
code here won't like Unicode that much :)

Would it make sense to a explicitly raise a more meaningful exception here
if __all__ doesnt contain strings?




From tim.one at home.com  Sun Apr 29 05:17:47 2001
From: tim.one at home.com (Tim Peters)
Date: Sat, 28 Apr 2001 23:17:47 -0400
Subject: [Python-Dev] RE: Iterators, map, xreadlines and docs
In-Reply-To: <15083.28976.418924.738526@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEEAJPAA.tim.one@home.com>

[Fred]
>   Won't there be at least one standard iterator object defined for
> lists, etc.?

>>> iter([])
<iterator object at 00792640>

>>> iter({})
<dictionary-iterator object at 00793A40>

>>> iter(())
<iterator object at 00792640>

>>> import sys
>>> iter(sys.stdin)
<callable-iterator object at 00793FE0>

>>> class C:
...     def __iter__(self): return self
...
>>> iter(C())
<__main__.C instance at 007938EC>
>>>

What do those have in common?  Objects and types are the wrong way to
approach this one:  it's really of no interest that, e.g., iter(list) and
iter(dict) return objects of different types; what *is* interesting is that
iter(whatever) returns *an* object that conforms to the iterator protocol (or
"implements the iterator interface" -- all the same to me).  You can give
*examples* of builtin iterator types that conform to the protocol, but the
protocol needs to be defined for its own sake first.  The protocol is
fundamental, and is neither an object nor a type.

> That could be described in the built-in types section (as with
> files, lists, etc.) of the Library Reference.  That will be used
> as the definition of the iterator protocol in the same way the
> file object description there is referred to from places that want
> file or file-like objects.

"file-like objects" is the bad doc experience I'm hoping we don't repeat.
The phrase "file-like object" is indeed used freely in the docs, but it's not
(AFAICT) *defined* anywhere, and doesn't even appear in the index.  Besides,
the notion that "file-like object" refers to section

    Buitin-in Types, Exceptions and Functions ->
     Other Built-in Types ->
      File Objects

was news to me.  I see the individual method descriptions there sometimes
refer to "file-like objects", and other times "objects implementing a
file-like interface".  The latter phrase appears uniquely in the description
of .readlines(), and may be the clearest explanation in the docs of wtf
"file-like object" means.  If so, it shouldn't be buried in the bowels of one
method description.

>   I think we need some re-organization of the built-in types section
> to separate abstract protocols from specific implementations,

Yes.

> but that's an orthagonal aspect and can be handled at the same
> time as the rest of the built-in types.

I assume you're thinking of creating a new "Iterator Objects" section under
"Other Built-in Types"?  That would work for me if it *started* with a
description of the iterator interface/protocol.

There's a twist, though:  iterators need to be defined already in the
Language Reference manual (we can't explain for-loops without them anymore).

>   Specific changes for places that accept iterators should be made as
> the code is changed, as usual.  Please describe the changes clearly in
> checkin messages so iterator related changes don't propogate to the
> maintenance branch.

We need an example to build on -- this is too abstract for me (which is
saying something <wink>).

For example, today we have:

    list(sequence)
        Return a list whose items are the same and in the same order as
        sequence's items. If sequence is already a list, a copy is made
        and returned, similar to sequence[:]. For instance, list('abc')
        returns returns ['a', 'b', 'c'] and list( (1, 2, 3) )
        returns [1, 2, 3].

list() doesn't yet work with iterators, but surely will.  What do we want the
docs to say after it changes?  Should it be implicit or explicit that
"sequence" now means "sequence or sequence-like object"?  Where is the
connection between "sequence-like object" and "iterable" explained?  Perhaps
what's really needed is s/sequence/iterable/ in this description.  But then
where is "iterable" defined?

Solve this once and the rest should follow easily.  But solving it the first
time doesn't look easy to me.  That's why I'm bugging you now.




From mal at lemburg.com  Mon Apr 30 12:19:53 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 12:19:53 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
Message-ID: <3AED3C49.ACDD40E@lemburg.com>

Rebooting the thread...

While testing mxNumber, I discovered what looks like a bug in
Win95: both Thomas Heller and I are seeing a problem with 
Python 2.1 when importing extension modules which rely on other 
DLLs as library.

Interestingly, the problem only shows up when starting Python
from the installation directory. Looking at the imports using
python -vv shows that in this situation, Python tries to import
modules, packages, extensions etc. using *relative* paths.

Now, under Win98 there is no problem, but Win95 doesn't seem
to like these relative imports when it comes to .pyd files
which reference DLLs in the same directory. It doesn't have
any problems when Python is started outside the installation
dir, since in that case Python uses absolute paths for importing
modules and extensions.

Would it be hard to tweak Python into always using absolute search
paths during module import ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From guido at digicool.com  Mon Apr 30 15:21:49 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 30 Apr 2001 08:21:49 -0500
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: Your message of "Mon, 30 Apr 2001 12:19:53 +0200."
             <3AED3C49.ACDD40E@lemburg.com> 
References: <3AED3C49.ACDD40E@lemburg.com> 
Message-ID: <200104301321.IAA07476@cj20424-a.reston1.va.home.com>

> Would it be hard to tweak Python into always using absolute search
> paths during module import ?

I resist doing this *in general* because absolute paths don't always
mean the right thing on all platforms (and aren't always obtainable),
but I agree that for Windows this can and should be done.

The easiest way I can think of is for PC/getpathp.py to tweak the path
entries to be absolute pathnames.  A single getcwd() call should
suffice.

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



From MarkH at ActiveState.com  Mon Apr 30 14:23:23 2001
From: MarkH at ActiveState.com (Mark Hammond)
Date: Mon, 30 Apr 2001 22:23:23 +1000
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: <3AED3C49.ACDD40E@lemburg.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPIEBNDLAA.MarkH@ActiveState.com>

> Interestingly, the problem only shows up when starting Python
> from the installation directory. Looking at the imports using
> python -vv shows that in this situation, Python tries to import
> modules, packages, extensions etc. using *relative* paths.

I'm not quite with you here.  Are you saying both Win98 and 95 use relative
paths, but only Win95 has the problem, or that only Win95 sees relative
paths?

My Win98 box uses absolute paths for all imports when using -vv

> Would it be hard to tweak Python into always using absolute search
> paths during module import ?

Where are the relative paths coming from?  If we can determine that, we can
determine how hard it would be to fix ;-)

Mark.




From mal at lemburg.com  Mon Apr 30 14:53:21 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 14:53:21 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
References: <LCEPIIGDJPKCOIHOBJEPIEBNDLAA.MarkH@ActiveState.com>
Message-ID: <3AED6041.A3E3AE7B@lemburg.com>

Mark Hammond wrote:
> 
> > Interestingly, the problem only shows up when starting Python
> > from the installation directory. Looking at the imports using
> > python -vv shows that in this situation, Python tries to import
> > modules, packages, extensions etc. using *relative* paths.
> 
> I'm not quite with you here.  Are you saying both Win98 and 95 use relative
> paths, but only Win95 has the problem, or that only Win95 sees relative
> paths?

Both are using relative paths, but only Win95 has a problem with not
finding the DLL needed by a PYD file in a subpackage:

abc/
    __init__.py
    mxABC.pyd
    mamba.dll

mxABC.pyd needs mamba.dll.
 
> My Win98 box uses absolute paths for all imports when using -vv

Are you sure ? Please CD to the C:\Python21 dir and then try
to import and installed package (say mx.Tools from egenix-mx-base).
You should be seeing relative paths with -vv.
 
> > Would it be hard to tweak Python into always using absolute search
> > paths during module import ?
> 
> Where are the relative paths coming from?  If we can determine that, we can
> determine how hard it would be to fix ;-)

The relative paths come from the import logic: the current dir
is scanned first and if the package is found in that directory,
all subsequent lookups are done using relative paths.

While this is prefectly OK, Win95 seems to have a problem with
importing extensions using these relative paths. I think we could
solve the problem by making the pathname which is passed to
LoadLibraryEx() in dynload_win.c absolute.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From mal at lemburg.com  Mon Apr 30 14:54:54 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 14:54:54 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
References: <3AED3C49.ACDD40E@lemburg.com> <200104301321.IAA07476@cj20424-a.reston1.va.home.com>
Message-ID: <3AED609E.A7D9B454@lemburg.com>

Guido van Rossum wrote:
> 
> > Would it be hard to tweak Python into always using absolute search
> > paths during module import ?
> 
> I resist doing this *in general* because absolute paths don't always
> mean the right thing on all platforms (and aren't always obtainable),
> but I agree that for Windows this can and should be done.

I have only run into the problem with Win95, so yes, doing this
for Windows only should be OK (and even there it's probably only
needed for importing PYD files).
 
> The easiest way I can think of is for PC/getpathp.py to tweak the path
> entries to be absolute pathnames.  A single getcwd() call should
> suffice.

I'd rather keep the changes in dynload_win.c if that's possible.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From guido at digicool.com  Mon Apr 30 15:57:56 2001
From: guido at digicool.com (Guido van Rossum)
Date: Mon, 30 Apr 2001 08:57:56 -0500
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: Your message of "Mon, 30 Apr 2001 14:54:54 +0200."
             <3AED609E.A7D9B454@lemburg.com> 
References: <3AED3C49.ACDD40E@lemburg.com> <200104301321.IAA07476@cj20424-a.reston1.va.home.com>  
            <3AED609E.A7D9B454@lemburg.com> 
Message-ID: <200104301357.IAA07564@cj20424-a.reston1.va.home.com>

> I'd rather keep the changes in dynload_win.c if that's possible.

Fine with me.

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



From MarkH at ActiveState.com  Mon Apr 30 15:01:33 2001
From: MarkH at ActiveState.com (Mark Hammond)
Date: Mon, 30 Apr 2001 23:01:33 +1000
Subject: [Python-Dev] Importing extensions on Windows 95
In-Reply-To: <3AED6041.A3E3AE7B@lemburg.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPIEBODLAA.MarkH@ActiveState.com>

> abc/
>     __init__.py
>     mxABC.pyd
>     mamba.dll
>
> mxABC.pyd needs mamba.dll.
>
> > My Win98 box uses absolute paths for all imports when using -vv
>
> Are you sure ? Please CD to the C:\Python21 dir and then try

Right - I am with you now...

> importing extensions using these relative paths. I think we could
> solve the problem by making the pathname which is passed to
> LoadLibraryEx() in dynload_win.c absolute.

Just calling GetFullPathName() before the LoadLibEx() would seem a
reasonable and appropriate patch.  Keeps it a long way from the "*in
general*" Guido was concerned about, and sounds low-risk to me!

Ahh - Guido just OK'd it, so go for it ;-)

Mark.




From mal at lemburg.com  Mon Apr 30 16:10:16 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Apr 2001 16:10:16 +0200
Subject: [Python-Dev] Importing extensions on Windows 95
References: <LCEPIIGDJPKCOIHOBJEPIEBODLAA.MarkH@ActiveState.com>
Message-ID: <3AED7248.B7386B83@lemburg.com>

Mark Hammond wrote:
> 
> > abc/
> >     __init__.py
> >     mxABC.pyd
> >     mamba.dll
> >
> > mxABC.pyd needs mamba.dll.
> >
> > > My Win98 box uses absolute paths for all imports when using -vv
> >
> > Are you sure ? Please CD to the C:\Python21 dir and then try
> 
> Right - I am with you now...
> 
> > importing extensions using these relative paths. I think we could
> > solve the problem by making the pathname which is passed to
> > LoadLibraryEx() in dynload_win.c absolute.
> 
> Just calling GetFullPathName() before the LoadLibEx() would seem a
> reasonable and appropriate patch.  Keeps it a long way from the "*in
> general*" Guido was concerned about, and sounds low-risk to me!
> 
> Ahh - Guido just OK'd it, so go for it ;-)

Here's a stab at a patch. Could you review it and test it ? I
don't have enough knowledge of win32 for this...

dynload_win.c:
...
#ifdef MS_WIN32
	{
		HINSTANCE hDLL;
		char pathbuf[260];
		LPTSTR *dummy;
		
		if (strchr(pathname, '\\') == NULL &&
		    strchr(pathname, '/') == NULL)
		{
			/* Prefix bare filename with ".\" */
			char *p = pathbuf;
			*p = '\0';
			_getcwd(pathbuf, sizeof pathbuf);
			if (*p != '\0' && p[1] == ':')
				p += 2;
			sprintf(p, ".\\%-.255s", pathname);
			pathname = pathbuf;
		}
		/* Convert to full pathname; we ignore errors to maintain
		   b/w compatibility here. */
		if (GetFullPathName(pathname,
				    sizeof(pathbuf),
				    pathbuf,
				    &dummy))
		    pathname = pathbuf;
		/* Look for dependent DLLs in directory of pathname first */
		/* XXX This call doesn't exist in Windows CE */
		if (pathname)
		    hDLL = LoadLibraryEx(pathname, NULL,
					 LOAD_WITH_ALTERED_SEARCH_PATH);
		if (hDLL == NULL) {
			char errBuf[256];
			unsigned int errorCode;
...

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/



From michel at digicool.com  Mon Apr 30 20:39:38 2001
From: michel at digicool.com (Michel Pelletier)
Date: Mon, 30 Apr 2001 11:39:38 -0700 (PDT)
Subject: [Python-Dev] RE: Iterators, map, xreadlines and docs
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEEAJPAA.tim.one@home.com>
Message-ID: <Pine.LNX.4.21.0104301049590.7346-100000@localhost.localdomain>

On Sat, 28 Apr 2001, Tim Peters wrote:

> What do those have in common?  Objects and types are the wrong way to
> approach this one:  it's really of no interest that, e.g., iter(list) and
> iter(dict) return objects of different types; what *is* interesting is that
> iter(whatever) returns *an* object that conforms to the iterator protocol (or
> "implements the iterator interface" -- all the same to me).  

I have added a notional iter interface to the PEP 245 prototype and will
be making another release of it later tonight.

> "file-like objects" is the bad doc experience I'm hoping we don't repeat.
> The phrase "file-like object" is indeed used freely in the docs, but it's not
> (AFAICT) *defined* anywhere, and doesn't even appear in the index.  Besides,
> the notion that "file-like object" refers to section
> 
>     Buitin-in Types, Exceptions and Functions ->
>      Other Built-in Types ->
>       File Objects
> 
> was news to me.  I see the individual method descriptions there sometimes
> refer to "file-like objects", and other times "objects implementing a
> file-like interface".  The latter phrase appears uniquely in the description
> of .readlines(), and may be the clearest explanation in the docs of wtf
> "file-like object" means.  If so, it shouldn't be buried in the bowels of one
> method description.

245 takes a couple stabs at File interfaces, trying to satisfy the
bare-bones kind of file, a Python File, StringI, StringO etc...

> >   I think we need some re-organization of the built-in types section
> > to separate abstract protocols from specific implementations,
> 
> Yes.

FYI, 245 defines the following interfaces.  Some of them may be wrong,
I took most of this straight from the Pydocs and stuff done by Jim:

  Mutable
  
  Comparable

  Orderable(Comparable)

  Hashable
  
  Hashkey(Comparable, Hashable)

  Membership

  Mapping

  Sized

  MutableMapping(Mutable)    

  Sequence(Mapping)

  Sequential(Sequential)

  Type

  Null

  String(Sequence, Sized)

  Tuple(Sequence, Sized)

  List(Mapping, MutableMapping, Sequence, Sized)

  Dictionary(Mapping, MutableMapping, Sized)

  File - and the various specific file functionality

  Module

  Class

  Function

  InstanceMethod

  Exception

  Number - Real, Compex, Exact, others....

Here are some examples from the current prototype.  The primary
utility function from PEP 245 is 'does':

    Python 2.1 (#1, Apr 22 2001, 06:33:07) 
    [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
    Type "copyright", "credits" or "license" for more information.
    >>> from Interface import does

'does' can be used two ways.  The first way is to pass imp an object
and it will return the interfaces that the object implements:

    >>> does({})
    [<Interface Dictionary at 82e288c>]
    >>> does([])
    [<Interface List at 82c71f4>]
    >>> does(sys.stdin)
    [<Interface PyFile at 8261e54>]
    >>> def f(): pass
    ...
    >>> does(f)
    [<Interface Function at 82ff134>]

Here, we see that a dictionary and a list do the 'Dictionary' and
'List' interfaces respectively, and that files and functions also
implement interfaces.  'does' can also be used with another argument,
to ask whether the object implements a certain interface:

    >>> from Interface.Protocols import Mapping, Sequence, Mutable
    >>> from Interface.File import File
    >>> does({}, Mapping)
    1
    >>> does([], Sequence)
    1
    >>> does((), Mutable)
    0
    >>> does({}, Dictionary)
    1
    >>> does(sys.stdin, File)
    1

Note that PEP 245 requires NO changes to Python.  You can download it
now and try this stuff out.

-Michel






From michel at digicool.com  Mon Apr 30 21:48:25 2001
From: michel at digicool.com (Michel Pelletier)
Date: Mon, 30 Apr 2001 12:48:25 -0700 (PDT)
Subject: [Python-Dev] RE: Iterators, map, xreadlines and docs
In-Reply-To: <Pine.LNX.4.21.0104301049590.7346-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0104301247450.7346-100000@localhost.localdomain>

On Mon, 30 Apr 2001, Michel Pelletier wrote:

> On Sat, 28 Apr 2001, Tim Peters wrote:
> 
> I have added a notional iter interface to the PEP 245 prototype and will
> be making another release of it later tonight.

I forgot to mention that you can get the previous release (without
iter) here:

http://www.zope.org/Members/michel/InterfacesPEP/Interface.tgz

-Michel