From fdrake@acm.org  Thu Jun  1 02:30:28 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Wed, 31 May 2000 21:30:28 -0400 (EDT)
Subject: [Python-Dev] Adding LDAP to the Python core... ?!
In-Reply-To: <Pine.LNX.4.10.10005311522480.30220-100000@nebula.lyra.org>
References: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com>
 <Pine.LNX.4.10.10005311522480.30220-100000@nebula.lyra.org>
Message-ID: <14645.48308.347086.279280@cj42289-a.reston1.va.home.com>

Greg Stein writes:
 > davlib.py is pure Python, building upon my upgraded httplib.py and
 > xml.utils.qp_xml (and pyexpat)

  So the dependencies are definately an issue.

 > [ and recall my email last week that I've updated httplib.py and posted it
 >   to my web pages; it is awaiting review for integration into the Python
 >   core; it still needs docs and more testing scenarios, tho
 > 
 >   http://www.python.org/pipermail/python-dev/2000-May/005643.html
 > ]

  Jeremy, were you looking at this?

 > davlib will probably be a 1.7 item. It still needs some heavy work to
 > easily deal with authentication (which is usually going to be required for

  Sounds good to me; let's take a look at it in 3 or 4 months.  I'd
hope to have at least preliminary reference documentation for review.


  -Fred

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



From skip@mojam.com (Skip Montanaro)  Thu Jun  1 14:48:41 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 1 Jun 2000 08:48:41 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34
In-Reply-To: <200006010312.UAA10844@slayer.i.sourceforge.net>
References: <200006010312.UAA10844@slayer.i.sourceforge.net>
Message-ID: <14646.27065.279988.93102@beluga.mojam.com>

    Fred> Log Message:
    Fred> Michael Hudson <mwh21@cam.ac.uk>:
    Fred> Removed PyErr_BadArgument() calls and replaced them with more
    Fred> useful error messages.

    ...
    Fred> --- 389,395 ----
    Fred>   	PyListObject *np;
    Fred>   	if (!PyList_Check(bb)) {
    Fred> ! 		PyErr_Format(PyExc_TypeError,
    Fred> ! 			     "can only append list (not \"%.200s\") to list",
    Fred> ! 			     bb->ob_type->tp_name);
    Fred>   		return NULL;
    Fred>   	}
    Fred> ***************
    ...

I've seen this new error message cross my mailbox a few times.  On the face
of it, it's incorrect, because you can append any sort of object to a list,
right?  This message appears in the list_concat method.  Shouldn't it be
something like

    can't concatenate \"%.200s\" object with list

?  I would consider this change very picky except for the fact that it's
making a statement about the properties of lists that is clearly not true.

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
"We have become ... the stewards of life's continuity on earth.  We did not
ask for this role...  We may not be suited to it, but here we are."
- Stephen Jay Gould


From fdrake@acm.org  Thu Jun  1 15:29:17 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 1 Jun 2000 10:29:17 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34
In-Reply-To: <14646.27065.279988.93102@beluga.mojam.com>
References: <200006010312.UAA10844@slayer.i.sourceforge.net>
 <14646.27065.279988.93102@beluga.mojam.com>
Message-ID: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com>

Skip Montanaro writes:
 > I've seen this new error message cross my mailbox a few times.  On the face
 > of it, it's incorrect, because you can append any sort of object to a list,
 > right?  This message appears in the list_concat method.  Shouldn't it be
 > something like
 > 
 >     can't concatenate \"%.200s\" object with list

Skip,
  You're right!  How about:

       can only concatenate list (not \"%.200s\") to list

  If you don't object by the time this mail reaches you, I'll check it
in.  ;)


  -Fred

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



From mwh21@cam.ac.uk  Thu Jun  1 16:39:59 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: Thu, 1 Jun 2000 16:39:59 +0100 (BST)
Subject: [Python-Dev] CVS: python/dist/src/Objects listobject.c,2.69,2.70 and friends
In-Reply-To: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10006011637320.13221-100000@localhost.localdomain>

On Thu, 1 Jun 2000, Fred L. Drake, Jr. wrote:

> 
> Skip Montanaro writes:
>  > I've seen this new error message cross my mailbox a few times.  On the face
>  > of it, it's incorrect, because you can append any sort of object to a list,
>  > right?  This message appears in the list_concat method.  Shouldn't it be
>  > something like
>  > 
>  >     can't concatenate \"%.200s\" object with list
> 
> Skip,
>   You're right!  How about:
> 
>        can only concatenate list (not \"%.200s\") to list
> 
>   If you don't object by the time this mail reaches you, I'll check it
> in.  ;)

Then you'd better do something about tupleobject.c as well; I'd also say

       can only concatenate list (not \"%.200s\") and list
       can only concatenate tuple (not \"%.200s\") and tuple

are slightly preferable, on reflection (note the s/to/and/).

Cheers,
Michael



From andy@reportlab.com  Thu Jun  1 17:23:36 2000
From: andy@reportlab.com (Andy Robinson)
Date: Thu, 1 Jun 2000 17:23:36 +0100
Subject: [Python-Dev] SIG: python-lang
Message-ID: <PGECLPOBGNBNKHNAGIJHIEDNCCAA.andy@reportlab.com>

It seems to me that the main problem is that
comp.lang.python is too big to follow.  So why 
not split it?  I don't know the right subgroups,
but if (say) comp.lang.python.language focusses 
on the core language, it might enable people to 
start reading it again.  

I asked this twice on c.l.p, one year ago and 
two years ago, and the answer was always "the 
traffic is too low".  I used to subscribe to
the NeXTSteap groups, and splitting worked
really well there.

- Andy Robinson


From mal@lemburg.com  Thu Jun  1 14:10:42 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 01 Jun 2000 15:10:42 +0200
Subject: [Python-Dev] Adding LDAP to the Python core... ?!
References: <Pine.LNX.4.10.10005311452150.30220-100000@nebula.lyra.org>
Message-ID: <393660D2.4926E5C1@lemburg.com>

Greg Stein wrote:
> 
> On Wed, 31 May 2000, Barry A. Warsaw wrote:
> > >>>>> "M" == M  <mal@lemburg.com> writes:
> >
> >     M> Would there be interest in adding the python-ldap module
> >     M> (http://sourceforge.net/project/?group_id=2072) to the
> >     M> core distribution ?
> >
> > I haven't looked at this stuff, but yes, I think a standard LDAP
> > module would be quite useful.  It's a well enough established
> > protocol, and it would be good to be able to count on it "being
> > there".
> 
> My WebDAV module implements an established protocol (an RFC tends to do
> that :-), but the API within the module is still in flux (IMO).
> 
> Is the LDAP module's API pretty solid? Is it changing?

It is closing in on version 2.0 -- not sure how much it
still changes. I just thought I'd query here before asking
Daniel about his thoughts on including the module in the
core (wouldn't make much sense if there was no interest).
 
> And is this module a C extension, or a pure Python implementation?

It's a Python module which uses a C wrapper to interface
to OpenLDAP, which is a portable C lib dealing with
all aspects of LDAP.

There are at least two other projects built on top of
python-ldap (see Parnassus for infos).

I just thought I'd mention it here, because  LDAP is certainly
a widely used protocol in the corporate world and many 
decision makers have this on their list of buzz words.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gward@mems-exchange.org  Thu Jun  1 22:01:41 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Thu, 1 Jun 2000 17:01:41 -0400
Subject: [Python-Dev] What's that sound?
In-Reply-To: <393547A2.30CB7113@prescod.net>; from paul@prescod.net on Wed, May 31, 2000 at 12:10:58PM -0500
References: <39353CCD.1F3E9A0B@prescod.net> <14645.17611.318538.986772@anthem.python.org> <393547A2.30CB7113@prescod.net>
Message-ID: <20000601170140.A24794@mems-exchange.org>

On 31 May 2000, Paul Prescod said:
> Look closer, big-egoed-four-stringed-guitar-playing-one. It could just
> as easily be a J.
> 
> And you know what you get when you put P and J together?

Pajamas!

Yes, that's right, when Python takes over the world, we'll all have to
sleep BUCK NAKED!!!

(What was that about "zero noise" on python-dev?  Oh well, we must have
our fun...)

        Greg


From esr@snark.thyrsus.com  Thu Jun  1 23:36:29 2000
From: esr@snark.thyrsus.com (Eric S. Raymond)
Date: Thu, 1 Jun 2000 18:36:29 -0400
Subject: [Python-Dev] ascii.py?
Message-ID: <200006012236.SAA03578@snark.thyrsus.com>

There has been a vast and echoing silence about the ascii.py module I
posted here at Fred Drake's request.  Is it really such a  bad idea?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"Those who make peaceful revolution impossible 
will make violent revolution inevitable."
	-- John F. Kennedy


From Ka-Ping Yee <pingster@ilm.com>  Thu Jun  1 23:33:19 2000
From: Ka-Ping Yee <pingster@ilm.com> (Ka-Ping Yee)
Date: Thu, 1 Jun 2000 15:33:19 -0700 (PDT)
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <Pine.SGI.3.96.1000601153039.30600P-100000@happy>

On Thu, 1 Jun 2000, Eric S. Raymond wrote:
> There has been a vast and echoing silence about the ascii.py module I
> posted here at Fred Drake's request.  Is it really such a  bad idea?

Don't look at me.  I'm busy working on inspect and htmldoc. :)

Actually, i guess i probably didn't respond because it isn't
of immediate use to me.  Maybe this is the sort of thing that
might come in handy one day but that hordes of people aren't
desperate for.

Hmm.  Perhaps it's because people are used to saying "in string.digits"
instead of wanting isdigit() &c.

Hmm.  Perhaps it's also something that ought to be eventually
handled via the Unicode character property route.

Dunno.


-- ?!ng

"China is a big country, inhabited by many Chinese."
    -- Former French President Charles de Gaulle




From gstein@lyra.org  Thu Jun  1 23:34:13 2000
From: gstein@lyra.org (Greg Stein)
Date: Thu, 1 Jun 2000 15:34:13 -0700 (PDT)
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <Pine.LNX.4.10.10006011531500.6088-100000@nebula.lyra.org>

On Thu, 1 Jun 2000, Eric S. Raymond wrote:
> There has been a vast and echoing silence about the ascii.py module I
> posted here at Fred Drake's request.  Is it really such a  bad idea?

hehe...

I'd say silence implies a +0 from people ("seems reasonable to go in, but
I wouldn't be upset if it doesn't").

If people thought it was bad, then you'd hear about it :-)

I took a quick look at it. Doesn't seem too bad, but I can't think of
anything that I've done in a long while that would require it. So I can't
really say "wow! put that baby in the distro!"

YMMV, of course :-)

Cheers,
-g

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



From esr@thyrsus.com  Thu Jun  1 23:51:45 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 1 Jun 2000 18:51:45 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <Pine.LNX.4.10.10006011531500.6088-100000@nebula.lyra.org>; from gstein@lyra.org on Thu, Jun 01, 2000 at 03:34:13PM -0700
References: <200006012236.SAA03578@snark.thyrsus.com> <Pine.LNX.4.10.10006011531500.6088-100000@nebula.lyra.org>
Message-ID: <20000601185145.A3667@thyrsus.com>

Greg Stein <gstein@lyra.org>:
> I took a quick look at it. Doesn't seem too bad, but I can't think of
> anything that I've done in a long while that would require it. So I can't
> really say "wow! put that baby in the distro!"

It starts to get pretty useful in conjunction with curses -- for example, in
writing interpreters for character-at-a-time command loops.

I have a new version that adds the following:

\begin{funcdesc}{ascii}{c}
Return the ASCII value corresponding to the low 7 bits of c.
\end{funcdesc}

The following function takes either a single-character string or
integer byte value; it returns a string.

\begin{funcdesc}{unctrl}{c}
Return a string representation of the ASCII character c.  If c is
printable, this string is the character itself.  If the character
is a control character (0x00-0x1f) the string consists of a caret
(^) followed by the corresponding uppercase letter.  If the character
is an ASCII delete (0x7f) the string is "^?".  If the character has
its meta bit (0x80) set, the meta bit is stripped, the preceding rules
applied, and "!" prepended to the result.
\end{funcdesc}

Finally, the module supplies a 33-element string array 
called controlnames that contains the ASCII mnemonics for the
thirty-two ASCII control characters from 0 (NUL) to 0x1f (US),
in order, plus the mnemonic "SP" for space.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Certainly one of the chief guarantees of freedom under any government,
no matter how popular and respected, is the right of the citizens to
keep and bear arms.  [...] the right of the citizens to bear arms is
just one guarantee against arbitrary government and one more safeguard
against a tyranny which now appears remote in America, but which
historically has proved to be always possible.
        -- Hubert H. Humphrey, 1960


From akuchlin@mems-exchange.org  Fri Jun  2 00:32:32 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 1 Jun 2000 19:32:32 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>; from esr@snark.thyrsus.com on Thu, Jun 01, 2000 at 06:36:29PM -0400
References: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <20000601193232.A12831@newcnri.cnri.reston.va.us>

On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
>There has been a vast and echoing silence about the ascii.py module I
>posted here at Fred Drake's request.  Is it really such a  bad idea?

One misgiving I had was locales; is it a bug or a feature that locales
aren't supported, as they are for the C isdigit(), isalpha(), &c,
functions?  I'm not entirely sure which it is.  (The locale module
doesn't expose the C is*() functions, though I think they're used in
constructing string.letters.)

--amk


From esr@thyrsus.com  Fri Jun  2 00:45:11 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 1 Jun 2000 19:45:11 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <20000601193232.A12831@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Thu, Jun 01, 2000 at 07:32:32PM -0400
References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us>
Message-ID: <20000601194511.A3948@thyrsus.com>

Andrew Kuchling <akuchlin@cnri.reston.va.us>:
> On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
> >There has been a vast and echoing silence about the ascii.py module I
> >posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> One misgiving I had was locales; is it a bug or a feature that locales
> aren't supported, as they are for the C isdigit(), isalpha(), &c,
> functions?  I'm not entirely sure which it is.  (The locale module
> doesn't expose the C is*() functions, though I think they're used in
> constructing string.letters.)

It's a feature.  That's why this module is called ascii, not string :-)
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

  "...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
        -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),


From paul@prescod.net  Fri Jun  2 04:53:41 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 01 Jun 2000 22:53:41 -0500
Subject: [Python-Dev] ascii.py?
References: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <39372FC5.DE1CE8EA@prescod.net>

"Eric S. Raymond" wrote:
> 
> There has been a vast and echoing silence about the ascii.py module I
> posted here at Fred Drake's request.  Is it really such a  bad idea?

Without looking closely, or even being particularly knowledgable (how's
that for a disclaimer!) my instinctive reaction was: "does the ASCII
subset of Unicode need its own module just before we add Unicode to the
language?"

It may be that there are some semantics of ASCII that are not captured
in the Unicode spec. and thus are not generalizable. I'm pretty
confident that these ones ARE generalizable:

isalnum
isalpha
isascii
islower
isupper
isspace
isxdigit

How do Unicode users get this information from the famous Unicode
database and why not merge the Unicode and ASCII versions in 1.6?

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/~perlis-alan/quotes.html


From esr@thyrsus.com  Fri Jun  2 06:43:54 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Fri, 2 Jun 2000 01:43:54 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <39372FC5.DE1CE8EA@prescod.net>; from paul@prescod.net on Thu, Jun 01, 2000 at 10:53:41PM -0500
References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net>
Message-ID: <20000602014353.A5211@thyrsus.com>

Paul Prescod <paul@prescod.net>:
> "Eric S. Raymond" wrote:
> > 
> > There has been a vast and echoing silence about the ascii.py module I
> > posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> Without looking closely, or even being particularly knowledgable (how's
> that for a disclaimer!) my instinctive reaction was: "does the ASCII
> subset of Unicode need its own module just before we add Unicode to the
> language?"
> 
> It may be that there are some semantics of ASCII that are not captured
> in the Unicode spec. and thus are not generalizable.

ascii.ctrl is one such.

>                                                       I'm pretty
> confident that these ones ARE generalizable:
> 
> isalnum
> isalpha
> isascii
> islower
> isupper
> isspace
> isxdigit
> 
> How do Unicode users get this information from the famous Unicode
> database and why not merge the Unicode and ASCII versions in 1.6?

Answer: ascii.py is not designed for text processing.  I wrote it to package
some functions useful for classifying *ASCII* data, especially in the
context of roguelike programs that interpret keystrokes coming in through
a curses interface.

(Where this all touches ground is CML2, my replacement configuration 
system for the Linux kernel.)
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

..every Man has a Property in his own Person. This no Body has any
Right to but himself.  The Labour of his Body, and the Work of his
Hands, we may say, are properly his. .... The great and chief end
therefore, of Mens uniting into Commonwealths, and putting themselves
under Government, is the Preservation of their Property.
	-- John Locke, "A Treatise Concerning Civil Government"


From gstein@lyra.org  Fri Jun  2 09:43:13 2000
From: gstein@lyra.org (Greg Stein)
Date: Fri, 2 Jun 2000 01:43:13 -0700 (PDT)
Subject: [Python-Dev] httplib (was: Adding LDAP to the Python core... ?!)
In-Reply-To: <14645.51445.963154.817309@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.10006020134050.17073-100000@nebula.lyra.org>

It looks like a definite bug. I have *no* idea, tho, why it is doing
that... I did quite a bit of testing with chunked replies. Admittedly,
though, I didn't stack up requests like you've done in your test. I'm
wrapping up mod_dav at the moment, so I don't really have time to look
deeply into this. Mebbe next week?

Regarding the pipeline request thing. I think it would probably be best to
just drop the whole "hold the previous response and wait for it to be
closed" thing. I don't know why that is in there; probably a leftover
(converted) semantic from the old-style HTTP() class. I'd be quite fine
just axing it and allowing the client to shove ten requests down the pipe
before pulling the first response back out.

Oh. Wait. Maybe that was it. You can't read the "next" response until the
first one has been read. Well... no need to block putting new responses;
we just need to create a way to "get the next reply" and/or "can I get the
next reply yet?"

Cheers,
-g

p.s. Moshe also had a short list of review items. I read thru them, but
not with the code in hand to understand some of his specifics.


On Wed, 31 May 2000, Jeremy Hylton wrote:
> >>>>> "GS" == Greg Stein <gstein@lyra.org> writes:
> 
>   GS> [ and recall my email last week that I've updated httplib.py and
>   GS> posted it to my web pages; it is awaiting review for integration
>   GS> into the Python core; it still needs docs and more testing
>   GS> scenarios, tho
> 
> I've been looking at the httplib code, and I found what may be a bug.
> Not sure, because I'm not sure how the API works for pipelined
> requests. 
> 
> I've got some test code that looks a bit like this:
> 
> def test_new_interface_series(urls):
>     paths = []
>     the_host = None
>     for url in urls:
>         host, path = get_host_and_path(url)
>         if the_host is None:
>             the_host = host
>         else:
>             assert host == the_host
>         paths.append(path)
>         
>     conn = httplib.HTTPConnection(the_host)
>     for path in paths:
>         conn.request('GET', path, headers={'User-Agent': 'httplib/Python'})
>     for path in paths:
>         errcode, errmsg, resp = conn.getreply()
>         buf = resp.read()
>         if errcode == 200:
>             print errcode, resp.headers
>         else:
>             print errcode, `errmsg`, resp
>         print resp.getheader('Content-Length'), len(buf)
>         print repr(buf[:40])
>         print repr(buf[-40:])
>         print
>     conn.close()
> 
> test_new_interface_series(['http://www.python.org/',
>                         'http://www.python.org/pics/PyBanner054.gif',
>                         'http://www.python.org/pics/PythonHi.gif',
>                         'http://www.python.org/Jobs.html',
>                         'http://www.python.org/doc/',
>                         'http://www.python.org/doc/current/',
>                            ])
> 
> The second loop that reads the replies gets fouled up after a couple
> of responses.  I added even more debugging and found that the first
> line of the corrupted response is
> 
> > 'ontent-Type: text/html\015\012'
> 
> It looks like some part of the program is consuming too much input.  I
> haven't been able to figure out what part yet.  Hoping that you might
> have some good ideas.
> 
> Thinking about this issue, I came up with a potential API problem.
> You must read the body after calling getreply and before calling
> getreply a second time.  This kind of implicit requirement is a bit
> tricky.  It would help if the implementation could raise an error if
> this happens.  It might be even better if it just worked, although it
> seems a bit too magical.
> 
> Jeremy
> 

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





From mal@lemburg.com  Fri Jun  2 09:11:05 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 10:11:05 +0200
Subject: [Python-Dev] Re: [Patches] Translating doc strings
References: <200006020701.JAA28620@pandora>
Message-ID: <39376C19.53A01A27@lemburg.com>

Martin von Loewis wrote:
> 
> To simplify usage of Python for people who don't speak English well,
> I'd like to start a project translating the doc strings in the Python
> library. This has two aspects:
> 
> 1. there must be a simple way to access the translated doc strings

Do you plan to use GNU gettext here ? (This would cause the
translated version of Python to fall under GPL, AFAIK)

I'd propose to use the existing doc-strings as keys to 
a translation mapping. This assures that existing doc-strings
remain intact and that the actual translation process is
done at query time, e.g. by using a help() built-in function.

> 2. there must be actual translations to the various native languages
>    of Python users.
> 
> Since the second task is much more complicated, I submit a snapshot of
> this project, namely, a message catalog of the doc strings in the
> Python libraries, taken from the CVS; along with a snapshot of the
> German translations. I intend to complete the German translations in
> the coming weeks, but I want to give other translators a chance to
> also start working on that.
> 
> Please note that extracting the docstrings was not straight-forward;
> I've used François Pinard's most excellent po-utils 0.5 as a starting
> point, and enhanced it with the capability to recognize __doc__[] in C
> code, so that I would also get (most of) the doc strings in C modules.
> I plan to update this catalog a few times before Python 1.6 is
> released, so that translators can update their translations.
> 
> A key point is finding translators. I propose to use the
> infrastructure of the GNU translation project for that: There are
> established teams for all major languages, and an infrastructure (also
> maintained by François) where notifications about new catalogs are
> automatically distributed to the teams. That should not stop
> volunteers which don't currently participate in the GNU translation
> project from translating - however, they should announce that they
> plan to work on translating these messages to avoid duplication of
> work.

This will only work iff the translations can be submitted
via the usual "post to patches with dislcaimer" method...
aren't the GNU people interested in putting the translations
under the GPL ?

> Another matter is where the catalogs should live in the Python source
> tree. I propose to have a Misc/po directory, which will contain both
> the PO catalogues, as well as the binary .mo objects; only the latter
> will be installed during the installation process.
> 
> Please let me know what you think, in particular, whether I can submit
> the catalog to the translation teams.
> 
> Regards,
> Martin
> 
>   ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>               Name: doc.tgz
>    doc.tgz    Type: unspecified type (application/octet-stream)
>           Encoding: base64

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From mal@lemburg.com  Fri Jun  2 08:55:04 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 09:55:04 +0200
Subject: [Python-Dev] ascii.py?
References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us>
Message-ID: <39376858.55D4F778@lemburg.com>

Andrew Kuchling wrote:
> 
> On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
> >There has been a vast and echoing silence about the ascii.py module I
> >posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> One misgiving I had was locales; is it a bug or a feature that locales
> aren't supported, as they are for the C isdigit(), isalpha(), &c,
> functions?  I'm not entirely sure which it is.  (The locale module
> doesn't expose the C is*() functions, though I think they're used in
> constructing string.letters.)

FYI, both strings and Unicode object already have a few
.isXXX() methods:

	isdigit(), islower(), isspace(), istitle(), isupper()

For strings these use the C APIs (which are locale aware),
for Unicode the built in mappings are used.

BTW, I haven't looked at the docs lately, but are the string
and Unicode methods already documented ? All of them
have doc-strings, so it should be easy extracting the data
to build a TeX-file.

On the topic of adding ascii.py, I'm +0 -- I don't currently
have a need for it, but writing .append(ascii.CR + ascii.LF)
does add to the readability of scripts.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From mal@lemburg.com  Fri Jun  2 09:02:35 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 10:02:35 +0200
Subject: [I18n-sig] Re: [Python-Dev] ascii.py?
References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net>
Message-ID: <39376A1B.10E45C7B@lemburg.com>

Paul Prescod wrote:
> 
> "Eric S. Raymond" wrote:
> >
> > There has been a vast and echoing silence about the ascii.py module I
> > posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> Without looking closely, or even being particularly knowledgable (how's
> that for a disclaimer!) my instinctive reaction was: "does the ASCII
> subset of Unicode need its own module just before we add Unicode to the
> language?"
> 
> It may be that there are some semantics of ASCII that are not captured
> in the Unicode spec. and thus are not generalizable. I'm pretty
> confident that these ones ARE generalizable:
> 
> isalnum
> isalpha
> isascii
> islower
> isupper
> isspace
> isxdigit
> 
> How do Unicode users get this information from the famous Unicode
> database and why not merge the Unicode and ASCII versions in 1.6?

Note that many of the above are already implemented as
string|Unicode methods.

The Unicode database is accessible via the unicodedata
module. The specs for the used APIs and constants can
be found in the Unicode database description file
on www.unicode.org.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From loewis@informatik.hu-berlin.de  Fri Jun  2 13:33:07 2000
From: loewis@informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 14:33:07 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <39376C19.53A01A27@lemburg.com> (mal@lemburg.com)
References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com>
Message-ID: <200006021233.OAA16962@pandora>

> Do you plan to use GNU gettext here ? (This would cause the
> translated version of Python to fall under GPL, AFAIK)

No, I plan to use the Python gettext module, which is currently being
integrated into Python. It will either use the system's gettext
library, or read mo files using pure Python.

> I'd propose to use the existing doc-strings as keys to=20
> a translation mapping. This assures that existing doc-strings
> remain intact and that the actual translation process is
> done at query time, e.g. by using a help() built-in function.

This is more or less what I've planned. I'd propose to call the
function doc, with an interface like

>>> doc(time.time)
time() -> Gleitkommazahl

Gib die aktuelle Zeit in Sekunden seit Beginn der Epoche zur=FCck.
Sekundenbruchteile sind vorhanden, falls die Systemuhr sie bereitstellt.

It won't use a dictionary, though, but the underlying gettext query
mechanism. Exact naming and parameters are certainly subject to
discussion, my proposal would be

doc(object, doprint=3D1, translate=3D1)

so that users save quite some typing over

>>> print time.time.__doc__=20
time() -> floating point number

Return the current time in seconds since the Epoch.
Fractions of a second may be present if the system clock provides them.

> This will only work iff the translations can be submitted
> via the usual "post to patches with dislcaimer" method...
> aren't the GNU people interested in putting the translations
> under the GPL ?

Is it really necessary to have the translations posted to
patches@python.org? Or would it be sufficient if translators express
their disclaimer in some other way.

I don't think the translation teams are "the GNU people"; the
translators accepted to assign their copyright to the FSF for the
translations they did - I'd assume at least some of them would also
accept maintaining the copyright, or assigning it to the Python
Consortium (or whoever else wants it). It's more that the Python
distributor would need to make suggestions what the copyright on
translations should be - I'm sure that could be clearly communicated
to the translators.

Regards,
Martin


From fdrake@acm.org  Fri Jun  2 13:50:35 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 2 Jun 2000 08:50:35 -0400 (EDT)
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>
References: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <14647.44443.651246.979946@cj42289-a.reston1.va.home.com>

Eric S. Raymond writes:
 > There has been a vast and echoing silence about the ascii.py module I
 > posted here at Fred Drake's request.  Is it really such a  bad idea?

  Did you get my comments?


  -Fred

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



From bwarsaw@python.org  Fri Jun  2 14:37:42 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 2 Jun 2000 09:37:42 -0400 (EDT)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
References: <200006020701.JAA28620@pandora>
 <39376C19.53A01A27@lemburg.com>
 <200006021233.OAA16962@pandora>
Message-ID: <14647.47270.330318.807347@anthem.python.org>

>>>>> "MvL" == Martin von Loewis <loewis@informatik.hu-berlin.de> writes:

    MvL> No, I plan to use the Python gettext module, which is
    MvL> currently being integrated into Python. It will either use
    MvL> the system's gettext library, or read mo files using pure
    MvL> Python.

pygettext is in Tools/i18n, and I've been working with James
Henstridge and Peter Funk on getting a standard gettext module
integrated into the core.  A few other things have bumped that down on
my list, but it's still there.

We'll still need xgettext to scan the C code.  Also, marking Python
module docstrings is a bit problematic.  I've resorted to Something
Really Ugly:

-------------------- snip snip --------------------
try:
    import fintl
    _ = fintl.gettext
except ImportError:
    def _(s): return s


__doc__ = _("""pygettext -- Python equivalent of xgettext(1)
...")
-------------------- snip snip --------------------

Yuck.

-Barry


From pf@artcom-gmbh.de  Fri Jun  2 14:57:32 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Fri, 2 Jun 2000 15:57:32 +0200 (MEST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <14647.47270.330318.807347@anthem.python.org> from "Barry A. Warsaw" at "Jun 2, 2000  9:37:42 am"
Message-ID: <m12xrx6-000DifC@artcom0.artcom-gmbh.de>

Hi, 

[Barry A. Warsaw]:
> pygettext is in Tools/i18n, and I've been working with James
> Henstridge and Peter Funk on getting a standard gettext module
> integrated into the core.  A few other things have bumped that down on
> my list, but it's still there.

I will try to make some progress.  Currently I'm not sure how to
define a class 'Translator' ...  I'm open for suggestions.  James
has also made some interesting points.

> We'll still need xgettext to scan the C code.  Also, marking Python
> module docstrings is a bit problematic.  I've resorted to Something
> Really Ugly:
> 
> -------------------- snip snip --------------------
> try:
>     import fintl
>     _ = fintl.gettext
> except ImportError:
>     def _(s): return s
> 
> 
> __doc__ = _("""pygettext -- Python equivalent of xgettext(1)
> ...")
> -------------------- snip snip --------------------
> 
> Yuck.

I agree: this is really ugly.  Since doc-strings are something special,
I don't think, we should travel further down this road.  I believe,
we should use a special doc-string extration-tool (possibly build
on top of ping's 'inspect.py'?), which will then create a .pot-file
solely out of __doc__-strings.

Regards, Peter.


From loewis@informatik.hu-berlin.de  Fri Jun  2 16:03:50 2000
From: loewis@informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 17:03:50 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <14647.47270.330318.807347@anthem.python.org>
 (bwarsaw@python.org)
References: <200006020701.JAA28620@pandora>
 <39376C19.53A01A27@lemburg.com>
 <200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org>
Message-ID: <200006021503.RAA26314@pandora>

> We'll still need xgettext to scan the C code.

Please have a look at my lib.pot; I've been using xpot to extract the
C doc strings, which aren't currently marked-up in the Python source.

As for module docstrings: xpot doesn't recognize them either, but I
think it could be improved to do so. However, that would give a
substantial increase of the catalogs, so I'd recommend to add them
only when the translators are done with the first round of
translation. Having the full set of distutils doc strings in the
catalog is already a substantial amount of text to translate...

Regards,
Martin


From loewis@informatik.hu-berlin.de  Fri Jun  2 16:05:35 2000
From: loewis@informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 17:05:35 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <m12xrx6-000DifC@artcom0.artcom-gmbh.de> (pf@artcom-gmbh.de)
References: <m12xrx6-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <200006021505.RAA26338@pandora>

> I agree: this is really ugly.  Since doc-strings are something special,
> I don't think, we should travel further down this road.  I believe,
> we should use a special doc-string extration-tool (possibly build
> on top of ping's 'inspect.py'?), which will then create a .pot-file
> solely out of __doc__-strings.

I agree. Again, I'd like to advertise Fran=E7ois Pinard's xpot, which
can extract doc strings from both Python code and C code.

Regards,
Martin


From Moshe Zadka <moshez@math.huji.ac.il>  Fri Jun  2 18:52:59 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Fri, 2 Jun 2000 20:52:59 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
Message-ID: <Pine.GSO.4.10.10006022048430.9466-100000@sundial>

Trusting OS-based mtimes for .pyc caching has some inherent problems.
(Clock syncing and similar) Frankly, though I've never been bitten by
this, it does give me an uncomfortable feeling. What if, instead, we'd use
md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
problems is miniscule compared to the real problems clock syncing has
already caused. (I think I remember some problem with .pyc's on IIS, but
I may just be hallucinating)

Problems:
.pyc size would increase by 24 bytes <wink>

--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From trentm@activestate.com  Fri Jun  2 19:14:17 2000
From: trentm@activestate.com (Trent Mick)
Date: Fri, 2 Jun 2000 11:14:17 -0700
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer?
Message-ID: <20000602111417.A17233@activestate.com>

So, is PyMarshal_WriteLongToFile intended to write a C long, regardless of
its size, or is it intended to alway write 32-bits?

Currently it just writes 32-bits and if sizeof(long) > 4 for that platform
then it is silently truncated. PyMarshal_WriteLongToFile is currently only
used (in the core anyway) to write the magic number and timestamp for .pyc
files in import.c.

The current situation is pretty misleading. If you write a long directly with
PyMarshal_WriteLongToFile your long is truncated to 32-bits. However, if you
write a long indirectly by PyMarshal_WriteObjectToFile, where that Python
object is or contains a PyInt (C long), then the long is *not* truncated.

Options:

1. leave it, who cares

2. - change PyMarshal_WriteLongToFile to write 64-bits if long is 64-bits
   - add something like PyMarshal_WriteInt32ToFile for the benefit of users
	 like import.c that want to control exactly how many bytes get written

3. - change PyMarshal_WriteLongToFile to raise an exception if the long
	 overflows a 32-bit range

Thanks,
Trent


-- 
Trent Mick
trentm@activestate.com


From pf@artcom-gmbh.de  Fri Jun  2 20:21:30 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Fri, 2 Jun 2000 21:21:30 +0200 (MEST)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006022048430.9466-100000@sundial> from Moshe Zadka at "Jun 2, 2000  8:52:59 pm"
Message-ID: <m12xx0c-000DifC@artcom0.artcom-gmbh.de>

hi,

Moshe Zadka wrote:
> Trusting OS-based mtimes for .pyc caching has some inherent problems.
> (Clock syncing and similar) Frankly, though I've never been bitten by
> this, it does give me an uncomfortable feeling. What if, instead, we'd use
> md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
> problems is miniscule compared to the real problems clock syncing has
> already caused. (I think I remember some problem with .pyc's on IIS, but
> I may just be hallucinating)

The timestamp is returned by simply 'stat'ing the .py file.  If you
want more, you actually would have to open the .py files all the time.
This would be trading a big performance penalty for a security, that
will almost always not needed.  In Unix many sub systems (for example
'make' depend on a monotone system clock.  A random jumping clock
would break many of them anyway.

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)


From gstein@lyra.org  Fri Jun  2 20:53:21 2000
From: gstein@lyra.org (Greg Stein)
Date: Fri, 2 Jun 2000 12:53:21 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006022048430.9466-100000@sundial>
Message-ID: <Pine.LNX.4.10.10006021251140.20995-100000@nebula.lyra.org>

On Fri, 2 Jun 2000, Moshe Zadka wrote:
> Trusting OS-based mtimes for .pyc caching has some inherent problems.
> (Clock syncing and similar) Frankly, though I've never been bitten by
> this, it does give me an uncomfortable feeling. What if, instead, we'd use
> md5- or sha-based approach?

That is an expensive computation. You'd have to read the whole file in and
compute the hash.

Today, we simply stat() each file. If the .pyc looks valid, we open it and
check the date stamp against one of those stat's.

You would be adding an open(), a read of the full file, and compute a
hash -- to every import of a .pyc.


-1

Cheers,
-g

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



From mal@lemburg.com  Fri Jun  2 20:13:20 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 21:13:20 +0200
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
References: <Pine.GSO.4.10.10006022048430.9466-100000@sundial>
Message-ID: <39380750.97CD3BA0@lemburg.com>

Moshe Zadka wrote:
> 
> Trusting OS-based mtimes for .pyc caching has some inherent problems.
> (Clock syncing and similar) Frankly, though I've never been bitten by
> this, it does give me an uncomfortable feeling. What if, instead, we'd use
> md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
> problems is miniscule compared to the real problems clock syncing has
> already caused. (I think I remember some problem with .pyc's on IIS, but
> I may just be hallucinating)
> 
> Problems:
> .pyc size would increase by 24 bytes <wink>

Much worse: you'd have to recalculate the MD5-sum every time
you import the .pyc file...

Frankly, I don't think this is needed at all ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From loewis@informatik.hu-berlin.de  Fri Jun  2 21:46:34 2000
From: loewis@informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 22:46:34 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <Pine.SGI.3.96.1000602115722.30600f-100000@happy> (message from
 Ka-Ping Yee on Fri, 2 Jun 2000 12:07:22 -0700 (PDT))
References: <Pine.SGI.3.96.1000602115722.30600f-100000@happy>
Message-ID: <200006022046.WAA29600@pandora>

> But presumably we want to get all the strings, don't we?

Certainly not. For example, in ftplib, the string "anonymous" should
not be translated - it would end up as "anonym" in German, and that
would not be accepted by FTP servers. In general, great care is needed
to select translatable strings. 

For example, the GNU ls program was localized to print the month names
in German. Pretty safe, eh? Now, the emacs dired mode wouldn't
recognize any file names in the list output anymore, because it
had a regular expression to detect the various fields, which involved
an alternative list for all the month names...

Regards,
Martin


From pingster@ilm.com  Fri Jun  2 20:07:22 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Fri, 2 Jun 2000 12:07:22 -0700 (PDT)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <m12xrx6-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.SGI.3.96.1000602115722.30600f-100000@happy>

On Fri, 2 Jun 2000, Peter Funk wrote:
> 
> I agree: this is really ugly.  Since doc-strings are something special,
> I don't think, we should travel further down this road.  I believe,
> we should use a special doc-string extration-tool (possibly build
> on top of ping's 'inspect.py'?), which will then create a .pot-file
> solely out of __doc__-strings.

Getting __doc__ strings is pretty easy (inspect.py is one possibility).
But presumably we want to get all the strings, don't we?

That should be trivial with tokenize, right?

    ---- getstrings.py -----

    import sys, tokenize
    strings = []
    def tokeneater(type, token, start, end, line):
        if type == tokenize.STRING: strings.append(eval(token))
            
    file = open(sys.argv[1])
    tokenize.tokenize(file.readline, tokeneater)
    print strings

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

    % ./getstrings.py /usr/local/lib/python1.5/calendar.py 
    ['calendar.error', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday', 'Sunday', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun', '', 'January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'No
vember', 'December', '   ', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec', 'bad month number', ' ', ' ', '', '', ' ', ' ', '\012', '\012', '\012', ' ', '', '', ' ']

Am i missing something?


-- ?!ng



From gstein@lyra.org  Fri Jun  2 22:32:52 2000
From: gstein@lyra.org (Greg Stein)
Date: Fri, 2 Jun 2000 14:32:52 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <m12xx0c-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>

On Fri, 2 Jun 2000, Peter Funk wrote:
> Moshe Zadka wrote:
> > Trusting OS-based mtimes for .pyc caching has some inherent problems.
> > (Clock syncing and similar) Frankly, though I've never been bitten by
> > this, it does give me an uncomfortable feeling. What if, instead, we'd use
> > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
> > problems is miniscule compared to the real problems clock syncing has
> > already caused. (I think I remember some problem with .pyc's on IIS, but
> > I may just be hallucinating)
> 
> The timestamp is returned by simply 'stat'ing the .py file.  If you
> want more, you actually would have to open the .py files all the time.
> This would be trading a big performance penalty for a security, that
> will almost always not needed.  In Unix many sub systems (for example
> 'make' depend on a monotone system clock.  A random jumping clock
> would break many of them anyway.

He does have a point, but I think the wrong solution :-)

While the clock may be monotonically increasing on one system, it isn't
always the case when things like NFS come into play.

I recall a case back '95 when I was editing a .py over an NFS mount and
running the code on the target machine. The clocks on the two boxes were
off by about three seconds. I was going thru the edit/run/edit/run cycle
so quickly, that at one point, I saved a .py file that was older than the
associated .pyc file.

Needless to say, I was really confused that my recent edit didn't produce
the desired result :-)

Cheers,
-g

p.s. and no, I don't know why the internal timestamp didn't take effect

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



From pingster@ilm.com  Sat Jun  3 00:10:01 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Fri, 2 Jun 2000 16:10:01 -0700 (PDT)
Subject: [Python-Dev] Protecting __name__ &c.
Message-ID: <Pine.SGI.3.96.1000602160710.30600q-100000@happy>

Would it be too much trouble to prevent replacing
double-underscore attributes like __name__ and __file__?

I'll accept a "consenting adults" argument -- it's just
that somehow this makes me uneasy:

    Python 1.5.2 (#54, Jul 14 1999, 12:50:51) [C] on irix6
    Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
    >>> import foo
    >>> foo.__name__
    'bar'
    >>> foo.__file__
    'bar.py'
    >>> foo
    <module 'bar' from 'bar.py'>

Of course, there is no 'bar.py'.  'foo.py' just contains

    __file__ = 'bar.py'
    __name__ = 'bar'

(If you say i deserved to be punished for such heresy, fine...)



-- ?!ng



From mhammond@skippinet.com.au  Sat Jun  3 00:21:07 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Sat, 3 Jun 2000 09:21:07 +1000
Subject: [Python-Dev] Protecting __name__ &c.
In-Reply-To: <Pine.SGI.3.96.1000602160710.30600q-100000@happy>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEECCMAA.mhammond@skippinet.com.au>

> Would it be too much trouble to prevent replacing
> double-underscore attributes like __name__ and __file__?

This can be handy sometimes.

> I'll accept a "consenting adults" argument -- it's just
> that somehow this makes me uneasy:

OK - accept it :-)  Just dont do it if it makes you uneasy.

>     >>> import foo
>     >>> foo.__name__
>     'bar'
>     >>> foo.__file__
>     'bar.py'
>     >>> foo
>     <module 'bar' from 'bar.py'>

That is no worse than, say:

>>> a=1
>>> globals()['a']=2
>>> a
2

So you could make the same argument that globals() should be read-only, to
force you to do the "normal" thing.

To me, this is one of Python's big features.  I dont want it holding my
hand so tightly it cuts circulation :-)

Mark.



From akuchlin@mems-exchange.org  Sat Jun  3 04:15:50 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 2 Jun 2000 23:15:50 -0400
Subject: [Python-Dev] What's New (first draft)
Message-ID: <20000602231550.A986@newcnri.cnri.reston.va.us>

I've put up the crude first draft of a "What's New in Python 1.6" article,
co-written with Moshe Zadka.  Please offer comments (or even patches to the
LaTeX!). 

http://www.python.net/crew/amk/python/writing/new-python/

PDF, DVI, ASCII, and the LaTeX source are in:
	ftp://www.python.net/pub/crew/amk/new/

Various people are mentioned by name in the document ("effbot did
this; MAL did that; Christian did that other thing...") because I want to
emphasize the number of contributors to this release; does everyone think
this is a good idea?  If I've missed your name, or credited you wrongly,
please let me know.

--amk


From akuchlin@mems-exchange.org  Sat Jun  3 04:25:21 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 2 Jun 2000 23:25:21 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
Message-ID: <20000602232521.B986@newcnri.cnri.reston.va.us>

I've slightly revised the 1.6 jobs list
at http://www.python.net/crew/amk/python/1.6-jobs.html .
Things still on the TODO list, maybe:

Import hooks revamp (or is this a post-1.6 thing?) 
Update the documentation to match 1.6 changes. 
Document more undocumented modules (goes without saying, really...) : codecs,
	unicodedata, mmap, pyexpat, curses, regrtest. 
Unicode: Compress the size of unicodedatabase 
Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch)
Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?)
Delete obsolete subdirectories in Demo/ directory 
Refurbish Demo subdirectories to be properly documented, match modern coding
	style, etc. 
Fix ./ld_so_aix installation problem on AIX 
Make test.regrtest.py more usable outside of thePython test suite 
Conservative garbage collection of cycles (maybe -- I don't know what GvR
	thinks about this)
Changes to PyExpat module
Test the hell out of SRE

The end of coding may be in sight, leaving only the job of documenting
everything new.  I'm getting kind of worried about the lengthening backlog
of patches, though; maybe next week we can start cutting it down? (Quick,
while Guido's away, everyone come up with new keywords and check them in!)

--amk


From esr@thyrsus.com  Sat Jun  3 04:49:16 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Fri, 2 Jun 2000 23:49:16 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Fri, Jun 02, 2000 at 11:25:21PM -0400
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <20000602234916.B9680@thyrsus.com>

Andrew Kuchling <akuchlin@cnri.reston.va.us>:
> Document more undocumented modules (goes without saying, really...) : codecs,
> 	unicodedata, mmap, pyexpat, curses, regrtest. 

About curses.  Have you got the entry points listed and dxescribed yet?
If so, I'll flesh out the docs with my tutorial stuff.

We have a volunteer maintainer for curses after release, now, BTW.  It's
new Pythoneer Jim Dennis, the "Answer Guy" from the Linux Gazette.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The end move in politics is always to pick up a gun.
	-- R. Buckminster Fuller


From bwarsaw@python.org  Sat Jun  3 05:41:42 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Sat, 3 Jun 2000 00:41:42 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <14648.35974.486959.379543@anthem.python.org>

Did we ever decide on building in thread support by default?  I'd
really like to see threads enabled by default in 1.6 and I /think/
it'll just take some autoconf hacking, which I'm willing to do.  Are
there any objections to building in threads support by default if
autoconf detects threads?

-Barry


From Moshe Zadka <moshez@math.huji.ac.il>  Sat Jun  3 07:05:09 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Sat, 3 Jun 2000 09:05:09 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>
Message-ID: <Pine.GSO.4.10.10006030900030.14749-100000@sundial>

On Fri, 2 Jun 2000, Greg Stein wrote:

> He does have a point, but I think the wrong solution :-)

In my defense, it was after spending the whole day on my feet giving a
lecture, or driving (for 12 hours).

But it does bother me, even if the solution is terrible.
How about having, in addition to the time-stamp, the size of the file?
At least on UNIX, it comes for free with the same stat call.
--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From Moshe Zadka <moshez@math.huji.ac.il>  Sat Jun  3 08:56:15 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Sat, 3 Jun 2000 10:56:15 +0300 (IDT)
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit
 integer?
In-Reply-To: <20000602111417.A17233@activestate.com>
Message-ID: <Pine.GSO.4.10.10006030833470.14749-100000@sundial>

On Fri, 2 Jun 2000, Trent Mick wrote:

> 3. - change PyMarshal_WriteLongToFile to raise an exception if the long
> 	 overflows a 32-bit range

+1 on that, finally non-portable integers will cause an exception.

--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From Moshe Zadka <moshez@math.huji.ac.il>  Sat Jun  3 09:11:45 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Sat, 3 Jun 2000 11:11:45 +0300 (IDT)
Subject: [Python-Dev] Protecting __name__ &c.
In-Reply-To: <Pine.SGI.3.96.1000602160710.30600q-100000@happy>
Message-ID: <Pine.GSO.4.10.10006031109180.14749-100000@sundial>

On Fri, 2 Jun 2000, Ka-Ping Yee wrote:

> Would it be too much trouble to prevent replacing
> double-underscore attributes like __name__ and __file__?

Well, special casing seems like a bad idea on the face of it. Where does
it stop? The correct way to "solve" this, is to add declarations to
Python, including "constant" declaration, and then saying that __name__
and __file__ are "implicitly declared" constants.

please-scatter-IMHOs-generously-throughtout-the-mail-ly y'rs, Z.
--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From gstein@lyra.org  Sat Jun  3 10:52:39 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 02:52:39 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14648.35974.486959.379543@anthem.python.org>
Message-ID: <Pine.LNX.4.10.10006030252230.28613-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Barry A. Warsaw wrote:
> Did we ever decide on building in thread support by default?  I'd
> really like to see threads enabled by default in 1.6 and I /think/
> it'll just take some autoconf hacking, which I'm willing to do.  Are
> there any objections to building in threads support by default if
> autoconf detects threads?

+1 -- if they are there, then build them in!

Cheers,
-g

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



From gmcm@hypernet.com  Sat Jun  3 12:26:18 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Sat, 3 Jun 2000 07:26:18 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <1252090883-19062603@hypernet.com>

Andrew Kuchling wrote:

> I've slightly revised the 1.6 jobs list
> at http://www.python.net/crew/amk/python/1.6-jobs.html .
> Things still on the TODO list, maybe:
> 
> Import hooks revamp (or is this a post-1.6 thing?) 

The import SIG was created to resolve the controversies 
around imputils. The archives of the import SIG contain 
absolutely no controversy. So I say do it.

- Gordon


From skip@mojam.com (Skip Montanaro)  Sat Jun  3 13:15:28 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Sat, 3 Jun 2000 07:15:28 -0500 (CDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>
References: <m12xx0c-000DifC@artcom0.artcom-gmbh.de>
 <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>
Message-ID: <14648.63200.850429.304545@beluga.mojam.com>

    Greg> I recall a case back '95 when I was editing a .py over an NFS
    Greg> mount and running the code on the target machine. The clocks on
    Greg> the two boxes were off by about three seconds. I was going thru
    Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved
    Greg> a .py file that was older than the associated .pyc file.

A help I think would be to compare the mtimes of the .py and .pyc files with 
the current system clock and squawk if either appears to have been created
in the future.  I believe this is what GNU make does.

Of course, the best solution to all of this is the non-Python solution: use
NTP so your clocks stay sync'd.  It's even available out-of-the-box on my
iMac...

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
"We have become ... the stewards of life's continuity on earth.  We did not
ask for this role...  We may not be suited to it, but here we are."
- Stephen Jay Gould


From Moshe Zadka <moshez@math.huji.ac.il>  Sat Jun  3 13:53:47 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Sat, 3 Jun 2000 15:53:47 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com>
Message-ID: <Pine.GSO.4.10.10006031551470.17983-100000@sundial>

On Sat, 3 Jun 2000, Skip Montanaro wrote:

> Of course, the best solution to all of this is the non-Python solution: use
> NTP so your clocks stay sync'd.  It's even available out-of-the-box on my
> iMac...

But the "Python Way" was always to adapt: not to require One True Way, but
to use the facilities where it finds itself.

In any case, is there any objection to storing the size of the .py
alongside it's mtime in the .pyc, and regenerating if either is changed?
This is just as efficient, and much more reliable.
--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From mal@lemburg.com  Sat Jun  3 10:55:26 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 03 Jun 2000 11:55:26 +0200
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <3938D60E.391AAF31@lemburg.com>

Andrew Kuchling wrote:
> 
> I've slightly revised the 1.6 jobs list
> at http://www.python.net/crew/amk/python/1.6-jobs.html .
> Things still on the TODO list, maybe:
> 
> Import hooks revamp (or is this a post-1.6 thing?)
> Update the documentation to match 1.6 changes.
> Document more undocumented modules (goes without saying, really...) : codecs,
>         unicodedata, mmap, pyexpat, curses, regrtest.

I would appreciate some help with codec and unicodedata.
codec.py has quite a bit of __doc__ string documentation
which can be used more or less directly for the TeX docs.

> Unicode: Compress the size of unicodedatabase

Christian was working on this one, but I never got the
patches ... Chris ?

> Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch)

I wonder why that patch hasn't been accepted yet -- I guess
the patches list needs some more people willing to review things
and of course people with check in permissions.

I would volunteer to handle the above for the Unicode parts
of the distribution if someone would explain to me how to
checkin new code into SourceForge CVS.

> Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?)

Hmm, there are no XXX markings left in my version of that
file -- perhaps I've missed adding it to the patch sets...

Anyway, the file will have to undergo some rewrite now that
the default encoding strategy has changed. I'll fix that next
week.

> Delete obsolete subdirectories in Demo/ directory
> Refurbish Demo subdirectories to be properly documented, match modern coding
>         style, etc.
> Fix ./ld_so_aix installation problem on AIX
> Make test.regrtest.py more usable outside of thePython test suite
> Conservative garbage collection of cycles (maybe -- I don't know what GvR
>         thinks about this)
> Changes to PyExpat module
> Test the hell out of SRE
> 
> The end of coding may be in sight, leaving only the job of documenting
> everything new.  I'm getting kind of worried about the lengthening backlog
> of patches, though; maybe next week we can start cutting it down? (Quick,
> while Guido's away, everyone come up with new keywords and check them in!)

:-)

Still, you've got a point there: Trent's patches are getting
piled up and due to the fact that they touch many different
parts of the code, they are likely to get in the way of other
patches.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jeremy@beopen.com  Sat Jun  3 17:11:48 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Sat, 3 Jun 2000 12:11:48 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <3938D60E.391AAF31@lemburg.com>
Message-ID: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>

M.-A. Lemburg wrote:
>I wonder why that patch hasn't been accepted yet -- I guess
>the patches list needs some more people willing to review things
>and of course people with check in permissions.

One of the problems I'm having is keeping track of which patches
are still outstanding.  This is really a management/tools problem.
I have a mailbox full of messages from the patches list -- some
of the messages are patches, others are discussion.  Some patches
supercede others or are duplicates.  It would help if we had better
tools for managing the submitted/pending patches.

SourceForge makes it a little more inconvenient to check which
patches have been applied.  Under the old CVS arrangement, it was
a local operation to do a cvs log or diff.  Now it's a slow network
operation that requires authentication.  (I really want a local
mirror of the entire CVS repository!)

Sorry for the excuses.  I think better tools would help a lot, but
we'll have to get more people checkin privileges regardless.

Jeremy






From tismer@tismer.com  Sat Jun  3 17:43:51 2000
From: tismer@tismer.com (Christian Tismer)
Date: Sat, 03 Jun 2000 18:43:51 +0200
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com>
Message-ID: <393935C7.7624448A@tismer.com>


"M.-A. Lemburg" wrote:

> > Unicode: Compress the size of unicodedatabase
> 
> Christian was working on this one, but I never got the
> patches ... Chris ?

Schmurpel :->

Something came in between where I couldn't resist
to work on... yes, the microthread stuff was it.

Ok, it is a pain for me to go for a sub-optimum solution,
but yep, I'll force me to write the code gen now.

...
> Still, you've got a point there: Trent's patches are getting
> piled up and due to the fact that they touch many different
> parts of the code, they are likely to get in the way of other
> patches.

patch-as-patch-can-ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com


From tismer@tismer.com  Sat Jun  3 17:44:31 2000
From: tismer@tismer.com (Christian Tismer)
Date: Sat, 03 Jun 2000 18:44:31 +0200
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com>
Message-ID: <393935EF.89AA40DF@tismer.com>


"M.-A. Lemburg" wrote:

> > Unicode: Compress the size of unicodedatabase
> 
> Christian was working on this one, but I never got the
> patches ... Chris ?

Schmurpel :->

Something came in between where I couldn't resist
to work on... yes, the microthread stuff was it.

Not to talk of the starship mess, which will hopefully
end by this weekend...

Ok, it is a pain for me to go for a sub-optimum solution,
but yep, I'll force me to write the code gen now.

...
> Still, you've got a point there: Trent's patches are getting
> piled up and due to the fact that they touch many different
> parts of the code, they are likely to get in the way of other
> patches.

patch-as-patch-can-ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com


From gstein@lyra.org  Sat Jun  3 20:41:19 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 12:41:19 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com>
Message-ID: <Pine.LNX.4.10.10006031236430.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Skip Montanaro wrote:
>     Greg> I recall a case back '95 when I was editing a .py over an NFS
>     Greg> mount and running the code on the target machine. The clocks on
>     Greg> the two boxes were off by about three seconds. I was going thru
>     Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved
>     Greg> a .py file that was older than the associated .pyc file.
> 
> A help I think would be to compare the mtimes of the .py and .pyc files with 
> the current system clock and squawk if either appears to have been created
> in the future.  I believe this is what GNU make does.

Sure, but to the target machine, the .pyc was fine and the .py was in the
past. :-)

Of course, the proper solution is to introduce compile/link stages into
Python so that we don't get bitten by 3-second clock differences.

:-)

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



From gstein@lyra.org  Sat Jun  3 21:26:00 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 13:26:00 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.8,2.9
In-Reply-To: <200006031941.MAA21418@slayer.i.sourceforge.net>
Message-ID: <Pine.LNX.4.10.10006031324470.29036-100000@nebula.lyra.org>

Actually, PyArg_ParseTuple() is a better call for this. It allows you to
specify the method name:

    if (!PyArg_ParseTuple(args, ":close")) return NULL;


Cheers,,
-g

On Sat, 3 Jun 2000, A.M. Kuchling wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv21410
> 
> Modified Files:
> 	mmapmodule.c 
> Log Message:
> Add missing PyArg_NoArgs() calls to methods that didn't take arguments
>    (Pointed out by Moshe Zadka)
> 
> 
> Index: mmapmodule.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/mmapmodule.c,v
> retrieving revision 2.8
> retrieving revision 2.9
> diff -C2 -r2.8 -r2.9
> *** mmapmodule.c	2000/05/03 23:44:32	2.8
> --- mmapmodule.c	2000/06/03 19:41:42	2.9
> ***************
> *** 2,6 ****
>    /  Author: Sam Rushing <rushing@nightmare.com>
>    /  Hacked for Unix by A.M. Kuchling <amk1@bigfoot.com> 
> !  /  $Id: mmapmodule.c,v 2.8 2000/05/03 23:44:32 guido Exp $
>   
>    / mmapmodule.cpp -- map a view of a file into memory
> --- 2,6 ----
>    /  Author: Sam Rushing <rushing@nightmare.com>
>    /  Hacked for Unix by A.M. Kuchling <amk1@bigfoot.com> 
> !  /  $Id: mmapmodule.c,v 2.9 2000/06/03 19:41:42 akuchling Exp $
>   
>    / mmapmodule.cpp -- map a view of a file into memory
> ***************
> *** 76,79 ****
> --- 76,81 ----
>   mmap_close_method (mmap_object * self, PyObject * args)
>   {
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   #ifdef MS_WIN32
>   	UnmapViewOfFile (self->data);
> ***************
> *** 119,122 ****
> --- 121,126 ----
>   	char * where;
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   	if (self->pos >= 0 && self->pos < self->size) {
>   	        where = self->data + self->pos;
> ***************
> *** 132,136 ****
>   static PyObject *
>   mmap_read_line_method (mmap_object * self,
> ! 			   PyObject * args)
>   {
>   	char * start = self->data+self->pos;
> --- 136,140 ----
>   static PyObject *
>   mmap_read_line_method (mmap_object * self,
> ! 		       PyObject * args)
>   {
>   	char * start = self->data+self->pos;
> ***************
> *** 140,143 ****
> --- 144,149 ----
>   
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   
>   	eol = memchr(start, '\n', self->size - self->pos);
> ***************
> *** 154,158 ****
>   static PyObject *
>   mmap_read_method (mmap_object * self,
> ! 		      PyObject * args)
>   {
>   	long num_bytes;
> --- 160,164 ----
>   static PyObject *
>   mmap_read_method (mmap_object * self,
> ! 		  PyObject * args)
>   {
>   	long num_bytes;
> ***************
> *** 226,230 ****
>   static PyObject *
>   mmap_write_byte_method (mmap_object * self,
> ! 			    PyObject * args)
>   {
>   	char value;
> --- 232,236 ----
>   static PyObject *
>   mmap_write_byte_method (mmap_object * self,
> ! 			PyObject * args)
>   {
>   	char value;
> ***************
> *** 242,248 ****
>   static PyObject *
>   mmap_size_method (mmap_object * self,
> ! 		      PyObject * args)
>   {
>   	CHECK_VALID(NULL);
>   
>   #ifdef MS_WIN32
> --- 248,256 ----
>   static PyObject *
>   mmap_size_method (mmap_object * self,
> ! 		  PyObject * args)
>   {
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   
>   #ifdef MS_WIN32
> ***************
> *** 347,350 ****
> --- 355,360 ----
>   {
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   	return (Py_BuildValue ("l", self->pos) );
>   }
> ***************
> *** 463,470 ****
>   
>   static int
> ! mmap_buffer_getreadbuf(self, index, ptr)
> ! 	mmap_object *self;
> ! int index;
> ! const void **ptr;
>   {
>   	CHECK_VALID(-1);
> --- 473,477 ----
>   
>   static int
> ! mmap_buffer_getreadbuf(mmap_object *self, int index, const void **ptr)
>   {
>   	CHECK_VALID(-1);
> ***************
> *** 868,869 ****
> --- 875,877 ----
>   
>   }
> + 
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins@python.org
> http://www.python.org/mailman/listinfo/python-checkins
> 

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



From gstein@lyra.org  Sat Jun  3 21:34:26 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 13:34:26 -0700 (PDT)
Subject: [Python-Dev] autoconf macros (was: RE: [Patches] Patch to Modules/pcre.h)
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBMEEMCMAA.mhammond@skippinet.com.au>
Message-ID: <Pine.LNX.4.10.10006031326320.29036-100000@nebula.lyra.org>

[moving to python-dev]

On Sun, 4 Jun 2000, Mark Hammond wrote:
> > I don't even see where DONT_HAVE_SYS_TYPES_H is ever defined:
> ...
> > Is it defined in some Mac-specific project file?
> 
> A few existed before, but I know I submitted a couple of the listed ones
> for Windows CE.  However, the CE config.h has never made it into the core,
> hence you can't find that particular definition...

Well, as I pointed out, the best way to do this is to add sys/types.h,
sys/stat.h, and stat.h to the AC_CHECK_HEADER() macro in configure.in. The
HAVE_SYS_TYPES_H macro and friends could then be checked.

PC/wince_config.h (or whatever it is called) would just #undef the 
HAVE_* macros.

The underlying issue here, is that autoconf can take care of these things
for us quite easily -- that we don't need manual maintenance of the
macros. For the odd platform without sys/types.h, autoconf will handle it,
rather than Python needing to do a special-case declaration.

Cheers,
-g

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



From gstein@lyra.org  Sat Jun  3 21:44:07 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 13:44:07 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
Message-ID: <Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Jeremy Hylton wrote:
>...
> Sorry for the excuses.  I think better tools would help a lot, but
> we'll have to get more people checkin privileges regardless.

There are several issues with expanded checkin privs:

1) trust: will the person make sure it is Right And Proper to do the
   checkin? (have they reviewed the code? is a a Good Change? etc) The
   counter here is that we don't want people that will simply take stuff
   arriving at patches@ and checking them in.

2) more people reviewing changes on the -checkins mailing list. Assuming
   that you want more than one pair of eyeballs looking at patches/code,
   that more people with commit privs increases the rate of commits, then
   you need more reviewers to keep up (because the reviewers probably are
   not going to review ALL checkins)

3) increasing dependence on -checkins means that patches MUST be smaller
   chunks. they MUST be single-purpose patches. practically nobody will
   review a 200k patch, or patches that fix N different things at once. A
   small, focused patch is easily reviewed.

   For example: Trent has recently mailed a bunch of patches to the
   patches list. This is Goodness: each one is focused and can be
   individually reviewed. Since they are not a single, giant blob, it also
   keeps them short and reviewable... each can have a +1/-1 independent of
   the others.


Cheers,
-g

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



From gstein@lyra.org  Sat Jun  3 22:14:49 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 14:14:49 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006031551470.17983-100000@sundial>
Message-ID: <Pine.LNX.4.10.10006031412460.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Moshe Zadka wrote:
>...
> In any case, is there any objection to storing the size of the .py
> alongside it's mtime in the .pyc, and regenerating if either is changed?
> This is just as efficient, and much more reliable.

If we change the header size, then this would be fine. At the moment, I
don't think that anybody is suggesting a change to the .pyc header format
because of the number of tool breakages that would ensue.

People have seemed interested in my idea to update the marshal format to
record a version number -- it doesn't require a change to the .pyc header.

Cheers,
-g

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



From gstein@lyra.org  Sat Jun  3 23:53:18 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 15:53:18 -0700 (PDT)
Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!)
In-Reply-To: <Pine.LNX.4.10.10006020134050.17073-100000@nebula.lyra.org>
Message-ID: <Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>

I found the problem. Sneaky...

sock.makefile() does a dup() on the file descriptor, then opens a FILE*
with that. See it coming yet? ...

FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd
file descriptor. When we went to grab another chunk on the *original*
descriptor, we missed input [that is now sitting in the FILE* buffer].

Answer: change the .makefile() in getreply() to:

    file = self.sock.makefile('rb', 0)

This problem is going to affect the original httplib, too. IMO, we're
about to replace the sucker, so no worries...

Cheers,
-g

On Fri, 2 Jun 2000, Greg Stein wrote:
> It looks like a definite bug. I have *no* idea, tho, why it is doing
> that... I did quite a bit of testing with chunked replies. Admittedly,
> though, I didn't stack up requests like you've done in your test. I'm
> wrapping up mod_dav at the moment, so I don't really have time to look
> deeply into this. Mebbe next week?
> 
> Regarding the pipeline request thing. I think it would probably be best to
> just drop the whole "hold the previous response and wait for it to be
> closed" thing. I don't know why that is in there; probably a leftover
> (converted) semantic from the old-style HTTP() class. I'd be quite fine
> just axing it and allowing the client to shove ten requests down the pipe
> before pulling the first response back out.
> 
> Oh. Wait. Maybe that was it. You can't read the "next" response until the
> first one has been read. Well... no need to block putting new responses;
> we just need to create a way to "get the next reply" and/or "can I get the
> next reply yet?"
> 
> Cheers,
> -g
> 
> p.s. Moshe also had a short list of review items. I read thru them, but
> not with the code in hand to understand some of his specifics.
> 
> 
> On Wed, 31 May 2000, Jeremy Hylton wrote:
> > >>>>> "GS" == Greg Stein <gstein@lyra.org> writes:
> > 
> >   GS> [ and recall my email last week that I've updated httplib.py and
> >   GS> posted it to my web pages; it is awaiting review for integration
> >   GS> into the Python core; it still needs docs and more testing
> >   GS> scenarios, tho
> > 
> > I've been looking at the httplib code, and I found what may be a bug.
> > Not sure, because I'm not sure how the API works for pipelined
> > requests. 
> > 
> > I've got some test code that looks a bit like this:
> > 
> > def test_new_interface_series(urls):
> >     paths = []
> >     the_host = None
> >     for url in urls:
> >         host, path = get_host_and_path(url)
> >         if the_host is None:
> >             the_host = host
> >         else:
> >             assert host == the_host
> >         paths.append(path)
> >         
> >     conn = httplib.HTTPConnection(the_host)
> >     for path in paths:
> >         conn.request('GET', path, headers={'User-Agent': 'httplib/Python'})
> >     for path in paths:
> >         errcode, errmsg, resp = conn.getreply()
> >         buf = resp.read()
> >         if errcode == 200:
> >             print errcode, resp.headers
> >         else:
> >             print errcode, `errmsg`, resp
> >         print resp.getheader('Content-Length'), len(buf)
> >         print repr(buf[:40])
> >         print repr(buf[-40:])
> >         print
> >     conn.close()
> > 
> > test_new_interface_series(['http://www.python.org/',
> >                         'http://www.python.org/pics/PyBanner054.gif',
> >                         'http://www.python.org/pics/PythonHi.gif',
> >                         'http://www.python.org/Jobs.html',
> >                         'http://www.python.org/doc/',
> >                         'http://www.python.org/doc/current/',
> >                            ])
> > 
> > The second loop that reads the replies gets fouled up after a couple
> > of responses.  I added even more debugging and found that the first
> > line of the corrupted response is
> > 
> > > 'ontent-Type: text/html\015\012'
> > 
> > It looks like some part of the program is consuming too much input.  I
> > haven't been able to figure out what part yet.  Hoping that you might
> > have some good ideas.
> > 
> > Thinking about this issue, I came up with a potential API problem.
> > You must read the body after calling getreply and before calling
> > getreply a second time.  This kind of implicit requirement is a bit
> > tricky.  It would help if the implementation could raise an error if
> > this happens.  It might be even better if it just worked, although it
> > seems a bit too magical.
> > 
> > Jeremy
> > 
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 
> 
> 
> 

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



From thomas@xs4all.net  Sat Jun  3 23:56:01 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sun, 4 Jun 2000 00:56:01 +0200
Subject: [Python-Dev] Re: Is it just Syntactic Sugar ?
In-Reply-To: <3935B383.469032AE@python.org>; from guido@python.org on Wed, May 31, 2000 at 11:49:57PM +0000
References: <k7lW4.96338$E85.1941352@news1.rdc1.md.home.com> <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <mt4s7f7q62.fsf@astron.berkeley.edu> <m3u2ffydwy.fsf@atrus.jesus.cam.ac.uk> <mtog5n68ak.fsf@astron.berkeley.edu> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org>
Message-ID: <20000604005601.T469@xs4all.nl>

On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum wrote:

> I know I shouldn't be posting in this thread, and I won't be there to read
> the responses, but here's what I thought would be cool.

As the 'lucky, lucky bastard' is probably standing before the altar about
now, I'll send this to the dev-list instead. Not that I expect anyone *not*
to be at the wedding, but I bet the rest is back sooner ;-)

> x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means "and becomes"
> (an old Algol-68 naming convention; we could pick something better later
> but this will do for the explanation).

> For immutable types, this is defined as

>   def __add_ab__(self, other):
>       return self+other

> For mutable types, this is defined as a self-mutating operation,
> e.g. for lists it could be

>   def __add_ab__(self, other):
>       self.extend(other)
>       return self

This was what I had in mind, and was trying to explain. Does you voicing
your opinion mean someone (you ? someone else ?) is working on this, or soon
going to work on this ? I had a chat with Michael about fixing up his patch
to work all the way (it's currently a proof-of-concept-quick-hack that only
works for builtin types) which prompted me to study Python's internals a bit
closer. (I hope I dont sound too patronizing when I say I was impressed ;-)

I'm curious what should happen with index-assignment and slice-assignment:

x[y] += z
x[:y] += z

(Obviously this wont make sense for a lot of types, or will be too
un-obvious to include, but I can imagine matrix-types to happily add this.)

Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, y, z) ? Or
would x[y] += z always call x[y].__add_item_ab__() and x[:y] create a new
object, a slice of x, and call its __add_ab__() method ? Or would it try all
of them, or more, until it gets a good result ? Or am I running ahead of
things and should we wait for a working patch first ? :)

If I suddenly grow a deep understanding of Python's internals (not ruled
out, it's fairly obvious) and hack-up something that works before anyone
else, I'll be sure to mail ;)

oh-and-congratulations-to-Mrs.-van-Rossum-too-ly yr's,
-- 
Thomas Wouters <thomas@xs4all.net>

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


From gstein@lyra.org  Sun Jun  4 00:06:07 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 16:06:07 -0700 (PDT)
Subject: [Python-Dev] httplib
In-Reply-To: <Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>
Message-ID: <Pine.LNX.4.10.10006031605000.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Greg Stein wrote:
> I found the problem. Sneaky...
> 
> sock.makefile() does a dup() on the file descriptor, then opens a FILE*
> with that. See it coming yet? ...
> 
> FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd
> file descriptor. When we went to grab another chunk on the *original*
> descriptor, we missed input [that is now sitting in the FILE* buffer].
> 
> Answer: change the .makefile() in getreply() to:
> 
>     file = self.sock.makefile('rb', 0)
> 
> This problem is going to affect the original httplib, too. IMO, we're
> about to replace the sucker, so no worries...

Oh... actually it won't affect the original since that doesn't pipeline
requests.

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



From gstein@lyra.org  Sun Jun  4 00:13:55 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 16:13:55 -0700 (PDT)
Subject: [Python-Dev] more on httplib
Message-ID: <Pine.LNX.4.10.10006031606100.29036-100000@nebula.lyra.org>

I would like to propose a few changes to the (new) httplib:

*) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to
   provide backwards-compat for it

*) revamp the pipeline support:

   - record the "last response object" ... when a new getreply() is done,
     then we store the "last" into response.prior
   - reading of the "HTTP/1.1 <code> <msg>" line is deferred, and
     performed by the response object
   - the read of that line is lazy
   - if the response line is read *before* the "prior" response (if any) 
     is "closed", then an exception is raised: ResponseNotReady

*) address some of Moshe's concerns:

   - use class-based exceptions
   - clarify that HTTPConnection is designed for *blocking* sockets
   - conn.close() followed by conn.send() will reopen the socket. This
     could lead to programming errors. I'll add a class-based default flag
     to disable this behavior.
   - in request(), we check for errno==32 ... what to do on Windows?


I will implement these changes in small chunks so that each can be
reviewed in my CVS repository. The history is available at:

    http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/


Cheers,
-g

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




From mhammond@skippinet.com.au  Sun Jun  4 03:03:34 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Sun, 4 Jun 2000 12:03:34 +1000
Subject: [Python-Dev] What's New (first draft)
In-Reply-To: <20000602231550.A986@newcnri.cnri.reston.va.us>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEFCCMAA.mhammond@skippinet.com.au>

> emphasize the number of contributors to this release; does everyone think
> this is a good idea?  If I've missed your name, or credited you wrongly,
> please let me know.

OK - as you insist :-)

Bill Tutt and I could do with a credit for the new winreg module.

Thanks,

Mark.



From tim_one@email.msn.com  Sun Jun  4 05:09:02 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sun, 4 Jun 2000 00:09:02 -0400
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006030900030.14749-100000@sundial>
Message-ID: <000a01bfcdda$9e876060$1d2d153f@tim>

[Moshe]
> How about having, in addition to the time-stamp, the size of the file?
> At least on UNIX, it comes for free with the same stat call.

+1 from me.  Note that, besides inter-machine clock skew, some filesystems
have a timestamp granularity too coarse to distinguish close-in-time writes.
For those (& related) reasons, the attentive Pythoneer will have noted that
all of the winning 1st-round Software Carpentry "make"-replacement designs
provide for alternatives to timestamps.  Tom Tromey's has the clearest
discussion of the problems with timestamps:

http://software-carpentry.codesourcery.com/entries/build/Tromey/Tromey.html

In my industrial experience, (timestamp, size) pairs have never failed in
practice.  However, "my industrial experience" has been entirely in projects
where source-control wrappers add a checkin comment block to every
checked-in file, and that alone made it exceedingly unlikely that any two
successive versions of a file would have the same size.

In Python I'm still (a little) worried about cases like

SOME_GLOBAL_CONFIG_OPTION = 0

where "0" gets replaced by "1" or "2" or ... there are lots of interesting
things you can do to Python programs without changing their size.  At
Dragon, checked-in Python files were also subject to the "checkin comment
block" rule, so no project under source control suffered from this.  I
suspect it burned people in their pre-source-controlled development
projects, though!  One group in particular had a project that involved acres
of machine-generated Python modules, and I know they suffered from coarse
timestamps on their flavor of Unix (so part of their "make" procedure was to
nuke all .pyc's on each build).

it's-easy-to-laugh-at-problems-you-don't-have<wink>-ly y'rs  - tim




From Moshe Zadka <moshez@math.huji.ac.il>  Sun Jun  4 05:59:31 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Sun, 4 Jun 2000 07:59:31 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <000a01bfcdda$9e876060$1d2d153f@tim>
Message-ID: <Pine.GSO.4.10.10006040757010.23740-100000@sundial>

On Sun, 4 Jun 2000, Tim Peters wrote:

[Moshe]
> How about having, in addition to the time-stamp, the size of the file?
> At least on UNIX, it comes for free with the same stat call.

 
[Tim]
> +1 from me.
<even more reasons>

Now there is the big problem, that this will be changing the header size.
I thought that this would be a good time anyway, since 1.5.2 pycs aren't
compatible with 1.6, but changing the header size is a bigger thing.

so-this-waits-until-guido-comes-back-i-guess-ly y'rs, Z.
--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From bwarsaw@python.org  Sun Jun  4 21:51:30 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Sun, 4 Jun 2000 16:51:30 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <3938D60E.391AAF31@lemburg.com>
 <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
Message-ID: <14650.49490.725648.798719@anthem.python.org>

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

    JH> One of the problems I'm having is keeping track of which
    JH> patches are still outstanding.

SF has a patch manager but I haven't played with it much.  In fact, I
can't seem to find it for the Python project, but it's there in the
Mailman project.

-Barry


From gstein@lyra.org  Sun Jun  4 21:55:09 2000
From: gstein@lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 13:55:09 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14650.49490.725648.798719@anthem.python.org>
Message-ID: <Pine.LNX.4.10.10006041353020.29036-100000@nebula.lyra.org>

On Sun, 4 Jun 2000, Barry A. Warsaw wrote:
> >>>>> "JH" == Jeremy Hylton <jeremy@beopen.com> writes:
> 
>     JH> One of the problems I'm having is keeping track of which
>     JH> patches are still outstanding.
> 
> SF has a patch manager but I haven't played with it much.  In fact, I
> can't seem to find it for the Python project, but it's there in the
> Mailman project.

You can administratively turn those things on/off, I thought. You're an
admin, Barry, so you should be able to turn the thing on.

Cheers,
-g

p.s. and yah.. there are damn too many projects at SF that are just a
project name. no code, no description, all features enabled for no
purpose, etc... Newbie coders, me thinks. Python is Goodness because it
does disable the unused items.

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



From gstein@lyra.org  Mon Jun  5 00:30:08 2000
From: gstein@lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 16:30:08 -0700 (PDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total
 reference count in debug builds.)
Message-ID: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>

Given the New World Order, how does that impact the need for these release
statements and/or wet signatures?

Or a better way to put it, who "owns" Python now? Given a "who", then we
can ask that person/entity whether they want release statements.

Given that Python is now on SourceForge, and there are multiple people (at
CNRI and otherwise) that can directly make modifications, then the release
below is certainly a bit "off". For example, David Ascher has commit
privs, so at his "sole discretion, [he may] decide whether or not to
incorporiate this contribution..." :-)

Thoughts?

Cheers,
-g

p.s. IMO, I'd like to see Guido own the Copyright for all current and
future Python development

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

---------- Forwarded message ----------
Date: Mon, 5 Jun 2000 09:18:30 +1000
From: Mark Hammond <mhammond@skippinet.com.au>
To: patches@python.org
Subject: [Patches] New sys method to return total reference count in debug
    builds.

[... snip ...]

Release info:

I confirm that, to the best of my knowledge and belief, this contribution
is free of any claims of third parties under copyright, patent or other
rights or interests ("claims").  To the extent that I have any such claims,
I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide
license to reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part of the
Python software and its related documentation, or any derivative versions
thereof, at no cost to CNRI or its licensed users, and to authorize others
to do so.

I acknowledge that CNRI may, at its sole discretion, decide whether or not
to incorporate this contribution in the Python software and its related
documentation.  I further grant CNRI permission to use my name and other
identifying information provided to CNRI by me for use in connection with
the Python software and its related documentation.

Mark.


_______________________________________________
Patches mailing list
Patches@python.org
http://www.python.org/mailman/listinfo/patches



From bwarsaw@python.org  Mon Jun  5 04:09:36 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Sun, 4 Jun 2000 23:09:36 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <14650.49490.725648.798719@anthem.python.org>
 <Pine.LNX.4.10.10006041353020.29036-100000@nebula.lyra.org>
Message-ID: <14651.6640.709657.306682@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:

    GS> You can administratively turn those things on/off, I
    GS> thought. You're an admin, Barry, so you should be able to turn
    GS> the thing on.

I'm happy to if people think it will help.  SF's patch management is a
durn site better than Python's is now <wink>.  I'd also consider
shutting off Jitterbug on python.org but I'm not sure how to (or if we
should) migrate the current bug set to SF.

-Barry


From gstein@lyra.org  Mon Jun  5 07:13:39 2000
From: gstein@lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 23:13:39 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.6640.709657.306682@anthem.python.org>
Message-ID: <Pine.LNX.4.10.10006042311500.29036-100000@nebula.lyra.org>

On Sun, 4 Jun 2000 bwarsaw@python.org wrote:
> >>>>> "GS" == Greg Stein <gstein@lyra.org> writes:
> 
>     GS> You can administratively turn those things on/off, I
>     GS> thought. You're an admin, Barry, so you should be able to turn
>     GS> the thing on.
> 
> I'm happy to if people think it will help.  SF's patch management is a
> durn site better than Python's is now <wink>.  I'd also consider
> shutting off Jitterbug on python.org but I'm not sure how to (or if we
> should) migrate the current bug set to SF.

IMO, use the provided tools. The Patch Manager is more than we have now.
It also allows assignment, which can be nice :-)  (compared to the
arbitrary "who is taking care of this patch?" thing today)

The SF bug database certainly works, and it provides additional "locality"
for the code + bugs + patches.

Cheers,
-g

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



From jeremy@beopen.com  Mon Jun  5 05:43:45 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 00:43:45 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <3938D60E.391AAF31@lemburg.com>
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
 <3938D60E.391AAF31@lemburg.com>
Message-ID: <14651.12289.191631.704477@localhost.localdomain>

[Entry from AMK's 1.6 jobs list:]
> Conservative garbage collection of cycles (maybe -- I don't know what GvR
>         thinks about this)

I believe Guido would like to see a version of Neil's patches
integrated into Python 1.6, most likely turned off by default but with
a configure flag to enable.

I would like to check the patch in soon but I have had some trouble
with segfaults.  I ran a simple benchmark using the compiler code in
the nondist tree to compile itself.  I get a crash during a routine
collect pass, where it looks like the GC header info is getting
trashed.  I haven't had much time to track it any farther.

If anyone else is interested, I'd love to hear about successes using
the GC patch with other large programs.  I'd like to run at least
Gadfly and Grail successfully before committing the patch.

I wonder if "conservative" is the right word to describe the GC
approach?  I think conservative means that the garbage collector is
not told what is a pointer and what is not, so it must conservatively
assume that every bit pattern could represent a pointer.  The GC patch
is not conservative in this sense.  It does have a mechanism that is
"conservative" in a very broad sense, i.e. it does not attempt to
trace every reference, but depends on the ref count fields to account
for references held in untraced variables on the C stack.  I'm not
sure what the right terminology for this approach is.

I also worry that the performance impact of the GC patch is not at all
understood.  I don't know what informed the choice of heuristics for
deciding how often to collect and how to move objects between
generations.  (The current scheme has three generations.)  It would be
good to get a working patch in before the next alpha release and then
gather a lot of data to help make good choices about these parameters.

Jeremy

PS Even if Guido doesn't think the GC patch should go in, we've got a
golden opportunity.  I caught him in a state of newly-wedded bliss
this morning and convinced him to let me check in my non-optional
braces patch while he's on his honeymoon.  He's so happy he'll let us
get away with anything.

PPS I don't know if we should really carry on about personal matters
on a development list, but I hope no one minds if I indulge briefly:
Guido & Kim's wedding yesterday was beautiful and fun, held outside in
meadow looking out on hills and woods.  They are great couple and I'm
sure they'll be very happy.



From jeremy@beopen.com  Mon Jun  5 05:58:11 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 00:58:11 -0400 (EDT)
Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!)
In-Reply-To: <Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>
References: <Pine.LNX.4.10.10006020134050.17073-100000@nebula.lyra.org>
 <Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>
Message-ID: <14651.13155.253651.575394@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:

  GS> I found the problem. Sneaky...  sock.makefile() does a dup() on
  GS> the file descriptor, then opens a FILE* with that. See it coming
  GS> yet? ...

Bingo!  I was suspicious of all these dup'd file descriptors, but
missed the connection to a FILE* object.

  [In a previous message you wrote:]
  >> 
  >> Regarding the pipeline request thing. I think it would probably
  >> be best to just drop the whole "hold the previous response and
  >> wait for it to be closed" thing.
  [...]
  >> 
  >> Oh. Wait. Maybe that was it. You can't read the "next" response
  >> until the first one has been read. Well... no need to block
  >> putting new responses; we just need to create a way to "get the
  >> next reply" and/or "can I get the next reply yet?"
  >> 

Maybe I should clarify the concern I had here.  I think we're on the
same page, but I'm not sure.

The problem with pipelined requests is that the client must be sure to
read all of response I before it can call getreply to get response
I+1.  I imagine that it could add a lot of complexity to use code to
implement this requirement, e.g. when multiple threads are sharing a
single connection.  It would be good if the library could do something
reasonable about the multiplexing.  In the absence of making it just
work, the library could raise an error that makes clear what has gone
wrong -- that the client isn't using the interface properly.

Jeremy


From jeremy@beopen.com  Mon Jun  5 06:00:06 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 01:00:06 -0400 (EDT)
Subject: [Python-Dev] Re: Is it just Syntactic Sugar ?
In-Reply-To: <20000604005601.T469@xs4all.nl>
References: <k7lW4.96338$E85.1941352@news1.rdc1.md.home.com>
 <3929E47E.993727CF@roguewave.com>
 <3933F800.9CCE3B6D@cs.byu.edu>
 <20000530213957.E469@xs4all.nl>
 <mt4s7f7q62.fsf@astron.berkeley.edu>
 <m3u2ffydwy.fsf@atrus.jesus.cam.ac.uk>
 <mtog5n68ak.fsf@astron.berkeley.edu>
 <20000531090045.I469@xs4all.nl>
 <3935B383.469032AE@python.org>
 <20000604005601.T469@xs4all.nl>
Message-ID: <14651.13270.353056.246432@localhost.localdomain>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

  TW> On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum
  TW> wrote:
  >> I know I shouldn't be posting in this thread, and I won't be
  >> there to read the responses, but here's what I thought would be
  >> cool.

  >> x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means
  >> "and becomes" (an old Algol-68 naming convention; we could pick
  >> something better later but this will do for the explanation).

  [...]

  TW> This was what I had in mind, and was trying to explain. Does you
  TW> voicing your opinion mean someone (you ? someone else ?) is
  TW> working on this, or soon going to work on this ? 

I don't believe anyone at PythonLabs is working on this now, certainly
not Guido or I.

Jeremy


From jeremy@beopen.com  Mon Jun  5 05:53:32 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 00:53:32 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>
References: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
 <Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>
Message-ID: <14651.12876.575925.701737@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:

  GS> On Sat, 3 Jun 2000, Jeremy Hylton wrote:
  >> ...  Sorry for the excuses.  I think better tools would help a
  >> lot, but we'll have to get more people checkin privileges
  >> regardless.

  GS> There are several issues with expanded checkin privs:

  GS> 1) trust: will the person make sure it is Right And Proper to do
  GS> the checkin? (have they reviewed the code? is a a Good Change?
  GS> etc) The counter here is that we don't want people that will
  GS> simply take stuff arriving at patches@ and checking them in.

Many of the people who ultimately have checkin privileges should limit
themselves to their particular domains.  There are a bunch of modules
that are owned by other people, e.g. Eric's netrc module, your new
httplib, MAL for Unicode, etc.

We'll probably develop a second group of developers who have broader
privileges to make changes, but they'll know how they are.

Ultimately, I think I agree with Mark's suggestion that we be a little
more liberal with changes and risk backing out the occasional
changes.  (For some definition of "a little more" :-).

  GS> 2) more people reviewing changes on the -checkins mailing
  GS> list. Assuming that you want more than one pair of eyeballs
  GS> looking at patches/code, that more people with commit privs
  GS> increases the rate of commits, then you need more reviewers to
  GS> keep up (because the reviewers probably are not going to review
  GS> ALL checkins)

You're doing a great job so far.  We'll just have to get you to spend
more time on it <0.8 wink>.

  GS> 3) increasing dependence on -checkins means that patches MUST be
  GS> smaller chunks. they MUST be single-purpose patches. practically
  GS> nobody will review a 200k patch, or patches that fix N different
  GS> things at once. A small, focused patch is easily reviewed.

  GS>    For example: Trent has recently mailed a bunch of patches to
  GS> the patches list. This is Goodness: each one is focused and can
  GS> be individually reviewed. Since they are not a single, giant
  GS> blob, it also keeps them short and reviewable... each can have a
  GS> +1/-1 independent of the others.

I agree in principle, but there are times when it will make more sense
to commit a set of changes as one big patch.  The GC patches are going
to affect a bunch of files, but probably ought to be done as one big
commit. 

Jeremy


From jeremy@beopen.com  Mon Jun  5 06:03:46 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 01:03:46 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total
 reference count in debug builds.)
In-Reply-To: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
References: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
Message-ID: <14651.13490.858960.390030@localhost.localdomain>

Off the top of my head, I'd say that your questions aren't going to
get answered until Guido gets back and gets a chance to answer them.
In the interim, I think we should stick with the current approach.  In
the long run, of course, you won't need to grant CNRI permission to do
anything with a submission.

Jeremy


From nascheme@enme.ucalgary.ca  Mon Jun  5 07:35:00 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Mon, 5 Jun 2000 00:35:00 -0600
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.12289.191631.704477@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 12:43:45AM -0400
References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> <14651.12289.191631.704477@localhost.localdomain>
Message-ID: <20000605003500.B6169@acs.ucalgary.ca>

On Mon, Jun 05, 2000 at 12:43:45AM -0400, Jeremy Hylton wrote:
> [Entry from AMK's 1.6 jobs list:]
> > Conservative garbage collection of cycles (maybe -- I don't know what GvR
> >         thinks about this)
> 
> I believe Guido would like to see a version of Neil's patches
> integrated into Python 1.6, most likely turned off by default but with
> a configure flag to enable.

Okay, I was thinking he had passed it over for 1.6 since I didn't
hear any comments from him for a long time.

> I would like to check the patch in soon but I have had some trouble
> with segfaults.  I ran a simple benchmark using the compiler code in
> the nondist tree to compile itself.  I get a crash during a routine
> collect pass, where it looks like the GC header info is getting
> trashed.  I haven't had much time to track it any farther.

Yow.  I will try to see if I can reproduce this.  What platform?

> If anyone else is interested, I'd love to hear about successes using
> the GC patch with other large programs.  I'd like to run at least
> Gadfly and Grail successfully before committing the patch.

I've used it with Grail, Sketch, IDLE as well as some of my own
software.  I may have introduced that SEGV bug when porting the
patch to a newer version of the CVS sources.  I will check it
out.

> I also worry that the performance impact of the GC patch is not
> at all understood.

Me too.

> I don't know what informed the choice of heuristics for
> deciding how often to collect and how to move objects between
> generations. (The current scheme has three generations.) It
> would be good to get a working patch in before the next alpha
> release and then gather a lot of data to help make good choices
> about these parameters.

Getting good performance will be a matter of tuning how often the
collector runs.  I don't think there is any substitute for
running real programs and collecting data.  Programs that
allocate lots of objects will be most interesting.  It would
probably be a good idea to add more support for keeping
collection statistics.  Unfortunately my time is very limited
right now.

> PS Even if Guido doesn't think the GC patch should go in, we've got a
> golden opportunity.  I caught him in a state of newly-wedded bliss
> this morning and convinced him to let me check in my non-optional
> braces patch while he's on his honeymoon.  He's so happy he'll let us
> get away with anything.

I wonder if he will be scowling less at the conferences now that
he is hitched. :)

    Neil


From gstein@lyra.org  Mon Jun  5 07:42:35 2000
From: gstein@lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 23:42:35 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.12876.575925.701737@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.10006042329020.29036-100000@nebula.lyra.org>

On Mon, 5 Jun 2000, Jeremy Hylton wrote:
> >>>>> "GS" == Greg Stein <gstein@lyra.org> writes:
>...
>   GS> 1) trust: will the person make sure it is Right And Proper to do
>   GS> the checkin? (have they reviewed the code? is a a Good Change?
>   GS> etc) The counter here is that we don't want people that will
>   GS> simply take stuff arriving at patches@ and checking them in.
> 
> Many of the people who ultimately have checkin privileges should limit
> themselves to their particular domains.  There are a bunch of modules
> that are owned by other people, e.g. Eric's netrc module, your new
> httplib, MAL for Unicode, etc.

Agreed. Each person with commit privs will definitely need to operate
under the premise of "<this> is the area that I'm allowed to commit
changes for." For example, I believe that Guido made it very clear, at
some point in the past, that *nobody* but Guido will have commit access to
the Parser/ area.

Note that when I say "commit access" here, this is the same as "areas that
I can commit for." In fact, it is really just an extension of the Basic
Python Principle, "we're all adults here, don't do what you know you
shouldn't be doing." :-)

>...
> Ultimately, I think I agree with Mark's suggestion that we be a little
> more liberal with changes and risk backing out the occasional
> changes.  (For some definition of "a little more" :-).

This only works if you have reasonably assurance of review via the
-checkins alias. Otherwise, you simply need to accept that instabilities
will creep in. (and that broader alpha/beta/etc cycles may be desirable)

In the Apache group, we have a very good set of eyeballs watching the
checkins. I'd say that each checkin is reviewed by two or three people in
detail. Invariably, there are several checkins each week that result in a
thread discussing: (a) you broke it, (b) why was it done that way, (c)
couldn't it be done this way, (d) this appears to be missing, (e) etc.

IMO, for that to happen several (or more!) times every week means that we
have a good set of eyeballs. Maybe it also means the committers just suck
lollipops, but I'd like to think otherwise :-)

>   GS> 2) more people reviewing changes on the -checkins mailing
>   GS> list. Assuming that you want more than one pair of eyeballs
>   GS> looking at patches/code, that more people with commit privs
>   GS> increases the rate of commits, then you need more reviewers to
>   GS> keep up (because the reviewers probably are not going to review
>   GS> ALL checkins)
> 
> You're doing a great job so far.  We'll just have to get you to spend
> more time on it <0.8 wink>.

hehe...

well, I just completed a big-ass wave of mod_dav work. In fact, I don't
know what else to do to the thing. I made a snapshot and am waiting for
feedback, if any, before declaring it 1.0. Maybe I'll add some comments to
the code :-)

Anyways... that's why I've been working on httplib. Free time! :-)

>   GS> 3) increasing dependence on -checkins means that patches MUST be
>   GS> smaller chunks. they MUST be single-purpose patches. practically
>   GS> nobody will review a 200k patch, or patches that fix N different
>   GS> things at once. A small, focused patch is easily reviewed.
> 
>   GS>    For example: Trent has recently mailed a bunch of patches to
>   GS> the patches list. This is Goodness: each one is focused and can
>   GS> be individually reviewed. Since they are not a single, giant
>   GS> blob, it also keeps them short and reviewable... each can have a
>   GS> +1/-1 independent of the others.
> 
> I agree in principle, but there are times when it will make more sense
> to commit a set of changes as one big patch.  The GC patches are going
> to affect a bunch of files, but probably ought to be done as one big
> commit. 

Actually, I will disagree here. I've reviewed the GC patch a couple times.
There are a number of changes in there that can/should be done separately
from the "real" GC patch.

For example, there were a number of changes to use PyMem_Allco() instead
of PyMEM_Alloc(). Or whatever. Point being, that they had *nothing* to do
with GC -- they could be checked in *independent* of the actual GC work.
The changes to the PyTypeObject declaration (adding tp_clean) can also be
done without doing the "real work".

After these "zero impact" changes are completed, then the GC patch will be
greatly reduced in size and complexity. It makes it much more reviewable.

The point being: even big patches can usually be broken down into layers.
One layer after another, adding "platform" functionality until you get to
the meat of the matter. The GC patch was a definite case of this.

Really huge patches are okay if they have a *seriously* narrow focus. For
example, Skip's patch to use PyArg_ParseTuple() with the ":method" stuff.
That was pretty brain-dead to review. The hardest part was that the
context-diff wasn't contextual enough to verify that the name in the
ParseTuple matched the method that it occurred in.
[ I found a case where they did not match. not easy... ]

Cheers,
-g

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



From pf@artcom-gmbh.de  Mon Jun  5 08:28:38 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Mon, 5 Jun 2000 09:28:38 +0200 (MEST)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org> from Greg Stein at "Jun 2, 2000  2:32:52 pm"
Message-ID: <m12yrJO-000DifC@artcom0.artcom-gmbh.de>

Hi,

Greg Stein:
> He does have a point, but I think the wrong solution :-)
> 
> While the clock may be monotonically increasing on one system, it isn't
> always the case when things like NFS come into play.

That is a well known and common trap.  Don't use NFS for Software
development unless you've read and understood RFC 868. ;-)

BTW.: Last year someone posted a pure Python implementation of RFC 868
time server and clients to c.l.p.  This might be useful on those WinXX boxes.

> I recall a case back '95 when I was editing a .py over an NFS mount and
> running the code on the target machine. The clocks on the two boxes were
> off by about three seconds. I was going thru the edit/run/edit/run cycle
> so quickly, that at one point, I saved a .py file that was older than the
> associated .pyc file.
> 
> Needless to say, I was really confused that my recent edit didn't produce
> the desired result :-)

Sure. ;-)  But the same would have happenend, if you edited a .c source
file and if your target computer has C-compiler/linker, which is fast
enough to have a edit/compile/run cycle completed faster than the clock 
difference.  This is not uncommon today.

So the problem is not Python's fault and so I see no need to fix it there.
One thing could be added though: If Python 'stat's a .py file, which has
a time stamp in the future, it could issue a warning similar to that
displayed by 'make':
*** Warning: File `%s' has modification time in the future (%ld > %ld

Possibly this message could point the user to RFC 868 and the 'netdate' 
Unix command.  But that would be sugar on the cake.

Regards, Peter


From Moshe Zadka <moshez@math.huji.ac.il>  Mon Jun  5 11:21:32 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Mon, 5 Jun 2000 13:21:32 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <m12yrJO-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.GSO.4.10.10006051318060.12591-100000@sundial>

On Mon, 5 Jun 2000, Peter Funk wrote:

> Greg Stein:
> > He does have a point, but I think the wrong solution :-)
> > 
> > While the clock may be monotonically increasing on one system, it isn't
> > always the case when things like NFS come into play.
> 
> That is a well known and common trap.  Don't use NFS for Software
> development unless you've read and understood RFC 868. ;-)

"Make"'s philosphy for basing the decision on which files need to be
remade on the timestapmps is not necessarily the best -- but the user can
replace mkae if it doesn't "do the right thing".

Since Python takes on some of Make's roles (regenrating files only if
those need to be regenerated), it is subject to the same problems. So it
is Python's fault, and that's where the problem should be fixed.

--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From bwarsaw@python.org  Mon Jun  5 14:21:05 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Mon, 5 Jun 2000 09:21:05 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <14651.6640.709657.306682@anthem.python.org>
 <Pine.LNX.4.10.10006042311500.29036-100000@nebula.lyra.org>
Message-ID: <14651.43329.783797.949349@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:

    GS> IMO, use the provided tools. The Patch Manager is more than we
    GS> have now.  It also allows assignment, which can be nice :-)
    GS> (compared to the arbitrary "who is taking care of this patch?"
    GS> thing today)

    GS> The SF bug database certainly works, and it provides
    GS> additional "locality" for the code + bugs + patches.

I've turned on the SF patch manager and bug database.

-Barry


From bwarsaw@python.org  Mon Jun  5 14:32:54 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:32:54 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
 <Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>
 <14651.12876.575925.701737@localhost.localdomain>
Message-ID: <14651.44038.828370.123514@anthem.python.org>

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

    JH> Many of the people who ultimately have checkin privileges
    JH> should limit themselves to their particular domains.  There
    JH> are a bunch of modules that are owned by other people,
    JH> e.g. Eric's netrc module, your new httplib, MAL for Unicode,
    JH> etc.

Right.  I think GregS was the one advocating a more Apache-like model,
where people have the ability to check into the whole tree, but
generally don't or risk the derision of their peers.  Python's big
enough for people to assert their expertise over various corners.

    JH> Ultimately, I think I agree with Mark's suggestion that we be
    JH> a little more liberal with changes and risk backing out the
    JH> occasional changes.  (For some definition of "a little more"
    JH> :-).

It all depends on the scope of the changes.  If it's fairly localized
to a single library module, then we don't worry as much.  More
important there will be the API design.  If it's a more sweeping
change like GC or Unicode, or a change in the language definition,
then there /has/ to be broader support.

For Big Changes, I really like the RFC idea someone suggested.  Gets
everything documented for newbies and posterity.  Has a shelf life,
etc.

-Barry


From bwarsaw@python.org  Mon Jun  5 14:36:28 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:36:28 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <14651.12876.575925.701737@localhost.localdomain>
 <Pine.LNX.4.10.10006042329020.29036-100000@nebula.lyra.org>
Message-ID: <14651.44252.78362.195436@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:

    GS> In the Apache group, we have a very good set of eyeballs
    GS> watching the checkins. I'd say that each checkin is reviewed
    GS> by two or three people in detail. Invariably, there are
    GS> several checkins each week that result in a thread discussing:
    GS> (a) you broke it, (b) why was it done that way, (c) couldn't
    GS> it be done this way, (d) this appears to be missing, (e) etc.

Maybe we also need to expand on the test suite, do nightly builds, and
post the results.  Kind of the way Mozilla does it.  Well, Python
probably doesn't change so radically every night, but a more expanded
test suite with web based feedback would be cool.

-Barry


From bwarsaw@python.org  Mon Jun  5 14:38:20 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:38:20 -0400 (EDT)
Subject: [Python-Dev] Re: Is it just Syntactic Sugar ?
References: <k7lW4.96338$E85.1941352@news1.rdc1.md.home.com>
 <3929E47E.993727CF@roguewave.com>
 <3933F800.9CCE3B6D@cs.byu.edu>
 <20000530213957.E469@xs4all.nl>
 <mt4s7f7q62.fsf@astron.berkeley.edu>
 <m3u2ffydwy.fsf@atrus.jesus.cam.ac.uk>
 <mtog5n68ak.fsf@astron.berkeley.edu>
 <20000531090045.I469@xs4all.nl>
 <3935B383.469032AE@python.org>
 <20000604005601.T469@xs4all.nl>
 <14651.13270.353056.246432@localhost.localdomain>
Message-ID: <14651.44364.408119.422821@anthem.python.org>

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

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> This was what I had in mind, and was trying to explain. Does
    TW> you voicing your opinion mean someone (you ? someone else ?)
    TW> is working on this, or soon going to work on this ?

    JH> I don't believe anyone at PythonLabs is working on this now,
    JH> certainly not Guido or I.

I'm not tracking this either.
-Barry


From bwarsaw@python.org  Mon Jun  5 14:41:39 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:41:39 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total
 reference count in debug builds.)
References: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
Message-ID: <14651.44563.556790.469651@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:

    GS> Given the New World Order, how does that impact the need for
    GS> these release statements and/or wet signatures?

    GS> Or a better way to put it, who "owns" Python now? Given a
    GS> "who", then we can ask that person/entity whether they want
    GS> release statements.

    GS> Given that Python is now on SourceForge, and there are
    GS> multiple people (at CNRI and otherwise) that can directly make
    GS> modifications, then the release below is certainly a bit
    GS> "off". For example, David Ascher has commit privs, so at his
    GS> "sole discretion, [he may] decide whether or not to
    GS> incorporiate this contribution..." :-)

I talked to Guido briefly about this.  Since 1.6 is the last "CNRI
release", he wants to continue along the current path for the time
being.  I'm sure he'll be just as happy to chuck all this crap as
Greg, and we probably will for 1.7.

-Barry


From fdrake@beopen.com  Mon Jun  5 17:40:26 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 5 Jun 2000 12:40:26 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14648.35974.486959.379543@anthem.python.org>
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
 <14648.35974.486959.379543@anthem.python.org>
Message-ID: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com>

Barry A. Warsaw writes:
 > Did we ever decide on building in thread support by default?  I'd
 > really like to see threads enabled by default in 1.6 and I /think/
 > it'll just take some autoconf hacking, which I'm willing to do.  Are
 > there any objections to building in threads support by default if
 > autoconf detects threads?

  test_fork1 fails on Linux with threads on SMP machines.  (It's
irrelevant without threads.)  This is a hard failure -- the process
can either SEGV or hang forever.
  Is this a showstopper?  SMP boxes are becoming increasingly common
both as servers and workstations.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From bwarsaw@python.org  Mon Jun  5 17:55:49 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Mon, 5 Jun 2000 12:55:49 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
 <14648.35974.486959.379543@anthem.python.org>
 <14651.55290.728256.183107@cj42289-a.reston1.va.home.com>
Message-ID: <14651.56213.661929.481476@anthem.python.org>

>>>>> "Fred" == Fred L Drake, Jr <fdrake@beopen.com> writes:

    Fred>   test_fork1 fails on Linux with threads on SMP machines.
    Fred> (It's irrelevant without threads.)  This is a hard failure
    Fred> -- the process can either SEGV or hang forever.  Is this a
    Fred> showstopper?

I would think so, regardless of whether threads are built-in by
default or not.


From fdrake@beopen.com  Mon Jun  5 18:59:31 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 5 Jun 2000 13:59:31 -0400 (EDT)
Subject: [Python-Dev] What's New (first draft)
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBIEFCCMAA.mhammond@skippinet.com.au>
References: <20000602231550.A986@newcnri.cnri.reston.va.us>
 <ECEPKNMJLHAPFFJHDOJBIEFCCMAA.mhammond@skippinet.com.au>
Message-ID: <14651.60035.502321.510452@cj42289-a.reston1.va.home.com>

Mark Hammond writes:
 > Bill Tutt and I could do with a credit for the new winreg module.

  The documentation for winreg could stand to be written as well --
care to extract the docstrings, or is that in my court?  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From DavidA@ActiveState.com  Mon Jun  5 20:26:13 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Mon, 5 Jun 2000 12:26:13 -0700
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJCEIKCGAA.DavidA@ActiveState.com>

>   test_fork1 fails on Linux with threads on SMP machines.  (It's
> irrelevant without threads.)  This is a hard failure -- the process
> can either SEGV or hang forever.
>   Is this a showstopper?  SMP boxes are becoming increasingly common
> both as servers and workstations.

Why does the test fail?  I'd hate to see the thousands (nay, hundreds of
thousands) of users complain that foo isn't working just because the test
for a rarely used feature on a rare platform is broken.

--david



From nascheme@enme.ucalgary.ca  Mon Jun  5 22:03:13 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Mon, 5 Jun 2000 15:03:13 -0600
Subject: [Python-Dev] Re: Revised 1.6 jobs list
Message-ID: <20000605150313.A15917@acs.ucalgary.ca>

[David Ascher]
>> test_fork1 fails on Linux with threads on SMP machines. (It's
>> irrelevant without threads.) This is a hard failure -- the
>> process can either SEGV or hang forever. Is this a showstopper?
>> SMP boxes are becoming increasingly common both as servers and
>> workstations.
>
> Why does the test fail? I'd hate to see the thousands (nay,
> hundreds of thousands) of users complain that foo isn't working
> just because the test for a rarely used feature on a rare
> platform is broken.

Threads and fork() don't seem to mix on Linux.  Even on a
UP machine things seem strange:

    http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=613477888&fmt=text

I tried to reproduce the problem with a C program but could not.
When things hang the forking thread is stuck in wait4() while the
child process is suspended:

    #0  0x4027d9ba in sigsuspend () from /lib/libc.so.6
    #1  0x40232c77 in __pthread_wait_for_restart_signal ()
       from /lib/libpthread.so.0
    #2  0x4023406e in __pthread_lock () from /lib/libpthread.so.0
    #3  0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0
    #4  0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at
    thread_pthread.h:339
    #5  0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64,
    locals=0x0, 
        args=0x81be278, argcount=0, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, 
        owner=0x0) at ceval.c:630
    #6  0x805ac19 in call_function (func=0x81ebb2c, arg=0x81be26c,
    kw=0x0)
        at ceval.c:2552
    #7  0x805a5a4 in PyEval_CallObjectWithKeywords (func=0x81ebb2c,
    arg=0x81be26c, 
        kw=0x0) at ceval.c:2390
    #8  0x80b2c7b in t_bootstrap (boot_raw=0x81ebb50) at
    ./threadmodule.c:224
    #9  0x40230c8f in pthread_start_thread () from
    /lib/libpthread.so.0

I don't know if this is a LinuxThread problem or a Python
problem.

    Neil

-- 
The internet: Learn what you know.  Share what you don't.


From DavidA@ActiveState.com  Mon Jun  5 22:23:11 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Mon, 5 Jun 2000 14:23:11 -0700
Subject: [Python-Dev] RE: Revised 1.6 jobs list
In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca>
Message-ID: <PLEJJNOHDIGGLDPOGPJJKEJACGAA.DavidA@ActiveState.com>

> Threads and fork() don't seem to mix on Linux.  Even on a
> UP machine things seem strange:

I believe it.  My general point however is that even if the problem can't be
fixed because Linux is broken in some way, the test suite should be fixed
even if it means to ignore failures of test_fork1 if the system was
configured --with-thread.

--david



From mhammond@skippinet.com.au  Tue Jun  6 00:47:44 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Tue, 6 Jun 2000 09:47:44 +1000
Subject: [Python-Dev] Re: Revised 1.6 jobs list
In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEHJCMAA.mhammond@skippinet.com.au>

> I tried to reproduce the problem with a C program but could not.
> When things hang the forking thread is stuck in wait4() while the
> child process is suspended:

This looks very suspect.

>
>     #0  0x4027d9ba in sigsuspend () from /lib/libc.so.6
>     #1  0x40232c77 in __pthread_wait_for_restart_signal ()
>        from /lib/libpthread.so.0
>     #2  0x4023406e in __pthread_lock () from /lib/libpthread.so.0
>     #3  0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0
>     #4  0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at
>     thread_pthread.h:339
>     #5  0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64,

And very much like the Python thread-state is not being managed correctly
with fork.  From my understanding of fork (which is small), and of the
Python thread-state management, this doesnt surprise me.

Given the stack trace, it appears that Python is doing its periodic
thread-release as part of running around the main loop.

In the process of _releasing_ the thread-lock, it needs to _acquire_ a
mutex.  I dont know the Python threading on pthreads at all - would this be
correct (it would seem likely that such an implementation would be done).

But in the process of acquiring that mutex, we call

__pthread_wait_for_restart_signal()

Is it possible that is is something as simple as thread-idents changing
underneath Python when using fork?  It seems to me that the thread thinks
it is either new, or stale?

Just my 2c worth - and given my knowledge of Linux and pthreads, plus the
state of our dollar at the moment, it has better be AUD $0.02 :-)

Mark.




From trentm@activestate.com  Tue Jun  6 01:14:03 2000
From: trentm@activestate.com (Trent Mick)
Date: Mon, 5 Jun 2000 17:14:03 -0700
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer?
In-Reply-To: <Pine.GSO.4.10.10006030833470.14749-100000@sundial>
References: <20000602111417.A17233@activestate.com> <Pine.GSO.4.10.10006030833470.14749-100000@sundial>
Message-ID: <20000605171403.A21808@activestate.com>

On Sat, Jun 03, 2000 at 10:56:15AM +0300, Moshe Zadka wrote:
> On Fri, 2 Jun 2000, Trent Mick wrote:
> 
> > 3. - change PyMarshal_WriteLongToFile to raise an exception if the long
> > 	 overflows a 32-bit range
> 
> +1 on that, finally non-portable integers will cause an exception.
> 

Okay, I have to reiterate and ask again because I have the suspicion that I
may be missing the point and you all may not realize that. Stop me when I go
astray:

- the PyMarshal interface is used for all the .pyc content writing
- PyMarshal_WriteLongToFile is only used for writing the magic number and the
  time stamp
- the rest of the .pyc is written via PyMarshal_WriteObjectToFile


- PyMarshal_WriteLongToFile will currently silently truncate a 64-bit long to
  32-bits
- PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will
  *NOT* truncate the 64-bit integer but will write the whole thing

- On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr
  when a 64-bit integral value is read and the current platform is 32-bit.


The question is: Do we want PyMarshal_WriteLongToFile *AND*
PyMarshal_WriteObjectToFile to raise an exception when a long value overflows
32-bits? Up til now I was only proposing the former.


Trent

-- 
Trent Mick
trentm@activestate.com


From esr@thyrsus.com  Tue Jun  6 02:02:31 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Mon, 5 Jun 2000 21:02:31 -0400
Subject: [Python-Dev] ascii.py
Message-ID: <20000605210231.A25895@thyrsus.com>

--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii

Latest version.  Adds isctrl() and ismeta() functions (because I use them...)

Um.  What's the checkin procedure for library modules?  And do I have
permissions to do it?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"Guard with jealous attention the public liberty.  Suspect every one
who approaches that jewel.  Unfortunately, nothing will preserve it
but downright force.  Whenever you give up that force, you are
inevitably ruined."
	-- Patrick Henry, speech of June 5 1788

--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ascii.py"

#
# ascii.py -- constants and memembership tests for ASCII characters
#

NUL	= 0x00	# ^@
SOH	= 0x01	# ^A
STX	= 0x02	# ^B
ETX	= 0x03	# ^C
EOT	= 0x04	# ^D
ENQ	= 0x05	# ^E
ACK	= 0x06	# ^F
BEL	= 0x07	# ^G
BS	= 0x08	# ^H
TAB	= 0x09	# ^I
HT	= 0x09	# ^I
LF	= 0x0a	# ^J
NL	= 0x0a	# ^J
VT	= 0x0b	# ^K
FF	= 0x0c	# ^L
CR	= 0x0d	# ^M
SO	= 0x0e	# ^N
SI	= 0x0f	# ^O
DLE	= 0x10	# ^P
DC1	= 0x11	# ^Q
DC2	= 0x12	# ^R
DC3	= 0x13	# ^S
DC4	= 0x14	# ^T
NAK	= 0x15	# ^U
SYN	= 0x16	# ^V
ETB	= 0x17	# ^W
CAN	= 0x18	# ^X
EM	= 0x19	# ^Y
SUB	= 0x1a	# ^Z
ESC	= 0x1b	# ^[
FS	= 0x1c	# ^\
GS	= 0x1d	# ^]
RS	= 0x1e	# ^^
US	= 0x1f	# ^_
SP	= 0x20	# space
DEL	= 0x7f	# delete

controlnames = [
"NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL",
"BS",  "HT",  "LF",  "VT",  "FF",  "CR",  "SO",  "SI",
"DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB",
"CAN", "EM",  "SUB", "ESC", "FS",  "GS",  "RS",  "US",
"SP"
]

def _ctoi(c):
    if type(c) == type(""):
        return ord(c)
    else:
        return c

def isalnum(c): return isalpha(c) or isdigit(c)
def isalpha(c): return isupper(c) or islower(c)
def isascii(c): return _ctoi(c) <= 127		# ?
def isblank(c): return _ctoi(c) in (8,32)
def iscntrl(c): return _ctoi(c) <= 31
def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57
def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126
def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122
def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126
def ispunct(c): return _ctoi(c) != 32 and not isalnum(c)
def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11)
def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90
def isxdigit(c): return isdigit(c) or \
    (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102)
def isctrl(c): return _ctoi(c) < 32
def ismeta(c): return _ctoi(c) > 127

def ascii(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x7f)
    else:
        return _ctoi(c) & 0x7f

def ctrl(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x1f)
    else:
        return _ctoi(c) & 0x1f

def alt(c):
    if type(c) == type(""):
        return chr(_ctoi(c) | 0x80)
    else:
        return _ctoi(c) | 0x80

def unctrl(c):
    bits = _ctoi(c)
    if bits == 0x7f:
        rep = "^?"
    elif bits & 0x20:
        rep = chr((bits & 0x7f) | 0x20)
    else:
        rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20)
    if bits & 0x80:
        return "!" + rep
    return rep


--82I3+IH0IqGh5yIs
Content-Type: application/x-tex
Content-Disposition: attachment; filename="libascii.tex"

\section{\module{ascii} ---
         Constants and set-membership functions for ASCII characters.}

\declaremodule{standard}{ascii}
\modulesynopsis{Constants and set-membership functions for ASCII characters.}
\moduleauthor{Eric S. Raymond}{esr@thyrsus.com}
\sectionauthor{Eric S. Raymond}{esr@thyrsus.com}

\versionadded{1.6}

The \module{ascii} module supplies name constants for ASCII characters
and functions to test membership in various ASCII character classes.  
The constants supplied are names for control characters as follows:

NUL, SOH, STX, ETX, EOT, ENQ, ACK, BEL, BS, TAB, HT, LF, NL, VT, FF, CR,
SO, SI, DLE, DC1, DC2, DC3, DC4, NAK, SYN, ETB, CAN, EM, SUB, ESC, FS, 
GS, RS, US, SP, DEL.

NL and LF are synonyms; so are HT and TAB.  The module also supplies
the following functions, patterned on those in the standard C library:

\begin{funcdesc}{isalnum}{c}
Checks for an ASCII alphanumeric character; it is equivalent to
isalpha(c) or isdigit(c))
\end{funcdesc}

\begin{funcdesc}{isalpha}{c}
Checks for an ASCII alphabetic character; it is equivalent to
isupper(c) or islower(c))
\end{funcdesc}

\begin{funcdesc}{isascii}{c}
Checks for a character value that fits in the 7-bit ASCII set.
\end{funcdesc}

\begin{funcdesc}{isblank}{c}
Checks for an ASCII alphanumeric character; it is equivalent to
isalpha(c) or isdigit(c))
\end{funcdesc}

\begin{funcdesc}{iscntrl}{c}
Checks for an ASCII control character (range 0x00 to 0x1f).
\end{funcdesc}

\begin{funcdesc}{isdigit}{c}
Checks for an ASCII decimal digit, 0 through 9.
\end{funcdesc}

\begin{funcdesc}{isgraph}{c}
Checks for ASCII any printable character except space.
\end{funcdesc}

\begin{funcdesc}{islower}{c}
Checks for an ASCII lower-case character.
\end{funcdesc}

\begin{funcdesc}{isprint}{c}
Checks for any ASCII printable character including space.
\end{funcdesc}

\begin{funcdesc}{ispunct}{c}
Checks for any printable ASCII character which is not a space or an
alphanumeric character.
\end{funcdesc}

\begin{funcdesc}{isspace}{c}
Checks for ASCII white-space characters; space, tab, line feed,
carriage return, form feed, horizontal tab, vertical tab.
\end{funcdesc}

\begin{funcdesc}{isupper}{c}
Checks for an ASCII uppercase letter.
\end{funcdesc}

\begin{funcdesc}{isxdigit}{c}
Checks for an ASCII hexadecimal digit, i.e. one of 0123456789abcdefABCDEF.
\end{funcdesc}

\begin{funcdesc}{isctrl}{c}
Checks for an ASCII control character, bit values 0 to 31.
\end{funcdesc}

\begin{funcdesc}{ismeta}{c}
Checks for a (non-ASCII) character, bit values 0x80 and above.
\end{funcdesc}

These functions accept either integers or strings; when the argument
is a string, it is first converted using the built-in function ord().

Note that all these functions check ordinal bit values derived from the 
first character of the string you pass in; they do not actually know
anything about the host machine's character encoding.  For functions 
that know about the character encoding (and handle
internationalization properly) see the string module.

The following two functions take either a single-character string or
integer byte value; they return a value of the same type.

\begin{funcdesc}{ascii}{c}
Return the ASCII value corresponding to the low 7 bits of c.
\end{funcdesc}

\begin{funcdesc}{ctrl}{c}
Return the control character corresponding to the given character
(the character bit value is logical-anded with 0x1f).
\end{funcdesc}

\begin{funcdesc}{alt}{c}
Return the 8-bit character corresponding to the given ASCII character
(the character bit value is logical-ored with 0x80).
\end{funcdesc}

The following function takes either a single-character string or
integer byte value; it returns a string.

\begin{funcdesc}{unctrl}{c}
Return a string representation of the ASCII character c.  If c is
printable, this string is the character itself.  If the character
is a control character (0x00-0x1f) the string consists of a caret
(^) followed by the corresponding uppercase letter.  If the character
is an ASCII delete (0x7f) the string is "^?".  If the character has
its meta bit (0x80) set, the meta bit is stripped, the preceding rules
applied, and "!" prepended to the result.
\end{funcdesc}

Finally, the module supplies a 33-element string array 
called controlnames that contains the ASCII mnemonics for the
thirty-two ASCII control characters from 0 (NUL) to 0x1f (US),
in order, plus the mnemonic "SP" for space.

 

--82I3+IH0IqGh5yIs--


From gstein@lyra.org  Tue Jun  6 02:10:17 2000
From: gstein@lyra.org (Greg Stein)
Date: Mon, 5 Jun 2000 18:10:17 -0700 (PDT)
Subject: [Python-Dev] ascii.py
In-Reply-To: <20000605210231.A25895@thyrsus.com>
Message-ID: <Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>

On Mon, 5 Jun 2000, Eric S. Raymond wrote:
> Latest version.  Adds isctrl() and ismeta() functions (because I use them...)
> 
> Um.  What's the checkin procedure for library modules?

Guido has to give his blessing -- that he finds this useful and
appropriate for the Python library. He does that using his own criteria
and feedback from people here.

For example, I'm "+0" on it. (meaning that it seems okay, but I can also
live without it)

The actual mechanics are outlined at SourceForge:

  http://sourceforge.net/cvs/?group_id=5470


> And do I have permissions to do it?

Nope.

There are ten people with checkin privs:
  http://sourceforge.net/project/memberlist.php?group_id=5470

Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They use
<whatever> policy to determine whether a given person should become a SF
project member. That policy is probably just a gut feeling rather than
concrete rules, so I can't say "X, Y, and Z." I also don't know what kinds
of policies that they are asserting on people with privs.

Cheers,
-g

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



From jeremy@beopen.com  Tue Jun  6 02:23:40 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 21:23:40 -0400 (EDT)
Subject: [Python-Dev] ascii.py
In-Reply-To: <Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>
References: <20000605210231.A25895@thyrsus.com>
 <Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>
Message-ID: <14652.21148.139774.192634@localhost.localdomain>

Greg seems to understand this process better than the admins -- or at
least he can explain it quickly and clearly :-).  I apologize for the
rather confused state of affairs.  We'll clean up the process and
document it soon.

>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:
  GS> On Mon, 5 Jun 2000, Eric S. Raymond wrote:
  >> Latest version.  Adds isctrl() and ismeta() functions (because I
  >> use them...)
  >> 
  >> Um.  What's the checkin procedure for library modules?

  GS> Guido has to give his blessing -- that he finds this useful and
  GS> appropriate for the Python library. He does that using his own
  GS> criteria and feedback from people here.

I think I can safely speak for the admins when I say that we're not
sure what the process is other than securing Guido's blessing.  We
need to work out a clearer policy, but that will have to wait until
Guido gets back from his honeymoon.  Any new checkins we are making
are limited for the most part to modules we've already gotten his
blessing for.

There won't be another alpha release until he returns, so it's not
like we have to worry about getting new code in before a code freeze.

  GS> For example, I'm "+0" on it. (meaning that it seems okay, but I
  GS> can also live without it)

I'm in the same boat.  

  GS> There are ten people with checkin privs:
  GS> http://sourceforge.net/project/memberlist.php?group_id=5470

  GS> Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They
  GS> use <whatever> policy to determine whether a given person should
  GS> become a SF project member. That policy is probably just a gut
  GS> feeling rather than concrete rules, so I can't say "X, Y, and
  GS> Z." I also don't know what kinds of policies that they are
  GS> asserting on people with privs.

Another policy that needs to be defined.  "<whatever>" is surprisingly
close to what we actually have written down in our policies and
procedures manual.  I expect we will arrive at a policy where people
own pieces of the library and are free to maintain it.  Guido will
probably retain control over what modules come and go.

-- Jeremy Hylton <http://www.python.org/~jeremy/>



From esr@thyrsus.com  Tue Jun  6 02:33:24 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Mon, 5 Jun 2000 21:33:24 -0400
Subject: [Python-Dev] ascii.py
In-Reply-To: <14652.21148.139774.192634@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 09:23:40PM -0400
References: <20000605210231.A25895@thyrsus.com> <Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org> <14652.21148.139774.192634@localhost.localdomain>
Message-ID: <20000605213324.A26055@thyrsus.com>

Jeremy Hylton <jeremy@beopen.com>:
> Another policy that needs to be defined.  "<whatever>" is surprisingly
> close to what we actually have written down in our policies and
> procedures manual.  I expect we will arrive at a policy where people
> own pieces of the library and are free to maintain it.  Guido will
> probably retain control over what modules come and go.

Pretty much as I expected.  OK.  Let us know when things settle out
a little.  
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Before a standing army can rule, the people must be disarmed, as they
are in almost every kingdom in Europe. The supreme power in America
cannot enforce unjust laws by the sword, because the people are armed,
and constitute a force superior to any band of regular troops.
	-- Noah Webster


From tim_one@email.msn.com  Tue Jun  6 03:09:22 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Mon, 5 Jun 2000 22:09:22 -0400
Subject: Augmented assignment (was RE: [Python-Dev] Re: Is it just Syntactic Sugar ?)
In-Reply-To: <20000604005601.T469@xs4all.nl>
Message-ID: <001601bfcf5c$3bcb8e00$0ca0143f@tim>

[posted & mailed]

[Thomas Wouters, asking about Guido's sketch]
> This was what I had in mind, and was trying to explain. Does you
> voicing your opinion mean someone (you ? someone else ?) is working
> on this, or soon going to work on this ?

It's the same scheme he sketched the last time he was provoked into writing
about this <wink>, and that was at least a year ago.

> ...
> I'm curious what should happen with index-assignment and
> slice-assignment:

Nothing special!  You're reading far too much into Guido's sketch -- it
doesn't have all these convolutions.  Try reading his msg again, but this
time thinking like him too <wink>.

> x[y] += z

temp1 = x  # perhaps the first three are permuted, though
temp2 = y
temp3 = z
temp1[temp2] = temp1[temp2].__add_ab__(temp3)

And, yes, indexing is done twice (although "x" and "y" are evaluated only
once each).

> x[:y] += z

temp1 = x
temp2 = y
temp3 = z
temp1[:temp2] = temp1[:temp2].__add_ab__(temp3)

Similarly slicing is done twice.

> (Obviously this wont make sense for a lot of types, or will be too
> un-obvious to include, but I can imagine matrix-types to happily
> add this.)

Every type is free to implement __add_ab__ or not, in whatever way it likes.
But Python can't tell at compile-time which types do and don't implement it,
so chances are great that doing

   x += y

for x of a type that does not implement __add_ab__ will raise a runtime
AttributeError.

> Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0,
> y, z) ?

No.  *All* instances of "+=" are mapped straightforwardly to __add_ab__.
Context is irrelevent; indexing and slicing are not special cases (except to
the extent that they are already ...).

> Or would x[y] += z always call x[y].__add_item_ab__()

No.

> and x[:y] create a new object, a slice of x

What x[:y] means is entirely up to the type of x, and has no connection to
augmented assignment (except in that the author of the type may design both
to work smoothly together).

> and call its __add_ab__() method ?

__add_ab__ would be invoked on whatever x[:y] returns; whether that's "a new
object" or not is x.__get_slice__'s choice to make.

> Or would it try all of them, or more, until it gets a good result ?

No.  It works or it doesn't.

> Or am I running ahead of things and should we wait for a working
> patch first ? :)

No, you're running a few years behind things <wink>, and imagining
complications Guido would never sign up for.

and-now-the-spirits-must-rest-ly y'rs  - tim




From bwarsaw@python.org  Tue Jun  6 03:27:42 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 22:27:42 -0400 (EDT)
Subject: [Python-Dev] ascii.py
References: <20000605210231.A25895@thyrsus.com>
 <Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>
 <14652.21148.139774.192634@localhost.localdomain>
Message-ID: <14652.24990.563016.976820@anthem.python.org>

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

    JH> I think I can safely speak for the admins when I say that
    JH> we're not sure what the process is other than securing Guido's
    JH> blessing.  We need to work out a clearer policy, but that will
    JH> have to wait until Guido gets back from his honeymoon.  Any
    JH> new checkins we are making are limited for the most part to
    JH> modules we've already gotten his blessing for.

My suggestion would be to upload to the SourceForge patch manager, any
patches or code you care about that you don't want us to lose track
of.  Things get buried in my inbox pretty easily, but at least with
the patch manager, we've got a record of it, and can eventually assign
a developer to tracking it.

-Barry


From trentm@activestate.com  Tue Jun  6 03:52:44 2000
From: trentm@activestate.com (Trent Mick)
Date: Mon, 5 Jun 2000 19:52:44 -0700
Subject: [Python-Dev] about patches on SourceForge
Message-ID: <20000605195244.A25437@activestate.com>

I just put up one my patches from this past week on SOurceForge. Question:
WWould you all prefer to have the "raw patch" just include the actually
patch/diff and for the first comment to be the patch description (and legal
stuff?) or would you prefer for the patch description and legal stuff to be
part of the "raw patch".

I am inclined to think that the former would be preferable. Is there some
"apply patch" button in SourceForge that would require the "raw patch" to
actually be raw?

Go check it out and you will know what I am talking about.

http://sourceforge.net/patch/?func=browse&group_id=5470&set=open


When I get an good opinion from some of you I will send up my other patches.




Trent

-- 
Trent Mick
trentm@activestate.com


From gstein@lyra.org  Tue Jun  6 04:32:27 2000
From: gstein@lyra.org (Greg Stein)
Date: Mon, 5 Jun 2000 20:32:27 -0700 (PDT)
Subject: [Python-Dev] Re: httplib
In-Reply-To: <14651.13155.253651.575394@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.10006052025390.14292-100000@nebula.lyra.org>

On Mon, 5 Jun 2000, Jeremy Hylton wrote:
> >>>>> "GS" == Greg Stein <gstein@lyra.org> writes:
>...
>   >> Oh. Wait. Maybe that was it. You can't read the "next" response
>   >> until the first one has been read. Well... no need to block
>   >> putting new responses; we just need to create a way to "get the
>   >> next reply" and/or "can I get the next reply yet?"
> 
> Maybe I should clarify the concern I had here.  I think we're on the
> same page, but I'm not sure.
> 
> The problem with pipelined requests is that the client must be sure to
> read all of response I before it can call getreply to get response
> I+1.

Actually, you can issue a getreply() after you've read the prior
response's headers, but before you completely read its body. Once you have
the header, then you know whether the connection will remain open or not.
Assuming it *will* remain open, then you can go ahead and do a
request/reply sequence. If the connection is going to close, then you have
to fail at request time.

> I imagine that it could add a lot of complexity to use code to
> implement this requirement, e.g. when multiple threads are sharing a
> single connection.  It would be good if the library could do something
> reasonable about the multiplexing.  In the absence of making it just
> work, the library could raise an error that makes clear what has gone
> wrong -- that the client isn't using the interface properly.

I'm working through this stuff right now. It is a bit tricky to get it
right *and* have it clear. I'm concentrating on the latter as much as
possible.

At the moment, HTTPResponse instances can be created without problems. I'm
locating the "can you issue a request [and get a response]" logic in the
connection object itself.

Another detail that I'm trying to work through is where the connection is
allowed to get the HTTPResponse to read the HTTP header. Reading off the
network could block, so we need to be a bit more careful about what
methods can block (if any).

In any case, the current httplib (at www.lyra.org/greg/python/) has got
just about everything. The next checkin will deal with this pipelining
issue.


QUESTION #2: I *really* want to get rid of the HTTPS() class. It is
introducing excessive complexity, with the only purpose being
compatibility against the post-1.5.2 CVS.

Anyone? Thoughts on removal?


Cheers,
-g

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



From mhammond@skippinet.com.au  Tue Jun  6 04:43:15 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Tue, 6 Jun 2000 13:43:15 +1000
Subject: [Python-Dev] about patches on SourceForge
In-Reply-To: <20000605195244.A25437@activestate.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au>

> When I get an good opinion from some of you I will send up my
> other patches.

How do you qualify a "good" opinion?  One that matches yours? <wink>

This is all too hard until Guido gets back.  But personally I believe the
raw patch should be just the CVS diff output, and the comments should
reflect all other text, including the release notice while it is still
necessary.

I hope my opinion is good enough :-)

Mark.



From jeremy@beopen.com  Tue Jun  6 04:46:01 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 23:46:01 -0400 (EDT)
Subject: [Python-Dev] Re: httplib
In-Reply-To: <Pine.LNX.4.10.10006052025390.14292-100000@nebula.lyra.org>
References: <14651.13155.253651.575394@localhost.localdomain>
 <Pine.LNX.4.10.10006052025390.14292-100000@nebula.lyra.org>
Message-ID: <14652.29689.663218.777234@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:

  GS> QUESTION #2: I *really* want to get rid of the HTTPS() class. It
  GS> is introducing excessive complexity, with the only purpose being
  GS> compatibility against the post-1.5.2 CVS.

  GS> Anyone? Thoughts on removal?

I've got two answers.  I don't particularly like the old-style HTTP
interface, so I'm happy to see it replaced with a better one.  I say
who cares about HTTPS. 

On the other hand, there is a lot of existing code that uses the old
interface.  It would be good if that code could be modified to use the
new SSL interface without having to also re-write the code to use the
new http interface.  Perhaps we should keep it to provide a future
upgrade path for all the legacy code.  

I could probably be convinced that the amount of effort to change from
the old interface to the new interface is fairly small.  If you're
going to make one change to the code anyway, might as well start using
the modern interface, too.

Is there anyone who actually has http code to maintain that has an
opinion? 

Jeremy


From fdrake@beopen.com  Tue Jun  6 04:45:54 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 5 Jun 2000 23:45:54 -0400 (EDT)
Subject: [Python-Dev] about patches on SourceForge
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au>
References: <20000605195244.A25437@activestate.com>
 <ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au>
Message-ID: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com>

Mark Hammond writes:
 > This is all too hard until Guido gets back.  But personally I believe the
 > raw patch should be just the CVS diff output, and the comments should
 > reflect all other text, including the release notice while it is still
 > necessary.

  Sounds good to me.  Let's do it this way until there's a god reason
to do it differently.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From pf@artcom-gmbh.de  Tue Jun  6 10:05:58 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Tue, 6 Jun 2000 11:05:58 +0200 (MEST)
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer?
In-Reply-To: <20000605171403.A21808@activestate.com> from Trent Mick at "Jun 5, 2000  5:14: 3 pm"
Message-ID: <m12zFJ8-000DifC@artcom0.artcom-gmbh.de>

Hi,

[Trent Mick]:
[...]
> - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will
>   *NOT* truncate the 64-bit integer but will write the whole thing
> 
> - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr
>   when a 64-bit integral value is read and the current platform is 32-bit.
[...]
> The question is: Do we want PyMarshal_WriteLongToFile *AND*
> PyMarshal_WriteObjectToFile to raise an exception when a long value overflows
> 32-bits? Up til now I was only proposing the former.

Yes.  This should at least be the default behaviour of Python.

The current behaviour would otherwise cause great damage in the
following scenario, where an innocent software developer working on
a 64-Bit system trusts on the cross platform portability of Pythons
bytecode files and unintentional uses a huge integer literal.

If some people really don't care about portability, there could be 
switch/option/pragma/whatever to disable this behaviour.

IMO the portability of Python bytecode files is a *very* valuable property,
which we shouldn't give up on.

Regards, Peter


From gstein@lyra.org  Tue Jun  6 10:58:44 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 6 Jun 2000 02:58:44 -0700 (PDT)
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit
 integer?
In-Reply-To: <m12zFJ8-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.LNX.4.10.10006060257010.14292-100000@nebula.lyra.org>

On Tue, 6 Jun 2000, Peter Funk wrote:
> [Trent Mick]:
> [...]
> > - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will
> >   *NOT* truncate the 64-bit integer but will write the whole thing
> > 
> > - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr
> >   when a 64-bit integral value is read and the current platform is 32-bit.
> [...]
> > The question is: Do we want PyMarshal_WriteLongToFile *AND*
> > PyMarshal_WriteObjectToFile to raise an exception when a long value overflows
> > 32-bits? Up til now I was only proposing the former.
> 
> Yes.  This should at least be the default behaviour of Python.
> 
> The current behaviour would otherwise cause great damage in the
> following scenario, where an innocent software developer working on
> a 64-Bit system trusts on the cross platform portability of Pythons
> bytecode files and unintentional uses a huge integer literal.
> 
> If some people really don't care about portability, there could be 
> switch/option/pragma/whatever to disable this behaviour.
> 
> IMO the portability of Python bytecode files is a *very* valuable property,
> which we shouldn't give up on.

It isn't only bytecodes. As I mentioned before, marshal byte streams are
specified as portable. Therefore, they are used all the time for passing
over the network, for persistence mechanisms, etc.

Having a marshal stream that is *not* cross-platform is just plain busted.

So... you can silently truncate to 32-bits or you can raise an exception.
You cannot, however, marshal a 64-bit value when the definition of an
"marshal integer" is only 32.

Cheers,
-g

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



From gvwilson@nevex.com  Tue Jun  6 15:40:25 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Tue, 6 Jun 2000 10:40:25 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
Message-ID: <Pine.LNX.4.10.10006061035250.29478-100000@akbar.nevex.com>

Hi, everyone.  We're a month away from final submissions in the Software
Carpentry design competition, which means we're two months away from
announcing winners and starting implementation effort, and we're wondering
whether there are generally-accepted coding standards, naming conventions,
or other guidelines that we should adopt.  If so, URLs would be welcome...

Also, it appears that there are two implementations of the xUnit testing
framework in Python:

Steve Purcell: http://sourceforge.net/project/?group_id=3912
Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip

We'd be grateful for comments on either.

Thanks,
Greg Wilson
Software Carpentry Project Coordinator




From klm@digicool.com  Tue Jun  6 17:16:58 2000
From: klm@digicool.com (Ken Manheimer)
Date: Tue, 6 Jun 2000 12:16:58 -0400 (EDT)
Subject: [Python-Dev] Guido and Kim married
Message-ID: <14653.9210.757666.324583@korak.digicool.com>

Guido van Rossum and Kim Knapp were married Saturday afternoon on the
lawn of a graceful southern estate, Claymont Court, in West Virginia,
USA.  The weather was *stunningly* fine - a great boon, considering
the rain the night before (a torrential downpour in nearby DC) - and
the couple left for their honeymoon sunday.  Hooray!

The crowd consisted of i would guess 70 to 100 people, a mixture of
hollanders (including several van rossum relatives - hiya Just!),
knapps, pythoners, contact improvisors, economists, martial artists,
and sundry other friends and family.

I leave to others to quibble about whether or not this qualifies as a
"python development".  (I probably made enough of a fool of myself at
the wedding, with pronouncements of good will and dancing and such,
that i can't do any more harm...-)

Yay!

Ken
klm@digicool.com


From tim_one@email.msn.com  Tue Jun  6 18:20:49 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 6 Jun 2000 13:20:49 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.LNX.4.10.10006061035250.29478-100000@akbar.nevex.com>
Message-ID: <001001bfcfdb$8f64d240$48a2143f@tim>

[Greg Wilson]
> Hi, everyone.  We're a month away from final submissions in the
> Software Carpentry design competition, which means we're two months
> away from announcing winners and starting implementation effort,

Yay!  This is a wonderful competition, and if nobody yet has bothered to
thank you for spearheading it, let me know & I'll find someone who will
<wink>.

> and we're wondering whether there are generally-accepted coding
> standards, naming conventions, or other guidelines that we should
> adopt.  If so, URLs would be welcome...

When you can't fight about where to put curly braces, there's not much left
to argue.  The only serious attempt at a Python style guide I've seen is
Guido's:

    http://www.python.org/doc/essays/styleguide.html

Two from there large numbers of people will still argue about, but to no
avail:

+ No hard tabs.  Indents are 4 spaces, period.

+ Keep lines strictly less than 80 characters wide (I happen to keep them
under 77, to allow for one level of "> " mail quoting).

These rules ensure that code is readable as intended across all platforms.

> Also, it appears that there are two implementations of the xUnit
> testing framework in Python:
>
> Steve Purcell: http://sourceforge.net/project/?group_id=3912
> Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip
>
> We'd be grateful for comments on either.

Sorry, unfamiliar with these.




From pingster@ilm.com  Tue Jun  6 18:25:57 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Tue, 6 Jun 2000 10:25:57 -0700 (PDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <Pine.SGI.3.96.1000606102423.30600j-100000@happy>

On Tue, 6 Jun 2000, Tim Peters wrote:
> 
> Yay!  This is a wonderful competition, and if nobody yet has bothered to
> thank you for spearheading it, let me know & I'll find someone who will
> <wink>.

Yeah, what he said. :)

> The only serious attempt at a Python style guide I've seen is Guido's:
> 
>     http://www.python.org/doc/essays/styleguide.html

I love this style guide.  I know it's a strange reaction to
have to a style guide, but i agree with basically everything
in it, which is probably pretty rare for these sorts of things.

> + No hard tabs.  Indents are 4 spaces, period.

Tab characters are the work of the devil.


-- ?!ng

"China is a big country, inhabited by many Chinese."
    -- Former French President Charles de Gaulle



From gvwilson@nevex.com  Tue Jun  6 18:31:32 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Tue, 6 Jun 2000 13:31:32 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <Pine.LNX.4.10.10006061328070.32393-100000@akbar.nevex.com>

> Tim Peters wrote:
> When you can't fight about where to put curly braces, there's not much
> left to argue.  The only serious attempt at a Python style guide I've
> seen is Guido's:
>     http://www.python.org/doc/essays/styleguide.html

Yes, I've seen this.  I was wondering (a) whether it's up to date (i.e.
whether common practice has moved on), and (b) whether there is now a
consensus about module structure --- we're expecting several packages that
will be shared between tools, plus multiple modules within tools.  I've
been tracking the occasional message about re-organizing the standard
Python library, and would like whatever we do to be in line with wherever
Python itself is going.

Thanks,
Greg




From esr@thyrsus.com  Tue Jun  6 18:47:13 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Tue, 6 Jun 2000 13:47:13 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.SGI.3.96.1000606102423.30600j-100000@happy>; from pingster@ilm.com on Tue, Jun 06, 2000 at 10:25:57AM -0700
References: <001001bfcfdb$8f64d240$48a2143f@tim> <Pine.SGI.3.96.1000606102423.30600j-100000@happy>
Message-ID: <20000606134713.A29204@thyrsus.com>

Ka-Ping Yee <pingster@ilm.com>:
> > The only serious attempt at a Python style guide I've seen is Guido's:
> > 
> >     http://www.python.org/doc/essays/styleguide.html
> 
> I love this style guide.  I know it's a strange reaction to
> have to a style guide, but i agree with basically everything
> in it, which is probably pretty rare for these sorts of things.

Likewise.  I never read this before, but it's spooky how closely the
style I evolved myself tracks it.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

If a thousand men were not to pay their tax-bills this year, that would
... [be] the definition of a peaceable revolution, if any such is possible.
	-- Henry David Thoreau


From petrilli@amber.org  Tue Jun  6 18:52:50 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Tue, 6 Jun 2000 13:52:50 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>; from tim_one@email.msn.com on Tue, Jun 06, 2000 at 01:20:49PM -0400
References: <Pine.LNX.4.10.10006061035250.29478-100000@akbar.nevex.com> <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <20000606135250.A25856@trump.amber.org>

Tim Peters [tim_one@email.msn.com] wrote:

> When you can't fight about where to put curly braces, there's not much left
> to argue.  The only serious attempt at a Python style guide I've seen is
> Guido's:
> 
>     http://www.python.org/doc/essays/styleguide.html

The only thing that might be added (I haven't looked in a while, but
didn't see it last time I did), is some naming convention issues.  I
follow pretty standard Smalltalk guidelines:

       - No '_', use camelCase for seps

       - Capitalize all Classes, and also global variables

       - Lowercase for all methods (i.e. setNewBreakpoint)

This is just me, and obviously not everyone does this :-)

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From gvwilson@nevex.com  Tue Jun  6 18:50:38 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Tue, 6 Jun 2000 13:50:38 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <20000606135250.A25856@trump.amber.org>
Message-ID: <Pine.LNX.4.10.10006061347510.32673-100000@akbar.nevex.com>

> > Tim Peters:
> > http://www.python.org/doc/essays/styleguide.html

> On Tue, 6 Jun 2000, Christopher Petrilli wrote:
> The only thing that might be added (I haven't looked in a while, but
> didn't see it last time I did), is some naming convention issues.  I
> follow pretty standard Smalltalk guidelines:
> 
>        - No '_', use camelCase for seps

I know this is become common practice, but I've been told by two different
HCI specialists that studies have shown CamelBackNotation to be harder for
non-native speakers to read than underbar_separated_text, particularly
when acronyms are part of the name.  If anyone has a pointer to an
original reference for this, I'd be grateful.

Thanks,
Greg




From klm@digicool.com  Tue Jun  6 19:32:12 2000
From: klm@digicool.com (Ken Manheimer)
Date: Tue, 6 Jun 2000 14:32:12 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.SGI.3.96.1000606102423.30600j-100000@happy>
Message-ID: <Pine.LNX.4.21.0006061431040.675-100000@korak.digicool.com>

On Tue, 6 Jun 2000, Ka-Ping Yee wrote:

> > The only serious attempt at a Python style guide I've seen is Guido's:
> > 
> >     http://www.python.org/doc/essays/styleguide.html
> 
> I love this style guide.  I know it's a strange reaction to
> have to a style guide, but i agree with basically everything
> in it, which is probably pretty rare for these sorts of things.

Me too!  (Or three, or four by now...)

Ken
klm@digicool.com



From tim_one@email.msn.com  Tue Jun  6 19:36:26 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 6 Jun 2000 14:36:26 -0400
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bitinteger?
In-Reply-To: <Pine.LNX.4.10.10006060257010.14292-100000@nebula.lyra.org>
Message-ID: <001201bfcfe6$1fe51dc0$48a2143f@tim>

[GregS]
> It isn't only bytecodes. As I mentioned before, marshal byte streams are
> specified as portable. Therefore, they are used all the time for passing
> over the network, for persistence mechanisms, etc.
>
> Having a marshal stream that is *not* cross-platform is just plain busted.
>
> So... you can silently truncate to 32-bits or you can raise an exception.

But in either of those cases it's not cross-platform == it's just plain
busted.

> You cannot, however, marshal a 64-bit value when the definition of an
> "marshal integer" is only 32.

The current code is insane.  Long-term the visible distinction between
(Python) ints and longs should vanish.  Short-term the PyInt_Check case of
w_object should see whether the int fits in 4 bytes, and if so write it as a
C long, and if not write the thing as a Python long (that's the only way to
keep the marshal portable!).  Any code keying off the SIZEOF_LONG symbol is
highly suspect, piling another layer of "convenient but wrong" assumptions
on top of the current layer.  Code in marshal should *never* try to exploit
that C longs happen to be bigger than 4 bytes on the current platform.
PyMarshal_WriteLongToFile should be changed to raise an exception if passed
something that doesn't fit in 4 bytes, and should be declared obsolete.  The
Python core should be changed now never to call PyMarshal_WriteLongToFile
(in answer to Trent's original question, the intent of that code can't be
distinguished from what it does, which is to blindly write exactly 4 bytes
no matter what).

Most of this crap is in support of a bad assumption about mtimes, and,
sorry, but it sure looks to me like the .pyc header format is "just plain
busted" too.  Let's bite the bullet and fix the header -- then all the rest
of this will be clearly seen as the broken hackery it really is.




From trentm@activestate.com  Tue Jun  6 19:57:52 2000
From: trentm@activestate.com (Trent Mick)
Date: Tue, 6 Jun 2000 11:57:52 -0700
Subject: [Python-Dev] about patches on SourceForge
In-Reply-To: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com>
References: <20000605195244.A25437@activestate.com> <ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au> <14652.29682.819341.881773@cj42289-a.reston1.va.home.com>
Message-ID: <20000606115752.D28943@activestate.com>

On Mon, Jun 05, 2000 at 11:45:54PM -0400, Fred L. Drake, Jr. wrote:
> 
> Mark Hammond writes:
>  > This is all too hard until Guido gets back.  But personally I believe the
>  > raw patch should be just the CVS diff output, and the comments should
>  > reflect all other text, including the release notice while it is still
>  > necessary.
> 
>   Sounds good to me.  Let's do it this way until there's a god reason
                                                             ^^^
> to do it differently.
> 

I think maybe that you meant 'good', but I am not so sure. ;-)

Trent


-- 
Trent Mick
trentm@activestate.com


From gmcm@hypernet.com  Tue Jun  6 19:59:49 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Tue, 6 Jun 2000 14:59:49 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.LNX.4.10.10006061328070.32393-100000@akbar.nevex.com>
References: <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <1251804473-5567942@hypernet.com>

Greg Wilson wrote:

> > Tim Peters wrote:
[Guido's style guide]

> Yes, I've seen this.  I was wondering 
> ... whether
> there is now a consensus about module structure ...

No, there's not. And if you ask me, (which you didn't) there's 
some very bad precedents getting set in the misguided pursuit 
of "ease of use".

Time to call out the PSU before things get out of hand...


- Gordon


From gstein@lyra.org  Tue Jun  6 20:04:25 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 6 Jun 2000 12:04:25 -0700 (PDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.LNX.4.10.10006061347510.32673-100000@akbar.nevex.com>
Message-ID: <Pine.LNX.4.10.10006061201340.14292-100000@nebula.lyra.org>

On Tue, 6 Jun 2000, Greg Wilson wrote:
> > > Tim Peters:
> > > http://www.python.org/doc/essays/styleguide.html
> 
> > On Tue, 6 Jun 2000, Christopher Petrilli wrote:
> > The only thing that might be added (I haven't looked in a while, but
> > didn't see it last time I did), is some naming convention issues.  I
> > follow pretty standard Smalltalk guidelines:
> > 
> >        - No '_', use camelCase for seps
> 
> I know this is become common practice, but I've been told by two different
> HCI specialists that studies have shown CamelBackNotation to be harder for
> non-native speakers to read than underbar_separated_text, particularly
> when acronyms are part of the name.  If anyone has a pointer to an
> original reference for this, I'd be grateful.

Actually, the "camel case" for identifiers is not a standard Python style.
I've seen three forms:

- no separator or case usage (e.g. getattr())
- mixed case
- lower case with underscores

Chris' other points: upper-case-initial classes and lower-case-initial
methods are *definitely* standard.

Globals are a bit different. I don't think it is standard to capitalize
them as Chris mentioned (they might look like classes in that case). There
isn't much of a standard there.

Definitely another point is the use of "_" for the initial character to
signify "private -- don't touch"

Cheers,
-g

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





From gstein@lyra.org  Tue Jun  6 20:29:56 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 6 Jun 2000 12:29:56 -0700 (PDT)
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errors
 in signalmodule.c and bufferobject.c)
In-Reply-To: <001c01bfcfea$b73a2040$48a2143f@tim>
Message-ID: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org>

On Tue, 6 Jun 2000, Tim Peters wrote:
>...
> [on K&R style declarations failing to act as prototypes]
> > ...
> > Give the man a prize. That was it. We'll just forget that part of the
> > patch then and thank you Tim for changing all function declarations
> > from K&R to ANSI. :)
> 
> Believe it or not, I do intend to do that, although I expect resistance from
> Guido <0.5 wink>.  Python's infrastructure is creaking from age, and an
> update to ANSI C is l-o-n-g overdue.  It appears to me that a very large
> part of your "Win64" efforts have amounted to fighting long-obsolete K&R C
> assumptions!

Euh... I thought Guido was entirely supportive of ANSI-fying the source.
Something like changing from K&R functions over to ANSI declarations is
"brain-dead" that should not introduce errors.

Going through and revamping the protoypes (e.g. PyString_FromStringAndSize
to now use size_t) is a bit different, though...

I shouldn't think Guido would be upset about prototypes.

Cheers,
-g

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



From Fredrik Lundh" <effbot@telia.com  Tue Jun  6 21:23:19 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Tue, 6 Jun 2000 22:23:19 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org>
Message-ID: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid>

greg wrote:
> Euh... I thought Guido was entirely supportive of ANSI-fying the =
source.

note that 1.6 won't build on non-ANSI platforms; lots of new
stuff, including the unicode type, the builtin exceptions, and
SRE are pure ANSI.

(btw, what are all those "register" declarations doing in MAL's
version of unicodeobject.c?  does any modern compiler even
care about that keyword?)

</F>



From tim_one@email.msn.com  Tue Jun  6 22:00:33 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 6 Jun 2000 17:00:33 -0400
Subject: [Python-Dev] RE: ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c)
In-Reply-To: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org>
Message-ID: <001f01bfcffa$41ed2f20$48a2143f@tim>

[Greg Stein]
> Euh... I thought Guido was entirely supportive of ANSI-fying the source.
> Something like changing from K&R functions over to ANSI declarations is
> "brain-dead" that should not introduce errors. ...

He'll be less & less in favor of it when it hits home how time-consuming and
massive the changes will be.  They won't be viewed as "a feature" to BeOpen,
so BeOpen will give him grief about it too.  Etc.  I've fought the same
stinking infrastructure battles for 20+ years, and don't expect that having
a new boss will make any material difference to that <0.7 wink>.  Testing is
expensive, robustness is expensive, portability is expensive (and C doesn't
help!  honest to God, it's much worse than Fortran for portability).

> Going through and revamping the protoypes (e.g. PyString_FromStringAndSize
> to now use size_t) is a bit different, though...
>
> I shouldn't think Guido would be upset about prototypes.

Nobody should get upset about *having* them, it's getting them done that
takes away from getting everything else done.  That's why every project I've
ever seen puts it off year after year.  Note that if Guido valued this
*highly*, it would already have been done.

been-there-done-that-been-there-done-that-been-there-done-that-ly y'rs  -
tim




From jack@oratrix.nl  Tue Jun  6 22:14:10 2000
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 06 Jun 2000 23:14:10 +0200
Subject: [Python-Dev] Trying again:  [Patches] Patch to import.c
Message-ID: <20000606211416.10B6ED8397@oratrix.oratrix.nl>

--boogadaboogadabooga
Content-Type: text/plain; charset="us-ascii"

Folks,
I posted this message to the patches mailing list last week, but
either I missed the reply (we had full disks over the weekend) or
nobody replied yet. And I am waiting for these patches, or rather
other people who want to play with MacPython and MacOSX are, so I'd
really like to know whether I should revise the patches and in what
direction or have them checked in....

Hmm, that may all sound a bit pushy, but that isn't the intention. I
really just want to know (a) what the status of my patches is and (b)
what I can expect in the future....

	Jack
--boogadaboogadabooga
Content-Type: message/rfc822

From jack@oratrix.nl  Sat Jun  3 13: 06:03 2000
Delivered-To:  jack@oratrix.nl
Received:  by oratrix.oratrix.nl (Postfix, from userid 201)
	  	id 63987D7210; Sat,  3 Jun 2000 13:06:02 +0200 (MET DST)
Received:  from localhost (localhost [127.0.0.1])
	  	by oratrix.oratrix.nl (Postfix) with ESMTP
	  	id 3EED619B1E9A; Sat,  3 Jun 2000 13:05:57 +0200 (MET DST)
To:  patches@python.org
Cc:  jack@oratrix.nl
Subject:  Re: [Patches] Patch to import.c 
In-Reply-To:  Message by Greg Stein <gstein@lyra.org> ,
	     	     Sat, 3 Jun 2000 03:26:25 -0700 (PDT) , <Pine.LNX.4.10.1000
6030325330.29036-100000@nebula.lyra.org> 
Organisation:  Oratrix Development, Valeriusplein 30, 1075 BJ Amsterdam, NL
Phone:  +31 20 6795452(work), +31 20 6795309 (fax), +31 20 6160335(home)
X-Last-Band-Seen:  Stiff Little Fingers (Melkweg, 4-5)
X-Mini-Review:  Absolutely brilliant!!!
Date:  Sat, 03 Jun 2000 13:05:57 +0200
From:  Jack Jansen <jack@oratrix.nl>
Return-Path:  <jack@oratrix.nl>
Message-Id:  <20000603110602.63987D7210@oratrix.oratrix.nl>

I'm a bit confused as to the current procedure for patches. It used to 
be that Guido said "yes" or "no", and that was it. Nowadays there seem 
to be very many people on the patches mailing list, and a patch gets a 
number of replies ranging from "don't do this" to "can't you do this
differently". I've tried to reply to all the issues, but I'm now completely
in the dark as to the status of my patches: I'm under the impression
that I've defended the case for my patches satisfactorily (hehe:-),
but people on the patch mailing list may think that I've some fixing
up to do.

As I didn't follow discussions on the new patch system: is there a
procedure and, if so, could it be documented on python.org/patches?
And if there isn't one: could one be designed and documented, please?

A time-limit on patch acceptance/rejection would also be nice, if
possible: I use the repository to sync my home machine and work
machine, which worked fine when Guido alone was responsible as he
worked what seems to be 19 hours per day, so patches usually ended up
in the repository before I had the chance to cycle from home to work
or vv., but with the new procedure it can apparently take a lot longer 
for patches to appear, so I may have to come up with another scheme to 
sync my multiple machines...
--
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 


--boogadaboogadabooga--


From mal@lemburg.com  Tue Jun  6 23:53:02 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Jun 2000 00:53:02 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit
 warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org> <01b101bfcff5$1000faa0$f2a6b5d4@hagrid>
Message-ID: <393D80CE.D6C387AA@lemburg.com>

Fredrik Lundh wrote:
> 
> note that 1.6 won't build on non-ANSI platforms; lots of new
> stuff, including the unicode type, the builtin exceptions, and
> SRE are pure ANSI.
> 
> (btw, what are all those "register" declarations doing in MAL's
> version of unicodeobject.c?  does any modern compiler even
> care about that keyword?)

"register" helps compilers in situations where normal
optimizations don't give satisfying results, e.g. to aid
in keeping often used variables or counters in registers
rather than on the stack. It can also help with inling
functions and can speed up parameter passing.

GCC is one such modern compiler that does care, not sure
about MSVC++. IBM's OS/2 compilers did (last time
I looked some 5 years ago ;).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From pf@artcom-gmbh.de  Tue Jun  6 23:47:41 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 00:47:41 +0200 (MEST)
Subject: Style guide (was Re: [Python-Dev] req: Software Carpentry / coding standards)
In-Reply-To: <Pine.LNX.4.10.10006061347510.32673-100000@akbar.nevex.com> from Greg Wilson at "Jun 6, 2000  1:50:38 pm"
Message-ID: <m12zS8L-000DifC@artcom0.artcom-gmbh.de>

Hi,

Greg Wilson:
> > > Tim Peters:
> > > http://www.python.org/doc/essays/styleguide.html
> 
> > On Tue, 6 Jun 2000, Christopher Petrilli wrote:
> > The only thing that might be added (I haven't looked in a while, but
> > didn't see it last time I did), is some naming convention issues.  I
> > follow pretty standard Smalltalk guidelines:
> > 
> >        - No '_', use camelCase for seps
> 
> I know this is become common practice, but I've been told by two different
> HCI specialists that studies have shown CamelBackNotation to be harder for
> non-native speakers to read than underbar_separated_text, particularly
> when acronyms are part of the name.  If anyone has a pointer to an
> original reference for this, I'd be grateful.

This would be indeed very interesting.  

But my own experiences support this POV:

This naming style issue is similar in Python and one of its early
anchestors Modula-2.

In 1985 we started our company programming in Modula-2.  At that
time we decided to code conforming to the original Modula-2 language
definition as published by N.Wirth in March, 1980:  underscores were 
not allowed in identifiers!  German: '_' verboten! ;-)

The software is in use until today and several of our employees still
have to use Modula-2 for maintainance.  The code base is currently
about 1 Mio. LOC.

We tried to use english identifiers, although all programmers are 
native german speakers.

We too adopted a style using first char lowercase or uppercase to
distinguish identifier classes (modules and procedure names uppercase
and all other identifiers lowercase) and later we ran into the
problems described above.

A few years ago we allowed the use of '_' in identifiers, because
the compiler support was available.  This has improved the situation
somewhat.  All our programmers like the possibility to occasionally
use '_' in identifiers, especially if idents contain acronyms.

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)


From pf@artcom-gmbh.de  Wed Jun  7 10:34:12 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 11:34:12 +0200 (MEST)
Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5)
In-Reply-To: <200006070911.CAA17368@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000  2:11:43 am"
Message-ID: <m12zcE0-000DifC@artcom0.artcom-gmbh.de>

Hi,

Marc-Andre Lemburg:
[...]
> Added a new locale name aliasing engine which also supports
> locale encodings, a feature which is used by the new default
> encoding support in site.py.
> 
> Index: locale.py
[...]
> + ### C lib locale APIs
> + 
> + from _locale import *

Wouldn't it be clever to provide some dummy stubs on those platforms, where 
the _locale module was not enabled?  

try:
    from _locale import *
except:
    def setlocale(....
    def localeconv(....
    ...

Especially the MacOS 1.5.2 release provided by Jack Jansen was
compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
is still disabled per default in 'Modules/Setup.in'.  I didn't had
a look into the current CVS though, so this may have changed.

I think the name aliasing tables might be also useful on those
systems lacking locale support in their C-library.

Regards, Peter


From pf@artcom-gmbh.de  Wed Jun  7 10:40:17 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 11:40:17 +0200 (MEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules Setup.in,1.100,1.101
In-Reply-To: <200006070912.CAA17814@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000  2:12:56 am"
Message-ID: <m12zcJt-000DifC@artcom0.artcom-gmbh.de>

Uoooppps....
I was just too fast with my previous email about _locale emulation.

Marc-Andre Lemburg:
> *** Setup.in	2000/05/26 19:02:42	1.100
> --- Setup.in	2000/06/07 09:12:54	1.101
> ***************
> *** 141,145 ****
>                           # static Unicode character database
>   
> ! #_locale _localemodule.c  # access to ISO C locale support
>   
>   
> --- 141,145 ----
>                           # static Unicode character database
>   
> ! _locale _localemodule.c  # access to ISO C locale support
>   

Is this likely to work on the Mac with C-libraries coming with
Metrowerks CodeWarrior?  Jack?

Regards, Peter


From fredrik@pythonware.com  Wed Jun  7 11:24:46 2000
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 7 Jun 2000 12:24:46 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org> <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com>
Message-ID: <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com>

MAL wrote:
> > (btw, what are all those "register" declarations doing in MAL's
> > version of unicodeobject.c?  does any modern compiler even
> > care about that keyword?)
>=20
> "register" helps compilers in situations where normal
> optimizations don't give satisfying results, e.g. to aid
> in keeping often used variables or counters in registers
> rather than on the stack. It can also help with inling
> functions and can speed up parameter passing.

Yeah, I know what register is supposed to do.

But common knowledge (at least where I live) is that modern optimizers
know better than you, and usually ignore "register" altogether if you =
use
higher optimization levels... (and if they don't, using "register" is =
likely to
make things worse on some platforms).  In other words, "register" should
not be used in portable code.

fwiw, a certain Linux kernel hacker seem to agree with me on that one:

    http://www2.linuxjournal.com/lj-issues/issue17/1138.html
    ...
    #define register
    ...
    "Gcc, the normal Linux C compiler, understands the register keyword,
    but the code optimiser is sufficiently good that using register is =
normally
    a bad idea."
    ...

(If it's good enough for Alan Cox etc).

But never mind.  I doubt that removing them would matter on any con-
temporary platform, but on the other hand, keeping them in there won't
hurt much either.  It just makes the source code a little bit more ver-
bose than it has to be...

</F>



From mal@lemburg.com  Wed Jun  7 11:25:08 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Jun 2000 12:25:08 +0200
Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS:
 python/dist/src/Lib locale.py,1.4,1.5)
References: <m12zcE0-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <393E2304.4BE8CDE0@lemburg.com>

Peter Funk wrote:
> 
> Hi,
> 
> Marc-Andre Lemburg:
> [...]
> > Added a new locale name aliasing engine which also supports
> > locale encodings, a feature which is used by the new default
> > encoding support in site.py.
> >
> > Index: locale.py
> [...]
> > + ### C lib locale APIs
> > +
> > + from _locale import *
> 
> Wouldn't it be clever to provide some dummy stubs on those platforms, where
> the _locale module was not enabled?
> 
> try:
>     from _locale import *
> except:
>     def setlocale(....
>     def localeconv(....
>     ...
> 
> Especially the MacOS 1.5.2 release provided by Jack Jansen was
> compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
> is still disabled per default in 'Modules/Setup.in'.  I didn't had
> a look into the current CVS though, so this may have changed.
> 
> I think the name aliasing tables might be also useful on those
> systems lacking locale support in their C-library.

setlocale and localeconv are ANSI C and Python requires an ANSI C
compiler, so there should be no problem (at least in theory).

If there is a problem, adding the missing symbols would
be no problem: the APIs could always report locale 'C'
and its numeric settings.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From mal@lemburg.com  Wed Jun  7 11:40:24 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Jun 2000 12:40:24 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit
 warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org> <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com> <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com>
Message-ID: <393E2698.D2DFFC91@lemburg.com>

Fredrik Lundh wrote:
> 
> MAL wrote:
> > > (btw, what are all those "register" declarations doing in MAL's
> > > version of unicodeobject.c?  does any modern compiler even
> > > care about that keyword?)
> >
> > "register" helps compilers in situations where normal
> > optimizations don't give satisfying results, e.g. to aid
> > in keeping often used variables or counters in registers
> > rather than on the stack. It can also help with inling
> > functions and can speed up parameter passing.
> 
> Yeah, I know what register is supposed to do.

I know you know, but I find adding some explanations for others
which might not know is good practice.
 
> But common knowledge (at least where I live) is that modern optimizers
> know better than you, and usually ignore "register" altogether if you use
> higher optimization levels... (and if they don't, using "register" is likely to
> make things worse on some platforms).  In other words, "register" should
> not be used in portable code.
> 
> fwiw, a certain Linux kernel hacker seem to agree with me on that one:
> 
>     http://www2.linuxjournal.com/lj-issues/issue17/1138.html
>     ...
>     #define register
>     ...
>     "Gcc, the normal Linux C compiler, understands the register keyword,
>     but the code optimiser is sufficiently good that using register is normally
>     a bad idea."
>     ...

Well, make that "normally not needed": gcc sometimes doesn't inline
functions because it thinks that the function needs parameters to be
on the stack. The register keyword can do wonders here.

Adding "register" is like adding salt & pepper: things usually
taste better than before ;-).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From gward@mems-exchange.org  Wed Jun  7 14:19:06 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 09:19:06 -0400
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <200006021503.RAA26314@pandora>; from loewis@informatik.hu-berlin.de on Fri, Jun 02, 2000 at 05:03:50PM +0200
References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org> <200006021503.RAA26314@pandora>
Message-ID: <20000607091906.A5559@ludwig.cnri.reston.va.us>

On 02 June 2000, Martin von Loewis said:
> Having the full set of distutils doc strings in the
> catalog is already a substantial amount of text to translate...

Most of those docstrings in the Distutils are not really for public
consumption; they're there so that Distutils developers can remember (or
learn) what the heck such-and-such a method is supposed to do.

Also, they're a moving target; things are still changing in the
Distutils, and trying to keep on top of translating internal docstrings
would be a hopeless and frustrating task.

        Greg


From jack@oratrix.nl  Wed Jun  7 14:51:54 2000
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 07 Jun 2000 15:51:54 +0200
Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins]
 CVS: python/dist/src/Lib locale.py,1.4,1.5)
In-Reply-To: Message by "M.-A. Lemburg" <mal@lemburg.com> ,
 Wed, 07 Jun 2000 12:25:08 +0200 , <393E2304.4BE8CDE0@lemburg.com>
Message-ID: <20000607135154.8DCFD370CF2@snelboot.oratrix.nl>

The locale stuff in the CodeWarrior libraries is basically a dummy 
placeholder, that's why I didn't export it to Python. But it appears that it's 
better to export it anyway, if I understand the dsicussion correctly, so I'll 
do so from the next release.
--
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 gward@mems-exchange.org  Wed Jun  7 14:56:38 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 09:56:38 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>; from jeremy@beopen.com on Sat, Jun 03, 2000 at 12:11:48PM -0400
References: <3938D60E.391AAF31@lemburg.com> <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
Message-ID: <20000607095638.B5559@ludwig.cnri.reston.va.us>

On 03 June 2000, Jeremy Hylton said:
> SourceForge makes it a little more inconvenient to check which
> patches have been applied.  Under the old CVS arrangement, it was
> a local operation to do a cvs log or diff.  Now it's a slow network
> operation that requires authentication.  (I really want a local
> mirror of the entire CVS repository!)

I have come up with a partial solution to the inconvenience of accessing
SourceForge, specifically the need for constant authentication.  I
generated a new, unencrypted SSH key and put it in ~/.ssh/alt-identity.
Then I wrote a little C program (source attached) that does the
equivalent of

  os.exec ("ssh", "-i", "$HOME/.ssh/alt-identity")

(in an imaginary dialect of Python that interpolates environment
variables ;-).  Then I set CVS_RSH to this little C program
(~/bin/alt_ssh).  (It could have easily been a script, but I wanted to
avoid the overhead of launching an interpreter for every
authentication.)

So now CVS operations against SF are just s..l..o..w, and I'm not
forever typing in my SSH passphrase.  Of course, anyone with root access
at CNRI could now steal my unencrypted key -- which I *only* use for CVS
access to SF -- and use it to impersonate me for checkins.  But I think
the only person who knows how to do that already has Python checkin
privilege.  ;-)

But yeah, remote CVS still bites the big one.  Very painful over a 28.8k 
modem line.  (It sucks being a cheap bastard!)

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367


From gward@mems-exchange.org  Wed Jun  7 14:57:41 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 09:57:41 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us>; from gward@ludwig.cnri.reston.va.us on Wed, Jun 07, 2000 at 09:56:38AM -0400
References: <3938D60E.391AAF31@lemburg.com> <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com> <20000607095638.B5559@ludwig.cnri.reston.va.us>
Message-ID: <20000607095741.C5559@ludwig.cnri.reston.va.us>

--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii

On 07 June 2000, I said:
> Then I wrote a little C program (source attached) that does the
> equivalent of

Oops, forgot the attachment.  Here 'tis.

--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="alt_ssh.c"

/*
 * alt_ssh
 *
 * exec ssh with an alternate "identity" (key pair) -- needed since
 * the CVS_RSH variable can't include options for the rsh-like
 * command.
 *
 * GPW 2000/05/28
 *
 * $Id: alt_ssh.c,v 1.3 2000/06/07 13:54:19 gward Exp $
 */

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main (int argc, char * argv[])
{
    char * keyfile = "/.ssh/alt-identity";
    char * keyfile_full;
    char * home;
    int  num_args;
    char ** ssh_args;
    int i;

    home = getenv("HOME");
    keyfile_full = (char *) malloc (strlen(home) + strlen(keyfile) + 1);
    assert (home != NULL && keyfile_full != NULL);
    strcpy(keyfile_full, home);
    strcat(keyfile_full, keyfile);

    num_args = argc + 2;                /* -i, identity-file */
    ssh_args = (char **) calloc (num_args+1, sizeof(char *));
    ssh_args[0] = "ssh";
    ssh_args[1] = "-i";
    ssh_args[2] = keyfile_full;

    for (i = 3; i < num_args; i++)
        ssh_args[i] = argv[i-2];
    ssh_args[i] = NULL;

    for (i = 0; i < num_args; i++)
    {
        printf(ssh_args[i]);
        if (i < num_args)
            printf(" ");
    }
    printf("\n");
    
    execvp("ssh", ssh_args);
    perror("couldn't exec ssh");
    exit(1);
}

--NzB8fVQJ5HfG6fxh--


From jeremy@beopen.com  Wed Jun  7 15:04:12 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 10:04:12 -0400 (EDT)
Subject: [Python-Dev] Fwd: Hmmmm... (Jim Anderson)
Message-ID: <14654.22108.959934.552869@localhost.localdomain>

--iNprjKW4TE
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

You guys haven't seen more Perl traffic on this list have you? :-)

Jeremy


--iNprjKW4TE
Content-Type: message/rfc822
Content-Description: forwarded message
Content-Transfer-Encoding: 7bit

X-Digest: perl5-porters Digest 7 Jun 2000 05:57:31 -0000 Issue 490
Message-ID: <14653.8785.324733.949201@gargle.gargle.HOWL>
MIME-Version: 1.0
Content-Type: text/plain
From: "Jim Anderson" <jander@ml.com>
To: perl5-porters@perl.org
Subject: Hmmmm...
Date: Tue, 6 Jun 2000 12:09:53 -0400 (EDT)

This list has been ominously quiet the last couple of days. What's the
deal? Is everyone:

1. stressed out?

2. on holiday?

3. switching to python?

:)

jim


--iNprjKW4TE--


From gward@mems-exchange.org  Wed Jun  7 15:11:46 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 10:11:46 -0400
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.)
In-Reply-To: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>; from gstein@lyra.org on Sun, Jun 04, 2000 at 04:30:08PM -0700
References: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
Message-ID: <20000607101146.D5559@ludwig.cnri.reston.va.us>

On 04 June 2000, Greg Stein said:
> p.s. IMO, I'd like to see Guido own the Copyright for all current and
> future Python development

Second that.  Given that I work for CNRI and was forced (at gunpoint, as
I recall) to sign an incredibly draconian IP agreement -- along the
lines of "everything you have ever created, or will ever consider
creating, in any medium whatsoever, no matter where you did it or who
pays for it, is the property of CNRI for all time" -- I'd have a hard
time getting away with slapping "Copyright (c) 1999-2000 Gregory
P. Ward" all over the Distutils code.  And given that fair chunks of
that code have been contributed by other people, I couldn't even
ethically do that.

So, given that I probably can't claim ownership in the code, and that
CNRI has absolutely no moral right to it (although probably some legal
right), I'd prefer to sign it away to Guido.  Or optionally, to some
legal fiction that represents the Python community; preferably *not* the
Python Consortium, as long as CNRI is in any way connected.

Death to the lawyers!

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367


From Moshe Zadka <moshez@math.huji.ac.il>  Wed Jun  7 15:33:10 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Wed, 7 Jun 2000 17:33:10 +0300 (IDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to
 return total reference count in debug builds.)
In-Reply-To: <20000607101146.D5559@ludwig.cnri.reston.va.us>
Message-ID: <Pine.GSO.4.10.10006071731200.2293-100000@sundial>

On Wed, 7 Jun 2000, Greg Ward wrote:

> CNRI has absolutely no moral right to it (although probably some legal
> right), I'd prefer to sign it away to Guido.  Or optionally, to some
> legal fiction that represents the Python community; preferably *not* the
> Python Consortium, as long as CNRI is in any way connected.

Who's in charge of the PSA?
Or should we form *another* non-profit, and sign it over to it?
(Personally, I couldn't care less who I transfer copyright over my Python
contributions to -- I'd put it in the public domain if that's what it
took)

--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From pf@artcom-gmbh.de  Wed Jun  7 15:44:30 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 16:44:30 +0200 (MEST)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us> from Greg Ward at "Jun 7, 2000  9:56:38 am"
Message-ID: <m12zh4J-000DifC@artcom0.artcom-gmbh.de>

Hi,

Greg Ward:
> But yeah, remote CVS still bites the big one.  Very painful over a 28.8k 
> modem line.  (It sucks being a cheap bastard!)

Certainly you know about 'rsync'?  Would this help here?  
Let me quote a small section from the 'rsync' man page:

"""    To synchronize my samba source trees I use  the  following
       Makefile targets:

              get:
              	rsync -avuzb --exclude ´*~´ samba:samba/ .

              put:
              	rsync -Cavuzb . samba:samba/

              sync: get put

       this  allows  me to sync with a CVS directory at the other
       end of the link. I then do cvs operations  on  the  remote
       machine,  which saves a lot of time as the remote cvs pro­
       tocol isn´t very efficient.  """

I can't access CVS because of our restrictive HTTP/UUCP only firewall, 
but in our company we use 'rsync' a lot.

Regards, Peter


From bwarsaw@python.org  Wed Jun  7 16:06:42 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 7 Jun 2000 11:06:42 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <3938D60E.391AAF31@lemburg.com>
 <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
 <20000607095638.B5559@ludwig.cnri.reston.va.us>
Message-ID: <14654.25858.564089.574043@anthem.python.org>

>>>>> "GW" == Greg Ward <gward@mems-exchange.org> writes:

    GW> I have come up with a partial solution to the inconvenience of
    GW> accessing SourceForge, specifically the need for constant
    GW> authentication.

Greg, are you aware of ssh-agent?  Same convenience, same possible
exploits, but at least they've done the hard work for ya. :)

I usually just run XEmacs under ssh-agent.  First thing you do is fire
up a shell buffer, run ssh-add to authenticate once, and from there
on, all your ssh interactions (not just with SF) yank the private key
out of the ssh-agent process and never bother you with a passphrase
prompt.

-Barry


From bwarsaw@python.org  Wed Jun  7 16:22:20 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 7 Jun 2000 11:22:20 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to
 return total reference count in debug builds.)
References: <20000607101146.D5559@ludwig.cnri.reston.va.us>
 <Pine.GSO.4.10.10006071731200.2293-100000@sundial>
Message-ID: <14654.26796.936980.875783@anthem.python.org>

>>>>> "MZ" == Moshe Zadka <moshez@math.huji.ac.il> writes:

    MZ> Who's in charge of the PSA?  Or should we form *another*
    MZ> non-profit, and sign it over to it?  (Personally, I couldn't
    MZ> care less who I transfer copyright over my Python
    MZ> contributions to -- I'd put it in the public domain if that's
    MZ> what it took)

Please remember that the copyright holder can release the code under
whatever license they want, even multiple different licenses.
Copyright != license.

I'm not sure what the right thing to do here is.  On the one hand, Bob
Kahn always said nobody would use Python if its heritage
(i.e. copyright ownership) were not nailed down like Java.  On the
other hand, there's a lot of nobodies out there right now :).

For GNU projects, the FSF wants to own all the copyrights to the code.
They actually want you to legally assign the copyright to them.  Their
explanation for this onerous requirement is that if they were not the
copyright holder, they would not have the legal standing to defend GPL
violations, or would have to coordinate with a ton of developers,
making such legal defenses practically impossible.

Python is in a different situation, IMO, because it has a /less/
restrictive license than the GPL, so there's less to get all huffy
about in court.  If someone builds a binary-only proprietary blend of
Python and starts selling it without source code, well, there's no
license violation there, so what's to defend?

The argument has been made that without clear legal title, someone
could claim that some of the donated code in Python violated a
copyright or patent and try to stop 3rd parties from using Python.
Who knows what the actual legal possibility of that happening are, but
I don't see how 1) we could take any real defense against this or 2)
it affects Python any differently than any other large
multi-contributor open source system.

-Barry


From andy@robanal.demon.co.uk  Wed Jun  7 21:48:48 2000
From: andy@robanal.demon.co.uk (Andy Robinson)
Date: Wed, 07 Jun 2000 20:48:48 GMT
Subject: [Python-Dev] Package ambiguities
Message-ID: <393eb52b.47053339@post.demon.co.uk>

We hit some very weird behaviour recently while setting up a package
hierarchy.  Robin Becker managed to distil this into a simple example.
Can anyone shed any light on what is happening below?  Is Python
behaving as it should?

Create a package A, empty __init__.py, with modules as follows:
--------parent.py----------
class Parent:
    pass

--------child.py------------
from parent import Parent
class Child(Parent):
    pass

---------test.py--------
from parent import *
class Examiner:
    def examine(self, arg):
        print 'examining argument:'
        print 'class of arg =3D', arg.__class__
        print 'bases of arg =3D', arg.__class__.__bases__
        print 'arg =3D', arg
        if isinstance(arg, Parent):
            print "arg is an instance of Parent"
        else:
            print "arg IS NOT an instance of Parent"
        print
       =20
if __name__=3D=3D'__main__':
        from traceback import print_exc
        import sys
        def run0():
                from A.child import Child
                e =3D Examiner()
                e.examine(Child())

        def run1():
                from A.child import Child
                from A.test import Examiner
                e =3D Examiner()
                e.examine(Child())
        run0()
        run1()


Running this script produces the following output:

  C:\users\andy\A>test.py
  examining argument:
  class of arg =3D A.child.Child
  bases of arg =3D (<class A.parent.Parent at 7f9150>,)
  arg =3D <A.child.Child instance at 7f9410>
  arg IS NOT an instance of Parent

  examining argument:
  class of arg =3D A.child.Child
  bases of arg =3D (<class A.parent.Parent at 7f9150>,)
  arg =3D <A.child.Child instance at 7f83c0>
  arg is an instance of Parent


Many thanks,

Andy Robinson




From Ka-Ping Yee <pingster@ilm.com>  Wed Jun  7 22:05:26 2000
From: Ka-Ping Yee <pingster@ilm.com> (Ka-Ping Yee)
Date: Wed, 7 Jun 2000 14:05:26 -0700 (PDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <393eb52b.47053339@post.demon.co.uk>
Message-ID: <Pine.SGI.3.96.1000607135723.428158j-100000@happy>

On Wed, 7 Jun 2000, Andy Robinson wrote:
> We hit some very weird behaviour recently while setting up a package
> hierarchy.  Robin Becker managed to distil this into a simple example.
> Can anyone shed any light on what is happening below?  Is Python
> behaving as it should?

It looks to me like you have two "parent" modules.

When you run "test.py" directly from the command line, the
first "from parent import *" imports parent.py as module "parent".
But subsequently parent.py is imported again as module "A.parent".

Similarly, you have two "Examiner" classes.  In run0() you
get Examiner from __main__, which contains the Parent class
from module "parent".  In run1() you get Examiner from A.test,
which contains the Parent class imported from module "A.parent".

If you insert

        print 'in module', __name__, 'parent is', repr(Parent)

at the beginning of the examine() method, it should make things
clear.

The solution is to avoid directly running scripts that are
inside packages; the confusion is produced by the fact that
you're running "test.py" from within the A/ directory.


-- ?!ng



From jeremy@beopen.com  Wed Jun  7 22:25:53 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 17:25:53 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
Message-ID: <14654.48609.710990.321688@localhost.localdomain>

Say a startup company decided to put some resources behind the Python
Web site -- a full-time Web master, some content developers, etc.
What would you have them do?  What could be done to open up the site
to the community and make it more responsive to developers and users?
What's your wish list for content, services, etc.?

If you've got any ideas, please get back to me soon.

Jeremy



From esr@thyrsus.com  Wed Jun  7 22:41:48 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Wed, 7 Jun 2000 17:41:48 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14654.48609.710990.321688@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 07, 2000 at 05:25:53PM -0400
References: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <20000607174148.A6801@thyrsus.com>

Jeremy Hylton <jeremy@beopen.com>:
> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?

I think it's pretty good as is -- lots of content, pretty well 
organized.  My top wishlist item is "Burn all your GIFs".
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The right of self-defense is the first law of nature: in most
governments it has been the study of rulers to confine this right
within the narrowest limits possible.  Wherever standing armies
are kept up, and when the right of the people to keep and bear
arms is, under any color or pretext whatsoever, prohibited,
liberty, if not already annihilated, is on the brink of
destruction." 
	-- Henry St. George Tucker (in Blackstone's Commentaries)


From jack@oratrix.nl  Wed Jun  7 22:47:01 2000
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 07 Jun 2000 23:47:01 +0200
Subject: [Python-Dev] hey, who broke the array module?
In-Reply-To: Message by Guido van Rossum <guido@python.org> ,
 Thu, 18 May 2000 15:05:45 -0700 , <200005182205.PAA12830@cj20424-a.reston1.va.home.com>
Message-ID: <20000607214706.65CB2D8397@oratrix.oratrix.nl>

Recently, Guido van Rossum <guido@python.org> said:
> > On Thu, May 18, 2000 at 12:01:16PM +0200, Jack Jansen wrote:
> > > > I broke it with my patches to test overflow for some of the PyArg_Parse
> *()
> > > > formatting characters. The upshot of testing for overflow is that now t
> hose
> > > > formatting characters ('b', 'h', 'i', 'l') enforce signed-ness or
> > > > unsigned-ness as appropriate (you have to know if the value is signed o
> r
> > > > unsigned to know what limits to check against for overflow). Two
> > > > possibilities presented themselves:
> > > 
> > > I think this is a _very_ bad idea. I have a few thousand (literally) rout
> ines 
> > > calling to Macintosh system calls that use "h" for 16 bit flag-word value
> s, 
> > > and the constants are all of the form
> > > 
> > > kDoSomething = 0x0001
> > > kDoSomethingElse = 0x0002
> > > ...
> > > kDoSomethingEvenMoreBrilliant = 0x8000
> > > 
> > > I'm pretty sure other operating systems have lots of calls with similar 
> > > problems. I would strongly suggest using a new format char if you want 
> > > overflow-tested integers.
> > 
> > Sigh. What do you think Guido? This is your call.
> > 
> > 1. go back to no bounds testing
> > 2. bounds check for [SHRT_MIN, USHRT_MAX] etc (this would allow signed and
> > unsigned values but is sort of false security for bounds checking)
> > 3. keep it the way it is: 'b' is unsigned and the rest are signed
> > 4. add new format characters or a modifying character for signed and unsign
> ed
> > versions of these.
> 
> Sigh indeed.  Ideally, we'd introduce H for unsigned and then lock
> Jack in a room with his Macintosh computer for 48 hours to fix all his
> code...

Hmm, hmm. As stated before I'm not too fond of this as it is a
gratuitous change that breaks lots of things (not only in Mac modules: 
the array module was what started this discussion, test_cPickle
and test_pkg crash, socketmodule, os.stat() and I assume all code that
uses structmodule will also have to be looked at, and quite possibly
there's a lot more) and for which I don't really see all that much
benefit.

As a datapoint: a quick search for 8-digit hex numbers starting with
digit 8-F and not suffixed with an L throughout the Python files in
the distribution found a stunning 464 matches. Add another 1147
4-digit hex numbers with the sign bit on and there are an awful lot of 
candidates for breaking...
--
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 gmcm@hypernet.com  Wed Jun  7 22:59:20 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Wed, 7 Jun 2000 17:59:20 -0400
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <Pine.SGI.3.96.1000607135723.428158j-100000@happy>
References: <393eb52b.47053339@post.demon.co.uk>
Message-ID: <1251707300-11412775@hypernet.com>

Ka-Ping wrote:

> On Wed, 7 Jun 2000, Andy Robinson wrote:
> > We hit some very weird behaviour recently while setting up a
> > package hierarchy.  Robin Becker managed to distil this into a
> > simple example. Can anyone shed any light on what is happening
> > below?  Is Python behaving as it should?

[snip entirely correct analysis]

> The solution is to avoid directly running scripts that are
> inside packages; the confusion is produced by the fact that
> you're running "test.py" from within the A/ directory.

I disagree with the moral.

If test.py uses "import A.parent" and changes references 
accordingly, it works.

So my version of the moral is that import * is EVIL. Not only 
that, but relative imports are EVIL.

This is what I meant when I said (in reply to Greg Wilson's 
inquiry about package structures) that there are some very 
bad precedents getting set.

Doing this junk (usually in __init__.py) not only makes your 
package fragile, it also makes the package structure 
mysterious to the user (who's a developer - making things 
mysterious to him/her is just making both your lives harder!). If 
you want to make it friendly to lazy coders, then something 
like:

import A.parent
Parent = A.parent.Parent

also works, (leaving references as Parent). I'm not terribly fond 
of this, either, but at least the coder has a reasonable hope of 
tracking down what "Parent" actually is.

I'm not necessarily yelling at you, Andy. It seems that most 
package developers are going down this slope. It stinks.


- Gordon


From jeremy@beopen.com  Wed Jun  7 23:06:29 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 18:06:29 -0400 (EDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <1251707300-11412775@hypernet.com>
References: <393eb52b.47053339@post.demon.co.uk>
 <1251707300-11412775@hypernet.com>
Message-ID: <14654.51045.18807.74677@localhost.localdomain>

Gordon's comments are on the money.  An import in a module inside a
package should be fully qualified.  I'd put that in the style guide if
it were up to me (and, of course, it's not).

Jeremy


From bwarsaw@python.org  Wed Jun  7 23:38:02 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 7 Jun 2000 18:38:02 -0400 (EDT)
Subject: [Python-Dev] Package ambiguities
References: <393eb52b.47053339@post.demon.co.uk>
 <1251707300-11412775@hypernet.com>
 <14654.51045.18807.74677@localhost.localdomain>
Message-ID: <14654.52938.139406.371556@anthem.concentric.net>

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

    JH> Gordon's comments are on the money.  An import in a module
    JH> inside a package should be fully qualified.  I'd put that in
    JH> the style guide if it were up to me (and, of course, it's
    JH> not).

I concur on both points.  BTW, one of the Things I'd Like To Do, is
update and flesh out the style guide.  It's incomplete in places and
out of date in others.  If someone else has the gumption to lead this
effort, I'd be happy to send my comments instead.

-Barry


From Ka-Ping Yee <pingster@ilm.com>  Wed Jun  7 23:39:28 2000
From: Ka-Ping Yee <pingster@ilm.com> (Ka-Ping Yee)
Date: Wed, 7 Jun 2000 15:39:28 -0700 (PDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <1251707300-11412775@hypernet.com>
Message-ID: <Pine.SGI.3.96.1000607150444.428158l-100000@happy>

On Wed, 7 Jun 2000, Gordon McMillan wrote:
> I disagree with the moral.
> 
> If test.py uses "import A.parent" and changes references 
> accordingly, it works.

Correct.

Well, maybe there are two things going on here.

I agree that import * isn't usually a very good idea.

However, notice that the problem occurs even if the first line
of test.py is "import parent" (no star).  When you talk about
changing references accordingly, the real issue is referencing
"A.parent" rather than "parent".

In fact, if you change the first line to "from A.parent import *"
(not that i am advocating this!) -- it works.  In short:

    from parent import *    ...  Parent             doesn't work
    import parent           ...  parent.Parent      doesn't work
    
    from A.parent import *  ...  Parent             works
    import A.parent         ...  A.parent.Parent    works

The first two cases -- attempting to import "parent" -- are
only made possible by the fact that we're executing test.py
from within the A/ directory, and hence the confusion.


This problem is an "advanced" version of a simpler issue
which a friend of mine discovered and complained about
recently to me: the __main__ vs. module-name conflict.
Allow me to paraphrase his example.

Exhibit A:

    ---- spam.py ----
    import eggs

    def go():
        print "was", eggs.a
        eggs.a = 3
        print "now", eggs.a

    ---- eggs.py ----
    import spam

    a = 1

    def go():
        spam.go()
        print "finally", a

    if __name__ == "__main__": go()

    --- watch what happens ----
    % python eggs.py
    was 1
    now 3
    finally 1

    % python
    >>> import eggs
    >>> eggs.go()
    was 1
    now 3
    finally 3


Exhibit B:

    ---- one.py ----
    import two
    def go(): pass

    ---- two.py ----
    import one
    one.go()

    ---- watch what happens ----
    % python one.py

    % python two.py
    Traceback (innermost last):
      File "two.py", line 1, in ?
        import one
      File "./one.py", line 1, in ?
        import two
      File "./two.py", line 2, in ?
        one.go()
    AttributeError: go
    Exit 1

    % python
    >>> import one
    Traceback (innermost last):
      File "<stdin>", line 1, in ?
      File "./one.py", line 1, in ?
        import two
      File "./two.py", line 2, in ?
        one.go()
    AttributeError: go
    >>> import two
    >>> 


The facts that eggs.a appears to behave differently in Exhibit A,
and that one.py can be run but two.py cannot, yet "two" can be
imported and "one" cannot, in Exhibit B, both result from the
duplication namespaces in __main__ and in a module.

Normally, this only affects the main file that you are running,
the one with the __main__ namespace.  However, attempting to run
scripts in package directories allows this problem to propagate
further into the duplication of other modules:

    __main__ imports parent which imports child
    A.test imports A.parent which imports A.child

...and that can cause duplicate classes all over the place,
which is what happened to Andy.


My friend was quite irked by the existence of __main__, citing
it as the culprit for this duplication.  But naturally Python
can't always know the name of the script being run -- in the
case of a file ending in .py, perhaps, it's easy, but the script
might come from a pipe, for example.  So eliminating __main__
doesn't seem like a feasible response.

Depending how "real" you consider this problem, leaving things
as they are and instructing people in the discipline of keeping
modules and scripts separated may be the best response.

I bet this crops up all the time in those "testing" sections
of modules that use the 'if __name__ == "__main__"' convention,
though...


-- ?!ng

"Computers are useless.  They can only give you answers."
    -- Pablo Picasso



From petrilli@amber.org  Wed Jun  7 23:51:50 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Wed, 7 Jun 2000 18:51:50 -0400
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <14654.52938.139406.371556@anthem.concentric.net>; from bwarsaw@python.org on Wed, Jun 07, 2000 at 06:38:02PM -0400
References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> <14654.52938.139406.371556@anthem.concentric.net>
Message-ID: <20000607185150.A29156@trump.amber.org>

Barry A. Warsaw [bwarsaw@python.org] wrote:
> 
> >>>>> "JH" == Jeremy Hylton <jeremy@beopen.com> writes:
> 
>     JH> Gordon's comments are on the money.  An import in a module
>     JH> inside a package should be fully qualified.  I'd put that in
>     JH> the style guide if it were up to me (and, of course, it's
>     JH> not).
> 
> I concur on both points.  BTW, one of the Things I'd Like To Do, is
> update and flesh out the style guide.  It's incomplete in places and
> out of date in others.  If someone else has the gumption to lead this
> effort, I'd be happy to send my comments instead.

Something we futzed with at Digital Creations was "commentable" or
discussable web pages.  This would be a great use for this.  If you
took and made each basic topic/issue a page, and let people "discuss"
them.  A nice threaded discussion could add a lot of insight.   This
is versus a wiki where it's more "free for all", which isn't really
appropraiate for a "guide".

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From pingster@ilm.com  Wed Jun  7 23:48:29 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Wed, 7 Jun 2000 15:48:29 -0700 (PDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <20000607185150.A29156@trump.amber.org>
Message-ID: <Pine.SGI.3.96.1000607154751.428158n-100000@happy>

On Wed, 7 Jun 2000, Christopher Petrilli wrote:
> Something we futzed with at Digital Creations was "commentable" or
> discussable web pages.  This would be a great use for this.  If you
> took and made each basic topic/issue a page, and let people "discuss"
> them.  A nice threaded discussion could add a lot of insight.   This
> is versus a wiki where it's more "free for all", which isn't really
> appropraiate for a "guide".

Well, y'all could go nuts marking up the style guide with Crit.

    http://crit.org/


...or marking up anything else on the whole Web, for that matter. :)



-- ?!ng

"To be human is to continually change.  Your desire to remain what
you are is what ultimately limits you."
    -- The Puppet Master, Ghost in the Shell



From jeremy@beopen.com  Thu Jun  8 00:00:36 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 19:00:36 -0400 (EDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <Pine.SGI.3.96.1000607150444.428158l-100000@happy>
References: <1251707300-11412775@hypernet.com>
 <Pine.SGI.3.96.1000607150444.428158l-100000@happy>
Message-ID: <14654.54292.711289.254224@localhost.localdomain>

>In fact, if you change the first line to "from A.parent import *"
>(not that i am advocating this!) -- it works.  In short:
>
>    from parent import *    ...  Parent             doesn't work
>    import parent           ...  parent.Parent      doesn't work
>    
>    from A.parent import *  ...  Parent             works
>    import A.parent         ...  A.parent.Parent    works

One other possibility that ought to work (?)

    from A import parent

Jeremy


From gmcm@hypernet.com  Thu Jun  8 00:47:47 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Wed, 7 Jun 2000 19:47:47 -0400
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <Pine.SGI.3.96.1000607150444.428158l-100000@happy>
References: <1251707300-11412775@hypernet.com>
Message-ID: <1251700795-11803988@hypernet.com>

Ka-Ping wrote:

> ... In short:
> 
>     from parent import *    ...  Parent             doesn't work
>     import parent           ...  parent.Parent      doesn't work
> 
>     from A.parent import *  ...  Parent             works
>     import A.parent         ...  A.parent.Parent    works

Right. That's why I cast relative imports as evil.

> This problem is an "advanced" version of a simpler issue
> which a friend of mine discovered and complained about
> recently to me: the __main__ vs. module-name conflict.

This comes up a whole lot. In those periods where I have the 
time, energy and patience to monitor c.l.py closely, I've seen 
this come up 4 or 5 times in one week. Almost always in 
conjunction with import *.

I can live with explaining how __main__ is special. That's one 
of those "you only have to explain it once" problems.

But the import * problems (name hiding, the fact that 
assignments aren't seen) and relative imports are things that 
come up over and over again, and trip up even experienced 
people (and them more than once).



- Gordon


From gstein@lyra.org  Thu Jun  8 03:30:14 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 19:30:14 -0700
Subject: [Python-Dev] Idea: emulating _locale
In-Reply-To: <393E2304.4BE8CDE0@lemburg.com>; from mal@lemburg.com on Wed, Jun 07, 2000 at 12:25:08PM +0200
References: <m12zcE0-000DifC@artcom0.artcom-gmbh.de> <393E2304.4BE8CDE0@lemburg.com>
Message-ID: <20000607193014.P3348@lyra.org>

On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote:
>...
> Peter Funk wrote:
>...
> > > + ### C lib locale APIs
> > > +
> > > + from _locale import *
> > 
> > Wouldn't it be clever to provide some dummy stubs on those platforms, where
> > the _locale module was not enabled?
> > 
> > try:
> >     from _locale import *
> > except:
> >     def setlocale(....
> >     def localeconv(....
> >     ...
> > 
> > Especially the MacOS 1.5.2 release provided by Jack Jansen was
> > compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
> > is still disabled per default in 'Modules/Setup.in'.  I didn't had
> > a look into the current CVS though, so this may have changed.
> > 
> > I think the name aliasing tables might be also useful on those
> > systems lacking locale support in their C-library.
> 
> setlocale and localeconv are ANSI C and Python requires an ANSI C
> compiler, so there should be no problem (at least in theory).
> 
> If there is a problem, adding the missing symbols would
> be no problem: the APIs could always report locale 'C'
> and its numeric settings.

An ANSI C compiler and the ANSI C library are very different. Just because
Python requires an ANSI compiler (or close to it), does NOT mean that we can
or should depend upon particular elements in the library.

IMO, we should follow Peter's advice and have stubs for the platforms where
_locale is not built.

Cheers,
-g

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


From gstein@lyra.org  Thu Jun  8 03:35:37 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 19:35:37 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.21,2.22
In-Reply-To: <200006070913.CAA18060@slayer.i.sourceforge.net>; from lemburg@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 02:13:24AM -0700
References: <200006070913.CAA18060@slayer.i.sourceforge.net>
Message-ID: <20000607193537.Q3348@lyra.org>

On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote:
> Update of /cvsroot/python/python/dist/src/Objects
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects
> 
> Modified Files:
> 	unicodeobject.c 
> Log Message:
> Marc-Andre Lemburg <mal@lemburg.com>:
> Change the default encoding to 'ascii' (it was previously
> defined as UTF-8).
> 
> Note: The implementation still uses UTF-8 to implement
> the buffer protocol, so C APIs will still see UTF-8. This
> is on purpose: rather than fixing the Unicode implementation,
> the C APIs should be made Unicode aware.

I'm a little confused on where this gets applied. Is this when somebody says
"str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when
somebody says "unicode(str)" and we expect <str> to be ASCII?

Cheers,
-g

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


From gstein@lyra.org  Thu Jun  8 04:06:24 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 20:06:24 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26
In-Reply-To: <200006080008.RAA15980@slayer.i.sourceforge.net>; from gward@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 05:08:17PM -0700
References: <200006080008.RAA15980@slayer.i.sourceforge.net>
Message-ID: <20000607200624.R3348@lyra.org>

On Wed, Jun 07, 2000 at 05:08:17PM -0700, Greg Ward wrote:
> Update of /cvsroot/python/distutils/distutils/command
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv15881
> 
> Modified Files:
> 	sdist.py 
> Log Message:
> Made all debug output go through the 'debug_print()' method instead of
> directly printing to stdout.  This was a bit more work than it sounds like
> it should have been:
>   * turned 'select_pattern()' and 'exclude_pattern()' from functions into
>     methods, so they can refer to 'self' to access the method

You wouldn't have to do this if you make debug_print() a function. There is
nothing in debug_print() that requires "self", so its existence as a method
is suspect in the first place. Considering the fallout changes, I'd say move
debug_print() to a plain function (in "utils").

Unless you were planning on more stuff in there; if so, then a comment in
debug_print would be nice.

>...
> ***************
> *** 297,301 ****
>               if (cur_dir == dir and
>                   (pattern_re is None or pattern_re.match (cur_base))):
> !                 print "removing %s" % self.files[i]
>                   del self.files[i]
>   
> --- 298,302 ----
>               if (cur_dir == dir and
>                   (pattern_re is None or pattern_re.match (cur_base))):
> !                 self.debug_print("removing %s" % self.files[i])
>                   del self.files[i]

Gah... "pattern_re.match (cur_base)" ...

You do realize that God intended there to be no spaces between a function
name and the opening paren? Heretic!

:-)

Really -- I have noticed this throughout a lot of the distutils code. That
space in there is really awful. It reduces the "binding" of the name to the
paren, which changes the meaning during a quick read. Put another way: when
you skim code, NAME( is a function call and NAME ( is something else. A
space after a name usually indicates the name is participating in an
expression, rather than being used as a function name. Then, you hit the
paren and go "what the heck? <pause> oh. a function call."

Please... can they be removed?

Cheers,
-g

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


From gstein@lyra.org  Thu Jun  8 05:05:55 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 21:05:55 -0700
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.)
In-Reply-To: <Pine.GSO.4.10.10006071731200.2293-100000@sundial>; from moshez@math.huji.ac.il on Wed, Jun 07, 2000 at 05:33:10PM +0300
References: <20000607101146.D5559@ludwig.cnri.reston.va.us> <Pine.GSO.4.10.10006071731200.2293-100000@sundial>
Message-ID: <20000607210555.X3348@lyra.org>

On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote:
> On Wed, 7 Jun 2000, Greg Ward wrote:
> 
> > CNRI has absolutely no moral right to it (although probably some legal
> > right), I'd prefer to sign it away to Guido.  Or optionally, to some
> > legal fiction that represents the Python community; preferably *not* the
> > Python Consortium, as long as CNRI is in any way connected.
> 
> Who's in charge of the PSA?

CNRI

Effectively, the PSA is a legal fiction for collecting donations to further
the development of Python. The Consortium is similar, but members have the
actual/explicit capability to steer Python's development. I believe this
ability to steer the development is (was?) rooted in the fact that CNRI
employed Guido. I have no idea how that will work now -- the "steering" will
(essentially) have to rely entirely on Guido's good graces. Guido is an
excellent listener to people's needs, so there is no immediate problem here.

> Or should we form *another* non-profit, and sign it over to it?

The Apache Software Foundation is already a legal, formed, non-profit
corporation. If the desire is to transfer copyright to a non-profit, then
I'd recommend reusing the ASF rather than trying to start a new one.
Recognize that running a company (even a non-profit) is not a "zero cost"
item. Somebody would have to put that time in.

CNRI is also non-profit, but its members/board/directors/etc are not as Open
Source minded as the ASF.

> (Personally, I couldn't care less who I transfer copyright over my Python
> contributions to -- I'd put it in the public domain if that's what it
> took)

As Barry said: license and copyright are different. Since you own the
copyright, then you *can* put it into the public domain Right Now. I've done
that with some of my modules (e.g. qp_xml and imputil).

Here is the header from qp_xml.py:

#
# qp_xml: Quick Parsing for XML
#
# Written by Greg Stein. Public Domain.
# No Copyright, no Rights Reserved, and no Warranties.
#

Fun, huh? :-)

On the other hand, I have given Guido two pieces of code: httplib.py and
davlib.py:

#
# DAV client library
#
# Copyright (C) 1998-1999 Guido van Rossum. All Rights Reserved.
# Written by Greg Stein. Given to Guido. Licensed using the Python license.
#

Oh. I need to update his copyright year :-)

Want to know something really funny? Presuming my httplib.py goes into the
Python distribution, that will be the first piece of code that Guido truly
owns in Python. All the other code he wrote is owned by CWI or CNRI....

Cheers,
-g

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


From fredrik@pythonware.com  Thu Jun  8 09:30:39 2000
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 8 Jun 2000 10:30:39 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26
References: <200006080008.RAA15980@slayer.i.sourceforge.net> <20000607200624.R3348@lyra.org>
Message-ID: <009501bfd123$d4b2c750$0500a8c0@secret.pythonware.com>

greg wrote:
> Gah... "pattern_re.match (cur_base)" ...
>=20
> You do realize that God intended there to be no spaces between a =
function
> name and the opening paren? Heretic!

http://www.python.org/doc/essays/styleguide.html

    ...
    I hate whitespace in the following places:=20
    ...
    Immediately before the open parenthesis that starts the argument
    list of a function call, as in spam (1). Always write this as =
spam(1).
    ...
    Don't bother to argue with me on any of the above
    ...

</F>



From andy@reportlab.com  Thu Jun  8 09:42:46 2000
From: andy@reportlab.com (Andy Robinson)
Date: Thu, 8 Jun 2000 09:42:46 +0100
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <20000608030555.532221CDEF@dinsdale.python.org>
Message-ID: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk>

Thanks for all the replies.  We really need a 'style guide'
on package use, so I hope this example can be thrashed
out and used to help others.  We need to decide something
and release next week, and also provide good docs for
other users who will be new to Python.

Apart from the ambiguity, which was a surprise but which 
we can work around, I have some general questions on the
"right thing".  Here are my examples:

1. use of __init__ to save users work
------------------------------------ 
ReportLab has a subpackage called 'platypus' which we have
just reorganized and not yet released.  The division
into subpackages is clear - each exposes a different
kind of functionality - but the division of each
package into modules is based on keeping a sane 
length for each and not on providing a friendly
user interface.

reportlab
    pdfgen
        canvas.py  defines class Canvas
        textobject.py defines class TextObject
        pathobject.py defines class PathObject
    platypus
        (the same problem, but 3x worse)
    lib
        (loads of modules, all independent)

We reached a point where users need to import eight or 
ten classes to do useful work and were having to put eight 
or ten different import lines at the top of every script.  
This just feels dumb and wrong.

So, the 'least messy' idea was to put __init__.py
methods in each subpackage which explicitly import
what they need.  (We have not used "import *")

---reportlab/pdfgen/__init__.py--------
from canvas import Canvas
from textobject.py import TextObject
from pathobject.py impory PathObject

Then users can just do:
from reportlab.pdfgen import Canvas, PathObject, TextObject

It seems that this (a) makes life easier for users, and
(b) gives us freedom to refactor code as it grows, without
changing the user interface.  

Is this style evil?  If so, why? 


2. Ambiguities running scripts within package
---------------------------------------------
We have various test functions scattered 
throughout our distribution.  A control script iterates
through the lot and kicks them off before every release,
executing everything with an 'if __name__=='__main__'
handler.  If these were standalone scripts just for 
testing, they could import "reportlab.platypus.tables"
or whatever.  But if I just want to put a test
routine at the end of "reportlab.platypus.tables"
then I seem destined to run into exactly the ambiguity
outlined before.  

Should test scripts all be moved out of the package?  
Indeed, is Python behaving the way it ought to?

3. Preferred subpackage import technique
----------------------------------------
I have two scripts 'spam.py' and 'eggs.py' in
subpackage 'A.B'.  spam imports eggs.
Should it say...
   import eggs
or...
   import A.B.eggs?

Both work sometimes, but can lead to different
behavious sometimes.  Which is the preferred style?

Thanks,

Andy Robinson



From pf@artcom-gmbh.de  Thu Jun  8 10:35:14 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Thu, 8 Jun 2000 11:35:14 +0200 (MEST)
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk> from Andy Robinson at "Jun 8, 2000  9:42:46 am"
Message-ID: <m12zyiZ-000DieC@artcom0.artcom-gmbh.de>

Hi Andy,  

> Thanks for all the replies.  
> We really need a 'style guide' on package use, 

On 'import', packages and modules:
----------------------------------
You should definitely have a look at the approach used by Greg
McFarlane in his 'Pmw' package.  In particular at his PmwLoader class
and the Pmw.def.  For my own project I've simplified and somewhat
generalized his approach to dynamic and lazy importing.  I posted a
preliminary implemantation of this to comp.lang.python a while ago
but didn't got much feedback.  May be due to fact, that I had to repost
the thing, because the TABs went wrong in the first try :-(

[...]
> Is this style evil?  If so, why? 

I believe it will get really hard to come up with a 'namespace style guide' 
which everybody can aggree on.  But who cares: let's start a rant:

-->  IMO 'from ... import ...' is EVIL and its use should be banned!  <--

Why?  Because if software becomes bigger (> 100k LOC), these
unqualified names definitely become a maintaince nightmare, since you
didn't know what names are defined in the module you are currently
staring at and what names come from the "outside world".

I believe Python inherited two of its three forms of import syntax at 
least in part from its anchestors Modula-2 and Modula-3.  

My perception of this import-problem may be blurred by programming in
Modula-2 in our company since 1985, where the code base now is about ~1
Mio. LOC.  Some of the older code contains still modules using a lot of
'FROM foobar IMPORT ....;' lines in the header.  These have usually
been harder to read and understand by new employees than those having
'IMPORT foobar;' in the header and than using 'foobar.component'
everywhere in the code body below.

from .... import * is *EVEN MORE EVIL*.

Well: at least if people use 'from' to import arbitrary objects and
classes.  Using 'from package.subpackage import module' is an idiom,
with which I can live with comfortably.

> Should test scripts all be moved out of the package?  

This would defeat the use of Tim Peters wonderful 'doctest' module.
I'm still thinking, 'doctest' should be made part of the standard
library in order to give the publicity this elegant approach deserves.

Regards, Peter


From Vladimir.Marangozov@inrialpes.fr  Thu Jun  8 11:27:10 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Thu, 8 Jun 2000 12:27:10 +0200 (CEST)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <20000607174148.A6801@thyrsus.com> from "Eric S. Raymond" at Jun 07, 2000 05:41:48 PM
Message-ID: <200006081027.MAA02445@python.inrialpes.fr>

[Jeremy Hylton]
>
> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?

The content is good. Some wishes on its presentation, not taking into
account any cosmetic changes.

With my webmaster's hat, I would say:

1. Make the content accessible, i.e. compliant to the standards
   HTML tidy does a pretty good job in cleaning up existing Web pages
   I would suggest sticking with valid XHTML 1.0 transitional or HTML 4.x
   transitional.

2. Use CSS -- not too much, though, given its growing but still limited
   support. I am using myself parts of CSS1. My approach is to use styles
   *and* attributes (which is redundant, for now). Browsers that understand
   styles would honor them, while those that don't would take into account
   the attributes. The aim is to have the same end result. With the evolution
   of the browsers, the attributes would disappear.

   A compromise that introduces styles smoothly.

3. Have a comprehensible site map for direct access to the major topics.
   I tend to like ours which is convenient for small to medium sized sites
   (http://www.inrialpes.fr/plansite.html)

4. Do not use frames, do not use JavaScript or similar, do not use anything
   that hurts content accessibility.

[Eric S. Raymond]
> 
>  My top wishlist item is "Burn all your GIFs".

This seems to be an important symbol for an organization with an Open Source
spirit.  Hopefully, a gif2png batch processing should make things easier.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From gstein@lyra.org  Thu Jun  8 12:43:24 2000
From: gstein@lyra.org (Greg Stein)
Date: Thu, 8 Jun 2000 04:43:24 -0700
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <m12zyiZ-000DieC@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Thu, Jun 08, 2000 at 11:35:14AM +0200
References: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk> <m12zyiZ-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <20000608044324.L3348@lyra.org>

On Thu, Jun 08, 2000 at 11:35:14AM +0200, Peter Funk wrote:
>...
> > Is this style evil?  If so, why? 
> 
> I believe it will get really hard to come up with a 'namespace style guide' 
> which everybody can aggree on.  But who cares: let's start a rant:
> 
> -->  IMO 'from ... import ...' is EVIL and its use should be banned!  <--

You are being overly strict here. I use this all the time:

from module import submodule
...
submodule.Class()

or even

from module.submodule import subsub
...
subsub.Blargle()

In other words, "from package import module" is a Fine Thing. It can
simplify your code without hiding where the symbols come from.

In general, I agree with you: importing symbols from a module into your
namespace is a Bad Thing.

Cheers,
-g

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


From fdrake@beopen.com  Thu Jun  8 13:37:04 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 8 Jun 2000 08:37:04 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <200006081027.MAA02445@python.inrialpes.fr>
References: <20000607174148.A6801@thyrsus.com>
 <200006081027.MAA02445@python.inrialpes.fr>
Message-ID: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>

Vladimir Marangozov writes:
 > 2. Use CSS -- not too much, though, given its growing but still limited
 >    support. I am using myself parts of CSS1. My approach is to use styles
 >    *and* attributes (which is redundant, for now). Browsers that understand
 >    styles would honor them, while those that don't would take into account
 >    the attributes. The aim is to have the same end result. With the evolution
 >    of the browsers, the attributes would disappear.

  The approach to CSS I've taken with the documentation is to use
attributes for anything that's really needed to make the presentation
readable and then an external CSS stylesheet for everything else.
This seems like a reasonable approach to me, and avoids including too
much duplicate information.  This also seems like the best way to
maintain support for older browsers.
  Perhaps we should collect browser statistics on python.org so we'll
know how many "legacy" browsers are in use?  I would be surprised if
many of the text-mode browsers support CSS well (and there are several
being actively worked on these days, so please don't tell me they
don't count!).

 > 4. Do not use frames, do not use JavaScript or similar, do not use anything
 >    that hurts content accessibility.

  I do have some JavaScript on python.org, but it's only to make data
entry in a form a little easier by making adjustments to related
fields, so it remains completely operational without JavaScript.  I
don't think there's currently any required JavaScript.  And I have yet
to see a frame, thank goodness!

[Eric S. Raymond]
 > 
 >  My top wishlist item is "Burn all your GIFs".

  Is it more important than accessibility?  This is a real issue for
legacy browsers, especially on minority platforms.  One of the big
wins for Python is that it is as portable as it is.  Does that matter
if information is hard to get to?
  A good reason to avoid using images for anything that isn't
cosmetic!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From pf@artcom-gmbh.de  Thu Jun  8 13:28:11 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Thu, 8 Jun 2000 14:28:11 +0200 (MEST)
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <20000608044324.L3348@lyra.org> from Greg Stein at "Jun 8, 2000  4:43:24 am"
Message-ID: <m1301Pv-000DieC@artcom0.artcom-gmbh.de>

Hi Greg,

[me]
> > -->  IMO 'from ... import ...' is EVIL and its use should be banned!  <--

[Greg Stein]:
> You are being overly strict here. I use this all the time:
> 
> from module import submodule
> ...
> submodule.Class()
> 
> or even
> 
> from module.submodule import subsub
> ...
> subsub.Blargle()

Okay.  Later in my rant I wrote:

< Well: at least if people use 'from' to import arbitrary objects and
< classes.  Using 'from package.subpackage import module' is an idiom,
< with which I can live with comfortably.

[Greg Stein]:
> In other words, "from package import module" is a Fine Thing. It can
> simplify your code without hiding where the symbols come from.

Yes, you are right.

But if you put the facade pattern[*] into use within such packages,
this will even simplify your live, if you later have to redesign
the internal substructure of your package.

[*] Design patterns and especially the "facade pattern" were AFAIK 
    introduced in the so called "Gang of four" book: "Design Patterns -
    Elements of Reusable Object-Oriented Software", Addison Wesley, 1995.

    The somewhat similar "whole part" design pattern is discussed 
    in the book "A System of Patterns" written by Buschmann, Meunier, 
    Rohnert, Sommerlad, Stal; published by John Wiley & Sons, New York; 1996; 
    ISBN 0 471 95869 7

> In general, I agree with you: importing symbols from a module into your
> namespace is a Bad Thing.

Fine.  Consensus gives a warm and fuzzy feeling. ;-)

Regards, Peter


From esr@thyrsus.com  Thu Jun  8 13:53:51 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 8 Jun 2000 08:53:51 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 08, 2000 at 08:37:04AM -0400
References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>
Message-ID: <20000608085351.A9299@thyrsus.com>

Fred L. Drake, Jr. <fdrake@beopen.com>:
> [Eric S. Raymond]
>  > 
>  >  My top wishlist item is "Burn all your GIFs".
> 
>   Is it more important than accessibility?  This is a real issue for
> legacy browsers, especially on minority platforms.  One of the big
> wins for Python is that it is as portable as it is.  Does that matter
> if information is hard to get to?

Go check out the PNG site's census of PNG support in "legacy"
browsers. Basically, as long as your PNGs don't use transparency or
animation, you're fine.  You've already had the good taste to eschew
animation. I don't think you're using transparency anywhere that 
simply matteing the image on a white background won't fix it -- and
gif2png has an option to do that.

>   A good reason to avoid using images for anything that isn't
> cosmetic!

I agree with that.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Sometimes the law defends plunder and participates in it. Sometimes
the law places the whole apparatus of judges, police, prisons and
gendarmes at the service of the plunderers, and treats the victim --
when he defends himself -- as a criminal.
	-- Frederic Bastiat, "The Law"


From jeremy@beopen.com  Thu Jun  8 14:58:42 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 8 Jun 2000 09:58:42 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.)
In-Reply-To: <20000607210555.X3348@lyra.org>
References: <20000607101146.D5559@ludwig.cnri.reston.va.us>
 <Pine.GSO.4.10.10006071731200.2293-100000@sundial>
 <20000607210555.X3348@lyra.org>
Message-ID: <14655.42642.608768.433695@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:

  GS> On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote:
  >> On Wed, 7 Jun 2000, Greg Ward wrote:
  >> 
  >> > CNRI has absolutely no moral right to it (although probably
  >> some legal > right), I'd prefer to sign it away to Guido.  Or
  >> optionally, to some > legal fiction that represents the Python
  >> community; preferably *not* the > Python Consortium, as long as
  >> CNRI is in any way connected.
  >> 
  >> Who's in charge of the PSA?

  GS> CNRI

  GS> Effectively, the PSA is a legal fiction for collecting donations
  GS> to further the development of Python. The Consortium is similar,
  GS> but members have the actual/explicit capability to steer
  GS> Python's development. I believe this ability to steer the
  GS> development is (was?) rooted in the fact that CNRI employed
  GS> Guido. I have no idea how that will work now -- the "steering"
  GS> will (essentially) have to rely entirely on Guido's good
  GS> graces. Guido is an excellent listener to people's needs, so
  GS> there is no immediate problem here.

The description of the PSA isn't exactly right.  The PSA FAQ has an
official explanation, which may not be right either, but at least it's
what CNRI wants you to think.  (And it may be right; I don't mean to
suggest a nefarious plot, just that the relationship is convoluted
enough that the explanation could be wrong.)

http://www.python.org/psa/FAQ.html

An abbreviated version follows:

|Where does the money from membership fees go and who pays the rest?
|
|    The money goes towards the salary of those who maintain and
|    coordinate the Python web site, ftp server, mailing lists,
|    conference expenses etc....  The case for these expenditures is
|    that a seed community is being incubated. CNRI officers and
|    directors see proof of the existence of such a community from the
|    fact that some members of that community are willing to pay some
|    of their own money to foster the activity.
|
|Who funds Python's development?
|    PSA fees do not fund the Python development effort....


CNRI is no longer maintaining python.org, although it still owns the
domain and maintains the equipment it runs on.  The existence of a
community should be obvious now, without the need for people to pay
money to prove it.

Jeremy

    


From skip@mojam.com (Skip Montanaro)  Thu Jun  8 15:08:13 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 8 Jun 2000 09:08:13 -0500
Subject: [Python-Dev] impact of cycle gc...
Message-ID: <200006081408.JAA03136@beluga.mojam.com>

I spent a little time poking around with a very simple test script
(appended) that makes use of Neil's cycle gc patch.  It measures the time it
takes to instantiate and delete a cycle-producing instance 100,000 times
(based upon a report in python-bugs).  For vanilla 1.6a2 ("./configure" ;
make") I got the following (last of six runs):

    memory usage @ start: 5560
    clock: 1.33 elapsed: 1.34805500507
    memory usage @ end: 18816

For 1.6a2 configured --with-cycle-gc ("./configure --with-cycle-gc ; make")
I got the following (also the last of six runs):

    memory usage @ start: 5576
    clock: 2.34 elapsed: 2.33785700798
    memory usage @ end: 5576

I was very impressed with the memory usage, but dismayed at the increased
execution time (about 75% more).  Of course, this is a test script that is
bound to show the potential performance penalty in the worst possible light.
Maybe pystone will be more indicative of the performance hit we can expect
from it.  (There's a new one - pystone.py being a better indicator of true
system performance than some other test script!)

Plain:

    Pystone(1.1) time for 10000 passes = 1.76
    This machine benchmarks at 5681.82 pystones/second

--with-cycle-gc:

    Pystone(1.1) time for 10000 passes = 1.83
    This machine benchmarks at 5464.48 pystones/second

That suggests something more like a 4% performance penalty.  I suspect that
may be the lower limit.  While I haven't looked at pystone recently, I doubt
it creates any cyclic garbage.

My next step will be to try it out on my development database server and see 
what happens.

just-another-data-point-ly y'rs,

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
"We have become ... the stewards of life's continuity on earth.  We did not
ask for this role...  We may not be suited to it, but here we are."
- Stephen Jay Gould



class fred:
    def __init__(self):
        self.indirectFunc = self.theFunc

    def theFunc(self):
        return "blah"

def test():
    f = fred()
    del f


if __name__ == "__main__":
    import os, time, sys
    sys.stdout.write("memory usage @ start: ")
    sys.stdout.flush()
    os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'")
    t = time.clock(), time.time()
    for x in xrange(100000):
        test()
    print "clock:", time.clock()-t[0], "elapsed:", time.time()-t[1]
    sys.stdout.write("memory usage @ end: ")
    sys.stdout.flush()
    os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'")


From gmcm@hypernet.com  Thu Jun  8 15:48:01 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Thu, 8 Jun 2000 10:48:01 -0400
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk>
References: <20000608030555.532221CDEF@dinsdale.python.org>
Message-ID: <1251646781-15052905@hypernet.com>

Andy wrote:

> 1. use of __init__ to save users work
[package structure]
> reportlab
>     pdfgen
>         canvas.py  defines class Canvas
>         textobject.py defines class TextObject
>         pathobject.py defines class PathObject
>     platypus
>         (the same problem, but 3x worse)
>     lib
>         (loads of modules, all independent)

> ---reportlab/pdfgen/__init__.py--------
> from canvas import Canvas
> from textobject.py import TextObject
> from pathobject.py impory PathObject

I would suggest that these not use relative names. 

from reportlab.pdfgen.canvas import Canvas

will ensure that Canvas is only found in one way (no matter 
where the script is, or rather, what sys.path[0] evaluates to at 
import time).

Your other choice is to disallow any scripts within reportlab/ 
and deliver 220 V shocks to any user who starts Python 
anyplace within reportlab/ (or otherwise lets any part of 
sys.path evaluate to anything within reportlab/).
 
> Then users can just do:
> from reportlab.pdfgen import Canvas, PathObject, TextObject
> 
> It seems that this (a) makes life easier for users, and
> (b) gives us freedom to refactor code as it grows, without
> changing the user interface.  

Since you're doing this for "convenience", another option is to 
provide convenience methods:

def newCanvas():
  return reportlab.pdfgen.canvas.Canvas()

> 2. Ambiguities running scripts within package
> ---------------------------------------------

> Should test scripts all be moved out of the package?  
> Indeed, is Python behaving the way it ought to?

If you use relative imports, yes. But even so, you incur a risk 
in using relative imports (see above). And you only do it from 
laziness. So I say don't use relative imports.

> 3. Preferred subpackage import technique
> ----------------------------------------
> I have two scripts 'spam.py' and 'eggs.py' in
> subpackage 'A.B'.  spam imports eggs.
> Should it say...
>    import eggs
> or...
>    import A.B.eggs?

You know what I'm going to say...

- Gordon


From mal@lemburg.com  Thu Jun  8 15:48:49 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 16:48:49 +0200
Subject: [Python-Dev] revamped Python web site
References: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <393FB251.6100175B@lemburg.com>

Jeremy Hylton wrote:
> 
> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?
> 
> If you've got any ideas, please get back to me soon.

Why not turn python.org into a Python portal site with all the
jazz that goes with it, e.g. newsletters, browsable news
forums for different news aspects (business news, new developments,
press references, Python related meetings, etc.), customization
of the information layout, email notification when things
change, chat forums, a Python knowledge base, etc. etc.

The reasoning is that Python is starting to go business and
the site should reflect this move. As more
companies start producing Python tools, I think it might
even be worthwhile considering Python related marketing
on the Python site, e.g. small banners, external links, etc.
This would help finance the site and its administrators.

As far as content goes, I think Python.org is hardly beatable :-)
What's missing is some more service to push its fun factor
which in return pushes Python's acceptance.

Anyway, just a thought...
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From mal@lemburg.com  Thu Jun  8 15:54:01 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 16:54:01 +0200
Subject: [Python-Dev] Package ambiguities
References: <393eb52b.47053339@post.demon.co.uk>
 <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain>
Message-ID: <393FB389.893D20E3@lemburg.com>

Jeremy Hylton wrote:
> 
> Gordon's comments are on the money.  An import in a module inside a
> package should be fully qualified.  I'd put that in the style guide if
> it were up to me (and, of course, it's not).

+1 from here :-)

I usually write things like this:

from mx.DateTime import now
print 'The time is', now()

If you don't do so, you'll run into strange problems, the most
subtle one I've encountered is with pickled objects... if unpickled
inside the same package they can cause the same module to
be loaded *twice* with all the consequences attached to this 
(e.g. issubclass() no longer works).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From mal@lemburg.com  Thu Jun  8 16:20:23 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 17:20:23 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects
 unicodeobject.c,2.21,2.22
References: <200006070913.CAA18060@slayer.i.sourceforge.net> <20000607193537.Q3348@lyra.org>
Message-ID: <393FB9B7.B93A7C61@lemburg.com>

Greg Stein wrote:
> 
> On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote:
> > Update of /cvsroot/python/python/dist/src/Objects
> > In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects
> >
> > Modified Files:
> >       unicodeobject.c
> > Log Message:
> > Marc-Andre Lemburg <mal@lemburg.com>:
> > Change the default encoding to 'ascii' (it was previously
> > defined as UTF-8).
> >
> > Note: The implementation still uses UTF-8 to implement
> > the buffer protocol, so C APIs will still see UTF-8. This
> > is on purpose: rather than fixing the Unicode implementation,
> > the C APIs should be made Unicode aware.
> 
> I'm a little confused on where this gets applied. Is this when somebody says
> "str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when
> somebody says "unicode(str)" and we expect <str> to be ASCII?

The buffer protocol is used for "s", "t" and "s#" argument
parsing in C. Since these pass back pointers to internal
buffers of the object which must be kept alive until the
object is GCed, there's no easy way to change the
encoding of that buffer. 

To play safe I left that buffer
encoded in UTF-8 (the hash value is also computed from the
UTF-8 encoding of the unicode value to make it compatible to
ASCII 8-bit strings).

Note that both str(unicode) and unicode(str) will use
the default encoding. %-formatting and comparisons also
use the default encoding.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From mal@lemburg.com  Thu Jun  8 16:08:45 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 17:08:45 +0200
Subject: [Python-Dev] Idea: emulating _locale
References: <m12zcE0-000DifC@artcom0.artcom-gmbh.de> <393E2304.4BE8CDE0@lemburg.com> <20000607193014.P3348@lyra.org>
Message-ID: <393FB6FD.AB0124E2@lemburg.com>

Greg Stein wrote:
> 
> On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote:
> >...
> > Peter Funk wrote:
> >...
> > > > + ### C lib locale APIs
> > > > +
> > > > + from _locale import *
> > >
> > > Wouldn't it be clever to provide some dummy stubs on those platforms, where
> > > the _locale module was not enabled?
> > >
> > > try:
> > >     from _locale import *
> > > except:
> > >     def setlocale(....
> > >     def localeconv(....
> > >     ...
> > >
> > > Especially the MacOS 1.5.2 release provided by Jack Jansen was
> > > compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
> > > is still disabled per default in 'Modules/Setup.in'.  I didn't had
> > > a look into the current CVS though, so this may have changed.
> > >
> > > I think the name aliasing tables might be also useful on those
> > > systems lacking locale support in their C-library.
> >
> > setlocale and localeconv are ANSI C and Python requires an ANSI C
> > compiler, so there should be no problem (at least in theory).
> >
> > If there is a problem, adding the missing symbols would
> > be no problem: the APIs could always report locale 'C'
> > and its numeric settings.
> 
> An ANSI C compiler and the ANSI C library are very different. Just because
> Python requires an ANSI compiler (or close to it), does NOT mean that we can
> or should depend upon particular elements in the library.

Well, ok, it's POSIX.1 too, but...
 
> IMO, we should follow Peter's advice and have stubs for the platforms where
> _locale is not built.

...ok, since it doesn't hurt, I'll add some dummies to locale.py
which return the same thing as the 'C' locale.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From pingster@ilm.com  Thu Jun  8 18:10:46 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Thu, 8 Jun 2000 10:10:46 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26
In-Reply-To: <20000607200624.R3348@lyra.org>
Message-ID: <Pine.SGI.3.96.1000608100602.428158D-100000@happy>

On Wed, 7 Jun 2000, Greg Stein wrote:
> Gah... "pattern_re.match (cur_base)" ...
> 
> You do realize that God intended there to be no spaces between a function
> name and the opening paren? Heretic!
[...]
> Put another way: when
> you skim code, NAME( is a function call and NAME ( is something else. A
> space after a name usually indicates the name is participating in an
> expression, rather than being used as a function name.

Yesyesyes!

This is an absolute rule for me (in other languages too: in C, for
example, *always* a space between "if" or "for" and the open-paren).

I colourize based on this.  It's great -- the one green word on the
line stands out; it's the verb, and that lets me know what's going
on at a quick glance.

(My "Principle of Syntax Highlighting" is to highlight not by what
things are, but by what *role* they play.  Defining occurrence of
anything is a biggie.  Comments and docstrings are coloured alike;
docstrings are not data.  And so on.)


-- ?!ng



From klm@digicool.com  Thu Jun  8 19:38:32 2000
From: klm@digicool.com (Ken Manheimer)
Date: Thu, 8 Jun 2000 14:38:32 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com>

On Wed, 7 Jun 2000, Jeremy Hylton wrote:

> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?
> 
> If you've got any ideas, please get back to me soon.

Here's some suggestions - i put things more important to me closer to the
top, more or less.

1. Delegation of sections to individuals or groups.  Eg:

  - topic guides - particular people get management of areas.  (Of
    course, i'd do this with zope, including zwiki pages as well as
    regular zope documents for the respective topic-guide managers
    to use in constructing their content - and for delegating or openning
    up portions of *their* sections to others...)

  - The humor page (i'm sad to see that languishing)

  - Other incidental stuff in the Documentation section of the current
    site

2. Community-contributed news and hints - portal-style membership/
   contribution of news items, reviewed for release or rejection (maybe
   with community-based reviewers voting) 

3. Vaults of parnassus already does this, but i'll still mention - 
   Contributed software/docs/etc - managed similar to moderated news
   postings, but with classification/cataloguing of artifacts, ability for
   people to vote on desirability for ranking purposes

5. Jobs board - job postings possibly also managed with news-style
   reviewing process

6. Subscription to pages, to get notifcations when they change (probably
   batched, so people don't get too many as something is undergoing
   development).

7. Discussion "area" for coordinating and collecting logs of IRC-style
   chats when hot-topics arise that need rendezvous.

8. Open community wiki(s) for growing interesting little worlds (and with
   my new zwiki nesting-organization features, it may not be too chaotic).

Ken
klm@digicool.com



From gvwilson@nevex.com  Thu Jun  8 19:45:37 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Thu, 8 Jun 2000 14:45:37 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com>
Message-ID: <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>

> Ken Manheimer said
> 3. Vaults of parnassus already does this, but i'll still mention - 
>    Contributed software/docs/etc - managed similar to moderated news
>    postings, but with classification/cataloguing of artifacts, ability for
>    people to vote on desirability for ranking purposes

I'd like to see the Vaults, Starship, and other sub-sites folded into, or
become subsections of, a larger Python site, so that I've got the same
kind of one-stop shopping that CPAN gives me.

Thanks,

Greg




From esr@thyrsus.com  Thu Jun  8 19:54:45 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 8 Jun 2000 14:54:45 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400
References: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com> <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>
Message-ID: <20000608145445.A10500@thyrsus.com>

Greg Wilson <gvwilson@nevex.com>:
> > Ken Manheimer said
> > 3. Vaults of parnassus already does this, but i'll still mention - 
> >    Contributed software/docs/etc - managed similar to moderated news
> >    postings, but with classification/cataloguing of artifacts, ability for
> >    people to vote on desirability for ranking purposes
> 
> I'd like to see the Vaults, Starship, and other sub-sites folded into, or
> become subsections of, a larger Python site, so that I've got the same
> kind of one-stop shopping that CPAN gives me.

Second that.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Such are a well regulated militia, composed of the freeholders,
citizen and husbandman, who take up arms to preserve their property,
as individuals, and their rights as freemen.
        -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" 
            referred to in the Second Amendment to the Constitution.


From gmcm@hypernet.com  Thu Jun  8 19:57:51 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Thu, 8 Jun 2000 14:57:51 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com>
References: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <1251631791-15954519@hypernet.com>

From Ken Manheimer's Python web site wishlist:

>   - The humor page (i'm sad to see that languishing)

A weekly nude Tim Peters jpeg!

- Gordon


From fdrake@beopen.com  Thu Jun  8 20:46:00 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 8 Jun 2000 15:46:00 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <20000608085351.A9299@thyrsus.com>
References: <20000607174148.A6801@thyrsus.com>
 <200006081027.MAA02445@python.inrialpes.fr>
 <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>
 <20000608085351.A9299@thyrsus.com>
Message-ID: <14655.63480.384525.129125@cj42289-a.reston1.va.home.com>

Eric S. Raymond writes:
 > Go check out the PNG site's census of PNG support in "legacy"
 > browsers. Basically, as long as your PNGs don't use transparency or
 > animation, you're fine.  You've already had the good taste to eschew

  Excellent!  I'll review the list next week probably.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From jeremy@beopen.com  Thu Jun  8 21:24:51 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 8 Jun 2000 16:24:51 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <1251631791-15954519@hypernet.com>
References: <14654.48609.710990.321688@localhost.localdomain>
 <1251631791-15954519@hypernet.com>
Message-ID: <14656.275.83488.186898@localhost.localdomain>

>>>>> "GM" == Gordon McMillan <gmcm@hypernet.com> writes:

  >> From Ken Manheimer's Python web site wishlist: - The humor page
  >> (i'm sad to see that languishing)

  GM> A weekly nude Tim Peters jpeg!

We were going to keep those on the pythonlabs.com internal site, but
if Tim doesn't object...

Jeremy



From jeremy@beopen.com  Thu Jun  8 22:19:49 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 8 Jun 2000 17:19:49 -0400 (EDT)
Subject: [Python-Dev] impact of cycle gc...
In-Reply-To: <200006081408.JAA03136@beluga.mojam.com>
References: <200006081408.JAA03136@beluga.mojam.com>
Message-ID: <14656.3573.754658.791617@localhost.localdomain>

Skip,

I don't have time today to look at your post in detail, but one thing
you said rtiggered a pretty immediate response: We should worry more
about the GC performance on examples like the one you posted, and less
about pystone.  

pystone is a good benchmark for testing the overhead in cases when the
garbage collector isn't invoked.  There's so little memory allocation
that nothing interesting happens.  The GC patch ought to have no
effect in this case.  I suppose 4% is okay.

The worry is about programs that allocate a lot of objects, even if
they never create circular references.  The compiler test is one
example, because the parser tree consumes an enormous number of tuples
and objects.

I suspect big slowdowns like the one you posted just mean we don't
know how to adjust the tuneable parameters.

Jeremy



From gstein@lyra.org  Fri Jun  9 01:01:08 2000
From: gstein@lyra.org (Greg Stein)
Date: Thu, 8 Jun 2000 17:01:08 -0700
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400
References: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com> <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>
Message-ID: <20000608170108.B16880@lyra.org>

On Thu, Jun 08, 2000 at 02:45:37PM -0400, Greg Wilson wrote:
> > Ken Manheimer said
> > 3. Vaults of parnassus already does this, but i'll still mention - 
> >    Contributed software/docs/etc - managed similar to moderated news
> >    postings, but with classification/cataloguing of artifacts, ability for
> >    people to vote on desirability for ranking purposes
> 
> I'd like to see the Vaults, Starship, and other sub-sites folded into, or
> become subsections of, a larger Python site, so that I've got the same
> kind of one-stop shopping that CPAN gives me.

+1 on that!

If python.org opens up (beyond what was possible w.r.t CNRI's security
policy), then I see a lot of the impetus for separate sites, such as
Starship and Parnassus, simply disappearing.

While we're at it: Python-URL has some funny location that I can't ever
remember. Providing a way for the organizers to publish those onto
python.org (and maintain the archive there) would be good. If /F is still
doing the daily URL, then it could go there, too...

Cheers,
-g

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


From nascheme@enme.ucalgary.ca  Fri Jun  9 02:29:00 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 8 Jun 2000 19:29:00 -0600
Subject: [Python-Dev] impact of cycle gc...
Message-ID: <20000608192900.A21668@acs.ucalgary.ca>

Just a few points and then I will get off python-dev. :)

First of all, I don't think it is very meaningful to use leaking
applications to do timing comparisons.  The collector has be
quite careful when freeing structures containing reference
cycles.  However, using something other than pystone is
definitely a good idea.

Here the pybench results for the latest patch:

PYBENCH 0.6

Benchmark: b_nogc (rounds=4, warp=30)

Tests:                              per run    per oper.  diff *
------------------------------------------------------------------------
          BuiltinFunctionCalls:     286.25 ms    3.37 us   -4.22%
           BuiltinMethodLookup:     367.50 ms    1.05 us   -4.55%
                 ConcatStrings:     368.37 ms    3.68 us  +42.50%
               CreateInstances:     477.87 ms   17.07 us   -4.45%
       CreateStringsWithConcat:     322.12 ms    2.42 us  +10.27%
                  DictCreation:     382.75 ms    3.83 us   +1.29%
                      ForLoops:     536.88 ms   80.73 us   +0.99%
                    IfThenElse:     432.75 ms    0.96 us   -3.21%
                   ListSlicing:     236.87 ms  104.12 us  +11.73%
                NestedForLoops:     320.00 ms    1.28 us   +0.16%
          NormalClassAttribute:     386.50 ms    0.97 us   +0.00%
           PythonFunctionCalls:     477.87 ms    4.34 us   -3.51%
             PythonMethodCalls:     379.12 ms    7.59 us  -12.67%
                     Recursion:     280.75 ms   33.70 us   -0.88%
                  SecondImport:     206.62 ms   12.41 us   -5.76%
           SecondPackageImport:     216.75 ms   13.02 us   -4.41%
         SecondSubmoduleImport:     279.25 ms   16.77 us   -2.57%
       SimpleComplexArithmetic:     351.00 ms    2.39 us   +0.72%
        SimpleDictManipulation:     320.75 ms    1.60 us   -2.99%
         SimpleFloatArithmetic:     361.50 ms    0.99 us  -20.37%
      SimpleIntFloatArithmetic:     336.00 ms    0.76 us   +0.04%
       SimpleIntegerArithmetic:     328.38 ms    0.75 us   -0.76%
        SimpleListManipulation:     312.88 ms    1.74 us   -1.61%
          SimpleLongArithmetic:     308.75 ms    2.81 us   +9.88%
                    SmallLists:     470.13 ms    2.77 us   -5.05%
                   SmallTuples:     374.62 ms    2.34 us  -15.74%
         SpecialClassAttribute:     384.00 ms    0.96 us   -1.88%
      SpecialInstanceAttribute:     446.38 ms    1.12 us   -2.75%
                 StringSlicing:     315.50 ms    2.70 us  +16.58%
                     TryExcept:     585.37 ms    0.59 us   -1.70%
                TryRaiseExcept:     312.75 ms   31.28 us   -5.30%
                  TupleSlicing:     299.38 ms    4.39 us  +12.18%
------------------------------------------------------------------------
            Average round time:   13615.00 ms              -1.13%

My AMD-K6-II processor is a pretty quirky beast so I don't think
you can conclude too much for those results.  Here are the
median timings from running Jeremy's compiler on its own source:

	$ time python compile.py `find . -name '*.py'`

Python 1.6 without GC:

	real    0m16.926s
	user    0m16.810s
	sys     0m0.110s

Python 1.6 with GC:

	real    0m21.593s
	user    0m21.470s
	sys     0m0.080s

Python 1.6 with GC, collection disabled (ie. gc.set_threshold(0)):

	real    0m18.441s
	user    0m18.220s
	sys     0m0.220s

We can tune the collection frequency all we want but we won't do
any better than the last numbers.  Those numbers reflect the cost
of keeping track of the objects and the increase in object size.

On a related note, I would like to cleanup the PyGC_{NEW,
VAR_NEW} macros but I can't figure out a way to transform this
code into a macro:

    op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp));
    if (op)
        op = PyGC_OBJ((PyGCInfo *)op);

If C's || operator was like the Python or I could do something
like:

    #define PyGC_OBJ_SAFE(g) ((PyGCInfo *)(((g) || -1) + 1))

Any ideas?  Using an inline function in the header file would
be nice but of course it is not portable.  GCC has statement
expressions but again they are not portable.

    Neil


From Vladimir.Marangozov@inrialpes.fr  Fri Jun  9 03:03:59 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Fri, 9 Jun 2000 04:03:59 +0200 (CEST)
Subject: [Python-Dev] impact of cycle gc...
In-Reply-To: <20000608192900.A21668@acs.ucalgary.ca> from "Neil Schemenauer" at Jun 08, 2000 07:29:00 PM
Message-ID: <200006090204.EAA11518@python.inrialpes.fr>

Neil Schemenauer wrote:
> 
> On a related note, I would like to cleanup the PyGC_{NEW,
> VAR_NEW} macros but I can't figure out a way to transform this
> code into a macro:
> 
>     op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp));
>     if (op)
>         op = PyGC_OBJ((PyGCInfo *)op);

The correct thing to do, IMO, is to reflect the sizeof(PyGCInfo)
mem increment in the tp_basicsize slot of the type object. Thus, we can
reuse the current PyObject_New/NEW code, which boils down to
PyObject_MALLOC(_PyObject_SIZE(tp)).  There is no need for PyGC_NEW/NEW_VAR.

This would imply some additional changes to PyObject_Init when the
GC_FLAG is set for a given typeobj.

I had a closer look at the patch today. It looks good, but I think it
needs some more work for a smooth integration with the existing APIs.
There's room for optimisations (there are lots of function calls in there,
so I am not surprised about the performance hit), but they'll come
later on, once the big chunks of the patch fit in their places.

One thing that bothered me is that the current gc object allocation
code won't fly with C++, where the object storage is allocated (and its
size is computed) automatically. There is no PyObject_New, and a C++
object constructor is supposed to begin with PyObject_Init.

Another thing is the function names: PyGC_NEW, PyGC_Info, PyGC_Insert, etc.
It would be better if they reflect the fact that we're talking about GC
on PyObjects, and not about GC in general (on arbitrary mem chunks).

I would suggest renaming them along these lines:

PyGC_Info -> PyGC_ObjectHead
PyGC_Insert -> PyGC_ObjectInit
PyGC_Remove -> PyGC_ObjectFini
...

All this needs some more thought though...

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From mal@lemburg.com  Fri Jun  9 12:03:56 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 09 Jun 2000 13:03:56 +0200
Subject: [Python-Dev] Japanese Codecs
Message-ID: <3940CF1C.2C625624@lemburg.com>

Python currently supports lots of different code pages and
other more specific codecs. I was wondering what your thoughts
on this are: should we proceed to include an even wider range
of codecs or limit the available number to an absolute minimum ?

I'm asking this, because Tamito KAJIYAMA wrote a set of
codecs for EUC-JP and Shift_JIS which would probably
be very useful for Japanese Python users -- I just don't
know how many there are and whether inclusion of an extra
650k of source code would hurt or not.

Thoughts ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From akuchlin@mems-exchange.org  Fri Jun  9 16:08:46 2000
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Fri, 9 Jun 2000 11:08:46 -0400
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <3940CF1C.2C625624@lemburg.com>; from mal@lemburg.com on Fri, Jun 09, 2000 at 01:03:56PM +0200
References: <3940CF1C.2C625624@lemburg.com>
Message-ID: <20000609110846.C10688@amarok.cnri.reston.va.us>

On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote:
>I'm asking this, because Tamito KAJIYAMA wrote a set of
>codecs for EUC-JP and Shift_JIS which would probably
>be very useful for Japanese Python users -- I just don't
>know how many there are and whether inclusion of an extra
>650k of source code would hurt or not.

This seems too much code added that would only be of use to a limited
audience, so -1 from me.  Japanese packagers of Python would probably
include them, of course.

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I confidently expect it to be a fairly resounding failure.
  -- John Cleese, on the Monty Python reunion planned for 1999






From skip@mojam.com (Skip Montanaro)  Fri Jun  9 16:19:59 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 9 Jun 2000 10:19:59 -0500 (CDT)
Subject: [Python-Dev] impact of cycle gc...
In-Reply-To: <14656.3573.754658.791617@localhost.localdomain>
References: <200006081408.JAA03136@beluga.mojam.com>
 <14656.3573.754658.791617@localhost.localdomain>
Message-ID: <14657.2847.914770.368965@beluga.mojam.com>

    Jeremy> I don't have time today to look at your post in detail, but one
    Jeremy> thing you said rtiggered a pretty immediate response: We should
    Jeremy> worry more about the GC performance on examples like the one you
    Jeremy> posted, and less about pystone.

I wasn't really worried about pystone, just looking for something quick that
didn't generate cycles... ;-)

Your suggestion is an excellent one.  To try and account for the typical
case, I modified the test slightly.  I added a new class, ethyl:

    def foo():
	pass

    class ethyl:
	def __init__(self):
	    self.indirectFunc = foo

	def theFunc(self):
	    return "blah"

which performs essentially the same work at instantiation time as fred, but
doesn't create a cycle.  The time (in seconds) to create and delete 100,000
freds and ethyls with and without cycle-gc enabled looks like (last of six
consecutive runs):

			./python		./python-cycle-gc
    fred (cycle)	1.4			2.51
    ethyl (no cycle)	1.39			1.55

The memory consumption is as you would expect - leaky when creating fred's
without using cycle-gc, stable otherwise.

So, the penalty for creating and deleting objects that don't contain cycles
would appear to be reasonable (about 10-15%).  As more experience is gained
with it, I imagine it can be reduced further.

Skip



From mal@lemburg.com  Fri Jun  9 16:32:41 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 09 Jun 2000 17:32:41 +0200
Subject: [Python-Dev] Japanese Codecs
References: <3940CF1C.2C625624@lemburg.com> <20000609110846.C10688@amarok.cnri.reston.va.us>
Message-ID: <39410E19.4E4B1EE7@lemburg.com>

"Andrew M. Kuchling" wrote:
> 
> On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote:
> >I'm asking this, because Tamito KAJIYAMA wrote a set of
> >codecs for EUC-JP and Shift_JIS which would probably
> >be very useful for Japanese Python users -- I just don't
> >know how many there are and whether inclusion of an extra
> >650k of source code would hurt or not.
> 
> This seems too much code added that would only be of use to a limited
> audience, so -1 from me.  Japanese packagers of Python would probably
> include them, of course.

I just wish that these packagers actually become a reality
some day... the concept is good, but there currently seem to
be no volunteers or companies jumping in :-(

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From DavidA@ActiveState.com  Fri Jun  9 19:54:03 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Fri, 9 Jun 2000 11:54:03 -0700
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <39410E19.4E4B1EE7@lemburg.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com>

> I just wish that these packagers actually become a reality
> some day... the concept is good, but there currently seem to
> be no volunteers or companies jumping in :-(

I can't speak for Japanese packagers, but ActiveState will be packaging
Python in various ways.

--david



From klm@digicool.com  Fri Jun  9 19:59:26 2000
From: klm@digicool.com (Ken Manheimer)
Date: Fri, 9 Jun 2000 14:59:26 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14656.275.83488.186898@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0006081731080.675-100000@korak.digicool.com>

On Thu, 8 Jun 2000, Jeremy Hylton wrote:

> >>>>> "GM" == Gordon McMillan <gmcm@hypernet.com> writes:
> 
>   >> From Ken Manheimer's Python web site wishlist: - The humor page
>   >> (i'm sad to see that languishing)
> 
>   GM> A weekly nude Tim Peters jpeg!
> 
> We were going to keep those on the pythonlabs.com internal site, but
> if Tim doesn't object...

Anything for a buck, ay, now that you're in the commercial world?-)

Ken
klm@digicool.com



From tim_one@email.msn.com  Fri Jun  9 20:11:42 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 9 Jun 2000 15:11:42 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.21.0006081731080.675-100000@korak.digicool.com>
Message-ID: <000c01bfd246$8c02ca40$a12d153f@tim>

[KenM]
> - The humor page (i'm sad to see that languishing)

[Gordon, as always, guides our youth]
> A weekly nude Tim Peters jpeg!

[JeremyH]
> We were going to keep those on the pythonlabs.com internal site, but
> if Tim doesn't object...

[KenM]
> Anything for a buck, ay, now that you're in the commercial world?-)

After one of my recent "going away" parties here (I "get to" move to VA next
week), a group of old chums were sitting around the restaurant table,
belching up bad Italian cooking and speculating on our places in God's
Inscrutable Plan.  When it came time to pick on me, one naturally pugnacious
fellow-- emboldened beyond his normal aggression by wine --looked me
straight in the eye and demanded to know if there's *anything* I wouldn't do
for money.  Well, in point of fact I believe there are a great many such
things, but in the moment God only inspired me with one, and so I heard
myself retorting:  "Ya, sure, I'd fuck a dog for science ... but I wouldn't
take a job at Microsoft!".

strangely-enough-i-think-that's-backwards-ly y'rs  - tim




From Moshe Zadka <moshez@math.huji.ac.il>  Fri Jun  9 20:20:17 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Fri, 9 Jun 2000 22:20:17 +0300 (IDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <000c01bfd246$8c02ca40$a12d153f@tim>
Message-ID: <Pine.GSO.4.10.10006092217350.28979-100000@sundial>

On Fri, 9 Jun 2000, Tim Peters wrote:

> In the moment God only inspired me with one, and so I heard
> myself retorting:  "Ya, sure, I'd fuck a dog for science ... but I wouldn't
> take a job at Microsoft!".
> 
> strangely-enough-i-think-that's-backwards-ly y'rs  - tim

Backwards? You mean you'd fuck Microsoft for science but wouldn't take a
job at a dog? Or you'd fuck a dog for Microsoft but wouldn't take a job at
science? Or you'd take a job for science, but wouldn't fuck at Microsoft?

misunderstanding-tim-seems-to-be-a-common-pass-time-around-here-ly y'rs, Z

--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



Return-Path: <moshez@math.huji.ac.il>
Delivered-To: python-dev@python.org
Received: from math.ma.huji.ac.il (ma.huji.ac.il [132.64.32.5])
	by dinsdale.python.org (Postfix) with ESMTP
	id C19A61CD28; Fri,  9 Jun 2000 14:37:53 -0400 (EDT)
Received: from localhost (moshez@localhost)
	by math.ma.huji.ac.il (8.9.1b+Sun/8.9.3) with ESMTP id VAA28640;
	Fri, 9 Jun 2000 21:37:03 +0300 (IDT)
Date: Fri, 9 Jun 2000 21:37:03 +0300 (IDT)
From: Moshe Zadka <moshez@math.huji.ac.il>
X-Sender: moshez@sundial
Reply-To: Moshe Zadka <moshez@math.huji.ac.il>
To: perl_monkey@my-deja.com
Cc: python-list@python.org, s2mdalle@titan.vcu.edu
In-Reply-To: <8hrbph$a4n$1@nnrp1.deja.com>
Message-ID: <Pine.GSO.4.10.10006092133190.28574-100000@sundial>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Python-Dev] Re: Porting CPython
Sender: python-dev-admin@python.org
Errors-To: python-dev-admin@python.org
X-BeenThere: python-dev@python.org
X-Mailman-Version: 2.0beta3
Precedence: bulk
List-Id: Python core developers <python-dev.python.org>

Not a lot I can help you with, but:

On Fri, 9 Jun 2000 perl_monkey@my-deja.com wrote:

> - Excluding Modules
> 
> What is the build procedure for omitting certain built in C modules?
> (I"m talking about the stuff in Modules/)

Edit the "Setup.in" file. Instructions for how are inside the file, but if
you have any more specific questions, please ask again.

> Any help on any of these issues would be appreciated.  Also, when/if I
> finish this, I'd be willing to diff the source and put it into the main
> python branch if that's something people would be interested in.

I'm CCing Python-Dev on this, so hopefully someone from the BeOpen team
can respond. I can just say I'm for it. (Python-dev is on BCC so replies
to this won't automatically go there.)

--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From jeremy@beopen.com  Fri Jun  9 22:00:09 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 9 Jun 2000 17:00:09 -0400 (EDT)
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com>
References: <39410E19.4E4B1EE7@lemburg.com>
 <PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com>
Message-ID: <14657.23257.478479.141319@localhost.localdomain>

>>>>> "DA" == David Ascher <DavidA@ActiveState.com> writes:

  >> I just wish that these packagers actually become a reality some
  >> day... the concept is good, but there currently seem to be no
  >> volunteers or companies jumping in :-(

  DA> I can't speak for Japanese packagers, but ActiveState will be
  DA> packaging Python in various ways.

BeOpen also has packaging plans :-).

Jeremy


From mal@lemburg.com  Fri Jun  9 22:49:37 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 09 Jun 2000 23:49:37 +0200
Subject: [Python-Dev] Japanese Codecs
References: <39410E19.4E4B1EE7@lemburg.com>
 <PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com> <14657.23257.478479.141319@localhost.localdomain>
Message-ID: <39416671.AF78100F@lemburg.com>

Jeremy Hylton wrote:
> 
> >>>>> "DA" == David Ascher <DavidA@ActiveState.com> writes:
> 
>   >> I just wish that these packagers actually become a reality some
>   >> day... the concept is good, but there currently seem to be no
>   >> volunteers or companies jumping in :-(
> 
>   DA> I can't speak for Japanese packagers, but ActiveState will be
>   DA> packaging Python in various ways.
> 
> BeOpen also has packaging plans :-).

Sounds cool.

I just hope that someone will hint me of the first Python IPO
*before* it hits NASDAQ ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From Fredrik Lundh" <effbot@telia.com  Fri Jun  9 22:59:18 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 9 Jun 2000 23:59:18 +0200
Subject: [Python-Dev] Japanese Codecs
References: <39410E19.4E4B1EE7@lemburg.com><PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com> <14657.23257.478479.141319@localhost.localdomain>
Message-ID: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid>

> I can't speak for Japanese packagers, but ActiveState will be
> packaging Python in various ways.
>=20
> BeOpen also has packaging plans :-).

get in line, guys ;-)

</F>



From esr@thyrsus.com  Fri Jun  9 23:19:24 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Fri, 9 Jun 2000 18:19:24 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000609215719.47624E2673@oratrix.oratrix.nl>; from jack@oratrix.nl on Fri, Jun 09, 2000 at 11:57:14PM +0200
References: <20000609215719.47624E2673@oratrix.oratrix.nl>
Message-ID: <20000609181924.A15728@thyrsus.com>

Jack Jansen <jack@oratrix.nl>:
> I include PIL in the standard MacPython and Mac users are apparently
> very happy with that [...]

I think it's time to consider including PIL in the core Python 1.6 release.
I've been following the work being done over there, and I believe the 
code has reached a sufficient level of maturity to justify this.

The "Batteries are included" philosophy seems to me to imply that we
ought to be looking for application libraries to promote into the core
once we're satisfied that they meet core-Pythonic standards of good
API design, stability, general usefulness, and documentation quality.
PIL seems to me like a good candidate on all counts.

Guido has to make the final call, of course.  But let's have the discussion
now so we can develop a yea or nay consensus on ther list.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Society in every state is a blessing, but government even in its best
state is but a necessary evil; in its worst state an intolerable one;
for when we suffer, or are exposed to the same miseries *by a
government*, which we might expect in a country *without government*,
our calamities is heightened by reflecting that we furnish the means
by which we suffer."
	-- Thomas Paine


From pingster@ilm.com  Fri Jun  9 23:28:27 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Fri, 9 Jun 2000 15:28:27 -0700 (PDT)
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000609181924.A15728@thyrsus.com>
Message-ID: <Pine.SGI.3.96.1000609151846.621134V-100000@happy>

On Fri, 9 Jun 2000, Eric S. Raymond wrote:
> Jack Jansen <jack@oratrix.nl>:
> > I include PIL in the standard MacPython and Mac users are apparently
> > very happy with that [...]
> 
> I think it's time to consider including PIL in the core Python 1.6 release.
> I've been following the work being done over there, and I believe the 
> code has reached a sufficient level of maturity to justify this.

I'm +0.  Well, perhaps +0.1.

I guess what i would really be "+" about is something to the effect
of "a popular Linux distribution decides to throw in the .so for PIL".
Then it wouldn't really matter to me whether it was in the "real"
standard distribution.


-- ?!ng

"The police are not here to create disorder. They're here to preserve
disorder."
    -- Former Chicago mayor Daley



From akuchlin@mems-exchange.org  Sat Jun 10 02:52:23 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 9 Jun 2000 21:52:23 -0400
Subject: [Python-Dev] Re: [Image-SIG] RFC: Including PIL in 1.6
In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com>
Message-ID: <20000609215223.A23230@newcnri.cnri.reston.va.us>

On Fri, Jun 09, 2000 at 06:19:24PM -0400, Eric S. Raymond wrote:
>I think it's time to consider including PIL in the core Python 1.6 release.

-1 unless Fredrik says there's a C and Python API for extending PIL that
he's happy with, in which case it's +0.  I've written a few extensions for
PIL and it required a fair amount of grubbing around inside of C structures;
it isn't clear that the structures will be the same in future versions of
PIL.  We don't want to add something that people will extend messily, which
will then make fixing the API more difficult because of backward
compatibility.  (Disclaimer: I haven't looked at PIL 1.1 yet; maybe /F has
documented an API, or maybe he's pretty sure the data structures will remain
the same.)

OTOH, given that the Distutils is making good progress on building RPMs for
an arbitrary Python package, installing PIL may get much easier in future,
reducing the need to add it to the core.  But then Paul always yells at me
for that argument.  :) 

-- 
A.M. Kuchling			akuchlin@mems-exchange.org
Posting "Please send e-mail, since I don't read this group": Poster is
rendered illiterate by a simple trepanation.
  -- Kibo, in the Happynet Manifesto


From akuchlin@mems-exchange.org  Sat Jun 10 03:50:08 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 9 Jun 2000 22:50:08 -0400
Subject: [Python-Dev] What's New: 2nd draft
Message-ID: <20000609225008.A23369@newcnri.cnri.reston.va.us>

We've made a second pass at the "What's New in 1.6" document; the only
unwritten section is IDLE, and I don't think either Moshe or I use IDLE.
Can anyone tell us what the new features are?

Again, suggestions on style, forgotten changes, *anything*, are welcomed:
http://starship.python.net/crew/amk/python/writing/new-python/

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
  "How about you -- what're you up to?"
  "Issue #3."
      -- Vic and Zot, in ZOT! #3
      


From Moshe Zadka <moshez@math.huji.ac.il>  Sat Jun 10 06:29:56 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Sat, 10 Jun 2000 08:29:56 +0300 (IDT)
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid>
Message-ID: <Pine.GSO.4.10.10006100828230.1511-100000@sundial>

On Fri, 9 Jun 2000, Fredrik Lundh wrote:

> > I can't speak for Japanese packagers, but ActiveState will be
> > packaging Python in various ways.
> > 
> > BeOpen also has packaging plans :-).
> 
> get in line, guys ;-)

I wonder if next we'll see threads on slashdot about "PythonOne is just
trying to get on the Python hype. It has nothing to offer except for a 
trivial installer anyone can write in 5 minutes in Python"

(cf: the LinuxOne fiasco)
--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From paul@prescod.net  Thu Jun  8 22:32:27 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 08 Jun 2000 23:32:27 +0200
Subject: [Python-Dev] [Fwd: Re: Case sensitivity]
Message-ID: <394010EB.DBCBC5FD@prescod.net>

Here's a good summary of how XML's case sensitivity came to be.

-------- Original Message --------
Subject: Re: Case sensitivity
Date: Mon, 3 Apr 2000 12:44:37 -0400
From: Steve DeRose <Steven_DeRose@brown.edu>
To: xml-dev@lists.oasis-open.org
References: <B50E2EFA.1B57%soord@vda.nl>

Languages with no need for case folding are not much of  a problem: the
case-folding table or program would merely have no effect on characters
belonging to such languages: It would change 26 of our 26 alphabetic
code
points, and no others. After all, in English we already use lots of
characters that don't get case-folded (like digits).

The serious problems are subtler:

The practical problem that with Unicode your folding table gets really
big;
on the order of 128Kbytes instead of 256 bytes (barring compresson):
this
is a pain on small devices (like a cell-phone browser), a pain to load,
a
pain to implement compression for, etc.

The theoretical problem is more important: it's not the caseless
languages
that pose problems, but the complicated case-folding ones. For example,
lots of languages only apply diacritical marks to lower-case letters:
for
example, "a" may come with 6 different accents, but "A" takes none --
which
makes case-folding unreversible. If there are languages that operate the
other way as well, then neither fold-to-upper nor fold-to-lower can work
for all languages: either way would trash some languages.


That said, I think it incumbent on XML *search engines* to support
case-folding (as well as decent treatment of accents, types of hyphens,
etc) for text content searches: Making English speakers search for

  "the" | "thE" | "tHe" | "tHE" | "The" | "ThE" | "THe" | "THE"
or
  "[tT][hH][eE]

is patently absurd; and besides, there is no user cost to (say) a
Japanese
speaker if an engine *does* case-fold. Also, many languages use Roman
characters occasionally, as for acronyms; so their speakers also pay a
price if searches aren't smart enough. And the primary problems with
case-folding do not weigh so heavily in the search engine world (for
example, AltaVista isn't likely to run their main servers on cell phones
for a while yet).




From esr@thyrsus.com  Sat Jun 10 16:42:27 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 11:42:27 -0400
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
Message-ID: <20000610114227.A19052@thyrsus.com>

Last night I sent the following patch for urllib to python-patches:

# Support for launching a browser

if os.environ.has_key("BROWSER"):
    _browsers = string.split(os.environ["BROWSER"], ":")
else:
    _browsers = ["mozilla %s &",
                "netscape -remote 'openURL(%s)'",
                "netscape %s &",
                "lynx %s &",
                "w3m %s &"]

def urlbrowse(url):
    """Launch a browser, in background, pointed at the given URL.
    Accept either a string or a parsed URL tuple. 
    Interpret the BROWSER environment variable, if it exists,
    as a colon-separated list of browser commands to try.
    """
    from urlparse import urlunparse 
    if type(url) == ():
        url = urlunparse(url)
    for browser in _browsers:
        if not os.system('which 1>/dev/null 2>&1 '+string.split(browser)[0]):
            if os.system((browser % url)) == 0:
                return 1
    return 0

Obviously this is not portable off Unix.  Equally obviously it should
be possible to do an equivalent thing under Windows (at least).  For
anybody writing interactive programs in this Web-mad era, this
function is just too useful not to have in the toolbox.  So this is a
nudge to any Windows and Mac wizards on this list -- let's make this
function available cross-platform.

I've also copied this note to Chip Salzenberg.  Perl ought to have
this capability too -- and I'm sufficiently serious about that to
(gasp) code in Perl myself to make it happen if I have to.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

(Those) who are trying to read the Second Amendment out of the Constitution by
claiming it's not an individual right (are) courting disaster by encouraging
others to use the same means to eliminate portions of the Constitution they
don't like.
	-- Alan Dershowitz, Harvard Law School


From akuchlin@mems-exchange.org  Sat Jun 10 16:42:50 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sat, 10 Jun 2000 11:42:50 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610113124.B18982@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 11:31:24AM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com>
Message-ID: <20000610114250.A25014@newcnri.cnri.reston.va.us>

[Redirecting a private conversation to python-dev]

On Sat, Jun 10, 2000 at 11:31:24AM -0400, Eric S. Raymond wrote:
>I found a workaround.  The two curses enhancements (traceback wrapper
>and text pad) are now working and ready to be integrated into the
>1.6 library.  How should we proceed?

OK; python-dev has discussed creating a curses package, and reaction
seemed favorable.  So, my plan of action is:

1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv'
inside the SourceForge CVS repository so the complete history of the
module doesn't get lost with the renaming?)

2) Create a Lib/curses/
directory; __init__.py does 'from _curses import *'.  

3) The traceback wrapper can then be put into __init__.py, since I
assume it's fairly small and everyone should use it.  The text pad
stuff could then go in another module in the curses package.

Seem reasonable to everyone?  

--amk


From esr@thyrsus.com  Sat Jun 10 17:01:48 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 12:01:48 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 11:42:50AM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us>
Message-ID: <20000610120148.A19168@thyrsus.com>

Andrew Kuchling <akuchlin@cnri.reston.va.us>:
> OK; python-dev has discussed creating a curses package, and reaction
> seemed favorable.  So, my plan of action is:
> 
> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv'
> inside the SourceForge CVS repository so the complete history of the
> module doesn't get lost with the renaming?)
> 
> 2) Create a Lib/curses/
> directory; __init__.py does 'from _curses import *'.  
> 
> 3) The traceback wrapper can then be put into __init__.py, since I
> assume it's fairly small and everyone should use it.  The text pad
> stuff could then go in another module in the curses package.
> 
> Seem reasonable to everyone?  

Works for me.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

We shall not cease from exploration, and the end of all our exploring will be
to arrive where we started and know the place for the first time.
	-- T.S. Eliot


From Moshe Zadka <moshez@math.huji.ac.il>  Sat Jun 10 18:03:51 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Sat, 10 Jun 2000 20:03:51 +0300 (IDT)
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us>
Message-ID: <Pine.GSO.4.10.10006102000540.6989-100000@sundial>

On Sat, 10 Jun 2000, Andrew Kuchling wrote:

> OK; python-dev has discussed creating a curses package, and reaction
> seemed favorable.  So, my plan of action is:
> 
> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv'
> inside the SourceForge CVS repository so the complete history of the
> module doesn't get lost with the renaming?)
> 
> 2) Create a Lib/curses/
> directory; __init__.py does 'from _curses import *'.  
> 
> 3) The traceback wrapper can then be put into __init__.py, since I
> assume it's fairly small and everyone should use it.  The text pad
> stuff could then go in another module in the curses package.
> 
> Seem reasonable to everyone?  

I'm +1, except for some nagging doubt about the traceback wrapper.
Why not put it in its own (small, granted) module? 
There are no backward compatabilities to worry here, so there shouldn't be
any excuse to put code in __init__.py. But it is so small, that I don't
really feel strongly about it.

i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z.
--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From esr@thyrsus.com  Sat Jun 10 18:24:18 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 13:24:18 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <Pine.GSO.4.10.10006102000540.6989-100000@sundial>; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 08:03:51PM +0300
References: <20000610114250.A25014@newcnri.cnri.reston.va.us> <Pine.GSO.4.10.10006102000540.6989-100000@sundial>
Message-ID: <20000610132418.A19442@thyrsus.com>

Moshe Zadka <moshez@math.huji.ac.il>:
> I'm +1, except for some nagging doubt about the traceback wrapper.
> Why not put it in its own (small, granted) module? 

I don't understand.  Whuy do you want to do this?

> i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z.

You can try it out now:

#
# Curses extensions -- these are expected to be in the 1.6 Python library
#
import sys, curses, ascii

def wrapper(func, *rest):
    "Wrapper function that restores normal keyboard/screen behavior on error."
    res = None
    try:
	# Initialize curses
	stdscr=curses.initscr()
	# Turn off echoing of keys, and enter cbreak mode,
	# where no buffering is performed on keyboard input
	curses.noecho() ; curses.cbreak()

	# In keypad mode, escape sequences for special keys
	# (like the cursor keys) will be interpreted and
	# a special value like curses.KEY_LEFT will be returned
        stdscr.keypad(1)

        res = apply(func, (stdscr,) + rest)
    except:
	# In the event of an error, restore the terminal
	# to a sane state.
	stdscr.keypad(0)
	curses.echo() ; curses.nocbreak()
	curses.endwin()
        # Pass the exception upwards
        (exc_type, exc_value, exc_traceback) = sys.exc_info()
        raise exc_type, exc_value, exc_traceback
    else:
	# Set everything back to normal
	stdscr.keypad(0)
	curses.echo() ; curses.nocbreak()
	curses.endwin()		 # Terminate curses

        return res

def rectangle(win, uly, ulx, lry, lrx):
    "Draw a rectangle."
    win.vline(uly+1, ulx, curses.ACS_VLINE, lry - uly - 1)
    win.hline(uly, ulx+1, curses.ACS_HLINE, lrx - ulx - 1)
    win.hline(lry, ulx+1, curses.ACS_HLINE, lrx - ulx - 1)
    win.vline(uly+1, lrx, curses.ACS_VLINE, lry - uly - 1)
    win.addch(uly, ulx, curses.ACS_ULCORNER)
    win.addch(uly, lrx, curses.ACS_URCORNER)
    win.addch(lry, lrx, curses.ACS_LRCORNER)
    win.addch(lry, ulx, curses.ACS_LLCORNER)

class textbox:
    """Editing widget using the interior of a window object.
    Supports the following Emacs-like key bindings:

    Ctrl-A      Go to left edge of window.
    Ctrl-B      Cursor left, wrapping to previous line if appropriate.
    Ctrl-D      Delete character under cursor.
    Ctrl-E      Go to right edge (nospaces off) or end of line (nospaces on).
    Ctrl-F      Cursor right, wrapping to next line when appropriate.
    Ctrl-G      Terminate, returning the window contents.
    Ctrl-J      Terminate if the window is 1 line, otherwise insert newline.
    Ctrl-K      If line is blank, delete it, otherwise clear to end of line.
    Ctrl-L      Refresh screen
    Ctrl-N      Cursor down; move down one line.
    Ctrl-O      Insert a blank line at cursor location.
    Ctrl-P      Cursor up; move up one line.

    Move operations do nothing if the cursor is at an edge where the movement
    is not possible.  The following synonyms are supported where possible:

    KEY_LEFT = Ctrl-B, KEY_RIGHT = Ctrl-F, KEY_UP = Ctrl-P, KEY_DOWN = Ctrl-N
    """
    def __init__(self, win):
        self.win = win
        (self.maxy, self.maxx) = win.getmaxyx()
        self.maxy = self.maxy - 1
        self.maxx = self.maxx - 1
        self.stripspaces = 1
        win.keypad(1)

    def firstblank(self, y):
        "Go to the location of the first blank on the given line."
        (oldy, oldx) = self.win.getyx()
        self.win.move(y, self.maxx-1)
        last = self.maxx-1
        while 1:
            if last == 0:
                break
            if ascii.ascii(self.win.inch(y, last)) != ascii.SP:
                last = last + 1
                break
            last = last - 1
        self.win.move(oldy, oldx)
        return last

    def do_command(self, ch):
        "Process a single editing command."
        (y, x) = self.win.getyx()
        if ascii.isprint(ch):
            if y < self.maxy or x < self.maxx:
                # The try-catch ignores the error we trigger from some curses
                # versions by trying to write into the lowest-rightmost spot
                # in the self.window.
                try:
                    self.win.addch(ch)
                except ERR:
                    pass
        elif ch == ascii.SOH:				# Ctrl-a
            self.win.move(y, 0)
        elif ch in (ascii.STX, curses.KEY_LEFT):	# Ctrl-b
            if x > 0:
                self.win.move(y, x-1)
            elif y == 0:
                pass
            elif self.stripspaces:
                self.win.move(y-1, self.firstblank(y-1))
            else:
                self.win.move(y-1, self.maxx)
        elif ch == ascii.EOT:				# Ctrl-d
            self.win.delch()
        elif ch == ascii.ENQ:				# Ctrl-e
            if self.stripspaces:
                self.win.move(y, self.firstblank(y, maxx))
            else:
                self.win.move(y, self.maxx)
        elif ch in (ascii.ACK, curses.KEY_RIGHT):	# Ctrl-f
            if x < self.maxx:
                self.win.move(y, x+1)
            elif y == self.maxx:
                pass
            else:
                self.win.move(y+1, 0)
        elif ch == ascii.BEL:				# Ctrl-g
            return 0
        elif ch == ascii.NL:				# Ctrl-j
            if self.maxy == 0:
                return 0
            elif y < self.maxy:
                self.win.move(y+1, 0)
        elif ch == ascii.VT:				# Ctrl-k
            if x == 0 and self.firstblank(y) == 0:
                self.win.deleteln()
            else:
                self.win.clrtoeol()
        elif ch == ascii.FF:				# Ctrl-l
            self.win.refresh()
        elif ch in (ascii.SO, curses.KEY_DOWN):		# Ctrl-n
            if y < self.maxy:
                self.win.move(y+1, x)
        elif ch == ascii.SI:				# Ctrl-o
            self.win.insertln()
        elif ch in (ascii.DLE, curses.KEY_UP):		# Ctrl-p
            if y > 0:
                self.win.move(y-1, x)
        self.win.refresh()
        return 1
        
    def gather(self):
        "Collect and return the contents of the window."
        result = ""
        for y in range(self.maxy+1):
            self.win.move(y, 0)
            stop = self.firstblank(y)
            if stop == 0 and self.stripspaces:
                continue
            for x in range(self.maxx+1):
                if self.stripspaces and x == stop:
                    break
                result = result + chr(ascii.ascii(self.win.inch(y, x)))
            if self.maxy > 0:
                result = result + "\n"
        return result

    def edit(self, validate=None):
        "Edit in the widget window and collect the results."
        while 1:
            ch = self.win.getch()
            if self.validate:
                ch = validate(ch)
            if not self.do_command(ch):
                break
        return self.gather()

if __name__ == '__main__':
    def test_editbox(stdscr):
        win = curses.newwin(4, 9, 15, 20)
        rectangle(stdscr, 14, 19, 19, 29)
        stdscr.refresh()
        return textbox(win).edit()

    str = wrapper(test_editbox)
    print str
-- 
		<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 bwarsaw@python.org  Sat Jun 10 18:58:04 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Sat, 10 Jun 2000 13:58:04 -0400 (EDT)
Subject: [Python-Dev] Creating curses package: OK?
References: <200006100748.DAA17920@snark.thyrsus.com>
 <20000610111323.A24895@newcnri.cnri.reston.va.us>
 <20000610113124.B18982@thyrsus.com>
 <20000610114250.A25014@newcnri.cnri.reston.va.us>
Message-ID: <14658.33196.426211.329070@anthem.concentric.net>

>>>>> "AK" == Andrew Kuchling <akuchlin@cnri.reston.va.us> writes:

    AK> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you
    AK> do a 'mv' inside the SourceForge CVS repository so the
    AK> complete history of the module doesn't get lost with the
    AK> renaming?)

Not easily (IOW, I have to play several rounds of ugly loginfo games
which are hard to get right).  Best thing to do would be to submit a
SF admin request, which I think since you're a developer you can do.

-Barry


From Moshe Zadka <moshez@math.huji.ac.il>  Sat Jun 10 21:12:32 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Sat, 10 Jun 2000 23:12:32 +0300 (IDT)
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610132418.A19442@thyrsus.com>
Message-ID: <Pine.GSO.4.10.10006102308380.9354-100000@sundial>

[Moshe Zadka]
> I'm +1, except for some nagging doubt about the traceback wrapper.
> Why not put it in its own (small, granted) module? 

[Eric S. Raymond]
> I don't understand.  Why do you want to do this?

I have religious beliefs, and I follow them without thinking. Like
"HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting
real code in __init__.py bad".

(I think that should go in the package style guide, BTW)

religions-are-bad-of-course-ly y'rs, Z.
--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From esr@thyrsus.com  Sat Jun 10 21:24:40 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 16:24:40 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <Pine.GSO.4.10.10006102308380.9354-100000@sundial>; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:12:32PM +0300
References: <20000610132418.A19442@thyrsus.com> <Pine.GSO.4.10.10006102308380.9354-100000@sundial>
Message-ID: <20000610162440.A19859@thyrsus.com>

Moshe Zadka <moshez@math.huji.ac.il>:
> [Eric S. Raymond]
> > I don't understand.  Why do you want to do this?
> 
> I have religious beliefs, and I follow them without thinking. Like
> "HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting
> real code in __init__.py bad".

I'm even more confused now.  Why would the traceback wrapper I'm proposing
go in __init__.py?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The Bible is not my book, and Christianity is not my religion.  I could never
give assent to the long, complicated statements of Christian dogma.
	-- Abraham Lincoln


From Moshe Zadka <moshez@math.huji.ac.il>  Sat Jun 10 21:21:57 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Sat, 10 Jun 2000 23:21:57 +0300 (IDT)
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610162440.A19859@thyrsus.com>
Message-ID: <Pine.GSO.4.10.10006102319051.9354-100000@sundial>

On Sat, 10 Jun 2000, Eric S. Raymond wrote:

> I'm even more confused now.  Why would the traceback wrapper I'm proposing
> go in __init__.py?

Maybe I'm confused here. I thought that was what AMK suggested, no?
Where would you want it to go? There are currently 3 planned files in 
the curses package:

__init__.py: apparently not
textpad.py: why here? it has nothing to do with text pads
_curses.so: certainly not here...you don't want to code in C more then you
            have to

I'm proposing:

wrapper.py: put it here

i-hope-i-managed-to-confuse-everyone-further-ly y'rs, Z.
--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From akuchlin@mems-exchange.org  Sat Jun 10 23:25:14 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sat, 10 Jun 2000 18:25:14 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <Pine.GSO.4.10.10006102319051.9354-100000@sundial>; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:21:57PM +0300
References: <20000610162440.A19859@thyrsus.com> <Pine.GSO.4.10.10006102319051.9354-100000@sundial>
Message-ID: <20000610182514.A25949@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote:
>Maybe I'm confused here. I thought that was what AMK suggested, no?

I did in fact suggest that, since the wrapper is small, and we ideally
want every Python/curses application using it, so they don't leave the
terminal in a wacky state if they raise an exception.  But it's not a
big deal and could easily go in wrapper.py, though __init__.py might
still import it automatically.

--amk


From esr@thyrsus.com  Sat Jun 10 23:38:06 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 18:38:06 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400
References: <20000610162440.A19859@thyrsus.com> <Pine.GSO.4.10.10006102319051.9354-100000@sundial> <20000610182514.A25949@newcnri.cnri.reston.va.us>
Message-ID: <20000610183806.A20280@thyrsus.com>

Andrew Kuchling <akuchlin@cnri.reston.va.us>:
> On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote:
> >Maybe I'm confused here. I thought that was what AMK suggested, no?
> 
> I did in fact suggest that, since the wrapper is small, and we ideally
> want every Python/curses application using it, so they don't leave the
> terminal in a wacky state if they raise an exception.  But it's not a
> big deal and could easily go in wrapper.py, though __init__.py might
> still import it automatically.

The traceback wrapper is not the only Python code I'll be supplying...
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

I do not find in orthodox Christianity one redeeming feature.
	-- Thomas Jefferson


From gstein@lyra.org  Sat Jun 10 23:33:20 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 15:33:20 -0700
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400
References: <20000610162440.A19859@thyrsus.com> <Pine.GSO.4.10.10006102319051.9354-100000@sundial> <20000610182514.A25949@newcnri.cnri.reston.va.us>
Message-ID: <20000610153320.A19484@lyra.org>

On Sat, Jun 10, 2000 at 06:25:14PM -0400, Andrew Kuchling wrote:
> On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote:
> >Maybe I'm confused here. I thought that was what AMK suggested, no?
> 
> I did in fact suggest that, since the wrapper is small, and we ideally
> want every Python/curses application using it, so they don't leave the
> terminal in a wacky state if they raise an exception.  But it's not a
> big deal and could easily go in wrapper.py, though __init__.py might
> still import it automatically.

Yes, I think we'd want it to import the stuff; just organizationally to
place the source code outside of __init__.py

I'd agree that real code should not go into __init__. It should preload some
standard modules, maybe expose some symbols, but otherwise no code.

Cheers,
-g

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


From gstein@lyra.org  Sun Jun 11 00:30:13 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 16:30:13 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <200006102306.QAA18088@slayer.i.sourceforge.net>; from akuchling@slayer.i.sourceforge.net on Sat, Jun 10, 2000 at 04:06:55PM -0700
References: <200006102306.QAA18088@slayer.i.sourceforge.net>
Message-ID: <20000610163013.B19484@lyra.org>

On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote:
>...
> def wrapper(func, *rest):
>     """Wrapper function that initializes curses and calls another function,
>     restoring normal keyboard/screen behavior on error.
>     The callable object 'func' is then passed the main window 'stdscr'
>     as its first argument, followed by any other arguments passed to
>     wrapper().
>     """
>     
>     res = None
>     try:
> 	# Initialize curses
> 	stdscr=curses.initscr()
> 	# Turn off echoing of keys, and enter cbreak mode,
> 	# where no buffering is performed on keyboard input
> 	curses.noecho() ; curses.cbreak()
> 
> 	# In keypad mode, escape sequences for special keys
> 	# (like the cursor keys) will be interpreted and
> 	# a special value like curses.KEY_LEFT will be returned
>         stdscr.keypad(1)
> 
>         res = apply(func, (stdscr,) + rest)
>     except:
> 	# In the event of an error, restore the terminal
> 	# to a sane state.
> 	stdscr.keypad(0)
> 	curses.echo() ; curses.nocbreak()
> 	curses.endwin()
>         # Pass the exception upwards
>         (exc_type, exc_value, exc_traceback) = sys.exc_info()
>         raise exc_type, exc_value, exc_traceback
>     else:
> 	# Set everything back to normal
> 	stdscr.keypad(0)
> 	curses.echo() ; curses.nocbreak()
> 	curses.endwin()		 # Terminate curses
> 
>         return res

This is too complicated. It should read:

   ...
   return apply(func, (stdscr,) + rest)
 finally:
   # Set everything back to normal
   stdscr.keypad(0)
   curses.echo()
   curses.nocbreak()
   curses.endwin()

Andrew: can you make this change?


Separate from the above simplification, it is important to note:

    exc_type, exc_value, exc_traceback = sys.exc_info()
    raise exc_type, exc_value, exc_traceback
    
and

    raise
    
are equivalent in (most) function. The difference is that the former places
the traceback into local variable storage (exc_traceback) which then
introduces a reference loop.

Whenever sys.exc_info() is used, it is very important to watch out for loops
caused by the traceback object. "del exc_traceback" is very handy :-)

Cheers,
-g

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


From gstein@lyra.org  Sun Jun 11 00:33:05 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 16:33:05 -0700
Subject: [Python-Dev] curses wrapper checkin
In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org>
Message-ID: <20000610163305.C19484@lyra.org>

On Sat, Jun 10, 2000 at 04:30:13PM -0700, Greg Stein wrote:
> On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote:
> >...
> > def wrapper(func, *rest):
> >     """Wrapper function that initializes curses and calls another function,
> >     restoring normal keyboard/screen behavior on error.
> >     The callable object 'func' is then passed the main window 'stdscr'
> >     as its first argument, followed by any other arguments passed to
> >     wrapper().
> >     """
> >     
> >     res = None

Oh. This line can disappear, too.

Cheers,
-g

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


From akuchlin@mems-exchange.org  Sun Jun 11 00:33:12 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sat, 10 Jun 2000 19:33:12 -0400
Subject: [Python-Dev] Creating curses package: done
In-Reply-To: <14658.33196.426211.329070@anthem.concentric.net>; from bwarsaw@python.org on Sat, Jun 10, 2000 at 01:58:04PM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net>
Message-ID: <20000610193312.A26098@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 01:58:04PM -0400, Barry A. Warsaw wrote:
>which are hard to get right).  Best thing to do would be to submit a
>SF admin request, which I think since you're a developer you can do.

I've submitted a support request to rename the file, and checked in
the Lib/curses subdirectory, containing only __init__.py and
wrapper.py, along with the required Makefile.in and Setup.in changes.
If you compile the CVS tree right now, you'll need to rename
cursesmodule.c to _cursesmodule.c manually.

The textbox stuff poses two problems.  First, it requires ascii.py,
and wasn't the decision to wait for GvR on adding that module?
Second, Eric, I'm not sure what you want as the module name for the
textbox stuff: textbox.py?  Your call...  (I'll check it in, and if
ascii.py is vetoed, it can be rewritten to not require ascii.py, or
we can have curses.ascii.)

--amk


From esr@thyrsus.com  Sun Jun 11 00:48:22 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 19:48:22 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org>
Message-ID: <20000610194822.A882@thyrsus.com>

Greg Stein <gstein@lyra.org>:
> This is too complicated. It should read:
> 
>    ...
>    return apply(func, (stdscr,) + rest)
>  finally:
>    # Set everything back to normal
>    stdscr.keypad(0)
>    curses.echo()
>    curses.nocbreak()
>    curses.endwin()
> 
> Andrew: can you make this change?

I'll test it and make the change in my masters if it works for both
cases.  I haven't actually shipped the box of goodies yet...
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Alcohol still kills more people every year than all `illegal' drugs put
together, and Prohibition only made it worse.  Oppose the War On Some Drugs!


From esr@thyrsus.com  Sun Jun 11 00:50:27 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 19:50:27 -0400
Subject: [Python-Dev] Creating curses package: done
In-Reply-To: <20000610193312.A26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:33:12PM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us>
Message-ID: <20000610195027.B882@thyrsus.com>

Andrew Kuchling <akuchlin@cnri.reston.va.us>:
> The textbox stuff poses two problems.  First, it requires ascii.py,
> and wasn't the decision to wait for GvR on adding that module?
> Second, Eric, I'm not sure what you want as the module name for the
> textbox stuff: textbox.py?  Your call...  (I'll check it in, and if
> ascii.py is vetoed, it can be rewritten to not require ascii.py, or
> we can have curses.ascii.)

I thought it was going to become part of curses from the user's point
of view, so that "import curses" brings it in.  That seemed to be the 
intent of the request at the end of the curses HOWTO.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"Taking my gun away because I might shoot someone is like cutting my tongue
out because I might yell `Fire!' in a crowded theater."
        -- Peter Venetoklis


From akuchlin@mems-exchange.org  Sun Jun 11 00:44:54 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sat, 10 Jun 2000 19:44:54 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <20000610194822.A882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:48:22PM -0400
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com>
Message-ID: <20000610194454.B26098@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote:
>I'll test it and make the change in my masters if it works for both
>cases.  I haven't actually shipped the box of goodies yet...

Already tested and checked in.  If you make other changes, just ship
me the new version.  

(Oh, I forgot about the stupid legal stuff; you should probably send
wrapper.py and textbox.py to patches@python.org with the requisite
legal disclaimer.)

--amk


From esr@thyrsus.com  Sun Jun 11 00:59:31 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 19:59:31 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <20000610194454.B26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:44:54PM -0400
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com> <20000610194454.B26098@newcnri.cnri.reston.va.us>
Message-ID: <20000610195931.A985@thyrsus.com>

Andrew Kuchling <akuchlin@cnri.reston.va.us>:
> On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote:
> >I'll test it and make the change in my masters if it works for both
> >cases.  I haven't actually shipped the box of goodies yet...
> 
> Already tested and checked in.  If you make other changes, just ship
> me the new version.  

Well, dang.  Didn't you want me to document it first? :-)
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Rifles, muskets, long-bows and hand-grenades are inherently democratic
weapons.  A complex weapon makes the strong stronger, while a simple
weapon -- so long as there is no answer to it -- gives claws to the
weak.
        -- George Orwell, "You and the Atom Bomb", 1945


From akuchlin@mems-exchange.org  Sun Jun 11 00:51:30 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sat, 10 Jun 2000 19:51:30 -0400
Subject: [Python-Dev] Creating curses package: done
In-Reply-To: <20000610195027.B882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:50:27PM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us> <20000610195027.B882@thyrsus.com>
Message-ID: <20000610195130.C26098@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 07:50:27PM -0400, Eric S. Raymond wrote:
>I thought it was going to become part of curses from the user's point
>of view, so that "import curses" brings it in.  That seemed to be the 
>intent of the request at the end of the curses HOWTO.

Ooh, no; that text is saying that an editor would make a good example
to put in the HOWTO.  I'd rather have the curses module contain only a
fairly close mapping of the C API, and extensions written in Python
would be in submodules like curses.editor, curses.textbox, whatever.
Similar to how socketmodule.c is a thin veneer over the BSD socket API, 
and the spiffy extensions are in asyncore.py, httplib.py, &c.

--amk



From nhodgson@bigpond.net.au  Sun Jun 11 01:04:53 2000
From: nhodgson@bigpond.net.au (Neil Hodgson)
Date: Sun, 11 Jun 2000 10:04:53 +1000
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
References: <20000610114227.A19052@thyrsus.com>
Message-ID: <016301bfd338$ab8458f0$e3cb8490@neil>

> Obviously this is not portable off Unix.  Equally obviously it should
> be possible to do an equivalent thing under Windows (at least).  For
> anybody writing interactive programs in this Web-mad era, this
> function is just too useful not to have in the toolbox.  So this is a
> nudge to any Windows and Mac wizards on this list -- let's make this
> function available cross-platform.

   The most common way on Windows to launch the user's preferred browser
with an URL would be:

>>> import win32api
>>> win32api.ShellExecute(0,None,"http://www.python.org",None,"",1)

# Note to Mark - more of the parameters should be optional

   However this, like most process control stuff, requires the Win32
extensions, not the base Python distribution. Trying to hack this up with
os.system would be unpleasant. ShellExecute knows when to do icky stuff like
use DDE to open the correct URL.

   Does this type of UI operation really belong in urllib?

   Neil



From esr@thyrsus.com  Sun Jun 11 02:26:08 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 21:26:08 -0400
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
In-Reply-To: <016301bfd338$ab8458f0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 10:04:53AM +1000
References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil>
Message-ID: <20000610212608.A1109@thyrsus.com>

Neil Hodgson <nhodgson@bigpond.net.au>:
>    Does this type of UI operation really belong in urllib?

It fetches the contents of an URL for inspection.  Where else would you put it?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

It would be thought a hard government that should tax its people one tenth 
part.
	-- Benjamin Franklin


From nhodgson@bigpond.net.au  Sun Jun 11 02:51:34 2000
From: nhodgson@bigpond.net.au (Neil Hodgson)
Date: Sun, 11 Jun 2000 11:51:34 +1000
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com>
Message-ID: <01af01bfd347$937b3fd0$e3cb8490@neil>

> >    Does this type of UI operation really belong in urllib?
>
> It fetches the contents of an URL for inspection.  Where else would you
put it?

   os?
   Or a submodule of os.

   The current os has a bunch of executable-oriented process creation and
managment functions. On Macintosh and Windows, data-oriented process
creation would be useful.

   os.process.open("http://www.python.org")

   os.process.print("c:\src\map.png")

   Neil




From esr@thyrsus.com  Sun Jun 11 03:14:56 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 22:14:56 -0400
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
In-Reply-To: <01af01bfd347$937b3fd0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 11:51:34AM +1000
References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com> <01af01bfd347$937b3fd0$e3cb8490@neil>
Message-ID: <20000610221456.A1223@thyrsus.com>

Neil Hodgson <nhodgson@bigpond.net.au>:
> > It fetches the contents of an URL for inspection.  Where else would you
> put it?
> 
>    os?
>    Or a submodule of os.
> 
>    The current os has a bunch of executable-oriented process creation and
> managment functions. On Macintosh and Windows, data-oriented process
> creation would be useful.

I don't really care where it lives, and will cheerfully defer to those 
with religious beliefs about the namespace ;-).

If it's not obvious, this flurry of library suggestions you've been
seeing from me lately all come straight out of the CML2 project.  I
use the urlbrowse() function to make URLs in help windows into live
objects that you can click on.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

This would be the best of all possible worlds, if there were
no religion in it.
	-- John Adams, in a letter to Thomas Jefferson.


From esr@snark.thyrsus.com  Sun Jun 11 05:29:37 2000
From: esr@snark.thyrsus.com (Eric S. Raymond)
Date: Sun, 11 Jun 2000 00:29:37 -0400
Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper
Message-ID: <200006110429.AAA01719@snark.thyrsus.com>

Greg Stein's correction broke my traceback wrapper.  I now do *not*
see a traceback on an exit due to Python runtime errors.  I don't know
why this is.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

No one who's seen it in action can say the phrase "government help" without
either laughing or crying.


From gstein@lyra.org  Sun Jun 11 06:44:30 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 22:44:30 -0700
Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper
In-Reply-To: <200006110429.AAA01719@snark.thyrsus.com>; from esr@snark.thyrsus.com on Sun, Jun 11, 2000 at 12:29:37AM -0400
References: <200006110429.AAA01719@snark.thyrsus.com>
Message-ID: <20000610224430.E19484@lyra.org>

On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote:
> Greg Stein's correction broke my traceback wrapper.  I now do *not*
> see a traceback on an exit due to Python runtime errors.  I don't know
> why this is.

That's strange... a "finally" does not munge tracebacks at all. An exception
from a lower level should propagate outwards without interference.

Do you still have an "except:" in your code somewhere? (that could be eating
your exception) Maybe your test case isn't failing as expected :-) If you'd
like, post a copy of the test, and we can debug the wrapper and/or test.

Cheers,
-g

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


From gstein@lyra.org  Sun Jun 11 12:01:50 2000
From: gstein@lyra.org (Greg Stein)
Date: Sun, 11 Jun 2000 04:01:50 -0700
Subject: [Python-Dev] more on httplib
In-Reply-To: <Pine.LNX.4.10.10006031606100.29036-100000@nebula.lyra.org>; from gstein@lyra.org on Sat, Jun 03, 2000 at 04:13:55PM -0700
References: <Pine.LNX.4.10.10006031606100.29036-100000@nebula.lyra.org>
Message-ID: <20000611040150.K19484@lyra.org>

All of the work below has been completed except for the errno==32 stuff.

Module:  http://www.lyra.org/greg/python/httplib.py
History: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/

There are three items left, that I know of:
  1) need doc for new stuff
  2) need new test cases
  3) I want to remove a "feature" of the old HTTP class. This would be a
     change in behavior, but (IMO) minor. Specifically, if the Status-Line
     is malformed, the old httplib.py would return (-1, <malformed line>,
     None) and store <file ob hooked to socket> into self.file. Nominally,
     that file object allows a client to read more data from the socket
     after the parse problem on the malformed Status-Line. I think it is
     useless, unused by any clients out there, and it causes me pain to
     provide it :-)  I'd like to just store None into self.file

Thoughts? Comments? I'd like to get this thing into Python RSN.

Cheers,
-g

On Sat, Jun 03, 2000 at 04:13:55PM -0700, Greg Stein wrote:
> I would like to propose a few changes to the (new) httplib:
> 
> *) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to
>    provide backwards-compat for it
> 
> *) revamp the pipeline support:
> 
>    - record the "last response object" ... when a new getreply() is done,
>      then we store the "last" into response.prior
>    - reading of the "HTTP/1.1 <code> <msg>" line is deferred, and
>      performed by the response object
>    - the read of that line is lazy
>    - if the response line is read *before* the "prior" response (if any) 
>      is "closed", then an exception is raised: ResponseNotReady
> 
> *) address some of Moshe's concerns:
> 
>    - use class-based exceptions
>    - clarify that HTTPConnection is designed for *blocking* sockets
>    - conn.close() followed by conn.send() will reopen the socket. This
>      could lead to programming errors. I'll add a class-based default flag
>      to disable this behavior.
>    - in request(), we check for errno==32 ... what to do on Windows?
> 
> 
> I will implement these changes in small chunks so that each can be
> reviewed in my CVS repository. The history is available at:
> 
>     http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/

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


From Moshe Zadka <moshez@math.huji.ac.il>  Sun Jun 11 12:58:28 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Sun, 11 Jun 2000 14:58:28 +0300 (IDT)
Subject: [Python-Dev] more on httplib
In-Reply-To: <20000611040150.K19484@lyra.org>
Message-ID: <Pine.GSO.4.10.10006111414220.12067-100000@sundial>

On Sun, 11 Jun 2000, Greg Stein wrote:

>   3) I want to remove a "feature" of the old HTTP class. This would be a
>      change in behavior, but (IMO) minor. Specifically, if the Status-Line
>      is malformed, the old httplib.py would return (-1, <malformed line>,
>      None) and store <file ob hooked to socket> into self.file. Nominally,
>      that file object allows a client to read more data from the socket
>      after the parse problem on the malformed Status-Line. I think it is
>      useless, unused by any clients out there, and it causes me pain to
>      provide it :-)  I'd like to just store None into self.file

What do the old docs say about this?

\begin{methoddesc}{getfile}{}
Return a file object from which the data returned by the server can be
read, using the \method{read()}, \method{readline()} or
\method{readlines()} methods.
\end{methoddesc}

So why not put a "dummy" file: one whose read(), readline() or readlines() 
act as if it was at EOF?
(IOW, the Pythonic equivalent of open("/dev/null"))


-- 
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From akuchlin@mems-exchange.org  Sun Jun 11 14:19:48 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sun, 11 Jun 2000 09:19:48 -0400
Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper
In-Reply-To: <20000610224430.E19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 10:44:30PM -0700
References: <200006110429.AAA01719@snark.thyrsus.com> <20000610224430.E19484@lyra.org>
Message-ID: <20000611091948.A27835@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 10:44:30PM -0700, Greg Stein wrote:
>On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote:
>> Greg Stein's correction broke my traceback wrapper.  
>If you'd like, post a copy of the test, and we can debug the wrapper
>and/or test.

I'll leave it to the two of you to figure out what's going on and
submit a corrected version, if necessary.  I did test the simplified
version and it seemed fine, though maybe there's a subtle problem.
I'm off to CA, and will be back on Wednesday.  (Mmmm... hours of plane
hacking...)

--amk


From gstein@lyra.org  Sun Jun 11 20:18:26 2000
From: gstein@lyra.org (Greg Stein)
Date: Sun, 11 Jun 2000 12:18:26 -0700
Subject: [Python-Dev] more on httplib
In-Reply-To: <Pine.GSO.4.10.10006111414220.12067-100000@sundial>; from moshez@math.huji.ac.il on Sun, Jun 11, 2000 at 02:58:28PM +0300
References: <20000611040150.K19484@lyra.org> <Pine.GSO.4.10.10006111414220.12067-100000@sundial>
Message-ID: <20000611121826.L19484@lyra.org>

On Sun, Jun 11, 2000 at 02:58:28PM +0300, Moshe Zadka wrote:
> On Sun, 11 Jun 2000, Greg Stein wrote:
> 
> >   3) I want to remove a "feature" of the old HTTP class. This would be a
> >      change in behavior, but (IMO) minor. Specifically, if the Status-Line
> >      is malformed, the old httplib.py would return (-1, <malformed line>,
> >      None) and store <file ob hooked to socket> into self.file. Nominally,
> >      that file object allows a client to read more data from the socket
> >      after the parse problem on the malformed Status-Line. I think it is
> >      useless, unused by any clients out there, and it causes me pain to
> >      provide it :-)  I'd like to just store None into self.file
> 
> What do the old docs say about this?
> 
> \begin{methoddesc}{getfile}{}
> Return a file object from which the data returned by the server can be
> read, using the \method{read()}, \method{readline()} or
> \method{readlines()} methods.
> \end{methoddesc}
> 
> So why not put a "dummy" file: one whose read(), readline() or readlines() 
> act as if it was at EOF?
> (IOW, the Pythonic equivalent of open("/dev/null"))

Sure, I can put different things there, but that would also be a change in
semantics.

The backwards compat class, HTTP, preserves the API completely -- even down
to how it reacts in error situations. (although, it *can* raise errors that
it didn't before, when you use methods in the wrong order)

I'd like to make a change in the semantics for this particular error
condition. Where a client used to be able to do:

    errcode, errmsg, hdrs = h.getreply()
    if errcode == -1:
        file = h.getfile()
	print 'ERROR: some kind of error occurred'
	print '    partial read:', `errmsg`
	print '    next 100 bytes:', `file.read(100)`

I'd like to eliminate that "next 100 bytes" ability, and just close the
socket when a protocol error occurs. Before making a change in behavior for
this (central) class, I'd like to get some feedback. Some voting?

Cheers,
-g

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


From andy@reportlab.com  Mon Jun 12 12:45:57 2000
From: andy@reportlab.com (Andy Robinson)
Date: Mon, 12 Jun 2000 12:45:57 +0100
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <20000610160032.0004A1CFA2@dinsdale.python.org>
Message-ID: <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>


>
> Message: 2
> From: "David Ascher" <DavidA@ActiveState.com>
> To: "Python Developers @ python.org" <python-dev@python.org>
> Subject: RE: [Python-Dev] Japanese Codecs
> Date: Fri, 9 Jun 2000 11:54:03 -0700
> charset="US-ASCII"
>
> > I just wish that these packagers actually become a reality
> > some day... the concept is good, but there currently seem to
> > be no volunteers or companies jumping in :-(
>
> I can't speak for Japanese packagers, but ActiveState will be packaging
> Python in various ways.
>
The handful of Python users who know some Japanese are kind of busy at the
moment, and the codec work takes more than a night or two; I was hoping to
tackle it myself, but as the only Python startup without any venture
funding, it is hard to clear aside the time without a customer; and it also
needs C skills.

I believe we should try and put resources together to fund this work and
ensure it gets done this year.  I can tell you that HP are now well and
truly out of the picture as a sponsor.  AFAIK the organisations who should
talk are at least...
   PythonLabs/BeOpen
   ActiveState
   Digital Garage
   PythonWare / Secret Labs ??? (not sure how rapid their global plans are)
   ReportLab

Are there any others?  Please get in touch with me...

feeling-rather-guilty-as-i18n-sig-coordinator-ly-yrs,

Andy Robinson





From mal@lemburg.com  Mon Jun 12 13:51:11 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 12 Jun 2000 14:51:11 +0200
Subject: [Python-Dev] Japanese Codecs
References: <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>
Message-ID: <3944DCBF.34DA9E4B@lemburg.com>

Andy Robinson wrote:
> 
> > > I just wish that these packagers actually become a reality
> > > some day... the concept is good, but there currently seem to
> > > be no volunteers or companies jumping in :-(
> >
> > I can't speak for Japanese packagers, but ActiveState will be packaging
> > Python in various ways.
> >
> The handful of Python users who know some Japanese are kind of busy at the
> moment, and the codec work takes more than a night or two; I was hoping to
> tackle it myself, but as the only Python startup without any venture
> funding, it is hard to clear aside the time without a customer; and it also
> needs C skills.
>
> I believe we should try and put resources together to fund this work and
> ensure it gets done this year.  I can tell you that HP are now well and
> truly out of the picture as a sponsor. 

How come ...wheren't they the initial sponsors for the i18n of
Python ? 

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From gstein@lyra.org  Mon Jun 12 19:19:07 2000
From: gstein@lyra.org (Greg Stein)
Date: Mon, 12 Jun 2000 11:19:07 -0700
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>; from andy@robanal.demon.co.uk on Mon, Jun 12, 2000 at 12:45:57PM +0100
References: <20000610160032.0004A1CFA2@dinsdale.python.org> <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>
Message-ID: <20000612111907.B19484@lyra.org>

On Mon, Jun 12, 2000 at 12:45:57PM +0100, Andy Robinson wrote:
> > Message: 2
> > From: "David Ascher" <DavidA@ActiveState.com>
> > To: "Python Developers @ python.org" <python-dev@python.org>
> > Subject: RE: [Python-Dev] Japanese Codecs
> > Date: Fri, 9 Jun 2000 11:54:03 -0700
> > charset="US-ASCII"
> >
> > > I just wish that these packagers actually become a reality
> > > some day... the concept is good, but there currently seem to
> > > be no volunteers or companies jumping in :-(
> >
> > I can't speak for Japanese packagers, but ActiveState will be packaging
> > Python in various ways.
> >
> The handful of Python users who know some Japanese are kind of busy at the
> moment, and the codec work takes more than a night or two; I was hoping to
> tackle it myself, but as the only Python startup without any venture
> funding, it is hard to clear aside the time without a customer; and it also
> needs C skills.
> 
> I believe we should try and put resources together to fund this work and
> ensure it gets done this year.

Um... why is it incumbent upon "us" (for whatever definition of "us" you
want to apply :-) to find/fund the work for the Japanese codecs? Why isn't
this up to the people who want/need it?

Yes, being proactive is a very nice thing to do, but I don't see that we
must be, in this case.

> I can tell you that HP are now well and truly out of the picture as a
> sponsor.

eh? What's going on with that?

Cheers,
-g

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


From bwarsaw@python.org  Mon Jun 12 21:53:10 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 12 Jun 2000 16:53:10 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
Message-ID: <14661.19894.465676.770545@anthem.concentric.net>

Okay, let me just preface this by saying none of the following has
been blessed by Guido in any way.  I'm sure he's still getting nice
and tan and drinking exotic tropical alcohol-based beverages, and not
thinking about Python one little bit. :)

Fred and Jeremy and I had a meeting today and thought about a schedule
/we'd/ like to see for Python 1.6 final.  This may or may not be
feasible but I throw it out here for discussion anyway.

The O'Reilly Open Source conference[1] starts July 17th and it would
be a nice target to release 1.6 final on the 14th, the Friday before
the conference.  We all plan on being there.n

What do we need to do to hit this target?  If we figure a 2 week beta
cycle, 1.6beta1 would have to be released June 30, with probably the
last alpha on June 23.  This is a tight schedule; is it even
feasible?.  Looking at Andrew's TODO list[2], here's what we came up
with:

- import hooks revamped (push this to 1.7)
- update docos to match 1.6 changes (Fred is going to integrate what's
  sitting in his inbox)
- document more undocumented modules (codes - done; unicodedata -
  needs work; mmap & pyexpat - Fred to integrate; curses - needs
  updates; regrtest - push to 1.7, see below)
- Unicode: Compress the size of unicodedatabase (waiting for Chris
  Tismer patches?)
- Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch,
  but none of us know what the state of this is -- is it crucial
  anyway?).
- Unicode: the various XXX items in Misc/unicode.txt (we didn't
  actually find such outstanding issues in this file).
- Delete obsolete subdirs in Demo/ directory (done)
- Refurbish Demo subdirs to be properly documented, match modern
  coding style, etc. (???)
- Fix ./ld_so_aix installation problem on AIX (anybody know more about
  this???)
- Make test/regrtest.py more usable outside of the Python test suite &
  document it.  (push to 1.7)
- Conservative GC, of cycles (this is basically done but needs a lot
  more testing)
- Changes to PyExpat module (Fred says this is done)
- Test the hell out of SRE.  (waiting for /F's complete implementation)
- enable threads by default if OS supports it
- integrate intl/gettext module
- clear the patches and bugs backlog

As we saw it the most critical things that need to get done are
testing the GC stuff and the SRE module.  Of those, the most critical
is SRE since AFAIK, we're still waiting for the final complete code
from /F.  I could be wrong about that.

The last three weren't on Andrew's list.  I'm on the hook for enabling
threads support by default and integrating intl/gettext.  I think
those will just be a couple of days work.

The final one requires Us to go through the outstanding bug and
patches lists and address the critical bugs.

Thoughts?  What have I missed?
-Barry

[1] http://conferences.oreilly.com/oscon2000/

[2] http://starship.python.net/crew/amk/python/1.6-jobs.html


From gstein@lyra.org  Tue Jun 13 01:32:14 2000
From: gstein@lyra.org (Greg Stein)
Date: Mon, 12 Jun 2000 17:32:14 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <20000612173214.F19484@lyra.org>

On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
> ... disclaimers applied ...
>
> - import hooks revamped (push this to 1.7)

The latest thought had two items here:

1) incorporate feedback into imputil.py.
   [ the feedback is visible at the end of the most recent version:
       http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/
   ]
2) drop imputil into the standard library, but don't go down the "replace
   Python's default mechanism with imputil"

Essentially, this gets imputil out there and usable, but it doesn't directly
impact Python's operation in 1.6.

>...
> - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch,
>   but none of us know what the state of this is -- is it crucial
>   anyway?).

Bill posted some patches. Little feedback. He will be reposting an updated
patch.

>...
> - Conservative GC, of cycles (this is basically done but needs a lot
>   more testing)

I would recommend doing this in small, reviewable steps. I believe there are
a lot of "framework" changes that can occur without actually changing Python
itself. After that first round, which will make adding GC easier, then we
can do Step 2 and add the real GC stuff.

>...

New item:
  - replace httplib.py with Greg's new module. plus docs/test.

>...
> As we saw it the most critical things that need to get done are
> testing the GC stuff and the SRE module.  Of those, the most critical
> is SRE since AFAIK, we're still waiting for the final complete code
> from /F.  I could be wrong about that.

I believe his recent patch (which AMK applied) brings it up to "current".

Cheers,
-g

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


From Vladimir.Marangozov@inrialpes.fr  Tue Jun 13 03:37:23 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Tue, 13 Jun 2000 04:37:23 +0200 (CEST)
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net> from "Barry A. Warsaw" at Jun 12, 2000 04:53:10 PM
Message-ID: <200006130237.EAA10373@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> - document more undocumented modules (codes - done; unicodedata -
>   needs work; mmap & pyexpat - Fred to integrate; curses - needs
>   updates; regrtest - push to 1.7, see below)

+ Write missing bits in the extend/embed docs (me)

Also, last time I ran the 1.6 alpha on AIX, test_mmap failed.
I have to take a closer look at this...

> - Fix ./ld_so_aix installation problem on AIX (anybody know more about
>   this???)

Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem
for building C extensions with distutils than an installation problem per se.
Some time ago, I saw a workaround checked in by Greg. If this is still judged
as a problem, I'd like to hear about it. This is a minor thing. I have yet
to install & run the distutil package on AIX, though, and see what happens.

> - enable threads by default if OS supports it

Who's going to champion this? I recall Greg Stein volunteering for it ;)
(or for something related)

> - Test the hell out of SRE.  (waiting for /F's complete implementation)
...
> As we saw it the most critical things that need to get done are
> testing the GC stuff and the SRE module.  Of those, the most critical
> is SRE since AFAIK, we're still waiting for the final complete code
> from /F.  I could be wrong about that.

It thas been my impression that people are pushing /F for SRE deliveries,
but he feels uncomfortable with a number of Unicode compromises (affecting
the SRE code and/or design???) and has some implementation hesitations.
Add to this the pression of the recent PythonWorks' release. In this context,
if there's something to be finished, it would be nice to stop pushing him
and help him finishing this project. Unfortunately, I can't offer any help
as I don't know much about RE engines.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From bwarsaw@python.org  Tue Jun 13 14:17:07 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Tue, 13 Jun 2000 09:17:07 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
 <200006130237.EAA10373@python.inrialpes.fr>
Message-ID: <14662.13395.520180.272688@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr> writes:

    >> - enable threads by default if OS supports it

    VM> Who's going to champion this? I recall Greg Stein volunteering
    VM> for it ;) (or for something related)

This isn't the free-threading stuff, which I think we're pushing back
to 1.7, right?  Just making --with-threads turned on by default if the
OS supports it.

    >> - Test the hell out of SRE.  (waiting for /F's complete
    >> implementation)
    VM> ...
    >> As we saw it the most critical things that need to get done are
    >> testing the GC stuff and the SRE module.  Of those, the most
    >> critical is SRE since AFAIK, we're still waiting for the final
    >> complete code from /F.  I could be wrong about that.

    VM> It thas been my impression that people are pushing /F for SRE
    VM> deliveries, but he feels uncomfortable with a number of
    VM> Unicode compromises (affecting the SRE code and/or design???)
    VM> and has some implementation hesitations.  Add to this the
    VM> pression of the recent PythonWorks' release. In this context,
    VM> if there's something to be finished, it would be nice to stop
    VM> pushing him and help him finishing this
    VM> project. Unfortunately, I can't offer any help as I don't know
    VM> much about RE engines.

Neither do I.  /F, how can we help?

-Barry


From mal@lemburg.com  Tue Jun 13 14:18:59 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 15:18:59 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
 <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net>
Message-ID: <394634C3.9C217913@lemburg.com>

bwarsaw@python.org wrote:
> 
> >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr> writes:
> 
>     >> - enable threads by default if OS supports it
> 
>     VM> Who's going to champion this? I recall Greg Stein volunteering
>     VM> for it ;) (or for something related)
> 
> This isn't the free-threading stuff, which I think we're pushing back
> to 1.7, right?  Just making --with-threads turned on by default if the
> OS supports it.

Ehm, didn't we agree on not enabling this by default ? From what
I've heard there are simply too many problems with thread
implementations which cause Python to break in different ways
(not necessarily Python's faults).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From gstein@lyra.org  Tue Jun 13 14:26:08 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 13 Jun 2000 06:26:08 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <394634C3.9C217913@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 03:18:59PM +0200
References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com>
Message-ID: <20000613062608.A19484@lyra.org>

On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote:
> bwarsaw@python.org wrote:
> > 
> > >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr> writes:
> > 
> >     >> - enable threads by default if OS supports it
> > 
> >     VM> Who's going to champion this? I recall Greg Stein volunteering
> >     VM> for it ;) (or for something related)
> > 
> > This isn't the free-threading stuff, which I think we're pushing back
> > to 1.7, right?  Just making --with-threads turned on by default if the
> > OS supports it.
> 
> Ehm, didn't we agree on not enabling this by default ? From what
> I've heard there are simply too many problems with thread
> implementations which cause Python to break in different ways
> (not necessarily Python's faults).

Threads are quite fine nowadays. Windows has enabled threads for years.
Recent Linux distros all turn it on.

etc

No sense in being afraid any more. :-)

Cheers,
-g

p.s. and yes: free-threading is post 1.6

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


From jim@interet.com  Tue Jun 13 14:32:33 2000
From: jim@interet.com (James C. Ahlstrom)
Date: Tue, 13 Jun 2000 09:32:33 -0400
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <394637F1.73E24380@interet.com>

Just a heads up that there is a patch in
patches@python.org to fix a bug in zipfile.py.

JimA


From mal@lemburg.com  Tue Jun 13 14:35:26 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 15:35:26 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com> <20000613062608.A19484@lyra.org>
Message-ID: <3946389E.B9C5E2F5@lemburg.com>

Greg Stein wrote:
> 
> On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote:
> > bwarsaw@python.org wrote:
> > >
> > > >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr> writes:
> > >
> > >     >> - enable threads by default if OS supports it
> > >
> > >     VM> Who's going to champion this? I recall Greg Stein volunteering
> > >     VM> for it ;) (or for something related)
> > >
> > > This isn't the free-threading stuff, which I think we're pushing back
> > > to 1.7, right?  Just making --with-threads turned on by default if the
> > > OS supports it.
> >
> > Ehm, didn't we agree on not enabling this by default ? From what
> > I've heard there are simply too many problems with thread
> > implementations which cause Python to break in different ways
> > (not necessarily Python's faults).
> 
> Threads are quite fine nowadays. Windows has enabled threads for years.
> Recent Linux distros all turn it on.

Ok, then make it default on Linux and Windows... but leave it
turned off on other platforms which still have problems
such as AIX.

> No sense in being afraid any more. :-)

Naa, not being afraid :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From jim@interet.com  Tue Jun 13 14:49:36 2000
From: jim@interet.com (James C. Ahlstrom)
Date: Tue, 13 Jun 2000 09:49:36 -0400
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org>
Message-ID: <39463BF0.823C0366@interet.com>

Greg Stein wrote:
> 
> On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
> > ... disclaimers applied ...
> >
> > - import hooks revamped (push this to 1.7)
> 
> The latest thought had two items here:
> 
> 1) incorporate feedback into imputil.py.
>    [ the feedback is visible at the end of the most recent version:
>        http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/
>    ]
> 2) drop imputil into the standard library, but don't go down the "replace
>    Python's default mechanism with imputil"
> 
> Essentially, this gets imputil out there and usable, but it doesn't directly
> impact Python's operation in 1.6.

I would very much like to see imputil.py in the distribution.  I
currently
use ZIP importing, and I have the ZIP importer class done, except that
it
is based on the old imputil.py.  I think ZIP importing could be a
popular feature.

JimA


From Vladimir.Marangozov@inrialpes.fr  Tue Jun 13 14:54:13 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Tue, 13 Jun 2000 15:54:13 +0200 (CEST)
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <3946389E.B9C5E2F5@lemburg.com> from "M.-A. Lemburg" at Jun 13, 2000 03:35:26 PM
Message-ID: <200006131354.PAA11656@python.inrialpes.fr>

M.-A. Lemburg wrote:
> 
> Ok, then make it default on Linux and Windows... but leave it
> turned off on other platforms which still have problems
> such as AIX.

No, I'd suggest turning it on by default everywhere and provide a
--without-thread configure option if it isn't there yet.

On AIX there are identified compiler/libthread combinations that work
or don't work. They can be detected though and since the compiler is
detected earlier, --with-thread can be automatically disabled with a
notification message about the conflict.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From mal@lemburg.com  Tue Jun 13 15:05:55 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 16:05:55 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
Message-ID: <39463FC3.16D6718@lemburg.com>

Vladimir Marangozov wrote:
> 
> M.-A. Lemburg wrote:
> >
> > Ok, then make it default on Linux and Windows... but leave it
> > turned off on other platforms which still have problems
> > such as AIX.
> 
> No, I'd suggest turning it on by default everywhere and provide a
> --without-thread configure option if it isn't there yet.
> 
> On AIX there are identified compiler/libthread combinations that work
> or don't work. They can be detected though and since the compiler is
> detected earlier, --with-thread can be automatically disabled with a
> notification message about the conflict.

Ok, let me drop in another argument:

How you are going to sell the performance loss due to
enabled thread support even when a script doesn't 
need threads at all ?

How about building two versions of the interpreter per default:
one with threads enabled and one without threads ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From gstein@lyra.org  Tue Jun 13 15:09:02 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 13 Jun 2000 07:09:02 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <39463FC3.16D6718@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 04:05:55PM +0200
References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com>
Message-ID: <20000613070902.G19484@lyra.org>

On Tue, Jun 13, 2000 at 04:05:55PM +0200, M.-A. Lemburg wrote:
> Vladimir Marangozov wrote:
> > 
> > M.-A. Lemburg wrote:
> > >
> > > Ok, then make it default on Linux and Windows... but leave it
> > > turned off on other platforms which still have problems
> > > such as AIX.
> > 
> > No, I'd suggest turning it on by default everywhere and provide a
> > --without-thread configure option if it isn't there yet.
> > 
> > On AIX there are identified compiler/libthread combinations that work
> > or don't work. They can be detected though and since the compiler is
> > detected earlier, --with-thread can be automatically disabled with a
> > notification message about the conflict.
> 
> Ok, let me drop in another argument:
> 
> How you are going to sell the performance loss due to
> enabled thread support even when a script doesn't 
> need threads at all ?
> 
> How about building two versions of the interpreter per default:
> one with threads enabled and one without threads ?

Hey, the sky is falling, too.

If people are concerned with the performance and want to eek that gain out,
then they can build with --without-threads

Not a problem.

"Gee. My operating system is too slow because it deals with all these
process and threads. Why can't I have a single-process OS like DOS? It runs
*so* much faster."

:-)

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


From bwarsaw@python.org  Tue Jun 13 15:34:34 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Tue, 13 Jun 2000 10:34:34 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <3946389E.B9C5E2F5@lemburg.com>
 <200006131354.PAA11656@python.inrialpes.fr>
Message-ID: <14662.18042.397439.614107@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr> writes:

    VM> On AIX there are identified compiler/libthread combinations
    VM> that work or don't work. They can be detected though and since
    VM> the compiler is detected earlier, --with-thread can be
    VM> automatically disabled with a notification message about the
    VM> conflict.

Can you provide a list of such combinations?

-Barry


From mal@lemburg.com  Tue Jun 13 15:44:20 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 16:44:20 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org>
Message-ID: <394648C4.2A701B5B@lemburg.com>

[enabling threads per default]
> >
> > How you are going to sell the performance loss due to
> > enabled thread support even when a script doesn't
> > need threads at all ?
> >
> > How about building two versions of the interpreter per default:
> > one with threads enabled and one without threads ?
> 
> Hey, the sky is falling, too.
> 
> If people are concerned with the performance and want to eek that gain out,
> then they can build with --without-threads
> 
> Not a problem.
> 
> "Gee. My operating system is too slow because it deals with all these
> process and threads. Why can't I have a single-process OS like DOS? It runs
> *so* much faster."

Oh well... never mind, as long as I can still build my
Python without threads, I'm fine :-)

BTW, what about the idea of adding threads at Python level
that was tossed around a few years ago ? Should be easy to
do given Christian's stackless patches together with the
asyncore libs...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From bwarsaw@python.org  Tue Jun 13 15:47:21 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Tue, 13 Jun 2000 10:47:21 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
 <39463FC3.16D6718@lemburg.com>
Message-ID: <14662.18809.468033.931803@anthem.concentric.net>

>>>>> "M" == M  <mal@lemburg.com> writes:

    M> How about building two versions of the interpreter per default:
    M> one with threads enabled and one without threads ?

Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1.

with threads: 8547.01 pystones/second
without threads: 9259.26 pystones/second

So an 8% hit isn't negligible but I think it's acceptable for the
benefit of being confidently able to distribute threaded apps.

-Barry


From petrilli@amber.org  Tue Jun 13 16:02:01 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Tue, 13 Jun 2000 11:02:01 -0400
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14662.18809.468033.931803@anthem.concentric.net>; from bwarsaw@python.org on Tue, Jun 13, 2000 at 10:47:21AM -0400
References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <14662.18809.468033.931803@anthem.concentric.net>
Message-ID: <20000613110201.B25344@trump.amber.org>

Barry A. Warsaw [bwarsaw@python.org] wrote:
> 
> >>>>> "M" == M  <mal@lemburg.com> writes:
> 
>     M> How about building two versions of the interpreter per default:
>     M> one with threads enabled and one without threads ?
> 
> Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1.
> 
> with threads: 8547.01 pystones/second
> without threads: 9259.26 pystones/second
> 
> So an 8% hit isn't negligible but I think it's acceptable for the
> benefit of being confidently able to distribute threaded apps.

Just as a data point, in the "Python problems" with Zope, this, along
with soe idiocy in packaging of RPMs in RedHat are the two biggest
problems we have a the Python level.  People not compiling with
threads turned on, and RedHat's decision to ship the header files
separate than the regular Python files. BLAH!

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From bwarsaw@python.org  Tue Jun 13 15:52:24 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Tue, 13 Jun 2000 10:52:24 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
 <39463FC3.16D6718@lemburg.com>
 <20000613070902.G19484@lyra.org>
 <394648C4.2A701B5B@lemburg.com>
Message-ID: <14662.19112.118940.63296@anthem.concentric.net>

>>>>> "M" == M  <mal@lemburg.com> writes:

    M> BTW, what about the idea of adding threads at Python level
    M> that was tossed around a few years ago ? Should be easy to
    M> do given Christian's stackless patches together with the
    M> asyncore libs...

Definitely not for 1.6!


From mal@lemburg.com  Tue Jun 13 16:17:13 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 17:17:13 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
 <39463FC3.16D6718@lemburg.com>
 <20000613070902.G19484@lyra.org>
 <394648C4.2A701B5B@lemburg.com> <14662.19112.118940.63296@anthem.concentric.net>
Message-ID: <39465079.64174882@lemburg.com>

"Barry A. Warsaw" wrote:
> 
> >>>>> "M" == M  <mal@lemburg.com> writes:
> 
>     M> BTW, what about the idea of adding threads at Python level
>     M> that was tossed around a few years ago ? Should be easy to
>     M> do given Christian's stackless patches together with the
>     M> asyncore libs...
> 
> Definitely not for 1.6!

Sure... just wanted to add a hint for 1.7 :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From DavidA@ActiveState.com  Tue Jun 13 18:31:32 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Tue, 13 Jun 2000 10:31:32 -0700
Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming
Message-ID: <PLEJJNOHDIGGLDPOGPJJMEMMCHAA.DavidA@ActiveState.com>

It's that time of year again, the O'Reilly Open Source Convention, including
the Python track, is fast approaching.   You can save up to $280 if you
register by Friday July 16. The event will be held this July 17-20 in
Monterey, California.

Meet all the key Python players, meet fellow Python enthusiasts, learn about
new Python developments, find Python-related jobs, and have fun at this
yearly event in sunny Monterey, CA.

For details on the Python tutorials, see
http://www.oreillynet.com/pub/w/python_tutorials.html

For details on the Python talks, see
http://www.oreillynet.com/pub/w/python_presentations.html

For details on the Conference as a whole, see
http://conferences.oreilly.com/oscon2000/index.html

Looking forward to meeting you there,


-- David Ascher
   OSCON Python Track Program Chair
   Senior Developer, ActiveState Tool Corporation

Students and academics should remember to sign up for reduced fees:
http://conferences.oreilly.com/oscon2000/register/



From DavidA@ActiveState.com  Tue Jun 13 19:00:41 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Tue, 13 Jun 2000 11:00:41 -0700
Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJMEMMCHAA.DavidA@ActiveState.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJMEMOCHAA.DavidA@ActiveState.com>

> It's that time of year again, the O'Reilly Open Source 
> Convention, including the Python track, is fast approaching.
> You can save up to $280 if you register by Friday July 16. 

Make that June 19.  Sorry about that.

--david ascher


From mal@lemburg.com  Tue Jun 13 20:25:04 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 21:25:04 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <39468A90.697D1CE5@lemburg.com>

"Barry A. Warsaw" wrote:
> 
> The O'Reilly Open Source conference[1] starts July 17th and it would
> be a nice target to release 1.6 final on the 14th, the Friday before
> the conference.  We all plan on being there.n
> 
> What do we need to do to hit this target?  If we figure a 2 week beta
> cycle, 1.6beta1 would have to be released June 30, with probably the
> last alpha on June 23.  This is a tight schedule; is it even
> feasible?.  Looking at Andrew's TODO list[2], here's what we came up
> with:
> 
> [...]
> - document more undocumented modules (codes - done; unicodedata -
>   needs work; mmap & pyexpat - Fred to integrate; curses - needs
>   updates; regrtest - push to 1.7, see below)

I'll take care of unicodedata. What's "codes" -- or did you mean
codecs ?

> - Unicode: Compress the size of unicodedatabase (waiting for Chris
>   Tismer patches?)

Right...

> - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch,
>   but none of us know what the state of this is -- is it crucial
>   anyway?).

Not crucial, but would be nice to have.

> - Unicode: the various XXX items in Misc/unicode.txt (we didn't
>   actually find such outstanding issues in this file).

There are no more discussion points... at least not in that
file ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From bwarsaw@python.org  Tue Jun 13 20:31:51 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Tue, 13 Jun 2000 15:31:51 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
 <39468A90.697D1CE5@lemburg.com>
Message-ID: <14662.35879.156976.61686@anthem.concentric.net>

>>>>> "M" == M  <mal@lemburg.com> writes:

    M> I'll take care of unicodedata. What's "codes" -- or did you
    M> mean codecs ?

Oops, yes, "codecs".

    M> There are no more discussion points... at least not in that
    M> file ;-)

<shudder> :)

-Barry


From gstein@lyra.org  Tue Jun 13 21:11:45 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 13 Jun 2000 13:11:45 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <39463BF0.823C0366@interet.com>; from jim@interet.com on Tue, Jun 13, 2000 at 09:49:36AM -0400
References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org> <39463BF0.823C0366@interet.com>
Message-ID: <20000613131145.O19484@lyra.org>

On Tue, Jun 13, 2000 at 09:49:36AM -0400, James C. Ahlstrom wrote:
> Greg Stein wrote:
> > On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
> > > ... disclaimers applied ...
> > >
> > > - import hooks revamped (push this to 1.7)
> > 
> > The latest thought had two items here:
> > 
> > 1) incorporate feedback into imputil.py.
> >    [ the feedback is visible at the end of the most recent version:
> >        http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/
> >    ]
> > 2) drop imputil into the standard library, but don't go down the "replace
> >    Python's default mechanism with imputil"
> > 
> > Essentially, this gets imputil out there and usable, but it doesn't directly
> > impact Python's operation in 1.6.
> 
> I would very much like to see imputil.py in the distribution.  I
> currently
> use ZIP importing, and I have the ZIP importer class done, except that
> it
> is based on the old imputil.py.  I think ZIP importing could be a
> popular feature.

Yes, this should happen.

In my current setup, I've got a second module named "importers.py" that has
some of the "standard" importers. It would go into there.

Oh, so I guess we'd also want to include importers.py into the distro.

All of this is preconditioned on getting at least some of that imputil work
done that is listed in the TODO area at the bottom of the file... I'm not
sure how soon I'll be able to get to that.

Cheers,
-g

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


From Vladimir.Marangozov@inrialpes.fr  Wed Jun 14 01:57:05 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Wed, 14 Jun 2000 02:57:05 +0200 (CEST)
Subject: [Python-Dev] --with-threads by default (was: Towards 1.6 Final)
In-Reply-To: <14662.18042.397439.614107@anthem.concentric.net> from "Barry A. Warsaw" at Jun 13, 2000 10:34:34 AM
Message-ID: <200006140057.CAA12560@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> 
> >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr> writes:
> 
>     VM> On AIX there are identified compiler/libthread combinations
>     VM> that work or don't work. They can be detected though and since
>     VM> the compiler is detected earlier, --with-thread can be
>     VM> automatically disabled with a notification message about the
>     VM> conflict.
> 
> Can you provide a list of such combinations?
> 

This is outlined in Misc/AIX-NOTES, section thread support.
I've heard that recent versions of gcc work as well, so long as the
executable is linked with AIX ld (not GNU ld).

Ideally, IMO, there should be an appropriate AC_TRY_RUN little threaded
program (or a program suite corresponding to different thread libs and or
standards for a given platform) that would disable threads on failure.
This approach has the merit of being applicable to all Unix flavors.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From trentm@activestate.com  Wed Jun 14 06:21:42 2000
From: trentm@activestate.com (Trent Mick)
Date: Tue, 13 Jun 2000 22:21:42 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <394701D6.37E6F560@yahoo.com>
References: <394701D6.37E6F560@yahoo.com>
Message-ID: <20000613222142.A27523@activestate.com>

On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote:
> Is this a bug or a feature?:
> 
> Python 1.6a2 (#4, Jun  9 2000, 02:22:41)  [GCC 2.95.2 19991024
> (release)] on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
> 
> >>> ''.isdigit()
> 1
> >>> ''.isspace()
> 1
> 

Good point, maybe. The __docs__ say:

"S.isdigit() -> int\n\
\n\
Return 1 if there are only digit characters in S,\n\
0 otherwise.";


static char isspace__doc__[] =
"S.isspace() -> int\n\
\n\
Return 1 if there are only whitespace characters in S,\n\
0 otherwise.";


I am not an English language lawyer so I could see both interpretations from
the doc strings. I agree, that the result with a zero length string is
surprising. 


Hi All,
Which should it be? Sorry, if this has been covered.



Trent


-- 
Trent Mick
trentm@activestate.com


From mal@lemburg.com  Wed Jun 14 09:43:45 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 10:43:45 +0200
Subject: [Python-Dev] Re: stringobject question
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com>
Message-ID: <394745C1.7FA27DCB@lemburg.com>

Trent Mick wrote:
> 
> On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote:
> > Is this a bug or a feature?:
> >
> > Python 1.6a2 (#4, Jun  9 2000, 02:22:41)  [GCC 2.95.2 19991024
> > (release)] on linux2
> > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
> >
> > >>> ''.isdigit()
> > 1
> > >>> ''.isspace()
> > 1
> >
> 
> Good point, maybe. The __docs__ say:
> 
> "S.isdigit() -> int\n\
> \n\
> Return 1 if there are only digit characters in S,\n\
> 0 otherwise.";
> 
> static char isspace__doc__[] =
> "S.isspace() -> int\n\
> \n\
> Return 1 if there are only whitespace characters in S,\n\
> 0 otherwise.";
> 
> I am not an English language lawyer so I could see both interpretations from
> the doc strings. I agree, that the result with a zero length string is
> surprising.
> 
> Hi All,
> Which should it be? Sorry, if this has been covered.

I guess it's a bug... a subtle one though, because in a
certain sense both 1 and 0 are acceptable. But since
'' is considered to be false, I think that returning 0
makes more sense.

I'll fix this to return 0 for emtpy strings and Unicode objects.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From Moshe Zadka <moshez@math.huji.ac.il>  Wed Jun 14 09:46:48 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Wed, 14 Jun 2000 11:46:48 +0300 (IDT)
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <394745C1.7FA27DCB@lemburg.com>
Message-ID: <Pine.GSO.4.10.10006141145320.2269-100000@sundial>

On Wed, 14 Jun 2000, M.-A. Lemburg wrote:

> > > >>> ''.isdigit()
> > > 1
> > > >>> ''.isspace()
> > > 1
> > >
> > 
> > Good point, maybe. The __docs__ say:
> > 
> > "S.isdigit() -> int\n\
> > \n\
> > Return 1 if there are only digit characters in S,\n\
> > 0 otherwise.";
> > 
> > static char isspace__doc__[] =
> > "S.isspace() -> int\n\
> > \n\
> > Return 1 if there are only whitespace characters in S,\n\
> > 0 otherwise.";
> > 
> > I am not an English language lawyer so I could see both interpretations from
> > the doc strings. I agree, that the result with a zero length string is
> > surprising.
> > 
> > Hi All,
> > Which should it be? Sorry, if this has been covered.
> 
> I guess it's a bug... a subtle one though, because in a
> certain sense both 1 and 0 are acceptable. But since
> '' is considered to be false, I think that returning 0
> makes more sense.
> 
> I'll fix this to return 0 for emtpy strings and Unicode objects.

I just realized something: if you change the semantics to mean "number of
digits", you'll get the right answer for all 0- and 1- length strings
and unicode objects.

just-an-observation-ly y'rs, Z.
--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From mal@lemburg.com  Wed Jun 14 10:18:10 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 11:18:10 +0200
Subject: [Python-Dev] Re: stringobject question
References: <Pine.GSO.4.10.10006141145320.2269-100000@sundial>
Message-ID: <39474DD2.BF51C872@lemburg.com>

Moshe Zadka wrote:
> 
> On Wed, 14 Jun 2000, M.-A. Lemburg wrote:
> 
> > > > >>> ''.isdigit()
> > > > 1
> > > > >>> ''.isspace()
> > > > 1
> > > >
> > >
> > > Good point, maybe. The __docs__ say:
> > >
> > > "S.isdigit() -> int\n\
> > > \n\
> > > Return 1 if there are only digit characters in S,\n\
> > > 0 otherwise.";
> > >
> > > static char isspace__doc__[] =
> > > "S.isspace() -> int\n\
> > > \n\
> > > Return 1 if there are only whitespace characters in S,\n\
> > > 0 otherwise.";
> > >
> > > I am not an English language lawyer so I could see both interpretations from
> > > the doc strings. I agree, that the result with a zero length string is
> > > surprising.
> > >
> > > Hi All,
> > > Which should it be? Sorry, if this has been covered.
> >
> > I guess it's a bug... a subtle one though, because in a
> > certain sense both 1 and 0 are acceptable. But since
> > '' is considered to be false, I think that returning 0
> > makes more sense.
> >
> > I'll fix this to return 0 for emtpy strings and Unicode objects.
> 
> I just realized something: if you change the semantics to mean "number of
> digits", you'll get the right answer for all 0- and 1- length strings
> and unicode objects.

Hmm, the .isXXX() tests should return 1/0 since they test
properties rather than count characters.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From billtut@microsoft.com  Wed Jun 14 11:12:48 2000
From: billtut@microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:12:48 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50>

Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?
From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
4.xxx.

I was all set to integrate the \N{...} support into the Unicode-escape
encoding, and dynamically load the hash table data in on demand, but
dynload_aix only cares about module entry points and won't let you specify
an explicit function name.

Ugh, how annoying...

Bill




From mal@lemburg.com  Wed Jun 14 11:19:44 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 12:19:44 +0200
Subject: [Python-Dev] AIX shared library support
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50>
Message-ID: <39475C40.EF9CE51B@lemburg.com>

Bill Tutt wrote:
> 
> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?
> >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> 4.xxx.
> 
> I was all set to integrate the \N{...} support into the Unicode-escape
> encoding, and dynamically load the hash table data in on demand, but
> dynload_aix only cares about module entry points and won't let you specify
> an explicit function name.

Uhm, why do you need to go that deep into the internals
of the import mechanism ? 

Wouldn't is suffice to put the hash table into a _ucnhash module
which get imported on demand (the import mechanism would then
take care of the rest) ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From billtut@microsoft.com  Wed Jun 14 11:12:48 2000
From: billtut@microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:12:48 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50>

Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?
From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
4.xxx.

I was all set to integrate the \N{...} support into the Unicode-escape
encoding, and dynamically load the hash table data in on demand, but
dynload_aix only cares about module entry points and won't let you specify
an explicit function name.

Ugh, how annoying...

Bill




From billtut@microsoft.com  Wed Jun 14 11:33:11 2000
From: billtut@microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:33:11 -0700
Subject: [Python-Dev] unicode character name patch status
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50>

I was all set to integrate the \N{...} support into the Unicode-escape
encoding, and dynamically load the hash table data in on demand, but
dynload_aix only cares about module entry points and won't let you specify
an explicit function name.

Ugh. So, its question and answer time folks:
1)	If we can't dynamically load the hash table data, is it that big of
a deal?
		Probably only for WinCE, palm pilot, etc, and they already
have patches against CVS.
2)	Or, should I just have a separate encoding?

I'd prefer to pick option #1 since Perl natively supports the syntax in
their strings. The data is all constant read/only data that will be mmapped
directly from the binary, so it only effects working set if the feature is
used.

Barry, Greg, Guido?
The only feedback I got last time I submitted the patch was from MAL, it'd
help if some other folks would comment on it.

Thanks,
Bill









From mal@lemburg.com  Wed Jun 14 11:45:01 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 12:45:01 +0200
Subject: [Python-Dev] unicode character name patch status
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50>
Message-ID: <3947622D.9995572E@lemburg.com>

[Me again, hope you don't mind ;-)]

Bill Tutt wrote:
> 
> I was all set to integrate the \N{...} support into the Unicode-escape
> encoding, and dynamically load the hash table data in on demand, but
> dynload_aix only cares about module entry points and won't let you specify
> an explicit function name.
> 
> Ugh. So, its question and answer time folks:
> 1)      If we can't dynamically load the hash table data, is it that big of
> a deal?
>                 Probably only for WinCE, palm pilot, etc, and they already
> have patches against CVS.
> 2)      Or, should I just have a separate encoding?
> 
> I'd prefer to pick option #1 since Perl natively supports the syntax in
> their strings. The data is all constant read/only data that will be mmapped
> directly from the binary, so it only effects working set if the feature is
> used.

Why can't you use PyImport_Import() to do the dynamic loading and
combine this with the standard unicode-escape codec ?
If it fails (e.g. the user has disabled the module entry in
Setup), then simply raise an exception.

I wouldn't want the hash table around linked statically -- it's
simply to big.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From billtut@microsoft.com  Wed Jun 14 11:48:49 2000
From: billtut@microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:48:49 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50>

MAL wrote:

> Bill Tutt wrote:
> > 
> > Is there any particular reason that dynload_aix.c doesn't use AIX's
dlopen?
> > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> > 4.xxx.
> 
> > I was all set to integrate the \N{...} support into the Unicode-escape
> > encoding, and dynamically load the hash table data in on demand, but
> > dynload_aix only cares about module entry points and won't let you
specify
> > an explicit function name.

> Uhm, why do you need to go that deep into the internals
> of the import mechanism ? 

> Wouldn't is suffice to put the hash table into a _ucnhash module
> which get imported on demand (the import mechanism would then
> take care of the rest) ?

It would suffice, but it'd be less efficient (and more work) since I'd then
have to access the data/hash functions through the normal PyObject
mechanisms instead of directly as C functions. That is, I'm trying to avoid
creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then
again, maybe I'm just being too performance sensitive.

The import mechanism got redone weirdly, all of the ways of doing dynamic
loading except AIX encode the idea that the function name must be preceeded
by "init".
Dynload_xxx.c is the wrong place to put that requirement. Whomever calls
_PyImport_GetDynLoadFunc() should handle that issue.

Just as an FYI, the only problem I've found so far with my last patch was
wrt handling Unicode characters with values in the UCS-4 code space. (Not
that there are any yet, but the code must handle that case anyway, sine I
don't want to have to go change it later.)

Bill



From mal@lemburg.com  Wed Jun 14 12:00:50 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 13:00:50 +0200
Subject: [Python-Dev] AIX shared library support
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50>
Message-ID: <394765E2.BFBEA135@lemburg.com>

Bill Tutt wrote:
> 
> MAL wrote:
> 
> > Bill Tutt wrote:
> > >
> > > Is there any particular reason that dynload_aix.c doesn't use AIX's
> dlopen?
> > > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> > > 4.xxx.
> >
> > > I was all set to integrate the \N{...} support into the Unicode-escape
> > > encoding, and dynamically load the hash table data in on demand, but
> > > dynload_aix only cares about module entry points and won't let you
> specify
> > > an explicit function name.
> 
> > Uhm, why do you need to go that deep into the internals
> > of the import mechanism ?
> 
> > Wouldn't is suffice to put the hash table into a _ucnhash module
> > which get imported on demand (the import mechanism would then
> > take care of the rest) ?
> 
> It would suffice, but it'd be less efficient (and more work) since I'd then
> have to access the data/hash functions through the normal PyObject
> mechanisms instead of directly as C functions. That is, I'm trying to avoid
> creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then
> again, maybe I'm just being too performance sensitive.

You could pass a pointer to the char* via a PyCObject. 

I usually export the whole module C API via such an object and it works
great: you can rely on module import to get the magic right and
still have a C API around which you can call directly from
C -- without the need to wrap anything in Python objects.

FYI, mxODBC and mxDateTime are tied together using this mechanism;
look in the mxDateTime.h|c files for details.
 
> The import mechanism got redone weirdly, all of the ways of doing dynamic
> loading except AIX encode the idea that the function name must be preceeded
> by "init".
> Dynload_xxx.c is the wrong place to put that requirement. Whomever calls
> _PyImport_GetDynLoadFunc() should handle that issue.

That's to Greg's address, I guess ;-)
 
> Just as an FYI, the only problem I've found so far with my last patch was
> wrt handling Unicode characters with values in the UCS-4 code space. (Not
> that there are any yet, but the code must handle that case anyway, sine I
> don't want to have to go change it later.)

Why is there a problem there ? Python currently uses UTF16
as native format. UTF-16 surrogates are not supported though...
and probably won't be for a while.

I don't see much of a problem here.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From billtut@microsoft.com  Wed Jun 14 12:10:44 2000
From: billtut@microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 04:10:44 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50>

MAL:
> Bill:
> > Just as an FYI, the only problem I've found so far with my last patch
was
> > wrt handling Unicode characters with values in the UCS-4 code space.
(Not
> > that there are any yet, but the code must handle that case anyway, sine
I
> > don't want to have to go change it later.)

> Why is there a problem there ? Python currently uses UTF16
> as native format. UTF-16 surrogates are not supported though...
> and probably won't be for a while.

The rest of Python may not care about UTF-16, but that's no particular
reason to not have this code support generating surrogates if an input
UnicodeData.txt happens to have character names for code points that require
surrogates.

Bill



From mwh21@cam.ac.uk  Wed Jun 14 12:18:27 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 14 Jun 2000 12:18:27 +0100
Subject: [Python-Dev] Can starship please have its front page back?
Message-ID: <m3d7lk33zw.fsf@atrus.jesus.cam.ac.uk>

I'm not sure if I should ask this here, but I've tried crew@starship
and comp.lang.python, so forgive me please.

There are links all over the place (eg. python.org, oriellynet) to
"http://starship.python.net/", which currently gets the gentle
browsing newbie a rather forbidding, somewhat out-of-date status page.
I don't really think this gives a good impression.  Particularly as
said page is no longer on the machine that had the hard disc
failure...

Cheers,
M.



From mal@lemburg.com  Wed Jun 14 12:36:25 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 13:36:25 +0200
Subject: [Python-Dev] AIX shared library support
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50>
Message-ID: <39476E39.E4163D20@lemburg.com>

Bill Tutt wrote:
> 
> MAL:
> > Bill:
> > > Just as an FYI, the only problem I've found so far with my last patch
> was
> > > wrt handling Unicode characters with values in the UCS-4 code space.
> (Not
> > > that there are any yet, but the code must handle that case anyway, sine
> I
> > > don't want to have to go change it later.)
> 
> > Why is there a problem there ? Python currently uses UTF16
> > as native format. UTF-16 surrogates are not supported though...
> > and probably won't be for a while.
> 
> The rest of Python may not care about UTF-16, but that's no particular
> reason to not have this code support generating surrogates if an input
> UnicodeData.txt happens to have character names for code points that require
> surrogates.

True. As long as the design permitts generating surrogates,
there should be no problem.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From Vladimir.Marangozov@inrialpes.fr  Wed Jun 14 15:48:01 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Wed, 14 Jun 2000 16:48:01 +0200 (CEST)
Subject: [Python-Dev] AIX shared library support
In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> from "Bill Tutt" at Jun 14, 2000 03:12:48 AM
Message-ID: <200006141448.QAA14090@python.inrialpes.fr>

Bill Tutt wrote:
> 
> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?
> >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> 4.xxx.

Historically, the dlopen interface (originally a Sun thing) was included
as a standard library (libdl.a) starting from AIX 4.3 (or 4.2). It doesn't
exist on AIX 3.x and AIX 4.1.x. There was a dlopen emulation library,
though, written by an old AIX guru, but it had to be installed manually
on these versions of AIX.

Then, slowly, IBM started to be more receptive about some defacto standards,
included libdl.a in the standard AIX distribution and introduced the -G flag
in ld (a la Sun and others) which adds -ldl to the link automatically.
But all this really works on AIX 4.3 and up.

So what is implemented in Python relies on lower-level dynamic linker
primitives that exist on all AIX releases. Furthermore, our original
goal was not to provide a complete (per symbol) runtime linker, hence
the current state of affairs. The 'init' entry point convention is a
Python convention.  It can be changed at link time, but still, there is
no a full featured dynamic linker and there is no reason to have it in
Python. Python wisely limits itself to the loading of a shared object (lib)
in memory, then to invoke an init function, without going into subtle
per-platform dynlinking details, which would have been a royal pain to
maintain anyway.

I second MAL's opinions: you really don't want to be so deep about
dynloads and it's better to fit in the current architecture. Personnally,
I won't care if my smiley takes half a second to load in memory. :-)

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From gstein@lyra.org  Wed Jun 14 16:00:23 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 14 Jun 2000 08:00:23 -0700
Subject: [Python-Dev] unicode character name patch status
In-Reply-To: <3947622D.9995572E@lemburg.com>; from mal@lemburg.com on Wed, Jun 14, 2000 at 12:45:01PM +0200
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> <3947622D.9995572E@lemburg.com>
Message-ID: <20000614080023.L27338@lyra.org>

On Wed, Jun 14, 2000 at 12:45:01PM +0200, M.-A. Lemburg wrote:
>...
> Bill Tutt wrote:
> > I was all set to integrate the \N{...} support into the Unicode-escape
> > encoding, and dynamically load the hash table data in on demand, but
> > dynload_aix only cares about module entry points and won't let you specify
> > an explicit function name.
> > 
> > Ugh. So, its question and answer time folks:
> > 1)      If we can't dynamically load the hash table data, is it that big of
> > a deal?
> >                 Probably only for WinCE, palm pilot, etc, and they already
> > have patches against CVS.
> > 2)      Or, should I just have a separate encoding?
> > 
> > I'd prefer to pick option #1 since Perl natively supports the syntax in
> > their strings. The data is all constant read/only data that will be mmapped
> > directly from the binary, so it only effects working set if the feature is
> > used.
> 
> Why can't you use PyImport_Import() to do the dynamic loading and
> combine this with the standard unicode-escape codec ?
> If it fails (e.g. the user has disabled the module entry in
> Setup), then simply raise an exception.
> 
> I wouldn't want the hash table around linked statically -- it's
> simply to big.

I'm with MAL. Use Python's import mechanism. That gets you the dynamic load
stuff no problem. It *also* handles the case where the module is statically
linked.

If you go play games with the dynload stuff, then it would be a bitch to
build a single, statically-linked executable.

Cheers,
-g

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


From akuchlin@mems-exchange.org  Wed Jun 14 17:13:23 2000
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Wed, 14 Jun 2000 12:13:23 -0400
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <20000614121323.A13993@amarok.cnri.reston.va.us>

On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
>If we figure a 2 week beta cycle, ...

Unicode support, a new regex engine, various minor backward
incompatible changes that may or may not cause people problems...  a 2-week
beta seems too short.

--amk


From billtut@microsoft.com  Wed Jun 14 17:29:30 2000
From: billtut@microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 09:29:30 -0700
Subject: [Python-Dev] unicode character name patch status
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>


> From: Greg Stein [mailto:gstein@lyra.org]

> I'm with MAL. Use Python's import mechanism. That gets you 
> the dynamic load
> stuff no problem. It *also* handles the case where the module 
> is statically
> linked.
> 

Ok, ok, so much for the idea about modifying as few lines as possible in my
patch. :)

> If you go play games with the dynload stuff, then it would be 
> a bitch to
> build a single, statically-linked executable.
> 

Nah, thats what the config.h hAVE_... for dynamic load support #define is
for. :)

Bill


From trentm@activestate.com  Wed Jun 14 18:36:32 2000
From: trentm@activestate.com (Trent Mick)
Date: Wed, 14 Jun 2000 10:36:32 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <394745C1.7FA27DCB@lemburg.com>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com>
Message-ID: <20000614103632.C29778@activestate.com>

On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote:
> 
> I guess it's a bug... a subtle one though, because in a
> certain sense both 1 and 0 are acceptable. But since
> '' is considered to be false, I think that returning 0
> makes more sense.
> 
> I'll fix this to return 0 for emtpy strings and Unicode objects.

These are copied from Java, are they not? What do the Java equivalents
return?

Trent



-- 
Trent Mick
trentm@activestate.com


From gstein@lyra.org  Wed Jun 14 22:52:08 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 14 Jun 2000 14:52:08 -0700
Subject: [Python-Dev] unicode character name patch status
In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>; from billtut@microsoft.com on Wed, Jun 14, 2000 at 09:29:30AM -0700
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>
Message-ID: <20000614145208.D28280@lyra.org>

On Wed, Jun 14, 2000 at 09:29:30AM -0700, Bill Tutt wrote:
> > From: Greg Stein [mailto:gstein@lyra.org]
>...
> > If you go play games with the dynload stuff, then it would be 
> > a bitch to
> > build a single, statically-linked executable.
> 
> Nah, thats what the config.h hAVE_... for dynamic load support #define is
> for. :)

Just to beat a dead horse here: no. Just because config.h says that I
*could* dynamically load doesn't mean that I *want* to. If I want to build a
mother, static Python and I want the name table bundled in, then any dynamic
loading that you make explicit is just going to gum up the process.

Now shut up, and drink your Kool-Aid. :-)

Cheers,
-g

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


From thomas@xs4all.net  Thu Jun 15 18:53:27 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 15 Jun 2000 19:53:27 +0200
Subject: [Python-Dev] Augmented assignment
Message-ID: <20000615195327.R8000@xs4all.nl>

I'd like some (minor) feedback on the augmented assignment thing I'm working
on. I understand Guido is the only one who accepts patches like this, and
appreciate that, but I'm hoping someone can at least tell me what I'm doing
wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
flap, just tell me so and I'll calm down.

I also appreciate the fact that the patch is quite large, and not many
people have the time to scrutinize each version, so I'll summerize the
issues I'm uncertain about.

 * The patch needs to add a new type of opcode, one that takes 2 arguments.
This is because the opcodes that load, change and store a name need one
argument for the index in the name table (or local variable number), and one
argument for the actual operation.

It could also work by using PyInt or another PyObject to pass the extra
argument on the stack, but I don't think pushing a non-PyObject-pointer onto
the stack is a good idea. Adding 2-argument opcodes seemed the easiest
solution.

However, I'm not really into Python-hacking (or was, I should say, because
it's great fun) and the python-dev list doesn't seem to be searchable ;) so
I can't know if this issue has come up before. Has it ? Would the new
opcode-type be an unsurpassable problem ? should I use the stack instead ?

* The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries
in the PyNumberMethods struct and 2 new entries in the PySequenceMethods
struct. Would that conceivably be a problem ? I've heard people on the
python-list complain about this ;-P

 * Should I start sending the patch, in pieces, to the patches-list, or is
it a wasted effort because noone will touch it until Guido is back ? If I
should send it, should I send it in one large patch (minus autogenerated
files) or in nice functionality-sized pieces ?

 * How 'cool' does Guido actually think this syntax is ? Apparently the
subject has come up a few times ;) and I got positive signals from both Tim
and Guido, but if the patch won't go in as a patch, and won't actually be
used other than some inspiration for a future rewrite of the CPython core,
I'm not going to worry too much about the patch ;)

I'm trying to get my boss to send me to OSCON2000 to harass Guido about
these issues himself, but he (my boss) isn't co-operating ;-P (Not
suprising, as Python isn't quite part of my job description, *snif*)

Regards,

-- 
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  Thu Jun 15 19:12:50 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 15 Jun 2000 20:12:50 +0200
Subject: [Python-Dev] Augmented assignment
References: <20000615195327.R8000@xs4all.nl>
Message-ID: <39491CA2.2BDC0DDC@lemburg.com>

Thomas Wouters wrote:
> 
> I'd like some (minor) feedback on the augmented assignment thing I'm working
> on. I understand Guido is the only one who accepts patches like this, and
> appreciate that, but I'm hoping someone can at least tell me what I'm doing
> wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> flap, just tell me so and I'll calm down.

I'd make this a 1.7 issue. 1.6 should go into the stabilization
phase and big complicated patches like yours should receive some
more design and concept discussion before getting checked in.

BTW, with "augmented assign" I suppose you mean things like
a += 1 and b *= 2, right ?

> I also appreciate the fact that the patch is quite large, and not many
> people have the time to scrutinize each version, so I'll summerize the
> issues I'm uncertain about.
> 
>  * The patch needs to add a new type of opcode, one that takes 2 arguments.
> This is because the opcodes that load, change and store a name need one
> argument for the index in the name table (or local variable number), and one
> argument for the actual operation.
> 
> It could also work by using PyInt or another PyObject to pass the extra
> argument on the stack, but I don't think pushing a non-PyObject-pointer onto
> the stack is a good idea. Adding 2-argument opcodes seemed the easiest
> solution.
> 
> However, I'm not really into Python-hacking (or was, I should say, because
> it's great fun) and the python-dev list doesn't seem to be searchable ;) so
> I can't know if this issue has come up before. Has it ? Would the new
> opcode-type be an unsurpassable problem ? should I use the stack instead ?

Any reason you can't do this with the existing op codes ?

E.g. a += b

1. load a
2. load b
3. add
4. store a

> * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries
> in the PyNumberMethods struct and 2 new entries in the PySequenceMethods
> struct. Would that conceivably be a problem ? I've heard people on the
> python-list complain about this ;-P

More generic solutions are usually more accepted.

BTW, before hacking too much into this, you ought to consider
that we are planning for rich comparisons and decentralized
coercion in 1.7 (this was planned for 1.6, but David and I
got carried away with other things).
 
I wouldn't want to have to hack 11 new slots to get this right...

>  * Should I start sending the patch, in pieces, to the patches-list, or is
> it a wasted effort because noone will touch it until Guido is back ? If I
> should send it, should I send it in one large patch (minus autogenerated
> files) or in nice functionality-sized pieces ?

Better put it on a web page and inform python-dev of new features,
enhancements, etc.
 
>  * How 'cool' does Guido actually think this syntax is ? Apparently the
> subject has come up a few times ;) and I got positive signals from both Tim
> and Guido, but if the patch won't go in as a patch, and won't actually be
> used other than some inspiration for a future rewrite of the CPython core,
> I'm not going to worry too much about the patch ;)

Having a patch is good for discussion, whether it gets incorporated
is a different issue ;-)
 
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From bckfnn@worldonline.dk  Thu Jun 15 19:16:03 2000
From: bckfnn@worldonline.dk (Finn Bock)
Date: Thu, 15 Jun 2000 18:16:03 GMT
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <20000614103632.C29778@activestate.com>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com>
Message-ID: <39491d4f.4591422@smtp.worldonline.dk>

>On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote:
>> 
>> I guess it's a bug... a subtle one though, because in a
>> certain sense both 1 and 0 are acceptable. But since
>> '' is considered to be false, I think that returning 0
>> makes more sense.
>> 
>> I'll fix this to return 0 for emtpy strings and Unicode objects.

[Trent Mick]

>These are copied from Java, are they not? What do the Java equivalents
>return?

The .isXX methods does not exists on java strings, only on the Character
class. So in java they can never be called on anything with length 0.

regards,
finn


From trentm@activestate.com  Thu Jun 15 19:28:57 2000
From: trentm@activestate.com (Trent Mick)
Date: Thu, 15 Jun 2000 11:28:57 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <39491d4f.4591422@smtp.worldonline.dk>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk>
Message-ID: <20000615112857.A4508@activestate.com>

On Thu, Jun 15, 2000 at 06:16:03PM +0000, Finn Bock wrote:
> >These are copied from Java, are they not? What do the Java equivalents
> >return?
> 
> The .isXX methods does not exists on java strings, only on the Character
> class. So in java they can never be called on anything with length 0.
> 

Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
unless others have any opposition.

Trent

-- 
Trent Mick
trentm@activestate.com


From fdrake@beopen.com  Thu Jun 15 19:34:02 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 15 Jun 2000 14:34:02 -0400 (EDT)
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <20000615112857.A4508@activestate.com>
References: <394701D6.37E6F560@yahoo.com>
 <20000613222142.A27523@activestate.com>
 <394745C1.7FA27DCB@lemburg.com>
 <20000614103632.C29778@activestate.com>
 <39491d4f.4591422@smtp.worldonline.dk>
 <20000615112857.A4508@activestate.com>
Message-ID: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com>

Trent Mick writes:
 > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
 > unless others have any opposition.

  This sounds good to me.
  Marc-Andre, go ahead and checkin anything that isn't already in
whenever you're ready; I've not seen any hints of opposition yet, and
there's been enough waiting to just check it in.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From trentm@activestate.com  Thu Jun 15 19:58:27 2000
From: trentm@activestate.com (Trent Mick)
Date: Thu, 15 Jun 2000 11:58:27 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com>
Message-ID: <20000615115827.A4657@activestate.com>

On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote:
> 
> Trent Mick writes:
>  > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
>  > unless others have any opposition.
> 
>   This sounds good to me.
>   Marc-Andre, go ahead and checkin anything that isn't already in
> whenever you're ready; I've not seen any hints of opposition yet, and
> there's been enough waiting to just check it in.
> 

From what I have seen it is already in.

Trent

-- 
Trent Mick
trentm@activestate.com


From mal@lemburg.com  Thu Jun 15 20:10:43 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 15 Jun 2000 21:10:43 +0200
Subject: [Python-Dev] Re: stringobject question
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> <20000615115827.A4657@activestate.com>
Message-ID: <39492A33.75440AA4@lemburg.com>

Trent Mick wrote:
> 
> On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote:
> >
> > Trent Mick writes:
> >  > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
> >  > unless others have any opposition.
> >
> >   This sounds good to me.
> >   Marc-Andre, go ahead and checkin anything that isn't already in
> > whenever you're ready; I've not seen any hints of opposition yet, and
> > there's been enough waiting to just check it in.
> >
> 
> >From what I have seen it is already in.

Right ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From fdrake@beopen.com  Thu Jun 15 20:21:40 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 15 Jun 2000 15:21:40 -0400 (EDT)
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <39492A33.75440AA4@lemburg.com>
References: <394701D6.37E6F560@yahoo.com>
 <20000613222142.A27523@activestate.com>
 <394745C1.7FA27DCB@lemburg.com>
 <20000614103632.C29778@activestate.com>
 <39491d4f.4591422@smtp.worldonline.dk>
 <20000615112857.A4508@activestate.com>
 <14665.8602.65230.481663@cj42289-a.reston1.va.home.com>
 <20000615115827.A4657@activestate.com>
 <39492A33.75440AA4@lemburg.com>
Message-ID: <14665.11460.597390.222317@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Trent Mick wrote:
 > > >From what I have seen it is already in.
 > 
 > Right ;-)

  I may have mentioned that I've been losing track of all the
patches.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From thomas@xs4all.net  Thu Jun 15 22:41:53 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 15 Jun 2000 23:41:53 +0200
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <39491CA2.2BDC0DDC@lemburg.com>; from mal@lemburg.com on Thu, Jun 15, 2000 at 08:12:50PM +0200
References: <20000615195327.R8000@xs4all.nl> <39491CA2.2BDC0DDC@lemburg.com>
Message-ID: <20000615234153.S8000@xs4all.nl>

On Thu, Jun 15, 2000 at 08:12:50PM +0200, M.-A. Lemburg wrote:

> > I'd like some (minor) feedback on the augmented assignment thing I'm working
> > on. I understand Guido is the only one who accepts patches like this, and
> > appreciate that, but I'm hoping someone can at least tell me what I'm doing
> > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> > flap, just tell me so and I'll calm down.

> I'd make this a 1.7 issue. 1.6 should go into the stabilization
> phase and big complicated patches like yours should receive some
> more design and concept discussion before getting checked in.

That's more or less what I figured, though I wasn't aware of the revised
schedule on 1.6 ;)

> BTW, with "augmented assign" I suppose you mean things like
> a += 1 and b *= 2, right ?

Yes; All binary operands, to be exact:

'+=' | '-=' | '*=' | '/=' | '%=' | '&=' | '|=' | '^=' | '<<=' | '>>=' | '**='

> Any reason you can't do this with the existing op codes ?
> 
> E.g. a += b
> 
> 1. load a
> 2. load b
> 3. add
> 4. store a

Yes: It wouldn't be thread-safe, and it would be impossible (or at least
very hard and complicated) to see the difference between 'a += b' and 'a = a
+ b', which would make it very hard to make them functionally different.

The patch not only adds the syntax (Michael Hudsons' patch did that, roughly
how you describe it) but also adds generic semantics for in-place operations
on builtin types, extension types and classes.

> > * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries
> > in the PyNumberMethods struct and 2 new entries in the PySequenceMethods
> > struct. Would that conceivably be a problem ? I've heard people on the
> > python-list complain about this ;-P

> More generic solutions are usually more accepted.

I thought so, but I didn't see a good, simple addition to the API that
wasn't too complicated. What it adds now is 'PyNumber_InPlaceAdd()', which
is functionally the same as 'PyNumber_Add()', except that the left-hand-side
object is given the chance to define the operation in-place. That's also
where the new PyNumberMethods/PySequenceMethods members come in.

> BTW, before hacking too much into this, you ought to consider
> that we are planning for rich comparisons and decentralized
> coercion in 1.7 (this was planned for 1.6, but David and I
> got carried away with other things).

Too late. Most, if not all, of the patch is already written. Not that that's
a reason to accept it, not at all ;)

> I wouldn't want to have to hack 11 new slots to get this right...

I'm not sure if that's necessary, but I'll have to look into your
comparison/coercion work before I can say that for sure. In any case, I'd be
perfectly happy with adjusting the augmented-assignment patch to the
comparison/coercion change, instead of the other way 'round ;)

> >  * Should I start sending the patch, in pieces, to the patches-list, or is
> > it a wasted effort because noone will touch it until Guido is back ? If I
> > should send it, should I send it in one large patch (minus autogenerated
> > files) or in nice functionality-sized pieces ?

> Better put it on a web page and inform python-dev of new features,
> enhancements, etc.

The webpage is already there, with the version I sent to python-list last
Friday. That patch is missing quite a few things, but it serves as an
example of what it should do: http://www.xs4all.nl/~thomas/python/
I hope to upload an almost-finished version tomorrow morning (Amsterdam
time) - if work doesn't intervene again.

> >  * How 'cool' does Guido actually think this syntax is ? Apparently the
> > subject has come up a few times ;) and I got positive signals from both Tim
> > and Guido, but if the patch won't go in as a patch, and won't actually be
> > used other than some inspiration for a future rewrite of the CPython core,
> > I'm not going to worry too much about the patch ;)

> Having a patch is good for discussion, whether it gets incorporated
> is a different issue ;-)

Of course :) The thing is, the patch is actually quite done. What I'm doing
now is more or less auditing and optimizing it, and that is probably a waste
of time if the patch is going to need a complete rewrite anyway. On the
other hand, I'm getting a couple of ideas for optimization of the 'normal'
operations too, so it's not like it's wasted time. I guess I'll start a new
thread on that issue if/when I reach it ;)

Thanx for the feedback!
-- 
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  Thu Jun 15 22:30:45 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Thu, 15 Jun 2000 23:30:45 +0200 (MEST)
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000  7:53:27 pm"
Message-ID: <m132hDp-000DieC@artcom0.artcom-gmbh.de>

Hi!

Thomas Wouters:
> I'd like some (minor) feedback on the augmented assignment thing I'm working
> on. I understand Guido is the only one who accepts patches like this, and
> appreciate that, but I'm hoping someone can at least tell me what I'm doing
> wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> flap, just tell me so and I'll calm down.

Disclaimer: The following is only *my* personal opinion.
But since you have asked for it. ;-)

I don't like this augmented assignment syntax at all! (independent 
from your particular implementation, which I didn't had a look at).  

Augmented assignments are unPythonic because they don't add any new 
functionality to the language.  From what I've seen, all people, 
who ever missed it, were experienced C-programmers.  And C shows 
its inheritance from various assembler languages in its 
augmented assignment and its ++pre and post increment++ and decrement--
operators.  Many of these features were born in the 70s of the
last century:  At that time optimizing was very important and 
compilers were relatively dumb.  This applies in no way to the
situation we have today with Python.

What remains is, that augmented assignments are only a short cut
notation, which introduces more variability to express the same
algorithms and so they hurt readability.  This feature must be learned
additionally, where normal assignment are easiely understood from
school mathematics.  It also introduces many more possibilities to make
subtle mistakes, since it is not obvious (at least to No-C-programmers)
when and how often the index expression will be valuated.  Look at
the following example:

        class Bar:
	    def __init__(self):
	        self.val = 0
	    def __call__(self):
	        self.val = self.val + 1
		return self.val
	bar = Bar()
	foo = range(4)
and than
	foo[bar()] = foo[bar()] + bar()
	print foo
versus
	foo[bar()] += bar()
	print foo

Todays Python forces the programmer to explicitly say, what should happen.

So I think these +=,-=,*= features are evil.  In the same sense as macro
preprocessors are evil in 'C' and 'from module import *' is already evil
in Python.  Add more and more of this stuff and you end up on the dark 
side of programming.

If augmented assignments will ever become part of Python, I would at least
like to see a strong recommendation added to the styleguide not to use 
this feature.

Enough with this rant.

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)


From nascheme@enme.ucalgary.ca  Thu Jun 15 23:26:35 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 15 Jun 2000 16:26:35 -0600
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <m132hDp-000DieC@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200
References: <20000615195327.R8000@xs4all.nl> <m132hDp-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <20000615162635.B11507@acs.ucalgary.ca>

On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote:
> Augmented assignments are unPythonic because they don't add any new 
> functionality to the language.
[...]
> 	foo[bar()] = foo[bar()] + bar()
> versus
> 	foo[bar()] += bar()

Not quite.  I think with the proposed implementation += could
modify the LHS object in place.  This could be a big performance
win for things like NumPy objects.  OTOH, the same effect can be
achieved with a method call:

    foo[bar()].add(bar())

  Neil


From thomas@xs4all.net  Thu Jun 15 23:25:23 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 16 Jun 2000 00:25:23 +0200
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <m132hDp-000DieC@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200
References: <20000615195327.R8000@xs4all.nl> <m132hDp-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <20000616002523.T8000@xs4all.nl>

On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote:

> Thomas Wouters:
> > I'd like some (minor) feedback on the augmented assignment thing I'm working
> > on. I understand Guido is the only one who accepts patches like this, and
> > appreciate that, but I'm hoping someone can at least tell me what I'm doing
> > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> > flap, just tell me so and I'll calm down.

> I don't like this augmented assignment syntax at all! (independent 
> from your particular implementation, which I didn't had a look at).  

> Augmented assignments are unPythonic because they don't add any new 
> functionality to the language. 

[ snip quite good summary of the problems with augmented assignment ]

I agree with almost all of the above, except the statement that they do not
add anything. If augmented assignment was only syntactic sugar I would not
have taken Michael's patch and rewritten it; I do not propose auto-increment
operators, and would have a hard time accepting them.

However, augmented assignment *does* add new functionality, because it is a
way to inform the object that is being operated on, that it can do the
operation in-place if it so wants. Instead of having to create a new object,
which might be costly in cpu and/or memory, and doing the operation on that,
the object can choose to do the operation on itself, and return 'self'. If
the object doesn't want to do that, it doesn't have to be any different from
'x = x + 1'. (In fact, augmented assignment should, and does, fall back to
that.)

>
>
> [ snip good example of indexes-with-sideffect ]
>
>

This actually proves the point of augmented assignment. With the syntax

foo[bar()] += 1

You can see that bar() is only called once, so you *know* what index is
being retrieved, and that the new value is stored in the same place. Using

foo[bar()] = foo[bar()] + 1

you can't see by the expression which value is being retrieved and where the
result is stored. You have to remember the rules about operand evaluation to
see that. Yes, 

foo[bar()] += bar()

is indeed more complicated than the above example, but absolutely not more
complicated than the normal-add version that calls bar() three times.

The augmented assignment syntax is actually clearer and more easy to
explain, in my opinion. You can only (accurately) explain

a = a + 1 

as 'add a and 1, and store the result in a'. However,

a += 1

is simply 'add 1 to a'. 

> So I think these +=,-=,*= features are evil.  In the same sense as macro
> preprocessors are evil in 'C' and 'from module import *' is already evil
> in Python.  Add more and more of this stuff and you end up on the dark 
> side of programming.

Well, I like the odd Star Wars film, but I do not believe that the Dark Side
lies opposite the Right Way. The Right Way can't help but be very close to
the Dark Side. You may dislike macro preprocessors in C, but CPython (and
almost all other C code) do use them alot, for functionality which would
otherwise be very hard (or complicated and unreadable) to achieve. The same
goes for 'from module import *' in Python.

The funny thing is that augmented assignment operators and auto in/decrement
operators might be added to C because they were easier to optimize (I dont
think that was the main reason, but I wasn't there ;) but any halfway decent
C compiler doesn't need that explicitness, and can optimize the 'x = x + 1'
expression directly. Python, however, can (currently) not do that, and
*does* need the added syntax to be able to do optimization, even if only to
let the object know it's safe to operate on itself.

Of course, once there are semantics for inplace-operations, it _might_ be
possible to optimize 'x = x + 1' into 'x += 1' ;)

> If augmented assignments will ever become part of Python, I would at least
> like to see a strong recommendation added to the styleguide not to use 
> this feature.

If such a recommendation was added, the change would be useless. Better get
Guido to not add this feature instead, or Python will end up like Perl ;)
I honestly do not care much wether it gets added or not. If Guido decides
not to add it, I'm certain he has very valid rasons for it, and I dont
assume to know as much about Python, the applicability of Python, the
average usage of Python or the Future of Python as he sees it, as him ;)

I-don't-know-any-of-that-in-fact-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 gmcm@hypernet.com  Fri Jun 16 01:44:38 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Thu, 15 Jun 2000 20:44:38 -0400
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <m132hDp-000DieC@artcom0.artcom-gmbh.de>
References: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000  7:53:27 pm"
Message-ID: <1251006162-53585376@hypernet.com>

Peter Funk wrote:

> Augmented assignments are unPythonic because they don't add any
> new functionality to the language.  

Most changes to Python are nothing but syntactic sugar.

In concept, I'm +0.9 on simple "name += val".

I'm -0.9 on "expr += val" if the behavior requires an 
understanding of Python internals, and +0 otherwise (since I 
avoid "expr = expr + val" if possible).

Thomas's statement that the complexity is largely due to 
problems of thread safety is eminently believable, and I doubt 
that the syntactic sugar (which is at least somewhat 
desirable) is worth the price. 

> ....  Many of these features were born in the
> 70s of the last century:  At that time optimizing was very
> important and compilers were relatively dumb.  This applies in no
> way to the situation we have today with Python.

Actually, Python's compiler is very dumb, and optimization is 
still important. So where I would use "expr" 3 times in 3 lines 
in C / C++ and *expect* the compiler to optimize it into one 
evaluation, I have to remind myself to use an extra line and 
compute it once in Python myself. One might argue that that's 
unPythonic, because it inhibits the direct expression of the 
idea. One might, but I won't.
 
> What remains is, that augmented assignments are only a short cut
> notation, which introduces more variability to express the same
> algorithms and so they hurt readability.  

It definitely *improves* the readability of incrementing very-long-
expression. Just not to the point of readability ;-).

> ...  It also introduces many more
> possibilities to make subtle mistakes,

and eliminates othes, such as typos...

> since it is not obvious
> (at least to No-C-programmers) when and how often the index
> expression will be valuated.  Look at the following example:
> 
>         class Bar:
>      def __init__(self):
>          self.val = 0
>      def __call__(self):
>          self.val = self.val + 1
>   return self.val
>  bar = Bar()
>  foo = range(4)
> and than
>  foo[bar()] = foo[bar()] + bar()
>  print foo
> versus
>  foo[bar()] += bar()
>  print foo

To understand the first requires a sufficiently deep 
understanding of how Python works that I doubt the 2nd is 
really much worse. They're both the other side of horrid.
 
I don't care very much myself, but none of these arguments 
are without strong counters (which we've all read many times 
on c.l.py). The only real basis, I think, is whether the changes 
complexify things too much.

- Gordon


From pf@artcom-gmbh.de  Fri Jun 16 08:11:57 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Fri, 16 Jun 2000 09:11:57 +0200 (MEST)
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <1251006162-53585376@hypernet.com> from Gordon McMillan at "Jun 15, 2000  8:44:38 pm"
Message-ID: <m132qIH-000DieC@artcom0.artcom-gmbh.de>

Hi,

[...]
[me]:
> > What remains is, that augmented assignments are only a short cut
> > notation, which introduces more variability to express the same
> > algorithms and so they hurt readability.  

[Gordon McMillan]:
> It definitely *improves* the readability of incrementing very-long-
> expression. Just not to the point of readability ;-).

I agree, that very complicated multidimensional expressions, (possible
mixing tuples, lists, dicts and computations) are even more errorprone
, if you have to repeat them twice just to increment an element.
But than you would use an helper variable to hold the index expression
anyway.

example:

   foo = range(3); bar = range(3); cols = ('red', 'green', 'blue')
   chans = {'red':2, 'green':1, 'blue':0}

   foo[chans[cols[2-bar[0]]]] = foo[chans[cols[2-bar[0]]]] + 1

is indeed ugly.  But

   i = chans[cols[2-bar[0]]]; foo[i] = foo[i] + 1

is at least just as (un)readable as 

   foo[chans[cols[bar[0]]]] += 1

with the exception, that even newbies get a chance to figure out, 
what the former line is supposed to do without having to read a language 
reference manual telling them something about augmented assignments.

But you are right:  This has been discussed often enough on c.l.p.

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)


From Fredrik Lundh" <effbot@telia.com  Fri Jun 16 17:24:26 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 18:24:26 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
Message-ID: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>

(the eff-bot is back!)

is there any special reason for this restriction:

Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> a =3D [1, 2, 3]
>>> a.extend((4, 5, 6))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: list.extend() argument must be a list

from the look of it, it should be trivial to change list.extend
to use the abstract sequence API instead of the list API.

has anyone benchmarked the abstract sequence API?  how
much slower is it?  would it be a good idea to treat lists as
a special case, to avoid slowing down existing code?

other comments?

if I don't hear anything, I'll post patches later this weekend.

</F>



From Fredrik Lundh" <effbot@telia.com  Fri Jun 16 17:41:36 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 18:41:36 +0200
Subject: [Python-Dev] possible Tkinter speedup
Message-ID: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid>

the _flatten method in Tkinter is one of the major performance
bottlenecks for Python/Tk programmers.  the method "flattens"
a nested sequence, by repeatedly adding tuples to each other.

obviously, this isn't very efficient if the sequences are longer
than, say, five to ten items...  and has of course led to claims
like "wxPython is a thousand times faster than Tkinter".

anyway, taking recent changes to Python into account, it should
be possible to speed this up quite a bit.

the old code looked like this:

    def _flatten(tuple):
        res =3D ()
        for item in tuple:
            if type(item) in (TupleType, ListType):
                res =3D res + _flatten(item)
            elif item is not None:
                res =3D res + (item,)
        return res

after a some trials and errors, here's my proposed replacement:

    def _flatten1(seq):
        res =3D []
        for item in seq:
            if type(item) in (TupleType, ListType):
                res.extend(_flatten1(item))
            elif item is not None:
                res.append(item)
        return res
   =20
    def _flatten(seq):
        return tuple(_flatten1(seq))

in my tests, this is slighly faster on very short sequences (two
coordinate pairs, which is a common case for e.g. rectangles),
and much faster on long sequences (polylines, polygons).

for example, for a 5000-point line, it's about 15 times faster.
on a 10,000 point line, it's over 50 times faster.  etc.

comments?

can anyone come up with an even faster way to do this?

if I don't hear anything negative, I'll post patches (etc)

</F>

PS. even after this optimization, uiToolkit is still about 100 times
faster than Tkinter, but that's another story ;-)



From Fredrik Lundh" <effbot@telia.com  Fri Jun 16 17:47:01 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 18:47:01 +0200
Subject: [Python-Dev] Q: is concatenation and append really the same thing?
Message-ID: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid>

Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
>>> (1, 2, 3) + [1, 2, 3]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only append tuple (not "list") to tuple

is "append" really the right word here?

sure confused the hell out of yours truly...  ("there's no
friggin' append call in this code")

</F>



From jeremy@beopen.com  Fri Jun 16 17:45:07 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 16 Jun 2000 12:45:07 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
Message-ID: <14666.22931.521438.936776@localhost.localdomain>

>>>>> "FL" == Fredrik Lundh <effbot@telia.com> writes:

  FL> has anyone benchmarked the abstract sequence API?  how much
  FL> slower is it?  would it be a good idea to treat lists as a
  FL> special case, to avoid slowing down existing code?

The abstract interface is fairly expensive.  The current code uses
PyList_GET_ITEM to access the elements of the list.  The abstract
interface adds two function calls (PySequence_GetItem,
PyList_GetItem).  The first function just does a couple of sanity
checks (verify arg is sequence & that it has get_item).  The second
function verifies that the arg is a list, then does a bounds check.
None of the work that either of these functions does is necessary for
the list case!

In the extended call syntax implementation, I used PySequence_Tuple to
handle non-standard sequences.  Once converted to a tuple, they can be
processed using the macros.  If you support user-defined sequences,
the sanity checking can get pretty hairy if you don't coerce to a
tuple; e.g. the PySequence_Length method can lie!  

I don't remember considering the cost of allocating the new tuple,
which is only used internally.

Jeremy






From thomas@xs4all.net  Fri Jun 16 17:45:14 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 16 Jun 2000 18:45:14 +0200
Subject: [Python-Dev] Augmented assignment, update
Message-ID: <20000616184514.Q26436@xs4all.nl>

I've more or less finished the augmented-assignment patch I posted last
week. It can be found, including a longish explanation, here:

http://www.xs4all.nl/~thomas/python/

(For those who missed it, the previous posting is here:
http://www.python.org/pipermail/python-list/2000-June/060680.html
The link in the posting, however, points to the new patch.)

I do not know if augmented assignment will every be incorporated into Python
(this patch or something entirely different) but at least noone can claim the
groundwork is missing :-)

Feel free to send questions, comments and verbal abuse my way ;)

-- 
Thomas Wouters <thomas@xs4all.net>

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


From mwh21@cam.ac.uk  Fri Jun 16 17:53:42 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 16 Jun 2000 17:53:42 +0100
Subject: [Python-Dev] Q: is concatenation and append really the same thing?
In-Reply-To: "Fredrik Lundh"'s message of "Fri, 16 Jun 2000 18:47:01 +0200"
References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid>
Message-ID: <m3ln05wort.fsf@atrus.jesus.cam.ac.uk>

"Fredrik Lundh" <effbot@telia.com> writes:

> Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
> >>> (1, 2, 3) + [1, 2, 3]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: can only append tuple (not "list") to tuple
> 
> is "append" really the right word here?

My fault.  I have sent at least one patch to patches@python.org to
change it to

can only concatenate tuple (not "list") to tuple

to bring it into line with listobject.c; here it is again:

Index: Objects/tupleobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v
retrieving revision 2.34
diff -u -r2.34 tupleobject.c
--- Objects/tupleobject.c	2000/06/01 03:12:13	2.34
+++ Objects/tupleobject.c	2000/06/06 16:30:39
@@ -362,7 +362,7 @@
 	PyTupleObject *np;
 	if (!PyTuple_Check(bb)) {
 		PyErr_Format(PyExc_TypeError,
-       		     "can only append tuple (not \"%.200s\") to tuple",
+       		     "can only concatenate tuple (not \"%.200s\") to tuple",
 			     bb->ob_type->tp_name);
 		return NULL;
 	}

HTH, HAND,
Michael



From mal@lemburg.com  Fri Jun 16 17:53:59 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 18:53:59 +0200
Subject: [Python-Dev] possible Tkinter speedup
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid>
Message-ID: <394A5BA7.F001E220@lemburg.com>

Fredrik Lundh wrote:
> 
> the _flatten method in Tkinter is one of the major performance
> bottlenecks for Python/Tk programmers.  the method "flattens"
> a nested sequence, by repeatedly adding tuples to each other.
> 
> obviously, this isn't very efficient if the sequences are longer
> than, say, five to ten items...  and has of course led to claims
> like "wxPython is a thousand times faster than Tkinter".
> 
> anyway, taking recent changes to Python into account, it should
> be possible to speed this up quite a bit.
> 
> the old code looked like this:
> 
>     def _flatten(tuple):
>         res = ()
>         for item in tuple:
>             if type(item) in (TupleType, ListType):
>                 res = res + _flatten(item)
>             elif item is not None:
>                 res = res + (item,)
>         return res
> 
> after a some trials and errors, here's my proposed replacement:
> 
>     def _flatten1(seq):
>         res = []
>         for item in seq:
>             if type(item) in (TupleType, ListType):
>                 res.extend(_flatten1(item))
>             elif item is not None:
>                 res.append(item)
>         return res
> 
>     def _flatten(seq):
>         return tuple(_flatten1(seq))
> 
> in my tests, this is slighly faster on very short sequences (two
> coordinate pairs, which is a common case for e.g. rectangles),
> and much faster on long sequences (polylines, polygons).
> 
> for example, for a 5000-point line, it's about 15 times faster.
> on a 10,000 point line, it's over 50 times faster.  etc.
> 
> comments?

Why not implement this in C and add it to _tkinter.c ?
It might even make a nice standard builtin...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From fdrake@beopen.com  Fri Jun 16 18:02:22 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 13:02:22 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
Message-ID: <14666.23966.437909.949260@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > if I don't hear anything, I'll post patches later this weekend.

  Sounds good to me!  If lists and tuples are special cased, it
shouldn't even matter if the sequence API is too slow -- that's new
functionality for [].extend(), and can be optimized later if it needs
to be.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From mal@lemburg.com  Fri Jun 16 18:07:40 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 19:07:40 +0200
Subject: [Python-Dev] Q: is concatenation and append really the same thing?
References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid> <m3ln05wort.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <394A5EDC.7431C900@lemburg.com>

Michael Hudson wrote:
> 
> "Fredrik Lundh" <effbot@telia.com> writes:
> 
> > Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
> > >>> (1, 2, 3) + [1, 2, 3]
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > TypeError: can only append tuple (not "list") to tuple
> >
> > is "append" really the right word here?
> 
> My fault.  I have sent at least one patch to patches@python.org to
> change it to
> 
> can only concatenate tuple (not "list") to tuple
> 
> to bring it into line with listobject.c; here it is again:
> 
> Index: Objects/tupleobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v
> retrieving revision 2.34
> diff -u -r2.34 tupleobject.c
> --- Objects/tupleobject.c       2000/06/01 03:12:13     2.34
> +++ Objects/tupleobject.c       2000/06/06 16:30:39
> @@ -362,7 +362,7 @@
>         PyTupleObject *np;
>         if (!PyTuple_Check(bb)) {
>                 PyErr_Format(PyExc_TypeError,
> -                            "can only append tuple (not \"%.200s\") to tuple",
> +                            "can only concatenate tuple (not \"%.200s\") to tuple",
>                              bb->ob_type->tp_name);
>                 return NULL;
>         }
> 

Should be in CVS by now...

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From fdrake@beopen.com  Fri Jun 16 18:13:55 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 13:13:55 -0400 (EDT)
Subject: [Python-Dev] mailbox formats
Message-ID: <14666.24659.9174.717901@cj42289-a.reston1.va.home.com>

  I've been playing with a function to open a mailbox and return the
appropriate type of mailbox object from the mailbox module, but I
don't have examples of anything but mbox style mailboxes to test
with.
  Could anyone send real examples of MMDF, MH, maildir, and Babyl
mailboxes?  The mail can be junk; don't send anything I shouldn't see!
  Essentially, I'd like to see two new functions added to the mailbox
module:  open('name'), which returns a mailbox object opened for
reading, and which('name'), which returns the name of the mailbox
constructor, and possibly a flag indicating whether a
__builtin__.open() is needed.
  Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From mal@lemburg.com  Fri Jun 16 19:59:39 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 20:59:39 +0200
Subject: [Python-Dev] Announcment list
Message-ID: <394A791B.17F5AEFF@lemburg.com>

Does anybody know about the state of the python-announce
mailing list ?

I've sent an announcement there (about mxCGIPython), but have
only received an error message and got no posting back 
from the list. I posted a note to the postmaster@beopen.com,
but have heard nothing from there yet.

Can somebody please look into this ?!

BTW, what about the announcement list -> c.l.p.a gateway ?
Will that happen anytime soon (or do I have to hack the
headers to post there ? ;-)

Here's the error message:
"""
Subject: 
        failure notice
   Date: 
        13 Jun 2000 11:34:39 -0000
   From: 
        MAILER-DAEMON@starship.beopen.com
     To: 
        mal@lemburg.com

Hi. This is the qmail-send program at starship.beopen.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<clpa@python.net>:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <mal@lemburg.com>
Received: (qmail 31495 invoked from network); 13 Jun 2000 11:34:38 -0000
Received: from dinsdale.cnri.reston.va.us (HELO dinsdale.python.org) (132.151.1.21)
  by starship.beopen.com with SMTP; 13 Jun 2000 11:34:38 -0000
Received: by dinsdale.python.org (Postfix)
        id AD6DD1CDE3; Tue, 13 Jun 2000 07:29:56 -0400 (EDT)
Delivered-To: python-announce-people@python.org
...
"""

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From bwarsaw@python.org  Fri Jun 16 20:24:21 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 16 Jun 2000 15:24:21 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
 <14666.23966.437909.949260@cj42289-a.reston1.va.home.com>
Message-ID: <14666.32485.172984.122789@anthem.concentric.net>

>>>>> "Fred" == Fred L Drake, Jr <fdrake@beopen.com> writes:

    Fred>   Sounds good to me!  If lists and tuples are special cased,
    Fred> it shouldn't even matter if the sequence API is too slow --
    Fred> that's new functionality for [].extend(), and can be
    Fred> optimized later if it needs to be.

This has been a typical implementation strategy for a long while now,
and I think successfully so.  When I removed the distinction between
list and tuple unpacking to allow any sequence unpacking (and
incidently w/o special syntax), I did exactly this.  Special case for
tuples and lists, and if it was neither then use the sequence API.

Jeremy's right that this can get hairy if your as anal as I am about
error checking and refcounting.  In addition to PySequence_Length()
ability to lie, there are all sorts of errors that can happen, which
should abort the whole process and clean up any temporary objects.
Plus you've now got three very similar branches in the code, which
adds its own overhead.

So you should decide whether this situation will be used widely enough
to warrant the extra coding complexity for the performance win.
list.extend() is probably not used too often these days, but it should
be 'cause it's cool.  So maybe it's worth it in this case.

On the other hand, this is a situation that comes up often, and if we
were to really audit the APIs, we'd probably find even more cases
where restrictions to concrete lists or tuples should be relaxed to
accept any sequence.  Maybe there's a way we can factor this out in a
single function which handles this once and for all?

-Barry


From paul@prescod.net  Fri Jun 16 20:22:08 2000
From: paul@prescod.net (Paul Prescod)
Date: Fri, 16 Jun 2000 21:22:08 +0200
Subject: [Python-Dev] Augmented assignment
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <394A7E60.6F715424@prescod.net>

Many people have given examples where the augmented assignment version
is substantially more readable. Others have argued that it is more
explicit in that it says *exactly what you mean* rather than using a
more general operator in a specific (common) situation. Another
important argument is that augmented assignment allows *in place*
assignment for some types. That's really important for matrix math etc.

 All of these arguments convince me that this is not a simple matter of
"another notation for what we already do."

> Augmented assignments are unPythonic because they don't add any new
> functionality to the language.  From what I've seen, all people,
> who ever missed it, were experienced C-programmers.  

That's true, but we should not be ashamed to steal good ideas from other
languages. Probably the only people who would miss __getattr__ would be
SmallTalk programmers and the original proponents of the various
operator overloading features may well have come from C++.

> ...
> This feature must be learned
> additionally, where normal assignment are easiely understood from
> school mathematics.  

Not really!

a=a+1 is totally illegal in basic arithmetic.

> It also introduces many more possibilities to make
> subtle mistakes, since it is not obvious (at least to No-C-programmers)
> when and how often the index expression will be valuated.  

As I understand the proposal, the function will be called exactly as
many times as it is printed in the source code:

> versus
>         foo[bar()] += bar()
>         print foo

Presumably bar() gets called twice.

The only argument against this that is persusaive to me is that it makes
the core Python language larger and thus a (little) harder to learn. My
impression is that the design of the feature has been well done.

My personal opinion is that the cost in education probably outweighs the
benefits in clarity but others who work a lot with matrices etc. would
probably have a different view.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Music is the stuff between the notes." - Claude Debussy



From petrilli@amber.org  Fri Jun 16 20:42:46 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Fri, 16 Jun 2000 15:42:46 -0400
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <394A7E60.6F715424@prescod.net>; from paul@prescod.net on Fri, Jun 16, 2000 at 09:22:08PM +0200
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de> <394A7E60.6F715424@prescod.net>
Message-ID: <20000616154246.A5513@trump.amber.org>

Paul Prescod [paul@prescod.net] wrote:
> That's true, but we should not be ashamed to steal good ideas from other
> languages. Probably the only people who would miss __getattr__ would be
> SmallTalk programmers and the original proponents of the various
> operator overloading features may well have come from C++.

Actually as a good Talker, I write methods for everything, so I almost 
nver use __getattr__ except as a way to force people to use methods
and not directly access attributes. Long story.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From fdrake@beopen.com  Fri Jun 16 20:42:12 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 15:42:12 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <14666.32485.172984.122789@anthem.concentric.net>
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
 <14666.23966.437909.949260@cj42289-a.reston1.va.home.com>
 <14666.32485.172984.122789@anthem.concentric.net>
Message-ID: <14666.33556.123258.252030@cj42289-a.reston1.va.home.com>

Barry A. Warsaw writes:
 > Jeremy's right that this can get hairy if your as anal as I am about
 > error checking and refcounting.  In addition to PySequence_Length()
 > ability to lie, there are all sorts of errors that can happen, which
 > should abort the whole process and clean up any temporary objects.
 > Plus you've now got three very similar branches in the code, which
 > adds its own overhead.
 > 
 > So you should decide whether this situation will be used widely enough
 > to warrant the extra coding complexity for the performance win.
 > list.extend() is probably not used too often these days, but it should
 > be 'cause it's cool.  So maybe it's worth it in this case.
 > 
 > On the other hand, this is a situation that comes up often, and if we
 > were to really audit the APIs, we'd probably find even more cases
 > where restrictions to concrete lists or tuples should be relaxed to
 > accept any sequence.  Maybe there's a way we can factor this out in a
 > single function which handles this once and for all?

  How about this: special case the list & tuple flavors (since that'll
be roughly what's in there now), and for other sequences, convert to
either a tuple or a list and let it pass through that special case,
keeping a flag to discard the temporary list when done?
  There are two APIs, PySequence_List() and PySequence_Tuple(), which
can take care of a lot of the machinery in dealing with sequences that
lie about their length or otherwise break (during __getitem__() calls
or whatever), that a large part of the work is done.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From mal@lemburg.com  Fri Jun 16 20:45:16 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 21:45:16 +0200
Subject: [Python-Dev] Augmented assignment
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de> <394A7E60.6F715424@prescod.net>
Message-ID: <394A83CC.98F177DC@lemburg.com>

Paul Prescod wrote:
> > Augmented assignments are unPythonic because they don't add any new
> > functionality to the language.  From what I've seen, all people,
> > who ever missed it, were experienced C-programmers.
> 
> That's true, but we should not be ashamed to steal good ideas from other
> languages. Probably the only people who would miss __getattr__ would be
> SmallTalk programmers and the original proponents of the various
> operator overloading features may well have come from C++.

Don't forget the crowd of people doing environmental acquisition
(you know who they are ;-).

Honestly, I think that __getattr__ is one of the most useful
hooks available on Python objects.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From jeremy@beopen.com  Fri Jun 16 21:01:18 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 16 Jun 2000 16:01:18 -0400 (EDT)
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <394A83CC.98F177DC@lemburg.com>
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de>
 <394A7E60.6F715424@prescod.net>
 <394A83CC.98F177DC@lemburg.com>
Message-ID: <14666.34702.801826.453565@localhost.localdomain>

I'm leery of acquisition, but we gotta have __getattr__.

Jeremy

>>>>> "MAL" == M -A Lemburg <mal@lemburg.com> writes:

  MAL> Paul Prescod wrote:
  >> > Augmented assignments are unPythonic because they don't add any
  >> > new functionality to the language.  From what I've seen, all
  >> > people, who ever missed it, were experienced C-programmers.
  >> 
  >> That's true, but we should not be ashamed to steal good ideas
  >> from other languages. Probably the only people who would miss
  >> __getattr__ would be SmallTalk programmers and the original
  >> proponents of the various operator overloading features may well
  >> have come from C++.

  MAL> Don't forget the crowd of people doing environmental
  MAL> acquisition (you know who they are ;-).

  MAL> Honestly, I think that __getattr__ is one of the most useful
  MAL> hooks available on Python objects.



From fdrake@beopen.com  Fri Jun 16 22:44:05 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 17:44:05 -0400 (EDT)
Subject: [Python-Dev] possible Tkinter speedup
In-Reply-To: <394A5BA7.F001E220@lemburg.com>
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid>
 <394A5BA7.F001E220@lemburg.com>
Message-ID: <14666.40869.331831.90682@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Why not implement this in C and add it to _tkinter.c ?

  I think this is the right approach; do you have an implementation?  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From Fredrik Lundh" <effbot@telia.com  Fri Jun 16 22:50:58 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 23:50:58 +0200
Subject: [Python-Dev] possible Tkinter speedup
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com>
Message-ID: <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid>

mal wrote:
> > for example, for a 5000-point line, it's about 15 times faster.
> > on a 10,000 point line, it's over 50 times faster.  etc.
> >=20
> > comments?
>=20
> Why not implement this in C and add it to _tkinter.c ?
> It might even make a nice standard builtin...

bang for the buck?

getting a working C version is a whole lot of work, and I'd rather
spend that time on things that can speed things up a whole lot
more [1].  but if it's still raining tomorrow...

</F>

1) http://w1.132.telia.com/~u13208596/tkinter



From Fredrik Lundh" <effbot@telia.com  Fri Jun 16 23:33:43 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 00:33:43 +0200
Subject: [Python-Dev] possible Tkinter speedup
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com> <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid>
Message-ID: <017101bfd7e2$f2d3a2c0$f2a6b5d4@hagrid>

eff-bot wrote:
> bang for the buck?
>=20
> getting a working C version is a whole lot of work

okay, I just proved that I don't know what I'm talking about.  it wasn't
that hard, and the performance boost is rather interesting...

for 5000 vertices:

    Tkinter 1.6:
        10.44 seconds
    Tkinter 1.6 with new flatten:
        0.27 seconds
    Tkinter 1.6 with C version of flatten:
        2.57 milliseconds

patch follows.

</F>



From Fredrik Lundh" <effbot@telia.com  Sat Jun 17 08:55:16 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 09:55:16 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> <14666.22931.521438.936776@localhost.localdomain>
Message-ID: <003501bfd831$8bb11a60$f2a6b5d4@hagrid>

jeremy wrote:

>   FL> has anyone benchmarked the abstract sequence API?  how much
>   FL> slower is it?  would it be a good idea to treat lists as a
>   FL> special case, to avoid slowing down existing code?
>=20
> The abstract interface is fairly expensive.  The current code uses
> PyList_GET_ITEM to access the elements of the list.  The abstract
> interface adds two function calls (PySequence_GetItem,
> PyList_GetItem).  The first function just does a couple of sanity
> checks (verify arg is sequence & that it has get_item).  The second
> function verifies that the arg is a list, then does a bounds check.
> None of the work that either of these functions does is necessary for
> the list case!

just for the record, I just changed some generic sequence code
to something like:

    if (PyList_Check(seq) || PyTuple_Check(seq))
        Py_INCREF(seq);
    else if (PySequence_Check(seq)) {
        seq =3D PySequence_Tuple(seq);
        if (!seq)
            return NULL;
    } else {
        PyErr_SetString(PyExc_TypeError, "argument must be a sequence");
        return NULL;
    }

    ... allocate PyObject_Length(seq) slots ...

    if (PyList_Check(seq))
        ... list code using PyList_GET_ITEM
    else
        ... tuple code using PyTuple_GET_ITEM

    Py_DECREF(seq);

for the standard case (lists, in this case), this resulted in a
total speedup of 4 times (this includes some other overhead).

so in other words, this construct is more than 4 times faster
than plain use of PySequence_GetItem.

guess it's time to fix a couple of things in PIL...

</F>



From mhammond@skippinet.com.au  Sat Jun 17 09:16:18 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Sat, 17 Jun 2000 18:16:18 +1000
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <003501bfd831$8bb11a60$f2a6b5d4@hagrid>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au>

/F:
> just for the record, I just changed some generic sequence code
> to something like:
...
> so in other words, this construct is more than 4 times faster
> than plain use of PySequence_GetItem.

Good stuff!

> guess it's time to fix a couple of things in PIL...

Its a fair bit of code to duplicate everywhere you want the speed increase.
How can we add a similar scheme to the core, so the changes people need to
make are trivial (to the point where the change is zero!)?

Mark.



From Fredrik Lundh" <effbot@telia.com  Sat Jun 17 09:40:20 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 10:40:20 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au>
Message-ID: <006a01bfd837$ac689840$f2a6b5d4@hagrid>

mark wrote:
> > so in other words, this construct is more than 4 times faster
> > than plain use of PySequence_GetItem.
>=20
> Good stuff!
>=20
> > guess it's time to fix a couple of things in PIL...
>=20
> Its a fair bit of code to duplicate everywhere you want the speed =
increase.
> How can we add a similar scheme to the core, so the changes people =
need to
> make are trivial (to the point where the change is zero!)?

the first part is trivial; just add something like this to
Objects/abstract.c:

PyObject*
PySequence_TupleOrList(PyObject* seq)
{
    if (PyList_Check(seq) || PyTuple_Check(seq))
        Py_INCREF(seq);
    else if (PySequence_Check(seq))
        seq =3D PySequence_Tuple(seq);
    else {
        PyErr_SetString(PyExc_TypeError, "argument must be a sequence");
        seq =3D NULL;
    }
    return seq;
}

the second parts is harder -- and that's of course where the
real performance boost comes from.  as far as I'm aware, very
few C compilers can "specialize" loops for you...

</F>



From mal@lemburg.com  Sat Jun 17 09:41:25 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 10:41:25 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au>
Message-ID: <394B39B5.B478720E@lemburg.com>

Mark Hammond wrote:
> 
> /F:
> > just for the record, I just changed some generic sequence code
> > to something like:
> ...
> > so in other words, this construct is more than 4 times faster
> > than plain use of PySequence_GetItem.
> 
> Good stuff!
> 
> > guess it's time to fix a couple of things in PIL...
> 
> Its a fair bit of code to duplicate everywhere you want the speed increase.
> How can we add a similar scheme to the core, so the changes people need to
> make are trivial (to the point where the change is zero!)?

We could add special code the standard type to PySequence_GetItem()
et al., but it would still cause a C function call (not much,
but noticable in inner loops).

How about adding some inline markers to the most often
used (and small) routines in the medium level abstract interface
(PySequence_*, PyMapping_*, etc.) ?!

Together with the special code for the native Python types
this should yield a speedup for all extensions by simple
virtue of a recompile... OTOH, changes to these APIs would
need a recompile of the extensions too.

BTW, I've used the same approach as Fredrik in mx.Tools.
It does make great a difference...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From mal@lemburg.com  Sat Jun 17 09:53:20 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 10:53:20 +0200
Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)
References: <20000617000834.C29B41CF4A@dinsdale.python.org>
Message-ID: <394B3C80.248B4CB1@lemburg.com>

cfandrich@8cs.com wrote:
> 
> Full_Name: Christopher Fandrich
> Version: 1.5.2
> OS: Windows
> Submission from: (NULL) (208.41.174.4)
> 
> I'm embedding Python in an application.  For now, all I'm doing is initializing
> and finalizing Python.
> 
> When I run my app I get a memory leak of 12288 bytes.  The memory is malloc'ed
> by dictresize() which is called by PyDict_SetItem() which is called by
> PyString_InternInPlace().
> 
> For now, I've added
>     PyDict_Clear(interned);
>     interned = NULL;
> to PyString_Fini().  So far it works fine, but I don't know if it's safe to do
> in the grand scheme of things.

I would suggest adding code to dealloc the interned dict
iff it is empty after the sweeping action in PyString_Fini().
I have a feeling that this is not the case though, since interned
strings are used quite a lot in the core interpreter (e.g. in
classobject.c) and these are usually not recovered.

Perhaps we ought to add some code which takes care of cleaning
up all remaining garbage left over after the call to
call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
of all interned strings and cached ints/floats and associated
free lists or dicts.

We'd need new APIs in string|float|intobject.c to implement this.

Thoughts ? Patches ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From Fredrik Lundh" <effbot@telia.com  Sat Jun 17 13:45:57 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 14:45:57 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid>
Message-ID: <00d701bfd859$fd435300$f2a6b5d4@hagrid>

the eff-bot wrote:

> the first part is trivial; just add something like this to
> Objects/abstract.c:
>=20
> PyObject*
> PySequence_TupleOrList(PyObject* seq)
> ...
>=20
> the second parts is harder -- and that's of course where the
> real performance boost comes from.  as far as I'm aware, very
> few C compilers can "specialize" loops for you...

in the same test setup, moving the PyList_Check inside the
loop gives a 25-30% slowdown (or to look at it from the other
side, 3 times instead of 4 times faster than naive code).

a compromise solution could be to combine the above function
with a macro:

    #define PySequence_TupleOrList_GET_ITEM(seq, index)\
        (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\
        PyTuple_GET_ITEM(seq, index)

(anyone got a better name? ;-)

standard usage:

    seq =3D PySequence_TupleOrList(seq_in);

    size =3D PyObject_Length(seq);
   =20
    for (i =3D 0; i < size; i++) {
        PyObject* obj =3D PySequence_TupleOrList_GET_ITEM(seq, i);
        ...
    }

comments?

</F>



From mal@lemburg.com  Sat Jun 17 15:18:26 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 16:18:26 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid>
Message-ID: <394B88B2.EA116971@lemburg.com>

Fredrik Lundh wrote:
> 
> the eff-bot wrote:
> 
> > the first part is trivial; just add something like this to
> > Objects/abstract.c:
> >
> > PyObject*
> > PySequence_TupleOrList(PyObject* seq)
> > ...
> >
> > the second parts is harder -- and that's of course where the
> > real performance boost comes from.  as far as I'm aware, very
> > few C compilers can "specialize" loops for you...
> 
> in the same test setup, moving the PyList_Check inside the
> loop gives a 25-30% slowdown (or to look at it from the other
> side, 3 times instead of 4 times faster than naive code).
> 
> a compromise solution could be to combine the above function
> with a macro:
> 
>     #define PySequence_TupleOrList_GET_ITEM(seq, index)\
>         (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\
>         PyTuple_GET_ITEM(seq, index)
> 
> (anyone got a better name? ;-)
> 
> standard usage:
> 
>     seq = PySequence_TupleOrList(seq_in);
> 
>     size = PyObject_Length(seq);
> 
>     for (i = 0; i < size; i++) {
>         PyObject* obj = PySequence_TupleOrList_GET_ITEM(seq, i);
>         ...
>     }
> 
> comments?

The above looks a lot like an iterator... how about
providing a standard PySequence_Iterate(obj, callback)
with the callback being called for every element of the
sequence ?!

The iterator could then be optimized for lists and tuples.
Not as fast as inlining, but a more generic solution...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From Fredrik Lundh" <effbot@telia.com  Sat Jun 17 15:42:52 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 16:42:52 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com>
Message-ID: <010401bfd86a$5282cca0$f2a6b5d4@hagrid>

mal wrote:
> The above looks a lot like an iterator... how about
> providing a standard PySequence_Iterate(obj, callback)
> with the callback being called for every element of the
> sequence ?!

PySequence_Enumerate, perhaps?

> The iterator could then be optimized for lists and tuples.
> Not as fast as inlining, but a more generic solution...

more generic than useful, imo:

    - it's slower.

    - it's awkward to use: you need to put the state in a
      structure, invert your program logic, etc.

    - it doesn't scale: what if you want to loop over two
      structures?  what if you want to loop over two objects,
      using two different indices?

</F>




From mal@lemburg.com  Sat Jun 17 15:44:47 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 16:44:47 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com> <010401bfd86a$5282cca0$f2a6b5d4@hagrid>
Message-ID: <394B8EDF.57630FE9@lemburg.com>

Fredrik Lundh wrote:
> 
> mal wrote:
> > The above looks a lot like an iterator... how about
> > providing a standard PySequence_Iterate(obj, callback)
> > with the callback being called for every element of the
> > sequence ?!
> 
> PySequence_Enumerate, perhaps?
>
> > The iterator could then be optimized for lists and tuples.
> > Not as fast as inlining, but a more generic solution...
> 
> more generic than useful, imo:
> 
>     - it's slower.
> 
>     - it's awkward to use: you need to put the state in a
>       structure, invert your program logic, etc.
> 
>     - it doesn't scale: what if you want to loop over two
>       structures?  what if you want to loop over two objects,
>       using two different indices?

Or perhaps, use a different iteration technique: the one
used by PyDict_Next(). It doesn't need a callback, but
instead plays with pointers you pass to it via output
variables.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From Fredrik Lundh" <effbot@telia.com  Sat Jun 17 16:44:58 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 17:44:58 +0200
Subject: [Python-Dev] proposal: core support for "fast" sequence iteration
Message-ID: <011901bfd873$00632740$f2a6b5d4@hagrid>

mark wrote:

> Its a fair bit of code to duplicate everywhere you want the speed =
increase.
> How can we add a similar scheme to the core, so the changes people =
need to
> make are trivial (to the point where the change is zero!)?

okay, here's my current proposal:

    PyObject* PySequence_Fast(PyObject *o)=20

        Return value: New reference.=20

        Returns the o as a tuple or a list on success, and
        NULL on failure.  If o doesn't have the right type,
        it is converted to a tuple using PySequence_Tuple.

        This is equivalent to the following Python code:

            if type(o) in (ListType, TupleType):
                return o
            return tuple(o)

        This function is intended to be used together with
        PySequence_Fast_GET_ITEM, for functions that need
        to loop over a read-only sequence as fast as they
        possibly can, while still supporting any object that
        implements the sequence protocol.

    PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i)

        Return value: Borrowed reference.=20

        Returns the object at position i, from the sequence
        seq (which must be a list or a tuple).  This is a
        macro, and has no error checking.

        If you need error checking, use PySequence_GetItem.

for the rationale, see my earlier posts in the "list.extend" thread.

unless somebody comes up with a more efficient solution, I'll wrap
this up together with the list.extend patch (first thing tomorrow).

</F>



From gstein@lyra.org  Sat Jun 17 21:52:31 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 17 Jun 2000 13:52:31 -0700
Subject: [Python-Dev] proposal: core support for "fast" sequence iteration
In-Reply-To: <011901bfd873$00632740$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jun 17, 2000 at 05:44:58PM +0200
References: <011901bfd873$00632740$f2a6b5d4@hagrid>
Message-ID: <20000617135231.E29590@lyra.org>

+1

coolness.


On Sat, Jun 17, 2000 at 05:44:58PM +0200, Fredrik Lundh wrote:
> mark wrote:
> 
> > Its a fair bit of code to duplicate everywhere you want the speed increase.
> > How can we add a similar scheme to the core, so the changes people need to
> > make are trivial (to the point where the change is zero!)?
> 
> okay, here's my current proposal:
> 
>     PyObject* PySequence_Fast(PyObject *o) 
> 
>         Return value: New reference. 
> 
>         Returns the o as a tuple or a list on success, and
>         NULL on failure.  If o doesn't have the right type,
>         it is converted to a tuple using PySequence_Tuple.
> 
>         This is equivalent to the following Python code:
> 
>             if type(o) in (ListType, TupleType):
>                 return o
>             return tuple(o)
> 
>         This function is intended to be used together with
>         PySequence_Fast_GET_ITEM, for functions that need
>         to loop over a read-only sequence as fast as they
>         possibly can, while still supporting any object that
>         implements the sequence protocol.
> 
>     PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i)
> 
>         Return value: Borrowed reference. 
> 
>         Returns the object at position i, from the sequence
>         seq (which must be a list or a tuple).  This is a
>         macro, and has no error checking.
> 
>         If you need error checking, use PySequence_GetItem.
> 
> for the rationale, see my earlier posts in the "list.extend" thread.
> 
> unless somebody comes up with a more efficient solution, I'll wrap
> this up together with the list.extend patch (first thing tomorrow).
> 
> </F>
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev

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


From gstein@lyra.org  Sat Jun 17 23:37:26 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 17 Jun 2000 15:37:26 -0700
Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)
In-Reply-To: <394B3C80.248B4CB1@lemburg.com>; from mal@lemburg.com on Sat, Jun 17, 2000 at 10:53:20AM +0200
References: <20000617000834.C29B41CF4A@dinsdale.python.org> <394B3C80.248B4CB1@lemburg.com>
Message-ID: <20000617153726.H29590@lyra.org>

On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote:
>...
> I would suggest adding code to dealloc the interned dict
> iff it is empty after the sweeping action in PyString_Fini().
> I have a feeling that this is not the case though, since interned
> strings are used quite a lot in the core interpreter (e.g. in
> classobject.c) and these are usually not recovered.
> 
> Perhaps we ought to add some code which takes care of cleaning
> up all remaining garbage left over after the call to
> call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
> of all interned strings and cached ints/floats and associated
> free lists or dicts.
> 
> We'd need new APIs in string|float|intobject.c to implement this.
> 
> Thoughts ? Patches ?

I would definitely like to see this, and suggested it to Guido about four
years ago :-)

During my threading work, I looked at all the globals, which includes the
pools and the one-off allocations in classobject.c and friends. I figured it
would be a Good Thing(tm) to write a general object pool API which could be
used by tuples, floats, frames, etc. Having the single implementation of a
pool would mean that we could add thread locks in a single place.

Similarly, for cleanup reasons, I also suggested a general API for
allocating the "constants" and torching them at shutdown.

As we all know, though... suggestions don't mean crap. Code counts. :-)

That said, I'll look into some of this with the free-threading work. That is
all post-1.6, though. It would be great if somebody could do it before then.

Cheers,
-g

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


From Vladimir.Marangozov@inrialpes.fr  Sun Jun 18 00:01:30 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Sun, 18 Jun 2000 01:01:30 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)
In-Reply-To: <20000617153726.H29590@lyra.org> from "Greg Stein" at Jun 17, 2000 03:37:26 PM
Message-ID: <200006172301.BAA01642@python.inrialpes.fr>

Greg Stein wrote:
> 
> On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote:
> >...
> > Perhaps we ought to add some code which takes care of cleaning
> > up all remaining garbage left over after the call to
> > call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
> > of all interned strings and cached ints/floats and associated
> > free lists or dicts.
> > 
> > We'd need new APIs in string|float|intobject.c to implement this.
> > 
> > Thoughts ? Patches ?
> 
> I would definitely like to see this, and suggested it to Guido about four
> years ago :-)
> 
> During my threading work, I looked at all the globals, which includes the
> pools and the one-off allocations in classobject.c and friends. I figured it
> would be a Good Thing(tm) to write a general object pool API which could be
> used by tuples, floats, frames, etc. Having the single implementation of a
> pool would mean that we could add thread locks in a single place.
> 
> Similarly, for cleanup reasons, I also suggested a general API for
> allocating the "constants" and torching them at shutdown.
> 
> As we all know, though... suggestions don't mean crap. Code counts. :-)

pymalloc (the debugging stuff put aside) is an efficient implementation
of this pool concept. The interface just needs to be exported under an
appropriate PyObject_ API, not as a general malloc replacement. Maybe
it needs some more work regarding finalization, but the code is there.
Per pool locking is there too. Maybe it needs to be adjusted wrt the
pool granularity we want.

The various core object allocators would use this API with PyObject_NEW
inlined.

> 
> That said, I'll look into some of this with the free-threading work. That is
> all post-1.6, though. It would be great if somebody could do it before then.

Voila.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From Vladimir.Marangozov@inrialpes.fr  Sun Jun 18 01:50:51 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Sun, 18 Jun 2000 02:50:51 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11
In-Reply-To: <200006172241.PAA02080@slayer.i.sourceforge.net> from "A.M. Kuchling" at Jun 17, 2000 03:41:24 PM
Message-ID: <200006180050.CAA07547@python.inrialpes.fr>

A.M. Kuchling wrote:
>
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060
>
> Modified Files:
>       mmapmodule.c
> Log Message:
> Fix the size() method to return the size of the file on Unix, not the
> size of the mapped area.  This seems to be what the Windows version does.
> This change requires keeping around the fd of the mapped file.

On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
It works okay without the MS_INVALIDATE flag though, so I'd suggest
removing it from msync in the flush and dealloc methods.

Also, it would probably be a good idea to allow optional flags for
flush, as it's done in new_mmap_object, the default being only MS_SYNC.

Given that this module is enabled by default, I think that it needs some
more stress-testing in test_mmap.py. I'll try to add a couple of tests
shortly.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From trentm@activestate.com  Sun Jun 18 04:20:09 2000
From: trentm@activestate.com (Trent Mick)
Date: Sat, 17 Jun 2000 20:20:09 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11
In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr>
References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr>
Message-ID: <20000617202009.A20019@activestate.com>

On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote:
> 
> A.M. Kuchling wrote:
> >
> > Update of /cvsroot/python/python/dist/src/Modules
> > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060
> >
> > Modified Files:
> >       mmapmodule.c
> > Log Message:
> > Fix the size() method to return the size of the file on Unix, not the
> > size of the mapped area.  This seems to be what the Windows version does.
> > This change requires keeping around the fd of the mapped file.
> 
> On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
> It works okay without the MS_INVALIDATE flag though, so I'd suggest
> removing it from msync in the flush and dealloc methods.
> 
> Also, it would probably be a good idea to allow optional flags for
> flush, as it's done in new_mmap_object, the default being only MS_SYNC.
> 
> Given that this module is enabled by default, I think that it needs some
> more stress-testing in test_mmap.py. I'll try to add a couple of tests
> shortly.
> 

Just to add to the mmap fray. The seek() method is broken for any 'whence'
value (seek from start, current, orend) other than the default. Ihave a patch
that fixes that as well as gets mmap'd files working on Linux64 and Win64.
The test_mmap was also extended. The patch is up on SourceForge for your
perusal. :)

https://sourceforge.net/patch/?func=detailpatch&patch_id=100515&group_id=5470

Cheers,
Trent

-- 
Trent Mick
trentm@activestate.com


From mhammond@skippinet.com.au  Sun Jun 18 04:35:00 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Sun, 18 Jun 2000 13:35:00 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1
In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEJKCNAA.mhammond@skippinet.com.au>

> Documentation for the mmap module: proofreaders welcomed

OK :-)


> the file handle \var{fileno}, and returns a mmap object.  If you have
> a Python file object, its
> \method{fileno()} method returns the file's handle, which is
> just an integer.

This could be a little clearer - on first reading, I thought you were
talking about the return value.  Maybe something like: "if you wish to pass
an existing Python file object for this parameter, use its
\method{fileno()} method to obtain the fileno."


> \var{tagname}, if specified, is a string giving a tag name for
> the mapping. XXX what is the purpose of the tag name?

Something like: Windows allows you to have many different mappings against
the same file.  If you specify the name of an existing tag, that tag is
opened, otherwise a new tag of this name is created.  If this parameter is
None, the mapping is created without a name.  Avoiding the use of the tag
parameter will assist in keeping your code portable between Unix and
Windows.

> \begin{funcdesc}{mmap}{file, size \optional{, flags, prot}}
> (Unix version) Maps \var{length} bytes from the file specified by the
> file handle \var{fileno}, and returns a mmap object.  If you have a
> Python file object, its \method{fileno()} method returns the file's
> handle, which is just an integer.

I believe you mean the signature to say "fileno" instead of "file" - this
makes it consistent with the Windows signature, and reinforces that this
param is indeed identical.

As a meta-comment, the structure of this implies that the param signatures
are more different than they are - eg, it should be possible to write
portable mmap code in most cases, without concern for the platform.  the
platform only becomes relevant when you use the optional params for each
platform?


> \begin{methoddesc}{read}{\var{num}}
> Return a string containing up to \var{num} bytes taken from the

"taken from" -> "starting from" ??

> \begin{methoddesc}{write_byte}{\var{byte}}
> Write \var{byte} into memory at the current position of
> the file pointer; the file position is advanced by 1.
> \end{methoddesc}

The type of "byte" should be explained - its never clear to me if a "byte"
should be an int or a string of size 1.  In this case, it is the latter.

Looks good!

Mark.



From mhammond@skippinet.com.au  Sun Jun 18 04:35:33 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Sun, 18 Jun 2000 13:35:33 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1
In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEJLCNAA.mhammond@skippinet.com.au>

Sorry about that - I meant to send it direct to Andrew...

Mark.



From Vladimir.Marangozov@inrialpes.fr  Sun Jun 18 05:24:05 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Sun, 18 Jun 2000 06:24:05 +0200 (CEST)
Subject: [Python-Dev] Towards selective compilation to native code?
Message-ID: <200006180424.GAA14040@python.inrialpes.fr>

There was a cool seminar the other day here, focusing on embedded &
real-time Java, so I'll throw here some impressions while they're fresh.
One of the presenters talked extensively about compilation strategies and
techniques for Java bytecode to native code, and while I know that Java
is not Python, it would be interesting to, at least, try to project some
of the ideas to Python in the long run, where applicable.

Needless to say, the guy & his environment (ex-OSF, now Silicomp) are
experts in compiler technology and I'm not in a position to comment on
everything, but you may find the second half of the slides enlightening: 
http://cgi-serv.inrialpes.fr/InTech/2000-06-15/ejava-silicomp.ppt

So, the interesting part of the talk was about a "new" compiler
architecture, built upon the concept of "Flash compiling" (quite
unappropriate name), which produces a mixture of the following:

  1. Bytecode
  2. Native code
  3. Native code is compiled selectively on demand and/or ahead of time
     (!= JIT) for "expensive" methods.
  4. Expensive methods are, on one hand, detected by dynamic profiling
     of the bytecode, and OTOH, determined ahead of time according to the
     following 2 simple creteria:
       - methods containing loops
       - methods calling native code from bytecode
           (to avoid bytecode to native and vice versa arg conversion paths
            which are expensive -- btw Python has the same perf. bottleneck)
  5. Everything relies on dyn loading & late binding of native code
     (front-end loads dynamically the back-end, native code is stored
     in the code stream, but linked incrementally & dynamically during
     execution)
  6. The whole thing is designed to avoid code explosion and to preserve
     the advantage of bytecode == small code size, and the presented
     preliminary results are quite optimistic -- the figures differ depending
     on the code size / speed tradeoff.

Of course, this is Java and there's static typing in there, but it
would be interesting to see whether Python can steal something from these
ideas. For instance, I'm trying to foresee what kind of static typing
(i.e. how much static info) would be appropriate in Python from this
point of view but I fail to obtain any realistic image :).
I see most parts of the dyn loading / late binding aspect though --
they are typical for Python.

Hm. Sounds like I'll be harrassing Tim to make him finally write something
valuable for Python ;-)

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From akuchlin@mems-exchange.org  Sun Jun 18 05:22:24 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sun, 18 Jun 2000 00:22:24 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11
In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 02:50:51AM +0200
References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr>
Message-ID: <20000618002224.A12729@newcnri.cnri.reston.va.us>

On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote:
>On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
>It works okay without the MS_INVALIDATE flag though, so I'd suggest
>removing it from msync in the flush and dealloc methods.

Ooh, you're right.  The Linux msync man page says "MS_ASYNC specifies
that an update be scheduled, but the call returns immediately.
MS_SYNC asks for an update and waits for it to complete.
MS_INVALIDATE asks to invalidate other mappings of the same file (so
that they can be updated with the fresh values just written)."  So
MS_INVALIDATE seems far too drastic.

>Also, it would probably be a good idea to allow optional flags for
>flush, as it's done in new_mmap_object, the default being only MS_SYNC.

The problem is: does Windows provide equivalent functionality?  (Is
there documentation available online for CreateFileMapping that I
could look at?)

>Given that this module is enabled by default, I think that it needs some
>more stress-testing in test_mmap.py. I'll try to add a couple of tests
>shortly.

Good idea.  I'll try to look at Trent Mick's patch and apply it ASAP
if it checks out.

--amk


From akuchlin@mems-exchange.org  Sun Jun 18 06:03:16 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sun, 18 Jun 2000 01:03:16 -0400
Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule
In-Reply-To: <Pine.LNX.4.10.10006171623520.11690-100000@sancho.ccd.uniroma2.it>; from lorenzo@sancho.ccd.uniroma2.it on Sat, Jun 17, 2000 at 04:29:14PM +0200
References: <Pine.LNX.4.10.10006171623520.11690-100000@sancho.ccd.uniroma2.it>
Message-ID: <20000618010316.D12729@newcnri.cnri.reston.va.us>

On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote:
>therefore, here is the change: if we are compiling for linux, define
>_GNU_SOURCE before including mman.h, and all is done. It seems the

Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present,
that doesn't imply that mremap() doesn't work at all; instead, a
resize may fail if the mapping would have to be moved to a different
virtual address.  Quoting from the Linux man page:

       MREMAP_MAYMOVE
              indicates  if  the operation should fail, or change
              the virtual address if the resize cannot be done at
              the current virtual address.

I think the correct fix is to simply specify MREMAP_MAYMOVE if it's
defined, but still support attempting to resize. Possibly the
configure script should also check for mremap()'s existence.

--amk


From lorenzo@sancho.ccd.uniroma2.it  Sun Jun 18 08:39:55 2000
From: lorenzo@sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Sun, 18 Jun 2000 09:39:55 +0200 (CEST)
Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule
In-Reply-To: <20000618010316.D12729@newcnri.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10006180859570.2676-100000@sancho.ccd.uniroma2.it>

On Sun, 18 Jun 2000, Andrew Kuchling wrote:

AK> On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote:
AK> >therefore, here is the change: if we are compiling for linux, define
AK> >_GNU_SOURCE before including mman.h, and all is done. It seems the
AK>=20
AK> Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present,
AK> that doesn't imply that mremap() doesn't work at all; instead, a
AK> resize may fail if the mapping would have to be moved to a different
AK> virtual address.  Quoting from the Linux man page:
AK>=20
AK>        MREMAP_MAYMOVE
AK>               indicates  if  the operation should fail, or change
AK>               the virtual address if the resize cannot be done at
AK>               the current virtual address.
AK>=20
AK> I think the correct fix is to simply specify MREMAP_MAYMOVE if it's
AK> defined, but still support attempting to resize. Possibly the
AK> configure script should also check for mremap()'s existence.
AK>=20

I think I've been too dense... Here I see two problems: on one hand, from
what I have understood of python's object, it's much better if the c
pointers are movable in VM on the remap, and the MAYMOVE flag is only
defined in mman.h if _GNU_SOURCE is; on the other hand, we only know
about linux mremap semantics: for what I see in linix mremap(2)

"""
CONFORMING TO
       This  call  is  Linux-specific,  and should not be used in
       programs intended to be portable.   4.2BSD  had  a  (never
       actually  implemented) mremap(2) call with completely dif=AD
       ferent semantics.
"""

Therefore, I think that really checking for __linux__ and using the
MAYMOVE flag, which is thefined there, is going towards the right way. If
someone else comes out with another kernel supporting a mremap syscall[1],
I think we'll be able to add proper support afterwards. As for the
configure script, on linux we have both mremap and MAYMOVE; if you go to
the <a href=3D"http://www.gnu.org/software/libc/all-M.html">Extended UNIX A=
BI, M*
</a> Page,=20

you'll find:

=09GNU Unix98 Unix95 POSIX ISO C SVID 3 4.3BSD XPG
mremap   X

It seems only the systems supported by GNU libc-2 (only linux systems,
then) support mremap...

Have a nice time.


lmc


* Just tried searching for mremap on=20
http://www.FreeBSD.org/cgi/man.cgi?query=3Dmmap
and looked around the various BSD derivatives whose man pages are
available there.=20

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci@ccd.uniroma2.it | Universit=E0 degli Studi di Roma "Tor Vergata" =
|
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+



From petrilli@amber.org  Sun Jun 18 19:50:22 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Sun, 18 Jun 2000 14:50:22 -0400
Subject: [Python-Dev] Towards selective compilation to native code?
In-Reply-To: <200006180424.GAA14040@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 06:24:05AM +0200
References: <200006180424.GAA14040@python.inrialpes.fr>
Message-ID: <20000618145022.A13031@trump.amber.org>

Vladimir Marangozov [Vladimir.Marangozov@inrialpes.fr] wrote:
> 
> Of course, this is Java and there's static typing in there, but it
> would be interesting to see whether Python can steal something from these
> ideas. For instance, I'm trying to foresee what kind of static typing
> (i.e. how much static info) would be appropriate in Python from this
> point of view but I fail to obtain any realistic image :).
> I see most parts of the dyn loading / late binding aspect though --
> they are typical for Python.

One might take a look at Smalltalk/X which compiles into C, and has a
pretty (ney very) high performance reputation.  There are some other
Smalltalk implementations taht do this as well.  This would be closer
I think to what Python would use than Java will be.  

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From Fredrik Lundh" <effbot@telia.com  Sun Jun 18 20:06:45 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sun, 18 Jun 2000 21:06:45 +0200
Subject: [Python-Dev] talking about performance...
Message-ID: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>

consider this little program:

import time, sre

k =3D u"foo"
p =3D sre.compile(k)
s =3D "*"*500 + k + "*"*500

def f1():
    p.search(s)

def f2():
    s.find(k)

def bench(f):
    t0 =3D time.clock()
    for i in range(100000):
        f()
    print f, time.clock() - t0

bench(f1)
bench(f2)

which prints:

    <function f1 at 7a0680> 2.94704487169
    <function f2 at 7a06a0> 10.5247875425

(Windows 95, 233 MHz)

if I change the k variable to an 8-bit string, it
prints:

    <function f1 at 7a0740> 2.47613520173
    <function f2 at 7a0760> 2.5178698939

(for some reason, sre is still slighty faster...)

so in other words, something in unicode land isn't
as efficient as it should...

</F>



From akuchlin@mems-exchange.org  Sun Jun 18 20:20:20 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sun, 18 Jun 2000 15:20:20 -0400
Subject: [Python-Dev] talking about performance...
In-Reply-To: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jun 18, 2000 at 09:06:45PM +0200
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>
Message-ID: <20000618152020.B14713@newcnri.cnri.reston.va.us>

On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote:
>so in other words, something in unicode land isn't
>as efficient as it should...

The relevant bit of findstring() in unicodeobject.c:

    if (direction < 0) {
        for (; end >= start; end--)
            if (Py_UNICODE_MATCH(self, end, substring))
                return end;
    } else {
        for (; start <= end; start++)
            if (Py_UNICODE_MATCH(self, start, substring))
                return start;
    }

And...

#define Py_UNICODE_MATCH(string, offset, substring)\
    (!memcmp((string)->str + (offset), (substring)->str,\
             (substring)->length*sizeof(Py_UNICODE)))

Proposed patch:

Index: unicodeobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
retrieving revision 2.26
diff -u -r2.26 unicodeobject.c
--- unicodeobject.c	2000/06/14 09:18:32	2.26
+++ unicodeobject.c	2000/06/18 19:18:01
@@ -2168,11 +2168,13 @@
 
     if (direction < 0) {
         for (; end >= start; end--)
-            if (Py_UNICODE_MATCH(self, end, substring))
+            if ( *(self->str + end) == *(substring->str) &&
+		 Py_UNICODE_MATCH(self, end, substring))
                 return end;
     } else {
         for (; start <= end; start++)
-            if (Py_UNICODE_MATCH(self, start, substring))
+            if (*(self->str + start) == *(substring->str) &&
+		Py_UNICODE_MATCH(self, start, substring))
                 return start;
     }
 

--amk



From akuchlin@mems-exchange.org  Sun Jun 18 20:32:37 2000
From: akuchlin@mems-exchange.org (A.M. Kuchling)
Date: Sun, 18 Jun 2000 15:32:37 -0400
Subject: [Python-Dev] Turning on sre?
Message-ID: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com>

Before 1.6a3, should the sre module be turned on, replacing re?  That
way it'll start getting tested; better we find problems sooner rather
than later...

--amk



From guido@python.org  Sun Jun 18 21:47:22 2000
From: guido@python.org (Guido van Rossum)
Date: Sun, 18 Jun 2000 15:47:22 -0500
Subject: [Python-Dev] Turning on sre?
In-Reply-To: Your message of "Sun, 18 Jun 2000 15:32:37 -0400."
 <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com>
References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com>
Message-ID: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>

> Before 1.6a3, should the sre module be turned on, replacing re?  That
> way it'll start getting tested; better we find problems sooner rather
> than later...

That would be nice.  If I replace re.py with "from sre import *" and
run test_re.py, I grt in trouble in the sub() test:

$ ./python ../Lib/test/test_re.py
Running tests on re.search and re.match
Running tests on re.sub
Traceback (most recent call last):
  File "../Lib/test/test_re.py", line 41, in ?
    assert re.sub(r'\d+', bump_num, '08.2 -2 23x99y') == '9.3 -3 24x100y'
  File "./../Lib/sre.py", line 35, in sub
    return _compile(pattern).sub(repl, string, count)
  File "./../Lib/sre.py", line 84, in _sub
    return _subn(pattern, template, string, count)[0]
  File "./../Lib/sre.py", line 114, in _subn
    return string[:0].join(s), n
TypeError: sequence item 0 not a string
$

It appears that the value of s is a list containing alternating zeros
and strings: [0, '.', 0, ' -', 0, ' ', 0, 'x', 0, 'y'].

No time to look into this further, but it could be a bug in sre._subn().

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


From akuchlin@mems-exchange.org  Sun Jun 18 21:28:59 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Sun, 18 Jun 2000 16:28:59 -0400
Subject: [Python-Dev] Turning on sre?
In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>; from guido@python.org on Sun, Jun 18, 2000 at 03:47:22PM -0500
References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> <200006182047.PAA03008@cj20424-a.reston1.va.home.com>
Message-ID: <20000618162859.A15018@newcnri.cnri.reston.va.us>

On Sun, Jun 18, 2000 at 03:47:22PM -0500, Guido van Rossum wrote:
>No time to look into this further, but it could be a bug in sre._subn().

It's a typo; fixed.  However, test_re then runs into the fact that
_expand(), which should expand escapes in the replacement string,
isn't implemented yet.

--amk


From Fredrik Lundh" <effbot@telia.com  Sun Jun 18 22:42:00 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sun, 18 Jun 2000 23:42:00 +0200
Subject: [Python-Dev] talking about performance...
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us>
Message-ID: <008301bfd96e$0bd98d20$f2a6b5d4@hagrid>

amk wrote:

> On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote:
> >so in other words, something in unicode land isn't
> >as efficient as it should...
>=20
> The relevant bit of findstring() in unicodeobject.c:
>=20
>     if (direction < 0) {
>         for (; end >=3D start; end--)
>             if (Py_UNICODE_MATCH(self, end, substring))
>                 return end;
>     } else {
>         for (; start <=3D end; start++)
>             if (Py_UNICODE_MATCH(self, start, substring))
>                 return start;
>     }
>=20
> And...
>=20
> #define Py_UNICODE_MATCH(string, offset, substring)\
>     (!memcmp((string)->str + (offset), (substring)->str,\
>              (substring)->length*sizeof(Py_UNICODE)))

heh.  it's my own code, of course...

> Proposed patch:
>=20
> Index: unicodeobject.c

MATCH is used in a couple of places; it's probably a better idea
to change the macro (in Include/unicodeobject.h).  MAL?

</F>



From Fredrik Lundh" <effbot@telia.com  Sun Jun 18 22:43:51 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sun, 18 Jun 2000 23:43:51 +0200
Subject: [Python-Dev] Turning on sre?
References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com>
Message-ID: <009501bfd96e$4d11b7e0$f2a6b5d4@hagrid>

amk wrote:


> Before 1.6a3, should the sre module be turned on, replacing re?  That
> way it'll start getting tested; better we find problems sooner rather
> than later...

in addition to the typo you noticed, there's a backtracking
(I think) problem that affects xmllib.py and tokenize.py...

I'm working on it.

</F>



From mal@lemburg.com  Sun Jun 18 22:48:32 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sun, 18 Jun 2000 23:48:32 +0200
Subject: [Python-Dev] talking about performance...
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid>
Message-ID: <394D43B0.8CC7070@lemburg.com>

Fredrik Lundh wrote:
> 
> amk wrote:
> 
> > On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote:
> > >so in other words, something in unicode land isn't
> > >as efficient as it should...
> >
> > The relevant bit of findstring() in unicodeobject.c:
> >
> >     if (direction < 0) {
> >         for (; end >= start; end--)
> >             if (Py_UNICODE_MATCH(self, end, substring))
> >                 return end;
> >     } else {
> >         for (; start <= end; start++)
> >             if (Py_UNICODE_MATCH(self, start, substring))
> >                 return start;
> >     }
> >
> > And...
> >
> > #define Py_UNICODE_MATCH(string, offset, substring)\
> >     (!memcmp((string)->str + (offset), (substring)->str,\
> >              (substring)->length*sizeof(Py_UNICODE)))
> 
> heh.  it's my own code, of course...
> 
> > Proposed patch:
> >
> > Index: unicodeobject.c
> 
> MATCH is used in a couple of places; it's probably a better idea
> to change the macro (in Include/unicodeobject.h).  MAL?

Right. I'll add Andrew's proposed patch to the macro def.

--
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From Fredrik Lundh" <effbot@telia.com  Sun Jun 18 23:33:10 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Mon, 19 Jun 2000 00:33:10 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include unicodeobject.h,2.9,2.10
References: <200006182222.PAA19408@slayer.i.sourceforge.net>
Message-ID: <00c601bfd975$358d0aa0$f2a6b5d4@hagrid>

mal wrote:
>  =20
>   #define Py_UNICODE_MATCH(string, offset, substring)\
> !     ((*((string)->str + (offset)) =3D=3D *((substring)->str)) &&\
> !      !memcmp((string)->str + (offset), (substring)->str,\
>                (substring)->length*sizeof(Py_UNICODE)))
>  =20

I completely forgot that this has different semantics if the
substring happens to be empty.

(substrings are null terminated, but "\0" isn't the same
thing as ""...)

don't have time to screen unicodeobject.c right now, but
maybe someone else can do it?  if not, maybe amk's patch
was a better idea after all...

</F>



From mwh21@cam.ac.uk  Mon Jun 19 00:15:25 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 19 Jun 2000 00:15:25 +0100
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100
In-Reply-To: "A.M. Kuchling"'s message of "Sun, 18 Jun 2000 11:45:52 -0700"
References: <200006181845.LAA10182@slayer.i.sourceforge.net>
Message-ID: <m33dma7f8y.fsf@atrus.jesus.cam.ac.uk>

"A.M. Kuchling" <akuchling@users.sourceforge.net> writes:

> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv10064/Modules
> 
> Modified Files:
> 	_tkinter.c 
> Log Message:
> Patch from /F:
> this patch adds a fast _flatten function to the _tkinter
> module, and imports it from Tkinter.py (if available).
> 
> this speeds up canvas operations like create_line and
> create_polygon.  for example, a create_line with 5000
> vertices runs about 50 times faster with this patch in
> place.

Unfortunately this introduces another Way To Make Python Core:

[mwh21@atrus build]$ ./python 
Python 1.6a2 (#4, Jun 18 2000, 23:57:36)  [GCC 2.95.1 19990816/Linux (release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> import Tkinter
>>> l = []
>>> l.append(l)
>>> Tkinter._flatten(l)
Segmentation fault (core dumped)

Here's a simple solution:

Index: _tkinter.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v
retrieving revision 1.100
diff -u -r1.100 _tkinter.c
--- _tkinter.c	2000/06/18 18:45:50	1.100
+++ _tkinter.c	2000/06/18 23:13:22
@@ -2001,13 +2001,16 @@
 }
 
 static int
-_flatten1(FlattenContext* context, PyObject* item)
+_flatten1(FlattenContext* context, PyObject* item, int depth)
 {
 	/* add tuple or list to argument tuple (recursively) */
 
 	int i, size;
 
-	if (PyList_Check(item)) {
+	if (depth > 1000) {
+		PyErr_SetString(PyExc_ValueError,"nesting too deep in _flatten");
+		return 0;
+	} else if (PyList_Check(item)) {
 		size = PyList_GET_SIZE(item);
 		/* preallocate (assume no nesting) */
 		if (context->size + size > context->maxsize && !_bump(context, size))
@@ -2016,7 +2019,7 @@
 		for (i = 0; i < size; i++) {
 			PyObject *o = PyList_GET_ITEM(item, i);
 			if (PyList_Check(o) || PyTuple_Check(o)) {
-				if (!_flatten1(context, o))
+				if (!_flatten1(context, o, depth + 1))
 					return 0;
 			} else if (o != Py_None) {
 				if (context->size + 1 > context->maxsize && !_bump(context, 1))
@@ -2033,7 +2036,7 @@
 		for (i = 0; i < size; i++) {
 			PyObject *o = PyTuple_GET_ITEM(item, i);
 			if (PyList_Check(o) || PyTuple_Check(o)) {
-				if (!_flatten1(context, o))
+				if (!_flatten1(context, o, depth + 1))
 					return 0;
 			} else if (o != Py_None) {
 				if (context->size + 1 > context->maxsize && !_bump(context, 1))
@@ -2068,7 +2071,7 @@
 	
 	context.size = 0;
 
-	if (!_flatten1(&context, item))
+	if (!_flatten1(&context, item,0))
 		return NULL;
 
 	if (_PyTuple_Resize(&context.tuple, context.size, 0))

"seems to work"; I've not tested it for performance, but I can't
believe this is too hard a hit.

Cheers,
M.



From mal@lemburg.com  Mon Jun 19 00:20:27 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 19 Jun 2000 01:20:27 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include
 unicodeobject.h,2.9,2.10
References: <200006182222.PAA19408@slayer.i.sourceforge.net> <00c601bfd975$358d0aa0$f2a6b5d4@hagrid>
Message-ID: <394D593B.DD4804E6@lemburg.com>

Fredrik Lundh wrote:
> 
> mal wrote:
> >
> >   #define Py_UNICODE_MATCH(string, offset, substring)\
> > !     ((*((string)->str + (offset)) == *((substring)->str)) &&\
> > !      !memcmp((string)->str + (offset), (substring)->str,\
> >                (substring)->length*sizeof(Py_UNICODE)))
> >
> 
> I completely forgot that this has different semantics if the
> substring happens to be empty.
> 
> (substrings are null terminated, but "\0" isn't the same
> thing as ""...)
> 
> don't have time to screen unicodeobject.c right now, but
> maybe someone else can do it?  if not, maybe amk's patch
> was a better idea after all...

I've checked the places where this macro is used: all
except the in .count() method showed the same behaviour
as for 8-bit strings.

The Unicode .count() method now also returns the same
value for empty substrings as the 8-bit strings.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From Fredrik Lundh" <effbot@telia.com  Mon Jun 19 00:29:23 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Mon, 19 Jun 2000 01:29:23 +0200
Subject: [Python-Dev] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100
References: <200006181845.LAA10182@slayer.i.sourceforge.net> <m33dma7f8y.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <002701bfd97d$09d8b640$f2a6b5d4@hagrid>

michael wrote:
> > this patch adds a fast _flatten function to the _tkinter
> > module, and imports it from Tkinter.py (if available).
>
> Unfortunately this introduces another Way To Make Python Core:

well, there are lots of way to dump core through Tkinter/Tk, so I
convinced myself that it wasn't really worth the effort to prevent
it in _flatten...

either way, the patch looks okay to me.

</F>



From mwh21@cam.ac.uk  Mon Jun 19 00:41:22 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 19 Jun 2000 00:41:22 +0100
Subject: [Python-Dev] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100
In-Reply-To: "Fredrik Lundh"'s message of "Mon, 19 Jun 2000 01:29:23 +0200"
References: <200006181845.LAA10182@slayer.i.sourceforge.net> <m33dma7f8y.fsf@atrus.jesus.cam.ac.uk> <002701bfd97d$09d8b640$f2a6b5d4@hagrid>
Message-ID: <m3zooi5zh9.fsf@atrus.jesus.cam.ac.uk>

"Fredrik Lundh" <effbot@telia.com> writes:

> michael wrote:
> > > this patch adds a fast _flatten function to the _tkinter
> > > module, and imports it from Tkinter.py (if available).
> >
> > Unfortunately this introduces another Way To Make Python Core:
> 
> well, there are lots of way to dump core through Tkinter/Tk, so I
> convinced myself that it wasn't really worth the effort to prevent
> it in _flatten...

Are there?  (I hardly know Tkinter).  Oh well.

I don't know of many "core" methods of doing it; the only one I can
think of is marshalling a recursive list, and as there seems to be a
loud party going on next door to me, I may write a patch for that this
evening...

Cheers,
M.



From mhammond@skippinet.com.au  Mon Jun 19 01:05:00 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Mon, 19 Jun 2000 10:05:00 +1000
Subject: [Python-Dev] Welcome back
In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEKGCNAA.mhammond@skippinet.com.au>

<To the tune from "Welcome back Kotter" :->

Welcome back, welcome back, welcome baaaaack - Welcome back, welcome back,
welcome baaaaack

Good to see you return.  Im sure you had a wonderful time!  From all
accounts, your wedding was beautiful, as Im sure your honeymoon was...

Now-were-just-waiting-for-the-baby-announcements-ly,

Mark.

> -----Original Message-----
> From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On
> Behalf Of Guido van Rossum
> Sent: Monday, 19 June 2000 6:47 AM
> To: akuchlin@mems-exchange.org
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] Turning on sre?



From tim_one@email.msn.com  Mon Jun 19 03:05:16 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sun, 18 Jun 2000 22:05:16 -0400
Subject: [Python-Dev] Welcome back
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBCEKGCNAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEOKGEAA.tim_one@email.msn.com>

[Mark Hammond]
> ...
> Good to see you return.  Im sure you had a wonderful time!  From
> all accounts, your wedding was beautiful, as Im sure your
> honeymoon was...
>
> Now-were-just-waiting-for-the-baby-announcements-ly,

Guido & Kim just spent the last night of their honeymoon with Uncle Timmy
(who is now living in a Virginia motel room), and I can assure you no babies
were made by any pair of us tonight.  Unless Guido is quicker than he looks.

i'm-certainly-not-ly y'rs  - tim




From skip@mojam.com (Skip Montanaro)  Sat Jun 17 04:45:14 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 16 Jun 2000 22:45:14 -0500 (CDT)
Subject: [Python-Dev] list comprehensions
Message-ID: <14666.62538.988511.305499@beluga.mojam.com>

Did list comprehensions ever make it into 1.6?  I thought I submitted a
1.6-compatible update of Greg Ewing's mods awhile ago.  Should I resubmit?
To the patches list?

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395


From guido@python.org  Mon Jun 19 16:01:24 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 19 Jun 2000 10:01:24 -0500
Subject: [Python-Dev] list comprehensions
In-Reply-To: Your message of "Fri, 16 Jun 2000 22:45:14 EST."
 <14666.62538.988511.305499@beluga.mojam.com>
References: <14666.62538.988511.305499@beluga.mojam.com>
Message-ID: <200006191501.KAA02197@cj20424-a.reston1.va.home.com>

> Did list comprehensions ever make it into 1.6?

No (as far as I'm aware :-).

> I thought I submitted a
> 1.6-compatible update of Greg Ewing's mods awhile ago.  Should I resubmit?
> To the patches list?

It's rather late in the release cycle -- I'm trying to get alpha 3
released, and i'm still 1400 messages behind on my email.

But submitting a patch might be a good idea anyway so we won't forget
about it (and maybe it's of such baffling simplicity that it'll charm
its way past the guards :-).

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


From ping@lfw.org  Mon Jun 19 19:59:15 2000
From: ping@lfw.org (Ka-Ping Yee)
Date: Mon, 19 Jun 2000 13:59:15 -0500 (CDT)
Subject: [Python-Dev] list comprehensions
In-Reply-To: <200006191501.KAA02197@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10006191358330.10836-100000@server1.lfw.org>

On Mon, 19 Jun 2000, Guido van Rossum wrote:
> > Did list comprehensions ever make it into 1.6?
> 
> No (as far as I'm aware :-).
[...] 
> But submitting a patch might be a good idea anyway so we won't forget
> about it (and maybe it's of such baffling simplicity that it'll charm
> its way past the guards :-).

I just have to say i thought list comprehensions were
really cool.


-- ?!ng



From skip@mojam.com (Skip Montanaro)  Mon Jun 19 21:17:59 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Mon, 19 Jun 2000 15:17:59 -0500
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
Message-ID: <200006192017.PAA00690@beluga.mojam.com>

Python's sys module defines an exitfunc variable that is settable from
Python scripts.  At exit, that function will be called with no arguments.
While this is a good start at supporting standard cleanup activities, it
defines no protocol to be used by modules that wish to use sys.exitfunc,
which leads to one of two extremes: 1, two modules wishing to define cleanup
functions both clobber sys.exitfunc or 2, to avoid collisions they don't use
the functionality provided.

At an application level this is okay.  Within a single application you can
define an application-specific protocol to handle the situation.
Unfortunately, this still leaves Python's core modules without a good way to
register exit functions.

I ran into this problem today.  I would really like the rlcompleter module
to read and write readline history files from Python.  Reading a history
file at module startup is no problem, but deciding where to write the
history file is a problem.  The logical place is at the time sys.exitfunc is
executed.

For my own applications I long ago wrote a very simple module (called
exit.py, appended to this message) that defines two functions:

    * exit.register_exitfunc takes a function object and a set of optional
      arguments and appends them to a list.

    * exit._run_exitfuncs is bound to sys.exitfunc and executes the
      registered exit functions in the order they appear in the list.

I propose exit.py as the starting point for a well-defined protocol for
modules to register exit functions without collisions.

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395


"""
allow programmer to define multiple exit functions to be executed upon normal
program termination.
"""

_exithandlers = []
def _run_exitfuncs():
    while _exithandlers:
        func, targs, kargs = _exithandlers[0]
        apply(func, targs, kargs)
        _exithandlers.remove(_exithandlers[0])

def register_exitfunc(func, *targs, **kargs):
    """register a function to be executed upon normal program termination

    arguments are a function object, and zero or more arguments to pass to
    it.
    """
    _exithandlers.append((func, targs, kargs))

import sys
try:
    x = sys.exitfunc
except AttributeError:
    sys.exitfunc = _run_exitfuncs
del sys

if __name__ == "__main__":
    def x1():
        print "running x1"
    def x2(n):
        print "running x2(%s)" % `n`
    def x3(n, kwd=None):
        print "running x3(%s, kwd=%s)" % (`n`, `kwd`)

    register_exitfunc(x1)
    register_exitfunc(x2, 12)
    register_exitfunc(x3, 5, "bar")
    register_exitfunc(x3, "no kwd args")



From DavidA@ActiveState.com  Mon Jun 19 21:27:48 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Mon, 19 Jun 2000 13:27:48 -0700
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <200006192017.PAA00690@beluga.mojam.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJCEPHCIAA.DavidA@ActiveState.com>

+1 on the idea.  I wonder if it makes sense to publish a mechanism to allow
de-registering of callbacks, or if that's featuritis.

Also, I'd change:

> try:
>     x = sys.exitfunc
> except AttributeError:
>     sys.exitfunc = _run_exitfuncs
> del sys

to:

try:
	register_exitfuncs(sys.exitfunc)
finally:
	sys.exitfunc = _run_exitfuncs

Or some such.

--david

> -----Original Message-----
> From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On
> Behalf Of Skip Montanaro
> Sent: Monday, June 19, 2000 1:18 PM
> To: python-dev@python.org
> Subject: [Python-Dev] Proposal: standard way of defining and executing
> "atexit" functions...
> Importance: Low
>
>
>
> Python's sys module defines an exitfunc variable that is settable from
> Python scripts.  At exit, that function will be called with no arguments.
> While this is a good start at supporting standard cleanup activities, it
> defines no protocol to be used by modules that wish to use sys.exitfunc,
> which leads to one of two extremes: 1, two modules wishing to
> define cleanup
> functions both clobber sys.exitfunc or 2, to avoid collisions
> they don't use
> the functionality provided.
>
> At an application level this is okay.  Within a single application you can
> define an application-specific protocol to handle the situation.
> Unfortunately, this still leaves Python's core modules without a
> good way to
> register exit functions.
>
> I ran into this problem today.  I would really like the rlcompleter module
> to read and write readline history files from Python.  Reading a history
> file at module startup is no problem, but deciding where to write the
> history file is a problem.  The logical place is at the time
> sys.exitfunc is
> executed.
>
> For my own applications I long ago wrote a very simple module (called
> exit.py, appended to this message) that defines two functions:
>
>     * exit.register_exitfunc takes a function object and a set of optional
>       arguments and appends them to a list.
>
>     * exit._run_exitfuncs is bound to sys.exitfunc and executes the
>       registered exit functions in the order they appear in the list.
>
> I propose exit.py as the starting point for a well-defined protocol for
> modules to register exit functions without collisions.
>
> --
> Skip Montanaro, skip@mojam.com, http://www.mojam.com/,
> http://www.musi-cal.com/
> On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always
> lived
> his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
>     https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395
>
>
> """
> allow programmer to define multiple exit functions to be executed upon
> normal
> program termination.
> """
>
> _exithandlers = []
> def _run_exitfuncs():
>     while _exithandlers:
>         func, targs, kargs = _exithandlers[0]
>         apply(func, targs, kargs)
>         _exithandlers.remove(_exithandlers[0])
>
> def register_exitfunc(func, *targs, **kargs):
>     """register a function to be executed upon normal program termination
>
>     arguments are a function object, and zero or more arguments to pass to
>     it.
>     """
>     _exithandlers.append((func, targs, kargs))
>
> import sys
> try:
>     x = sys.exitfunc
> except AttributeError:
>     sys.exitfunc = _run_exitfuncs
> del sys
>
> if __name__ == "__main__":
>     def x1():
>         print "running x1"
>     def x2(n):
>         print "running x2(%s)" % `n`
>     def x3(n, kwd=None):
>         print "running x3(%s, kwd=%s)" % (`n`, `kwd`)
>
>     register_exitfunc(x1)
>     register_exitfunc(x2, 12)
>     register_exitfunc(x3, 5, "bar")
>     register_exitfunc(x3, "no kwd args")
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev
>



From skip@mojam.com (Skip Montanaro)  Mon Jun 19 21:55:09 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Mon, 19 Jun 2000 15:55:09 -0500 (CDT)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJCEPHCIAA.DavidA@ActiveState.com>
References: <200006192017.PAA00690@beluga.mojam.com>
 <PLEJJNOHDIGGLDPOGPJJCEPHCIAA.DavidA@ActiveState.com>
Message-ID: <14670.34989.887973.797947@beluga.mojam.com>

    David> +1 on the idea.  I wonder if it makes sense to publish a
    David> mechanism to allow de-registering of callbacks, or if that's
    David> featuritis.

While writing my message I thought, "I'll bet the first question asked will
be about unregistering exit functions."  I've been using the module I
appended to my message unchanged for a couple years and never needed such
functionality.  I'm sure there are applications that could use it, but I
think they'd be a small minority.  Since the only defined interface is a
single registration function (_run_exitfuncs is only used internally), I
think you'd be free to add some unregister function protocol at a later
time if it was deemed necessary.

    David> Also, I'd change:

    >> try:
    >>     x = sys.exitfunc
    >> except AttributeError:
    >>     sys.exitfunc = _run_exitfuncs
    >> del sys

    David> to:

    David> try:
    David> 	register_exitfuncs(sys.exitfunc)
    David> finally:
    David> 	sys.exitfunc = _run_exitfuncs

    David> Or some such.

register_exitfunc is only meant to be called by clients of the module, not
used internally.  You're assuming that if something else was already bound
to sys.exitfunc that it's not _run_exitfuncs.  With your try/finally code
try the following (mentally is fine):

    import exit
    def foo():
        print 1
    exit.register_exitfunc(foo)
    reload(exit)

I think you'll see that exit._run_exitfuncs is on its own list of exit
functions.  That could be bad.

The setup code:

    try:
        x = sys.exitfunc
    except AttributeError:
        sys.exitfunc = _run_exitfuncs

is meant to avoid doing anything if any other module beat us to
sys.exitfunc.  Perhaps it should just be

    sys.exitfunc = _run_exitfuncs

If someone fails to use the defined protocol, screw 'em... ;-)

Skip


From DavidA@ActiveState.com  Mon Jun 19 22:12:03 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Mon, 19 Jun 2000 14:12:03 -0700
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <14670.34989.887973.797947@beluga.mojam.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com>

> If someone fails to use the defined protocol, screw 'em... ;-)

That's unreasonable given that existing tools might include a library which
might be upgraded to use the new mechanism while the old code used its own
mechanism happily.  For example, I've used my own protocols in the past
which went something like...

def register_exitfunc(func):
    old_exitfunc = getattr(sys, 'exitfunc', None)
    def wrapper(old_exitfunc=old_exitfunc, new_func=func):
      if old_exitfunc is not None: old_exitfunc()
      new_func()
    sys.exitfunc = wrapper

or some such, creating a call chain instead of a sequence of calls, and it's
a 'fine' protocol in that it worked fine in the absence of a standard.  No
need to break code if we can avoid it.

The point of my pseudo-patch, if it wasn't clear, was that if a function is
already in sys.exitfunc, then it should still be called on exit after the
new exit module is imported.  You're right that my patch didn't properly
check that _run_exitfuncs might be that function.

--david



From skip@mojam.com (Skip Montanaro)  Mon Jun 19 22:41:54 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Mon, 19 Jun 2000 16:41:54 -0500 (CDT)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com>
References: <14670.34989.887973.797947@beluga.mojam.com>
 <PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com>
Message-ID: <14670.37794.998270.762852@beluga.mojam.com>

    >> If someone fails to use the defined protocol, screw 'em... ;-)

    David> That's unreasonable given that existing tools might include a
    David> library which might be upgraded to use the new mechanism while
    David> the old code used its own mechanism happily.  

Point taken.  I'll look at extending the module to accommodate other
sys.exitfunc callers.

Skip


From Vladimir.Marangozov@inrialpes.fr  Tue Jun 20 02:11:24 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Tue, 20 Jun 2000 03:11:24 +0200 (CEST)
Subject: [Python-Dev] mmapmodule.c,2.10,2.11
In-Reply-To: <20000618002224.A12729@newcnri.cnri.reston.va.us> from "Andrew Kuchling" at Jun 18, 2000 12:22:24 AM
Message-ID: <200006200111.DAA01591@python.inrialpes.fr>

Andrew Kuchling wrote:
> 
> On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote:
> >On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
> >It works okay without the MS_INVALIDATE flag though, so I'd suggest
> >removing it from msync in the flush and dealloc methods.
> 
> Ooh, you're right.  The Linux msync man page says "MS_ASYNC specifies
> that an update be scheduled, but the call returns immediately.
> MS_SYNC asks for an update and waits for it to complete.
> MS_INVALIDATE asks to invalidate other mappings of the same file (so
> that they can be updated with the fresh values just written)."  So
> MS_INVALIDATE seems far too drastic.

Yes.

> 
> >Also, it would probably be a good idea to allow optional flags for
> >flush, as it's done in new_mmap_object, the default being only MS_SYNC.
> 
> The problem is: does Windows provide equivalent functionality?  (Is
> there documentation available online for CreateFileMapping that I
> could look at?)

Well, I had a look at my Windows book. Although the mmap functionnality is
equivalent, overall, there are no equivalent flags in FlushViewOfFile, etc.
Maybe this is too subtle to be of any real use after all, so I retract the
idea. MS_SYNC alone is fine.

Another point: I'm not thrilled about the idea of raising a SystemError
for m.resize if native mremap is missing (which is also AIX's case).
unmap/mmap again with the new size is the emulation solution everybody
would do in Python when m.resize is not implemented. So I'd suggest
implementing it in C (which is what the Windows version does, btw).
Furthermore, having an unimplemented method makes little sense to me.
For implementing this emulation on Unix, however, we would need to
remember in additional slots the original mmap flags & rights, so that
the second (or any subsequent) mmap call uses the same flags & rights
as the first one.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From pf@artcom-gmbh.de  Tue Jun 20 08:32:33 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Tue, 20 Jun 2000 09:32:33 +0200 (MEST)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com> from David Ascher at "Jun 19, 2000  2:12: 3 pm"
Message-ID: <m134IWP-000DieC@artcom0.artcom-gmbh.de>

Hi Skip, Hi David,

David Ascher:
> > If someone fails to use the defined protocol, screw 'em... ;-)
> 
> That's unreasonable given that existing tools might include a library which
> might be upgraded to use the new mechanism while the old code used its own
> mechanism happily.  For example, I've used my own protocols in the past
> which went something like...
> 
> def register_exitfunc(func):
>     old_exitfunc = getattr(sys, 'exitfunc', None)
>     def wrapper(old_exitfunc=old_exitfunc, new_func=func):
>       if old_exitfunc is not None: old_exitfunc()
>       new_func()
>     sys.exitfunc = wrapper
> 
> or some such, creating a call chain instead of a sequence of calls, and it's
> a 'fine' protocol in that it worked fine in the absence of a standard.  No
> need to break code if we can avoid it.

Davids wrapper function implements a FIFO strategy for termination.  
I think this is not desired.  Normally you want LIFO, because higher level 
services in an application are initialized later during startup.  Those 
services usually depend on lower level services, which should still be 
available at termination time of the higher level services.  

I try to explain this by an example:
Module A provides some kind of network connections. 
Module B uses (imports) Module A to access a remote resource administration 
server to provide access to remote devices or resources.
During program termination Module B likes to release all resources reserved 
for (owned by) the program.  It uses Module A to submit a cleanup request to
the server.  Module A however wants to close all open network connections.

The following function (termination protocol) solves this by exchanging the 
sequence of calls within the wrapper:

def register_exit_func(func, *args, **kw):
    import sys
    previous_func = sys.exit_func
    def wrapped_func(previous_func=previous_func, func=func, args=args, kw=kw):
        try:
            apply(func, args, kw)
        finally:
            if previous_func is not None: 
                previous_func()
    sys.exit_func = wrapped_func

In the past I've placed such a function into a common base module of my apps.
But I think, Skip is right, that a termination protocol should be part of
the standard library.  

But a separate module 'exit.py' seems to be overkill for single basic 
function.  May be it should be put into the module 'os'?  Handling of 
program termination is something, which considered as a generic 
operating system service.  From the users point of view 'sys' would
be a better place, but this would require rewriting in C: ugly.

I also agree with Skip, that the possibility to unregister an exit_func is 
normally not needed.  The same effect can be achieved by doing nothing in 
the exit_func.

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)


From mhammond@skippinet.com.au  Tue Jun 20 09:02:14 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Tue, 20 Jun 2000 18:02:14 +1000
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <m134IWP-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <ECEPKNMJLHAPFFJHDOJBOEMCCNAA.mhammond@skippinet.com.au>

Peter:

> Davids wrapper function implements a FIFO strategy for termination.  
> I think this is not desired.  Normally you want LIFO,

Agreed.  LIFO is definately preferred IMO.

Mark.



From pf@artcom-gmbh.de  Tue Jun 20 09:08:16 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Tue, 20 Jun 2000 10:08:16 +0200 (MEST)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: From "(env:" "pf)" at "Jun 20, 2000  9:32:33 am"
Message-ID: <m134J4y-000DieC@artcom0.artcom-gmbh.de>

Hi, 

I wrote:
> def register_exit_func(func, *args, **kw):
>     import sys
>     previous_func = sys.exit_func

this should have been 'sys.exitfunc'.
I've also misssed to note, that I placed the following line into 
the module init code: 

import sys; def _nop(): pass; sys.exitfunc = _nop
Otherwise I had to use getattr(sys, 'exitfunc', None) as David suggested.

Next time I should actually cut'n'paste working code instead typing from
blurred memory. :-(

Another point I forgot, was that you usually want to install signal
handlers on unices, that handle the signal.SIGTERM, signal.SIGHUP and
signal.SIGINT signals and invoke exit function to do some final
cleanup.

Regards, Peter


From mal@lemburg.com  Tue Jun 20 10:01:50 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 20 Jun 2000 11:01:50 +0200
Subject: [Python-Dev] Proposal: standard way of defining and executing
 "atexit" functions...
References: <m134J4y-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <394F32FE.B926C19A@lemburg.com>

This is a multi-part message in MIME format.
--------------23EABAE62CA66BEF28D4AF1B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Attached you find a similar module which I have used for years.
It has all the requested features, plus allows deregistration
and supports a more OO-like interface.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
--------------23EABAE62CA66BEF28D4AF1B
Content-Type: text/python; charset=us-ascii;
 name="ExitFunctions.py"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ExitFunctions.py"

""" Central Registry for sys.exitfunc()-type functions
"""
__version__ = "0.1"
__package_info__ = """
BEGIN PYTHON-PACKAGE-INFO 1.0
Title:                  Central Registry for sys.exitfunc()-type functions
Current-Version:        0.1
Home-Page:              http://starship.skyport.net/~lemburg
Primary-Site:           http://starship.skyport.net/~lemburg/ExitFunctions.py
END PYTHON-PACKAGE-INFO
"""
import sys,traceback

class ExitFunctionDispatcher:

    """ Singleton that manages exit functions. These function will be
        called upon system exit in reverse order of their registering.
    """
    def __init__(self):

        """ Install the dispatcher as sys.exitfunc()
        """
        self.exitfunc_list = []
        if hasattr(sys,'exitfunc'):
            self.old_exitfunc = sys.exitfunc
        else:
            self.old_exitfunc = None
        sys.exitfunc = self.exitfunc

    def exitfunc(self,

                 write=sys.stderr.write,print_exc=traceback.print_exc,
                 stderr=sys.stderr):

        """ This is the exitfunc that we install to dispatch the
            processing to the registered other functions
        """
        for f in self.exitfunc_list:
            try:
                f()
            except:
                write('Error while executing Exitfunction %s:\n' % f.__name__)
                print_exc(10,stderr)
        # Now that we're finished, call the previously installed exitfunc()
        if self.old_exitfunc:
            self.old_exitfunc()

    def register(self,f,position=0):
        
        """ Register f as exit function. These functions must not take
            parameters.
            - position = 0: register the function at the beginning of the
              list; these functions get called before the functions already
              in the list (default)
            - position = -1: register the function at the end of the list;
              the function will get called after all other functions
        """
        if position < 0: 
            position = position + len(self.exitfunc_list) + 1
        self.exitfunc_list.insert(position,f)

    def deregister(self,f):

        """ Remove the function f from the exitfunc list; if it is not
            found, the error is silently ignored.
        """
        try:
            self.exitfunc_list.remove(f)
        except:
            pass

# Create the singleton
ExitFunctions = ExitFunctionDispatcher()

--------------23EABAE62CA66BEF28D4AF1B--



From fredrik@pythonware.com  Tue Jun 20 11:15:01 2000
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 12:15:01 +0200
Subject: [Python-Dev] talking about performance... [case closed]
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com>
Message-ID: <003101bfdaa0$693b4de0$0900a8c0@SPIFF>

mal wrote:
> > > Index: unicodeobject.c
> > 
> > MATCH is used in a couple of places; it's probably a better idea
> > to change the macro (in Include/unicodeobject.h).  MAL?
> 
> Right. I'll add Andrew's proposed patch to the macro def.

for the record, my little benchmark now runs about five
times faster than before -- which means that 16-bit find
is now ~30% faster than 8-bit find (barry? ;-)

cheers /F

footnote: for the exact figures, see:
http://hem.passagen.se/eff/2000_06_01_bot-archive.htm#361472



From mhammond@skippinet.com.au  Tue Jun 20 12:42:53 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Tue, 20 Jun 2000 21:42:53 +1000
Subject: [Python-Dev] Fw: Access violation when no memory
Message-ID: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au>

From the newsgroup.  Any thoughts?

Mark.

"Phil Mayes" <nospam@bitbucket.com> wrote in message
news:<olD35.82$_%.4481@newsfeed.avtel.net>...
> The following program progressively allocates all memory:
>     size = 1 << 20
>     list = [None,]
>     while size:
>         try:
>             mem = [None] * size
>             mem[0] = list
>             list = mem
>         except:
>             size = size / 2
>
> It fails with an access violation.  (Turn off virtual memory
> to provoke it.)  This is not a theoretical situation for me:
> I have a beta release in the field that is crashing like this.
> The immediate cause is this:
>
> 1. we are handling a MemoryError
> 2. the following call cannot allocate a traceback object
>      ceval.c line 1800:    PyErr_Fetch(&exc, &val, &tb);
> 3. the NULL pointer at tb is pushed here:
>      ceval.c line 1816:    PUSH(tb);
>      ceval.c line 1817:    PUSH(val);
>      ceval.c line 1818:    PUSH(exc);
> 4. later it is popped here and its ref count is decremented:
>      ceval.c line 682:    case POP_TOP:
>      ceval.c line 683:        v = POP();
>      ceval.c line 684:        Py_DECREF(v);
>      ceval.c line 685:        continue;
>
> This is with 1.5.2 but the crash still happens with 1.6a2.
> At this stage I am way out of my depth, and  the only way I
> see to fix this is to change Py_DECREF to Py_XDECREF, which
> is a (minor?) inefficiency. Can anyone recommend a better way?
>
> And should I report this at http://www.python.org/python-bugs?
> I do not have access to the current CVS tree.
>
> TIA, Phil Mayes
> --
> pmayes AT olivebr DOT com
>
>
>



From gward@mems-exchange.org  Tue Jun 20 13:33:44 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Tue, 20 Jun 2000 08:33:44 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com>
Message-ID: <20000620083344.A3499@ludwig.cnri.reston.va.us>

On 09 June 2000, Eric S. Raymond said:
> I think it's time to consider including PIL in the core Python 1.6 release.
> I've been following the work being done over there, and I believe the 
> code has reached a sufficient level of maturity to justify this.

-1 from me.  What's the point of the Distutils if we just throw
everything "useful" into the standard distribution?

        Greg


From gward@mems-exchange.org  Tue Jun 20 13:40:41 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Tue, 20 Jun 2000 08:40:41 -0400
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <200006130237.EAA10373@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jun 13, 2000 at 04:37:23AM +0200
References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr>
Message-ID: <20000620084040.B3499@ludwig.cnri.reston.va.us>

On 13 June 2000, Vladimir Marangozov said:
> > - Fix ./ld_so_aix installation problem on AIX (anybody know more about
> >   this???)
> 
> Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem
> for building C extensions with distutils than an installation problem per se.
> Some time ago, I saw a workaround checked in by Greg. If this is still judged
> as a problem, I'd like to hear about it. This is a minor thing. I have yet
> to install & run the distutil package on AIX, though, and see what happens.

As I recall, my workaround didn't work.  (Would that make it a
failaround?)

Vladimir, *please* give the Distutils a whirl on AIX -- I suspect some
sort of hack is needed to get extension-building working there.  I don't
much care if the Makefile installed by Python is "fixed" to have an
absolute path to "ld_so_aix" instead of "./ld_so_aix" -- that should
make extension-building with the Distutils OK, but it will break the
relocatability of a Python installation on AIX.  Also, it won't fix
Distutils with Python 1.5.2.

Thanks --

       Greg


From paul@prescod.net  Tue Jun 20 14:30:13 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 20 Jun 2000 15:30:13 +0200
Subject: [Python-Dev] RFC: Including PIL in 1.6
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us>
Message-ID: <394F71E5.C7CEC32D@prescod.net>

Greg Ward wrote:
> 
> ...
> -1 from me.  What's the point of the Distutils if we just throw
> everything "useful" into the standard distribution?

One way to look at it is vertical versus horizontal. I think that that's
how the Java world works (unofficially). If Java is one extreme and ANSI
C is on the other, I prefer to err on the Java side (which we probably
do).

The big issue is configuration management. if we put PIL (or anything
else) in the standard distribution we are promising to keep that code in
sync with everything else. This is a big boon to users and a big
headache for maintainers. The question is when the boon is enough to
justify the headache.

It's one thing to tell a user: "Just type distutils and everything will
magically become available." But they usually come back: "I'm getting an
error message about append not taking that many arguments..." or
something like that. Libraries breaking libraries is actually the most
common case.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Music is the stuff between the notes." - Claude Debussy


From bwarsaw@python.org  Tue Jun 20 14:43:32 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Tue, 20 Jun 2000 09:43:32 -0400 (EDT)
Subject: [Python-Dev] talking about performance... [case closed]
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>
 <20000618152020.B14713@newcnri.cnri.reston.va.us>
 <008301bfd96e$0bd98d20$f2a6b5d4@hagrid>
 <394D43B0.8CC7070@lemburg.com>
 <003101bfdaa0$693b4de0$0900a8c0@SPIFF>
Message-ID: <14671.29956.819067.208771@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <fredrik@pythonware.com> writes:

    FL> for the record, my little benchmark now runs about five
    FL> times faster than before -- which means that 16-bit find
    FL> is now ~30% faster than 8-bit find (barry? ;-)

Awesome!


From akuchlin@mems-exchange.org  Tue Jun 20 14:53:09 2000
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 09:53:09 -0400
Subject: [Python-Dev] talking about performance... [case closed]
In-Reply-To: <003101bfdaa0$693b4de0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jun 20, 2000 at 12:15:01PM +0200
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF>
Message-ID: <20000620095309.A3039@amarok.cnri.reston.va.us>

On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote:
>for the record, my little benchmark now runs about five
>times faster than before -- which means that 16-bit find
>is now ~30% faster than 8-bit find (barry? ;-)

Speculation: the code in stringobject.c looks like this:
                for (; i <= last; ++i)
                        if (s[i] == sub[0] &&
                            (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0))
                                return (long)i;
 
It checks the first character, and then does the memcmp() skipping the
first character, or succeeds if the substring length is 1; the Unicode
find is simpler, just doing the full memcmp.  I wonder if the extra n
== 1 and i+1, n-1 arithmetic costs more than it saves?  This is
probably delicately tied to the speed of your memcmp().  Anyone want
to try the simpler version and report on whether it makes a difference?

--amk


From Fredrik Lundh" <effbot@telia.com  Tue Jun 20 16:26:42 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 17:26:42 +0200
Subject: [Python-Dev] faster 8-bit find/split (was: talking about performance...)
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> <20000620095309.A3039@amarok.cnri.reston.va.us>
Message-ID: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid>

This is a multi-part message in MIME format.

------=_NextPart_000_0071_01BFDADC.B3488D80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

[as discussed on python-dev]

amk wrote:
> On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote:
> >for the record, my little benchmark now runs about five
> >times faster than before -- which means that 16-bit find
> >is now ~30% faster than 8-bit find (barry? ;-)
>=20
> Speculation: the code in stringobject.c looks like this:
>                 for (; i <=3D last; ++i)
>                         if (s[i] =3D=3D sub[0] &&
>                             (n =3D=3D 1 || memcmp(&s[i+1], &sub[1], =
n-1) =3D=3D 0))
>                                 return (long)i;
> =20
> It checks the first character, and then does the memcmp() skipping the
> first character, or succeeds if the substring length is 1; the Unicode
> find is simpler, just doing the full memcmp.  I wonder if the extra n
> =3D=3D 1 and i+1, n-1 arithmetic costs more than it saves?

at least on my box (win95, msvc 5)...  after simplifying the code,
string.find is now faster than sre.search.  it's still 15% slower than
the 16-bit string find, but I don't have time to dig into that right
now...

patches are included. =20

</F>

I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under copyright,
patent or other rights or interests ("claims").  To the extent that I
have any such claims, I hereby grant to CNRI a nonexclusive,
irrevocable, royalty-free, worldwide license to reproduce, distribute,
perform and/or display publicly, prepare derivative versions, and
otherwise use this contribution as part of the Python software and its
related documentation, or any derivative versions thereof, at no cost to
CNRI or its licensed users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide whether or
not to incorporate this contribution in the Python software and its
related documentation.  I further grant CNRI permission to use my name
and other identifying information provided to CNRI by me for use in
connection with the Python software and its related documentation.


------=_NextPart_000_0071_01BFDADC.B3488D80
Content-Type: text/plain;
	name="string-patch.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="string-patch.txt"

Index: Objects/stringobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/stringobject.c,v
retrieving revision 2.68
diff -u -r2.68 stringobject.c
--- Objects/stringobject.c	2000/06/14 09:18:09	2.68
+++ Objects/stringobject.c	2000/06/20 15:07:51
@@ -651,7 +651,7 @@
 
 	i = j = 0;
 	while (i+n <= len) {
-		if (s[i] == sub[0] && (n == 1 || memcmp(s+i, sub, n) == 0)) {
+		if (s[i] == sub[0] && memcmp(s+i, sub, n) == 0) {
 			if (maxsplit-- <= 0)
 				break;
 			item = PyString_FromStringAndSize(s+j, (int)(i-j));
@@ -852,8 +852,7 @@
 			return (long)i;
 		last -= n;
 		for (; i <= last; ++i)
-			if (s[i] == sub[0] &&
-			    (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0))
+			if (s[i] == sub[0] && memcmp(s+i, sub, n) == 0)
 				return (long)i;
 	}
 	else {
@@ -862,8 +861,7 @@
         	if (n == 0 && i <= last)
 			return (long)last;
 		for (j = last-n; j >= i; --j)
-			if (s[j] == sub[0] &&
-			    (n == 1 || memcmp(&s[j+1], &sub[1], n-1) == 0))
+			if (s[j] == sub[0] && memcmp(s+j, sub, n) == 0)
 				return (long)j;
 	}
 	
@@ -1415,9 +1413,7 @@
 	len -= pat_len;
 
 	for (ii = 0; ii <= len; ii++) {
-		if (mem[ii] == pat[0] &&
-		    (pat_len == 1 ||
-		     memcmp(&mem[ii+1], &pat[1], pat_len-1) == 0)) {
+		if (mem[ii] == pat[0] && memcmp(mem+ii, pat, pat_len) == 0) {
 			return ii;
 		}
 	}

------=_NextPart_000_0071_01BFDADC.B3488D80--



From fdrake@beopen.com  Tue Jun 20 16:47:35 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 20 Jun 2000 11:47:35 -0400 (EDT)
Subject: [Python-Dev] faster 8-bit find/split (was: talking about performance...)
In-Reply-To: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid>
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>
 <20000618152020.B14713@newcnri.cnri.reston.va.us>
 <008301bfd96e$0bd98d20$f2a6b5d4@hagrid>
 <394D43B0.8CC7070@lemburg.com>
 <003101bfdaa0$693b4de0$0900a8c0@SPIFF>
 <20000620095309.A3039@amarok.cnri.reston.va.us>
 <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid>
Message-ID: <14671.37399.809253.945519@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > patches are included.  

  Now checked in, thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From tim_one@email.msn.com  Tue Jun 20 17:47:47 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 20 Jun 2000 12:47:47 -0400
Subject: [Python-Dev] talking about performance... [case closed]
In-Reply-To: <20000620095309.A3039@amarok.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCGECFGFAA.tim_one@email.msn.com>

[Fredrik Lundh]
> for the record, my little benchmark now runs about five
> times faster than before -- which means that 16-bit find
> is now ~30% faster than 8-bit find (barry? ;-)

[Andrew M. Kuchling]/
> Speculation: the code in stringobject.c looks like this:
>                 for (; i <= last; ++i)
>                         if (s[i] == sub[0] &&
>                             (n == 1 || memcmp(&s[i+1], &sub[1],
> n-1) == 0))
>                                 return (long)i;
> ...
> the Unicode find is simpler, just doing the full memcmp.  I wonder
> if the extra n == 1 and i+1, n-1 arithmetic costs more than it
> saves?

So the intent of the code is to avoid the expense of calling memcmp if a
full n-character memcmp can't possibly find equality at i (due to mismatch
of first characters), and the assumption is that first characters mismatch
frequently.  Both seem like good calls to me!

> This is probably delicately tied to the speed of your memcmp().

Also on whether your memcmp() is an actual external function or a full or
partial inline expansion (e.g., the strcmp at KSR expanded into code much
like the "by-hand" stuff above, skipping "the real" strcmp if the first
characters weren't equal).

> Anyone want to try the simpler version and report on whether
> it makes a difference?

No <wink>.  But if someone does, a good compromise might be to split this
into two loops, one for the n==1 case and another for n>1.  The "+1/-1" are
dubious in any case (i.e., "memcmp(s+i, sub, n) == 0" saves the fiddly
arithmetic at the also-minor cost of making memcmp do one redundant
character compare).




From dan@cgsoftware.com  Tue Jun 20 17:55:11 2000
From: dan@cgsoftware.com (Daniel Berlin)
Date: Tue, 20 Jun 2000 09:55:11 -0700 (PDT)
Subject: [Python-Dev] talking about performance... [case closed]
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECFGFAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10006200953020.31239-100000@propylaea.anduin.com>

> So the intent of the code is to avoid the expense of calling memcmp if a
> full n-character memcmp can't possibly find equality at i (due to mismatch
> of first characters), and the assumption is that first characters mismatch
> frequently.  Both seem like good calls to me!

However, smart compilers (gcc 2.95+ fer instance) will produce an inline
memcmp call that is faster, and has no overhead (IE it's not making a
library call).
Thus, the first character mismatch test is useless.
We had the same thing in strcmp macros in GDB, where we tested the first
character, then strcmp'd.
It was faster to just strcmp, even when they *did* mismatch.

--Dan



From esr@thyrsus.com  Tue Jun 20 18:21:50 2000
From: esr@thyrsus.com (esr@thyrsus.com)
Date: Tue, 20 Jun 2000 13:21:50 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <Pine.LNX.4.10.10006191358330.10836-100000@server1.lfw.org>
References: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> <Pine.LNX.4.10.10006191358330.10836-100000@server1.lfw.org>
Message-ID: <20000620132150.O8678@thyrsus.com>

Ka-Ping Yee <ping@lfw.org>:
> On Mon, 19 Jun 2000, Guido van Rossum wrote:
> > But submitting a patch might be a good idea anyway so we won't forget
> > about it (and maybe it's of such baffling simplicity that it'll charm
> > its way past the guards :-).
> 
> I just have to say i thought list comprehensions were
> really cool.

Ditto.  I would like to see this in 1.6.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The men and women who founded our country knew, by experience, that there
are times when the free person's answer to oppressive government has to be
delivered with a bullet.  Thus, the right to bear arms is not just *a*
freedom; it's the mother of all freedoms.  Don't let them disarm you!


From esr@thyrsus.com  Tue Jun 20 19:04:19 2000
From: esr@thyrsus.com (esr@thyrsus.com)
Date: Tue, 20 Jun 2000 14:04:19 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620083344.A3499@ludwig.cnri.reston.va.us>
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us>
Message-ID: <20000620140419.C10038@thyrsus.com>

Greg Ward <gward@mems-exchange.org>:
> -1 from me.  What's the point of the Distutils if we just throw
> everything "useful" into the standard distribution?

Watch that argument -- it could turn and bite you.  What's the justification
for including, e.g. POP client classes in the standard distribution?

One of Python's most important strengths is the "batteries *are*
included" richness of the standard environment.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The two pillars of `political correctness' are, 
  a) willful ignorance, and
  b) a steadfast refusal to face the truth
	-- George MacDonald Fraser


From Fredrik Lundh" <effbot@telia.com  Tue Jun 20 18:59:35 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 19:59:35 +0200
Subject: [Python-Dev] RFC: Including PIL in 1.6
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us>
Message-ID: <001101bfdae1$5094f7a0$f2a6b5d4@hagrid>

greg wrote:

> On 09 June 2000, Eric S. Raymond said:
> > I think it's time to consider including PIL in the core Python 1.6 =
release.
> > I've been following the work being done over there, and I believe =
the=20
> > code has reached a sufficient level of maturity to justify this.
>=20
> -1 from me.  What's the point of the Distutils if we just throw
> everything "useful" into the standard distribution?

strange argument.  what's the point of including *anything*
if we have distutils?

...

fwiw, I'm -0 on this one;

it might better to work on a "Python Standards Base" which
specifies a bunch of extensions that people are encouraged
to include in their distributions.

let's see: zlib, expat, (portions of) numpy, pil, piddle, ...

</F>



From Fredrik Lundh" <effbot@telia.com  Tue Jun 20 19:02:24 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 20:02:24 +0200
Subject: [Python-Dev] talking about performance...
References: <LNBBLJKPBEHFEDALKOLCGECFGFAA.tim_one@email.msn.com>
Message-ID: <002001bfdae1$b28942e0$f2a6b5d4@hagrid>

tim wrote:

> No <wink>.  But if someone does, a good compromise might be to split =
this
> into two loops, one for the n=3D=3D1 case and another for n>1.

how about this one:

    if (dir > 0) {
        char *p, *e;
        if (n =3D=3D 0 && i <=3D last)
            return (long)i;
        e =3D s + last - n + 1;
        for (;;) {
            p =3D memchr(s, sub[0], e - s);
            if (p =3D=3D NULL)
                break;
            if (n =3D=3D 1 || memcmp(p, sub, n) =3D=3D 0)
                return (long) (p - s);
            s =3D p + 1;
        }
    }

new record time: 1.6 seconds (down from 2.2)

</F>



From akuchlin@mems-exchange.org  Tue Jun 20 19:04:06 2000
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 14:04:06 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com>
Message-ID: <20000620140406.B3142@amarok.cnri.reston.va.us>

>Watch that argument -- it could turn and bite you.  What's the justification
>for including, e.g. POP client classes in the standard distribution?
>One of Python's most important strengths is the "batteries *are*
>included" richness of the standard environment.

Once there are enough pieces to make finding and getting the software
near-automatic, I actually wouldn't mind splitting them out and
shipping a much smaller core distribution, perhaps with a script that
downloads the latest versions of what's in the standard library.
Debian did that for a while, with python-net, python-base,
python-text, &c.

I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the
binary, and install two packages of Elisp code (EFS and xemacs-base).
Then you run xemacs, do Options > Manage Packages > List and Install,
and you get a nice list containing GNUS, W3, programming language
modes, etc.  Pick the ones you want, it adds the ones needed by the
ones you selected, and it fetches and installs them.  Easy!  Now
imagine doing the same thing with Python modules.  Of course, we'd
have to design that feature first...

(ESR & Paul Prescod vs. AMK & GPW: the First Pythonic War! :) )

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
This is, after all, a book about reading, and the kind of reader I am
addressing does not care primarily about being in fashion.
  -- Robertson Davies, _A Voice from the Attic_



From DavidA@ActiveState.com  Tue Jun 20 19:16:40 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Tue, 20 Jun 2000 11:16:40 -0700
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEMCCNAA.mhammond@skippinet.com.au>
Message-ID: <PLEJJNOHDIGGLDPOGPJJCECJCJAA.DavidA@ActiveState.com>

> Peter:
>
> > Davids wrapper function implements a FIFO strategy for termination.
> > I think this is not desired.  Normally you want LIFO,
>
> Agreed.  LIFO is definately preferred IMO.

Agreed.  My wrapper was also from memory, and that was not at all the main
point of my post =).

--da



From akuchlin@mems-exchange.org  Tue Jun 20 19:17:47 2000
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 14:17:47 -0400
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
In-Reply-To: <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 20, 2000 at 08:18:03PM +0200
References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid>
Message-ID: <20000620141747.D3142@amarok.cnri.reston.va.us>

On Tue, Jun 20, 2000 at 08:18:03PM +0200, Fredrik Lundh quoted FLD:
>>   What is "sip"?  Is it defined by an RFC (which?), or Internet Draft
>> (which?  what's the expected activity?).

Is there a canonical list of all the defined URL types anywhere?  I
notice that 'ldap' isn't there, and maybe there are more missing.
(Some of the ones in there are marginal: who cares about Prospero?)

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
That's so obvious that someone has already got a patent on it.
  -- Guido van Rossum, 12 Jan 1999

 


From DavidA@ActiveState.com  Tue Jun 20 19:29:26 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Tue, 20 Jun 2000 11:29:26 -0700
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
In-Reply-To: <20000620141747.D3142@amarok.cnri.reston.va.us>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAECLCJAA.DavidA@ActiveState.com>

> Is there a canonical list of all the defined URL types anywhere?  I
> notice that 'ldap' isn't there, and maybe there are more missing.
> (Some of the ones in there are marginal: who cares about Prospero?)

Mozilla defines a bunch, which I doubt are RFC anything. (chrome://,
component://, etc.).

--david



From jeremy@beopen.com  Tue Jun 20 19:33:59 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Tue, 20 Jun 2000 14:33:59 -0400 (EDT)
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620140406.B3142@amarok.cnri.reston.va.us>
References: <20000609215719.47624E2673@oratrix.oratrix.nl>
 <20000609181924.A15728@thyrsus.com>
 <20000620083344.A3499@ludwig.cnri.reston.va.us>
 <20000620140419.C10038@thyrsus.com>
 <20000620140406.B3142@amarok.cnri.reston.va.us>
Message-ID: <14671.47383.313007.531923@localhost.localdomain>

>>>>> "AMK" == Andrew M Kuchling <akuchlin@cnri.reston.va.us> writes:

  AMK> I just compiled XEmacs 21.1.10 on a new Linux machine; you
  AMK> compile the binary, and install two packages of Elisp code (EFS
  AMK> and xemacs-base).  Then you run xemacs, do Options > Manage
  AMK> Packages > List and Install, and you get a nice list containing
  AMK> GNUS, W3, programming language modes, etc.  Pick the ones you
  AMK> want, it adds the ones needed by the ones you selected, and it
  AMK> fetches and installs them.  Easy!  Now imagine doing the same
  AMK> thing with Python modules.  Of course, we'd have to design that
  AMK> feature first...

I did the same install on my new Linux box last month.  I was
similarly pleased with the ease of installation.  Let's get working on
a design for this feature!

Jeremy


From Fredrik Lundh" <effbot@telia.com  Tue Jun 20 19:37:30 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 20:37:30 +0200
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us>
Message-ID: <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid>

amk wrote:
> Is there a canonical list of all the defined URL types anywhere?  I
> notice that 'ldap' isn't there, and maybe there are more missing.

your local search bot to the rescue:
http://www.isi.edu/in-notes/iana/assignments/url-schemes

(see http://www.iana.org/numbers.htm for a full list of things
they keep track of)

</F>



From akuchlin@mems-exchange.org  Tue Jun 20 19:44:40 2000
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 14:44:40 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <14671.47383.313007.531923@localhost.localdomain>; from jeremy@beopen.com on Tue, Jun 20, 2000 at 02:33:59PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> <14671.47383.313007.531923@localhost.localdomain>
Message-ID: <20000620144440.E3142@amarok.cnri.reston.va.us>

On Tue, Jun 20, 2000 at 02:33:59PM -0400, Jeremy Hylton wrote:
>I did the same install on my new Linux box last month.  I was
>similarly pleased with the ease of installation.  Let's get working on
>a design for this feature!

I have some notes on this, but they're at home.  I'll post them tonight.

--amk


From paul@prescod.net  Tue Jun 20 19:42:21 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 20 Jun 2000 13:42:21 -0500
Subject: [Python-Dev] RFC: Including PIL in 1.6
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us>
Message-ID: <394FBB0D.96D88DBB@prescod.net>

"Andrew M. Kuchling" wrote:
> 
> ...
> 
> I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the
> binary, and install two packages of Elisp code (EFS and xemacs-base).
> Then you run xemacs, do Options > Manage Packages > List and Install,
> and you get a nice list containing GNUS, W3, programming language
> modes, etc.  Pick the ones you want, it adds the ones needed by the
> ones you selected, and it fetches and installs them.  Easy!  Now
> imagine doing the same thing with Python modules.  Of course, we'd
> have to design that feature first...

Let me repeat that I don't think that the main issue is whether it lives
in this tarfile versus that tarfile. It's 

 a) about agreeing to keep everything comptible.
 b) about being able to depend on the thing being there when you write a
module.

*In theory* Red Hat linux could be a kernel, a shell and the RPM engine.
In practice, people like to be able to say: "if you have Red Hat version
X then such and such will work because it comes with a functional
package Y."

Distutils is extremely important for vertical modules but if we start to
use it as an excuse for leaving out core modules then I have to go with
ESR and say: "where do we stop?" 

Unicode on demand? re on demand? pickle on demand?

I think that the more relevant criteria are the ones we have always
used:

 * how big is it
 * how easy is it to maintain
 * how integrated is it with everything else
 * how well-thought-out is it
 * and most important: how many people want it?

I think that PIL is not yet a clear home run.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Music is the stuff between the notes." - Claude Debussy


From guido@python.org  Tue Jun 20 21:09:05 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 20 Jun 2000 15:09:05 -0500
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: Your message of "Tue, 20 Jun 2000 14:04:06 -0400."
 <20000620140406.B3142@amarok.cnri.reston.va.us>
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com>
 <20000620140406.B3142@amarok.cnri.reston.va.us>
Message-ID: <200006202009.PAA01064@cj20424-a.reston1.va.home.com>

> I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the
> binary, and install two packages of Elisp code (EFS and xemacs-base).
> Then you run xemacs, do Options > Manage Packages > List and Install,
> and you get a nice list containing GNUS, W3, programming language
> modes, etc.  Pick the ones you want, it adds the ones needed by the
> ones you selected, and it fetches and installs them.  Easy!  Now
> imagine doing the same thing with Python modules.  Of course, we'd
> have to design that feature first...

I just had to go through that process.  It was actually rather
painful, and I wouldn't have been able to succeed if it wasn't for
XEmax grandmaster Barry Warsaw standing next to me holding my hand for
a really long time...  The autofetcher appeared broken at first, then
had some unintuitive behavior next, before we finally got it running.
Finally I got the hang of it, but after that I still had about a week
where I occasionally used a familiar keystroke that triggered an
error, and usually it took an email to Barry to find out which package
contained the module defining the missing function.

Not to say that I'm against this kind of thing, but warning that even
in the best circumstances it can be a hurdle for newcomers...

Which is why there's a market for packagers like Red Hat.

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


From guido@python.org  Tue Jun 20 21:12:09 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 20 Jun 2000 15:12:09 -0500
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
In-Reply-To: Your message of "Tue, 20 Jun 2000 20:37:30 +0200."
 <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid>
References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us>
 <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid>
Message-ID: <200006202012.PAA01130@cj20424-a.reston1.va.home.com>

> > Is there a canonical list of all the defined URL types anywhere?  I
> > notice that 'ldap' isn't there, and maybe there are more missing.
> 
> your local search bot to the rescue:
> http://www.isi.edu/in-notes/iana/assignments/url-schemes

Of course now the trick is which ones are still relevant (as the
doubt expressed about prospero exemplify).

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


From fdrake@beopen.com  Tue Jun 20 20:10:31 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 20 Jun 2000 15:10:31 -0400 (EDT)
Subject: [Python-Dev] David Ascher's compile.py script?
Message-ID: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>

  Does anyone have a copy of David Ascher's compile.py from his
starship pages?  The links there appear to be broken, and David
appearantly hasn't been able to find time to look for a copy, or can't
find it (I've sent him another mail about it in case it has turned
up), and documentation users are asking about it.  (There's a link
from the extending & embedding manual.)
  If anyone has a copy, perhaps I could find provide a temporary
location for it and revise the link in the online documentation to
point there, as a stop-gap measure.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From nascheme@enme.ucalgary.ca  Tue Jun 20 20:18:03 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Tue, 20 Jun 2000 13:18:03 -0600
Subject: [Python-Dev] David Ascher's compile.py script?
In-Reply-To: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jun 20, 2000 at 03:10:31PM -0400
References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>
Message-ID: <20000620131803.A13811@acs.ucalgary.ca>

On Tue, Jun 20, 2000 at 03:10:31PM -0400, Fred L. Drake, Jr. wrote:
>   Does anyone have a copy of David Ascher's compile.py from his
> starship pages?

I don't know how recent this copy is:

    http://www.enme.ucalgary.ca/~nascheme/python/compile.py

  Neil


From fdrake@beopen.com  Tue Jun 20 20:19:05 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 20 Jun 2000 15:19:05 -0400 (EDT)
Subject: [Python-Dev] David Ascher's compile.py script?
In-Reply-To: <20000620131803.A13811@acs.ucalgary.ca>
References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>
 <20000620131803.A13811@acs.ucalgary.ca>
Message-ID: <14671.50089.860177.145255@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > I don't know how recent this copy is:
 > 
 >     http://www.enme.ucalgary.ca/~nascheme/python/compile.py

  Thanks!  If nothing else shows up within the next day, I'll use this
one.
  David, is this sufficiently recent?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From skip@mojam.com (Skip Montanaro)  Tue Jun 20 20:33:20 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Tue, 20 Jun 2000 14:33:20 -0500 (CDT)
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com>
References: <20000609215719.47624E2673@oratrix.oratrix.nl>
 <20000609181924.A15728@thyrsus.com>
 <20000620083344.A3499@ludwig.cnri.reston.va.us>
 <20000620140419.C10038@thyrsus.com>
 <20000620140406.B3142@amarok.cnri.reston.va.us>
 <200006202009.PAA01064@cj20424-a.reston1.va.home.com>
Message-ID: <14671.50944.796299.47756@beluga.mojam.com>

    Guido> I just had to go through that process.  It was actually rather
    Guido> painful ...

I will echo that sentiment.  Actually, the first time I upgraded to the
package stuff it went without a hitch.  The next time it took me awhile to
figure out why it didn't work.

I imagine it's just teething pain that will get worked out as the XEmacs
folks get more experience themselves, but auto-package install is definitely
something that would have to be pretty bulletproof.  I doubt the average
Python user will have a similar level of computer savvy as the average
XEmacs user.

On top of that, how will you know that you want package X until you download
it and try it out?  I presume that carried to its logical conclusion, a
package's documentation would be installed along with its source...

chicken-and-egg-ly y'rs,

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395


From paul@prescod.net  Tue Jun 20 21:09:18 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 20 Jun 2000 15:09:18 -0500
Subject: [Python-Dev] Argh...
Message-ID: <394FCF6E.85559D56@prescod.net>

Okay, this is blatantly off-topic. I'm trying to increase the noise
ratio so that people here will go back to comp.lang.python.

All I need is for someone to email me in private email what's the Java
equivalent of 

a=sys.argv[0]

(it's almost over, it's almost over, it's almost over)

Okay, here's an obPython: why doesn't the main module have an __file__
if it happens to be a file. I can understand why one piped in wouldn't
but the interpreter knows when the main module is a file.

-- 
 Paul Prescod
"Music is the stuff between the notes." - Claude Debussy


From guido@python.org  Tue Jun 20 22:31:00 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 20 Jun 2000 16:31:00 -0500
Subject: [Python-Dev] Argh...
In-Reply-To: Your message of "Tue, 20 Jun 2000 15:09:18 EST."
 <394FCF6E.85559D56@prescod.net>
References: <394FCF6E.85559D56@prescod.net>
Message-ID: <200006202131.QAA01631@cj20424-a.reston1.va.home.com>

> Okay, here's an obPython: why doesn't the main module have an __file__
> if it happens to be a file. I can understand why one piped in wouldn't
> but the interpreter knows when the main module is a file.

Mostly because it's tough to pass that information around all the way
to where it's needed.

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


From mhammond@skippinet.com.au  Wed Jun 21 00:06:57 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Wed, 21 Jun 2000 09:06:57 +1000
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBKENCCNAA.mhammond@skippinet.com.au>

[Guido]

> Not to say that I'm against this kind of thing, but warning that even
> in the best circumstances it can be a hurdle for newcomers...
>
> Which is why there's a market for packagers like Red Hat.

And even _then_ it is hard to get right.

My experience similar to this was with debian, and its xptselect package.
I was a Linux newbie, and the entire installation went pretty well until I
was asked which packages I want to fetch and install.

I was _soooo_ lost.  I found the interface a complete mystery.  It appeard
to make random selections of stuff I didnt want, then randomly de-select
stuff I didnt want.  I had no idea how to search for anything, and the help
was less than useful.  Sometimes it wanted to download nothing, other times
it wanted to download 400MB to complete the install!!!  I only just
resisted the temptation to go and buy a bunch of MS stock <wink>.

Of course, within a week, I understood what was going on, and the sofware
was indeed functioning correctly.

But it took me that entire week to have a Linux system with everything I
wanted installed and working correctly.

The point I am trying to make is that for stuff that should be considered
"core", the bar is very very high for these auto-configure applications.
The usual audience will be _complete_ newbies.  In my example, it was clear
that a complete linux newbie was never let loose on this program while
sitting in the same room as the author or the marketting team ;-)  But I
expect those with reasonable Linux experience quite like it, and themselves
would not be happy with the complete-newbie version.

The-included-batteries-were-the-wrong-size-ly,

Mark.



From Vladimir.Marangozov@inrialpes.fr  Wed Jun 21 00:34:31 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Wed, 21 Jun 2000 01:34:31 +0200 (CEST)
Subject: [Python-Dev] Fw: Access violation when no memory
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au> from "Mark Hammond" at Jun 20, 2000 09:42:53 PM
Message-ID: <200006202334.BAA03150@python.inrialpes.fr>

Mark Hammond wrote:
> 
> >From the newsgroup.  Any thoughts?
> 
> Mark.
> 
> "Phil Mayes" <nospam@bitbucket.com> wrote in message
> news:<olD35.82$_%.4481@newsfeed.avtel.net>...
> > The following program progressively allocates all memory:
> >     size = 1 << 20
> >     list = [None,]
> >     while size:
> >         try:
> >             mem = [None] * size
> >             mem[0] = list
> >             list = mem
> >         except:
> >             size = size / 2
> >
> > It fails with an access violation.

The only immediate thought I have is that Python does not have builtin
emergency procedures for such extreme situations. Although there are some
safety checks, it is fairly easy to crash the interpreter in a number of
ways.

For example, with the introduction of the mmapmodule, there are even more
"risks", like managing to mmap the python executable and screw it up
completely (not speaking of the possibility to introduce Trojan horses
and similar if this is done on purpose). There would probably be more
checks, but complete safety is hard to achieve in the current state.

The proposed solution is not a solution. The example program dumps core
in different locations on my machine. We just do not have enough control
from Python for managing such extreme cases. Sad, but true...

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From akuchlin@mems-exchange.org  Wed Jun 21 02:46:43 2000
From: akuchlin@mems-exchange.org (A.M. Kuchling)
Date: Tue, 20 Jun 2000 21:46:43 -0400
Subject: [Python-Dev] Installation requirements
Message-ID: <200006210146.VAA01220@207-172-37-166.s166.tnt7.ann.va.dialup.rcn.com>

[Follow-up to the Distutils SIG, please.]

There are a few steps needed to find and install a package:
1) Discovery : which module does what I need?
2) Download  : where can I get a copy?
3) Security  : is this actually from the package author, and not a Trojan?
4) Installation : how do I set it up?
5) Checking for new versions: I have 1.0 installed; is a newer version 
   available?

Distutils focuses on the hardest and most complicated step, #4.  

For #1, you would need to browse through a list of available packages,
browse through a hierarchy like Parnassus, or do keyword searches.

#2 is pretty simple, since you just get one or more download URLs
corresponding to a given package name, using the same database as in
#1.

For #3, you'd have to check a signature on the downloaded package,
using something external like GnuPG.  This means this step has to be
skipped if the external tool isn't available.  We could implement our
own signature scheme with Python code, but that's a bad idea; security
is hard, and few people will bother to generate keys that are only
useful for this one application of distributing Python modules.  (Side
note: the sdist and bdist_* commands should have a --sign switch to
sign the generated .tgz, .rpm, or whatever file.)

For #5, the existing stuff in Tools/versioncheck might be partially
applicable, though it requires that every package have a text file
somewhere which gives the latest version.  You'd want to use the same
database for everything, to ensure that people actually use it!

To start off with, we'd need some sort of generic API to the above
functions, so that different interfaces can be written.  A
command-line interface would then be easiest.

I don't know how network communications should be handled: HTTP to CGI
scripts that return sets of RFC-822 headers, maybe?  Combined with a
DNS alias like modules.python.org, or modules.{us,uk,...}.python.org?

Some potential sources of inspiration:

Debian: apt
Perl: CPAM.pm
FreeBSD: ports system
RPMfind (rpmfind.net)
XEmacs: packages system

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
  "Jo, it's a pity escapology wasn't part of your curriculum."
  "Funny you should say that. Look." <shows untied hand>
  -- The Doctor and Jo, tied up, in "Terror of the Autons"


From tim_one@email.msn.com  Wed Jun 21 04:44:18 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 20 Jun 2000 23:44:18 -0400
Subject: [Python-Dev] talking about performance...
In-Reply-To: <002001bfdae1$b28942e0$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEDPGFAA.tim_one@email.msn.com>

[posted & mailed]

[Fredrik Lundh]
> how about this one:
>
>     if (dir > 0) {
>         char *p, *e;
>         if (n == 0 && i <= last)
>             return (long)i;
>         e = s + last - n + 1;
>         for (;;) {
>             p = memchr(s, sub[0], e - s);
>             if (p == NULL)
>                 break;
>             if (n == 1 || memcmp(p, sub, n) == 0)
>                 return (long) (p - s);
>             s = p + 1;
>         }
>     }
>
> new record time: 1.6 seconds (down from 2.2)

I expect that whether this is faster or slower depends on both the compiler
you're using and the exact strings you're using to time it.

In any case, it appears to be incorrect:  p & s both change inside the
infinite loop, and the innermost return computes their difference.  Surely
it should be returning the difference between p and the value s had *before*
the loop was entered.  If this passed your tests, then, it suggests you had
no "false hits" (i.e., that the inner loop returned on its first iteration,
else the return value would have been wrong), which are probably the cases
in which using memchr rather than the current code is least likely to slow
things down.

It's bad that the original code never bothered to document what it's
supposed to return, but that's no excuse to return probabilistically-correct
gibberish <wink>.




From tim_one@email.msn.com  Wed Jun 21 04:44:25 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 20 Jun 2000 23:44:25 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <20000620132150.O8678@thyrsus.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>

[Ka-Ping Yee]
> I just have to say i thought list comprehensions were
> really cool.

[Eric S. Raymond]
> Ditto.  I would like to see this in 1.6.

Nobody has been more vocal in support of these (& augmented assignments)
than me, but I very strongly doubt they'll be in 1.6.  In the interests of
getting that out the door, Guido considers the 1.6 feature set to be frozen
already.

I think part of the pressure to get one more feature in Python (again &
again & again) is that release cycles have been soooooo protracted, now
slobbering well over the full year mark.  If I accomplish nothing else at
BeOpen, I want to give that a major speed boost -- I don't think we should
ever let 6 months go by without at least pumping out a bugfix release.

there-are-other-things-guido-doesn't-yet-know-he-believes-too<wink>-ly
    y'rs  - tim




From skip@mojam.com (Skip Montanaro)  Wed Jun 21 05:33:12 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Tue, 20 Jun 2000 23:33:12 -0500 (CDT)
Subject: [Python-Dev] feeble attempt at list comprehensions doc...
Message-ID: <14672.17800.994102.266619@beluga.mojam.com>

--R/cQMyfgKa
Content-Type: text/plain; charset=us-ascii
Content-Description: message body and .signature
Content-Transfer-Encoding: 7bit


Attached to this message are two patches, one for Doc/ref/ref5.tex and one
for Doc/tut/tut.tex.  They provide minimal documentation for list
comprehensions.  I'm sure just about anyone else could do better.  Feel free 
to embellish.

The BNF used in the reference manual doesn't seem to match the BNF in the
Grammar file very well, so I'm not even certain I have the correct BNF or
have it in the correct place.  In particular, I'm pretty sure the
BNF for list_for and list_if are incorrect.

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395


--R/cQMyfgKa
Content-Type: application/octet-stream
Content-Description: list comprehension diffs
Content-Disposition: attachment;
	filename="tut.diff"
Content-Transfer-Encoding: base64

KioqIC90bXAvdHV0LnRleC5+MS4xMDd+CVR1ZSBKdW4gMjAgMjM6MjY6MzggMjAwMAotLS0g
L3RtcC90dXQudGV4CVR1ZSBKdW4gMjAgMjM6MjY6MzggMjAwMAoqKioqKioqKioqKioqKioK
KioqIDE3NTIsMTc1NyAqKioqCi0tLSAxNzUyLDE3NzggLS0tLQogIDAKICBcZW5ke3ZlcmJh
dGltfQogIAorIFxzdWJzZWN0aW9ue0xpc3QgQ29tcHJlaGVuc2lvbnN9CisgCisgTGlzdCBj
b21wcmVoZW5zaW9ucyBwcm92aWRlIGEgY29uY2lzZSB3YXkgdG8gY3JlYXRlIGxpc3RzIHdp
dGhvdXQgcmVzb3J0aW5nCisgdG8gdXNlIG9mIHRoZSBcZnVuY3ttYXAoKX0gb3IgXGZ1bmN7
ZmlsdGVyKCl9IGZ1bmN0aW9ucy4gIFRoZSByZXN1bHRpbmcKKyBjb25zdHJ1Y3QgdGVuZHMg
b2Z0ZW4gdG8gYmUgY2xlYXJlciB0aGFuIHVzZSBvZiB0aG9zZSBmdW5jdGlvbnMuCisgCisg
XGJlZ2lue3ZlcmJhdGltfQorID4+PiBzcGNzID0gWyIgIEFwcGxlIiwgIiBCYW5hbmEgIiwg
IkNvY28gIG51dCAgIl0KKyA+Pj4gcHJpbnQgW3Muc3RyaXAoKSBmb3IgcyBpbiBzcGNzXQor
IFsnQXBwbGUnLCAnQmFuYW5hJywgJ0NvY28gIG51dCddCisgPj4+IHZlYyA9IFsyLCA0LCA2
XQorID4+PiBwcmludCBbMyp4IGZvciB4IGluIHZlY10KKyBbNiwgMTIsIDE4XQorID4+PiB2
ZWMxID0gWzIsIDQsIDZdCisgPj4+IHZlYzIgPSBbNCwgMywgLTldCisgPj4+IHByaW50IFt4
KnkgZm9yIHggaW4gdmVjMSBmb3IgeSBpbiB2ZWMyXQorIFs4LCA2LCAtMTgsIDE2LCAxMiwg
LTM2LCAyNCwgMTgsIC01NF0KKyA+Pj4gcHJpbnQgW3greSBmb3IgeCBpbiB2ZWMxIGZvciB5
IGluIHZlYzJdCisgWzYsIDUsIC03LCA4LCA3LCAtNSwgMTAsIDksIC0zXQorIFxlbmR7dmVy
YmF0aW19CisgCiAgXHNlY3Rpb257VGhlIFxrZXl3b3Jke2RlbH0gc3RhdGVtZW50IFxsYWJl
bHtkZWx9fQogIAogIFRoZXJlIGlzIGEgd2F5IHRvIHJlbW92ZSBhbiBpdGVtIGZyb20gYSBs
aXN0IGdpdmVuIGl0cyBpbmRleCBpbnN0ZWFkCg==

--R/cQMyfgKa
Content-Type: application/octet-stream
Content-Description: reference manual diff
Content-Disposition: attachment;
	filename="ref5.diff"
Content-Transfer-Encoding: base64

KioqIC90bXAvcmVmNS50ZXgufjEuMjl+CVR1ZSBKdW4gMjAgMjM6Mjc6MTQgMjAwMAotLS0g
L3RtcC9yZWY1LnRleAlUdWUgSnVuIDIwIDIzOjI3OjE0IDIwMDAKKioqKioqKioqKioqKioq
CioqKiAxNTIsMTY0ICoqKioKICBzcXVhcmUgYnJhY2tldHM6CiAgCiAgXGJlZ2lue3ZlcmJh
dGltfQohIGxpc3RfZGlzcGxheTogICAiWyIgW2V4cHJlc3Npb25fbGlzdF0gIl0iCiAgXGVu
ZHt2ZXJiYXRpbX0KICAKICBBIGxpc3QgZGlzcGxheSB5aWVsZHMgYSBuZXcgbGlzdCBvYmpl
Y3QuICBJZiBpdCBoYXMgbm8gZXhwcmVzc2lvbgogIGxpc3QsIHRoZSBsaXN0IG9iamVjdCBo
YXMgbm8gaXRlbXMuICBPdGhlcndpc2UsIHRoZSBlbGVtZW50cyBvZiB0aGUKICBleHByZXNz
aW9uIGxpc3QgYXJlIGV2YWx1YXRlZCBmcm9tIGxlZnQgdG8gcmlnaHQgYW5kIGluc2VydGVk
IGluIHRoZQohIGxpc3Qgb2JqZWN0IGluIHRoYXQgb3JkZXIuCiAgXG9iaW5kZXh7bGlzdH0K
ICBcaW5kZXhpaXtlbXB0eX17bGlzdH0KICAKLS0tIDE1MiwxNjkgLS0tLQogIHNxdWFyZSBi
cmFja2V0czoKICAKICBcYmVnaW57dmVyYmF0aW19CiEgbGlzdF9kaXNwbGF5OiAgICJbIiBb
ZXhwcmVzc2lvbl9saXN0IFtsaXN0X2l0ZXJdXSAiXSIKISBsaXN0X2l0ZXI6ICAgbGlzdF9m
b3IgfCBsaXN0X2lmCiEgbGlzdF9mb3I6ICAgICJmb3IiIGV4cHJlc3Npb25fbGlzdCAiaW4i
IHRlc3RsaXN0IFtsaXN0X2l0ZXJdCiEgbGlzdF9pZjogICAgICJpZiIgdGVzdCBbbGlzdF9p
dGVyXQogIFxlbmR7dmVyYmF0aW19CiAgCiAgQSBsaXN0IGRpc3BsYXkgeWllbGRzIGEgbmV3
IGxpc3Qgb2JqZWN0LiAgSWYgaXQgaGFzIG5vIGV4cHJlc3Npb24KICBsaXN0LCB0aGUgbGlz
dCBvYmplY3QgaGFzIG5vIGl0ZW1zLiAgT3RoZXJ3aXNlLCB0aGUgZWxlbWVudHMgb2YgdGhl
CiAgZXhwcmVzc2lvbiBsaXN0IGFyZSBldmFsdWF0ZWQgZnJvbSBsZWZ0IHRvIHJpZ2h0IGFu
ZCBpbnNlcnRlZCBpbiB0aGUKISBsaXN0IG9iamVjdCBpbiB0aGF0IG9yZGVyLiBMaXN0IGNv
bXByZWhlbnNpb25zIGRlZmluZSBjb25kaXRpb25hbAohIGV4cHJlc3Npb25zIHVzZWQgdG8g
ZGVmaW5lIGxpc3RzLgohIAogIFxvYmluZGV4e2xpc3R9CiAgXGluZGV4aWl7ZW1wdHl9e2xp
c3R9CiAgCg==

--R/cQMyfgKa--


From tim_one@email.msn.com  Wed Jun 21 05:53:59 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 21 Jun 2000 00:53:59 -0400
Subject: [Python-Dev] Warnings in mmapmodule
Message-ID: <LNBBLJKPBEHFEDALKOLCOEEDGFAA.tim_one@email.msn.com>

I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
mismatches:

Modules\mmapmodule.c(571) : warning C4018: '>=' : signed/unsigned mismatch
	if (i < 0 || i >= self->size) {
Modules\mmapmodule.c(586) : warning C4018: '>' : signed/unsigned mismatch
	else if (ilow > self->size)
Modules\mmapmodule.c(592) : warning C4018: '>' : signed/unsigned mismatch
	else if (ihigh > self->size)
Modules\mmapmodule.c(631) : warning C4018: '>' : signed/unsigned mismatch
	else if (ilow > self->size)
Modules\mmapmodule.c(637) : warning C4018: '>' : signed/unsigned mismatch
	else if (ihigh > self->size)
Modules\mmapmodule.c(664) : warning C4018: '>=' : signed/unsigned mismatch
	if (i < 0 || i >= self->size) {

I'll volunteer to fix these if nobody else does (although at the moment I'm
not able to produce either a patch or check in).

new-laptops-in-hotel-rooms-have-their-limitations-ly y'rs  - tim




From mhammond@skippinet.com.au  Wed Jun 21 05:57:54 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Wed, 21 Jun 2000 14:57:54 +1000
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEEDGFAA.tim_one@email.msn.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEOACNAA.mhammond@skippinet.com.au>

> I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
> mismatches:

Me too :-)

> I'll volunteer to fix these if nobody else does (although at the
> moment I'm
> not able to produce either a patch or check in).

I nearly did, but then couldnt find the time to chase up how Unix declared
the relevant items - I didnt want to assume they were identical to Windows.

My intention was to make the patch, then test it out on my gleaming Linux
box.

But-the-road-to-hell-is-paved-with-good-intentions-ly,

Mark.



From tim_one@email.msn.com  Wed Jun 21 06:22:37 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 21 Jun 2000 01:22:37 -0400
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBIEOACNAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>

[posted & mailed]

[Tim]
> I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
> mismatches:

[Mark Hammond]
> Me too :-)
>
> I nearly [fixed them], but then couldnt find the time to chase up how
> Unix declared the relevant items - I didnt want to assume they were
> identical to Windows.

They all involve mixing ints with mmap_object.size in comparisons, which
latter is declared size_t and so will resolve to *some* unsigned integral
type on all platforms.  The proper fix is to get rid of the ints before
making these tests -- ask Trent, he should be able to do this in his sleep
now <wink>.

> My intention was to make the patch, then test it out on my gleaming Linux
> box.
>
> But-the-road-to-hell-is-paved-with-good-intentions-ly,

No, it's paved with Linux:  I've been using Windows so long I forgot why
Unix is supposed to be more usable <0.9 wink>.  Mark, if you've figured out
how to do a SourceForge checkin from a Windows box, drop me a line offline!
It would save me from figuring out which one of the 10,000 SSH+Windows
search hits actually leads to something that works (and, no, so long as my
entire life is sitting on my laptop, I'm not getting another OS anywhere
near this box).

becoming-a-linux-true-believer-again-is-on-my-schedule-but-not-
    for-a-couple-months-ly y'rs  - tim




From DavidA@ActiveState.com  Wed Jun 21 06:40:36 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Tue, 20 Jun 2000 22:40:36 -0700
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>
Message-ID: <LMBBIEIJKMPMLBONJMFCIEBLCJAA.DavidA@ActiveState.com>

> No, it's paved with Linux:  I've been using Windows so long I forgot why
> Unix is supposed to be more usable <0.9 wink>.  Mark, if you've
> figured out
> how to do a SourceForge checkin from a Windows box, drop me a
> line offline!

No, please, drop us all a line online!  I've decided that I'm not going to
waste any more of my time dealing w/ SourceForge.  Luckily I seem to have
found some helpers for the PyOpenGL transition who are willing to deal with
that!

--david



From mhammond@skippinet.com.au  Wed Jun 21 06:49:45 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Wed, 21 Jun 2000 15:49:45 +1000
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <LMBBIEIJKMPMLBONJMFCIEBLCJAA.DavidA@ActiveState.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au>

[David]
> No, please, drop us all a line online!

OK - here it is, for what it is worth.  You will notice that I spent the
time to research my facts carefully before giving out this information
(NOT!)

Sure.  It is a bit of a PITA (surprise, surprise, surprise):

First, get the latest WinCVS.  Has some nice new features.  Mine shows as
1.1b13.  It has a slightly “slicker” more windowsy look than the older one.
What we really want is the version with the Options/Preferences dialog that
allows you to supply the “RAS identity” file when you select “SSH Server”
as the auth method.  Previous versions allow you to select the SSH Server,
but give you nowhere to put the identity file.  Hence previous versions
used a batch file wrapper, which you probably saw reference to.  This
version makes it much simpler.

I use the standard SSH Version 1.2.14 binary set.  I cant recall the URL,
but it is quite small and only a few binary files.  “ssh” shows usage -
“ssh -v” shows versbose usage, “verbose” in this context apparently means
showing the version number (took me ages to work that one out :-)

There were only a few files, so I just dumped them all in the same
directory as the CVS binaries.

You then need to make a “key” file - I cant recall the exact process, but
it is pretty simple.  This is creating the identify file you specify to
WinCVS, as well as the public key you upload to source-force.

NOTE - from memory, you MUST have a HOME env var set, and you MUST have a
“.ssh” directory under your home.  Otherwise you get cryptic errors from
SSH that give no clue that this is the problem.

After uploading the public key to source forge, you are nearly set.  The
last step is convinving CVS that you want to use this new SSH setting, and
not the setting CVS so kindly persists in its “CVS\Root” files.  The only
way I found to do this was to either edit the Root files manually, or
remove the directories locally and force CVS to re-create them (and thereby
re-pull everything - I assume you have ADSL in that hotel room :-)
Alternatively, dig up that CVS script posted to py-dev recently and change
it - personally, I never trusted it :-)

All my root files look like:
:ext:mhammond@cvs.python.sourceforge.net:/cvsroot/python

Yours almost certainly will be setup for anon access, not using ssh.

Hope that makes sense.  Im happy to chase anything else up I can for you...

Mark.



From Fredrik Lundh" <effbot@telia.com  Wed Jun 21 08:58:06 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Wed, 21 Jun 2000 09:58:06 +0200
Subject: [Python-Dev] talking about performance...
References: <LNBBLJKPBEHFEDALKOLCAEDPGFAA.tim_one@email.msn.com>
Message-ID: <006401bfdb56$6f84ae60$f2a6b5d4@hagrid>

tim wrote:

> >             p =3D memchr(s, sub[0], e - s);
> >             if (p =3D=3D NULL)
> >                 break;
> >             if (n =3D=3D 1 || memcmp(p, sub, n) =3D=3D 0)
> >                 return (long) (p - s);

> I expect that whether this is faster or slower depends on both the =
compiler
> you're using and the exact strings you're using to time it.

With test strings that contain false matches for every single
position, it's 30% slower than the old code in my tests.  With
test strings that contain no false matches, it's 50% faster.

But without more extensive tests on a variety of platforms, we
might as well forget about this one...

</F>



From mal@lemburg.com  Wed Jun 21 09:23:02 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Jun 2000 10:23:02 +0200
Subject: [Python-Dev] Proposal: standard way of defining and executing
 "atexit" functions...
References: <PLEJJNOHDIGGLDPOGPJJCECJCJAA.DavidA@ActiveState.com>
Message-ID: <39507B66.763DB418@lemburg.com>

[Skip's exit.py module + David's extension to support already
 registered exitfunc'tions]

Looks like everyone agrees -- with a final word from Guido
we'd only need some docs to go with it and then check Skip's
module in as new standard module.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From skip@mojam.com (Skip Montanaro)  Wed Jun 21 14:38:01 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Wed, 21 Jun 2000 08:38:01 -0500 (CDT)
Subject: [Python-Dev] Proposal: standard way of defining and executing
 "atexit" functions...
In-Reply-To: <39507B66.763DB418@lemburg.com>
References: <PLEJJNOHDIGGLDPOGPJJCECJCJAA.DavidA@ActiveState.com>
 <39507B66.763DB418@lemburg.com>
Message-ID: <14672.50489.611301.616242@beluga.mojam.com>

    MA> Looks like everyone agrees -- with a final word from Guido we'd only
    MA> need some docs to go with it and then check Skip's module in as new
    MA> standard module.

I'll try to get David's enhancement added to my code and write some simple
documentation today.  Is "exit.py" acceptable with everyone as the name of
the module?

Skip


From skip@mojam.com (Skip Montanaro)  Wed Jun 21 19:15:19 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Wed, 21 Jun 2000 13:15:19 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
Message-ID: <14673.1591.506532.170015@beluga.mojam.com>

--tqfUNARIjv
Content-Type: text/plain; charset=us-ascii
Content-Description: message body and .signature
Content-Transfer-Encoding: 7bit

This message contains four attached files:

    Lib/exit.py	- a module that allows users to register cleanup functions
    Lib/test/test_exit.py - a simple test script
    Lib/test/output/test_exit - expected test output
    Doc/lib/libexit.tex - library reference manual section

Besides adding documentation and a test script, the following two mods were
made to exit.py since I previously posted it:

    1. It implements a LIFO execution order
    2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is 
       treated as an exit function and appended to the exit function list.

Comments, please.  Also, can someone tell me how to coax CVS into creating a 
unified diff that actually contains new files?  I tried

    cvs diff -RNau

without success.

Thanks,

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395


--tqfUNARIjv
Content-Type: text/plain
Content-Description: Lib/exit.py
Content-Disposition: inline;
	filename="exit.py"
Content-Transfer-Encoding: 7bit

"""
exit.py - allow programmer to define multiple exit functions to be executed
upon normal program termination.

One public function, register_exitfunc, is defined.  
"""

_exithandlers = []
def _run_exitfuncs():
    """run any registered exit functions

    _exithandlers is traversed in reverse order so functions are executed
    last in, first out.
    """
    
    while _exithandlers:
        func, targs, kargs = _exithandlers[-1]
        apply(func, targs, kargs)
        _exithandlers.remove(_exithandlers[-1])

def register_exitfunc(func, *targs, **kargs):
    """register a function to be executed upon normal program termination

    func - function to be called at exit
    targs - optional arguments to pass to func
    kargs - optional keyword arguments to pass to func
    """
    _exithandlers.append((func, targs, kargs))

import sys
try:
    x = sys.exitfunc
except AttributeError:
    sys.exitfunc = _run_exitfuncs
else:
    # if x isn't our own exit func executive, assume it's another
    # registered exit function - append it to our list...
    if x != _run_exitfuncs:
        register_exitfunc(x)
del sys

if __name__ == "__main__":
    def x1():
        print "running x1"
    def x2(n):
        print "running x2(%s)" % `n`
    def x3(n, kwd=None):
        print "running x3(%s, kwd=%s)" % (`n`, `kwd`)

    register_exitfunc(x1)
    register_exitfunc(x2, 12)
    register_exitfunc(x3, 5, "bar")
    register_exitfunc(x3, "no kwd args")


--tqfUNARIjv
Content-Type: text/plain
Content-Description: Lib/test/test_exit.py
Content-Disposition: inline;
	filename="test_exit.py"
Content-Transfer-Encoding: 7bit

# Test the exit module
from test_support import verbose
import exit

def handler1():
    print "handler1"

def handler2(*args, **kargs):
    print "handler2", args, kargs

# save any exit functions that may have been registered as part of the
# test framework
_exithandlers = exit._exithandlers
exit._exithandlers = []

exit.register_exitfunc(handler1)
exit.register_exitfunc(handler2)
exit.register_exitfunc(handler2, 7, kw="abc")

# simulate exit behavior by calling exit._run_exitfuncs directly...
exit._run_exitfuncs()

# restore exit handlers
exit._exithandlers = _exithandlers

--tqfUNARIjv
Content-Type: text/plain
Content-Description: Lib/test/output/test_exit
Content-Disposition: inline;
	filename="test_exit"
Content-Transfer-Encoding: 7bit

test_exit
handler2 (7,) {'kw': 'abc'}
handler2 () {}
handler1

--tqfUNARIjv
Content-Type: text/plain
Content-Description: Doc/lib/libexit.tex
Content-Disposition: inline;
	filename="libexit.tex"
Content-Transfer-Encoding: 7bit

\section{\module{exit} ---
         exit handlers}

\declaremodule{standard}{exit}
\sectionauthor{Skip Montanaro}{skip@mojam.com}
\modulesynopsis{Register and execute cleanup functions.}

The \module{exit} module defines a single function to register cleanup
functions.  Functions thus registered are automatically executed upon normal
interpreter termination.

\begin{funcdesc}{register_exitfunc}{func\optional{, *args\optional{,
**kargs}}} Register \code{func} as a function to be executed at termination.
Any optional arguments that are to be passed to func must be passed as
arguments to
\func{register_exitfunc}. 

At normal program termination (for instance, if \func{sys.exit} is called or
the main module's execution completes), all functions registered are called
in last in, first out order.  The assumption is that lower level modules
will normally be imported before higher level modules and thus must be
cleaned up later.

\subsection{Example}

The following simple example demonstrates how a module can initialize a
counter from a file when it is imported and save the counter's updated value
automatically when the program terminates.

\begin{verbatim}
try:
    _count = eval(open("/tmp/counter").read())
except IOError:
    _count = 0

def incrcounter(n):
    global _count
    _count = _count + n

def savecounter():
    open("/tmp/counter", "w").write("%d" % _count)

import exit
exit.register_exitfunc(savecounter)
\end{verbatim}


--tqfUNARIjv--


From trentm@activestate.com  Wed Jun 21 20:20:12 2000
From: trentm@activestate.com (Trent Mick)
Date: Wed, 21 Jun 2000 12:20:12 -0700
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>
References: <ECEPKNMJLHAPFFJHDOJBIEOACNAA.mhammond@skippinet.com.au> <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>
Message-ID: <20000621122012.A28236@activestate.com>

On Wed, Jun 21, 2000 at 01:22:37AM -0400, Tim Peters wrote:
> [posted & mailed]
> 
> [Tim]
> > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
> > mismatches:
> 
> [Mark Hammond]
> > Me too :-)
> >
> > I nearly [fixed them], but then couldnt find the time to chase up how
> > Unix declared the relevant items - I didnt want to assume they were
> > identical to Windows.
> 
> They all involve mixing ints with mmap_object.size in comparisons, which
> latter is declared size_t and so will resolve to *some* unsigned integral
> type on all platforms.  The proper fix is to get rid of the ints before
> making these tests -- ask Trent, he should be able to do this in his sleep
> now <wink>.
> 

I wish I could do it in my sleep, then I would be much more well rested. Yes
I will clean these up. I was going to look at mmap a little anyway as
test_mmap currently fails on Win32 (probably as a resul of my mmpa patch).

Trent


-- 
Trent Mick
trentm@activestate.com


From DavidA@ActiveState.com  Wed Jun 21 18:25:07 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Wed, 21 Jun 2000 10:25:07 -0700
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>

> First, get the latest WinCVS.

	http://www.wincvs.org/download.html

> I use the standard SSH Version 1.2.14 binary set.  I cant recall the URL,

There's a version at:

      ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip

BUT...

> You then need to make a “key” file - I cant recall the exact process, but
> it is pretty simple.  This is creating the identify file you specify to
> WinCVS, as well as the public key you upload to source-force.

	C:\WinCVS>ssh-keygen

I always get a 'gethostname: no such file or directory' so I had to create
the key on Linux (as is mentioned in the page
http://bmrc.berkeley.edu/people/chaffee/winntutil.html).

Maybe you have a better binary for ssh?

> NOTE - from memory, you MUST have a HOME env var set, and you MUST have a
> “.ssh” directory under your home.  Otherwise you get cryptic errors from
> SSH that give no clue that this is the problem.
>
> After uploading the public key to source forge, you are nearly set.

How do you do that?

> The
> last step is convinving CVS that you want to use this new SSH setting, and
> not the setting CVS so kindly persists in its “CVS\Root” files.  The only
> way I found to do this was to either edit the Root files manually, or
> remove the directories locally and force CVS to re-create them
> (and thereby
> re-pull everything - I assume you have ADSL in that hotel room :-)
> Alternatively, dig up that CVS script posted to py-dev recently and change
> it - personally, I never trusted it :-)
>
> All my root files look like:
> :ext:mhammond@cvs.python.sourceforge.net:/cvsroot/python
>
> Yours almost certainly will be setup for anon access, not using ssh.
>
> Hope that makes sense.  Im happy to chase anything else up I can
> for you...
>
> Mark.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev
>



From akuchlin@mems-exchange.org  Wed Jun 21 21:27:31 2000
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Wed, 21 Jun 2000 16:27:31 -0400
Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400
References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEGHGFAA.tim_one@email.msn.com> <14673.158.183876.75480@localhost.localdomain>
Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us>

On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote:
>>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:
>  TP> + This mailing list doesn't work.  At least the SourceForge
>I agree that it's a complete mess, though.

While you're all admiring the difficulty of the problem, how about
actually checking in the pythonrun.c patch, assuming it's reasonable?

<flame> 

Frankly, I don't think the current mailing list is broken, *as long as
patches are handled with reasonable speed* so that the backlog doesn't
build up.  That hasn't been done, and I don't understand why.
Obviously the CNRI->BeOpen transaction resulted in some downtime for
everyone, but now it's a month later and there's still stagnation.
Why aren't incoming patches being handled now?  It's not like there
are very many patches per day; an hour or two should suffice to keep
the queue from growing.

At this point, the best fix is to do two things:

1) Someone downloads the mbox archives of the patches list, and goes
through all the past patches: apply them, discard them, send them back
for revision.

2) Commit to handling new patches that arrive, and either
apply/discard/revise them.

Worrying about patch management mechanism, while more patches pile up
and are ignored in the meantime, is not going to help and will just
results in continued stagnation.  
</flame>

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I couldn't think of one clever way to stop this guy, so I just trusted to
mindless violence.
  -- Cliff Steele in DOOM PATROL #21



From akuchlin@mems-exchange.org  Wed Jun 21 21:27:31 2000
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Wed, 21 Jun 2000 16:27:31 -0400
Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400
References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEGHGFAA.tim_one@email.msn.com> <14673.158.183876.75480@localhost.localdomain>
Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us>

On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote:
>>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:
>  TP> + This mailing list doesn't work.  At least the SourceForge
>I agree that it's a complete mess, though.

While you're all admiring the difficulty of the problem, how about
actually checking in the pythonrun.c patch, assuming it's reasonable?

<flame> 

Frankly, I don't think the current mailing list is broken, *as long as
patches are handled with reasonable speed* so that the backlog doesn't
build up.  That hasn't been done, and I don't understand why.
Obviously the CNRI->BeOpen transaction resulted in some downtime for
everyone, but now it's a month later and there's still stagnation.
Why aren't incoming patches being handled now?  It's not like there
are very many patches per day; an hour or two should suffice to keep
the queue from growing.

At this point, the best fix is to do two things:

1) Someone downloads the mbox archives of the patches list, and goes
through all the past patches: apply them, discard them, send them back
for revision.

2) Commit to handling new patches that arrive, and either
apply/discard/revise them.

Worrying about patch management mechanism, while more patches pile up
and are ignored in the meantime, is not going to help and will just
results in continued stagnation.  
</flame>

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I couldn't think of one clever way to stop this guy, so I just trusted to
mindless violence.
  -- Cliff Steele in DOOM PATROL #21



From akuchlin@mems-exchange.org  Wed Jun 21 21:27:31 2000
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Wed, 21 Jun 2000 16:27:31 -0400
Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400
References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEGHGFAA.tim_one@email.msn.com> <14673.158.183876.75480@localhost.localdomain>
Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us>

On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote:
>>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:
>  TP> + This mailing list doesn't work.  At least the SourceForge
>I agree that it's a complete mess, though.

While you're all admiring the difficulty of the problem, how about
actually checking in the pythonrun.c patch, assuming it's reasonable?

<flame> 

Frankly, I don't think the current mailing list is broken, *as long as
patches are handled with reasonable speed* so that the backlog doesn't
build up.  That hasn't been done, and I don't understand why.
Obviously the CNRI->BeOpen transaction resulted in some downtime for
everyone, but now it's a month later and there's still stagnation.
Why aren't incoming patches being handled now?  It's not like there
are very many patches per day; an hour or two should suffice to keep
the queue from growing.

At this point, the best fix is to do two things:

1) Someone downloads the mbox archives of the patches list, and goes
through all the past patches: apply them, discard them, send them back
for revision.

2) Commit to handling new patches that arrive, and either
apply/discard/revise them.

Worrying about patch management mechanism, while more patches pile up
and are ignored in the meantime, is not going to help and will just
results in continued stagnation.  
</flame>

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I couldn't think of one clever way to stop this guy, so I just trusted to
mindless violence.
  -- Cliff Steele in DOOM PATROL #21



From guido@python.org  Wed Jun 21 23:55:22 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 21 Jun 2000 17:55:22 -0500
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: Your message of "Wed, 21 Jun 2000 13:15:19 EST."
 <14673.1591.506532.170015@beluga.mojam.com>
References: <14673.1591.506532.170015@beluga.mojam.com>
Message-ID: <200006212255.RAA02444@cj20424-a.reston1.va.home.com>

If I had designed this, I might have called the module "onexit" or
"atexit" and the public function simply "register()".  But I've got
only a +0 for my own proposal.  A +1 for the general idea.

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


From paul@prescod.net  Wed Jun 21 23:13:39 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 21 Jun 2000 17:13:39 -0500
Subject: [Python-Dev] list comprehensions
References: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>
Message-ID: <39513E13.F8082811@prescod.net>

Tim Peters wrote:
> 
> ...
> Nobody has been more vocal in support of these (& augmented assignments)
> than me, but I very strongly doubt they'll be in 1.6.  In the interests of
> getting that out the door, Guido considers the 1.6 feature set to be frozen
> already.

Is there an argument for putting in features with flaming red neon
lights: "warning, experimental, use at your risk." We want to follow a
bazaar (if not outright bizarre) development strategy after all. Putting
a patch "out there" really doesn't do much about having people really
play with and comment on a feature. I would never have experimented (and
decided against using...) metaclasses if they hadn't popped up as an
experimental feature.

Of course if there is a decent chance of breaking something already in
there that works then that's another issue...

> I think part of the pressure to get one more feature in Python (again &
> again & again) is that release cycles have been soooooo protracted, now
> slobbering well over the full year mark.  

Nah, no matter how quick you do the turnarounds, nobody wants to wait
for their favorite feature. :)

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Floggings will continue until morale improves.


From DavidA@ActiveState.com  Wed Jun 21 18:25:07 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Wed, 21 Jun 2000 10:25:07 -0700
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>

> First, get the latest WinCVS.

	http://www.wincvs.org/download.html

> I use the standard SSH Version 1.2.14 binary set.  I cant recall the URL,

There's a version at:

      ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip

BUT...

> You then need to make a “key” file - I cant recall the exact process, but
> it is pretty simple.  This is creating the identify file you specify to
> WinCVS, as well as the public key you upload to source-force.

	C:\WinCVS>ssh-keygen

I always get a 'gethostname: no such file or directory' so I had to create
the key on Linux (as is mentioned in the page
http://bmrc.berkeley.edu/people/chaffee/winntutil.html).

Maybe you have a better binary for ssh?

> NOTE - from memory, you MUST have a HOME env var set, and you MUST have a
> “.ssh” directory under your home.  Otherwise you get cryptic errors from
> SSH that give no clue that this is the problem.
>
> After uploading the public key to source forge, you are nearly set.

How do you do that?

> The
> last step is convinving CVS that you want to use this new SSH setting, and
> not the setting CVS so kindly persists in its “CVS\Root” files.  The only
> way I found to do this was to either edit the Root files manually, or
> remove the directories locally and force CVS to re-create them
> (and thereby
> re-pull everything - I assume you have ADSL in that hotel room :-)
> Alternatively, dig up that CVS script posted to py-dev recently and change
> it - personally, I never trusted it :-)
>
> All my root files look like:
> :ext:mhammond@cvs.python.sourceforge.net:/cvsroot/python
>
> Yours almost certainly will be setup for anon access, not using ssh.
>
> Hope that makes sense.  Im happy to chase anything else up I can
> for you...
>
> Mark.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev
>



From nascheme@enme.ucalgary.ca  Thu Jun 22 01:25:46 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Wed, 21 Jun 2000 18:25:46 -0600
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14673.1591.506532.170015@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 01:15:19PM -0500
References: <14673.1591.506532.170015@beluga.mojam.com>
Message-ID: <20000621182546.B25879@acs.ucalgary.ca>

On Wed, Jun 21, 2000 at 01:15:19PM -0500, Skip Montanaro wrote:
> Also, can someone tell me how to coax CVS into creating a 
> unified diff that actually contains new files?  I tried
> 
>     cvs diff -RNau
> 
> without success.

Did you "cvs add" them?

  Neil

-- 
"Simplicity does not precede complexity, but follows it." -- Alan Perlis


From skip@mojam.com (Skip Montanaro)  Thu Jun 22 01:39:03 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Wed, 21 Jun 2000 19:39:03 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <20000621182546.B25879@acs.ucalgary.ca>
References: <14673.1591.506532.170015@beluga.mojam.com>
 <20000621182546.B25879@acs.ucalgary.ca>
Message-ID: <14673.24615.291912.261214@beluga.mojam.com>

    >> Also, can someone tell me how to coax CVS into creating a unified
    >> diff that actually contains new files?  I tried
    >> 
    >> cvs diff -RNau
    >> 
    >> without success.

    Neil> Did you "cvs add" them?

Not something I could do, since I'm cvs'ing against the sourceforge
repository.  The best I guess I can do is to mirror the repository twice,
add the new files to one tree, then perform a regular diff...

Skip


From esr@thyrsus.com  Thu Jun 22 03:09:35 2000
From: esr@thyrsus.com (esr@thyrsus.com)
Date: Wed, 21 Jun 2000 22:09:35 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>
References: <20000620132150.O8678@thyrsus.com> <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>
Message-ID: <20000621220934.A1044@thyrsus.com>

Tim Peters <tim_one@email.msn.com>:
> Nobody has been more vocal in support of these (& augmented assignments)
> than me, but I very strongly doubt they'll be in 1.6.  In the interests of
> getting that out the door, Guido considers the 1.6 feature set to be frozen
> already.
> 
> I think part of the pressure to get one more feature in Python (again &
> again & again) is that release cycles have been soooooo protracted, now
> slobbering well over the full year mark.  If I accomplish nothing else at
> BeOpen, I want to give that a major speed boost -- I don't think we should
> ever let 6 months go by without at least pumping out a bugfix release.

OK, I can buy this.  Are there concrete plans (as in, a specified timeframe)
for a release in which new features will be admitted?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

What, then is law [government]? It is the collective organization of
the individual right to lawful defense."
	-- Frederic Bastiat, "The Law"


From mal@lemburg.com  Thu Jun 22 10:05:09 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 22 Jun 2000 11:05:09 +0200
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
References: <14673.1591.506532.170015@beluga.mojam.com>
Message-ID: <3951D6C5.BA31276B@lemburg.com>

> This message contains four attached files:
> 
>     Lib/exit.py - a module that allows users to register cleanup functions
>     Lib/test/test_exit.py - a simple test script
>     Lib/test/output/test_exit - expected test output
>     Doc/lib/libexit.tex - library reference manual section
> 
> Besides adding documentation and a test script, the following two mods were
> made to exit.py since I previously posted it:
> 
>     1. It implements a LIFO execution order
>     2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is 
>        treated as an exit function and appended to the exit function list.
> 
> Comments, please.

Looks ok to me, but since this is going to be a new standard
module I guess we should wait for Guido's ok before checking
it in.

> Also, can someone tell me how to coax CVS into creating a 
> unified diff that actually contains new files?  I tried
> 
>     cvs diff -RNau
> 
> without success.

I'm not an CVS expert, but I could imagine that you'll have to
add the files to CVS first and then run the above diff.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From gstein@lyra.org  Thu Jun 22 14:30:53 2000
From: gstein@lyra.org (Greg Stein)
Date: Thu, 22 Jun 2000 06:30:53 -0700
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>; from DavidA@ActiveState.com on Wed, Jun 21, 2000 at 10:25:07AM -0700
References: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au> <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>
Message-ID: <20000622063053.M29590@lyra.org>

On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote:
>...
> > You then need to make a “key” file - I cant recall the exact process, but
> > it is pretty simple.  This is creating the identify file you specify to
> > WinCVS, as well as the public key you upload to source-force.
> 
> 	C:\WinCVS>ssh-keygen
> 
> I always get a 'gethostname: no such file or directory' so I had to create
> the key on Linux (as is mentioned in the page
> http://bmrc.berkeley.edu/people/chaffee/winntutil.html).
> 
> Maybe you have a better binary for ssh?

Nah. Mark just forgets that I generated the key for him from my Linux box :-)

hehe...

Cheers,
-g

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


From tim_one@email.msn.com  Thu Jun 22 14:46:15 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 22 Jun 2000 09:46:15 -0400
Subject: [Python-Dev] SourceForge vs Windows
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBCEOECNAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEINGFAA.tim_one@email.msn.com>

I have to get SourceForge developer access working with Windows (Win98SE,
specifically), so I'll write up detailed instructions along the way,
building on Mark Hammond's good clues.  Play along!  I'll accumulate
everyone's input & make a coherent how-to out of it.

Today's installment only covers the first step, as it took 12 hours for meto
complete it (rotten connectivity today, via 56K modem, requiring many
attempts at downloading before one succeeded):

[Mark Hammond]
> First, get the latest WinCVS.  Has some nice new features.  Mine shows
> as 1.1b13.  It has a slightly “slicker” more windowsy look than the
> older one.  What we really want is the version with the
Options/Preferences
> dialog that allows you to supply the “RAS identity” file when you select
> “SSH Server” as the auth method.  Previous versions allow you to select
> the SSH Server, but give you nowhere to put the identity file.  Hence
> previous versions used a batch file wrapper, which you probably saw
> reference to.  This version makes it much simpler.

I picked up the 1.1b14 version, released 19 Jun 2000, from

    http://www.wincvs.org/download.html

It's a 3.21 Mb zip file.

hard-to-blow-it-so-far<wink>-ly y'rs  - tim





From tim_one@email.msn.com  Thu Jun 22 14:46:17 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 22 Jun 2000 09:46:17 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <20000621220934.A1044@thyrsus.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIOGFAA.tim_one@email.msn.com>

[Tim, sez the 1.6 feature set should be considered frozen, and that
 Python should move to a much less sloth-like release schedule
 thereafter]

[esr@thyrsus.com]
> OK, I can buy this.

Comes with a 30-day warranty, too <wink>.

> Are there concrete plans (as in, a specified timeframe)
> for a release in which new features will be admitted?

There damn well ought to be.  PythonLabs will be having its first all-hands
meeting tomorrow (Guido's been gone, I've been in this state less than a
week, & I'm still not sure Jeremy Hylton exists), and rational, timely
release schedules are certainly on my agenda.  I have no problem with new
features in minor releases either, provided they're 100% backward-compatible
(e.g., list comprehensions, yes (so long as they don't introduce new
bytecodes); having str(long) strip the trailing "L", no).  More when we know
more.

and-less-when-we-know-less-ly y'rs  - tim





From nascheme@enme.ucalgary.ca  Thu Jun 22 16:24:16 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 22 Jun 2000 09:24:16 -0600
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14673.24615.291912.261214@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 07:39:03PM -0500
References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> <14673.24615.291912.261214@beluga.mojam.com>
Message-ID: <20000622092416.A31223@acs.ucalgary.ca>

On Wed, Jun 21, 2000 at 07:39:03PM -0500, Skip Montanaro wrote:
>     Neil> Did you "cvs add" them?
> 
> Not something I could do, since I'm cvs'ing against the sourceforge
> repository.

That's okay.  "cvs add" only modifies things locally.  You have
to "cvs commit" to change things in the repository.

  Neil

-- 
The internet: Learn what you know.  Share what you don't.


From klm@digicool.com  Thu Jun 22 17:13:46 2000
From: klm@digicool.com (Ken Manheimer)
Date: Thu, 22 Jun 2000 12:13:46 -0400 (EDT)
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <20000622063053.M29590@lyra.org>
Message-ID: <Pine.LNX.4.21.0006221210510.19353-100000@korak.digicool.com>

A bit of a tangent, but MindTerm - http://www.mindbright.se/mindterm - is
a pretty nice java SSH client which you can use on windows to generate the
RSA identity.  (It also is a fine SSH client, with just about all the
nicities except compression - scp, x11 forwarding, arbitrary tunneling,
etc are all in there...)

Ken
klm@digicool.com

On Thu, 22 Jun 2000, Greg Stein wrote:

> On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote:
> >...
> > > You then need to make a =93key=94 file - I cant recall the exact proc=
ess, but
> > > it is pretty simple.  This is creating the identify file you specify =
to
> > > WinCVS, as well as the public key you upload to source-force.
> >=20
> > =09C:\WinCVS>ssh-keygen
> >=20
> > I always get a 'gethostname: no such file or directory' so I had to cre=
ate
> > the key on Linux (as is mentioned in the page
> > http://bmrc.berkeley.edu/people/chaffee/winntutil.html).
> >=20
> > Maybe you have a better binary for ssh?
>=20
> Nah. Mark just forgets that I generated the key for him from my Linux box=
 :-)
>=20
> hehe...
>=20
> Cheers,
> -g
>=20
> --=20
> Greg Stein, http://www.lyra.org/
>=20
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev
>=20



From skip@mojam.com (Skip Montanaro)  Thu Jun 22 18:21:04 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 22 Jun 2000 12:21:04 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <200006212255.RAA02444@cj20424-a.reston1.va.home.com>
References: <14673.1591.506532.170015@beluga.mojam.com>
 <200006212255.RAA02444@cj20424-a.reston1.va.home.com>
Message-ID: <14674.19200.325533.979792@beluga.mojam.com>

    Guido> If I had designed this, I might have called the module "onexit"
    Guido> or "atexit" and the public function simply "register()".  But
    Guido> I've got only a +0 for my own proposal.  A +1 for the general
    Guido> idea.

I'm happy to change things.  I was a bit curious if people would ask about
such a common word for a new module name.  What module name do people
prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not
careful), or something else?

Skip


From skip@mojam.com (Skip Montanaro)  Thu Jun 22 18:27:18 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 22 Jun 2000 12:27:18 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <20000622092416.A31223@acs.ucalgary.ca>
References: <14673.1591.506532.170015@beluga.mojam.com>
 <20000621182546.B25879@acs.ucalgary.ca>
 <14673.24615.291912.261214@beluga.mojam.com>
 <20000622092416.A31223@acs.ucalgary.ca>
Message-ID: <14674.19574.609843.392230@beluga.mojam.com>

    Neil> That's okay.  "cvs add" only modifies things locally.  You have to
    Neil> "cvs commit" to change things in the repository.

Ah, thanks for the tip.  I'll try that next time...

Skip


From tim_one@email.msn.com  Fri Jun 23 02:38:43 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 22 Jun 2000 21:38:43 -0400
Subject: [Python-Dev] RE: [Patches] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <20000621162731.B3918@amarok.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>

[Andrew M. Kuchling]
> While you're all admiring the difficulty of the problem, how about
> actually checking in the pythonrun.c patch, assuming it's reasonable?

I can't yet.  Be my guest!

> <flame>
>
> Frankly, I don't think the current mailing list is broken, *as long as
> patches are handled with reasonable speed* so that the backlog doesn't
> build up.

Andrew, this is saying that if it didn't display all the symptoms of
illness, it wouldn't be sick.  The consistent (this started long before
Guido's honeymoon!) lack of timely action here *is* the brokenness.

> That hasn't been done, and I don't understand why.

Why didn't you check in the pythonrun.c patch?  Multiply by 10 people and
100 patches.  There are no mechanisms in a mailing list for assigning,
recording or checking responsibility, neither for recording or querying
disposition status.  Nobody owns any part of the problem now, and it's
extraordinarly difficult to determine the status of any particular patch you
may be interested in via this mish-mash of archived all-topic email
scattered across patches and python-dev.

Prior to this mailing list, Guido owned every problem and the database was
in his head.  I think it's the lack of the "owned" and "database" parts
we're suffering from here, not especially the lack of the "Guido" part.
SourceForge provides rudimentary mechanisms for both of the former; a Python
replacement for Guido is one of BeOpen's highest secret priorities <wink>.

> ...
> Worrying about patch management mechanism, while more patches pile up
> and are ignored in the meantime, is not going to help and will just
> results in continued stagnation.

At an all-hands PythonLabs group mtg today, it was decided to move patch
activity to SourceForge and kill the patches list.  I'll send more about
that later.  There is absolutely nothing new stopping checkins while the
move to the SourceForge patch manager is in progress, so if the patches
continue to pile up it's certainly not the move's fault.  If the pythonrun.c
patch is still sitting untouched after the move, I'll assign it to you <0.7
wink>.

the-only-one-working-on-the-move-is-me-and-i-haven't-done-a-checkin-
    yet-anyway-ly y'rs  - tim




From mal@lemburg.com  Fri Jun 23 09:03:41 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 23 Jun 2000 10:03:41 +0200
Subject: [Python-Dev] Re: [Patches] Patch management (was: Warnings in pythonrun.c)
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>
Message-ID: <395319DD.F2584321@lemburg.com>

Tim Peters wrote:
> 
> > Worrying about patch management mechanism, while more patches pile up
> > and are ignored in the meantime, is not going to help and will just
> > results in continued stagnation.
> 
> At an all-hands PythonLabs group mtg today, it was decided to move patch
> activity to SourceForge and kill the patches list.  I'll send more about
> that later.  There is absolutely nothing new stopping checkins while the
> move to the SourceForge patch manager is in progress, so if the patches
> continue to pile up it's certainly not the move's fault.  If the pythonrun.c
> patch is still sitting untouched after the move, I'll assign it to you <0.7
> wink>.

But how are we going to discuss new patches from people outside
python-dev then ? I do see the use of moving patch submission
to SourceForge, but posting the patches on the list for
revision by everyone who listens is certainly better than
having to scan the patch manager entries... (push strategies
usually produce more feedback than pull ones).

A gateway from the patch manager to the patches list would
solve this nicely.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From Vladimir.Marangozov@inrialpes.fr  Fri Jun 23 11:00:23 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Fri, 23 Jun 2000 12:00:23 +0200 (CEST)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com> from "Skip Montanaro" at Jun 22, 2000 12:21:04 PM
Message-ID: <200006231000.MAA03550@python.inrialpes.fr>

Skip Montanaro wrote:
> 
> 
>     Guido> If I had designed this, I might have called the module "onexit"
>     Guido> or "atexit" and the public function simply "register()".  But
>     Guido> I've got only a +0 for my own proposal.  A +1 for the general
>     Guido> idea.
> 
> I'm happy to change things.  I was a bit curious if people would ask about
> such a common word for a new module name.  What module name do people
> prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not
> careful), or something else?
> 
> Skip

atexit.py

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From mal@lemburg.com  Fri Jun 23 11:08:46 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 23 Jun 2000 12:08:46 +0200
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
References: <200006231000.MAA03550@python.inrialpes.fr>
Message-ID: <3953372E.274907AB@lemburg.com>

Vladimir Marangozov wrote:
> 
> Skip Montanaro wrote:
> >
> >
> >     Guido> If I had designed this, I might have called the module "onexit"
> >     Guido> or "atexit" and the public function simply "register()".  But
> >     Guido> I've got only a +0 for my own proposal.  A +1 for the general
> >     Guido> idea.
> >
> > I'm happy to change things.  I was a bit curious if people would ask about
> > such a common word for a new module name.  What module name do people
> > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not
> > careful), or something else?
> >
> > Skip
> 
> atexit.py

How about exitfunc.py ? It would make the relation to sys.exitfunc
pretty clear.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From akuchlin@mems-exchange.org  Fri Jun 23 12:30:02 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 23 Jun 2000 07:30:02 -0400
Subject: [Python-Dev] Patch management
In-Reply-To: <395319DD.F2584321@lemburg.com>; from mal@lemburg.com on Fri, Jun 23, 2000 at 10:03:41AM +0200
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com> <395319DD.F2584321@lemburg.com>
Message-ID: <20000623073002.B9385@newcnri.cnri.reston.va.us>

On Fri, Jun 23, 2000 at 10:03:41AM +0200, M.-A. Lemburg wrote:
>A gateway from the patch manager to the patches list would
>solve this nicely.

According to what was said to me, it's thought that mailing new
patches to an e-mail address is supported, and therefore setting up a

So, I no longer have much of a problem with moving patches to SF,
though I *still* think the mailing list would be sufficient with a bit
more focused effort; sorry, Tim!  But at least we're not going to burn
weeks looking at different patch manager products, and then arguing
about them, which is what I feared most.

--amk


From bwarsaw@python.org  Fri Jun 23 15:33:11 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 23 Jun 2000 10:33:11 -0400 (EDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
References: <14674.19200.325533.979792@beluga.mojam.com>
 <200006231000.MAA03550@python.inrialpes.fr>
Message-ID: <14675.29991.933911.446078@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr> writes:

    VM> atexit.py

+1


From gward@mems-exchange.org  Fri Jun 23 16:42:03 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Fri, 23 Jun 2000 11:42:03 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com>
Message-ID: <20000623114202.A1778@ludwig.cnri.reston.va.us>

On 20 June 2000, esr@thyrsus.com said:
> Watch that argument -- it could turn and bite you.  What's the justification
> for including, e.g. POP client classes in the standard distribution?
> 
> One of Python's most important strengths is the "batteries *are*
> included" richness of the standard environment.

I totally agree.  There are two extremes, both completely silly: include
nothing with Python (except string, re, os, and sys -- because Distutils
needs them ;-), and include every useful, working, documented module
under the sun.  I don't think anyone would seriously argue for either
approach.  (Although you could argue that a completely stripped-down
Python might be useful in certain environments, eg. a hand-held.  But I
don't think you'd win that argument.)

And I will be the first to admit that the Distutils still aren't good
enough: in most respects, they're better than MakeMaker (IMHO), but
there's nothing like CPAN.pm or the XEmacs package manager.  And I know
from personal experience that, amazing as CPAN.pm is, it's not The
Answer; and others have attested, that XEmacs is pretty damn good but
still not perfect.

But I still don't think PIL should be included in the core, if only
because it's one of the Distutils "test cases".  ;-)

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367


From gward@mems-exchange.org  Fri Jun 23 16:45:16 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Fri, 23 Jun 2000 11:45:16 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <39513E13.F8082811@prescod.net>; from paul@prescod.net on Wed, Jun 21, 2000 at 05:13:39PM -0500
References: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com> <39513E13.F8082811@prescod.net>
Message-ID: <20000623114516.B1778@ludwig.cnri.reston.va.us>

On 21 June 2000, Paul Prescod said:
> Is there an argument for putting in features with flaming red neon
> lights: "warning, experimental, use at your risk." We want to follow a
> bazaar (if not outright bizarre) development strategy after all. Putting
> a patch "out there" really doesn't do much about having people really
> play with and comment on a feature. I would never have experimented (and
> decided against using...) metaclasses if they hadn't popped up as an
> experimental feature.

Well, remember there will probably be a "--with-gc" option to the
configure script in 1.6.  That's a good example of getting an
experimental feature out there.

However, a "--with-list-comprehensions" option would be a really bad
idea; all of a sudden, it's no longer enough to say, "You need Python
1.6" to run this script/use this module, now you need to say, "You need
Python 1.6 built with list comprehensions".  Ugh.

Real language features should not be selectable: either the language is
Python 1.6 or it isn't.

       Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367


From akuchlin@mems-exchange.org  Fri Jun 23 16:54:02 2000
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Fri, 23 Jun 2000 11:54:02 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <20000623114516.B1778@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Fri, Jun 23, 2000 at 11:45:16AM -0400
References: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com> <39513E13.F8082811@prescod.net> <20000623114516.B1778@ludwig.cnri.reston.va.us>
Message-ID: <20000623115402.B4805@amarok.cnri.reston.va.us>

On Fri, Jun 23, 2000 at 11:45:16AM -0400, Greg Ward wrote:
>idea; all of a sudden, it's no longer enough to say, "You need Python
>1.6" to run this script/use this module, now you need to say, "You need
>Python 1.6 built with list comprehensions".  Ugh.

The same argument applies to --with-gc, though, since people might
write code that creates cycles and needs GC to run without leaking
like a sieve.  Making GC optional is still the right solution, though,
because its performance effects are still unknown and might be costly.

--amk




From gvwilson@nevex.com  Fri Jun 23 17:09:36 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Fri, 23 Jun 2000 12:09:36 -0400 (EDT)
Subject: [Python-Dev] Re: list comprehensions / garbage collection / optional features
In-Reply-To: <20000623115402.B4805@amarok.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10006231159160.16185-100000@akbar.nevex.com>

> >Greg Ward wrote:

> >idea; all of a sudden, it's no longer enough to say, "You need Python
> >1.6" to run this script/use this module, now you need to say, "You need
> >Python 1.6 built with list comprehensions".  Ugh.

> Andrew Kuchling wrote:

> The same argument applies to --with-gc, though, since people might
> write code that creates cycles and needs GC to run without leaking
> like a sieve.  Making GC optional is still the right solution, though,
> because its performance effects are still unknown and might be costly.

Greg Wilson writes:

I'm really looking forward to recycling my rusty SETL idioms when list
comprehensions become part of the "official" release, and to creating
graphs in the obvious way if GC ever becomes standard.  However, the more
variations there are in the "standard" (as opposed to "developer")
release, the more expensive (in time and sweat) it is to manage Python at
large sites (like Los Alamos).  This in turn makes it harder to persuade
people that using Python will make their lives easier...

Thanks,

Greg

Footnote: The existence of JPython was one of the arguments in favor of
choosing Python for the Software Carpentry project. The fact that JPython
and CPython have very different memory management behaviors almost negated
that point: as one thirty-year veteran said, "It's no use having code that
runs in lots of places if it runs differently in each."



From nascheme@enme.ucalgary.ca  Fri Jun 23 18:12:51 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 23 Jun 2000 11:12:51 -0600
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects classobject.c,2.86,2.87 dictobject.c,2.52,2.53 funcobject.c,2.20,2.21 listobject.c,2.73,2.74 tupleobject.c,2.36,2.37
In-Reply-To: <200006231418.HAA02869@slayer.i.sourceforge.net>; from jhylton@users.sourceforge.net on Fri, Jun 23, 2000 at 07:18:13AM -0700
References: <200006231418.HAA02869@slayer.i.sourceforge.net>
Message-ID: <20000623111251.B10850@acs.ucalgary.ca>

On Fri, Jun 23, 2000 at 07:18:13AM -0700, Jeremy Hylton wrote:
> Round 1 of Neil Schemenauer's GC patches:

Yay.  :)

> + class_traverse(PyClassObject *o, visitproc visit, void *arg)
> + {
...
> + 	return 0;
> + }

> + instance_traverse(PyInstanceObject *o, visitproc visit, void *arg)
> + {
...
> + 	return 1;
> + }

Oops.  I think "return 0" is the proper thing to do.  There are a
few other functions that return 1 as well.

  Neil


From fdrake@acm.org  Fri Jun 23 19:08:06 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 23 Jun 2000 11:08:06 -0700 (PDT)
Subject: [Python-Dev] out of touch
Message-ID: <14675.42886.423185.310220@mailhost.beopen.com>

  My laptop has died, so I'm catching up with a couple of days of
mail.  I've not had time to look at Paul's proposed DOM-like additions
to the standard library.  Hopefully Andrew can (or has) summarized the
relevant portions of our discussion from yesterday; if I don't see it,
I'll try to get another message out later.  (But I don't have my saved
mail or files, so there's still not a lot I can do. ;( )


  -Fred


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



From fdrake@beopen.com  Fri Jun 23 20:04:55 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 23 Jun 2000 12:04:55 -0700 (PDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com>
References: <14673.1591.506532.170015@beluga.mojam.com>
 <200006212255.RAA02444@cj20424-a.reston1.va.home.com>
 <14674.19200.325533.979792@beluga.mojam.com>
Message-ID: <14675.46295.836727.117258@mailhost.beopen.com>

Skip Montanaro writes:
 > I'm happy to change things.  I was a bit curious if people would ask about
 > such a common word for a new module name.  What module name do people
 > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not

  I like "atexit" better.


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>



From guido@python.org  Fri Jun 23 21:08:36 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 23 Jun 2000 15:08:36 -0500
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: Your message of "Fri, 23 Jun 2000 12:04:55 MST."
 <14675.46295.836727.117258@mailhost.beopen.com>
References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> <14674.19200.325533.979792@beluga.mojam.com>
 <14675.46295.836727.117258@mailhost.beopen.com>
Message-ID: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>

> Skip Montanaro writes:
>  > I'm happy to change things.  I was a bit curious if people would ask about
>  > such a common word for a new module name.  What module name do people
>  > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not

[fred]
>   I like "atexit" better.

OK, let it be atexit.  I'm glad this time the naming debate is at
least civilized. :-)

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


From DavidA@ActiveState.com  Fri Jun 23 20:30:31 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Fri, 23 Jun 2000 12:30:31 -0700
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJIEMMCJAA.DavidA@ActiveState.com>

> OK, let it be atexit.  I'm glad this time the naming debate is at
> least civilized. :-)

No, wait, i think it should be exit_AT!

Actually, I'm sick of this english-centricity.  You american jerks are all
the same!  Go home Yankee!  It should be en_sortant or nothing at all!

--david "I try..." ascher



From nascheme@enme.ucalgary.ca  Fri Jun 23 21:11:03 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 23 Jun 2000 14:11:03 -0600
Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed
Message-ID: <20000623141103.A13079@acs.ucalgary.ca>

Has this been addressed yet for 1.6?  It is probably an easy fix.
The original poster claimed it took 4 seconds to start Python on
his machine.

  Neil

----- Forwarded message from Johannes Stezenbach <yawyi@gmx.de> -----

Date: Thu, 22 Jun 2000 15:03:01 +0200
From: yawyi@gmx.de (Johannes Stezenbach)
Subject: Re: Linux/NT python startup speed

Niklas Frykholm <r2d2@mao.acc.umu.se> wrote:
>Can someone explain this difference. (The processor on the Linux system is
>certainly not 40 times faster.)

This was discussed here a few months ago. The reason for the slow
startup is the winsound module (source: PC/winsound.c) which is
unnecessarily a builtin.  winsound causes Python to load the
Windows multimedia DLLs, which can be slow if your sound drivers
make it so.

Two solutions were discussed:
a) make winsound a .pyd
b) use some obscure "delayload" feature of the M$ linker. There
   is a ready to use python15.dll for Python 1.5.2 with this
   feature somewhere out there (I don't remember where, though,
   since I use Linux now)

IMHO solution a) should be standard in Python 1.6 (it isn't in
1.6a2).

Johannes



----- End forwarded message -----


From tim_one@email.msn.com  Fri Jun 23 21:11:47 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 23 Jun 2000 16:11:47 -0400
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJIEMMCJAA.DavidA@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEELLGFAA.tim_one@email.msn.com>

[Guido]
>> OK, let it be atexit.  I'm glad this time the naming debate is at
>> least civilized. :-)

{David Ascher]
> No, wait, i think it should be exit_AT!
>
> Actually, I'm sick of this english-centricity.  You american jerks are all
> the same!  Go home Yankee!  It should be en_sortant or nothing at all!

Oh, screw you and the frog you rode in, Frenchie.  Using an inferior
language is no excuse for poor grammar:  "exit at" reads like a freeway
sign, as in "Kentucky Fried Chicken, exit at 12B".  en_sortant is no
better -- worse, I have no idea what this has to do with arranging ants in
order (and what kind of algorithm is en_sort anyway?).
uponbutpriortoexiting is an idea that can't even be expressed in French, I
bet.

internationally y'rs  - tim




From guido@python.org  Fri Jun 23 22:49:05 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 23 Jun 2000 16:49:05 -0500
Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed
In-Reply-To: Your message of "Fri, 23 Jun 2000 14:11:03 CST."
 <20000623141103.A13079@acs.ucalgary.ca>
References: <20000623141103.A13079@acs.ucalgary.ca>
Message-ID: <200006232149.QAA03157@cj20424-a.reston1.va.home.com>

> Has this been addressed yet for 1.6?  It is probably an easy fix.
> The original poster claimed it took 4 seconds to start Python on
> his machine.

In 1.6, winsound is a separate subproject and hence a separately
loadable DLL, so it doesn't slow down the main code.  Ditto for
socket and a few others.

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



From jeremy@beopen.com  Fri Jun 23 23:01:19 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 23 Jun 2000 18:01:19 -0400
Subject: [Python-Dev] Python 1.6 planning
Message-ID: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>

We discussed plans for Python 1.6 at the all-hands PythonLabs staff meeting
yesterday.  (At this meeting, the PythonLabs staff closed ranks and agreed
to say that Tim Peters exists.)
I'd like to quickly summarize plans.

The target release date for Python 1.6 beta 1 is early July.  Any code that
is going to be in the beta must be checked in before July 1.

Tim Peters pushed us to take care of the patches backlog.  Our plan is to
close the patches list and move all patch management to Sourceforge.  We
know the list is broken; we don't know that Sourceforge is broken.

There are a bunch of modules and technical issues that must be resolved one
way or another.


SRE-- /F needs to finish this up.  Unanswered question is whether the beta
will ship with known bugs.

GC-- Neil's garbage collector will be shipped as experimental feature
requiring configure option.

XML-- Some parts of the XML package will be included in the library under
the xmlcore package.  SAX and DOM (provided that it is stable enough).
Andrew gets to decide, I believe.

List comprehensions -- Next release.  Despite the love fest at the meeting
(everyone seems to want them), there is no way an implementation will be
ready or stable enough.

httplib-- We will include Greg Stein's new httplib, provided that it
supports an old-style HTTPS class.

curses-- one return type needs to be implemented (5-tuple).  Andrew will
finish ASAP.  ESR's ascii module will be part of the curses package.

imputil-- The imputil module will be dropped in the std library to enable
wider distribution, but no changes will be made to the normal import
machinery.

Unicode shorthand-- Andrew will look at Bill Tutt's code. We intend to add
it.

Unicode compression-- We need to find out if Christian will be able to
provide a compressed database.

ldso_aix-- I still don't understand, but I didn't really try; Vladimir must
help

threads-- They will be on by default if the platform supports.

gettext-- Barry will check in his gettext module.

atexit.py-- add it

Jeremy




From nascheme@enme.ucalgary.ca  Fri Jun 23 23:22:50 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 23 Jun 2000 16:22:50 -0600
Subject: [Python-Dev] Python 1.6 planning
In-Reply-To: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400
References: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>
Message-ID: <20000623162250.A14311@acs.ucalgary.ca>

On Fri, Jun 23, 2000 at 06:01:19PM -0400, Jeremy Hylton wrote:
> threads-- They will be on by default if the platform supports.

Does the Linux thread/fork problem still exist?  It would be nice
to kill this before 1.6 final.  I will test this with the CVS
source this weekend.

  Neil


From skip@mojam.com (Skip Montanaro)  Sat Jun 24 02:09:04 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 23 Jun 2000 20:09:04 -0500
Subject: [Python-Dev] test failures...
Message-ID: <200006240109.UAA14738@beluga.mojam.com>

Using the latest CVS code, I get failures for three tests on my Linux
Mandrake 6.1 laptop:

  test test_exceptions failed -- Writing: 'spam', expected: 'Attr'
  test test_types crashed -- exceptions.OverflowError : long int too long to convert
  test test_long failed -- int(long(-sys.maxint-1)) overflowed!

Are these known/expected or unknown/unexpected failures?


From skip@mojam.com (Skip Montanaro)  Sat Jun 24 02:27:39 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 23 Jun 2000 20:27:39 -0500 (CDT)
Subject: [Python-Dev] atexit.py patch
Message-ID: <14676.3723.916135.602@beluga.mojam.com>

--0bkw+IZ+u3
Content-Type: text/plain; charset=us-ascii
Content-Description: message body and .signature
Content-Transfer-Encoding: 7bit

Here's the latest version of my exit module.  Per the earlier discussion,
the module has been renamed to atexit.py.  I also took the suggestion from
someone (Guido?) that the registration function be renamed to simply
"register".  Other than that everything else should be the same.

I'm only sending this to python-dev, operating under the assumption that the 
patches list is about to take a long vacation...

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."


--0bkw+IZ+u3
Content-Type: application/octet-stream
Content-Description: atexit.py & doc
Content-Disposition: attachment;
	filename="atexit.diff"
Content-Transfer-Encoding: base64

ZGlmZiAtTmF1ciBzcmMub3JpZy9Eb2MvbGliL2xpYmF0ZXhpdC50ZXggc3JjL0RvYy9saWIv
bGliYXRleGl0LnRleAotLS0gc3JjLm9yaWcvRG9jL2xpYi9saWJhdGV4aXQudGV4CVdlZCBE
ZWMgMzEgMTg6MDA6MDAgMTk2OQorKysgc3JjL0RvYy9saWIvbGliYXRleGl0LnRleAlGcmkg
SnVuIDIzIDE3OjI2OjIzIDIwMDAKQEAgLTAsMCArMSw0NSBAQAorXHNlY3Rpb257XG1vZHVs
ZXthdGV4aXR9IC0tLQorICAgICAgICAgZXhpdCBoYW5kbGVyc30KKworXGRlY2xhcmVtb2R1
bGV7c3RhbmRhcmR9e2F0ZXhpdH0KK1xzZWN0aW9uYXV0aG9ye1NraXAgTW9udGFuYXJvfXtz
a2lwQG1vamFtLmNvbX0KK1xtb2R1bGVzeW5vcHNpc3tSZWdpc3RlciBhbmQgZXhlY3V0ZSBj
bGVhbnVwIGZ1bmN0aW9ucy59CisKK1RoZSBcbW9kdWxle2F0ZXhpdH0gbW9kdWxlIGRlZmlu
ZXMgYSBzaW5nbGUgZnVuY3Rpb24gdG8gcmVnaXN0ZXIgY2xlYW51cAorZnVuY3Rpb25zLiAg
RnVuY3Rpb25zIHRodXMgcmVnaXN0ZXJlZCBhcmUgYXV0b21hdGljYWxseSBleGVjdXRlZCB1
cG9uIG5vcm1hbAoraW50ZXJwcmV0ZXIgdGVybWluYXRpb24uCisKK1xiZWdpbntmdW5jZGVz
Y317cmVnaXN0ZXJ9e2Z1bmNcb3B0aW9uYWx7LCAqYXJnc1xvcHRpb25hbHssICoqa2FyZ3N9
fX0KK1JlZ2lzdGVyIFxjb2Rle2Z1bmN9IGFzIGEgZnVuY3Rpb24gdG8gYmUgZXhlY3V0ZWQg
YXQgdGVybWluYXRpb24uICBBbnkKK29wdGlvbmFsIGFyZ3VtZW50cyB0aGF0IGFyZSB0byBi
ZSBwYXNzZWQgdG8gZnVuYyBtdXN0IGJlIHBhc3NlZCBhcyBhcmd1bWVudHMKK3RvIFxmdW5j
e3JlZ2lzdGVyfS4KKworQXQgbm9ybWFsIHByb2dyYW0gdGVybWluYXRpb24gKGZvciBpbnN0
YW5jZSwgaWYgXGZ1bmN7c3lzLmV4aXR9IGlzIGNhbGxlZCBvcgordGhlIG1haW4gbW9kdWxl
J3MgZXhlY3V0aW9uIGNvbXBsZXRlcyksIGFsbCBmdW5jdGlvbnMgcmVnaXN0ZXJlZCBhcmUg
Y2FsbGVkCitpbiBsYXN0IGluLCBmaXJzdCBvdXQgb3JkZXIuICBUaGUgYXNzdW1wdGlvbiBp
cyB0aGF0IGxvd2VyIGxldmVsIG1vZHVsZXMKK3dpbGwgbm9ybWFsbHkgYmUgaW1wb3J0ZWQg
YmVmb3JlIGhpZ2hlciBsZXZlbCBtb2R1bGVzIGFuZCB0aHVzIG11c3QgYmUKK2NsZWFuZWQg
dXAgbGF0ZXIuCisKK1xzdWJzZWN0aW9ue0V4YW1wbGV9CisKK1RoZSBmb2xsb3dpbmcgc2lt
cGxlIGV4YW1wbGUgZGVtb25zdHJhdGVzIGhvdyBhIG1vZHVsZSBjYW4gaW5pdGlhbGl6ZSBh
Citjb3VudGVyIGZyb20gYSBmaWxlIHdoZW4gaXQgaXMgaW1wb3J0ZWQgYW5kIHNhdmUgdGhl
IGNvdW50ZXIncyB1cGRhdGVkIHZhbHVlCithdXRvbWF0aWNhbGx5IHdoZW4gdGhlIHByb2dy
YW0gdGVybWluYXRlcy4KKworXGJlZ2lue3ZlcmJhdGltfQordHJ5OgorICAgIF9jb3VudCA9
IGV2YWwob3BlbigiL3RtcC9jb3VudGVyIikucmVhZCgpKQorZXhjZXB0IElPRXJyb3I6Cisg
ICAgX2NvdW50ID0gMAorCitkZWYgaW5jcmNvdW50ZXIobik6CisgICAgZ2xvYmFsIF9jb3Vu
dAorICAgIF9jb3VudCA9IF9jb3VudCArIG4KKworZGVmIHNhdmVjb3VudGVyKCk6CisgICAg
b3BlbigiL3RtcC9jb3VudGVyIiwgInciKS53cml0ZSgiJWQiICUgX2NvdW50KQorCitpbXBv
cnQgYXRleGl0CithdGV4aXQucmVnaXN0ZXIoc2F2ZWNvdW50ZXIpCitcZW5ke3ZlcmJhdGlt
fQorCmRpZmYgLU5hdXIgc3JjLm9yaWcvTGliL2F0ZXhpdC5weSBzcmMvTGliL2F0ZXhpdC5w
eQotLS0gc3JjLm9yaWcvTGliL2F0ZXhpdC5weQlXZWQgRGVjIDMxIDE4OjAwOjAwIDE5NjkK
KysrIHNyYy9MaWIvYXRleGl0LnB5CUZyaSBKdW4gMjMgMTc6Mjc6MzIgMjAwMApAQCAtMCww
ICsxLDU0IEBACisiIiIKK2F0ZXhpdC5weSAtIGFsbG93IHByb2dyYW1tZXIgdG8gZGVmaW5l
IG11bHRpcGxlIGV4aXQgZnVuY3Rpb25zIHRvIGJlIGV4ZWN1dGVkCit1cG9uIG5vcm1hbCBw
cm9ncmFtIHRlcm1pbmF0aW9uLgorCitPbmUgcHVibGljIGZ1bmN0aW9uLCByZWdpc3Rlciwg
aXMgZGVmaW5lZC4gIAorIiIiCisKK19leGl0aGFuZGxlcnMgPSBbXQorZGVmIF9ydW5fZXhp
dGZ1bmNzKCk6CisgICAgIiIicnVuIGFueSByZWdpc3RlcmVkIGV4aXQgZnVuY3Rpb25zCisK
KyAgICBfZXhpdGhhbmRsZXJzIGlzIHRyYXZlcnNlZCBpbiByZXZlcnNlIG9yZGVyIHNvIGZ1
bmN0aW9ucyBhcmUgZXhlY3V0ZWQKKyAgICBsYXN0IGluLCBmaXJzdCBvdXQuCisgICAgIiIi
CisgICAgCisgICAgd2hpbGUgX2V4aXRoYW5kbGVyczoKKyAgICAgICAgZnVuYywgdGFyZ3Ms
IGthcmdzID0gX2V4aXRoYW5kbGVyc1stMV0KKyAgICAgICAgYXBwbHkoZnVuYywgdGFyZ3Ms
IGthcmdzKQorICAgICAgICBfZXhpdGhhbmRsZXJzLnJlbW92ZShfZXhpdGhhbmRsZXJzWy0x
XSkKKworZGVmIHJlZ2lzdGVyKGZ1bmMsICp0YXJncywgKiprYXJncyk6CisgICAgIiIicmVn
aXN0ZXIgYSBmdW5jdGlvbiB0byBiZSBleGVjdXRlZCB1cG9uIG5vcm1hbCBwcm9ncmFtIHRl
cm1pbmF0aW9uCisKKyAgICBmdW5jIC0gZnVuY3Rpb24gdG8gYmUgY2FsbGVkIGF0IGV4aXQK
KyAgICB0YXJncyAtIG9wdGlvbmFsIGFyZ3VtZW50cyB0byBwYXNzIHRvIGZ1bmMKKyAgICBr
YXJncyAtIG9wdGlvbmFsIGtleXdvcmQgYXJndW1lbnRzIHRvIHBhc3MgdG8gZnVuYworICAg
ICIiIgorICAgIF9leGl0aGFuZGxlcnMuYXBwZW5kKChmdW5jLCB0YXJncywga2FyZ3MpKQor
CitpbXBvcnQgc3lzCit0cnk6CisgICAgeCA9IHN5cy5leGl0ZnVuYworZXhjZXB0IEF0dHJp
YnV0ZUVycm9yOgorICAgIHN5cy5leGl0ZnVuYyA9IF9ydW5fZXhpdGZ1bmNzCitlbHNlOgor
ICAgICMgaWYgeCBpc24ndCBvdXIgb3duIGV4aXQgZnVuYyBleGVjdXRpdmUsIGFzc3VtZSBp
dCdzIGFub3RoZXIKKyAgICAjIHJlZ2lzdGVyZWQgZXhpdCBmdW5jdGlvbiAtIGFwcGVuZCBp
dCB0byBvdXIgbGlzdC4uLgorICAgIGlmIHggIT0gX3J1bl9leGl0ZnVuY3M6CisgICAgICAg
IHJlZ2lzdGVyKHgpCitkZWwgc3lzCisKK2lmIF9fbmFtZV9fID09ICJfX21haW5fXyI6Cisg
ICAgZGVmIHgxKCk6CisgICAgICAgIHByaW50ICJydW5uaW5nIHgxIgorICAgIGRlZiB4Mihu
KToKKyAgICAgICAgcHJpbnQgInJ1bm5pbmcgeDIoJXMpIiAlIGBuYAorICAgIGRlZiB4Myhu
LCBrd2Q9Tm9uZSk6CisgICAgICAgIHByaW50ICJydW5uaW5nIHgzKCVzLCBrd2Q9JXMpIiAl
IChgbmAsIGBrd2RgKQorCisgICAgcmVnaXN0ZXIoeDEpCisgICAgcmVnaXN0ZXIoeDIsIDEy
KQorICAgIHJlZ2lzdGVyKHgzLCA1LCAiYmFyIikKKyAgICByZWdpc3Rlcih4MywgIm5vIGt3
ZCBhcmdzIikKKwpkaWZmIC1OYXVyIHNyYy5vcmlnL0xpYi90ZXN0L291dHB1dC90ZXN0X2F0
ZXhpdCBzcmMvTGliL3Rlc3Qvb3V0cHV0L3Rlc3RfYXRleGl0Ci0tLSBzcmMub3JpZy9MaWIv
dGVzdC9vdXRwdXQvdGVzdF9hdGV4aXQJV2VkIERlYyAzMSAxODowMDowMCAxOTY5CisrKyBz
cmMvTGliL3Rlc3Qvb3V0cHV0L3Rlc3RfYXRleGl0CUZyaSBKdW4gMjMgMTc6Mjg6NTMgMjAw
MApAQCAtMCwwICsxLDQgQEAKK3Rlc3RfYXRleGl0CitoYW5kbGVyMiAoNywpIHsna3cnOiAn
YWJjJ30KK2hhbmRsZXIyICgpIHt9CitoYW5kbGVyMQpkaWZmIC1OYXVyIHNyYy5vcmlnL0xp
Yi90ZXN0L3Rlc3RfYXRleGl0LnB5IHNyYy9MaWIvdGVzdC90ZXN0X2F0ZXhpdC5weQotLS0g
c3JjLm9yaWcvTGliL3Rlc3QvdGVzdF9hdGV4aXQucHkJV2VkIERlYyAzMSAxODowMDowMCAx
OTY5CisrKyBzcmMvTGliL3Rlc3QvdGVzdF9hdGV4aXQucHkJRnJpIEp1biAyMyAxNzoyODoz
MSAyMDAwCkBAIC0wLDAgKzEsMjQgQEAKKyMgVGVzdCB0aGUgZXhpdCBtb2R1bGUKK2Zyb20g
dGVzdF9zdXBwb3J0IGltcG9ydCB2ZXJib3NlCitpbXBvcnQgYXRleGl0CisKK2RlZiBoYW5k
bGVyMSgpOgorICAgIHByaW50ICJoYW5kbGVyMSIKKworZGVmIGhhbmRsZXIyKCphcmdzLCAq
KmthcmdzKToKKyAgICBwcmludCAiaGFuZGxlcjIiLCBhcmdzLCBrYXJncworCisjIHNhdmUg
YW55IGV4aXQgZnVuY3Rpb25zIHRoYXQgbWF5IGhhdmUgYmVlbiByZWdpc3RlcmVkIGFzIHBh
cnQgb2YgdGhlCisjIHRlc3QgZnJhbWV3b3JrCitfZXhpdGhhbmRsZXJzID0gYXRleGl0Ll9l
eGl0aGFuZGxlcnMKK2F0ZXhpdC5fZXhpdGhhbmRsZXJzID0gW10KKworYXRleGl0LnJlZ2lz
dGVyKGhhbmRsZXIxKQorYXRleGl0LnJlZ2lzdGVyKGhhbmRsZXIyKQorYXRleGl0LnJlZ2lz
dGVyKGhhbmRsZXIyLCA3LCBrdz0iYWJjIikKKworIyBzaW11bGF0ZSBleGl0IGJlaGF2aW9y
IGJ5IGNhbGxpbmcgYXRleGl0Ll9ydW5fZXhpdGZ1bmNzIGRpcmVjdGx5Li4uCithdGV4aXQu
X3J1bl9leGl0ZnVuY3MoKQorCisjIHJlc3RvcmUgZXhpdCBoYW5kbGVycworYXRleGl0Ll9l
eGl0aGFuZGxlcnMgPSBfZXhpdGhhbmRsZXJzCg==

--0bkw+IZ+u3--


From trentm@activestate.com  Sat Jun 24 03:19:23 2000
From: trentm@activestate.com (Trent Mick)
Date: Fri, 23 Jun 2000 19:19:23 -0700
Subject: [Python-Dev] test failures...
In-Reply-To: <200006240109.UAA14738@beluga.mojam.com>
References: <200006240109.UAA14738@beluga.mojam.com>
Message-ID: <20000623191923.A25730@activestate.com>

On Fri, Jun 23, 2000 at 08:09:04PM -0500, Skip Montanaro wrote:
> Using the latest CVS code, I get failures for three tests on my Linux
> Mandrake 6.1 laptop:
> 
>   test test_exceptions failed -- Writing: 'spam', expected: 'Attr'

Don't know about this one.

>   test test_types crashed -- exceptions.OverflowError : long int too long to convert

This is related to some conversion checking that I added a while back, I
believe.


>   test test_long failed -- int(long(-sys.maxint-1)) overflowed!
> 
Same thing. Potentially this *should* overflow and the test should expect
that.


Don't take my word on this right now, only looked quickly. I will look at it
this weekend (hopefully). Skip, I don't get the test failures, although I am
a few days behind Python-CVS. Are these very new failures? Could you provide
the verbose output from running these tests indepedently? Thanks.


Trent


-- 
Trent Mick
trentm@activestate.com


From tim_one@email.msn.com  Sat Jun 24 03:32:46 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 23 Jun 2000 22:32:46 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <200006240109.UAA14738@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEMEGFAA.tim_one@email.msn.com>

[Skip Montanaro]
> Using the latest CVS code, I get failures for three tests on my Linux
> Mandrake 6.1 laptop:
>
>   test test_exceptions failed -- Writing: 'spam', expected: 'Attr'
>   test test_types crashed -- exceptions.OverflowError : long int
> too long to convert
>   test test_long failed -- int(long(-sys.maxint-1)) overflowed!
>
> Are these known/expected or unknown/unexpected failures?

First two don't ring a bell, last one has shown up several times & each time
traced to an optimization bug, usually in a particular older version of gcc.
Recompile with optimization off and see whether that makes all of them go
away.  If so, try using a recent gcc.




From tim_one@email.msn.com  Sat Jun 24 03:41:23 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 23 Jun 2000 22:41:23 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <20000623191923.A25730@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEMFGFAA.tim_one@email.msn.com>

>>   test test_types crashed -- exceptions.OverflowError : long
>> int too long to convert

> This is related to some conversion checking that I added a while back, I
> believe.

Possible but doubt it.

>>   test test_long failed -- int(long(-sys.maxint-1)) overflowed!

> Same thing. Potentially this *should* overflow and the test should expect
> that.

Definitely not on this one:  sys.maxint is by defn the largest positive
Python int, so on any 2's-comp machine -sys.maxint-1 should be a legit
Python int too.  This bogus failure has popped up due to compiler
optimization bugs under at least two older different compilers, though (gcc
being by far the more often reported culprit -- I think the other was one of
those HP compilers that seems to generate more bad code than good <0.3
wink>).

The first step in test failures like this is to recompile with optimization
off.




From skip@mojam.com (Skip Montanaro)  Sat Jun 24 04:45:04 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 23 Jun 2000 22:45:04 -0500 (CDT)
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEMEGFAA.tim_one@email.msn.com>
References: <200006240109.UAA14738@beluga.mojam.com>
 <LNBBLJKPBEHFEDALKOLCMEMEGFAA.tim_one@email.msn.com>
Message-ID: <14676.11968.263924.752216@beluga.mojam.com>

    >> test test_exceptions failed -- Writing: 'spam', expected: 'Attr'
    >> test test_types crashed -- exceptions.OverflowError : long int too long to convert
    >> test test_long failed -- int(long(-sys.maxint-1)) overflowed!

    Tim> First two don't ring a bell, last one has shown up several times &
    Tim> each time traced to an optimization bug, usually in a particular
    Tim> older version of gcc.  Recompile with optimization off and see
    Tim> whether that makes all of them go away.  If so, try using a recent
    Tim> gcc.

Turning off optimization got rid of the test_types and test_long failures.
The test_exceptins failure remains.  Here's a diff:

    diff test_exceptions.save test_exceptions
    2a3
    > spam
    3a5
    > spam
    4a7
    > spam
    5a9
    > spam
    6a11
    > spam
    7a13
    > spam
    8a15
    > spam
    10a18
    > spam
    12a21
    > spam
    13a23
    > spam
    14a25
    > spam
    16a28
    > spam
    17a30
    > spam
    19a33
    > spam
    20a35
    > spam
    21a37
    > spam
    22a39
    > spam
    23a41
    > spam

I'm not sure what that means, but it seems consistent. ;-)

As for the age of my gcc, I think I'm reasonably current (only a bit over a
year old):

    % gcc -v
    Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs
    gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)

I will try downloading a newer RPM.

Skip


From ping@lfw.org  Sat Jun 24 07:08:42 2000
From: ping@lfw.org (Ka-Ping Yee)
Date: Sat, 24 Jun 2000 01:08:42 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your
 perusal
In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>

On Fri, 23 Jun 2000, Guido van Rossum wrote:
> [fred]
> >   I like "atexit" better.
> 
> OK, let it be atexit.  I'm glad this time the naming debate is at
> least civilized. :-)

Sorry to confuddle things, but what happened to the idea of
sticking it in "sys"?  If sys.exitfunc lives there, doesn't
sys.atexit(...) also make sense?  It can't be very hard to do...


-- ?!ng



From guido@python.org  Sat Jun 24 17:03:07 2000
From: guido@python.org (Guido van Rossum)
Date: Sat, 24 Jun 2000 11:03:07 -0500
Subject: [Python-Dev] test failures...
In-Reply-To: Your message of "Fri, 23 Jun 2000 20:09:04 EST."
 <200006240109.UAA14738@beluga.mojam.com>
References: <200006240109.UAA14738@beluga.mojam.com>
Message-ID: <200006241603.LAA05123@cj20424-a.reston1.va.home.com>

>   test test_exceptions failed -- Writing: 'spam', expected: 'Attr'

There's a "print buf" at the end of the new function
test_raise_catch() that causes this.  Jeremy added this; either the
"print buf" shouldn't be there, or the file
Lib/test/output/test_exceptions should be updated.  It's up to Jeremy
now.

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



From skip@mojam.com (Skip Montanaro)  Sat Jun 24 16:11:18 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Sat, 24 Jun 2000 10:11:18 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your
 perusal
In-Reply-To: <Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
 <Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
Message-ID: <14676.53142.263320.435588@beluga.mojam.com>

    Ping> Sorry to confuddle things, but what happened to the idea of
    Ping> sticking it in "sys"?  If sys.exitfunc lives there, doesn't
    Ping> sys.atexit(...) also make sense?  It can't be very hard to do...

I like the general idea that stuff implemented in C is just a thin interface
layer on top of existing system services and that higher level protocols are
implemented in Python where there's no overriding need for them to be
written in C.  This fits that model, at least to a first approximation.  The
sys.exitfunc variable functions pretty much like calling the atexit(3)
library call (though that's not how sys.exitfunc is implemented), and the
atexit module provides a protocol that dictates how that mechanism is used
in a cooperative setting.

There's almost certainly no performance reason this code should be
implemented in C.  It's going to be easier to maintain and enhance if
written in Python, and won't add size to the interpreter for those
programmers who don't use it (or don't use other modules that do).

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."


From nascheme@enme.ucalgary.ca  Sat Jun 24 17:04:18 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Sat, 24 Jun 2000 10:04:18 -0600
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEMFGFAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Fri, Jun 23, 2000 at 10:41:23PM -0400
References: <20000623191923.A25730@activestate.com> <LNBBLJKPBEHFEDALKOLCMEMFGFAA.tim_one@email.msn.com>
Message-ID: <20000624100418.A20411@acs.ucalgary.ca>

On Fri, Jun 23, 2000 at 10:41:23PM -0400, Tim Peters wrote:
> The first step in test failures like this is to recompile with
> optimization off.

Mandrake is known for shipping bad compilers.  They used to ship
pgcc as the default compiler even though it was know to have a
lot of problems.

  Neil


From tim_one@email.msn.com  Sat Jun 24 18:27:19 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:27:19 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <14676.11968.263924.752216@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>

[Skip Montanaro]
> Turning off optimization got rid of the test_types and test_long failures.
> The test_exceptins failure remains.

Bingo, and Guido pinned test_exceptions on Jeremy.  You can likely get a
usable Python by disabling optimization only for longobject.c, if for some
reason you need to stick with that compiler.

> As for the age of my gcc, I think I'm reasonably current (only a
> bit over a year old):
>
>     % gcc -v
>     Reading specs from
> /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs
>     gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)

Well, I haven't had need of following the gcc/egcs soap opera, but I think
"a year" (& particularly the last one <wink>) is a lifetime in that saga.
"2.95" rings a vague bell, as the only compiler in that line my former
employer felt was usable for their development work under Linux.

unlike-python-so-far-they've-had-some-bad-releases-ly y'rs  - tim




From tim_one@email.msn.com  Sat Jun 24 18:30:54 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:30:54 -0400
Subject: [Python-Dev] atexit.py patch
In-Reply-To: <14676.3723.916135.602@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEMKGFAA.tim_one@email.msn.com>

[Skip]
> I'm only sending this to python-dev, operating under the
> assumption that the  patches list is about to take a long vacation...

Skip, if you can't put it on SourceForge for some reason (like what?), the
patches list is certainly better than python-dev!  I've got enough to do
trying to disentangle multi-megabytes of patches-list archives that I'm not
going to expand my search to other archives (like python-dev) too.




From gstein@lyra.org  Sat Jun 24 18:39:34 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 24 Jun 2000 10:39:34 -0700
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:27:19PM -0400
References: <14676.11968.263924.752216@beluga.mojam.com> <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>
Message-ID: <20000624103934.Y29590@lyra.org>

On Sat, Jun 24, 2000 at 01:27:19PM -0400, Tim Peters wrote:
> [Skip Montanaro]
> > Turning off optimization got rid of the test_types and test_long failures.
> > The test_exceptins failure remains.
> 
> Bingo, and Guido pinned test_exceptions on Jeremy.  You can likely get a
> usable Python by disabling optimization only for longobject.c, if for some
> reason you need to stick with that compiler.

Euh... shouldn't we insert some defensive code into longobject.c? Great,
Skip knows to disable opt for that file... what about all the other people?

Cheers,
-g

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


From tim_one@email.msn.com  Sat Jun 24 18:42:29 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:42:29 -0400
Subject: [Python-Dev] Patch management
In-Reply-To: <20000623073002.B9385@newcnri.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMLGFAA.tim_one@email.msn.com>

[Andrew Kuchling]
> ...
> So, I no longer have much of a problem with moving patches to SF,
> though I *still* think the mailing list would be sufficient with a bit
> more focused effort; sorry, Tim!

"Do something" to supply that focus on this mailing list, and then I can
stop bothering with the move.  That would be great.  But repeating that if
the list worked, it wouldn't be broken <0.7 wink>, has not proven sufficient
to fix it.

> But at least we're not going to burn weeks looking at different patch
> manager products, and then arguing about them, which is what I feared
> most.

Same here.

well-actually-the-radio-on-the-drive-down-to-va-got-me-more-worried-
    about-lyme-disease-ly y'rs  - tim





From tim_one@email.msn.com  Sat Jun 24 18:51:14 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:51:14 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <20000624103934.Y29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMMGFAA.tim_one@email.msn.com>

[Greg Stein]
> Euh... shouldn't we insert some defensive code into longobject.c? Great,
> Skip knows to disable opt for that file... what about all the
> other people?

Don't understand what you want to see.  The compiler in question is both
broken & old.  At most I'd put a note in one of the readmes saying so.




From fdrake@beopen.com  Sat Jun 24 22:19:50 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Sat, 24 Jun 2000 14:19:50 -0700 (PDT)
Subject: [Python-Dev] updated exit.py and supporting files for your
 perusal
In-Reply-To: <Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
 <Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
Message-ID: <14677.9718.880695.265962@mailhost.beopen.com>

Ka-Ping Yee writes:
 > Sorry to confuddle things, but what happened to the idea of
 > sticking it in "sys"?  If sys.exitfunc lives there, doesn't
 > sys.atexit(...) also make sense?  It can't be very hard to do...

  I'd be happy with this as well, but I don't think it's required to
do it that way.


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>



From gstein@lyra.org  Sat Jun 24 23:18:24 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 24 Jun 2000 15:18:24 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37
In-Reply-To: <200006242040.NAA28315@slayer.i.sourceforge.net>; from gward@users.sourceforge.net on Sat, Jun 24, 2000 at 01:40:05PM -0700
References: <200006242040.NAA28315@slayer.i.sourceforge.net>
Message-ID: <20000624151824.A29590@lyra.org>

Would the "shlex" module be helpful here? It is in the standard library and
is (well?) maintained by ESR. It could help reduce the code inside
distutils.
[ I've always questioned the need for distutils' own "copy file" functions
  and whatnot... seems there is a bit of duplication occurring... ]

Cheers,
-g

On Sat, Jun 24, 2000 at 01:40:05PM -0700, Greg Ward wrote:
> Update of /cvsroot/python/distutils/distutils
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv28287
> 
> Modified Files:
> 	util.py 
> Log Message:
> Added 'split_quoted()' function to deal with strings that are quoted in 
> Unix shell-like syntax (eg. in Python's Makefile, for one thing -- now that
> I have this function, I'll probably allow quoted strings in config files too.
> 
> Index: util.py
> ===================================================================
> RCS file: /cvsroot/python/distutils/distutils/util.py,v
> retrieving revision 1.36
> retrieving revision 1.37
> diff -C2 -r1.36 -r1.37
> *** util.py	2000/06/18 15:45:55	1.36
> --- util.py	2000/06/24 20:40:02	1.37
> ***************
> *** 167,168 ****
> --- 167,235 ----
>   
>       return error
> + 
> + 
> + # Needed by 'split_quoted()'
> + _wordchars_re = re.compile(r'[^\\\'\"\ ]*')
> + _squote_re = re.compile(r"'(?:[^'\\]|\\.)*'")
> + _dquote_re = re.compile(r'"(?:[^"\\]|\\.)*"')
> + 
> + def split_quoted (s):
> +     """Split a string up according to Unix shell-like rules for quotes and
> +     backslashes.  In short: words are delimited by spaces, as long as those
> +     spaces are not escaped by a backslash, or inside a quoted string.
> +     Single and double quotes are equivalent, and the quote characters can
> +     be backslash-escaped.  The backslash is stripped from any two-character
> +     escape sequence, leaving only the escaped character.  The quote
> +     characters are stripped from any quoted string.  Returns a list of
> +     words.
> +     """
> + 
> +     # This is a nice algorithm for splitting up a single string, since it
> +     # doesn't require character-by-character examination.  It was a little
> +     # bit of a brain-bender to get it working right, though...
> + 
> +     s = string.strip(s)
> +     words = []
> +     pos = 0
> + 
> +     while s:
> +         m = _wordchars_re.match(s, pos)
> +         end = m.end()
> +         if end == len(s):
> +             words.append(s[:end])
> +             break
> + 
> +         if s[end] == ' ':               # unescaped, unquoted space: now
> +             words.append(s[:end])       # we definitely have a word delimiter
> +             s = string.lstrip(s[end:])
> +             pos = 0
> + 
> +         elif s[end] == '\\':            # preserve whatever is being escaped;
> +                                         # will become part of the current word
> +             s = s[:end] + s[end+1:]
> +             pos = end+1
> + 
> +         else:
> +             if s[end] == "'":           # slurp singly-quoted string
> +                 m = _squote_re.match(s, end)
> +             elif s[end] == '"':         # slurp doubly-quoted string
> +                 m = _dquote_re.match(s, end)
> +             else:
> +                 raise RuntimeError, \
> +                       "this can't happen (bad char '%c')" % s[end]
> + 
> +             if m is None:
> +                 raise ValueError, \
> +                       "bad string (mismatched %s quotes?)" % s[end]
> + 
> +             (beg, end) = m.span()
> +             s = s[:beg] + s[beg+1:end-1] + s[end:]
> +             pos = m.end() - 2
> + 
> +         if pos >= len(s):
> +             words.append(s)
> +             break
> + 
> +     return words
> + 
> + # split_quoted ()
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins@python.org
> http://www.python.org/mailman/listinfo/python-checkins

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


From gstein@lyra.org  Sat Jun 24 23:50:23 2000
From: gstein@lyra.org (Greg Stein)
Date: Sat, 24 Jun 2000 15:50:23 -0700
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEMMGFAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:51:14PM -0400
References: <20000624103934.Y29590@lyra.org> <LNBBLJKPBEHFEDALKOLCAEMMGFAA.tim_one@email.msn.com>
Message-ID: <20000624155023.B29590@lyra.org>

On Sat, Jun 24, 2000 at 01:51:14PM -0400, Tim Peters wrote:
> [Greg Stein]
> > Euh... shouldn't we insert some defensive code into longobject.c? Great,
> > Skip knows to disable opt for that file... what about all the
> > other people?
> 
> Don't understand what you want to see.  The compiler in question is both
> broken & old.  At most I'd put a note in one of the readmes saying so.

The compiler Skip quoted was pgcc-2.91.66. The "pgcc" part may have
introduced the problem, but my RedHat 6.2 (i.e. the LATEST) has the
following:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)


Maybe 2.91.66 is "old" but that is the compiler being shipped on RedHat 6.2.

Having said that, I bet the pgcc people messed up the compiler :-). I set
-O9 on my box and recompiled longobject.c. It wouldn't reproduce the problem.

Cheers,
-g

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


From gmcm@hypernet.com  Sun Jun 25 00:01:05 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Sat, 24 Jun 2000 19:01:05 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>
References: <14676.11968.263924.752216@beluga.mojam.com>
Message-ID: <1250234786-20097552@hypernet.com>

Tim "The Windows Guy" Peters wrote:

> [Skip Montanaro]
> > /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs
> >     gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)
> 
> Well, I haven't had need of following the gcc/egcs soap opera,
> but I think "a year" (& particularly the last one <wink>) is a
> lifetime in that saga.

gcc 2.90 (egcs 1.0.3) that came with RH 5.2 was broken - but 
got fixed by rebuilding it from source.

- Gordon


From gstein@lyra.org  Sun Jun 25 09:40:23 2000
From: gstein@lyra.org (Greg Stein)
Date: Sun, 25 Jun 2000 01:40:23 -0700
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache]
Message-ID: <20000625014023.D29590@lyra.org>

Woah... this is an interesting factoid about the number of committers for a
project. I had no idea PHP had this many...

Can this work with Python? Dunno. I think if a "true core" group pays
attention to the -checkins alias, then yah. If that review is ever lost,
then those "edge" committers could introduce crap.

I'm not asking for more committers to Python. But if some people were
worried about the "explosion" of committers from about six a couple months
ago to the current 13, then just look to PHP and count your thanks :-)
Mostly, this email is for pondering...

Cheers,
-g

----- Forwarded message from Rasmus Lerdorf <rasmus@apache.org> -----

Reply-To: members@apache.org
Date: Sat, 24 Jun 2000 20:52:01 -0700 (PDT)
From: Rasmus Lerdorf <rasmus@apache.org>
To: members@apache.org
Subject: Re: PMCs and Apache

> More relevant is the process by which I became a contributor.  For PHP, I
> sent a note describing what I was exploring, and I was sent a note with a
> password.  I didn't know CVS.  I didn't know PHP.  I didn't know open
> source.  But like a stranger offering to help at a barn raising, I was
> simply handed a hammer and expected to get busy.

That has always been the atmosphere.  It isn't quite as free as that.  We
get 10-20 cvs write account requests every week and tend to only hand out
1 or 2 actual accounts.  There are a lot of clueless people out there.  
However, if the person has shown any sign of being competent by explaining
in a rational manner what they plan on working on, I see no reason not to
let them bash away.  Reversing somebodys' changes and removing a cvs
account is trivial, and in the past 5 years we have yet to revoke an
account.  We have reversed changes of course, but even that doesn't happen
too often.

There are currently 165 people with write access to the PHP source tree.

This does also relate to the fact that the PHP project is a very broad
project.  No single person could possibly know all 16 supported low-level
database apis, for example.  

For other projects with a much more limited scope, this approach is
probably not optimal, but for PHP it works nicely.  Someone will write a
bit of broken code that shows some good ideas, and others will pounce on
it and fix it.  Often the people who fix it are poor sods who tried to use
the broken feature and had to dive in and fix it themselves.  They request
a cvs account to do this, and they are hooked.  They tend to never stop at
fixing just one thing once they have been given the golden keys.

This approach has also done wonders for the PHP documentation.  The
current manual is around 1100 pages long and has been fully translated to
German, Italian and Japanese with more languages on the way.  (check out
http://snaps.php.net/manual/)

-Rasmus

----- End forwarded message -----

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


From gstein@lyra.org  Mon Jun 26 00:20:43 2000
From: gstein@lyra.org (Greg Stein)
Date: Sun, 25 Jun 2000 16:20:43 -0700
Subject: [Python-Dev] Python/Apache stuff (was: Re: [XML-SIG] speed question re DOM parsing)
In-Reply-To: <200006251540.JAA13556@localhost.localdomain>; from uogbuji@fourthought.com on Sun, Jun 25, 2000 at 09:40:59AM -0600
References: <gstein@lyra.org> <200006251540.JAA13556@localhost.localdomain>
Message-ID: <20000625162043.J29590@lyra.org>

On Sun, Jun 25, 2000 at 09:40:59AM -0600, Uche Ogbuji wrote:
> Greg Stein:
> > When could I get to it? eek. I *will*, but dunno when. It is amazing just
> > how much stuff can fall on a person's plate despite having no job :-). I've
> > got some layered I/O in Apache, mod_dav integration, a new httplib, imputil
> > issues, these qp_xml upgrades, ViewCVS stuff, edna releases, free threading
> > changes, Python/Apache integration, and coding for Subversion. Fuggin
> > frightening.
> 
> Ooh!  Ooh!  Can you tell us more about the Python/Apache integration item?  
> We've been discussing distributing a 4Suite kit bundled with PyApache, but 
> that package is quite complex and I'm not sure how strongly maintained.  Are 
> you talking about improvements to PyApache?  Another approach entirely 
> (PyApache still has much more overhead than, say mod_perl)?  Do you have an 
> approximate time-line?  A project URL?

There are several Python/Apache efforts (where Python is embedded into the
Apache process):

*) PyApache: essentially this is just a CGI accelerator. Take a standard CGI
   script and it will "run faster."
   (URL? dunno)

*) mod_python: similar to mod_perl. Built for Apache 1.3. Despite its
   version 2.4, it is still a bit rough. I've been working with the author
   to improve the code. I did a code review a while back with a lot of
   suggestions. It is reasonable, but not as mature as mod_perl.
   http://www.modpython.org/

*) mod_snake: obvious misnomer :-). This is a module built for Apache 2.0,
   with the intent of making use of Apache 2.0's threadedness (plus a few of
   A2's other internal features). The code is very good looking.
   - available at SourceForge

*) mod_slimpy: my name for an Apache 2.0 module which will be even lighter
   weight than mod_snake. There will be only the slimmest layer of C code to
   interface Apache and Python. Most/all operational logic will be deferred
   to the Python side. I've used this design to good effect in some of the
   Python/COM work and its univgw package in particular.

Obviously, the latter two will compete, but oh well :-). The first two fit
their problem environment without particular complications.

When I start the mod_slimpy work, I'm also going to push on setting up
python.apache.org. Essentially, it will host (under the ASF umbrella) the
mod_slimpy work plus any other efforts that may want to operate there. I'm
going to ask the authors of the other packages whether they would like to be
hosted there, too.

Of course, python.apache.org can host any Python project. It doesn't have to
be related to the web server, or any other ASF project for that matter.
Consider all the non-web stuff that operates under xml.apache.org,
java.apache.org, and jakarta.apache.org.

Cheers,
-g

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


From Vladimir.Marangozov@inrialpes.fr  Mon Jun 26 12:33:56 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Mon, 26 Jun 2000 13:33:56 +0200 (CEST)
Subject: [Python-Dev] Fw: Access violation when no memory
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au> from "Mark Hammond" at Jun 20, 2000 09:42:53 PM
Message-ID: <200006261133.NAA03073@python.inrialpes.fr>

Mark Hammond wrote:
> 
> >From the newsgroup.  Any thoughts?
> 
> Mark.
> 
> "Phil Mayes" <nospam@bitbucket.com> wrote in message
> news:<olD35.82$_%.4481@newsfeed.avtel.net>...
> > The following program progressively allocates all memory:
> >     size = 1 << 20
> >     list = [None,]
> >     while size:
> >         try:
> >             mem = [None] * size
> >             mem[0] = list
> >             list = mem
> >         except:
> >             size = size / 2
> >
> > It fails with an access violation.  (Turn off virtual memory
> > to provoke it.)

I had a closer look at this report. It revealed a buglet in Instance_New
and raises a question on how to handle the possible NULL values pushed
on the stack in ceval.c, at the exception handling code block:

> > 3. the NULL pointer at tb is pushed here:
> >      ceval.c line 1816:    PUSH(tb);
> >      ceval.c line 1817:    PUSH(val);
> >      ceval.c line 1818:    PUSH(exc);

1. In PyInstance_New, when the inst->in_dict allocation fails, there's
   a DECREF(inst) which triggers the instance_dealloc function. The latter
   goes on checking whether __del__ is defined in the instance's dict
   (by calling getattr2) whithout checking first whether inst->in_dict
   is not NULL. I.e. the dealloc_function assumes the instance has been
   initialized successfully. The net effect is a segfault in PyDict_GetItem
   which is called with a NULL dict.

   There are two possible fixes, and I'm not sure which one is better:

   a) Fix the Instance_New code, by freeing the instance on inst->in_dict
      allocation failure (without decref'ing the instance).

   b) Fix the dealloc code, by checking whether in_dict is not NULL
      before proceeding with the __del__ finalization logic.

   Opinions?

2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on
   low-memory conditions. They are pushed on the stack, then popped with
   a segfault.  The only reasonable behavior I get, after some testing,
   is by setting the tb and exc to Py_None if any of them is NULL before
   pushing them onto the stack. The program succeeds or the process is
   killed by the OS (tested on Linux).

   However, I'm not sure that setting tb and/or exc to Py_None, if NULL,
   makes any sense and won't cause side effects.

   Any other suggestions?

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From guido@python.org  Mon Jun 26 15:49:11 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 09:49:11 -0500
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Fri, 23 Jun 2000 10:03:41 +0200."
 <395319DD.F2584321@lemburg.com>
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>
 <395319DD.F2584321@lemburg.com>
Message-ID: <200006261449.JAA01684@cj20424-a.reston1.va.home.com>

It's official: I've changed the patch submission guidelines
(http://www.python.org/patches/) to point to the patch manager at
SourceForge.  We are no longer bound by CNRI's legal department, so
the requirement for disclaimers or wet signatures is gone.

We'll have to see how it works in practice.  I've set the address
where new patches are mailed to patches@python.org; this should send
notifications to the patches list.  We could change this to python-dev
perhaps, so we can retire the patches address completely (giving it an
auto-respond pointing to the SF patch manager, as barry suggested).

There are several tasks to be assigned now: we need a triage person
who should go through the list of new patches regularly to assign them
to developers; we need developers who are willing to have patches
assigned to them.

We also need a consensus process to decide which patches will be
allowed through.  I'm hoping to experiment with SF in the coming days
to come up with something.

Finally, we still need to do something about the existing backlog of
patches.  The PythonLabs team will try to do something reasonable
here.

This is not the end -- it's the beginning!

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


From jack@oratrix.nl  Mon Jun 26 15:29:05 2000
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 26 Jun 2000 16:29:05 +0200
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache]
In-Reply-To: Message by Greg Stein <gstein@lyra.org> ,
 Sun, 25 Jun 2000 01:40:23 -0700 , <20000625014023.D29590@lyra.org>
Message-ID: <20000626142906.1DDBD37186E@snelboot.oratrix.nl>

> Woah... this is an interesting factoid about the number of committers for a
> project. I had no idea PHP had this many...
> 
> Can this work with Python? Dunno. I think if a "true core" group pays
> attention to the -checkins alias, then yah. If that review is ever lost,
> then those "edge" committers could introduce crap.

This is one of the reasons I never asked for committer status: the fewer 
people doing commits the better. I can live with the <2days delay we had upto 
recently, and for now I'm expecting it to go down to that again after all the 
turmoil is over.
--
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 guido@python.org  Mon Jun 26 16:43:38 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 10:43:38 -0500
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache]
In-Reply-To: Your message of "Mon, 26 Jun 2000 16:29:05 +0200."
 <20000626142906.1DDBD37186E@snelboot.oratrix.nl>
References: <20000626142906.1DDBD37186E@snelboot.oratrix.nl>
Message-ID: <200006261543.KAA02198@cj20424-a.reston1.va.home.com>

[Jack Jansen]
> This is one of the reasons I never asked for committer status: the
> fewer people doing commits the better. I can live with the <2days
> delay we had upto recently, and for now I'm expecting it to go down
> to that again after all the turmoil is over.

Actually, I'd be glad to give you committer status (your colleague
Sjoerd just got his :-).  I expect that the majority of the
subscribers to python-dev can be trusted as committers.

I fully expect that most committers won't be committing much -- I
don't expect a frenzy of work by committers on the source tree.
However the committer status offloads the responsibility of applying
the patches you submit after they have been approved -- you can now do
it yourself.  Less work for me and the others here at PythonLabs!

BTW, I would heartily recommend putting the Macintosh tree for Python
under SourceForge!

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


From mal@lemburg.com  Mon Jun 26 16:03:30 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 26 Jun 2000 17:03:30 +0200
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>
 <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
Message-ID: <395770C2.B903724A@lemburg.com>

Guido van Rossum wrote:
> 
> It's official: I've changed the patch submission guidelines
> (http://www.python.org/patches/) to point to the patch manager at
> SourceForge.  We are no longer bound by CNRI's legal department, so
> the requirement for disclaimers or wet signatures is gone.
> 
> We'll have to see how it works in practice.  I've set the address
> where new patches are mailed to patches@python.org; this should send
> notifications to the patches list.  We could change this to python-dev
> perhaps, so we can retire the patches address completely (giving it an
> auto-respond pointing to the SF patch manager, as barry suggested).

Will there be a list which gets the patches mailed to it
by SF ?

I'm just asking because the current setup of having the patches
available through mail really helps in discussing patch details.
 
> There are several tasks to be assigned now: we need a triage person
> who should go through the list of new patches regularly to assign them
> to developers; we need developers who are willing to have patches
> assigned to them.

I'll volunteer for the Unicode side of things :-)

> We also need a consensus process to decide which patches will be
> allowed through.  I'm hoping to experiment with SF in the coming days
> to come up with something.
> 
> Finally, we still need to do something about the existing backlog of
> patches.  The PythonLabs team will try to do something reasonable
> here.
> 
> This is not the end -- it's the beginning!

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From jack@oratrix.nl  Mon Jun 26 16:13:54 2000
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 26 Jun 2000 17:13:54 +0200
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache]
In-Reply-To: Message by Guido van Rossum <guido@python.org> ,
 Mon, 26 Jun 2000 10:43:38 -0500 , <200006261543.KAA02198@cj20424-a.reston1.va.home.com>
Message-ID: <20000626151355.3EF8C37186E@snelboot.oratrix.nl>

> Actually, I'd be glad to give you committer status (your colleague
> Sjoerd just got his :-).  I expect that the majority of the
> subscribers to python-dev can be trusted as committers.

Oww, grumble grumble... Okay, I'll apply for committer status. So there.

> BTW, I would heartily recommend putting the Macintosh tree for Python
> under SourceForge!

I don't think MacCVS can do ssh authorization, and if I followed the 
discussion here that is needed, right? But if that hurdle can be taken: fine!
--
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 guido@python.org  Mon Jun 26 17:32:37 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 11:32:37 -0500
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Mon, 26 Jun 2000 17:03:30 +0200."
 <395770C2.B903724A@lemburg.com>
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com> <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
 <395770C2.B903724A@lemburg.com>
Message-ID: <200006261632.LAA02506@cj20424-a.reston1.va.home.com>

[MAL]
> Will there be a list which gets the patches mailed to it
> by SF ?
> 
> I'm just asking because the current setup of having the patches
> available through mail really helps in discussing patch details.

I don't think this feature is part of the SF Patch Manager just yet.
You could submit it as a request to the SF PM developers though --
apparently they're still working on it.

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


From paul@prescod.net  Mon Jun 26 16:43:31 2000
From: paul@prescod.net (Paul Prescod)
Date: Mon, 26 Jun 2000 08:43:31 -0700
Subject: [Python-Dev] winreg
Message-ID: <39577A23.EF7DE922@prescod.net>

[I'm having mail troubles so my response time may be slow...]

I've just had a chance to look at the winreg module. I think that it is
too low-level. I wrote a wrapper class that I feel is more Pythonic.
I'll outline the basic ideas and then if there is interest I'll develop
a test suite and send it out for eyeballing by Mark and others. Yes, I
am proposing this for 1.6. If we're going to put in a registry module,
it should be as Pythonic as possible.

First, about Winreg 1:

It was perfect when it was part of the win32 package and was supposed to
mirror the win32 APIs exactly (for reasons of documentation and
familiarity) but as the "standard" Python registry manipulation module
it seems too low-level to me.

I'm sure Mark would be the first to admit that it isn't very Pythonic.
It's more Microsoft-ic. In one part of the docs he says: "this API is
lame, lame, lame. Don't use it." :) 

There are also bogus parameters that Microsoft hasn't got around to
assigning values to, undocumented constants and so forth. My favorite is
"WHOLE_HIVE_VOLATILE".

Winreg 2:

The basic idea in the pythonic wrapper is that there are key "objects"
rather than just handles. winreg already has a primtive "handle object"
but for some reason most of the stuff that would logically be methods
are actually functions that take the handle as the first param.

Keys can have subkeys. So in winreg 1 you would say:

winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE,
"HARDWARE"), "DESCRIPTION" )

now you say:

winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey(
"DESCRIPTION" )

(you could also use a path syntax in either case)

You can get a complete list of existant subkeys with a getSubkeys()
method call. This list behaves like a Python mapping and also like a
sequence. You can use either string key names or integer ordinal
indexes. You can fetch and delete keys based on those indexes:

for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys():
	dosomething( key )

Before it was something like this:

for index in xrange( 0, sys.maxint ):
	try:
		dosomething( winreg.EnumKey( index ) )
	except WindowsError:
		break

"Values" (in the Microsoft sense) are handled the same basic way.
Looping, deleting, etc. is the same.

When you fetch a value, you get a (type,value) tuple. Types are objects
with properties:

typeobj.intval -> 0..10
typeobj.msname -> REG_SZ, REG_SZ_MULTI, ...
typeobj.friendlyname -> "String", "Sting List", ...

Type coercions are all done by the underlying module (the old winreg)
except that I've decided that binary data should be returned as an
array.array('c') rather than an 8-bit string.

-- 
 Paul Prescod
Out of timber so crooked as that which man is made nothing entirely
straight can be built. - Immanuel Kant


From fdrake@beopen.com  Mon Jun 26 17:04:40 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT)
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395770C2.B903724A@lemburg.com>
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>
 <395319DD.F2584321@lemburg.com>
 <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
 <395770C2.B903724A@lemburg.com>
Message-ID: <14679.32536.133849.573542@mailhost.beopen.com>

M.-A. Lemburg writes:
 > Will there be a list which gets the patches mailed to it
 > by SF ?

  patches@python.org should get messages of patch manager activity (at
least certain actions; not sure which ones yet, but at least
additions).

 > I'm just asking because the current setup of having the patches
 > available through mail really helps in discussing patch details.

  Yes!  I'd really hate to lose notifications!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Mon Jun 26 17:04:40 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT)
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395770C2.B903724A@lemburg.com>
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>
 <395319DD.F2584321@lemburg.com>
 <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
 <395770C2.B903724A@lemburg.com>
Message-ID: <14679.32536.133849.573542@mailhost.beopen.com>

M.-A. Lemburg writes:
 > Will there be a list which gets the patches mailed to it
 > by SF ?

  patches@python.org should get messages of patch manager activity (at
least certain actions; not sure which ones yet, but at least
additions).

 > I'm just asking because the current setup of having the patches
 > available through mail really helps in discussing patch details.

  Yes!  I'd really hate to lose notifications!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From paul@prescod.net  Mon Jun 26 16:43:31 2000
From: paul@prescod.net (Paul Prescod)
Date: Mon, 26 Jun 2000 08:43:31 -0700
Subject: [Python-Dev] winreg
Message-ID: <39577A23.EF7DE922@prescod.net>

[I'm having mail troubles so my response time may be slow...]

I've just had a chance to look at the winreg module. I think that it is
too low-level. I wrote a wrapper class that I feel is more Pythonic.
I'll outline the basic ideas and then if there is interest I'll develop
a test suite and send it out for eyeballing by Mark and others. Yes, I
am proposing this for 1.6. If we're going to put in a registry module,
it should be as Pythonic as possible.

First, about Winreg 1:

It was perfect when it was part of the win32 package and was supposed to
mirror the win32 APIs exactly (for reasons of documentation and
familiarity) but as the "standard" Python registry manipulation module
it seems too low-level to me.

I'm sure Mark would be the first to admit that it isn't very Pythonic.
It's more Microsoft-ic. In one part of the docs he says: "this API is
lame, lame, lame. Don't use it." :) 

There are also bogus parameters that Microsoft hasn't got around to
assigning values to, undocumented constants and so forth. My favorite is
"WHOLE_HIVE_VOLATILE".

Winreg 2:

The basic idea in the pythonic wrapper is that there are key "objects"
rather than just handles. winreg already has a primtive "handle object"
but for some reason most of the stuff that would logically be methods
are actually functions that take the handle as the first param.

Keys can have subkeys. So in winreg 1 you would say:

winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE,
"HARDWARE"), "DESCRIPTION" )

now you say:

winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey(
"DESCRIPTION" )

(you could also use a path syntax in either case)

You can get a complete list of existant subkeys with a getSubkeys()
method call. This list behaves like a Python mapping and also like a
sequence. You can use either string key names or integer ordinal
indexes. You can fetch and delete keys based on those indexes:

for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys():
	dosomething( key )

Before it was something like this:

for index in xrange( 0, sys.maxint ):
	try:
		dosomething( winreg.EnumKey( index ) )
	except WindowsError:
		break

"Values" (in the Microsoft sense) are handled the same basic way.
Looping, deleting, etc. is the same.

When you fetch a value, you get a (type,value) tuple. Types are objects
with properties:

typeobj.intval -> 0..10
typeobj.msname -> REG_SZ, REG_SZ_MULTI, ...
typeobj.friendlyname -> "String", "Sting List", ...

Type coercions are all done by the underlying module (the old winreg)
except that I've decided that binary data should be returned as an
array.array('c') rather than an 8-bit string.

-- 
 Paul Prescod
Out of timber so crooked as that which man is made nothing entirely
straight can be built. - Immanuel Kant


From fdrake@beopen.com  Mon Jun 26 16:46:23 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 08:46:23 -0700 (PDT)
Subject: [Python-Dev] Fw: Access violation when no memory
In-Reply-To: <200006261133.NAA03073@python.inrialpes.fr>
References: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au>
 <200006261133.NAA03073@python.inrialpes.fr>
Message-ID: <14679.31439.11309.105239@mailhost.beopen.com>

Vladimir Marangozov writes:
 >    There are two possible fixes, and I'm not sure which one is better:
 > 
 >    a) Fix the Instance_New code, by freeing the instance on inst->in_dict
 >       allocation failure (without decref'ing the instance).

  I think this is the right one; this *shold* be all that's ever
needed, and isolates the check to the cod ethat can experiance
failure.

 >    b) Fix the dealloc code, by checking whether in_dict is not NULL
 >       before proceeding with the __del__ finalization logic.

  This protects against bad C code elsewhere that makes a mess of
existing objects by stepping around the API (such as by setting
inst->in_dict to NULL).  I'm not sure we want to protect against that
since it could mask bugs (I doubt anyone would do that deliberatly, so
I feel safe calling it a bug!).

 >    Opinions?

  And for free!  So infer what you will about their worth.  :)

 > 2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on
 >    low-memory conditions. They are pushed on the stack, then popped with
 >    a segfault.  The only reasonable behavior I get, after some testing,
 >    is by setting the tb and exc to Py_None if any of them is NULL before
 >    pushing them onto the stack. The program succeeds or the process is
 >    killed by the OS (tested on Linux).
 > 
 >    However, I'm not sure that setting tb and/or exc to Py_None, if NULL,
 >    makes any sense and won't cause side effects.

  This doesn't seem like a situation where you'd be masking some other
kind of bug by using Py_None, and it avoids the core dump.  Since
you're not masking anything, I'd go ahead and use Py_None here.


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From esr@thyrsus.com  Mon Jun 26 19:01:25 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Mon, 26 Jun 2000 14:01:25 -0400
Subject: [Python-Dev] Now that the man is back...
Message-ID: <20000626140125.A3266@thyrsus.com>

--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii

Guido, can we get these into 1.6?  They're needed for the the ncurses 
extensions I'm working on.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"This country, with its institutions, belongs to the people who
inhabit it. Whenever they shall grow weary of the existing government,
they can exercise their constitutional right of amending it or their
revolutionary right to dismember it or overthrow it."
	-- Abraham Lincoln, 4 April 1861

--k1lZvvs/B4yU6o8G
Content-Type: application/x-tex
Content-Disposition: attachment; filename="libascii.tex"

\section{\module{ascii} ---
         Constants and set-membership functions for ASCII characters.}

\declaremodule{standard}{ascii}
\modulesynopsis{Constants and set-membership functions for ASCII characters.}
\moduleauthor{Eric S. Raymond}{esr@thyrsus.com}
\sectionauthor{Eric S. Raymond}{esr@thyrsus.com}

\versionadded{1.6}

The \module{ascii} module supplies name constants for ASCII characters
and functions to test membership in various ASCII character classes.  
The constants supplied are names for control characters as follows:

NUL, SOH, STX, ETX, EOT, ENQ, ACK, BEL, BS, TAB, HT, LF, NL, VT, FF, CR,
SO, SI, DLE, DC1, DC2, DC3, DC4, NAK, SYN, ETB, CAN, EM, SUB, ESC, FS, 
GS, RS, US, SP, DEL.

NL and LF are synonyms; so are HT and TAB.  The module also supplies
the following functions, patterned on those in the standard C library:

\begin{funcdesc}{isalnum}{c}
Checks for an ASCII alphanumeric character; it is equivalent to
isalpha(c) or isdigit(c))
\end{funcdesc}

\begin{funcdesc}{isalpha}{c}
Checks for an ASCII alphabetic character; it is equivalent to
isupper(c) or islower(c))
\end{funcdesc}

\begin{funcdesc}{isascii}{c}
Checks for a character value that fits in the 7-bit ASCII set.
\end{funcdesc}

\begin{funcdesc}{isblank}{c}
Checks for an ASCII alphanumeric character; it is equivalent to
isalpha(c) or isdigit(c))
\end{funcdesc}

\begin{funcdesc}{iscntrl}{c}
Checks for an ASCII control character (range 0x00 to 0x1f).
\end{funcdesc}

\begin{funcdesc}{isdigit}{c}
Checks for an ASCII decimal digit, 0 through 9.
\end{funcdesc}

\begin{funcdesc}{isgraph}{c}
Checks for ASCII any printable character except space.
\end{funcdesc}

\begin{funcdesc}{islower}{c}
Checks for an ASCII lower-case character.
\end{funcdesc}

\begin{funcdesc}{isprint}{c}
Checks for any ASCII printable character including space.
\end{funcdesc}

\begin{funcdesc}{ispunct}{c}
Checks for any printable ASCII character which is not a space or an
alphanumeric character.
\end{funcdesc}

\begin{funcdesc}{isspace}{c}
Checks for ASCII white-space characters; space, tab, line feed,
carriage return, form feed, horizontal tab, vertical tab.
\end{funcdesc}

\begin{funcdesc}{isupper}{c}
Checks for an ASCII uppercase letter.
\end{funcdesc}

\begin{funcdesc}{isxdigit}{c}
Checks for an ASCII hexadecimal digit, i.e. one of 0123456789abcdefABCDEF.
\end{funcdesc}

\begin{funcdesc}{isctrl}{c}
Checks for an ASCII control character, bit values 0 to 31.
\end{funcdesc}

\begin{funcdesc}{ismeta}{c}
Checks for a (non-ASCII) character, bit values 0x80 and above.
\end{funcdesc}

These functions accept either integers or strings; when the argument
is a string, it is first converted using the built-in function ord().

Note that all these functions check ordinal bit values derived from the 
first character of the string you pass in; they do not actually know
anything about the host machine's character encoding.  For functions 
that know about the character encoding (and handle
internationalization properly) see the string module.

The following two functions take either a single-character string or
integer byte value; they return a value of the same type.

\begin{funcdesc}{ascii}{c}
Return the ASCII value corresponding to the low 7 bits of c.
\end{funcdesc}

\begin{funcdesc}{ctrl}{c}
Return the control character corresponding to the given character
(the character bit value is logical-anded with 0x1f).
\end{funcdesc}

\begin{funcdesc}{alt}{c}
Return the 8-bit character corresponding to the given ASCII character
(the character bit value is logical-ored with 0x80).
\end{funcdesc}

The following function takes either a single-character string or
integer byte value; it returns a string.

\begin{funcdesc}{unctrl}{c}
Return a string representation of the ASCII character c.  If c is
printable, this string is the character itself.  If the character
is a control character (0x00-0x1f) the string consists of a caret
(^) followed by the corresponding uppercase letter.  If the character
is an ASCII delete (0x7f) the string is "^?".  If the character has
its meta bit (0x80) set, the meta bit is stripped, the preceding rules
applied, and "!" prepended to the result.
\end{funcdesc}

Finally, the module supplies a 33-element string array 
called controlnames that contains the ASCII mnemonics for the
thirty-two ASCII control characters from 0 (NUL) to 0x1f (US),
in order, plus the mnemonic "SP" for space.

 

--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ascii.py"

#
# ascii.py -- constants and memembership tests for ASCII characters
#

NUL	= 0x00	# ^@
SOH	= 0x01	# ^A
STX	= 0x02	# ^B
ETX	= 0x03	# ^C
EOT	= 0x04	# ^D
ENQ	= 0x05	# ^E
ACK	= 0x06	# ^F
BEL	= 0x07	# ^G
BS	= 0x08	# ^H
TAB	= 0x09	# ^I
HT	= 0x09	# ^I
LF	= 0x0a	# ^J
NL	= 0x0a	# ^J
VT	= 0x0b	# ^K
FF	= 0x0c	# ^L
CR	= 0x0d	# ^M
SO	= 0x0e	# ^N
SI	= 0x0f	# ^O
DLE	= 0x10	# ^P
DC1	= 0x11	# ^Q
DC2	= 0x12	# ^R
DC3	= 0x13	# ^S
DC4	= 0x14	# ^T
NAK	= 0x15	# ^U
SYN	= 0x16	# ^V
ETB	= 0x17	# ^W
CAN	= 0x18	# ^X
EM	= 0x19	# ^Y
SUB	= 0x1a	# ^Z
ESC	= 0x1b	# ^[
FS	= 0x1c	# ^\
GS	= 0x1d	# ^]
RS	= 0x1e	# ^^
US	= 0x1f	# ^_
SP	= 0x20	# space
DEL	= 0x7f	# delete

controlnames = [
"NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL",
"BS",  "HT",  "LF",  "VT",  "FF",  "CR",  "SO",  "SI",
"DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB",
"CAN", "EM",  "SUB", "ESC", "FS",  "GS",  "RS",  "US",
"SP"
]

def _ctoi(c):
    if type(c) == type(""):
        return ord(c)
    else:
        return c

def isalnum(c): return isalpha(c) or isdigit(c)
def isalpha(c): return isupper(c) or islower(c)
def isascii(c): return _ctoi(c) <= 127		# ?
def isblank(c): return _ctoi(c) in (8,32)
def iscntrl(c): return _ctoi(c) <= 31
def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57
def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126
def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122
def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126
def ispunct(c): return _ctoi(c) != 32 and not isalnum(c)
def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11)
def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90
def isxdigit(c): return isdigit(c) or \
    (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102)
def isctrl(c): return _ctoi(c) < 32
def ismeta(c): return _ctoi(c) > 127

def ascii(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x7f)
    else:
        return _ctoi(c) & 0x7f

def ctrl(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x1f)
    else:
        return _ctoi(c) & 0x1f

def alt(c):
    if type(c) == type(""):
        return chr(_ctoi(c) | 0x80)
    else:
        return _ctoi(c) | 0x80

def unctrl(c):
    bits = _ctoi(c)
    if bits == 0x7f:
        rep = "^?"
    elif bits & 0x20:
        rep = chr((bits & 0x7f) | 0x20)
    else:
        rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20)
    if bits & 0x80:
        return "!" + rep
    return rep


--k1lZvvs/B4yU6o8G--


From tpeters@beopen.com  Mon Jun 26 19:41:12 2000
From: tpeters@beopen.com (Tim Peters)
Date: Mon, 26 Jun 2000 14:41:12 -0400
Subject: [Python-Dev] RE: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>

[Guido]
> It's official: I've changed the patch submission guidelines
> (http://www.python.org/patches/) to point to the patch manager at
> SourceForge.  We are no longer bound by CNRI's legal department, so
> the requirement for disclaimers or wet signatures is gone.

Yay!  Wonder how long that will last <wink>.

Attached is a first cut at documenting the intended use of SourceForge's
patch status tags, and the workflow associated with patch status changes.
The areas in need of fleshing out are marked with "[xxx ...]".  Gripe at
will.

I don't think anyone expects this to work smoothly at first.  Strive for
patience, and let's work to make SF a really *good* place for patches!

never-thought-i'd-actually-miss-lotus-notes-ly y'rs  - tim

PS:  I'll move this (& related info) to a reasonable place eventually, so
don't bother griping about email for now.


Intended use of SourceForge patch status tags
---------------------------------------------
revision 1                        26-Jun-2000


Open
    The initial status of all patches.
    The patch is under consideration, but has not
    been reviewed yet.
    The status will normally change to Accepted or Rejected next.
    The person submitting the patch should (if they can) assign
    it to the person they most want to review it.
    Else the patch will be assigned via
        [xxx a list of expertise areas should be developed]
    Discussion of patches is carried out via
        [xxx Python-Dev?  patches list?  without a mail gateway,
             the SourceForge patch interface looks too clumsy
             to use for controversial patches]
Accepted
    The powers that be have accepted the patch, but it has not
        been applied yet.
        [xxx flesh out -- Guido Bottleneck avoidable here?]
    The status will normally change to Closed next.
    The person changing the status to Accepted should, at the
    same time, assign the patch to whoever they believe is most
    likely to be able & willing to apply it (the submitter if
    possible).
Closed
    The patch has been accepted and applied.
    The previous status was Accepted, or possibly Open if the
    submitter was Guido (or moral equivalent in some particular
    area of expertise).
    If possible, the submitter should apply the patch and change
    the status to Closed.
    Else anyone with sufficient power should feel encouraged to
    do these on the submitter's behalf.
Rejected
    The patch has been reviewed and rejected.
    When the objections are addressed, the status may change to
    Open again.
    Note that SourceForge allows the submitter to overwrite the patch
    with a new version.
Out of date
    Previous status was Open or Accepted or Postponed, but the
    patch no longer works.
    Please enter a comment when changing the status to "Out of date",
    to record the nature of the problem and the previous status.
Postponed
    The previous status was Open or Accepted, but for some reason
    (e.g., pending release) the patch should not be reviewed or
    applied until further notice.
    The status will normally change to Open or Accepted next.
    Please enter a comment when changing the status to Postponed,
    to record the reason, the previous status, and the conditions
    under which the patch should revert to Open or Accepted.
Deleted
    Bit bucket.
    Use only if it's OK for the patch and its SourceForge history
    to disappear.
    As of 26-June-2000, SF does not actually throw away Deleted
    patches, but that may change.




From DavidA@ActiveState.com  Mon Jun 26 20:10:04 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Mon, 26 Jun 2000 12:10:04 -0700
Subject: [Python-Dev] semaphore support in thread_*.h
Message-ID: <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com>

I noticed that the support for the semaphore calls in the various thread_*
is very very spotty, with a comment in the BeOS implementation that read:

 * Guido says not to implement this because it's not used anywhere;
 * I'll do it anyway, you never know when it might be handy, and it's
 * easy...

(that last bit is not true of all implementations, apparently =).

1) Is it true that the sema_ calls are never used?

2) If yes, shouldn't we remove the sema_ calls from the thread API and have
similar functionality on all platforms?

(There are related issues re: for example whether async thread locking is
available, whether threads are joinable or not (see thread_cthread.h), etc.)

--david



From tpeters@beopen.com  Mon Jun 26 20:19:58 2000
From: tpeters@beopen.com (Tim Peters)
Date: Mon, 26 Jun 2000 15:19:58 -0400
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395770C2.B903724A@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEPFGFAA.tim_one@email.msn.com>

[MAL]
> Will there be a list which gets the patches mailed to it
> by SF ?
>
> I'm just asking because the current setup of having the patches
> available through mail really helps in discussing patch details.

I agree -- SF isn't (yet) good for patch discussions.  Plugging away, but
haven't yet figured out exactly when or how SF decides to send email.  In
particular, don't yet know how (or whether it's possible) to trick current
SF into populating a mailing list.




From guido@python.org  Mon Jun 26 21:24:57 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 15:24:57 -0500
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: Your message of "Mon, 26 Jun 2000 14:01:25 -0400."
 <20000626140125.A3266@thyrsus.com>
References: <20000626140125.A3266@thyrsus.com>
Message-ID: <200006262024.PAA01212@cj20424-a.reston1.va.home.com>

[ESR]
> Guido, can we get these into 1.6?  They're needed for the the ncurses 
> extensions I'm working on.

Eric,

We (PythonLabs + Andrew Kuchling & Greg Ward) discussed this at our
recent 1.6 planning meeting.  This doesn't have much use outside
curses.  Therefore, Andrew will check it in as a submodule of the new
curses package.

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


From fdrake@beopen.com  Mon Jun 26 20:24:40 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 12:24:40 -0700 (PDT)
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <20000626140125.A3266@thyrsus.com>
References: <20000626140125.A3266@thyrsus.com>
Message-ID: <14679.44536.931222.448738@mailhost.beopen.com>

Eric S. Raymond writes:
 > Guido, can we get these into 1.6?  They're needed for the the ncurses 
 > extensions I'm working on.

  This will be the curses.ascii module per a discussion last week
which included both Guido and Andrew.
  Andrew, my Unix machine is down for repairs; can you check these in
for me, changing the module name to curses.ascii in the documentation
file?  I don't want to hold up since Eric is still developing some of
the ncurses support.
  Thanks!


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From jeremy@beopen.com  Mon Jun 26 20:35:17 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 26 Jun 2000 15:35:17 -0400 (EDT)
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <20000626140125.A3266@thyrsus.com>
References: <20000626140125.A3266@thyrsus.com>
Message-ID: <14679.45173.439937.800007@bitdiddle.concentric.com>

The ascii module is going into the curses package.  Andrew Kuchling is
responsible for it.

Jeremy


From esr@thyrsus.com  Mon Jun 26 20:46:50 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Mon, 26 Jun 2000 15:46:50 -0400
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com>; from fdrake@beopen.com on Mon, Jun 26, 2000 at 12:24:40PM -0700
References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com>
Message-ID: <20000626154650.C3685@thyrsus.com>

Fred L. Drake, Jr. <fdrake@beopen.com>:
>   This will be the curses.ascii module per a discussion last week
> which included both Guido and Andrew.

OK, I guess.  It will be useful for more than curses, though, so I don't
understand the naming choice.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Hoplophobia (n.): The irrational fear of weapons, correctly described by 
Freud as "a sign of emotional and sexual immaturity".  Hoplophobia, like
homophobia, is a displacement symptom; hoplophobes fear their own
"forbidden" feelings and urges to commit violence.  This would be
harmless, except that they project these feelings onto others.  The
sequelae of this neurosis include irrational and dangerous behaviors
such as passing "gun-control" laws and trashing the Constitution.


From paul@prescod.net  Mon Jun 26 20:53:18 2000
From: paul@prescod.net (Paul Prescod)
Date: Mon, 26 Jun 2000 12:53:18 -0700
Subject: [Python-Dev] winreg
Message-ID: <3957B4AE.5562716C@prescod.net>

I haven't seen this message come through:

http://www.python.org/pipermail/python-dev/2000-June/006346.html

I'm not sure if I missed it due to an email problem.

 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
        - "This is your bill of rights...on drugs", Harpers, Dec. 1999


From fdrake@beopen.com  Mon Jun 26 20:59:10 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 12:59:10 -0700 (PDT)
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <20000626154650.C3685@thyrsus.com>
References: <20000626140125.A3266@thyrsus.com>
 <14679.44536.931222.448738@mailhost.beopen.com>
 <20000626154650.C3685@thyrsus.com>
Message-ID: <14679.46606.287276.330659@mailhost.beopen.com>

Eric S. Raymond writes:
 > OK, I guess.  It will be useful for more than curses, though, so I don't
 > understand the naming choice.

Eric,
  In theory, yes, but... there have not been a lot of requests for the
is*() functions (which are the ones I think you're referring to as
generally useful).  I think some of these are already take care of by
things like "if c in string.hexdigits:", and others can be handled by
making queries on the Unicode character properties.  Given the dearth
of requests for this, I don't see a clear need to place this
elsewhere.
  If feedback to the beta suggests a better location, we'll certainly
consider it!

  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From guido@python.org  Mon Jun 26 22:28:16 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 16:28:16 -0500
Subject: [Python-Dev] semaphore support in thread_*.h
In-Reply-To: Your message of "Mon, 26 Jun 2000 12:10:04 MST."
 <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com>
References: <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com>
Message-ID: <200006262128.QAA01518@cj20424-a.reston1.va.home.com>

> I noticed that the support for the semaphore calls in the various thread_*
> is very very spotty, with a comment in the BeOS implementation that read:
> 
>  * Guido says not to implement this because it's not used anywhere;
>  * I'll do it anyway, you never know when it might be handy, and it's
>  * easy...
> 
> (that last bit is not true of all implementations, apparently =).
> 
> 1) Is it true that the sema_ calls are never used?
> 
> 2) If yes, shouldn't we remove the sema_ calls from the thread API and have
> similar functionality on all platforms?
> 
> (There are related issues re: for example whether async thread locking is
> available, whether threads are joinable or not (see thread_cthread.h), etc.)

The sema_ calls aren't used anywhere in the current source.  I'd be
for removing them.  I'm not even sure why they are there -- maybe
Sjoerd remembers?  (This code was once part of something else than
Python.)

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


From akuchlin@mems-exchange.org  Mon Jun 26 22:28:26 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Mon, 26 Jun 2000 17:28:26 -0400
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com>
References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com>
Message-ID: <20000626172826.E2282@kronos.cnri.reston.va.us>

On Mon, Jun 26, 2000 at 12:24:40PM -0700, Fred L. Drake, Jr. wrote:
>  Andrew, my Unix machine is down for repairs; can you check these in
>for me, changing the module name to curses.ascii in the documentation
>file?  I don't want to hold up since Eric is still developing some of
>the ncurses support.

I'll do that tonight; I had no time for Python hacking over the weekend...

--amk


From mhammond@skippinet.com.au  Tue Jun 27 01:03:16 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Tue, 27 Jun 2000 10:03:16 +1000
Subject: [Python-Dev] winreg
In-Reply-To: <39577A23.EF7DE922@prescod.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au>

> I've just had a chance to look at the winreg module. I think that it is
> too low-level.

I agree.  There was a proposal (from Thomas Heller, IIRC) to do just this.
I successfully argued there should be _2_ modules for Python - the raw
low-level API, which guarantees you can do (almost) anything.  A
higher-level API could cover the 80% of cases.  It is probably worth
getting in touch with Thomas - he may be able to dig up his proposed
high-level API.  Ive CCd him on this message [I hope is _was_ you Thomas -
otherwise you will be wondering WTF I am on about :]

I was very keen to ensure the win32api code was used as the low-level API,
simply because it has been well tested and used.  We _know_ it has no
significant limitations.

Im happy to support a high-level API, but didnt have the inclination to
provide one.  Every one I have seen and every one I have tried to design
has started to fall-apart under real-world use - Ive needed to revert back
to the low-level.

> There are also bogus parameters that Microsoft hasn't got around to
> assigning values to, undocumented constants and so forth. My favorite is
> "WHOLE_HIVE_VOLATILE".

This is exactly my concern with a high-level API - you cant hope to capture
all this - especially the undocumented ones - so having a low-level API
means you can do anything, even stuff never dreamt of by the high-level
designer.

I have no real problem with your proposed design, as long as it it written
in Python, _using_ the low-level API.  It could be called "registry" or I
would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module
to be called "winreg.py"

Mark.



From tpeters@beopen.com  Mon Jun 26 23:13:42 2000
From: tpeters@beopen.com (Tim Peters)
Date: Mon, 26 Jun 2000 18:13:42 -0400
Subject: [Python-Dev] semaphore support in thread_*.h
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEAGGGAA.tim_one@email.msn.com>

[David Ascher]
> I noticed that the support for the semaphore calls in the various thread_*
> is very very spotty, with a comment in the BeOS implementation that read:
>
>  * Guido says not to implement this because it's not used anywhere;
>  * I'll do it anyway, you never know when it might be handy, and it's
>  * easy...

> (that last bit is not true of all implementations, apparently =).
>
> 1) Is it true that the sema_ calls are never used?

Best I can tell, the following sema functions are indeed never used:

    PyThread_allocate_sema
    PyThread_free_sema
    PyThread_down_sema
    PyThread_up_sema

the following #define's are never used:

    WAIT_SEMA
    NOWAIT_SEMA

and the following non-sema pythread.h functions are not only never used,
they're defined only in thread_sgi.h:

    PyThread_create_key
    PyThread_delete_key
    PyThread_set_key_value
    PyThread_get_key_value

> 2) If yes, shouldn't we remove the sema_ calls from the thread
> API and have similar functionality on all platforms?

+1 from me.  If someone wants platform-specific thread functions, they
should be in a platform-specific extension module, not messing up the core.

> (There are related issues re: for example whether async thread locking is
> available, whether threads are joinable or not (see
> thread_cthread.h), etc.)

Sorry, don't know what you're getting at here (e.g., have any specific line
or function of thread_cthread.h in mind?).





From fdrake@beopen.com  Mon Jun 26 23:25:42 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 15:25:42 -0700 (PDT)
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com>
References: <14679.32536.133849.573542@mailhost.beopen.com>
 <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com>
Message-ID: <14679.55398.996503.269852@mailhost.beopen.com>

Tim Peters writes:
 > Fred, would you please explain how that works or where that was set up?
 > I've puttered away many hours now playing with the SourceForge facilities

  From the "project page", go to "Project Admin" on the left
navigation bar, then "Edit Public Info" at the top of the page.  There
are places to edit some email addresses near the bottom of the page.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From tpeters@beopen.com  Mon Jun 26 22:38:51 2000
From: tpeters@beopen.com (Tim Peters)
Date: Mon, 26 Jun 2000 17:38:51 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <14679.32536.133849.573542@mailhost.beopen.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com>

[Fred]
>   patches@python.org should get messages of patch manager activity (at
> least certain actions; not sure which ones yet, but at least
> additions).

Fred, would you please explain how that works or where that was set up?
I've puttered away many hours now playing with the SourceForge facilities
(alas, most of that time waiting for web pages to load), but haven't
stumbled into anything that hints the patch manager knows anything about
patches@python.org.

so-stupid-in-so-many-ways-ly y'rs  - tim




From tpeters@beopen.com  Tue Jun 27 00:14:06 2000
From: tpeters@beopen.com (Tim Peters)
Date: Mon, 26 Jun 2000 19:14:06 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <14679.55398.996503.269852@mailhost.beopen.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEALGGAA.tim_one@email.msn.com>

[Fred L. Drake, Jr.]
>   From the "project page", go to "Project Admin" on the left
> navigation bar, then "Edit Public Info" at the top of the page.  There
> are places to edit some email addresses near the bottom of the page.

Aha!  The one & only link I had never clicked -- I bet I could have figured
that out myself in another week or two <wink>.  Thank you.

Now why do we have "Use Bug Tracker" checked?  If nobody objects, I'll turn
that off -- we're still doing bugs w/ Jitterbug on python.org.

ten-stop-shopping-ly y'rs  - tim




From guido@beopen.com  Tue Jun 27 03:35:52 2000
From: guido@beopen.com (Guido van Rossum)
Date: Mon, 26 Jun 2000 21:35:52 -0500
Subject: [Python-Dev] ANN: Release schedule
Message-ID: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>

Here at BeOpen we're scrambling to get the release schedule for the
rest of Python 1.6 planned.  We're now looking at releasing Python
1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
This means that if SRE isn't ready, we'll go with an incomplete SRE.
Still better than no SRE!

Please, PLEASE, if you have pending patches that you think should go
into 1.6b1, submit them to SourceForge.  We'll do our best to have a
look at every patch submitted; but don't wait until the last moment.
(Trent Mick, it would be helpful if you assigned each of your patches
a potential reviewer from the list of existing developers -- that way
we can split up the review load.)

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


From trentm@activestate.com  Tue Jun 27 04:52:59 2000
From: trentm@activestate.com (Trent Mick)
Date: Mon, 26 Jun 2000 20:52:59 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pyexpat.py,1.2,1.3
In-Reply-To: <200006270037.RAA25539@slayer.i.sourceforge.net>
References: <200006270037.RAA25539@slayer.i.sourceforge.net>
Message-ID: <20000626205259.A3866@activestate.com>

On Mon, Jun 26, 2000 at 05:37:27PM -0700, A . M . Kuchling wrote:
> Update of /cvsroot/python/python/dist/src/Lib/test
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv25501
> 
> Modified Files:
> 	test_pyexpat.py 
> Log Message:
> Change pyexpat test suite to exercise the .returns_unicode attribute,
> parsing the sample data once with 8-bit strings and once with Unicode.
> 

Does this require a new Lib/test/output/test_pyexpat?


Trent


-- 
Trent Mick
trentm@activestate.com


From DavidA@ActiveState.com  Tue Jun 27 06:34:13 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Mon, 26 Jun 2000 22:34:13 -0700
Subject: [Python-Dev] semaphore support in thread_*.h
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEAGGGAA.tim_one@email.msn.com>
Message-ID: <LMBBIEIJKMPMLBONJMFCEEHJCJAA.DavidA@ActiveState.com>

> > (There are related issues re: for example whether async thread
> locking is
> > available, whether threads are joinable or not (see
> > thread_cthread.h), etc.)
>
> Sorry, don't know what you're getting at here (e.g., have any
> specific line
> or function of thread_cthread.h in mind?).

	/* looks like solaris detaches the thread to never rejoin
	 * so well do it here
	 */

in thread_cthread.h

The async thread locking comment was one of my personal issues -- I
considered briefly providing a thread layer on top of the NSPR (Netscape
Portable runtime) which is part of Mozilla.  It has locks, but no async
locking calls.

--david



From rob@hooft.net  Tue Jun 27 10:32:02 2000
From: rob@hooft.net (Rob W. W. Hooft)
Date: Tue, 27 Jun 2000 11:32:02 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1
In-Reply-To: <200006262355.QAA17089@slayer.i.sourceforge.net>
References: <200006262355.QAA17089@slayer.i.sourceforge.net>
Message-ID: <14680.29842.372192.274003@temoleh.chem.uu.nl>

 AMK> Update of /cvsroot/python/python/dist/src/Lib/curses
 AMK> In directory slayer.i.sourceforge.net:/tmp/cvs-serv17079

 AMK> Added Files:
 AMK> ascii.py textpad.py 
 AMK> Log Message:
 AMK> Added two modules for ASCII characters and a simple editing form (ESR)


 AMK> --- NEW FILE ---
 AMK> #
 AMK> # ascii.py -- constants and memembership tests for ASCII characters
 AMK> #
                                  ^^^^^ two letters too much?

Rob


From gvwilson@nevex.com  Tue Jun 27 11:30:55 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Tue, 27 Jun 2000 06:30:55 -0400 (EDT)
Subject: [Python-Dev] C# (new language from Microsoft)
Message-ID: <Pine.LNX.4.10.10006270630080.4977-100000@akbar.nevex.com>

I'm sure many of you will have seen this announcement already, but for
those who haven't, Microsoft is launching a new language to compete with
C, C++, and Java:

http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp

Greg



From Fredrik Lundh" <effbot@telia.com  Tue Jun 27 11:35:22 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 12:35:22 +0200
Subject: [Python-Dev] ANN: Release schedule
References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>
Message-ID: <017501bfe023$684fca40$f2a6b5d4@hagrid>

guido wrote:


> Here at BeOpen we're scrambling to get the release schedule for the
> rest of Python 1.6 planned.  We're now looking at releasing Python
> 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
> This means that if SRE isn't ready, we'll go with an incomplete SRE.
> Still better than no SRE!

a major SRE patch is coming up later today.

btw, what would it take for me to check it in myself (assuming someone
will give me commit privs, of course)?  can I apply patches via =
sourceforge's
web interface, or do I have to figure out how to run cvs over ssh etc =
etc

(tim? where's the second installment of your sourceforge vs. windows =
series?)

</F>



From gmcm@hypernet.com  Tue Jun 27 11:36:07 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Tue, 27 Jun 2000 06:36:07 -0400
Subject: [Python-Dev] winreg
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au>
References: <39577A23.EF7DE922@prescod.net>
Message-ID: <1250020276-32999633@hypernet.com>

Mark wrote:

[Paul]
> > I've just had a chance to look at the winreg module. I think
> > that it is too low-level.
> 
> I agree.  There was a proposal (from Thomas Heller, IIRC) to do
> just this. I successfully argued there should be _2_ modules for
> Python - the raw low-level API, which guarantees you can do
> (almost) anything.  A higher-level API could cover the 80% of
> cases.  It is probably worth getting in touch with Thomas - he
> may be able to dig up his proposed high-level API.  

Found it.

------- Forwarded message follows -------
From:           	"Thomas Heller" <thomas.heller@ion-
tof.com>
To:             	<python-dev@python.org>, <distutil-
sig@python.org>
Date sent:      	Thu, 3 Feb 2000 14:27:00 +0100
Subject:        	[Python-Dev] Revised proposal (and 
preliminary implementation): Registry access module for 
Python on Windows

Ok, at least the first proposal did start the discussion.
Here is a revised one:

A preliminary implementation is available at
http://starship.python.net/crew/theller/

-----------------------------------------------------------------
----- winreg - windows registry access module

Exception:
  error - raised when a function fails. Will contain
    a windows error code and a textual description.

Objects:
  regnode object - represents a open key in the
  registry.

Functions:
  OpenKey (name) -> regnode object
    Opens an existing key with the specified access rights
    and returns a regnode object.
    name is specified like "HKLM\Software\Python"
    or "HKEY_LOCAL_MACHINE\Software\Python"

  CreateKey (name) -> regnode object
    Creates a new key or opens an existing one
    and returns a regnode object.
    For the name format see OpenKey

regnode object methods:
  Values () -> dict
    Returns a dictionary mapping names to values.
    The <default> or unnamed value has the key ''.
    The values are either strings or integers, depending
    on the REG_* type.

  GetValue ([name]) -> integer or string
    Returns a value specified by name or the default value.

  SetValue ([name,] value)
    Set a named or the <default> value.
    Named values must be integers or string (which are stored 
as
    REG_DWORD or REG_SZ). Should an optional third 
parameter be
    used, allowing to store in other REG_* typecodes? I dont
    think so.

  DeleteValue ([name])
    Deletes a named or the <default> value.

  SubKeys () -> sequence
    Returns a sequence containing the names of all subkeys.

  DeleteKey (name [,recursive=0])
    If recursive is 0, deletes the named key if no subkeys exist.
    If there are subkeys an error is raised.    If recursive is
    not 0, the named key is deleted including subkeys.

  OpenKey (name) -> regnode object
    Openes an existing subkey and returns a regnode
    object pointing to it.

  CreateKey (name) -> regnode object
    Creates a new or openes an existing subkey and
    returns a regnode object pointing to it.

regnode objects have the following properties:
  name - the name of the RegistryKey, something
    like "HKLM\Software\Python"
  hkey - the integer keyhandle

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

Thomas Heller





_______________________________________________
Python-Dev maillist  -  Python-Dev@python.org
http://www.python.org/mailman/listinfo/python-dev
------- End of forwarded message -------

- Gordon


From gstein@lyra.org  Tue Jun 27 11:52:02 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 03:52:02 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
In-Reply-To: <200006270050.RAA26210@slayer.i.sourceforge.net>; from akuchling@users.sourceforge.net on Mon, Jun 26, 2000 at 05:50:42PM -0700
References: <200006270050.RAA26210@slayer.i.sourceforge.net>
Message-ID: <20000627035202.M29590@lyra.org>

I just don't buy this.

Look at that code. Look at the definition of finally. That code simply
screams for the use of finally.

Eric: just what happens? What is "broke things"? Do you have a reproducible
test case that I can use?

In good conscience, I have to disagree with reverting this stuff. If we're
seeking to make the code the best possible, then this is a backward step.
Besides its redundancy, it also places the traceback into a local variable
and then raises an exception -- a perfect recipe for creating a ref loop.

Cheers,
-g

On Mon, Jun 26, 2000 at 05:50:42PM -0700, A.M. Kuchling wrote:
> Update of /cvsroot/python/python/dist/src/Lib/curses
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv26153
> 
> Modified Files:
> 	wrapper.py 
> Log Message:
> Drop back to old version of wrapper(); ESR reports that it broke things,
> and I lack the time to track down the cause.
> 
> 
> Index: wrapper.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/curses/wrapper.py,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -C2 -r1.2 -r1.3
> *** wrapper.py	2000/06/10 23:39:05	1.2
> --- wrapper.py	2000/06/27 00:50:40	1.3
> ***************
> *** 18,24 ****
> --- 18,26 ----
>       """
>       
> +     res = None
>       try:
>   	# Initialize curses
>   	stdscr=curses.initscr()
> +         
>   	# Turn off echoing of keys, and enter cbreak mode,
>   	# where no buffering is performed on keyboard input
> ***************
> *** 30,39 ****
>           stdscr.keypad(1)
>   
> ! 	return apply(func, (stdscr,) + rest)
> ! 
> !     finally:
> ! 	# Restore the terminal to a sane state on the way out.
>   	stdscr.keypad(0)
>   	curses.echo() ; curses.nocbreak()
>   	curses.endwin()
>   
> --- 32,51 ----
>           stdscr.keypad(1)
>   
> !         res = apply(func, (stdscr,) + rest)
> !     except:
> ! 	# In the event of an error, restore the terminal
> ! 	# to a sane state.
>   	stdscr.keypad(0)
>   	curses.echo() ; curses.nocbreak()
>   	curses.endwin()
> +         
> +         # Pass the exception upwards
> +         (exc_type, exc_value, exc_traceback) = sys.exc_info()
> +         raise exc_type, exc_value, exc_traceback
> +     else:
> + 	# Set everything back to normal
> + 	stdscr.keypad(0)
> + 	curses.echo() ; curses.nocbreak()
> + 	curses.endwin()		 # Terminate curses
>   
> +         return res
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins@python.org
> http://www.python.org/mailman/listinfo/python-checkins

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


From thomas.heller@ion-tof.com  Tue Jun 27 12:09:24 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Tue, 27 Jun 2000 13:09:24 +0200
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au>
Message-ID: <019601bfe028$281dab90$4500a8c0@thomasnb>

> > I've just had a chance to look at the winreg module. I think that it is
> > too low-level.
>
> I agree.  There was a proposal (from Thomas Heller, IIRC) to do just this.
> I successfully argued there should be _2_ modules for Python - the raw
> low-level API, which guarantees you can do (almost) anything.  A
> higher-level API could cover the 80% of cases.  It is probably worth
> getting in touch with Thomas - he may be able to dig up his proposed
> high-level API.  Ive CCd him on this message [I hope is _was_ you Thomas -
> otherwise you will be wondering WTF I am on about :]
Yes, it was me :-)

Here is the 3. (final?) proposal, earlier ones are in the archives:
http://www.python.org/pipermail/python-dev/2000-February/003417.html
and
http://www.python.org/pipermail/python-dev/2000-February/003472.html

----------------------------------------------------------------------
winreg - windows registry access module

Exception:
  error - raised when a function fails. Will contain
    a windows error code and a textual description.

Objects:
  regkey object - represents a open key in the
  registry.

Functions:
  OpenKey (name) -> regkey object
    Opens an existing key with the specified access rights
    and returns a regkey object.
    name is specified like "HKLM\Software\Python"
    or "HKEY_LOCAL_MACHINE\Software\Python"

  CreateKey (name) -> regkey object
    Creates a new key or opens an existing one
    and returns a regkey object.
    For the name format see OpenKey

regkey object methods:
  Standard Mapping protocol:
  len (r)
  r[k]
  r[k] = x
  del r[k]
  r.clear()
  r.has_key(k)
  r.items()
  r.keys()
  r.update(dict)
  r.values()
  r.get(k[, x])

  todict() -> dictionary
    Returns a dictionary mapping value names to values.

  SubKeys () -> sequence
    Returns a sequence containing the names of all subkeys.

  DeleteKey (name [,recursive=0])
    If recursive is 0, deletes the named key if no subkeys exist.
    If there are subkeys an error is raised.
    If recursive is not 0, the named key is deleted
    including subkeys.

  OpenKey (name) -> regkey object
    Openes an existing subkey and returns a regkey
    object pointing to it.

  CreateKey (name) -> regkey object
    Creates a new or openes an existing subkey and
    returns a regkey object pointing to it.

regkey objects have the following properties:
  name - the name of the RegistryKey, something
    like "HKLM\Software\Python"
  hkey - the integer keyhandle

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

It would not be too much work to implement it, but
I will be away the next 20 days...

> I have no real problem with your proposed design, as long as it it written
> in Python, _using_ the low-level API.  It could be called "registry" or I
> would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module
> to be called "winreg.py"
>
If we change the name of the low level api module, we have to change
Distutils,
because it is used there. Maybe we would better use the high level api then,
but there is still this 1.5 compatibility using the win32api module.

Thomas



From guido@beopen.com  Tue Jun 27 13:23:36 2000
From: guido@beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 07:23:36 -0500
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: Your message of "Tue, 27 Jun 2000 12:35:22 +0200."
 <017501bfe023$684fca40$f2a6b5d4@hagrid>
References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>
 <017501bfe023$684fca40$f2a6b5d4@hagrid>
Message-ID: <200006271223.HAA01391@cj20424-a.reston1.va.home.com>

[effbot]
> a major SRE patch is coming up later today.

Great!

> btw, what would it take for me to check it in myself (assuming someone
> will give me commit privs, of course)?  can I apply patches via sourceforge's
> web interface, or do I have to figure out how to run cvs over ssh etc etc

Erm, the latter.  From a Unix system it's a breeze.  From Windows,
it's a relative breeze to do an *anonymous* checkout (no SSH
required), but getting commit permission is a pain -- Tim will
research this.  (Do you have access to any Unix or Linux system at
all?)

I'll make you a developer anyway.

> (tim? where's the second installment of your sourceforge vs. windows series?)

I'm waiting too!

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


From guido@beopen.com  Tue Jun 27 15:30:30 2000
From: guido@beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 09:30:30 -0500
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Mon, 26 Jun 2000 17:38:51 -0400."
 <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com>
Message-ID: <200006271430.JAA01769@cj20424-a.reston1.va.home.com>

> [Fred]
> >   patches@python.org should get messages of patch manager activity (at
> > least certain actions; not sure which ones yet, but at least
> > additions).

[Tim]
> Fred, would you please explain how that works or where that was set up?
> I've puttered away many hours now playing with the SourceForge facilities
> (alas, most of that time waiting for web pages to load), but haven't
> stumbled into anything that hints the patch manager knows anything about
> patches@python.org.

Yes, it's hidden, and Fred had to show me too.

First, login to SourceForge.  Then, go to the Python Project.  In the
left sidebar, under Project: Python, go to Project Admin.  Near the
top, you now see some navigation links; go to Edit Public Info.
At the very bottom there are three text fields for email addresses.

The address for New Patches (a misnomer -- it's really all changes
made to the Patch Manager) says patches@python.org.

The address for New Bugs is currently set to guido@beopen.com.  I
suppose I should set it to pythoneers@beopen.com or even to
python-dev@python.org?

We're not using the Support manager yet.

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


From mhammond@skippinet.com.au  Tue Jun 27 15:45:07 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Wed, 28 Jun 2000 00:45:07 +1000
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
In-Reply-To: <20000627035202.M29590@lyra.org>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEICCOAA.mhammond@skippinet.com.au>

> Besides its redundancy, it also places the traceback into a
> local variable
> and then raises an exception -- a perfect recipe for creating a ref loop.

Isnt it true that _every_ time you store a traceback object as a local
variable, and that traceback has a reference to the frame holding the
local, you _always_ get a reference loop, regardless of how you exit the
function?

ie, I believe that _every_ time you store a traceback obtained from inside
an except handler, you _always_ get a ref-loop, period.  The only way to
clean the cycle is to explictly unbind the local from the traceback.

Mark.




From mhammond@skippinet.com.au  Tue Jun 27 15:39:15 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Wed, 28 Jun 2000 00:39:15 +1000
Subject: [Python-Dev] C# (new language from Microsoft)
In-Reply-To: <Pine.LNX.4.10.10006270630080.4977-100000@akbar.nevex.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEIBCOAA.mhammond@skippinet.com.au>

I cant say much, as I am still under NDA.  However, I probably can say:

* C Sharp is really not the interesting part of this technology.  MS are
controlling the way (the order, really) the information is coming out; as
more info comes out, C Sharp should move back into perspective for what is
really is.  Suffice it to say, hardly anyone on slashdot is even in the
ball-park!

* The MS PDC in a couple of weeks will be the official announcement of the
more interesting things.  After this, everyone involved in the project will
be completely free to discuss all they know, including me (and a few other
Pythoneers)

* Python has a very good and interesting story in all this - there is no
need to be alarmed.  If anything, be excited :-)

Mark.

> -----Original Message-----
> From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On
> Behalf Of Greg Wilson
> Sent: Tuesday, 27 June 2000 8:31 PM
> To: Python Developers
> Subject: [Python-Dev] C# (new language from Microsoft)
>
>
> I'm sure many of you will have seen this announcement already, but for
> those who haven't, Microsoft is launching a new language to compete with
> C, C++, and Java:
>
> http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp
>
> Greg
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev
>



From paul@prescod.net  Tue Jun 27 16:15:29 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:15:29 -0700
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb>
Message-ID: <3958C511.17282EF7@prescod.net>

Mark, Thomas and whoever, thanks for your input and I hope you can spare
some more...

Thomas Heller wrote:
> 

This is similar to what I have implemented...

> ----------------------------------------------------------------------
> winreg - windows registry access module
> 
> Exception:
>   error - raised when a function fails. Will contain
>     a windows error code and a textual description.

As an aside, I notice that the winreg documentation says it will raise
an EnvironmentError but it actually raises a WindowsError. 

> Objects:
>   regkey object - represents a open key in the
>   registry.

Right. Even the same name.

My stance was that keys would always be created from keys, so you would
start with

HKEY_LOCAL_MACHINE.CreateKey("Software\Python")

That mirrors the underlying API a little closer and reduces the number
of functions to 0.

The question is whether the CreateKey and OpenKey functions are
important enough as "convenience functions".

> regkey object methods:
>   Standard Mapping protocol:
>   len (r)
>   r[k]
>   r[k] = x
>   del r[k]
>   r.clear()
>   r.has_key(k)
>   r.items()
>   r.keys()
>   r.update(dict)
>   r.values()
>   r.get(k[, x])

I had a separate object for values. I couldn't really justify elevating
either the Subkeys or the Values. I tried to treat them as alike as
possible.

>   todict() -> dictionary
>     Returns a dictionary mapping value names to values.

I called this getValues() and it returned an object that was both a
mapping and a sequence and allowed read/write/delete of values.

>   SubKeys () -> sequence
>     Returns a sequence containing the names of all subkeys.
> 
>   DeleteKey (name [,recursive=0])
>     If recursive is 0, deletes the named key if no subkeys exist.
>     If there are subkeys an error is raised.
>     If recursive is not 0, the named key is deleted
>     including subkeys.

I may or may not get around to implementing the recursive version. You
have to be VERY CAREFUL when you test such a thing. :)

>   OpenKey (name) -> regkey object
>     Openes an existing subkey and returns a regkey
>     object pointing to it.

Okay.

>   CreateKey (name) -> regkey object
>     Creates a new or openes an existing subkey and
>     returns a regkey object pointing to it.

Okay.

> regkey objects have the following properties:
>   name - the name of the RegistryKey, something
>     like "HKLM\Software\Python"

Okay.

>   hkey - the integer keyhandle

Is this really useful? Better to use the low-level API in that case...

> If we change the name of the low level api module, we have to change
> Distutils,
> because it is used there. Maybe we would better use the high level api then,
> but there is still this 1.5 compatibility using the win32api module.

The high level could probably be made compatible with 1.5 like this:

try:
    import _winreg
except ImportError:
    import win32api
    winreg=win32api

It would probably be good for DistUtils to use the high level API as
soon as it is possible for testing purposes.

I am considering doing away with the two enumeration interfaces. The
cost/benefit of having two more objects is probably low.

We can simplify the whole thing by just using methods on the regkey
object:

deleteValue(name) 
getValue(name)-> (type, value)
setValue(name,(type,value))
getValueNames() -> List of strings

getSubkey(name) -> regkey
deleteSubkey(name)
getSubkeyNames( ) -> List of strings

Iterating will be slightly less efficient because it will loop twice,
once to gather the names and once to do whatever you need to do but
that's not the typical registry use case anyhow. Anyone who needs
absolute performance can use the low-level API.

Recursive iteration under the existing model:

def doit( key ):
    for subkey in key.getSubkeyNames():
        doit( subkey )

Recursive iteration under the proposed model:

def doit( key ):
    for keyname in key.getSubkeyNames():
        doit( key.getSubkey( name ))

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999


From paul@prescod.net  Tue Jun 27 16:28:55 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:28:55 -0700
Subject: [Python-Dev] winreg features
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb>
Message-ID: <3958C837.ECD925CC@prescod.net>

There are a few features missing from the proposed API. I don't think
that this API should serve the 80%, but rather the 97%. The only things
I plan to exclude from the low level API are things that are
undocumented and a little bit of performance.

I see no reason not to add support for close, flush, save, remote keys
and REG_FOO types.

If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add
support for that too. :)

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999


From paul@prescod.net  Tue Jun 27 16:29:16 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:29:16 -0700
Subject: [Python-Dev] winreg features
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb>
Message-ID: <3958C84C.37C3EAD@prescod.net>

There are a few features missing from the proposed API. I don't think
that this API should serve the 80%, but rather the 97%. The only things
I plan to exclude from the low level API are things that are
undocumented and a little bit of performance. I want to simplify the
API, not dumb it down.

I see no reason not to add support for close, flush, save, remote keys
and REG_FOO types.

If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add
support for that too. :)

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999


From thomas.heller@ion-tof.com  Tue Jun 27 16:42:26 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Tue, 27 Jun 2000 17:42:26 +0200
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net>
Message-ID: <02e201bfe04e$4cecc700$4500a8c0@thomasnb>

(Hopefully it is ok to use the reply-all button)

> ...
> My stance was that keys would always be created from keys, so you would
> start with
>
> HKEY_LOCAL_MACHINE.CreateKey("Software\Python")
>
> That mirrors the underlying API a little closer and reduces the number
> of functions to 0.
Good idea!
Maybe HKLM and so on should be provided as aliases.

> >
> >   DeleteKey (name [,recursive=0])
> >     If recursive is 0, deletes the named key if no subkeys exist.
> >     If there are subkeys an error is raised.
> >     If recursive is not 0, the named key is deleted
> >     including subkeys.
>
> I may or may not get around to implementing the recursive version. You
> have to be VERY CAREFUL when you test such a thing. :)
Someone (I don't remember who) mentioned in the discussion
about my proposal that one should use SHDeleteKey for recursive
deletion of keys. See the MSDN docs on RegDeleteKey for details.
Don't know if this is exposed by the lowlevel module.

>
> > If we change the name of the low level api module, we have to change
> > Distutils,
> > because it is used there. Maybe we would better use the high level api
then,
> > but there is still this 1.5 compatibility using the win32api module.
>
> The high level could probably be made compatible with 1.5 like this:
>
> try:
>     import _winreg
> except ImportError:
>     import win32api
>     winreg=win32api
Currently it goes like this, because win32api and winreg (which
will soon be _winreg) have slightly different apis, but it will
doubtlessly be solved:

try:
    import winreg
    _can_read_reg = 1
    hkey_mod = winreg

    RegOpenKeyEx = winreg.OpenKeyEx
    RegEnumKey = winreg.EnumKey
    RegEnumValue = winreg.EnumValue
    RegError = winreg.error

except ImportError:
    try:
        import win32api
        import win32con
        _can_read_reg = 1
        hkey_mod = win32con

        RegOpenKeyEx = win32api.RegOpenKeyEx
        RegEnumKey = win32api.RegEnumKey
        RegEnumValue = win32api.RegEnumValue
        RegError = win32api.error

    except ImportError:
        pass

Thomas



From paul@prescod.net  Tue Jun 27 16:52:27 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:52:27 -0700
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb>
Message-ID: <3958CDBB.3F354C97@prescod.net>

Right now the Python list is a little slow (at least for me) so I
appreciate cc:s directly to me.

Thomas Heller wrote:
> 
> Good idea!
> Maybe HKLM and so on should be provided as aliases.

Sure.

> Someone (I don't remember who) mentioned in the discussion
> about my proposal that one should use SHDeleteKey for recursive
> deletion of keys. See the MSDN docs on RegDeleteKey for details.
> Don't know if this is exposed by the lowlevel module.

Don't think so.

> Currently it goes like this, because win32api and winreg (which
> will soon be _winreg) have slightly different apis, but it will
> doubtlessly be solved:

Ouch. I don't know if I have time to figure out all of the
correspondances. Are the only differences those four method names or are
those the only four differences that DistUtils happened to care about.
I'm not interested in 1.5 compatibility if it will take a lot of work.

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999


From thomas.heller@ion-tof.com  Tue Jun 27 17:03:30 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Tue, 27 Jun 2000 18:03:30 +0200
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net>
Message-ID: <02fe01bfe051$3df655b0$4500a8c0@thomasnb>

> Right now the Python list is a little slow (at least for me) so I
> appreciate cc:s directly to me.
Same for me: All python lists take hours to distribute the mails.

> > Someone (I don't remember who) mentioned in the discussion
> > about my proposal that one should use SHDeleteKey for recursive
> > deletion of keys. See the MSDN docs on RegDeleteKey for details.
> > Don't know if this is exposed by the lowlevel module.
>
> Don't think so.
The tricky thing is: Deletion of keys behaves differently
on Win95/98 and NT/2000.
(Quoting MSDN:)
The RegDeleteKey function deletes a subkey.

Windows 95/98: The function also deletes all subkeys and values. To delete a
key only if the key has no subkeys or values, use the SHDeleteEmptyKey
function.

Windows NT/2000: The subkey to be deleted must not have subkeys. To delete a
key and all its subkeys, you need to recursively enumerate the subkeys and
delete them individually. To recursively delete keys, use the SHDeleteKey
function.
(end quote)

The SHDelete* funtions require version 4.71 of shlwapi.dll, which
is included in Win98 or 2000 (or in IE 4.0).

>
> > Currently it goes like this, because win32api and winreg (which
> > will soon be _winreg) have slightly different apis, but it will
> > doubtlessly be solved:
>
> Ouch. I don't know if I have time to figure out all of the
> correspondances. Are the only differences those four method names or are
> those the only four differences that DistUtils happened to care about.
> I'm not interested in 1.5 compatibility if it will take a lot of work.
So you should simply ignore this. We will work it out on distutils.

Thomas
(I will disappear soon for holidays)



From Vladimir.Marangozov@inrialpes.fr  Tue Jun 27 17:23:52 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Tue, 27 Jun 2000 18:23:52 +0200 (CEST)
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 26, 2000 09:35:52 PM
Message-ID: <200006271623.SAA04926@python.inrialpes.fr>

Guido van Rossum wrote:
> 
> Here at BeOpen we're scrambling to get the release schedule for the
> rest of Python 1.6 planned.  We're now looking at releasing Python
> 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
> This means that if SRE isn't ready, we'll go with an incomplete SRE.
> Still better than no SRE!
> 
> Please, PLEASE, if you have pending patches that you think should go
> into 1.6b1, submit them to SourceForge.  We'll do our best to have a
> look at every patch submitted; but don't wait until the last moment.

So, to sum up (because I'm a bit lost after all this patch-related
messages), what should I do to avoid at best adding to the collective
burden :

1. Should I send patches to SF and be quiet until June 30 ?

2. Should I apply for privileges and spend <big time> installing
   an SSH client on my box (illegal in France ;), then make my Python
   way into the SF galaxy ?

3. If I volunteer for help with the patches backlog, what do I do ?

4. Other options presented to me ?

Context : I (will) have some patches lying around, there are some
patches of mine on the pile sent to patches@python.org that I'm
confident about, I have read the FAQ at SF which gave me 0 clues
on how things are being set up there (only general info about
who why and what for + terms of service), and I managed to create
an account with a personal page containing two bookmarks in it
(after being distracted with personal and project ratings + gobs of
links to gobs of stuff).

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From guido@beopen.com  Tue Jun 27 18:27:24 2000
From: guido@beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 12:27:24 -0500
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: Your message of "Tue, 27 Jun 2000 18:23:52 +0200."
 <200006271623.SAA04926@python.inrialpes.fr>
References: <200006271623.SAA04926@python.inrialpes.fr>
Message-ID: <200006271727.MAA03564@cj20424-a.reston1.va.home.com>

> 1. Should I send patches to SF and be quiet until June 30 ?

Yes.  Not too quiet -- helping selecting which old patches are good
would help.  Also downloading patches from SF and commenting on them
(+1/-1) in the patches list would help.

> 2. Should I apply for privileges and spend <big time> installing
>    an SSH client on my box (illegal in France ;), then make my Python
>    way into the SF galaxy ?

Probably no.

> 3. If I volunteer for help with the patches backlog, what do I do ?

Go through the patches archives and review patches.  If you find one
for which you would vote +1 and which you think I might like, submit
it to SF.

> 4. Other options presented to me ?
> 
> Context : I (will) have some patches lying around, there are some
> patches of mine on the pile sent to patches@python.org that I'm
> confident about, I have read the FAQ at SF which gave me 0 clues
> on how things are being set up there (only general info about
> who why and what for + terms of service), and I managed to create
> an account with a personal page containing two bookmarks in it
> (after being distracted with personal and project ratings + gobs of
> links to gobs of stuff).

Go to the Python Project Summary, then to the Patch Manager.  At the
top, click on Submit Patch.

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


From mal@lemburg.com  Tue Jun 27 17:38:54 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 27 Jun 2000 18:38:54 +0200
Subject: [Python-Dev] SF patch manager...
Message-ID: <3958D89E.39D084C8@lemburg.com>

[Please excuse my ranting... :-)]

I've received the first round of notification message from the
patch manager and can't really say that I like them. Ok, I 
understand that the patch manager is still alpha or beta software,
but these messages really don't have any usable content at all:

"""
Patch #100646 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470
"""

Also, reviewing the patches has become a pain and discussing them
is nearly impossible (I don't consider the slashdot like comment
mechanism to be of any use: there's simply no audience for
discussion).

Is there any chance of tee'ing patches from SF to the patches
list or some other patch discussion and review forum ? I do
understand that the mechanism can help with patch *checkins*,
but it's certainly not going to help much with the discussion
step needed before conidering any actions. The independent
peer review principal doesn't work with this kind of setup.

Ok, enough whining, let's get on with business now ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From esr@thyrsus.com  Tue Jun 27 17:50:53 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Tue, 27 Jun 2000 12:50:53 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
In-Reply-To: <20000627035202.M29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 03:52:02AM -0700
References: <200006270050.RAA26210@slayer.i.sourceforge.net> <20000627035202.M29590@lyra.org>
Message-ID: <20000627125053.B6531@thyrsus.com>

Greg Stein <gstein@lyra.org>:
> I just don't buy this.
> 
> Look at that code. Look at the definition of finally. That code simply
> screams for the use of finally.
> 
> Eric: just what happens? What is "broke things"? Do you have a reproducible
> test case that I can use?

What happened is that your version failed to pass an error exception upwards
after fielding it.  My test case was a buggy version of cmlconfigure.py, bug
since fixed.

Cleanliness is good, but the code has to work first.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Faith may be defined briefly as an illogical belief in the occurrence
of the improbable...A man full of faith is simply one who has lost (or
never had) the capacity for clear and realistic thought. He is not a
mere ass: he is actually ill.
	-- H. L. Mencken 


From trentm@activestate.com  Tue Jun 27 17:46:58 2000
From: trentm@activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 09:46:58 -0700
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>
References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>
Message-ID: <20000627094658.B7257@activestate.com>

On Mon, Jun 26, 2000 at 09:35:52PM -0500, Guido van Rossum wrote:
> (Trent Mick, it would be helpful if you assigned each of your patches
> a potential reviewer from the list of existing developers -- that way
> we can split up the review load.)
> 

Do you mean I should reassigned patch-reviewing over and above the
assignments that you have done recently? I was just going to put up twenty
more patches and assign them all to Tim as well. :) Kidding.

If, "yes", then I will make a go at that today.


BTW I have answered a couple a questions on my patches. Does the person to
whom the patch is assigned get an update notification?

Trent


-- 
Trent Mick
trentm@activestate.com


From trentm@activestate.com  Tue Jun 27 17:57:38 2000
From: trentm@activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 09:57:38 -0700
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <14679.36964.766774.864078@localhost.localdomain>
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain>
Message-ID: <20000627095738.D7257@activestate.com>

On Mon, Jun 26, 2000 at 01:18:28PM -0400, Jeremy Hylton wrote:
> Ok.  I was looking for a test case to include in the test suite.  I've
> made the change, but it looks like it will have to go without an
> accompanying test.


I asked the question a while back if it would reasonable/useful/popular to
have a mechanism where parts of the Python/C Api could be tested directly.

My proposal used an extension module _testmodule (although I made it a core
module on UN*X it should not bog down the core) which exported a bunch o'
test_* routines that tested specific parts of the Python/C API. A
test_internal.py module would be added to the std regression test suite that
would import this module and call each of the exported test_* routines in
turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested.

Anybody have any opinions?


Trent

p.s. I have a patch largely (all except the above menntion limitation) ready
for this, including some tests that I used for my 64-bit porting stuff. 


-- 
Trent Mick
trentm@activestate.com


From skip@mojam.com (Skip Montanaro)  Tue Jun 27 18:11:33 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Tue, 27 Jun 2000 12:11:33 -0500 (CDT)
Subject: [Python-Dev] semi-subtle atexit gotcha?
Message-ID: <14680.57413.385666.482385@beluga.mojam.com>

In thinking about the new atexit module a little more, it occurred to me
that I've handled the case where the atexit module gets loaded after another 
module that wants to set sys.exitfunc (it just incorporates that function
into its list of functions), but not if atexit gets loaded before another
modules that uses sys.exitfunc.  I see two possible choices:

    1. Punt and put a bit of verbiage in the atexit section of the library
       reference manual and the 1.6 release notes.

    2. Have atexit.register check each time it's called to see if
       sys.exitfunc is what it expects.  This isn't a perfect solution for a 
       couple reasons.  One, there's no guarantee that other sys.exitfunc- 
       modifying code isn't executed after the last call to
       atexit.register.  Two, there's no guarantee that the other code
       doesn't attempt to be "intelligent" in a fashion similar to atexit
       (can you say dueling banjos?).

I vote for option number one since there appears to be no guaranteed way to
make it work, but I'm open to other suggestions.

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."


From trentm@activestate.com  Tue Jun 27 18:16:58 2000
From: trentm@activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 10:16:58 -0700
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>
References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>
Message-ID: <20000627101658.E7257@activestate.com>

On Mon, Jun 26, 2000 at 02:41:12PM -0400, Tim Peters wrote:
> Intended use of SourceForge patch status tags
> ---------------------------------------------
> revision 1                        26-Jun-2000
> 
> 
> Open
>     The initial status of all patches.
>     The patch is under consideration, but has not
>     been reviewed yet.
>     The status will normally change to Accepted or Rejected next.
>     The person submitting the patch should (if they can) assign
>     it to the person they most want to review it.
>     Else the patch will be assigned via
>         [xxx a list of expertise areas should be developed]

What are the chances of getting other meta data fields on patches, i.e.
changes to the patch manager? Categorizing patches could really help as a
filter. For instance, I may be a Unicode genius and would like to see the
patches associated with it.


>     Discussion of patches is carried out via
>         [xxx Python-Dev?  patches list?  without a mail gateway,
>              the SourceForge patch interface looks too clumsy
>              to use for controversial patches]

I like the separation of python-dev and patches, but it is not a biggie for
me.


> Postponed
>     The previous status was Open or Accepted, but for some reason
>     (e.g., pending release) the patch should not be reviewed or
>     applied until further notice.
>     The status will normally change to Open or Accepted next.
>     Please enter a comment when changing the status to Postponed,
>     to record the reason, the previous status, and the conditions
>     under which the patch should revert to Open or Accepted.

Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the
person responsible for later taking to patch out of 'postponed' status.



Trent


-- 
Trent Mick
trentm@activestate.com


From jeremy@beopen.com  Tue Jun 27 18:21:28 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Tue, 27 Jun 2000 13:21:28 -0400 (EDT)
Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <20000627095738.D7257@activestate.com>
References: <20000622193610.27452.qmail@eik.g.aas.no>
 <395272D0.B82A0353@lemburg.com>
 <m3r99pjvrx.fsf@eik.g.aas.no>
 <39531A20.1BEAA51E@lemburg.com>
 <m3hfak4tds.fsf@eik.g.aas.no>
 <14675.30233.658776.764865@localhost.localdomain>
 <m38zvwxn9u.fsf@eik.g.aas.no>
 <14679.36964.766774.864078@localhost.localdomain>
 <20000627095738.D7257@activestate.com>
Message-ID: <14680.58008.466802.160183@bitdiddle.concentric.com>

I think testing the C API directly is a great idea!  Sorry I missed it
the first time around.

I don't think I understand the suggested approach well enough to
critique it.  Most of the tests need to be written in C, right?  When
an error is encountered, it seems that you should check what the C API
returns *and* what happens at the Python level, i.e. whether the call
sets a Python exception (or clears an existing Python exception).

I guess you ought to show us the code.  I don't think it will go in
Python 1.6, but it sounds like a valuable component for future
releases. 

Jeremy


From trentm@activestate.com  Tue Jun 27 18:37:00 2000
From: trentm@activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 10:37:00 -0700
Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <14680.58008.466802.160183@bitdiddle.concentric.com>
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com>
Message-ID: <20000627103700.G7257@activestate.com>

On Tue, Jun 27, 2000 at 01:21:28PM -0400, Jeremy Hylton wrote:
> 
> I don't think I understand the suggested approach well enough to
> critique it.  Most of the tests need to be written in C, right?  When

All of the testing code would be in C, in the _testmodule.c, or whatever
name.

> an error is encountered, it seems that you should check what the C API
> returns *and* what happens at the Python level, i.e. whether the call
> sets a Python exception (or clears an existing Python exception).

Yes you are right. It depends on the API under test. Basically you just try
to test all conditions to ensure that the API behaves as expected/advertised.


> 
> I guess you ought to show us the code.  I don't think it will go in
> Python 1.6, but it sounds like a valuable component for future
> releases. 
> 

Okay. I agree that this would probably not make 1.6 so I will probably wait
on this for a little while. Busy.


Trent

-- 
Trent Mick
trentm@activestate.com


From trentm@activestate.com  Tue Jun 27 18:56:47 2000
From: trentm@activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 10:56:47 -0700
Subject: [Python-Dev] my dev status on SourceForge
In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com>
References: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com> <200006271430.JAA01769@cj20424-a.reston1.va.home.com>
Message-ID: <20000627105647.H7257@activestate.com>

SPeaking of surprising little SourceForge things:

I just made the mistake of clicking on the little garbage can beside "Python"
in "My Projects". I seem to have booted myself from the Python project. Can I
put myself back on? or can one of you with admin status please do that for
me?

my SourceForge username is: tmick

Sorry and thanks,
Trent




-- 
Trent Mick
trentm@activestate.com


From akuchlin@mems-exchange.org  Tue Jun 27 19:20:21 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 27 Jun 2000 14:20:21 -0400
Subject: [Python-Dev] curses/wrapper.py
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEICCOAA.mhammond@skippinet.com.au>
References: <20000627035202.M29590@lyra.org> <ECEPKNMJLHAPFFJHDOJBAEICCOAA.mhammond@skippinet.com.au>
Message-ID: <20000627142021.G19033@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 12:45:07AM +1000, Mark Hammond quoted:
>> Besides its redundancy, it also places the traceback into a
>> local variable
>> and then raises an exception -- a perfect recipe for creating a ref loop.

I think this is irrelevant for the curses.wrapper() function, which
simply restores the terminal state before re-raising the exception.
It probably won't ever be called repeatedly, making the question of a
memory leak moot.

Yes, I'd like to have wrapper() use Greg Stein's simpler and tidier
code.  Yes, I'd like to know why ESR claims the simpler version
doesn't work and have a replicable test case.  But right now there are
higher priority things to do, so I'm shelving this until after 1.6b1.
(Right now I'm trying to get the curses module compiling on Tru64, and
things don't look good.)

--amk



From Ka-Ping Yee <pingster@ilm.com>  Tue Jun 27 19:25:01 2000
From: Ka-Ping Yee <pingster@ilm.com> (Ka-Ping Yee)
Date: Tue, 27 Jun 2000 11:25:01 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1
In-Reply-To: <14680.29842.372192.274003@temoleh.chem.uu.nl>
Message-ID: <Pine.SGI.3.96.1000627110923.621134C-100000@happy>

On Tue, 27 Jun 2000, Rob W. W. Hooft wrote:
>  AMK> --- NEW FILE ---
>  AMK> #
>  AMK> # ascii.py -- constants and memembership tests for ASCII characters
>  AMK> #
>                                   ^^^^^ two letters too much?

Grrrr... surely by now we should be getting docstrings instead of
comments at the top of modules!

In keeping with the format of most other modules, i also suggest
not repeating the module name.  Thus:

    """Constants and membership tests for ASCII characters."""



-- ?!ng

(166 irender improvements since May 1999)






From Vladimir.Marangozov@inrialpes.fr  Tue Jun 27 19:39:35 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Tue, 27 Jun 2000 20:39:35 +0200 (CEST)
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <no.id> from "Vladimir Marangozov" at Jun 27, 2000 06:23:52 PM
Message-ID: <200006271839.UAA05354@python.inrialpes.fr>

I'm resending this msg since it didn't seem to get through the 1st time
(and we're experiencing some major hw&sw router problems lately)

Vladimir Marangozov wrote:
> 
> Guido van Rossum wrote:
> > 
> > Here at BeOpen we're scrambling to get the release schedule for the
> > rest of Python 1.6 planned.  We're now looking at releasing Python
> > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
> > This means that if SRE isn't ready, we'll go with an incomplete SRE.
> > Still better than no SRE!
> > 
> > Please, PLEASE, if you have pending patches that you think should go
> > into 1.6b1, submit them to SourceForge.  We'll do our best to have a
> > look at every patch submitted; but don't wait until the last moment.
> 
> So, to sum up (because I'm a bit lost after all this patch-related
> messages), what should I do to avoid at best adding to the collective
> burden :
> 
> 1. Should I send patches to SF and be quiet until June 30 ?
> 
> 2. Should I apply for privileges and spend <big time> installing
>    an SSH client on my box (illegal in France ;), then make my Python
>    way into the SF galaxy ?
> 
> 3. If I volunteer for help with the patches backlog, what do I do ?
> 
> 4. Other options presented to me ?
> 
> Context : I (will) have some patches lying around, there are some
> patches of mine on the pile sent to patches@python.org that I'm
> confident about, I have read the FAQ at SF which gave me 0 clues
> on how things are being set up there (only general info about
> who why and what for + terms of service), and I managed to create
> an account with a personal page containing two bookmarks in it
> (after being distracted with personal and project ratings + gobs of
> links to gobs of stuff).
> 
> -- 
>        Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
> http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
> 


-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From paul@prescod.net  Tue Jun 27 19:46:40 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 11:46:40 -0700
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net> <02fe01bfe051$3df655b0$4500a8c0@thomasnb>
Message-ID: <3958F690.EDB27D07@prescod.net>

I'm trying to figure out all of the constants in _winreg. Some of them
seem related to functions that _winreg doesn't support. I won't put
those in new winreg because they can't be used. The only one I can't
figure out through web searches is REG_OPTION_OPEN_LINK.

RegNotifyChangeKeyValue (unsupported)
	REG_NOTIFY_CHANGE_NAME
	REG_NOTIFY_CHANGE_LAST_SET 
	REG_NOTIFY_CHANGE_SECURITY 
	REG_NOTIFY_CHANGE_ATTRIBUTES 

RegRestoreKey (unsupported)
	REG_FORCE_RESTORE
	REG_NO_LAZY_FLUSH
	REG_REFRESH_HIVE
	REG_WHOLE_HIVE_VOLATILE

RegCreateKeyEx (unxupported)
	REG_OPTION_RESERVED
	REG_OPTION_VOLATILE
	REG_OPTION_NON_VOLATILE
	REG_OPTION_BACKUP_RESTORE
	REG_CREATED_NEW_KEY
	REG_OPENED_EXISTING_KEY
	REG_OPTION_CREATE_LINK

I presume that nobody intends to add these three functions to _winreg in
time for Python 1.6!

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999


From Fredrik Lundh" <effbot@telia.com  Tue Jun 27 20:25:23 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 21:25:23 +0200
Subject: [Python-Dev] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
References: <200006270050.RAA26210@slayer.i.sourceforge.net> <20000627035202.M29590@lyra.org> <20000627125053.B6531@thyrsus.com>
Message-ID: <001f01bfe06d$753492a0$f2a6b5d4@hagrid>

Eric S. Raymond wrote:
> What happened is that your version failed to pass an error exception =
upwards
> after fielding it.  My test case was a buggy version of =
cmlconfigure.py, bug
> since fixed.
>=20
> Cleanliness is good, but the code has to work first.

umm.  as far as I can tell from the patch, there's no way your
code can work in a situation where try/finally wouldn't do exactly
the same thing.

if you *do* get different results (try inserting "raise whatever"
in the try clause to test this), it might be that you've stumbled
upon a real bug (either in Python or in the curses C bindings)...

</F>



From guido@beopen.com  Tue Jun 27 21:25:49 2000
From: guido@beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 15:25:49 -0500
Subject: [Python-Dev] Re: my dev status on SourceForge
In-Reply-To: Your message of "Tue, 27 Jun 2000 10:56:47 MST."
 <20000627105647.H7257@activestate.com>
References: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com> <200006271430.JAA01769@cj20424-a.reston1.va.home.com>
 <20000627105647.H7257@activestate.com>
Message-ID: <200006272025.PAA04010@cj20424-a.reston1.va.home.com>

> SPeaking of surprising little SourceForge things:
> 
> I just made the mistake of clicking on the little garbage can beside "Python"
> in "My Projects". I seem to have booted myself from the Python project. Can I
> put myself back on? or can one of you with admin status please do that for
> me?
> 
> my SourceForge username is: tmick

OK, you're back!

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


From pingster@ilm.com  Tue Jun 27 20:38:15 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Tue, 27 Jun 2000 12:38:15 -0700 (PDT)
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <3958D89E.39D084C8@lemburg.com>
Message-ID: <Pine.SGI.3.96.1000627123233.621134G-100000@happy>

On Tue, 27 Jun 2000, M.-A. Lemburg wrote:
> I've received the first round of notification message from the
> patch manager and can't really say that I like them.

I wish i could propose Roundup, but it currently lacks the
ability to decode e-mail attachments.  Aside from that, it
has reasonable (if basic) e-mail handling, colour-coded
status and priorities, and so on.

I would jump on it in a second except that the Software
Carpentry deadline is also this Friday and i'm still barely
pulling that thing together.

Of course, if you feel like hacking it up to do attachments
feel free to get it at http://pingster.com/roundup.html and
hack away!

Alternatively i suppose you could keep the patch files on
SourceForge and do the discussions in Roundup as an interim
solution?  Messy, i know, but it might be an improvement.



-- ?!ng



From paul@prescod.net  Tue Jun 27 20:45:16 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 12:45:16 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses
 ascii.py,NONE,1.1 textpad.py,NONE,1.1
References: <Pine.SGI.3.96.1000627110923.621134C-100000@happy>
Message-ID: <3959044C.B5C537FA@prescod.net>

Ka-Ping Yee wrote:
> 
> -- ?!ng
> 
> (166 irender improvements since May 1999)

> Although some shots were composited with Sabre, ILM's extensions 
> to Discreet Logic's Flame and Inferno software, CompTime was 
> the compositing tool for the CG department, according to 
> Jeff Yost. First used for one shot in Saving Private Ryan, 
> CompTime is based on the studio's long-time scripted system, but 
> now boasts a graphical user interface and hooks for plug-ins that 
> can be written in Python or C++. 

Is it safe to say that "Without Python, Saving Private Ryan would not
have been possible, much less an Oscar winner?"

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999


From Fredrik Lundh" <effbot@telia.com  Tue Jun 27 21:01:26 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 22:01:26 +0200
Subject: [Python-Dev] Re: testing the Python/C API
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com> <20000627103700.G7257@activestate.com>
Message-ID: <006801bfe072$7abc0820$f2a6b5d4@hagrid>

trent wrote:
> > I don't think I understand the suggested approach well enough to
> > critique it.  Most of the tests need to be written in C, right?  =
When
>=20
> All of the testing code would be in C, in the _testmodule.c, or =
whatever
> name.

SWIG, anyone?

</F>



From Fredrik Lundh" <effbot@telia.com  Tue Jun 27 21:06:30 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 22:06:30 +0200
Subject: [Python-Dev] SF patch manager...
References: <3958D89E.39D084C8@lemburg.com>
Message-ID: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>

mal wrote:

> I've received the first round of notification message from the
> patch manager and can't really say that I like them. Ok, I=20
> understand that the patch manager is still alpha or beta software,
> but these messages really don't have any usable content at all:
>=20
> """
> Patch #100646 has been updated.=20
> Visit SourceForge.net for more info.
>=20
> =
http://sourceforge.net/patch/?func=3Ddetailpatch&patch_id=3D100646&group_=
id=3D5470
> """
>=20
> Also, reviewing the patches has become a pain and discussing them
> is nearly impossible (I don't consider the slashdot like comment
> mechanism to be of any use: there's simply no audience for
> discussion).
>=20
> Is there any chance of tee'ing patches from SF to the patches
> list or some other patch discussion and review forum ? I do
> understand that the mechanism can help with patch *checkins*,
> but it's certainly not going to help much with the discussion
> step needed before conidering any actions. The independent
> peer review principal doesn't work with this kind of setup.

I fully agree.

someone really needs to fuse the patch manager with roundup (that
we should use roundup for bug tracking goes without saying...)

how much work would it be to move the entire repository over to
pythonlabs, btw?  sourceforget is frustratingly slow...

</F>



From guido@beopen.com  Tue Jun 27 22:07:41 2000
From: guido@beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:07:41 -0500
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names)
In-Reply-To: Your message of "Tue, 27 Jun 2000 09:57:38 MST."
 <20000627095738.D7257@activestate.com>
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain>
 <20000627095738.D7257@activestate.com>
Message-ID: <200006272107.QAA04498@cj20424-a.reston1.va.home.com>

> I asked the question a while back if it would reasonable/useful/popular to
> have a mechanism where parts of the Python/C Api could be tested directly.
> 
> My proposal used an extension module _testmodule (although I made it a core
> module on UN*X it should not bog down the core) which exported a bunch o'
> test_* routines that tested specific parts of the Python/C API. A
> test_internal.py module would be added to the std regression test suite that
> would import this module and call each of the exported test_* routines in
> turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested.
> 
> Anybody have any opinions?
> 
> 
> Trent
> 
> p.s. I have a patch largely (all except the above menntion limitation) ready
> for this, including some tests that I used for my 64-bit porting stuff. 

Great idea.  Please wait for 1.7.  There *will* be releases after 1.6!

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


From guido@beopen.com  Tue Jun 27 22:08:42 2000
From: guido@beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:08:42 -0500
Subject: [Python-Dev] semi-subtle atexit gotcha?
In-Reply-To: Your message of "Tue, 27 Jun 2000 12:11:33 EST."
 <14680.57413.385666.482385@beluga.mojam.com>
References: <14680.57413.385666.482385@beluga.mojam.com>
Message-ID: <200006272108.QAA04509@cj20424-a.reston1.va.home.com>

> In thinking about the new atexit module a little more, it occurred to me
> that I've handled the case where the atexit module gets loaded after another 
> module that wants to set sys.exitfunc (it just incorporates that function
> into its list of functions), but not if atexit gets loaded before another
> modules that uses sys.exitfunc.  I see two possible choices:
> 
>     1. Punt and put a bit of verbiage in the atexit section of the library
>        reference manual and the 1.6 release notes.
> 
>     2. Have atexit.register check each time it's called to see if
>        sys.exitfunc is what it expects.  This isn't a perfect solution for a 
>        couple reasons.  One, there's no guarantee that other sys.exitfunc- 
>        modifying code isn't executed after the last call to
>        atexit.register.  Two, there's no guarantee that the other code
>        doesn't attempt to be "intelligent" in a fashion similar to atexit
>        (can you say dueling banjos?).
> 
> I vote for option number one since there appears to be no guaranteed way to
> make it work, but I'm open to other suggestions.

Yes, #1 is good enough.  I don't think there will be lots of people
bitten by this...

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


From guido@beopen.com  Tue Jun 27 22:11:46 2000
From: guido@beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:11:46 -0500
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Tue, 27 Jun 2000 10:16:58 MST."
 <20000627101658.E7257@activestate.com>
References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>
 <20000627101658.E7257@activestate.com>
Message-ID: <200006272111.QAA04542@cj20424-a.reston1.va.home.com>

> What are the chances of getting other meta data fields on patches, i.e.
> changes to the patch manager? Categorizing patches could really help as a
> filter. For instance, I may be a Unicode genius and would like to see the
> patches associated with it.

Good idea.  The PM clearly needs work.  I see two places where you
could submit feature requests: (1) the "Report SF Bug" item in the
left side bar; (2) the "Feature Requests" discussion forum
(http://sourceforge.net/forum/forum.php?forum_id=4&et=0)

> I like the separation of python-dev and patches, but it is not a biggie for
> me.

For me it's just an annoyance, especially when cross-posting is used.

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


From guido@beopen.com  Tue Jun 27 22:36:57 2000
From: guido@beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:36:57 -0500
Subject: [Python-Dev] python.org mail unclogged
Message-ID: <200006272136.QAA04723@cj20424-a.reston1.va.home.com>

It seems we've removed a major source of email cloggage on python.org
-- a site in France was hitting every page in the mailman membership
administration using a commercial crawler (Teleport Pro) that didn't
honor our robots.txt file, and forking a 4 Mb CGI script for each user
in each mailing list.  Thanks for Barry and Andrew!  This was on top
of problems caused when the Ultraseek crawler ran out of memory and
caused postfix or mailman to fail. :-(

Mail seems to be flowing again, the queues are emptying.  Once we're
happy, we'll turn on the Ultraseek crawler and search service.

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


From jeremy@beopen.com  Tue Jun 27 21:54:38 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Tue, 27 Jun 2000 16:54:38 -0400 (EDT)
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <Pine.SGI.3.96.1000627123233.621134G-100000@happy>
References: <3958D89E.39D084C8@lemburg.com>
 <Pine.SGI.3.96.1000627123233.621134G-100000@happy>
Message-ID: <14681.5262.464079.557095@bitdiddle.concentric.com>

Maybe the right solution is to work with the SourceForge maintainers
to make roundup part of the standard support software.  

jeremy


From fdrake@beopen.com  Tue Jun 27 22:01:54 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 27 Jun 2000 17:01:54 -0400 (EDT)
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <20000627101658.E7257@activestate.com>
References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
 <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>
 <20000627101658.E7257@activestate.com>
Message-ID: <14681.5698.732269.523890@cj42289-a.reston1.va.home.com>

Trent Mick writes:
 > Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the
 > person responsible for later taking to patch out of 'postponed' status.

  Agreed; assignment should be changed whenever the next person
required to deal with it changes.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From nascheme@enme.ucalgary.ca  Tue Jun 27 22:05:55 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Tue, 27 Jun 2000 15:05:55 -0600
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 27, 2000 at 10:06:30PM +0200
References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid>
Message-ID: <20000627150555.A3083@acs.ucalgary.ca>

On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote:
> how much work would it be to move the entire repository over to
> pythonlabs, btw?  sourceforget is frustratingly slow...

rsync access to the CVS repository would be nice too.  rsync
should be faster than "cvs update".  Also, once you have the
whole repository making diffs and checking out different versions
is much faster.

  Neil

-- 
"I saw `cout' being shifted "Hello world" times to the
left and stopped right there."  -- Steve Gonedes


From jeremy@beopen.com  Tue Jun 27 22:49:01 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Tue, 27 Jun 2000 17:49:01 -0400 (EDT)
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <20000627150555.A3083@acs.ucalgary.ca>
References: <3958D89E.39D084C8@lemburg.com>
 <007801bfe073$3008b0c0$f2a6b5d4@hagrid>
 <20000627150555.A3083@acs.ucalgary.ca>
Message-ID: <14681.8525.343786.194271@bitdiddle.concentric.com>

>>>>> "NS" == Neil Schemenauer <nascheme@enme.ucalgary.ca> writes:

  NS> On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote:
  >> how much work would it be to move the entire repository over to
  >> pythonlabs, btw?  sourceforget is frustratingly slow...

  NS> rsync access to the CVS repository would be nice too.  rsync
  NS> should be faster than "cvs update".  Also, once you have the
  NS> whole repository making diffs and checking out different
  NS> versions is much faster.

Absolutely!  OpenSSL works this way and I find it much more convenient
than using a remote CVS server.  I use commands like diff, log, and
annotate frequently during development.

Have you suggested that as a SourceForge feature?

Jeremy


From akuchlin@mems-exchange.org  Tue Jun 27 22:47:07 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 27 Jun 2000 17:47:07 -0400
Subject: [Python-Dev] Testdrive systems
Message-ID: <20000627174707.P19033@kronos.cnri.reston.va.us>

Portability-related note: I've just fixed a reported compilation
problem with the curses module on Tru64 Unix using a machine made
available by Compaq.  If you go to http://www.testdrive.compaq.com/,
you can sign up for a free 30-day account on a variety of machines:
Alphas running Tru64, FreeBSD, and Linux, and Intel machines running
BSD or Linux.  A nice way to fix reported problems quickly...  The
environment on the systems is a bit Spartan; emacs is there, but no
fancy shells and no CVS (which is especially annoying).

--amk


From nascheme@enme.ucalgary.ca  Tue Jun 27 23:56:09 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Tue, 27 Jun 2000 16:56:09 -0600
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <14681.8525.343786.194271@bitdiddle.concentric.com>; from jeremy@beopen.com on Tue, Jun 27, 2000 at 05:49:01PM -0400
References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <20000627150555.A3083@acs.ucalgary.ca> <14681.8525.343786.194271@bitdiddle.concentric.com>
Message-ID: <20000627165609.A3941@acs.ucalgary.ca>

On Tue, Jun 27, 2000 at 05:49:01PM -0400, Jeremy Hylton wrote:
> Have you suggested [rsync access to CVS] as a SourceForge feature?

Nope.  Be my guest. :)

  Neil


From tpeters@beopen.com  Wed Jun 28 01:11:44 2000
From: tpeters@beopen.com (Tim Peters)
Date: Tue, 27 Jun 2000 20:11:44 -0400
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <3958D89E.39D084C8@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEMBGGAA.tim_one@email.msn.com>

[MAL]
> [Please excuse my ranting... :-)]

No problem -- you're not complaining about *our* software <wink>.

> I've received the first round of notification message from the
> patch manager and can't really say that I like them. Ok, I
> understand that the patch manager is still alpha or beta software,
> but these messages really don't have any usable content at all:
>
> """
> Patch #100646 has been updated.
> Visit SourceForge.net for more info.
>
>
http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470
> """

I expect the title of the patch was also in the Subject line, yes?  And a
live link to the patch is certainly "usable".  I've found both those right
on target as I've been assigned or deassigned to patches so far, although
I'd sure like to see something in the body saying exactly *what* about the
patch "has been updated".

Not saying I think it's good enough, am saying it's (barely) a start.

> Also, reviewing the patches has become a pain

I don't understand that, in that the text of the patch is what you got
before, and what you can get now.  Is your complaint here specifically that
patches don't show up in your mailbox by magic?  Or something else?

> and discussing them is nearly impossible (I don't consider the
> slashdot like comment mechanism to be of any use: there's simply
> no audience for discussion).

Wholly agreed there.  So use python-dev for discussions for now; I agree too
with Guido that the rampant but inconsistent x-posting between patches and
python-dev was part of the problem.

> Is there any chance of tee'ing patches from SF to the patches
> list or some other patch discussion and review forum ?

I expect you know as much about SF's possibilities as anyone <0.5 wink>:
don't know.  The SF docs are either non-existent or inadequate, far as I can
tell, and I believe I share a mistaken belief with Fred Drake that new
patches "should" *already* be showing up on the patches list.

> I do understand that the mechanism can help with patch *checkins*,

Yes, but not yet as much as it should (e.g., the default view of patches
lacks basic info like the patch current status, and there's apparently not
yet any way to define a different view).

> but it's certainly not going to help much with the discussion
> step needed before conidering any actions.

Python-Dev now, possibly roundup later.  OTOH, it's perfectly adequate for
tiny little principal-reviewer <-> submitter give-and-take; many patches are
really quite trivial.

> The independent peer review principal doesn't work with this
> kind of setup.

I think your view is warped on this one, as you've been in the extremely
favored position of pumping out crucial patches for a hot area.  Most other
peoples' patches have been flatly ignored for *months* now.  It's not
necessarily bad if other people get some attention now too <wink>.




From tpeters@beopen.com  Wed Jun 28 01:11:52 2000
From: tpeters@beopen.com (Tim Peters)
Date: Tue, 27 Jun 2000 20:11:52 -0400
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEMBGGAA.tim_one@email.msn.com>

[Fredrik Lundh]
> ...
> how much work would it be to move the entire repository over to
> pythonlabs, btw?

Impossibly more than we could make time for soon.

> sourceforget is frustratingly slow...

'Tis very erratic indeed.  It *can* be speedy, but that seems much more the
exception than the rule.




From Ka-Ping Yee <pingster@ilm.com>  Wed Jun 28 00:29:04 2000
From: Ka-Ping Yee <pingster@ilm.com> (Ka-Ping Yee)
Date: Tue, 27 Jun 2000 16:29:04 -0700 (PDT)
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <200006272111.QAA04542@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.SGI.3.96.1000627144959.621134U-100000@happy>

Fredrik Lundh wrote:
> someone really needs to fuse the patch manager with roundup (that
> we should use roundup for bug tracking goes without saying...)

How sweet!  Why, thank you. :)

Trent Mick wrote:
> What are the chances of getting other meta data fields on patches, i.e.
> changes to the patch manager? Categorizing patches could really help as a
> filter. For instance, I may be a Unicode genius and would like to see the
> patches associated with it.

I agree that doing that kind of filtering is very useful.  I have
a discussion thingie (based on Roundup) at http://headspaces.com/.
(Also prototype -- very prototype.)  I hacked out the "status" and
"fixer" fields and added a "keywords" field.  Not much volume yet,
but i think it will work well.

Perhaps something like that for discussing patches?

Jeremy Hylton wrote:
> Maybe the right solution is to work with the SourceForge maintainers
> to make roundup part of the standard support software.  

Hmmm... maybe i should look into that after i've figured out how
super-Roundup is going to work.


-- ?!ng




From gward@python.net  Wed Jun 28 01:58:43 2000
From: gward@python.net (Greg Ward)
Date: Tue, 27 Jun 2000 20:58:43 -0400
Subject: [Python-Dev] DOS text files and CVS
Message-ID: <20000627205843.A1607@beelzebub>

Hi all --

can anyone enlighten me on the right way to check in DOS text files to a 
CVS repository?  I have Thomas Heller's C source for his simple
graphical installer for Python modules, and it should definitely be in
the Distutils CVS tree.  But I don't want to check it in if it'll screw
up line-endings for anyone.  Is there a Right Way to do this?

Thanks --

        Greg
-- 
Greg Ward - Linux nerd                                  gward@python.net
http://starship.python.net/~gward/
Just because you're paranoid doesn't mean they *aren't* out to get you.


From tpeters@beopen.com  Wed Jun 28 02:13:54 2000
From: tpeters@beopen.com (Tim Peters)
Date: Tue, 27 Jun 2000 21:13:54 -0400
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <017501bfe023$684fca40$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEMFGGAA.tim_one@email.msn.com>

[Fredrik Lundh]
> (tim? where's the second installment of your sourceforge vs.
> windows series?)

Waiting for you to finish SRE <wink>.  Seriously, I don't *need* to get
Windows checkin access for the imminent release, so I moved this down my
priority list.  I needed to move *something* down because finding a place to
live around here is both urgent & consuming much more time than I had
planned on (vacancy rate:  0%).  Windows vs SourceForge is still on my
plate, and I'm not giving up on it, just slipping it.

just-carrying-my-plans-between-the-bathroom-&-the-bed-is-
    invigorating-exercise-ly y'rs  - tim




From mhammond@skippinet.com.au  Wed Jun 28 02:18:44 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Wed, 28 Jun 2000 11:18:44 +1000
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEMFGGAA.tim_one@email.msn.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEJECOAA.mhammond@skippinet.com.au>

> just-carrying-my-plans-between-the-bathroom-&-the-bed-is-
>     invigorating-exercise-ly y'rs  - tim

Your plans, or your pans?

I-knew-you-were-old-but-not-that-old-<wink>-ly,

Mark.



From tpeters@beopen.com  Wed Jun 28 02:39:31 2000
From: tpeters@beopen.com (Tim Peters)
Date: Tue, 27 Jun 2000 21:39:31 -0400
Subject: [Python-Dev] RE: [Distutils] DOS text files and CVS
In-Reply-To: <20000627205843.A1607@beelzebub>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMIGGAA.tim_one@email.msn.com>

[Greg Ward]
> can anyone enlighten me on the right way to check in DOS text files to a
> CVS repository?

Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe
you need to convince CVS that it's a binary (not text) file.  Then it will
skip line-end conversions.

not-a-solution-but-maybe-a-clue-ly y'rs  - tim




From gstein@lyra.org  Wed Jun 28 02:46:15 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 18:46:15 -0700
Subject: [Python-Dev] add Demo/imputil/importers.py ?
Message-ID: <20000627184615.A29590@lyra.org>

A while back, I pulled the "demo" importers out of imputil.py. I think those
should be added into Demo/imputil/.

It would also be Goodness to include JimA's zipimporter. Where would that go?

Cheers,
-g

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


From gmcm@hypernet.com  Wed Jun 28 02:47:30 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Tue, 27 Jun 2000 21:47:30 -0400
Subject: [Python-Dev] DOS text files and CVS
In-Reply-To: <20000627205843.A1607@beelzebub>
Message-ID: <1249965584-36289880@hypernet.com>

Greg Ward asks:

> can anyone enlighten me on the right way to check in DOS text
> files to a CVS repository?  I have Thomas Heller's C source for
> his simple graphical installer for Python modules, and it should
> definitely be in the Distutils CVS tree.  But I don't want to
> check it in if it'll screw up line-endings for anyone.  Is there
> a Right Way to do this?

Well, if you checked it in from a Windows box, CVS would 
translate line endings to native, then a Windows checkout 
would translate back to Windows endings.

So assuming you don't want to get your fingers dirty, give it 
*n*x line endings and check it in.

CVS does understand text, you know :-).

(And about the only Windows editor that barfs on *n*x line 
endings is Notepad.)


- Gordon


From davida@pobox.com  Wed Jun 28 02:50:24 2000
From: davida@pobox.com (David Arnold)
Date: Wed, 28 Jun 2000 11:50:24 +1000
Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS
In-Reply-To: Your message of "Tue, 27 Jun 2000 21:39:31 -0400."
 <LNBBLJKPBEHFEDALKOLCAEMIGGAA.tim_one@email.msn.com>
Message-ID: <200006280150.LAA17759@xevious.dstc.monash.edu.au>

-->"Tim" == Tim Peters <tim_one@email.msn.com> writes:

  Tim> Aargh, I haven't used CVS in about 6 years ... somehow or
  Tim> other, I believe you need to convince CVS that it's a binary
  Tim> (not text) file.  Then it will skip line-end conversions.

cvs add -kb file

should work to add a binary file.  not sure that this is the best way
to deal with DOS files, but it should work ...



d


From akuchlin@mems-exchange.org  Wed Jun 28 03:04:53 2000
From: akuchlin@mems-exchange.org (A.M. Kuchling)
Date: Tue, 27 Jun 2000 22:04:53 -0400
Subject: [Python-Dev] Text about cycle GC
Message-ID: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>

I've written some text for the What's New article on the GCing of
cycles, but it wasn't a topic I paid close attention to at the time,
so I'd like corrections.  Here's what I've got; please send me
comments privately. 

                       6. Optional Collection of Cycles

   The C implementation of Python uses reference counting to implement
   garbage collection. Every Python object maintains a count of the
   number of references pointing to itself, and adjusts the count as
   references are created or destroyed. Once the reference count reaches
   zero, the object is no longer accessible, since you need to have a
   reference to an object to access it, and if the count is zero, no
   references exist any longer.

   Reference counting has some pleasant properties: it's easy to
   understand and implement, and the resulting implementation is
   portable, fairly fast, and reacts well with other libraries that
   implement their own memory handling schemes. The major problem with
   reference counting is that it sometimes doesn't realise that objects
   are no longer accessible, resulting in a memory leak. This happens
   when there are cycles of references.

   Consider the simplest possible cycle, a class instance which has a
   reference to itself:

instance = SomeClass()
instance.myself = instance

   After the above two lines of code have been executed, the reference
   count of instance is 2; one reference is from the variable named
   "'instance'", and the other is from the "myself"attribute of the
   instance.

   If the next line of code is del instance, what happens? The reference
   count of instance is decreased by 1, so it has a reference count of 1;
   the reference in the "myself" attribute still exists. Yet the instance
   is no longer accessible through Python code, and it could be deleted.
   Several objects can participate in a cycle if they have references to
   each other, causing all of the objects to be leaked.

   An experimental step has been made toward fixing this problem. When
   compiling Python, the -with-cycle-gc (XXX correct option flag?) option
   can be specified. This causes a cycle detection algorithm to be
   periodically executed, which looks for inaccessible cycles and deletes
   the objects involved.

   Why isn't this enabled by default? Running the cycle detection
   algorithm takes some time, and some tuning will be required to
   minimize the overhead cost. It's not yet obvious how much performance
   is lost, because benchmarking this is tricky and depends sensitively
   on how often the program creates and destroys objects. XXX is this
   actually the correct reason? Or is it fear of breaking software that
   runs happily while leaving garbage?

   Several people worked on this problem. Early versions were written by
   XXX1, XXX2. (I vaguely remember several people writing first cuts at
   this. Anyone recall who?) The implementation that's in Python 1.6 is a
   rewritten version, this time done by Neil Schemenauer. Lots of other
   people offered suggestions along the way, such as (in alphabetical
   order) Marc-André Lemburg, Tim Peters, Greg Stein, Eric Tiedemann. 
   (XXX other names?  If you feel you should be added, e-mail me).  The
   March 2000 archives of the python-dev mailing list contain most of the
   relevant discussion, especially in the threads titled ``Reference
   cycle collection for Python'' and ``Finalization again''.



From ians@amc.com  Wed Jun 28 02:51:45 2000
From: ians@amc.com (Ian Searle)
Date: Tue, 27 Jun 2000 18:51:45 -0700
Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS
References: <LNBBLJKPBEHFEDALKOLCAEMIGGAA.tim_one@email.msn.com>
Message-ID: <39595A31.6462CA42@amc.com>

The best way to check DOS text files into CVS is from a Windows/DOS
machine using the CVS client/pserver route.  Using this method, the
files are stored in canonical format.  When someone checks them out from
a Unix client they get /n only.  And, when someone checks them out from
a Windows/DOS client, they get /r/n.  And, everyone is happy (well, as
much as can be expected :-)  

If you do a 'cvs add -kb foo.dos-txt' then CVS will treat the file as
binary and forego the keyword substitutions and end of line
translations.  But, folks checking them out will always get the /r/n
regardless of platform.

-Ian

Tim Peters wrote:
> 
> [Greg Ward]
> > can anyone enlighten me on the right way to check in DOS text files to a
> > CVS repository?
> 
> Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe
> you need to convince CVS that it's a binary (not text) file.  Then it will
> skip line-end conversions.
> 
> not-a-solution-but-maybe-a-clue-ly y'rs  - tim
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://www.python.org/mailman/listinfo/distutils-sig


From akuchlin@mems-exchange.org  Wed Jun 28 03:04:15 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 27 Jun 2000 22:04:15 -0400
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <20000627184615.A29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 06:46:15PM -0700
References: <20000627184615.A29590@lyra.org>
Message-ID: <20000627220415.A22246@newcnri.cnri.reston.va.us>

On Tue, Jun 27, 2000 at 06:46:15PM -0700, Greg Stein wrote:
>A while back, I pulled the "demo" importers out of imputil.py. I think those
>should be added into Demo/imputil/.

While on the subject of adding demo directories, I'd like to add a
Demo/curses directory.  (Not going to happen until after b1, though;
cute little demos aren't a high priority at the moment.)

--amk


From bwarsaw@beopen.com  Wed Jun 28 03:25:47 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Tue, 27 Jun 2000 22:25:47 -0400 (EDT)
Subject: [Python-Dev] DOS text files and CVS
References: <20000627205843.A1607@beelzebub>
Message-ID: <14681.25131.166235.152210@anthem.concentric.net>

>>>>> "GW" == Greg Ward <gward@python.net> writes:

    GW> can anyone enlighten me on the right way to check in DOS text
    GW> files to a CVS repository?  I have Thomas Heller's C source
    GW> for his simple graphical installer for Python modules, and it
    GW> should definitely be in the Distutils CVS tree.  But I don't
    GW> want to check it in if it'll screw up line-endings for anyone.
    GW> Is there a Right Way to do this?

If there's no reason why it /has/ to be DOS text, convert it to Unix
line endings first.  XEmacs will even do the conversion for you!  That
is, if the other suggestions people have made don't help.

-Barry


From skip@mojam.com (Skip Montanaro)  Wed Jun 28 03:51:03 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Tue, 27 Jun 2000 21:51:03 -0500 (CDT)
Subject: [Python-Dev] readline history read/write
Message-ID: <14681.26647.228866.236111@beluga.mojam.com>

--lhrBnbs8QA
Content-Type: text/plain; charset=us-ascii
Content-Description: message body and .signature
Content-Transfer-Encoding: 7bit


The original thing that motivated me to propose what became atexit.py was my 
desire to read and write readline history files.  The two attached context
diffs patch Modules/readline.c and Lib/rlcompleter.py to do that.  Two new
functions are added to the readline module and rlcompleter is tweaked to
read the history file referenced by the PYTHONHISTORY environment variable
(if it's defined) and automatically save it when the interpreter exits.

I'm looking for a little feedback.  Here are a few things that jumped to my
mind:

    1. Is it okay to add the read and register/write code to rlcompleter.py?
       Reading and writing readline history files doesn't have anything
       directly to do with identifier completion, but they both have to do
       with readline.

    2. Assuming that history file read/write is desired, should it be
       predicated on the presence of an environment variable or (as in bash
       and other readline-aware programs) should it just happen?

    3. Am I correct in assuming that this capability will only be available
       to Unix/Linux environments, or is readline generally available, thus
       forcing me to think about cross-platform issues?

    4. Is there some mechanism already present in IDLE and/or PythonWin I
       should be aware of and try to emulate?

The two context diffs are both short.  You should be able to follow
everything just by reading the bits of code.  Offering your thoughts on the
above questions shouldn't require actually modifying your interpreter.

Thx,

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."


--lhrBnbs8QA
Content-Type: text/plain
Content-Description: read/write history files
Content-Disposition: inline;
	filename="readline.dif"
Content-Transfer-Encoding: 7bit

*** /tmp/readline.c.~2.17~SlD5BD	Tue Jun 27 21:38:08 2000
--- /tmp/readline.cSlDGMJ	Tue Jun 27 21:38:08 2000
***************
*** 94,99 ****
--- 94,147 ----
  ";
  
  
+ /* Exported function to load a readline history file */
+ 
+ static PyObject *
+ read_history_file(self, args)
+ 	PyObject *self;
+ 	PyObject *args;
+ {
+ 	char *s = NULL;
+ 	if (!PyArg_ParseTuple(args, "|z:read_history_file", &s))
+ 		return NULL;
+ 	errno = read_history(s);
+ 	if (errno)
+ 		return PyErr_SetFromErrno(PyExc_IOError);
+ 	Py_INCREF(Py_None);
+ 	return Py_None;
+ }
+ 
+ static char doc_read_history_file[] = "\
+ read_history_file([filename]) -> None\n\
+ Load a readline history file.\n\
+ The default filename is ~/.history.\
+ ";
+ 
+ 
+ /* Exported function to save a readline history file */
+ 
+ static PyObject *
+ write_history_file(self, args)
+ 	PyObject *self;
+ 	PyObject *args;
+ {
+ 	char *s = NULL;
+ 	if (!PyArg_ParseTuple(args, "|z:write_history_file", &s))
+ 		return NULL;
+ 	errno = write_history(s);
+ 	if (errno)
+ 		return PyErr_SetFromErrno(PyExc_IOError);
+ 	Py_INCREF(Py_None);
+ 	return Py_None;
+ }
+ 
+ static char doc_write_history_file[] = "\
+ write_history_file([filename]) -> None\n\
+ Save a readline history file.\n\
+ The default filename is ~/.history.\
+ ";
+ 
+ 
  /* Exported function to specify a word completer in Python */
  
  static PyObject *completer = NULL;
***************
*** 261,266 ****
--- 309,316 ----
  	{"get_line_buffer", get_line_buffer, 0, doc_get_line_buffer},
  	{"insert_text", insert_text, 1, doc_insert_text},
  	{"read_init_file", read_init_file, 1, doc_read_init_file},
+ 	{"read_history_file", read_history_file, 1, doc_read_history_file},
+ 	{"write_history_file", write_history_file, 1, doc_write_history_file},
  	{"set_completer", set_completer, 1, doc_set_completer},
  	{"get_begidx", get_begidx, 0, doc_get_begidx},
  	{"get_endidx", get_endidx, 0, doc_get_endidx},

--lhrBnbs8QA
Content-Type: text/plain
Content-Description: load and save readline history files automatically
Content-Disposition: inline;
	filename="rlcompleter.dif"
Content-Transfer-Encoding: 7bit

*** /tmp/rlcompleter.py.~1.7~SlDswI	Tue Jun 27 21:36:32 2000
--- /tmp/rlcompleter.pySlD56O	Tue Jun 27 21:36:32 2000
***************
*** 118,120 ****
--- 118,131 ----
      return ret
  
  readline.set_completer(Completer().complete)
+ 
+ import os
+ histfile = os.getenv("PYTHONHISTORY")
+ if histfile is not None:
+     try:
+         readline.read_history_file(histfile)
+     except IOError:
+         pass
+     import atexit
+     atexit.register(readline.write_history_file, histfile)
+ del os, histfile

--lhrBnbs8QA--


From gstein@lyra.org  Wed Jun 28 04:08:46 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 20:08:46 -0700
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEMBGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 08:11:52PM -0400
References: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEMBGGAA.tim_one@email.msn.com>
Message-ID: <20000627200846.D29590@lyra.org>

On Tue, Jun 27, 2000 at 08:11:52PM -0400, Tim Peters wrote:
> [Fredrik Lundh]
> > ...
> > how much work would it be to move the entire repository over to
> > pythonlabs, btw?
> 
> Impossibly more than we could make time for soon.
> 
> > sourceforget is frustratingly slow...
> 
> 'Tis very erratic indeed.  It *can* be speedy, but that seems much more the
> exception than the rule.

hehe... I have 30ms pings and have observed multiple Mb/sec :-)

download.sourceforge.net is excellent given those stats...

Of course, I'm practically just down the street.

Cheers,
-g

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


From tpeters@beopen.com  Wed Jun 28 04:13:52 2000
From: tpeters@beopen.com (Tim Peters)
Date: Tue, 27 Jun 2000 23:13:52 -0400
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <20000627200846.D29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>

[Greg Stein]
> hehe... I have 30ms pings and have observed multiple Mb/sec :-)
>
> download.sourceforge.net is excellent given those stats...
>
> Of course, I'm practically just down the street.

Would please send me the Python script you use to configure Win98 so that I
can get multiple Mb/sec too?  Thanks in advance.  I always *knew* there was
a secret way to boost these 56K laptop modems <wink>.

keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's-
    basement-ly y'rs  - tim




From gstein@lyra.org  Wed Jun 28 04:25:31 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 20:25:31 -0700
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 11:13:52PM -0400
References: <20000627200846.D29590@lyra.org> <LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>
Message-ID: <20000627202531.G29590@lyra.org>

On Tue, Jun 27, 2000 at 11:13:52PM -0400, Tim Peters wrote:
> [Greg Stein]
> > hehe... I have 30ms pings and have observed multiple Mb/sec :-)
> >
> > download.sourceforge.net is excellent given those stats...
> >
> > Of course, I'm practically just down the street.
> 
> Would please send me the Python script you use to configure Win98 so that I
> can get multiple Mb/sec too?  Thanks in advance.  I always *knew* there was
> a secret way to boost these 56K laptop modems <wink>.

DSL big boy! DSL!

And I use a real OS :-)

> keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's-
>     basement-ly y'rs  - tim

eek!

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


From tpeters@beopen.com  Wed Jun 28 05:11:22 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 00:11:22 -0400
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBCEJECOAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCGENEGGAA.tim_one@email.msn.com>

>> just-carrying-my-plans-between-the-bathroom-&-the-bed-is-
>>     invigorating-exercise-ly y'rs  - tim

[Mark Hammond]
> Your plans, or your pans?
>
> I-knew-you-were-old-but-not-that-old-<wink>-ly,

My pans are in storage somewhere in Baltimore, so I can't report on their
possible growth.  Or is this an Australian thing <wink>?

put-another-pan-on-the-barbie-mate?-ly y'rs  - tim


PS:  My testicles *have* grown since I moved to VA!  I'm wondering whether
it's an early symptom of Lyme disease.  They're still easy to carry from
room to room, though, provided simply I'm careful not to trip over them.




From bwarsaw@beopen.com  Wed Jun 28 05:13:32 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 00:13:32 -0400 (EDT)
Subject: [Python-Dev] SF patch manager...
References: <20000627200846.D29590@lyra.org>
 <LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>
Message-ID: <14681.31596.221693.491788@anthem.concentric.net>

>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:

    TP> keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's-
    TP> basement-ly y'rs - tim

Say the word, send me some hardware, and I'll clear a space between
the drums, bass rig, and litter boxes.

cover-it-in-sisal-and-even-the-cats'll-be-happy-ly y'rs,
-Barry


From tpeters@beopen.com  Wed Jun 28 06:04:36 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 01:04:36 -0400
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <20000627095738.D7257@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMENGGGAA.tim_one@email.msn.com>

[Trent Mick]
> I asked the question a while back if it would reasonable/useful/popular
> to have a mechanism where parts of the Python/C Api could be tested
> directly.

Not only reasonable, IMO it's essential.  "If it's not tested, it's broken."
Tattoo that on your neighbor's forehead so it's always in mind <wink>.
Every time we get a legit bug report on Python, I view it as a failure of
the test suite.  That's one of the things I hope to spend a lot of time on
(but have not been promised I can spend any time on -- aren't startups great
<wink>?).

> My proposal used an extension module _testmodule (although I made
> it a core module on UN*X it should not bog down the core) which exported
> a bunch o' test_* routines that tested specific parts of the Python/C
> API. A test_internal.py module would be added to the std regression test
> suite that would import this module and call each of the exported test_*
> routines in turn. This would allow things like the _GetAttr/_SetAttr
> behaviour to be tested.
>
> Anybody have any opinions?

Great start!  But the people who most need to take this seriously (including
but not limited to me) have no bandwidth to spare before 1.6 is out the
door.

focus!-it's-not-just-for-breakfast-anymore-ly y'rs  - tim




From DavidA@ActiveState.com  Wed Jun 28 06:33:37 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Tue, 27 Jun 2000 22:33:37 -0700
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMENGGGAA.tim_one@email.msn.com>
Message-ID: <LMBBIEIJKMPMLBONJMFCOEKFCJAA.DavidA@ActiveState.com>

> [Trent Mick]
> > I asked the question a while back if it would reasonable/useful/popular
> > to have a mechanism where parts of the Python/C Api could be tested
> > directly.
>
> Not only reasonable, IMO it's essential.  "If it's not tested,
> it's broken." Tattoo that on your neighbor's forehead so it's always in
mind <wink>.

Stay _off_ my forehead, thank you very much.  My hairline is receding enough
without ink stains killing off hair follicles.

Besides, I like my lobster-colored forehead just fine.

--da



From tpeters@beopen.com  Wed Jun 28 07:23:38 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 02:23:38 -0400
Subject: [Python-Dev] C# (new language from Microsoft)
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBGEIBCOAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENKGGAA.tim_one@email.msn.com>

[Mark Hammond]
> ...
> * Python has a very good and interesting story in all this - there is no
> need to be alarmed.  If anything, be excited :-)

I was never worried about Python, but I lay awake at night worrying about
MS -- I'm still an MS shareholder, so don't screw this up <wink>.

every-new-c#-programmer-is-a-potential-python-convert-ly y'rs  - tim




From tpeters@beopen.com  Wed Jun 28 07:23:40 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 02:23:40 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>

[Guido van Rossum]
> ...
> The address for New Bugs is currently set to guido@beopen.com.  I
> suppose I should set it to pythoneers@beopen.com or even to
> python-dev@python.org?

Since we (PythonLabs, last week) decided to continue using Jitterbug (on
python.org) for now, should the SF Bug Manager even be enabled?  If it is
enabled, and we are using Jitterbug, then someone has to own reentering SF
bugs into the Jitterbug system.

obviously y'rs  - tim




From gstein@lyra.org  Wed Jun 28 07:47:06 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 23:47:06 -0700
Subject: [Python-Dev] C# (new language from Microsoft)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCENKGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 02:23:38AM -0400
References: <ECEPKNMJLHAPFFJHDOJBGEIBCOAA.mhammond@skippinet.com.au> <LNBBLJKPBEHFEDALKOLCCENKGGAA.tim_one@email.msn.com>
Message-ID: <20000627234706.N29590@lyra.org>

On Wed, Jun 28, 2000 at 02:23:38AM -0400, Tim Peters wrote:
> [Mark Hammond]
> > ...
> > * Python has a very good and interesting story in all this - there is no
> > need to be alarmed.  If anything, be excited :-)
> 
> I was never worried about Python, but I lay awake at night worrying about
> MS -- I'm still an MS shareholder, so don't screw this up <wink>.

I'm an MS shareholder, too.

Oh. Wait. Did I say I was involved? Don't think so...

ahem.

-g

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


From andy@reportlab.com  Wed Jun 28 08:03:07 2000
From: andy@reportlab.com (Andy Robinson)
Date: Wed, 28 Jun 2000 08:03:07 +0100
Subject: [Python-Dev] SourceForge win32 HOWTO
Message-ID: <PGECLPOBGNBNKHNAGIJHCEPDCCAA.andy@reportlab.com>

Sorry, I've been offline and missed this thread.  I could have saved you
some time. These are the instructions we've used at ReportLab to work with
SourceForge on Win32.  No problems so far despite several Unix and CVS
newbies, myself included.    They are adapted from an article by Jay Andrew
Kay somewhere on Sourceforge and are generic rather than specific to the
Python source.

I have used the ReportLab project and my user name as an example but I'm
sure you guys can adapt that....

1. Get ftp.reportlab.com/tools/cvs-1.10-win.zip and
ftp.reportlab.com/tools/ssh-1.2.14-win32bin.zip

(copied from somewhere obscure for safety, I forget where)

2. Unzip these to a location on your path.  Type 'cvs'
or 'shh' from somewhere else to verify.

3. Choose where to keep your CVS projects; let's assume
C:\code

4. Create a subdirectory c:\code\.ssh  (yes, dot-ssh)

5. Create two environment variables:
	HOME=C:\CODE
	CVS_RSH=SSH
On Win9x, this can be done in a batch file or autoexec.bat;
on NT or 2000, go to Control Panel | System | Environment
and set them at either user or machine level.
The first must point to the directory above your .ssh directory.

6. If not done so, get a Sourceforge account and a project
you can log in to.

7. Test SSH independently by doing
	SSH -l username myproject.sourceforge.net
It should prompt for a password, then tell you that
"myproject.sourceforge.net" is added to the list of known hosts;
then give you a shell.

8. You will need either a lengthy command line or a batch file
for each sourceforge project.  I set cvsroot in a batch file
in my 'c:\code' directory, and have one such file for each
CVS project I use (about ten of them!):

------cvsreportlab.bat--------------
set HOME=C:\CODE
set CVS_RSH=SSH
set CVSROOT=:ext:my_user_name@cvs.myproject.sourceforge.net:/cvsroot/dirname
---------------------------------------
'dirname' is the top level directory in the CVS tree; a project can have
several, but usually there is just one.

9. execute this batch file.  You can now go to C:\Code and do
	cvs -z7 checkout myproject
(z7 means 'compress network traffic', handy over dialup lines)

10. From now on, just use CVS normally.  I wouldn't survive without
Karl Fogel's book "Open Source Development with CVS", Coriolis Press.

Footnote: for anonymous checkout, I think you just omit
the 'my_user_name@' part from the CVSROOT variable.

I hope this helps; let me know if people have any problems
with the instructions.

-
Andy Robinson
ReportLab



From andy@reportlab.com  Wed Jun 28 08:03:08 2000
From: andy@reportlab.com (Andy Robinson)
Date: Wed, 28 Jun 2000 08:03:08 +0100
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <20000628025304.BB64A1CE0D@dinsdale.python.org>
Message-ID: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>

I missed all the SourceForge discussions, but ReportLab have been running
all our development on SourceForge for five months and I'd like to share
some concerns.

First, we all use command line CVS, mostly from Windows; I just posted our
setup instructions.  It works fine but a bit slowly.

I find the web interface totally unusable from IE5 and Netscape 4.XX,
working over 64k lines or dialup lines.  Once one logs in via SSL, only
about one click in five ever returns a sensible page, and most just time out
and give an error message.  Many other people on the reportlab-users list
and my team report similar problems.   On the other hand, many are
incredulous and say they have never had a problem.  I found no complaints on
the SF discussion groups, but as far as I can tell hardly anyone uses them.
It seems to be better over big corporate connections.  I don't think it is
because I am in Europe; we never have trouble with our US ISPs.

As a result of this, we have not used the wonderful looking bug tracking,
to-do-list, patch manager etc.

How many people here have actually created accounts for themselves on
SourceForge and tried to do stuff when logged in - raise bugs and so on?
Did it work for you?  We ought to get a few data points before making this
the way Python is managed.

- Andy Robinson





From nhodgson@bigpond.net.au  Wed Jun 28 08:23:52 2000
From: nhodgson@bigpond.net.au (Neil Hodgson)
Date: Wed, 28 Jun 2000 17:23:52 +1000
Subject: [Python-Dev] Sourceforge Interface Concerns
References: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <002401bfe0d1$d05a9fd0$e3cb8490@neil>

> How many people here have actually created accounts for themselves on
> SourceForge and tried to do stuff when logged in - raise bugs and so on?
> Did it work for you?  We ought to get a few data points before making this
> the way Python is managed.

   Its generally quite good for me now that I've upgraded from a modem to a
cable connection although there are brown-out periods. The only web browser
I have any success with is Navigator 4.6 and 4.7. Both IE and Mozilla give
poor results with SSL login. As far as getting other people to use the bug
logger, its been a complete failure. Its much easier to email me or the
mailing list.

   Some parts of SourceForge such as the file release upload are quite
poorly designed and are too unpleasant to use on a slow connection if you
have several packages for each release.

   Neil




From tpeters@beopen.com  Wed Jun 28 08:28:10 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 03:28:10 -0400
Subject: [Python-Dev] SourceForge win32 HOWTO
In-Reply-To: <PGECLPOBGNBNKHNAGIJHCEPDCCAA.andy@reportlab.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENOGGAA.tim_one@email.msn.com>

[Andy Robinson]
> Sorry, I've been offline and missed this thread.  I could have saved you
> some time. These are the instructions we've used at ReportLab to work with
> SourceForge on Win32.  No problems so far despite several Unix and CVS
> newbies, myself included. ...

Thanks, Andy!  I just *knew* that if I sat on my ass, someone would solve
this one for me <wink>.  I'll give these instructions a try, and also see
what it takes to adapt them to wincvs.  Note that I'm going to be putting
similar (perhaps, by an amazing coincidence, even identical) instructions up
on pythonlabs.com, so if you want to stop maintaining this, dump it on me.




From tpeters@beopen.com  Wed Jun 28 08:28:26 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 03:28:26 -0400
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENOGGAA.tim_one@email.msn.com>

[Andy Robinson]
> ...
> I find the web interface totally unusable from IE5 and Netscape 4.XX,
> working over 64k lines or dialup lines.  Once one logs in via SSL, only
> about one click in five ever returns a sensible page, and most
> just time out and give an error message.  Many other people on the
> reportlab-users list and my team report similar problems.   On the other
> hand, many are incredulous and say they have never had a problem.
> I found no complaints on the SF discussion groups, but as far as I can
> tell hardly anyone uses them.   It seems to be better over big corporate
> connections.  I don't think it is because I am in Europe; we never have
> trouble with our US ISPs.

I'm in the middle:  sometimes it works great, sometimes slow as molasses
(IE5 via 56K modem on the other side of the country), and an error each one
of two clicks.  Greg Stein lives near it, and reports wonderful access via
DSL.

> As a result of this, we have not used the wonderful looking bug tracking,
> to-do-list, patch manager etc.

They're actually pretty feeble.

> How many people here have actually created accounts for themselves on
> SourceForge and tried to do stuff when logged in - raise bugs and so on?
> Did it work for you?  We ought to get a few data points before making this
> the way Python is managed.

We're not using the bug tracker, task list, news, forum or support managers.
Just the CVS tree and the patch manager.  There are particular reasons for
using those particular two, and I doubt we'll be moving more there until SF
gets better.  OTOH, we're also interested in *helping* SF get better!  SF is
as much an Open Source project as Python, and it could become an incredible
resource for the entire OS community.

doesn't-mean-i-won't-gripe-too-though-ly y'rs  - tim




From gstein@lyra.org  Wed Jun 28 09:04:07 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 01:04:07 -0700
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCENOGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 03:28:26AM -0400
References: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk> <LNBBLJKPBEHFEDALKOLCCENOGGAA.tim_one@email.msn.com>
Message-ID: <20000628010407.T29590@lyra.org>

On Wed, Jun 28, 2000 at 03:28:26AM -0400, Tim Peters wrote:
>...
> We're not using the bug tracker, task list, news, forum or support managers.
> Just the CVS tree and the patch manager.  There are particular reasons for
> using those particular two, and I doubt we'll be moving more there until SF
> gets better.  OTOH, we're also interested in *helping* SF get better!  SF is
> as much an Open Source project as Python, and it could become an incredible
> resource for the entire OS community.

This last statement is (unfortunately) not quite true. SourceForge is
developed in a closed, cathedral environment. There is no CVS access to it,
and all the developers work at VA Linux. Strictly speaking, the *output* of
this closed development is GPL'd. But it isn't what you would expect.

The documentation for SF is separate. Apparently, there was an independent
effort to help do some documentation and they got a good ways. Then the VA
guys suddenly popped out the "SFDocs" project, ignoring the work from the
other people. Not sure where I read that, so I can't provide a reference to
the stories/threads :-(

btw, there is a survey about SF that you can fill out:
  http://sourceforge.net/survey/survey.php?group_id=1&survey_id=10599

Cheers,
-g

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


From mal@lemburg.com  Wed Jun 28 09:03:00 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Jun 2000 10:03:00 +0200
Subject: [Python-Dev] SF patch manager...
References: <LNBBLJKPBEHFEDALKOLCIEMBGGAA.tim_one@email.msn.com>
Message-ID: <3959B134.1538B4B7@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > [Please excuse my ranting... :-)]
> 
> No problem -- you're not complaining about *our* software <wink>.
> 
> > I've received the first round of notification message from the
> > patch manager and can't really say that I like them. Ok, I
> > understand that the patch manager is still alpha or beta software,
> > but these messages really don't have any usable content at all:
> >
> > """
> > Patch #100646 has been updated.
> > Visit SourceForge.net for more info.
> >
> >
> http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470
> > """
> 
> I expect the title of the patch was also in the Subject line, yes? 

Right, but that's just about all the information you get:
the title, the fact that something changed and a link to the
patch page.

> And a
> live link to the patch is certainly "usable".  I've found both those right
> on target as I've been assigned or deassigned to patches so far, although
> I'd sure like to see something in the body saying exactly *what* about the
> patch "has been updated".
> 
> Not saying I think it's good enough, am saying it's (barely) a start.

True and I don't want to put this down. The only reason for
my ranting is that I'd rather get more infos in mail than
via some link to a page. Discussing patches via quoting email
is just so much more convenient -- opening two or three 
browsers to get at the hard facts isn't and, as others have
already noted, is rather slow too.
 
> > Also, reviewing the patches has become a pain
> 
> I don't understand that, in that the text of the patch is what you got
> before, and what you can get now.  Is your complaint here specifically that
> patches don't show up in your mailbox by magic?  Or something else?

I would very much prefer to get the patches or changes
appended to the update messages (much like was manually done
on patches@python.org). That way I can read the patch and
then reply to the sender and the list community from within
the mail application -- without copy&paste, looking up
email addresses in SF etc.
 
> > and discussing them is nearly impossible (I don't consider the
> > slashdot like comment mechanism to be of any use: there's simply
> > no audience for discussion).
> 
> Wholly agreed there.  So use python-dev for discussions for now; I agree too
> with Guido that the rampant but inconsistent x-posting between patches and
> python-dev was part of the problem.
>
> > Is there any chance of tee'ing patches from SF to the patches
> > list or some other patch discussion and review forum ?
> 
> I expect you know as much about SF's possibilities as anyone <0.5 wink>:
> don't know.  The SF docs are either non-existent or inadequate, far as I can
> tell, and I believe I share a mistaken belief with Fred Drake that new
> patches "should" *already* be showing up on the patches list.

They are showing up there... at least new ones are. Discussions
(via posting comments on the patch page) are not relayed to the
list though: only the comment authors get an email.
 
> > I do understand that the mechanism can help with patch *checkins*,
> 
> Yes, but not yet as much as it should (e.g., the default view of patches
> lacks basic info like the patch current status, and there's apparently not
> yet any way to define a different view).
> 
> > but it's certainly not going to help much with the discussion
> > step needed before conidering any actions.
> 
> Python-Dev now, possibly roundup later.  OTOH, it's perfectly adequate for
> tiny little principal-reviewer <-> submitter give-and-take; many patches are
> really quite trivial.

True, but even small patches occasionally need peer review from 
more people than just the assigned developer.
 
> > The independent peer review principal doesn't work with this
> > kind of setup.
> 
> I think your view is warped on this one, as you've been in the extremely
> favored position of pumping out crucial patches for a hot area.  Most other
> peoples' patches have been flatly ignored for *months* now.  It's not
> necessarily bad if other people get some attention now too <wink>.

Oops, did it shine through that much ? ;-)

Seriously, I would like to see a processing speedup too, it's
just the workflow that bothers me a bit.

BTW, another great feature for the patch manager would be
a button to perform the actual checkin via the web interface.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From rob@hooft.net  Wed Jun 28 10:27:18 2000
From: rob@hooft.net (Rob W. W. Hooft)
Date: Wed, 28 Jun 2000 11:27:18 +0200 (CEST)
Subject: [Python-Dev] Typo's
Message-ID: <14681.50422.966321.780406@temoleh.chem.uu.nl>

I located some typo's in the CVS. Here is a patch.

Warning: I'm a non-native English speaker. Please verify fixes.

Rob

Index: Demo/pdist/rcslib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Demo/pdist/rcslib.py,v
retrieving revision 1.6
diff -u -r1.6 rcslib.py
--- Demo/pdist/rcslib.py	1998/09/14 16:43:57	1.6
+++ Demo/pdist/rcslib.py	2000/06/28 07:42:50
@@ -296,7 +296,7 @@
     def _system(self, cmd):
         """INTERNAL: run COMMAND in a subshell.
 
-        Standard input for the command is taken fron /dev/null.
+        Standard input for the command is taken from /dev/null.
 
         Raise IOError when the exit status is not zero.
 
Index: Demo/sgi/video/Vcopy.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vcopy.py,v
retrieving revision 1.7
diff -u -r1.7 Vcopy.py
--- Demo/sgi/video/Vcopy.py	1996/11/27 19:50:07	1.7
+++ Demo/sgi/video/Vcopy.py	2000/06/28 07:42:50
@@ -8,7 +8,7 @@
 # - Manipulate the time base:
 #   = resample at a fixed rate
 #   = divide the time codes by a speed factor (to make it go faster/slower)
-#   = drop frames that are less than n msec apart (to accomodate slow players)
+#   = drop frames that are less than n msec apart (to accommodate slow players)
 # - Convert to a different format
 # - Magnify (scale) the image
 
Index: Demo/sgi/video/Vtime.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vtime.py,v
retrieving revision 1.4
diff -u -r1.4 Vtime.py
--- Demo/sgi/video/Vtime.py	1996/11/27 19:50:28	1.4
+++ Demo/sgi/video/Vtime.py	2000/06/28 07:42:50
@@ -7,7 +7,7 @@
 #
 # - resample at a fixed rate
 # - divide the time codes by a speed factor (to make it go faster/slower)
-# - drop frames that are less than n msec apart (to accomodate slow players)
+# - drop frames that are less than n msec apart (to accommodate slow players)
 
 
 # Usage:
Index: Lib/Queue.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/Queue.py,v
retrieving revision 1.10
diff -u -r1.10 Queue.py
--- Lib/Queue.py	2000/02/02 15:10:14	1.10
+++ Lib/Queue.py	2000/06/28 07:42:51
@@ -119,7 +119,7 @@
     def _qsize(self):
         return len(self.queue)
 
-    # Check wheter the queue is empty
+    # Check whether the queue is empty
     def _empty(self):
         return not self.queue
 
Index: Lib/binhex.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/binhex.py,v
retrieving revision 1.12
diff -u -r1.12 binhex.py
--- Lib/binhex.py	2000/02/04 15:39:29	1.12
+++ Lib/binhex.py	2000/06/28 07:42:51
@@ -13,7 +13,7 @@
 # XXXX Note: currently, textfiles appear in mac-form on all platforms.
 # We seem to lack a simple character-translate in python.
 # (we should probably use ISO-Latin-1 on all but the mac platform).
-# XXXX The simeple routines are too simple: they expect to hold the complete
+# XXXX The simple routines are too simple: they expect to hold the complete
 # files in-core. Should be fixed.
 # XXXX It would be nice to handle AppleDouble format on unix
 # (for servers serving macs).
@@ -48,7 +48,7 @@
     try:
         openrf = MacOS.openrf
     except AttributeError:
-        # Backward compatability
+        # Backward compatibility
         openrf = open
     
     def FInfo():
Index: Lib/calendar.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/calendar.py,v
retrieving revision 1.15
diff -u -r1.15 calendar.py
--- Lib/calendar.py	2000/02/02 15:10:14	1.15
+++ Lib/calendar.py	2000/06/28 07:42:51
@@ -1,6 +1,6 @@
 """Calendar printing functions"""
 
-# Revision 2: uses funtions from built-in time module
+# Revision 2: uses functions from built-in time module
 
 # Import functions and variables from time module
 from time import localtime, mktime
Index: Lib/fnmatch.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/fnmatch.py,v
retrieving revision 1.7
diff -u -r1.7 fnmatch.py
--- Lib/fnmatch.py	1997/10/22 20:57:40	1.7
+++ Lib/fnmatch.py	2000/06/28 07:42:51
@@ -36,7 +36,7 @@
 	return fnmatchcase(name, pat)
 
 def fnmatchcase(name, pat):
-	"""Test wheter FILENAME matches PATTERN, including case.
+	"""Test whether FILENAME matches PATTERN, including case.
 	
 	This is a version of fnmatch() which doesn't case-normalize
 	its arguments.
Index: Lib/locale.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/locale.py,v
retrieving revision 1.6
diff -u -r1.6 locale.py
--- Lib/locale.py	2000/06/08 17:49:41	1.6
+++ Lib/locale.py	2000/06/28 07:42:52
@@ -220,7 +220,7 @@
 
         The language code corresponds to RFC 1766.  code and encoding
         can be None in case the values cannot be determined or are
-        unkown to this implementation.
+        unknown to this implementation.
 
     """
     code = normalize(localename)
@@ -229,7 +229,7 @@
     elif code == 'C':
         return None, None
     else:
-        raise ValueError,'unkown locale: %s' % localename
+        raise ValueError,'unknown locale: %s' % localename
     return l
 
 def _build_localename(localetuple):
Index: Lib/posixpath.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/posixpath.py,v
retrieving revision 1.30
diff -u -r1.30 posixpath.py
--- Lib/posixpath.py	2000/02/29 13:31:16	1.30
+++ Lib/posixpath.py	2000/06/28 07:42:52
@@ -24,7 +24,7 @@
     return s
 
 
-# Return wheter a path is absolute.
+# Return whether a path is absolute.
 # Trivial in Posix, harder on the Mac or MS-DOS.
 
 def isabs(s):
@@ -304,7 +304,7 @@
 
 # Expand paths containing shell variable substitutions.
 # This expands the forms $variable and ${variable} only.
-# Non-existant variables are left unchanged.
+# Non-existent variables are left unchanged.
 
 _varprog = None
 
Index: Lib/sgmllib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/sgmllib.py,v
retrieving revision 1.19
diff -u -r1.19 sgmllib.py
--- Lib/sgmllib.py	2000/02/04 15:28:40	1.19
+++ Lib/sgmllib.py	2000/06/28 07:42:53
@@ -47,7 +47,7 @@
 # <foo> and </foo>, respectively, or do_foo to handle <foo> by itself.
 # (Tags are converted to lower case for this purpose.)  The data
 # between tags is passed to the parser by calling self.handle_data()
-# with some data as argument (the data may be split up in arbutrary
+# with some data as argument (the data may be split up in arbitrary
 # chunks).  Entity references are passed by calling
 # self.handle_entityref() with the entity reference as argument.
 
Index: Lib/site.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/site.py,v
retrieving revision 1.11
diff -u -r1.11 site.py
--- Lib/site.py	2000/06/07 09:12:09	1.11
+++ Lib/site.py	2000/06/28 07:42:53
@@ -122,7 +122,7 @@
 #
 # Set the string encoding used by the Unicode implementation to the
 # encoding used by the default locale of this system. If the default
-# encoding cannot be determined or is unkown, it defaults to 'ascii'.
+# encoding cannot be determined or is unknown, it defaults to 'ascii'.
 #
 def locale_aware_defaultencoding():
     import locale
Index: Lib/urllib2.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/urllib2.py,v
retrieving revision 1.3
diff -u -r1.3 urllib2.py
--- Lib/urllib2.py	2000/02/10 17:17:14	1.3
+++ Lib/urllib2.py	2000/06/28 07:42:54
@@ -141,7 +141,7 @@
     _opener = opener
 
 # do these error classes make sense?
-# make sure all of the IOError stuff is overriden.  we just want to be 
+# make sure all of the IOError stuff is overridden.  we just want to be 
  # subtypes.
 
 class URLError(IOError):
Index: Lib/xmllib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/xmllib.py,v
retrieving revision 1.18
diff -u -r1.18 xmllib.py
--- Lib/xmllib.py	2000/06/21 20:01:10	1.18
+++ Lib/xmllib.py	2000/06/28 07:42:54
@@ -79,7 +79,7 @@
 # special names to handle tags: start_foo and end_foo to handle <foo>
 # and </foo>, respectively.  The data between tags is passed to the
 # parser by calling self.handle_data() with some data as argument (the
-# data may be split up in arbutrary chunks).
+# data may be split up in arbitrary chunks).
 
 class XMLParser:
     attributes = {}                     # default, to be overridden
Index: Lib/distutils/cmd.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/cmd.py,v
retrieving revision 1.18
diff -u -r1.18 cmd.py
--- Lib/distutils/cmd.py	2000/06/08 00:02:36	1.18
+++ Lib/distutils/cmd.py	2000/06/28 07:42:55
@@ -323,7 +323,7 @@
         should be disabled by the "dry run" flag, and should announce
         themselves if the current verbosity level is high enough.  This
         method takes care of all that bureaucracy for you; all you have to
-        do is supply the funtion to call and an argument tuple for it (to
+        do is supply the function to call and an argument tuple for it (to
         embody the "external action" being performed), a message to print
         if the verbosity level is high enough, and an optional verbosity
         threshold.
Index: Lib/distutils/util.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/util.py,v
retrieving revision 1.37
diff -u -r1.37 util.py
--- Lib/distutils/util.py	2000/06/24 20:40:02	1.37
+++ Lib/distutils/util.py	2000/06/28 07:42:55
@@ -28,7 +28,7 @@
         return os.path.normpath(path)
 
 
-# More backwards compatability hacks
+# More backwards compatibility hacks
 def extend (list, new_list):
     """Appends the list 'new_list' to 'list', just like the 'extend()'
        list method does in Python 1.5.2 -- but this works on earlier
Index: Lib/distutils/version.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/version.py,v
retrieving revision 1.1
diff -u -r1.1 version.py
--- Lib/distutils/version.py	1998/12/18 22:00:30	1.1
+++ Lib/distutils/version.py	2000/06/28 07:42:55
@@ -207,7 +207,7 @@
 # provides enough benefit to be worth using, and will submit their
 # version numbering scheme to its domination.  The free-thinking
 # anarchists in the lot will never give in, though, and something needs
-# to be done to accomodate them.
+# to be done to accommodate them.
 # 
 # Perhaps a "moderately strict" version class could be implemented that
 # lets almost anything slide (syntactically), and makes some heuristic
Index: Lib/distutils/command/build_ext.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/build_ext.py,v
retrieving revision 1.51
diff -u -r1.51 build_ext.py
--- Lib/distutils/command/build_ext.py	2000/06/28 01:29:37	1.51
+++ Lib/distutils/command/build_ext.py	2000/06/28 07:42:56
@@ -1,7 +1,7 @@
 """distutils.command.build_ext
 
 Implements the Distutils 'build_ext' command, for building extension
-modules (currently limited to C extensions, should accomodate C++
+modules (currently limited to C extensions, should accommodate C++
 extensions ASAP)."""
 
 # created 1999/08/09, Greg Ward
@@ -385,7 +385,7 @@
             # Next, compile the source code to object files.
 
             # XXX not honouring 'define_macros' or 'undef_macros' -- the
-            # CCompiler API needs to change to accomodate this, and I
+            # CCompiler API needs to change to accommodate this, and I
             # want to do one thing at a time!
 
             # Two possible sources for extra compiler arguments:
Index: Lib/dos-8x3/posixpat.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/posixpat.py,v
retrieving revision 1.10
diff -u -r1.10 posixpat.py
--- Lib/dos-8x3/posixpat.py	2000/05/08 17:31:00	1.10
+++ Lib/dos-8x3/posixpat.py	2000/06/28 07:42:56
@@ -24,7 +24,7 @@
     return s
 
 
-# Return wheter a path is absolute.
+# Return whether a path is absolute.
 # Trivial in Posix, harder on the Mac or MS-DOS.
 
 def isabs(s):
@@ -304,7 +304,7 @@
 
 # Expand paths containing shell variable substitutions.
 # This expands the forms $variable and ${variable} only.
-# Non-existant variables are left unchanged.
+# Non-existent variables are left unchanged.
 
 _varprog = None
 
Index: Lib/dos-8x3/queue.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/queue.py,v
retrieving revision 1.7
diff -u -r1.7 queue.py
--- Lib/dos-8x3/queue.py	2000/05/08 17:31:00	1.7
+++ Lib/dos-8x3/queue.py	2000/06/28 07:42:56
@@ -119,7 +119,7 @@
     def _qsize(self):
         return len(self.queue)
 
-    # Check wheter the queue is empty
+    # Check whether the queue is empty
     def _empty(self):
         return not self.queue
 
Index: Lib/dos-8x3/test_win.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_win.py,v
retrieving revision 1.1
diff -u -r1.1 test_win.py
--- Lib/dos-8x3/test_win.py	2000/05/08 17:31:03	1.1
+++ Lib/dos-8x3/test_win.py	2000/06/28 07:42:57
@@ -115,7 +115,7 @@
     # Opening should now fail!
     try:
         key = OpenKey(root_key, test_key_name)
-        assert 0, "Could open the non-existant key"
+        assert 0, "Could open the non-existent key"
     except WindowsError: # Use this error name this time
         pass
 
Index: Lib/dos-8x3/test_zli.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_zli.py,v
retrieving revision 1.5
diff -u -r1.5 test_zli.py
--- Lib/dos-8x3/test_zli.py	2000/05/08 17:31:03	1.5
+++ Lib/dos-8x3/test_zli.py	2000/06/28 07:42:57
@@ -11,7 +11,7 @@
 buf = file.read() * 8
 file.close()
 
-# test the chucksums (hex so the test doesn't break on 64-bit machines)
+# test the checksums (hex so the test doesn't break on 64-bit machines)
 print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1))
 print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1))
 
Index: Lib/plat-irix5/CL_old.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/CL_old.py,v
retrieving revision 1.1
diff -u -r1.1 CL_old.py
--- Lib/plat-irix5/CL_old.py	1995/05/17 11:18:22	1.1
+++ Lib/plat-irix5/CL_old.py	2000/06/28 07:42:57
@@ -200,7 +200,7 @@
 BOTTOM_UP = 1
 
 #
-# SGI Proprietaty Algorithm Header Start Code
+# SGI Proprietary Algorithm Header Start Code
 #
 HEADER_START_CODE = 0xc1C0DEC
 
Index: Lib/plat-irix5/flp.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/flp.py,v
retrieving revision 1.17
diff -u -r1.17 flp.py
--- Lib/plat-irix5/flp.py	1998/03/26 20:22:58	1.17
+++ Lib/plat-irix5/flp.py	2000/06/28 07:42:57
@@ -203,7 +203,7 @@
     return datum[1]
 #
 # Internal: parse fd form, or skip if name doesn't match.
-# the special value None means 'allways parse it'.
+# the special value None means 'always parse it'.
 #
 def _parse_fd_form(file, name):
     datum = _parse_1_line(file)
@@ -222,7 +222,7 @@
     return None
 
 #
-# Internal class: a convient place to store object info fields
+# Internal class: a convenient place to store object info fields
 #
 class _newobj:
     def add(self, name, value):
Index: Lib/plat-irix5/panel.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/panel.py,v
retrieving revision 1.4
diff -u -r1.4 panel.py
--- Lib/plat-irix5/panel.py	1995/09/18 22:00:37	1.4
+++ Lib/plat-irix5/panel.py	2000/06/28 07:42:58
@@ -2,7 +2,7 @@
 #
 # Support for the Panel library.
 # Uses built-in module 'pnl'.
-# Applciations should use 'panel.function' instead of 'pnl.function';
+# Applications should use 'panel.function' instead of 'pnl.function';
 # most 'pnl' functions are transparently exported by 'panel',
 # but dopanel() is overridden and you have to use this version
 # if you want to use callbacks.
@@ -137,7 +137,7 @@
 					print 'assign failed:', stmt
 
 
-# Build a real actuator from an actuator descriptior.
+# Build a real actuator from an actuator description.
 # Return a pair (actuator, name).
 #
 def build_actuator(descr):
Index: Lib/plat-irix6/flp.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/flp.py,v
retrieving revision 1.4
diff -u -r1.4 flp.py
--- Lib/plat-irix6/flp.py	1998/03/26 20:23:01	1.4
+++ Lib/plat-irix6/flp.py	2000/06/28 07:42:58
@@ -203,7 +203,7 @@
     return datum[1]
 #
 # Internal: parse fd form, or skip if name doesn't match.
-# the special value None means 'allways parse it'.
+# the special value None means 'always parse it'.
 #
 def _parse_fd_form(file, name):
     datum = _parse_1_line(file)
@@ -222,7 +222,7 @@
     return None
 
 #
-# Internal class: a convient place to store object info fields
+# Internal class: a convenient place to store object info fields
 #
 class _newobj:
     def add(self, name, value):
Index: Lib/plat-irix6/panel.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/panel.py,v
retrieving revision 1.1
diff -u -r1.1 panel.py
--- Lib/plat-irix6/panel.py	1997/01/15 19:19:11	1.1
+++ Lib/plat-irix6/panel.py	2000/06/28 07:42:58
@@ -2,7 +2,7 @@
 #
 # Support for the Panel library.
 # Uses built-in module 'pnl'.
-# Applciations should use 'panel.function' instead of 'pnl.function';
+# Applications should use 'panel.function' instead of 'pnl.function';
 # most 'pnl' functions are transparently exported by 'panel',
 # but dopanel() is overridden and you have to use this version
 # if you want to use callbacks.
@@ -137,7 +137,7 @@
 					print 'assign failed:', stmt
 
 
-# Build a real actuator from an actuator descriptior.
+# Build a real actuator from an actuator description.
 # Return a pair (actuator, name).
 #
 def build_actuator(descr):
Index: Lib/test/test_al.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_al.py,v
retrieving revision 1.2
diff -u -r1.2 test_al.py
--- Lib/test/test_al.py	1998/03/26 19:41:38	1.2
+++ Lib/test/test_al.py	2000/06/28 07:42:58
@@ -8,7 +8,7 @@
 alattrs = ['__doc__', '__name__', 'getdefault', 'getminmax', 'getname', 'getparams',
            'newconfig', 'openport', 'queryparams', 'setparams']
 
-# This is a very inobstrusive test for the existance of the al module and all it's
+# This is a very inobtrusive test for the existence of the al module and all it's
 # attributes.  More comprehensive examples can be found in Demo/al
 
 def main():
Index: Lib/test/test_b1.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_b1.py,v
retrieving revision 1.22
diff -u -r1.22 test_b1.py
--- Lib/test/test_b1.py	2000/04/14 19:13:22	1.22
+++ Lib/test/test_b1.py	2000/06/28 07:42:58
@@ -270,7 +270,7 @@
 # Different base:
 if int("10",16) <> 16L: raise TestFailed, 'int("10",16)'
 if int(u"10",16) <> 16L: raise TestFailed, 'int(u"10",16)'
-# Test conversion fron strings and various anomalies
+# Test conversion from strings and various anomalies
 L = [
         ('0', 0),
         ('1', 1),
Index: Lib/test/test_cd.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cd.py,v
retrieving revision 1.2
diff -u -r1.2 test_cd.py
--- Lib/test/test_cd.py	1998/03/26 19:41:49	1.2
+++ Lib/test/test_cd.py	2000/06/28 07:42:58
@@ -10,7 +10,7 @@
            'ident', 'index', 'msftoframe', 'open', 'pnum', 'ptime']
 
 
-# This is a very inobstrusive test for the existance of the cd module and all it's
+# This is a very inobtrusive test for the existence of the cd module and all it's
 # attributes.  More comprehensive examples can be found in Demo/cd and
 # require that you have a CD and a CD ROM drive
 
Index: Lib/test/test_cl.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cl.py,v
retrieving revision 1.2
diff -u -r1.2 test_cl.py
--- Lib/test/test_cl.py	1998/03/26 19:41:52	1.2
+++ Lib/test/test_cl.py	2000/06/28 07:42:58
@@ -63,7 +63,7 @@
 'YUV422DC', 'YUV422HC', '__doc__', '__name__', 'cvt_type', 'error']
 
 
-# This is a very inobstrusive test for the existance of the cl
+# This is a very inobtrusive test for the existence of the cl
 # module and all it's attributes.
 
 def main():
Index: Lib/test/test_pwd.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_pwd.py,v
retrieving revision 1.5
diff -u -r1.5 test_pwd.py
--- Lib/test/test_pwd.py	1998/03/26 19:42:32	1.5
+++ Lib/test/test_pwd.py	2000/06/28 07:42:58
@@ -59,7 +59,7 @@
 else:
     print 'fakename', fakename, 'did not except pwd.getpwnam()'
 
-# Choose a non-existant uid.
+# Choose a non-existent uid.
 fakeuid = 4127
 while byuids.has_key(fakeuid):
     fakeuid = (fakeuid * 3) % 0x10000
Index: Lib/test/test_winreg.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_winreg.py,v
retrieving revision 1.2
diff -u -r1.2 test_winreg.py
--- Lib/test/test_winreg.py	2000/04/01 05:25:57	1.2
+++ Lib/test/test_winreg.py	2000/06/28 07:42:58
@@ -115,7 +115,7 @@
     # Opening should now fail!
     try:
         key = OpenKey(root_key, test_key_name)
-        assert 0, "Could open the non-existant key"
+        assert 0, "Could open the non-existent key"
     except WindowsError: # Use this error name this time
         pass
 
Index: Lib/test/test_zlib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_zlib.py,v
retrieving revision 1.7
diff -u -r1.7 test_zlib.py
--- Lib/test/test_zlib.py	2000/02/10 15:31:07	1.7
+++ Lib/test/test_zlib.py	2000/06/28 07:42:59
@@ -11,7 +11,7 @@
 buf = file.read() * 8
 file.close()
 
-# test the chucksums (hex so the test doesn't break on 64-bit machines)
+# test the checksums (hex so the test doesn't break on 64-bit machines)
 print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1))
 print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1))
 
Index: Python/exceptions.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/exceptions.c,v
retrieving revision 1.2
diff -u -r1.2 exceptions.c
--- Python/exceptions.c	2000/06/20 18:36:26	1.2
+++ Python/exceptions.c	2000/06/28 07:42:59
@@ -189,7 +189,7 @@
  *
  * First thing we create is the base class for all exceptions, called
  * appropriately enough: Exception.  Creation of this class makes no
- * assumptions about the existance of any other exception class -- except
+ * assumptions about the existence of any other exception class -- except
  * for TypeError, which can conditionally exist.
  *
  * Next, StandardError is created (which is quite simple) followed by
Index: Python/import.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/import.c,v
retrieving revision 2.134
diff -u -r2.134 import.c
--- Python/import.c	2000/05/03 23:44:39	2.134
+++ Python/import.c	2000/06/28 07:43:01
@@ -87,7 +87,7 @@
 #define MAGIC (50428 | ((long)'\r'<<16) | ((long)'\n'<<24))
 
 /* Magic word as global; note that _PyImport_Init() can change the
-   value of this global to accomodate for alterations of how the
+   value of this global to accommodate for alterations of how the
    compiler works which are enabled by command line switches. */
 static long pyc_magic = MAGIC;
 


From Fredrik Lundh" <effbot@telia.com  Wed Jun 28 10:47:32 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 11:47:32 +0200
Subject: [Python-Dev] Typo's
References: <14681.50422.966321.780406@temoleh.chem.uu.nl>
Message-ID: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid>

> I located some typo's in the CVS. Here is a patch.

wow!

just one nit:

"inobstrusive" should be "unobtrusive" (not "inobtrusive")

(and it's not clear if "descriptior" means "description" or
"descriptor"...)

> Warning: I'm a non-native English speaker.

same here.

</F>



From Fredrik Lundh" <effbot@telia.com  Wed Jun 28 12:07:24 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 13:07:24 +0200
Subject: [Python-Dev] OT: A Day in the Life of p5p
Message-ID: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>

http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

unfortunately, his "What is it with those Python fucks anyway" talk
isn't posted... ;-)

</F>



From fdrake@beopen.com  Wed Jun 28 12:16:53 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 07:16:53 -0400 (EDT)
Subject: [Python-Dev] back up & running
Message-ID: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com>

  My mega-laptop got fixed faster than I'd expected, so I'm back up to
doing useful work.  My top priorities are handling patches and going
back through my email to find all the documentation patches that have
sat idle for too long.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From mwh21@cam.ac.uk  Wed Jun 28 12:54:27 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 28 Jun 2000 12:54:27 +0100
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: "Andy Robinson"'s message of "Wed, 28 Jun 2000 08:03:08 +0100"
References: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <m3vgyu9g24.fsf@atrus.jesus.cam.ac.uk>

"Andy Robinson" <andy@robanal.demon.co.uk> writes:

> It seems to be better over big corporate connections.  I don't think it is
> because I am in Europe; we never have trouble with our US ISPs.

FWIW, it's pretty good from here (but then the university has pretty
serious bandwidth).  It seems a bit odd that it's so much worse with
lower badwidth (in particular that people on modems get more errors).
Oh well.

Cheers,
M.



From Vladimir.Marangozov@inrialpes.fr  Wed Jun 28 13:22:56 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Wed, 28 Jun 2000 14:22:56 +0200 (CEST)
Subject: [Python-Dev] back up & running
In-Reply-To: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jun 28, 2000 07:16:53 AM
Message-ID: <200006281222.OAA03150@python.inrialpes.fr>

Fred L. Drake, Jr. wrote:
> 
>   My mega-laptop got fixed faster than I'd expected, so I'm back up to
> doing useful work.  My top priorities are handling patches and going
> back through my email to find all the documentation patches that have
> sat idle for too long.

Excellent!

Finally someone who cares to checkin patches. I've been disappointed
to see that the June 30 intent-date was announced, but people keep
chewing-gumming about SourceForge caveats while the patches backlog
grows and the number of closed patches stays invariably to 3, of which
one is a test!

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From bwarsaw@beopen.com  Wed Jun 28 14:27:12 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 09:27:12 -0400 (EDT)
Subject: [Python-Dev] Sourceforge Interface Concerns
References: <20000628025304.BB64A1CE0D@dinsdale.python.org>
 <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <14681.64816.561341.920024@anthem.concentric.net>

>>>>> "AR" == Andy Robinson <andy@robanal.demon.co.uk> writes:

    AR> How many people here have actually created accounts for
    AR> themselves on SourceForge and tried to do stuff when logged in
    AR> - raise bugs and so on?  Did it work for you?  We ought to get
    AR> a few data points before making this the way Python is
    AR> managed.

In general SF's web has been fine for me, although it is sometimes
unavailable due to routing problems.  I'm on a fairly reliable DSL
line now, though I don't remember significantly more SF-blamable
problems when I was on a 56K line.

It's often quite slow to do CVS/SSH to SF.  Sometimes I'll have to
spin for several minutes just to do an update or a diff.  That sucks.

-Barry


From fdrake@beopen.com  Wed Jun 28 14:30:22 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 09:30:22 -0400 (EDT)
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
References: <20000628025304.BB64A1CE0D@dinsdale.python.org>
 <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com>

Andy Robinson writes:
 > I find the web interface totally unusable from IE5 and Netscape 4.XX,
 > working over 64k lines or dialup lines.  Once one logs in via SSL, only
 > about one click in five ever returns a sensible page, and most just time out

  I've not been able to reproduce this behavior; the Web interface
seems to work well with IE5 and Netscape 4.XX for me; the only problem
I've had with IE5 is accessing a project's anonymous FTP area from the
project page (IE5 just froze completely).  Netscape didn't exhibit
that problem for me and allowed perfectly reasonable use.
  Sometimes it seems a little slow, but I attribute that to load and
the public-key crypto using SSH for CVS access; I understand that CVS
doesn't have the most efficient wire-protocol either.
  I should note that I've mostly used it over T1 and cable modem
links; I don't know that smaller pipes would make a huge difference
though.  I'd be more suspicious of trans-Atlantic linkage than
anything else without having more information.  Routing can do strange
things, so you may be getting the worst-possible link for SourceForge
while other things get better routes, but I wouldn't expect that to be
terribly consistent.

 > How many people here have actually created accounts for themselves on
 > SourceForge and tried to do stuff when logged in - raise bugs and so on?
 > Did it work for you?  We ought to get a few data points before making this
 > the way Python is managed.

  I've never had the kind of problems you describe.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From Vladimir.Marangozov@inrialpes.fr  Wed Jun 28 14:58:26 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Wed, 28 Jun 2000 15:58:26 +0200 (CEST)
Subject: [Python-Dev] Typo's
In-Reply-To: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 28, 2000 11:47:32 AM
Message-ID: <200006281358.PAA03368@python.inrialpes.fr>

Fredrik Lundh wrote:
> 
> > I located some typo's in the CVS. Here is a patch.
> 
> wow!

Wow, indeed.
+1

I've uploaded this patch to SourceForge.

> 
> just one nit:
> 
> "inobstrusive" should be "unobtrusive" (not "inobtrusive")

fixed in the patch.

> 
> (and it's not clear if "descriptior" means "description" or
> "descriptor"...)

I examined the patched file - it's "description".


> 
> > Warning: I'm a non-native English speaker.
> 
> same here.

same here :-)

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From guido@beopen.com  Wed Jun 28 15:55:00 2000
From: guido@beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 09:55:00 -0500
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: Your message of "Tue, 27 Jun 2000 18:46:15 MST."
 <20000627184615.A29590@lyra.org>
References: <20000627184615.A29590@lyra.org>
Message-ID: <200006281455.JAA01690@cj20424-a.reston1.va.home.com>

> A while back, I pulled the "demo" importers out of imputil.py. I think those
> should be added into Demo/imputil/.

OK.  Go ahead and create that directory and add the demo importers.

> It would also be Goodness to include JimA's zipimporter. Where would that go?

Same place I'd hope?  Can you check that it works?

We're dependent on you volunteers to maintain relatively non-core
things like this -- I don't want to extend the feature freeze to
Demo/, but I also don't have the time to keep the stuff there up to
date.  Maybe at some point the Demo directory should become a separate
distribution, or just a collection of stuff on the web?

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


From akuchlin@mems-exchange.org  Wed Jun 28 15:07:22 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 10:07:22 -0400
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com>
References: <20000628025304.BB64A1CE0D@dinsdale.python.org> <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk> <14681.65006.782463.491824@cj42289-a.reston1.va.home.com>
Message-ID: <20000628100722.A9063@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 09:30:22AM -0400, Fred L. Drake, Jr. wrote:
>  I should note that I've mostly used it over T1 and cable modem
>links; I don't know that smaller pipes would make a huge difference
>though. 

At home I have a 28.8 modem (never figured out how to upgrade it to
56K), and while CVS operations are fairly slow, there usually aren't
any problems.  The same goes for accessing the Web pages through SSL;
somewhat slow, but reliable.

--amk


From gward@mems-exchange.org  Wed Jun 28 15:18:12 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Wed, 28 Jun 2000 10:18:12 -0400
Subject: [Python-Dev] Python 1.6 planning
In-Reply-To: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400
References: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>
Message-ID: <20000628101812.A15643@ludwig.cnri.reston.va.us>

On 23 June 2000, Jeremy Hylton said:
> ldso_aix-- I still don't understand, but I didn't really try; Vladimir must
> help

This has been fixed in the Distutils.  AFAIK it's still broken for
Makefile.pre.in builds -- as long as the installed Makefile is fixed
(not the actual installation location of ld_so_aix), then Distutils
builds will continue to work.

(Thanks to Rene Liebscher for providing the Distutils fix, and Vladimir
for testing it.)

        Greg


From gward@mems-exchange.org  Wed Jun 28 15:29:02 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Wed, 28 Jun 2000 10:29:02 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37
In-Reply-To: <20000624151824.A29590@lyra.org>; from gstein@lyra.org on Sat, Jun 24, 2000 at 03:18:24PM -0700
References: <200006242040.NAA28315@slayer.i.sourceforge.net> <20000624151824.A29590@lyra.org>
Message-ID: <20000628102901.B15643@ludwig.cnri.reston.va.us>

On 24 June 2000, Greg Stein said:
> Would the "shlex" module be helpful here? It is in the standard library and
> is (well?) maintained by ESR. It could help reduce the code inside
> distutils.

I looked at "shlex", but didn't like the fact that it 1) does
character-by-character analysis of input, and 2) requires a file-like
object.  Just a performance concern, really.

> [ I've always questioned the need for distutils' own "copy file" functions
>   and whatnot... seems there is a bit of duplication occurring... ]

Two reasons for that: bugs in the standard library versions, and missing
features in the standard library versions.  I think the first argument
goes away now that I've given up on 1.5.1 compatibility (shutil.py was
really broken in 1.5.1), but the fact remains that the copy functions in
shutil.py don't have a dry_run option, don't have a verbose option,
don't have a preserve_times option, don't have a preserve_symlinks
option, etc.  All of these things are somewhere between useful and
necessary.

I'm always open for ideas on reducing the amount of code in the
Distutils; it really is getting ridiculous.  It cracked 10k lines of
code+comments+doc this weekend -- about 5300 lines of straight code, I
think.  Anyways, the basic required functionality is now in place, so
I'm open to clever refactoring/reduction/simplification patches.

        Greg


From guido@beopen.com  Wed Jun 28 16:41:26 2000
From: guido@beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 10:41:26 -0500
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Wed, 28 Jun 2000 02:23:40 -0400."
 <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>
Message-ID: <200006281541.KAA02041@cj20424-a.reston1.va.home.com>

> Since we (PythonLabs, last week) decided to continue using Jitterbug (on
> python.org) for now, should the SF Bug Manager even be enabled?  If it is
> enabled, and we are using Jitterbug, then someone has to own reentering SF
> bugs into the Jitterbug system.

OK, I've disabled the SF bugs manager.  There were two bugs submitted
so far.  I've assigned one to you (about os.listdir on Windows) and
one to MAL (about -U vs. exec/eval).  You two can take care of
entering these into JB.  You can still access the bugs database via
this URL:

https://sourceforge.net/bugs/?group_id=5470

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


From gward@mems-exchange.org  Wed Jun 28 16:35:05 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Wed, 28 Jun 2000 11:35:05 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 01:07:24PM +0200
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
Message-ID: <20000628113505.C15643@ludwig.cnri.reston.va.us>

On 28 June 2000, Fredrik Lundh said:
> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt
> 
> unfortunately, his "What is it with those Python fucks anyway" talk
> isn't posted... ;-)

But the "Conclusion" of his "Lies We Tell" talk:

   Perl sucks. Use Python.

Presumably tongue-in-cheek, but you never know...

        Greg


From trentm@activestate.com  Wed Jun 28 17:53:19 2000
From: trentm@activestate.com (Trent Mick)
Date: Wed, 28 Jun 2000 09:53:19 -0700
Subject: [Python-Dev] back up & running
In-Reply-To: <200006281222.OAA03150@python.inrialpes.fr>
References: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> <200006281222.OAA03150@python.inrialpes.fr>
Message-ID: <20000628095319.C14129@activestate.com>

On Wed, Jun 28, 2000 at 02:22:56PM +0200, Vladimir Marangozov wrote:
> Fred L. Drake, Jr. wrote:
> > 
> >   My mega-laptop got fixed faster than I'd expected, so I'm back up to
> > doing useful work.  My top priorities are handling patches and going
> > back through my email to find all the documentation patches that have
> > sat idle for too long.
> 
> Excellent!
> 
> Finally someone who cares to checkin patches. I've been disappointed
> to see that the June 30 intent-date was announced, but people keep
> chewing-gumming about SourceForge caveats while the patches backlog
> grows and the number of closed patches stays invariably to 3, of which
> one is a test!
> 

You can count me as one of the significatn bottlenecks here. Tim and Guido
have accepted some of my patches, I just have to check them in. Real Soon Now
(tm).


Trent Mick (also tm)

-- 
Trent Mick
trentm@activestate.com


From mal@lemburg.com  Wed Jun 28 17:57:35 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Jun 2000 18:57:35 +0200
Subject: [Python-Dev] Named Unicode Characters
Message-ID: <395A2E7F.A1DDEC35@lemburg.com>

I've just checked in the patches by Bill Tutt, which add
support for \N{NAMED UNICODE CHARACTERS}. The new escape
code is available per default in the standard unicode-escape
codec. The (big) hash table needed to drive the mapping
is loaded on demand to reduce memory overhead.

The patch also includes a new tool called perfecthash which
is used to generate the hash table (and function) from 
names to ordinals. I'm sure this can be of use in other
areas too... but it needs some more work to become more
generic (currently you have to edit the source code to generate
other mapping modules).

Thanks to Bill Tutt -- this is great work !

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From paul@prescod.net  Wed Jun 28 18:11:19 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:11:19 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
Message-ID: <395A31B7.911D9BC2@prescod.net>

Fredrik Lundh wrote:
> 
> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

How about this one:

http://gisle.aas.no/perl/illguts/

Just thank your lucky stars...

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski


From paul@prescod.net  Wed Jun 28 18:16:45 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:16:45 -0700
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>
Message-ID: <395A32FD.D3C58B23@prescod.net>

I don't want to be paranoid, but are we putting any important
information into SourceForge that we are not backing up elsewhere? I
mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust
suit...) would we have backups of our patches, bugs, wish lists and so
forth? I hope that's a criteria in deciding what services to move to
SourceForge. I am in the business of preserving investments in data and
of telling customers to avoid software that does not keep them in
complete control of their data. SF makes me nervous that way....

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski


From mal@lemburg.com  Wed Jun 28 18:22:40 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Jun 2000 19:22:40 +0200
Subject: [Python-Dev] Checkin Utility
Message-ID: <395A3460.3FF013F0@lemburg.com>

This is a multi-part message in MIME format.
--------------4A599D73348784E859687D01
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I thought you might have some use for the attached utility. It's
a simple script which helps with checking in patches which I've
been using for a while now. It also hides the CVS options and
parameters away as far as possible, so that CVS knowledge is
not really needed to complete the task.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
--------------4A599D73348784E859687D01
Content-Type: text/python; charset=us-ascii;
 name="checkin.py"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="checkin.py"

#!/usr/local/bin/python -u
"""
    Tools for (interactive) CVS checkins.

    (c) Marc-Andre Lemburg, mal@lemburg.com, All Rights Reserved.

    Permission to use, copy, modify, and distribute this software and its
    documentation for any purpose and without fee or royalty is hereby granted,
    provided that the above copyright notice appear in all copies and that
    both that copyright notice and this permission notice appear in
    supporting documentation or portions thereof, including modifications,
    that you make.

    THE AUTHOR MARC-ANDRE LEMBURG DISCLAIMS ALL WARRANTIES WITH REGARD TO
    THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
    FITNESS, IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL,
    INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
    FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
    NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
    WITH THE USE OR PERFORMANCE OF THIS SOFTWARE !

"""#"

import string,os,exceptions,tempfile,sys

__version__ = '0.3'

### Configuration

# CVS Options which will always be used
CVSOPTIONS = '-z3'

# Path of the cvs tool
CVS = "/usr/bin/cvs"

# Default name of patcher
default_author = 'Marc-Andre Lemburg'
default_email = 'mal@lemburg.com'

# Check the settings
if not os.path.exists(CVS):
    CVS = 'cvs'

# Debug ?
__debug__ = 0

### Errors

class CVSError(exceptions.StandardError):
    pass

### Low Level interface

def cvs(command, flags=(), files=(), options=(), test=0):

    if options:
        options = '-' + string.join(options, ' -')
    else:
        options = ''
    if flags:
        flags = '-' + string.join(flags, ' -')
    else:
        flags = ''
    cmd = '%s %s %s %s %s %s' % (CVS,
                                 CVSOPTIONS,
                                 options,
                                 command,
                                 flags,
                                 string.join(files, ' '))
    if test:
        print '* exec "%s"' % cmd
        return ''
    try:
        p = os.popen(cmd)
    except os.error,why:
        raise CVSError, why
    return p.read()

def check_files(files=('.',), modify=0):

    options = options=('q',)
    if not modify:
        options = options + ('n',)
    output = cvs('update', files=files, options=options)
    lines = string.split(output, '\n')
    added_files = []
    modified_files = []
    updated_files = []
    patched_files = []
    for line in lines:
        if not line:
            continue
        try:
            marker, filename = string.split(line)
        except ValueError:
            if __debug__:
                print '* could not parse: "%s"' % line
            continue
        if marker == '?':
            list = added_files
        elif marker == 'M':
            list = modified_files
        elif marker == 'U':
            list = updated_files
        elif marker == 'P':
            list = patched_files
        else:
            if __debug__:
                print '* unkown marker: "%s" for file "%s"' % \
                      (marker, filename)
            continue
        list.append(filename)
    return added_files, modified_files, updated_files, patched_files

def update_files(files=('.',), verbose=0):

    return check_files(files, modify=1)

def print_check_results(a, m, u, p):

    if a:
        print 'Added to work dir:'
        for filename in a:
            print '  ',filename
    if m:
        print 'Modified in work dir:'
        for filename in m:
            print '  ',filename
    if u:
        print 'Updated in repository:'
        for filename in u:
            print '  ',filename
    if p:
        print 'Patched in repository:'
        for filename in p:
            print '  ',filename

def checkin_files(files, message='', rev=''):

    options = ('Q',)
    flags = ()
    if message:
        tempname = tempfile.mktemp()
        open(tempname, 'w').write(message)
        flags = flags + ('F %s' % tempname,)
    else:
        tempname = ''
    if rev:
        flags = flags + ('r %s' % rev,)
    try:
        if not __debug__:
            output = cvs('commit', files=files, options=options, flags=flags)
        else:
            output = cvs('commit', files=files, options=options, flags=flags,
                         test=1)
            print message
        if output:
            if __debug__:
                print '* commit output:'
                print output
    finally:
        os.unlink(tempname)

def checkin_file(file, message='', rev=''):

    return checkin_files((file,), message, rev)
    
def add_files(files):

    if not __debug__:
        output = cvs('add', files=files, options=('Q',))
    else:
        output = cvs('add', files=files, options=('Q',), test=1)
    if output:
        if __debug__:
            print '* add output:'
            print output

def add_file(file):

    return add_files((file,))

def multiline_input(prompt='', term='.', linesep='\n'):

    lines = []
    while 1:
        line = raw_input(prompt)
        if not lines and \
           not line:
            return ''
        if line == term or \
           lines and lines[-1] == line:
            return string.join(lines, linesep)
        lines.append(line)

def format_message(message, author, email=''):

    if email:
        header = '%s <%s>:\n' % (author, email)
    elif author:
        header = '%s:\n' % (author)
    else:
        header = ''
    msg = header + message
    return string.strip(msg)
    
if __name__ == '__main__':

    # -f cmd line switch
    if len(sys.argv) > 1 and sys.argv[1] == '-f':
        force = 1
    else:
        force = 0

    print '='*72
    print 'CVS Checkin Utility'
    print '-'*72
    print
    print 'Checking work dir...',
    a,m,u,p = check_files()
    if not force and \
       (u or p):
        print
        print '* Files changed in the repository since the last update.'
        print '* Please update before proceeding with the checkin or run'
        print '* this script with switch -f.'
        print
        print 'For your information, these files were found to be out'
        print 'of sync:'
        print
        print_check_results((),(),u,p)
        sys.exit(1)
    print 'done.'
    print
    if not a and not m:
        print '* No files need to be checked in.'
        print
        sys.exit(1)

    print 'These files will be checked in:'
    print
    print_check_results(a,m,u,p)

    print
    print '='*72
    print 'Please enter the name and email of the patch author:'
    print
    author = raw_input('Name: [%s] ' % default_author) or default_author
    email = raw_input('EMail: [%s] ' % default_email) or default_email

    print
    print '='*72
    print 'Please enter the commit messages for each file below...'
    print
    print '[Emtpy entries will be skipped, comments must be terminated by'
    print ' line containing a single dot or two consecutive empty lines]'

    if a:
        print
        print '# New Files:'
        for file in a:
            print
            print '%s' % file
            print '-'*72
            message = multiline_input(term='.')
            print '-'*72
            if not message:
                print '>>> (commit skipped)'
                continue
            print '>>> Adding to CVS Repository...',
            message = format_message(message, author, email)
            add_file(file)
            checkin_file(file, message)
            print 'done.'

    if m:
        print
        print '# Modified Files:'
        for file in m:
            print
            print '%s' % file
            print '-'*72
            message = multiline_input(term='.')
            print '-'*72
            if not message:
                print '>>> (commit skipped)'
                continue
            print '>>> Committing to CVS Repository...',
            message = format_message(message, author, email)
            checkin_file(file, message)
            print 'done.'

    print
    print 'Done. Thanks :-)'

--------------4A599D73348784E859687D01--



From esr@thyrsus.com  Wed Jun 28 18:38:05 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Wed, 28 Jun 2000 13:38:05 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:11:19AM -0700
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net>
Message-ID: <20000628133805.D20855@thyrsus.com>

Paul Prescod <paul@prescod.net>:
> http://gisle.aas.no/perl/illguts/
> 
> Just thank your lucky stars...

Ghods.  Reading that just about ruined my lunch.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"The power to tax involves the power to destroy;...the power to
destroy may defeat and render useless the power to create...."
	-- Chief Justice John Marshall, 1819.


From paul@prescod.net  Wed Jun 28 18:27:54 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:27:54 -0700
Subject: [Python-Dev] Text about cycle GC
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>
Message-ID: <395A359A.2CF0CA70@prescod.net>

"A.M. Kuchling" wrote:
> 
> ...
> 
>    An experimental step has been made toward fixing this problem. When
>    compiling Python, the -with-cycle-gc (XXX correct option flag?) option
>    can be specified. This causes a cycle detection algorithm to be
>    periodically executed, which looks for inaccessible cycles and deletes
>    the objects involved.

I propose (without any investigation into the difficulty of
implementation) that 

import cyclicgc

should turn on the -with-cycle-gc flag.

Then you could do a 

import cyclicgc
import someDOM

And not worry about cycles. If it's too slow, you remove the line and
take responsibility for cycle checking. The important thing is that you
don't have to tell YOUR USERS to turn on GC in order for your code to
work.

I think that this model will get more people actively using (and
depending upon!) GC and thus give us a better idea about usage patterns,
stability and performance. This is especially important in the beta
period when we are trying to shake out bugs.

Really, this comes back to Greg's point that we should not have
incompatible sub-languages running around. A module depends on the
feature or it doesn't. The end-user should not be responsible for
knowing whether any module in a whole program needs GC.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski


From paul@prescod.net  Wed Jun 28 18:34:35 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:34:35 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com>
Message-ID: <395A372B.34E15A62@prescod.net>

"Eric S. Raymond" wrote:
> 
> Ghods.  Reading that just about ruined my lunch.

You read it? Eric, I was just kidding!

Actually, my theory is that the whole thing is a big, extended, April
Fools joke.

Not the document. The language. (rimshot)

 SvOOK-vs-SvIV-and-SvNV-indeed-ly 'yrs

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski


From gmcm@hypernet.com  Wed Jun 28 18:37:07 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Wed, 28 Jun 2000 13:37:07 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
Message-ID: <1249908601-39717068@hypernet.com>

> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

What I noticed is that Tim is mentioned in every other 
paragraph.

Where-does-he-find-the-time?-ly y'rs

- Gordon


From jeremy@beopen.com  Wed Jun 28 18:41:50 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 28 Jun 2000 13:41:50 -0400 (EDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
 <395A31B7.911D9BC2@prescod.net>
Message-ID: <14682.14558.380773.307392@bitdiddle.concentric.net>

>>>>> "PP" == Paul Prescod <paul@prescod.net> writes:

  PP> Fredrik Lundh wrote:
  >>  http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

  PP> How about this one:

  PP> http://gisle.aas.no/perl/illguts/

  PP> Just thank your lucky stars...

What beautiful diagrams!  It almost makes me wish Python was
complicated enough to require such pretty pictures.

Jeremy


From guido@beopen.com  Wed Jun 28 19:41:48 2000
From: guido@beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 13:41:48 -0500
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Wed, 28 Jun 2000 10:16:45 MST."
 <395A32FD.D3C58B23@prescod.net>
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>
 <395A32FD.D3C58B23@prescod.net>
Message-ID: <200006281841.NAA03154@cj20424-a.reston1.va.home.com>

[PP]
> I don't want to be paranoid, but are we putting any important
> information into SourceForge that we are not backing up elsewhere? I
> mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust
> suit...) would we have backups of our patches, bugs, wish lists and so
> forth? I hope that's a criteria in deciding what services to move to
> SourceForge. I am in the business of preserving investments in data and
> of telling customers to avoid software that does not keep them in
> complete control of their data. SF makes me nervous that way....

Good point.

SF has a way to get a nightly snapshot of the CVS tree.  We should
suggest that they provide snapshots (in XML of course!) of the bugs
database too.

Note that I have no bandwidth left to communicate to SF folks so this
is up to the user community.  (I'm also very optimistic and trusting
in nature. :-)

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


From jeremy@beopen.com  Wed Jun 28 18:49:32 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 28 Jun 2000 13:49:32 -0400 (EDT)
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <395A359A.2CF0CA70@prescod.net>
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>
 <395A359A.2CF0CA70@prescod.net>
Message-ID: <14682.15020.589514.702145@bitdiddle.concentric.net>

>>>>> "PP" == Paul Prescod <paul@prescod.net> writes:

  PP> "A.M. Kuchling" wrote:
  >>  ...
  >> 
  >> An experimental step has been made toward fixing this
  >> problem. When compiling Python, the -with-cycle-gc (XXX correct
  >> option flag?) option can be specified. This causes a cycle
  >> detection algorithm to be periodically executed, which looks for
  >> inaccessible cycles and deletes the objects involved.

  PP> I propose (without any investigation into the difficulty of
  PP> implementation) that

  PP> import cyclicgc

  PP> should turn on the -with-cycle-gc flag.

The -with-cycle-gc flag is an option to configure when you build
Python.  It can't be turned on or off at runtime.

We hope that everyone will build with the -with-cycle-gc flag during
the beta testing, but we don't expect to have enough confidence in it
by final release to make it anything other than an experimental
option. 

Jeremy


From esr@thyrsus.com  Wed Jun 28 19:02:37 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Wed, 28 Jun 2000 14:02:37 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A372B.34E15A62@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:34:35AM -0700
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> <395A372B.34E15A62@prescod.net>
Message-ID: <20000628140237.A21043@thyrsus.com>

Paul Prescod <paul@prescod.net>:
> "Eric S. Raymond" wrote:
> > 
> > Ghods.  Reading that just about ruined my lunch.
> 
> You read it? Eric, I was just kidding!

Yes, I read it.  Un-fscking-believable.  I knew Perl was complicated and
ugly on the inside, but the full horror had not obtruded itself on me
before now.  If I'm any judge, that's an implementation on the brink of
collapsing under its own weight.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Non-cooperation with evil is as much a duty as cooperation with good.
	-- Mohandas Gandhi


From paul@prescod.net  Wed Jun 28 18:53:16 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:53:16 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
 <395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net>
Message-ID: <395A3B8B.B6117DA1@prescod.net>

Note that the document doesn't yet cover the regular expression engine
or the "PerlInterpreter". 

I can't think of a disclaimer that doesn't sound like it is tongue in
cheek but I do feel bad about beating up on a design which, in its own
way, has a certain kind of quality (just not one I happen to prefer).
When you optimize the snot out of things they tend to start looking
ugly. Perl runs faster than Python. That's probably not a coincidence.

Jeremy Hylton wrote:
> 
> What beautiful diagrams!  It almost makes me wish Python was
> complicated enough to require such pretty pictures.

To be fair, our internals documentation needs some work. I'll bet there
are a lot of people in comp.lang.python that would be interested in a
project like that or another one, such as adding a full warning
infrastructure to Python. I wonder how we could do a Software Carpentry
like deal (no money) where we get people to submit designs and ideas and
then "award" the job to someone. They could do it for reputational
capital and an opportunity to join "the team" (of CVS committers,
PythonDev denizens etc.).

It's probably better to give people ideas rather than have them
implement random things that we will need to turn down. Like stackless.
<duck and cover!!!>
-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski


From paul@prescod.net  Wed Jun 28 19:09:38 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 11:09:38 -0700
Subject: [Python-Dev] Text about cycle GC
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>
 <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net>
Message-ID: <395A3F62.EA1E8B89@prescod.net>

Jeremy Hylton wrote:
> 
> ....
> 
> The -with-cycle-gc flag is an option to configure when you build
> Python.  It can't be turned on or off at runtime.

Doh! Sorry. Andrew's text does say that but I didn't read carefully and
testing it with my stuff hasn't floated to the top yet (because when I
looked into it, I realized I'd have to recompile...double doh!)
Compiling is really slow on my "transitional" computer.

I'm a little disappointed that it will be so difficult for people to
test with GC on, but I'm not going to claim that there is some easy way
to make it a runtime option because I haven't looked at it at all. There
probably isn't.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski


From nascheme@enme.ucalgary.ca  Wed Jun 28 19:27:25 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Wed, 28 Jun 2000 12:27:25 -0600
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <395A3F62.EA1E8B89@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 11:09:38AM -0700
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net>
Message-ID: <20000628122725.A13473@acs.ucalgary.ca>

On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote:
> I'm a little disappointed that it will be so difficult for people to
> test with GC on, but I'm not going to claim that there is some easy way
> to make it a runtime option because I haven't looked at it at all. There
> probably isn't.

There isn't.  With an interpreter compiled --with-cycle-gc you can
turn off the collection with gc.set_threshold(0) but that's not
the same thing.

  Neil


From bwarsaw@beopen.com  Wed Jun 28 19:33:23 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 14:33:23 -0400 (EDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
 <395A31B7.911D9BC2@prescod.net>
 <20000628133805.D20855@thyrsus.com>
 <395A372B.34E15A62@prescod.net>
 <20000628140237.A21043@thyrsus.com>
Message-ID: <14682.17651.552666.318592@anthem.concentric.net>

>>>>> "ESR" == Eric S Raymond <esr@thyrsus.com> writes:

    ESR> Yes, I read it.  Un-fscking-believable.  I knew Perl was
    ESR> complicated and ugly on the inside, but the full horror had
    ESR> not obtruded itself on me before now.  If I'm any judge,
    ESR> that's an implementation on the brink of collapsing under its
    ESR> own weight.

And of course, we'll be right there to pick up the pieces. :)


From guido@beopen.com  Wed Jun 28 20:43:06 2000
From: guido@beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 14:43:06 -0500
Subject: [Python-Dev] Python 1.6 schedule
Message-ID: <200006281943.OAA03414@cj20424-a.reston1.va.home.com>

I've updated the 1.6 page on python.org (http://www.python.org/1.6/)
to include the latest schedule for 1.6.  I've also included a link to
Andrew's "what's new" article.  Here's the new schedule in text form:

  July 1: beta 1; feature freeze. 

  July 14: beta 2, in time for the O'Reilly Open Source Software Convention. 

  August 1: release candidate. 

  August 15: final release. 

I'm happy with how the patches are coming along today (/F even
submitted the SRE patch...).  We may actually have a release party
Saturday!

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


From guido@beopen.com  Wed Jun 28 21:27:43 2000
From: guido@beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 15:27:43 -0500
Subject: [Python-Dev] Named Unicode Characters
In-Reply-To: Your message of "Wed, 28 Jun 2000 18:57:35 +0200."
 <395A2E7F.A1DDEC35@lemburg.com>
References: <395A2E7F.A1DDEC35@lemburg.com>
Message-ID: <200006282027.PAA04607@cj20424-a.reston1.va.home.com>

> I've just checked in the patches by Bill Tutt, which add
> support for \N{NAMED UNICODE CHARACTERS}. The new escape
> code is available per default in the standard unicode-escape
> codec. The (big) hash table needed to drive the mapping
> is loaded on demand to reduce memory overhead.
> 
> The patch also includes a new tool called perfecthash which
> is used to generate the hash table (and function) from 
> names to ordinals. I'm sure this can be of use in other
> areas too... but it needs some more work to become more
> generic (currently you have to edit the source code to generate
> other mapping modules).
> 
> Thanks to Bill Tutt -- this is great work !

Thanks Bill and Marc-Andre!

I've closed the patch in SF now.

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


From tpeters@beopen.com  Wed Jun 28 20:40:18 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 15:40:18 -0400
Subject: [Python-Dev] back up & running
In-Reply-To: <20000628095319.C14129@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEPMGGAA.tim_one@email.msn.com>

[Vladimir Marangozov]
> ...
> I've been disappointed to see that the June 30 intent-date was
> announced, but people keep chewing-gumming about SourceForge
> caveats while the patches backlog grows and the number of closed
> patches stays invariably to 3, of which one is a test!

Absolutely on-target, Vladimir!  The current state of our world is
embarrassing.  Someday when the bosses aren't listening, I'll explain to you
how it got this way <0.9 wink>.

[Trent Mick]
> You can count me as one of the significant bottlenecks here. Tim and
> Guido have accepted some of my patches, I just have to check them in.
> Real Soon Now (tm).

Trent, you are *not* a bottleneck!  You've cooperated with the process (or
lack thereof) every step of the way, and it hasn't even been 12 hours since
I accepted some of your patches.  And the bulk of them are still on my plate
to review.

I don't think we have an actual bottleneck now, but we do have a large
backlog to work off, and people with too many things that need to be done.

perseverance-and-patience-will-probably-work-better-than-their-opposites-ly
    y'rs  - tim




From gstein@lyra.org  Wed Jun 28 20:46:06 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 12:46:06 -0700
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <200006281455.JAA01690@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 09:55:00AM -0500
References: <20000627184615.A29590@lyra.org> <200006281455.JAA01690@cj20424-a.reston1.va.home.com>
Message-ID: <20000628124606.K29590@lyra.org>

On Wed, Jun 28, 2000 at 09:55:00AM -0500, Guido van Rossum wrote:
> > A while back, I pulled the "demo" importers out of imputil.py. I think those
> > should be added into Demo/imputil/.
> 
> OK.  Go ahead and create that directory and add the demo importers.

Will do.

> > It would also be Goodness to include JimA's zipimporter. Where would that go?
> 
> Same place I'd hope?  Can you check that it works?

Yup and yup.

> We're dependent on you volunteers to maintain relatively non-core
> things like this -- I don't want to extend the feature freeze to
> Demo/, but I also don't have the time to keep the stuff there up to
> date.

Not a problem, and I had figured on being the "point man" on keeping it
working. My query here was more along the lines of "is Demo/imputil/ a good
idea? If so, then I'll run with it." You said "yes", so I'll go put on my
shoes.

> Maybe at some point the Demo directory should become a separate
> distribution, or just a collection of stuff on the web?

I believe a separate distribution. Unpacking the bugger to the main web site
would also be a good option, but that would be a second priority.

I'd throw Tools into the same thing. As a separate distro, you can have a
faster release cycle. ... you could release Idle updates easily and
distinctly from the Python core.

Note: by a "collection on the web", the only view that I have, is that the
collection exists on the python.org web site. Distributed pieces "here and
there" is handled by the Vaults (and similar). The Demo/ directory is a bit
more newbie-ish, so (IMO) it ought to get bundled up somehow since the
Vaults are a bit daunting to find "example of embedding". If the bundle also
happens to reside in an obvious area on python.org? Great.

Cheers,
-g

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


From tpeters@beopen.com  Wed Jun 28 20:54:42 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 15:54:42 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEABGHAA.tim_one@email.msn.com>

[Paul Prescod]
> How about this one:
>
> http://gisle.aas.no/perl/illguts/

> Just thank your lucky stars...

Ack, don't get me started -- well, I'd love to, but have real work to do.
I've posted about that before.  I'm not infrequently amazed that they manage
to keep Perl running at all.  The amazing thing about the PerlGuts doc above
is that it was apparently reverse-engineered by staring at Perl's
implementation code.  You can't find any of it explained in the source!

either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter-
    than-us-and-i-know-which-of-those-i'm-more-likely-to-
    believe<wink>-ly y'rs  - tim




From guido@beopen.com  Wed Jun 28 21:59:46 2000
From: guido@beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 15:59:46 -0500
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: Your message of "Wed, 28 Jun 2000 12:27:25 CST."
 <20000628122725.A13473@acs.ucalgary.ca>
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net>
 <20000628122725.A13473@acs.ucalgary.ca>
Message-ID: <200006282059.PAA04852@cj20424-a.reston1.va.home.com>

> On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote:
> > I'm a little disappointed that it will be so difficult for people to
> > test with GC on, but I'm not going to claim that there is some easy way
> > to make it a runtime option because I haven't looked at it at all. There
> > probably isn't.
> 
> There isn't.  With an interpreter compiled --with-cycle-gc you can
> turn off the collection with gc.set_threshold(0) but that's not
> the same thing.
> 
>   Neil

I wonder if we should turn this option *on* during beta testing?

That way we gather a lot more experience with its use!  Maybe nobody
complains and we can leave it on in the final release...

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


From akuchlin@mems-exchange.org  Wed Jun 28 21:10:28 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 16:10:28 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A3B8B.B6117DA1@prescod.net>
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net> <395A3B8B.B6117DA1@prescod.net>
Message-ID: <20000628161028.C23352@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 10:53:16AM -0700, Paul Prescod wrote:
>Note that the document doesn't yet cover the regular expression engine
>or the "PerlInterpreter". 

The regex engine's pretty hard to read, mostly because comments are
infrequent and not very helpful, and disentangling it from the rest of
Perl would require a skilled wizard.  (PCRE, if slower, is at least
much clearer and easier to understand, though the compile() function
is pretty ugly.)  A while ago I saw a p5p post from Ilya Zakharevich
who did most of the recent regex hacking; he draw attention to one
flag variable in the code and said basically "I don't know what this
flag means; I think it's some sort of UTF-8 setting, but Larry didn't
explain it."

>I can't think of a disclaimer that doesn't sound like it is tongue in
>cheek but I do feel bad about beating up on a design which, in its own
>way, has a certain kind of quality (just not one I happen to prefer).

Agreed; it could be made much simpler, but maybe at a performance
cost.  (Though performance is tricky, and maybe the extra work costs
more than it saves.)

For example, note the flag bits in SvNULL, which have values like
GMAGICAL.  You could imagine a Python implementation that added flag
bits to every object, and set a bit if there was a __getattr__ method
defined; code could then do 'if (obj->flags & GMAGICAL) ...'  instead
of the more complicated 'if (PyObject_HasAttrString(obj,
"__getattr__")'.  It would be interesting to know if Topaz, Chip
Salzenberg's experimental C++ implementation, preserves this
complexity or aims to cut it away.  The use of several levels of C
structs is also reminiscent of the way you do OO in C, as in X
toolkits.

You can also see the importance of text processing in the SvPVBM type,
for attaching a Boyer-Moore related table to a string and speeding up
regex searches.  

--amk


From tpeters@beopen.com  Wed Jun 28 21:15:34 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 16:15:34 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A3B8B.B6117DA1@prescod.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com>

[Paul Prescod]
> ...
> When you optimize the snot out of things they tend to start looking
> ugly. Perl runs faster than Python. That's probably not a coincidence.

More, IMO it's not even true.  I can't make time for this now, but on
several occasions I've coded the same algorithm in idiomatic Perl and
Python, and Python was invariably faster (not talking orders of magnitude,
but 10-40%).

The catch is that I know something about both implementations, and avoided
the sweet spots in both.  Perl gets enormous bang out of its line-at-a-time
text file input "cheating", and its integrated regexps.  Avoid those, and
it's generally *slower* in my experience, which is perfectly consistent with
the relative messiness of its implementation (all those magic flags aren't
passive, they need runtime conditionals to use!  Perl can't even inline its
refcount manipulations because they're so complicated due to the flags).

Against that, line-at-a-time text file input in particular is something that
every newbie bumps into at once, and Perl does have a monster advantage
there (at least 2x faster, probably closer to 3 on most platforms).  Perl
doesn't really look like it was designed to "be fast" in general -- it looks
like it was designed to be supernaturally fast in specific situations.  Best
I've been able to tell, that's how it *acts*, too.

I'm keen to add comparable (but limited) internal warts to Python, but for
*general* speedup ideas we'll be much better off looking to, e.g., Dylan and
Squeak.

all-that-said-python-is-fast-enough-for-me-already!-ly y'rs  - tim




From DavidA@ActiveState.com  Wed Jun 28 21:17:46 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Wed, 28 Jun 2000 13:17:46 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEABGHAA.tim_one@email.msn.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJKENKCKAA.DavidA@ActiveState.com>

> either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter-
>     than-us-and-i-know-which-of-those-i'm-more-likely-to-
>     believe<wink>-ly y'rs  - tim

I was sitting next to Gisle (the author of said document) when he started to
work on the Perl methods work for Zope. Within a day, starting w/ not
knowing anything about Python, he had Perl embedded in Python.  It says much
about the cleanliness of Python's design and the quality of its
documentation that Gisle could do that.  It also says a lot about Gisle, as
does the perlguts document

Not saying anything about anyone being nuts, especially when responding to
someone who talks about his in public. <ha&bang;/>

--david




From pingster@ilm.com  Wed Jun 28 21:22:15 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Wed, 28 Jun 2000 13:22:15 -0700 (PDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <20000628161028.C23352@kronos.cnri.reston.va.us>
Message-ID: <Pine.SGI.3.96.1000628131524.621134y-100000@happy>

On Wed, 28 Jun 2000, Andrew Kuchling wrote:
> You could imagine a Python implementation that added flag
> bits to every object, and set a bit if there was a __getattr__ method
> defined; code could then do 'if (obj->flags & GMAGICAL) ...'  instead
> of the more complicated 'if (PyObject_HasAttrString(obj,
> "__getattr__")'.

That looks like a reasonable sort of optimization to me, though
as far as i can tell it looks like that optimization has already
been done:

in PyClass_New(bases, dict, name):
    [...]
    op->cl_getattr = class_lookup(op, getattrstr, &dummy);
    [...]

in instance_getattr(inst, name):
    if (res == NULL && (func = inst->in_class->cl_getattr) != NULL) {
        [...special __getattr__ handling...]
    }

In general, optimizations of the form "add a flag to avoid a
frequent expensive test" seem okay to me, as long they are a
demonstrable win and the flag can be given a clear, simple name.


-- ?!ng

"To be human is to continually change.  Your desire to remain what
you are is what ultimately limits you."
    -- The Puppet Master, Ghost in the Shell



From akuchlin@mems-exchange.org  Wed Jun 28 21:25:54 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 16:25:54 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <Pine.SGI.3.96.1000628131524.621134y-100000@happy>
References: <20000628161028.C23352@kronos.cnri.reston.va.us> <Pine.SGI.3.96.1000628131524.621134y-100000@happy>
Message-ID: <20000628162554.E23352@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 01:22:15PM -0700, Ka-Ping Yee wrote:
>That looks like a reasonable sort of optimization to me, though
>as far as i can tell it looks like that optimization has already
>been done:

Damn time machine again...

--amk


From tpeters@beopen.com  Wed Jun 28 21:31:58 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 16:31:58 -0400
Subject: SourceForge patch notifications (was RE: [Python-Dev] ANN: Release schedule)
In-Reply-To: <20000628090230.A14129@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEAIGHAA.tim_one@email.msn.com>

[Trent Mick]
> ...
> BTW I have answered a couple a questions on my patches. Does
> the person to whom the patch is assigned get an update notification?

Trent & I investigated this offline:  he added a comment to one of his
patches to which I am assigned.  I did indeed get prompt email notification,
although as everyone has noticed by now, there's no indication from SF about
*why* I was getting notified; just:

From: noreply@sourceforge.net [mailto:noreply@sourceforge.net]
Sent: Wednesday, June 28, 2000 12:01 PM
To: tmick@mail.com; tim_one@email.msn.com
Subject: [Patch #100513] fix posixmodule for 64-bit systems (mainly Win64)


Patch #100513 has been updated.
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100513&group_id=5470


So the outcome could have been worse <wink>.

a-new-criterion-for-excellence-ly y'rs  - tim




From Fredrik Lundh" <effbot@telia.com  Wed Jun 28 21:42:56 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 22:42:56 +0200
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com>
Message-ID: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>

tim wrote:
> Against that, line-at-a-time text file input in particular is =
something that
> every newbie bumps into at once, and Perl does have a monster =
advantage
> there (at least 2x faster, probably closer to 3 on most platforms).

and 2-3x is what you get if you replace readline with readlines,
as described in this note:
http://w1.132.telia.com/~u13208596/notes/readline-performance.htm

it would be very nice if the file object could do something similar
internally (only in text mode, perhaps).  maybe in 1.7?

(as I've mentioned earlier, SRE+faster IO can result in a 10x speedup
for a straightforward while/readline/match loop...)

</F>



From jack@oratrix.nl  Wed Jun 28 21:58:27 2000
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 28 Jun 2000 22:58:27 +0200
Subject: [Python-Dev] ucnhash module
Message-ID: <20000628205832.C3234E2673@oratrix.oratrix.nl>

I'm a bit worried about the ucnhash module and its huge size. I didn't 
follow the discussion closely at the time, because I thought I could
always exclude it from the Pythons without dynamic linking, but now it 
seems that if i don't include it test_unicode doesn't run anymore.

Is this a problem with test_unicode, or should I consider ucnhash a
mandatory module?

(BTW: there were also a couple of bugs in the module, include <> in
stead of include "", and static in stead of staticforward
declarations, I'll submit patches for those 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/ ++++


From gstein@lyra.org  Wed Jun 28 22:03:42 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 14:03:42 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com> <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>
Message-ID: <20000628140342.Q29590@lyra.org>

On Wed, Jun 28, 2000 at 10:42:56PM +0200, Fredrik Lundh wrote:
> tim wrote:
> > Against that, line-at-a-time text file input in particular is something that
> > every newbie bumps into at once, and Perl does have a monster advantage
> > there (at least 2x faster, probably closer to 3 on most platforms).
> 
> and 2-3x is what you get if you replace readline with readlines,
> as described in this note:
> http://w1.132.telia.com/~u13208596/notes/readline-performance.htm
> 
> it would be very nice if the file object could do something similar
> internally (only in text mode, perhaps).  maybe in 1.7?

That could be troublesome. It should only be done if the file is seekable so
that you can rewind. If a readline() on (say) a socket moved you *past* the
newline, then you could be in big trouble. Or what happens in said socket is
blocking? etc.

Now... please don't start a thread about this now. Wait for post 1.6. Maybe
I'm totally off, and some smart guy here can say so. But it just doesn't
matter, so I'd rather not have to read a whole thread on the stuff :-)

Cheers,
-g

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


From gstein@lyra.org  Wed Jun 28 22:14:41 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 14:14:41 -0700
Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69)
In-Reply-To: <200006281553.IAA11238@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 08:53:17AM -0700
References: <200006281553.IAA11238@slayer.i.sourceforge.net>
Message-ID: <20000628141441.R29590@lyra.org>

Woah. Never knew this was in Python.

It is quite interesting, as there is a very similar concept within Apache.
In that model, you register a cleanup function for the particular data that
needs to be cleaned post-fork. After the fork occurs, the cleanups are
called.

In essence, Python would register PyOS_AfterFork. Of course, any schmoe can
call fork() and avoid the cleanups, so it bungs up the whole scheme. In
Apache, the "only" way to fork is to call an APR function, which guarantees
the cleanups.

Cheers,
-g

On Wed, Jun 28, 2000 at 08:53:17AM -0700, Fred L. Drake wrote:
> Update of /cvsroot/python/python/dist/src/Doc/api
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv11228/api
> 
> Modified Files:
> 	api.tex 
> Log Message:
> 
> Added documentation for PyOS_AfterFork().
> 
> 
> Index: api.tex
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Doc/api/api.tex,v
> retrieving revision 1.68
> retrieving revision 1.69
> diff -C2 -r1.68 -r1.69
> *** api.tex	2000/06/18 05:21:21	1.68
> --- api.tex	2000/06/28 15:53:13	1.69
> ***************
> *** 1034,1037 ****
> --- 1034,1044 ----
>   \end{cfuncdesc}
>   
> + \begin{cfuncdesc}{void}{PyOS_AfterFork}{}
> + Function to update some internal state after a process fork; this
> + should be called in the new process if the Python interpreter will
> + continue to be used.  If a new executable is loaded into the new
> + process, this function does not need to be called.
> + \end{cfuncdesc}
> + 
>   
>   \section{Process Control \label{processControl}}
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins@python.org
> http://www.python.org/mailman/listinfo/python-checkins

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


From Fredrik Lundh" <effbot@telia.com  Wed Jun 28 22:19:36 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 23:19:36 +0200
Subject: [Python-Dev] exceptions trouble
Message-ID: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>

import traceback
try:
    raise SyntaxError, "argument"
except:
    traceback.print_exc()

prints:

Traceback (most recent call last):
  File "test.py", line 3, in ?
    raise SyntaxError, "argument"
Traceback (most recent call last):
  File "test.py", line 5, in ?
    traceback.print_exc()
  File "C:\py16\lib\traceback.py", line 182, in print_exc
    print_exception(etype, value, tb, limit, file)
  File "C:\py16\lib\traceback.py", line 110, in print_exception
    lines =3D format_exception_only(etype, value)
  File "C:\py16\lib\traceback.py", line 169, in format_exception_only
    list.append('%s: %s\n' % (str(stype), str(value)))
SystemError: new style getargs format but argument is not a tuple

not really what I expected.  am I out of sync, or have I
stumbled upon a bug in the new exceptions code?

</F>



From tpeters@beopen.com  Wed Jun 28 22:21:52 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 17:21:52 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <20000628140342.Q29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEAMGHAA.tim_one@email.msn.com>

[Greg Stein]
> ...
> Now... please don't start a thread about this now. Wait for post
> 1.6.

Amen.

> Maybe I'm totally off, and some smart guy here can say so. But it
> just doesn't matter, so I'd rather not have to read a whole thread
> on the stuff :-)

If you change your mind, you can go back in the archives and read at least
two old threads on the topic -- it's not like there's actually anything new
here <wink>.




From akuchlin@mems-exchange.org  Wed Jun 28 22:30:38 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 17:30:38 -0400
Subject: [Python-Dev] exceptions trouble
In-Reply-To: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>
References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>
Message-ID: <20000628173038.B28659@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 11:19:36PM +0200, Fredrik Lundh wrote:
>SystemError: new style getargs format but argument is not a tuple
>not really what I expected.  am I out of sync, or have I
>stumbled upon a bug in the new exceptions code?

It works fine in my current copy of the CVS tree, and I think I
rebuilt everything this morning.

--amk


From fdrake@beopen.com  Wed Jun 28 22:32:36 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 17:32:36 -0400 (EDT)
Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69)
In-Reply-To: <20000628141441.R29590@lyra.org>
References: <200006281553.IAA11238@slayer.i.sourceforge.net>
 <20000628141441.R29590@lyra.org>
Message-ID: <14682.28404.125379.249287@cj42289-a.reston1.va.home.com>

Greg Stein writes:
 > Woah. Never knew this was in Python.

  I didn't either, until I read a patch that used it.  That's one way
to keep the documentation up to date!  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From gstein@lyra.org  Wed Jun 28 22:48:00 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 14:48:00 -0700
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <200006282112.OAA03095@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:12:28PM -0700
References: <200006282112.OAA03095@slayer.i.sourceforge.net>
Message-ID: <20000628144800.T29590@lyra.org>

On Wed, Jun 28, 2000 at 02:12:28PM -0700, Guido van Rossum wrote:
>...
> - chunk #2: 
> The id() function guarantees a unique return value for different
> objects.  It does this by returning the pointer to the object. By
> returning a PyInt, on Win64 (sizeof(long) < sizeof(void*)) the pointer
> is truncated and the guarantee may be proven false. The appropriate
> return function is PyLong_FromVoidPtr, this returns a PyLong if that
> is necessary to return the pointer without truncation.
> 
> [GvR: note that this means that id() can now return a long on Win32
> platforms.  This *might* break some code...]

Strictly speaking: the Long only occurs on Win64 platforms.

I would guess that it is also possible on say, an Alpha running Linux.
Presuming that has 64-bit pointers(?).

Regardless: yes, it can certainly break some code. IMO, if any code out
there makes any kinds of assumptions about id(), then they deserve to be
broken :-)

Cheers,
-g

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


From paul@prescod.net  Wed Jun 28 22:44:33 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 14:44:33 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com> <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> <20000628140342.Q29590@lyra.org>
Message-ID: <395A71C1.A4E332D@prescod.net>

Re: Performance

At the very least this readlines() optimization should be in FileInput
which was invented, after all, in order to compete with Perl.
---
Re: Inline Unicode smily faces

Bill and Mark-Andre, you rock. Another feature stolen from Perl.

If only it were as easy to steal cleanliness and elegance. :)
---
Re: GC

On by default in beta would be peachy.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski


From bwarsaw@beopen.com  Wed Jun 28 23:01:00 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 18:01:00 -0400 (EDT)
Subject: [Python-Dev] exceptions trouble
References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>
 <20000628173038.B28659@kronos.cnri.reston.va.us>
Message-ID: <14682.30108.714768.740415@anthem.concentric.net>

>>>>> "AK" == Andrew Kuchling <akuchlin@mems-exchange.org> writes:

    AK> It works fine in my current copy of the CVS tree, and I think
    AK> I rebuilt everything this morning.

Same here.


From trentm@activestate.com  Wed Jun 28 23:04:28 2000
From: trentm@activestate.com (Trent Mick)
Date: Wed, 28 Jun 2000 15:04:28 -0700
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <20000628144800.T29590@lyra.org>
References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org>
Message-ID: <20000628150428.E17875@activestate.com>

On Wed, Jun 28, 2000 at 02:48:00PM -0700, Greg Stein wrote:
> Regardless: yes, it can certainly break some code. IMO, if any code out
> there makes any kinds of assumptions about id(), then they deserve to be
> broken :-)

Amen.

Trent

-- 
Trent Mick
trentm@activestate.com


From nascheme@enme.ucalgary.ca  Wed Jun 28 23:07:43 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Wed, 28 Jun 2000 16:07:43 -0600
Subject: [Python-Dev] id() on Win64
Message-ID: <20000628160743.A16262@acs.ucalgary.ca>

[Greg Stein]
>Strictly speaking: the Long only occurs on Win64 platforms.
>
>I would guess that it is also possible on say, an Alpha running
>Linux.  Presuming that has 64-bit pointers(?).

I think the Alpha is okay. The problem is strange type models
were int is 32 bits and pointers are 64.  AFAIK, the Alpha uses
64 bits for both.

  Neil


From guido@beopen.com  Thu Jun 29 00:10:52 2000
From: guido@beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 18:10:52 -0500
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: Your message of "Wed, 28 Jun 2000 14:48:00 MST."
 <20000628144800.T29590@lyra.org>
References: <200006282112.OAA03095@slayer.i.sourceforge.net>
 <20000628144800.T29590@lyra.org>
Message-ID: <200006282310.SAA05850@cj20424-a.reston1.va.home.com>

> > [GvR: note that this means that id() can now return a long on Win32
> > platforms.  This *might* break some code...]
> 
> Strictly speaking: the Long only occurs on Win64 platforms.

You're right.

> I would guess that it is also possible on say, an Alpha running Linux.
> Presuming that has 64-bit pointers(?).

No, because their longs are also 64 bits, and hence so are Python ints.

> Regardless: yes, it can certainly break some code. IMO, if any code out
> there makes any kinds of assumptions about id(), then they deserve to be
> broken :-)

That depends.  It is documented as an integer -- which may be vague
enough to encompass longs, but that's weasel-wording. ;-)

I do think that the likelihood of this breaking significant code is low.

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


From gstein@lyra.org  Wed Jun 28 23:17:58 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 15:17:58 -0700
Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
In-Reply-To: <200006282157.OAA05880@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:57:20PM -0700
References: <200006282157.OAA05880@slayer.i.sourceforge.net>
Message-ID: <20000628151758.X29590@lyra.org>

On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote:
> Update of /cvsroot/python/python/dist/src/Objects
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838
> 
> Modified Files:
> 	classobject.c object.c 
> Log Message:
> Trent Mick: change a few casts for Win64 compatibility.
> 
> 
> Index: classobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v
> retrieving revision 2.89
> retrieving revision 2.90
> diff -C2 -r2.89 -r2.90
> *** classobject.c	2000/06/23 19:37:01	2.89
> --- classobject.c	2000/06/28 21:57:18	2.90
> ***************
> *** 284,288 ****
>   	if (v == NULL || !PyString_Check(v))
>   		return "__name__ must be a string object";
> ! 	if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v))
>   		return "__name__ must not contain null bytes";
>   	set_slot(&c->cl_name, v);
> --- 284,288 ----
>   	if (v == NULL || !PyString_Check(v))
>   		return "__name__ must be a string object";
> ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
>   		return "__name__ must not contain null bytes";
>   	set_slot(&c->cl_name, v);

Actually, it would seem to make more sense to place the cast *inside* the
PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.

May as well start some ANSI-fication while we can...

Guido: any problem with my changing the macro?

Cheers,
-g

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


From gstein@lyra.org  Wed Jun 28 23:16:17 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 15:16:17 -0700
Subject: [Python-Dev] httplib doc (was: CVS: python/dist/src/Doc/lib libhttplib.tex,1.19,1.20)
In-Reply-To: <200006282151.OAA05489@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 02:51:46PM -0700
References: <200006282151.OAA05489@slayer.i.sourceforge.net>
Message-ID: <20000628151617.W29590@lyra.org>

Please mark me for a TODO to update the httplib doc. For example, the code
below is more effectively written as:

h = httplib.HTTPConnection('www.musi-cal.com')
h.request('POST', '/cgi-bin/query', paramstring, {'Accept': 'text/plain'})
response = h.getresponse()
print response.status   # should be 200
data = response.read()  # get the raw HTML

Note that 'Accept' is usually not a required header and can be omitted in
most scenarios. I left it in the example simply to show how to fully map
between the old/new APIs.

[ Content-Length and Host are sent automatically by HTTPConnection. ]

Cheers,
-g

On Wed, Jun 28, 2000 at 02:51:46PM -0700, Fred L. Drake wrote:
> Update of /cvsroot/python/python/dist/src/Doc/lib
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv5474/lib
> 
> Modified Files:
> 	libhttplib.tex 
> Log Message:
> 
> Skip Montanaro <skip@mojam.com>:
> Added an example of using an HTTP POST request.
> 
> 
> Index: libhttplib.tex
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Doc/lib/libhttplib.tex,v
> retrieving revision 1.19
> retrieving revision 1.20
> diff -C2 -r1.19 -r1.20
> *** libhttplib.tex	1999/04/22 16:47:27	1.19
> --- libhttplib.tex	2000/06/28 21:51:43	1.20
> ***************
> *** 115,119 ****
>   \nodename{HTTP Example}
>   
> ! Here is an example session:
>   
>   \begin{verbatim}
> --- 115,119 ----
>   \nodename{HTTP Example}
>   
> ! Here is an example session that uses the \samp{GET} method:
>   
>   \begin{verbatim}
> ***************
> *** 129,131 ****
> --- 129,148 ----
>   >>> data = f.read() # Get the raw HTML
>   >>> f.close()
> + \end{verbatim}
> + 
> + Here is an example session that shows how to \samp{POST} requests:
> + 
> + \begin{verbatim}
> + >>> import httplib, urllib
> + >>> params = urllib.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})
> + >>> h = httplib.HTTP("www.musi-cal.com:80")
> + >>> h.putrequest("POST", "/cgi-bin/query")
> + >>> h.putheader("Content-length", "%d" % len(params))
> + >>> h.putheader('Accept', 'text/plain')
> + >>> h.putheader('Host', 'www.musi-cal.com')
> + >>> h.endheaders()
> + >>> h.send(paramstring)
> + >>> reply, msg, hdrs = h.getreply()
> + >>> print errcode # should be 200
> + >>> data = h.getfile().read() # get the raw HTML
>   \end{verbatim}
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins@python.org
> http://www.python.org/mailman/listinfo/python-checkins

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


From mal@lemburg.com  Wed Jun 28 23:38:29 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 00:38:29 +0200
Subject: [Python-Dev] ucnhash module
References: <20000628205832.C3234E2673@oratrix.oratrix.nl>
Message-ID: <395A7E65.2271C723@lemburg.com>

Jack Jansen wrote:
> 
> I'm a bit worried about the ucnhash module and its huge size. I didn't
> follow the discussion closely at the time, because I thought I could
> always exclude it from the Pythons without dynamic linking, but now it
> seems that if i don't include it test_unicode doesn't run anymore.
> 
> Is this a problem with test_unicode, or should I consider ucnhash a
> mandatory module?

The ucnhash module is loaded on demand to avoid memory bloat.
In practice the difference is not really noticeable since 
loading a shared module or swapping in a few pages of static
C data result in pretty much the same overall memory usage.

If no-one complains, I'll fix the test suite though to make
the tests of the named Unicode characters optional.

Is this ok with you, Bill ?
 
> (BTW: there were also a couple of bugs in the module, include <> in
> stead of include "", and static in stead of staticforward
> declarations, I'll submit patches for those shortly).

I didn't have any problem compiling the module (don't even get
warnings when compiling with -Wall) ... but you're right:
these ought to get fixed.

BTW, since ucnhash.h|c are generated using the scripts
in Tools/perfecthash/ your patch should probably also fix the
instances of the problems found in there.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From tpeters@beopen.com  Wed Jun 28 23:47:04 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 18:47:04 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <20000628150428.E17875@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>

[Greg Stein]
> Regardless: yes, it can certainly break some code. IMO, if any code out
> there makes any kinds of assumptions about id(), then they deserve to be
> broken :-)

[Trent Mick]
> Amen.

Guys, it's almost never that simple, and developers are the last ones to
think of the reasonable cases that may break.  In this case, e.g., code may
be doing something as harmless as printing an id() via a "... %d ..." format
in a log, and-- BOOM! --that blows up with an OverflowError if you feed it a
Python long larger than a C long.

I'd rather fix %d formats than leave id() broken, though!  id() has to
return a unique value.

but-i'll-sympathize-with-the-users-even-in-public<wink>-ly y'rs  - tim




From trentm@activestate.com  Thu Jun 29 00:49:55 2000
From: trentm@activestate.com (Trent Mick)
Date: Wed, 28 Jun 2000 16:49:55 -0700
Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
In-Reply-To: <20000628151758.X29590@lyra.org>
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org>
Message-ID: <20000628164955.B19053@activestate.com>

On Wed, Jun 28, 2000 at 03:17:58PM -0700, Greg Stein wrote:
> On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote:
> > Update of /cvsroot/python/python/dist/src/Objects
> > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838
> > 
> > Modified Files:
> > 	classobject.c object.c 
> > Log Message:
> > Trent Mick: change a few casts for Win64 compatibility.
> > 
> > 
> > Index: classobject.c
> > ===================================================================
> > RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v
> > retrieving revision 2.89
> > retrieving revision 2.90
> > diff -C2 -r2.89 -r2.90
> > *** classobject.c	2000/06/23 19:37:01	2.89
> > --- classobject.c	2000/06/28 21:57:18	2.90
> > ***************
> > *** 284,288 ****
> >   	if (v == NULL || !PyString_Check(v))
> >   		return "__name__ must be a string object";
> > ! 	if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v))
> >   		return "__name__ must not contain null bytes";
> >   	set_slot(&c->cl_name, v);
> > --- 284,288 ----
> >   	if (v == NULL || !PyString_Check(v))
> >   		return "__name__ must be a string object";
> > ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
> >   		return "__name__ must not contain null bytes";
> >   	set_slot(&c->cl_name, v);
> 
> Actually, it would seem to make more sense to place the cast *inside* the
> PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
> 
> May as well start some ANSI-fication while we can...
> 

I agree. Go to town, Greg. :)

Trent

-- 
Trent Mick
trentm@activestate.com


From gstein@lyra.org  Thu Jun 29 01:08:40 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:08:40 -0700
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 03:59:46PM -0500
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> <200006282059.PAA04852@cj20424-a.reston1.va.home.com>
Message-ID: <20000628170840.E29590@lyra.org>

On Wed, Jun 28, 2000 at 03:59:46PM -0500, Guido van Rossum wrote:
> > On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote:
> > > I'm a little disappointed that it will be so difficult for people to
> > > test with GC on, but I'm not going to claim that there is some easy way
> > > to make it a runtime option because I haven't looked at it at all. There
> > > probably isn't.
> > 
> > There isn't.  With an interpreter compiled --with-cycle-gc you can
> > turn off the collection with gc.set_threshold(0) but that's not
> > the same thing.
> > 
> >   Neil
> 
> I wonder if we should turn this option *on* during beta testing?
> 
> That way we gather a lot more experience with its use!  Maybe nobody
> complains and we can leave it on in the final release...

That presumes an adequate number of testers and a wide variety of
deployment/usage scenarios. Given the relatively short timeframe, that may
be a bit aggressive.

I *do* agree with enabling it during the beta. But I'm just not sure about
leaving it on.

Cheers,
-g

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


From tpeters@beopen.com  Thu Jun 29 01:07:20 2000
From: tpeters@beopen.com (Tim Peters)
Date: Wed, 28 Jun 2000 20:07:20 -0400
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <20000628124606.K29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEBGGHAA.tim_one@email.msn.com>

[Greg Stein]
> ...
> I'd throw Tools into the same thing [as Demos]. As a separate distro,
> you can have a faster release cycle. ... you could release Idle
> updates easily and distinctly from the Python core.

Note that Guido gave his blessing for a "wide open" policy on IDLE (== its
own project in SourceForge, and anyone can be a developer).  If that's a
success (& I predict it will be, provided someone actually bothers to set up
the SF project!), I'd like to see it spread to Tools and Demos too.

ignoring-the-downsides-cuz-they'll-make-themselves-known-ly y'rs  - tim




From guido@beopen.com  Thu Jun 29 02:11:36 2000
From: guido@beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 20:11:36 -0500
Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
In-Reply-To: Your message of "Wed, 28 Jun 2000 15:17:58 MST."
 <20000628151758.X29590@lyra.org>
References: <200006282157.OAA05880@slayer.i.sourceforge.net>
 <20000628151758.X29590@lyra.org>
Message-ID: <200006290111.UAA08357@cj20424-a.reston1.va.home.com>

> > ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
> 
> Actually, it would seem to make more sense to place the cast *inside* the
> PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
> 
> May as well start some ANSI-fication while we can...
> 
> Guido: any problem with my changing the macro?

Please leave the macro alone.  The type of the macro should be the
same as the type of the function -- PyString_Size() -- which is int.
If you change this, you potentially get tons of warnings because of
the signed / unsigned nature.

ANSI-fication is a good project for after 1.6.  But even then, it's a
separate decision whether the size of a string should be a size_t
instead of an int.  (The ob_size field should also change, if so --
with even more consequences.)

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


From gstein@lyra.org  Thu Jun 29 01:29:20 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:29:20 -0700
Subject: [Python-Dev] PyString_GET_SIZE()
In-Reply-To: <200006290111.UAA08357@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 08:11:36PM -0500
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com>
Message-ID: <20000628172919.G29590@lyra.org>

On Wed, Jun 28, 2000 at 08:11:36PM -0500, Guido van Rossum wrote:
> > > ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
> > 
> > Actually, it would seem to make more sense to place the cast *inside* the
> > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
> > 
> > May as well start some ANSI-fication while we can...
> > 
> > Guido: any problem with my changing the macro?
> 
> Please leave the macro alone.  The type of the macro should be the
> same as the type of the function -- PyString_Size() -- which is int.
> If you change this, you potentially get tons of warnings because of
> the signed / unsigned nature.
> 
> ANSI-fication is a good project for after 1.6.  But even then, it's a
> separate decision whether the size of a string should be a size_t
> instead of an int.  (The ob_size field should also change, if so --
> with even more consequences.)

Post 1.6, yes... I had figured on ob_size changing. Certainly not now :-)

But I understand the point about different return types. No problem.

[ of course, I would state that PyString_Size should also change and we fix
  those warnings... but I'll be patient :-) ]

How about removing Py_PROTO() usage, and changing function definitions from
K&R arg declaration to ANSI declarations? That kind of work is pretty
simple, straight-forward, and if somebody has free time to plod through the
work... so much the better. I believe that these changes would not introduce
any stability problems, and could be done independently from your busy
schedule.

Hmm. Is there a good place to start listing these todo items? One that we
can truly use for communicating this info? In Apache, we have a file named
STATUS that everybody uses for dropping ideas, patch references, critical
bugs, etc. As that file gets changed, we see it in the -checkins alias, so
everybody is aware of the suggested changes/problems/available patches/etc.
It also holds people's votes on particular changes.

Can we institute something similar? Possibly Misc/STATUS? Should I post
Apache's STATUS file as an example?

Cheers,
-g

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


From gstein@lyra.org  Thu Jun 29 01:34:24 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:34:24 -0700
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395A32FD.D3C58B23@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:16:45AM -0700
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net>
Message-ID: <20000628173424.H29590@lyra.org>

I think you are being paranoid :-)

Consider that this same issue applies to all 5900 projects and 38000
developers at SourceForge. VA Linux has a brand identity entirely built on
the trust and support of the Linux (and Open Source) communities. If they
blow away that trust, they are simply screwed.

That said: it would still be a good thing to have export capabilities. I
recall that certain portions of the data (the Trove map?) can be exported in
XML format. I don't recall the magic URL for that, however.

Cheers,
-g

On Wed, Jun 28, 2000 at 10:16:45AM -0700, Paul Prescod wrote:
> I don't want to be paranoid, but are we putting any important
> information into SourceForge that we are not backing up elsewhere? I
> mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust
> suit...) would we have backups of our patches, bugs, wish lists and so
> forth? I hope that's a criteria in deciding what services to move to
> SourceForge. I am in the business of preserving investments in data and
> of telling customers to avoid software that does not keep them in
> complete control of their data. SF makes me nervous that way....
> 
> -- 
>  Paul Prescod - Not encumbered by corporate consensus
> The calculus and the rich body of mathematical analysis to which it 
> gave rise made modern science possible, but it was the algorithm that 
> made the modern world possible.
> 	- The Advent of the Algorithm (pending), by David Berlinski
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev

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


From gstein@lyra.org  Thu Jun 29 01:36:41 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:36:41 -0700
Subject: [Python-Dev] RTFM: SourceForge access for Win32
Message-ID: <20000628173641.I29590@lyra.org>

All right guys... all this banter about setting up CVS access for Win32
users has been quite silly. Did anybody even stop to look at the docs?

http://sfdocs.sourceforge.net/sfdocs/

In particular:

http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=19
http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=20
http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=46

There is also a new tool available (released today);

http://sfsetup.sourceforge.net/


Cheers,
-g

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


From gstein@lyra.org  Thu Jun 29 02:01:40 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 18:01:40 -0700
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEBGGHAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 08:07:20PM -0400
References: <20000628124606.K29590@lyra.org> <LNBBLJKPBEHFEDALKOLCAEBGGHAA.tim_one@email.msn.com>
Message-ID: <20000628180140.M29590@lyra.org>

On Wed, Jun 28, 2000 at 08:07:20PM -0400, Tim Peters wrote:
> [Greg Stein]
> > ...
> > I'd throw Tools into the same thing [as Demos]. As a separate distro,
> > you can have a faster release cycle. ... you could release Idle
> > updates easily and distinctly from the Python core.
> 
> Note that Guido gave his blessing for a "wide open" policy on IDLE (== its
> own project in SourceForge, and anyone can be a developer).  If that's a
> success (& I predict it will be, provided someone actually bothers to set up
> the SF project!), I'd like to see it spread to Tools and Demos too.

Are you suggesting that IDLE be separate from a Tools/Demo package, or that
the whole bunch be shoved out into the wild?

Hmm... I guess that I don't much have an opinion one way or the other, but
was mostly looking for clarification.

Cheers,
-g

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


From jeremy@beopen.com  Thu Jun 29 03:08:51 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 28 Jun 2000 22:08:51 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
Message-ID: <14682.44979.673881.83798@bitdiddle.concentric.net>

Setup.in contains the following comment:

# (Note: the expat build process doesn't yet build a libexpat.a; you can
# do this manually while we try convince the author to add it.)

I've got expat, and I've built it, but I don't have any idea how to
build libexpat.a.  It may be possible to do it manually, but it would
help a lot if the comments could say how to build it or contain a link
to instructions on how to build it.

Jeremy


From gward@python.net  Thu Jun 29 03:37:08 2000
From: gward@python.net (Greg Ward)
Date: Wed, 28 Jun 2000 22:37:08 -0400
Subject: [Python-Dev] Just spotted on SourceForge main page
Message-ID: <20000628223707.A1168@beelzebub>

Maybe this is what all you Windows folks are looking for.

  SFSetup v1 released 
  mhearn - 06/28/00 11:00   -   SourceForge Setup for Win32 

  SFSetup is a program to automatically setup SSH and WinCVS for
  SourceForge projects under the Windows 32 platform. It's now available
  for download so if you have not yet set up SSH and WinCVS and want it
  done for you, you can use this program. Go to sfsetup.sourceforge.net
  to find out how to use it. It's open source and written in Delphi -
  the code is in CVS and any improvements are welcome! Thanks -mike
                
-- 
Greg Ward - Linux nerd                                  gward@python.net
http://starship.python.net/~gward/
I love ROCK 'N ROLL!  I memorized the all WORDS to "WIPE-OUT" in 1965!!


From fdrake@beopen.com  Thu Jun 29 04:26:55 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 23:26:55 -0400 (EDT)
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <200006282310.SAA05850@cj20424-a.reston1.va.home.com>
References: <200006282112.OAA03095@slayer.i.sourceforge.net>
 <20000628144800.T29590@lyra.org>
 <200006282310.SAA05850@cj20424-a.reston1.va.home.com>
Message-ID: <14682.49663.208158.88794@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > That depends.  It is documented as an integer -- which may be vague
 > enough to encompass longs, but that's weasel-wording. ;-)

  The 1.6 documentation will make it clear that this may be a long
integer, but I don't think we need to promise on which platforms this
will be the case.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From paul@prescod.net  Thu Jun 29 05:21:41 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 21:21:41 -0700
Subject: [Python-Dev] how do I build pyexpat?
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
Message-ID: <395ACED5.83764D45@prescod.net>

I don't know where you got your expat or how new it is, but with the one
I got from the xml-sig, I can type

"make libexpat.a"

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski


From tpeters@beopen.com  Thu Jun 29 05:55:22 2000
From: tpeters@beopen.com (Tim Peters)
Date: Thu, 29 Jun 2000 00:55:22 -0400
Subject: [Python-Dev] PyString_GET_SIZE()
In-Reply-To: <20000628172919.G29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEBPGHAA.tim_one@email.msn.com>

[Greg Stein]
> ...
> How about removing Py_PROTO() usage, and changing function
> definitions from K&R arg declaration to ANSI declarations? That
> kind of work is pretty simple, straight-forward, and if somebody
> has free time to plod through the work... so much the better.

I think it's too late in the cycle to suggest work for others to do and get
any payback from that.  Unless you're the one with the free time -- in which
case full speed ahead and God bless!  I previously volunteered to take the
Py_PROTO crap on, as I use an editor with a symbol database that gets
confused by that stuff, but I'm sure not going to start that this week.

> ...
> Hmm. Is there a good place to start listing these todo items?

Not that I know of.  "Group whiteboards" and shared journals etc are darned
useful, though.

> One that we can truly use for communicating this info? In Apache, we
> have a file named STATUS that everybody uses for dropping ideas, patch
> references, critical bugs, etc. As that file gets changed, we see it
> in the -checkins alias, so everybody is aware of the suggested
> changes/problems/available patches/etc.  It also holds people's votes
> on particular changes.
>
> Can we institute something similar? Possibly Misc/STATUS? Should I post
> Apache's STATUS file as an example?

Yes, sure, no:  just check one in!  If Guido hates it, we can remove it
later.  In the meantime, I bet we'll find great ways to use it.  In the
spirit of Unix, maybe it should be called Misc/gwtbd <wink>.

let-a-thousand-idiosyncracies-bloom-ly y'rs  - tim




From tpeters@beopen.com  Thu Jun 29 05:55:24 2000
From: tpeters@beopen.com (Tim Peters)
Date: Thu, 29 Jun 2000 00:55:24 -0400
Subject: [Python-Dev] RTFM: SourceForge access for Win32
In-Reply-To: <20000628173641.I29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEBPGHAA.tim_one@email.msn.com>

> All right guys... all this banter about setting up CVS access for Win32
> users has been quite silly.

It's been a valuable object lesson, Greg:  I showed everyone the value of
sitting on their ass until someone who knows what they're doing can't stand
it anymore <0.8 wink>.

> Did anybody even stop to look at the docs?

Didn't seem so to me.  I personally never found any docs, despite looking
for them.

> http://sfdocs.sourceforge.net/sfdocs/

Great!  Thank you.

> ...
> There is also a new tool available (released today);
>
> http://sfsetup.sourceforge.net/




From tpeters@beopen.com  Thu Jun 29 06:08:27 2000
From: tpeters@beopen.com (Tim Peters)
Date: Thu, 29 Jun 2000 01:08:27 -0400
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <20000628180140.M29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCOECAGHAA.tim_one@email.msn.com>

[Greg Stein]
> Are you suggesting that IDLE be separate from a Tools/Demo
> package, or that the whole bunch be shoved out into the wild?

There's already an IDLE distribution distinct from Python's:

    http://www.python.org/idle/

Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not
clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack
of time).

> Hmm... I guess that I don't much have an opinion one way or the other, but
> was mostly looking for clarification.

I don't have a specific plan in mind either -- just "me too"ing on the idea
that it would do no harm and possibly do real good to let these peripheral
(to the core) things live on their own schedules.  I don't see any harm in
including "the latest" snapshot of them with the core distribution,
though -- it's handy for newcomers to get these things without needing to
search for them.  I know I learned a lot about Python at the start from
browsing these directories.




From skip@mojam.com (Skip Montanaro)  Thu Jun 29 06:27:02 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 29 Jun 2000 00:27:02 -0500 (CDT)
Subject: [Python-Dev] Another Python-based company makes good...
Message-ID: <14682.56870.790737.261865@beluga.mojam.com>

Saw this on InfoBeat today:

    ** Yahoo to buy EGroups

    Yahoo said it would buy e-mail service provider EGroups
    (www.egroups.com) for $437.5 million in stock to enhance the
    Internet giant's communications services. Yahoo (YHOO) said it
    would issue 3.43 million shares of stock for all of EGroups
    shares, options, and warrants. The purchase will be accounted for
    as a pooling of interests and is expected to close in the third
    quarter. Yahoo said it would report a one-time charge during the
    third quarter for expenses to cover the takeover.

Looks like Scott Hassan can safely drop out of grad school now (if he hasn't
already)... ;-)

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."


From skip@mojam.com (Skip Montanaro)  Thu Jun 29 06:39:09 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 29 Jun 2000 00:39:09 -0500 (CDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
 <395A31B7.911D9BC2@prescod.net>
Message-ID: <14682.57597.600123.167311@beluga.mojam.com>

    Paul> http://gisle.aas.no/perl/illguts/

The author of all those pretty diagrams is going to be really pissed when
they rename all the data structures in Perl 6... :-/

Skip


From tpeters@beopen.com  Thu Jun 29 07:47:41 2000
From: tpeters@beopen.com (Tim Peters)
Date: Thu, 29 Jun 2000 02:47:41 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <200006281541.KAA02041@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKECGGHAA.tim_one@email.msn.com>

[Guido]
> OK, I've disabled the SF bugs manager.  There were two bugs submitted
> so far.  I've assigned one to you (about os.listdir on Windows) and
> one to MAL (about -U vs. exec/eval).  You two can take care of
> entering these into JB.  You can still access the bugs database via
> this URL:
>
> https://sourceforge.net/bugs/?group_id=5470

I moved "my" bug to Jitterbug, and moved Marc-Andre's too to save him the
bother.  Marked them "Closed" and "Duplicate" on SourceForge, so that if we
reenable bug management there someday they won't confuse us.




From Moshe Zadka <moshez@math.huji.ac.il>  Thu Jun 29 08:12:17 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Thu, 29 Jun 2000 10:12:17 +0300 (IDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <200006282213.PAA13365@slayer.i.sourceforge.net>
Message-ID: <Pine.GSO.4.10.10006290943150.15938-100000@sundial>

On Wed, 28 Jun 2000, Fred L. Drake wrote:

> + * Update the filecmp documentation (Moshe?).

I'm waiting for Gordon to check-in his directory comparisons to filecmp.
Gordon?
--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



From Fredrik Lundh" <effbot@telia.com  Thu Jun 29 09:19:42 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 10:19:42 +0200
Subject: [Python-Dev] id() on Win64
References: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>
Message-ID: <00d501bfe1a2$c93f8cc0$f2a6b5d4@hagrid>

tim wrote:
> [Greg Stein]
> > Regardless: yes, it can certainly break some code. IMO, if any code =
out
> > there makes any kinds of assumptions about id(), then they deserve =
to be
> > broken :-)
>=20
> [Trent Mick]
> > Amen.
>=20
> Guys, it's almost never that simple, and developers are the last ones =
to
> think of the reasonable cases that may break.

especially since it's documented to be an integer:

    id (object)=20
    Return the `identity' of an object. This is an integer which is
    guaranteed to be unique and constant for this object during
    its lifetime.

(section 2.1.4 says that "integer" is the same thing as a "plain
integer", and that "long integer" is something different).

</F>



From gstein@lyra.org  Thu Jun 29 10:15:08 2000
From: gstein@lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 02:15:08 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.4,2.5
In-Reply-To: <200006290857.BAA11219@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 01:57:57AM -0700
References: <200006290857.BAA11219@slayer.i.sourceforge.net>
Message-ID: <20000629021508.P29590@lyra.org>

Euh... can we get a bit more information in that checkin message. "towards
1.6b1" says zippo about what is changing or why.

Cheers,
-g

On Thu, Jun 29, 2000 at 01:57:57AM -0700, Fredrik Lundh wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv11206
> 
> Modified Files:
> 	_sre.c 
> Log Message:
> towards 1.6b1
> 
> Index: _sre.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/_sre.c,v
> retrieving revision 2.4
> retrieving revision 2.5
> diff -C2 -r2.4 -r2.5
> *** _sre.c	2000/06/01 17:34:20	2.4
> --- _sre.c	2000/06/29 08:57:54	2.5
> ***************
> *** 4,20 ****
>    * $Id$
>    *
> !  * simple regular expression matching engine
>    *
>    * partial history:
> !  * 99-10-24 fl	created (based on the template matcher)
>    * 99-11-13 fl	added categories, branching, and more (0.2)
>    * 99-11-16 fl	some tweaks to compile on non-Windows platforms
>    * 99-12-18 fl	non-literals, generic maximizing repeat (0.3)
> !  * 99-02-28 fl	tons of changes (not all to the better ;-) (0.4)
> [...1589 lines suppressed...]
>   
>   void
> ! #if defined(WIN32)
>   __declspec(dllexport)
>   #endif
> ***************
> *** 1708,1713 ****
>           Cursor_Type.ob_type = &PyType_Type;
>   
> ! 	Py_InitModule("_sre", _functions);
>   }
>   
> ! #endif
> --- 1846,1851 ----
>           Cursor_Type.ob_type = &PyType_Type;
>   
> ! 	Py_InitModule("_" MODULE, _functions);
>   }
>   
> ! #endif /* !defined(SRE_RECURSIVE) */
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins@python.org
> http://www.python.org/mailman/listinfo/python-checkins

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


From Fredrik Lundh" <effbot@telia.com  Thu Jun 29 10:29:11 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 11:29:11 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.4,2.5
References: <200006290857.BAA11219@slayer.i.sourceforge.net> <20000629021508.P29590@lyra.org>
Message-ID: <005601bfe1ac$7e014460$f2a6b5d4@hagrid>

greg wrote:

> Euh... can we get a bit more information in that checkin message. =
"towards
> 1.6b1" says zippo about what is changing or why.

just bringing the repository in sync with the current development
snapshot -- I promise to provide more info when the checkins are
more focused...

just gotta reach "1.6b1 quality" first...

</F>



From bckfnn@worldonline.dk  Thu Jun 29 10:42:03 2000
From: bckfnn@worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 09:42:03 GMT
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>
Message-ID: <395b1528.5978476@smtp.worldonline.dk>

[Tim Peters]

>id() has to return a unique value.

This property of id() does not hold in JPython. When used with hotspot,
id() is not unique.

regards,
finn


From Vladimir.Marangozov@inrialpes.fr  Thu Jun 29 11:05:12 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Thu, 29 Jun 2000 12:05:12 +0200 (CEST)
Subject: [Python-Dev] id() on Win64
In-Reply-To: <395b1528.5978476@smtp.worldonline.dk> from "Finn Bock" at Jun 29, 2000 09:42:03 AM
Message-ID: <200006291005.MAA20940@python.inrialpes.fr>

Finn Bock wrote:
> 
> [Tim Peters]
> 
> >id() has to return a unique value.
> 
> This property of id() does not hold in JPython. When used with hotspot,
> id() is not unique.

Is it?
Not unique or not persistent during the object's lifetime?

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From Fredrik Lundh" <effbot@telia.com  Thu Jun 29 11:07:42 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 12:07:42 +0200
Subject: [Python-Dev] build problems under MSVC 5.0
Message-ID: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid>

Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier
Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before =
identifier 'rv'
Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier
Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before =
'type'
Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier

in MSVC 5.0, _beginthread returns an "unsigned long" (this is also
how it's documented in MSDN).

I suggest changing the declaration in thread_nt.h to:

#if _MSC_VER >=3D 1200
 INT_PTR rv;
#else
 unsigned long rv;
#endif

on the other hand, the same docs claim that it returns -1 on errors.
doesn't exactly look like an unsigned long to me, but that's another
story...

</F>



From Fredrik Lundh" <effbot@telia.com  Thu Jun 29 11:21:22 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 12:21:22 +0200
Subject: [Python-Dev] arraymodule still broken?
Message-ID: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid>

just checked everything out and rebuilt, the exceptions
problem sure disappeared, but I still get this error:

>>> import array
>>> array.array("H", [60000])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: signed short integer is greater than maximum

second opinion, anyone?

</F>



From bckfnn@worldonline.dk  Thu Jun 29 11:43:55 2000
From: bckfnn@worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 10:43:55 GMT
Subject: [Python-Dev] id() on Win64
In-Reply-To: <200006291005.MAA20940@python.inrialpes.fr>
References: <200006291005.MAA20940@python.inrialpes.fr>
Message-ID: <395b26e6.10520397@smtp.worldonline.dk>

[Finn Bock]

> This property of id() does not hold in JPython. When used with hotspot,
> id() is not unique.

[Vladimir Marangozov}

>Is it?
>Not unique or not persistent during the object's lifetime?

Not unique. Two different objects can return the same value from
System.identityHashCode().

The HTML java docs have this to say about hashCodes:

"""
  As much as is reasonably practical, the hashCode method defined by class
  Object does return distinct integers for distinct objects. (This is
  typically implemented by converting the internal address of the object
  into an integer, but this implementation technique is not required by the
  JavaTM programming language.)
"""

Its just one of those small difference that we have to live with. In
pratical term I have seen it cause problems in pickle.py and
copy.deepcopy()

regards,
finn


From gmcm@hypernet.com  Thu Jun 29 13:22:12 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Thu, 29 Jun 2000 08:22:12 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <Pine.GSO.4.10.10006290943150.15938-100000@sundial>
References: <200006282213.PAA13365@slayer.i.sourceforge.net>
Message-ID: <1249841091-43777448@hypernet.com>

Moshe wrote:

> On Wed, 28 Jun 2000, Fred L. Drake wrote:
> 
> > + * Update the filecmp documentation (Moshe?).
> 
> I'm waiting for Gordon to check-in his directory comparisons to
> filecmp. Gordon? 

Looking at CVS, my stuff was there in filecmp revision 1.2 
(+299 -38) and wiped out by 1.3 (+38 -299) which was done 
the following day.

- Gordon


From akuchlin@mems-exchange.org  Thu Jun 29 13:25:19 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 29 Jun 2000 08:25:19 -0400
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <395ACED5.83764D45@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 09:21:41PM -0700
References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net>
Message-ID: <20000629082519.A13839@newcnri.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 09:21:41PM -0700, Paul Prescod wrote:
>I don't know where you got your expat or how new it is, but with the one
>I got from the xml-sig, I can type
>"make libexpat.a"

That's a patch I made to the Makefile and submitted to James Clark.
For Modules/Setup.in, I can change it to explicitly list the 8 files
from Expat that need to be linked to.  The problem is that one of the
files will vary:

# Use one of the next two lines; unixfilemap is better if it works.
FILEMAP_OBJ=xmlwf/unixfilemap.o
#FILEMAP_OBJ=xmlwf/readfilemap.o

--amk


From gward@mems-exchange.org  Thu Jun 29 13:26:47 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 08:26:47 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com> <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>
Message-ID: <20000629082647.A27322@ludwig.cnri.reston.va.us>

On 28 June 2000, Fredrik Lundh said:
> it would be very nice if the file object could do something similar
> internally (only in text mode, perhaps).  maybe in 1.7?

Oddly enough, I've been idly contemplating writing an extension type
(hypothetically called "superfile") that makes most of Perl's
file-handling semantics, and maybe some of the speedup, available in
Python.  At one level, it would be a rewrite of my 'text_file'
module/TextFile class in C.

But this is all speculation, mainly predicated on the theory that I
*really* should be eating my own dogfood and distributing some Python
extension, instead of just telling other people how to do it.  ;-)

        Greg


From gward@mems-exchange.org  Thu Jun 29 13:33:39 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 08:33:39 -0400
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <14682.15020.589514.702145@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Jun 28, 2000 at 01:49:32PM -0400
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net>
Message-ID: <20000629083339.B27322@ludwig.cnri.reston.va.us>

On 28 June 2000, Jeremy Hylton said:
>   PP> import cyclicgc
> 
>   PP> should turn on the -with-cycle-gc flag.
> 
> The -with-cycle-gc flag is an option to configure when you build
> Python.  It can't be turned on or off at runtime.

No, no, *obviously* Paul meant that "import cyclicgc" should configure
and compile a new Python interpreter with "--with-cycle-gc" and 'exec()'
it for you.  What else would it mean?

;-)

        Greg

(PS. if this were Perl, you could say

   use cyclegc;

to turn it on, and then elsewhere in your code

   no cyclegc;

to turn it off.  Maybe Python needs an "unimport" command?)

(Kidding!)


From gward@mems-exchange.org  Thu Jun 29 13:39:08 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 08:39:08 -0400
Subject: [Python-Dev] ucnhash module
In-Reply-To: <395A7E65.2271C723@lemburg.com>; from mal@lemburg.com on Thu, Jun 29, 2000 at 12:38:29AM +0200
References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com>
Message-ID: <20000629083908.D27322@ludwig.cnri.reston.va.us>

On 29 June 2000, M.-A. Lemburg said:
> The ucnhash module is loaded on demand to avoid memory bloat.
> In practice the difference is not really noticeable since 
> loading a shared module or swapping in a few pages of static
> C data result in pretty much the same overall memory usage.
> 
> If no-one complains, I'll fix the test suite though to make
> the tests of the named Unicode characters optional.

How 'bout a separate "test_ucn" to test this feature?

...of course, this is yet another case of language syntax features
becoming optional and selectable at compile-time, which I still think is
a bad idea.  Hmmm.

        Greg


From guido@beopen.com  Thu Jun 29 14:39:59 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 08:39:59 -0500
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: Your message of "Thu, 29 Jun 2000 01:08:27 -0400."
 <LNBBLJKPBEHFEDALKOLCOECAGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCOECAGHAA.tim_one@email.msn.com>
Message-ID: <200006291339.IAA09887@cj20424-a.reston1.va.home.com>

> There's already an IDLE distribution distinct from Python's:
> 
>     http://www.python.org/idle/
> 
> Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not
> clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack
> of time).

Yes.

> > Hmm... I guess that I don't much have an opinion one way or the other, but
> > was mostly looking for clarification.
> 
> I don't have a specific plan in mind either -- just "me too"ing on the idea
> that it would do no harm and possibly do real good to let these peripheral
> (to the core) things live on their own schedules.  I don't see any harm in
> including "the latest" snapshot of them with the core distribution,
> though -- it's handy for newcomers to get these things without needing to
> search for them.  I know I learned a lot about Python at the start from
> browsing these directories.

Additionally, it's great for Python on Windows to come with a working
GUI.  Pythonwin may be more like Windows, but it's much more fragile
than (recent versions of) IDLE in my experience.

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


From guido@beopen.com  Thu Jun 29 14:49:32 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 08:49:32 -0500
Subject: [Python-Dev] PyString_GET_SIZE()
In-Reply-To: Your message of "Wed, 28 Jun 2000 17:29:20 MST."
 <20000628172919.G29590@lyra.org>
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com>
 <20000628172919.G29590@lyra.org>
Message-ID: <200006291349.IAA09962@cj20424-a.reston1.va.home.com>

> Hmm. Is there a good place to start listing these todo items? One that we
> can truly use for communicating this info? In Apache, we have a file named
> STATUS that everybody uses for dropping ideas, patch references, critical
> bugs, etc. As that file gets changed, we see it in the -checkins alias, so
> everybody is aware of the suggested changes/problems/available patches/etc.
> It also holds people's votes on particular changes.
> 
> Can we institute something similar? Possibly Misc/STATUS? Should I post
> Apache's STATUS file as an example?

Possibly, but I'm somewhat skeptical.  I used to have a large TODO
file -- still have it -- but it's so full of long-term ideas that
never happened that I rarely look in it any more.  I never got into
the discipline of using it for my day-to-day priorities -- it was more
of a place to write down long-term ideas so I could forget about
them.  I'll append it.  I appreciate a copy of Apache's STATUS file.

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

NEW TODO LIST FOR 1.6
=====================

IDLE: set window class?
socket/ssl version mystery

UNIFIED TODO LIST
=================

From psa-members post
---------------------

Documentation.  I am working on api.tex.  The ext.tex file needs a
major overhaul too -- it's rather out of date.  I still haven't gotten
Harlequin's webmaker to produce decent HTML from the FrameMaker
version of the reference manual.

Unbundling.  I'm thinking of unbundling the documentation, demos, most
tools, and some platform specific or rarely used extension modules.  A
proposal would be welcome.

There are some unresolved issued with the Py_NewInterpreter()
interface and cleaning up threads, e.g. Demo/threads/condition.py
doesn't work.  I think I may have to change some interfaces (arguably
this is more than just a bug).

Some stuff that I have pending (the really small or well understood
bugs left out):

- urllib or ftplib seems to be getting the second transfer not quite
right; needs investigation

- tmb submitted patches to make creating large lists by appending
items one at a time faster; these were controversial because they work
by doubling the allocation size, which may waste precious mmmory for
very large lists; it is not clear whether it's actually needed

- my attempts at threading _tkinter backfired; the Tcl group says I
have to build my own version of Tcl and write my own notifier; but I
don't want to!

- and what to do about createfilehandler on Win and Mac platforms with
Tk 8.0?

- repr(), str(), print and cmp() may run into infinite loops when
comparing recursive objects; this should be fixed by checking the
recursion limit present in the thread state

- when the byte code gets too big, a better warning should be issued;
I've seen it dump core

- I'm not sure that dict objects always propagate exceptions in
comparisons properly

- there's discussion about __init__.py when using ni; should it be a
submodule of the project or run in the project's module?

- more places should accept arbitrary sequences or mappings instead of
lists/tuples and dicts

- there's a bunch of typedefs (e.g. binaryfunc) that should be grandly
renamed

- the .h files should all be renamed

- some .c files in Modules are better moved to Python now

- doc strings everywhere?

- some modules still break on 64-bit platforms

- sometimes test_select fails on Win (NT or 95?) with 'error 0'


1.5 TODO list
=============

urllib ftp problems -- see message from Wolfgang Weitz

finish api.tex! especially, document new threading/embedding interface

fix ref.doc

look into tmb's diffs (perhaps with an ifdef?)

make cPickle use new PyImporty_Import()

Showstoppers
------------

Plain old bugs
--------------

problem in _tkinter when passing a non-str'able object to tk.call()

check photoimage bug reported by Roman Milner to psa-members

GetAttr/SetAttr/DelAttr don't check for string object

"Must do" wishes
----------------

check for NULL from Py_Initmodule*()

limit recursion in repr() etc. a la stack check

error when bytecode gets too big is confusing (even core dumps possible!)

catch and propagate errors in comparisons in dictobject.c

Thread problems
---------------

Windows 95/NT
-------------

Tk 8.0 compatibility -- what do do about CreateFileHandler?

seeks in mailbox.py cause it not to work with files opened in text mode

??? select test fails on Windows with 'error 0' (is this w95?)

64-bit problems
---------------

verify that (2L**3671-1)%107423446849988119 is gone

test_audioop gives loads of "unaligned access" errors but reports OK

test_rgbimg and test_imageop gives segmentation faults

Other platform specific
-----------------------

mac Tk 8.0 compatibility -- what do do about CreateFileHandler?

AIX and linux have broken strftime

ultrix needs -li (i18n library) to use threads

FAQ
---

officially discard the python FAQ from usenet list of FAQs

add copyright boilerplate to FAQ (???)

point to faq wiz on website

point faq maintainers to faq wiz

Documentation
-------------

\code{~connolly} in liburllib.tex loses the ~ in html conversion

add __doc__ strings to type objects (and everywhere else :-)

PC/example_nt should also support DevStudio VC++ 5.0

restructure tutorial according to Skip M's suggestions

@e in HTML generated from libregex.tex.

Cleanup
-------

get rid of rgbimg and imgop (and audioop?)

move Demo and (some?) Tools from distribution to ftp/web site?

merge objimpl.h into object.h; clean up the comments

a bunch of typedefs (e.g. binaryfunc) in object.h are still old style;
also things like BAD_STATIC_FORWARD, staticforward, statichere (and
all the configure macros of course -- HAVE_*)

use size_t more often (e.g. for all string and list lengths)
(problem: can't be negative)

more routines should take arbitrary sequences -- e.g. string.join(), apply()

unified uu unpacking of image files for tests

urllib ftp cache behaves strangely when files are not read till EOF

Wishes
------

improve finalization order in modules

need portable file locking primitives

look into Embed.Lutz example

add fileevent to Tkinter

better output when regrtest detects an output difference

better diagnostic for skipping tests of optional features

Get rid of all references to old cgi module from web site

better unified drivers for uu, quopri, base64, binhex, and mimify

ni.py interferes with Mark Hammond's special module location mods.

ni.py and __init__.py?

argcount errors in Tk callbacks show up in traceback for mainloop(n).

Done/fixed/dealt with
---------------------

[fixed] copy.py bug (use of temp objects in memo?)

[that was on purpose] (dl_nt.c lost some code :-)

[done] see if method objects can be allocated from a free list

[done] the PC/example_nt readme file should be updated

[done] document new behavior of os.environ

[done] embedding example

[done] remove old FAQ from distribution; move new FAQ.html in

[done, I presume] AIX 4.2 supports ld -G

[fixed] test_strftime crashes on Mac with float -> int conversion

[never mind] report of 'str' not defined in NT freeze sometimes

[done] build debug and release versions like customary

[done] get 5.0 compiler to work; or reinstall 4.2 compiler

[done] rename mapping*c to dict*c in project file

[fixed] cgi.py uses nonportable unlink semantics

[fixed] bug I found in sortmail.py regexes

[done] look into JimF's PyImport_Import (to work with ni and rexec)

[done] generate ref/postscript

[fixed] test_strftime for windows

[done] get new cPickle

[done] Jim F's cgi.py and tempfile.py (?)

[done] Jack's diffs

[fixed] __del__ fails if __builtins__ is already gone

[done] Lee Busby's patches

[no; mhammond has dropped his dialog.py] Lib/tkinter/Dialog.c should
be renamed to avoid conflict with PythonWin's Dialog

[fixed] fileno() is undocumented

[done] Should add HAVE_KILL to configure.in

[never mind] look into greg's comments about thread state

[fixed] After running test_thread interactively, my sys.exitfunc()
dies: Fatal Python error: eval_code2 called without a current thread
IOT trap

[done] add sys.executable == path of Python binary

[done] add SocketType to socket module

[done] in regrtest, wrap __import__(test) in try/except+traceback

[no; rippped out] is the last_name trick in dictobject.c still needed?

[taken care of] delete _ on EOF for better GC?

[done] _tkinter threading

[fixed] Leak in: while 1: a=eval("1") (also in while 1: exec "a=1")

[fixed] urlparse clearcache makes the module non reentrant!

[explained] leak in exec reported by Just

[yes] make sure Lemburg's regex complaint is taken care of

[done] cgi.py should be runnable without environment or input

[fixed] shouldn't ignore exceptions in comparisons

[probably fixed] exception in ftplib.close can trip urllib

[fixed] PyFile_WriteString masks exceptions!

[fixed] test_audioop fails

[fixed] test_pwd uses an unreliable way to pick a non-existing uid for
fakeuid (if the largerst uid is the largest unsigned short, adding 1
makes it 0)

[fixed] object.[ch] doesn't have PyObject_HasAttr() even though
abstract.h has it

[fixed] win32 should guess sys.path like Unix getpath.c

[fixed] [by using sleep 5] DG/UX fails test_signal

[fixed] getpath.c doesn't work on DOS or OS/2 (Jim A submitted getpathp.c)

[fixed] use binary mode in ftpmirror script

[fixed] unlink before rename in ftpmirror script

[fixed] complexobject.c still has the c_error global

[fixed] ihooks' __import__ is leaking file descriptors (cause: the following)

[fixed] catching exceptions leaks frames!!! (same as following)

[fixed] ceval.c :: set_exc_info() appears to have a refcount problem
w.r.t. tstate->exc_* (it never does a DECREF on the prior contents).

[fixed] socket test fails on Windows in os.fork()

[fixed] add PIL init to tkappinit.c

[fixed] cPickle is broken

[fixed] Try curses and ncurses for readline (make it a loop?)

[fixed] make sure dis.py is up to date.

[fixed] read() of 8M file should be more efficient on Windows...

[fixed] regexpr.c: '^' doesn't match after '\n'

[done] python.exp (AIX) needs to have new symbols added

[fixed] README: use Digital Unix, not OSF/1.

[fixed] the vc40.mak and example.mak still has different linkage flags
(/MD vs. /MTd).  don't ask me what they're called in dev studio...

[done] remove TODO file from the distribution

[ignore] Lundh can't get ``CC=compiler ./configure'' to work

[fixed] 64-bit warnings in regexpr.c (Lundh)

[done] Set -Olimit 1500

[fixed] test_builtin is broken on 64-bit platforms:
    if hex(-16) != '0xfffffff0': raise TestFailed, 'hex(-16)'
alternative:
    if len(hex(-1)) != len(hex(sys.maxint)):
	raise TestFailed, 'len(hex(-1))'
    if hex(-16) not in ('0xfffffff0', '0xfffffffffffffff0'):
	raise TestFailed, 'hex(-16)'

[fixed] Donn Cave's problems with getpath.c
	- absolute VPATH doesn't do the right thing
	- stop after PREFIX

[fixed -- use O_NONBLOCK] Why doesn't FCNTL always define FNDELAY?

[fixed] re search and match were slowed down 10x by extraneous string copy

[fixed] 64-bit shift in cPickle.c:678

======================================================================

AMK's list:

Wishlist for Python 1.5:
========================

* Enhanced regex test suite (AMK)

* Updated cursesmodule (documented, supports ncurses)
	-- add conditionalized ncurses support and a way to detect it (OA)
	-- document the module (AMK)
	-- a few demos (Life game, text mode browser(?) ) (AMK & others)

* Update BSDDB module to work with version 2.0 of the DB code at http://www.bostic.com/db/ 
  (but 2.0 isn't compatible with 1.85--groan...)

* Did anything ever come of the DateTime class that someone had?

* More docstrings!

* Remove knowledge of the long int representation from Python/marshal.c 

* minor typo fixes 

* test suite for dumbdbm.py 

* whatswrong.py (suggested by Fredrik Lundh)

Documentation issues
====================

* Note from someone: calling __dict__ readonly is a massive piece of
misinformation, especially when the docs immediately show it being
modified. . .  (Technically incorrect--__dict__ returns a mutable
object, but you can't say i.__dict__={} )

* Document SocketServer.

* More documentation on threads

* Rework the tutorial, to avoid all the many "New features in Python
  1.X" sections (Guido)

* Updated Tkinter life preserver (Frederik Lundh)

* Better LaTeX typography--narrower margins, nicer appearance
	-- ragged setting & no hyphenation?
	-- Decrease the space after periods
	-- Try to remove footnotes
	-- Improve conversion to Texinfo and HTML

* Improve the index--look for references on making good book indices.
	GB: A global master index of all identifiers
	    and macros, with descriptions, references to point of
            definition, and scope, would kick some *serious* butt, but
            may require some serious sweat...

* Text at the start of the index encouraging the user to report index
  flaws to some e-mail address

* Crossreferences across modules.  For example, rand.py could have 
  "Related modules: whrandom (sect. X.Y.Z), random (sect. I.J.K)"

* A style guide for the documentation

* Use macros and styles consistently throughout -- this will involve
  writing a style guide, and then reading through the TeX source
  looking for nits... 

======================================================================
my own older lists...
======================================================================

Bugs:

... exception in __del__ when __builtins__ has been deleted

Features:

... simple threading support (with lock) for Tk

Documentation:

... Add section on filesystem interface to tutorial

... Update tutorial for changes in the language & library

... New sections for library reference manual (use NEWS file for hints)

... add stuff to ext.tex about threads and embedded Python

... mention that -2147483648 doesn't work

... mention that 0e0 and 01.0 etc. don't work

Maybe not (yet):

... get rid of 'owner' passed around for newframeobject and evalcode

... rename init<module> to PyInit_<module>.

... import ni seems to interpret the current directory as a package.

... prototype for PyOS_CheckStack() somewhere

... On some Linuxes, ``python -c "print 12" | wc'' produces no output???

... Add INSTALL_ROOT variable to Makefile.in

... More thread testing (Solaris?), wait for David Arnold

... Get rid of more modules: (stdwin, soundex, SGI specific?)

... Use autoconf features to find X11 libraries

... Use more modern autoconf features (e.g. for platform testing)

======================================================================
======================================================================
The following is old and I haven't checked whether it still applies:

(-) many module should export their symbolic constants instead of
relying on a module written in Python

(-) change regexmodule.c to cooperate with other non-python users and
to export the symbolic constants

(-) save/restore sys.exc_{type,value,traceback} around except clauses.

(-) don't call class instance's __del__ more than once?????

(-) add "access" to posix?  What name should it have?

(-) add facility to "freeze" lists and dictionaries?

(-) add WNOHANG to posix

(-) support lists in newgetargs()

(-) syntax errors detected during compilation should give line number

(-) dbm.open(): rwmode, filemode should be made optional; same for gdbm

(-) find a bsd hash interface

(-) posix.mkdir(): mode should be made optional

(-) find a more useful order than alphabetical for Doc/libfuncs.tex

======================================================================

(-) investigate PPRC <URL:ftp://ftp.parc.xerox.com/pub/ppcr/>

(-) interface to getdtablesize() in posix

(-) reentrancy with global variables vs. decref in
./Modules/cdmodule.c ./Modules/flmodule.c ./Objects/accessobject.c
./Objects/frameobject.c ./Python/traceback.c

(-) speed up regsub.gsub

(-) try posixenviron.c and merge back into posixmodule.c?

(-) add and document chroot() ?

(-) Add `@CFLAGS@', `@CPPFLAGS@', and `@LDFLAGS@' to `Makefile.in'

(-) modules should be able to define a module destructor hook

(-) destroy modules in reverse order of importation?

(-) make array a standard built-in object

(-) makesetup should accept .o files without corresponding .c file

(-) try Boehm/Dehmers/Weiser conservative garbage collector

(-) document new Python/C API

(-) add various things to module dictionary, e.g. pathname, dictionary
where found, __version__ string?

(-) pass dict of builtins to exec / execfile / eval ???

(?) stack frame correspondence problem (Jim Roskind)
(probably solved by err_fetch / err_restore)

(-) make lots of places use newgetargs

(-) readline 2.0 on sequent has ^C problem (works only first time)

(-) need to add truncate() and ftruncate() to posixmodule.c (Windows:
chsize(fd, size) (solution: added to file objects instead)

(-) improve performance of list.append/insert etc. by keeping high/low
watermark instead of realloc'ing each time?

(-) findmethod should cache (also findmember?)

(-) sysget("check_interval") is called before each method call which
breaks dictlookup caching

(-) core dump on repr / print of deeply nested or recursive object

(-) whrandom doc needs update

(-) fix signalmodule.c to re-establish SIGC[H]LD handler

(-) redesign error handling (cf. Donald's mail)

(-) does MPW 3.2 need the MPW_881_BUG defined in Parser/acceler.c

(-) rename MPW_3_1 define (which really means 3.x)

(-) add warning to docs about sys.exc_traceback and sys.last_traceback.

(-) latex docs for signal module

(-) systematically create /usr/local/lib/python/<machine>-<os>/
    subdirectories, with a lib/ subdirectory containing the lib*.a
    files etc.

(-) need newer DOS binary (16 bit version doesn't do default args)

(-) document Tk

(-) class browser

(-) interactive Python GUI (a la NT thingie)

(-) more stuff under CVS (demo, extensions)

(-) use const for char * parameters (and many more) where possible

(-) The Great Renaming!

(-) document __getattr__, __setattr__

(-) many things that take strings should also take arrays of chars

(-) add list of existing extensions to FAQ

(-) update "recent additions" chapter in tutorial

(-) rewrite "output formatting" chapter in tutorial

(-) document addpack, urllib, ...

(-) make regsub.[g]sub() optionally case insensitive

(-) dynamic linking on the Mac (is this a dream?)

(-) Later:
    - put the offending object in IOError and posix.error
    - make module marshal work with user-defined file-like objects
    - built-in help?
    - hierarchical module names?

Big plans:

- allow separate interpreters (a la Xt's Applocation Contexts, and Tcl)
- complete reflexive nature of the language, e.g. have interfaces et
create any kind of object

FAQ:

why don't list methods return self

Even older:

make .pyc files executable (how?)

thread status and improvements (lock stmt; signal/wait)

optional optimizations

pthread migration

multiple interpreter objects

persistency

new Dbhash.py, dbhash library

(-) dbm objects miss items(), values() methods

(-) answer q about coerce()

(-) describe() ?

(-) distribute demo2 with Holmes

(-) classes are too slow

(-) add += etc. ?

optimize tuple = tuple

allow (a, b) = [1, 2] and [1, 2] = (1, 2) ???

explain rules about == vs. 'is' for strings (* by others on the list)

rewrite section on formatting in tutorial

======================================================================
TODO-TOO list:

test for overflow when converting python long to float

lift restrictions on tuple or list in many cases

Should double-check all changes with docs!

(?) Interrupting output still sometimes doesn't call clearerr() properly

sometimes ghost errors when interrupting during debugging in
'continue' mode?

typing a comment to a primary prompt shouldn't issue a secondary prompt

readline: add hooks to recognize Python syntax and to expand Python
commands and names

should have absolute pathnames in function objects

in general check that all the exceptions are modernized and that the
messages aren't giving the same error twice (e.g., stdwinmodule.c!)

- check read/write allowed for file objects

- introduce macros to set/inspect errno for syscalls, to support things
  like getoserr()

======================================================================
DOS/Windows Python

(???) command line options?

(???) interrupts

(???) wrap



From Fredrik Lundh" <effbot@telia.com  Thu Jun 29 13:58:13 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 14:58:13 +0200
Subject: [Python-Dev] PyString_GET_SIZE()
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com>             <20000628172919.G29590@lyra.org>  <200006291349.IAA09962@cj20424-a.reston1.va.home.com>
Message-ID: <006201bfe1c9$b928d400$f2a6b5d4@hagrid>

guido wrote:

> > Hmm. Is there a good place to start listing these todo items? One =
that we
> > can truly use for communicating this info? In Apache, we have a file =
named
> > STATUS that everybody uses for dropping ideas, patch references, =
critical
> > bugs, etc. As that file gets changed, we see it in the -checkins =
alias, so
> > everybody is aware of the suggested changes/problems/available =
patches/etc.
> > It also holds people's votes on particular changes.
> >=20
> > Can we institute something similar? Possibly Misc/STATUS? Should I =
post
> > Apache's STATUS file as an example?
>=20
> Possibly, but I'm somewhat skeptical.  I used to have a large TODO
> file -- still have it -- but it's so full of long-term ideas that
> never happened that I rarely look in it any more.

instead of a file, I suggest taking a look at ?!ng's Roundup
(once 1.6 final is out, of course).

</F>



From guido@beopen.com  Thu Jun 29 14:58:00 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 08:58:00 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: Your message of "Thu, 29 Jun 2000 08:22:12 -0400."
 <1249841091-43777448@hypernet.com>
References: <200006282213.PAA13365@slayer.i.sourceforge.net>
 <1249841091-43777448@hypernet.com>
Message-ID: <200006291358.IAA10045@cj20424-a.reston1.va.home.com>

> Moshe wrote:
> 
> > On Wed, 28 Jun 2000, Fred L. Drake wrote:
> > 
> > > + * Update the filecmp documentation (Moshe?).
> > 
> > I'm waiting for Gordon to check-in his directory comparisons to
> > filecmp. Gordon? 
> 
> Looking at CVS, my stuff was there in filecmp revision 1.2 
> (+299 -38) and wiped out by 1.3 (+38 -299) which was done 
> the following day.

Argh!  An inappropriate side effect of Ping's cleanup -- thanks for
catching this.  Apparently Ping didn't do a CVS update before
generating his diffs.

I can restore version 1.2 easily, but I'm not sure what to do with
/F's changes (1.3 -> 1.4).  Gordon, can you look at this and suggest
what to do?

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


From mal@lemburg.com  Thu Jun 29 14:04:24 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 15:04:24 +0200
Subject: [Python-Dev] ucnhash module
References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com> <20000629083908.D27322@ludwig.cnri.reston.va.us>
Message-ID: <395B4958.C9909145@lemburg.com>

Greg Ward wrote:
> 
> On 29 June 2000, M.-A. Lemburg said:
> > The ucnhash module is loaded on demand to avoid memory bloat.
> > In practice the difference is not really noticeable since
> > loading a shared module or swapping in a few pages of static
> > C data result in pretty much the same overall memory usage.
> >
> > If no-one complains, I'll fix the test suite though to make
> > the tests of the named Unicode characters optional.
> 
> How 'bout a separate "test_ucn" to test this feature?

Good idea.
 
> ...of course, this is yet another case of language syntax features
> becoming optional and selectable at compile-time, which I still think is
> a bad idea.  Hmmm.

It's not selectable at run-time: either you have compiled the
module or not. It is enabled per default.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From Vladimir.Marangozov@inrialpes.fr  Thu Jun 29 14:31:21 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Thu, 29 Jun 2000 15:31:21 +0200 (CEST)
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 28, 2000 03:59:46 PM
Message-ID: <200006291331.PAA21571@python.inrialpes.fr>

Guido van Rossum wrote:
> 
> I wonder if we should turn this option *on* during beta testing?

Why not, as long as --without-gc does not suffer from bugs hidden by
--with-gc.

> 
> That way we gather a lot more experience with its use!  Maybe nobody
> complains and we can leave it on in the final release...

This is risky. We don't have enough experience with this implementation.
All we know is that things get slower and consume more memory. Without
a clear picture of the impact of this GC implementation, it's probably
a bad idea to enable (i.e. impose) it by default.  

The "optional experimental feature" label is good and IMO it complies
with anybody's expectations. Interested people will jump in and will
eventually contribute with improvements, those who don't care won't
and will live happily without it (at least until the day the feature
and its implementation reach their expected maturity).

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From gmcm@hypernet.com  Thu Jun 29 14:27:01 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Thu, 29 Jun 2000 09:27:01 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com>
References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400."             <1249841091-43777448@hypernet.com>
Message-ID: <1249837203-44011365@hypernet.com>

[Gordon] 
> > Looking at CVS, my stuff was there in filecmp revision 1.2
> > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the
> > following day.
[Guido]
> Argh!  An inappropriate side effect of Ping's cleanup -- thanks
> for catching this.  Apparently Ping didn't do a CVS update before
> generating his diffs.
> 
> I can restore version 1.2 easily, but I'm not sure what to do
> with /F's changes (1.3 -> 1.4).  Gordon, can you look at this and
> suggest what to do?

If you have the eff-bot's diff, it should apply to 1.2 (my changes 
are all below there - basically I added a rewritten dircmp). I 
think a CVS merge would do the right thing, too.

- Gordon


From mal@lemburg.com  Thu Jun 29 14:33:36 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 15:33:36 +0200
Subject: [Python-Dev] CVS locks on SF
Message-ID: <395B5030.C0F08E82@lemburg.com>

I'm getting loads of lock messages during CVS checkins recently.
Is this due to overload ? (I wonder why anoncvs access causes
locking at all -- there is no write access so why should there
be file locking ?):

[06:31:40] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test
cvs server: [06:32:10] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test
cvs server: [06:32:41] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test
cvs server: [06:33:11] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From fdrake@beopen.com  Thu Jun 29 14:52:40 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 09:52:40 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <20000629082519.A13839@newcnri.cnri.reston.va.us>
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
 <395ACED5.83764D45@prescod.net>
 <20000629082519.A13839@newcnri.cnri.reston.va.us>
Message-ID: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com>

Andrew Kuchling writes:
 > That's a patch I made to the Makefile and submitted to James Clark.
 > For Modules/Setup.in, I can change it to explicitly list the 8 files
 > from Expat that need to be linked to.  The problem is that one of the

  It's not in the stable version I picked up last night; I'll dig up
the experimental version today.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From paul@prescod.net  Thu Jun 29 14:52:21 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 29 Jun 2000 06:52:21 -0700
Subject: [Python-Dev] Text about cycle GC
References: <200006291331.PAA21571@python.inrialpes.fr>
Message-ID: <395B5495.CF274583@prescod.net>

Vladimir Marangozov wrote:
> 
>...
>
> This is risky. We don't have enough experience with this implementation.
> All we know is that things get slower and consume more memory. Without
> a clear picture of the impact of this GC implementation, it's probably
> a bad idea to enable (i.e. impose) it by default.

Won't we have a clear picture by the end of the beta period?

> The "optional experimental feature" label is good and IMO it complies
> with anybody's expectations. Interested people will jump in and will
> eventually contribute with improvements, those who don't care won't
> and will live happily without it (at least until the day the feature
> and its implementation reach their expected maturity).

A million Window users will live unhappily without it because they don't
know how to recompile to get it!

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski


From billtut@microsoft.com  Thu Jun 29 14:54:21 2000
From: billtut@microsoft.com (Bill Tutt)
Date: Thu, 29 Jun 2000 06:54:21 -0700
Subject: [Python-Dev] re: ucnhash
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50>

Re: ucnhash and where the stuff gets tested

Doesn't matter to me where the test goes.

WRT how big it is, thats why its dynamically loaded at run time.
If you don't compile it at all, then the \N{...} syntax just won't owrk.

Re: static vs. staticforward
I can actually do a patch for that, and regen ucnhash.c for you.

Re: "" vs. <>
Whats wrong with what I'm currently doing?

All of the .h files I'm including are on the include file path. "" usage
just means stick "." before everything else in your include path.
None of the files need that. :) If there's a diffferent policy in the Python
source 'bout that that I'm not aware of, then I can fix that issue too.

Bill


From guido@beopen.com  Thu Jun 29 16:03:36 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 10:03:36 -0500
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: Your message of "Thu, 29 Jun 2000 15:33:36 +0200."
 <395B5030.C0F08E82@lemburg.com>
References: <395B5030.C0F08E82@lemburg.com>
Message-ID: <200006291503.KAA10324@cj20424-a.reston1.va.home.com>

> I'm getting loads of lock messages during CVS checkins recently.
> Is this due to overload ? (I wonder why anoncvs access causes
> locking at all -- there is no write access so why should there
> be file locking ?):

I haven't seen this myself.  Could be you were just unlucky.  Could be
someone was doing a full checkout over a slow connection.

I think the anon checkouts still use (read) locks because they need to
get a consistent version.

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


From gstein@lyra.org  Thu Jun 29 15:10:51 2000
From: gstein@lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 07:10:51 -0700
Subject: [Python-Dev] STATUS files (was: PyString_GET_SIZE())
In-Reply-To: <200006291349.IAA09962@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 08:49:32AM -0500
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> <200006291349.IAA09962@cj20424-a.reston1.va.home.com>
Message-ID: <20000629071051.T29590@lyra.org>

On Thu, Jun 29, 2000 at 08:49:32AM -0500, Guido van Rossum wrote:
> > Hmm. Is there a good place to start listing these todo items? One that we
> > can truly use for communicating this info? In Apache, we have a file named
> > STATUS that everybody uses for dropping ideas, patch references, critical
> > bugs, etc. As that file gets changed, we see it in the -checkins alias, so
> > everybody is aware of the suggested changes/problems/available patches/etc.
> > It also holds people's votes on particular changes.
> > 
> > Can we institute something similar? Possibly Misc/STATUS? Should I post
> > Apache's STATUS file as an example?
> 
> Possibly, but I'm somewhat skeptical.  I used to have a large TODO
> file -- still have it -- but it's so full of long-term ideas that
> never happened that I rarely look in it any more.  I never got into
> the discipline of using it for my day-to-day priorities -- it was more
> of a place to write down long-term ideas so I could forget about
> them.  I'll append it.  I appreciate a copy of Apache's STATUS file.

Attached below...

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

Apache 2.0 STATUS:
Last modified at [$Date: 2000/06/28 11:41:14 $]

Release:

    2.0a5   : ???
    2.0a4   : released June 7, 2000
    2.0a3   : released April 28, 2000
    2.0a2   : released March 31, 2000
    2.0a1   : released March 10, 2000

RELEASE SHOWSTOPPERS:
    * Win32: Get mod_auth_digest working under win32
      - APR_HAS_RANDOM should be defined on windows and there is a 
      lib/apr/misc/win32/rand.c which is basically a copy of what
      mod_auth_digest used to use.

    * Re-work configuration for top level Apache.  Work should start with
      trying to clean the autoconf stuff.  If and only if this proves
      impossible to do (very unlikely), autoconf should be removed and we
      will roll our own config implementation.

    * suEXEC doesn't work
        Status: Manoj has posted an patch to fix this.
        <19991103003605.A20612@samosa.mindspring.com>

    * Win32: Enable the Windows MPM to honor max_requests_per_child
        Status: Bill will fix this.

    * Win32: Get Apache working on Windows 95/98. The following work
	(at least) needs to be done:
	- winnt MPM: Fix 95/98 code paths in the winnt MPM. There is some NT
	specific code that is still not in NT only code paths
	- IOL binds to APR sendfile, implemented with TransmitFile, which 
        is not available on 95/98.

    * Win32: Test access logging with multiple threads. Will the 
	native file I/O calls serialize automagically like the 
	CRT calls or do we need to add region locking each time 
	we access the logs?
	Status: 

    * Win32: Complete the revamp the service environment and relocation
        into the WinNT MPM.  Changes ServerRoot service registry 
        parameter into ConfigArgs for multiple service startup parameters.
        Problems to fix in the revamp: -k shutdown/restart are broken, 
        signals are not being acknowledged.  Close window and shutdown 
        also seem out of sorts.
        OtherBill is working on this

    * Win32: fix build/run time environment to remove ApacheCore.dll 
        linkage from ab.exe and htdigest.exe.
    
    * We need a thread-safe resolver, at least on Unix.
        Status: The best known candidate would be something from
	BIND v9.
        Status: Greg asks, "why? doesn't gethostbyname_r() handle this?"

    * Modify mod_cgi and mod_cgid to deal with directories.  This allows
      a lot of directives to be removed from the core.

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
    * OS/2: Get loadable modules working again. Requires shared core support
      which doesn't appear to be catered for in the current build system.

    * OS/2: Make mod_status work for spmt_os2 MPM.

    * Build scripts do not recognise AIX 4.2.1 pthreads, so the
      pthread MPMs will not build.

    * Win32: Reuse accept socket after transmitfile/close
	This is not a bug, but would be nice to get this feature in 
	before ship.

    * Win32: Enable the winnt MPM to use the new scoreboard API

    * Win32: Implement ap_shm_ functions in APR.

    * Win32: Win9x console window still won't play nice with the
        close window, logoff and shutdown scenarios.

    * Win32: Add a simple hold console open patch (wait for close or
        the ESC key, with a nice message) if the server died a bad 
        death (non-zero exit code) in console mode.

    * Platforms that do not support fork (primarily Win32 and AS/400)
      Consider introducing HAVE_FORK feature macro. Architect start-up code
      that avoids initializing all the modules in the parent process on
      platforms that do not support fork.

    * Clean the code.  There are a lot of places we used APR but didn't 
      remove the hacks that were required for the cross-platform code in
      1.3.  We need to make the code look like APR was supposed to be there. 

    * Go throught the 1.3 Bug DB and research the bugs marked "suspended".
      People were told these would be considered for inclusion in Apache 2.0,
      it would be nice to actually do so.

    * Win32: Migrate the MPM over to use APR thread/process calls. This
      would eliminate some code in the Win32 branch that essentially
      duplicates what is in APR.

      Bill says we need a new procattr, APR_CREATE_SUSPENDED (or
      something similar) to direct ap_create_process to create the
      process suspended. We also need a call to wake up the suspended 
      process This may not be able to be implemented everywhere though.

        Status: 

    * Move I/O layering into APR.

    * There are still a number of places in the code where we are
      loosing error status (i.e. throwing away the error returned by a
      system call and replacing it with a generic error code)

    * Win32: Implement reliable piped logs on Windows
        Status: 
          
    * Use APR to get rid of more platform dependancies.
        Status: Ryan Bloom <rbb@covalenet.net> is working on this.

    * The connection status table is not very efficient. Also, very few stats
      are exported to the connection status table (easy to fix), and mod_status
      is ugly.

    * Mass vhosting version of suEXEC.

    * Replace tables with a proper opaque ADT that has pluggable
      implementations (including something like the existing data type,
      plus hash tables for speed, with options for more later).
	Status: fanf is working on this.

    * configuration option to use *DBM
      Status: Greg +1 (volunteers)

    * add SDBM into src/lib/sdbm/ as a default/fallback DBM implementation.
      SDBM is used by Perl, mod_dav, mod_sssl, others for basic DBM support.
      Status: Greg +1 (volunteers)

    * Integrate mod_dav.
        Message-id: <20000625173247.M29590@lyra.org>
        Status: in process.
        - APR does not provide a couple needed things: chmod()
          and ap_finfo_t.st_dev.
	- expat-lite needs to be brought up to parity with the 1.3
	  vsn and inserted into the config/build process
	- SDBM needs to go into the config/build process
	- fix up include dirs to pick up expat-lite, sdbm, dav/main
	- APR-ization to the dav/fs/ stuff
	- case_preserved_filename stuff

    * ap_core_translate() and its use by mod_mmap_static are a bit wonky.
      The function should probably be exposed as a utility function (such
      as ap_translate_url2fs() or ap_validate_fs_url() or something).
      Another approach would be a new hook phase after "translate" which
      would allow mod_mmap_static to munge what the translation has
      decided to do.
        Status: Greg +1 (volunteers), Ryan +1

    * Go through ap_config.h and namespace-protect the symbols (e.g. USE_*).
      Some symbols can/should move to mpm_common.h where possible.

    * Explore use of a post-config hook for the code in http_main.c which
      calls ap_fixup_virutal_hosts(), ap_fini_vhost_config(), and
      ap_sort_hooks()  [to reduce the logic in main()]

    * read the config tree just once, and process N times (as necessary)

    * add a version number to ap_initialize() as an extra failsafe against
      (APR) library version skew.
      MsgID: <Pine.LNX.4.10.10005231712380.31927-100000@nebula.lyra.org>
      Status: Greg +1 (volunteers), Jeff +1, Ryan +1, Tony -0(?)

    * mod_info to use the configuration tree

    * add output filtering. there are a couple variants for this.
      - The "link-based" variant is ready to go:
        MsgID: <20000627044436.N29590@lyra.org>   (patch)
	MsgID: <20000627053302.O29590@lyra.org>   (demo usage)
	MsgID: <Pine.LNX.4.21.0006270731240.4006-100000@koj.rkbloom.net>
                             (problems with the patch)
        Status: Greg +1, Ryan -1
        

Other bugs that need fixing:

    * MaxRequestsPerChild measures connections, not requests.
        Until someone has a better way, we'll probably just rename it
        "MaxConnectionsPerChild".
    
    * Regex containers don't work in an intutive way
        Status: No one has come up with an efficient way to fix this
        behavior. Dean has suggested getting rid of regex containers
        completely.

    * SIGSEGV on Linux (glibc 2.1.2) isn't caught properly by a
      sigwaiting thread. We need to work around this, perhaps unless
      there is hope soon for a fixed glibc.

    * The mod_cgid daemon process isn't always cleaned up when httpd
      gets SIGTERM.  Jeff thinks it may be as simple as registering
      the daemon process for cleanup with the proper pool, but he hasn't
      looked at it in enough detail.

    * The MM library is built as static and shared library. This should
      be set up to build only the required version.

Other features that need writing:

    * Finish infrastructure in core for async MPMs
        Status: post 2.0

    * TODO in source -- just do an egrep on "TODO" and see what's there

Documentation that needs writing:
    * Mod_status docs are needed.

    * The concept of MPMs, especially if we ship more than one MPM for a
      given platform

    * New directives in the various MPMs and appropriate links from
	obsolete directives in core.html to the MPM documentation.

    * Revise manual/stopping.html and the last part of
	manual/misc/perf-tuning.html to take account of the MPMs.

    * API documentation
        Status: Ben Laurie has written some hooks documentation
        (apache-2.0/htdocs/hooks.html)

    * Changes since 1.3.9 can be more easily seen in the commitlog file
         dev.apache.org:/home/cvs/CVSROOT/commitlogs/apache-2.0
      which includes some of Roy's comments when the changes were
      committed in rough change-sets by purpose.  Note that the commitlog
      does not show the contents of new files until later.

    * mod_dav documentation (once integrated)

Available Patches:

   * Mike Abbott's <mja@trudge.engr.sgi.com> patches to improve
     performance
       Status: These were written for 1.3, and are awaiting a port to
       2.0
 
   * Jim Winstead's <jimw@trainedmonkey.com> patch to add CookieDomain and 
     other small mod_usertrack features

Open issues:

   * What do we do about mod_proxy?

   * Which MPMs will be included with Apache 2.0?

   * Is conf/highperformance.conf-dist obsolete?  It looks obsolete.



From fredrik@pythonware.com  Thu Jun 29 15:11:26 2000
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 16:11:26 +0200
Subject: [Python-Dev] Text about cycle GC
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net>             <20000628122725.A13473@acs.ucalgary.ca>  <200006282059.PAA04852@cj20424-a.reston1.va.home.com>
Message-ID: <016a01bfe1d3$ea2474b0$0900a8c0@SPIFF>

guido wrote:
> I wonder if we should turn this option *on* during beta testing?

+1 from me.

> That way we gather a lot more experience with its use!  Maybe nobody
> complains and we can leave it on in the final release...

I won't mind (unless it breaks my code, of course).

</F>



From mal@lemburg.com  Thu Jun 29 15:10:28 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 16:10:28 +0200
Subject: [Python-Dev] re: ucnhash
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50>
Message-ID: <395B58D4.E52CBBD6@lemburg.com>

Bill Tutt wrote:
> 
> Re: ucnhash and where the stuff gets tested
> 
> Doesn't matter to me where the test goes.

I'm currently trying to check these changes in... doesn't work
though due to some obscure CVS locks.
 
> WRT how big it is, thats why its dynamically loaded at run time.
> If you don't compile it at all, then the \N{...} syntax just won't owrk.
> 
> Re: static vs. staticforward
> I can actually do a patch for that, and regen ucnhash.c for you.

Someone (Fred ?) already patches those places for you. He didn't
send patches for the perfect hash tool though.
 
> Re: "" vs. <>
> Whats wrong with what I'm currently doing?

<> uses a differnt header file lookup path... normally doesn't
hurt, but...
 
> All of the .h files I'm including are on the include file path. "" usage
> just means stick "." before everything else in your include path.
> None of the files need that. :) If there's a diffferent policy in the Python
> source 'bout that that I'm not aware of, then I can fix that issue too.

... you already know that ;-)

Again, these are already fixed :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From guido@beopen.com  Thu Jun 29 16:15:09 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 10:15:09 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: Your message of "Thu, 29 Jun 2000 09:27:01 -0400."
 <1249837203-44011365@hypernet.com>
References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com>
 <1249837203-44011365@hypernet.com>
Message-ID: <200006291515.KAA10374@cj20424-a.reston1.va.home.com>

> [Gordon] 
> > > Looking at CVS, my stuff was there in filecmp revision 1.2
> > > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the
> > > following day.
> [Guido]
> > Argh!  An inappropriate side effect of Ping's cleanup -- thanks
> > for catching this.  Apparently Ping didn't do a CVS update before
> > generating his diffs.
> > 
> > I can restore version 1.2 easily, but I'm not sure what to do
> > with /F's changes (1.3 -> 1.4).  Gordon, can you look at this and
> > suggest what to do?

[Gordon]
> If you have the eff-bot's diff, it should apply to 1.2 (my changes 
> are all below there - basically I added a rewritten dircmp). I 
> think a CVS merge would do the right thing, too.

There was a change in indent style, so effbot's diff didn't apply
cleanly -- but your suggestion made me realize that it was easy to
re-apply manually.

It's all fixed now.  Thanks all!

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


From mal@lemburg.com  Thu Jun 29 15:15:23 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 16:15:23 +0200
Subject: [Python-Dev] CVS locks on SF
References: <395B5030.C0F08E82@lemburg.com> <200006291503.KAA10324@cj20424-a.reston1.va.home.com>
Message-ID: <395B59FB.1CD472AE@lemburg.com>

Guido van Rossum wrote:
> 
> > I'm getting loads of lock messages during CVS checkins recently.
> > Is this due to overload ? (I wonder why anoncvs access causes
> > locking at all -- there is no write access so why should there
> > be file locking ?):
> 
> I haven't seen this myself.  Could be you were just unlucky.  Could be
> someone was doing a full checkout over a slow connection.
> 
> I think the anon checkouts still use (read) locks because they need to
> get a consistent version.

Looks like someone is using a 9.6kBaud mobile phone connection ;-)
The problem still persists and I've been trying for about
half an hour now.

I'll try again later today...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From guido@beopen.com  Thu Jun 29 16:21:47 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 10:21:47 -0500
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: Your message of "Thu, 29 Jun 2000 06:52:21 MST."
 <395B5495.CF274583@prescod.net>
References: <200006291331.PAA21571@python.inrialpes.fr>
 <395B5495.CF274583@prescod.net>
Message-ID: <200006291521.KAA10440@cj20424-a.reston1.va.home.com>

> Won't we have a clear picture by the end of the beta period?

Not clear.  Unfortunately, few people who run important apps will
download a beta and try it.  But they *will* download a new release
labeled "final" and install it without making sure it works for their
app.  This has been my experience throughout Python's life.  I've
become pretty conservative about staying backwards compatible as a
result...

> > The "optional experimental feature" label is good and IMO it complies
> > with anybody's expectations. Interested people will jump in and will
> > eventually contribute with improvements, those who don't care won't
> > and will live happily without it (at least until the day the feature
> > and its implementation reach their expected maturity).
> 
> A million Window users will live unhappily without it because they don't
> know how to recompile to get it!

This can be solved the way we solve everything for Windows users: give
them two distributions to choose from -- or maybe one distribution
with a checkbox to choose which version to use.

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


From skip@mojam.com (Skip Montanaro)  Thu Jun 29 14:38:20 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 29 Jun 2000 08:38:20 -0500 (CDT)
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
References: <20000628025304.BB64A1CE0D@dinsdale.python.org>
 <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <14683.20812.615266.196934@beluga.mojam.com>

    Andy> How many people here have actually created accounts for themselves
    Andy> on SourceForge and tried to do stuff when logged in - raise bugs
    Andy> and so on?  Did it work for you?

I've submitted a few patches with no problems.  My usual connections are a
corporate T1-ish connection or cable modem access from home, however.

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."


From jeremy@beopen.com  Thu Jun 29 15:45:27 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 29 Jun 2000 10:45:27 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com>
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
 <395ACED5.83764D45@prescod.net>
 <20000629082519.A13839@newcnri.cnri.reston.va.us>
 <14683.21672.414396.364125@cj42289-a.reston1.va.home.com>
Message-ID: <14683.24839.650558.23732@bitdiddle.concentric.net>

>>>>> "FLD" == Fred L Drake, <fdrake@beopen.com> writes:

  FLD> Andrew Kuchling writes:
  >> That's a patch I made to the Makefile and submitted to James
  >> Clark.  For Modules/Setup.in, I can change it to explicitly list
  >> the 8 files from Expat that need to be linked to.  The problem is
  >> that one of the

  FLD>   It's not in the stable version I picked up last night; I'll
  FLD> dig up the experimental version today.

I downloaded version 1.1 from the expat home page.  The URL for the
download is ftp://ftp.jclark.com/pub/xml/expat.zip.  This version
hasn't changed in the last two weeks. 

The instructions Fred include worked almost just right.  I checked in
the corrected ar command and it looks good.

Jeremy


From fdrake@beopen.com  Thu Jun 29 15:46:48 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 10:46:48 -0400 (EDT)
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <200006291503.KAA10324@cj20424-a.reston1.va.home.com>
References: <395B5030.C0F08E82@lemburg.com>
 <200006291503.KAA10324@cj20424-a.reston1.va.home.com>
Message-ID: <14683.24920.264911.840500@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > I think the anon checkouts still use (read) locks because they need to
 > get a consistent version.

  Yes; you need a directory lock to avoid files getting modified or
deleted underneath you while checking out/updating.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Thu Jun 29 15:48:38 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 10:48:38 -0400 (EDT)
Subject: [Python-Dev] re: ucnhash
In-Reply-To: <395B58D4.E52CBBD6@lemburg.com>
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50>
 <395B58D4.E52CBBD6@lemburg.com>
Message-ID: <14683.25030.205960.13328@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Someone (Fred ?) already patches those places for you. He didn't
 > send patches for the perfect hash tool though.

  Not this Fred...


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Thu Jun 29 15:52:28 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 10:52:28 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <14683.24839.650558.23732@bitdiddle.concentric.net>
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
 <395ACED5.83764D45@prescod.net>
 <20000629082519.A13839@newcnri.cnri.reston.va.us>
 <14683.21672.414396.364125@cj42289-a.reston1.va.home.com>
 <14683.24839.650558.23732@bitdiddle.concentric.net>
Message-ID: <14683.25260.182929.808330@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > The instructions Fred include worked almost just right.  I checked in
 > the corrected ar command and it looks good.

  That's what I get for typing in the dark on a dark keyboard.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From tpeters@beopen.com  Thu Jun 29 17:23:54 2000
From: tpeters@beopen.com (Tim Peters)
Date: Thu, 29 Jun 2000 12:23:54 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <395b1528.5978476@smtp.worldonline.dk>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>

[posted & mailed]

[Tim]
> id() has to return a unique value.

[Finn Bock]
> This property of id() does not hold in JPython. When used with hotspot,
> id() is not unique.

So it's possible there for one of these be true:

    id(x) == id(y) and x is not y
    id(x) != id(x)

?  Then that's a bug in JPython or hotspot.  Know which?  Filed a bug
report?

In CPython, we just use the address of an object's header, and as CPython
never moves an object's header in memory, the good stuff follows trivially.
Don't know what JPython tries to do, but it's bound to be harder there (as
Java can move memory around).




From bckfnn@worldonline.dk  Thu Jun 29 17:43:09 2000
From: bckfnn@worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 16:43:09 GMT
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>
Message-ID: <395b79a7.31704869@smtp.worldonline.dk>

[Tim]

>So it's possible there for one of these be true:
>
>    id(x) == id(y) and x is not y
>    id(x) != id(x)
>
>?

Yes, the first.


d = {}
cnt = 0

for i in xrange(100000):
    s = "test" + `i`
    j = id(s)
    if d.has_key(j):
        cnt = cnt + 1
    d[j] = s

print cnt, "failures"

Will print 500+ failures when run by JPython & JDK1.3 on win2k.

>Then that's a bug in JPython or hotspot.  Know which?

JPython.

> Filed a bug report?

Years ago <wink>:
  http://www.python.org/jpython-bugs/incoming?id=118

>In CPython, we just use the address of an object's header, and as CPython
>never moves an object's header in memory, the good stuff follows trivially.
>Don't know what JPython tries to do, but it's bound to be harder there (as
>Java can move memory around).

That is also my guess. I cannot see what we can do about it, except inform
users that not all python platform behave exactly the same. Which is why I
brought it up.

regards,
finn


From trentm@activestate.com  Thu Jun 29 17:42:56 2000
From: trentm@activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 09:42:56 -0700
Subject: [Python-Dev] arraymodule still broken?
In-Reply-To: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid>
References: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid>
Message-ID: <20000629094256.A21926@activestate.com>

On Thu, Jun 29, 2000 at 12:21:22PM +0200, Fredrik Lundh wrote:
> just checked everything out and rebuilt, the exceptions
> problem sure disappeared, but I still get this error:
> 
> >>> import array
> >>> array.array("H", [60000])
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> OverflowError: signed short integer is greater than maximum
> 
> second opinion, anyone?
> 

I think this is because we are in the middling state where all of my patches
have not gotten in yet. I say this because this is what I get with my version
that has all of my patches applied:

Python 1.6a2 (#1, Jun 29 2000, 09:28:15)  [GCC egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> import array
>>> array.array("H", [60000])
array('H', [60000])
>>>


Specifically, I haven't looked for the issue. Is it alright if I look at this
this weekend?


Trent


-- 
Trent Mick
trentm@activestate.com


From trentm@activestate.com  Thu Jun 29 17:53:43 2000
From: trentm@activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 09:53:43 -0700
Subject: [Python-Dev] build problems under MSVC 5.0
In-Reply-To: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid>
References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid>
Message-ID: <20000629095343.B21926@activestate.com>

On Thu, Jun 29, 2000 at 12:07:42PM +0200, Fredrik Lundh wrote:
> Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier
> Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv'
> Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier
> Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type'
> Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier
> 
This is a result of one of my patches. I was using MSVC 6.0, where INT_PTR is
defined as you would expect. I did not realize that it was new to that
version of the headers.

BTW, INT_PTR, UINT_PTR, etc are the standard defines that I saw Microsoft
suggesting in their Win64 docs. I don't like those names, because they are
not portable. I should have used the (ANSI?) equivalents: intptr_t,
uintptr_t. In fact, I *did* use those in some of my patches where the code
portability was required (as obviously it is not in thread_*nt*.h).


> in MSVC 5.0, _beginthread returns an "unsigned long" (this is also
> how it's documented in MSDN).

Yup. And in the Win64 headers _beginthread returns uintptr_t, which makes me
wonder why I picked INT_PTR.


> 
> I suggest changing the declaration in thread_nt.h to:
> 
> #if _MSC_VER >= 1200
>  INT_PTR rv;
> #else
>  unsigned long rv;
> #endif
> 

As I said above, I acknowledge that I should not have used INT_PTR.
Win32: unsigned long _beginthread()
Win64: uintptr_t _beginthread()

I think (am I wrong?) to generalize that the intention for both Win32 and
Win64 is to have _beginthread return an unsigned pointer-sized integer: hence
uintptr_t.

This would eliminate the #ifdef but would require a typedef for uintptr_t on
Win32. This can be done in PC/config.h (I already did this for intptr_t,
because I needed *that* elsewhere.) Does this also need to be generalized to
typedef uintptr_t whereever it is not defined, i.e. in the autoconf files.

I can look at this this weekend, if that is soon enough.



> on the other hand, the same docs claim that it returns -1 on errors.
> doesn't exactly look like an unsigned long to me, but that's another
> story...
> 

Yes, strange.



Trent

-- 
Trent Mick
trentm@activestate.com


From Fredrik Lundh" <effbot@telia.com  Thu Jun 29 18:07:02 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 19:07:02 +0200
Subject: [Python-Dev] build problems under MSVC 5.0
References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> <20000629095343.B21926@activestate.com>
Message-ID: <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid>

trent wrote:
> I think (am I wrong?) to generalize that the intention for both Win32 =
and
> Win64 is to have _beginthread return an unsigned pointer-sized =
integer: hence
> uintptr_t.
>=20
> This would eliminate the #ifdef but would require a typedef for =
uintptr_t on
> Win32. This can be done in PC/config.h (I already did this for =
intptr_t,
> because I needed *that* elsewhere.) Does this also need to be =
generalized to
> typedef uintptr_t whereever it is not defined, i.e. in the autoconf =
files.
>=20
> I can look at this this weekend, if that is soon enough.

I suggest checking in the #ifdef as a stopgap measure, if you
promise to come up with the right thing (whatever that is) in
time for 1.6 final.

Should I go ahead and check it in?

</F>



From tpeters@beopen.com  Thu Jun 29 18:15:08 2000
From: tpeters@beopen.com (Tim Peters)
Date: Thu, 29 Jun 2000 13:15:08 -0400
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <395B5030.C0F08E82@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com>

[MAL]
> I'm getting loads of lock messages during CVS checkins recently.
> Is this due to overload ? (I wonder why anoncvs access causes
> locking at all -- there is no write access so why should there
> be file locking ?):

IIRC, CVS maintains the illusion of being a multi-user system by using
per-*directory* locks.  That means it gives you the warm fuzzy feeling that
you're being protected against (e.g.) getting an inconsistent snapshot while
someone else is committing, but in fact you're not protected at all
(inter-directory).  It locks per-directory to ensure the integrity of its
own data files, but users are subject to the luck of the draw.

Note that Perl is maintained under (the commercial, alas) Perforce, which is
one of the few SCMs to take multi-developer multi-directory issues
seriously.

So the good news is that when you see a CVS lock gripe, that means CVS is
protecting itself from corruption.  The bad news is that if we used a system
that protected *us* against inconsistencies too, we'd probably see lock
gripes even more often.




From gmcm@hypernet.com  Thu Jun 29 18:19:51 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Thu, 29 Jun 2000 13:19:51 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>
References: <395b1528.5978476@smtp.worldonline.dk>
Message-ID: <1249823239-44851587@hypernet.com>

[Finn Bock]
> > This property of id() does not hold in JPython. When used with
> > hotspot, id() is not unique.
[Tim] 
> So it's possible there for one of these be true:
> 
>     id(x) == id(y) and x is not y
>     id(x) != id(x)
> 
> ?  Then that's a bug in JPython or hotspot.  Know which?  Filed a
> bug report?

Oh, you silly boy. There are (by definition) no bugs in hotspot.

it's-only-'cause-Guido's-a-weenie-that-Python-has-'em-ly y'rs

- Gordon


From tpeters@beopen.com  Thu Jun 29 18:44:45 2000
From: tpeters@beopen.com (Tim Peters)
Date: Thu, 29 Jun 2000 13:44:45 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <395b79a7.31704869@smtp.worldonline.dk>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>

[Finn Bock, says id() is buggy under JPython]

[Tim]
>> Filed a bug report?

[Finn]
> Years ago <wink>:
>   http://www.python.org/jpython-bugs/incoming?id=118

>> In CPython, we just use the address of an object's header, and as CPython
>> never moves an object's header in memory, the good stuff follows
>> trivially.  Don't know what JPython tries to do, but it's bound to be
>> harder there (as Java can move memory around).

> That is also my guess. I cannot see what we can do about it, except
> inform users that not all python platform behave exactly the same. Which
> is why I brought it up.

Well, neither Java's hashCode nor identityHashCode are correct
implementations of Python's id(), so JPython's id() is simply wrong.  I
don't know anything about the internals of JPython.  If there's a "choke
point" for allocating Python objects, the quickest way out may be to add a
write-once "id" field to each Python object under JPython, and simply fill
it with an integer that's (safely) incremented by 1 on each allocation.

Python doesn't guarantee you'll get the *same* id(x) across implementations,
or even across runs under a single implementation, so the implementations of
id() in CPython and JPython can do entirely different things.  They have to
meet the promises in the Python docs, though, and JPython's currently
doesn't.





From Fredrik Lundh" <effbot@telia.com  Thu Jun 29 18:51:32 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 19:51:32 +0200
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org>
Message-ID: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>

greg wrote:
> I think you are being paranoid :-)
>=20
> Consider that this same issue applies to all 5900 projects and 38000
> developers at SourceForge. VA Linux has a brand identity entirely =
built on
> the trust and support of the Linux (and Open Source) communities. If =
they
> blow away that trust, they are simply screwed.

on the other hand, lots of people thought that dejanews
would store usenet postings forever...

http://salon.com/tech/log/2000/06/20/deja/index.html

</F>



From Ka-Ping Yee <pingster@ilm.com>  Thu Jun 29 18:47:13 2000
From: Ka-Ping Yee <pingster@ilm.com> (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 10:47:13 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.SGI.3.96.1000629104223.621134m-100000@happy>

On Thu, 29 Jun 2000, Guido van Rossum wrote:
> 
> Argh!  An inappropriate side effect of Ping's cleanup -- thanks for
> catching this.  Apparently Ping didn't do a CVS update before
> generating his diffs.

My apologies!  I'm pretty sure i did an update, but i must have
left too long a gap during which 1.2 got checked in.  You'd think
somehow a version-control system would have noticed the inconsistency
between ancestor versions...

Anyway, very sorry for the trouble.  Glad it appears to be cleared
up now.


-- ?!ng



From Fredrik Lundh" <effbot@telia.com  Thu Jun 29 18:56:02 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 19:56:02 +0200
Subject: [Python-Dev] id() on Win64
References: <20000628160743.A16262@acs.ucalgary.ca>
Message-ID: <027101bfe1f3$4d478ae0$f2a6b5d4@hagrid>

neil wrote:
> [Greg Stein]
> >Strictly speaking: the Long only occurs on Win64 platforms.
> >
> >I would guess that it is also possible on say, an Alpha running
> >Linux.  Presuming that has 64-bit pointers(?).
>=20
> I think the Alpha is okay. The problem is strange type models
> were int is 32 bits and pointers are 64.  AFAIK, the Alpha uses
> 64 bits for both.

is this true for linux alpha too?

it's definitely true for tru64; we've been using python
extensively on that platform since 1995:
http://www.smhi.se/weather/satelitbilder/satellitbilder.htm
(in swedish, but I suppose you all can figure out what
it is anyway ;-)

</F>



From gward@mems-exchange.org  Thu Jun 29 18:55:25 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 13:55:25 -0400
Subject: [Python-Dev] Test results of linuxaudiodev.c
Message-ID: <20000629135525.A5221@ludwig.cnri.reston.va.us>

Hi --

here are results from testing linuxaudiodev from the latest CVS Python
1.6.  This is on a Dell Dimension with on-board audio hardware: the
Yamaha YMF724 chipset.  I'm using the ALSA 0.5.8a driver (the latest as
of a week or two ago, and the only one that supports the YMF724).

Bottom line: the test sound plays, but it sounds horrible when played by 
linuxaudiodev.  If I do this:

  $ play Lib/test/audiotest.au

then Cardinal Fang comes through loud and clear.  ("play" is a shell
script wrapper for "sox", writing to /dev/dsp.)  But if I do this:

  $ ./python Lib/test/regrtest.py test_linuxaudiodev

he's still audible (and at the same volume), but very scratchy.  Sounds
kind of like a very over-driven amp, or like a cheap car radio that
somebody attacked with a knife.

[...some time passes...]

OK, I just tried it on another machine, also a Dell but with a different
sound chip: the Crystal CS4232.  I'm pretty sure this one is using the
OSS drivers included with the kernel, which is probably the second most
important difference after the chipset itself.  Bottom line: it also
sounds horrible.

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367


From bwarsaw@beopen.com  Thu Jun 29 18:57:27 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 13:57:27 -0400 (EDT)
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
References: <395b79a7.31704869@smtp.worldonline.dk>
 <LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>
Message-ID: <14683.36359.864478.495915@anthem.concentric.net>

>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:

    TP> Well, neither Java's hashCode nor identityHashCode are correct
    TP> implementations of Python's id(), so JPython's id() is simply
    TP> wrong.  I don't know anything about the internals of JPython.
    TP> If there's a "choke point" for allocating Python objects, the
    TP> quickest way out may be to add a write-once "id" field to each
    TP> Python object under JPython, and simply fill it with an
    TP> integer that's (safely) incremented by 1 on each allocation.

    TP> Python doesn't guarantee you'll get the *same* id(x) across
    TP> implementations, or even across runs under a single
    TP> implementation, so the implementations of id() in CPython and
    TP> JPython can do entirely different things.  They have to meet
    TP> the promises in the Python docs, though, and JPython's
    TP> currently doesn't.

I can't generate patches right now, but what you need to change is in
__builtin__.java, the id() function.  It should probably call
object.id() which would fill in the monotonically incrementing id as
Tim suggestions.

One question is what to do about Java proxies.  Currently built-in
id() returns the identityHashCode() of the proxy object, which is just
an Object.  I'm not sure sticking the id in the wrapper is the right
thing or not.

-Barry


From Fredrik Lundh" <effbot@telia.com  Thu Jun 29 19:18:26 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 20:18:26 +0200
Subject: [Python-Dev] Re: sourceforge data (was: Let's use the SourceForge Patch Manager)
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> <20000629110557.W29590@lyra.org>
Message-ID: <02d901bfe1f6$720ca920$f2a6b5d4@hagrid>

greg wrote:
> > on the other hand, lots of people thought that dejanews
> > would store usenet postings forever...
>=20
> Different problem space. They weren't holding people's data.

well, they dropped a few thousand eff-bot postings ;-)

> Worrying about it is a useless exercise, IMO.

well, I'm not worried.  but in the internet universe, strange
things happen all the time...

(checked out http://www.fuckedcompany.com/ lately?)

...

btw, has anyone checked what's in:
http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz=20

(with ping times somewhere around one second, it's too
large for me to check out...)

</F>



From Fredrik Lundh" <effbot@telia.com  Thu Jun 29 19:05:34 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 20:05:34 +0200
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <20000628113505.C15643@ludwig.cnri.reston.va.us>
Message-ID: <02cd01bfe1f4$a271cca0$f2a6b5d4@hagrid>

greg wrote:


> On 28 June 2000, Fredrik Lundh said:
> > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt
> >=20
> > unfortunately, his "What is it with those Python fucks anyway" talk
> > isn't posted... ;-)
>=20
> But the "Conclusion" of his "Lies We Tell" talk:
>=20
>    Perl sucks. Use Python.
>=20
> Presumably tongue-in-cheek, but you never know...

note that all lies he mentioned earlier in that talk
was quoted; this one wasn't.  in other words, it's
a fact.  but we already know that, don't we ;-)

</F>



From bwarsaw@beopen.com  Thu Jun 29 19:56:52 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 14:56:52 -0400 (EDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
References: <20000629135525.A5221@ludwig.cnri.reston.va.us>
Message-ID: <14683.39924.477408.233069@anthem.concentric.net>

>>>>> "GW" == Greg Ward <gward@mems-exchange.org> writes:

    GW> then Cardinal Fang comes through loud and clear.  ("play" is a
    GW> shell script wrapper for "sox", writing to /dev/dsp.)  But if
    GW> I do this:

    GW>   $ ./python Lib/test/regrtest.py test_linuxaudiodev

    GW> he's still audible (and at the same volume), but very
    GW> scratchy.  Sounds kind of like a very over-driven amp, or like
    GW> a cheap car radio that somebody attacked with a knife.

I don't even get that.  play works fine for me too, but on this Dell
Optiplex GX110 with unknown sound chip set, test_linuxaudiodev gives
me nothing.

-Barry


From gstein@lyra.org  Thu Jun 29 19:05:57 2000
From: gstein@lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 11:05:57 -0700
Subject: [Python-Dev] sourceforge data (was: Let's use the SourceForge Patch Manager)
In-Reply-To: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>; from effbot@telia.com on Thu, Jun 29, 2000 at 07:51:32PM +0200
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>
Message-ID: <20000629110557.W29590@lyra.org>

On Thu, Jun 29, 2000 at 07:51:32PM +0200, Fredrik Lundh wrote:
> greg wrote:
> > I think you are being paranoid :-)
> > 
> > Consider that this same issue applies to all 5900 projects and 38000
> > developers at SourceForge. VA Linux has a brand identity entirely built on
> > the trust and support of the Linux (and Open Source) communities. If they
> > blow away that trust, they are simply screwed.
> 
> on the other hand, lots of people thought that dejanews
> would store usenet postings forever...

Different problem space. They weren't holding people's data.

If SourceForge were ever to close, then I have 100% faith that they would
make sure to provide a way for everybody to get their data off the machines.

Worrying about it is a useless exercise, IMO.

Cheers,
-g

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


From guido@beopen.com  Thu Jun 29 20:05:11 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 14:05:11 -0500
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: Your message of "Thu, 29 Jun 2000 13:15:08 -0400."
 <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com>
Message-ID: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>

> [MAL]
> > I'm getting loads of lock messages during CVS checkins recently.
> > Is this due to overload ? (I wonder why anoncvs access causes
> > locking at all -- there is no write access so why should there
> > be file locking ?):
> 
> IIRC, CVS maintains the illusion of being a multi-user system by using
> per-*directory* locks.  That means it gives you the warm fuzzy feeling that
> you're being protected against (e.g.) getting an inconsistent snapshot while
> someone else is committing, but in fact you're not protected at all
> (inter-directory).  It locks per-directory to ensure the integrity of its
> own data files, but users are subject to the luck of the draw.

Yes, that's how it works...

> Note that Perl is maintained under (the commercial, alas) Perforce, which is
> one of the few SCMs to take multi-developer multi-directory issues
> seriously.

We tried Perforce at CNRI.  It's really neat, but somehow it was
lacking some stuff we were used to and we never converted.

Note that Perforce is free for open source projects -- at least at the
time it was.  (CNRI paid a license fee, but that was just an
expression of CNRI's reluctance against free software. :-)

There's also bitkeeper.  It stayed in beta so long that we gave up
(and they have a weird license) -- but it's out of beta since May 4:
see http://www.bitkeeper.com/.  But there's no immediate download!
You must sign up and they send you instructions in the mail...

> So the good news is that when you see a CVS lock gripe, that means CVS is
> protecting itself from corruption.  The bad news is that if we used a system
> that protected *us* against inconsistencies too, we'd probably see lock
> gripes even more often.

Well, the implementation could save the previous consistent version
and give you that while an update was under way...  There are other
ways to protect against inconsistencies.  But I'm not sure that you
always *want* this -- as a system grows, it's better to be able to
deal with inconsistencies than to try to avoid them (and have the
world blow up in your face when the avoidance fails).

Anyway, I submitted a service request to have the lock in the Lib/test
lock removed.  (Apparently some process didn't clear up its lock.
That's rare, but sometimes it happens.)  It's been fixed now, so
checkins in the Lib/test directory should move forward again.

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


From bckfnn@worldonline.dk  Thu Jun 29 20:15:45 2000
From: bckfnn@worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 19:15:45 GMT
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>
Message-ID: <395b9f71.41379240@smtp.worldonline.dk>

[Tim]

>Well, neither Java's hashCode nor identityHashCode are correct
>implementations of Python's id(), so JPython's id() is simply wrong. 

I agree.

>I don't know anything about the internals of JPython.  If there's a "choke  
>point" for allocating Python objects, 

The constructor of PyObject should do nicely.

>the quickest way out may be to add a
>write-once "id" field to each Python object under JPython, and simply fill
>it with an integer that's (safely) incremented by 1 on each allocation.

Properly have to be a java long to avoid overflowing.

>Python doesn't guarantee you'll get the *same* id(x) across implementations,
>or even across runs under a single implementation, so the implementations of
>id() in CPython and JPython can do entirely different things.  They have to
>meet the promises in the Python docs, though, and JPython's currently
>doesn't.

I haven't considered it to be so important. It is possible to fix the std
modules so it doesn't cause problems (as is done in cPickle.java). 

[Barry]

>One question is what to do about Java proxies.  Currently built-in
>id() returns the identityHashCode() of the proxy object, which is just
>an Object.  I'm not sure sticking the id in the wrapper is the right
>thing or not.

It properly isn't. New wrappers can be created for the same object. F.ex
when a java object is passed from python into java code and returned back
into python, two wrappers will exists for the same java object. Since these
two wrappers represent the same object they should (as it does now) return
the same id() value.

regards,
finn


From bwarsaw@beopen.com  Thu Jun 29 20:23:48 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 15:23:48 -0400 (EDT)
Subject: [Python-Dev] Re: sourceforge data (was: Let's use the SourceForge Patch Manager)
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>
 <395A32FD.D3C58B23@prescod.net>
 <20000628173424.H29590@lyra.org>
 <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>
 <20000629110557.W29590@lyra.org>
 <02d901bfe1f6$720ca920$f2a6b5d4@hagrid>
Message-ID: <14683.41540.530581.459708@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <effbot@telia.com> writes:

    FL> btw, has anyone checked what's in:
    FL> http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz 

I suck down nightly copies of that file and the corresponding Mailman
tarball.  I looked at them when I first set up my script, but haven't
checked them lately.

-Barry


From nascheme@enme.ucalgary.ca  Thu Jun 29 21:02:02 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 29 Jun 2000 14:02:02 -0600
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com> <200006291905.OAA17265@cj20424-a.reston1.va.home.com>
Message-ID: <20000629140201.A20446@acs.ucalgary.ca>

I recently made the conversion from CVS to PRCS.  I like PRCS
much better.  It is easier to use, implemented indepentant of
rcs, faster, more flexible and has versioned project meta-data.
Branching and merging is much simpiler than CVS.  Operations on
project versions are atomic.  Renaming and moving files is easy.
It is well documented.

Unfortunately version 1 does not support distributed
repositories.  Josh has informed my that version to is coming
(hopefully this year) and will support distributed repositories.

For Python I don't think that a multi-user version control system
is strictly necessary anyhow.  The PRCS repository could be made
available via rsync and a process could be setup for checking
patches into the central repository.  It should actually be more
efficient than the current CVS setup.

I just looked at the webpage and the beta for 2.0 is out:

    http://www.xcf.berkeley.edu/~jmacd/prcs.html

If PythonLabs is interested in using PRCS I will even volunteer
to make sure those Windows weenies have a good port. :)

  Neil



From jeremy@beopen.com  Thu Jun 29 21:40:14 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 29 Jun 2000 16:40:14 -0400 (EDT)
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <20000629140201.A20446@acs.ucalgary.ca>
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com>
 <200006291905.OAA17265@cj20424-a.reston1.va.home.com>
 <20000629140201.A20446@acs.ucalgary.ca>
Message-ID: <14683.46126.19856.447975@bitdiddle.concentric.net>

I was just looking at Josh's work last week, and thought it looks
quite interesting.  Despite my interest, I don't expect we would use
it for Python unless SourceForge adopted it.  We moved the Python CVS
tree to SourceForge to avoid maintaing a large installation of
software development/management tools.

Jeremy


From klm@digicool.com  Thu Jun 29 21:53:21 2000
From: klm@digicool.com (Ken Manheimer)
Date: Thu, 29 Jun 2000 16:53:21 -0400 (EDT)
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEBPGHAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>

On Thu, 29 Jun 2000, Tim Peters wrote:

> > ...
> > Hmm. Is there a good place to start listing these todo items?
> 
> Not that I know of.  "Group whiteboards" and shared journals etc are darned
> useful, though.

Wiki = Group whiteboard

Zope could do a lot of this stuff well.  As is, ZWiki offers some
organizational features.  I've held off on pushing them because they're
still baking - things like change notifications, discretion about change
privileges, versions (with differences, based on your ndiff.py), etc are
coming soonish.  (Exactly how soonish is hard to say, the way time and
more direct business obligations are - but this stuff actually is
important to us, we're using them a lot for collaboration, and need for
the dynamics to scale...)

I also have the feeling that our tracker would be good for patch
management - except, i don't really know what the requirements are, there,
and once again, tracker only gives notifications via email, it doesn't
take input that way.

Anyway, to see leads on both zwikis and tracker, see:

  http://www.zope.org/Members/klm/TrackerWiki

Oh, and it would be easy to set up a wiki for python dev on zope.org
somewhere - i could put it in my account, or we could situate one more
centrally, in a storage that's never packed, so the version history is
maintained.  Or any of you could get a zope.org membership and set some
up, yerselves.  Or set up a zope somewhere - it'd be !cool! if sourceforge
were willing...

Ken
klm@zope.org



From klm@digicool.com  Thu Jun 29 22:25:55 2000
From: klm@digicool.com (Ken Manheimer)
Date: Thu, 29 Jun 2000 17:25:55 -0400 (EDT)
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>
Message-ID: <Pine.LNX.4.21.0006291723370.4495-100000@korak.digicool.com>

On Thu, 29 Jun 2000, Ken Manheimer wrote:

> Wiki = Group whiteboard
> [...]
> Oh, and it would be easy to set up a wiki for python dev on zope.org
> somewhere - i could put it in my account, or we could situate one more

http://www.zope.org/Members/klm/PythonDev/TodoLists

There's nothing else of substance there, but anyone who's a member at
zope.org can edit and add pages...

Ken



From guido@python.org  Fri Jun 30 00:25:09 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 29 Jun 2000 18:25:09 -0500
Subject: [Python-Dev] New PythonLabs site revealed!
Message-ID: <200006292325.SAA19744@cj20424-a.reston1.va.home.com>

Today, without much fanfare, we opened the new PythonLabs website.
The design is by BeOpen's creative Director, Jun Simmons.  Thanks to
Jeremy Hylton, who did most of the actual HTML editing to get our
contents in place.

The new beta will be released via this site.

And since you python-dev folks will find this out through my checkins
anyway, let this be an advance warning that it will be called Python
2.0.  Here's my explanation for the version bump (soon to be checked
in to README):

"""
While Pythoneers have grown fond of Python's exceedingly slow version
incrementing, that same quality makes parts of the rest of the world
think Python is barely out of its first alpha test.  Especially
enterprise customers are often fearful of anything that's version 1.x!
The new version number also clearly marks Python's departure from
CNRI.

Previously, the version number 2.0 was associated with a mythical and
elusive incompatible future release.  That release (still ways off,
and not as incompatible as people fear!) is now referred to as Python
3000.
"""

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


From mwh21@cam.ac.uk  Thu Jun 29 23:53:39 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 29 Jun 2000 23:53:39 +0100
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: Greg Ward's message of "Thu, 29 Jun 2000 13:55:25 -0400"
References: <20000629135525.A5221@ludwig.cnri.reston.va.us>
Message-ID: <m33dlw85fw.fsf@atrus.jesus.cam.ac.uk>

Greg Ward <gward@mems-exchange.org> writes:

> Hi --
> 
> here are results from testing linuxaudiodev from the latest CVS Python
> 1.6.  This is on a Dell Dimension with on-board audio hardware: the
> Yamaha YMF724 chipset.  I'm using the ALSA 0.5.8a driver (the latest as
> of a week or two ago, and the only one that supports the YMF724).
> 
> Bottom line: the test sound plays, but it sounds horrible when played by 
> linuxaudiodev.  If I do this:
> 
>   $ play Lib/test/audiotest.au
> 
> then Cardinal Fang comes through loud and clear.  ("play" is a shell
> script wrapper for "sox", writing to /dev/dsp.)  But if I do this:
> 
>   $ ./python Lib/test/regrtest.py test_linuxaudiodev
> 
> he's still audible (and at the same volume), but very scratchy.  Sounds
> kind of like a very over-driven amp, or like a cheap car radio that
> somebody attacked with a knife.
> 
> [...some time passes...]
> 
> OK, I just tried it on another machine, also a Dell but with a different
> sound chip: the Crystal CS4232.  I'm pretty sure this one is using the
> OSS drivers included with the kernel, which is probably the second most
> important difference after the chipset itself.  Bottom line: it also
> sounds horrible.

Just tried that here; ouch.  I have a Dell Dimension XPS D233 (which
has an on-board Yamaha chipset - the OPL2, I believe).  I use the
sound driver that comes with the redhat built kernel (which is the OSS
one I think).

$ play audiotest.au

sounds fine,

$  ../../../build/python regrtest.py test_linuxaudiodev.py \
test_linuxaudiodev

sounds horrible; it sounds like it's being rammed through at far too
high a volume, but playing with the PCM or volume sliders in gmix has
no appreciable effect on the quality.  This suggests somewhat that the
problem lies in linuxaudiodev.c, doesn't it?

Is this stuff, like, documented anywhere?  I can't find any helpful
manpages...

I presume this module must work better than this for some people?

Cheers,
M.




From guido@python.org  Fri Jun 30 01:20:15 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 29 Jun 2000 19:20:15 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: Your message of "Thu, 29 Jun 2000 16:05:01 MST."
 <200006292305.QAA11929@slayer.i.sourceforge.net>
References: <200006292305.QAA11929@slayer.i.sourceforge.net>
Message-ID: <200006300020.TAA21877@cj20424-a.reston1.va.home.com>

> On second thought, first try for _winreg, and then winreg.  Only if both
> fail do we try for win32api/win32con.  If *those* both fail, then we don't
> have registry access.  Phew!

Is this smart?  Doesn't the new winreg have a very different I/F than
the old one?

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


From pingster@ilm.com  Fri Jun 30 00:24:28 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 16:24:28 -0700 (PDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: <m33dlw85fw.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <Pine.SGI.3.96.1000629162303.621134p-100000@happy>

On 29 Jun 2000, Michael Hudson wrote:
> $ play audiotest.au
> 
> sounds fine,
> 
> $  ../../../build/python regrtest.py test_linuxaudiodev.py \
> test_linuxaudiodev
> 
> sounds horrible; it sounds like it's being rammed through at far too
> high a volume

Sounds like u-law to me.  linuxaudiodev.c selects /dev/dsp by
default, which accepts raw data, not .au format.

Try setting the environment variable AUDIODEV to /dev/audio
before running the test script.  Does that work any better?


-- ?!ng



From fdrake@beopen.com  Fri Jun 30 00:29:42 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 19:29:42 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: <200006300020.TAA21877@cj20424-a.reston1.va.home.com>
References: <200006292305.QAA11929@slayer.i.sourceforge.net>
 <200006300020.TAA21877@cj20424-a.reston1.va.home.com>
Message-ID: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>

Greg Ward wrote in a checkin message:
 > On second thought, first try for _winreg, and then winreg.  Only if both
 > fail do we try for win32api/win32con.  If *those* both fail, then we don't
 > have registry access.  Phew!

Guido van Rossum writes on python-dev:
 > Is this smart?  Doesn't the new winreg have a very different I/F than
 > the old one?

  No, this is bad.  It *will* break with winreg; if _winreg isn't
available, it should use the win32api/win32con/whatever stuff; it's a
Python 1.5.2 interpreter at that point.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From skip@mojam.com (Skip Montanaro)  Thu Jun 29 23:22:18 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 29 Jun 2000 17:22:18 -0500 (CDT)
Subject: [Python-Dev] Mysterious SF message...
Message-ID: <14683.52250.789900.357275@beluga.mojam.com>

I just submitted a patch for lib/libatexit.tex.  In the response page it
displayed a list of patches, then the following cryptic message:

    Patch Uploaded Successfully Added Patch Could Not Send Patch Update

Any idea what that means?

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."


From tpeters@beopen.com  Fri Jun 30 00:32:42 2000
From: tpeters@beopen.com (Tim Peters)
Date: Thu, 29 Jun 2000 19:32:42 -0400
Subject: [Python-Dev] Controversial patch (cmath)
Message-ID: <LNBBLJKPBEHFEDALKOLCAEFBGHAA.tim_one@email.msn.com>

I just voted to accept a patch that's broken.  If you want to argue it, be
my guest, but I'm out of it now <wink>.

Here's the patch:

https://sourceforge.net/patch/?func=detailpatch&patch_id=100651&group_id=547
0

Here's my comment (also available on that page):

Accepted (but reluctantly; see below), and assigned back to Guido for
checkin.

cmathmodule is not production quality, and this patch isn't either, but its
asinh and acosh are better than what's there now.

The author avoided some of the numerical foolishness in the original, but
didn't avoid all of it.  For example, it's harder to get asinh to do
something ridiculous now than it was before, but still possible:

>>> cmath.acosh(1e200)
(461.210165779+0j)
>>> cmath.asinh(1e200)
(1.#INF+0j)
>>>

asinh should have returned something approximately equal to what acosh
returned.

That may not be the patch's problem, though!  I suspect that's due to one of
the module's other functions that's too naive about the limits of floating
point.  In any case, it is much easier to provoke the *current* cmath
functions into cases like this one.

Another possible problem has to do with principal values.  My reference
books are in storage, so about the best I can do right now is compare what
this code does to Macsyma (which I have on my laptop).  The acosh in this
patch often returns the negative of what Macysma computes.  For example,

>>> cmath.acosh(-1-1j)
(1.06127506191-2.23703575929j)
>>>

Macsyma returns the negation of that.  On the other hand, the *original*
acosh doesn't agree with Macsyma on some signs where this acosh does.  So
call this one a wash.

I may have mentioned this before <wink>:  robust math libraries are
extremely difficult to get right.  It would take several months to write a
production-quality cmath module from scratch, which is several months more
than were devoted to Python's current cmath <wink>.  I vote we check this in
anyway (since it *is*, overall, an improvement), and look into borrowing
some other language's complex math library later (note in particular that
C9X adds complex numbers and these functions on them, so if we sit on our
asses long enough, we can inherit libc's!).




From mwh21@cam.ac.uk  Fri Jun 30 00:33:37 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 30 Jun 2000 00:33:37 +0100
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:24:28 -0700 (PDT)"
References: <Pine.SGI.3.96.1000629162303.621134p-100000@happy>
Message-ID: <m3ya3o6p0u.fsf@atrus.jesus.cam.ac.uk>

Ka-Ping Yee <pingster@ilm.com> writes:

> On 29 Jun 2000, Michael Hudson wrote:
> > $ play audiotest.au
> > 
> > sounds fine,
> > 
> > $  ../../../build/python regrtest.py test_linuxaudiodev.py \
> > test_linuxaudiodev
> > 
> > sounds horrible; it sounds like it's being rammed through at far too
> > high a volume
> 
> Sounds like u-law to me.  linuxaudiodev.c selects /dev/dsp by
> default, which accepts raw data, not .au format.
> 
> Try setting the environment variable AUDIODEV to /dev/audio
> before running the test script.  Does that work any better?

That's the ticket.  "play" and the test now sound identical, modulo
some pops & cracks at the start and end of the test.  I presume what
follows is thus a good idea?

Index: test_linuxaudiodev.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_linuxaudiodev.py,v
retrieving revision 1.1
diff -u -r1.1 test_linuxaudiodev.py
--- test_linuxaudiodev.py       2000/06/10 04:22:57     1.1
+++ test_linuxaudiodev.py       2000/06/29 23:32:55
@@ -17,4 +17,6 @@
 def test():
     play_sound_file(findfile('audiotest.au'))
 
+os.environ["AUDIODEV"] = "/dev/audio"
+
 test()

Cheers,
M.



From Vladimir.Marangozov@inrialpes.fr  Fri Jun 30 00:38:19 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 01:38:19 +0200 (CEST)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <200006292325.SAA19744@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 29, 2000 06:25:09 PM
Message-ID: <200006292338.BAA07798@python.inrialpes.fr>

Guido van Rossum wrote:
> 
> Today, without much fanfare, we opened the new PythonLabs website.
> The design is by BeOpen's creative Director, Jun Simmons.  Thanks to
> Jeremy Hylton, who did most of the actual HTML editing to get our
> contents in place.
> 
> The new beta will be released via this site.
> 
> And since you python-dev folks will find this out through my checkins
> anyway, let this be an advance warning that it will be called Python
> 2.0.  Here's my explanation for the version bump (soon to be checked
> in to README):

Guido van Rossum just won't stop surprising us! :-) Witness the three
shocking news that arrived in one day: (1) very strict self-discipline
about "long-term" TODO's full of short-term and less than medium-term
topics that were very logically left behind, (2) major version number
revision one day before the official beta-cycle, (3) a new PythonLabs
corporate-style Web site with a flashing color palette & tutti quanti.
I am really (positively) amazed! :-)

spanish-inquisition-is-all-we-deserve-<wink>-ly y'rs

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From fdrake@beopen.com  Fri Jun 30 00:39:48 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 19:39:48 -0400 (EDT)
Subject: [Python-Dev] documentation patch guidelines
Message-ID: <14683.56900.433607.125111@cj42289-a.reston1.va.home.com>

  I've updated the patch guidelines for documentation to match other
patches, and added a patch category for documentation.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From pingster@ilm.com  Fri Jun 30 00:46:32 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 16:46:32 -0700 (PDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: <Pine.SGI.3.96.1000629162303.621134p-100000@happy>
Message-ID: <Pine.SGI.3.96.1000629163112.621134r-100000@happy>

On Thu, 29 Jun 2000, Ka-Ping Yee wrote:
> Try setting the environment variable AUDIODEV to /dev/audio
> before running the test script.  Does that work any better?

Even if that works, i realize that's not the way the interface
was intended to be used.  To play an AU file, the routine should
look something like this (not tested, as i don't have a working
Linux box)...

def play_au_file(path):

    fp = open(path, "r")

    # Read the .au file header.
    header = fp.read(24)
    hdrsize, length, encoding, rate, channels = \
        struct.unpack(">xxxxiiiii", header)
    fp.read(hdrsize - 24)
    
    data = fp.read()
    fp.close()

    # Set the data format according to the code in the .au header.
    if encoding == 1:
        size, fmt = 8, linuxaudiodev.AFMT_MU_LAW
    elif encoding == 2:
        size, fmt = 8, linuxaudiodev.AFMT_S8
    elif encoding == 3:
        size, fmt = 16, linuxaudiodev.AFMT_S16_BE
    else:
        raise "audio format not supported"
        
    dsp = linuxaudiodev.open("w")
    dsp.setparameters(rate, size, channels, fmt)
    dsp.write(data)
    dsp.close()


-- ?!ng

Explicit hoc totum;            This completes the whole;
Pro Christo da mihi potum.     For Christ's sake give me a drink.
    -- from the colophon of a 12th-century copyist



From nascheme@enme.ucalgary.ca  Fri Jun 30 01:00:37 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 29 Jun 2000 18:00:37 -0600
Subject: [Python-Dev] Mysterious SF message...
In-Reply-To: <14683.52250.789900.357275@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 05:22:18PM -0500
References: <14683.52250.789900.357275@beluga.mojam.com>
Message-ID: <20000629180037.A22566@acs.ucalgary.ca>

On Thu, Jun 29, 2000 at 05:22:18PM -0500, Skip Montanaro wrote:
> 
> I just submitted a patch for lib/libatexit.tex.  In the response page it
> displayed a list of patches, then the following cryptic message:
> 
>     Patch Uploaded Successfully Added Patch Could Not Send Patch Update
> 
> Any idea what that means?

SourceForge sucks?  Seriously though, I think it means:

  Patch Uploaded Successfully, Added Patch, Could Not Send Patch Update
  
For some reason it couldn't email out the patch update URL.


  Neil


From mwh21@cam.ac.uk  Fri Jun 30 01:06:04 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 30 Jun 2000 01:06:04 +0100
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:46:32 -0700 (PDT)"
References: <Pine.SGI.3.96.1000629163112.621134r-100000@happy>
Message-ID: <m3u2ec6nir.fsf@atrus.jesus.cam.ac.uk>

Ka-Ping Yee <pingster@ilm.com> writes:

> On Thu, 29 Jun 2000, Ka-Ping Yee wrote:
> > Try setting the environment variable AUDIODEV to /dev/audio
> > before running the test script.  Does that work any better?
> 
> Even if that works, i realize that's not the way the interface
> was intended to be used.  To play an AU file, the routine should
> look something like this (not tested, as i don't have a working
> Linux box)...
[snip]

Yup, that works fine.  Don't understand the details - and as I have my
graduation ceremony tomorrow I'm going to go to bed and leave learning
them until some other occasion!

Cheers,
M.

PS: my Lib/test/test_linuxaudiodev.py is now this:

from test_support import verbose, findfile, TestFailed
import linuxaudiodev
import os,struct

def play_au_file(path):

    fp = open(path, "r")

    # Read the .au file header.
    header = fp.read(24)
    hdrsize, length, encoding, rate, channels = \
        struct.unpack(">xxxxiiiii", header)
    fp.read(hdrsize - 24)
    
    data = fp.read()
    fp.close()

    # Set the data format according to the code in the .au header.
    if encoding == 1:
        size, fmt = 8, linuxaudiodev.AFMT_MU_LAW
    elif encoding == 2:
        size, fmt = 8, linuxaudiodev.AFMT_S8
    elif encoding == 3:
        size, fmt = 16, linuxaudiodev.AFMT_S16_BE
    else:
        raise "audio format not supported"
        
    dsp = linuxaudiodev.open("w")
    dsp.setparameters(rate, size, channels, fmt)
    dsp.write(data)
    dsp.close()


def test():
    play_au_file(findfile('audiotest.au'))

test()

... which is an improvement on what's there now.



From pingster@ilm.com  Fri Jun 30 01:44:35 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 17:44:35 -0700 (PDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: <m3u2ec6nir.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <Pine.SGI.3.96.1000629173646.621134u-100000@happy>

On 30 Jun 2000, Michael Hudson wrote:
> Yup, that works fine.  Don't understand the details - and as I have my
> graduation ceremony tomorrow I'm going to go to bed and leave learning
> them until some other occasion!

Cool.

Okay, i just discovered sunau.py.  Here's my real shot at
test_linuxaudiodev.py.  Can you give this a try?


---- test_linuxaudiodev.py ----
from test_support import verbose, findfile, TestFailed
import linuxaudiodev
import os, sunau

formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW,
           ("NONE", 1): linuxaudiodev.AFMT_S8,
           ("NONE", 2): linuxaudiodev.AFMT_S16_BE}

def play_au_file(path):
    au = sunau.open(path, "r")
    data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE)
    au.close()

    spec = (au.getcomptype(), au.getsampwidth())
    if not has_key(formats, spec):
        raise "audio format not supported by linuxaudiodev"
        
    dsp = linuxaudiodev.open("w")
    dsp.setparameters(au.getframerate(), au.getsampwidth() * 8,
                      au.getnchannels(), formats[spec])
    dsp.write(data)
    dsp.close()

def test():
    play_au_file(findfile('audiotest.au'))

test()
---- test_linuxaudiodev.py ----



-- ?!ng



From gstein@lyra.org  Fri Jun 30 02:03:11 2000
From: gstein@lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 18:03:11 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8
In-Reply-To: <200006291238.FAA01061@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 05:38:48AM -0700
References: <200006291238.FAA01061@slayer.i.sourceforge.net>
Message-ID: <20000629180311.I29590@lyra.org>

Fredrik,

Something you are doing is forcing CVS to issue a new revision for some of
those files, even when you are not changing them. These "false" revisions
are probably not a good thing.

Could you review your checkin process to see what is up? I would guess that
you have the "-f" option in your commit line.

Cheers,
-g

On Thu, Jun 29, 2000 at 05:38:48AM -0700, Fredrik Lundh wrote:
> Update of /cvsroot/python/python/dist/src/Lib
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv899/Lib
> 
> Modified Files:
> 	sre.py sre_compile.py sre_constants.py sre_parse.py 
> Log Message:
> 
> 
> - make sure group names are valid identifiers
>   (closes the "SRE: symbolic reference" bug)
> 
> Index: sre.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre.py,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -C2 -r1.9 -r1.10
> 
> Index: sre_compile.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre_compile.py,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -C2 -r1.7 -r1.8
> 
> Index: sre_constants.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre_constants.py,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -C2 -r1.7 -r1.8
> 
> Index: sre_parse.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre_parse.py,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -C2 -r1.7 -r1.8
> *** sre_parse.py	2000/06/29 11:34:27	1.7
> --- sre_parse.py	2000/06/29 12:38:45	1.8
> ***************
> *** 169,172 ****
> --- 169,190 ----
>   	return this
>   
> + def isident(char):
> +     return "a" <= char <= "z" or "A" <= char <= "Z" or char == "_"
> + 
> + def isdigit(char):
> +     return "0" <= char <= "9"
> + 
> + def isname(name):
> +     # check that group name is a valid string
> +     # FIXME: <fl> this code is really lame.  should use a regular
> +     # expression instead, but I seem to have certain bootstrapping
> +     # problems here ;-)
> +     if not isident(name[0]):
> + 	return 0
> +     for char in name:
> + 	if not isident(char) and not isdigit(char):
> + 	    return 0
> +     return 1
> + 
>   def _group(escape, state):
>       # check if the escape string represents a valid group
> ***************
> *** 419,425 ****
>   			    if char == ">":
>   				break
> - 			    # FIXME: check for valid character
>   			    name = name + char
>   			group = 1
>   		    elif source.match("="):
>   			# named backreference
> --- 437,444 ----
>   			    if char == ">":
>   				break
>   			    name = name + char
>   			group = 1
> + 			if not isname(name):
> + 			    raise error, "illegal character in group name"
>   		    elif source.match("="):
>   			# named backreference
> ***************
> *** 523,540 ****
>   			char = s.get()
>   			if char is None:
> ! 			    raise error, "unterminated index"
>   			if char == ">":
>   			    break
> - 			# FIXME: check for valid character
>   			name = name + char
>   		if not name:
> ! 		    raise error, "bad index"
>   		try:
>   		    index = int(name)
>   		except ValueError:
>   		    try:
>   			index = pattern.groupindex[name]
>   		    except KeyError:
> ! 			raise IndexError, "unknown index"
>   		a((MARK, index))
>   	    elif len(this) > 1 and this[1] in DIGITS:
> --- 542,560 ----
>   			char = s.get()
>   			if char is None:
> ! 			    raise error, "unterminated group name"
>   			if char == ">":
>   			    break
>   			name = name + char
>   		if not name:
> ! 		    raise error, "bad group name"
>   		try:
>   		    index = int(name)
>   		except ValueError:
> + 		    if not isname(name):
> + 			raise error, "illegal character in group name"
>   		    try:
>   			index = pattern.groupindex[name]
>   		    except KeyError:
> ! 			raise IndexError, "unknown group name"
>   		a((MARK, index))
>   	    elif len(this) > 1 and this[1] in DIGITS:
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins@python.org
> http://www.python.org/mailman/listinfo/python-checkins

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


From akuchlin@mems-exchange.org  Fri Jun 30 02:29:41 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 29 Jun 2000 21:29:41 -0400
Subject: [Python-Dev] Removing modules
Message-ID: <20000629212941.A21563@newcnri.cnri.reston.va.us>

For the "deleted modules" section of the 2.0 article, I drew up a list
of modules that might be outdated, mostly the SGI-specific ones.  Are
those modules still useful, and do the libraries they were written for
still exist?

For your cogitation, here's the list: sgimodule.c, glmodule.c (and
hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c,
almodule.c, clmodule.c,  knee.py.

Also, can someone explain why importing a third party extension built
for Python 1.5.x is supposed to result in an immediate crash on
Windows?  I'd like to explain why this happens...

--amk




From guido@python.org  Fri Jun 30 04:13:13 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 29 Jun 2000 22:13:13 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8
In-Reply-To: Your message of "Thu, 29 Jun 2000 18:03:11 MST."
 <20000629180311.I29590@lyra.org>
References: <200006291238.FAA01061@slayer.i.sourceforge.net>
 <20000629180311.I29590@lyra.org>
Message-ID: <200006300313.WAA22134@cj20424-a.reston1.va.home.com>

> Fredrik,
> 
> Something you are doing is forcing CVS to issue a new revision for some of
> those files, even when you are not changing them. These "false" revisions
> are probably not a good thing.
> 
> Could you review your checkin process to see what is up? I would guess that
> you have the "-f" option in your commit line.
> 
> Cheers,
> -g

Greg, we already know why this is.  It's the $ID$.

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


From mhammond@skippinet.com.au  Fri Jun 30 03:49:06 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 12:49:06 +1000
Subject: [Python-Dev] Removing modules
In-Reply-To: <20000629212941.A21563@newcnri.cnri.reston.va.us>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEPMCOAA.mhammond@skippinet.com.au>

> Also, can someone explain why importing a third party extension built
> for Python 1.5.x is supposed to result in an immediate crash on
> Windows?  I'd like to explain why this happens...

The 1.5 module is linked against Python15.dll.  When Python.exe (linked
against Python16.dll) starts up, it initializes the Python data structures
in Python16.dll.  When Python then imports foo.pyd (linked against
Python15.dll), it immediately tries to call the functions in that DLL (such
as getting the thread state).  As Python has not been initialized in that
DLL, we immediately die.

Ironically, if Python1x.dll was simply named "Python.dll", there is a
_reasonable_ chance it would work fine.  The cost of doing this tho, is
that you can not have Python 1.5 and Python 1.6 "side by side" on the same
machine.

There are a few possibilities for magic tricks we could pull, but to be
honest Im not too inclined to bother with them myself...  They would also
require a commitment to a fully backwards compatible C API, which I dont
think we can afford to commit to!

Mark.



From gward@python.net  Fri Jun 30 04:30:03 2000
From: gward@python.net (Greg Ward)
Date: Thu, 29 Jun 2000 23:30:03 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
Message-ID: <20000629233003.A1766@beelzebub>

Curses!

I just noticed that sys.platform in 1.6a2 (and the latest CVS from this
morning) returns "linux2" on my PC, not "linux-i386".  As I recall this
decision is made in the configure script.  Does anyone know why it
changed?  This is not the end of the world, but the OS name alone is not
really enough on a multi-architecture OS...

...back to calling os.uname() myself, I guess.  ;-(

        Greg
-- 
Greg Ward - programmer-at-big                           gward@python.net
http://starship.python.net/~gward/
God made machine language; all the rest is the work of man.


From fdrake@beopen.com  Fri Jun 30 04:33:45 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 23:33:45 -0400 (EDT)
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <20000629233003.A1766@beelzebub>
References: <20000629233003.A1766@beelzebub>
Message-ID: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>

Greg Ward writes:
 > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this
 > morning) returns "linux2" on my PC, not "linux-i386".  As I recall this

  I didn't know it ever returned linux-i386; perhaps you're thinking
of Marc-Andre's platform module?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From trentm@activestate.com  Fri Jun 30 04:34:17 2000
From: trentm@activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 20:34:17 -0700
Subject: [Python-Dev] Controversial patch (cmath)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEFBGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCAEFBGHAA.tim_one@email.msn.com>
Message-ID: <20000629203417.B23077@activestate.com>

[Tim discusses god awful math details]
Would you want to foward this to python-list to see if any lurking
mathematicians might be spurred to action?

Trent

-- 
Trent Mick
trentm@activestate.com


From gward@python.net  Fri Jun 30 04:53:34 2000
From: gward@python.net (Greg Ward)
Date: Thu, 29 Jun 2000 23:53:34 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 11:33:45PM -0400
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
Message-ID: <20000629235334.B1294@beelzebub>

On 29 June 2000, Fred L. Drake, Jr. said:
>   I didn't know it ever returned linux-i386; perhaps you're thinking
> of Marc-Andre's platform module?

D'ohh!  That appears to be an artifact of Red Hat's build -- I was using
/usr/bin/python (theirs), not /usr/local/bin/python (mine).

  $ /usr/bin/python
  Python 1.5.2 (#1, Feb  1 2000, 16:32:16)  [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> sys.platform
  'linux-i386'

Sorry for getting alarmist.  Guess I never should have started using
sys.platform in the first place (or just not worry about getting the CPU
in there too).

        Greg
-- 
Greg Ward - geek                                        gward@python.net
http://starship.python.net/~gward/
Support bacteria -- it's the only culture some people have!


From skip@mojam.com (Skip Montanaro)  Fri Jun 30 03:57:47 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 29 Jun 2000 21:57:47 -0500 (CDT)
Subject: [Python-Dev] available to look at bugs and patches...
Message-ID: <14684.3243.480545.880199@beluga.mojam.com>

Barry added me as a developer yesterday.  Those people assigning bugs and
patches can use me as a resource...

Skip


From gward@python.net  Fri Jun 30 05:26:20 2000
From: gward@python.net (Greg Ward)
Date: Fri, 30 Jun 2000 00:26:20 -0400
Subject: [Python-Dev] ANNOUNCE: Distutils 0.9
Message-ID: <20000630002620.A2329@beelzebub>

                     Python Distribution Utilities
                              release 0.9
                             June 29, 2000

The Python Distribution Utilities, or Distutils for short, are a
collection of modules that aid in the development, distribution, and
installation of Python modules.  (It is intended that ultimately the
Distutils will grow up into a system for distributing and installing
whole Python applications, but for now their scope is limited to module
distributions.)

The Distutils are a standard part of Python 2.0; if you are running 2.0
(or one of the 1.6 alpha releases that preceded it), you don't need to
install the Distutils separately.  This release is primarily so that you
can add the Distutils to a Python 1.5.2 installation -- you will then be
able to install modules that require the Distutils, or use the Distutils
to distribute your own modules.

More information is available at the Distutils web page:

    http://www.python.org/sigs/distutils-sig/

and in the README.txt included in the Distutils source distribution.

You can download the Distutils from

    http://www.python.org/sigs/distutils-sig/download.html

Trivial patches can be sent to me (Greg Ward) at gward@python.net.
Larger patches should be discussed on the Distutils mailing list:
distutils-sig@python.org.


From tpeters@beopen.com  Fri Jun 30 06:05:32 2000
From: tpeters@beopen.com (Tim Peters)
Date: Fri, 30 Jun 2000 01:05:32 -0400
Subject: [Python-Dev] Controversial patch (cmath)
In-Reply-To: <20000629203417.B23077@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEFLGHAA.tim_one@email.msn.com>

[Trent Mick]

> [Tim discusses god awful math details]
> Would you want to foward this to python-list to see if any lurking
> mathematicians might be spurred to action?

God, please no!  This requires a numerical analyst, not a mathematician.
Voting by talented amateurs is only going to make things worse <0.5 wink>.
I was an NA in a previous life, and know what needs to be done to resolve
all this.  But that takes way more time than we have before 2.0b1.  The
patch in question makes life better for the world's only known user of cmath
<ahem>.

may-as-well-ask-c.l.py-to-discuss-python's-version-number<wink>-ly
    y'rs  - tim




From jeremy@beopen.com  Fri Jun 30 06:08:30 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 01:08:30 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include objimpl.h,2.16,2.17
In-Reply-To: <200006300502.WAA03256@slayer.i.sourceforge.net>
References: <200006300502.WAA03256@slayer.i.sourceforge.net>
Message-ID: <14684.11086.47325.776691@bitdiddle.concentric.net>

These patches should catch up with Neil's latest submissions, but may
not have the very latest changes suggested by Neil and Vladimir.  I
will double-check with them in the morning.  I will also change
configure.in to enable GC by default for the beta test phase, unless
there is strong objection.

Jeremy


From skip@mojam.com (Skip Montanaro)  Fri Jun 30 05:00:29 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 29 Jun 2000 23:00:29 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1
In-Reply-To: <200006300502.WAA03286@slayer.i.sourceforge.net>
References: <200006300502.WAA03286@slayer.i.sourceforge.net>
Message-ID: <14684.7005.661874.713000@beluga.mojam.com>

    Jeremy> Log Message:
    Jeremy> final patches from Neil Schemenauer for garbage collection

    Jeremy> --- NEW FILE ---
    Jeremy> test_gc
    Jeremy> list 0x831a754
    Jeremy> dict 0x831a754
    ...
    Jeremy> dict 0x831a9bc
    Jeremy> func 0x831d9e4

I can all but guarantee you this test will always fail.  Printing absolute
machine addresses (via calls to id() in this case) in test cases should be
verboten.

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."


From trentm@activestate.com  Fri Jun 30 07:05:50 2000
From: trentm@activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 23:05:50 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7
In-Reply-To: <200006300502.WAA03275@slayer.i.sourceforge.net>
References: <200006300502.WAA03275@slayer.i.sourceforge.net>
Message-ID: <20000629230550.A24811@activestate.com>

On Thu, Jun 29, 2000 at 10:02:55PM -0700, Jeremy Hylton wrote:
> Update of /cvsroot/python/python/dist/src/PCbuild
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv3220/PCbuild
> 
> Modified Files:
> 	python16.dsp 
> Log Message:
> final patches from Neil Schemenauer for garbage collection
> 
> 
> Index: python16.dsp
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/PCbuild/python16.dsp,v
> retrieving revision 1.6
> retrieving revision 1.7
> diff -C2 -r1.6 -r1.7
> *** python16.dsp	2000/06/06 23:29:09	1.6
> --- python16.dsp	2000/06/30 05:02:53	1.7
> ***************
> *** 660,663 ****
> --- 660,677 ----
>   # End Source File
>   # Begin Source File
> + SOURCE=..\Modules\gcmodule.c
> + 
> + !IF  "$(CFG)" == "python16 - Win32 Release"
> + 
> + !ELSEIF  "$(CFG)" == "python16 - Win32 Debug"
> + 
> + !ELSEIF  "$(CFG)" == "python16 - Win32 Alpha Debug"
> + 
> + !ELSEIF  "$(CFG)" == "python16 - Win32 Alpha Release"
> + 
> + !ENDIF 
> + 
> + # End Source File
> + # Begin Source File
>   
>   SOURCE=..\Python\getargs.c
> 

Pardon me if I am wrong (I have not actually checked the repository) but is
this correct now that the version number is 2.0?

Trent


-- 
Trent Mick
trentm@activestate.com


From trentm@activestate.com  Fri Jun 30 07:27:33 2000
From: trentm@activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 23:27:33 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <200006300608.XAA13124@slayer.i.sourceforge.net>
References: <200006300608.XAA13124@slayer.i.sourceforge.net>
Message-ID: <20000629232733.D24811@activestate.com>

Cool

On Thu, Jun 29, 2000 at 11:08:38PM -0700, Skip Montanaro wrote:
> 
> --- NEW FILE ---
> 			 Writing Python Test Cases
> 			 -------------------------
> 			       Skip Montanaro
> 
> 
> To run the entire test suite, make the "test" target at the top level:
> 
>     cd ...
>     make test

This is a UN*Xism, on Windows and UN*X:
cd ...\Lib\test
python regrtest.py



A sample walk through to create a test might make it more approachable for
people. As well, it would be helpful to mention
test_support.{verbose|TESTFN|...}.  But I have no right to bitch about good
work.


Trent



-- 
Trent Mick
trentm@activestate.com


From tpeters@beopen.com  Fri Jun 30 07:39:15 2000
From: tpeters@beopen.com (Tim Peters)
Date: Fri, 30 Jun 2000 02:39:15 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <20000629232733.D24811@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com>

[Trent Mick]
> ...
> But I have no right to bitch about good work.

How do you figure that?  We do it to you enough <wink>.

BTW, I'd just like to say what a delight it is to work with *all* of you
folks!  I wanted to say that before I can be accused of pimping for my
employer -- so far, BeOpen hasn't paid me a dime, so you know my opinion
hasn't yet been bought.

well-maybe-on-credit<wink>-ly y'rs  - tim




From tpeters@beopen.com  Fri Jun 30 07:39:12 2000
From: tpeters@beopen.com (Tim Peters)
Date: Fri, 30 Jun 2000 02:39:12 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7
In-Reply-To: <20000629230550.A24811@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEFPGHAA.tim_one@email.msn.com>

[Trent Mick, on Guido's late-night (for him <wink>) checkin of
 python16.dsp]

> Pardon me if I am wrong (I have not actually checked the
> repository) but is this correct now that the version number is 2.0?

No, it is not, and the Windows build is slightly damaged now.  I've already
yelled at Guido about this, but I suspect he's asleep.  I'm sure it will get
sorted out in the morning.




From trentm@activestate.com  Fri Jun 30 07:52:47 2000
From: trentm@activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 23:52:47 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com>
References: <20000629232733.D24811@activestate.com> <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com>
Message-ID: <20000629235247.A25090@activestate.com>

On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote:
> BTW, I'd just like to say what a delight it is to work with *all* of you
> folks!

I feel a group hug coming on in the morning. Or maybe I am just moved by the
beer that I had for dinner. :) Likewise, Tim. As my first foray into
community development I find this, Python dev, a refreshing pleasure.

Trent

-- 
Trent Mick
trentm@activestate.com


From tpeters@beopen.com  Fri Jun 30 08:41:28 2000
From: tpeters@beopen.com (Tim Peters)
Date: Fri, 30 Jun 2000 03:41:28 -0400
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEGBGHAA.tim_one@email.msn.com>

[Tim]
> ... "Group whiteboards" and shared journals etc are darned
> useful, though.

[Ken Manheimer]
> Wiki = Group whiteboard

Ya, I kind of picked that up from your last passionate advertisement for
this stuff <wink>.  Not knocking it!  Never tried it.  Believe it or not, I
spend as little time on the web as possible.  After I've gotten into a place
to live here, and this current release crunch is behind us, I'm definitely
going to check out your leads.

For the past several years my development group worked thru Lotus Notes,
which I didn't much care for at the time, but I'm increasingly realizing
just how essential group-modifiable shared persistent documents were to our
productivity.  Notes is the purest example of a whole being greater than the
sum of its parts I've ever seen (lousy mail system, lousy database, lousy
change manager, lousy bug tracker, lousy workflow manager, worse than lousy
native scripting ... but they all sucked in ways that were downright
synergistic <0.9 wink>).

> ...
> Anyway, to see leads on both zwikis and tracker, see:
>
>   http://www.zope.org/Members/klm/TrackerWiki

can-beopen-zwiki-2.0-be-far-behind<wink>?-ly y'rs  - tim




From pingster@ilm.com  Fri Jun 30 09:21:08 2000
From: pingster@ilm.com (Ka-Ping Yee)
Date: Fri, 30 Jun 2000 01:21:08 -0700 (PDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <200006292338.BAA07798@python.inrialpes.fr>
Message-ID: <Pine.SGI.3.96.1000630010709.621134O-100000@happy>

Guido van Rossum wrote:
> let this be an advance warning that it will be called Python 2.0.

On Fri, 30 Jun 2000, Vladimir Marangozov wrote:
> Guido van Rossum just won't stop surprising us! :-)

Will many be spooked by the jump in version number into fearing
incompatibility with older scripts...?

I wonder if we'll end up trying to persuade the user community that
the changes are small ("no, don't worry, your scripts will still
work") and yet big ("honest, it really deserves to be called 2.0,
it's not just a ploy") at the same time.

Perl 5 was basically incompatible with Perl 4.  Some things run,
but a lot don't.  (Actually many microversions of Perl 5 were
mutually incompatible with each other, but i'll ignore that. :) )

I've thought of the jump to Python3k (lowercase "k", please) much
like the Perl-4-to-Perl-5 jump: simple stuff is still okay but a lot
of guts have changed.  If i hadn't been "on the inside" watching
development activity, i might expect something of similar magnitude
upon hearing of going from Python 1.x to 2.0.

I guess we can point at Unicode and SRE as big things.


-- ?!ng



From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 09:33:10 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 10:33:10 +0200
Subject: [Python-Dev] SRE status report
Message-ID: <005001bfe26d$d3dc3540$f2a6b5d4@hagrid>

just checked in a test script for sre.  the test_sre file is a
copy of test_re, with some minor changes:

-- disabled one test (caused by bug #8; see below)

-- added T (template mode, experimental, unsupported)
   and U (unicode locale) flags to the flag test

-- removed keyword arguments in pattern test loop:

    result =3D obj.search(s, pos=3Dresult.start(0), =
endpos=3Dresult.end(0)+1)

was changed to:

    result =3D obj.search(s, result.start(0), result.end(0)+1)

as far as I can tell, the docs don't mention anything about keyword
arguments...

-- added unicode pattern / target string / locale tests to
   the pattern test loop.

however, the current version SRE doesn't fully pass the test.
here's an annotated version of Lib/test/output/test_sre:

1) test_support -- test failed re module pickle
2) test_support -- test failed re module cPickle

under SRE, patterns are C objects, not class instances.
to allow pickling, I need to modify copy_reg (either by
modifing the file itself, or by updating the registry when
SRE is first imported).  see patch #100650 for more info,

3) =3D=3D=3D Syntax error: ('(?P<foo_123>a)(?P=3Dfoo_123)', 'aa', 0, =
'g1', 'a')

this is a bug in the SRE parser.  should be easy to fix.

4) =3D=3D=3D Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A')

this is a bug in the engine (nested repetitions). needs
further research.

5) =3D=3D=3D Failed incorrectly ('(a+)+\\1', 'aa', 0, 'found+"-"+g1', =
'aa-a')

this is a bug in the engine or in the parser.  needs further
research.

6) =3D=3D=3D grouping error ('([^/]*/)*sub1/', =
'd:msgs/tdir/sub1/trial/away.cpp', 0, 'found+"-"+g1', =
'd:msgs/tdir/sub1/-tdir/') 'd:msgs/tdir/sub1/-trial/' should be =
'd:msgs/tdir/sub1/-tdir/'

same as #5.

7) =3D=3D=3D Syntax error: ('(?P<id>aa)(?P=3Did)', 'aaaa', 0, =
'found+"-"+id', 'aaaa-aa')

same as #3.

8) =3D=3D=3D grouping error ('([abc])*bcd', 'abcd', 0, 'found+"-"+g1', =
'abcd-a') 'abcd-c' should be 'abcd-a'

this is a bug in the engine.  should be easy to fix, I think.
in fact, I could have sworn that I'd fixed it already.

9) =3D=3D=3D grouping error ('(?i)([abc])*bcd', 'ABCD', 0, =
'found+"-"+g1', 'ABCD-A') 'ABCD-C' should be 'ABCD-A'

same as #8

10) =3D=3D=3D Syntax error: ('a(?!b).', 'abad', 0, 'found', 'ad')

this is bug in the parser.  should be easy to fix.

11) =3D=3D=3D Syntax error: ('a(?=3Dd).', 'abad', 0, 'found', 'ad')

same as (or at least related to) #10

12) =3D=3D=3D Syntax error: ('a(?=3Dc|d).', 'abad', 0, 'found', 'ad')

same as #11

13) =3D=3D=3D Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A')

same as #4 (literally!).

...

fwiw, *all* RE-based code I've played with seem to
work.  ymmv.  let me know asap if it does.

</F>



From mhammond@skippinet.com.au  Fri Jun 30 09:41:44 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 18:41:44 +1000
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <Pine.SGI.3.96.1000630010709.621134O-100000@happy>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>

> Will many be spooked by the jump in version number into fearing
> incompatibility with older scripts...?
>
> I wonder if we'll end up trying to persuade the user community that
> the changes are small ("no, don't worry, your scripts will still
> work") and yet big ("honest, it really deserves to be called 2.0,
> it's not just a ploy") at the same time.

I see your concerns, but I think the trick is to be honest, just as Guido
was.  We simply say it was bumped to V2 for the reasons of percieved
maturity, and a clear break from CNRI Python.

Both seem reasonable.  I believe many people will simply wait for some form
of consensus on the newsgroup, regardless of the version number.

Personally, Im a little - umm - lets just say that I can see the irony in
the fact that I recently changed a few bits of code that were dependent on
a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x
family.  I figured there was no point trying to predict the packaging
details of the 2.x family, seeing it as still some time off.  Nothing like
foresight :-)

And-"foresight"-isnt-an-excuse-for-Tim-to-get-back-on-the-topic-of-his-geni
tals-<wink>-ly,

Mark.



From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 09:55:01 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 10:55:01 +0200
Subject: [Python-Dev] New PythonLabs site revealed!
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>
Message-ID: <005801bfe270$e140d440$f2a6b5d4@hagrid>

mark wrote:
> Personally, Im a little - umm - lets just say that I can see the irony =
in
> the fact that I recently changed a few bits of code that were =
dependent on
> a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of =
the 1.x
> family.

heh.  you're not the only one...

btw, now that we're bumping to 2.0, maybe we can break
socket.connect and friends once again?  if somebody com-
plains, just tell them "it's a major release, dammit" ;-)

</F>



From gstein@lyra.org  Fri Jun 30 09:59:56 2000
From: gstein@lyra.org (Greg Stein)
Date: Fri, 30 Jun 2000 01:59:56 -0700
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com> <200006291905.OAA17265@cj20424-a.reston1.va.home.com>
Message-ID: <20000630015956.S29590@lyra.org>

On Thu, Jun 29, 2000 at 02:05:11PM -0500, Guido van Rossum wrote:
>...
> > Note that Perl is maintained under (the commercial, alas) Perforce, which is
> > one of the few SCMs to take multi-developer multi-directory issues
> > seriously.
> 
> We tried Perforce at CNRI.  It's really neat, but somehow it was
> lacking some stuff we were used to and we never converted.
> 
> Note that Perforce is free for open source projects -- at least at the
> time it was.  (CNRI paid a license fee, but that was just an
> expression of CNRI's reluctance against free software. :-)
> 
> There's also bitkeeper.  It stayed in beta so long that we gave up
> (and they have a weird license) -- but it's out of beta since May 4:
> see http://www.bitkeeper.com/.  But there's no immediate download!
> You must sign up and they send you instructions in the mail...

And coming down the pipe (end of the year) is Subversion:

    http://subversion.tigris.org/

Cheers,
-g

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


From mhammond@skippinet.com.au  Fri Jun 30 10:23:53 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 19:23:53 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6
In-Reply-To: <200006300904.CAA04151@slayer.i.sourceforge.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEBACPAA.mhammond@skippinet.com.au>

> Making a tiny change to figure out what I'm going to screw up
> by trying to use CVS under Windows at all ...

Congratulations :-)

Mark.



From mhammond@skippinet.com.au  Fri Jun 30 10:25:39 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 19:25:39 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBGEBACPAA.mhammond@skippinet.com.au>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEBACPAA.mhammond@skippinet.com.au>

> To: python-dev@python.org

Damn damn damn - did it again.  Sorry.

[I wishing mailing-lists would agree on how they handle reply-to :-]

Mark.


From mal@lemburg.com  Fri Jun 30 10:27:57 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 11:27:57 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
Message-ID: <395C681D.C3211F6@lemburg.com>

"Fred L. Drake, Jr." wrote:
> 
> Greg Ward writes:
>  > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this
>  > morning) returns "linux2" on my PC, not "linux-i386".  As I recall this
> 
>   I didn't know it ever returned linux-i386; perhaps you're thinking
> of Marc-Andre's platform module?

Python has returned 'linux2' on my machine ever since I moved
to a 2.x kernel -- why should it return 'linux-i386' (without
any indication of version) ?

As Fred mentioned, you should probably use platform.py to
access the information you have in mind. It supports loads
of different architectures and has pretty much all the
information you need for distutils warpped in nice APIs.

Why not simply include it in distutils ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 11:04:00 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 12:04:00 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2
References: <200006300953.CAA14782@slayer.i.sourceforge.net>
Message-ID: <00b001bfe27a$845f7880$f2a6b5d4@hagrid>

MAL wrote:
>     out.write(header)
>     out =3D open(cFileName, "w")
> !   out.write("#include "%s"\n" % headerFileName)
>     out.write(code)
>     perfHash.generate_graph(out)

umm.  I suppose you meant:

> !   out.write('#include "%s"\n' % headerFileName)

or possibly:

> !   out.write("#include \"%s\"\n" % headerFileName)

</F>



From mal@lemburg.com  Fri Jun 30 11:15:23 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 12:15:23 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS:
 python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2
References: <200006300953.CAA14782@slayer.i.sourceforge.net> <00b001bfe27a$845f7880$f2a6b5d4@hagrid>
Message-ID: <395C733B.4E2AFFA3@lemburg.com>

Fredrik Lundh wrote:
> 
> MAL wrote:
> >     out.write(header)
> >     out = open(cFileName, "w")
> > !   out.write("#include "%s"\n" % headerFileName)
> >     out.write(code)
> >     perfHash.generate_graph(out)
> 
> umm.  I suppose you meant:
> 
> > !   out.write('#include "%s"\n' % headerFileName)
> 
> or possibly:
> 
> > !   out.write("#include \"%s\"\n" % headerFileName)

Oops, you're right.

Thanks.
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From fdrake@beopen.com  Fri Jun 30 14:20:23 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:20:23 -0400 (EDT)
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEGBGHAA.tim_one@email.msn.com>
References: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>
 <LNBBLJKPBEHFEDALKOLCMEGBGHAA.tim_one@email.msn.com>
Message-ID: <14684.40599.135974.497497@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > productivity.  Notes is the purest example of a whole being greater than the
 > sum of its parts I've ever seen (lousy mail system, lousy database, lousy
 > change manager, lousy bug tracker, lousy workflow manager, worse than lousy
 > native scripting ... but they all sucked in ways that were downright
 > synergistic <0.9 wink>).

  I had to use Notes before working at CNRI, and wouldn't have
described all those sucky components as "synergistic".  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Fri Jun 30 14:26:15 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:26:15 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <Pine.SGI.3.96.1000630010709.621134O-100000@happy>
References: <200006292338.BAA07798@python.inrialpes.fr>
 <Pine.SGI.3.96.1000630010709.621134O-100000@happy>
Message-ID: <14684.40951.644965.274278@cj42289-a.reston1.va.home.com>

Ka-Ping Yee writes:
 > Will many be spooked by the jump in version number into fearing
 > incompatibility with older scripts...?
 > 
 > I wonder if we'll end up trying to persuade the user community that
 > the changes are small ("no, don't worry, your scripts will still
 > work") and yet big ("honest, it really deserves to be called 2.0,
 > it's not just a ploy") at the same time.

Ping,
  Haven't we heard our users complain about the conservative version
numbering a lot?  Pushing to 2.0 allows us to make the next release
2.1, which neither the "never 1.x!" crowd nor the "never x.0!" will
worry about.  Sounds like a good move to me!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Fri Jun 30 14:28:15 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:28:15 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <005801bfe270$e140d440$f2a6b5d4@hagrid>
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>
 <005801bfe270$e140d440$f2a6b5d4@hagrid>
Message-ID: <14684.41071.958061.743836@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > btw, now that we're bumping to 2.0, maybe we can break
 > socket.connect and friends once again?  if somebody com-
 > plains, just tell them "it's a major release, dammit" ;-)

  If by "break" you mean "tightly conform to the documentation", I'm
all for it!  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Fri Jun 30 14:32:24 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:32:24 -0400 (EDT)
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <395C681D.C3211F6@lemburg.com>
References: <20000629233003.A1766@beelzebub>
 <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
 <395C681D.C3211F6@lemburg.com>
Message-ID: <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>

Regarding platform.py:

M.-A. Lemburg writes:
 > Why not simply include it in distutils ?

  Why not include it in the standard library?
  Guido?  I'll document it if Marc-Andre is willing to provide the
module and the regression test.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From mal@lemburg.com  Fri Jun 30 14:40:36 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 15:40:36 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub>
 <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
 <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>
Message-ID: <395CA354.16AC5B7E@lemburg.com>

"Fred L. Drake, Jr." wrote:
> 
> Regarding platform.py:
> 
> M.-A. Lemburg writes:
>  > Why not simply include it in distutils ?
> 
>   Why not include it in the standard library?
>   Guido?  I'll document it if Marc-Andre is willing to provide the
> module and the regression test.

No objection from here.

I've attached my most recent copy to this mail. I'm not sure
how to write the regr. test though since output is dependent
on the platform running the functions... perhaps I'll just
add something like the audio thingie: "This string ought
to identify the platform you are currently running... if not,
then something is wrong ;-)".

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From bwarsaw@beopen.com  Fri Jun 30 14:42:19 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 09:42:19 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules gcmodule.c,NONE,2.1 Setup.thread.in,2.2,2.3 cPickle.c,2.43,2.44 newmodule.c,2.20,2.21
References: <200006300502.WAA03262@slayer.i.sourceforge.net>
Message-ID: <14684.41915.59835.325026@anthem.concentric.net>

So, Setup.thread.in isn't used just for threads anymore.  Perhaps it
should be renamed?  At the very least, a comment should be added to
the top that this file is for configure enabled modules.

-Barry

Index: Setup.thread.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/Setup.thread.in,v
retrieving revision 2.2
retrieving revision 2.3
diff -C2 -r2.2 -r2.3
*** Setup.thread.in	2000/06/29 16:08:28	2.2
--- Setup.thread.in	2000/06/30 05:02:53	2.3
***************
*** 11,12 ****
--- 11,15 ----
  
  @USE_THREAD_MODULE@thread threadmodule.c
+ 
+ # Garbage collection enabled with --with-cycle-gc
+ @USE_GC_MODULE@gc gcmodule.c


From mal@lemburg.com  Fri Jun 30 14:42:06 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 15:42:06 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub>
 <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
 <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com>
Message-ID: <395CA3AE.8A5800F1@lemburg.com>

This is a multi-part message in MIME format.
--------------B32584A17EA1E930287FE86F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ooops, forgot the attachement...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
--------------B32584A17EA1E930287FE86F
Content-Type: text/python; charset=iso-8859-1;
 name="platform.py"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="platform.py"

#!/usr/local/bin/python

""" This module tries to retrieve as much platform identifying data as
    possible. It makes this information available via function APIs.

    If called from the command line, it prints the platform
    information concatenated as single string to stdout. The output
    format is useable as part of a filename.

    Note that this module is a fast moving target. I plan to release
    version 1.0 as the final version.

    Still needed:
    · more support for WinCE
    · support for MS-DOS (PythonDX ?)
    · support for Amiga and other still unsupported platforms running Python
    · support for additional Linux distributions

    Many thanks to all those who helped adding platform specific
    checks (in no particular order):

      Charles G Waldman, David Arnold, Gordon McMillan, Ben Darnell,
      Jeff Bauer, Cliff Crawford, Ivan Van Laningham, Josef
      Betancourt, Randall Hopper, Karl Putland, John Farrell, Greg
      Andruk, Just van Rossum, Thomas Heller, Mark R. Levinson, Mark
      Hammond, Bill Tutt, Hans Nowak, Uwe Zessin (OpenVMS support),
      Colin Kong, Trent Mick
 
    History:
    0.7.2 - fixed architecture() to use sizeof(pointer) where available
    0.7.1 - added support for Caldera OpenLinux
    0.7.0 - some fixes for WinCE; untabified the source file
    0.6.2 - support for OpenVMS - requires version 1.5.2-V006 or higher and
            vms_lib.getsyi() configured
    0.6.1 - added code to prevent 'uname -p' on platforms which are
            known not to support it
    0.6.0 - fixed win32_ver() to hopefully work on Win95,98,NT and Win2k;
            did some cleanup of the interfaces - some APIs have changed
    0.5.5 - fixed another type in the MacOS code... should have
            used more coffee today ;-)
    0.5.4 - fixed a few typos in the MacOS code
    0.5.3 - added experimental MacOS support; added better popen()
            workarounds in _syscmd_ver() -- still not 100% elegant
            though
    0.5.2 - fixed uname() to return '' instead of 'unkown' in all
            return values (the system uname command tends to return
            'unkown' instead of just leaving the field emtpy)
    0.5.1 - included code for slackware dist; added exception handlers
            to cover up situations where platforms don't have os.popen
            (e.g. Mac) or fail on socket.gethostname(); fixed libc
            detection RE
    0.5.0 - changed the API names referring to system commands to *syscmd*;
            added java_ver(); made syscmd_ver() a private
            API (was system_ver() in previous versions) -- use uname()
            instead; extended the win32_ver() to also return processor
            type information
    0.4.0 - added win32_ver() and modified the platform() output for WinXX
    0.3.4 - fixed a bug in _follow_symlinks()
    0.3.3 - fixed popen() and "file" command invokation bugs
    0.3.2 - added architecture() API and support for it in platform()
    0.3.1 - fixed syscmd_ver() RE to support Windows NT
    0.3.0 - added system alias support
    0.2.3 - removed 'wince' again... oh well.
    0.2.2 - added 'wince' to syscmd_ver() supported platforms
    0.2.1 - added cache logic and changed the platform string format
    0.2.0 - changed the API to use functions instead of module globals
            since some action take too long to be run on module import
    0.1.0 - first release

    You can always get the latest version of this module at:

             http://starship.python.net/~lemburg/platform.py

    If that URL should fail, try contacting the author.

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

    (c) Copyright by Marc-Andre Lemburg (mailto:mal@lemburg.com)

    Permission to use, copy, modify, and distribute this software and its
    documentation for any purpose and without fee or royalty is hereby granted,
    provided that the above copyright notice appear in all copies and that
    both that copyright notice and this permission notice appear in
    supporting documentation or portions thereof, including modifications,
    that you make.

    THE AUTHOR MARC-ANDRE LEMBURG DISCLAIMS ALL WARRANTIES WITH REGARD TO
    THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
    FITNESS, IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL,
    INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
    FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
    NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
    WITH THE USE OR PERFORMANCE OF THIS SOFTWARE !

"""

__version__ = '0.7.0'

import sys,string,os,re

### Platform specific APIs

def libc_ver(executable=sys.executable,lib='',version='',

             chunksize=2048,
             libc_search=re.compile('(__libc_init)'
                                    '|'
                                    '(GLIBC_([0-9.]+))' 
                                    '|' 
                                    '(libc(_\w+)?\.so(?:\.(\d[0-9.]*))?)'
                                    )
         ):

    """ Tries to determine the libc version against which the
        file executable (defaults to the Python interpreter) is linked.

        Returns a tuple of strings (lib,version) which default to the
        given parameters in case the lookup fails.

        Note that the function has intimate knowledge of how different
        libc versions add symbols to the executable is probably only
        useable for executables compiled using gcc. 

        The file is read and scanned in chunks of chunksize bytes.

    """
    f = open(executable,'rb')
    binary = f.read(chunksize)
    pos = 0
    while 1:
        m = libc_search.search(binary,pos)
        if not m:
            binary = f.read(chunksize)
            if not binary:
                break
            pos = 0
            continue
        libcinit,glibc,glibcversion,so,threads,soversion = m.groups()
        if libcinit and not lib:
            lib = 'libc'
        elif glibc:
            if lib != 'glibc':
                lib = 'glibc'
                version = glibcversion
            elif glibcversion > version:
                version = glibcversion
        elif so:
            if lib != 'glibc':
                lib = 'libc'
                if soversion > version:
                    version = soversion
                if threads and version[-len(threads):] != threads:
                    version = version + threads
        pos = m.end()
    f.close()
    return lib,version

def _dist_try_harder(distname,version,id):

    """ Tries some special tricks to get the distribution 
        information in case the default method fails.

        Currently supports older SuSE Linux, Caldera OpenLinux and
        Slackware Linux distributions.

    """
    if os.path.exists('/var/adm/inst-log/info'):
        # SuSE Linux stores distribution information in that file
        info = open('/var/adm/inst-log/info').readlines()
        distname = 'SuSE'
        for line in info:
            tv = string.split(line)
            if len(tv) == 2:
                tag,value = tv
            else:
                continue
            if tag == 'MIN_DIST_VERSION':
                version = string.strip(value)
            elif tag == 'DIST_IDENT':
                values = string.split(value,'-')
                id = values[2]
        return distname,version,id

    if os.path.exists('/etc/.installed'):
        # Caldera OpenLinux has some infos in that file (thanks to Colin Kong)
        info = open('/etc/.installed').readlines()
        for line in info:
            pkg = string.split(line,'-')
            if len(pkg) >= 2 and pkg[0] == 'OpenLinux':
                # XXX does Caldera support non Intel platforms ? If yes,
                #     where can we find the needed id ?
                return 'OpenLinux',pkg[1],id

    if os.path.isdir('/usr/lib/setup'):
        # Check for slackware verson tag file (thanks to Greg Andruk)
        verfiles = os.listdir('/usr/lib/setup')
        for n in range(len(verfiles)-1, -1, -1):
            if verfiles[n][:14] != 'slack-version-':
                del verfiles[n]
        if verfiles:
            verfiles.sort()
            distname = 'slackware'
            version = verfiles[-1][14:]
            return distname,version,id

    return distname,version,id

def dist(distname='',version='',id='',

         supported_dists=('SuSE','debian','redhat','mandrake'),
         release_filename=re.compile('(\w+)[-_](release|version)'),
         release_version=re.compile('([\d.]+)[^(]*(?:\((.+)\))?')):

    """ Tries to determine the name of the OS distribution name

        The function first looks for a distribution release file in
        /etc and then reverts to _dist_try_harder() in case no
        suitable files are found.

        Returns a tuple distname,version,id which default to the
        args given as parameters.

    """
    try:
        etc = os.listdir('/etc')
    except os.error:
        # Probably not a Unix system
        return distname,version,id
    for file in etc:
        m = release_filename.match(file)
        if m:
            _distname,dummy = m.groups()
            if _distname in supported_dists:
                distname = _distname
                break
    else:
        return _dist_try_harder(distname,version,id)
    f = open('/etc/'+file,'r')
    firstline = f.readline()
    f.close()
    m = release_version.search(firstline)
    if m:
        _version,_id = m.groups()
        if _version:
            version = _version
        if _id:
            id = _id
    else:
        # Unkown format... take the first two words
        l = string.split(string.strip(firstline))
        if l:
            version = l[0]
            if len(l) > 1:
                id = l[1]
    return distname,version,id

class _popen:

    """ Fairly portable (alternative) popen implementation.

        This is mostly needed in case os.popen() is not available, or
        doesn't work as advertised, e.g. in Win9X GUI programs like
        PythonWin or IDLE.

        XXX Writing to the pipe is currently not supported.

    """
    tmpfile = ''
    pipe = None
    bufsize = None
    mode = 'r'

    def __init__(self,cmd,mode='r',bufsize=None):

        if mode != 'r':
            raise ValueError,'popen()-emulation only support read mode'
        import tempfile
        self.tmpfile = tmpfile = tempfile.mktemp()
        os.system(cmd + ' > %s' % tmpfile)
        self.pipe = open(tmpfile,'rb')
        self.bufsize = bufsize
        self.mode = mode

    def read(self):

        return self.pipe.read()

    def readlines(self):

        if self.bufsize is not None:
            return self.pipe.readlines()

    def close(self,

              remove=os.unlink,error=os.error):

        if self.pipe:
            rc = self.pipe.close()
        else:
            rc = 255
        if self.tmpfile:
            try:
                remove(self.tmpfile)
            except error:
                pass
        return rc

    # Alias
    __del__ = close

def popen(cmd, mode='r', bufsize=None):

    """ Portable popen() interface.
    """
    # Find a working popen implementation preferring win32pipe.popen
    # over os.popen over _popen
    popen = None
    if os.environ.get('OS','') == 'Windows_NT':
        # On NT win32pipe should work; on Win9x it hangs due to bugs
        # in the MS C lib (see MS KnowledgeBase article Q150956)
        try:
            import win32pipe
        except ImportError:
            pass
        else:
            popen = win32pipe.popen
    if popen is None:
        if hasattr(os,'popen'):
            popen = os.popen
            # Check whether it works... it doesn't in GUI programs
            # on Windows platforms
            if sys.platform == 'win32': # XXX Others too ?
                try:
                    popen('')
                except os.error:
                    popen = _popen
        else:
            popen = _popen
    if bufsize is None:
        return popen(cmd,mode)
    else:
        return popen(cmd,mode,bufsize)

def _norm_version(version,build=''):

    """ Normalize the version and build strings and return a sinlge
        vesion string using the format major.minor.build (or patchlevel).
    """
    l = string.split(version,'.')
    if build:
        l.append(build)
    try:
        ints = map(int,l)
    except ValueError:
        strings = l
    else:
        strings = map(str,ints)
    version = string.join(strings[:3],'.')
    return version

def _syscmd_ver(system='',release='',version='',

               supported_platforms=('win32','win16','dos','os2'),
               ver_output=re.compile('(?:([\w ]+) ([\w.]+) '
                                     '.*'
                                     'Version ([\d.]+))')):

    """ Tries to figure out the OS version used and returns
        a tuple (system,release,version).
        
        It uses the "ver" shell command for this which is known
        to exists on Windows, DOS and OS/2. XXX Others too ?

        In case this fails, the given parameters are used as
        defaults.

    """
    if sys.platform not in supported_platforms:
        return system,release,version

    # Try some common cmd strings
    for cmd in ('ver','command /c ver','cmd /c ver'):
        try:
            pipe = popen(cmd)
            info = pipe.read()
            if pipe.close():
                raise os.error,'command failed'
            # XXX How can I supress shell errors from being written
            #     to stderr ?
        except os.error,why:
            #print 'Command %s failed: %s' % (cmd,why)
            continue
        except IOError,why:
            #print 'Command %s failed: %s' % (cmd,why)
            continue
        else:
            break
    else:
        return system,release,version

    # Parse the output
    info = string.strip(info)
    m = ver_output.match(info)
    if m:
        system,release,version = m.groups()
        # Strip trailing dots from version and release
        if release[-1] == '.':
            release = release[:-1]
        if version[-1] == '.':
            version = version[:-1]
        # Normalize the version and build strings (eliminating additional
        # zeros)
        version = _norm_version(version)
    return system,release,version

def _win32_getvalue(key,name,default=''):

    """ Read a value for name from the registry key.

        In case this fails, default is returned.

    """
    from win32api import RegQueryValueEx
    try:
        return RegQueryValueEx(key,name)
    except:
        return default

def win32_ver(release='',version='',csd='',ptype=''):

    """ Get additional version information from the Windows Registry
        and return a tuple (version,csd,ptype) referring to version
        number, CSD level and OS type (multi/single
        processor).

        As a hint: ptype returns 'Uniprocessor Free' on single
        processor NT machines and 'Multiprocessor Free' on multi
        processor machines. The 'Free' refers to the OS version being
        free of debugging code. It could also state 'Checked' which
        means the OS version uses debugging code, i.e. code that
        checks arguments, ranges, etc. (Thomas Heller).

        Note: this functions only works if Mark Hammond's win32
        package is installed and obviously only runs on Win32
        compatible platforms.

        XXX Is there any way to find out the processor type on WinXX ?

        XXX Is win32 available on Windows CE ?

        Adapted from code posted by Karl Putland to comp.lang.python.

    """
    # Import the needed APIs
    try:
        import win32api
    except ImportError:
        return release,version,csd,ptype
    from win32api import RegQueryValueEx,RegOpenKeyEx,RegCloseKey,GetVersionEx
    from win32con import HKEY_LOCAL_MACHINE,VER_PLATFORM_WIN32_NT,\
                         VER_PLATFORM_WIN32_WINDOWS

    # Find out the registry key and some general version infos
    maj,min,buildno,plat,csd = GetVersionEx()
    version = '%i.%i.%i' % (maj,min,buildno & 0xFFFF)
    if csd[:13] == 'Service Pack ':
        csd = 'SP' + csd[13:]
    if plat == VER_PLATFORM_WIN32_WINDOWS:
        regkey = 'SOFTWARE\\Microsoft\\Windows\\CurrentVersion'
        # Try to guess the release name
        if maj == 4:
            if min == 0:
                release = '95'
            else:
                release = '98'
        elif maj == 5:
            release = '2000'
    elif plat == VER_PLATFORM_WIN32_NT:
        regkey = 'SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion'
        if maj <= 4:
            release = 'NT'
        elif maj == 5:
            release = '2000'
    else:
        if not release:
            # E.g. Win3.1 with win32s
            release = '%i.%i' % (maj,min)
        return release,version,csd,ptype

    # Open the registry key
    try:
        keyCurVer = RegOpenKeyEx(HKEY_LOCAL_MACHINE,regkey)
        # Get a value to make sure the key exists...
        RegQueryValueEx(keyCurVer,'SystemRoot')
    except:
        return release,version,csd,ptype
    
    # Parse values
    #subversion = _win32_getvalue(keyCurVer,
    #                            'SubVersionNumber',
    #                            ('',1))[0]
    #if subversion:
    #   release = release + subversion # 95a, 95b, etc.
    build = _win32_getvalue(keyCurVer,
                            'CurrentBuildNumber',
                            ('',1))[0]
    ptype = _win32_getvalue(keyCurVer,
                           'CurrentType',
                           (ptype,1))[0]

    # Normalize version
    version = _norm_version(version,build)

    # Close key
    RegCloseKey(keyCurVer)
    return release,version,csd,ptype

def _mac_ver_lookup(selectors,default=None):

    from gestalt import gestalt
    l = []
    append = l.append
    for selector in selectors:
        try:
            append(gestalt(selector))
        except RuntimeError:
            append(default)
    return l

def _bcd2str(bcd):

    return hex(bcd)[2:]

def mac_ver(release='',versioninfo=('','',''),machine=''):

    """ Get MacOS version information and return it as tuple (release,
        versioninfo, machine) with versioninfo being a tuple (version,
        dev_stage, non_release_version).

        Entries which cannot be determined are set to ''. All tuple
        entries are strings.

        Thanks to Mark R. Levinson for mailing documentation links and
        code examples for this function. Documentation for the
        gestalt() API is available online at:

           http://www.rgaros.nl/gestalt/

    """
    # Check whether the version info module is available
    try:
        import gestalt
    except ImportError:
        return release,versioninfo,machine
    # Get the infos
    sysv,sysu,sysa = _mac_ver_lookup(('sysv','sysu','sysa'))
    # Decode the infos
    if sysv:
        major = (sysv & 0xFF00) >> 8
        minor = (sysv & 0x00F0) >> 4
        patch = (sysv & 0x000F)
        release = '%s.%i.%i' % (_bcd2str(major),minor,patch)
    if sysu:
        major =  (sysu & 0xFF000000) >> 24
        minor =  (sysu & 0x00F00000) >> 20
        bugfix = (sysu & 0x000F0000) >> 16
        stage =  (sysu & 0x0000FF00) >> 8
        nonrel = (sysu & 0x000000FF)
        version = '%s.%i.%i' % (_bcd2str(major),minor,bugfix)
        nonrel = _bcd2str(nonrel)
        stage = {0x20:'development',
                 0x40:'alpha',
                 0x60:'beta',
                 0x80:'final'}.get(stage,'')
        versioninfo = (version,stage,nonrel)
    if sysa:
        machine = {0x1: '68k', 
                   0x2: 'PowerPC'}.get(sysa,'')
    return release,versioninfo,machine

def _java_getprop(self,name,default):

    from java.lang import System
    try:
        return System.getProperty(name)
    except:
        return default

def java_ver(release='',vendor='',vminfo=('','',''),osinfo=('','','')):
    
    """ Version interface for JPython.

        Returns a tuple (release,vendor,vminfo,osinfo) with vminfo being
        a tuple (vm_name,vm_release,vm_vendor) and osinfo being a
        tuple (os_name,os_version,os_arch).

        Values which cannot be determined are set to the defaults
        given as parameters (which all default to '').

    """
    # Import the needed APIs
    try:
        import java.lang
    except ImportError:
        return release,vendor,vminfo,osinfo

    vendor = _java_getprop('java.vendor',vendor)
    release = _java_getprop('java.version',release)
    vm_name,vm_release,vm_vendor = vminfo
    vm_name = _java_getprop('java.vm.name',vm_name)
    vm_vendor = _java_getprop('java.vm.vendor',vm_vendor)
    vm_release = _java_getprop('java.vm.version',vm_release)
    vminfo = vm_name,vm_release,vm_vendor
    os_name,os_version,os_arch = osinfo
    os_arch = _java_getprop('java.os.arch',os_arch)
    os_name = _java_getprop('java.os.name',os_name)
    os_version = _java_getprop('java.os.version',os_version)
    osinfo = os_name,os_version,os_arch
    
    return release,vendor,vminfo,osinfo

### System name aliasing

def system_alias(system,release,version):

    """ Returns (system,release,version) aliased to common
        marketing names used for some systems.

        It also does some reordering of the information in some cases
        where it would otherwise cause confusion.

    """
    if system == 'Rhapsody':
        # Apple's BSD derivative
        # XXX How can we determine the marketing release number ?
        return 'MacOS X Server',system+release,version

    elif system == 'SunOS':
        # Sun's OS
        if release < '5':
            # These releases use the old name SunOS
            return system,release,version
        # Modify release (marketing release = SunOS release - 3)
        l = string.split(release,'.')
        if l:
            try:
                major = int(l[0])
            except ValueError:
                pass
            else:
                major = major - 3
                l[0] = str(major)
                release = string.join(l,'.')
        if release < '6':
            system = 'Solaris'
        else:
            # XXX Whatever the new SunOS marketing name is...
            system = 'Solaris'

    elif system == 'IRIX64':
        # IRIX reports IRIX64 on platforms with 64-bit support; yet it
        # is really a version and not a different platform, since 32-bit
        # apps are also supported..
        system = 'IRIX'
        if version:
            version = version + ' (64bit)'
        else:
            version = '64bit'

    elif system in ('win32','win16'):
        # In case one of the other tricks
        system = 'Windows'

    return system,release,version

### Various internal helpers

def _platform(*args):

    """ Helper to format the platform string in a filename
        compatible format e.g. "system-version-machine".
    """
    # Format the platform string
    platform = string.join(
        map(string.strip,
            filter(len,args)),
        '-')

    # Cleanup some possible filename obstacles...
    replace = string.replace
    platform = replace(platform,' ','_')
    platform = replace(platform,'/','-')
    platform = replace(platform,'\\','-')
    platform = replace(platform,':','-')
    platform = replace(platform,';','-')
    platform = replace(platform,'"','-')
    platform = replace(platform,'(','-')
    platform = replace(platform,')','-')

    # No need to report 'unkown' information...
    platform = replace(platform,'unknown','')

    # Fold '--'s and remove trailing '-'
    while 1:
        cleaned = replace(platform,'--','-')
        if cleaned == platform:
            break
        platform = cleaned
    while platform[-1] == '-':
        platform = platform[:-1]

    return platform

def _node(default=''):

    """ Helper to determine the node name of this machine.
    """
    try:
        import socket
    except ImportError:
        # No sockets...
        return default
    try:
        return socket.gethostname()
    except socket.error:
        # Still not working...
        return default

# os.path.abspath is new in Python 1.5.2:
if not hasattr(os.path,'abspath'):

    def _abspath(path,

                 isabs=os.path.isabs,join=os.path.join,getcwd=os.getcwd,
                 normpath=os.path.normpath):

        if not isabs(path):
            path = join(getcwd(), path)
        return normpath(path)

else:

    _abspath = os.path.abspath

def _follow_symlinks(filepath):

    """ In case filepath is a symlink, follow it until a
        real file is reached.
    """
    filepath = _abspath(filepath)
    while os.path.islink(filepath):
        filepath = os.path.normpath(
            os.path.join(filepath,os.readlink(filepath)))
    return filepath

def _syscmd_uname(option,default=''):

    """ Interface to the system's uname command.
    """
    if sys.platform in ('dos','win32','win16','os2'):
        # XXX Others too ?
        return default
    try:
        f = os.popen('uname %s 2> /dev/null' % option)
    except (AttributeError,os.error):
        return default
    output = string.strip(f.read())
    rc = f.close()
    if not output or rc:
        return default
    else:
        return output

def _syscmd_file(target,default=''):

    """ Interface to the system's file command.

        The function uses the -b option of the file command to have it
        ommit the filename in its output and if possible the -L option
        to have the command follow symlinks. It returns default in
        case the command should fail.

    """
    target = _follow_symlinks(target)
    try:
        f = os.popen('file %s 2> /dev/null' % target)
    except (AttributeError,os.error):
        return default
    output = string.strip(f.read())
    rc = f.close()
    if not output or rc:
        return default
    else:
        return output

### Information about the used architecture

# Default values for architecture; non-empty strings override the
# defaults given as parameters
_default_architecture = {
    'win32': ('','WindowsPE'),
    'win16': ('','Windows'),
    'dos': ('','MSDOS'),
}

def architecture(executable=sys.executable,bits='',linkage='',

                 split=re.compile('[\s,]').split):

    """ Queries the given executable (defaults to the Python interpreter
        binary) for various architecture informations.

        Returns a tuple (bits,linkage) which contain information about
        the bit architecture and the linkage format used for the
        executable. Both values are returned as strings.

        Values that cannot be determined are returned as given by the
        parameter presets. If bits is given as '', the sizeof(pointer)
        (or sizeof(long) on Python version < 1.5.2) is used as
        indicator for the supported pointer size.

        The function relies on the system's "file" command to do the
        actual work. This is available on most if not all Unix
        platforms. On some non-Unix platforms and then only if the
        executable points to the Python interpreter defaults from
        _default_architecture are used.

    """
    # Use the sizeof(pointer) as default number of bits if nothing
    # else is given as default.
    if not bits:
        import struct
        try:
            size = struct.calcsize('P')
        except struct.error:
            # Older installations can only query longs
            size = struct.calcsize('l')
        bits = str(size*8) + 'bit'
    
    # Get data from the 'file' system command
    output = _syscmd_file(executable,'')

    if not output and \
       executable == sys.executable:
        # "file" command did not return anything; we'll try to provide
        # some sensible defaults then... 
        if _default_architecture.has_key(sys.platform):
            b,l = _default_architecture[sys.platform]
            if b:
                bits = b
            if l:
                linkage = l
        return bits,linkage

    # Split the output into a list of strings omitting the filename
    fileout = split(output)[1:]
    
    if 'executable' not in fileout:
        # Format not supported
        return bits,linkage

    # Bits
    if '32-bit' in fileout:
        bits = '32bit'
    elif 'N32' in fileout:
        # On Irix only
        bits = 'n32bit'
    elif '64-bit' in fileout:
        bits = '64bit'

    # Linkage
    if 'ELF' in fileout:
        linkage = 'ELF'
    elif 'PE' in fileout:
        # E.g. Windows uses this format
        if 'Windows' in fileout:
            linkage = 'WindowsPE'
        else:
            linkage = 'PE'
    elif 'COFF' in fileout:
        linkage = 'COFF'
    elif 'MS-DOS' in fileout:
        linkage = 'MSDOS'
    else:
        # XXX the A.OUT format also falls under this class...
        pass

    return bits,linkage

### Portable uname() interface
    
_uname_cache = None

def uname():

    """ Fairly portable uname interface. Returns a tuple
        of strings (system,node,release,version,machine,processor)
        identifying the underlying platform.

        Note that unlike the os.uname function this also returns
        possible processor information as additional tuple entry.

        Entries which cannot be determined are set to ''.

    """
    global _uname_cache

    if _uname_cache is not None:
        return _uname_cache

    # Get some infos from the builtin os.uname API...
    try:
        system,node,release,version,machine = os.uname()

    except AttributeError:
        # Hmm, no uname... we'll have to poke around the system then.
        system = sys.platform
        release = ''
        version = ''
        node = _node()
        machine = ''
        processor = ''
        use_syscmd_ver = 1

        # Try win32_ver() on win32 platforms
        if system == 'win32':
            release,version,csd,ptype = win32_ver()
            if release and version:
                use_syscmd_ver = 0
        
        # Try the 'ver' system command available on some
        # platforms
        if use_syscmd_ver:
            system,release,version = _syscmd_ver(system)

        # In case we still don't know anything useful, we'll try to
        # help ourselves
        if system in ('win32','win16'):
            if not version:
                if system == 'win32':
                    version = '32bit'
                else:
                    version = '16bit'
            system = 'Windows'

        elif system[:4] == 'java':
            release,vendor,vminfo,osinfo = java_ver()
            system = 'Java'
            version = string.join(vminfo,', ')
            if not version:
                version = vendor

        elif os.name == 'mac':
            release,(version,stage,nonrel),machine = mac_ver()
            system = 'MacOS'

    else:
        # System specific extensions
        if system == 'OpenVMS':
            # OpenVMS seems to have release and version mixed up
            if not release or release == '0':
                release = version
                version = ''
            # Get processor information
            try:
                import vms_lib
            except ImportError:
                pass
            else:
                csid, cpu_number = vms_lib.getsyi('SYI$_CPU',0)
                if (cpu_number >= 128):
                    processor = 'Alpha'
                else:
                    processor = 'VAX'
        else:
            # Get processor information from the uname system command
            processor = _syscmd_uname('-p','')

    # 'unkown' is not really any useful as information; we'll convert
    # it to '' which is more portable
    if system == 'unknown':
        system = ''
    if node == 'unknown':
        node = ''
    if release == 'unknown':
        release = ''
    if version == 'unknown':
        version = ''
    if machine == 'unknown':
        machine = ''
    if processor == 'unknown':
        processor = ''
    _uname_cache = system,node,release,version,machine,processor
    return _uname_cache

### Direct interfaces to some of the uname() return values

def system():

    """ Returns the system/OS name, e.g. 'Linux', 'Windows' or 'Java'.

        An empty string is returned if the value cannot be determined.

    """
    return uname()[0]

def node():

    """ Returns the computer's network name (may not be fully qualified !)

        An empty string is returned if the value cannot be determined.

    """
    return uname()[1]

def release():

    """ Returns the system's release, e.g. '2.2.0' or 'NT'

        An empty string is returned if the value cannot be determined.

    """
    return uname()[2]

def version():

    """ Returns the system's release version, e.g. '#3 on degas'

        An empty string is returned if the value cannot be determined.

    """
    return uname()[3]

def machine():

    """ Returns the machine type, e.g. 'i386'

        An empty string is returned if the value cannot be determined.

    """
    return uname()[4]

def processor():

    """ Returns the (true) processor name, e.g. 'amdk6'

        An empty string is returned if the value cannot be
        determined. Note that many platforms do not provide this
        information or simply return the same value as for machine(),
        e.g.  NetBSD does this.

    """
    return uname()[5]

### The Opus Magnum of platform strings :-)

_platform_cache = None
_platform_aliased_cache = None

def platform(aliased=0, terse=0):

    """ Returns a single string identifying the underlying platform
        with as much useful information as possible (but no more :).
        
        The output is intended to be human readable rather than
        machine parseable. It may look different on different
        platforms and this is intended.

        If "aliased" is true, the function will use aliases for
        various platforms that report system names which differ from
        their common names, e.g. SunOS will be reported as
        Solaris. The system_alias() function is used to implement
        this.

        Setting terse to true causes the function to return only the
        absolute minimum information needed to identify the platform.

    """
    global _platform_cache,_platform_aliased_cache

    if not aliased and (_platform_cache is not None):
        return _platform_cache
    elif _platform_aliased_cache is not None:
        return _platform_aliased_cache

    # Get uname information and then apply platform specific cosmetics
    # to it...
    system,node,release,version,machine,processor = uname()
    if machine == processor:
        processor = ''
    if aliased:
        system,release,version = system_alias(system,release,version)

    if system == 'Windows':
        # MS platforms
        rel,vers,csd,ptype = win32_ver(version)
        if terse:
            platform = _platform(system,release)
        else:
            platform = _platform(system,release,version,csd)

    elif system in ('Linux',):
        # Linux based systems
        distname,distversion,distid = dist('')
        if distname and not terse:
            platform = _platform(system,release,machine,processor,
                                 'with',
                                 distname,distversion,distid)
        else:
            # If the distribution name is unknown check for libc vs. glibc
            libcname,libcversion = libc_ver(sys.executable)
            platform = _platform(system,release,machine,processor,
                                 'with',
                                 libcname+libcversion)
    elif system == 'Java':
        # Java platforms
        r,v,vminfo,(os_name,os_version,os_arch) = java_ver()
        if terse:
            platform = _platform(system,release,version)
        else:
            platform = _platform(system,release,version,
                                 'on',
                                 os_name,os_version,os_arch)

    elif system == 'MacOS':
        # MacOS platforms
        if terse:
            platform = _platform(system,release)
        else:
            platform = _platform(system,release,machine)

    else:
        # Generic handler
        if terse:
            platform = _platform(system,release)
        else:
            bits,linkage = architecture(sys.executable)
            platform = _platform(system,release,machine,processor,bits,linkage)
    
    if aliased:
        _platform_aliased_cache = platform
    elif terse:
        pass
    else:
        _platform_cache = platform
    return platform

if __name__ == '__main__':
    # Default is to print the aliased verbose platform string
    terse = 'terse' in sys.argv
    aliased = not 'nonaliased' in sys.argv
    print platform(aliased,terse)
    sys.exit(0)

--------------B32584A17EA1E930287FE86F--




From guido@python.org  Fri Jun 30 15:47:29 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 09:47:29 -0500
Subject: [Python-Dev] Removing modules
In-Reply-To: Your message of "Thu, 29 Jun 2000 21:29:41 -0400."
 <20000629212941.A21563@newcnri.cnri.reston.va.us>
References: <20000629212941.A21563@newcnri.cnri.reston.va.us>
Message-ID: <200006301447.JAA30671@cj20424-a.reston1.va.home.com>

> For the "deleted modules" section of the 2.0 article, I drew up a list
> of modules that might be outdated, mostly the SGI-specific ones.  Are
> those modules still useful, and do the libraries they were written for
> still exist?

Doubtful.  I've asked Sjoerd and Jack, who were most involved in using
these.

> For your cogitation, here's the list: sgimodule.c, glmodule.c (and
> hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c,
> almodule.c, clmodule.c,  knee.py.

I'd like to keep knee.py -- it's a nice piece of *documentation* of
the package import.

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


From guido@python.org  Fri Jun 30 15:55:08 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 09:55:08 -0500
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: Your message of "Fri, 30 Jun 2000 15:40:36 +0200."
 <395CA354.16AC5B7E@lemburg.com>
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>
 <395CA354.16AC5B7E@lemburg.com>
Message-ID: <200006301455.JAA30721@cj20424-a.reston1.va.home.com>

> > Regarding platform.py:
> > 
> > M.-A. Lemburg writes:
> >  > Why not simply include it in distutils ?
> > 
> >   Why not include it in the standard library?
> >   Guido?  I'll document it if Marc-Andre is willing to provide the
> > module and the regression test.
> 
> No objection from here.
> 
> I've attached my most recent copy to this mail. I'm not sure
> how to write the regr. test though since output is dependent
> on the platform running the functions... perhaps I'll just
> add something like the audio thingie: "This string ought
> to identify the platform you are currently running... if not,
> then something is wrong ;-)".

You didn't include it!

But I vote -1 on this one anyway -- it's too much code and almost by
its very nature not something that belongs in a "standard" library.
Plus, I don't want to be responsible for maintaining it.  Sorry,

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


From bwarsaw@beopen.com  Fri Jun 30 14:57:47 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 09:57:47 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>
 <005801bfe270$e140d440$f2a6b5d4@hagrid>
Message-ID: <14684.42843.472230.609828@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <effbot@telia.com> writes:

    FL> btw, now that we're bumping to 2.0, maybe we can break
    FL> socket.connect and friends once again?  if somebody com-
    FL> plains, just tell them "it's a major release, dammit" ;-)

That's a good point.  A bump in major rev number is an /opportunity/
to break things, like a bone that hasn't healed right, so that they
can be fixed correctly.  We'll lose that for 2.0, mostly likely
because of the tight release schedule.  There's always 3.0 though,
which will mesh nicely with the mythical Py3k.

-Barry


From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 15:08:13 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 16:08:13 +0200
Subject: [Python-Dev] New PythonLabs site revealed!
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au><005801bfe270$e140d440$f2a6b5d4@hagrid> <14684.42843.472230.609828@anthem.concentric.net>
Message-ID: <016e01bfe29c$a2e8bb00$f2a6b5d4@hagrid>

barry wrote:
> >>>>> "FL" =3D=3D Fredrik Lundh <effbot@telia.com> writes:
>=20
>     FL> btw, now that we're bumping to 2.0, maybe we can break
>     FL> socket.connect and friends once again?  if somebody com-
>     FL> plains, just tell them "it's a major release, dammit" ;-)
>=20
> That's a good point.  A bump in major rev number is an /opportunity/
> to break things, like a bone that hasn't healed right, so that they
> can be fixed correctly.  We'll lose that for 2.0, mostly likely
> because of the tight release schedule.

yeah, but I'm sure Guido has the patches somewhere (after
all, the 1.6 release notes still mention this change).  if not,
the mad patcher volunteers to fix (or rather, break) this.

Guido?

</F>



From bwarsaw@beopen.com  Fri Jun 30 15:07:47 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 10:07:47 -0400 (EDT)
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6
References: <ECEPKNMJLHAPFFJHDOJBGEBACPAA.mhammond@skippinet.com.au>
 <ECEPKNMJLHAPFFJHDOJBMEBACPAA.mhammond@skippinet.com.au>
Message-ID: <14684.43443.919858.897738@anthem.concentric.net>

>>>>> "MH" == Mark Hammond <mhammond@skippinet.com.au> writes:

    MH> [I wishing mailing-lists would agree on how they handle
    MH> reply-to :-]

It's fundamentally broken, but the problem is in the mail readers
(MUA).  There's no header (that I'm aware of) that portably tells an
MUA - "Hey, for a group follow up, don't go to the original list, go
to THIS one instead, but for an individual followup (i.e. reply) still
address that to the original author."

This is one reason why munging reply-to is evil.  But in this case
we've agreed that following up to python-dev is more important than
preserving the ability to reply to the author.

-Barry


From mal@lemburg.com  Fri Jun 30 15:11:54 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 16:11:54 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>
 <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com>
Message-ID: <395CAAAA.5975A617@lemburg.com>

Guido van Rossum wrote:
> 
> > > Regarding platform.py:
> > >
> > > M.-A. Lemburg writes:
> > >  > Why not simply include it in distutils ?
> > >
> > >   Why not include it in the standard library?
> > >   Guido?  I'll document it if Marc-Andre is willing to provide the
> > > module and the regression test.
> >
> > No objection from here.
> >
> > I've attached my most recent copy to this mail. I'm not sure
> > how to write the regr. test though since output is dependent
> > on the platform running the functions... perhaps I'll just
> > add something like the audio thingie: "This string ought
> > to identify the platform you are currently running... if not,
> > then something is wrong ;-)".
> 
> You didn't include it!

I posted a reply to fix this ;-)
 
> But I vote -1 on this one anyway -- it's too much code and almost by
> its very nature not something that belongs in a "standard" library.
> Plus, I don't want to be responsible for maintaining it.  Sorry,

You don't have to maintain it... I will anyway since it's part
of mxCGIPython.

Anyway, perhaps Greg Ward can find some use for it in
distutils.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 15:18:13 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 16:18:13 +0200
Subject: [Python-Dev] SRE incompatibility
Message-ID: <018401bfe29e$07f26720$f2a6b5d4@hagrid>

my latest changes fixed a couple of things, but broke
one of the old RE tests, namely:

    re.match('\\x00ffffffffffffff', '\377') !=3D None

or in other words, long hexadecimal escapes are cast
down to 8-bit characters in RE.

in SRE (after the latest change), they're cast down to
the size of the engine's internal word size (currently 16
bits).

is the old behaviour worth keeping?  I'd rather not make
the engine dependent on string types; it shouldn't really
matter if you're using unicode patterns on 8-bit target
strings, or vice versa.

</F>



From gward@mems-exchange.org  Fri Jun 30 15:13:40 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Fri, 30 Jun 2000 10:13:40 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 07:29:42PM -0400
References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>
Message-ID: <20000630101340.A16350@ludwig.cnri.reston.va.us>

On 29 June 2000, Fred L. Drake, Jr. said:
> 
> Greg Ward wrote in a checkin message:
>  > On second thought, first try for _winreg, and then winreg.  Only if both
>  > fail do we try for win32api/win32con.  If *those* both fail, then we don't
>  > have registry access.  Phew!
> 
> Guido van Rossum writes on python-dev:
>  > Is this smart?  Doesn't the new winreg have a very different I/F than
>  > the old one?
> 
>   No, this is bad.  It *will* break with winreg; if _winreg isn't
> available, it should use the win32api/win32con/whatever stuff; it's a
> Python 1.5.2 interpreter at that point.

What if it's a 1.6a1 or 1.6a2 interpreter?  Presumably people will try
Distutils 0.9 with them.  Should I remove that feature now that 0.9 is
out, but before Python 2.0b1?

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367


From esr@thyrsus.com  Fri Jun 30 15:27:07 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Fri, 30 Jun 2000 10:27:07 -0400
Subject: [Python-Dev] Removing modules
In-Reply-To: <200006301447.JAA30671@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 09:47:29AM -0500
References: <20000629212941.A21563@newcnri.cnri.reston.va.us> <200006301447.JAA30671@cj20424-a.reston1.va.home.com>
Message-ID: <20000630102707.A27830@thyrsus.com>

Guido van Rossum <guido@python.org>:
> > For the "deleted modules" section of the 2.0 article, I drew up a list
> > of modules that might be outdated, mostly the SGI-specific ones.  Are
> > those modules still useful, and do the libraries they were written for
> > still exist?
> 
> Doubtful.  I've asked Sjoerd and Jack, who were most involved in using
> these.
> 
> > For your cogitation, here's the list: sgimodule.c, glmodule.c (and
> > hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c,
> > almodule.c, clmodule.c,  knee.py.
> 
> I'd like to keep knee.py -- it's a nice piece of *documentation* of
> the package import.

+1 on giving the SGI-specific modules the heave-ho.  

Their presence has always struck me as a sort of vermiform appendix in
a core library otherwise clearly aimed at being as platform-independent
as rdeasonably possible (e.g. given the Unix-vs.Windows differences).
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Power concedes nothing without a demand. It never did, and it never will.
Find out just what people will submit to, and you have found out the exact
amount of injustice and wrong which will be imposed upon them; and these will
continue until they are resisted with either words or blows, or with both.
The limits of tyrants are prescribed by the endurance of those whom they
oppress.
	-- Frederick Douglass, August 4, 1857


From gward@mems-exchange.org  Fri Jun 30 15:22:42 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Fri, 30 Jun 2000 10:22:42 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <395CAAAA.5975A617@lemburg.com>; from mal@lemburg.com on Fri, Jun 30, 2000 at 04:11:54PM +0200
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com>
Message-ID: <20000630102242.B16350@ludwig.cnri.reston.va.us>

On 30 June 2000, M.-A. Lemburg said:
> > But I vote -1 on this one anyway -- it's too much code and almost by
> > its very nature not something that belongs in a "standard" library.
> > Plus, I don't want to be responsible for maintaining it.  Sorry,
> 
> You don't have to maintain it... I will anyway since it's part
> of mxCGIPython.
> 
> Anyway, perhaps Greg Ward can find some use for it in
> distutils.

I looked at platform.py once briefly, and my impression was similar to
Guido's: too big!  All I want(ed) is "osname-cpu" -- linux-i386,
solaris-sparc, whatever.  osversion is optional.

But, consider that that the Distutils might want to know if it should
generate RPMs or Debian packages... then the stuff about grokking which
Linux distribution it's running on is relevant.  Argh!

Anyways, I'm already taking static about too much code in the Distutils,
and I partly agree.  (I agree there's a *lot* of code, I know there are
bits that can be refactored and reduced, but I'm not sure it's too
much.)  So I'll stick with sys.platform for now -- it's good enough.

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367


From sjoerd@oratrix.nl  Fri Jun 30 15:21:53 2000
From: sjoerd@oratrix.nl (Sjoerd Mullender)
Date: Fri, 30 Jun 2000 16:21:53 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32
In-Reply-To: Your message of Fri, 30 Jun 2000 03:29:59 -0700.
 <200006301029.DAA25494@slayer.i.sourceforge.net>
References: <200006301029.DAA25494@slayer.i.sourceforge.net>
Message-ID: <20000630142154.968F831047C@bireme.oratrix.nl>

Why was the change that occurred in revision 2.31 reverted?  Accident?

The change log said:
Jack Jansen: Use include "" instead of <>; and staticforward declarations

On Fri, Jun 30 2000 "M.-A. Lemburg" wrote:

> Update of /cvsroot/python/python/dist/src/Objects
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv25442/Objects
> 
> Modified Files:
> 	unicodeobject.c 
> Log Message:
> Marc-Andre Lemburg <mal@lemburg.com>:
> New buffer overflow checks for formatting strings.
> 
> By Trent Mick.
> 
> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.31
> retrieving revision 2.32
> diff -C2 -r2.31 -r2.32
> *** unicodeobject.c	2000/06/29 00:06:39	2.31
> --- unicodeobject.c	2000/06/30 10:29:57	2.32
> ***************
> *** 67,71 ****
>   #include "mymath.h"
>   #include "unicodeobject.h"
> ! #include "ucnhash.h"
>   
>   #if defined(HAVE_LIMITS_H)
> --- 67,71 ----
>   #include "mymath.h"
>   #include "unicodeobject.h"
> ! #include <ucnhash.h>
>   
>   #if defined(HAVE_LIMITS_H)
> ***************
> *** 1245,1249 ****
>   ucnFallthrough:
>               /* fall through on purpose */
> !         default:
>               *p++ = '\\';
>               *p++ = (unsigned char)s[-1];
> --- 1245,1249 ----
>   ucnFallthrough:
>               /* fall through on purpose */
> ! 		default:
>               *p++ = '\\';
>               *p++ = (unsigned char)s[-1];
> ***************
> *** 1252,1256 ****
>       }
>       if (_PyUnicode_Resize(v, (int)(p - buf)))
> ! 	goto onError;
>       return (PyObject *)v;
>       
> --- 1252,1256 ----
>       }
>       if (_PyUnicode_Resize(v, (int)(p - buf)))
> ! 		goto onError;
>       return (PyObject *)v;
>       
> ***************
> *** 4374,4377 ****
> --- 4374,4378 ----
>   static int
>   formatfloat(Py_UNICODE *buf,
> + 	    size_t buflen,
>   	    int flags,
>   	    int prec,
> ***************
> *** 4379,4382 ****
> --- 4380,4385 ----
>   	    PyObject *v)
>   {
> +     /* fmt = '%#.' + `prec` + `type`
> +        worst case length = 3 + 10 (len of INT_MAX) + 1 = 14 (use 20)*/
>       char fmt[20];
>       double x;
> ***************
> *** 4387,4395 ****
>       if (prec < 0)
>   	prec = 6;
> -     if (prec > 50)
> - 	prec = 50; /* Arbitrary limitation */
>       if (type == 'f' && (fabs(x) / 1e25) >= 1e25)
>   	type = 'g';
>       sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type);
>       return usprintf(buf, fmt, x);
>   }
> --- 4390,4408 ----
>       if (prec < 0)
>   	prec = 6;
>       if (type == 'f' && (fabs(x) / 1e25) >= 1e25)
>   	type = 'g';
>       sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type);
> +     /* worst case length calc to ensure no buffer overrun:
> +          fmt = %#.<prec>g
> +          buf = '-' + [0-9]*prec + '.' + 'e+' + (longest exp
> +             for any double rep.)
> +          len = 1 + prec + 1 + 2 + 5 = 9 + prec
> +        If prec=0 the effective precision is 1 (the leading digit is
> +        always given), therefore increase by one to 10+prec. */
> +     if (buflen <= (size_t)10 + (size_t)prec) {
> + 	PyErr_SetString(PyExc_OverflowError,
> + 	    "formatted float is too long (precision too long?)");
> + 	return -1;
> +     }
>       return usprintf(buf, fmt, x);
>   }
> ***************
> *** 4397,4400 ****
> --- 4410,4414 ----
>   static int
>   formatint(Py_UNICODE *buf,
> + 	  size_t buflen,
>   	  int flags,
>   	  int prec,
> ***************
> *** 4402,4405 ****
> --- 4416,4421 ----
>   	  PyObject *v)
>   {
> +     /* fmt = '%#.' + `prec` + 'l' + `type`
> +        worst case length = 3 + 10 (len of INT_MAX) + 1 + 1 = 15 (use 20)*/
>       char fmt[20];
>       long x;
> ***************
> *** 4410,4413 ****
> --- 4426,4436 ----
>       if (prec < 0)
>   	prec = 1;
> +     /* buf = '+'/'-'/'0'/'0x' + '[0-9]'*max(prec,len(x in octal))
> +        worst case buf = '0x' + [0-9]*prec, where prec >= 11 */
> +     if (buflen <= 13 || buflen <= (size_t)2+(size_t)prec) {
> +         PyErr_SetString(PyExc_OverflowError,
> +             "formatted integer is too long (precision too long?)");
> +         return -1;
> +     }
>       sprintf(fmt, "%%%s.%dl%c", (flags & F_ALT) ? "#" : "", prec, type);
>       return usprintf(buf, fmt, x);
> ***************
> *** 4416,4421 ****
>   static int
>   formatchar(Py_UNICODE *buf,
> ! 	   PyObject *v)
>   {
>       if (PyUnicode_Check(v)) {
>   	if (PyUnicode_GET_SIZE(v) != 1)
> --- 4439,4446 ----
>   static int
>   formatchar(Py_UNICODE *buf,
> !            size_t buflen,
> !            PyObject *v)
>   {
> +     /* presume that the buffer is at least 2 characters long */
>       if (PyUnicode_Check(v)) {
>   	if (PyUnicode_GET_SIZE(v) != 1)
> ***************
> *** 4447,4450 ****
> --- 4472,4485 ----
>   }
>   
> + /* fmt%(v1,v2,...) is roughly equivalent to sprintf(fmt, v1, v2, ...)
> + 
> +    FORMATBUFLEN is the length of the buffer in which the floats, ints, &
> +    chars are formatted. XXX This is a magic number. Each formatting
> +    routine does bounds checking to ensure no overflow, but a better
> +    solution may be to malloc a buffer of appropriate size for each
> +    format. For now, the current solution is sufficient.
> + */
> + #define FORMATBUFLEN (size_t)120
> + 
>   PyObject *PyUnicode_Format(PyObject *format,
>   			   PyObject *args)
> ***************
> *** 4506,4513 ****
>   	    PyObject *v = NULL;
>   	    PyObject *temp = NULL;
> ! 	    Py_UNICODE *buf;
>   	    Py_UNICODE sign;
>   	    int len;
> ! 	    Py_UNICODE tmpbuf[120]; /* For format{float,int,char}() */
>   
>   	    fmt++;
> --- 4541,4548 ----
>   	    PyObject *v = NULL;
>   	    PyObject *temp = NULL;
> ! 	    Py_UNICODE *pbuf;
>   	    Py_UNICODE sign;
>   	    int len;
> ! 	    Py_UNICODE formatbuf[FORMATBUFLEN]; /* For format{float,int,char}() */
>   
>   	    fmt++;
> ***************
> *** 4659,4664 ****
>   
>   	    case '%':
> ! 		buf = tmpbuf;
> ! 		buf[0] = '%';
>   		len = 1;
>   		break;
> --- 4694,4700 ----
>   
>   	    case '%':
> ! 		pbuf = formatbuf;
> ! 		/* presume that buffer length is at least 1 */
> ! 		pbuf[0] = '%';
>   		len = 1;
>   		break;
> ***************
> *** 4696,4700 ****
>   			goto onError;
>   		}
> ! 		buf = PyUnicode_AS_UNICODE(temp);
>   		len = PyUnicode_GET_SIZE(temp);
>   		if (prec >= 0 && len > prec)
> --- 4732,4736 ----
>   			goto onError;
>   		}
> ! 		pbuf = PyUnicode_AS_UNICODE(temp);
>   		len = PyUnicode_GET_SIZE(temp);
>   		if (prec >= 0 && len > prec)
> ***************
> *** 4710,4715 ****
>   		if (c == 'i')
>   		    c = 'd';
> ! 		buf = tmpbuf;
> ! 		len = formatint(buf, flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> --- 4746,4752 ----
>   		if (c == 'i')
>   		    c = 'd';
> ! 		pbuf = formatbuf;
> ! 		len = formatint(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE),
> ! 			flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> ***************
> *** 4719,4725 ****
>   		    if ((flags&F_ALT) &&
>   			(c == 'x' || c == 'X') &&
> ! 			buf[0] == '0' && buf[1] == c) {
> ! 			*res++ = *buf++;
> ! 			*res++ = *buf++;
>   			rescnt -= 2;
>   			len -= 2;
> --- 4756,4762 ----
>   		    if ((flags&F_ALT) &&
>   			(c == 'x' || c == 'X') &&
> ! 			pbuf[0] == '0' && pbuf[1] == c) {
> ! 			*res++ = *pbuf++;
> ! 			*res++ = *pbuf++;
>   			rescnt -= 2;
>   			len -= 2;
> ***************
> *** 4736,4741 ****
>   	    case 'g':
>   	    case 'G':
> ! 		buf = tmpbuf;
> ! 		len = formatfloat(buf, flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> --- 4773,4779 ----
>   	    case 'g':
>   	    case 'G':
> ! 		pbuf = formatbuf;
> ! 		len = formatfloat(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE),
> ! 			flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> ***************
> *** 4746,4751 ****
>   
>   	    case 'c':
> ! 		buf = tmpbuf;
> ! 		len = formatchar(buf, v);
>   		if (len < 0)
>   		    goto onError;
> --- 4784,4789 ----
>   
>   	    case 'c':
> ! 		pbuf = formatbuf;
> ! 		len = formatchar(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), v);
>   		if (len < 0)
>   		    goto onError;
> ***************
> *** 4759,4764 ****
>   	    }
>   	    if (sign) {
> ! 		if (*buf == '-' || *buf == '+') {
> ! 		    sign = *buf++;
>   		    len--;
>   		}
> --- 4797,4802 ----
>   	    }
>   	    if (sign) {
> ! 		if (*pbuf == '-' || *pbuf == '+') {
> ! 		    sign = *pbuf++;
  		    len--;
>   		}
> ***************
> *** 4796,4800 ****
>   	    if (sign && fill == ' ')
>   		*res++ = sign;
> ! 	    memcpy(res, buf, len * sizeof(Py_UNICODE));
>   	    res += len;
>   	    rescnt -= len;
> --- 4834,4838 ----
>   	    if (sign && fill == ' ')
>   		*res++ = sign;
> ! 	    memcpy(res, pbuf, len * sizeof(Py_UNICODE));
>   	    res += len;
>   	    rescnt -= len;
> 
> 

-- Sjoerd Mullender <sjoerd.mullender@oratrix.com>


From akuchlin@mems-exchange.org  Fri Jun 30 15:29:00 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 30 Jun 2000 10:29:00 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jun 30, 2000 at 04:18:13PM +0200
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid>
Message-ID: <20000630102900.A19597@kronos.cnri.reston.va.us>

On Fri, Jun 30, 2000 at 04:18:13PM +0200, Fredrik Lundh wrote:
>    re.match('\\x00ffffffffffffff', '\377') != None
>or in other words, long hexadecimal escapes are cast
>down to 8-bit characters in RE.

This is for compatibility with Python string literals:

kronos Python-1.6>./python
>>> '\x00fffffff'
'\377'
>>> u'\x00fffffff'
u'\uFFFF'

(Where do these semantics come from, BTW?  C's \x seems to take any
number of hex digits but then reports an error if the character is
greater than 256, too large to fit into a byte.)

Note that the \u escape for Unicode characters uses exactly 4 digits,
no more, no less.  It would certainly be simpler and clearer to only
support a fixed number of digits with \x, since I find the casting
down behaviour is magical and not obvious.  But I don't know if we
want to make that change now.  (Guido now realizes the downside to
numbering it 2.0, as everyone hurries to suggest their favorite
backward-incompatible change.)

That doesn't help with regexes, of course, since a pattern might be
written as a regular string but be intended to match Unicode.  Maybe
the simplest rule is the best; always take 4 digits, even if it winds
up being incompatible with the \x in string literals.

--amk


From fdrake@beopen.com  Fri Jun 30 15:33:47 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 10:33:47 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: <20000630101340.A16350@ludwig.cnri.reston.va.us>
References: <200006292305.QAA11929@slayer.i.sourceforge.net>
 <200006300020.TAA21877@cj20424-a.reston1.va.home.com>
 <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>
 <20000630101340.A16350@ludwig.cnri.reston.va.us>
Message-ID: <14684.45003.193701.382599@cj42289-a.reston1.va.home.com>

Greg Ward writes:
 > What if it's a 1.6a1 or 1.6a2 interpreter?  Presumably people will try
 > Distutils 0.9 with them.  Should I remove that feature now that 0.9 is
 > out, but before Python 2.0b1?

  You're placing too much value on code labelled "alpha". ;)  There
are two interesting versions -- 1.5.2 (since you scrapped support for
versions before that), and 2.0.  And the CVS version is the closest
approximation to 2.0 that anyone has.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Fri Jun 30 15:38:51 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 10:38:51 -0400 (EDT)
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <20000630102242.B16350@ludwig.cnri.reston.va.us>
References: <20000629233003.A1766@beelzebub>
 <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
 <395C681D.C3211F6@lemburg.com>
 <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>
 <395CA354.16AC5B7E@lemburg.com>
 <200006301455.JAA30721@cj20424-a.reston1.va.home.com>
 <395CAAAA.5975A617@lemburg.com>
 <20000630102242.B16350@ludwig.cnri.reston.va.us>
Message-ID: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>

Greg Ward writes:
 > But, consider that that the Distutils might want to know if it should
 > generate RPMs or Debian packages... then the stuff about grokking which
 > Linux distribution it's running on is relevant.  Argh!

  Why would you need to figure this out?  Are you selecting a
platform-specific packaging system automatically?  In that case, I'd
search for the presence of the tools rather than asking what sort of
distribution you're running on -- several distros use RPM, a few use
.deb packages, etc.  When the user specifies one on the command line,
just use the one they name and be done with it.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From mal@lemburg.com  Fri Jun 30 15:53:31 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 16:53:31 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects
 unicodeobject.c,2.31,2.32
References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl>
Message-ID: <395CB46B.34053D3E@lemburg.com>

> Why was the change that occurred in revision 2.31 reverted?  Accident?
> 
> The change log said:
> Jack Jansen: Use include "" instead of <>; and staticforward declarations

Accident... I'll revert that change.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From guido@python.org  Fri Jun 30 17:07:16 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 11:07:16 -0500
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: Your message of "Fri, 30 Jun 2000 16:18:13 +0200."
 <018401bfe29e$07f26720$f2a6b5d4@hagrid>
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid>
Message-ID: <200006301607.LAA10829@cj20424-a.reston1.va.home.com>

> my latest changes fixed a couple of things, but broke
> one of the old RE tests, namely:
> 
>     re.match('\\x00ffffffffffffff', '\377') != None
> 
> or in other words, long hexadecimal escapes are cast
> down to 8-bit characters in RE.
> 
> in SRE (after the latest change), they're cast down to
> the size of the engine's internal word size (currently 16
> bits).
> 
> is the old behaviour worth keeping?  I'd rather not make
> the engine dependent on string types; it shouldn't really
> matter if you're using unicode patterns on 8-bit target
> strings, or vice versa.

To someone familiar with '\x00ffffffffffffff' == '\377', the failure
is surprising.  What Would Larry Do?  (I.e. is this in Perl?)

Maybe make it dependent on the type of the searched string ('\377')
rather than on the type of the pattern?

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


From skip@mojam.com (Skip Montanaro)  Fri Jun 30 14:54:49 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 30 Jun 2000 08:54:49 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <20000629232733.D24811@activestate.com>
References: <200006300608.XAA13124@slayer.i.sourceforge.net>
 <20000629232733.D24811@activestate.com>
Message-ID: <14684.42665.221905.911205@beluga.mojam.com>

    Trent> Cool

Thanks.

    >> To run the entire test suite, make the "test" target at the top level:
    >> 
    >> cd ...
    >> make test

    Trent> This is a UN*Xism, on Windows and UN*X:
    Trent> cd ...\Lib\test
    Trent> python regrtest.py

Thanks, I'll check into it.  I'm a Unix weenie so am (blissfully) unaware of 
how Windows weenies do these things... ;-)

    Trent> A sample walk through to create a test might make it more
    Trent> approachable for people. As well, it would be helpful to mention
    Trent> test_support.{verbose|TESTFN|...}.  But I have no right to bitch
    Trent> about good work.

I'll check into that as well.  The README file was created in about 30
minutes and was a good excuse to test my checkin capabilities on something
that wouldn't break anything. ;-)

Skip


From mhammond@skippinet.com.au  Fri Jun 30 16:48:43 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Sat, 1 Jul 2000 01:48:43 +1000
Subject: [Python-Dev] Checked in new PC\config.h
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEBPCPAA.mhammond@skippinet.com.au>

Hi all,
	I noticed that PC\config.h still had a reference to "Python16.lib".  I
simply checked in a new version without submitting a patch or following any
other process.  I hope this was appropriate.

Mark.



From akuchlin@mems-exchange.org  Fri Jun 30 17:03:48 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 30 Jun 2000 12:03:48 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <200006301607.LAA10829@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 11:07:16AM -0500
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com>
Message-ID: <20000630120348.C19597@kronos.cnri.reston.va.us>

On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote:
>To someone familiar with '\x00ffffffffffffff' == '\377', the failure
>is surprising.  What Would Larry Do?  (I.e. is this in Perl?)

It uses two digits: "\x00ffff" is the string "<binary 0>ffff".

>Maybe make it dependent on the type of the searched string ('\377')
>rather than on the type of the pattern?

Won't work; you could just be compiling a pattern to make a regex
object, and have no idea what you're matching against.

--amk


From jeremy@beopen.com  Fri Jun 30 17:10:09 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 12:10:09 -0400 (EDT)
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid>
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid>
Message-ID: <14684.50785.245652.345591@bitdiddle.concentric.net>

I don't know if this is related, exactly, but there is some kind of
problem with the current test.

When I run make test, I see:

test test_sre crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation

tabnanny thinks test_sre.py is fine, so I'm not sure what the problem
is.

Jeremy


From tpeters@beopen.com  Fri Jun 30 17:18:03 2000
From: tpeters@beopen.com (Tim Peters)
Date: Fri, 30 Jun 2000 12:18:03 -0400
Subject: [Python-Dev] Checked in new PC\config.h
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEBPCPAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEHDGHAA.tim_one@email.msn.com>

[Mark Hammond]
> 	I noticed that PC\config.h still had a reference to
> "Python16.lib".  I simply checked in a new version without
> submitting a patch or following any other process.  I hope
> this was appropriate.

IMO, if you're an expert in an area and need to make a change in that area
that indeed needs to be made and isn't going to screw anybody (and because
you're an expert in that area, you're not wrong in your judgment of that
<wink>), just do it!  We'll see the diffs come by later.  Guido, Barry,
Jeremy, & Fred have been working that way a long time now.  If they didn't
want us to work that way too, they shouldn't have given us the ability to
commit.

empowering-the-masses-ly y'rs  - tim




From guido@python.org  Fri Jun 30 18:18:10 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 12:18:10 -0500
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: Your message of "Fri, 30 Jun 2000 12:03:48 -0400."
 <20000630120348.C19597@kronos.cnri.reston.va.us>
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com>
 <20000630120348.C19597@kronos.cnri.reston.va.us>
Message-ID: <200006301718.MAA12448@cj20424-a.reston1.va.home.com>

> On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote:
> >To someone familiar with '\x00ffffffffffffff' == '\377', the failure
> >is surprising.  What Would Larry Do?  (I.e. is this in Perl?)
> 
> It uses two digits: "\x00ffff" is the string "<binary 0>ffff".
> 
> >Maybe make it dependent on the type of the searched string ('\377')
> >rather than on the type of the pattern?
> 
> Won't work; you could just be compiling a pattern to make a regex
> object, and have no idea what you're matching against.

OK.  Let's change our spec.

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


From guido@python.org  Fri Jun 30 18:26:51 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 12:26:51 -0500
Subject: [Python-Dev] Checked in new PC\config.h
In-Reply-To: Your message of "Fri, 30 Jun 2000 12:18:03 -0400."
 <LNBBLJKPBEHFEDALKOLCMEHDGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCMEHDGHAA.tim_one@email.msn.com>
Message-ID: <200006301726.MAA12560@cj20424-a.reston1.va.home.com>

> IMO, if you're an expert in an area and need to make a change in that area
> that indeed needs to be made and isn't going to screw anybody (and because
> you're an expert in that area, you're not wrong in your judgment of that
> <wink>), just do it!  We'll see the diffs come by later.  Guido, Barry,
> Jeremy, & Fred have been working that way a long time now.  If they didn't
> want us to work that way too, they shouldn't have given us the ability to
> commit.

Exactly!

So far it's working like a charm!

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


From tpeters@beopen.com  Fri Jun 30 17:38:21 2000
From: tpeters@beopen.com (Tim Peters)
Date: Fri, 30 Jun 2000 12:38:21 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <20000630102900.A19597@kronos.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEHFGHAA.tim_one@email.msn.com>

[Andrew Kuchling]
> ...
> This is for compatibility with Python string literals:
>
> kronos Python-1.6>./python
> >>> '\x00fffffff'
> '\377'
> >>> u'\x00fffffff'
> u'\uFFFF'
>
> (Where do these semantics come from, BTW?  C's \x seems to take any
> number of hex digits but then reports an error if the character is
> greater than 256, too large to fit into a byte.)

The behavior of \x in C is mostly implementation-defined.  The committee
knew that C had to do *something* to support "large characters" down the
road, but in those early days they had no clear idea exactly what.  So,
rather than do something sensible <0.5 wink>, they invented a perfectly
general mechanism without portable semantics.  "C itself" isn't complaining
if the character "is greater than 256", it's the specific implementation of
C you're using that's complaining.  A different implementation is free to (&
probably will!) do something different.

Guido adopted the most commonly implemented semantics (ignore all but the
last byte) in Python, apparently under the delusion that this would be a
Good Thing <wink>.  Marc-Andre followed suit by generalizing this madness to
Unicode.

> Note that the \u escape for Unicode characters uses exactly 4 digits,
> no more, no less.

I pushed for that obnoxiously.  Glad you appreciate it <wink>.  Java does
the same.

> It would certainly be simpler and clearer to only support a fixed
> number of digits with \x, since I find the casting down behaviour is
> magical and not obvious.

Yes, it's basically nuts.

> But I don't know if we want to make that change now.

No from me, because it may break stuff.  Wait for Python 2.0 <ahem>.

> (Guido now realizes the downside to numbering it 2.0, as everyone
> hurries to suggest their favorite backward-incompatible change.)

Guido always realized that, I believe.  It's a "least of evils" kind of
thing, mixed with a celebration, not a pure win.

> That doesn't help with regexes, of course, since a pattern might be
> written as a regular string but be intended to match Unicode.  Maybe
> the simplest rule is the best; always take 4 digits, even if it winds
> up being incompatible with the \x in string literals.

I vote for backward compatibility for now, and not only because that will
irritate /F the most.




From bwarsaw@beopen.com  Fri Jun 30 17:51:15 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 12:51:15 -0400 (EDT)
Subject: [Python-Dev] --with-cycle-gc switch
Message-ID: <14684.53251.309942.13110@anthem.concentric.net>

I don't like --with-cycle-gc as the configure switch, and
unfortunately configure is explicitly designed not to complain about
bogus switches.  I just typed --without-gc and was momentarily
surprised that the module was still enabled.

I propose to change the switch to --with(out)-gc and to not recognize
--with(out)-cycle-gc.  The switch hasn't been there long enough to
support both.

-Barry


From jeremy@beopen.com  Fri Jun 30 18:02:42 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 13:02:42 -0400 (EDT)
Subject: [Python-Dev] --with-cycle-gc switch
In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net>
References: <14684.53251.309942.13110@anthem.concentric.net>
Message-ID: <14684.53938.307841.921051@bitdiddle.concentric.net>

The problem with the name --without-gc is that it suggests a build
without any garbage collection.  The new patch only handles one
special case of garbage collection.  The name --without-cycle-gc is a
little unwieldy, but clearer.

Jeremy


From Vladimir.Marangozov@inrialpes.fr  Fri Jun 30 18:11:50 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 19:11:50 +0200 (CEST)
Subject: [Python-Dev] --with-cycle-gc switch
In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 12:51:15 PM
Message-ID: <200006301711.TAA21382@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> I propose to change the switch to --with(out)-gc and to not recognize
> --with(out)-cycle-gc.  The switch hasn't been there long enough to
> support both.

-0

for the reason summarized by Jeremy

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 18:33:55 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 19:33:55 +0200
Subject: [Python-Dev] SRE: a minor glitch in re.py
References: <200006301625.JAA32503@slayer.i.sourceforge.net>
Message-ID: <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid>

from the new re.py:

> ! # change this to "pre" if your regexps stopped working.  don't
> ! # forget to send a bug report to <some suitable address>

is bugs-py@python.org suitable?

or should we refer people to=20
http://www.python.org/search/search_bugs.html

or should they pester me directly? (i.e. effbot@telia.com)

</F>




From guido@python.org  Fri Jun 30 19:33:46 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 13:33:46 -0500
Subject: [Python-Dev] SRE: a minor glitch in re.py
In-Reply-To: Your message of "Fri, 30 Jun 2000 19:33:55 +0200."
 <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid>
References: <200006301625.JAA32503@slayer.i.sourceforge.net>
 <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid>
Message-ID: <200006301833.NAA18667@cj20424-a.reston1.va.home.com>

> from the new re.py:
> 
> > ! # change this to "pre" if your regexps stopped working.  don't
> > ! # forget to send a bug report to <some suitable address>
> 
> is bugs-py@python.org suitable?
> 
> or should we refer people to 
> http://www.python.org/search/search_bugs.html
> 
> or should they pester me directly? (i.e. effbot@telia.com)

Probably.  You decide and check it in!

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


From bwarsaw@beopen.com  Fri Jun 30 18:39:12 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 13:39:12 -0400 (EDT)
Subject: [Python-Dev] --with-cycle-gc switch
References: <14684.53251.309942.13110@anthem.concentric.net>
 <200006301711.TAA21382@python.inrialpes.fr>
Message-ID: <14684.56128.700037.255534@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr> writes:

    VM> -0

    VM> for the reason summarized by Jeremy

Okay, I'll leave it alone.


From Vladimir.Marangozov@inrialpes.fr  Fri Jun 30 18:52:15 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 19:52:15 +0200 (CEST)
Subject: [Python-Dev] Oops on AIX
Message-ID: <200006301752.TAA22474@python.inrialpes.fr>

After the CVS commit storm that occurred during the last 3 days,
I wanted to validate the current build on AIX. And I am stalled.

I am not sure, but it seems like the errors I get relate with the
latest 64-bit support patches, and I don't dare to suggest corrections
in this area, so I welcome any help...


        xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c
"methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed.

        xlc_r  -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c
"./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined.
"./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h.
make: 1254-004 The error code from the last command is 1.

Thanks.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 18:53:45 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 19:53:45 +0200
Subject: [Python-Dev] SRE incompatibility
References: <LNBBLJKPBEHFEDALKOLCAEHFGHAA.tim_one@email.msn.com>
Message-ID: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid>

tim wrote:
> > That doesn't help with regexes, of course, since a pattern might be
> > written as a regular string but be intended to match Unicode.  Maybe
> > the simplest rule is the best; always take 4 digits, even if it =
winds
> > up being incompatible with the \x in string literals.
>=20
> I vote for backward compatibility for now, and not only because that =
will
> irritate /F the most.

backward compatibility with what?  8-bit string literals or unicode
string literals?

the problem here is that the pattern is compiled once (from either
8-bit or unicode strings), and can then be used on either 8-bit or
unicode targets.  to be fully backwards compatible, this means that
the compiler should use 8 bits, no matter what string type you're
using.

another solution would be to use the type of the pattern string to
choose between 8 and 16 bits.  I almost implemented that, before
I realized that it broke the following rather nice property:

    sre.compile("some pattern") =3D=3D sre.compile(u"some pattern")

(well, the pattern type doesn't implement __cmp__, but you get the
idea).  the current implementation guarantees "=3D=3D", but I'm planning
to change that to "is" (!).

anyway, I suspect it's too late to change this in 2.0b1.  if enough
people complain about this, we can always label it a "critical bug",
and do something about it in b2.

</F>



From bwarsaw@beopen.com  Fri Jun 30 19:04:06 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 14:04:06 -0400 (EDT)
Subject: [Python-Dev] Odd behavior with `make test'
Message-ID: <14684.57622.9807.868551@anthem.concentric.net>

make test is behaving strangely.  The first time I ran it I got

test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation

which I believe Jeremy has seen with test_sre.  tabnanny says
everything's fine, and running the module manually (and individually
w/ regrtest) shows no problems with the test.

Similarly, I got a different crash in test_sre.  It says:

test test_sre failed -- sre.search

and I also get

test test_re failed -- re.search

I'm also getting bizare stuff like

test test_strftime crashed -- exceptions.AttributeError : match
test test_tokenize crashed -- exceptions.AttributeError : compile
test test_xmllib crashed -- exceptions.AttributeError : compile

This is all with a CVS updated Python 2.0b1.

Now if I run "./python Lib/test/test_mmap.py" manually, this succeeds,
and now either the failures go away or are transmorgrified into
something more reasonable:

mmap, strftime, tokenize, sre, and xmllib all pass.

test_re still fails, but this time with

test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou"

Blowing away the Lib/test/*.pyc's doesn't seem to re-trigger the
problem once it's fixed, but doing a `make distclean' and `make test'
gets me back to the initial situation.

Weird!
-Barry


From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 19:12:11 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:12:11 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
References: <20000629232733.D24811@activestate.com> <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com> <20000629235247.A25090@activestate.com>
Message-ID: <037e01bfe2be$b814d5a0$f2a6b5d4@hagrid>

trent wrote:
> On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote:
> > BTW, I'd just like to say what a delight it is to work with *all* of =
you
> > folks!
>=20
> I feel a group hug coming on in the morning. Or maybe I am just moved =
by the
> beer that I had for dinner. :)

beer for dinner?  what an excellent idea.  didn't I have
some strong lager somewhere?

ah, yes...

hey, maybe I should rewrite the SRE core again, to get
rid of those last glitches...



From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 19:15:37 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:15:37 +0200
Subject: [Python-Dev] Odd behavior with `make test'
References: <14684.57622.9807.868551@anthem.concentric.net>
Message-ID: <038601bfe2bf$31c52da0$f2a6b5d4@hagrid>

> test_re still fails, but this time with
>=20
> test test_re failed -- Writing: '=3D=3D=3D Failed incorrectly', =
expected: "('abc', 'abc', 0, 'fou"

note that test_re should fail; someone (me?) needs to
regenerate the output file.

the rest looks a bit scary, to say the least.  does someone (sre?)
overwrite something? does anyone have purify (dmalloc, fences,
whatever) within reach?

</F>



From Vladimir.Marangozov@inrialpes.fr  Fri Jun 30 19:22:03 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 20:22:03 +0200 (CEST)
Subject: [Python-Dev] Odd behavior with `make test'
In-Reply-To: <14684.57622.9807.868551@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 02:04:06 PM
Message-ID: <200006301822.UAA22606@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> make test is behaving strangely.  The first time I ran it I got

On which platform? Linux seems to do fine with most of this.
On AIX (after some hacking related to my previous msg "Oops on AIX",
I managed to compile everything but I'll dump an error log on Trent :-)

> 
> test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation

same here

> test test_sre failed -- sre.search
> ...
> test test_re failed -- re.search
> ...
> test test_strftime crashed -- exceptions.AttributeError : match
> test test_tokenize crashed -- exceptions.AttributeError : compile
> test test_xmllib crashed -- exceptions.AttributeError : compile

same here. I believe Guido & al. are aware as per the checkin msg,
saying that  /F promises to fix this.

But on AIX I get in addition to the above failures:

test test_array failed -- array('b') overflowed assigning -128L


-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From tpeters@beopen.com  Fri Jun 30 19:20:46 2000
From: tpeters@beopen.com (Tim Peters)
Date: Fri, 30 Jun 2000 14:20:46 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEHLGHAA.tim_one@email.msn.com>

[Tim]
> I vote for backward compatibility for now, and not only because
> that will irritate /F the most.

[/F]
> backward compatibility with what?

1.5.2.

> 8-bit string literals

At least, because they were in 1.5.2.

> or unicode string literals?

I'm sorry \x escapes are even allowed in those -- \x notation is a gimmick
for making strings hold arbitrary binary data, which we're trying to get
away from.  To the extent that they make any sense at all in Unicode
strings, \u should be used instead.

> the problem here is that the pattern is compiled once (from either
> 8-bit or unicode strings), and can then be used on either 8-bit or
> unicode targets.  to be fully backwards compatible, this means that
> the compiler should use 8 bits, no matter what string type you're
> using.

Unicode strings weren't in 1.5.2, so there can't possibly be a backwards
compatibility issue with them -- at least not in the sense I'm using the
phrase here.

> another solution would be to use the type of the pattern string to
> choose between 8 and 16 bits.  I almost implemented that, before
> I realized that it broke the following rather nice property:
>
>     sre.compile("some pattern") == sre.compile(u"some pattern")
>
> (well, the pattern type doesn't implement __cmp__, but you get the
> idea).  the current implementation guarantees "==", but I'm planning
> to change that to "is" (!).

Do you mean that, e.g.,

    sre.compile("\u0045") == sre.compile(u"\u0045")

too?  If so, that doesn't make any sense to me (interpreting \u in 8-bit
strings is even more confused than interpreting \x in Unicode strings).  But
if you didn't mean to include this case, then the equality doesn't actually
hold now, so there's nothing to preserve <wink>.

> anyway, I suspect it's too late to change this in 2.0b1.  if enough
> people complain about this, we can always label it a "critical bug",
> and do something about it in b2.

I think the real problem here was MAL's generalization of \x to 2-byte stuff
in Unicode strings.  If Unicode strings *have* to support \x, then

    \x0123456789abcdef

in Unicode strings should act like

    \u00ef

in Unicode strings, and SRE should play along with that too.  \x was broken
to begin with; better to wipe it out than try to generalize it.

OTOH, I didn't get much sleep last night <0.8 wink>.




From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 19:29:54 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:29:54 +0200
Subject: [Python-Dev] Odd behavior with `make test'
References: <200006301822.UAA22606@python.inrialpes.fr>
Message-ID: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid>

> > test test_sre failed -- sre.search
> > ...
> > test test_re failed -- re.search
> > ...
> > test test_strftime crashed -- exceptions.AttributeError : match
> > test test_tokenize crashed -- exceptions.AttributeError : compile
> > test test_xmllib crashed -- exceptions.AttributeError : compile
>=20
> same here. I believe Guido & al. are aware as per the checkin msg,
> saying that  /F promises to fix this.

I have no idea what causes this.

however, I just noticed that evil tabs had snucked their way into
sre_parse and sre_compile.  new, properly untabified versions are
on their way to the repository.

maybe the interpreter messes up badly once -tt has reported an
error?  try removing -tt from the TESTPYTHON line in the makefile,
and see what happens.

</F>



From gward@mems-exchange.org  Fri Jun 30 19:26:51 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Fri, 30 Jun 2000 14:26:51 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jun 30, 2000 at 10:38:51AM -0400
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> <20000630102242.B16350@ludwig.cnri.reston.va.us> <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>
Message-ID: <20000630142650.B16028@ludwig.cnri.reston.va.us>

On 30 June 2000, Fred L. Drake, Jr. said:
>   Why would you need to figure this out?  Are you selecting a
> platform-specific packaging system automatically?  In that case, I'd
> search for the presence of the tools rather than asking what sort of
> distribution you're running on -- several distros use RPM, a few use
> .deb packages, etc.  When the user specifies one on the command line,
> just use the one they name and be done with it.

Currently it's up to the user to decide which kind of built distribution
they want, with stupid defaults: dumb tarball for Unix, dumb ZIP file
for Windows.  If you want an RPM or a Windows installer, you have to say 
so explicitly.  This is not a big deal, but it might be nice to detect
automatically if we can build (say) RPMs and do so.

This is not a high-priority feature, though.  I'll accept a patch if
someone out there is interested enough to implement it.

        Greg


From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 19:37:16 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:37:16 +0200
Subject: [Python-Dev] SRE incompatibility
References: <LNBBLJKPBEHFEDALKOLCEEHLGHAA.tim_one@email.msn.com>
Message-ID: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid>

tim wrote:
> > to be fully backwards compatible, this means that the compiler
> > should use 8 bits, no matter what string type you're using.
...
> I think the real problem here was MAL's generalization of \x to 2-byte =
stuff
> in Unicode strings.  If Unicode strings *have* to support \x, then
>=20
>     \x0123456789abcdef
>=20
> in Unicode strings should act like
>=20
>     \u00ef
>=20
> in Unicode strings, and SRE should play along with that too.  \x was =
broken
> to begin with; better to wipe it out than try to generalize it.

I think this means that we agree -- \x is a wart that can only
be used to embed *binary bytes* in a string.

</F>



From Vladimir.Marangozov@inrialpes.fr  Fri Jun 30 19:37:35 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 20:37:35 +0200 (CEST)
Subject: [Python-Dev] Odd behavior with `make test'
In-Reply-To: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 30, 2000 08:29:54 PM
Message-ID: <200006301837.UAA22688@python.inrialpes.fr>

Fredrik Lundh wrote:
> 
> maybe the interpreter messes up badly once -tt has reported an
> error?  try removing -tt from the TESTPYTHON line in the makefile,
> and see what happens.

Matches Barry's report exactly.
To which I'll add the array('b') failure which is not due to an
optimization of arraymodule.c. Will investigate this tonight.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From DavidA@ActiveState.com  Fri Jun 30 19:43:14 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Fri, 30 Jun 2000 11:43:14 -0700
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <200006301455.JAA30721@cj20424-a.reston1.va.home.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJEEGJCLAA.DavidA@ActiveState.com>

> But I vote -1 on this one anyway -- it's too much code and almost by
> its very nature not something that belongs in a "standard" library.
> Plus, I don't want to be responsible for maintaining it.  Sorry,
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Not that I hope to override the heavy -1, but I don't agree with the second
point.  It embodies a huge amount of knowledge that is needed to write
portable code.  As such, IMO, it _does_ belong in the standard library.  How
is it different in its nature from sys.platform, which is only a much weaker
version of the same concept?

--david



From skip@mojam.com (Skip Montanaro)  Fri Jun 30 18:35:20 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 30 Jun 2000 12:35:20 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5
In-Reply-To: <200006301841.LAA20523@slayer.i.sourceforge.net>
References: <200006301841.LAA20523@slayer.i.sourceforge.net>
Message-ID: <14684.55896.890339.982232@beluga.mojam.com>

    Fred> The new copyright / license.
    ...
    Fred> ! ...  IN NO EVENT SHALL THE REGENTS OR
    Fred> ! CONTRIBUTORS BE LIABLE FOR ...

Who are the "regents" and the "contributors"?  Should those terms be
defined somewhere?

not-a-lawyer-and-never-wanted-to-be-ly y'rs,

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."


From nascheme@enme.ucalgary.ca  Fri Jun 30 19:53:06 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 12:53:06 -0600
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1
In-Reply-To: <14684.7005.661874.713000@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 11:00:29PM -0500
References: <200006300502.WAA03286@slayer.i.sourceforge.net> <14684.7005.661874.713000@beluga.mojam.com>
Message-ID: <20000630125306.B32568@acs.ucalgary.ca>

--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Jun 29, 2000 at 11:00:29PM -0500, Skip Montanaro wrote:
> I can all but guarantee you this test will always fail.  Printing absolute
> machine addresses (via calls to id() in this case) in test cases should be
> verboten.

This test script should be better.  It doesn't generate any
output (the stuff the old script printed was pretty useless
anyhow).

  Neil

--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="test_gc.py"

import gc
from test_support import *

def test_list():
    l = []
    l.append(l)
    gc.collect()
    del l
    assert gc.collect() == 1

def test_dict():
    d = {}
    d[1] = d
    gc.collect()
    del d
    assert gc.collect() == 1

def test_tuple():
    l = []
    t = (l,)
    l.append(t)
    gc.collect()
    del t
    del l
    assert gc.collect() == 2

def test_class():
    class A:
        pass
    A.a = A
    gc.collect()
    del A
    assert gc.collect() > 0

def test_instance():
    class A:
        pass
    a = A()
    a.a = a
    gc.collect()
    del a
    assert gc.collect() > 0

def test_method():
    class A:
        def __init__(self):
            self.init = self.__init__
    a = A()
    gc.collect()
    del a
    assert gc.collect() > 0

def test_finalizer():
    class A:
        def __del__(self): pass
    class B:
        pass
    a = A()
    a.a = a
    id_a = id(a)
    b = B()
    b.b = b
    gc.collect()
    del a
    del b
    assert gc.collect() > 0
    for obj in gc.garbage:
        if id(obj) == id_a:
            return
    raise TestFailed

def test_function():
    d = {}
    exec("def f(): pass\n") in d
    gc.collect()
    del d
    assert gc.collect() > 0


def test_all():
    threshold = gc.get_threshold()
    gc.set_threshold(0) # disable automatic collection
    gc.collect()
    test_list()
    test_dict()
    test_tuple()
    test_class()
    test_instance()
    test_method()
    test_finalizer()
    test_function()
    apply(gc.set_threshold, threshold)

test_all()

--AqsLC8rIMeq19msA--


From tpeters@beopen.com  Fri Jun 30 19:51:59 2000
From: tpeters@beopen.com (Tim Peters)
Date: Fri, 30 Jun 2000 14:51:59 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEHOGHAA.tim_one@email.msn.com>

[/F]
> I think this means that we agree -- \x is a wart that can only
> be used to embed *binary bytes* in a string.

We certainly agree about that part!  I thought my

> I'm sorry \x escapes are even allowed in [u-strings] -- \x notation
> is a gimmick for making strings hold arbitrary binary data, which
> we're trying to get away from.  To the extent that they make any
> sense at all in Unicode strings, \u should be used instead.

was pretty explicit <wink>.

What we may still disagree on is how SRE should deal with the \x mess.  I'm
in favor of making \x mean "just the last byte" in plain and Unicode
strings -- do the least harm with this (mis)feature.  Making \x mean
anything other than that for plain strings, regardless of context, is not
backward compatible (with 1.5.2).  And since Unicode strings haven't been
released yet, it's not too late to change what they do with \x.

That would make SRE's job clear here, yes?  And in a way that allows the
now-failing test to pass again?




From skip@mojam.com (Skip Montanaro)  Fri Jun 30 18:43:21 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 30 Jun 2000 12:43:21 -0500 (CDT)
Subject: [Python-Dev] "make test" vs. "-tt"
Message-ID: <14684.56377.293211.329273@beluga.mojam.com>

Per Fredrik's suggestion, I changed "-tt" to simply "-t".  I've not yet done
a "cvs update" to grab the tab-corrected versions of whatever files were
causing the indigestion.  I'm down to a single test failure (test_re) now
when running "make test" before .py[co] files have been created.

I noticed a couple warnings when test_mmap was running though:

    ./Lib/sre_compile.py: inconsistent tab/space usage
    ./Lib/sre_parse.py: inconsistent tab/space usage

Could it be that when "-tt" detects a problem it causes a broken .py[co]
file to be generated?

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."


From DavidA@ActiveState.com  Fri Jun 30 19:58:20 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Fri, 30 Jun 2000 11:58:20 -0700
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <14684.42843.472230.609828@anthem.concentric.net>
Message-ID: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>

> That's a good point.  A bump in major rev number is an /opportunity/
> to break things, like a bone that hasn't healed right, so that they
> can be fixed correctly.  We'll lose that for 2.0, mostly likely
> because of the tight release schedule.

Yes, I find that frustrating.  The story for months (years?) has been that
we don't break things because it's a 'dot-release', and so we've shelved
improvements left and right.  Now we don't have time to do those things even
when it _is_ a major release.

Some advance notice would have been nice.

--david



From fdrake@beopen.com  Fri Jun 30 20:05:42 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 15:05:42 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
References: <14684.42843.472230.609828@anthem.concentric.net>
 <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
Message-ID: <14684.61318.668529.402341@cj42289-a.reston1.va.home.com>

David Ascher writes:
 > Yes, I find that frustrating.  The story for months (years?) has been that
 > we don't break things because it's a 'dot-release', and so we've shelved
 > improvements left and right.  Now we don't have time to do those things even
 > when it _is_ a major release.
 > 
 > Some advance notice would have been nice.

  I agree, but this was news to at least some of us even Wednesday.
The upside is that major releases are more likely to happen now that
the precedent has been set.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From tpeters@beopen.com  Fri Jun 30 20:06:04 2000
From: tpeters@beopen.com (Tim Peters)
Date: Fri, 30 Jun 2000 15:06:04 -0400
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIBGHAA.tim_one@email.msn.com>

[David Ascher, wishing he had had the opportunity to break things with 2.0]
> ...
> Some advance notice would have been nice.

David, it would have been nice for us too <0.3 wink>.

we're-not-keeping-secrets-we're-just-another-thrashing-startup-ly y'rs
    - tim




From nascheme@enme.ucalgary.ca  Fri Jun 30 20:50:52 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 13:50:52 -0600
Subject: [Python-Dev] Windows build issues
Message-ID: <20000630135052.A405@acs.ucalgary.ca>

A couple of things:

PCbuild/readme.txt

    Should be updated for the new release.

PC/config.h 

    VC++ 5.0 will not compile python20 unless "#include
    <basetsd.h>" is commented out.  Trent?

    WITH_CYCLE_GC should be uncommented if we want to have GC
    enabled in the beta.

PCbuild/python20.dsp

    Line endings seem to be incorrect.  Someone probably edited
    the file on a Unix machine and munched things up.  VC++ 5.0
    likes DOS line endings otherwise it refuses to load the
    project.

Also, I get a few warnings when compiling.  One is about an /IZ
(I think) option being ignored.  There are a few other warnings
as well which I didn't write down.

  Neil


From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 20:53:05 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 21:53:05 +0200
Subject: [Python-Dev] SRE incompatibility
References: <LNBBLJKPBEHFEDALKOLCKEHOGHAA.tim_one@email.msn.com>
Message-ID: <03f501bfe2cc$cf5dcce0$f2a6b5d4@hagrid>

tim wrote:
> That would make SRE's job clear here, yes?  And in a way that allows =
the
> now-failing test to pass again?

sure.  quoting from python-checkins:

RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_sre,v
...
  test_sre
- =3D=3D=3D Failed incorrectly ('\\x00ffffffffffffff', '\377', 0, =
'found', '\377')
  =3D=3D=3D Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A')
...

still messes up on nested repetitions, but that's entirely
different problem...

</F>



From fdrake@beopen.com  Fri Jun 30 21:23:35 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 16:23:35 -0400 (EDT)
Subject: [Python-Dev] 2.0b1 documentation online
Message-ID: <14685.455.115147.446238@cj42289-a.reston1.va.home.com>

  See it at:

  http://www.python.org/doc/devel/


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From guido@python.org  Fri Jun 30 22:23:09 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 16:23:09 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5
In-Reply-To: Your message of "Fri, 30 Jun 2000 12:35:20 EST."
 <14684.55896.890339.982232@beluga.mojam.com>
References: <200006301841.LAA20523@slayer.i.sourceforge.net>
 <14684.55896.890339.982232@beluga.mojam.com>
Message-ID: <200006302123.QAA20537@cj20424-a.reston1.va.home.com>

>     Fred> The new copyright / license.
>     ...
>     Fred> ! ...  IN NO EVENT SHALL THE REGENTS OR
>     Fred> ! CONTRIBUTORS BE LIABLE FOR ...
> 
> Who are the "regents" and the "contributors"?  Should those terms be
> defined somewhere?

Oops.  I thought I caught all the regents and replaced them with a
more politically correct term.  Seems one got away.  Fixed now.

> not-a-lawyer-and-never-wanted-to-be-ly y'rs,

Ditto,

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


From guido@python.org  Fri Jun 30 22:26:21 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 16:26:21 -0500
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: Your message of "Fri, 30 Jun 2000 11:58:20 MST."
 <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
References: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
Message-ID: <200006302126.QAA20621@cj20424-a.reston1.va.home.com>

> > That's a good point.  A bump in major rev number is an /opportunity/
> > to break things, like a bone that hasn't healed right, so that they
> > can be fixed correctly.  We'll lose that for 2.0, mostly likely
> > because of the tight release schedule.

[David Ascher]
> Yes, I find that frustrating.  The story for months (years?) has been that
> we don't break things because it's a 'dot-release', and so we've shelved
> improvements left and right.  Now we don't have time to do those things even
> when it _is_ a major release.

You have no idea how frustration it is for me!  But sometimes the
marketing people force us engineers to act quickly.  Just be glad I'm
not following the release schedule that they had *wanted* me to
use... :-)

> Some advance notice would have been nice.

Same here. :-)

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


From nascheme@enme.ucalgary.ca  Fri Jun 30 21:31:48 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 14:31:48 -0600
Subject: [Python-Dev] Idle breakage
Message-ID: <20000630143148.A9725@acs.ucalgary.ca>

Caused by _sre perhaps?

$ python Tools/idle/idle.py
Traceback (most recent call last):
  File "Tools/idle/idle.py", line 8, in ?
    IdleConf.load(idle_dir)
  File "Tools/idle/IdleConf.py", line 109, in load
    idleconf.read((os.path.join(dir, "config.txt"), genplatfile, platfile,
  File "/usr/local/lib/python2.0/ConfigParser.py", line 207, in read
    self.__read(fp, filename)
  File "/usr/local/lib/python2.0/ConfigParser.py", line 382, in __read
    raise e
ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt
        [line 21]: 'width= 80\012'
        [line 22]: 'height= 24\012'
        [line 26]: 'normal-foreground= black\012'
        [line 27]: 'normal-background= white\012'
        [line 29]: 'keyword-foreground= #ff7700\012'
        [line 30]: 'comment-foreground= #dd0000\012'
        [line 31]: 'string-foreground= #00aa00\012'
        [line 32]: 'definition-foreground= #0000ff\012'
        [line 33]: 'hilite-foreground= #000068\012'
        [line 34]: 'hilite-background= #006868\012'
        [line 35]: 'break-foreground= #ff7777\012'
        [line 36]: 'hit-foreground= #ffffff\012'
        [line 37]: 'hit-background= #000000\012'
        [line 38]: 'stdout-foreground= blue\012'
        [line 39]: 'stderr-foreground= red\012'
        [line 40]: 'console-foreground= #770000\012'
        [line 41]: 'error-background= #ff7777\012'
        [line 42]: 'cursor-background= black\012'
        [line 59]: 'enable= 0\012'
        [line 60]: 'style= expression\012'
        [line 61]: 'flash-delay= 500\012'
        [line 62]: 'bell= 1\012'
        [line 63]: 'hilite-foreground= black\012'
        [line 64]: 'hilite-background= #43cd80\012'


From jeremy@beopen.com  Fri Jun 30 21:33:01 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 16:33:01 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <200006302126.QAA20621@cj20424-a.reston1.va.home.com>
References: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
 <200006302126.QAA20621@cj20424-a.reston1.va.home.com>
Message-ID: <14685.1021.870885.796187@bitdiddle.concentric.net>

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

  >> That's a good point.  A bump in major rev number is an
  >> /opportunity/ to break things, like a bone that hasn't healed
  >> right, so that they can be fixed correctly.  We'll lose that
  >> for 2.0, mostly likely because of the tight release schedule.

  GvR> [David Ascher]
  >> Yes, I find that frustrating.  The story for months (years?) has
  >> been that we don't break things because it's a 'dot-release', and
  >> so we've shelved improvements left and right.  Now we don't have
  >> time to do those things even when it _is_ a major release.

  GvR> You have no idea how frustration it is for me!  But sometimes
  GvR> the marketing people force us engineers to act quickly.  Just
  GvR> be glad I'm not following the release schedule that they had
  GvR> *wanted* me to use... :-)

Perhaps I am too easy-going, but I consider the 2.0 release a
'dot-release' masquerading as a major revision.  It might be a little
silly, but it seems even sillier to preserve a naming scheme that
makes users think that the technology is immature.

Jeremy


From guido@python.org  Fri Jun 30 22:33:52 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 16:33:52 -0500
Subject: [Python-Dev] Windows build issues
In-Reply-To: Your message of "Fri, 30 Jun 2000 13:50:52 CST."
 <20000630135052.A405@acs.ucalgary.ca>
References: <20000630135052.A405@acs.ucalgary.ca>
Message-ID: <200006302133.QAA20696@cj20424-a.reston1.va.home.com>

> A couple of things:
> 
> PCbuild/readme.txt
> 
>     Should be updated for the new release.

Tim will do this.

> PC/config.h 
> 
>     VC++ 5.0 will not compile python20 unless "#include
>     <basetsd.h>" is commented out.  Trent?

I'll leave this to Trent -- I don't know how to check for VC 5.0
vs. 6.0.

>     WITH_CYCLE_GC should be uncommented if we want to have GC
>     enabled in the beta.

Done.

> PCbuild/python20.dsp
> 
>     Line endings seem to be incorrect.  Someone probably edited
>     the file on a Unix machine and munched things up.  VC++ 5.0
>     likes DOS line endings otherwise it refuses to load the
>     project.

There was one missing CR.  Fixed now.

> Also, I get a few warnings when compiling.  One is about an /IZ
> (I think) option being ignored.  There are a few other warnings
> as well which I didn't write down.

Probably 6.0 flags that 5.0 doesn't have.  What can we do?

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


From nascheme@enme.ucalgary.ca  Fri Jun 30 21:40:21 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 14:40:21 -0600
Subject: [Python-Dev] Idle breakage
In-Reply-To: <20000630143148.A9725@acs.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Fri, Jun 30, 2000 at 02:31:48PM -0600
References: <20000630143148.A9725@acs.ucalgary.ca>
Message-ID: <20000630144021.A9847@acs.ucalgary.ca>

Changing to pre fixes the problem.

  Neil


From mwh21@cam.ac.uk  Fri Jun 30 21:50:37 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 30 Jun 2000 21:50:37 +0100
Subject: [Python-Dev] Re: Test results of linuxaudiodev.c
In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 17:44:35 -0700 (PDT)"
References: <Pine.SGI.3.96.1000629173646.621134u-100000@happy>
Message-ID: <m3r99e7v1e.fsf@atrus.jesus.cam.ac.uk>

To python-dev: Sorry for the hiatus.

To python-list: does someone who knows about audio and can run linux
want to play with this (Ping and I fall into just one of these
categories each!).

Ka-Ping Yee <pingster@ilm.com> writes:

> On 30 Jun 2000, Michael Hudson wrote:
> > Yup, that works fine.  Don't understand the details - and as I have my
> > graduation ceremony tomorrow I'm going to go to bed and leave learning
> > them until some other occasion!
> 
> Cool.
> 
> Okay, i just discovered sunau.py.  Here's my real shot at
> test_linuxaudiodev.py.  Can you give this a try?
> 
> 
> ---- test_linuxaudiodev.py ----
> from test_support import verbose, findfile, TestFailed
> import linuxaudiodev
> import os, sunau
> 
> formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW,
>            ("NONE", 1): linuxaudiodev.AFMT_S8,
>            ("NONE", 2): linuxaudiodev.AFMT_S16_BE}
> 
> def play_au_file(path):
>     au = sunau.open(path, "r")
>     data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE)
>     au.close()
> 
>     spec = (au.getcomptype(), au.getsampwidth())
>     if not has_key(formats, spec):
             ^^^^^^^
Oops?

>         raise "audio format not supported by linuxaudiodev"

Maybe you mean:

        raise TestFailed, "audio format not supported by linuxaudiodev"

?  I thought string exceptions were deprecated...
         
>     dsp = linuxaudiodev.open("w")
>     dsp.setparameters(au.getframerate(), au.getsampwidth() * 8,
>                       au.getnchannels(), formats[spec])
>     dsp.write(data)
>     dsp.close()
> 
> def test():
>     play_au_file(findfile('audiotest.au'))
> 
> test()

This doesn't work.  I don't really understand why.

For audiotest.au, |spec| is ("ULAW",2), which I don't think is right;
file(1) says 

audiotest.au: Sun/NeXT audio data: 8-bit ISDN u-law, mono, 8000 Hz

So I think this could be a bug in sunau.

The other data (au.getframerate(), au.getnchannels()) agrees with
file(1).

Anybody have a better idea?

Cheers,
Michael Hudson, BA (as of today! woohoo!)



From jeremy@beopen.com  Fri Jun 30 21:57:44 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 16:57:44 -0400 (EDT)
Subject: [Python-Dev] last minute GC questions
Message-ID: <14685.2504.722378.79294@bitdiddle.concentric.net>

I've got two last minute questions.

Does it look to you like I checked in all of the changes that you and
Vladimir discussed?

Might we change the strategy for deciding when to collect?

There are two parts of the strategy that could probably change.  The
first is what kind of allocation events we count to determine when to
collect.  

Right now, the gc is counting the net effect of allocations and
deallocations.  This isn't effective for at least a couple of cases.
If we allocate N objects and don't deallocate anything, then no
garbage is going to be created.  If we have many objects currently
allocated and then dealloc N objects without allocating any, we could
create collectible garbage, but the collector won't run because there
haven't been any allocations.

It seems to me that counting deallocations only would be more
effective.  It is only the deallocations that cause a live object to
become garbage.

The other part of the strategy that might be changed is the collection
frequency.  Right now, the threshold is 100 net allocations &
dealloactions.  On the compiler benchmark, this leads to some 2600
collections, which seems like a lot.  (I have no idea why it seems
like a lot, but it does.)

I experimented with a policy that runs the collected every N
deallocations (not counting deallocations the occur during a
collection).  I set N == 1000 and got 1600 collections on the compiler
benchmark.  

There is only a small speedup (just a few percent), so maybe this
change doesn't have a big effect.  I don't recall much about the
cost/complexity of various GC approaches.

Jeremy


From nascheme@enme.ucalgary.ca  Fri Jun 30 22:12:06 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 15:12:06 -0600
Subject: [Python-Dev] Re: last minute GC questions
In-Reply-To: <14685.2504.722378.79294@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jun 30, 2000 at 04:57:44PM -0400
References: <14685.2504.722378.79294@bitdiddle.concentric.net>
Message-ID: <20000630151206.A10333@acs.ucalgary.ca>

On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote:
> I've got two last minute questions.
> 
> Does it look to you like I checked in all of the changes that you and
> Vladimir discussed?

Nope.

  Neil


Index: 0.13/Include/objimpl.h
*** 0.13/Include/objimpl.h Fri, 30 Jun 2000 13:05:40 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644)
--- 0.13(w)/Include/objimpl.h Fri, 30 Jun 2000 15:09:51 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644)
***************
*** 204,209 ****
--- 204,211 ----
  	(PyVarObject *) PyObject_MALLOC( _PyObject_VAR_SIZE((typeobj),(n)) ),\
  	(typeobj), (n)) )
  
+ #define PyObject_DEL(op) PyObject_FREE(op)
+ 
  /* This example code implements an object constructor with a custom
     allocator, where PyObject_New is inlined, and shows the important
     distinction between two steps (at least):
***************
*** 242,248 ****
     PyObject_{New, VarNew, Del} to manage the memory.  Set the type flag
     Py_TPFLAGS_GC and define the type method tp_recurse.  You should also
     add the method tp_clear if your object is mutable.  Include
!    PyGC_INFO_SIZE in the calculation of tp_basicsize.  Call
     PyObject_GC_Init after the pointers followed by tp_recurse become
     valid (usually just before returning the object from the allocation
     method.  Call PyObject_GC_Fini before those pointers become invalid
--- 244,250 ----
     PyObject_{New, VarNew, Del} to manage the memory.  Set the type flag
     Py_TPFLAGS_GC and define the type method tp_recurse.  You should also
     add the method tp_clear if your object is mutable.  Include
!    PyGC_HEAD_SIZE in the calculation of tp_basicsize.  Call
     PyObject_GC_Init after the pointers followed by tp_recurse become
     valid (usually just before returning the object from the allocation
     method.  Call PyObject_GC_Fini before those pointers become invalid
***************
*** 255,261 ****
  #define PyObject_GC_Fini(op)
  #define PyObject_AS_GC(op) (op)
  #define PyObject_FROM_GC(op) (op)
- #define PyObject_DEL(op) PyObject_FREE(op)
   
  #else
  
--- 257,262 ----
***************
*** 289,295 ****
  /* Get the object given the PyGC_Head */
  #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1))
  
! #define PyObject_DEL(op) PyObject_FREE( PyObject_IS_GC(op) ? \
  					(ANY *)PyObject_AS_GC(op) : \
  					(ANY *)(op) )
  
--- 290,297 ----
  /* Get the object given the PyGC_Head */
  #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1))
  
! #undef PyObject_DEL
! #define PyObject_DEL(op) PyObject_FREE( (op && PyObject_IS_GC(op)) ? \
  					(ANY *)PyObject_AS_GC(op) : \
  					(ANY *)(op) )
  
Index: 0.13/Objects/object.c
*** 0.13/Objects/object.c Fri, 30 Jun 2000 13:05:40 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644)
--- 0.13(w)/Objects/object.c Fri, 30 Jun 2000 15:05:26 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644)
***************
*** 192,205 ****
  	PyObject *op;
  {
  #ifdef WITH_CYCLE_GC
! 	if (PyType_IS_GC(op->ob_type)) {
! 		PyGC_Head *g = PyObject_AS_GC(op);
! 		PyObject_FREE(g);
! 	} else
! #endif
! 	{
! 		PyObject_FREE(op);
  	}
  }
  
  #ifndef WITH_CYCLE_GC
--- 192,202 ----
  	PyObject *op;
  {
  #ifdef WITH_CYCLE_GC
! 	if (op && PyType_IS_GC(op->ob_type)) {
! 		op = (PyObject *) PyObject_AS_GC(op);
  	}
+ #endif
+ 	PyObject_FREE(op);
  }
  
  #ifndef WITH_CYCLE_GC


From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 22:20:20 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 23:20:20 +0200
Subject: [Python-Dev] Windows build issues
References: <20000630135052.A405@acs.ucalgary.ca>  <200006302133.QAA20696@cj20424-a.reston1.va.home.com>
Message-ID: <044b01bfe2d9$01dcee60$f2a6b5d4@hagrid>

guido wrote:

> > PC/config.h=20
> >=20
> >     VC++ 5.0 will not compile python20 unless "#include
> >     <basetsd.h>" is commented out.  Trent?
>=20
> I'll leave this to Trent -- I don't know how to check for VC 5.0
> vs. 6.0.

#if _MSC_VER >=3D 1200
    VC 6.0
#else
    VC 5.0 or earlier   =20
#endif

(we added a similar workaround to Python/thread_nt.c)

> > Also, I get a few warnings when compiling.  One is about an /IZ
> > (I think) option being ignored.  There are a few other warnings
> > as well which I didn't write down.
>=20
> Probably 6.0 flags that 5.0 doesn't have.  What can we do?

ignore it, for now.  I remember seeing a few type warnings, but
nothing critical.  there's plenty of time to sort that out on the
way to 2.0 final.

</F>



From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 22:24:06 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 23:24:06 +0200
Subject: [Python-Dev] Idle breakage
References: <20000630143148.A9725@acs.ucalgary.ca>
Message-ID: <046a01bfe2d9$88302360$f2a6b5d4@hagrid>

neil wrote:


> Caused by _sre perhaps?
>=20
> ConfigParser.ParsingError: File contains parsing errors: =
Tools/idle/config.txt
>         [line 21]: 'width=3D 80\012'

probably; I'll dig into this.

when's the 2.0 deadline?

</F>



From nascheme@enme.ucalgary.ca  Fri Jun 30 22:30:08 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 15:30:08 -0600
Subject: [Python-Dev] Fwd: Re: last minute GC questions
Message-ID: <20000630153008.C10333@acs.ucalgary.ca>

Oops, should have cc python-dev.

----- Forwarded message from Neil Schemenauer <nascheme@enme.ucalgary.ca> -----

Date: Fri, 30 Jun 2000 15:27:48 -0600
From: Neil Schemenauer <nascheme@enme.ucalgary.ca>
Subject: Re: last minute GC questions
To: Jeremy Hylton <jeremy@beopen.com>
X-Url: http://www.enme.ucalgary.ca/~nascheme/

On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote:
> Might we change the strategy for deciding when to collect?

We might. :)

> It seems to me that counting deallocations only would be more
> effective.  It is only the deallocations that cause a live object to
> become garbage.

You can easily run out of memory with that strategy though:

    N = 10000
    while 1:
        l = []
        for i in xrange(N):
            l.append([])
        l[0] = l

You only get a couple of deallocations while a large amount of
garbage is created.  Think of large cyclic structures like graphs
being created and then becoming garbage due to one deallocation.
By counting the net new objects we guarantee that this doesn't
happen.

> The other part of the strategy that might be changed is the collection
> frequency.  Right now, the threshold is 100 net allocations &
> dealloactions.  On the compiler benchmark, this leads to some 2600
> collections, which seems like a lot.  (I have no idea why it seems
> like a lot, but it does.)

Try setting the threshold to zero.  The major part of the GC
overhead does not seem to be running the collector.  OTOH, the
frequency could probably be decreased without the risk of running
out of memory.  No Python applications currently exist that
create that amount of garbage anyhow.

  Neil

----- End forwarded message -----


From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 22:39:26 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 23:39:26 +0200
Subject: [Python-Dev] Idle breakage
References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid>
Message-ID: <049601bfe2db$acea1380$f2a6b5d4@hagrid>

I wrote:

> > Caused by _sre perhaps?
> >=20
> > ConfigParser.ParsingError: File contains parsing errors: =
Tools/idle/config.txt
> >         [line 21]: 'width=3D 80\012'
>=20
> probably; I'll dig into this.

confirmed.  SRE implements $ exactly as described in
the library reference, RE doesn't ;-)

patch coming within 30 minutes.

</F>



From bwarsaw@beopen.com  Fri Jun 30 22:57:19 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 17:57:19 -0400 (EDT)
Subject: [Python-Dev] Odd behavior with `make test'
References: <14684.57622.9807.868551@anthem.concentric.net>
 <038601bfe2bf$31c52da0$f2a6b5d4@hagrid>
Message-ID: <14685.6079.779817.674190@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <effbot@telia.com> writes:

    FL> the rest looks a bit scary, to say the least.  does someone
    FL> (sre?)  overwrite something? does anyone have purify (dmalloc,
    FL> fences, whatever) within reach?

I will very soon.  I found a Solaris box on which I could load up an
eval copy of Purify.  Will report back soon.

-Barry


From guido@python.org  Fri Jun 30 23:57:45 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 17:57:45 -0500
Subject: [Python-Dev] Idle breakage
In-Reply-To: Your message of "Fri, 30 Jun 2000 23:24:06 +0200."
 <046a01bfe2d9$88302360$f2a6b5d4@hagrid>
References: <20000630143148.A9725@acs.ucalgary.ca>
 <046a01bfe2d9$88302360$f2a6b5d4@hagrid>
Message-ID: <200006302257.RAA21104@cj20424-a.reston1.va.home.com>

> when's the 2.0 deadline?

In a couple of hours.

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


From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 23:14:49 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sat, 1 Jul 2000 00:14:49 +0200
Subject: [Python-Dev] Idle breakage
References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid>             <049601bfe2db$acea1380$f2a6b5d4@hagrid>  <200006302302.SAA21232@cj20424-a.reston1.va.home.com>
Message-ID: <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid>

guido wrote:

> > confirmed.  SRE implements $ exactly as described in
> > the library reference, RE doesn't ;-)
>=20
> All this is done to match what Perl does. :-(

guess we have to update the docs; I'll take care of that
when I've recovered from all this...

>     emit(ATCODES[AT_MULTILINE[av]])
> KeyError: at_boundary

sigh.  with ~1000 patterns in my collection of test scripts,
one could have hoped I'd seen it all.  but that's a new one.

patch coming within 30 minutes (when will I ever sleep?)

</F>



From bwarsaw@beopen.com  Fri Jun 30 23:15:34 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 18:15:34 -0400 (EDT)
Subject: [Python-Dev] Idle breakage
References: <20000630143148.A9725@acs.ucalgary.ca>
 <046a01bfe2d9$88302360$f2a6b5d4@hagrid>
 <049601bfe2db$acea1380$f2a6b5d4@hagrid>
 <200006302302.SAA21232@cj20424-a.reston1.va.home.com>
 <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid>
Message-ID: <14685.7174.668568.445940@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <effbot@telia.com> writes:

    FL> patch coming within 30 minutes (when will I ever sleep?)

When WE say you can :)

-Barry


From DavidA@ActiveState.com  Fri Jun 30 23:20:12 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Fri, 30 Jun 2000 15:20:12 -0700
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <200006302314.SAA21371@cj20424-a.reston1.va.home.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJMEHGCLAA.DavidA@ActiveState.com>

> > Not that I hope to override the heavy -1, but I don't agree
> with the second
> > point.  It embodies a huge amount of knowledge that is needed to write
> > portable code.  As such, IMO, it _does_ belong in the standard
> library.  How
> > is it different in its nature from sys.platform, which is only
> a much weaker
> > version of the same concept?
>
> A more subtle way of stating my opinion could be: if we were to do
> something in the standard distribution about the problems that this is
> addressing, I think we would do it in a much more direct fashion,
> e.g. by making the appropriate enquiry functions directly accessible.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

I much prefer that answer, as it leaves the door open to a patch.  I don't
care about the implementation, just the feature.  Thanks.

--david



From Fredrik Lundh" <effbot@telia.com  Fri Jun 30 23:36:55 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sat, 1 Jul 2000 00:36:55 +0200
Subject: [Python-Dev] Idle breakage
References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid>             <049601bfe2db$acea1380$f2a6b5d4@hagrid>  <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid>
Message-ID: <050501bfe2e3$b2517680$f2a6b5d4@hagrid>

> > KeyError: at_boundary
>=20
> sigh.  with ~1000 patterns in my collection of test scripts,
> one could have hoped I'd seen it all.  but that's a new one.

umm.  I'm not sure I want to check this one in.  of all
stupid bugs...  I really gotta do something about that
regression test suite.

(don't worry, the patch is on its way.  unfortunately, my
setup is botched, so I cannot test drive IDLE myself.  or
to put it another way, I cannot guarantee that this is the
last problem with IDLE+SRE...)

</F>



From bwarsaw@beopen.com  Fri Jun 30 23:37:20 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 18:37:20 -0400 (EDT)
Subject: [Python-Dev] Idle breakage
References: <20000630143148.A9725@acs.ucalgary.ca>
 <046a01bfe2d9$88302360$f2a6b5d4@hagrid>
 <049601bfe2db$acea1380$f2a6b5d4@hagrid>
 <200006302302.SAA21232@cj20424-a.reston1.va.home.com>
 <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid>
 <050501bfe2e3$b2517680$f2a6b5d4@hagrid>
Message-ID: <14685.8480.389966.608982@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <effbot@telia.com> writes:

    FL> (don't worry, the patch is on its way.  unfortunately, my
    FL> setup is botched, so I cannot test drive IDLE myself.  or
    FL> to put it another way, I cannot guarantee that this is the
    FL> last problem with IDLE+SRE...)

Go ahead and check it in.  I'll run idle and see wot hoppens.

-B


From Vladimir.Marangozov@inrialpes.fr  Fri Jun 30 23:46:37 2000
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Sat, 1 Jul 2000 00:46:37 +0200 (CEST)
Subject: [Python-Dev] Oops on AIX
In-Reply-To: <200006302310.SAA21344@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 30, 2000 06:10:30 PM
Message-ID: <200006302246.AAA23519@python.inrialpes.fr>

Guido van Rossum wrote:
> 
> let me suggest patches...  If these work, please check them in:

Yes, they do, thanks!
(I can't check them in)

There's one error left, occuring at two locations in the signalmodule,
but I think the solution would be to have an appropriate cast:

"./signalmodule.c", line 359.49: 1506-280 (E) Function argument assignment between types "void*" and "void(*)(int)" is not allowed.
"./signalmodule.c", line 363.48: 1506-280 (E) Function argument assignment between types "void*" and "void(*)(int)" is not allowed.


> 
> >         xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c
> > "methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed.
> 
> 
> Index: methodobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/methodobject.c,v
> retrieving revision 2.28
> diff -c -r2.28 methodobject.c
> *** methodobject.c	2000/06/30 15:01:00	2.28
> --- methodobject.c	2000/06/30 22:09:55
> ***************
> *** 180,186 ****
>   		if (x == -1)
>   			return -1;
>   	}
> ! 	y = _Py_HashPointer(a->m_ml->ml_meth);
>   	if (y == -1)
>   		return -1;
>   	x ^= y;
> --- 180,186 ----
>   		if (x == -1)
>   			return -1;
>   	}
> ! 	y = _Py_HashPointer((void*)(a->m_ml->ml_meth));
>   	if (y == -1)
>   		return -1;
>   	x ^= y;
> 
> 
> 
> >         xlc_r  -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c
> > "./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined.
> > "./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h.
> > make: 1254-004 The error code from the last command is 1.
> 
> Index: posixmodule.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v
> retrieving revision 2.138
> diff -c -r2.138 posixmodule.c
> *** posixmodule.c	2000/06/29 21:12:41	2.138
> --- posixmodule.c	2000/06/30 22:10:39
> ***************
> *** 285,290 ****
> --- 285,291 ----
>   #endif
>   
>   /* choose the appropriate stat and fstat functions and return structs */
> + #undef STAT
>   #ifdef MS_WIN64
>   #	define STAT _stati64
>   #	define FSTAT _fstati64
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 


-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From fdrake@beopen.com  Fri Jun 30 23:46:18 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 18:46:18 -0400 (EDT)
Subject: [Python-Dev] Idle breakage
In-Reply-To: <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid>
References: <20000630143148.A9725@acs.ucalgary.ca>
 <046a01bfe2d9$88302360$f2a6b5d4@hagrid>
 <049601bfe2db$acea1380$f2a6b5d4@hagrid>
 <200006302302.SAA21232@cj20424-a.reston1.va.home.com>
 <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid>
Message-ID: <14685.9018.355154.468866@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > guess we have to update the docs; I'll take care of that
 > when I've recovered from all this...

  The docs are frozen & published for this release, so next week is
fine.  ** THANKS! **

 > patch coming within 30 minutes (when will I ever sleep?)

  You sleep???


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From klm at digicool.com  Thu Jun  1 00:03:31 2000
From: klm at digicool.com (Ken Manheimer)
Date: Wed, 31 May 2000 18:03:31 -0400 (EDT)
Subject: [Python-Dev] SIG: python-lang
In-Reply-To: <643145F79272D211914B0020AFF640190BAA8F@gandalf.digicool.com>
Message-ID: <Pine.LNX.4.21.0005311755420.9023-100000@korak.digicool.com>

On Wed, 31 May 2000, Ka-Ping Yee wrote:

> Hey, i admit it's a bit primitive, but it seems significantly
> better than nothing.  The software people at ILM have coped
> with it fairly well for a year, and for the most part we like it.

I'm not sure about the requirements - particularly, submissions and
correspondence about bugs via email, which my zope "tracker" doesn't do -
but the tracker may be worth looking at, also:

  http://www.zope.org/Members/klm/SoftwareCarpentry

(See the prototype tracker, mentioned there, or my "tracker tracker" at
http://www.zope.org/Members/klm/Tracker , for flagrant, embarrassing
exposure of the outstanding tracker complaints...)

(I haven't had the time to take care of the tracker as i would like, or to
look at how tracker and roundup could inform eachother - but i haven't
even gotten as far as examining that.  I get the feeling they take fairly
different approaches - which could mean neat synergy, or total
disconnection.  Ping, any thoughts?)

Ken
klm at digicool.com




From fdrake at acm.org  Thu Jun  1 00:17:02 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 31 May 2000 18:17:02 -0400 (EDT)
Subject: [Python-Dev] Adding LDAP to the Python core... ?!
In-Reply-To: <Pine.LNX.4.10.10005311452150.30220-100000@nebula.lyra.org>
References: <14645.17446.749848.895965@anthem.python.org>
	<Pine.LNX.4.10.10005311452150.30220-100000@nebula.lyra.org>
Message-ID: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com>

Greg Stein writes:
 > My WebDAV module implements an established protocol (an RFC tends to do
 > that :-), but the API within the module is still in flux (IMO).

  I'd love to see this sort of thing added to the standard library,
esp. once packages are used there.  Especially if the implementation
is pure Python (which I think your WebDAV stuff is, right?)

 > Is the LDAP module's API pretty solid? Is it changing?

  This I don't know.

 > And is this module a C extension, or a pure Python implementation?

  Mixed, I think.  There is definately a C component.  I'd rather it
be pure Python, but I think it's a SWIGged wrapper around a C client
library.
  Is anyone talking to the developer about this yet?


  -Fred

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




From gstein at lyra.org  Thu Jun  1 00:27:04 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 31 May 2000 15:27:04 -0700 (PDT)
Subject: [Python-Dev] Adding LDAP to the Python core... ?!
In-Reply-To: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10005311522480.30220-100000@nebula.lyra.org>

On Wed, 31 May 2000, Fred L. Drake, Jr. wrote:
> Greg Stein writes:
>  > My WebDAV module implements an established protocol (an RFC tends to do
>  > that :-), but the API within the module is still in flux (IMO).
> 
>   I'd love to see this sort of thing added to the standard library,
> esp. once packages are used there.  Especially if the implementation
> is pure Python (which I think your WebDAV stuff is, right?)

davlib.py is pure Python, building upon my upgraded httplib.py and
xml.utils.qp_xml (and pyexpat)

[ and recall my email last week that I've updated httplib.py and posted it
  to my web pages; it is awaiting review for integration into the Python
  core; it still needs docs and more testing scenarios, tho

  http://www.python.org/pipermail/python-dev/2000-May/005643.html
]

davlib will probably be a 1.7 item. It still needs some heavy work to
easily deal with authentication (which is usually going to be required for
DAV operations).

Cheers,
-g

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




From mhammond at skippinet.com.au  Thu Jun  1 00:53:15 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Thu, 1 Jun 2000 08:53:15 +1000
Subject: [Python-Dev] SIG: python-lang
In-Reply-To: <Pine.LNX.4.21.0005311755420.9023-100000@korak.digicool.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEAKCMAA.mhammond@skippinet.com.au>

[Ken writes]
> I'm not sure about the requirements - particularly, submissions and
> correspondence about bugs via email, which my zope "tracker" doesn't do -
> but the tracker may be worth looking at, also:
>
>   http://www.zope.org/Members/klm/SoftwareCarpentry
>

Another alternative could be Bugzilla:

http://bugzilla.mozilla.org/

Sources at:

http://www.mozilla.org/bugs/source.html

Has many of the features people seem to want, and obviously supports large
projects - which may be the biggest problem - it may be too "heavy" for our
requirement...

Mark.




From fdrake at acm.org  Thu Jun  1 03:30:28 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 31 May 2000 21:30:28 -0400 (EDT)
Subject: [Python-Dev] Adding LDAP to the Python core... ?!
In-Reply-To: <Pine.LNX.4.10.10005311522480.30220-100000@nebula.lyra.org>
References: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com>
	<Pine.LNX.4.10.10005311522480.30220-100000@nebula.lyra.org>
Message-ID: <14645.48308.347086.279280@cj42289-a.reston1.va.home.com>

Greg Stein writes:
 > davlib.py is pure Python, building upon my upgraded httplib.py and
 > xml.utils.qp_xml (and pyexpat)

  So the dependencies are definately an issue.

 > [ and recall my email last week that I've updated httplib.py and posted it
 >   to my web pages; it is awaiting review for integration into the Python
 >   core; it still needs docs and more testing scenarios, tho
 > 
 >   http://www.python.org/pipermail/python-dev/2000-May/005643.html
 > ]

  Jeremy, were you looking at this?

 > davlib will probably be a 1.7 item. It still needs some heavy work to
 > easily deal with authentication (which is usually going to be required for

  Sounds good to me; let's take a look at it in 3 or 4 months.  I'd
hope to have at least preliminary reference documentation for review.


  -Fred

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




From skip at mojam.com  Thu Jun  1 15:48:41 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 1 Jun 2000 08:48:41 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34
In-Reply-To: <200006010312.UAA10844@slayer.i.sourceforge.net>
References: <200006010312.UAA10844@slayer.i.sourceforge.net>
Message-ID: <14646.27065.279988.93102@beluga.mojam.com>

    Fred> Log Message:
    Fred> Michael Hudson <mwh21 at cam.ac.uk>:
    Fred> Removed PyErr_BadArgument() calls and replaced them with more
    Fred> useful error messages.

    ...
    Fred> --- 389,395 ----
    Fred>   	PyListObject *np;
    Fred>   	if (!PyList_Check(bb)) {
    Fred> ! 		PyErr_Format(PyExc_TypeError,
    Fred> ! 			     "can only append list (not \"%.200s\") to list",
    Fred> ! 			     bb->ob_type->tp_name);
    Fred>   		return NULL;
    Fred>   	}
    Fred> ***************
    ...

I've seen this new error message cross my mailbox a few times.  On the face
of it, it's incorrect, because you can append any sort of object to a list,
right?  This message appears in the list_concat method.  Shouldn't it be
something like

    can't concatenate \"%.200s\" object with list

?  I would consider this change very picky except for the fact that it's
making a statement about the properties of lists that is clearly not true.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
"We have become ... the stewards of life's continuity on earth.  We did not
ask for this role...  We may not be suited to it, but here we are."
- Stephen Jay Gould



From fdrake at acm.org  Thu Jun  1 16:29:17 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 1 Jun 2000 10:29:17 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34
In-Reply-To: <14646.27065.279988.93102@beluga.mojam.com>
References: <200006010312.UAA10844@slayer.i.sourceforge.net>
	<14646.27065.279988.93102@beluga.mojam.com>
Message-ID: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com>

Skip Montanaro writes:
 > I've seen this new error message cross my mailbox a few times.  On the face
 > of it, it's incorrect, because you can append any sort of object to a list,
 > right?  This message appears in the list_concat method.  Shouldn't it be
 > something like
 > 
 >     can't concatenate \"%.200s\" object with list

Skip,
  You're right!  How about:

       can only concatenate list (not \"%.200s\") to list

  If you don't object by the time this mail reaches you, I'll check it
in.  ;)


  -Fred

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




From mwh21 at cam.ac.uk  Thu Jun  1 17:39:59 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: Thu, 1 Jun 2000 16:39:59 +0100 (BST)
Subject: [Python-Dev] CVS: python/dist/src/Objects listobject.c,2.69,2.70 and friends
In-Reply-To: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10006011637320.13221-100000@localhost.localdomain>

On Thu, 1 Jun 2000, Fred L. Drake, Jr. wrote:

> 
> Skip Montanaro writes:
>  > I've seen this new error message cross my mailbox a few times.  On the face
>  > of it, it's incorrect, because you can append any sort of object to a list,
>  > right?  This message appears in the list_concat method.  Shouldn't it be
>  > something like
>  > 
>  >     can't concatenate \"%.200s\" object with list
> 
> Skip,
>   You're right!  How about:
> 
>        can only concatenate list (not \"%.200s\") to list
> 
>   If you don't object by the time this mail reaches you, I'll check it
> in.  ;)

Then you'd better do something about tupleobject.c as well; I'd also say

       can only concatenate list (not \"%.200s\") and list
       can only concatenate tuple (not \"%.200s\") and tuple

are slightly preferable, on reflection (note the s/to/and/).

Cheers,
Michael




From andy at reportlab.com  Thu Jun  1 18:23:36 2000
From: andy at reportlab.com (Andy Robinson)
Date: Thu, 1 Jun 2000 17:23:36 +0100
Subject: [Python-Dev] SIG: python-lang
Message-ID: <PGECLPOBGNBNKHNAGIJHIEDNCCAA.andy@reportlab.com>

It seems to me that the main problem is that
comp.lang.python is too big to follow.  So why 
not split it?  I don't know the right subgroups,
but if (say) comp.lang.python.language focusses 
on the core language, it might enable people to 
start reading it again.  

I asked this twice on c.l.p, one year ago and 
two years ago, and the answer was always "the 
traffic is too low".  I used to subscribe to
the NeXTSteap groups, and splitting worked
really well there.

- Andy Robinson



From mal at lemburg.com  Thu Jun  1 15:10:42 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 01 Jun 2000 15:10:42 +0200
Subject: [Python-Dev] Adding LDAP to the Python core... ?!
References: <Pine.LNX.4.10.10005311452150.30220-100000@nebula.lyra.org>
Message-ID: <393660D2.4926E5C1@lemburg.com>

Greg Stein wrote:
> 
> On Wed, 31 May 2000, Barry A. Warsaw wrote:
> > >>>>> "M" == M  <mal at lemburg.com> writes:
> >
> >     M> Would there be interest in adding the python-ldap module
> >     M> (http://sourceforge.net/project/?group_id=2072) to the
> >     M> core distribution ?
> >
> > I haven't looked at this stuff, but yes, I think a standard LDAP
> > module would be quite useful.  It's a well enough established
> > protocol, and it would be good to be able to count on it "being
> > there".
> 
> My WebDAV module implements an established protocol (an RFC tends to do
> that :-), but the API within the module is still in flux (IMO).
> 
> Is the LDAP module's API pretty solid? Is it changing?

It is closing in on version 2.0 -- not sure how much it
still changes. I just thought I'd query here before asking
Daniel about his thoughts on including the module in the
core (wouldn't make much sense if there was no interest).
 
> And is this module a C extension, or a pure Python implementation?

It's a Python module which uses a C wrapper to interface
to OpenLDAP, which is a portable C lib dealing with
all aspects of LDAP.

There are at least two other projects built on top of
python-ldap (see Parnassus for infos).

I just thought I'd mention it here, because  LDAP is certainly
a widely used protocol in the corporate world and many 
decision makers have this on their list of buzz words.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From gward at mems-exchange.org  Thu Jun  1 23:01:41 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 1 Jun 2000 17:01:41 -0400
Subject: [Python-Dev] What's that sound?
In-Reply-To: <393547A2.30CB7113@prescod.net>; from paul@prescod.net on Wed, May 31, 2000 at 12:10:58PM -0500
References: <39353CCD.1F3E9A0B@prescod.net> <14645.17611.318538.986772@anthem.python.org> <393547A2.30CB7113@prescod.net>
Message-ID: <20000601170140.A24794@mems-exchange.org>

On 31 May 2000, Paul Prescod said:
> Look closer, big-egoed-four-stringed-guitar-playing-one. It could just
> as easily be a J.
> 
> And you know what you get when you put P and J together?

Pajamas!

Yes, that's right, when Python takes over the world, we'll all have to
sleep BUCK NAKED!!!

(What was that about "zero noise" on python-dev?  Oh well, we must have
our fun...)

        Greg



From esr at snark.thyrsus.com  Fri Jun  2 00:36:29 2000
From: esr at snark.thyrsus.com (Eric S. Raymond)
Date: Thu, 1 Jun 2000 18:36:29 -0400
Subject: [Python-Dev] ascii.py?
Message-ID: <200006012236.SAA03578@snark.thyrsus.com>

There has been a vast and echoing silence about the ascii.py module I
posted here at Fred Drake's request.  Is it really such a  bad idea?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"Those who make peaceful revolution impossible 
will make violent revolution inevitable."
	-- John F. Kennedy



From pingster at ilm.com  Fri Jun  2 00:33:19 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 1 Jun 2000 15:33:19 -0700 (PDT)
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <Pine.SGI.3.96.1000601153039.30600P-100000@happy>

On Thu, 1 Jun 2000, Eric S. Raymond wrote:
> There has been a vast and echoing silence about the ascii.py module I
> posted here at Fred Drake's request.  Is it really such a  bad idea?

Don't look at me.  I'm busy working on inspect and htmldoc. :)

Actually, i guess i probably didn't respond because it isn't
of immediate use to me.  Maybe this is the sort of thing that
might come in handy one day but that hordes of people aren't
desperate for.

Hmm.  Perhaps it's because people are used to saying "in string.digits"
instead of wanting isdigit() &c.

Hmm.  Perhaps it's also something that ought to be eventually
handled via the Unicode character property route.

Dunno.


-- ?!ng

"China is a big country, inhabited by many Chinese."
    -- Former French President Charles de Gaulle





From gstein at lyra.org  Fri Jun  2 00:34:13 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 1 Jun 2000 15:34:13 -0700 (PDT)
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <Pine.LNX.4.10.10006011531500.6088-100000@nebula.lyra.org>

On Thu, 1 Jun 2000, Eric S. Raymond wrote:
> There has been a vast and echoing silence about the ascii.py module I
> posted here at Fred Drake's request.  Is it really such a  bad idea?

hehe...

I'd say silence implies a +0 from people ("seems reasonable to go in, but
I wouldn't be upset if it doesn't").

If people thought it was bad, then you'd hear about it :-)

I took a quick look at it. Doesn't seem too bad, but I can't think of
anything that I've done in a long while that would require it. So I can't
really say "wow! put that baby in the distro!"

YMMV, of course :-)

Cheers,
-g

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




From esr at thyrsus.com  Fri Jun  2 00:51:45 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 1 Jun 2000 18:51:45 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <Pine.LNX.4.10.10006011531500.6088-100000@nebula.lyra.org>; from gstein@lyra.org on Thu, Jun 01, 2000 at 03:34:13PM -0700
References: <200006012236.SAA03578@snark.thyrsus.com> <Pine.LNX.4.10.10006011531500.6088-100000@nebula.lyra.org>
Message-ID: <20000601185145.A3667@thyrsus.com>

Greg Stein <gstein at lyra.org>:
> I took a quick look at it. Doesn't seem too bad, but I can't think of
> anything that I've done in a long while that would require it. So I can't
> really say "wow! put that baby in the distro!"

It starts to get pretty useful in conjunction with curses -- for example, in
writing interpreters for character-at-a-time command loops.

I have a new version that adds the following:

\begin{funcdesc}{ascii}{c}
Return the ASCII value corresponding to the low 7 bits of c.
\end{funcdesc}

The following function takes either a single-character string or
integer byte value; it returns a string.

\begin{funcdesc}{unctrl}{c}
Return a string representation of the ASCII character c.  If c is
printable, this string is the character itself.  If the character
is a control character (0x00-0x1f) the string consists of a caret
(^) followed by the corresponding uppercase letter.  If the character
is an ASCII delete (0x7f) the string is "^?".  If the character has
its meta bit (0x80) set, the meta bit is stripped, the preceding rules
applied, and "!" prepended to the result.
\end{funcdesc}

Finally, the module supplies a 33-element string array 
called controlnames that contains the ASCII mnemonics for the
thirty-two ASCII control characters from 0 (NUL) to 0x1f (US),
in order, plus the mnemonic "SP" for space.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Certainly one of the chief guarantees of freedom under any government,
no matter how popular and respected, is the right of the citizens to
keep and bear arms.  [...] the right of the citizens to bear arms is
just one guarantee against arbitrary government and one more safeguard
against a tyranny which now appears remote in America, but which
historically has proved to be always possible.
        -- Hubert H. Humphrey, 1960



From akuchlin at cnri.reston.va.us  Fri Jun  2 01:32:32 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Thu, 1 Jun 2000 19:32:32 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>; from esr@snark.thyrsus.com on Thu, Jun 01, 2000 at 06:36:29PM -0400
References: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <20000601193232.A12831@newcnri.cnri.reston.va.us>

On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
>There has been a vast and echoing silence about the ascii.py module I
>posted here at Fred Drake's request.  Is it really such a  bad idea?

One misgiving I had was locales; is it a bug or a feature that locales
aren't supported, as they are for the C isdigit(), isalpha(), &c,
functions?  I'm not entirely sure which it is.  (The locale module
doesn't expose the C is*() functions, though I think they're used in
constructing string.letters.)

--amk



From esr at thyrsus.com  Fri Jun  2 01:45:11 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 1 Jun 2000 19:45:11 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <20000601193232.A12831@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Thu, Jun 01, 2000 at 07:32:32PM -0400
References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us>
Message-ID: <20000601194511.A3948@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
> >There has been a vast and echoing silence about the ascii.py module I
> >posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> One misgiving I had was locales; is it a bug or a feature that locales
> aren't supported, as they are for the C isdigit(), isalpha(), &c,
> functions?  I'm not entirely sure which it is.  (The locale module
> doesn't expose the C is*() functions, though I think they're used in
> constructing string.letters.)

It's a feature.  That's why this module is called ascii, not string :-)
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

  "...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
        -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),



From paul at prescod.net  Fri Jun  2 05:53:41 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 01 Jun 2000 22:53:41 -0500
Subject: [Python-Dev] ascii.py?
References: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <39372FC5.DE1CE8EA@prescod.net>

"Eric S. Raymond" wrote:
> 
> There has been a vast and echoing silence about the ascii.py module I
> posted here at Fred Drake's request.  Is it really such a  bad idea?

Without looking closely, or even being particularly knowledgable (how's
that for a disclaimer!) my instinctive reaction was: "does the ASCII
subset of Unicode need its own module just before we add Unicode to the
language?"

It may be that there are some semantics of ASCII that are not captured
in the Unicode spec. and thus are not generalizable. I'm pretty
confident that these ones ARE generalizable:

isalnum
isalpha
isascii
islower
isupper
isspace
isxdigit

How do Unicode users get this information from the famous Unicode
database and why not merge the Unicode and ASCII versions in 1.6?

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/~perlis-alan/quotes.html



From esr at thyrsus.com  Fri Jun  2 07:43:54 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 2 Jun 2000 01:43:54 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <39372FC5.DE1CE8EA@prescod.net>; from paul@prescod.net on Thu, Jun 01, 2000 at 10:53:41PM -0500
References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net>
Message-ID: <20000602014353.A5211@thyrsus.com>

Paul Prescod <paul at prescod.net>:
> "Eric S. Raymond" wrote:
> > 
> > There has been a vast and echoing silence about the ascii.py module I
> > posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> Without looking closely, or even being particularly knowledgable (how's
> that for a disclaimer!) my instinctive reaction was: "does the ASCII
> subset of Unicode need its own module just before we add Unicode to the
> language?"
> 
> It may be that there are some semantics of ASCII that are not captured
> in the Unicode spec. and thus are not generalizable.

ascii.ctrl is one such.

>                                                       I'm pretty
> confident that these ones ARE generalizable:
> 
> isalnum
> isalpha
> isascii
> islower
> isupper
> isspace
> isxdigit
> 
> How do Unicode users get this information from the famous Unicode
> database and why not merge the Unicode and ASCII versions in 1.6?

Answer: ascii.py is not designed for text processing.  I wrote it to package
some functions useful for classifying *ASCII* data, especially in the
context of roguelike programs that interpret keystrokes coming in through
a curses interface.

(Where this all touches ground is CML2, my replacement configuration 
system for the Linux kernel.)
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

..every Man has a Property in his own Person. This no Body has any
Right to but himself.  The Labour of his Body, and the Work of his
Hands, we may say, are properly his. .... The great and chief end
therefore, of Mens uniting into Commonwealths, and putting themselves
under Government, is the Preservation of their Property.
	-- John Locke, "A Treatise Concerning Civil Government"



From gstein at lyra.org  Fri Jun  2 10:43:13 2000
From: gstein at lyra.org (Greg Stein)
Date: Fri, 2 Jun 2000 01:43:13 -0700 (PDT)
Subject: [Python-Dev] httplib (was: Adding LDAP to the Python core... ?!)
In-Reply-To: <14645.51445.963154.817309@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.10006020134050.17073-100000@nebula.lyra.org>

It looks like a definite bug. I have *no* idea, tho, why it is doing
that... I did quite a bit of testing with chunked replies. Admittedly,
though, I didn't stack up requests like you've done in your test. I'm
wrapping up mod_dav at the moment, so I don't really have time to look
deeply into this. Mebbe next week?

Regarding the pipeline request thing. I think it would probably be best to
just drop the whole "hold the previous response and wait for it to be
closed" thing. I don't know why that is in there; probably a leftover
(converted) semantic from the old-style HTTP() class. I'd be quite fine
just axing it and allowing the client to shove ten requests down the pipe
before pulling the first response back out.

Oh. Wait. Maybe that was it. You can't read the "next" response until the
first one has been read. Well... no need to block putting new responses;
we just need to create a way to "get the next reply" and/or "can I get the
next reply yet?"

Cheers,
-g

p.s. Moshe also had a short list of review items. I read thru them, but
not with the code in hand to understand some of his specifics.


On Wed, 31 May 2000, Jeremy Hylton wrote:
> >>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
> 
>   GS> [ and recall my email last week that I've updated httplib.py and
>   GS> posted it to my web pages; it is awaiting review for integration
>   GS> into the Python core; it still needs docs and more testing
>   GS> scenarios, tho
> 
> I've been looking at the httplib code, and I found what may be a bug.
> Not sure, because I'm not sure how the API works for pipelined
> requests. 
> 
> I've got some test code that looks a bit like this:
> 
> def test_new_interface_series(urls):
>     paths = []
>     the_host = None
>     for url in urls:
>         host, path = get_host_and_path(url)
>         if the_host is None:
>             the_host = host
>         else:
>             assert host == the_host
>         paths.append(path)
>         
>     conn = httplib.HTTPConnection(the_host)
>     for path in paths:
>         conn.request('GET', path, headers={'User-Agent': 'httplib/Python'})
>     for path in paths:
>         errcode, errmsg, resp = conn.getreply()
>         buf = resp.read()
>         if errcode == 200:
>             print errcode, resp.headers
>         else:
>             print errcode, `errmsg`, resp
>         print resp.getheader('Content-Length'), len(buf)
>         print repr(buf[:40])
>         print repr(buf[-40:])
>         print
>     conn.close()
> 
> test_new_interface_series(['http://www.python.org/',
>                         'http://www.python.org/pics/PyBanner054.gif',
>                         'http://www.python.org/pics/PythonHi.gif',
>                         'http://www.python.org/Jobs.html',
>                         'http://www.python.org/doc/',
>                         'http://www.python.org/doc/current/',
>                            ])
> 
> The second loop that reads the replies gets fouled up after a couple
> of responses.  I added even more debugging and found that the first
> line of the corrupted response is
> 
> > 'ontent-Type: text/html\015\012'
> 
> It looks like some part of the program is consuming too much input.  I
> haven't been able to figure out what part yet.  Hoping that you might
> have some good ideas.
> 
> Thinking about this issue, I came up with a potential API problem.
> You must read the body after calling getreply and before calling
> getreply a second time.  This kind of implicit requirement is a bit
> tricky.  It would help if the implementation could raise an error if
> this happens.  It might be even better if it just worked, although it
> seems a bit too magical.
> 
> Jeremy
> 

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






From mal at lemburg.com  Fri Jun  2 10:11:05 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 10:11:05 +0200
Subject: [Python-Dev] Re: [Patches] Translating doc strings
References: <200006020701.JAA28620@pandora>
Message-ID: <39376C19.53A01A27@lemburg.com>

Martin von Loewis wrote:
> 
> To simplify usage of Python for people who don't speak English well,
> I'd like to start a project translating the doc strings in the Python
> library. This has two aspects:
> 
> 1. there must be a simple way to access the translated doc strings

Do you plan to use GNU gettext here ? (This would cause the
translated version of Python to fall under GPL, AFAIK)

I'd propose to use the existing doc-strings as keys to 
a translation mapping. This assures that existing doc-strings
remain intact and that the actual translation process is
done at query time, e.g. by using a help() built-in function.

> 2. there must be actual translations to the various native languages
>    of Python users.
> 
> Since the second task is much more complicated, I submit a snapshot of
> this project, namely, a message catalog of the doc strings in the
> Python libraries, taken from the CVS; along with a snapshot of the
> German translations. I intend to complete the German translations in
> the coming weeks, but I want to give other translators a chance to
> also start working on that.
> 
> Please note that extracting the docstrings was not straight-forward;
> I've used Fran?ois Pinard's most excellent po-utils 0.5 as a starting
> point, and enhanced it with the capability to recognize __doc__[] in C
> code, so that I would also get (most of) the doc strings in C modules.
> I plan to update this catalog a few times before Python 1.6 is
> released, so that translators can update their translations.
> 
> A key point is finding translators. I propose to use the
> infrastructure of the GNU translation project for that: There are
> established teams for all major languages, and an infrastructure (also
> maintained by Fran?ois) where notifications about new catalogs are
> automatically distributed to the teams. That should not stop
> volunteers which don't currently participate in the GNU translation
> project from translating - however, they should announce that they
> plan to work on translating these messages to avoid duplication of
> work.

This will only work iff the translations can be submitted
via the usual "post to patches with dislcaimer" method...
aren't the GNU people interested in putting the translations
under the GPL ?

> Another matter is where the catalogs should live in the Python source
> tree. I propose to have a Misc/po directory, which will contain both
> the PO catalogues, as well as the binary .mo objects; only the latter
> will be installed during the installation process.
> 
> Please let me know what you think, in particular, whether I can submit
> the catalog to the translation teams.
> 
> Regards,
> Martin
> 
>   ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>               Name: doc.tgz
>    doc.tgz    Type: unspecified type (application/octet-stream)
>           Encoding: base64

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From mal at lemburg.com  Fri Jun  2 09:55:04 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 09:55:04 +0200
Subject: [Python-Dev] ascii.py?
References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us>
Message-ID: <39376858.55D4F778@lemburg.com>

Andrew Kuchling wrote:
> 
> On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
> >There has been a vast and echoing silence about the ascii.py module I
> >posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> One misgiving I had was locales; is it a bug or a feature that locales
> aren't supported, as they are for the C isdigit(), isalpha(), &c,
> functions?  I'm not entirely sure which it is.  (The locale module
> doesn't expose the C is*() functions, though I think they're used in
> constructing string.letters.)

FYI, both strings and Unicode object already have a few
.isXXX() methods:

	isdigit(), islower(), isspace(), istitle(), isupper()

For strings these use the C APIs (which are locale aware),
for Unicode the built in mappings are used.

BTW, I haven't looked at the docs lately, but are the string
and Unicode methods already documented ? All of them
have doc-strings, so it should be easy extracting the data
to build a TeX-file.

On the topic of adding ascii.py, I'm +0 -- I don't currently
have a need for it, but writing .append(ascii.CR + ascii.LF)
does add to the readability of scripts.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From mal at lemburg.com  Fri Jun  2 10:02:35 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 10:02:35 +0200
Subject: [I18n-sig] Re: [Python-Dev] ascii.py?
References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net>
Message-ID: <39376A1B.10E45C7B@lemburg.com>

Paul Prescod wrote:
> 
> "Eric S. Raymond" wrote:
> >
> > There has been a vast and echoing silence about the ascii.py module I
> > posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> Without looking closely, or even being particularly knowledgable (how's
> that for a disclaimer!) my instinctive reaction was: "does the ASCII
> subset of Unicode need its own module just before we add Unicode to the
> language?"
> 
> It may be that there are some semantics of ASCII that are not captured
> in the Unicode spec. and thus are not generalizable. I'm pretty
> confident that these ones ARE generalizable:
> 
> isalnum
> isalpha
> isascii
> islower
> isupper
> isspace
> isxdigit
> 
> How do Unicode users get this information from the famous Unicode
> database and why not merge the Unicode and ASCII versions in 1.6?

Note that many of the above are already implemented as
string|Unicode methods.

The Unicode database is accessible via the unicodedata
module. The specs for the used APIs and constants can
be found in the Unicode database description file
on www.unicode.org.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From loewis at informatik.hu-berlin.de  Fri Jun  2 14:33:07 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 14:33:07 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <39376C19.53A01A27@lemburg.com> (mal@lemburg.com)
References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com>
Message-ID: <200006021233.OAA16962@pandora>

> Do you plan to use GNU gettext here ? (This would cause the
> translated version of Python to fall under GPL, AFAIK)

No, I plan to use the Python gettext module, which is currently being
integrated into Python. It will either use the system's gettext
library, or read mo files using pure Python.

> I'd propose to use the existing doc-strings as keys to 
> a translation mapping. This assures that existing doc-strings
> remain intact and that the actual translation process is
> done at query time, e.g. by using a help() built-in function.

This is more or less what I've planned. I'd propose to call the
function doc, with an interface like

>>> doc(time.time)
time() -> Gleitkommazahl

Gib die aktuelle Zeit in Sekunden seit Beginn der Epoche zur?ck.
Sekundenbruchteile sind vorhanden, falls die Systemuhr sie bereitstellt.

It won't use a dictionary, though, but the underlying gettext query
mechanism. Exact naming and parameters are certainly subject to
discussion, my proposal would be

doc(object, doprint=1, translate=1)

so that users save quite some typing over

>>> print time.time.__doc__ 
time() -> floating point number

Return the current time in seconds since the Epoch.
Fractions of a second may be present if the system clock provides them.

> This will only work iff the translations can be submitted
> via the usual "post to patches with dislcaimer" method...
> aren't the GNU people interested in putting the translations
> under the GPL ?

Is it really necessary to have the translations posted to
patches at python.org? Or would it be sufficient if translators express
their disclaimer in some other way.

I don't think the translation teams are "the GNU people"; the
translators accepted to assign their copyright to the FSF for the
translations they did - I'd assume at least some of them would also
accept maintaining the copyright, or assigning it to the Python
Consortium (or whoever else wants it). It's more that the Python
distributor would need to make suggestions what the copyright on
translations should be - I'm sure that could be clearly communicated
to the translators.

Regards,
Martin



From fdrake at acm.org  Fri Jun  2 14:50:35 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 2 Jun 2000 08:50:35 -0400 (EDT)
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>
References: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <14647.44443.651246.979946@cj42289-a.reston1.va.home.com>

Eric S. Raymond writes:
 > There has been a vast and echoing silence about the ascii.py module I
 > posted here at Fred Drake's request.  Is it really such a  bad idea?

  Did you get my comments?


  -Fred

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




From bwarsaw at python.org  Fri Jun  2 15:37:42 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Fri, 2 Jun 2000 09:37:42 -0400 (EDT)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
References: <200006020701.JAA28620@pandora>
	<39376C19.53A01A27@lemburg.com>
	<200006021233.OAA16962@pandora>
Message-ID: <14647.47270.330318.807347@anthem.python.org>

>>>>> "MvL" == Martin von Loewis <loewis at informatik.hu-berlin.de> writes:

    MvL> No, I plan to use the Python gettext module, which is
    MvL> currently being integrated into Python. It will either use
    MvL> the system's gettext library, or read mo files using pure
    MvL> Python.

pygettext is in Tools/i18n, and I've been working with James
Henstridge and Peter Funk on getting a standard gettext module
integrated into the core.  A few other things have bumped that down on
my list, but it's still there.

We'll still need xgettext to scan the C code.  Also, marking Python
module docstrings is a bit problematic.  I've resorted to Something
Really Ugly:

-------------------- snip snip --------------------
try:
    import fintl
    _ = fintl.gettext
except ImportError:
    def _(s): return s


__doc__ = _("""pygettext -- Python equivalent of xgettext(1)
...")
-------------------- snip snip --------------------

Yuck.

-Barry



From pf at artcom-gmbh.de  Fri Jun  2 15:57:32 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Fri, 2 Jun 2000 15:57:32 +0200 (MEST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <14647.47270.330318.807347@anthem.python.org> from "Barry A. Warsaw" at "Jun 2, 2000  9:37:42 am"
Message-ID: <m12xrx6-000DifC@artcom0.artcom-gmbh.de>

Hi, 

[Barry A. Warsaw]:
> pygettext is in Tools/i18n, and I've been working with James
> Henstridge and Peter Funk on getting a standard gettext module
> integrated into the core.  A few other things have bumped that down on
> my list, but it's still there.

I will try to make some progress.  Currently I'm not sure how to
define a class 'Translator' ...  I'm open for suggestions.  James
has also made some interesting points.

> We'll still need xgettext to scan the C code.  Also, marking Python
> module docstrings is a bit problematic.  I've resorted to Something
> Really Ugly:
> 
> -------------------- snip snip --------------------
> try:
>     import fintl
>     _ = fintl.gettext
> except ImportError:
>     def _(s): return s
> 
> 
> __doc__ = _("""pygettext -- Python equivalent of xgettext(1)
> ...")
> -------------------- snip snip --------------------
> 
> Yuck.

I agree: this is really ugly.  Since doc-strings are something special,
I don't think, we should travel further down this road.  I believe,
we should use a special doc-string extration-tool (possibly build
on top of ping's 'inspect.py'?), which will then create a .pot-file
solely out of __doc__-strings.

Regards, Peter.



From loewis at informatik.hu-berlin.de  Fri Jun  2 17:03:50 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 17:03:50 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <14647.47270.330318.807347@anthem.python.org>
	(bwarsaw@python.org)
References: <200006020701.JAA28620@pandora>
	<39376C19.53A01A27@lemburg.com>
	<200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org>
Message-ID: <200006021503.RAA26314@pandora>

> We'll still need xgettext to scan the C code.

Please have a look at my lib.pot; I've been using xpot to extract the
C doc strings, which aren't currently marked-up in the Python source.

As for module docstrings: xpot doesn't recognize them either, but I
think it could be improved to do so. However, that would give a
substantial increase of the catalogs, so I'd recommend to add them
only when the translators are done with the first round of
translation. Having the full set of distutils doc strings in the
catalog is already a substantial amount of text to translate...

Regards,
Martin



From loewis at informatik.hu-berlin.de  Fri Jun  2 17:05:35 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 17:05:35 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <m12xrx6-000DifC@artcom0.artcom-gmbh.de> (pf@artcom-gmbh.de)
References: <m12xrx6-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <200006021505.RAA26338@pandora>

> I agree: this is really ugly.  Since doc-strings are something special,
> I don't think, we should travel further down this road.  I believe,
> we should use a special doc-string extration-tool (possibly build
> on top of ping's 'inspect.py'?), which will then create a .pot-file
> solely out of __doc__-strings.

I agree. Again, I'd like to advertise Fran?ois Pinard's xpot, which
can extract doc strings from both Python code and C code.

Regards,
Martin



From moshez at math.huji.ac.il  Fri Jun  2 19:52:59 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Fri, 2 Jun 2000 20:52:59 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
Message-ID: <Pine.GSO.4.10.10006022048430.9466-100000@sundial>

Trusting OS-based mtimes for .pyc caching has some inherent problems.
(Clock syncing and similar) Frankly, though I've never been bitten by
this, it does give me an uncomfortable feeling. What if, instead, we'd use
md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
problems is miniscule compared to the real problems clock syncing has
already caused. (I think I remember some problem with .pyc's on IIS, but
I may just be hallucinating)

Problems:
.pyc size would increase by 24 bytes <wink>

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From trentm at activestate.com  Fri Jun  2 20:14:17 2000
From: trentm at activestate.com (Trent Mick)
Date: Fri, 2 Jun 2000 11:14:17 -0700
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer?
Message-ID: <20000602111417.A17233@activestate.com>

So, is PyMarshal_WriteLongToFile intended to write a C long, regardless of
its size, or is it intended to alway write 32-bits?

Currently it just writes 32-bits and if sizeof(long) > 4 for that platform
then it is silently truncated. PyMarshal_WriteLongToFile is currently only
used (in the core anyway) to write the magic number and timestamp for .pyc
files in import.c.

The current situation is pretty misleading. If you write a long directly with
PyMarshal_WriteLongToFile your long is truncated to 32-bits. However, if you
write a long indirectly by PyMarshal_WriteObjectToFile, where that Python
object is or contains a PyInt (C long), then the long is *not* truncated.

Options:

1. leave it, who cares

2. - change PyMarshal_WriteLongToFile to write 64-bits if long is 64-bits
   - add something like PyMarshal_WriteInt32ToFile for the benefit of users
	 like import.c that want to control exactly how many bytes get written

3. - change PyMarshal_WriteLongToFile to raise an exception if the long
	 overflows a 32-bit range

Thanks,
Trent


-- 
Trent Mick
trentm at activestate.com



From pf at artcom-gmbh.de  Fri Jun  2 21:21:30 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Fri, 2 Jun 2000 21:21:30 +0200 (MEST)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006022048430.9466-100000@sundial> from Moshe Zadka at "Jun 2, 2000  8:52:59 pm"
Message-ID: <m12xx0c-000DifC@artcom0.artcom-gmbh.de>

hi,

Moshe Zadka wrote:
> Trusting OS-based mtimes for .pyc caching has some inherent problems.
> (Clock syncing and similar) Frankly, though I've never been bitten by
> this, it does give me an uncomfortable feeling. What if, instead, we'd use
> md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
> problems is miniscule compared to the real problems clock syncing has
> already caused. (I think I remember some problem with .pyc's on IIS, but
> I may just be hallucinating)

The timestamp is returned by simply 'stat'ing the .py file.  If you
want more, you actually would have to open the .py files all the time.
This would be trading a big performance penalty for a security, that
will almost always not needed.  In Unix many sub systems (for example
'make' depend on a monotone system clock.  A random jumping clock
would break many of them anyway.

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)



From gstein at lyra.org  Fri Jun  2 21:53:21 2000
From: gstein at lyra.org (Greg Stein)
Date: Fri, 2 Jun 2000 12:53:21 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006022048430.9466-100000@sundial>
Message-ID: <Pine.LNX.4.10.10006021251140.20995-100000@nebula.lyra.org>

On Fri, 2 Jun 2000, Moshe Zadka wrote:
> Trusting OS-based mtimes for .pyc caching has some inherent problems.
> (Clock syncing and similar) Frankly, though I've never been bitten by
> this, it does give me an uncomfortable feeling. What if, instead, we'd use
> md5- or sha-based approach?

That is an expensive computation. You'd have to read the whole file in and
compute the hash.

Today, we simply stat() each file. If the .pyc looks valid, we open it and
check the date stamp against one of those stat's.

You would be adding an open(), a read of the full file, and compute a
hash -- to every import of a .pyc.


-1

Cheers,
-g

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




From mal at lemburg.com  Fri Jun  2 21:13:20 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 21:13:20 +0200
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
References: <Pine.GSO.4.10.10006022048430.9466-100000@sundial>
Message-ID: <39380750.97CD3BA0@lemburg.com>

Moshe Zadka wrote:
> 
> Trusting OS-based mtimes for .pyc caching has some inherent problems.
> (Clock syncing and similar) Frankly, though I've never been bitten by
> this, it does give me an uncomfortable feeling. What if, instead, we'd use
> md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
> problems is miniscule compared to the real problems clock syncing has
> already caused. (I think I remember some problem with .pyc's on IIS, but
> I may just be hallucinating)
> 
> Problems:
> .pyc size would increase by 24 bytes <wink>

Much worse: you'd have to recalculate the MD5-sum every time
you import the .pyc file...

Frankly, I don't think this is needed at all ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From loewis at informatik.hu-berlin.de  Fri Jun  2 22:46:34 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 22:46:34 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <Pine.SGI.3.96.1000602115722.30600f-100000@happy> (message from
	Ka-Ping Yee on Fri, 2 Jun 2000 12:07:22 -0700 (PDT))
References: <Pine.SGI.3.96.1000602115722.30600f-100000@happy>
Message-ID: <200006022046.WAA29600@pandora>

> But presumably we want to get all the strings, don't we?

Certainly not. For example, in ftplib, the string "anonymous" should
not be translated - it would end up as "anonym" in German, and that
would not be accepted by FTP servers. In general, great care is needed
to select translatable strings. 

For example, the GNU ls program was localized to print the month names
in German. Pretty safe, eh? Now, the emacs dired mode wouldn't
recognize any file names in the list output anymore, because it
had a regular expression to detect the various fields, which involved
an alternative list for all the month names...

Regards,
Martin



From pingster at ilm.com  Fri Jun  2 21:07:22 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Fri, 2 Jun 2000 12:07:22 -0700 (PDT)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <m12xrx6-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.SGI.3.96.1000602115722.30600f-100000@happy>

On Fri, 2 Jun 2000, Peter Funk wrote:
> 
> I agree: this is really ugly.  Since doc-strings are something special,
> I don't think, we should travel further down this road.  I believe,
> we should use a special doc-string extration-tool (possibly build
> on top of ping's 'inspect.py'?), which will then create a .pot-file
> solely out of __doc__-strings.

Getting __doc__ strings is pretty easy (inspect.py is one possibility).
But presumably we want to get all the strings, don't we?

That should be trivial with tokenize, right?

    ---- getstrings.py -----

    import sys, tokenize
    strings = []
    def tokeneater(type, token, start, end, line):
        if type == tokenize.STRING: strings.append(eval(token))
            
    file = open(sys.argv[1])
    tokenize.tokenize(file.readline, tokeneater)
    print strings

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

    % ./getstrings.py /usr/local/lib/python1.5/calendar.py 
    ['calendar.error', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday', 'Sunday', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun', '', 'January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'No
vember', 'December', '   ', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec', 'bad month number', ' ', ' ', '', '', ' ', ' ', '\012', '\012', '\012', ' ', '', '', ' ']

Am i missing something?


-- ?!ng




From gstein at lyra.org  Fri Jun  2 23:32:52 2000
From: gstein at lyra.org (Greg Stein)
Date: Fri, 2 Jun 2000 14:32:52 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <m12xx0c-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>

On Fri, 2 Jun 2000, Peter Funk wrote:
> Moshe Zadka wrote:
> > Trusting OS-based mtimes for .pyc caching has some inherent problems.
> > (Clock syncing and similar) Frankly, though I've never been bitten by
> > this, it does give me an uncomfortable feeling. What if, instead, we'd use
> > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
> > problems is miniscule compared to the real problems clock syncing has
> > already caused. (I think I remember some problem with .pyc's on IIS, but
> > I may just be hallucinating)
> 
> The timestamp is returned by simply 'stat'ing the .py file.  If you
> want more, you actually would have to open the .py files all the time.
> This would be trading a big performance penalty for a security, that
> will almost always not needed.  In Unix many sub systems (for example
> 'make' depend on a monotone system clock.  A random jumping clock
> would break many of them anyway.

He does have a point, but I think the wrong solution :-)

While the clock may be monotonically increasing on one system, it isn't
always the case when things like NFS come into play.

I recall a case back '95 when I was editing a .py over an NFS mount and
running the code on the target machine. The clocks on the two boxes were
off by about three seconds. I was going thru the edit/run/edit/run cycle
so quickly, that at one point, I saved a .py file that was older than the
associated .pyc file.

Needless to say, I was really confused that my recent edit didn't produce
the desired result :-)

Cheers,
-g

p.s. and no, I don't know why the internal timestamp didn't take effect

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




From pingster at ilm.com  Sat Jun  3 01:10:01 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Fri, 2 Jun 2000 16:10:01 -0700 (PDT)
Subject: [Python-Dev] Protecting __name__ &c.
Message-ID: <Pine.SGI.3.96.1000602160710.30600q-100000@happy>

Would it be too much trouble to prevent replacing
double-underscore attributes like __name__ and __file__?

I'll accept a "consenting adults" argument -- it's just
that somehow this makes me uneasy:

    Python 1.5.2 (#54, Jul 14 1999, 12:50:51) [C] on irix6
    Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
    >>> import foo
    >>> foo.__name__
    'bar'
    >>> foo.__file__
    'bar.py'
    >>> foo
    <module 'bar' from 'bar.py'>

Of course, there is no 'bar.py'.  'foo.py' just contains

    __file__ = 'bar.py'
    __name__ = 'bar'

(If you say i deserved to be punished for such heresy, fine...)



-- ?!ng




From mhammond at skippinet.com.au  Sat Jun  3 01:21:07 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 3 Jun 2000 09:21:07 +1000
Subject: [Python-Dev] Protecting __name__ &c.
In-Reply-To: <Pine.SGI.3.96.1000602160710.30600q-100000@happy>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEECCMAA.mhammond@skippinet.com.au>

> Would it be too much trouble to prevent replacing
> double-underscore attributes like __name__ and __file__?

This can be handy sometimes.

> I'll accept a "consenting adults" argument -- it's just
> that somehow this makes me uneasy:

OK - accept it :-)  Just dont do it if it makes you uneasy.

>     >>> import foo
>     >>> foo.__name__
>     'bar'
>     >>> foo.__file__
>     'bar.py'
>     >>> foo
>     <module 'bar' from 'bar.py'>

That is no worse than, say:

>>> a=1
>>> globals()['a']=2
>>> a
2

So you could make the same argument that globals() should be read-only, to
force you to do the "normal" thing.

To me, this is one of Python's big features.  I dont want it holding my
hand so tightly it cuts circulation :-)

Mark.




From akuchlin at cnri.reston.va.us  Sat Jun  3 05:15:50 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Fri, 2 Jun 2000 23:15:50 -0400
Subject: [Python-Dev] What's New (first draft)
Message-ID: <20000602231550.A986@newcnri.cnri.reston.va.us>

I've put up the crude first draft of a "What's New in Python 1.6" article,
co-written with Moshe Zadka.  Please offer comments (or even patches to the
LaTeX!). 

http://www.python.net/crew/amk/python/writing/new-python/

PDF, DVI, ASCII, and the LaTeX source are in:
	ftp://www.python.net/pub/crew/amk/new/

Various people are mentioned by name in the document ("effbot did
this; MAL did that; Christian did that other thing...") because I want to
emphasize the number of contributors to this release; does everyone think
this is a good idea?  If I've missed your name, or credited you wrongly,
please let me know.

--amk



From akuchlin at cnri.reston.va.us  Sat Jun  3 05:25:21 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Fri, 2 Jun 2000 23:25:21 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
Message-ID: <20000602232521.B986@newcnri.cnri.reston.va.us>

I've slightly revised the 1.6 jobs list
at http://www.python.net/crew/amk/python/1.6-jobs.html .
Things still on the TODO list, maybe:

Import hooks revamp (or is this a post-1.6 thing?) 
Update the documentation to match 1.6 changes. 
Document more undocumented modules (goes without saying, really...) : codecs,
	unicodedata, mmap, pyexpat, curses, regrtest. 
Unicode: Compress the size of unicodedatabase 
Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch)
Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?)
Delete obsolete subdirectories in Demo/ directory 
Refurbish Demo subdirectories to be properly documented, match modern coding
	style, etc. 
Fix ./ld_so_aix installation problem on AIX 
Make test.regrtest.py more usable outside of thePython test suite 
Conservative garbage collection of cycles (maybe -- I don't know what GvR
	thinks about this)
Changes to PyExpat module
Test the hell out of SRE

The end of coding may be in sight, leaving only the job of documenting
everything new.  I'm getting kind of worried about the lengthening backlog
of patches, though; maybe next week we can start cutting it down? (Quick,
while Guido's away, everyone come up with new keywords and check them in!)

--amk



From esr at thyrsus.com  Sat Jun  3 05:49:16 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 2 Jun 2000 23:49:16 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Fri, Jun 02, 2000 at 11:25:21PM -0400
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <20000602234916.B9680@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> Document more undocumented modules (goes without saying, really...) : codecs,
> 	unicodedata, mmap, pyexpat, curses, regrtest. 

About curses.  Have you got the entry points listed and dxescribed yet?
If so, I'll flesh out the docs with my tutorial stuff.

We have a volunteer maintainer for curses after release, now, BTW.  It's
new Pythoneer Jim Dennis, the "Answer Guy" from the Linux Gazette.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The end move in politics is always to pick up a gun.
	-- R. Buckminster Fuller



From bwarsaw at python.org  Sat Jun  3 06:41:42 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Sat, 3 Jun 2000 00:41:42 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <14648.35974.486959.379543@anthem.python.org>

Did we ever decide on building in thread support by default?  I'd
really like to see threads enabled by default in 1.6 and I /think/
it'll just take some autoconf hacking, which I'm willing to do.  Are
there any objections to building in threads support by default if
autoconf detects threads?

-Barry



From moshez at math.huji.ac.il  Sat Jun  3 08:05:09 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 3 Jun 2000 09:05:09 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>
Message-ID: <Pine.GSO.4.10.10006030900030.14749-100000@sundial>

On Fri, 2 Jun 2000, Greg Stein wrote:

> He does have a point, but I think the wrong solution :-)

In my defense, it was after spending the whole day on my feet giving a
lecture, or driving (for 12 hours).

But it does bother me, even if the solution is terrible.
How about having, in addition to the time-stamp, the size of the file?
At least on UNIX, it comes for free with the same stat call.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From moshez at math.huji.ac.il  Sat Jun  3 09:56:15 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 3 Jun 2000 10:56:15 +0300 (IDT)
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit
 integer?
In-Reply-To: <20000602111417.A17233@activestate.com>
Message-ID: <Pine.GSO.4.10.10006030833470.14749-100000@sundial>

On Fri, 2 Jun 2000, Trent Mick wrote:

> 3. - change PyMarshal_WriteLongToFile to raise an exception if the long
> 	 overflows a 32-bit range

+1 on that, finally non-portable integers will cause an exception.

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com





From moshez at math.huji.ac.il  Sat Jun  3 10:11:45 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 3 Jun 2000 11:11:45 +0300 (IDT)
Subject: [Python-Dev] Protecting __name__ &c.
In-Reply-To: <Pine.SGI.3.96.1000602160710.30600q-100000@happy>
Message-ID: <Pine.GSO.4.10.10006031109180.14749-100000@sundial>

On Fri, 2 Jun 2000, Ka-Ping Yee wrote:

> Would it be too much trouble to prevent replacing
> double-underscore attributes like __name__ and __file__?

Well, special casing seems like a bad idea on the face of it. Where does
it stop? The correct way to "solve" this, is to add declarations to
Python, including "constant" declaration, and then saying that __name__
and __file__ are "implicitly declared" constants.

please-scatter-IMHOs-generously-throughtout-the-mail-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From gstein at lyra.org  Sat Jun  3 11:52:39 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 02:52:39 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14648.35974.486959.379543@anthem.python.org>
Message-ID: <Pine.LNX.4.10.10006030252230.28613-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Barry A. Warsaw wrote:
> Did we ever decide on building in thread support by default?  I'd
> really like to see threads enabled by default in 1.6 and I /think/
> it'll just take some autoconf hacking, which I'm willing to do.  Are
> there any objections to building in threads support by default if
> autoconf detects threads?

+1 -- if they are there, then build them in!

Cheers,
-g

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




From gmcm at hypernet.com  Sat Jun  3 13:26:18 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Sat, 3 Jun 2000 07:26:18 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <1252090883-19062603@hypernet.com>

Andrew Kuchling wrote:

> I've slightly revised the 1.6 jobs list
> at http://www.python.net/crew/amk/python/1.6-jobs.html .
> Things still on the TODO list, maybe:
> 
> Import hooks revamp (or is this a post-1.6 thing?) 

The import SIG was created to resolve the controversies 
around imputils. The archives of the import SIG contain 
absolutely no controversy. So I say do it.

- Gordon



From skip at mojam.com  Sat Jun  3 14:15:28 2000
From: skip at mojam.com (Skip Montanaro)
Date: Sat, 3 Jun 2000 07:15:28 -0500 (CDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>
References: <m12xx0c-000DifC@artcom0.artcom-gmbh.de>
	<Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>
Message-ID: <14648.63200.850429.304545@beluga.mojam.com>

    Greg> I recall a case back '95 when I was editing a .py over an NFS
    Greg> mount and running the code on the target machine. The clocks on
    Greg> the two boxes were off by about three seconds. I was going thru
    Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved
    Greg> a .py file that was older than the associated .pyc file.

A help I think would be to compare the mtimes of the .py and .pyc files with 
the current system clock and squawk if either appears to have been created
in the future.  I believe this is what GNU make does.

Of course, the best solution to all of this is the non-Python solution: use
NTP so your clocks stay sync'd.  It's even available out-of-the-box on my
iMac...

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
"We have become ... the stewards of life's continuity on earth.  We did not
ask for this role...  We may not be suited to it, but here we are."
- Stephen Jay Gould



From moshez at math.huji.ac.il  Sat Jun  3 14:53:47 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 3 Jun 2000 15:53:47 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com>
Message-ID: <Pine.GSO.4.10.10006031551470.17983-100000@sundial>

On Sat, 3 Jun 2000, Skip Montanaro wrote:

> Of course, the best solution to all of this is the non-Python solution: use
> NTP so your clocks stay sync'd.  It's even available out-of-the-box on my
> iMac...

But the "Python Way" was always to adapt: not to require One True Way, but
to use the facilities where it finds itself.

In any case, is there any objection to storing the size of the .py
alongside it's mtime in the .pyc, and regenerating if either is changed?
This is just as efficient, and much more reliable.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From mal at lemburg.com  Sat Jun  3 11:55:26 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 03 Jun 2000 11:55:26 +0200
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <3938D60E.391AAF31@lemburg.com>

Andrew Kuchling wrote:
> 
> I've slightly revised the 1.6 jobs list
> at http://www.python.net/crew/amk/python/1.6-jobs.html .
> Things still on the TODO list, maybe:
> 
> Import hooks revamp (or is this a post-1.6 thing?)
> Update the documentation to match 1.6 changes.
> Document more undocumented modules (goes without saying, really...) : codecs,
>         unicodedata, mmap, pyexpat, curses, regrtest.

I would appreciate some help with codec and unicodedata.
codec.py has quite a bit of __doc__ string documentation
which can be used more or less directly for the TeX docs.

> Unicode: Compress the size of unicodedatabase

Christian was working on this one, but I never got the
patches ... Chris ?

> Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch)

I wonder why that patch hasn't been accepted yet -- I guess
the patches list needs some more people willing to review things
and of course people with check in permissions.

I would volunteer to handle the above for the Unicode parts
of the distribution if someone would explain to me how to
checkin new code into SourceForge CVS.

> Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?)

Hmm, there are no XXX markings left in my version of that
file -- perhaps I've missed adding it to the patch sets...

Anyway, the file will have to undergo some rewrite now that
the default encoding strategy has changed. I'll fix that next
week.

> Delete obsolete subdirectories in Demo/ directory
> Refurbish Demo subdirectories to be properly documented, match modern coding
>         style, etc.
> Fix ./ld_so_aix installation problem on AIX
> Make test.regrtest.py more usable outside of thePython test suite
> Conservative garbage collection of cycles (maybe -- I don't know what GvR
>         thinks about this)
> Changes to PyExpat module
> Test the hell out of SRE
> 
> The end of coding may be in sight, leaving only the job of documenting
> everything new.  I'm getting kind of worried about the lengthening backlog
> of patches, though; maybe next week we can start cutting it down? (Quick,
> while Guido's away, everyone come up with new keywords and check them in!)

:-)

Still, you've got a point there: Trent's patches are getting
piled up and due to the fact that they touch many different
parts of the code, they are likely to get in the way of other
patches.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From jeremy at beopen.com  Sat Jun  3 18:11:48 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Sat, 3 Jun 2000 12:11:48 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <3938D60E.391AAF31@lemburg.com>
Message-ID: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>

M.-A. Lemburg wrote:
>I wonder why that patch hasn't been accepted yet -- I guess
>the patches list needs some more people willing to review things
>and of course people with check in permissions.

One of the problems I'm having is keeping track of which patches
are still outstanding.  This is really a management/tools problem.
I have a mailbox full of messages from the patches list -- some
of the messages are patches, others are discussion.  Some patches
supercede others or are duplicates.  It would help if we had better
tools for managing the submitted/pending patches.

SourceForge makes it a little more inconvenient to check which
patches have been applied.  Under the old CVS arrangement, it was
a local operation to do a cvs log or diff.  Now it's a slow network
operation that requires authentication.  (I really want a local
mirror of the entire CVS repository!)

Sorry for the excuses.  I think better tools would help a lot, but
we'll have to get more people checkin privileges regardless.

Jeremy







From tismer at tismer.com  Sat Jun  3 18:43:51 2000
From: tismer at tismer.com (Christian Tismer)
Date: Sat, 03 Jun 2000 18:43:51 +0200
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com>
Message-ID: <393935C7.7624448A@tismer.com>


"M.-A. Lemburg" wrote:

> > Unicode: Compress the size of unicodedatabase
> 
> Christian was working on this one, but I never got the
> patches ... Chris ?

Schmurpel :->

Something came in between where I couldn't resist
to work on... yes, the microthread stuff was it.

Ok, it is a pain for me to go for a sub-optimum solution,
but yep, I'll force me to write the code gen now.

...
> Still, you've got a point there: Trent's patches are getting
> piled up and due to the fact that they touch many different
> parts of the code, they are likely to get in the way of other
> patches.

patch-as-patch-can-ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com



From tismer at tismer.com  Sat Jun  3 18:44:31 2000
From: tismer at tismer.com (Christian Tismer)
Date: Sat, 03 Jun 2000 18:44:31 +0200
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com>
Message-ID: <393935EF.89AA40DF@tismer.com>


"M.-A. Lemburg" wrote:

> > Unicode: Compress the size of unicodedatabase
> 
> Christian was working on this one, but I never got the
> patches ... Chris ?

Schmurpel :->

Something came in between where I couldn't resist
to work on... yes, the microthread stuff was it.

Not to talk of the starship mess, which will hopefully
end by this weekend...

Ok, it is a pain for me to go for a sub-optimum solution,
but yep, I'll force me to write the code gen now.

...
> Still, you've got a point there: Trent's patches are getting
> piled up and due to the fact that they touch many different
> parts of the code, they are likely to get in the way of other
> patches.

patch-as-patch-can-ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com



From gstein at lyra.org  Sat Jun  3 21:41:19 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 12:41:19 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com>
Message-ID: <Pine.LNX.4.10.10006031236430.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Skip Montanaro wrote:
>     Greg> I recall a case back '95 when I was editing a .py over an NFS
>     Greg> mount and running the code on the target machine. The clocks on
>     Greg> the two boxes were off by about three seconds. I was going thru
>     Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved
>     Greg> a .py file that was older than the associated .pyc file.
> 
> A help I think would be to compare the mtimes of the .py and .pyc files with 
> the current system clock and squawk if either appears to have been created
> in the future.  I believe this is what GNU make does.

Sure, but to the target machine, the .pyc was fine and the .py was in the
past. :-)

Of course, the proper solution is to introduce compile/link stages into
Python so that we don't get bitten by 3-second clock differences.

:-)

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




From gstein at lyra.org  Sat Jun  3 22:26:00 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 13:26:00 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.8,2.9
In-Reply-To: <200006031941.MAA21418@slayer.i.sourceforge.net>
Message-ID: <Pine.LNX.4.10.10006031324470.29036-100000@nebula.lyra.org>

Actually, PyArg_ParseTuple() is a better call for this. It allows you to
specify the method name:

    if (!PyArg_ParseTuple(args, ":close")) return NULL;


Cheers,,
-g

On Sat, 3 Jun 2000, A.M. Kuchling wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv21410
> 
> Modified Files:
> 	mmapmodule.c 
> Log Message:
> Add missing PyArg_NoArgs() calls to methods that didn't take arguments
>    (Pointed out by Moshe Zadka)
> 
> 
> Index: mmapmodule.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/mmapmodule.c,v
> retrieving revision 2.8
> retrieving revision 2.9
> diff -C2 -r2.8 -r2.9
> *** mmapmodule.c	2000/05/03 23:44:32	2.8
> --- mmapmodule.c	2000/06/03 19:41:42	2.9
> ***************
> *** 2,6 ****
>    /  Author: Sam Rushing <rushing at nightmare.com>
>    /  Hacked for Unix by A.M. Kuchling <amk1 at bigfoot.com> 
> !  /  $Id: mmapmodule.c,v 2.8 2000/05/03 23:44:32 guido Exp $
>   
>    / mmapmodule.cpp -- map a view of a file into memory
> --- 2,6 ----
>    /  Author: Sam Rushing <rushing at nightmare.com>
>    /  Hacked for Unix by A.M. Kuchling <amk1 at bigfoot.com> 
> !  /  $Id: mmapmodule.c,v 2.9 2000/06/03 19:41:42 akuchling Exp $
>   
>    / mmapmodule.cpp -- map a view of a file into memory
> ***************
> *** 76,79 ****
> --- 76,81 ----
>   mmap_close_method (mmap_object * self, PyObject * args)
>   {
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   #ifdef MS_WIN32
>   	UnmapViewOfFile (self->data);
> ***************
> *** 119,122 ****
> --- 121,126 ----
>   	char * where;
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   	if (self->pos >= 0 && self->pos < self->size) {
>   	        where = self->data + self->pos;
> ***************
> *** 132,136 ****
>   static PyObject *
>   mmap_read_line_method (mmap_object * self,
> ! 			   PyObject * args)
>   {
>   	char * start = self->data+self->pos;
> --- 136,140 ----
>   static PyObject *
>   mmap_read_line_method (mmap_object * self,
> ! 		       PyObject * args)
>   {
>   	char * start = self->data+self->pos;
> ***************
> *** 140,143 ****
> --- 144,149 ----
>   
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   
>   	eol = memchr(start, '\n', self->size - self->pos);
> ***************
> *** 154,158 ****
>   static PyObject *
>   mmap_read_method (mmap_object * self,
> ! 		      PyObject * args)
>   {
>   	long num_bytes;
> --- 160,164 ----
>   static PyObject *
>   mmap_read_method (mmap_object * self,
> ! 		  PyObject * args)
>   {
>   	long num_bytes;
> ***************
> *** 226,230 ****
>   static PyObject *
>   mmap_write_byte_method (mmap_object * self,
> ! 			    PyObject * args)
>   {
>   	char value;
> --- 232,236 ----
>   static PyObject *
>   mmap_write_byte_method (mmap_object * self,
> ! 			PyObject * args)
>   {
>   	char value;
> ***************
> *** 242,248 ****
>   static PyObject *
>   mmap_size_method (mmap_object * self,
> ! 		      PyObject * args)
>   {
>   	CHECK_VALID(NULL);
>   
>   #ifdef MS_WIN32
> --- 248,256 ----
>   static PyObject *
>   mmap_size_method (mmap_object * self,
> ! 		  PyObject * args)
>   {
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   
>   #ifdef MS_WIN32
> ***************
> *** 347,350 ****
> --- 355,360 ----
>   {
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   	return (Py_BuildValue ("l", self->pos) );
>   }
> ***************
> *** 463,470 ****
>   
>   static int
> ! mmap_buffer_getreadbuf(self, index, ptr)
> ! 	mmap_object *self;
> ! int index;
> ! const void **ptr;
>   {
>   	CHECK_VALID(-1);
> --- 473,477 ----
>   
>   static int
> ! mmap_buffer_getreadbuf(mmap_object *self, int index, const void **ptr)
>   {
>   	CHECK_VALID(-1);
> ***************
> *** 868,869 ****
> --- 875,877 ----
>   
>   }
> + 
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins
> 

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




From gstein at lyra.org  Sat Jun  3 22:34:26 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 13:34:26 -0700 (PDT)
Subject: [Python-Dev] autoconf macros (was: RE: [Patches] Patch to Modules/pcre.h)
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBMEEMCMAA.mhammond@skippinet.com.au>
Message-ID: <Pine.LNX.4.10.10006031326320.29036-100000@nebula.lyra.org>

[moving to python-dev]

On Sun, 4 Jun 2000, Mark Hammond wrote:
> > I don't even see where DONT_HAVE_SYS_TYPES_H is ever defined:
> ...
> > Is it defined in some Mac-specific project file?
> 
> A few existed before, but I know I submitted a couple of the listed ones
> for Windows CE.  However, the CE config.h has never made it into the core,
> hence you can't find that particular definition...

Well, as I pointed out, the best way to do this is to add sys/types.h,
sys/stat.h, and stat.h to the AC_CHECK_HEADER() macro in configure.in. The
HAVE_SYS_TYPES_H macro and friends could then be checked.

PC/wince_config.h (or whatever it is called) would just #undef the 
HAVE_* macros.

The underlying issue here, is that autoconf can take care of these things
for us quite easily -- that we don't need manual maintenance of the
macros. For the odd platform without sys/types.h, autoconf will handle it,
rather than Python needing to do a special-case declaration.

Cheers,
-g

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




From gstein at lyra.org  Sat Jun  3 22:44:07 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 13:44:07 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
Message-ID: <Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Jeremy Hylton wrote:
>...
> Sorry for the excuses.  I think better tools would help a lot, but
> we'll have to get more people checkin privileges regardless.

There are several issues with expanded checkin privs:

1) trust: will the person make sure it is Right And Proper to do the
   checkin? (have they reviewed the code? is a a Good Change? etc) The
   counter here is that we don't want people that will simply take stuff
   arriving at patches@ and checking them in.

2) more people reviewing changes on the -checkins mailing list. Assuming
   that you want more than one pair of eyeballs looking at patches/code,
   that more people with commit privs increases the rate of commits, then
   you need more reviewers to keep up (because the reviewers probably are
   not going to review ALL checkins)

3) increasing dependence on -checkins means that patches MUST be smaller
   chunks. they MUST be single-purpose patches. practically nobody will
   review a 200k patch, or patches that fix N different things at once. A
   small, focused patch is easily reviewed.

   For example: Trent has recently mailed a bunch of patches to the
   patches list. This is Goodness: each one is focused and can be
   individually reviewed. Since they are not a single, giant blob, it also
   keeps them short and reviewable... each can have a +1/-1 independent of
   the others.


Cheers,
-g

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




From gstein at lyra.org  Sat Jun  3 23:14:49 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 14:14:49 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006031551470.17983-100000@sundial>
Message-ID: <Pine.LNX.4.10.10006031412460.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Moshe Zadka wrote:
>...
> In any case, is there any objection to storing the size of the .py
> alongside it's mtime in the .pyc, and regenerating if either is changed?
> This is just as efficient, and much more reliable.

If we change the header size, then this would be fine. At the moment, I
don't think that anybody is suggesting a change to the .pyc header format
because of the number of tool breakages that would ensue.

People have seemed interested in my idea to update the marshal format to
record a version number -- it doesn't require a change to the .pyc header.

Cheers,
-g

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




From gstein at lyra.org  Sun Jun  4 00:53:18 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 15:53:18 -0700 (PDT)
Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!)
In-Reply-To: <Pine.LNX.4.10.10006020134050.17073-100000@nebula.lyra.org>
Message-ID: <Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>

I found the problem. Sneaky...

sock.makefile() does a dup() on the file descriptor, then opens a FILE*
with that. See it coming yet? ...

FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd
file descriptor. When we went to grab another chunk on the *original*
descriptor, we missed input [that is now sitting in the FILE* buffer].

Answer: change the .makefile() in getreply() to:

    file = self.sock.makefile('rb', 0)

This problem is going to affect the original httplib, too. IMO, we're
about to replace the sucker, so no worries...

Cheers,
-g

On Fri, 2 Jun 2000, Greg Stein wrote:
> It looks like a definite bug. I have *no* idea, tho, why it is doing
> that... I did quite a bit of testing with chunked replies. Admittedly,
> though, I didn't stack up requests like you've done in your test. I'm
> wrapping up mod_dav at the moment, so I don't really have time to look
> deeply into this. Mebbe next week?
> 
> Regarding the pipeline request thing. I think it would probably be best to
> just drop the whole "hold the previous response and wait for it to be
> closed" thing. I don't know why that is in there; probably a leftover
> (converted) semantic from the old-style HTTP() class. I'd be quite fine
> just axing it and allowing the client to shove ten requests down the pipe
> before pulling the first response back out.
> 
> Oh. Wait. Maybe that was it. You can't read the "next" response until the
> first one has been read. Well... no need to block putting new responses;
> we just need to create a way to "get the next reply" and/or "can I get the
> next reply yet?"
> 
> Cheers,
> -g
> 
> p.s. Moshe also had a short list of review items. I read thru them, but
> not with the code in hand to understand some of his specifics.
> 
> 
> On Wed, 31 May 2000, Jeremy Hylton wrote:
> > >>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
> > 
> >   GS> [ and recall my email last week that I've updated httplib.py and
> >   GS> posted it to my web pages; it is awaiting review for integration
> >   GS> into the Python core; it still needs docs and more testing
> >   GS> scenarios, tho
> > 
> > I've been looking at the httplib code, and I found what may be a bug.
> > Not sure, because I'm not sure how the API works for pipelined
> > requests. 
> > 
> > I've got some test code that looks a bit like this:
> > 
> > def test_new_interface_series(urls):
> >     paths = []
> >     the_host = None
> >     for url in urls:
> >         host, path = get_host_and_path(url)
> >         if the_host is None:
> >             the_host = host
> >         else:
> >             assert host == the_host
> >         paths.append(path)
> >         
> >     conn = httplib.HTTPConnection(the_host)
> >     for path in paths:
> >         conn.request('GET', path, headers={'User-Agent': 'httplib/Python'})
> >     for path in paths:
> >         errcode, errmsg, resp = conn.getreply()
> >         buf = resp.read()
> >         if errcode == 200:
> >             print errcode, resp.headers
> >         else:
> >             print errcode, `errmsg`, resp
> >         print resp.getheader('Content-Length'), len(buf)
> >         print repr(buf[:40])
> >         print repr(buf[-40:])
> >         print
> >     conn.close()
> > 
> > test_new_interface_series(['http://www.python.org/',
> >                         'http://www.python.org/pics/PyBanner054.gif',
> >                         'http://www.python.org/pics/PythonHi.gif',
> >                         'http://www.python.org/Jobs.html',
> >                         'http://www.python.org/doc/',
> >                         'http://www.python.org/doc/current/',
> >                            ])
> > 
> > The second loop that reads the replies gets fouled up after a couple
> > of responses.  I added even more debugging and found that the first
> > line of the corrupted response is
> > 
> > > 'ontent-Type: text/html\015\012'
> > 
> > It looks like some part of the program is consuming too much input.  I
> > haven't been able to figure out what part yet.  Hoping that you might
> > have some good ideas.
> > 
> > Thinking about this issue, I came up with a potential API problem.
> > You must read the body after calling getreply and before calling
> > getreply a second time.  This kind of implicit requirement is a bit
> > tricky.  It would help if the implementation could raise an error if
> > this happens.  It might be even better if it just worked, although it
> > seems a bit too magical.
> > 
> > Jeremy
> > 
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 
> 
> 
> 

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




From thomas at xs4all.net  Sun Jun  4 00:56:01 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 4 Jun 2000 00:56:01 +0200
Subject: [Python-Dev] Re: Is it just Syntactic Sugar ?
In-Reply-To: <3935B383.469032AE@python.org>; from guido@python.org on Wed, May 31, 2000 at 11:49:57PM +0000
References: <k7lW4.96338$E85.1941352@news1.rdc1.md.home.com> <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <mt4s7f7q62.fsf@astron.berkeley.edu> <m3u2ffydwy.fsf@atrus.jesus.cam.ac.uk> <mtog5n68ak.fsf@astron.berkeley.edu> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org>
Message-ID: <20000604005601.T469@xs4all.nl>

On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum wrote:

> I know I shouldn't be posting in this thread, and I won't be there to read
> the responses, but here's what I thought would be cool.

As the 'lucky, lucky bastard' is probably standing before the altar about
now, I'll send this to the dev-list instead. Not that I expect anyone *not*
to be at the wedding, but I bet the rest is back sooner ;-)

> x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means "and becomes"
> (an old Algol-68 naming convention; we could pick something better later
> but this will do for the explanation).

> For immutable types, this is defined as

>   def __add_ab__(self, other):
>       return self+other

> For mutable types, this is defined as a self-mutating operation,
> e.g. for lists it could be

>   def __add_ab__(self, other):
>       self.extend(other)
>       return self

This was what I had in mind, and was trying to explain. Does you voicing
your opinion mean someone (you ? someone else ?) is working on this, or soon
going to work on this ? I had a chat with Michael about fixing up his patch
to work all the way (it's currently a proof-of-concept-quick-hack that only
works for builtin types) which prompted me to study Python's internals a bit
closer. (I hope I dont sound too patronizing when I say I was impressed ;-)

I'm curious what should happen with index-assignment and slice-assignment:

x[y] += z
x[:y] += z

(Obviously this wont make sense for a lot of types, or will be too
un-obvious to include, but I can imagine matrix-types to happily add this.)

Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, y, z) ? Or
would x[y] += z always call x[y].__add_item_ab__() and x[:y] create a new
object, a slice of x, and call its __add_ab__() method ? Or would it try all
of them, or more, until it gets a good result ? Or am I running ahead of
things and should we wait for a working patch first ? :)

If I suddenly grow a deep understanding of Python's internals (not ruled
out, it's fairly obvious) and hack-up something that works before anyone
else, I'll be sure to mail ;)

oh-and-congratulations-to-Mrs.-van-Rossum-too-ly yr's,
-- 
Thomas Wouters <thomas at xs4all.net>

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



From gstein at lyra.org  Sun Jun  4 01:06:07 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 16:06:07 -0700 (PDT)
Subject: [Python-Dev] httplib
In-Reply-To: <Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>
Message-ID: <Pine.LNX.4.10.10006031605000.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Greg Stein wrote:
> I found the problem. Sneaky...
> 
> sock.makefile() does a dup() on the file descriptor, then opens a FILE*
> with that. See it coming yet? ...
> 
> FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd
> file descriptor. When we went to grab another chunk on the *original*
> descriptor, we missed input [that is now sitting in the FILE* buffer].
> 
> Answer: change the .makefile() in getreply() to:
> 
>     file = self.sock.makefile('rb', 0)
> 
> This problem is going to affect the original httplib, too. IMO, we're
> about to replace the sucker, so no worries...

Oh... actually it won't affect the original since that doesn't pipeline
requests.

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




From gstein at lyra.org  Sun Jun  4 01:13:55 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 16:13:55 -0700 (PDT)
Subject: [Python-Dev] more on httplib
Message-ID: <Pine.LNX.4.10.10006031606100.29036-100000@nebula.lyra.org>

I would like to propose a few changes to the (new) httplib:

*) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to
   provide backwards-compat for it

*) revamp the pipeline support:

   - record the "last response object" ... when a new getreply() is done,
     then we store the "last" into response.prior
   - reading of the "HTTP/1.1 <code> <msg>" line is deferred, and
     performed by the response object
   - the read of that line is lazy
   - if the response line is read *before* the "prior" response (if any) 
     is "closed", then an exception is raised: ResponseNotReady

*) address some of Moshe's concerns:

   - use class-based exceptions
   - clarify that HTTPConnection is designed for *blocking* sockets
   - conn.close() followed by conn.send() will reopen the socket. This
     could lead to programming errors. I'll add a class-based default flag
     to disable this behavior.
   - in request(), we check for errno==32 ... what to do on Windows?


I will implement these changes in small chunks so that each can be
reviewed in my CVS repository. The history is available at:

    http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/


Cheers,
-g

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





From mhammond at skippinet.com.au  Sun Jun  4 04:03:34 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 4 Jun 2000 12:03:34 +1000
Subject: [Python-Dev] What's New (first draft)
In-Reply-To: <20000602231550.A986@newcnri.cnri.reston.va.us>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEFCCMAA.mhammond@skippinet.com.au>

> emphasize the number of contributors to this release; does everyone think
> this is a good idea?  If I've missed your name, or credited you wrongly,
> please let me know.

OK - as you insist :-)

Bill Tutt and I could do with a credit for the new winreg module.

Thanks,

Mark.




From tim_one at email.msn.com  Sun Jun  4 06:09:02 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 4 Jun 2000 00:09:02 -0400
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006030900030.14749-100000@sundial>
Message-ID: <000a01bfcdda$9e876060$1d2d153f@tim>

[Moshe]
> How about having, in addition to the time-stamp, the size of the file?
> At least on UNIX, it comes for free with the same stat call.

+1 from me.  Note that, besides inter-machine clock skew, some filesystems
have a timestamp granularity too coarse to distinguish close-in-time writes.
For those (& related) reasons, the attentive Pythoneer will have noted that
all of the winning 1st-round Software Carpentry "make"-replacement designs
provide for alternatives to timestamps.  Tom Tromey's has the clearest
discussion of the problems with timestamps:

http://software-carpentry.codesourcery.com/entries/build/Tromey/Tromey.html

In my industrial experience, (timestamp, size) pairs have never failed in
practice.  However, "my industrial experience" has been entirely in projects
where source-control wrappers add a checkin comment block to every
checked-in file, and that alone made it exceedingly unlikely that any two
successive versions of a file would have the same size.

In Python I'm still (a little) worried about cases like

SOME_GLOBAL_CONFIG_OPTION = 0

where "0" gets replaced by "1" or "2" or ... there are lots of interesting
things you can do to Python programs without changing their size.  At
Dragon, checked-in Python files were also subject to the "checkin comment
block" rule, so no project under source control suffered from this.  I
suspect it burned people in their pre-source-controlled development
projects, though!  One group in particular had a project that involved acres
of machine-generated Python modules, and I know they suffered from coarse
timestamps on their flavor of Unix (so part of their "make" procedure was to
nuke all .pyc's on each build).

it's-easy-to-laugh-at-problems-you-don't-have<wink>-ly y'rs  - tim





From moshez at math.huji.ac.il  Sun Jun  4 06:59:31 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sun, 4 Jun 2000 07:59:31 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <000a01bfcdda$9e876060$1d2d153f@tim>
Message-ID: <Pine.GSO.4.10.10006040757010.23740-100000@sundial>

On Sun, 4 Jun 2000, Tim Peters wrote:

[Moshe]
> How about having, in addition to the time-stamp, the size of the file?
> At least on UNIX, it comes for free with the same stat call.

 
[Tim]
> +1 from me.
<even more reasons>

Now there is the big problem, that this will be changing the header size.
I thought that this would be a good time anyway, since 1.5.2 pycs aren't
compatible with 1.6, but changing the header size is a bigger thing.

so-this-waits-until-guido-comes-back-i-guess-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From bwarsaw at python.org  Sun Jun  4 22:51:30 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Sun, 4 Jun 2000 16:51:30 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <3938D60E.391AAF31@lemburg.com>
	<AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
Message-ID: <14650.49490.725648.798719@anthem.python.org>

>>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:

    JH> One of the problems I'm having is keeping track of which
    JH> patches are still outstanding.

SF has a patch manager but I haven't played with it much.  In fact, I
can't seem to find it for the Python project, but it's there in the
Mailman project.

-Barry



From gstein at lyra.org  Sun Jun  4 22:55:09 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 13:55:09 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14650.49490.725648.798719@anthem.python.org>
Message-ID: <Pine.LNX.4.10.10006041353020.29036-100000@nebula.lyra.org>

On Sun, 4 Jun 2000, Barry A. Warsaw wrote:
> >>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:
> 
>     JH> One of the problems I'm having is keeping track of which
>     JH> patches are still outstanding.
> 
> SF has a patch manager but I haven't played with it much.  In fact, I
> can't seem to find it for the Python project, but it's there in the
> Mailman project.

You can administratively turn those things on/off, I thought. You're an
admin, Barry, so you should be able to turn the thing on.

Cheers,
-g

p.s. and yah.. there are damn too many projects at SF that are just a
project name. no code, no description, all features enabled for no
purpose, etc... Newbie coders, me thinks. Python is Goodness because it
does disable the unused items.

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




From gstein at lyra.org  Mon Jun  5 01:30:08 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 16:30:08 -0700 (PDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total
 reference count in debug builds.)
Message-ID: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>

Given the New World Order, how does that impact the need for these release
statements and/or wet signatures?

Or a better way to put it, who "owns" Python now? Given a "who", then we
can ask that person/entity whether they want release statements.

Given that Python is now on SourceForge, and there are multiple people (at
CNRI and otherwise) that can directly make modifications, then the release
below is certainly a bit "off". For example, David Ascher has commit
privs, so at his "sole discretion, [he may] decide whether or not to
incorporiate this contribution..." :-)

Thoughts?

Cheers,
-g

p.s. IMO, I'd like to see Guido own the Copyright for all current and
future Python development

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

---------- Forwarded message ----------
Date: Mon, 5 Jun 2000 09:18:30 +1000
From: Mark Hammond <mhammond at skippinet.com.au>
To: patches at python.org
Subject: [Patches] New sys method to return total reference count in debug
    builds.

[... snip ...]

Release info:

I confirm that, to the best of my knowledge and belief, this contribution
is free of any claims of third parties under copyright, patent or other
rights or interests ("claims").  To the extent that I have any such claims,
I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide
license to reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part of the
Python software and its related documentation, or any derivative versions
thereof, at no cost to CNRI or its licensed users, and to authorize others
to do so.

I acknowledge that CNRI may, at its sole discretion, decide whether or not
to incorporate this contribution in the Python software and its related
documentation.  I further grant CNRI permission to use my name and other
identifying information provided to CNRI by me for use in connection with
the Python software and its related documentation.

Mark.


_______________________________________________
Patches mailing list
Patches at python.org
http://www.python.org/mailman/listinfo/patches




From bwarsaw at python.org  Mon Jun  5 05:09:36 2000
From: bwarsaw at python.org (bwarsaw at python.org)
Date: Sun, 4 Jun 2000 23:09:36 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <14650.49490.725648.798719@anthem.python.org>
	<Pine.LNX.4.10.10006041353020.29036-100000@nebula.lyra.org>
Message-ID: <14651.6640.709657.306682@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

    GS> You can administratively turn those things on/off, I
    GS> thought. You're an admin, Barry, so you should be able to turn
    GS> the thing on.

I'm happy to if people think it will help.  SF's patch management is a
durn site better than Python's is now <wink>.  I'd also consider
shutting off Jitterbug on python.org but I'm not sure how to (or if we
should) migrate the current bug set to SF.

-Barry



From gstein at lyra.org  Mon Jun  5 08:13:39 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 23:13:39 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.6640.709657.306682@anthem.python.org>
Message-ID: <Pine.LNX.4.10.10006042311500.29036-100000@nebula.lyra.org>

On Sun, 4 Jun 2000 bwarsaw at python.org wrote:
> >>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
> 
>     GS> You can administratively turn those things on/off, I
>     GS> thought. You're an admin, Barry, so you should be able to turn
>     GS> the thing on.
> 
> I'm happy to if people think it will help.  SF's patch management is a
> durn site better than Python's is now <wink>.  I'd also consider
> shutting off Jitterbug on python.org but I'm not sure how to (or if we
> should) migrate the current bug set to SF.

IMO, use the provided tools. The Patch Manager is more than we have now.
It also allows assignment, which can be nice :-)  (compared to the
arbitrary "who is taking care of this patch?" thing today)

The SF bug database certainly works, and it provides additional "locality"
for the code + bugs + patches.

Cheers,
-g

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




From jeremy at beopen.com  Mon Jun  5 06:43:45 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 00:43:45 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <3938D60E.391AAF31@lemburg.com>
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
	<3938D60E.391AAF31@lemburg.com>
Message-ID: <14651.12289.191631.704477@localhost.localdomain>

[Entry from AMK's 1.6 jobs list:]
> Conservative garbage collection of cycles (maybe -- I don't know what GvR
>         thinks about this)

I believe Guido would like to see a version of Neil's patches
integrated into Python 1.6, most likely turned off by default but with
a configure flag to enable.

I would like to check the patch in soon but I have had some trouble
with segfaults.  I ran a simple benchmark using the compiler code in
the nondist tree to compile itself.  I get a crash during a routine
collect pass, where it looks like the GC header info is getting
trashed.  I haven't had much time to track it any farther.

If anyone else is interested, I'd love to hear about successes using
the GC patch with other large programs.  I'd like to run at least
Gadfly and Grail successfully before committing the patch.

I wonder if "conservative" is the right word to describe the GC
approach?  I think conservative means that the garbage collector is
not told what is a pointer and what is not, so it must conservatively
assume that every bit pattern could represent a pointer.  The GC patch
is not conservative in this sense.  It does have a mechanism that is
"conservative" in a very broad sense, i.e. it does not attempt to
trace every reference, but depends on the ref count fields to account
for references held in untraced variables on the C stack.  I'm not
sure what the right terminology for this approach is.

I also worry that the performance impact of the GC patch is not at all
understood.  I don't know what informed the choice of heuristics for
deciding how often to collect and how to move objects between
generations.  (The current scheme has three generations.)  It would be
good to get a working patch in before the next alpha release and then
gather a lot of data to help make good choices about these parameters.

Jeremy

PS Even if Guido doesn't think the GC patch should go in, we've got a
golden opportunity.  I caught him in a state of newly-wedded bliss
this morning and convinced him to let me check in my non-optional
braces patch while he's on his honeymoon.  He's so happy he'll let us
get away with anything.

PPS I don't know if we should really carry on about personal matters
on a development list, but I hope no one minds if I indulge briefly:
Guido & Kim's wedding yesterday was beautiful and fun, held outside in
meadow looking out on hills and woods.  They are great couple and I'm
sure they'll be very happy.




From jeremy at beopen.com  Mon Jun  5 06:58:11 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 00:58:11 -0400 (EDT)
Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!)
In-Reply-To: <Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>
References: <Pine.LNX.4.10.10006020134050.17073-100000@nebula.lyra.org>
	<Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>
Message-ID: <14651.13155.253651.575394@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

  GS> I found the problem. Sneaky...  sock.makefile() does a dup() on
  GS> the file descriptor, then opens a FILE* with that. See it coming
  GS> yet? ...

Bingo!  I was suspicious of all these dup'd file descriptors, but
missed the connection to a FILE* object.

  [In a previous message you wrote:]
  >> 
  >> Regarding the pipeline request thing. I think it would probably
  >> be best to just drop the whole "hold the previous response and
  >> wait for it to be closed" thing.
  [...]
  >> 
  >> Oh. Wait. Maybe that was it. You can't read the "next" response
  >> until the first one has been read. Well... no need to block
  >> putting new responses; we just need to create a way to "get the
  >> next reply" and/or "can I get the next reply yet?"
  >> 

Maybe I should clarify the concern I had here.  I think we're on the
same page, but I'm not sure.

The problem with pipelined requests is that the client must be sure to
read all of response I before it can call getreply to get response
I+1.  I imagine that it could add a lot of complexity to use code to
implement this requirement, e.g. when multiple threads are sharing a
single connection.  It would be good if the library could do something
reasonable about the multiplexing.  In the absence of making it just
work, the library could raise an error that makes clear what has gone
wrong -- that the client isn't using the interface properly.

Jeremy



From jeremy at beopen.com  Mon Jun  5 07:00:06 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 01:00:06 -0400 (EDT)
Subject: [Python-Dev] Re: Is it just Syntactic Sugar ?
In-Reply-To: <20000604005601.T469@xs4all.nl>
References: <k7lW4.96338$E85.1941352@news1.rdc1.md.home.com>
	<3929E47E.993727CF@roguewave.com>
	<3933F800.9CCE3B6D@cs.byu.edu>
	<20000530213957.E469@xs4all.nl>
	<mt4s7f7q62.fsf@astron.berkeley.edu>
	<m3u2ffydwy.fsf@atrus.jesus.cam.ac.uk>
	<mtog5n68ak.fsf@astron.berkeley.edu>
	<20000531090045.I469@xs4all.nl>
	<3935B383.469032AE@python.org>
	<20000604005601.T469@xs4all.nl>
Message-ID: <14651.13270.353056.246432@localhost.localdomain>

>>>>> "TW" == Thomas Wouters <thomas at xs4all.net> writes:

  TW> On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum
  TW> wrote:
  >> I know I shouldn't be posting in this thread, and I won't be
  >> there to read the responses, but here's what I thought would be
  >> cool.

  >> x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means
  >> "and becomes" (an old Algol-68 naming convention; we could pick
  >> something better later but this will do for the explanation).

  [...]

  TW> This was what I had in mind, and was trying to explain. Does you
  TW> voicing your opinion mean someone (you ? someone else ?) is
  TW> working on this, or soon going to work on this ? 

I don't believe anyone at PythonLabs is working on this now, certainly
not Guido or I.

Jeremy



From jeremy at beopen.com  Mon Jun  5 06:53:32 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 00:53:32 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>
References: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
	<Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>
Message-ID: <14651.12876.575925.701737@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

  GS> On Sat, 3 Jun 2000, Jeremy Hylton wrote:
  >> ...  Sorry for the excuses.  I think better tools would help a
  >> lot, but we'll have to get more people checkin privileges
  >> regardless.

  GS> There are several issues with expanded checkin privs:

  GS> 1) trust: will the person make sure it is Right And Proper to do
  GS> the checkin? (have they reviewed the code? is a a Good Change?
  GS> etc) The counter here is that we don't want people that will
  GS> simply take stuff arriving at patches@ and checking them in.

Many of the people who ultimately have checkin privileges should limit
themselves to their particular domains.  There are a bunch of modules
that are owned by other people, e.g. Eric's netrc module, your new
httplib, MAL for Unicode, etc.

We'll probably develop a second group of developers who have broader
privileges to make changes, but they'll know how they are.

Ultimately, I think I agree with Mark's suggestion that we be a little
more liberal with changes and risk backing out the occasional
changes.  (For some definition of "a little more" :-).

  GS> 2) more people reviewing changes on the -checkins mailing
  GS> list. Assuming that you want more than one pair of eyeballs
  GS> looking at patches/code, that more people with commit privs
  GS> increases the rate of commits, then you need more reviewers to
  GS> keep up (because the reviewers probably are not going to review
  GS> ALL checkins)

You're doing a great job so far.  We'll just have to get you to spend
more time on it <0.8 wink>.

  GS> 3) increasing dependence on -checkins means that patches MUST be
  GS> smaller chunks. they MUST be single-purpose patches. practically
  GS> nobody will review a 200k patch, or patches that fix N different
  GS> things at once. A small, focused patch is easily reviewed.

  GS>    For example: Trent has recently mailed a bunch of patches to
  GS> the patches list. This is Goodness: each one is focused and can
  GS> be individually reviewed. Since they are not a single, giant
  GS> blob, it also keeps them short and reviewable... each can have a
  GS> +1/-1 independent of the others.

I agree in principle, but there are times when it will make more sense
to commit a set of changes as one big patch.  The GC patches are going
to affect a bunch of files, but probably ought to be done as one big
commit. 

Jeremy



From jeremy at beopen.com  Mon Jun  5 07:03:46 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 01:03:46 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total
 reference count in debug builds.)
In-Reply-To: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
References: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
Message-ID: <14651.13490.858960.390030@localhost.localdomain>

Off the top of my head, I'd say that your questions aren't going to
get answered until Guido gets back and gets a chance to answer them.
In the interim, I think we should stick with the current approach.  In
the long run, of course, you won't need to grant CNRI permission to do
anything with a submission.

Jeremy



From nascheme at enme.ucalgary.ca  Mon Jun  5 08:35:00 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Mon, 5 Jun 2000 00:35:00 -0600
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.12289.191631.704477@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 12:43:45AM -0400
References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> <14651.12289.191631.704477@localhost.localdomain>
Message-ID: <20000605003500.B6169@acs.ucalgary.ca>

On Mon, Jun 05, 2000 at 12:43:45AM -0400, Jeremy Hylton wrote:
> [Entry from AMK's 1.6 jobs list:]
> > Conservative garbage collection of cycles (maybe -- I don't know what GvR
> >         thinks about this)
> 
> I believe Guido would like to see a version of Neil's patches
> integrated into Python 1.6, most likely turned off by default but with
> a configure flag to enable.

Okay, I was thinking he had passed it over for 1.6 since I didn't
hear any comments from him for a long time.

> I would like to check the patch in soon but I have had some trouble
> with segfaults.  I ran a simple benchmark using the compiler code in
> the nondist tree to compile itself.  I get a crash during a routine
> collect pass, where it looks like the GC header info is getting
> trashed.  I haven't had much time to track it any farther.

Yow.  I will try to see if I can reproduce this.  What platform?

> If anyone else is interested, I'd love to hear about successes using
> the GC patch with other large programs.  I'd like to run at least
> Gadfly and Grail successfully before committing the patch.

I've used it with Grail, Sketch, IDLE as well as some of my own
software.  I may have introduced that SEGV bug when porting the
patch to a newer version of the CVS sources.  I will check it
out.

> I also worry that the performance impact of the GC patch is not
> at all understood.

Me too.

> I don't know what informed the choice of heuristics for
> deciding how often to collect and how to move objects between
> generations. (The current scheme has three generations.) It
> would be good to get a working patch in before the next alpha
> release and then gather a lot of data to help make good choices
> about these parameters.

Getting good performance will be a matter of tuning how often the
collector runs.  I don't think there is any substitute for
running real programs and collecting data.  Programs that
allocate lots of objects will be most interesting.  It would
probably be a good idea to add more support for keeping
collection statistics.  Unfortunately my time is very limited
right now.

> PS Even if Guido doesn't think the GC patch should go in, we've got a
> golden opportunity.  I caught him in a state of newly-wedded bliss
> this morning and convinced him to let me check in my non-optional
> braces patch while he's on his honeymoon.  He's so happy he'll let us
> get away with anything.

I wonder if he will be scowling less at the conferences now that
he is hitched. :)

    Neil



From gstein at lyra.org  Mon Jun  5 08:42:35 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 23:42:35 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.12876.575925.701737@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.10006042329020.29036-100000@nebula.lyra.org>

On Mon, 5 Jun 2000, Jeremy Hylton wrote:
> >>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
>...
>   GS> 1) trust: will the person make sure it is Right And Proper to do
>   GS> the checkin? (have they reviewed the code? is a a Good Change?
>   GS> etc) The counter here is that we don't want people that will
>   GS> simply take stuff arriving at patches@ and checking them in.
> 
> Many of the people who ultimately have checkin privileges should limit
> themselves to their particular domains.  There are a bunch of modules
> that are owned by other people, e.g. Eric's netrc module, your new
> httplib, MAL for Unicode, etc.

Agreed. Each person with commit privs will definitely need to operate
under the premise of "<this> is the area that I'm allowed to commit
changes for." For example, I believe that Guido made it very clear, at
some point in the past, that *nobody* but Guido will have commit access to
the Parser/ area.

Note that when I say "commit access" here, this is the same as "areas that
I can commit for." In fact, it is really just an extension of the Basic
Python Principle, "we're all adults here, don't do what you know you
shouldn't be doing." :-)

>...
> Ultimately, I think I agree with Mark's suggestion that we be a little
> more liberal with changes and risk backing out the occasional
> changes.  (For some definition of "a little more" :-).

This only works if you have reasonably assurance of review via the
-checkins alias. Otherwise, you simply need to accept that instabilities
will creep in. (and that broader alpha/beta/etc cycles may be desirable)

In the Apache group, we have a very good set of eyeballs watching the
checkins. I'd say that each checkin is reviewed by two or three people in
detail. Invariably, there are several checkins each week that result in a
thread discussing: (a) you broke it, (b) why was it done that way, (c)
couldn't it be done this way, (d) this appears to be missing, (e) etc.

IMO, for that to happen several (or more!) times every week means that we
have a good set of eyeballs. Maybe it also means the committers just suck
lollipops, but I'd like to think otherwise :-)

>   GS> 2) more people reviewing changes on the -checkins mailing
>   GS> list. Assuming that you want more than one pair of eyeballs
>   GS> looking at patches/code, that more people with commit privs
>   GS> increases the rate of commits, then you need more reviewers to
>   GS> keep up (because the reviewers probably are not going to review
>   GS> ALL checkins)
> 
> You're doing a great job so far.  We'll just have to get you to spend
> more time on it <0.8 wink>.

hehe...

well, I just completed a big-ass wave of mod_dav work. In fact, I don't
know what else to do to the thing. I made a snapshot and am waiting for
feedback, if any, before declaring it 1.0. Maybe I'll add some comments to
the code :-)

Anyways... that's why I've been working on httplib. Free time! :-)

>   GS> 3) increasing dependence on -checkins means that patches MUST be
>   GS> smaller chunks. they MUST be single-purpose patches. practically
>   GS> nobody will review a 200k patch, or patches that fix N different
>   GS> things at once. A small, focused patch is easily reviewed.
> 
>   GS>    For example: Trent has recently mailed a bunch of patches to
>   GS> the patches list. This is Goodness: each one is focused and can
>   GS> be individually reviewed. Since they are not a single, giant
>   GS> blob, it also keeps them short and reviewable... each can have a
>   GS> +1/-1 independent of the others.
> 
> I agree in principle, but there are times when it will make more sense
> to commit a set of changes as one big patch.  The GC patches are going
> to affect a bunch of files, but probably ought to be done as one big
> commit. 

Actually, I will disagree here. I've reviewed the GC patch a couple times.
There are a number of changes in there that can/should be done separately
from the "real" GC patch.

For example, there were a number of changes to use PyMem_Allco() instead
of PyMEM_Alloc(). Or whatever. Point being, that they had *nothing* to do
with GC -- they could be checked in *independent* of the actual GC work.
The changes to the PyTypeObject declaration (adding tp_clean) can also be
done without doing the "real work".

After these "zero impact" changes are completed, then the GC patch will be
greatly reduced in size and complexity. It makes it much more reviewable.

The point being: even big patches can usually be broken down into layers.
One layer after another, adding "platform" functionality until you get to
the meat of the matter. The GC patch was a definite case of this.

Really huge patches are okay if they have a *seriously* narrow focus. For
example, Skip's patch to use PyArg_ParseTuple() with the ":method" stuff.
That was pretty brain-dead to review. The hardest part was that the
context-diff wasn't contextual enough to verify that the name in the
ParseTuple matched the method that it occurred in.
[ I found a case where they did not match. not easy... ]

Cheers,
-g

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




From pf at artcom-gmbh.de  Mon Jun  5 09:28:38 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Mon, 5 Jun 2000 09:28:38 +0200 (MEST)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org> from Greg Stein at "Jun 2, 2000  2:32:52 pm"
Message-ID: <m12yrJO-000DifC@artcom0.artcom-gmbh.de>

Hi,

Greg Stein:
> He does have a point, but I think the wrong solution :-)
> 
> While the clock may be monotonically increasing on one system, it isn't
> always the case when things like NFS come into play.

That is a well known and common trap.  Don't use NFS for Software
development unless you've read and understood RFC 868. ;-)

BTW.: Last year someone posted a pure Python implementation of RFC 868
time server and clients to c.l.p.  This might be useful on those WinXX boxes.

> I recall a case back '95 when I was editing a .py over an NFS mount and
> running the code on the target machine. The clocks on the two boxes were
> off by about three seconds. I was going thru the edit/run/edit/run cycle
> so quickly, that at one point, I saved a .py file that was older than the
> associated .pyc file.
> 
> Needless to say, I was really confused that my recent edit didn't produce
> the desired result :-)

Sure. ;-)  But the same would have happenend, if you edited a .c source
file and if your target computer has C-compiler/linker, which is fast
enough to have a edit/compile/run cycle completed faster than the clock 
difference.  This is not uncommon today.

So the problem is not Python's fault and so I see no need to fix it there.
One thing could be added though: If Python 'stat's a .py file, which has
a time stamp in the future, it could issue a warning similar to that
displayed by 'make':
*** Warning: File `%s' has modification time in the future (%ld > %ld

Possibly this message could point the user to RFC 868 and the 'netdate' 
Unix command.  But that would be sugar on the cake.

Regards, Peter



From moshez at math.huji.ac.il  Mon Jun  5 12:21:32 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Mon, 5 Jun 2000 13:21:32 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <m12yrJO-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.GSO.4.10.10006051318060.12591-100000@sundial>

On Mon, 5 Jun 2000, Peter Funk wrote:

> Greg Stein:
> > He does have a point, but I think the wrong solution :-)
> > 
> > While the clock may be monotonically increasing on one system, it isn't
> > always the case when things like NFS come into play.
> 
> That is a well known and common trap.  Don't use NFS for Software
> development unless you've read and understood RFC 868. ;-)

"Make"'s philosphy for basing the decision on which files need to be
remade on the timestapmps is not necessarily the best -- but the user can
replace mkae if it doesn't "do the right thing".

Since Python takes on some of Make's roles (regenrating files only if
those need to be regenerated), it is subject to the same problems. So it
is Python's fault, and that's where the problem should be fixed.

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From bwarsaw at python.org  Mon Jun  5 15:21:05 2000
From: bwarsaw at python.org (bwarsaw at python.org)
Date: Mon, 5 Jun 2000 09:21:05 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <14651.6640.709657.306682@anthem.python.org>
	<Pine.LNX.4.10.10006042311500.29036-100000@nebula.lyra.org>
Message-ID: <14651.43329.783797.949349@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

    GS> IMO, use the provided tools. The Patch Manager is more than we
    GS> have now.  It also allows assignment, which can be nice :-)
    GS> (compared to the arbitrary "who is taking care of this patch?"
    GS> thing today)

    GS> The SF bug database certainly works, and it provides
    GS> additional "locality" for the code + bugs + patches.

I've turned on the SF patch manager and bug database.

-Barry



From bwarsaw at python.org  Mon Jun  5 15:32:54 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:32:54 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
	<Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>
	<14651.12876.575925.701737@localhost.localdomain>
Message-ID: <14651.44038.828370.123514@anthem.python.org>

>>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:

    JH> Many of the people who ultimately have checkin privileges
    JH> should limit themselves to their particular domains.  There
    JH> are a bunch of modules that are owned by other people,
    JH> e.g. Eric's netrc module, your new httplib, MAL for Unicode,
    JH> etc.

Right.  I think GregS was the one advocating a more Apache-like model,
where people have the ability to check into the whole tree, but
generally don't or risk the derision of their peers.  Python's big
enough for people to assert their expertise over various corners.

    JH> Ultimately, I think I agree with Mark's suggestion that we be
    JH> a little more liberal with changes and risk backing out the
    JH> occasional changes.  (For some definition of "a little more"
    JH> :-).

It all depends on the scope of the changes.  If it's fairly localized
to a single library module, then we don't worry as much.  More
important there will be the API design.  If it's a more sweeping
change like GC or Unicode, or a change in the language definition,
then there /has/ to be broader support.

For Big Changes, I really like the RFC idea someone suggested.  Gets
everything documented for newbies and posterity.  Has a shelf life,
etc.

-Barry



From bwarsaw at python.org  Mon Jun  5 15:36:28 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:36:28 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <14651.12876.575925.701737@localhost.localdomain>
	<Pine.LNX.4.10.10006042329020.29036-100000@nebula.lyra.org>
Message-ID: <14651.44252.78362.195436@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

    GS> In the Apache group, we have a very good set of eyeballs
    GS> watching the checkins. I'd say that each checkin is reviewed
    GS> by two or three people in detail. Invariably, there are
    GS> several checkins each week that result in a thread discussing:
    GS> (a) you broke it, (b) why was it done that way, (c) couldn't
    GS> it be done this way, (d) this appears to be missing, (e) etc.

Maybe we also need to expand on the test suite, do nightly builds, and
post the results.  Kind of the way Mozilla does it.  Well, Python
probably doesn't change so radically every night, but a more expanded
test suite with web based feedback would be cool.

-Barry



From bwarsaw at python.org  Mon Jun  5 15:38:20 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:38:20 -0400 (EDT)
Subject: [Python-Dev] Re: Is it just Syntactic Sugar ?
References: <k7lW4.96338$E85.1941352@news1.rdc1.md.home.com>
	<3929E47E.993727CF@roguewave.com>
	<3933F800.9CCE3B6D@cs.byu.edu>
	<20000530213957.E469@xs4all.nl>
	<mt4s7f7q62.fsf@astron.berkeley.edu>
	<m3u2ffydwy.fsf@atrus.jesus.cam.ac.uk>
	<mtog5n68ak.fsf@astron.berkeley.edu>
	<20000531090045.I469@xs4all.nl>
	<3935B383.469032AE@python.org>
	<20000604005601.T469@xs4all.nl>
	<14651.13270.353056.246432@localhost.localdomain>
Message-ID: <14651.44364.408119.422821@anthem.python.org>

>>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:

>>>>> "TW" == Thomas Wouters <thomas at xs4all.net> writes:

    TW> This was what I had in mind, and was trying to explain. Does
    TW> you voicing your opinion mean someone (you ? someone else ?)
    TW> is working on this, or soon going to work on this ?

    JH> I don't believe anyone at PythonLabs is working on this now,
    JH> certainly not Guido or I.

I'm not tracking this either.
-Barry



From bwarsaw at python.org  Mon Jun  5 15:41:39 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:41:39 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total
 reference count in debug builds.)
References: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
Message-ID: <14651.44563.556790.469651@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

    GS> Given the New World Order, how does that impact the need for
    GS> these release statements and/or wet signatures?

    GS> Or a better way to put it, who "owns" Python now? Given a
    GS> "who", then we can ask that person/entity whether they want
    GS> release statements.

    GS> Given that Python is now on SourceForge, and there are
    GS> multiple people (at CNRI and otherwise) that can directly make
    GS> modifications, then the release below is certainly a bit
    GS> "off". For example, David Ascher has commit privs, so at his
    GS> "sole discretion, [he may] decide whether or not to
    GS> incorporiate this contribution..." :-)

I talked to Guido briefly about this.  Since 1.6 is the last "CNRI
release", he wants to continue along the current path for the time
being.  I'm sure he'll be just as happy to chuck all this crap as
Greg, and we probably will for 1.7.

-Barry



From fdrake at beopen.com  Mon Jun  5 18:40:26 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 5 Jun 2000 12:40:26 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14648.35974.486959.379543@anthem.python.org>
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
	<14648.35974.486959.379543@anthem.python.org>
Message-ID: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com>

Barry A. Warsaw writes:
 > Did we ever decide on building in thread support by default?  I'd
 > really like to see threads enabled by default in 1.6 and I /think/
 > it'll just take some autoconf hacking, which I'm willing to do.  Are
 > there any objections to building in threads support by default if
 > autoconf detects threads?

  test_fork1 fails on Linux with threads on SMP machines.  (It's
irrelevant without threads.)  This is a hard failure -- the process
can either SEGV or hang forever.
  Is this a showstopper?  SMP boxes are becoming increasingly common
both as servers and workstations.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From bwarsaw at python.org  Mon Jun  5 18:55:49 2000
From: bwarsaw at python.org (bwarsaw at python.org)
Date: Mon, 5 Jun 2000 12:55:49 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
	<14648.35974.486959.379543@anthem.python.org>
	<14651.55290.728256.183107@cj42289-a.reston1.va.home.com>
Message-ID: <14651.56213.661929.481476@anthem.python.org>

>>>>> "Fred" == Fred L Drake, Jr <fdrake at beopen.com> writes:

    Fred>   test_fork1 fails on Linux with threads on SMP machines.
    Fred> (It's irrelevant without threads.)  This is a hard failure
    Fred> -- the process can either SEGV or hang forever.  Is this a
    Fred> showstopper?

I would think so, regardless of whether threads are built-in by
default or not.



From fdrake at beopen.com  Mon Jun  5 19:59:31 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 5 Jun 2000 13:59:31 -0400 (EDT)
Subject: [Python-Dev] What's New (first draft)
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBIEFCCMAA.mhammond@skippinet.com.au>
References: <20000602231550.A986@newcnri.cnri.reston.va.us>
	<ECEPKNMJLHAPFFJHDOJBIEFCCMAA.mhammond@skippinet.com.au>
Message-ID: <14651.60035.502321.510452@cj42289-a.reston1.va.home.com>

Mark Hammond writes:
 > Bill Tutt and I could do with a credit for the new winreg module.

  The documentation for winreg could stand to be written as well --
care to extract the docstrings, or is that in my court?  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From DavidA at ActiveState.com  Mon Jun  5 21:26:13 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 5 Jun 2000 12:26:13 -0700
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJCEIKCGAA.DavidA@ActiveState.com>

>   test_fork1 fails on Linux with threads on SMP machines.  (It's
> irrelevant without threads.)  This is a hard failure -- the process
> can either SEGV or hang forever.
>   Is this a showstopper?  SMP boxes are becoming increasingly common
> both as servers and workstations.

Why does the test fail?  I'd hate to see the thousands (nay, hundreds of
thousands) of users complain that foo isn't working just because the test
for a rarely used feature on a rare platform is broken.

--david




From nascheme at enme.ucalgary.ca  Mon Jun  5 23:03:13 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Mon, 5 Jun 2000 15:03:13 -0600
Subject: [Python-Dev] Re: Revised 1.6 jobs list
Message-ID: <20000605150313.A15917@acs.ucalgary.ca>

[David Ascher]
>> test_fork1 fails on Linux with threads on SMP machines. (It's
>> irrelevant without threads.) This is a hard failure -- the
>> process can either SEGV or hang forever. Is this a showstopper?
>> SMP boxes are becoming increasingly common both as servers and
>> workstations.
>
> Why does the test fail? I'd hate to see the thousands (nay,
> hundreds of thousands) of users complain that foo isn't working
> just because the test for a rarely used feature on a rare
> platform is broken.

Threads and fork() don't seem to mix on Linux.  Even on a
UP machine things seem strange:

    http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=613477888&fmt=text

I tried to reproduce the problem with a C program but could not.
When things hang the forking thread is stuck in wait4() while the
child process is suspended:

    #0  0x4027d9ba in sigsuspend () from /lib/libc.so.6
    #1  0x40232c77 in __pthread_wait_for_restart_signal ()
       from /lib/libpthread.so.0
    #2  0x4023406e in __pthread_lock () from /lib/libpthread.so.0
    #3  0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0
    #4  0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at
    thread_pthread.h:339
    #5  0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64,
    locals=0x0, 
        args=0x81be278, argcount=0, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, 
        owner=0x0) at ceval.c:630
    #6  0x805ac19 in call_function (func=0x81ebb2c, arg=0x81be26c,
    kw=0x0)
        at ceval.c:2552
    #7  0x805a5a4 in PyEval_CallObjectWithKeywords (func=0x81ebb2c,
    arg=0x81be26c, 
        kw=0x0) at ceval.c:2390
    #8  0x80b2c7b in t_bootstrap (boot_raw=0x81ebb50) at
    ./threadmodule.c:224
    #9  0x40230c8f in pthread_start_thread () from
    /lib/libpthread.so.0

I don't know if this is a LinuxThread problem or a Python
problem.

    Neil

-- 
The internet: Learn what you know.  Share what you don't.



From DavidA at ActiveState.com  Mon Jun  5 23:23:11 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 5 Jun 2000 14:23:11 -0700
Subject: [Python-Dev] RE: Revised 1.6 jobs list
In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca>
Message-ID: <PLEJJNOHDIGGLDPOGPJJKEJACGAA.DavidA@ActiveState.com>

> Threads and fork() don't seem to mix on Linux.  Even on a
> UP machine things seem strange:

I believe it.  My general point however is that even if the problem can't be
fixed because Linux is broken in some way, the test suite should be fixed
even if it means to ignore failures of test_fork1 if the system was
configured --with-thread.

--david




From mhammond at skippinet.com.au  Tue Jun  6 01:47:44 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 6 Jun 2000 09:47:44 +1000
Subject: [Python-Dev] Re: Revised 1.6 jobs list
In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEHJCMAA.mhammond@skippinet.com.au>

> I tried to reproduce the problem with a C program but could not.
> When things hang the forking thread is stuck in wait4() while the
> child process is suspended:

This looks very suspect.

>
>     #0  0x4027d9ba in sigsuspend () from /lib/libc.so.6
>     #1  0x40232c77 in __pthread_wait_for_restart_signal ()
>        from /lib/libpthread.so.0
>     #2  0x4023406e in __pthread_lock () from /lib/libpthread.so.0
>     #3  0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0
>     #4  0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at
>     thread_pthread.h:339
>     #5  0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64,

And very much like the Python thread-state is not being managed correctly
with fork.  From my understanding of fork (which is small), and of the
Python thread-state management, this doesnt surprise me.

Given the stack trace, it appears that Python is doing its periodic
thread-release as part of running around the main loop.

In the process of _releasing_ the thread-lock, it needs to _acquire_ a
mutex.  I dont know the Python threading on pthreads at all - would this be
correct (it would seem likely that such an implementation would be done).

But in the process of acquiring that mutex, we call

__pthread_wait_for_restart_signal()

Is it possible that is is something as simple as thread-idents changing
underneath Python when using fork?  It seems to me that the thread thinks
it is either new, or stale?

Just my 2c worth - and given my knowledge of Linux and pthreads, plus the
state of our dollar at the moment, it has better be AUD $0.02 :-)

Mark.





From trentm at activestate.com  Tue Jun  6 02:14:03 2000
From: trentm at activestate.com (Trent Mick)
Date: Mon, 5 Jun 2000 17:14:03 -0700
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer?
In-Reply-To: <Pine.GSO.4.10.10006030833470.14749-100000@sundial>
References: <20000602111417.A17233@activestate.com> <Pine.GSO.4.10.10006030833470.14749-100000@sundial>
Message-ID: <20000605171403.A21808@activestate.com>

On Sat, Jun 03, 2000 at 10:56:15AM +0300, Moshe Zadka wrote:
> On Fri, 2 Jun 2000, Trent Mick wrote:
> 
> > 3. - change PyMarshal_WriteLongToFile to raise an exception if the long
> > 	 overflows a 32-bit range
> 
> +1 on that, finally non-portable integers will cause an exception.
> 

Okay, I have to reiterate and ask again because I have the suspicion that I
may be missing the point and you all may not realize that. Stop me when I go
astray:

- the PyMarshal interface is used for all the .pyc content writing
- PyMarshal_WriteLongToFile is only used for writing the magic number and the
  time stamp
- the rest of the .pyc is written via PyMarshal_WriteObjectToFile


- PyMarshal_WriteLongToFile will currently silently truncate a 64-bit long to
  32-bits
- PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will
  *NOT* truncate the 64-bit integer but will write the whole thing

- On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr
  when a 64-bit integral value is read and the current platform is 32-bit.


The question is: Do we want PyMarshal_WriteLongToFile *AND*
PyMarshal_WriteObjectToFile to raise an exception when a long value overflows
32-bits? Up til now I was only proposing the former.


Trent

-- 
Trent Mick
trentm at activestate.com



From esr at thyrsus.com  Tue Jun  6 03:02:31 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 5 Jun 2000 21:02:31 -0400
Subject: [Python-Dev] ascii.py
Message-ID: <20000605210231.A25895@thyrsus.com>

Latest version.  Adds isctrl() and ismeta() functions (because I use them...)

Um.  What's the checkin procedure for library modules?  And do I have
permissions to do it?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"Guard with jealous attention the public liberty.  Suspect every one
who approaches that jewel.  Unfortunately, nothing will preserve it
but downright force.  Whenever you give up that force, you are
inevitably ruined."
	-- Patrick Henry, speech of June 5 1788
-------------- next part --------------
#
# ascii.py -- constants and memembership tests for ASCII characters
#

NUL	= 0x00	# ^@
SOH	= 0x01	# ^A
STX	= 0x02	# ^B
ETX	= 0x03	# ^C
EOT	= 0x04	# ^D
ENQ	= 0x05	# ^E
ACK	= 0x06	# ^F
BEL	= 0x07	# ^G
BS	= 0x08	# ^H
TAB	= 0x09	# ^I
HT	= 0x09	# ^I
LF	= 0x0a	# ^J
NL	= 0x0a	# ^J
VT	= 0x0b	# ^K
FF	= 0x0c	# ^L
CR	= 0x0d	# ^M
SO	= 0x0e	# ^N
SI	= 0x0f	# ^O
DLE	= 0x10	# ^P
DC1	= 0x11	# ^Q
DC2	= 0x12	# ^R
DC3	= 0x13	# ^S
DC4	= 0x14	# ^T
NAK	= 0x15	# ^U
SYN	= 0x16	# ^V
ETB	= 0x17	# ^W
CAN	= 0x18	# ^X
EM	= 0x19	# ^Y
SUB	= 0x1a	# ^Z
ESC	= 0x1b	# ^[
FS	= 0x1c	# ^\
GS	= 0x1d	# ^]
RS	= 0x1e	# ^^
US	= 0x1f	# ^_
SP	= 0x20	# space
DEL	= 0x7f	# delete

controlnames = [
"NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL",
"BS",  "HT",  "LF",  "VT",  "FF",  "CR",  "SO",  "SI",
"DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB",
"CAN", "EM",  "SUB", "ESC", "FS",  "GS",  "RS",  "US",
"SP"
]

def _ctoi(c):
    if type(c) == type(""):
        return ord(c)
    else:
        return c

def isalnum(c): return isalpha(c) or isdigit(c)
def isalpha(c): return isupper(c) or islower(c)
def isascii(c): return _ctoi(c) <= 127		# ?
def isblank(c): return _ctoi(c) in (8,32)
def iscntrl(c): return _ctoi(c) <= 31
def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57
def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126
def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122
def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126
def ispunct(c): return _ctoi(c) != 32 and not isalnum(c)
def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11)
def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90
def isxdigit(c): return isdigit(c) or \
    (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102)
def isctrl(c): return _ctoi(c) < 32
def ismeta(c): return _ctoi(c) > 127

def ascii(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x7f)
    else:
        return _ctoi(c) & 0x7f

def ctrl(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x1f)
    else:
        return _ctoi(c) & 0x1f

def alt(c):
    if type(c) == type(""):
        return chr(_ctoi(c) | 0x80)
    else:
        return _ctoi(c) | 0x80

def unctrl(c):
    bits = _ctoi(c)
    if bits == 0x7f:
        rep = "^?"
    elif bits & 0x20:
        rep = chr((bits & 0x7f) | 0x20)
    else:
        rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20)
    if bits & 0x80:
        return "!" + rep
    return rep

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libascii.tex
Type: application/x-tex
Size: 4408 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000605/22747858/attachment.bin>

From gstein at lyra.org  Tue Jun  6 03:10:17 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 5 Jun 2000 18:10:17 -0700 (PDT)
Subject: [Python-Dev] ascii.py
In-Reply-To: <20000605210231.A25895@thyrsus.com>
Message-ID: <Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>

On Mon, 5 Jun 2000, Eric S. Raymond wrote:
> Latest version.  Adds isctrl() and ismeta() functions (because I use them...)
> 
> Um.  What's the checkin procedure for library modules?

Guido has to give his blessing -- that he finds this useful and
appropriate for the Python library. He does that using his own criteria
and feedback from people here.

For example, I'm "+0" on it. (meaning that it seems okay, but I can also
live without it)

The actual mechanics are outlined at SourceForge:

  http://sourceforge.net/cvs/?group_id=5470


> And do I have permissions to do it?

Nope.

There are ten people with checkin privs:
  http://sourceforge.net/project/memberlist.php?group_id=5470

Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They use
<whatever> policy to determine whether a given person should become a SF
project member. That policy is probably just a gut feeling rather than
concrete rules, so I can't say "X, Y, and Z." I also don't know what kinds
of policies that they are asserting on people with privs.

Cheers,
-g

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




From jeremy at beopen.com  Tue Jun  6 03:23:40 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 21:23:40 -0400 (EDT)
Subject: [Python-Dev] ascii.py
In-Reply-To: <Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>
References: <20000605210231.A25895@thyrsus.com>
	<Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>
Message-ID: <14652.21148.139774.192634@localhost.localdomain>

Greg seems to understand this process better than the admins -- or at
least he can explain it quickly and clearly :-).  I apologize for the
rather confused state of affairs.  We'll clean up the process and
document it soon.

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
  GS> On Mon, 5 Jun 2000, Eric S. Raymond wrote:
  >> Latest version.  Adds isctrl() and ismeta() functions (because I
  >> use them...)
  >> 
  >> Um.  What's the checkin procedure for library modules?

  GS> Guido has to give his blessing -- that he finds this useful and
  GS> appropriate for the Python library. He does that using his own
  GS> criteria and feedback from people here.

I think I can safely speak for the admins when I say that we're not
sure what the process is other than securing Guido's blessing.  We
need to work out a clearer policy, but that will have to wait until
Guido gets back from his honeymoon.  Any new checkins we are making
are limited for the most part to modules we've already gotten his
blessing for.

There won't be another alpha release until he returns, so it's not
like we have to worry about getting new code in before a code freeze.

  GS> For example, I'm "+0" on it. (meaning that it seems okay, but I
  GS> can also live without it)

I'm in the same boat.  

  GS> There are ten people with checkin privs:
  GS> http://sourceforge.net/project/memberlist.php?group_id=5470

  GS> Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They
  GS> use <whatever> policy to determine whether a given person should
  GS> become a SF project member. That policy is probably just a gut
  GS> feeling rather than concrete rules, so I can't say "X, Y, and
  GS> Z." I also don't know what kinds of policies that they are
  GS> asserting on people with privs.

Another policy that needs to be defined.  "<whatever>" is surprisingly
close to what we actually have written down in our policies and
procedures manual.  I expect we will arrive at a policy where people
own pieces of the library and are free to maintain it.  Guido will
probably retain control over what modules come and go.

-- Jeremy Hylton <http://www.python.org/~jeremy/>




From esr at thyrsus.com  Tue Jun  6 03:33:24 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 5 Jun 2000 21:33:24 -0400
Subject: [Python-Dev] ascii.py
In-Reply-To: <14652.21148.139774.192634@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 09:23:40PM -0400
References: <20000605210231.A25895@thyrsus.com> <Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org> <14652.21148.139774.192634@localhost.localdomain>
Message-ID: <20000605213324.A26055@thyrsus.com>

Jeremy Hylton <jeremy at beopen.com>:
> Another policy that needs to be defined.  "<whatever>" is surprisingly
> close to what we actually have written down in our policies and
> procedures manual.  I expect we will arrive at a policy where people
> own pieces of the library and are free to maintain it.  Guido will
> probably retain control over what modules come and go.

Pretty much as I expected.  OK.  Let us know when things settle out
a little.  
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Before a standing army can rule, the people must be disarmed, as they
are in almost every kingdom in Europe. The supreme power in America
cannot enforce unjust laws by the sword, because the people are armed,
and constitute a force superior to any band of regular troops.
	-- Noah Webster



From tim_one at email.msn.com  Tue Jun  6 04:09:22 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 5 Jun 2000 22:09:22 -0400
Subject: Augmented assignment (was RE: [Python-Dev] Re: Is it just Syntactic Sugar ?)
In-Reply-To: <20000604005601.T469@xs4all.nl>
Message-ID: <001601bfcf5c$3bcb8e00$0ca0143f@tim>

[posted & mailed]

[Thomas Wouters, asking about Guido's sketch]
> This was what I had in mind, and was trying to explain. Does you
> voicing your opinion mean someone (you ? someone else ?) is working
> on this, or soon going to work on this ?

It's the same scheme he sketched the last time he was provoked into writing
about this <wink>, and that was at least a year ago.

> ...
> I'm curious what should happen with index-assignment and
> slice-assignment:

Nothing special!  You're reading far too much into Guido's sketch -- it
doesn't have all these convolutions.  Try reading his msg again, but this
time thinking like him too <wink>.

> x[y] += z

temp1 = x  # perhaps the first three are permuted, though
temp2 = y
temp3 = z
temp1[temp2] = temp1[temp2].__add_ab__(temp3)

And, yes, indexing is done twice (although "x" and "y" are evaluated only
once each).

> x[:y] += z

temp1 = x
temp2 = y
temp3 = z
temp1[:temp2] = temp1[:temp2].__add_ab__(temp3)

Similarly slicing is done twice.

> (Obviously this wont make sense for a lot of types, or will be too
> un-obvious to include, but I can imagine matrix-types to happily
> add this.)

Every type is free to implement __add_ab__ or not, in whatever way it likes.
But Python can't tell at compile-time which types do and don't implement it,
so chances are great that doing

   x += y

for x of a type that does not implement __add_ab__ will raise a runtime
AttributeError.

> Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0,
> y, z) ?

No.  *All* instances of "+=" are mapped straightforwardly to __add_ab__.
Context is irrelevent; indexing and slicing are not special cases (except to
the extent that they are already ...).

> Or would x[y] += z always call x[y].__add_item_ab__()

No.

> and x[:y] create a new object, a slice of x

What x[:y] means is entirely up to the type of x, and has no connection to
augmented assignment (except in that the author of the type may design both
to work smoothly together).

> and call its __add_ab__() method ?

__add_ab__ would be invoked on whatever x[:y] returns; whether that's "a new
object" or not is x.__get_slice__'s choice to make.

> Or would it try all of them, or more, until it gets a good result ?

No.  It works or it doesn't.

> Or am I running ahead of things and should we wait for a working
> patch first ? :)

No, you're running a few years behind things <wink>, and imagining
complications Guido would never sign up for.

and-now-the-spirits-must-rest-ly y'rs  - tim





From bwarsaw at python.org  Tue Jun  6 04:27:42 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 22:27:42 -0400 (EDT)
Subject: [Python-Dev] ascii.py
References: <20000605210231.A25895@thyrsus.com>
	<Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>
	<14652.21148.139774.192634@localhost.localdomain>
Message-ID: <14652.24990.563016.976820@anthem.python.org>

>>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:

    JH> I think I can safely speak for the admins when I say that
    JH> we're not sure what the process is other than securing Guido's
    JH> blessing.  We need to work out a clearer policy, but that will
    JH> have to wait until Guido gets back from his honeymoon.  Any
    JH> new checkins we are making are limited for the most part to
    JH> modules we've already gotten his blessing for.

My suggestion would be to upload to the SourceForge patch manager, any
patches or code you care about that you don't want us to lose track
of.  Things get buried in my inbox pretty easily, but at least with
the patch manager, we've got a record of it, and can eventually assign
a developer to tracking it.

-Barry



From trentm at activestate.com  Tue Jun  6 04:52:44 2000
From: trentm at activestate.com (Trent Mick)
Date: Mon, 5 Jun 2000 19:52:44 -0700
Subject: [Python-Dev] about patches on SourceForge
Message-ID: <20000605195244.A25437@activestate.com>

I just put up one my patches from this past week on SOurceForge. Question:
WWould you all prefer to have the "raw patch" just include the actually
patch/diff and for the first comment to be the patch description (and legal
stuff?) or would you prefer for the patch description and legal stuff to be
part of the "raw patch".

I am inclined to think that the former would be preferable. Is there some
"apply patch" button in SourceForge that would require the "raw patch" to
actually be raw?

Go check it out and you will know what I am talking about.

http://sourceforge.net/patch/?func=browse&group_id=5470&set=open


When I get an good opinion from some of you I will send up my other patches.




Trent

-- 
Trent Mick
trentm at activestate.com



From gstein at lyra.org  Tue Jun  6 05:32:27 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 5 Jun 2000 20:32:27 -0700 (PDT)
Subject: [Python-Dev] Re: httplib
In-Reply-To: <14651.13155.253651.575394@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.10006052025390.14292-100000@nebula.lyra.org>

On Mon, 5 Jun 2000, Jeremy Hylton wrote:
> >>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
>...
>   >> Oh. Wait. Maybe that was it. You can't read the "next" response
>   >> until the first one has been read. Well... no need to block
>   >> putting new responses; we just need to create a way to "get the
>   >> next reply" and/or "can I get the next reply yet?"
> 
> Maybe I should clarify the concern I had here.  I think we're on the
> same page, but I'm not sure.
> 
> The problem with pipelined requests is that the client must be sure to
> read all of response I before it can call getreply to get response
> I+1.

Actually, you can issue a getreply() after you've read the prior
response's headers, but before you completely read its body. Once you have
the header, then you know whether the connection will remain open or not.
Assuming it *will* remain open, then you can go ahead and do a
request/reply sequence. If the connection is going to close, then you have
to fail at request time.

> I imagine that it could add a lot of complexity to use code to
> implement this requirement, e.g. when multiple threads are sharing a
> single connection.  It would be good if the library could do something
> reasonable about the multiplexing.  In the absence of making it just
> work, the library could raise an error that makes clear what has gone
> wrong -- that the client isn't using the interface properly.

I'm working through this stuff right now. It is a bit tricky to get it
right *and* have it clear. I'm concentrating on the latter as much as
possible.

At the moment, HTTPResponse instances can be created without problems. I'm
locating the "can you issue a request [and get a response]" logic in the
connection object itself.

Another detail that I'm trying to work through is where the connection is
allowed to get the HTTPResponse to read the HTTP header. Reading off the
network could block, so we need to be a bit more careful about what
methods can block (if any).

In any case, the current httplib (at www.lyra.org/greg/python/) has got
just about everything. The next checkin will deal with this pipelining
issue.


QUESTION #2: I *really* want to get rid of the HTTPS() class. It is
introducing excessive complexity, with the only purpose being
compatibility against the post-1.5.2 CVS.

Anyone? Thoughts on removal?


Cheers,
-g

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




From mhammond at skippinet.com.au  Tue Jun  6 05:43:15 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 6 Jun 2000 13:43:15 +1000
Subject: [Python-Dev] about patches on SourceForge
In-Reply-To: <20000605195244.A25437@activestate.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au>

> When I get an good opinion from some of you I will send up my
> other patches.

How do you qualify a "good" opinion?  One that matches yours? <wink>

This is all too hard until Guido gets back.  But personally I believe the
raw patch should be just the CVS diff output, and the comments should
reflect all other text, including the release notice while it is still
necessary.

I hope my opinion is good enough :-)

Mark.




From jeremy at beopen.com  Tue Jun  6 05:46:01 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 23:46:01 -0400 (EDT)
Subject: [Python-Dev] Re: httplib
In-Reply-To: <Pine.LNX.4.10.10006052025390.14292-100000@nebula.lyra.org>
References: <14651.13155.253651.575394@localhost.localdomain>
	<Pine.LNX.4.10.10006052025390.14292-100000@nebula.lyra.org>
Message-ID: <14652.29689.663218.777234@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

  GS> QUESTION #2: I *really* want to get rid of the HTTPS() class. It
  GS> is introducing excessive complexity, with the only purpose being
  GS> compatibility against the post-1.5.2 CVS.

  GS> Anyone? Thoughts on removal?

I've got two answers.  I don't particularly like the old-style HTTP
interface, so I'm happy to see it replaced with a better one.  I say
who cares about HTTPS. 

On the other hand, there is a lot of existing code that uses the old
interface.  It would be good if that code could be modified to use the
new SSL interface without having to also re-write the code to use the
new http interface.  Perhaps we should keep it to provide a future
upgrade path for all the legacy code.  

I could probably be convinced that the amount of effort to change from
the old interface to the new interface is fairly small.  If you're
going to make one change to the code anyway, might as well start using
the modern interface, too.

Is there anyone who actually has http code to maintain that has an
opinion? 

Jeremy



From fdrake at beopen.com  Tue Jun  6 05:45:54 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 5 Jun 2000 23:45:54 -0400 (EDT)
Subject: [Python-Dev] about patches on SourceForge
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au>
References: <20000605195244.A25437@activestate.com>
	<ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au>
Message-ID: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com>

Mark Hammond writes:
 > This is all too hard until Guido gets back.  But personally I believe the
 > raw patch should be just the CVS diff output, and the comments should
 > reflect all other text, including the release notice while it is still
 > necessary.

  Sounds good to me.  Let's do it this way until there's a god reason
to do it differently.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From pf at artcom-gmbh.de  Tue Jun  6 11:05:58 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 6 Jun 2000 11:05:58 +0200 (MEST)
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer?
In-Reply-To: <20000605171403.A21808@activestate.com> from Trent Mick at "Jun 5, 2000  5:14: 3 pm"
Message-ID: <m12zFJ8-000DifC@artcom0.artcom-gmbh.de>

Hi,

[Trent Mick]:
[...]
> - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will
>   *NOT* truncate the 64-bit integer but will write the whole thing
> 
> - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr
>   when a 64-bit integral value is read and the current platform is 32-bit.
[...]
> The question is: Do we want PyMarshal_WriteLongToFile *AND*
> PyMarshal_WriteObjectToFile to raise an exception when a long value overflows
> 32-bits? Up til now I was only proposing the former.

Yes.  This should at least be the default behaviour of Python.

The current behaviour would otherwise cause great damage in the
following scenario, where an innocent software developer working on
a 64-Bit system trusts on the cross platform portability of Pythons
bytecode files and unintentional uses a huge integer literal.

If some people really don't care about portability, there could be 
switch/option/pragma/whatever to disable this behaviour.

IMO the portability of Python bytecode files is a *very* valuable property,
which we shouldn't give up on.

Regards, Peter



From gstein at lyra.org  Tue Jun  6 11:58:44 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 6 Jun 2000 02:58:44 -0700 (PDT)
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit
 integer?
In-Reply-To: <m12zFJ8-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.LNX.4.10.10006060257010.14292-100000@nebula.lyra.org>

On Tue, 6 Jun 2000, Peter Funk wrote:
> [Trent Mick]:
> [...]
> > - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will
> >   *NOT* truncate the 64-bit integer but will write the whole thing
> > 
> > - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr
> >   when a 64-bit integral value is read and the current platform is 32-bit.
> [...]
> > The question is: Do we want PyMarshal_WriteLongToFile *AND*
> > PyMarshal_WriteObjectToFile to raise an exception when a long value overflows
> > 32-bits? Up til now I was only proposing the former.
> 
> Yes.  This should at least be the default behaviour of Python.
> 
> The current behaviour would otherwise cause great damage in the
> following scenario, where an innocent software developer working on
> a 64-Bit system trusts on the cross platform portability of Pythons
> bytecode files and unintentional uses a huge integer literal.
> 
> If some people really don't care about portability, there could be 
> switch/option/pragma/whatever to disable this behaviour.
> 
> IMO the portability of Python bytecode files is a *very* valuable property,
> which we shouldn't give up on.

It isn't only bytecodes. As I mentioned before, marshal byte streams are
specified as portable. Therefore, they are used all the time for passing
over the network, for persistence mechanisms, etc.

Having a marshal stream that is *not* cross-platform is just plain busted.

So... you can silently truncate to 32-bits or you can raise an exception.
You cannot, however, marshal a 64-bit value when the definition of an
"marshal integer" is only 32.

Cheers,
-g

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




From gvwilson at nevex.com  Tue Jun  6 16:40:25 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 6 Jun 2000 10:40:25 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
Message-ID: <Pine.LNX.4.10.10006061035250.29478-100000@akbar.nevex.com>

Hi, everyone.  We're a month away from final submissions in the Software
Carpentry design competition, which means we're two months away from
announcing winners and starting implementation effort, and we're wondering
whether there are generally-accepted coding standards, naming conventions,
or other guidelines that we should adopt.  If so, URLs would be welcome...

Also, it appears that there are two implementations of the xUnit testing
framework in Python:

Steve Purcell: http://sourceforge.net/project/?group_id=3912
Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip

We'd be grateful for comments on either.

Thanks,
Greg Wilson
Software Carpentry Project Coordinator





From klm at digicool.com  Tue Jun  6 18:16:58 2000
From: klm at digicool.com (Ken Manheimer)
Date: Tue, 6 Jun 2000 12:16:58 -0400 (EDT)
Subject: [Python-Dev] Guido and Kim married
Message-ID: <14653.9210.757666.324583@korak.digicool.com>

Guido van Rossum and Kim Knapp were married Saturday afternoon on the
lawn of a graceful southern estate, Claymont Court, in West Virginia,
USA.  The weather was *stunningly* fine - a great boon, considering
the rain the night before (a torrential downpour in nearby DC) - and
the couple left for their honeymoon sunday.  Hooray!

The crowd consisted of i would guess 70 to 100 people, a mixture of
hollanders (including several van rossum relatives - hiya Just!),
knapps, pythoners, contact improvisors, economists, martial artists,
and sundry other friends and family.

I leave to others to quibble about whether or not this qualifies as a
"python development".  (I probably made enough of a fool of myself at
the wedding, with pronouncements of good will and dancing and such,
that i can't do any more harm...-)

Yay!

Ken
klm at digicool.com



From tim_one at email.msn.com  Tue Jun  6 19:20:49 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 6 Jun 2000 13:20:49 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.LNX.4.10.10006061035250.29478-100000@akbar.nevex.com>
Message-ID: <001001bfcfdb$8f64d240$48a2143f@tim>

[Greg Wilson]
> Hi, everyone.  We're a month away from final submissions in the
> Software Carpentry design competition, which means we're two months
> away from announcing winners and starting implementation effort,

Yay!  This is a wonderful competition, and if nobody yet has bothered to
thank you for spearheading it, let me know & I'll find someone who will
<wink>.

> and we're wondering whether there are generally-accepted coding
> standards, naming conventions, or other guidelines that we should
> adopt.  If so, URLs would be welcome...

When you can't fight about where to put curly braces, there's not much left
to argue.  The only serious attempt at a Python style guide I've seen is
Guido's:

    http://www.python.org/doc/essays/styleguide.html

Two from there large numbers of people will still argue about, but to no
avail:

+ No hard tabs.  Indents are 4 spaces, period.

+ Keep lines strictly less than 80 characters wide (I happen to keep them
under 77, to allow for one level of "> " mail quoting).

These rules ensure that code is readable as intended across all platforms.

> Also, it appears that there are two implementations of the xUnit
> testing framework in Python:
>
> Steve Purcell: http://sourceforge.net/project/?group_id=3912
> Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip
>
> We'd be grateful for comments on either.

Sorry, unfamiliar with these.





From pingster at ilm.com  Tue Jun  6 19:25:57 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Tue, 6 Jun 2000 10:25:57 -0700 (PDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <Pine.SGI.3.96.1000606102423.30600j-100000@happy>

On Tue, 6 Jun 2000, Tim Peters wrote:
> 
> Yay!  This is a wonderful competition, and if nobody yet has bothered to
> thank you for spearheading it, let me know & I'll find someone who will
> <wink>.

Yeah, what he said. :)

> The only serious attempt at a Python style guide I've seen is Guido's:
> 
>     http://www.python.org/doc/essays/styleguide.html

I love this style guide.  I know it's a strange reaction to
have to a style guide, but i agree with basically everything
in it, which is probably pretty rare for these sorts of things.

> + No hard tabs.  Indents are 4 spaces, period.

Tab characters are the work of the devil.


-- ?!ng

"China is a big country, inhabited by many Chinese."
    -- Former French President Charles de Gaulle




From gvwilson at nevex.com  Tue Jun  6 19:31:32 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 6 Jun 2000 13:31:32 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <Pine.LNX.4.10.10006061328070.32393-100000@akbar.nevex.com>

> Tim Peters wrote:
> When you can't fight about where to put curly braces, there's not much
> left to argue.  The only serious attempt at a Python style guide I've
> seen is Guido's:
>     http://www.python.org/doc/essays/styleguide.html

Yes, I've seen this.  I was wondering (a) whether it's up to date (i.e.
whether common practice has moved on), and (b) whether there is now a
consensus about module structure --- we're expecting several packages that
will be shared between tools, plus multiple modules within tools.  I've
been tracking the occasional message about re-organizing the standard
Python library, and would like whatever we do to be in line with wherever
Python itself is going.

Thanks,
Greg





From esr at thyrsus.com  Tue Jun  6 19:47:13 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 6 Jun 2000 13:47:13 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.SGI.3.96.1000606102423.30600j-100000@happy>; from pingster@ilm.com on Tue, Jun 06, 2000 at 10:25:57AM -0700
References: <001001bfcfdb$8f64d240$48a2143f@tim> <Pine.SGI.3.96.1000606102423.30600j-100000@happy>
Message-ID: <20000606134713.A29204@thyrsus.com>

Ka-Ping Yee <pingster at ilm.com>:
> > The only serious attempt at a Python style guide I've seen is Guido's:
> > 
> >     http://www.python.org/doc/essays/styleguide.html
> 
> I love this style guide.  I know it's a strange reaction to
> have to a style guide, but i agree with basically everything
> in it, which is probably pretty rare for these sorts of things.

Likewise.  I never read this before, but it's spooky how closely the
style I evolved myself tracks it.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

If a thousand men were not to pay their tax-bills this year, that would
... [be] the definition of a peaceable revolution, if any such is possible.
	-- Henry David Thoreau



From petrilli at amber.org  Tue Jun  6 19:52:50 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Tue, 6 Jun 2000 13:52:50 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>; from tim_one@email.msn.com on Tue, Jun 06, 2000 at 01:20:49PM -0400
References: <Pine.LNX.4.10.10006061035250.29478-100000@akbar.nevex.com> <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <20000606135250.A25856@trump.amber.org>

Tim Peters [tim_one at email.msn.com] wrote:

> When you can't fight about where to put curly braces, there's not much left
> to argue.  The only serious attempt at a Python style guide I've seen is
> Guido's:
> 
>     http://www.python.org/doc/essays/styleguide.html

The only thing that might be added (I haven't looked in a while, but
didn't see it last time I did), is some naming convention issues.  I
follow pretty standard Smalltalk guidelines:

       - No '_', use camelCase for seps

       - Capitalize all Classes, and also global variables

       - Lowercase for all methods (i.e. setNewBreakpoint)

This is just me, and obviously not everyone does this :-)

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From gvwilson at nevex.com  Tue Jun  6 19:50:38 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 6 Jun 2000 13:50:38 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <20000606135250.A25856@trump.amber.org>
Message-ID: <Pine.LNX.4.10.10006061347510.32673-100000@akbar.nevex.com>

> > Tim Peters:
> > http://www.python.org/doc/essays/styleguide.html

> On Tue, 6 Jun 2000, Christopher Petrilli wrote:
> The only thing that might be added (I haven't looked in a while, but
> didn't see it last time I did), is some naming convention issues.  I
> follow pretty standard Smalltalk guidelines:
> 
>        - No '_', use camelCase for seps

I know this is become common practice, but I've been told by two different
HCI specialists that studies have shown CamelBackNotation to be harder for
non-native speakers to read than underbar_separated_text, particularly
when acronyms are part of the name.  If anyone has a pointer to an
original reference for this, I'd be grateful.

Thanks,
Greg





From klm at digicool.com  Tue Jun  6 20:32:12 2000
From: klm at digicool.com (Ken Manheimer)
Date: Tue, 6 Jun 2000 14:32:12 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.SGI.3.96.1000606102423.30600j-100000@happy>
Message-ID: <Pine.LNX.4.21.0006061431040.675-100000@korak.digicool.com>

On Tue, 6 Jun 2000, Ka-Ping Yee wrote:

> > The only serious attempt at a Python style guide I've seen is Guido's:
> > 
> >     http://www.python.org/doc/essays/styleguide.html
> 
> I love this style guide.  I know it's a strange reaction to
> have to a style guide, but i agree with basically everything
> in it, which is probably pretty rare for these sorts of things.

Me too!  (Or three, or four by now...)

Ken
klm at digicool.com




From tim_one at email.msn.com  Tue Jun  6 20:36:26 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 6 Jun 2000 14:36:26 -0400
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bitinteger?
In-Reply-To: <Pine.LNX.4.10.10006060257010.14292-100000@nebula.lyra.org>
Message-ID: <001201bfcfe6$1fe51dc0$48a2143f@tim>

[GregS]
> It isn't only bytecodes. As I mentioned before, marshal byte streams are
> specified as portable. Therefore, they are used all the time for passing
> over the network, for persistence mechanisms, etc.
>
> Having a marshal stream that is *not* cross-platform is just plain busted.
>
> So... you can silently truncate to 32-bits or you can raise an exception.

But in either of those cases it's not cross-platform == it's just plain
busted.

> You cannot, however, marshal a 64-bit value when the definition of an
> "marshal integer" is only 32.

The current code is insane.  Long-term the visible distinction between
(Python) ints and longs should vanish.  Short-term the PyInt_Check case of
w_object should see whether the int fits in 4 bytes, and if so write it as a
C long, and if not write the thing as a Python long (that's the only way to
keep the marshal portable!).  Any code keying off the SIZEOF_LONG symbol is
highly suspect, piling another layer of "convenient but wrong" assumptions
on top of the current layer.  Code in marshal should *never* try to exploit
that C longs happen to be bigger than 4 bytes on the current platform.
PyMarshal_WriteLongToFile should be changed to raise an exception if passed
something that doesn't fit in 4 bytes, and should be declared obsolete.  The
Python core should be changed now never to call PyMarshal_WriteLongToFile
(in answer to Trent's original question, the intent of that code can't be
distinguished from what it does, which is to blindly write exactly 4 bytes
no matter what).

Most of this crap is in support of a bad assumption about mtimes, and,
sorry, but it sure looks to me like the .pyc header format is "just plain
busted" too.  Let's bite the bullet and fix the header -- then all the rest
of this will be clearly seen as the broken hackery it really is.





From trentm at activestate.com  Tue Jun  6 20:57:52 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 6 Jun 2000 11:57:52 -0700
Subject: [Python-Dev] about patches on SourceForge
In-Reply-To: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com>
References: <20000605195244.A25437@activestate.com> <ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au> <14652.29682.819341.881773@cj42289-a.reston1.va.home.com>
Message-ID: <20000606115752.D28943@activestate.com>

On Mon, Jun 05, 2000 at 11:45:54PM -0400, Fred L. Drake, Jr. wrote:
> 
> Mark Hammond writes:
>  > This is all too hard until Guido gets back.  But personally I believe the
>  > raw patch should be just the CVS diff output, and the comments should
>  > reflect all other text, including the release notice while it is still
>  > necessary.
> 
>   Sounds good to me.  Let's do it this way until there's a god reason
                                                             ^^^
> to do it differently.
> 

I think maybe that you meant 'good', but I am not so sure. ;-)

Trent


-- 
Trent Mick
trentm at activestate.com



From gmcm at hypernet.com  Tue Jun  6 20:59:49 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 6 Jun 2000 14:59:49 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.LNX.4.10.10006061328070.32393-100000@akbar.nevex.com>
References: <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <1251804473-5567942@hypernet.com>

Greg Wilson wrote:

> > Tim Peters wrote:
[Guido's style guide]

> Yes, I've seen this.  I was wondering 
> ... whether
> there is now a consensus about module structure ...

No, there's not. And if you ask me, (which you didn't) there's 
some very bad precedents getting set in the misguided pursuit 
of "ease of use".

Time to call out the PSU before things get out of hand...


- Gordon



From gstein at lyra.org  Tue Jun  6 21:04:25 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 6 Jun 2000 12:04:25 -0700 (PDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.LNX.4.10.10006061347510.32673-100000@akbar.nevex.com>
Message-ID: <Pine.LNX.4.10.10006061201340.14292-100000@nebula.lyra.org>

On Tue, 6 Jun 2000, Greg Wilson wrote:
> > > Tim Peters:
> > > http://www.python.org/doc/essays/styleguide.html
> 
> > On Tue, 6 Jun 2000, Christopher Petrilli wrote:
> > The only thing that might be added (I haven't looked in a while, but
> > didn't see it last time I did), is some naming convention issues.  I
> > follow pretty standard Smalltalk guidelines:
> > 
> >        - No '_', use camelCase for seps
> 
> I know this is become common practice, but I've been told by two different
> HCI specialists that studies have shown CamelBackNotation to be harder for
> non-native speakers to read than underbar_separated_text, particularly
> when acronyms are part of the name.  If anyone has a pointer to an
> original reference for this, I'd be grateful.

Actually, the "camel case" for identifiers is not a standard Python style.
I've seen three forms:

- no separator or case usage (e.g. getattr())
- mixed case
- lower case with underscores

Chris' other points: upper-case-initial classes and lower-case-initial
methods are *definitely* standard.

Globals are a bit different. I don't think it is standard to capitalize
them as Chris mentioned (they might look like classes in that case). There
isn't much of a standard there.

Definitely another point is the use of "_" for the initial character to
signify "private -- don't touch"

Cheers,
-g

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






From gstein at lyra.org  Tue Jun  6 21:29:56 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 6 Jun 2000 12:29:56 -0700 (PDT)
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errors
 in signalmodule.c and bufferobject.c)
In-Reply-To: <001c01bfcfea$b73a2040$48a2143f@tim>
Message-ID: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org>

On Tue, 6 Jun 2000, Tim Peters wrote:
>...
> [on K&R style declarations failing to act as prototypes]
> > ...
> > Give the man a prize. That was it. We'll just forget that part of the
> > patch then and thank you Tim for changing all function declarations
> > from K&R to ANSI. :)
> 
> Believe it or not, I do intend to do that, although I expect resistance from
> Guido <0.5 wink>.  Python's infrastructure is creaking from age, and an
> update to ANSI C is l-o-n-g overdue.  It appears to me that a very large
> part of your "Win64" efforts have amounted to fighting long-obsolete K&R C
> assumptions!

Euh... I thought Guido was entirely supportive of ANSI-fying the source.
Something like changing from K&R functions over to ANSI declarations is
"brain-dead" that should not introduce errors.

Going through and revamping the protoypes (e.g. PyString_FromStringAndSize
to now use size_t) is a bit different, though...

I shouldn't think Guido would be upset about prototypes.

Cheers,
-g

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




From effbot at telia.com  Tue Jun  6 22:23:19 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 6 Jun 2000 22:23:19 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org>
Message-ID: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid>

greg wrote:
> Euh... I thought Guido was entirely supportive of ANSI-fying the source.

note that 1.6 won't build on non-ANSI platforms; lots of new
stuff, including the unicode type, the builtin exceptions, and
SRE are pure ANSI.

(btw, what are all those "register" declarations doing in MAL's
version of unicodeobject.c?  does any modern compiler even
care about that keyword?)

</F>




From tim_one at email.msn.com  Tue Jun  6 23:00:33 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 6 Jun 2000 17:00:33 -0400
Subject: [Python-Dev] RE: ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c)
In-Reply-To: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org>
Message-ID: <001f01bfcffa$41ed2f20$48a2143f@tim>

[Greg Stein]
> Euh... I thought Guido was entirely supportive of ANSI-fying the source.
> Something like changing from K&R functions over to ANSI declarations is
> "brain-dead" that should not introduce errors. ...

He'll be less & less in favor of it when it hits home how time-consuming and
massive the changes will be.  They won't be viewed as "a feature" to BeOpen,
so BeOpen will give him grief about it too.  Etc.  I've fought the same
stinking infrastructure battles for 20+ years, and don't expect that having
a new boss will make any material difference to that <0.7 wink>.  Testing is
expensive, robustness is expensive, portability is expensive (and C doesn't
help!  honest to God, it's much worse than Fortran for portability).

> Going through and revamping the protoypes (e.g. PyString_FromStringAndSize
> to now use size_t) is a bit different, though...
>
> I shouldn't think Guido would be upset about prototypes.

Nobody should get upset about *having* them, it's getting them done that
takes away from getting everything else done.  That's why every project I've
ever seen puts it off year after year.  Note that if Guido valued this
*highly*, it would already have been done.

been-there-done-that-been-there-done-that-been-there-done-that-ly y'rs  -
tim





From jack at oratrix.nl  Tue Jun  6 23:14:10 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Tue, 06 Jun 2000 23:14:10 +0200
Subject: [Python-Dev] Trying again:  [Patches] Patch to import.c
Message-ID: <20000606211416.10B6ED8397@oratrix.oratrix.nl>

Folks,
I posted this message to the patches mailing list last week, but
either I missed the reply (we had full disks over the weekend) or
nobody replied yet. And I am waiting for these patches, or rather
other people who want to play with MacPython and MacOSX are, so I'd
really like to know whether I should revise the patches and in what
direction or have them checked in....

Hmm, that may all sound a bit pushy, but that isn't the intention. I
really just want to know (a) what the status of my patches is and (b)
what I can expect in the future....

	Jack
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: no subject
Date: no date
Size: 38
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000606/00891a7f/attachment.eml>

From mal at lemburg.com  Wed Jun  7 00:53:02 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Jun 2000 00:53:02 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit 
 warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org> <01b101bfcff5$1000faa0$f2a6b5d4@hagrid>
Message-ID: <393D80CE.D6C387AA@lemburg.com>

Fredrik Lundh wrote:
> 
> note that 1.6 won't build on non-ANSI platforms; lots of new
> stuff, including the unicode type, the builtin exceptions, and
> SRE are pure ANSI.
> 
> (btw, what are all those "register" declarations doing in MAL's
> version of unicodeobject.c?  does any modern compiler even
> care about that keyword?)

"register" helps compilers in situations where normal
optimizations don't give satisfying results, e.g. to aid
in keeping often used variables or counters in registers
rather than on the stack. It can also help with inling
functions and can speed up parameter passing.

GCC is one such modern compiler that does care, not sure
about MSVC++. IBM's OS/2 compilers did (last time
I looked some 5 years ago ;).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From pf at artcom-gmbh.de  Wed Jun  7 00:47:41 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 00:47:41 +0200 (MEST)
Subject: Style guide (was Re: [Python-Dev] req: Software Carpentry / coding standards)
In-Reply-To: <Pine.LNX.4.10.10006061347510.32673-100000@akbar.nevex.com> from Greg Wilson at "Jun 6, 2000  1:50:38 pm"
Message-ID: <m12zS8L-000DifC@artcom0.artcom-gmbh.de>

Hi,

Greg Wilson:
> > > Tim Peters:
> > > http://www.python.org/doc/essays/styleguide.html
> 
> > On Tue, 6 Jun 2000, Christopher Petrilli wrote:
> > The only thing that might be added (I haven't looked in a while, but
> > didn't see it last time I did), is some naming convention issues.  I
> > follow pretty standard Smalltalk guidelines:
> > 
> >        - No '_', use camelCase for seps
> 
> I know this is become common practice, but I've been told by two different
> HCI specialists that studies have shown CamelBackNotation to be harder for
> non-native speakers to read than underbar_separated_text, particularly
> when acronyms are part of the name.  If anyone has a pointer to an
> original reference for this, I'd be grateful.

This would be indeed very interesting.  

But my own experiences support this POV:

This naming style issue is similar in Python and one of its early
anchestors Modula-2.

In 1985 we started our company programming in Modula-2.  At that
time we decided to code conforming to the original Modula-2 language
definition as published by N.Wirth in March, 1980:  underscores were 
not allowed in identifiers!  German: '_' verboten! ;-)

The software is in use until today and several of our employees still
have to use Modula-2 for maintainance.  The code base is currently
about 1 Mio. LOC.

We tried to use english identifiers, although all programmers are 
native german speakers.

We too adopted a style using first char lowercase or uppercase to
distinguish identifier classes (modules and procedure names uppercase
and all other identifiers lowercase) and later we ran into the
problems described above.

A few years ago we allowed the use of '_' in identifiers, because
the compiler support was available.  This has improved the situation
somewhat.  All our programmers like the possibility to occasionally
use '_' in identifiers, especially if idents contain acronyms.

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)



From pf at artcom-gmbh.de  Wed Jun  7 11:34:12 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 11:34:12 +0200 (MEST)
Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5)
In-Reply-To: <200006070911.CAA17368@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000  2:11:43 am"
Message-ID: <m12zcE0-000DifC@artcom0.artcom-gmbh.de>

Hi,

Marc-Andre Lemburg:
[...]
> Added a new locale name aliasing engine which also supports
> locale encodings, a feature which is used by the new default
> encoding support in site.py.
> 
> Index: locale.py
[...]
> + ### C lib locale APIs
> + 
> + from _locale import *

Wouldn't it be clever to provide some dummy stubs on those platforms, where 
the _locale module was not enabled?  

try:
    from _locale import *
except:
    def setlocale(....
    def localeconv(....
    ...

Especially the MacOS 1.5.2 release provided by Jack Jansen was
compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
is still disabled per default in 'Modules/Setup.in'.  I didn't had
a look into the current CVS though, so this may have changed.

I think the name aliasing tables might be also useful on those
systems lacking locale support in their C-library.

Regards, Peter



From pf at artcom-gmbh.de  Wed Jun  7 11:40:17 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 11:40:17 +0200 (MEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules Setup.in,1.100,1.101
In-Reply-To: <200006070912.CAA17814@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000  2:12:56 am"
Message-ID: <m12zcJt-000DifC@artcom0.artcom-gmbh.de>

Uoooppps....
I was just too fast with my previous email about _locale emulation.

Marc-Andre Lemburg:
> *** Setup.in	2000/05/26 19:02:42	1.100
> --- Setup.in	2000/06/07 09:12:54	1.101
> ***************
> *** 141,145 ****
>                           # static Unicode character database
>   
> ! #_locale _localemodule.c  # access to ISO C locale support
>   
>   
> --- 141,145 ----
>                           # static Unicode character database
>   
> ! _locale _localemodule.c  # access to ISO C locale support
>   

Is this likely to work on the Mac with C-libraries coming with
Metrowerks CodeWarrior?  Jack?

Regards, Peter



From fredrik at pythonware.com  Wed Jun  7 12:24:46 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 7 Jun 2000 12:24:46 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org> <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com>
Message-ID: <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com>

MAL wrote:
> > (btw, what are all those "register" declarations doing in MAL's
> > version of unicodeobject.c?  does any modern compiler even
> > care about that keyword?)
> 
> "register" helps compilers in situations where normal
> optimizations don't give satisfying results, e.g. to aid
> in keeping often used variables or counters in registers
> rather than on the stack. It can also help with inling
> functions and can speed up parameter passing.

Yeah, I know what register is supposed to do.

But common knowledge (at least where I live) is that modern optimizers
know better than you, and usually ignore "register" altogether if you use
higher optimization levels... (and if they don't, using "register" is likely to
make things worse on some platforms).  In other words, "register" should
not be used in portable code.

fwiw, a certain Linux kernel hacker seem to agree with me on that one:

    http://www2.linuxjournal.com/lj-issues/issue17/1138.html
    ...
    #define register
    ...
    "Gcc, the normal Linux C compiler, understands the register keyword,
    but the code optimiser is sufficiently good that using register is normally
    a bad idea."
    ...

(If it's good enough for Alan Cox etc).

But never mind.  I doubt that removing them would matter on any con-
temporary platform, but on the other hand, keeping them in there won't
hurt much either.  It just makes the source code a little bit more ver-
bose than it has to be...

</F>




From mal at lemburg.com  Wed Jun  7 12:25:08 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Jun 2000 12:25:08 +0200
Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: 
 python/dist/src/Lib locale.py,1.4,1.5)
References: <m12zcE0-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <393E2304.4BE8CDE0@lemburg.com>

Peter Funk wrote:
> 
> Hi,
> 
> Marc-Andre Lemburg:
> [...]
> > Added a new locale name aliasing engine which also supports
> > locale encodings, a feature which is used by the new default
> > encoding support in site.py.
> >
> > Index: locale.py
> [...]
> > + ### C lib locale APIs
> > +
> > + from _locale import *
> 
> Wouldn't it be clever to provide some dummy stubs on those platforms, where
> the _locale module was not enabled?
> 
> try:
>     from _locale import *
> except:
>     def setlocale(....
>     def localeconv(....
>     ...
> 
> Especially the MacOS 1.5.2 release provided by Jack Jansen was
> compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
> is still disabled per default in 'Modules/Setup.in'.  I didn't had
> a look into the current CVS though, so this may have changed.
> 
> I think the name aliasing tables might be also useful on those
> systems lacking locale support in their C-library.

setlocale and localeconv are ANSI C and Python requires an ANSI C
compiler, so there should be no problem (at least in theory).

If there is a problem, adding the missing symbols would
be no problem: the APIs could always report locale 'C'
and its numeric settings.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From mal at lemburg.com  Wed Jun  7 12:40:24 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Jun 2000 12:40:24 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit 
 warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org> <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com> <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com>
Message-ID: <393E2698.D2DFFC91@lemburg.com>

Fredrik Lundh wrote:
> 
> MAL wrote:
> > > (btw, what are all those "register" declarations doing in MAL's
> > > version of unicodeobject.c?  does any modern compiler even
> > > care about that keyword?)
> >
> > "register" helps compilers in situations where normal
> > optimizations don't give satisfying results, e.g. to aid
> > in keeping often used variables or counters in registers
> > rather than on the stack. It can also help with inling
> > functions and can speed up parameter passing.
> 
> Yeah, I know what register is supposed to do.

I know you know, but I find adding some explanations for others
which might not know is good practice.
 
> But common knowledge (at least where I live) is that modern optimizers
> know better than you, and usually ignore "register" altogether if you use
> higher optimization levels... (and if they don't, using "register" is likely to
> make things worse on some platforms).  In other words, "register" should
> not be used in portable code.
> 
> fwiw, a certain Linux kernel hacker seem to agree with me on that one:
> 
>     http://www2.linuxjournal.com/lj-issues/issue17/1138.html
>     ...
>     #define register
>     ...
>     "Gcc, the normal Linux C compiler, understands the register keyword,
>     but the code optimiser is sufficiently good that using register is normally
>     a bad idea."
>     ...

Well, make that "normally not needed": gcc sometimes doesn't inline
functions because it thinks that the function needs parameters to be
on the stack. The register keyword can do wonders here.

Adding "register" is like adding salt & pepper: things usually
taste better than before ;-).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gward at mems-exchange.org  Wed Jun  7 15:19:06 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 09:19:06 -0400
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <200006021503.RAA26314@pandora>; from loewis@informatik.hu-berlin.de on Fri, Jun 02, 2000 at 05:03:50PM +0200
References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org> <200006021503.RAA26314@pandora>
Message-ID: <20000607091906.A5559@ludwig.cnri.reston.va.us>

On 02 June 2000, Martin von Loewis said:
> Having the full set of distutils doc strings in the
> catalog is already a substantial amount of text to translate...

Most of those docstrings in the Distutils are not really for public
consumption; they're there so that Distutils developers can remember (or
learn) what the heck such-and-such a method is supposed to do.

Also, they're a moving target; things are still changing in the
Distutils, and trying to keep on top of translating internal docstrings
would be a hopeless and frustrating task.

        Greg



From jack at oratrix.nl  Wed Jun  7 15:51:54 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 07 Jun 2000 15:51:54 +0200
Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] 
 CVS: python/dist/src/Lib locale.py,1.4,1.5)
In-Reply-To: Message by "M.-A. Lemburg" <mal@lemburg.com> ,
	     Wed, 07 Jun 2000 12:25:08 +0200 , <393E2304.4BE8CDE0@lemburg.com> 
Message-ID: <20000607135154.8DCFD370CF2@snelboot.oratrix.nl>

The locale stuff in the CodeWarrior libraries is basically a dummy 
placeholder, that's why I didn't export it to Python. But it appears that it's 
better to export it anyway, if I understand the dsicussion correctly, so I'll 
do so from the next release.
--
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 gward at mems-exchange.org  Wed Jun  7 15:56:38 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 09:56:38 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>; from jeremy@beopen.com on Sat, Jun 03, 2000 at 12:11:48PM -0400
References: <3938D60E.391AAF31@lemburg.com> <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
Message-ID: <20000607095638.B5559@ludwig.cnri.reston.va.us>

On 03 June 2000, Jeremy Hylton said:
> SourceForge makes it a little more inconvenient to check which
> patches have been applied.  Under the old CVS arrangement, it was
> a local operation to do a cvs log or diff.  Now it's a slow network
> operation that requires authentication.  (I really want a local
> mirror of the entire CVS repository!)

I have come up with a partial solution to the inconvenience of accessing
SourceForge, specifically the need for constant authentication.  I
generated a new, unencrypted SSH key and put it in ~/.ssh/alt-identity.
Then I wrote a little C program (source attached) that does the
equivalent of

  os.exec ("ssh", "-i", "$HOME/.ssh/alt-identity")

(in an imaginary dialect of Python that interpolates environment
variables ;-).  Then I set CVS_RSH to this little C program
(~/bin/alt_ssh).  (It could have easily been a script, but I wanted to
avoid the overhead of launching an interpreter for every
authentication.)

So now CVS operations against SF are just s..l..o..w, and I'm not
forever typing in my SSH passphrase.  Of course, anyone with root access
at CNRI could now steal my unencrypted key -- which I *only* use for CVS
access to SF -- and use it to impersonate me for checkins.  But I think
the only person who knows how to do that already has Python checkin
privilege.  ;-)

But yeah, remote CVS still bites the big one.  Very painful over a 28.8k 
modem line.  (It sucks being a cheap bastard!)

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From gward at mems-exchange.org  Wed Jun  7 15:57:41 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 09:57:41 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us>; from gward@ludwig.cnri.reston.va.us on Wed, Jun 07, 2000 at 09:56:38AM -0400
References: <3938D60E.391AAF31@lemburg.com> <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com> <20000607095638.B5559@ludwig.cnri.reston.va.us>
Message-ID: <20000607095741.C5559@ludwig.cnri.reston.va.us>

On 07 June 2000, I said:
> Then I wrote a little C program (source attached) that does the
> equivalent of

Oops, forgot the attachment.  Here 'tis.
-------------- next part --------------
/*
 * alt_ssh
 *
 * exec ssh with an alternate "identity" (key pair) -- needed since
 * the CVS_RSH variable can't include options for the rsh-like
 * command.
 *
 * GPW 2000/05/28
 *
 * $Id: alt_ssh.c,v 1.3 2000/06/07 13:54:19 gward Exp $
 */

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main (int argc, char * argv[])
{
    char * keyfile = "/.ssh/alt-identity";
    char * keyfile_full;
    char * home;
    int  num_args;
    char ** ssh_args;
    int i;

    home = getenv("HOME");
    keyfile_full = (char *) malloc (strlen(home) + strlen(keyfile) + 1);
    assert (home != NULL && keyfile_full != NULL);
    strcpy(keyfile_full, home);
    strcat(keyfile_full, keyfile);

    num_args = argc + 2;                /* -i, identity-file */
    ssh_args = (char **) calloc (num_args+1, sizeof(char *));
    ssh_args[0] = "ssh";
    ssh_args[1] = "-i";
    ssh_args[2] = keyfile_full;

    for (i = 3; i < num_args; i++)
        ssh_args[i] = argv[i-2];
    ssh_args[i] = NULL;

    for (i = 0; i < num_args; i++)
    {
        printf(ssh_args[i]);
        if (i < num_args)
            printf(" ");
    }
    printf("\n");
    
    execvp("ssh", ssh_args);
    perror("couldn't exec ssh");
    exit(1);
}

From jeremy at beopen.com  Wed Jun  7 16:04:12 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 10:04:12 -0400 (EDT)
Subject: [Python-Dev] Fwd: Hmmmm... (Jim Anderson)
Message-ID: <14654.22108.959934.552869@localhost.localdomain>

You guys haven't seen more Perl traffic on this list have you? :-)

Jeremy

-------------- next part --------------
An embedded message was scrubbed...
From: "Jim Anderson" <jander at ml.com>
Subject: Hmmmm...
Date: Tue, 6 Jun 2000 12:09:53 -0400 (EDT)
Size: 490
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000607/d27a0195/attachment.eml>

From gward at mems-exchange.org  Wed Jun  7 16:11:46 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 10:11:46 -0400
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.)
In-Reply-To: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>; from gstein@lyra.org on Sun, Jun 04, 2000 at 04:30:08PM -0700
References: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
Message-ID: <20000607101146.D5559@ludwig.cnri.reston.va.us>

On 04 June 2000, Greg Stein said:
> p.s. IMO, I'd like to see Guido own the Copyright for all current and
> future Python development

Second that.  Given that I work for CNRI and was forced (at gunpoint, as
I recall) to sign an incredibly draconian IP agreement -- along the
lines of "everything you have ever created, or will ever consider
creating, in any medium whatsoever, no matter where you did it or who
pays for it, is the property of CNRI for all time" -- I'd have a hard
time getting away with slapping "Copyright (c) 1999-2000 Gregory
P. Ward" all over the Distutils code.  And given that fair chunks of
that code have been contributed by other people, I couldn't even
ethically do that.

So, given that I probably can't claim ownership in the code, and that
CNRI has absolutely no moral right to it (although probably some legal
right), I'd prefer to sign it away to Guido.  Or optionally, to some
legal fiction that represents the Python community; preferably *not* the
Python Consortium, as long as CNRI is in any way connected.

Death to the lawyers!

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From moshez at math.huji.ac.il  Wed Jun  7 16:33:10 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 7 Jun 2000 17:33:10 +0300 (IDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to
 return total reference count in debug builds.)
In-Reply-To: <20000607101146.D5559@ludwig.cnri.reston.va.us>
Message-ID: <Pine.GSO.4.10.10006071731200.2293-100000@sundial>

On Wed, 7 Jun 2000, Greg Ward wrote:

> CNRI has absolutely no moral right to it (although probably some legal
> right), I'd prefer to sign it away to Guido.  Or optionally, to some
> legal fiction that represents the Python community; preferably *not* the
> Python Consortium, as long as CNRI is in any way connected.

Who's in charge of the PSA?
Or should we form *another* non-profit, and sign it over to it?
(Personally, I couldn't care less who I transfer copyright over my Python
contributions to -- I'd put it in the public domain if that's what it
took)

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From pf at artcom-gmbh.de  Wed Jun  7 16:44:30 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 16:44:30 +0200 (MEST)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us> from Greg Ward at "Jun 7, 2000  9:56:38 am"
Message-ID: <m12zh4J-000DifC@artcom0.artcom-gmbh.de>

Hi,

Greg Ward:
> But yeah, remote CVS still bites the big one.  Very painful over a 28.8k 
> modem line.  (It sucks being a cheap bastard!)

Certainly you know about 'rsync'?  Would this help here?  
Let me quote a small section from the 'rsync' man page:

"""    To synchronize my samba source trees I use  the  following
       Makefile targets:

              get:
              	rsync -avuzb --exclude ?*~? samba:samba/ .

              put:
              	rsync -Cavuzb . samba:samba/

              sync: get put

       this  allows  me to sync with a CVS directory at the other
       end of the link. I then do cvs operations  on  the  remote
       machine,  which saves a lot of time as the remote cvs pro?
       tocol isn?t very efficient.  """

I can't access CVS because of our restrictive HTTP/UUCP only firewall, 
but in our company we use 'rsync' a lot.

Regards, Peter



From bwarsaw at python.org  Wed Jun  7 17:06:42 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Wed, 7 Jun 2000 11:06:42 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <3938D60E.391AAF31@lemburg.com>
	<AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
	<20000607095638.B5559@ludwig.cnri.reston.va.us>
Message-ID: <14654.25858.564089.574043@anthem.python.org>

>>>>> "GW" == Greg Ward <gward at mems-exchange.org> writes:

    GW> I have come up with a partial solution to the inconvenience of
    GW> accessing SourceForge, specifically the need for constant
    GW> authentication.

Greg, are you aware of ssh-agent?  Same convenience, same possible
exploits, but at least they've done the hard work for ya. :)

I usually just run XEmacs under ssh-agent.  First thing you do is fire
up a shell buffer, run ssh-add to authenticate once, and from there
on, all your ssh interactions (not just with SF) yank the private key
out of the ssh-agent process and never bother you with a passphrase
prompt.

-Barry



From bwarsaw at python.org  Wed Jun  7 17:22:20 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Wed, 7 Jun 2000 11:22:20 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to
 return total reference count in debug builds.)
References: <20000607101146.D5559@ludwig.cnri.reston.va.us>
	<Pine.GSO.4.10.10006071731200.2293-100000@sundial>
Message-ID: <14654.26796.936980.875783@anthem.python.org>

>>>>> "MZ" == Moshe Zadka <moshez at math.huji.ac.il> writes:

    MZ> Who's in charge of the PSA?  Or should we form *another*
    MZ> non-profit, and sign it over to it?  (Personally, I couldn't
    MZ> care less who I transfer copyright over my Python
    MZ> contributions to -- I'd put it in the public domain if that's
    MZ> what it took)

Please remember that the copyright holder can release the code under
whatever license they want, even multiple different licenses.
Copyright != license.

I'm not sure what the right thing to do here is.  On the one hand, Bob
Kahn always said nobody would use Python if its heritage
(i.e. copyright ownership) were not nailed down like Java.  On the
other hand, there's a lot of nobodies out there right now :).

For GNU projects, the FSF wants to own all the copyrights to the code.
They actually want you to legally assign the copyright to them.  Their
explanation for this onerous requirement is that if they were not the
copyright holder, they would not have the legal standing to defend GPL
violations, or would have to coordinate with a ton of developers,
making such legal defenses practically impossible.

Python is in a different situation, IMO, because it has a /less/
restrictive license than the GPL, so there's less to get all huffy
about in court.  If someone builds a binary-only proprietary blend of
Python and starts selling it without source code, well, there's no
license violation there, so what's to defend?

The argument has been made that without clear legal title, someone
could claim that some of the donated code in Python violated a
copyright or patent and try to stop 3rd parties from using Python.
Who knows what the actual legal possibility of that happening are, but
I don't see how 1) we could take any real defense against this or 2)
it affects Python any differently than any other large
multi-contributor open source system.

-Barry



From andy at robanal.demon.co.uk  Wed Jun  7 22:48:48 2000
From: andy at robanal.demon.co.uk (Andy Robinson)
Date: Wed, 07 Jun 2000 20:48:48 GMT
Subject: [Python-Dev] Package ambiguities
Message-ID: <393eb52b.47053339@post.demon.co.uk>

We hit some very weird behaviour recently while setting up a package
hierarchy.  Robin Becker managed to distil this into a simple example.
Can anyone shed any light on what is happening below?  Is Python
behaving as it should?

Create a package A, empty __init__.py, with modules as follows:
--------parent.py----------
class Parent:
    pass

--------child.py------------
from parent import Parent
class Child(Parent):
    pass

---------test.py--------
from parent import *
class Examiner:
    def examine(self, arg):
        print 'examining argument:'
        print 'class of arg =', arg.__class__
        print 'bases of arg =', arg.__class__.__bases__
        print 'arg =', arg
        if isinstance(arg, Parent):
            print "arg is an instance of Parent"
        else:
            print "arg IS NOT an instance of Parent"
        print
        
if __name__=='__main__':
        from traceback import print_exc
        import sys
        def run0():
                from A.child import Child
                e = Examiner()
                e.examine(Child())

        def run1():
                from A.child import Child
                from A.test import Examiner
                e = Examiner()
                e.examine(Child())
        run0()
        run1()


Running this script produces the following output:

  C:\users\andy\A>test.py
  examining argument:
  class of arg = A.child.Child
  bases of arg = (<class A.parent.Parent at 7f9150>,)
  arg = <A.child.Child instance at 7f9410>
  arg IS NOT an instance of Parent

  examining argument:
  class of arg = A.child.Child
  bases of arg = (<class A.parent.Parent at 7f9150>,)
  arg = <A.child.Child instance at 7f83c0>
  arg is an instance of Parent


Many thanks,

Andy Robinson





From pingster at ilm.com  Wed Jun  7 23:05:26 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Wed, 7 Jun 2000 14:05:26 -0700 (PDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <393eb52b.47053339@post.demon.co.uk>
Message-ID: <Pine.SGI.3.96.1000607135723.428158j-100000@happy>

On Wed, 7 Jun 2000, Andy Robinson wrote:
> We hit some very weird behaviour recently while setting up a package
> hierarchy.  Robin Becker managed to distil this into a simple example.
> Can anyone shed any light on what is happening below?  Is Python
> behaving as it should?

It looks to me like you have two "parent" modules.

When you run "test.py" directly from the command line, the
first "from parent import *" imports parent.py as module "parent".
But subsequently parent.py is imported again as module "A.parent".

Similarly, you have two "Examiner" classes.  In run0() you
get Examiner from __main__, which contains the Parent class
from module "parent".  In run1() you get Examiner from A.test,
which contains the Parent class imported from module "A.parent".

If you insert

        print 'in module', __name__, 'parent is', repr(Parent)

at the beginning of the examine() method, it should make things
clear.

The solution is to avoid directly running scripts that are
inside packages; the confusion is produced by the fact that
you're running "test.py" from within the A/ directory.


-- ?!ng




From jeremy at beopen.com  Wed Jun  7 23:25:53 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 17:25:53 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
Message-ID: <14654.48609.710990.321688@localhost.localdomain>

Say a startup company decided to put some resources behind the Python
Web site -- a full-time Web master, some content developers, etc.
What would you have them do?  What could be done to open up the site
to the community and make it more responsive to developers and users?
What's your wish list for content, services, etc.?

If you've got any ideas, please get back to me soon.

Jeremy




From esr at thyrsus.com  Wed Jun  7 23:41:48 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 7 Jun 2000 17:41:48 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14654.48609.710990.321688@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 07, 2000 at 05:25:53PM -0400
References: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <20000607174148.A6801@thyrsus.com>

Jeremy Hylton <jeremy at beopen.com>:
> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?

I think it's pretty good as is -- lots of content, pretty well 
organized.  My top wishlist item is "Burn all your GIFs".
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The right of self-defense is the first law of nature: in most
governments it has been the study of rulers to confine this right
within the narrowest limits possible.  Wherever standing armies
are kept up, and when the right of the people to keep and bear
arms is, under any color or pretext whatsoever, prohibited,
liberty, if not already annihilated, is on the brink of
destruction." 
	-- Henry St. George Tucker (in Blackstone's Commentaries)



From jack at oratrix.nl  Wed Jun  7 23:47:01 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 07 Jun 2000 23:47:01 +0200
Subject: [Python-Dev] hey, who broke the array module? 
In-Reply-To: Message by Guido van Rossum <guido@python.org> ,
	     Thu, 18 May 2000 15:05:45 -0700 , <200005182205.PAA12830@cj20424-a.reston1.va.home.com> 
Message-ID: <20000607214706.65CB2D8397@oratrix.oratrix.nl>

Recently, Guido van Rossum <guido at python.org> said:
> > On Thu, May 18, 2000 at 12:01:16PM +0200, Jack Jansen wrote:
> > > > I broke it with my patches to test overflow for some of the PyArg_Parse
> *()
> > > > formatting characters. The upshot of testing for overflow is that now t
> hose
> > > > formatting characters ('b', 'h', 'i', 'l') enforce signed-ness or
> > > > unsigned-ness as appropriate (you have to know if the value is signed o
> r
> > > > unsigned to know what limits to check against for overflow). Two
> > > > possibilities presented themselves:
> > > 
> > > I think this is a _very_ bad idea. I have a few thousand (literally) rout
> ines 
> > > calling to Macintosh system calls that use "h" for 16 bit flag-word value
> s, 
> > > and the constants are all of the form
> > > 
> > > kDoSomething = 0x0001
> > > kDoSomethingElse = 0x0002
> > > ...
> > > kDoSomethingEvenMoreBrilliant = 0x8000
> > > 
> > > I'm pretty sure other operating systems have lots of calls with similar 
> > > problems. I would strongly suggest using a new format char if you want 
> > > overflow-tested integers.
> > 
> > Sigh. What do you think Guido? This is your call.
> > 
> > 1. go back to no bounds testing
> > 2. bounds check for [SHRT_MIN, USHRT_MAX] etc (this would allow signed and
> > unsigned values but is sort of false security for bounds checking)
> > 3. keep it the way it is: 'b' is unsigned and the rest are signed
> > 4. add new format characters or a modifying character for signed and unsign
> ed
> > versions of these.
> 
> Sigh indeed.  Ideally, we'd introduce H for unsigned and then lock
> Jack in a room with his Macintosh computer for 48 hours to fix all his
> code...

Hmm, hmm. As stated before I'm not too fond of this as it is a
gratuitous change that breaks lots of things (not only in Mac modules: 
the array module was what started this discussion, test_cPickle
and test_pkg crash, socketmodule, os.stat() and I assume all code that
uses structmodule will also have to be looked at, and quite possibly
there's a lot more) and for which I don't really see all that much
benefit.

As a datapoint: a quick search for 8-digit hex numbers starting with
digit 8-F and not suffixed with an L throughout the Python files in
the distribution found a stunning 464 matches. Add another 1147
4-digit hex numbers with the sign bit on and there are an awful lot of 
candidates for breaking...
--
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 gmcm at hypernet.com  Wed Jun  7 23:59:20 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 7 Jun 2000 17:59:20 -0400
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <Pine.SGI.3.96.1000607135723.428158j-100000@happy>
References: <393eb52b.47053339@post.demon.co.uk>
Message-ID: <1251707300-11412775@hypernet.com>

Ka-Ping wrote:

> On Wed, 7 Jun 2000, Andy Robinson wrote:
> > We hit some very weird behaviour recently while setting up a
> > package hierarchy.  Robin Becker managed to distil this into a
> > simple example. Can anyone shed any light on what is happening
> > below?  Is Python behaving as it should?

[snip entirely correct analysis]

> The solution is to avoid directly running scripts that are
> inside packages; the confusion is produced by the fact that
> you're running "test.py" from within the A/ directory.

I disagree with the moral.

If test.py uses "import A.parent" and changes references 
accordingly, it works.

So my version of the moral is that import * is EVIL. Not only 
that, but relative imports are EVIL.

This is what I meant when I said (in reply to Greg Wilson's 
inquiry about package structures) that there are some very 
bad precedents getting set.

Doing this junk (usually in __init__.py) not only makes your 
package fragile, it also makes the package structure 
mysterious to the user (who's a developer - making things 
mysterious to him/her is just making both your lives harder!). If 
you want to make it friendly to lazy coders, then something 
like:

import A.parent
Parent = A.parent.Parent

also works, (leaving references as Parent). I'm not terribly fond 
of this, either, but at least the coder has a reasonable hope of 
tracking down what "Parent" actually is.

I'm not necessarily yelling at you, Andy. It seems that most 
package developers are going down this slope. It stinks.


- Gordon



From jeremy at beopen.com  Thu Jun  8 00:06:29 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 18:06:29 -0400 (EDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <1251707300-11412775@hypernet.com>
References: <393eb52b.47053339@post.demon.co.uk>
	<1251707300-11412775@hypernet.com>
Message-ID: <14654.51045.18807.74677@localhost.localdomain>

Gordon's comments are on the money.  An import in a module inside a
package should be fully qualified.  I'd put that in the style guide if
it were up to me (and, of course, it's not).

Jeremy



From bwarsaw at python.org  Thu Jun  8 00:38:02 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Wed, 7 Jun 2000 18:38:02 -0400 (EDT)
Subject: [Python-Dev] Package ambiguities
References: <393eb52b.47053339@post.demon.co.uk>
	<1251707300-11412775@hypernet.com>
	<14654.51045.18807.74677@localhost.localdomain>
Message-ID: <14654.52938.139406.371556@anthem.concentric.net>

>>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:

    JH> Gordon's comments are on the money.  An import in a module
    JH> inside a package should be fully qualified.  I'd put that in
    JH> the style guide if it were up to me (and, of course, it's
    JH> not).

I concur on both points.  BTW, one of the Things I'd Like To Do, is
update and flesh out the style guide.  It's incomplete in places and
out of date in others.  If someone else has the gumption to lead this
effort, I'd be happy to send my comments instead.

-Barry



From pingster at ilm.com  Thu Jun  8 00:39:28 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Wed, 7 Jun 2000 15:39:28 -0700 (PDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <1251707300-11412775@hypernet.com>
Message-ID: <Pine.SGI.3.96.1000607150444.428158l-100000@happy>

On Wed, 7 Jun 2000, Gordon McMillan wrote:
> I disagree with the moral.
> 
> If test.py uses "import A.parent" and changes references 
> accordingly, it works.

Correct.

Well, maybe there are two things going on here.

I agree that import * isn't usually a very good idea.

However, notice that the problem occurs even if the first line
of test.py is "import parent" (no star).  When you talk about
changing references accordingly, the real issue is referencing
"A.parent" rather than "parent".

In fact, if you change the first line to "from A.parent import *"
(not that i am advocating this!) -- it works.  In short:

    from parent import *    ...  Parent             doesn't work
    import parent           ...  parent.Parent      doesn't work
    
    from A.parent import *  ...  Parent             works
    import A.parent         ...  A.parent.Parent    works

The first two cases -- attempting to import "parent" -- are
only made possible by the fact that we're executing test.py
from within the A/ directory, and hence the confusion.


This problem is an "advanced" version of a simpler issue
which a friend of mine discovered and complained about
recently to me: the __main__ vs. module-name conflict.
Allow me to paraphrase his example.

Exhibit A:

    ---- spam.py ----
    import eggs

    def go():
        print "was", eggs.a
        eggs.a = 3
        print "now", eggs.a

    ---- eggs.py ----
    import spam

    a = 1

    def go():
        spam.go()
        print "finally", a

    if __name__ == "__main__": go()

    --- watch what happens ----
    % python eggs.py
    was 1
    now 3
    finally 1

    % python
    >>> import eggs
    >>> eggs.go()
    was 1
    now 3
    finally 3


Exhibit B:

    ---- one.py ----
    import two
    def go(): pass

    ---- two.py ----
    import one
    one.go()

    ---- watch what happens ----
    % python one.py

    % python two.py
    Traceback (innermost last):
      File "two.py", line 1, in ?
        import one
      File "./one.py", line 1, in ?
        import two
      File "./two.py", line 2, in ?
        one.go()
    AttributeError: go
    Exit 1

    % python
    >>> import one
    Traceback (innermost last):
      File "<stdin>", line 1, in ?
      File "./one.py", line 1, in ?
        import two
      File "./two.py", line 2, in ?
        one.go()
    AttributeError: go
    >>> import two
    >>> 


The facts that eggs.a appears to behave differently in Exhibit A,
and that one.py can be run but two.py cannot, yet "two" can be
imported and "one" cannot, in Exhibit B, both result from the
duplication namespaces in __main__ and in a module.

Normally, this only affects the main file that you are running,
the one with the __main__ namespace.  However, attempting to run
scripts in package directories allows this problem to propagate
further into the duplication of other modules:

    __main__ imports parent which imports child
    A.test imports A.parent which imports A.child

...and that can cause duplicate classes all over the place,
which is what happened to Andy.


My friend was quite irked by the existence of __main__, citing
it as the culprit for this duplication.  But naturally Python
can't always know the name of the script being run -- in the
case of a file ending in .py, perhaps, it's easy, but the script
might come from a pipe, for example.  So eliminating __main__
doesn't seem like a feasible response.

Depending how "real" you consider this problem, leaving things
as they are and instructing people in the discipline of keeping
modules and scripts separated may be the best response.

I bet this crops up all the time in those "testing" sections
of modules that use the 'if __name__ == "__main__"' convention,
though...


-- ?!ng

"Computers are useless.  They can only give you answers."
    -- Pablo Picasso




From petrilli at amber.org  Thu Jun  8 00:51:50 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Wed, 7 Jun 2000 18:51:50 -0400
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <14654.52938.139406.371556@anthem.concentric.net>; from bwarsaw@python.org on Wed, Jun 07, 2000 at 06:38:02PM -0400
References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> <14654.52938.139406.371556@anthem.concentric.net>
Message-ID: <20000607185150.A29156@trump.amber.org>

Barry A. Warsaw [bwarsaw at python.org] wrote:
> 
> >>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:
> 
>     JH> Gordon's comments are on the money.  An import in a module
>     JH> inside a package should be fully qualified.  I'd put that in
>     JH> the style guide if it were up to me (and, of course, it's
>     JH> not).
> 
> I concur on both points.  BTW, one of the Things I'd Like To Do, is
> update and flesh out the style guide.  It's incomplete in places and
> out of date in others.  If someone else has the gumption to lead this
> effort, I'd be happy to send my comments instead.

Something we futzed with at Digital Creations was "commentable" or
discussable web pages.  This would be a great use for this.  If you
took and made each basic topic/issue a page, and let people "discuss"
them.  A nice threaded discussion could add a lot of insight.   This
is versus a wiki where it's more "free for all", which isn't really
appropraiate for a "guide".

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From pingster at ilm.com  Thu Jun  8 00:48:29 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Wed, 7 Jun 2000 15:48:29 -0700 (PDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <20000607185150.A29156@trump.amber.org>
Message-ID: <Pine.SGI.3.96.1000607154751.428158n-100000@happy>

On Wed, 7 Jun 2000, Christopher Petrilli wrote:
> Something we futzed with at Digital Creations was "commentable" or
> discussable web pages.  This would be a great use for this.  If you
> took and made each basic topic/issue a page, and let people "discuss"
> them.  A nice threaded discussion could add a lot of insight.   This
> is versus a wiki where it's more "free for all", which isn't really
> appropraiate for a "guide".

Well, y'all could go nuts marking up the style guide with Crit.

    http://crit.org/


...or marking up anything else on the whole Web, for that matter. :)



-- ?!ng

"To be human is to continually change.  Your desire to remain what
you are is what ultimately limits you."
    -- The Puppet Master, Ghost in the Shell




From jeremy at beopen.com  Thu Jun  8 01:00:36 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 19:00:36 -0400 (EDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <Pine.SGI.3.96.1000607150444.428158l-100000@happy>
References: <1251707300-11412775@hypernet.com>
	<Pine.SGI.3.96.1000607150444.428158l-100000@happy>
Message-ID: <14654.54292.711289.254224@localhost.localdomain>

>In fact, if you change the first line to "from A.parent import *"
>(not that i am advocating this!) -- it works.  In short:
>
>    from parent import *    ...  Parent             doesn't work
>    import parent           ...  parent.Parent      doesn't work
>    
>    from A.parent import *  ...  Parent             works
>    import A.parent         ...  A.parent.Parent    works

One other possibility that ought to work (?)

    from A import parent

Jeremy



From gmcm at hypernet.com  Thu Jun  8 01:47:47 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 7 Jun 2000 19:47:47 -0400
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <Pine.SGI.3.96.1000607150444.428158l-100000@happy>
References: <1251707300-11412775@hypernet.com>
Message-ID: <1251700795-11803988@hypernet.com>

Ka-Ping wrote:

> ... In short:
> 
>     from parent import *    ...  Parent             doesn't work
>     import parent           ...  parent.Parent      doesn't work
> 
>     from A.parent import *  ...  Parent             works
>     import A.parent         ...  A.parent.Parent    works

Right. That's why I cast relative imports as evil.

> This problem is an "advanced" version of a simpler issue
> which a friend of mine discovered and complained about
> recently to me: the __main__ vs. module-name conflict.

This comes up a whole lot. In those periods where I have the 
time, energy and patience to monitor c.l.py closely, I've seen 
this come up 4 or 5 times in one week. Almost always in 
conjunction with import *.

I can live with explaining how __main__ is special. That's one 
of those "you only have to explain it once" problems.

But the import * problems (name hiding, the fact that 
assignments aren't seen) and relative imports are things that 
come up over and over again, and trip up even experienced 
people (and them more than once).



- Gordon



From gstein at lyra.org  Thu Jun  8 04:30:14 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 19:30:14 -0700
Subject: [Python-Dev] Idea: emulating _locale
In-Reply-To: <393E2304.4BE8CDE0@lemburg.com>; from mal@lemburg.com on Wed, Jun 07, 2000 at 12:25:08PM +0200
References: <m12zcE0-000DifC@artcom0.artcom-gmbh.de> <393E2304.4BE8CDE0@lemburg.com>
Message-ID: <20000607193014.P3348@lyra.org>

On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote:
>...
> Peter Funk wrote:
>...
> > > + ### C lib locale APIs
> > > +
> > > + from _locale import *
> > 
> > Wouldn't it be clever to provide some dummy stubs on those platforms, where
> > the _locale module was not enabled?
> > 
> > try:
> >     from _locale import *
> > except:
> >     def setlocale(....
> >     def localeconv(....
> >     ...
> > 
> > Especially the MacOS 1.5.2 release provided by Jack Jansen was
> > compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
> > is still disabled per default in 'Modules/Setup.in'.  I didn't had
> > a look into the current CVS though, so this may have changed.
> > 
> > I think the name aliasing tables might be also useful on those
> > systems lacking locale support in their C-library.
> 
> setlocale and localeconv are ANSI C and Python requires an ANSI C
> compiler, so there should be no problem (at least in theory).
> 
> If there is a problem, adding the missing symbols would
> be no problem: the APIs could always report locale 'C'
> and its numeric settings.

An ANSI C compiler and the ANSI C library are very different. Just because
Python requires an ANSI compiler (or close to it), does NOT mean that we can
or should depend upon particular elements in the library.

IMO, we should follow Peter's advice and have stubs for the platforms where
_locale is not built.

Cheers,
-g

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



From gstein at lyra.org  Thu Jun  8 04:35:37 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 19:35:37 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.21,2.22
In-Reply-To: <200006070913.CAA18060@slayer.i.sourceforge.net>; from lemburg@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 02:13:24AM -0700
References: <200006070913.CAA18060@slayer.i.sourceforge.net>
Message-ID: <20000607193537.Q3348@lyra.org>

On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote:
> Update of /cvsroot/python/python/dist/src/Objects
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects
> 
> Modified Files:
> 	unicodeobject.c 
> Log Message:
> Marc-Andre Lemburg <mal at lemburg.com>:
> Change the default encoding to 'ascii' (it was previously
> defined as UTF-8).
> 
> Note: The implementation still uses UTF-8 to implement
> the buffer protocol, so C APIs will still see UTF-8. This
> is on purpose: rather than fixing the Unicode implementation,
> the C APIs should be made Unicode aware.

I'm a little confused on where this gets applied. Is this when somebody says
"str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when
somebody says "unicode(str)" and we expect <str> to be ASCII?

Cheers,
-g

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



From gstein at lyra.org  Thu Jun  8 05:06:24 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 20:06:24 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26
In-Reply-To: <200006080008.RAA15980@slayer.i.sourceforge.net>; from gward@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 05:08:17PM -0700
References: <200006080008.RAA15980@slayer.i.sourceforge.net>
Message-ID: <20000607200624.R3348@lyra.org>

On Wed, Jun 07, 2000 at 05:08:17PM -0700, Greg Ward wrote:
> Update of /cvsroot/python/distutils/distutils/command
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv15881
> 
> Modified Files:
> 	sdist.py 
> Log Message:
> Made all debug output go through the 'debug_print()' method instead of
> directly printing to stdout.  This was a bit more work than it sounds like
> it should have been:
>   * turned 'select_pattern()' and 'exclude_pattern()' from functions into
>     methods, so they can refer to 'self' to access the method

You wouldn't have to do this if you make debug_print() a function. There is
nothing in debug_print() that requires "self", so its existence as a method
is suspect in the first place. Considering the fallout changes, I'd say move
debug_print() to a plain function (in "utils").

Unless you were planning on more stuff in there; if so, then a comment in
debug_print would be nice.

>...
> ***************
> *** 297,301 ****
>               if (cur_dir == dir and
>                   (pattern_re is None or pattern_re.match (cur_base))):
> !                 print "removing %s" % self.files[i]
>                   del self.files[i]
>   
> --- 298,302 ----
>               if (cur_dir == dir and
>                   (pattern_re is None or pattern_re.match (cur_base))):
> !                 self.debug_print("removing %s" % self.files[i])
>                   del self.files[i]

Gah... "pattern_re.match (cur_base)" ...

You do realize that God intended there to be no spaces between a function
name and the opening paren? Heretic!

:-)

Really -- I have noticed this throughout a lot of the distutils code. That
space in there is really awful. It reduces the "binding" of the name to the
paren, which changes the meaning during a quick read. Put another way: when
you skim code, NAME( is a function call and NAME ( is something else. A
space after a name usually indicates the name is participating in an
expression, rather than being used as a function name. Then, you hit the
paren and go "what the heck? <pause> oh. a function call."

Please... can they be removed?

Cheers,
-g

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



From gstein at lyra.org  Thu Jun  8 06:05:55 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 21:05:55 -0700
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.)
In-Reply-To: <Pine.GSO.4.10.10006071731200.2293-100000@sundial>; from moshez@math.huji.ac.il on Wed, Jun 07, 2000 at 05:33:10PM +0300
References: <20000607101146.D5559@ludwig.cnri.reston.va.us> <Pine.GSO.4.10.10006071731200.2293-100000@sundial>
Message-ID: <20000607210555.X3348@lyra.org>

On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote:
> On Wed, 7 Jun 2000, Greg Ward wrote:
> 
> > CNRI has absolutely no moral right to it (although probably some legal
> > right), I'd prefer to sign it away to Guido.  Or optionally, to some
> > legal fiction that represents the Python community; preferably *not* the
> > Python Consortium, as long as CNRI is in any way connected.
> 
> Who's in charge of the PSA?

CNRI

Effectively, the PSA is a legal fiction for collecting donations to further
the development of Python. The Consortium is similar, but members have the
actual/explicit capability to steer Python's development. I believe this
ability to steer the development is (was?) rooted in the fact that CNRI
employed Guido. I have no idea how that will work now -- the "steering" will
(essentially) have to rely entirely on Guido's good graces. Guido is an
excellent listener to people's needs, so there is no immediate problem here.

> Or should we form *another* non-profit, and sign it over to it?

The Apache Software Foundation is already a legal, formed, non-profit
corporation. If the desire is to transfer copyright to a non-profit, then
I'd recommend reusing the ASF rather than trying to start a new one.
Recognize that running a company (even a non-profit) is not a "zero cost"
item. Somebody would have to put that time in.

CNRI is also non-profit, but its members/board/directors/etc are not as Open
Source minded as the ASF.

> (Personally, I couldn't care less who I transfer copyright over my Python
> contributions to -- I'd put it in the public domain if that's what it
> took)

As Barry said: license and copyright are different. Since you own the
copyright, then you *can* put it into the public domain Right Now. I've done
that with some of my modules (e.g. qp_xml and imputil).

Here is the header from qp_xml.py:

#
# qp_xml: Quick Parsing for XML
#
# Written by Greg Stein. Public Domain.
# No Copyright, no Rights Reserved, and no Warranties.
#

Fun, huh? :-)

On the other hand, I have given Guido two pieces of code: httplib.py and
davlib.py:

#
# DAV client library
#
# Copyright (C) 1998-1999 Guido van Rossum. All Rights Reserved.
# Written by Greg Stein. Given to Guido. Licensed using the Python license.
#

Oh. I need to update his copyright year :-)

Want to know something really funny? Presuming my httplib.py goes into the
Python distribution, that will be the first piece of code that Guido truly
owns in Python. All the other code he wrote is owned by CWI or CNRI....

Cheers,
-g

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



From fredrik at pythonware.com  Thu Jun  8 10:30:39 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 8 Jun 2000 10:30:39 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26
References: <200006080008.RAA15980@slayer.i.sourceforge.net> <20000607200624.R3348@lyra.org>
Message-ID: <009501bfd123$d4b2c750$0500a8c0@secret.pythonware.com>

greg wrote:
> Gah... "pattern_re.match (cur_base)" ...
> 
> You do realize that God intended there to be no spaces between a function
> name and the opening paren? Heretic!

http://www.python.org/doc/essays/styleguide.html

    ...
    I hate whitespace in the following places: 
    ...
    Immediately before the open parenthesis that starts the argument
    list of a function call, as in spam (1). Always write this as spam(1).
    ...
    Don't bother to argue with me on any of the above
    ...

</F>




From andy at robanal.demon.co.uk  Thu Jun  8 10:42:46 2000
From: andy at robanal.demon.co.uk (Andy Robinson)
Date: Thu, 8 Jun 2000 09:42:46 +0100
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <20000608030555.532221CDEF@dinsdale.python.org>
Message-ID: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk>

Thanks for all the replies.  We really need a 'style guide'
on package use, so I hope this example can be thrashed
out and used to help others.  We need to decide something
and release next week, and also provide good docs for
other users who will be new to Python.

Apart from the ambiguity, which was a surprise but which 
we can work around, I have some general questions on the
"right thing".  Here are my examples:

1. use of __init__ to save users work
------------------------------------ 
ReportLab has a subpackage called 'platypus' which we have
just reorganized and not yet released.  The division
into subpackages is clear - each exposes a different
kind of functionality - but the division of each
package into modules is based on keeping a sane 
length for each and not on providing a friendly
user interface.

reportlab
    pdfgen
        canvas.py  defines class Canvas
        textobject.py defines class TextObject
        pathobject.py defines class PathObject
    platypus
        (the same problem, but 3x worse)
    lib
        (loads of modules, all independent)

We reached a point where users need to import eight or 
ten classes to do useful work and were having to put eight 
or ten different import lines at the top of every script.  
This just feels dumb and wrong.

So, the 'least messy' idea was to put __init__.py
methods in each subpackage which explicitly import
what they need.  (We have not used "import *")

---reportlab/pdfgen/__init__.py--------
from canvas import Canvas
from textobject.py import TextObject
from pathobject.py impory PathObject

Then users can just do:
from reportlab.pdfgen import Canvas, PathObject, TextObject

It seems that this (a) makes life easier for users, and
(b) gives us freedom to refactor code as it grows, without
changing the user interface.  

Is this style evil?  If so, why? 


2. Ambiguities running scripts within package
---------------------------------------------
We have various test functions scattered 
throughout our distribution.  A control script iterates
through the lot and kicks them off before every release,
executing everything with an 'if __name__=='__main__'
handler.  If these were standalone scripts just for 
testing, they could import "reportlab.platypus.tables"
or whatever.  But if I just want to put a test
routine at the end of "reportlab.platypus.tables"
then I seem destined to run into exactly the ambiguity
outlined before.  

Should test scripts all be moved out of the package?  
Indeed, is Python behaving the way it ought to?

3. Preferred subpackage import technique
----------------------------------------
I have two scripts 'spam.py' and 'eggs.py' in
subpackage 'A.B'.  spam imports eggs.
Should it say...
   import eggs
or...
   import A.B.eggs?

Both work sometimes, but can lead to different
behavious sometimes.  Which is the preferred style?

Thanks,

Andy Robinson




From pf at artcom-gmbh.de  Thu Jun  8 11:35:14 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Thu, 8 Jun 2000 11:35:14 +0200 (MEST)
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk> from Andy Robinson at "Jun 8, 2000  9:42:46 am"
Message-ID: <m12zyiZ-000DieC@artcom0.artcom-gmbh.de>

Hi Andy,  

> Thanks for all the replies.  
> We really need a 'style guide' on package use, 

On 'import', packages and modules:
----------------------------------
You should definitely have a look at the approach used by Greg
McFarlane in his 'Pmw' package.  In particular at his PmwLoader class
and the Pmw.def.  For my own project I've simplified and somewhat
generalized his approach to dynamic and lazy importing.  I posted a
preliminary implemantation of this to comp.lang.python a while ago
but didn't got much feedback.  May be due to fact, that I had to repost
the thing, because the TABs went wrong in the first try :-(

[...]
> Is this style evil?  If so, why? 

I believe it will get really hard to come up with a 'namespace style guide' 
which everybody can aggree on.  But who cares: let's start a rant:

-->  IMO 'from ... import ...' is EVIL and its use should be banned!  <--

Why?  Because if software becomes bigger (> 100k LOC), these
unqualified names definitely become a maintaince nightmare, since you
didn't know what names are defined in the module you are currently
staring at and what names come from the "outside world".

I believe Python inherited two of its three forms of import syntax at 
least in part from its anchestors Modula-2 and Modula-3.  

My perception of this import-problem may be blurred by programming in
Modula-2 in our company since 1985, where the code base now is about ~1
Mio. LOC.  Some of the older code contains still modules using a lot of
'FROM foobar IMPORT ....;' lines in the header.  These have usually
been harder to read and understand by new employees than those having
'IMPORT foobar;' in the header and than using 'foobar.component'
everywhere in the code body below.

from .... import * is *EVEN MORE EVIL*.

Well: at least if people use 'from' to import arbitrary objects and
classes.  Using 'from package.subpackage import module' is an idiom,
with which I can live with comfortably.

> Should test scripts all be moved out of the package?  

This would defeat the use of Tim Peters wonderful 'doctest' module.
I'm still thinking, 'doctest' should be made part of the standard
library in order to give the publicity this elegant approach deserves.

Regards, Peter



From Vladimir.Marangozov at inrialpes.fr  Thu Jun  8 12:27:10 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Thu, 8 Jun 2000 12:27:10 +0200 (CEST)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <20000607174148.A6801@thyrsus.com> from "Eric S. Raymond" at Jun 07, 2000 05:41:48 PM
Message-ID: <200006081027.MAA02445@python.inrialpes.fr>

[Jeremy Hylton]
>
> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?

The content is good. Some wishes on its presentation, not taking into
account any cosmetic changes.

With my webmaster's hat, I would say:

1. Make the content accessible, i.e. compliant to the standards
   HTML tidy does a pretty good job in cleaning up existing Web pages
   I would suggest sticking with valid XHTML 1.0 transitional or HTML 4.x
   transitional.

2. Use CSS -- not too much, though, given its growing but still limited
   support. I am using myself parts of CSS1. My approach is to use styles
   *and* attributes (which is redundant, for now). Browsers that understand
   styles would honor them, while those that don't would take into account
   the attributes. The aim is to have the same end result. With the evolution
   of the browsers, the attributes would disappear.

   A compromise that introduces styles smoothly.

3. Have a comprehensible site map for direct access to the major topics.
   I tend to like ours which is convenient for small to medium sized sites
   (http://www.inrialpes.fr/plansite.html)

4. Do not use frames, do not use JavaScript or similar, do not use anything
   that hurts content accessibility.

[Eric S. Raymond]
> 
>  My top wishlist item is "Burn all your GIFs".

This seems to be an important symbol for an organization with an Open Source
spirit.  Hopefully, a gif2png batch processing should make things easier.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From gstein at lyra.org  Thu Jun  8 13:43:24 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 8 Jun 2000 04:43:24 -0700
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <m12zyiZ-000DieC@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Thu, Jun 08, 2000 at 11:35:14AM +0200
References: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk> <m12zyiZ-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <20000608044324.L3348@lyra.org>

On Thu, Jun 08, 2000 at 11:35:14AM +0200, Peter Funk wrote:
>...
> > Is this style evil?  If so, why? 
> 
> I believe it will get really hard to come up with a 'namespace style guide' 
> which everybody can aggree on.  But who cares: let's start a rant:
> 
> -->  IMO 'from ... import ...' is EVIL and its use should be banned!  <--

You are being overly strict here. I use this all the time:

from module import submodule
...
submodule.Class()

or even

from module.submodule import subsub
...
subsub.Blargle()

In other words, "from package import module" is a Fine Thing. It can
simplify your code without hiding where the symbols come from.

In general, I agree with you: importing symbols from a module into your
namespace is a Bad Thing.

Cheers,
-g

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



From fdrake at beopen.com  Thu Jun  8 14:37:04 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 8 Jun 2000 08:37:04 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <200006081027.MAA02445@python.inrialpes.fr>
References: <20000607174148.A6801@thyrsus.com>
	<200006081027.MAA02445@python.inrialpes.fr>
Message-ID: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>

Vladimir Marangozov writes:
 > 2. Use CSS -- not too much, though, given its growing but still limited
 >    support. I am using myself parts of CSS1. My approach is to use styles
 >    *and* attributes (which is redundant, for now). Browsers that understand
 >    styles would honor them, while those that don't would take into account
 >    the attributes. The aim is to have the same end result. With the evolution
 >    of the browsers, the attributes would disappear.

  The approach to CSS I've taken with the documentation is to use
attributes for anything that's really needed to make the presentation
readable and then an external CSS stylesheet for everything else.
This seems like a reasonable approach to me, and avoids including too
much duplicate information.  This also seems like the best way to
maintain support for older browsers.
  Perhaps we should collect browser statistics on python.org so we'll
know how many "legacy" browsers are in use?  I would be surprised if
many of the text-mode browsers support CSS well (and there are several
being actively worked on these days, so please don't tell me they
don't count!).

 > 4. Do not use frames, do not use JavaScript or similar, do not use anything
 >    that hurts content accessibility.

  I do have some JavaScript on python.org, but it's only to make data
entry in a form a little easier by making adjustments to related
fields, so it remains completely operational without JavaScript.  I
don't think there's currently any required JavaScript.  And I have yet
to see a frame, thank goodness!

[Eric S. Raymond]
 > 
 >  My top wishlist item is "Burn all your GIFs".

  Is it more important than accessibility?  This is a real issue for
legacy browsers, especially on minority platforms.  One of the big
wins for Python is that it is as portable as it is.  Does that matter
if information is hard to get to?
  A good reason to avoid using images for anything that isn't
cosmetic!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From pf at artcom-gmbh.de  Thu Jun  8 14:28:11 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Thu, 8 Jun 2000 14:28:11 +0200 (MEST)
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <20000608044324.L3348@lyra.org> from Greg Stein at "Jun 8, 2000  4:43:24 am"
Message-ID: <m1301Pv-000DieC@artcom0.artcom-gmbh.de>

Hi Greg,

[me]
> > -->  IMO 'from ... import ...' is EVIL and its use should be banned!  <--

[Greg Stein]:
> You are being overly strict here. I use this all the time:
> 
> from module import submodule
> ...
> submodule.Class()
> 
> or even
> 
> from module.submodule import subsub
> ...
> subsub.Blargle()

Okay.  Later in my rant I wrote:

< Well: at least if people use 'from' to import arbitrary objects and
< classes.  Using 'from package.subpackage import module' is an idiom,
< with which I can live with comfortably.

[Greg Stein]:
> In other words, "from package import module" is a Fine Thing. It can
> simplify your code without hiding where the symbols come from.

Yes, you are right.

But if you put the facade pattern[*] into use within such packages,
this will even simplify your live, if you later have to redesign
the internal substructure of your package.

[*] Design patterns and especially the "facade pattern" were AFAIK 
    introduced in the so called "Gang of four" book: "Design Patterns -
    Elements of Reusable Object-Oriented Software", Addison Wesley, 1995.

    The somewhat similar "whole part" design pattern is discussed 
    in the book "A System of Patterns" written by Buschmann, Meunier, 
    Rohnert, Sommerlad, Stal; published by John Wiley & Sons, New York; 1996; 
    ISBN 0 471 95869 7

> In general, I agree with you: importing symbols from a module into your
> namespace is a Bad Thing.

Fine.  Consensus gives a warm and fuzzy feeling. ;-)

Regards, Peter



From esr at thyrsus.com  Thu Jun  8 14:53:51 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 8 Jun 2000 08:53:51 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 08, 2000 at 08:37:04AM -0400
References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>
Message-ID: <20000608085351.A9299@thyrsus.com>

Fred L. Drake, Jr. <fdrake at beopen.com>:
> [Eric S. Raymond]
>  > 
>  >  My top wishlist item is "Burn all your GIFs".
> 
>   Is it more important than accessibility?  This is a real issue for
> legacy browsers, especially on minority platforms.  One of the big
> wins for Python is that it is as portable as it is.  Does that matter
> if information is hard to get to?

Go check out the PNG site's census of PNG support in "legacy"
browsers. Basically, as long as your PNGs don't use transparency or
animation, you're fine.  You've already had the good taste to eschew
animation. I don't think you're using transparency anywhere that 
simply matteing the image on a white background won't fix it -- and
gif2png has an option to do that.

>   A good reason to avoid using images for anything that isn't
> cosmetic!

I agree with that.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Sometimes the law defends plunder and participates in it. Sometimes
the law places the whole apparatus of judges, police, prisons and
gendarmes at the service of the plunderers, and treats the victim --
when he defends himself -- as a criminal.
	-- Frederic Bastiat, "The Law"



From jeremy at beopen.com  Thu Jun  8 15:58:42 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 8 Jun 2000 09:58:42 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.)
In-Reply-To: <20000607210555.X3348@lyra.org>
References: <20000607101146.D5559@ludwig.cnri.reston.va.us>
	<Pine.GSO.4.10.10006071731200.2293-100000@sundial>
	<20000607210555.X3348@lyra.org>
Message-ID: <14655.42642.608768.433695@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

  GS> On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote:
  >> On Wed, 7 Jun 2000, Greg Ward wrote:
  >> 
  >> > CNRI has absolutely no moral right to it (although probably
  >> some legal > right), I'd prefer to sign it away to Guido.  Or
  >> optionally, to some > legal fiction that represents the Python
  >> community; preferably *not* the > Python Consortium, as long as
  >> CNRI is in any way connected.
  >> 
  >> Who's in charge of the PSA?

  GS> CNRI

  GS> Effectively, the PSA is a legal fiction for collecting donations
  GS> to further the development of Python. The Consortium is similar,
  GS> but members have the actual/explicit capability to steer
  GS> Python's development. I believe this ability to steer the
  GS> development is (was?) rooted in the fact that CNRI employed
  GS> Guido. I have no idea how that will work now -- the "steering"
  GS> will (essentially) have to rely entirely on Guido's good
  GS> graces. Guido is an excellent listener to people's needs, so
  GS> there is no immediate problem here.

The description of the PSA isn't exactly right.  The PSA FAQ has an
official explanation, which may not be right either, but at least it's
what CNRI wants you to think.  (And it may be right; I don't mean to
suggest a nefarious plot, just that the relationship is convoluted
enough that the explanation could be wrong.)

http://www.python.org/psa/FAQ.html

An abbreviated version follows:

|Where does the money from membership fees go and who pays the rest?
|
|    The money goes towards the salary of those who maintain and
|    coordinate the Python web site, ftp server, mailing lists,
|    conference expenses etc....  The case for these expenditures is
|    that a seed community is being incubated. CNRI officers and
|    directors see proof of the existence of such a community from the
|    fact that some members of that community are willing to pay some
|    of their own money to foster the activity.
|
|Who funds Python's development?
|    PSA fees do not fund the Python development effort....


CNRI is no longer maintaining python.org, although it still owns the
domain and maintains the equipment it runs on.  The existence of a
community should be obvious now, without the need for people to pay
money to prove it.

Jeremy

    



From skip at mojam.com  Thu Jun  8 16:08:13 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 8 Jun 2000 09:08:13 -0500
Subject: [Python-Dev] impact of cycle gc...
Message-ID: <200006081408.JAA03136@beluga.mojam.com>

I spent a little time poking around with a very simple test script
(appended) that makes use of Neil's cycle gc patch.  It measures the time it
takes to instantiate and delete a cycle-producing instance 100,000 times
(based upon a report in python-bugs).  For vanilla 1.6a2 ("./configure" ;
make") I got the following (last of six runs):

    memory usage @ start: 5560
    clock: 1.33 elapsed: 1.34805500507
    memory usage @ end: 18816

For 1.6a2 configured --with-cycle-gc ("./configure --with-cycle-gc ; make")
I got the following (also the last of six runs):

    memory usage @ start: 5576
    clock: 2.34 elapsed: 2.33785700798
    memory usage @ end: 5576

I was very impressed with the memory usage, but dismayed at the increased
execution time (about 75% more).  Of course, this is a test script that is
bound to show the potential performance penalty in the worst possible light.
Maybe pystone will be more indicative of the performance hit we can expect
from it.  (There's a new one - pystone.py being a better indicator of true
system performance than some other test script!)

Plain:

    Pystone(1.1) time for 10000 passes = 1.76
    This machine benchmarks at 5681.82 pystones/second

--with-cycle-gc:

    Pystone(1.1) time for 10000 passes = 1.83
    This machine benchmarks at 5464.48 pystones/second

That suggests something more like a 4% performance penalty.  I suspect that
may be the lower limit.  While I haven't looked at pystone recently, I doubt
it creates any cyclic garbage.

My next step will be to try it out on my development database server and see 
what happens.

just-another-data-point-ly y'rs,

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
"We have become ... the stewards of life's continuity on earth.  We did not
ask for this role...  We may not be suited to it, but here we are."
- Stephen Jay Gould



class fred:
    def __init__(self):
        self.indirectFunc = self.theFunc

    def theFunc(self):
        return "blah"

def test():
    f = fred()
    del f


if __name__ == "__main__":
    import os, time, sys
    sys.stdout.write("memory usage @ start: ")
    sys.stdout.flush()
    os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'")
    t = time.clock(), time.time()
    for x in xrange(100000):
        test()
    print "clock:", time.clock()-t[0], "elapsed:", time.time()-t[1]
    sys.stdout.write("memory usage @ end: ")
    sys.stdout.flush()
    os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'")



From gmcm at hypernet.com  Thu Jun  8 16:48:01 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 8 Jun 2000 10:48:01 -0400
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk>
References: <20000608030555.532221CDEF@dinsdale.python.org>
Message-ID: <1251646781-15052905@hypernet.com>

Andy wrote:

> 1. use of __init__ to save users work
[package structure]
> reportlab
>     pdfgen
>         canvas.py  defines class Canvas
>         textobject.py defines class TextObject
>         pathobject.py defines class PathObject
>     platypus
>         (the same problem, but 3x worse)
>     lib
>         (loads of modules, all independent)

> ---reportlab/pdfgen/__init__.py--------
> from canvas import Canvas
> from textobject.py import TextObject
> from pathobject.py impory PathObject

I would suggest that these not use relative names. 

from reportlab.pdfgen.canvas import Canvas

will ensure that Canvas is only found in one way (no matter 
where the script is, or rather, what sys.path[0] evaluates to at 
import time).

Your other choice is to disallow any scripts within reportlab/ 
and deliver 220 V shocks to any user who starts Python 
anyplace within reportlab/ (or otherwise lets any part of 
sys.path evaluate to anything within reportlab/).
 
> Then users can just do:
> from reportlab.pdfgen import Canvas, PathObject, TextObject
> 
> It seems that this (a) makes life easier for users, and
> (b) gives us freedom to refactor code as it grows, without
> changing the user interface.  

Since you're doing this for "convenience", another option is to 
provide convenience methods:

def newCanvas():
  return reportlab.pdfgen.canvas.Canvas()

> 2. Ambiguities running scripts within package
> ---------------------------------------------

> Should test scripts all be moved out of the package?  
> Indeed, is Python behaving the way it ought to?

If you use relative imports, yes. But even so, you incur a risk 
in using relative imports (see above). And you only do it from 
laziness. So I say don't use relative imports.

> 3. Preferred subpackage import technique
> ----------------------------------------
> I have two scripts 'spam.py' and 'eggs.py' in
> subpackage 'A.B'.  spam imports eggs.
> Should it say...
>    import eggs
> or...
>    import A.B.eggs?

You know what I'm going to say...

- Gordon



From mal at lemburg.com  Thu Jun  8 16:48:49 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 16:48:49 +0200
Subject: [Python-Dev] revamped Python web site
References: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <393FB251.6100175B@lemburg.com>

Jeremy Hylton wrote:
> 
> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?
> 
> If you've got any ideas, please get back to me soon.

Why not turn python.org into a Python portal site with all the
jazz that goes with it, e.g. newsletters, browsable news
forums for different news aspects (business news, new developments,
press references, Python related meetings, etc.), customization
of the information layout, email notification when things
change, chat forums, a Python knowledge base, etc. etc.

The reasoning is that Python is starting to go business and
the site should reflect this move. As more
companies start producing Python tools, I think it might
even be worthwhile considering Python related marketing
on the Python site, e.g. small banners, external links, etc.
This would help finance the site and its administrators.

As far as content goes, I think Python.org is hardly beatable :-)
What's missing is some more service to push its fun factor
which in return pushes Python's acceptance.

Anyway, just a thought...
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From mal at lemburg.com  Thu Jun  8 16:54:01 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 16:54:01 +0200
Subject: [Python-Dev] Package ambiguities
References: <393eb52b.47053339@post.demon.co.uk>
		<1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain>
Message-ID: <393FB389.893D20E3@lemburg.com>

Jeremy Hylton wrote:
> 
> Gordon's comments are on the money.  An import in a module inside a
> package should be fully qualified.  I'd put that in the style guide if
> it were up to me (and, of course, it's not).

+1 from here :-)

I usually write things like this:

from mx.DateTime import now
print 'The time is', now()

If you don't do so, you'll run into strange problems, the most
subtle one I've encountered is with pickled objects... if unpickled
inside the same package they can cause the same module to
be loaded *twice* with all the consequences attached to this 
(e.g. issubclass() no longer works).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From mal at lemburg.com  Thu Jun  8 17:20:23 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 17:20:23 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects 
 unicodeobject.c,2.21,2.22
References: <200006070913.CAA18060@slayer.i.sourceforge.net> <20000607193537.Q3348@lyra.org>
Message-ID: <393FB9B7.B93A7C61@lemburg.com>

Greg Stein wrote:
> 
> On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote:
> > Update of /cvsroot/python/python/dist/src/Objects
> > In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects
> >
> > Modified Files:
> >       unicodeobject.c
> > Log Message:
> > Marc-Andre Lemburg <mal at lemburg.com>:
> > Change the default encoding to 'ascii' (it was previously
> > defined as UTF-8).
> >
> > Note: The implementation still uses UTF-8 to implement
> > the buffer protocol, so C APIs will still see UTF-8. This
> > is on purpose: rather than fixing the Unicode implementation,
> > the C APIs should be made Unicode aware.
> 
> I'm a little confused on where this gets applied. Is this when somebody says
> "str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when
> somebody says "unicode(str)" and we expect <str> to be ASCII?

The buffer protocol is used for "s", "t" and "s#" argument
parsing in C. Since these pass back pointers to internal
buffers of the object which must be kept alive until the
object is GCed, there's no easy way to change the
encoding of that buffer. 

To play safe I left that buffer
encoded in UTF-8 (the hash value is also computed from the
UTF-8 encoding of the unicode value to make it compatible to
ASCII 8-bit strings).

Note that both str(unicode) and unicode(str) will use
the default encoding. %-formatting and comparisons also
use the default encoding.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From mal at lemburg.com  Thu Jun  8 17:08:45 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 17:08:45 +0200
Subject: [Python-Dev] Idea: emulating _locale
References: <m12zcE0-000DifC@artcom0.artcom-gmbh.de> <393E2304.4BE8CDE0@lemburg.com> <20000607193014.P3348@lyra.org>
Message-ID: <393FB6FD.AB0124E2@lemburg.com>

Greg Stein wrote:
> 
> On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote:
> >...
> > Peter Funk wrote:
> >...
> > > > + ### C lib locale APIs
> > > > +
> > > > + from _locale import *
> > >
> > > Wouldn't it be clever to provide some dummy stubs on those platforms, where
> > > the _locale module was not enabled?
> > >
> > > try:
> > >     from _locale import *
> > > except:
> > >     def setlocale(....
> > >     def localeconv(....
> > >     ...
> > >
> > > Especially the MacOS 1.5.2 release provided by Jack Jansen was
> > > compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
> > > is still disabled per default in 'Modules/Setup.in'.  I didn't had
> > > a look into the current CVS though, so this may have changed.
> > >
> > > I think the name aliasing tables might be also useful on those
> > > systems lacking locale support in their C-library.
> >
> > setlocale and localeconv are ANSI C and Python requires an ANSI C
> > compiler, so there should be no problem (at least in theory).
> >
> > If there is a problem, adding the missing symbols would
> > be no problem: the APIs could always report locale 'C'
> > and its numeric settings.
> 
> An ANSI C compiler and the ANSI C library are very different. Just because
> Python requires an ANSI compiler (or close to it), does NOT mean that we can
> or should depend upon particular elements in the library.

Well, ok, it's POSIX.1 too, but...
 
> IMO, we should follow Peter's advice and have stubs for the platforms where
> _locale is not built.

...ok, since it doesn't hurt, I'll add some dummies to locale.py
which return the same thing as the 'C' locale.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From pingster at ilm.com  Thu Jun  8 19:10:46 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 8 Jun 2000 10:10:46 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26
In-Reply-To: <20000607200624.R3348@lyra.org>
Message-ID: <Pine.SGI.3.96.1000608100602.428158D-100000@happy>

On Wed, 7 Jun 2000, Greg Stein wrote:
> Gah... "pattern_re.match (cur_base)" ...
> 
> You do realize that God intended there to be no spaces between a function
> name and the opening paren? Heretic!
[...]
> Put another way: when
> you skim code, NAME( is a function call and NAME ( is something else. A
> space after a name usually indicates the name is participating in an
> expression, rather than being used as a function name.

Yesyesyes!

This is an absolute rule for me (in other languages too: in C, for
example, *always* a space between "if" or "for" and the open-paren).

I colourize based on this.  It's great -- the one green word on the
line stands out; it's the verb, and that lets me know what's going
on at a quick glance.

(My "Principle of Syntax Highlighting" is to highlight not by what
things are, but by what *role* they play.  Defining occurrence of
anything is a biggie.  Comments and docstrings are coloured alike;
docstrings are not data.  And so on.)


-- ?!ng




From klm at digicool.com  Thu Jun  8 20:38:32 2000
From: klm at digicool.com (Ken Manheimer)
Date: Thu, 8 Jun 2000 14:38:32 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com>

On Wed, 7 Jun 2000, Jeremy Hylton wrote:

> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?
> 
> If you've got any ideas, please get back to me soon.

Here's some suggestions - i put things more important to me closer to the
top, more or less.

1. Delegation of sections to individuals or groups.  Eg:

  - topic guides - particular people get management of areas.  (Of
    course, i'd do this with zope, including zwiki pages as well as
    regular zope documents for the respective topic-guide managers
    to use in constructing their content - and for delegating or openning
    up portions of *their* sections to others...)

  - The humor page (i'm sad to see that languishing)

  - Other incidental stuff in the Documentation section of the current
    site

2. Community-contributed news and hints - portal-style membership/
   contribution of news items, reviewed for release or rejection (maybe
   with community-based reviewers voting) 

3. Vaults of parnassus already does this, but i'll still mention - 
   Contributed software/docs/etc - managed similar to moderated news
   postings, but with classification/cataloguing of artifacts, ability for
   people to vote on desirability for ranking purposes

5. Jobs board - job postings possibly also managed with news-style
   reviewing process

6. Subscription to pages, to get notifcations when they change (probably
   batched, so people don't get too many as something is undergoing
   development).

7. Discussion "area" for coordinating and collecting logs of IRC-style
   chats when hot-topics arise that need rendezvous.

8. Open community wiki(s) for growing interesting little worlds (and with
   my new zwiki nesting-organization features, it may not be too chaotic).

Ken
klm at digicool.com




From gvwilson at nevex.com  Thu Jun  8 20:45:37 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Thu, 8 Jun 2000 14:45:37 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com>
Message-ID: <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>

> Ken Manheimer said
> 3. Vaults of parnassus already does this, but i'll still mention - 
>    Contributed software/docs/etc - managed similar to moderated news
>    postings, but with classification/cataloguing of artifacts, ability for
>    people to vote on desirability for ranking purposes

I'd like to see the Vaults, Starship, and other sub-sites folded into, or
become subsections of, a larger Python site, so that I've got the same
kind of one-stop shopping that CPAN gives me.

Thanks,

Greg





From esr at thyrsus.com  Thu Jun  8 20:54:45 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 8 Jun 2000 14:54:45 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400
References: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com> <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>
Message-ID: <20000608145445.A10500@thyrsus.com>

Greg Wilson <gvwilson at nevex.com>:
> > Ken Manheimer said
> > 3. Vaults of parnassus already does this, but i'll still mention - 
> >    Contributed software/docs/etc - managed similar to moderated news
> >    postings, but with classification/cataloguing of artifacts, ability for
> >    people to vote on desirability for ranking purposes
> 
> I'd like to see the Vaults, Starship, and other sub-sites folded into, or
> become subsections of, a larger Python site, so that I've got the same
> kind of one-stop shopping that CPAN gives me.

Second that.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Such are a well regulated militia, composed of the freeholders,
citizen and husbandman, who take up arms to preserve their property,
as individuals, and their rights as freemen.
        -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" 
            referred to in the Second Amendment to the Constitution.



From gmcm at hypernet.com  Thu Jun  8 20:57:51 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 8 Jun 2000 14:57:51 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com>
References: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <1251631791-15954519@hypernet.com>


From fdrake at beopen.com  Thu Jun  8 21:46:00 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 8 Jun 2000 15:46:00 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <20000608085351.A9299@thyrsus.com>
References: <20000607174148.A6801@thyrsus.com>
	<200006081027.MAA02445@python.inrialpes.fr>
	<14655.37744.352128.72841@cj42289-a.reston1.va.home.com>
	<20000608085351.A9299@thyrsus.com>
Message-ID: <14655.63480.384525.129125@cj42289-a.reston1.va.home.com>

Eric S. Raymond writes:
 > Go check out the PNG site's census of PNG support in "legacy"
 > browsers. Basically, as long as your PNGs don't use transparency or
 > animation, you're fine.  You've already had the good taste to eschew

  Excellent!  I'll review the list next week probably.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From jeremy at beopen.com  Thu Jun  8 22:24:51 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 8 Jun 2000 16:24:51 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <1251631791-15954519@hypernet.com>
References: <14654.48609.710990.321688@localhost.localdomain>
	<1251631791-15954519@hypernet.com>
Message-ID: <14656.275.83488.186898@localhost.localdomain>

>>>>> "GM" == Gordon McMillan <gmcm at hypernet.com> writes:

  >> From Ken Manheimer's Python web site wishlist: - The humor page
  >> (i'm sad to see that languishing)

  GM> A weekly nude Tim Peters jpeg!

We were going to keep those on the pythonlabs.com internal site, but
if Tim doesn't object...

Jeremy




From jeremy at beopen.com  Thu Jun  8 23:19:49 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 8 Jun 2000 17:19:49 -0400 (EDT)
Subject: [Python-Dev] impact of cycle gc...
In-Reply-To: <200006081408.JAA03136@beluga.mojam.com>
References: <200006081408.JAA03136@beluga.mojam.com>
Message-ID: <14656.3573.754658.791617@localhost.localdomain>

Skip,

I don't have time today to look at your post in detail, but one thing
you said rtiggered a pretty immediate response: We should worry more
about the GC performance on examples like the one you posted, and less
about pystone.  

pystone is a good benchmark for testing the overhead in cases when the
garbage collector isn't invoked.  There's so little memory allocation
that nothing interesting happens.  The GC patch ought to have no
effect in this case.  I suppose 4% is okay.

The worry is about programs that allocate a lot of objects, even if
they never create circular references.  The compiler test is one
example, because the parser tree consumes an enormous number of tuples
and objects.

I suspect big slowdowns like the one you posted just mean we don't
know how to adjust the tuneable parameters.

Jeremy




From gstein at lyra.org  Fri Jun  9 02:01:08 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 8 Jun 2000 17:01:08 -0700
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400
References: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com> <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>
Message-ID: <20000608170108.B16880@lyra.org>

On Thu, Jun 08, 2000 at 02:45:37PM -0400, Greg Wilson wrote:
> > Ken Manheimer said
> > 3. Vaults of parnassus already does this, but i'll still mention - 
> >    Contributed software/docs/etc - managed similar to moderated news
> >    postings, but with classification/cataloguing of artifacts, ability for
> >    people to vote on desirability for ranking purposes
> 
> I'd like to see the Vaults, Starship, and other sub-sites folded into, or
> become subsections of, a larger Python site, so that I've got the same
> kind of one-stop shopping that CPAN gives me.

+1 on that!

If python.org opens up (beyond what was possible w.r.t CNRI's security
policy), then I see a lot of the impetus for separate sites, such as
Starship and Parnassus, simply disappearing.

While we're at it: Python-URL has some funny location that I can't ever
remember. Providing a way for the organizers to publish those onto
python.org (and maintain the archive there) would be good. If /F is still
doing the daily URL, then it could go there, too...

Cheers,
-g

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



From nascheme at enme.ucalgary.ca  Fri Jun  9 03:29:00 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 8 Jun 2000 19:29:00 -0600
Subject: [Python-Dev] impact of cycle gc...
Message-ID: <20000608192900.A21668@acs.ucalgary.ca>

Just a few points and then I will get off python-dev. :)

First of all, I don't think it is very meaningful to use leaking
applications to do timing comparisons.  The collector has be
quite careful when freeing structures containing reference
cycles.  However, using something other than pystone is
definitely a good idea.

Here the pybench results for the latest patch:

PYBENCH 0.6

Benchmark: b_nogc (rounds=4, warp=30)

Tests:                              per run    per oper.  diff *
------------------------------------------------------------------------
          BuiltinFunctionCalls:     286.25 ms    3.37 us   -4.22%
           BuiltinMethodLookup:     367.50 ms    1.05 us   -4.55%
                 ConcatStrings:     368.37 ms    3.68 us  +42.50%
               CreateInstances:     477.87 ms   17.07 us   -4.45%
       CreateStringsWithConcat:     322.12 ms    2.42 us  +10.27%
                  DictCreation:     382.75 ms    3.83 us   +1.29%
                      ForLoops:     536.88 ms   80.73 us   +0.99%
                    IfThenElse:     432.75 ms    0.96 us   -3.21%
                   ListSlicing:     236.87 ms  104.12 us  +11.73%
                NestedForLoops:     320.00 ms    1.28 us   +0.16%
          NormalClassAttribute:     386.50 ms    0.97 us   +0.00%
           PythonFunctionCalls:     477.87 ms    4.34 us   -3.51%
             PythonMethodCalls:     379.12 ms    7.59 us  -12.67%
                     Recursion:     280.75 ms   33.70 us   -0.88%
                  SecondImport:     206.62 ms   12.41 us   -5.76%
           SecondPackageImport:     216.75 ms   13.02 us   -4.41%
         SecondSubmoduleImport:     279.25 ms   16.77 us   -2.57%
       SimpleComplexArithmetic:     351.00 ms    2.39 us   +0.72%
        SimpleDictManipulation:     320.75 ms    1.60 us   -2.99%
         SimpleFloatArithmetic:     361.50 ms    0.99 us  -20.37%
      SimpleIntFloatArithmetic:     336.00 ms    0.76 us   +0.04%
       SimpleIntegerArithmetic:     328.38 ms    0.75 us   -0.76%
        SimpleListManipulation:     312.88 ms    1.74 us   -1.61%
          SimpleLongArithmetic:     308.75 ms    2.81 us   +9.88%
                    SmallLists:     470.13 ms    2.77 us   -5.05%
                   SmallTuples:     374.62 ms    2.34 us  -15.74%
         SpecialClassAttribute:     384.00 ms    0.96 us   -1.88%
      SpecialInstanceAttribute:     446.38 ms    1.12 us   -2.75%
                 StringSlicing:     315.50 ms    2.70 us  +16.58%
                     TryExcept:     585.37 ms    0.59 us   -1.70%
                TryRaiseExcept:     312.75 ms   31.28 us   -5.30%
                  TupleSlicing:     299.38 ms    4.39 us  +12.18%
------------------------------------------------------------------------
            Average round time:   13615.00 ms              -1.13%

My AMD-K6-II processor is a pretty quirky beast so I don't think
you can conclude too much for those results.  Here are the
median timings from running Jeremy's compiler on its own source:

	$ time python compile.py `find . -name '*.py'`

Python 1.6 without GC:

	real    0m16.926s
	user    0m16.810s
	sys     0m0.110s

Python 1.6 with GC:

	real    0m21.593s
	user    0m21.470s
	sys     0m0.080s

Python 1.6 with GC, collection disabled (ie. gc.set_threshold(0)):

	real    0m18.441s
	user    0m18.220s
	sys     0m0.220s

We can tune the collection frequency all we want but we won't do
any better than the last numbers.  Those numbers reflect the cost
of keeping track of the objects and the increase in object size.

On a related note, I would like to cleanup the PyGC_{NEW,
VAR_NEW} macros but I can't figure out a way to transform this
code into a macro:

    op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp));
    if (op)
        op = PyGC_OBJ((PyGCInfo *)op);

If C's || operator was like the Python or I could do something
like:

    #define PyGC_OBJ_SAFE(g) ((PyGCInfo *)(((g) || -1) + 1))

Any ideas?  Using an inline function in the header file would
be nice but of course it is not portable.  GCC has statement
expressions but again they are not portable.

    Neil



From Vladimir.Marangozov at inrialpes.fr  Fri Jun  9 04:03:59 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 9 Jun 2000 04:03:59 +0200 (CEST)
Subject: [Python-Dev] impact of cycle gc...
In-Reply-To: <20000608192900.A21668@acs.ucalgary.ca> from "Neil Schemenauer" at Jun 08, 2000 07:29:00 PM
Message-ID: <200006090204.EAA11518@python.inrialpes.fr>

Neil Schemenauer wrote:
> 
> On a related note, I would like to cleanup the PyGC_{NEW,
> VAR_NEW} macros but I can't figure out a way to transform this
> code into a macro:
> 
>     op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp));
>     if (op)
>         op = PyGC_OBJ((PyGCInfo *)op);

The correct thing to do, IMO, is to reflect the sizeof(PyGCInfo)
mem increment in the tp_basicsize slot of the type object. Thus, we can
reuse the current PyObject_New/NEW code, which boils down to
PyObject_MALLOC(_PyObject_SIZE(tp)).  There is no need for PyGC_NEW/NEW_VAR.

This would imply some additional changes to PyObject_Init when the
GC_FLAG is set for a given typeobj.

I had a closer look at the patch today. It looks good, but I think it
needs some more work for a smooth integration with the existing APIs.
There's room for optimisations (there are lots of function calls in there,
so I am not surprised about the performance hit), but they'll come
later on, once the big chunks of the patch fit in their places.

One thing that bothered me is that the current gc object allocation
code won't fly with C++, where the object storage is allocated (and its
size is computed) automatically. There is no PyObject_New, and a C++
object constructor is supposed to begin with PyObject_Init.

Another thing is the function names: PyGC_NEW, PyGC_Info, PyGC_Insert, etc.
It would be better if they reflect the fact that we're talking about GC
on PyObjects, and not about GC in general (on arbitrary mem chunks).

I would suggest renaming them along these lines:

PyGC_Info -> PyGC_ObjectHead
PyGC_Insert -> PyGC_ObjectInit
PyGC_Remove -> PyGC_ObjectFini
...

All this needs some more thought though...

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From mal at lemburg.com  Fri Jun  9 13:03:56 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 09 Jun 2000 13:03:56 +0200
Subject: [Python-Dev] Japanese Codecs
Message-ID: <3940CF1C.2C625624@lemburg.com>

Python currently supports lots of different code pages and
other more specific codecs. I was wondering what your thoughts
on this are: should we proceed to include an even wider range
of codecs or limit the available number to an absolute minimum ?

I'm asking this, because Tamito KAJIYAMA wrote a set of
codecs for EUC-JP and Shift_JIS which would probably
be very useful for Japanese Python users -- I just don't
know how many there are and whether inclusion of an extra
650k of source code would hurt or not.

Thoughts ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From akuchlin at cnri.reston.va.us  Fri Jun  9 17:08:46 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Fri, 9 Jun 2000 11:08:46 -0400
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <3940CF1C.2C625624@lemburg.com>; from mal@lemburg.com on Fri, Jun 09, 2000 at 01:03:56PM +0200
References: <3940CF1C.2C625624@lemburg.com>
Message-ID: <20000609110846.C10688@amarok.cnri.reston.va.us>

On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote:
>I'm asking this, because Tamito KAJIYAMA wrote a set of
>codecs for EUC-JP and Shift_JIS which would probably
>be very useful for Japanese Python users -- I just don't
>know how many there are and whether inclusion of an extra
>650k of source code would hurt or not.

This seems too much code added that would only be of use to a limited
audience, so -1 from me.  Japanese packagers of Python would probably
include them, of course.

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I confidently expect it to be a fairly resounding failure.
  -- John Cleese, on the Monty Python reunion planned for 1999







From skip at mojam.com  Fri Jun  9 17:19:59 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 9 Jun 2000 10:19:59 -0500 (CDT)
Subject: [Python-Dev] impact of cycle gc...
In-Reply-To: <14656.3573.754658.791617@localhost.localdomain>
References: <200006081408.JAA03136@beluga.mojam.com>
	<14656.3573.754658.791617@localhost.localdomain>
Message-ID: <14657.2847.914770.368965@beluga.mojam.com>

    Jeremy> I don't have time today to look at your post in detail, but one
    Jeremy> thing you said rtiggered a pretty immediate response: We should
    Jeremy> worry more about the GC performance on examples like the one you
    Jeremy> posted, and less about pystone.

I wasn't really worried about pystone, just looking for something quick that
didn't generate cycles... ;-)

Your suggestion is an excellent one.  To try and account for the typical
case, I modified the test slightly.  I added a new class, ethyl:

    def foo():
	pass

    class ethyl:
	def __init__(self):
	    self.indirectFunc = foo

	def theFunc(self):
	    return "blah"

which performs essentially the same work at instantiation time as fred, but
doesn't create a cycle.  The time (in seconds) to create and delete 100,000
freds and ethyls with and without cycle-gc enabled looks like (last of six
consecutive runs):

			./python		./python-cycle-gc
    fred (cycle)	1.4			2.51
    ethyl (no cycle)	1.39			1.55

The memory consumption is as you would expect - leaky when creating fred's
without using cycle-gc, stable otherwise.

So, the penalty for creating and deleting objects that don't contain cycles
would appear to be reasonable (about 10-15%).  As more experience is gained
with it, I imagine it can be reduced further.

Skip




From mal at lemburg.com  Fri Jun  9 17:32:41 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 09 Jun 2000 17:32:41 +0200
Subject: [Python-Dev] Japanese Codecs
References: <3940CF1C.2C625624@lemburg.com> <20000609110846.C10688@amarok.cnri.reston.va.us>
Message-ID: <39410E19.4E4B1EE7@lemburg.com>

"Andrew M. Kuchling" wrote:
> 
> On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote:
> >I'm asking this, because Tamito KAJIYAMA wrote a set of
> >codecs for EUC-JP and Shift_JIS which would probably
> >be very useful for Japanese Python users -- I just don't
> >know how many there are and whether inclusion of an extra
> >650k of source code would hurt or not.
> 
> This seems too much code added that would only be of use to a limited
> audience, so -1 from me.  Japanese packagers of Python would probably
> include them, of course.

I just wish that these packagers actually become a reality
some day... the concept is good, but there currently seem to
be no volunteers or companies jumping in :-(

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From DavidA at ActiveState.com  Fri Jun  9 20:54:03 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 9 Jun 2000 11:54:03 -0700
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <39410E19.4E4B1EE7@lemburg.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com>

> I just wish that these packagers actually become a reality
> some day... the concept is good, but there currently seem to
> be no volunteers or companies jumping in :-(

I can't speak for Japanese packagers, but ActiveState will be packaging
Python in various ways.

--david




From klm at digicool.com  Fri Jun  9 20:59:26 2000
From: klm at digicool.com (Ken Manheimer)
Date: Fri, 9 Jun 2000 14:59:26 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14656.275.83488.186898@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0006081731080.675-100000@korak.digicool.com>

On Thu, 8 Jun 2000, Jeremy Hylton wrote:

> >>>>> "GM" == Gordon McMillan <gmcm at hypernet.com> writes:
> 
>   >> From Ken Manheimer's Python web site wishlist: - The humor page
>   >> (i'm sad to see that languishing)
> 
>   GM> A weekly nude Tim Peters jpeg!
> 
> We were going to keep those on the pythonlabs.com internal site, but
> if Tim doesn't object...

Anything for a buck, ay, now that you're in the commercial world?-)

Ken
klm at digicool.com




From tim_one at email.msn.com  Fri Jun  9 21:11:42 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 9 Jun 2000 15:11:42 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.21.0006081731080.675-100000@korak.digicool.com>
Message-ID: <000c01bfd246$8c02ca40$a12d153f@tim>

[KenM]
> - The humor page (i'm sad to see that languishing)

[Gordon, as always, guides our youth]
> A weekly nude Tim Peters jpeg!

[JeremyH]
> We were going to keep those on the pythonlabs.com internal site, but
> if Tim doesn't object...

[KenM]
> Anything for a buck, ay, now that you're in the commercial world?-)

After one of my recent "going away" parties here (I "get to" move to VA next
week), a group of old chums were sitting around the restaurant table,
belching up bad Italian cooking and speculating on our places in God's
Inscrutable Plan.  When it came time to pick on me, one naturally pugnacious
fellow-- emboldened beyond his normal aggression by wine --looked me
straight in the eye and demanded to know if there's *anything* I wouldn't do
for money.  Well, in point of fact I believe there are a great many such
things, but in the moment God only inspired me with one, and so I heard
myself retorting:  "Ya, sure, I'd fuck a dog for science ... but I wouldn't
take a job at Microsoft!".

strangely-enough-i-think-that's-backwards-ly y'rs  - tim





From moshez at math.huji.ac.il  Fri Jun  9 21:20:17 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Fri, 9 Jun 2000 22:20:17 +0300 (IDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <000c01bfd246$8c02ca40$a12d153f@tim>
Message-ID: <Pine.GSO.4.10.10006092217350.28979-100000@sundial>

On Fri, 9 Jun 2000, Tim Peters wrote:

> In the moment God only inspired me with one, and so I heard
> myself retorting:  "Ya, sure, I'd fuck a dog for science ... but I wouldn't
> take a job at Microsoft!".
> 
> strangely-enough-i-think-that's-backwards-ly y'rs  - tim

Backwards? You mean you'd fuck Microsoft for science but wouldn't take a
job at a dog? Or you'd fuck a dog for Microsoft but wouldn't take a job at
science? Or you'd take a job for science, but wouldn't fuck at Microsoft?

misunderstanding-tim-seems-to-be-a-common-pass-time-around-here-ly y'rs, Z

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



Return-Path: <moshez at math.huji.ac.il>
Delivered-To: python-dev at python.org
Received: from math.ma.huji.ac.il (ma.huji.ac.il [132.64.32.5])
	by dinsdale.python.org (Postfix) with ESMTP
	id C19A61CD28; Fri,  9 Jun 2000 14:37:53 -0400 (EDT)
Received: from localhost (moshez at localhost)
	by math.ma.huji.ac.il (8.9.1b+Sun/8.9.3) with ESMTP id VAA28640;
	Fri, 9 Jun 2000 21:37:03 +0300 (IDT)
Date: Fri, 9 Jun 2000 21:37:03 +0300 (IDT)
From: Moshe Zadka <moshez at math.huji.ac.il>
X-Sender: moshez at sundial
Reply-To: Moshe Zadka <moshez at math.huji.ac.il>
To: perl_monkey at my-deja.com
Cc: python-list at python.org, s2mdalle at titan.vcu.edu
In-Reply-To: <8hrbph$a4n$1 at nnrp1.deja.com>
Message-ID: <Pine.GSO.4.10.10006092133190.28574-100000 at sundial>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Python-Dev] Re: Porting CPython
Sender: python-dev-admin at python.org
Errors-To: python-dev-admin at python.org
X-BeenThere: python-dev at python.org
X-Mailman-Version: 2.0beta3
Precedence: bulk
List-Id: Python core developers <python-dev.python.org>

Not a lot I can help you with, but:

On Fri, 9 Jun 2000 perl_monkey at my-deja.com wrote:

> - Excluding Modules
> 
> What is the build procedure for omitting certain built in C modules?
> (I"m talking about the stuff in Modules/)

Edit the "Setup.in" file. Instructions for how are inside the file, but if
you have any more specific questions, please ask again.

> Any help on any of these issues would be appreciated.  Also, when/if I
> finish this, I'd be willing to diff the source and put it into the main
> python branch if that's something people would be interested in.

I'm CCing Python-Dev on this, so hopefully someone from the BeOpen team
can respond. I can just say I'm for it. (Python-dev is on BCC so replies
to this won't automatically go there.)

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From jeremy at beopen.com  Fri Jun  9 23:00:09 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 9 Jun 2000 17:00:09 -0400 (EDT)
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com>
References: <39410E19.4E4B1EE7@lemburg.com>
	<PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com>
Message-ID: <14657.23257.478479.141319@localhost.localdomain>

>>>>> "DA" == David Ascher <DavidA at ActiveState.com> writes:

  >> I just wish that these packagers actually become a reality some
  >> day... the concept is good, but there currently seem to be no
  >> volunteers or companies jumping in :-(

  DA> I can't speak for Japanese packagers, but ActiveState will be
  DA> packaging Python in various ways.

BeOpen also has packaging plans :-).

Jeremy



From mal at lemburg.com  Fri Jun  9 23:49:37 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 09 Jun 2000 23:49:37 +0200
Subject: [Python-Dev] Japanese Codecs
References: <39410E19.4E4B1EE7@lemburg.com>
		<PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com> <14657.23257.478479.141319@localhost.localdomain>
Message-ID: <39416671.AF78100F@lemburg.com>

Jeremy Hylton wrote:
> 
> >>>>> "DA" == David Ascher <DavidA at ActiveState.com> writes:
> 
>   >> I just wish that these packagers actually become a reality some
>   >> day... the concept is good, but there currently seem to be no
>   >> volunteers or companies jumping in :-(
> 
>   DA> I can't speak for Japanese packagers, but ActiveState will be
>   DA> packaging Python in various ways.
> 
> BeOpen also has packaging plans :-).

Sounds cool.

I just hope that someone will hint me of the first Python IPO
*before* it hits NASDAQ ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From effbot at telia.com  Fri Jun  9 23:59:18 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 9 Jun 2000 23:59:18 +0200
Subject: [Python-Dev] Japanese Codecs
References: <39410E19.4E4B1EE7@lemburg.com><PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com> <14657.23257.478479.141319@localhost.localdomain>
Message-ID: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid>

> I can't speak for Japanese packagers, but ActiveState will be
> packaging Python in various ways.
> 
> BeOpen also has packaging plans :-).

get in line, guys ;-)

</F>




From esr at thyrsus.com  Sat Jun 10 00:19:24 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 9 Jun 2000 18:19:24 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000609215719.47624E2673@oratrix.oratrix.nl>; from jack@oratrix.nl on Fri, Jun 09, 2000 at 11:57:14PM +0200
References: <20000609215719.47624E2673@oratrix.oratrix.nl>
Message-ID: <20000609181924.A15728@thyrsus.com>

Jack Jansen <jack at oratrix.nl>:
> I include PIL in the standard MacPython and Mac users are apparently
> very happy with that [...]

I think it's time to consider including PIL in the core Python 1.6 release.
I've been following the work being done over there, and I believe the 
code has reached a sufficient level of maturity to justify this.

The "Batteries are included" philosophy seems to me to imply that we
ought to be looking for application libraries to promote into the core
once we're satisfied that they meet core-Pythonic standards of good
API design, stability, general usefulness, and documentation quality.
PIL seems to me like a good candidate on all counts.

Guido has to make the final call, of course.  But let's have the discussion
now so we can develop a yea or nay consensus on ther list.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Society in every state is a blessing, but government even in its best
state is but a necessary evil; in its worst state an intolerable one;
for when we suffer, or are exposed to the same miseries *by a
government*, which we might expect in a country *without government*,
our calamities is heightened by reflecting that we furnish the means
by which we suffer."
	-- Thomas Paine



From pingster at ilm.com  Sat Jun 10 00:28:27 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Fri, 9 Jun 2000 15:28:27 -0700 (PDT)
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000609181924.A15728@thyrsus.com>
Message-ID: <Pine.SGI.3.96.1000609151846.621134V-100000@happy>

On Fri, 9 Jun 2000, Eric S. Raymond wrote:
> Jack Jansen <jack at oratrix.nl>:
> > I include PIL in the standard MacPython and Mac users are apparently
> > very happy with that [...]
> 
> I think it's time to consider including PIL in the core Python 1.6 release.
> I've been following the work being done over there, and I believe the 
> code has reached a sufficient level of maturity to justify this.

I'm +0.  Well, perhaps +0.1.

I guess what i would really be "+" about is something to the effect
of "a popular Linux distribution decides to throw in the .so for PIL".
Then it wouldn't really matter to me whether it was in the "real"
standard distribution.


-- ?!ng

"The police are not here to create disorder. They're here to preserve
disorder."
    -- Former Chicago mayor Daley




From akuchlin at cnri.reston.va.us  Sat Jun 10 03:52:23 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Fri, 9 Jun 2000 21:52:23 -0400
Subject: [Python-Dev] Re: [Image-SIG] RFC: Including PIL in 1.6
In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com>
Message-ID: <20000609215223.A23230@newcnri.cnri.reston.va.us>

On Fri, Jun 09, 2000 at 06:19:24PM -0400, Eric S. Raymond wrote:
>I think it's time to consider including PIL in the core Python 1.6 release.

-1 unless Fredrik says there's a C and Python API for extending PIL that
he's happy with, in which case it's +0.  I've written a few extensions for
PIL and it required a fair amount of grubbing around inside of C structures;
it isn't clear that the structures will be the same in future versions of
PIL.  We don't want to add something that people will extend messily, which
will then make fixing the API more difficult because of backward
compatibility.  (Disclaimer: I haven't looked at PIL 1.1 yet; maybe /F has
documented an API, or maybe he's pretty sure the data structures will remain
the same.)

OTOH, given that the Distutils is making good progress on building RPMs for
an arbitrary Python package, installing PIL may get much easier in future,
reducing the need to add it to the core.  But then Paul always yells at me
for that argument.  :) 

-- 
A.M. Kuchling			akuchlin at mems-exchange.org
Posting "Please send e-mail, since I don't read this group": Poster is
rendered illiterate by a simple trepanation.
  -- Kibo, in the Happynet Manifesto



From akuchlin at cnri.reston.va.us  Sat Jun 10 04:50:08 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Fri, 9 Jun 2000 22:50:08 -0400
Subject: [Python-Dev] What's New: 2nd draft
Message-ID: <20000609225008.A23369@newcnri.cnri.reston.va.us>

We've made a second pass at the "What's New in 1.6" document; the only
unwritten section is IDLE, and I don't think either Moshe or I use IDLE.
Can anyone tell us what the new features are?

Again, suggestions on style, forgotten changes, *anything*, are welcomed:
http://starship.python.net/crew/amk/python/writing/new-python/

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
  "How about you -- what're you up to?"
  "Issue #3."
      -- Vic and Zot, in ZOT! #3
      



From moshez at math.huji.ac.il  Sat Jun 10 07:29:56 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 10 Jun 2000 08:29:56 +0300 (IDT)
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid>
Message-ID: <Pine.GSO.4.10.10006100828230.1511-100000@sundial>

On Fri, 9 Jun 2000, Fredrik Lundh wrote:

> > I can't speak for Japanese packagers, but ActiveState will be
> > packaging Python in various ways.
> > 
> > BeOpen also has packaging plans :-).
> 
> get in line, guys ;-)

I wonder if next we'll see threads on slashdot about "PythonOne is just
trying to get on the Python hype. It has nothing to offer except for a 
trivial installer anyone can write in 5 minutes in Python"

(cf: the LinuxOne fiasco)
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From paul at prescod.net  Thu Jun  8 23:32:27 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 08 Jun 2000 23:32:27 +0200
Subject: [Python-Dev] [Fwd: Re: Case sensitivity]
Message-ID: <394010EB.DBCBC5FD@prescod.net>

Here's a good summary of how XML's case sensitivity came to be.

-------- Original Message --------
Subject: Re: Case sensitivity
Date: Mon, 3 Apr 2000 12:44:37 -0400
From: Steve DeRose <Steven_DeRose at brown.edu>
To: xml-dev at lists.oasis-open.org
References: <B50E2EFA.1B57%soord at vda.nl>

Languages with no need for case folding are not much of  a problem: the
case-folding table or program would merely have no effect on characters
belonging to such languages: It would change 26 of our 26 alphabetic
code
points, and no others. After all, in English we already use lots of
characters that don't get case-folded (like digits).

The serious problems are subtler:

The practical problem that with Unicode your folding table gets really
big;
on the order of 128Kbytes instead of 256 bytes (barring compresson):
this
is a pain on small devices (like a cell-phone browser), a pain to load,
a
pain to implement compression for, etc.

The theoretical problem is more important: it's not the caseless
languages
that pose problems, but the complicated case-folding ones. For example,
lots of languages only apply diacritical marks to lower-case letters:
for
example, "a" may come with 6 different accents, but "A" takes none --
which
makes case-folding unreversible. If there are languages that operate the
other way as well, then neither fold-to-upper nor fold-to-lower can work
for all languages: either way would trash some languages.


That said, I think it incumbent on XML *search engines* to support
case-folding (as well as decent treatment of accents, types of hyphens,
etc) for text content searches: Making English speakers search for

  "the" | "thE" | "tHe" | "tHE" | "The" | "ThE" | "THe" | "THE"
or
  "[tT][hH][eE]

is patently absurd; and besides, there is no user cost to (say) a
Japanese
speaker if an engine *does* case-fold. Also, many languages use Roman
characters occasionally, as for acronyms; so their speakers also pay a
price if searches aren't smart enough. And the primary problems with
case-folding do not weigh so heavily in the search engine world (for
example, AltaVista isn't likely to run their main servers on cell phones
for a while yet).





From esr at thyrsus.com  Sat Jun 10 17:42:27 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 11:42:27 -0400
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
Message-ID: <20000610114227.A19052@thyrsus.com>

Last night I sent the following patch for urllib to python-patches:

# Support for launching a browser

if os.environ.has_key("BROWSER"):
    _browsers = string.split(os.environ["BROWSER"], ":")
else:
    _browsers = ["mozilla %s &",
                "netscape -remote 'openURL(%s)'",
                "netscape %s &",
                "lynx %s &",
                "w3m %s &"]

def urlbrowse(url):
    """Launch a browser, in background, pointed at the given URL.
    Accept either a string or a parsed URL tuple. 
    Interpret the BROWSER environment variable, if it exists,
    as a colon-separated list of browser commands to try.
    """
    from urlparse import urlunparse 
    if type(url) == ():
        url = urlunparse(url)
    for browser in _browsers:
        if not os.system('which 1>/dev/null 2>&1 '+string.split(browser)[0]):
            if os.system((browser % url)) == 0:
                return 1
    return 0

Obviously this is not portable off Unix.  Equally obviously it should
be possible to do an equivalent thing under Windows (at least).  For
anybody writing interactive programs in this Web-mad era, this
function is just too useful not to have in the toolbox.  So this is a
nudge to any Windows and Mac wizards on this list -- let's make this
function available cross-platform.

I've also copied this note to Chip Salzenberg.  Perl ought to have
this capability too -- and I'm sufficiently serious about that to
(gasp) code in Perl myself to make it happen if I have to.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

(Those) who are trying to read the Second Amendment out of the Constitution by
claiming it's not an individual right (are) courting disaster by encouraging
others to use the same means to eliminate portions of the Constitution they
don't like.
	-- Alan Dershowitz, Harvard Law School



From akuchlin at cnri.reston.va.us  Sat Jun 10 17:42:50 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sat, 10 Jun 2000 11:42:50 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610113124.B18982@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 11:31:24AM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com>
Message-ID: <20000610114250.A25014@newcnri.cnri.reston.va.us>

[Redirecting a private conversation to python-dev]

On Sat, Jun 10, 2000 at 11:31:24AM -0400, Eric S. Raymond wrote:
>I found a workaround.  The two curses enhancements (traceback wrapper
>and text pad) are now working and ready to be integrated into the
>1.6 library.  How should we proceed?

OK; python-dev has discussed creating a curses package, and reaction
seemed favorable.  So, my plan of action is:

1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv'
inside the SourceForge CVS repository so the complete history of the
module doesn't get lost with the renaming?)

2) Create a Lib/curses/
directory; __init__.py does 'from _curses import *'.  

3) The traceback wrapper can then be put into __init__.py, since I
assume it's fairly small and everyone should use it.  The text pad
stuff could then go in another module in the curses package.

Seem reasonable to everyone?  

--amk



From esr at thyrsus.com  Sat Jun 10 18:01:48 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 12:01:48 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 11:42:50AM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us>
Message-ID: <20000610120148.A19168@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> OK; python-dev has discussed creating a curses package, and reaction
> seemed favorable.  So, my plan of action is:
> 
> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv'
> inside the SourceForge CVS repository so the complete history of the
> module doesn't get lost with the renaming?)
> 
> 2) Create a Lib/curses/
> directory; __init__.py does 'from _curses import *'.  
> 
> 3) The traceback wrapper can then be put into __init__.py, since I
> assume it's fairly small and everyone should use it.  The text pad
> stuff could then go in another module in the curses package.
> 
> Seem reasonable to everyone?  

Works for me.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

We shall not cease from exploration, and the end of all our exploring will be
to arrive where we started and know the place for the first time.
	-- T.S. Eliot



From moshez at math.huji.ac.il  Sat Jun 10 19:03:51 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 10 Jun 2000 20:03:51 +0300 (IDT)
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us>
Message-ID: <Pine.GSO.4.10.10006102000540.6989-100000@sundial>

On Sat, 10 Jun 2000, Andrew Kuchling wrote:

> OK; python-dev has discussed creating a curses package, and reaction
> seemed favorable.  So, my plan of action is:
> 
> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv'
> inside the SourceForge CVS repository so the complete history of the
> module doesn't get lost with the renaming?)
> 
> 2) Create a Lib/curses/
> directory; __init__.py does 'from _curses import *'.  
> 
> 3) The traceback wrapper can then be put into __init__.py, since I
> assume it's fairly small and everyone should use it.  The text pad
> stuff could then go in another module in the curses package.
> 
> Seem reasonable to everyone?  

I'm +1, except for some nagging doubt about the traceback wrapper.
Why not put it in its own (small, granted) module? 
There are no backward compatabilities to worry here, so there shouldn't be
any excuse to put code in __init__.py. But it is so small, that I don't
really feel strongly about it.

i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com





From esr at thyrsus.com  Sat Jun 10 19:24:18 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 13:24:18 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <Pine.GSO.4.10.10006102000540.6989-100000@sundial>; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 08:03:51PM +0300
References: <20000610114250.A25014@newcnri.cnri.reston.va.us> <Pine.GSO.4.10.10006102000540.6989-100000@sundial>
Message-ID: <20000610132418.A19442@thyrsus.com>

Moshe Zadka <moshez at math.huji.ac.il>:
> I'm +1, except for some nagging doubt about the traceback wrapper.
> Why not put it in its own (small, granted) module? 

I don't understand.  Whuy do you want to do this?

> i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z.

You can try it out now:

#
# Curses extensions -- these are expected to be in the 1.6 Python library
#
import sys, curses, ascii

def wrapper(func, *rest):
    "Wrapper function that restores normal keyboard/screen behavior on error."
    res = None
    try:
	# Initialize curses
	stdscr=curses.initscr()
	# Turn off echoing of keys, and enter cbreak mode,
	# where no buffering is performed on keyboard input
	curses.noecho() ; curses.cbreak()

	# In keypad mode, escape sequences for special keys
	# (like the cursor keys) will be interpreted and
	# a special value like curses.KEY_LEFT will be returned
        stdscr.keypad(1)

        res = apply(func, (stdscr,) + rest)
    except:
	# In the event of an error, restore the terminal
	# to a sane state.
	stdscr.keypad(0)
	curses.echo() ; curses.nocbreak()
	curses.endwin()
        # Pass the exception upwards
        (exc_type, exc_value, exc_traceback) = sys.exc_info()
        raise exc_type, exc_value, exc_traceback
    else:
	# Set everything back to normal
	stdscr.keypad(0)
	curses.echo() ; curses.nocbreak()
	curses.endwin()		 # Terminate curses

        return res

def rectangle(win, uly, ulx, lry, lrx):
    "Draw a rectangle."
    win.vline(uly+1, ulx, curses.ACS_VLINE, lry - uly - 1)
    win.hline(uly, ulx+1, curses.ACS_HLINE, lrx - ulx - 1)
    win.hline(lry, ulx+1, curses.ACS_HLINE, lrx - ulx - 1)
    win.vline(uly+1, lrx, curses.ACS_VLINE, lry - uly - 1)
    win.addch(uly, ulx, curses.ACS_ULCORNER)
    win.addch(uly, lrx, curses.ACS_URCORNER)
    win.addch(lry, lrx, curses.ACS_LRCORNER)
    win.addch(lry, ulx, curses.ACS_LLCORNER)

class textbox:
    """Editing widget using the interior of a window object.
    Supports the following Emacs-like key bindings:

    Ctrl-A      Go to left edge of window.
    Ctrl-B      Cursor left, wrapping to previous line if appropriate.
    Ctrl-D      Delete character under cursor.
    Ctrl-E      Go to right edge (nospaces off) or end of line (nospaces on).
    Ctrl-F      Cursor right, wrapping to next line when appropriate.
    Ctrl-G      Terminate, returning the window contents.
    Ctrl-J      Terminate if the window is 1 line, otherwise insert newline.
    Ctrl-K      If line is blank, delete it, otherwise clear to end of line.
    Ctrl-L      Refresh screen
    Ctrl-N      Cursor down; move down one line.
    Ctrl-O      Insert a blank line at cursor location.
    Ctrl-P      Cursor up; move up one line.

    Move operations do nothing if the cursor is at an edge where the movement
    is not possible.  The following synonyms are supported where possible:

    KEY_LEFT = Ctrl-B, KEY_RIGHT = Ctrl-F, KEY_UP = Ctrl-P, KEY_DOWN = Ctrl-N
    """
    def __init__(self, win):
        self.win = win
        (self.maxy, self.maxx) = win.getmaxyx()
        self.maxy = self.maxy - 1
        self.maxx = self.maxx - 1
        self.stripspaces = 1
        win.keypad(1)

    def firstblank(self, y):
        "Go to the location of the first blank on the given line."
        (oldy, oldx) = self.win.getyx()
        self.win.move(y, self.maxx-1)
        last = self.maxx-1
        while 1:
            if last == 0:
                break
            if ascii.ascii(self.win.inch(y, last)) != ascii.SP:
                last = last + 1
                break
            last = last - 1
        self.win.move(oldy, oldx)
        return last

    def do_command(self, ch):
        "Process a single editing command."
        (y, x) = self.win.getyx()
        if ascii.isprint(ch):
            if y < self.maxy or x < self.maxx:
                # The try-catch ignores the error we trigger from some curses
                # versions by trying to write into the lowest-rightmost spot
                # in the self.window.
                try:
                    self.win.addch(ch)
                except ERR:
                    pass
        elif ch == ascii.SOH:				# Ctrl-a
            self.win.move(y, 0)
        elif ch in (ascii.STX, curses.KEY_LEFT):	# Ctrl-b
            if x > 0:
                self.win.move(y, x-1)
            elif y == 0:
                pass
            elif self.stripspaces:
                self.win.move(y-1, self.firstblank(y-1))
            else:
                self.win.move(y-1, self.maxx)
        elif ch == ascii.EOT:				# Ctrl-d
            self.win.delch()
        elif ch == ascii.ENQ:				# Ctrl-e
            if self.stripspaces:
                self.win.move(y, self.firstblank(y, maxx))
            else:
                self.win.move(y, self.maxx)
        elif ch in (ascii.ACK, curses.KEY_RIGHT):	# Ctrl-f
            if x < self.maxx:
                self.win.move(y, x+1)
            elif y == self.maxx:
                pass
            else:
                self.win.move(y+1, 0)
        elif ch == ascii.BEL:				# Ctrl-g
            return 0
        elif ch == ascii.NL:				# Ctrl-j
            if self.maxy == 0:
                return 0
            elif y < self.maxy:
                self.win.move(y+1, 0)
        elif ch == ascii.VT:				# Ctrl-k
            if x == 0 and self.firstblank(y) == 0:
                self.win.deleteln()
            else:
                self.win.clrtoeol()
        elif ch == ascii.FF:				# Ctrl-l
            self.win.refresh()
        elif ch in (ascii.SO, curses.KEY_DOWN):		# Ctrl-n
            if y < self.maxy:
                self.win.move(y+1, x)
        elif ch == ascii.SI:				# Ctrl-o
            self.win.insertln()
        elif ch in (ascii.DLE, curses.KEY_UP):		# Ctrl-p
            if y > 0:
                self.win.move(y-1, x)
        self.win.refresh()
        return 1
        
    def gather(self):
        "Collect and return the contents of the window."
        result = ""
        for y in range(self.maxy+1):
            self.win.move(y, 0)
            stop = self.firstblank(y)
            if stop == 0 and self.stripspaces:
                continue
            for x in range(self.maxx+1):
                if self.stripspaces and x == stop:
                    break
                result = result + chr(ascii.ascii(self.win.inch(y, x)))
            if self.maxy > 0:
                result = result + "\n"
        return result

    def edit(self, validate=None):
        "Edit in the widget window and collect the results."
        while 1:
            ch = self.win.getch()
            if self.validate:
                ch = validate(ch)
            if not self.do_command(ch):
                break
        return self.gather()

if __name__ == '__main__':
    def test_editbox(stdscr):
        win = curses.newwin(4, 9, 15, 20)
        rectangle(stdscr, 14, 19, 19, 29)
        stdscr.refresh()
        return textbox(win).edit()

    str = wrapper(test_editbox)
    print str
-- 
		<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 bwarsaw at python.org  Sat Jun 10 19:58:04 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Sat, 10 Jun 2000 13:58:04 -0400 (EDT)
Subject: [Python-Dev] Creating curses package: OK?
References: <200006100748.DAA17920@snark.thyrsus.com>
	<20000610111323.A24895@newcnri.cnri.reston.va.us>
	<20000610113124.B18982@thyrsus.com>
	<20000610114250.A25014@newcnri.cnri.reston.va.us>
Message-ID: <14658.33196.426211.329070@anthem.concentric.net>

>>>>> "AK" == Andrew Kuchling <akuchlin at cnri.reston.va.us> writes:

    AK> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you
    AK> do a 'mv' inside the SourceForge CVS repository so the
    AK> complete history of the module doesn't get lost with the
    AK> renaming?)

Not easily (IOW, I have to play several rounds of ugly loginfo games
which are hard to get right).  Best thing to do would be to submit a
SF admin request, which I think since you're a developer you can do.

-Barry



From moshez at math.huji.ac.il  Sat Jun 10 22:12:32 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 10 Jun 2000 23:12:32 +0300 (IDT)
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610132418.A19442@thyrsus.com>
Message-ID: <Pine.GSO.4.10.10006102308380.9354-100000@sundial>

[Moshe Zadka]
> I'm +1, except for some nagging doubt about the traceback wrapper.
> Why not put it in its own (small, granted) module? 

[Eric S. Raymond]
> I don't understand.  Why do you want to do this?

I have religious beliefs, and I follow them without thinking. Like
"HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting
real code in __init__.py bad".

(I think that should go in the package style guide, BTW)

religions-are-bad-of-course-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From esr at thyrsus.com  Sat Jun 10 22:24:40 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 16:24:40 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <Pine.GSO.4.10.10006102308380.9354-100000@sundial>; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:12:32PM +0300
References: <20000610132418.A19442@thyrsus.com> <Pine.GSO.4.10.10006102308380.9354-100000@sundial>
Message-ID: <20000610162440.A19859@thyrsus.com>

Moshe Zadka <moshez at math.huji.ac.il>:
> [Eric S. Raymond]
> > I don't understand.  Why do you want to do this?
> 
> I have religious beliefs, and I follow them without thinking. Like
> "HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting
> real code in __init__.py bad".

I'm even more confused now.  Why would the traceback wrapper I'm proposing
go in __init__.py?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The Bible is not my book, and Christianity is not my religion.  I could never
give assent to the long, complicated statements of Christian dogma.
	-- Abraham Lincoln



From moshez at math.huji.ac.il  Sat Jun 10 22:21:57 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 10 Jun 2000 23:21:57 +0300 (IDT)
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610162440.A19859@thyrsus.com>
Message-ID: <Pine.GSO.4.10.10006102319051.9354-100000@sundial>

On Sat, 10 Jun 2000, Eric S. Raymond wrote:

> I'm even more confused now.  Why would the traceback wrapper I'm proposing
> go in __init__.py?

Maybe I'm confused here. I thought that was what AMK suggested, no?
Where would you want it to go? There are currently 3 planned files in 
the curses package:

__init__.py: apparently not
textpad.py: why here? it has nothing to do with text pads
_curses.so: certainly not here...you don't want to code in C more then you
            have to

I'm proposing:

wrapper.py: put it here

i-hope-i-managed-to-confuse-everyone-further-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From akuchlin at cnri.reston.va.us  Sun Jun 11 00:25:14 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sat, 10 Jun 2000 18:25:14 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <Pine.GSO.4.10.10006102319051.9354-100000@sundial>; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:21:57PM +0300
References: <20000610162440.A19859@thyrsus.com> <Pine.GSO.4.10.10006102319051.9354-100000@sundial>
Message-ID: <20000610182514.A25949@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote:
>Maybe I'm confused here. I thought that was what AMK suggested, no?

I did in fact suggest that, since the wrapper is small, and we ideally
want every Python/curses application using it, so they don't leave the
terminal in a wacky state if they raise an exception.  But it's not a
big deal and could easily go in wrapper.py, though __init__.py might
still import it automatically.

--amk



From esr at thyrsus.com  Sun Jun 11 00:38:06 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 18:38:06 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400
References: <20000610162440.A19859@thyrsus.com> <Pine.GSO.4.10.10006102319051.9354-100000@sundial> <20000610182514.A25949@newcnri.cnri.reston.va.us>
Message-ID: <20000610183806.A20280@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote:
> >Maybe I'm confused here. I thought that was what AMK suggested, no?
> 
> I did in fact suggest that, since the wrapper is small, and we ideally
> want every Python/curses application using it, so they don't leave the
> terminal in a wacky state if they raise an exception.  But it's not a
> big deal and could easily go in wrapper.py, though __init__.py might
> still import it automatically.

The traceback wrapper is not the only Python code I'll be supplying...
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

I do not find in orthodox Christianity one redeeming feature.
	-- Thomas Jefferson



From gstein at lyra.org  Sun Jun 11 00:33:20 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 15:33:20 -0700
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400
References: <20000610162440.A19859@thyrsus.com> <Pine.GSO.4.10.10006102319051.9354-100000@sundial> <20000610182514.A25949@newcnri.cnri.reston.va.us>
Message-ID: <20000610153320.A19484@lyra.org>

On Sat, Jun 10, 2000 at 06:25:14PM -0400, Andrew Kuchling wrote:
> On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote:
> >Maybe I'm confused here. I thought that was what AMK suggested, no?
> 
> I did in fact suggest that, since the wrapper is small, and we ideally
> want every Python/curses application using it, so they don't leave the
> terminal in a wacky state if they raise an exception.  But it's not a
> big deal and could easily go in wrapper.py, though __init__.py might
> still import it automatically.

Yes, I think we'd want it to import the stuff; just organizationally to
place the source code outside of __init__.py

I'd agree that real code should not go into __init__. It should preload some
standard modules, maybe expose some symbols, but otherwise no code.

Cheers,
-g

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



From gstein at lyra.org  Sun Jun 11 01:30:13 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 16:30:13 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <200006102306.QAA18088@slayer.i.sourceforge.net>; from akuchling@slayer.i.sourceforge.net on Sat, Jun 10, 2000 at 04:06:55PM -0700
References: <200006102306.QAA18088@slayer.i.sourceforge.net>
Message-ID: <20000610163013.B19484@lyra.org>

On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote:
>...
> def wrapper(func, *rest):
>     """Wrapper function that initializes curses and calls another function,
>     restoring normal keyboard/screen behavior on error.
>     The callable object 'func' is then passed the main window 'stdscr'
>     as its first argument, followed by any other arguments passed to
>     wrapper().
>     """
>     
>     res = None
>     try:
> 	# Initialize curses
> 	stdscr=curses.initscr()
> 	# Turn off echoing of keys, and enter cbreak mode,
> 	# where no buffering is performed on keyboard input
> 	curses.noecho() ; curses.cbreak()
> 
> 	# In keypad mode, escape sequences for special keys
> 	# (like the cursor keys) will be interpreted and
> 	# a special value like curses.KEY_LEFT will be returned
>         stdscr.keypad(1)
> 
>         res = apply(func, (stdscr,) + rest)
>     except:
> 	# In the event of an error, restore the terminal
> 	# to a sane state.
> 	stdscr.keypad(0)
> 	curses.echo() ; curses.nocbreak()
> 	curses.endwin()
>         # Pass the exception upwards
>         (exc_type, exc_value, exc_traceback) = sys.exc_info()
>         raise exc_type, exc_value, exc_traceback
>     else:
> 	# Set everything back to normal
> 	stdscr.keypad(0)
> 	curses.echo() ; curses.nocbreak()
> 	curses.endwin()		 # Terminate curses
> 
>         return res

This is too complicated. It should read:

   ...
   return apply(func, (stdscr,) + rest)
 finally:
   # Set everything back to normal
   stdscr.keypad(0)
   curses.echo()
   curses.nocbreak()
   curses.endwin()

Andrew: can you make this change?


Separate from the above simplification, it is important to note:

    exc_type, exc_value, exc_traceback = sys.exc_info()
    raise exc_type, exc_value, exc_traceback
    
and

    raise
    
are equivalent in (most) function. The difference is that the former places
the traceback into local variable storage (exc_traceback) which then
introduces a reference loop.

Whenever sys.exc_info() is used, it is very important to watch out for loops
caused by the traceback object. "del exc_traceback" is very handy :-)

Cheers,
-g

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



From gstein at lyra.org  Sun Jun 11 01:33:05 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 16:33:05 -0700
Subject: [Python-Dev] curses wrapper checkin
In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org>
Message-ID: <20000610163305.C19484@lyra.org>

On Sat, Jun 10, 2000 at 04:30:13PM -0700, Greg Stein wrote:
> On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote:
> >...
> > def wrapper(func, *rest):
> >     """Wrapper function that initializes curses and calls another function,
> >     restoring normal keyboard/screen behavior on error.
> >     The callable object 'func' is then passed the main window 'stdscr'
> >     as its first argument, followed by any other arguments passed to
> >     wrapper().
> >     """
> >     
> >     res = None

Oh. This line can disappear, too.

Cheers,
-g

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



From akuchlin at cnri.reston.va.us  Sun Jun 11 01:33:12 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sat, 10 Jun 2000 19:33:12 -0400
Subject: [Python-Dev] Creating curses package: done
In-Reply-To: <14658.33196.426211.329070@anthem.concentric.net>; from bwarsaw@python.org on Sat, Jun 10, 2000 at 01:58:04PM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net>
Message-ID: <20000610193312.A26098@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 01:58:04PM -0400, Barry A. Warsaw wrote:
>which are hard to get right).  Best thing to do would be to submit a
>SF admin request, which I think since you're a developer you can do.

I've submitted a support request to rename the file, and checked in
the Lib/curses subdirectory, containing only __init__.py and
wrapper.py, along with the required Makefile.in and Setup.in changes.
If you compile the CVS tree right now, you'll need to rename
cursesmodule.c to _cursesmodule.c manually.

The textbox stuff poses two problems.  First, it requires ascii.py,
and wasn't the decision to wait for GvR on adding that module?
Second, Eric, I'm not sure what you want as the module name for the
textbox stuff: textbox.py?  Your call...  (I'll check it in, and if
ascii.py is vetoed, it can be rewritten to not require ascii.py, or
we can have curses.ascii.)

--amk



From esr at thyrsus.com  Sun Jun 11 01:48:22 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 19:48:22 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org>
Message-ID: <20000610194822.A882@thyrsus.com>

Greg Stein <gstein at lyra.org>:
> This is too complicated. It should read:
> 
>    ...
>    return apply(func, (stdscr,) + rest)
>  finally:
>    # Set everything back to normal
>    stdscr.keypad(0)
>    curses.echo()
>    curses.nocbreak()
>    curses.endwin()
> 
> Andrew: can you make this change?

I'll test it and make the change in my masters if it works for both
cases.  I haven't actually shipped the box of goodies yet...
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Alcohol still kills more people every year than all `illegal' drugs put
together, and Prohibition only made it worse.  Oppose the War On Some Drugs!



From esr at thyrsus.com  Sun Jun 11 01:50:27 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 19:50:27 -0400
Subject: [Python-Dev] Creating curses package: done
In-Reply-To: <20000610193312.A26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:33:12PM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us>
Message-ID: <20000610195027.B882@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> The textbox stuff poses two problems.  First, it requires ascii.py,
> and wasn't the decision to wait for GvR on adding that module?
> Second, Eric, I'm not sure what you want as the module name for the
> textbox stuff: textbox.py?  Your call...  (I'll check it in, and if
> ascii.py is vetoed, it can be rewritten to not require ascii.py, or
> we can have curses.ascii.)

I thought it was going to become part of curses from the user's point
of view, so that "import curses" brings it in.  That seemed to be the 
intent of the request at the end of the curses HOWTO.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"Taking my gun away because I might shoot someone is like cutting my tongue
out because I might yell `Fire!' in a crowded theater."
        -- Peter Venetoklis



From akuchlin at cnri.reston.va.us  Sun Jun 11 01:44:54 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sat, 10 Jun 2000 19:44:54 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <20000610194822.A882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:48:22PM -0400
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com>
Message-ID: <20000610194454.B26098@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote:
>I'll test it and make the change in my masters if it works for both
>cases.  I haven't actually shipped the box of goodies yet...

Already tested and checked in.  If you make other changes, just ship
me the new version.  

(Oh, I forgot about the stupid legal stuff; you should probably send
wrapper.py and textbox.py to patches at python.org with the requisite
legal disclaimer.)

--amk



From esr at thyrsus.com  Sun Jun 11 01:59:31 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 19:59:31 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <20000610194454.B26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:44:54PM -0400
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com> <20000610194454.B26098@newcnri.cnri.reston.va.us>
Message-ID: <20000610195931.A985@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote:
> >I'll test it and make the change in my masters if it works for both
> >cases.  I haven't actually shipped the box of goodies yet...
> 
> Already tested and checked in.  If you make other changes, just ship
> me the new version.  

Well, dang.  Didn't you want me to document it first? :-)
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Rifles, muskets, long-bows and hand-grenades are inherently democratic
weapons.  A complex weapon makes the strong stronger, while a simple
weapon -- so long as there is no answer to it -- gives claws to the
weak.
        -- George Orwell, "You and the Atom Bomb", 1945



From akuchlin at cnri.reston.va.us  Sun Jun 11 01:51:30 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sat, 10 Jun 2000 19:51:30 -0400
Subject: [Python-Dev] Creating curses package: done
In-Reply-To: <20000610195027.B882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:50:27PM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us> <20000610195027.B882@thyrsus.com>
Message-ID: <20000610195130.C26098@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 07:50:27PM -0400, Eric S. Raymond wrote:
>I thought it was going to become part of curses from the user's point
>of view, so that "import curses" brings it in.  That seemed to be the 
>intent of the request at the end of the curses HOWTO.

Ooh, no; that text is saying that an editor would make a good example
to put in the HOWTO.  I'd rather have the curses module contain only a
fairly close mapping of the C API, and extensions written in Python
would be in submodules like curses.editor, curses.textbox, whatever.
Similar to how socketmodule.c is a thin veneer over the BSD socket API, 
and the spiffy extensions are in asyncore.py, httplib.py, &c.

--amk




From nhodgson at bigpond.net.au  Sun Jun 11 02:04:53 2000
From: nhodgson at bigpond.net.au (Neil Hodgson)
Date: Sun, 11 Jun 2000 10:04:53 +1000
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
References: <20000610114227.A19052@thyrsus.com>
Message-ID: <016301bfd338$ab8458f0$e3cb8490@neil>

> Obviously this is not portable off Unix.  Equally obviously it should
> be possible to do an equivalent thing under Windows (at least).  For
> anybody writing interactive programs in this Web-mad era, this
> function is just too useful not to have in the toolbox.  So this is a
> nudge to any Windows and Mac wizards on this list -- let's make this
> function available cross-platform.

   The most common way on Windows to launch the user's preferred browser
with an URL would be:

>>> import win32api
>>> win32api.ShellExecute(0,None,"http://www.python.org",None,"",1)

# Note to Mark - more of the parameters should be optional

   However this, like most process control stuff, requires the Win32
extensions, not the base Python distribution. Trying to hack this up with
os.system would be unpleasant. ShellExecute knows when to do icky stuff like
use DDE to open the correct URL.

   Does this type of UI operation really belong in urllib?

   Neil




From esr at thyrsus.com  Sun Jun 11 03:26:08 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 21:26:08 -0400
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
In-Reply-To: <016301bfd338$ab8458f0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 10:04:53AM +1000
References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil>
Message-ID: <20000610212608.A1109@thyrsus.com>

Neil Hodgson <nhodgson at bigpond.net.au>:
>    Does this type of UI operation really belong in urllib?

It fetches the contents of an URL for inspection.  Where else would you put it?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

It would be thought a hard government that should tax its people one tenth 
part.
	-- Benjamin Franklin



From nhodgson at bigpond.net.au  Sun Jun 11 03:51:34 2000
From: nhodgson at bigpond.net.au (Neil Hodgson)
Date: Sun, 11 Jun 2000 11:51:34 +1000
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com>
Message-ID: <01af01bfd347$937b3fd0$e3cb8490@neil>

> >    Does this type of UI operation really belong in urllib?
>
> It fetches the contents of an URL for inspection.  Where else would you
put it?

   os?
   Or a submodule of os.

   The current os has a bunch of executable-oriented process creation and
managment functions. On Macintosh and Windows, data-oriented process
creation would be useful.

   os.process.open("http://www.python.org")

   os.process.print("c:\src\map.png")

   Neil





From esr at thyrsus.com  Sun Jun 11 04:14:56 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 22:14:56 -0400
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
In-Reply-To: <01af01bfd347$937b3fd0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 11:51:34AM +1000
References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com> <01af01bfd347$937b3fd0$e3cb8490@neil>
Message-ID: <20000610221456.A1223@thyrsus.com>

Neil Hodgson <nhodgson at bigpond.net.au>:
> > It fetches the contents of an URL for inspection.  Where else would you
> put it?
> 
>    os?
>    Or a submodule of os.
> 
>    The current os has a bunch of executable-oriented process creation and
> managment functions. On Macintosh and Windows, data-oriented process
> creation would be useful.

I don't really care where it lives, and will cheerfully defer to those 
with religious beliefs about the namespace ;-).

If it's not obvious, this flurry of library suggestions you've been
seeing from me lately all come straight out of the CML2 project.  I
use the urlbrowse() function to make URLs in help windows into live
objects that you can click on.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

This would be the best of all possible worlds, if there were
no religion in it.
	-- John Adams, in a letter to Thomas Jefferson.



From esr at snark.thyrsus.com  Sun Jun 11 06:29:37 2000
From: esr at snark.thyrsus.com (Eric S. Raymond)
Date: Sun, 11 Jun 2000 00:29:37 -0400
Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper
Message-ID: <200006110429.AAA01719@snark.thyrsus.com>

Greg Stein's correction broke my traceback wrapper.  I now do *not*
see a traceback on an exit due to Python runtime errors.  I don't know
why this is.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

No one who's seen it in action can say the phrase "government help" without
either laughing or crying.



From gstein at lyra.org  Sun Jun 11 07:44:30 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 22:44:30 -0700
Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper
In-Reply-To: <200006110429.AAA01719@snark.thyrsus.com>; from esr@snark.thyrsus.com on Sun, Jun 11, 2000 at 12:29:37AM -0400
References: <200006110429.AAA01719@snark.thyrsus.com>
Message-ID: <20000610224430.E19484@lyra.org>

On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote:
> Greg Stein's correction broke my traceback wrapper.  I now do *not*
> see a traceback on an exit due to Python runtime errors.  I don't know
> why this is.

That's strange... a "finally" does not munge tracebacks at all. An exception
from a lower level should propagate outwards without interference.

Do you still have an "except:" in your code somewhere? (that could be eating
your exception) Maybe your test case isn't failing as expected :-) If you'd
like, post a copy of the test, and we can debug the wrapper and/or test.

Cheers,
-g

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



From gstein at lyra.org  Sun Jun 11 13:01:50 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 11 Jun 2000 04:01:50 -0700
Subject: [Python-Dev] more on httplib
In-Reply-To: <Pine.LNX.4.10.10006031606100.29036-100000@nebula.lyra.org>; from gstein@lyra.org on Sat, Jun 03, 2000 at 04:13:55PM -0700
References: <Pine.LNX.4.10.10006031606100.29036-100000@nebula.lyra.org>
Message-ID: <20000611040150.K19484@lyra.org>

All of the work below has been completed except for the errno==32 stuff.

Module:  http://www.lyra.org/greg/python/httplib.py
History: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/

There are three items left, that I know of:
  1) need doc for new stuff
  2) need new test cases
  3) I want to remove a "feature" of the old HTTP class. This would be a
     change in behavior, but (IMO) minor. Specifically, if the Status-Line
     is malformed, the old httplib.py would return (-1, <malformed line>,
     None) and store <file ob hooked to socket> into self.file. Nominally,
     that file object allows a client to read more data from the socket
     after the parse problem on the malformed Status-Line. I think it is
     useless, unused by any clients out there, and it causes me pain to
     provide it :-)  I'd like to just store None into self.file

Thoughts? Comments? I'd like to get this thing into Python RSN.

Cheers,
-g

On Sat, Jun 03, 2000 at 04:13:55PM -0700, Greg Stein wrote:
> I would like to propose a few changes to the (new) httplib:
> 
> *) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to
>    provide backwards-compat for it
> 
> *) revamp the pipeline support:
> 
>    - record the "last response object" ... when a new getreply() is done,
>      then we store the "last" into response.prior
>    - reading of the "HTTP/1.1 <code> <msg>" line is deferred, and
>      performed by the response object
>    - the read of that line is lazy
>    - if the response line is read *before* the "prior" response (if any) 
>      is "closed", then an exception is raised: ResponseNotReady
> 
> *) address some of Moshe's concerns:
> 
>    - use class-based exceptions
>    - clarify that HTTPConnection is designed for *blocking* sockets
>    - conn.close() followed by conn.send() will reopen the socket. This
>      could lead to programming errors. I'll add a class-based default flag
>      to disable this behavior.
>    - in request(), we check for errno==32 ... what to do on Windows?
> 
> 
> I will implement these changes in small chunks so that each can be
> reviewed in my CVS repository. The history is available at:
> 
>     http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/

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



From moshez at math.huji.ac.il  Sun Jun 11 13:58:28 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sun, 11 Jun 2000 14:58:28 +0300 (IDT)
Subject: [Python-Dev] more on httplib
In-Reply-To: <20000611040150.K19484@lyra.org>
Message-ID: <Pine.GSO.4.10.10006111414220.12067-100000@sundial>

On Sun, 11 Jun 2000, Greg Stein wrote:

>   3) I want to remove a "feature" of the old HTTP class. This would be a
>      change in behavior, but (IMO) minor. Specifically, if the Status-Line
>      is malformed, the old httplib.py would return (-1, <malformed line>,
>      None) and store <file ob hooked to socket> into self.file. Nominally,
>      that file object allows a client to read more data from the socket
>      after the parse problem on the malformed Status-Line. I think it is
>      useless, unused by any clients out there, and it causes me pain to
>      provide it :-)  I'd like to just store None into self.file

What do the old docs say about this?

\begin{methoddesc}{getfile}{}
Return a file object from which the data returned by the server can be
read, using the \method{read()}, \method{readline()} or
\method{readlines()} methods.
\end{methoddesc}

So why not put a "dummy" file: one whose read(), readline() or readlines() 
act as if it was at EOF?
(IOW, the Pythonic equivalent of open("/dev/null"))


-- 
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From akuchlin at cnri.reston.va.us  Sun Jun 11 15:19:48 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sun, 11 Jun 2000 09:19:48 -0400
Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper
In-Reply-To: <20000610224430.E19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 10:44:30PM -0700
References: <200006110429.AAA01719@snark.thyrsus.com> <20000610224430.E19484@lyra.org>
Message-ID: <20000611091948.A27835@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 10:44:30PM -0700, Greg Stein wrote:
>On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote:
>> Greg Stein's correction broke my traceback wrapper.  
>If you'd like, post a copy of the test, and we can debug the wrapper
>and/or test.

I'll leave it to the two of you to figure out what's going on and
submit a corrected version, if necessary.  I did test the simplified
version and it seemed fine, though maybe there's a subtle problem.
I'm off to CA, and will be back on Wednesday.  (Mmmm... hours of plane
hacking...)

--amk



From gstein at lyra.org  Sun Jun 11 21:18:26 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 11 Jun 2000 12:18:26 -0700
Subject: [Python-Dev] more on httplib
In-Reply-To: <Pine.GSO.4.10.10006111414220.12067-100000@sundial>; from moshez@math.huji.ac.il on Sun, Jun 11, 2000 at 02:58:28PM +0300
References: <20000611040150.K19484@lyra.org> <Pine.GSO.4.10.10006111414220.12067-100000@sundial>
Message-ID: <20000611121826.L19484@lyra.org>

On Sun, Jun 11, 2000 at 02:58:28PM +0300, Moshe Zadka wrote:
> On Sun, 11 Jun 2000, Greg Stein wrote:
> 
> >   3) I want to remove a "feature" of the old HTTP class. This would be a
> >      change in behavior, but (IMO) minor. Specifically, if the Status-Line
> >      is malformed, the old httplib.py would return (-1, <malformed line>,
> >      None) and store <file ob hooked to socket> into self.file. Nominally,
> >      that file object allows a client to read more data from the socket
> >      after the parse problem on the malformed Status-Line. I think it is
> >      useless, unused by any clients out there, and it causes me pain to
> >      provide it :-)  I'd like to just store None into self.file
> 
> What do the old docs say about this?
> 
> \begin{methoddesc}{getfile}{}
> Return a file object from which the data returned by the server can be
> read, using the \method{read()}, \method{readline()} or
> \method{readlines()} methods.
> \end{methoddesc}
> 
> So why not put a "dummy" file: one whose read(), readline() or readlines() 
> act as if it was at EOF?
> (IOW, the Pythonic equivalent of open("/dev/null"))

Sure, I can put different things there, but that would also be a change in
semantics.

The backwards compat class, HTTP, preserves the API completely -- even down
to how it reacts in error situations. (although, it *can* raise errors that
it didn't before, when you use methods in the wrong order)

I'd like to make a change in the semantics for this particular error
condition. Where a client used to be able to do:

    errcode, errmsg, hdrs = h.getreply()
    if errcode == -1:
        file = h.getfile()
	print 'ERROR: some kind of error occurred'
	print '    partial read:', `errmsg`
	print '    next 100 bytes:', `file.read(100)`

I'd like to eliminate that "next 100 bytes" ability, and just close the
socket when a protocol error occurs. Before making a change in behavior for
this (central) class, I'd like to get some feedback. Some voting?

Cheers,
-g

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



From andy at robanal.demon.co.uk  Mon Jun 12 13:45:57 2000
From: andy at robanal.demon.co.uk (Andy Robinson)
Date: Mon, 12 Jun 2000 12:45:57 +0100
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <20000610160032.0004A1CFA2@dinsdale.python.org>
Message-ID: <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>


>
> Message: 2
> From: "David Ascher" <DavidA at ActiveState.com>
> To: "Python Developers @ python.org" <python-dev at python.org>
> Subject: RE: [Python-Dev] Japanese Codecs
> Date: Fri, 9 Jun 2000 11:54:03 -0700
> charset="US-ASCII"
>
> > I just wish that these packagers actually become a reality
> > some day... the concept is good, but there currently seem to
> > be no volunteers or companies jumping in :-(
>
> I can't speak for Japanese packagers, but ActiveState will be packaging
> Python in various ways.
>
The handful of Python users who know some Japanese are kind of busy at the
moment, and the codec work takes more than a night or two; I was hoping to
tackle it myself, but as the only Python startup without any venture
funding, it is hard to clear aside the time without a customer; and it also
needs C skills.

I believe we should try and put resources together to fund this work and
ensure it gets done this year.  I can tell you that HP are now well and
truly out of the picture as a sponsor.  AFAIK the organisations who should
talk are at least...
   PythonLabs/BeOpen
   ActiveState
   Digital Garage
   PythonWare / Secret Labs ??? (not sure how rapid their global plans are)
   ReportLab

Are there any others?  Please get in touch with me...

feeling-rather-guilty-as-i18n-sig-coordinator-ly-yrs,

Andy Robinson






From mal at lemburg.com  Mon Jun 12 14:51:11 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 12 Jun 2000 14:51:11 +0200
Subject: [Python-Dev] Japanese Codecs
References: <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>
Message-ID: <3944DCBF.34DA9E4B@lemburg.com>

Andy Robinson wrote:
> 
> > > I just wish that these packagers actually become a reality
> > > some day... the concept is good, but there currently seem to
> > > be no volunteers or companies jumping in :-(
> >
> > I can't speak for Japanese packagers, but ActiveState will be packaging
> > Python in various ways.
> >
> The handful of Python users who know some Japanese are kind of busy at the
> moment, and the codec work takes more than a night or two; I was hoping to
> tackle it myself, but as the only Python startup without any venture
> funding, it is hard to clear aside the time without a customer; and it also
> needs C skills.
>
> I believe we should try and put resources together to fund this work and
> ensure it gets done this year.  I can tell you that HP are now well and
> truly out of the picture as a sponsor. 

How come ...wheren't they the initial sponsors for the i18n of
Python ? 

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From gstein at lyra.org  Mon Jun 12 20:19:07 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 12 Jun 2000 11:19:07 -0700
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>; from andy@robanal.demon.co.uk on Mon, Jun 12, 2000 at 12:45:57PM +0100
References: <20000610160032.0004A1CFA2@dinsdale.python.org> <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>
Message-ID: <20000612111907.B19484@lyra.org>

On Mon, Jun 12, 2000 at 12:45:57PM +0100, Andy Robinson wrote:
> > Message: 2
> > From: "David Ascher" <DavidA at ActiveState.com>
> > To: "Python Developers @ python.org" <python-dev at python.org>
> > Subject: RE: [Python-Dev] Japanese Codecs
> > Date: Fri, 9 Jun 2000 11:54:03 -0700
> > charset="US-ASCII"
> >
> > > I just wish that these packagers actually become a reality
> > > some day... the concept is good, but there currently seem to
> > > be no volunteers or companies jumping in :-(
> >
> > I can't speak for Japanese packagers, but ActiveState will be packaging
> > Python in various ways.
> >
> The handful of Python users who know some Japanese are kind of busy at the
> moment, and the codec work takes more than a night or two; I was hoping to
> tackle it myself, but as the only Python startup without any venture
> funding, it is hard to clear aside the time without a customer; and it also
> needs C skills.
> 
> I believe we should try and put resources together to fund this work and
> ensure it gets done this year.

Um... why is it incumbent upon "us" (for whatever definition of "us" you
want to apply :-) to find/fund the work for the Japanese codecs? Why isn't
this up to the people who want/need it?

Yes, being proactive is a very nice thing to do, but I don't see that we
must be, in this case.

> I can tell you that HP are now well and truly out of the picture as a
> sponsor.

eh? What's going on with that?

Cheers,
-g

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



From bwarsaw at python.org  Mon Jun 12 22:53:10 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 12 Jun 2000 16:53:10 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
Message-ID: <14661.19894.465676.770545@anthem.concentric.net>

Okay, let me just preface this by saying none of the following has
been blessed by Guido in any way.  I'm sure he's still getting nice
and tan and drinking exotic tropical alcohol-based beverages, and not
thinking about Python one little bit. :)

Fred and Jeremy and I had a meeting today and thought about a schedule
/we'd/ like to see for Python 1.6 final.  This may or may not be
feasible but I throw it out here for discussion anyway.

The O'Reilly Open Source conference[1] starts July 17th and it would
be a nice target to release 1.6 final on the 14th, the Friday before
the conference.  We all plan on being there.n

What do we need to do to hit this target?  If we figure a 2 week beta
cycle, 1.6beta1 would have to be released June 30, with probably the
last alpha on June 23.  This is a tight schedule; is it even
feasible?.  Looking at Andrew's TODO list[2], here's what we came up
with:

- import hooks revamped (push this to 1.7)
- update docos to match 1.6 changes (Fred is going to integrate what's
  sitting in his inbox)
- document more undocumented modules (codes - done; unicodedata -
  needs work; mmap & pyexpat - Fred to integrate; curses - needs
  updates; regrtest - push to 1.7, see below)
- Unicode: Compress the size of unicodedatabase (waiting for Chris
  Tismer patches?)
- Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch,
  but none of us know what the state of this is -- is it crucial
  anyway?).
- Unicode: the various XXX items in Misc/unicode.txt (we didn't
  actually find such outstanding issues in this file).
- Delete obsolete subdirs in Demo/ directory (done)
- Refurbish Demo subdirs to be properly documented, match modern
  coding style, etc. (???)
- Fix ./ld_so_aix installation problem on AIX (anybody know more about
  this???)
- Make test/regrtest.py more usable outside of the Python test suite &
  document it.  (push to 1.7)
- Conservative GC, of cycles (this is basically done but needs a lot
  more testing)
- Changes to PyExpat module (Fred says this is done)
- Test the hell out of SRE.  (waiting for /F's complete implementation)
- enable threads by default if OS supports it
- integrate intl/gettext module
- clear the patches and bugs backlog

As we saw it the most critical things that need to get done are
testing the GC stuff and the SRE module.  Of those, the most critical
is SRE since AFAIK, we're still waiting for the final complete code
from /F.  I could be wrong about that.

The last three weren't on Andrew's list.  I'm on the hook for enabling
threads support by default and integrating intl/gettext.  I think
those will just be a couple of days work.

The final one requires Us to go through the outstanding bug and
patches lists and address the critical bugs.

Thoughts?  What have I missed?
-Barry

[1] http://conferences.oreilly.com/oscon2000/

[2] http://starship.python.net/crew/amk/python/1.6-jobs.html



From gstein at lyra.org  Tue Jun 13 02:32:14 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 12 Jun 2000 17:32:14 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <20000612173214.F19484@lyra.org>

On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
> ... disclaimers applied ...
>
> - import hooks revamped (push this to 1.7)

The latest thought had two items here:

1) incorporate feedback into imputil.py.
   [ the feedback is visible at the end of the most recent version:
       http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/
   ]
2) drop imputil into the standard library, but don't go down the "replace
   Python's default mechanism with imputil"

Essentially, this gets imputil out there and usable, but it doesn't directly
impact Python's operation in 1.6.

>...
> - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch,
>   but none of us know what the state of this is -- is it crucial
>   anyway?).

Bill posted some patches. Little feedback. He will be reposting an updated
patch.

>...
> - Conservative GC, of cycles (this is basically done but needs a lot
>   more testing)

I would recommend doing this in small, reviewable steps. I believe there are
a lot of "framework" changes that can occur without actually changing Python
itself. After that first round, which will make adding GC easier, then we
can do Step 2 and add the real GC stuff.

>...

New item:
  - replace httplib.py with Greg's new module. plus docs/test.

>...
> As we saw it the most critical things that need to get done are
> testing the GC stuff and the SRE module.  Of those, the most critical
> is SRE since AFAIK, we're still waiting for the final complete code
> from /F.  I could be wrong about that.

I believe his recent patch (which AMK applied) brings it up to "current".

Cheers,
-g

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



From Vladimir.Marangozov at inrialpes.fr  Tue Jun 13 04:37:23 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Tue, 13 Jun 2000 04:37:23 +0200 (CEST)
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net> from "Barry A. Warsaw" at Jun 12, 2000 04:53:10 PM
Message-ID: <200006130237.EAA10373@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> - document more undocumented modules (codes - done; unicodedata -
>   needs work; mmap & pyexpat - Fred to integrate; curses - needs
>   updates; regrtest - push to 1.7, see below)

+ Write missing bits in the extend/embed docs (me)

Also, last time I ran the 1.6 alpha on AIX, test_mmap failed.
I have to take a closer look at this...

> - Fix ./ld_so_aix installation problem on AIX (anybody know more about
>   this???)

Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem
for building C extensions with distutils than an installation problem per se.
Some time ago, I saw a workaround checked in by Greg. If this is still judged
as a problem, I'd like to hear about it. This is a minor thing. I have yet
to install & run the distutil package on AIX, though, and see what happens.

> - enable threads by default if OS supports it

Who's going to champion this? I recall Greg Stein volunteering for it ;)
(or for something related)

> - Test the hell out of SRE.  (waiting for /F's complete implementation)
...
> As we saw it the most critical things that need to get done are
> testing the GC stuff and the SRE module.  Of those, the most critical
> is SRE since AFAIK, we're still waiting for the final complete code
> from /F.  I could be wrong about that.

It thas been my impression that people are pushing /F for SRE deliveries,
but he feels uncomfortable with a number of Unicode compromises (affecting
the SRE code and/or design???) and has some implementation hesitations.
Add to this the pression of the recent PythonWorks' release. In this context,
if there's something to be finished, it would be nice to stop pushing him
and help him finishing this project. Unfortunately, I can't offer any help
as I don't know much about RE engines.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From bwarsaw at python.org  Tue Jun 13 15:17:07 2000
From: bwarsaw at python.org (bwarsaw at python.org)
Date: Tue, 13 Jun 2000 09:17:07 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
	<200006130237.EAA10373@python.inrialpes.fr>
Message-ID: <14662.13395.520180.272688@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:

    >> - enable threads by default if OS supports it

    VM> Who's going to champion this? I recall Greg Stein volunteering
    VM> for it ;) (or for something related)

This isn't the free-threading stuff, which I think we're pushing back
to 1.7, right?  Just making --with-threads turned on by default if the
OS supports it.

    >> - Test the hell out of SRE.  (waiting for /F's complete
    >> implementation)
    VM> ...
    >> As we saw it the most critical things that need to get done are
    >> testing the GC stuff and the SRE module.  Of those, the most
    >> critical is SRE since AFAIK, we're still waiting for the final
    >> complete code from /F.  I could be wrong about that.

    VM> It thas been my impression that people are pushing /F for SRE
    VM> deliveries, but he feels uncomfortable with a number of
    VM> Unicode compromises (affecting the SRE code and/or design???)
    VM> and has some implementation hesitations.  Add to this the
    VM> pression of the recent PythonWorks' release. In this context,
    VM> if there's something to be finished, it would be nice to stop
    VM> pushing him and help him finishing this
    VM> project. Unfortunately, I can't offer any help as I don't know
    VM> much about RE engines.

Neither do I.  /F, how can we help?

-Barry



From mal at lemburg.com  Tue Jun 13 15:18:59 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 15:18:59 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
		<200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net>
Message-ID: <394634C3.9C217913@lemburg.com>

bwarsaw at python.org wrote:
> 
> >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:
> 
>     >> - enable threads by default if OS supports it
> 
>     VM> Who's going to champion this? I recall Greg Stein volunteering
>     VM> for it ;) (or for something related)
> 
> This isn't the free-threading stuff, which I think we're pushing back
> to 1.7, right?  Just making --with-threads turned on by default if the
> OS supports it.

Ehm, didn't we agree on not enabling this by default ? From what
I've heard there are simply too many problems with thread
implementations which cause Python to break in different ways
(not necessarily Python's faults).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gstein at lyra.org  Tue Jun 13 15:26:08 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 13 Jun 2000 06:26:08 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <394634C3.9C217913@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 03:18:59PM +0200
References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com>
Message-ID: <20000613062608.A19484@lyra.org>

On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote:
> bwarsaw at python.org wrote:
> > 
> > >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:
> > 
> >     >> - enable threads by default if OS supports it
> > 
> >     VM> Who's going to champion this? I recall Greg Stein volunteering
> >     VM> for it ;) (or for something related)
> > 
> > This isn't the free-threading stuff, which I think we're pushing back
> > to 1.7, right?  Just making --with-threads turned on by default if the
> > OS supports it.
> 
> Ehm, didn't we agree on not enabling this by default ? From what
> I've heard there are simply too many problems with thread
> implementations which cause Python to break in different ways
> (not necessarily Python's faults).

Threads are quite fine nowadays. Windows has enabled threads for years.
Recent Linux distros all turn it on.

etc

No sense in being afraid any more. :-)

Cheers,
-g

p.s. and yes: free-threading is post 1.6

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



From jim at interet.com  Tue Jun 13 15:32:33 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Tue, 13 Jun 2000 09:32:33 -0400
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <394637F1.73E24380@interet.com>

Just a heads up that there is a patch in
patches at python.org to fix a bug in zipfile.py.

JimA



From mal at lemburg.com  Tue Jun 13 15:35:26 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 15:35:26 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com> <20000613062608.A19484@lyra.org>
Message-ID: <3946389E.B9C5E2F5@lemburg.com>

Greg Stein wrote:
> 
> On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote:
> > bwarsaw at python.org wrote:
> > >
> > > >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:
> > >
> > >     >> - enable threads by default if OS supports it
> > >
> > >     VM> Who's going to champion this? I recall Greg Stein volunteering
> > >     VM> for it ;) (or for something related)
> > >
> > > This isn't the free-threading stuff, which I think we're pushing back
> > > to 1.7, right?  Just making --with-threads turned on by default if the
> > > OS supports it.
> >
> > Ehm, didn't we agree on not enabling this by default ? From what
> > I've heard there are simply too many problems with thread
> > implementations which cause Python to break in different ways
> > (not necessarily Python's faults).
> 
> Threads are quite fine nowadays. Windows has enabled threads for years.
> Recent Linux distros all turn it on.

Ok, then make it default on Linux and Windows... but leave it
turned off on other platforms which still have problems
such as AIX.

> No sense in being afraid any more. :-)

Naa, not being afraid :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jim at interet.com  Tue Jun 13 15:49:36 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Tue, 13 Jun 2000 09:49:36 -0400
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org>
Message-ID: <39463BF0.823C0366@interet.com>

Greg Stein wrote:
> 
> On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
> > ... disclaimers applied ...
> >
> > - import hooks revamped (push this to 1.7)
> 
> The latest thought had two items here:
> 
> 1) incorporate feedback into imputil.py.
>    [ the feedback is visible at the end of the most recent version:
>        http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/
>    ]
> 2) drop imputil into the standard library, but don't go down the "replace
>    Python's default mechanism with imputil"
> 
> Essentially, this gets imputil out there and usable, but it doesn't directly
> impact Python's operation in 1.6.

I would very much like to see imputil.py in the distribution.  I
currently
use ZIP importing, and I have the ZIP importer class done, except that
it
is based on the old imputil.py.  I think ZIP importing could be a
popular feature.

JimA



From Vladimir.Marangozov at inrialpes.fr  Tue Jun 13 15:54:13 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Tue, 13 Jun 2000 15:54:13 +0200 (CEST)
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <3946389E.B9C5E2F5@lemburg.com> from "M.-A. Lemburg" at Jun 13, 2000 03:35:26 PM
Message-ID: <200006131354.PAA11656@python.inrialpes.fr>

M.-A. Lemburg wrote:
> 
> Ok, then make it default on Linux and Windows... but leave it
> turned off on other platforms which still have problems
> such as AIX.

No, I'd suggest turning it on by default everywhere and provide a
--without-thread configure option if it isn't there yet.

On AIX there are identified compiler/libthread combinations that work
or don't work. They can be detected though and since the compiler is
detected earlier, --with-thread can be automatically disabled with a
notification message about the conflict.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From mal at lemburg.com  Tue Jun 13 16:05:55 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 16:05:55 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
Message-ID: <39463FC3.16D6718@lemburg.com>

Vladimir Marangozov wrote:
> 
> M.-A. Lemburg wrote:
> >
> > Ok, then make it default on Linux and Windows... but leave it
> > turned off on other platforms which still have problems
> > such as AIX.
> 
> No, I'd suggest turning it on by default everywhere and provide a
> --without-thread configure option if it isn't there yet.
> 
> On AIX there are identified compiler/libthread combinations that work
> or don't work. They can be detected though and since the compiler is
> detected earlier, --with-thread can be automatically disabled with a
> notification message about the conflict.

Ok, let me drop in another argument:

How you are going to sell the performance loss due to
enabled thread support even when a script doesn't 
need threads at all ?

How about building two versions of the interpreter per default:
one with threads enabled and one without threads ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gstein at lyra.org  Tue Jun 13 16:09:02 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 13 Jun 2000 07:09:02 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <39463FC3.16D6718@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 04:05:55PM +0200
References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com>
Message-ID: <20000613070902.G19484@lyra.org>

On Tue, Jun 13, 2000 at 04:05:55PM +0200, M.-A. Lemburg wrote:
> Vladimir Marangozov wrote:
> > 
> > M.-A. Lemburg wrote:
> > >
> > > Ok, then make it default on Linux and Windows... but leave it
> > > turned off on other platforms which still have problems
> > > such as AIX.
> > 
> > No, I'd suggest turning it on by default everywhere and provide a
> > --without-thread configure option if it isn't there yet.
> > 
> > On AIX there are identified compiler/libthread combinations that work
> > or don't work. They can be detected though and since the compiler is
> > detected earlier, --with-thread can be automatically disabled with a
> > notification message about the conflict.
> 
> Ok, let me drop in another argument:
> 
> How you are going to sell the performance loss due to
> enabled thread support even when a script doesn't 
> need threads at all ?
> 
> How about building two versions of the interpreter per default:
> one with threads enabled and one without threads ?

Hey, the sky is falling, too.

If people are concerned with the performance and want to eek that gain out,
then they can build with --without-threads

Not a problem.

"Gee. My operating system is too slow because it deals with all these
process and threads. Why can't I have a single-process OS like DOS? It runs
*so* much faster."

:-)

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



From bwarsaw at python.org  Tue Jun 13 16:34:34 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Tue, 13 Jun 2000 10:34:34 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <3946389E.B9C5E2F5@lemburg.com>
	<200006131354.PAA11656@python.inrialpes.fr>
Message-ID: <14662.18042.397439.614107@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:

    VM> On AIX there are identified compiler/libthread combinations
    VM> that work or don't work. They can be detected though and since
    VM> the compiler is detected earlier, --with-thread can be
    VM> automatically disabled with a notification message about the
    VM> conflict.

Can you provide a list of such combinations?

-Barry



From mal at lemburg.com  Tue Jun 13 16:44:20 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 16:44:20 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org>
Message-ID: <394648C4.2A701B5B@lemburg.com>

[enabling threads per default]
> >
> > How you are going to sell the performance loss due to
> > enabled thread support even when a script doesn't
> > need threads at all ?
> >
> > How about building two versions of the interpreter per default:
> > one with threads enabled and one without threads ?
> 
> Hey, the sky is falling, too.
> 
> If people are concerned with the performance and want to eek that gain out,
> then they can build with --without-threads
> 
> Not a problem.
> 
> "Gee. My operating system is too slow because it deals with all these
> process and threads. Why can't I have a single-process OS like DOS? It runs
> *so* much faster."

Oh well... never mind, as long as I can still build my
Python without threads, I'm fine :-)

BTW, what about the idea of adding threads at Python level
that was tossed around a few years ago ? Should be easy to
do given Christian's stackless patches together with the
asyncore libs...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bwarsaw at python.org  Tue Jun 13 16:47:21 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Tue, 13 Jun 2000 10:47:21 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
	<39463FC3.16D6718@lemburg.com>
Message-ID: <14662.18809.468033.931803@anthem.concentric.net>

>>>>> "M" == M  <mal at lemburg.com> writes:

    M> How about building two versions of the interpreter per default:
    M> one with threads enabled and one without threads ?

Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1.

with threads: 8547.01 pystones/second
without threads: 9259.26 pystones/second

So an 8% hit isn't negligible but I think it's acceptable for the
benefit of being confidently able to distribute threaded apps.

-Barry



From petrilli at amber.org  Tue Jun 13 17:02:01 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Tue, 13 Jun 2000 11:02:01 -0400
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14662.18809.468033.931803@anthem.concentric.net>; from bwarsaw@python.org on Tue, Jun 13, 2000 at 10:47:21AM -0400
References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <14662.18809.468033.931803@anthem.concentric.net>
Message-ID: <20000613110201.B25344@trump.amber.org>

Barry A. Warsaw [bwarsaw at python.org] wrote:
> 
> >>>>> "M" == M  <mal at lemburg.com> writes:
> 
>     M> How about building two versions of the interpreter per default:
>     M> one with threads enabled and one without threads ?
> 
> Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1.
> 
> with threads: 8547.01 pystones/second
> without threads: 9259.26 pystones/second
> 
> So an 8% hit isn't negligible but I think it's acceptable for the
> benefit of being confidently able to distribute threaded apps.

Just as a data point, in the "Python problems" with Zope, this, along
with soe idiocy in packaging of RPMs in RedHat are the two biggest
problems we have a the Python level.  People not compiling with
threads turned on, and RedHat's decision to ship the header files
separate than the regular Python files. BLAH!

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From bwarsaw at python.org  Tue Jun 13 16:52:24 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Tue, 13 Jun 2000 10:52:24 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
	<39463FC3.16D6718@lemburg.com>
	<20000613070902.G19484@lyra.org>
	<394648C4.2A701B5B@lemburg.com>
Message-ID: <14662.19112.118940.63296@anthem.concentric.net>

>>>>> "M" == M  <mal at lemburg.com> writes:

    M> BTW, what about the idea of adding threads at Python level
    M> that was tossed around a few years ago ? Should be easy to
    M> do given Christian's stackless patches together with the
    M> asyncore libs...

Definitely not for 1.6!



From mal at lemburg.com  Tue Jun 13 17:17:13 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 17:17:13 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
		<39463FC3.16D6718@lemburg.com>
		<20000613070902.G19484@lyra.org>
		<394648C4.2A701B5B@lemburg.com> <14662.19112.118940.63296@anthem.concentric.net>
Message-ID: <39465079.64174882@lemburg.com>

"Barry A. Warsaw" wrote:
> 
> >>>>> "M" == M  <mal at lemburg.com> writes:
> 
>     M> BTW, what about the idea of adding threads at Python level
>     M> that was tossed around a few years ago ? Should be easy to
>     M> do given Christian's stackless patches together with the
>     M> asyncore libs...
> 
> Definitely not for 1.6!

Sure... just wanted to add a hint for 1.7 :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From DavidA at ActiveState.com  Tue Jun 13 19:31:32 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 13 Jun 2000 10:31:32 -0700
Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming
Message-ID: <PLEJJNOHDIGGLDPOGPJJMEMMCHAA.DavidA@ActiveState.com>

It's that time of year again, the O'Reilly Open Source Convention, including
the Python track, is fast approaching.   You can save up to $280 if you
register by Friday July 16. The event will be held this July 17-20 in
Monterey, California.

Meet all the key Python players, meet fellow Python enthusiasts, learn about
new Python developments, find Python-related jobs, and have fun at this
yearly event in sunny Monterey, CA.

For details on the Python tutorials, see
http://www.oreillynet.com/pub/w/python_tutorials.html

For details on the Python talks, see
http://www.oreillynet.com/pub/w/python_presentations.html

For details on the Conference as a whole, see
http://conferences.oreilly.com/oscon2000/index.html

Looking forward to meeting you there,


-- David Ascher
   OSCON Python Track Program Chair
   Senior Developer, ActiveState Tool Corporation

Students and academics should remember to sign up for reduced fees:
http://conferences.oreilly.com/oscon2000/register/




From DavidA at ActiveState.com  Tue Jun 13 20:00:41 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 13 Jun 2000 11:00:41 -0700
Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJMEMMCHAA.DavidA@ActiveState.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJMEMOCHAA.DavidA@ActiveState.com>

> It's that time of year again, the O'Reilly Open Source 
> Convention, including the Python track, is fast approaching.
> You can save up to $280 if you register by Friday July 16. 

Make that June 19.  Sorry about that.

--david ascher



From mal at lemburg.com  Tue Jun 13 21:25:04 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 21:25:04 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <39468A90.697D1CE5@lemburg.com>

"Barry A. Warsaw" wrote:
> 
> The O'Reilly Open Source conference[1] starts July 17th and it would
> be a nice target to release 1.6 final on the 14th, the Friday before
> the conference.  We all plan on being there.n
> 
> What do we need to do to hit this target?  If we figure a 2 week beta
> cycle, 1.6beta1 would have to be released June 30, with probably the
> last alpha on June 23.  This is a tight schedule; is it even
> feasible?.  Looking at Andrew's TODO list[2], here's what we came up
> with:
> 
> [...]
> - document more undocumented modules (codes - done; unicodedata -
>   needs work; mmap & pyexpat - Fred to integrate; curses - needs
>   updates; regrtest - push to 1.7, see below)

I'll take care of unicodedata. What's "codes" -- or did you mean
codecs ?

> - Unicode: Compress the size of unicodedatabase (waiting for Chris
>   Tismer patches?)

Right...

> - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch,
>   but none of us know what the state of this is -- is it crucial
>   anyway?).

Not crucial, but would be nice to have.

> - Unicode: the various XXX items in Misc/unicode.txt (we didn't
>   actually find such outstanding issues in this file).

There are no more discussion points... at least not in that
file ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bwarsaw at python.org  Tue Jun 13 21:31:51 2000
From: bwarsaw at python.org (bwarsaw at python.org)
Date: Tue, 13 Jun 2000 15:31:51 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
	<39468A90.697D1CE5@lemburg.com>
Message-ID: <14662.35879.156976.61686@anthem.concentric.net>

>>>>> "M" == M  <mal at lemburg.com> writes:

    M> I'll take care of unicodedata. What's "codes" -- or did you
    M> mean codecs ?

Oops, yes, "codecs".

    M> There are no more discussion points... at least not in that
    M> file ;-)

<shudder> :)

-Barry



From gstein at lyra.org  Tue Jun 13 22:11:45 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 13 Jun 2000 13:11:45 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <39463BF0.823C0366@interet.com>; from jim@interet.com on Tue, Jun 13, 2000 at 09:49:36AM -0400
References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org> <39463BF0.823C0366@interet.com>
Message-ID: <20000613131145.O19484@lyra.org>

On Tue, Jun 13, 2000 at 09:49:36AM -0400, James C. Ahlstrom wrote:
> Greg Stein wrote:
> > On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
> > > ... disclaimers applied ...
> > >
> > > - import hooks revamped (push this to 1.7)
> > 
> > The latest thought had two items here:
> > 
> > 1) incorporate feedback into imputil.py.
> >    [ the feedback is visible at the end of the most recent version:
> >        http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/
> >    ]
> > 2) drop imputil into the standard library, but don't go down the "replace
> >    Python's default mechanism with imputil"
> > 
> > Essentially, this gets imputil out there and usable, but it doesn't directly
> > impact Python's operation in 1.6.
> 
> I would very much like to see imputil.py in the distribution.  I
> currently
> use ZIP importing, and I have the ZIP importer class done, except that
> it
> is based on the old imputil.py.  I think ZIP importing could be a
> popular feature.

Yes, this should happen.

In my current setup, I've got a second module named "importers.py" that has
some of the "standard" importers. It would go into there.

Oh, so I guess we'd also want to include importers.py into the distro.

All of this is preconditioned on getting at least some of that imputil work
done that is listed in the TODO area at the bottom of the file... I'm not
sure how soon I'll be able to get to that.

Cheers,
-g

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



From Vladimir.Marangozov at inrialpes.fr  Wed Jun 14 02:57:05 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Wed, 14 Jun 2000 02:57:05 +0200 (CEST)
Subject: [Python-Dev] --with-threads by default (was: Towards 1.6 Final)
In-Reply-To: <14662.18042.397439.614107@anthem.concentric.net> from "Barry A. Warsaw" at Jun 13, 2000 10:34:34 AM
Message-ID: <200006140057.CAA12560@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> 
> >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:
> 
>     VM> On AIX there are identified compiler/libthread combinations
>     VM> that work or don't work. They can be detected though and since
>     VM> the compiler is detected earlier, --with-thread can be
>     VM> automatically disabled with a notification message about the
>     VM> conflict.
> 
> Can you provide a list of such combinations?
> 

This is outlined in Misc/AIX-NOTES, section thread support.
I've heard that recent versions of gcc work as well, so long as the
executable is linked with AIX ld (not GNU ld).

Ideally, IMO, there should be an appropriate AC_TRY_RUN little threaded
program (or a program suite corresponding to different thread libs and or
standards for a given platform) that would disable threads on failure.
This approach has the merit of being applicable to all Unix flavors.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From trentm at activestate.com  Wed Jun 14 07:21:42 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 13 Jun 2000 22:21:42 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <394701D6.37E6F560@yahoo.com>
References: <394701D6.37E6F560@yahoo.com>
Message-ID: <20000613222142.A27523@activestate.com>

On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote:
> Is this a bug or a feature?:
> 
> Python 1.6a2 (#4, Jun  9 2000, 02:22:41)  [GCC 2.95.2 19991024
> (release)] on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
> 
> >>> ''.isdigit()
> 1
> >>> ''.isspace()
> 1
> 

Good point, maybe. The __docs__ say:

"S.isdigit() -> int\n\
\n\
Return 1 if there are only digit characters in S,\n\
0 otherwise.";


static char isspace__doc__[] =
"S.isspace() -> int\n\
\n\
Return 1 if there are only whitespace characters in S,\n\
0 otherwise.";


I am not an English language lawyer so I could see both interpretations from
the doc strings. I agree, that the result with a zero length string is
surprising. 


Hi All,
Which should it be? Sorry, if this has been covered.



Trent


-- 
Trent Mick
trentm at activestate.com



From mal at lemburg.com  Wed Jun 14 10:43:45 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 10:43:45 +0200
Subject: [Python-Dev] Re: stringobject question
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com>
Message-ID: <394745C1.7FA27DCB@lemburg.com>

Trent Mick wrote:
> 
> On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote:
> > Is this a bug or a feature?:
> >
> > Python 1.6a2 (#4, Jun  9 2000, 02:22:41)  [GCC 2.95.2 19991024
> > (release)] on linux2
> > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
> >
> > >>> ''.isdigit()
> > 1
> > >>> ''.isspace()
> > 1
> >
> 
> Good point, maybe. The __docs__ say:
> 
> "S.isdigit() -> int\n\
> \n\
> Return 1 if there are only digit characters in S,\n\
> 0 otherwise.";
> 
> static char isspace__doc__[] =
> "S.isspace() -> int\n\
> \n\
> Return 1 if there are only whitespace characters in S,\n\
> 0 otherwise.";
> 
> I am not an English language lawyer so I could see both interpretations from
> the doc strings. I agree, that the result with a zero length string is
> surprising.
> 
> Hi All,
> Which should it be? Sorry, if this has been covered.

I guess it's a bug... a subtle one though, because in a
certain sense both 1 and 0 are acceptable. But since
'' is considered to be false, I think that returning 0
makes more sense.

I'll fix this to return 0 for emtpy strings and Unicode objects.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From moshez at math.huji.ac.il  Wed Jun 14 10:46:48 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 14 Jun 2000 11:46:48 +0300 (IDT)
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <394745C1.7FA27DCB@lemburg.com>
Message-ID: <Pine.GSO.4.10.10006141145320.2269-100000@sundial>

On Wed, 14 Jun 2000, M.-A. Lemburg wrote:

> > > >>> ''.isdigit()
> > > 1
> > > >>> ''.isspace()
> > > 1
> > >
> > 
> > Good point, maybe. The __docs__ say:
> > 
> > "S.isdigit() -> int\n\
> > \n\
> > Return 1 if there are only digit characters in S,\n\
> > 0 otherwise.";
> > 
> > static char isspace__doc__[] =
> > "S.isspace() -> int\n\
> > \n\
> > Return 1 if there are only whitespace characters in S,\n\
> > 0 otherwise.";
> > 
> > I am not an English language lawyer so I could see both interpretations from
> > the doc strings. I agree, that the result with a zero length string is
> > surprising.
> > 
> > Hi All,
> > Which should it be? Sorry, if this has been covered.
> 
> I guess it's a bug... a subtle one though, because in a
> certain sense both 1 and 0 are acceptable. But since
> '' is considered to be false, I think that returning 0
> makes more sense.
> 
> I'll fix this to return 0 for emtpy strings and Unicode objects.

I just realized something: if you change the semantics to mean "number of
digits", you'll get the right answer for all 0- and 1- length strings
and unicode objects.

just-an-observation-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From mal at lemburg.com  Wed Jun 14 11:18:10 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 11:18:10 +0200
Subject: [Python-Dev] Re: stringobject question
References: <Pine.GSO.4.10.10006141145320.2269-100000@sundial>
Message-ID: <39474DD2.BF51C872@lemburg.com>

Moshe Zadka wrote:
> 
> On Wed, 14 Jun 2000, M.-A. Lemburg wrote:
> 
> > > > >>> ''.isdigit()
> > > > 1
> > > > >>> ''.isspace()
> > > > 1
> > > >
> > >
> > > Good point, maybe. The __docs__ say:
> > >
> > > "S.isdigit() -> int\n\
> > > \n\
> > > Return 1 if there are only digit characters in S,\n\
> > > 0 otherwise.";
> > >
> > > static char isspace__doc__[] =
> > > "S.isspace() -> int\n\
> > > \n\
> > > Return 1 if there are only whitespace characters in S,\n\
> > > 0 otherwise.";
> > >
> > > I am not an English language lawyer so I could see both interpretations from
> > > the doc strings. I agree, that the result with a zero length string is
> > > surprising.
> > >
> > > Hi All,
> > > Which should it be? Sorry, if this has been covered.
> >
> > I guess it's a bug... a subtle one though, because in a
> > certain sense both 1 and 0 are acceptable. But since
> > '' is considered to be false, I think that returning 0
> > makes more sense.
> >
> > I'll fix this to return 0 for emtpy strings and Unicode objects.
> 
> I just realized something: if you change the semantics to mean "number of
> digits", you'll get the right answer for all 0- and 1- length strings
> and unicode objects.

Hmm, the .isXXX() tests should return 1/0 since they test
properties rather than count characters.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From billtut at microsoft.com  Wed Jun 14 12:12:48 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:12:48 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50>

Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?

From mal at lemburg.com  Wed Jun 14 12:19:44 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 12:19:44 +0200
Subject: [Python-Dev] AIX shared library support
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50>
Message-ID: <39475C40.EF9CE51B@lemburg.com>

Bill Tutt wrote:
> 
> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?
> >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> 4.xxx.
> 
> I was all set to integrate the \N{...} support into the Unicode-escape
> encoding, and dynamically load the hash table data in on demand, but
> dynload_aix only cares about module entry points and won't let you specify
> an explicit function name.

Uhm, why do you need to go that deep into the internals
of the import mechanism ? 

Wouldn't is suffice to put the hash table into a _ucnhash module
which get imported on demand (the import mechanism would then
take care of the rest) ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From billtut at microsoft.com  Wed Jun 14 12:12:48 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:12:48 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50>

Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?

From billtut at microsoft.com  Wed Jun 14 12:33:11 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:33:11 -0700
Subject: [Python-Dev] unicode character name patch status
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50>

I was all set to integrate the \N{...} support into the Unicode-escape
encoding, and dynamically load the hash table data in on demand, but
dynload_aix only cares about module entry points and won't let you specify
an explicit function name.

Ugh. So, its question and answer time folks:
1)	If we can't dynamically load the hash table data, is it that big of
a deal?
		Probably only for WinCE, palm pilot, etc, and they already
have patches against CVS.
2)	Or, should I just have a separate encoding?

I'd prefer to pick option #1 since Perl natively supports the syntax in
their strings. The data is all constant read/only data that will be mmapped
directly from the binary, so it only effects working set if the feature is
used.

Barry, Greg, Guido?
The only feedback I got last time I submitted the patch was from MAL, it'd
help if some other folks would comment on it.

Thanks,
Bill










From mal at lemburg.com  Wed Jun 14 12:45:01 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 12:45:01 +0200
Subject: [Python-Dev] unicode character name patch status
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50>
Message-ID: <3947622D.9995572E@lemburg.com>

[Me again, hope you don't mind ;-)]

Bill Tutt wrote:
> 
> I was all set to integrate the \N{...} support into the Unicode-escape
> encoding, and dynamically load the hash table data in on demand, but
> dynload_aix only cares about module entry points and won't let you specify
> an explicit function name.
> 
> Ugh. So, its question and answer time folks:
> 1)      If we can't dynamically load the hash table data, is it that big of
> a deal?
>                 Probably only for WinCE, palm pilot, etc, and they already
> have patches against CVS.
> 2)      Or, should I just have a separate encoding?
> 
> I'd prefer to pick option #1 since Perl natively supports the syntax in
> their strings. The data is all constant read/only data that will be mmapped
> directly from the binary, so it only effects working set if the feature is
> used.

Why can't you use PyImport_Import() to do the dynamic loading and
combine this with the standard unicode-escape codec ?
If it fails (e.g. the user has disabled the module entry in
Setup), then simply raise an exception.

I wouldn't want the hash table around linked statically -- it's
simply to big.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From billtut at microsoft.com  Wed Jun 14 12:48:49 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:48:49 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50>

MAL wrote:

> Bill Tutt wrote:
> > 
> > Is there any particular reason that dynload_aix.c doesn't use AIX's
dlopen?
> > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> > 4.xxx.
> 
> > I was all set to integrate the \N{...} support into the Unicode-escape
> > encoding, and dynamically load the hash table data in on demand, but
> > dynload_aix only cares about module entry points and won't let you
specify
> > an explicit function name.

> Uhm, why do you need to go that deep into the internals
> of the import mechanism ? 

> Wouldn't is suffice to put the hash table into a _ucnhash module
> which get imported on demand (the import mechanism would then
> take care of the rest) ?

It would suffice, but it'd be less efficient (and more work) since I'd then
have to access the data/hash functions through the normal PyObject
mechanisms instead of directly as C functions. That is, I'm trying to avoid
creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then
again, maybe I'm just being too performance sensitive.

The import mechanism got redone weirdly, all of the ways of doing dynamic
loading except AIX encode the idea that the function name must be preceeded
by "init".
Dynload_xxx.c is the wrong place to put that requirement. Whomever calls
_PyImport_GetDynLoadFunc() should handle that issue.

Just as an FYI, the only problem I've found so far with my last patch was
wrt handling Unicode characters with values in the UCS-4 code space. (Not
that there are any yet, but the code must handle that case anyway, sine I
don't want to have to go change it later.)

Bill




From mal at lemburg.com  Wed Jun 14 13:00:50 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 13:00:50 +0200
Subject: [Python-Dev] AIX shared library support
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50>
Message-ID: <394765E2.BFBEA135@lemburg.com>

Bill Tutt wrote:
> 
> MAL wrote:
> 
> > Bill Tutt wrote:
> > >
> > > Is there any particular reason that dynload_aix.c doesn't use AIX's
> dlopen?
> > > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> > > 4.xxx.
> >
> > > I was all set to integrate the \N{...} support into the Unicode-escape
> > > encoding, and dynamically load the hash table data in on demand, but
> > > dynload_aix only cares about module entry points and won't let you
> specify
> > > an explicit function name.
> 
> > Uhm, why do you need to go that deep into the internals
> > of the import mechanism ?
> 
> > Wouldn't is suffice to put the hash table into a _ucnhash module
> > which get imported on demand (the import mechanism would then
> > take care of the rest) ?
> 
> It would suffice, but it'd be less efficient (and more work) since I'd then
> have to access the data/hash functions through the normal PyObject
> mechanisms instead of directly as C functions. That is, I'm trying to avoid
> creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then
> again, maybe I'm just being too performance sensitive.

You could pass a pointer to the char* via a PyCObject. 

I usually export the whole module C API via such an object and it works
great: you can rely on module import to get the magic right and
still have a C API around which you can call directly from
C -- without the need to wrap anything in Python objects.

FYI, mxODBC and mxDateTime are tied together using this mechanism;
look in the mxDateTime.h|c files for details.
 
> The import mechanism got redone weirdly, all of the ways of doing dynamic
> loading except AIX encode the idea that the function name must be preceeded
> by "init".
> Dynload_xxx.c is the wrong place to put that requirement. Whomever calls
> _PyImport_GetDynLoadFunc() should handle that issue.

That's to Greg's address, I guess ;-)
 
> Just as an FYI, the only problem I've found so far with my last patch was
> wrt handling Unicode characters with values in the UCS-4 code space. (Not
> that there are any yet, but the code must handle that case anyway, sine I
> don't want to have to go change it later.)

Why is there a problem there ? Python currently uses UTF16
as native format. UTF-16 surrogates are not supported though...
and probably won't be for a while.

I don't see much of a problem here.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From billtut at microsoft.com  Wed Jun 14 13:10:44 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 04:10:44 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50>

MAL:
> Bill:
> > Just as an FYI, the only problem I've found so far with my last patch
was
> > wrt handling Unicode characters with values in the UCS-4 code space.
(Not
> > that there are any yet, but the code must handle that case anyway, sine
I
> > don't want to have to go change it later.)

> Why is there a problem there ? Python currently uses UTF16
> as native format. UTF-16 surrogates are not supported though...
> and probably won't be for a while.

The rest of Python may not care about UTF-16, but that's no particular
reason to not have this code support generating surrogates if an input
UnicodeData.txt happens to have character names for code points that require
surrogates.

Bill




From mwh21 at cam.ac.uk  Wed Jun 14 13:18:27 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 14 Jun 2000 12:18:27 +0100
Subject: [Python-Dev] Can starship please have its front page back?
Message-ID: <m3d7lk33zw.fsf@atrus.jesus.cam.ac.uk>

I'm not sure if I should ask this here, but I've tried crew at starship
and comp.lang.python, so forgive me please.

There are links all over the place (eg. python.org, oriellynet) to
"http://starship.python.net/", which currently gets the gentle
browsing newbie a rather forbidding, somewhat out-of-date status page.
I don't really think this gives a good impression.  Particularly as
said page is no longer on the machine that had the hard disc
failure...

Cheers,
M.




From mal at lemburg.com  Wed Jun 14 13:36:25 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 13:36:25 +0200
Subject: [Python-Dev] AIX shared library support
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50>
Message-ID: <39476E39.E4163D20@lemburg.com>

Bill Tutt wrote:
> 
> MAL:
> > Bill:
> > > Just as an FYI, the only problem I've found so far with my last patch
> was
> > > wrt handling Unicode characters with values in the UCS-4 code space.
> (Not
> > > that there are any yet, but the code must handle that case anyway, sine
> I
> > > don't want to have to go change it later.)
> 
> > Why is there a problem there ? Python currently uses UTF16
> > as native format. UTF-16 surrogates are not supported though...
> > and probably won't be for a while.
> 
> The rest of Python may not care about UTF-16, but that's no particular
> reason to not have this code support generating surrogates if an input
> UnicodeData.txt happens to have character names for code points that require
> surrogates.

True. As long as the design permitts generating surrogates,
there should be no problem.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From Vladimir.Marangozov at inrialpes.fr  Wed Jun 14 16:48:01 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Wed, 14 Jun 2000 16:48:01 +0200 (CEST)
Subject: [Python-Dev] AIX shared library support
In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> from "Bill Tutt" at Jun 14, 2000 03:12:48 AM
Message-ID: <200006141448.QAA14090@python.inrialpes.fr>

Bill Tutt wrote:
> 
> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?
> >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> 4.xxx.

Historically, the dlopen interface (originally a Sun thing) was included
as a standard library (libdl.a) starting from AIX 4.3 (or 4.2). It doesn't
exist on AIX 3.x and AIX 4.1.x. There was a dlopen emulation library,
though, written by an old AIX guru, but it had to be installed manually
on these versions of AIX.

Then, slowly, IBM started to be more receptive about some defacto standards,
included libdl.a in the standard AIX distribution and introduced the -G flag
in ld (a la Sun and others) which adds -ldl to the link automatically.
But all this really works on AIX 4.3 and up.

So what is implemented in Python relies on lower-level dynamic linker
primitives that exist on all AIX releases. Furthermore, our original
goal was not to provide a complete (per symbol) runtime linker, hence
the current state of affairs. The 'init' entry point convention is a
Python convention.  It can be changed at link time, but still, there is
no a full featured dynamic linker and there is no reason to have it in
Python. Python wisely limits itself to the loading of a shared object (lib)
in memory, then to invoke an init function, without going into subtle
per-platform dynlinking details, which would have been a royal pain to
maintain anyway.

I second MAL's opinions: you really don't want to be so deep about
dynloads and it's better to fit in the current architecture. Personnally,
I won't care if my smiley takes half a second to load in memory. :-)

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From gstein at lyra.org  Wed Jun 14 17:00:23 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 14 Jun 2000 08:00:23 -0700
Subject: [Python-Dev] unicode character name patch status
In-Reply-To: <3947622D.9995572E@lemburg.com>; from mal@lemburg.com on Wed, Jun 14, 2000 at 12:45:01PM +0200
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> <3947622D.9995572E@lemburg.com>
Message-ID: <20000614080023.L27338@lyra.org>

On Wed, Jun 14, 2000 at 12:45:01PM +0200, M.-A. Lemburg wrote:
>...
> Bill Tutt wrote:
> > I was all set to integrate the \N{...} support into the Unicode-escape
> > encoding, and dynamically load the hash table data in on demand, but
> > dynload_aix only cares about module entry points and won't let you specify
> > an explicit function name.
> > 
> > Ugh. So, its question and answer time folks:
> > 1)      If we can't dynamically load the hash table data, is it that big of
> > a deal?
> >                 Probably only for WinCE, palm pilot, etc, and they already
> > have patches against CVS.
> > 2)      Or, should I just have a separate encoding?
> > 
> > I'd prefer to pick option #1 since Perl natively supports the syntax in
> > their strings. The data is all constant read/only data that will be mmapped
> > directly from the binary, so it only effects working set if the feature is
> > used.
> 
> Why can't you use PyImport_Import() to do the dynamic loading and
> combine this with the standard unicode-escape codec ?
> If it fails (e.g. the user has disabled the module entry in
> Setup), then simply raise an exception.
> 
> I wouldn't want the hash table around linked statically -- it's
> simply to big.

I'm with MAL. Use Python's import mechanism. That gets you the dynamic load
stuff no problem. It *also* handles the case where the module is statically
linked.

If you go play games with the dynload stuff, then it would be a bitch to
build a single, statically-linked executable.

Cheers,
-g

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



From akuchlin at cnri.reston.va.us  Wed Jun 14 18:13:23 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Wed, 14 Jun 2000 12:13:23 -0400
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <20000614121323.A13993@amarok.cnri.reston.va.us>

On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
>If we figure a 2 week beta cycle, ...

Unicode support, a new regex engine, various minor backward
incompatible changes that may or may not cause people problems...  a 2-week
beta seems too short.

--amk



From billtut at microsoft.com  Wed Jun 14 18:29:30 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 09:29:30 -0700
Subject: [Python-Dev] unicode character name patch status
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>


> From: Greg Stein [mailto:gstein at lyra.org]

> I'm with MAL. Use Python's import mechanism. That gets you 
> the dynamic load
> stuff no problem. It *also* handles the case where the module 
> is statically
> linked.
> 

Ok, ok, so much for the idea about modifying as few lines as possible in my
patch. :)

> If you go play games with the dynload stuff, then it would be 
> a bitch to
> build a single, statically-linked executable.
> 

Nah, thats what the config.h hAVE_... for dynamic load support #define is
for. :)

Bill



From trentm at activestate.com  Wed Jun 14 19:36:32 2000
From: trentm at activestate.com (Trent Mick)
Date: Wed, 14 Jun 2000 10:36:32 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <394745C1.7FA27DCB@lemburg.com>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com>
Message-ID: <20000614103632.C29778@activestate.com>

On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote:
> 
> I guess it's a bug... a subtle one though, because in a
> certain sense both 1 and 0 are acceptable. But since
> '' is considered to be false, I think that returning 0
> makes more sense.
> 
> I'll fix this to return 0 for emtpy strings and Unicode objects.

These are copied from Java, are they not? What do the Java equivalents
return?

Trent



-- 
Trent Mick
trentm at activestate.com



From gstein at lyra.org  Wed Jun 14 23:52:08 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 14 Jun 2000 14:52:08 -0700
Subject: [Python-Dev] unicode character name patch status
In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>; from billtut@microsoft.com on Wed, Jun 14, 2000 at 09:29:30AM -0700
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>
Message-ID: <20000614145208.D28280@lyra.org>

On Wed, Jun 14, 2000 at 09:29:30AM -0700, Bill Tutt wrote:
> > From: Greg Stein [mailto:gstein at lyra.org]
>...
> > If you go play games with the dynload stuff, then it would be 
> > a bitch to
> > build a single, statically-linked executable.
> 
> Nah, thats what the config.h hAVE_... for dynamic load support #define is
> for. :)

Just to beat a dead horse here: no. Just because config.h says that I
*could* dynamically load doesn't mean that I *want* to. If I want to build a
mother, static Python and I want the name table bundled in, then any dynamic
loading that you make explicit is just going to gum up the process.

Now shut up, and drink your Kool-Aid. :-)

Cheers,
-g

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



From thomas at xs4all.net  Thu Jun 15 19:53:27 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 15 Jun 2000 19:53:27 +0200
Subject: [Python-Dev] Augmented assignment
Message-ID: <20000615195327.R8000@xs4all.nl>

I'd like some (minor) feedback on the augmented assignment thing I'm working
on. I understand Guido is the only one who accepts patches like this, and
appreciate that, but I'm hoping someone can at least tell me what I'm doing
wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
flap, just tell me so and I'll calm down.

I also appreciate the fact that the patch is quite large, and not many
people have the time to scrutinize each version, so I'll summerize the
issues I'm uncertain about.

 * The patch needs to add a new type of opcode, one that takes 2 arguments.
This is because the opcodes that load, change and store a name need one
argument for the index in the name table (or local variable number), and one
argument for the actual operation.

It could also work by using PyInt or another PyObject to pass the extra
argument on the stack, but I don't think pushing a non-PyObject-pointer onto
the stack is a good idea. Adding 2-argument opcodes seemed the easiest
solution.

However, I'm not really into Python-hacking (or was, I should say, because
it's great fun) and the python-dev list doesn't seem to be searchable ;) so
I can't know if this issue has come up before. Has it ? Would the new
opcode-type be an unsurpassable problem ? should I use the stack instead ?

* The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries
in the PyNumberMethods struct and 2 new entries in the PySequenceMethods
struct. Would that conceivably be a problem ? I've heard people on the
python-list complain about this ;-P

 * Should I start sending the patch, in pieces, to the patches-list, or is
it a wasted effort because noone will touch it until Guido is back ? If I
should send it, should I send it in one large patch (minus autogenerated
files) or in nice functionality-sized pieces ?

 * How 'cool' does Guido actually think this syntax is ? Apparently the
subject has come up a few times ;) and I got positive signals from both Tim
and Guido, but if the patch won't go in as a patch, and won't actually be
used other than some inspiration for a future rewrite of the CPython core,
I'm not going to worry too much about the patch ;)

I'm trying to get my boss to send me to OSCON2000 to harass Guido about
these issues himself, but he (my boss) isn't co-operating ;-P (Not
suprising, as Python isn't quite part of my job description, *snif*)

Regards,

-- 
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  Thu Jun 15 20:12:50 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 15 Jun 2000 20:12:50 +0200
Subject: [Python-Dev] Augmented assignment
References: <20000615195327.R8000@xs4all.nl>
Message-ID: <39491CA2.2BDC0DDC@lemburg.com>

Thomas Wouters wrote:
> 
> I'd like some (minor) feedback on the augmented assignment thing I'm working
> on. I understand Guido is the only one who accepts patches like this, and
> appreciate that, but I'm hoping someone can at least tell me what I'm doing
> wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> flap, just tell me so and I'll calm down.

I'd make this a 1.7 issue. 1.6 should go into the stabilization
phase and big complicated patches like yours should receive some
more design and concept discussion before getting checked in.

BTW, with "augmented assign" I suppose you mean things like
a += 1 and b *= 2, right ?

> I also appreciate the fact that the patch is quite large, and not many
> people have the time to scrutinize each version, so I'll summerize the
> issues I'm uncertain about.
> 
>  * The patch needs to add a new type of opcode, one that takes 2 arguments.
> This is because the opcodes that load, change and store a name need one
> argument for the index in the name table (or local variable number), and one
> argument for the actual operation.
> 
> It could also work by using PyInt or another PyObject to pass the extra
> argument on the stack, but I don't think pushing a non-PyObject-pointer onto
> the stack is a good idea. Adding 2-argument opcodes seemed the easiest
> solution.
> 
> However, I'm not really into Python-hacking (or was, I should say, because
> it's great fun) and the python-dev list doesn't seem to be searchable ;) so
> I can't know if this issue has come up before. Has it ? Would the new
> opcode-type be an unsurpassable problem ? should I use the stack instead ?

Any reason you can't do this with the existing op codes ?

E.g. a += b

1. load a
2. load b
3. add
4. store a

> * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries
> in the PyNumberMethods struct and 2 new entries in the PySequenceMethods
> struct. Would that conceivably be a problem ? I've heard people on the
> python-list complain about this ;-P

More generic solutions are usually more accepted.

BTW, before hacking too much into this, you ought to consider
that we are planning for rich comparisons and decentralized
coercion in 1.7 (this was planned for 1.6, but David and I
got carried away with other things).
 
I wouldn't want to have to hack 11 new slots to get this right...

>  * Should I start sending the patch, in pieces, to the patches-list, or is
> it a wasted effort because noone will touch it until Guido is back ? If I
> should send it, should I send it in one large patch (minus autogenerated
> files) or in nice functionality-sized pieces ?

Better put it on a web page and inform python-dev of new features,
enhancements, etc.
 
>  * How 'cool' does Guido actually think this syntax is ? Apparently the
> subject has come up a few times ;) and I got positive signals from both Tim
> and Guido, but if the patch won't go in as a patch, and won't actually be
> used other than some inspiration for a future rewrite of the CPython core,
> I'm not going to worry too much about the patch ;)

Having a patch is good for discussion, whether it gets incorporated
is a different issue ;-)
 
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bckfnn at worldonline.dk  Thu Jun 15 20:16:03 2000
From: bckfnn at worldonline.dk (Finn Bock)
Date: Thu, 15 Jun 2000 18:16:03 GMT
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <20000614103632.C29778@activestate.com>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com>
Message-ID: <39491d4f.4591422@smtp.worldonline.dk>

>On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote:
>> 
>> I guess it's a bug... a subtle one though, because in a
>> certain sense both 1 and 0 are acceptable. But since
>> '' is considered to be false, I think that returning 0
>> makes more sense.
>> 
>> I'll fix this to return 0 for emtpy strings and Unicode objects.

[Trent Mick]

>These are copied from Java, are they not? What do the Java equivalents
>return?

The .isXX methods does not exists on java strings, only on the Character
class. So in java they can never be called on anything with length 0.

regards,
finn



From trentm at activestate.com  Thu Jun 15 20:28:57 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 15 Jun 2000 11:28:57 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <39491d4f.4591422@smtp.worldonline.dk>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk>
Message-ID: <20000615112857.A4508@activestate.com>

On Thu, Jun 15, 2000 at 06:16:03PM +0000, Finn Bock wrote:
> >These are copied from Java, are they not? What do the Java equivalents
> >return?
> 
> The .isXX methods does not exists on java strings, only on the Character
> class. So in java they can never be called on anything with length 0.
> 

Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
unless others have any opposition.

Trent

-- 
Trent Mick
trentm at activestate.com



From fdrake at beopen.com  Thu Jun 15 20:34:02 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 15 Jun 2000 14:34:02 -0400 (EDT)
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <20000615112857.A4508@activestate.com>
References: <394701D6.37E6F560@yahoo.com>
	<20000613222142.A27523@activestate.com>
	<394745C1.7FA27DCB@lemburg.com>
	<20000614103632.C29778@activestate.com>
	<39491d4f.4591422@smtp.worldonline.dk>
	<20000615112857.A4508@activestate.com>
Message-ID: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com>

Trent Mick writes:
 > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
 > unless others have any opposition.

  This sounds good to me.
  Marc-Andre, go ahead and checkin anything that isn't already in
whenever you're ready; I've not seen any hints of opposition yet, and
there's been enough waiting to just check it in.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From trentm at activestate.com  Thu Jun 15 20:58:27 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 15 Jun 2000 11:58:27 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com>
Message-ID: <20000615115827.A4657@activestate.com>

On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote:
> 
> Trent Mick writes:
>  > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
>  > unless others have any opposition.
> 
>   This sounds good to me.
>   Marc-Andre, go ahead and checkin anything that isn't already in
> whenever you're ready; I've not seen any hints of opposition yet, and
> there's been enough waiting to just check it in.
> 


From mal at lemburg.com  Thu Jun 15 21:10:43 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 15 Jun 2000 21:10:43 +0200
Subject: [Python-Dev] Re: stringobject question
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> <20000615115827.A4657@activestate.com>
Message-ID: <39492A33.75440AA4@lemburg.com>

Trent Mick wrote:
> 
> On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote:
> >
> > Trent Mick writes:
> >  > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
> >  > unless others have any opposition.
> >
> >   This sounds good to me.
> >   Marc-Andre, go ahead and checkin anything that isn't already in
> > whenever you're ready; I've not seen any hints of opposition yet, and
> > there's been enough waiting to just check it in.
> >
> 
> >From what I have seen it is already in.

Right ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Thu Jun 15 21:21:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 15 Jun 2000 15:21:40 -0400 (EDT)
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <39492A33.75440AA4@lemburg.com>
References: <394701D6.37E6F560@yahoo.com>
	<20000613222142.A27523@activestate.com>
	<394745C1.7FA27DCB@lemburg.com>
	<20000614103632.C29778@activestate.com>
	<39491d4f.4591422@smtp.worldonline.dk>
	<20000615112857.A4508@activestate.com>
	<14665.8602.65230.481663@cj42289-a.reston1.va.home.com>
	<20000615115827.A4657@activestate.com>
	<39492A33.75440AA4@lemburg.com>
Message-ID: <14665.11460.597390.222317@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Trent Mick wrote:
 > > >From what I have seen it is already in.
 > 
 > Right ;-)

  I may have mentioned that I've been losing track of all the
patches.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From thomas at xs4all.net  Thu Jun 15 23:41:53 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 15 Jun 2000 23:41:53 +0200
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <39491CA2.2BDC0DDC@lemburg.com>; from mal@lemburg.com on Thu, Jun 15, 2000 at 08:12:50PM +0200
References: <20000615195327.R8000@xs4all.nl> <39491CA2.2BDC0DDC@lemburg.com>
Message-ID: <20000615234153.S8000@xs4all.nl>

On Thu, Jun 15, 2000 at 08:12:50PM +0200, M.-A. Lemburg wrote:

> > I'd like some (minor) feedback on the augmented assignment thing I'm working
> > on. I understand Guido is the only one who accepts patches like this, and
> > appreciate that, but I'm hoping someone can at least tell me what I'm doing
> > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> > flap, just tell me so and I'll calm down.

> I'd make this a 1.7 issue. 1.6 should go into the stabilization
> phase and big complicated patches like yours should receive some
> more design and concept discussion before getting checked in.

That's more or less what I figured, though I wasn't aware of the revised
schedule on 1.6 ;)

> BTW, with "augmented assign" I suppose you mean things like
> a += 1 and b *= 2, right ?

Yes; All binary operands, to be exact:

'+=' | '-=' | '*=' | '/=' | '%=' | '&=' | '|=' | '^=' | '<<=' | '>>=' | '**='

> Any reason you can't do this with the existing op codes ?
> 
> E.g. a += b
> 
> 1. load a
> 2. load b
> 3. add
> 4. store a

Yes: It wouldn't be thread-safe, and it would be impossible (or at least
very hard and complicated) to see the difference between 'a += b' and 'a = a
+ b', which would make it very hard to make them functionally different.

The patch not only adds the syntax (Michael Hudsons' patch did that, roughly
how you describe it) but also adds generic semantics for in-place operations
on builtin types, extension types and classes.

> > * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries
> > in the PyNumberMethods struct and 2 new entries in the PySequenceMethods
> > struct. Would that conceivably be a problem ? I've heard people on the
> > python-list complain about this ;-P

> More generic solutions are usually more accepted.

I thought so, but I didn't see a good, simple addition to the API that
wasn't too complicated. What it adds now is 'PyNumber_InPlaceAdd()', which
is functionally the same as 'PyNumber_Add()', except that the left-hand-side
object is given the chance to define the operation in-place. That's also
where the new PyNumberMethods/PySequenceMethods members come in.

> BTW, before hacking too much into this, you ought to consider
> that we are planning for rich comparisons and decentralized
> coercion in 1.7 (this was planned for 1.6, but David and I
> got carried away with other things).

Too late. Most, if not all, of the patch is already written. Not that that's
a reason to accept it, not at all ;)

> I wouldn't want to have to hack 11 new slots to get this right...

I'm not sure if that's necessary, but I'll have to look into your
comparison/coercion work before I can say that for sure. In any case, I'd be
perfectly happy with adjusting the augmented-assignment patch to the
comparison/coercion change, instead of the other way 'round ;)

> >  * Should I start sending the patch, in pieces, to the patches-list, or is
> > it a wasted effort because noone will touch it until Guido is back ? If I
> > should send it, should I send it in one large patch (minus autogenerated
> > files) or in nice functionality-sized pieces ?

> Better put it on a web page and inform python-dev of new features,
> enhancements, etc.

The webpage is already there, with the version I sent to python-list last
Friday. That patch is missing quite a few things, but it serves as an
example of what it should do: http://www.xs4all.nl/~thomas/python/
I hope to upload an almost-finished version tomorrow morning (Amsterdam
time) - if work doesn't intervene again.

> >  * How 'cool' does Guido actually think this syntax is ? Apparently the
> > subject has come up a few times ;) and I got positive signals from both Tim
> > and Guido, but if the patch won't go in as a patch, and won't actually be
> > used other than some inspiration for a future rewrite of the CPython core,
> > I'm not going to worry too much about the patch ;)

> Having a patch is good for discussion, whether it gets incorporated
> is a different issue ;-)

Of course :) The thing is, the patch is actually quite done. What I'm doing
now is more or less auditing and optimizing it, and that is probably a waste
of time if the patch is going to need a complete rewrite anyway. On the
other hand, I'm getting a couple of ideas for optimization of the 'normal'
operations too, so it's not like it's wasted time. I guess I'll start a new
thread on that issue if/when I reach it ;)

Thanx for the feedback!
-- 
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  Thu Jun 15 23:30:45 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Thu, 15 Jun 2000 23:30:45 +0200 (MEST)
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000  7:53:27 pm"
Message-ID: <m132hDp-000DieC@artcom0.artcom-gmbh.de>

Hi!

Thomas Wouters:
> I'd like some (minor) feedback on the augmented assignment thing I'm working
> on. I understand Guido is the only one who accepts patches like this, and
> appreciate that, but I'm hoping someone can at least tell me what I'm doing
> wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> flap, just tell me so and I'll calm down.

Disclaimer: The following is only *my* personal opinion.
But since you have asked for it. ;-)

I don't like this augmented assignment syntax at all! (independent 
from your particular implementation, which I didn't had a look at).  

Augmented assignments are unPythonic because they don't add any new 
functionality to the language.  From what I've seen, all people, 
who ever missed it, were experienced C-programmers.  And C shows 
its inheritance from various assembler languages in its 
augmented assignment and its ++pre and post increment++ and decrement--
operators.  Many of these features were born in the 70s of the
last century:  At that time optimizing was very important and 
compilers were relatively dumb.  This applies in no way to the
situation we have today with Python.

What remains is, that augmented assignments are only a short cut
notation, which introduces more variability to express the same
algorithms and so they hurt readability.  This feature must be learned
additionally, where normal assignment are easiely understood from
school mathematics.  It also introduces many more possibilities to make
subtle mistakes, since it is not obvious (at least to No-C-programmers)
when and how often the index expression will be valuated.  Look at
the following example:

        class Bar:
	    def __init__(self):
	        self.val = 0
	    def __call__(self):
	        self.val = self.val + 1
		return self.val
	bar = Bar()
	foo = range(4)
and than
	foo[bar()] = foo[bar()] + bar()
	print foo
versus
	foo[bar()] += bar()
	print foo

Todays Python forces the programmer to explicitly say, what should happen.

So I think these +=,-=,*= features are evil.  In the same sense as macro
preprocessors are evil in 'C' and 'from module import *' is already evil
in Python.  Add more and more of this stuff and you end up on the dark 
side of programming.

If augmented assignments will ever become part of Python, I would at least
like to see a strong recommendation added to the styleguide not to use 
this feature.

Enough with this rant.

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)



From nascheme at enme.ucalgary.ca  Fri Jun 16 00:26:35 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 15 Jun 2000 16:26:35 -0600
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <m132hDp-000DieC@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200
References: <20000615195327.R8000@xs4all.nl> <m132hDp-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <20000615162635.B11507@acs.ucalgary.ca>

On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote:
> Augmented assignments are unPythonic because they don't add any new 
> functionality to the language.
[...]
> 	foo[bar()] = foo[bar()] + bar()
> versus
> 	foo[bar()] += bar()

Not quite.  I think with the proposed implementation += could
modify the LHS object in place.  This could be a big performance
win for things like NumPy objects.  OTOH, the same effect can be
achieved with a method call:

    foo[bar()].add(bar())

  Neil



From thomas at xs4all.net  Fri Jun 16 00:25:23 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 16 Jun 2000 00:25:23 +0200
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <m132hDp-000DieC@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200
References: <20000615195327.R8000@xs4all.nl> <m132hDp-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <20000616002523.T8000@xs4all.nl>

On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote:

> Thomas Wouters:
> > I'd like some (minor) feedback on the augmented assignment thing I'm working
> > on. I understand Guido is the only one who accepts patches like this, and
> > appreciate that, but I'm hoping someone can at least tell me what I'm doing
> > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> > flap, just tell me so and I'll calm down.

> I don't like this augmented assignment syntax at all! (independent 
> from your particular implementation, which I didn't had a look at).  

> Augmented assignments are unPythonic because they don't add any new 
> functionality to the language. 

[ snip quite good summary of the problems with augmented assignment ]

I agree with almost all of the above, except the statement that they do not
add anything. If augmented assignment was only syntactic sugar I would not
have taken Michael's patch and rewritten it; I do not propose auto-increment
operators, and would have a hard time accepting them.

However, augmented assignment *does* add new functionality, because it is a
way to inform the object that is being operated on, that it can do the
operation in-place if it so wants. Instead of having to create a new object,
which might be costly in cpu and/or memory, and doing the operation on that,
the object can choose to do the operation on itself, and return 'self'. If
the object doesn't want to do that, it doesn't have to be any different from
'x = x + 1'. (In fact, augmented assignment should, and does, fall back to
that.)

>
>
> [ snip good example of indexes-with-sideffect ]
>
>

This actually proves the point of augmented assignment. With the syntax

foo[bar()] += 1

You can see that bar() is only called once, so you *know* what index is
being retrieved, and that the new value is stored in the same place. Using

foo[bar()] = foo[bar()] + 1

you can't see by the expression which value is being retrieved and where the
result is stored. You have to remember the rules about operand evaluation to
see that. Yes, 

foo[bar()] += bar()

is indeed more complicated than the above example, but absolutely not more
complicated than the normal-add version that calls bar() three times.

The augmented assignment syntax is actually clearer and more easy to
explain, in my opinion. You can only (accurately) explain

a = a + 1 

as 'add a and 1, and store the result in a'. However,

a += 1

is simply 'add 1 to a'. 

> So I think these +=,-=,*= features are evil.  In the same sense as macro
> preprocessors are evil in 'C' and 'from module import *' is already evil
> in Python.  Add more and more of this stuff and you end up on the dark 
> side of programming.

Well, I like the odd Star Wars film, but I do not believe that the Dark Side
lies opposite the Right Way. The Right Way can't help but be very close to
the Dark Side. You may dislike macro preprocessors in C, but CPython (and
almost all other C code) do use them alot, for functionality which would
otherwise be very hard (or complicated and unreadable) to achieve. The same
goes for 'from module import *' in Python.

The funny thing is that augmented assignment operators and auto in/decrement
operators might be added to C because they were easier to optimize (I dont
think that was the main reason, but I wasn't there ;) but any halfway decent
C compiler doesn't need that explicitness, and can optimize the 'x = x + 1'
expression directly. Python, however, can (currently) not do that, and
*does* need the added syntax to be able to do optimization, even if only to
let the object know it's safe to operate on itself.

Of course, once there are semantics for inplace-operations, it _might_ be
possible to optimize 'x = x + 1' into 'x += 1' ;)

> If augmented assignments will ever become part of Python, I would at least
> like to see a strong recommendation added to the styleguide not to use 
> this feature.

If such a recommendation was added, the change would be useless. Better get
Guido to not add this feature instead, or Python will end up like Perl ;)
I honestly do not care much wether it gets added or not. If Guido decides
not to add it, I'm certain he has very valid rasons for it, and I dont
assume to know as much about Python, the applicability of Python, the
average usage of Python or the Future of Python as he sees it, as him ;)

I-don't-know-any-of-that-in-fact-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 gmcm at hypernet.com  Fri Jun 16 02:44:38 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 15 Jun 2000 20:44:38 -0400
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <m132hDp-000DieC@artcom0.artcom-gmbh.de>
References: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000  7:53:27 pm"
Message-ID: <1251006162-53585376@hypernet.com>

Peter Funk wrote:

> Augmented assignments are unPythonic because they don't add any
> new functionality to the language.  

Most changes to Python are nothing but syntactic sugar.

In concept, I'm +0.9 on simple "name += val".

I'm -0.9 on "expr += val" if the behavior requires an 
understanding of Python internals, and +0 otherwise (since I 
avoid "expr = expr + val" if possible).

Thomas's statement that the complexity is largely due to 
problems of thread safety is eminently believable, and I doubt 
that the syntactic sugar (which is at least somewhat 
desirable) is worth the price. 

> ....  Many of these features were born in the
> 70s of the last century:  At that time optimizing was very
> important and compilers were relatively dumb.  This applies in no
> way to the situation we have today with Python.

Actually, Python's compiler is very dumb, and optimization is 
still important. So where I would use "expr" 3 times in 3 lines 
in C / C++ and *expect* the compiler to optimize it into one 
evaluation, I have to remind myself to use an extra line and 
compute it once in Python myself. One might argue that that's 
unPythonic, because it inhibits the direct expression of the 
idea. One might, but I won't.
 
> What remains is, that augmented assignments are only a short cut
> notation, which introduces more variability to express the same
> algorithms and so they hurt readability.  

It definitely *improves* the readability of incrementing very-long-
expression. Just not to the point of readability ;-).

> ...  It also introduces many more
> possibilities to make subtle mistakes,

and eliminates othes, such as typos...

> since it is not obvious
> (at least to No-C-programmers) when and how often the index
> expression will be valuated.  Look at the following example:
> 
>         class Bar:
>      def __init__(self):
>          self.val = 0
>      def __call__(self):
>          self.val = self.val + 1
>   return self.val
>  bar = Bar()
>  foo = range(4)
> and than
>  foo[bar()] = foo[bar()] + bar()
>  print foo
> versus
>  foo[bar()] += bar()
>  print foo

To understand the first requires a sufficiently deep 
understanding of how Python works that I doubt the 2nd is 
really much worse. They're both the other side of horrid.
 
I don't care very much myself, but none of these arguments 
are without strong counters (which we've all read many times 
on c.l.py). The only real basis, I think, is whether the changes 
complexify things too much.

- Gordon



From pf at artcom-gmbh.de  Fri Jun 16 09:11:57 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Fri, 16 Jun 2000 09:11:57 +0200 (MEST)
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <1251006162-53585376@hypernet.com> from Gordon McMillan at "Jun 15, 2000  8:44:38 pm"
Message-ID: <m132qIH-000DieC@artcom0.artcom-gmbh.de>

Hi,

[...]
[me]:
> > What remains is, that augmented assignments are only a short cut
> > notation, which introduces more variability to express the same
> > algorithms and so they hurt readability.  

[Gordon McMillan]:
> It definitely *improves* the readability of incrementing very-long-
> expression. Just not to the point of readability ;-).

I agree, that very complicated multidimensional expressions, (possible
mixing tuples, lists, dicts and computations) are even more errorprone
, if you have to repeat them twice just to increment an element.
But than you would use an helper variable to hold the index expression
anyway.

example:

   foo = range(3); bar = range(3); cols = ('red', 'green', 'blue')
   chans = {'red':2, 'green':1, 'blue':0}

   foo[chans[cols[2-bar[0]]]] = foo[chans[cols[2-bar[0]]]] + 1

is indeed ugly.  But

   i = chans[cols[2-bar[0]]]; foo[i] = foo[i] + 1

is at least just as (un)readable as 

   foo[chans[cols[bar[0]]]] += 1

with the exception, that even newbies get a chance to figure out, 
what the former line is supposed to do without having to read a language 
reference manual telling them something about augmented assignments.

But you are right:  This has been discussed often enough on c.l.p.

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)



From effbot at telia.com  Fri Jun 16 18:24:26 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 18:24:26 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
Message-ID: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>

(the eff-bot is back!)

is there any special reason for this restriction:

Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> a = [1, 2, 3]
>>> a.extend((4, 5, 6))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: list.extend() argument must be a list

from the look of it, it should be trivial to change list.extend
to use the abstract sequence API instead of the list API.

has anyone benchmarked the abstract sequence API?  how
much slower is it?  would it be a good idea to treat lists as
a special case, to avoid slowing down existing code?

other comments?

if I don't hear anything, I'll post patches later this weekend.

</F>




From effbot at telia.com  Fri Jun 16 18:41:36 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 18:41:36 +0200
Subject: [Python-Dev] possible Tkinter speedup
Message-ID: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid>

the _flatten method in Tkinter is one of the major performance
bottlenecks for Python/Tk programmers.  the method "flattens"
a nested sequence, by repeatedly adding tuples to each other.

obviously, this isn't very efficient if the sequences are longer
than, say, five to ten items...  and has of course led to claims
like "wxPython is a thousand times faster than Tkinter".

anyway, taking recent changes to Python into account, it should
be possible to speed this up quite a bit.

the old code looked like this:

    def _flatten(tuple):
        res = ()
        for item in tuple:
            if type(item) in (TupleType, ListType):
                res = res + _flatten(item)
            elif item is not None:
                res = res + (item,)
        return res

after a some trials and errors, here's my proposed replacement:

    def _flatten1(seq):
        res = []
        for item in seq:
            if type(item) in (TupleType, ListType):
                res.extend(_flatten1(item))
            elif item is not None:
                res.append(item)
        return res
    
    def _flatten(seq):
        return tuple(_flatten1(seq))

in my tests, this is slighly faster on very short sequences (two
coordinate pairs, which is a common case for e.g. rectangles),
and much faster on long sequences (polylines, polygons).

for example, for a 5000-point line, it's about 15 times faster.
on a 10,000 point line, it's over 50 times faster.  etc.

comments?

can anyone come up with an even faster way to do this?

if I don't hear anything negative, I'll post patches (etc)

</F>

PS. even after this optimization, uiToolkit is still about 100 times
faster than Tkinter, but that's another story ;-)




From effbot at telia.com  Fri Jun 16 18:47:01 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 18:47:01 +0200
Subject: [Python-Dev] Q: is concatenation and append really the same thing?
Message-ID: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid>

Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
>>> (1, 2, 3) + [1, 2, 3]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only append tuple (not "list") to tuple

is "append" really the right word here?

sure confused the hell out of yours truly...  ("there's no
friggin' append call in this code")

</F>




From jeremy at beopen.com  Fri Jun 16 18:45:07 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 16 Jun 2000 12:45:07 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
Message-ID: <14666.22931.521438.936776@localhost.localdomain>

>>>>> "FL" == Fredrik Lundh <effbot at telia.com> writes:

  FL> has anyone benchmarked the abstract sequence API?  how much
  FL> slower is it?  would it be a good idea to treat lists as a
  FL> special case, to avoid slowing down existing code?

The abstract interface is fairly expensive.  The current code uses
PyList_GET_ITEM to access the elements of the list.  The abstract
interface adds two function calls (PySequence_GetItem,
PyList_GetItem).  The first function just does a couple of sanity
checks (verify arg is sequence & that it has get_item).  The second
function verifies that the arg is a list, then does a bounds check.
None of the work that either of these functions does is necessary for
the list case!

In the extended call syntax implementation, I used PySequence_Tuple to
handle non-standard sequences.  Once converted to a tuple, they can be
processed using the macros.  If you support user-defined sequences,
the sanity checking can get pretty hairy if you don't coerce to a
tuple; e.g. the PySequence_Length method can lie!  

I don't remember considering the cost of allocating the new tuple,
which is only used internally.

Jeremy







From thomas at xs4all.net  Fri Jun 16 18:45:14 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 16 Jun 2000 18:45:14 +0200
Subject: [Python-Dev] Augmented assignment, update
Message-ID: <20000616184514.Q26436@xs4all.nl>

I've more or less finished the augmented-assignment patch I posted last
week. It can be found, including a longish explanation, here:

http://www.xs4all.nl/~thomas/python/

(For those who missed it, the previous posting is here:
http://www.python.org/pipermail/python-list/2000-June/060680.html
The link in the posting, however, points to the new patch.)

I do not know if augmented assignment will every be incorporated into Python
(this patch or something entirely different) but at least noone can claim the
groundwork is missing :-)

Feel free to send questions, comments and verbal abuse my way ;)

-- 
Thomas Wouters <thomas at xs4all.net>

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



From mwh21 at cam.ac.uk  Fri Jun 16 18:53:42 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 16 Jun 2000 17:53:42 +0100
Subject: [Python-Dev] Q: is concatenation and append really the same thing?
In-Reply-To: "Fredrik Lundh"'s message of "Fri, 16 Jun 2000 18:47:01 +0200"
References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid>
Message-ID: <m3ln05wort.fsf@atrus.jesus.cam.ac.uk>

"Fredrik Lundh" <effbot at telia.com> writes:

> Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
> >>> (1, 2, 3) + [1, 2, 3]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: can only append tuple (not "list") to tuple
> 
> is "append" really the right word here?

My fault.  I have sent at least one patch to patches at python.org to
change it to

can only concatenate tuple (not "list") to tuple

to bring it into line with listobject.c; here it is again:

Index: Objects/tupleobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v
retrieving revision 2.34
diff -u -r2.34 tupleobject.c
--- Objects/tupleobject.c	2000/06/01 03:12:13	2.34
+++ Objects/tupleobject.c	2000/06/06 16:30:39
@@ -362,7 +362,7 @@
 	PyTupleObject *np;
 	if (!PyTuple_Check(bb)) {
 		PyErr_Format(PyExc_TypeError,
-       		     "can only append tuple (not \"%.200s\") to tuple",
+       		     "can only concatenate tuple (not \"%.200s\") to tuple",
 			     bb->ob_type->tp_name);
 		return NULL;
 	}

HTH, HAND,
Michael




From mal at lemburg.com  Fri Jun 16 18:53:59 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 18:53:59 +0200
Subject: [Python-Dev] possible Tkinter speedup
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid>
Message-ID: <394A5BA7.F001E220@lemburg.com>

Fredrik Lundh wrote:
> 
> the _flatten method in Tkinter is one of the major performance
> bottlenecks for Python/Tk programmers.  the method "flattens"
> a nested sequence, by repeatedly adding tuples to each other.
> 
> obviously, this isn't very efficient if the sequences are longer
> than, say, five to ten items...  and has of course led to claims
> like "wxPython is a thousand times faster than Tkinter".
> 
> anyway, taking recent changes to Python into account, it should
> be possible to speed this up quite a bit.
> 
> the old code looked like this:
> 
>     def _flatten(tuple):
>         res = ()
>         for item in tuple:
>             if type(item) in (TupleType, ListType):
>                 res = res + _flatten(item)
>             elif item is not None:
>                 res = res + (item,)
>         return res
> 
> after a some trials and errors, here's my proposed replacement:
> 
>     def _flatten1(seq):
>         res = []
>         for item in seq:
>             if type(item) in (TupleType, ListType):
>                 res.extend(_flatten1(item))
>             elif item is not None:
>                 res.append(item)
>         return res
> 
>     def _flatten(seq):
>         return tuple(_flatten1(seq))
> 
> in my tests, this is slighly faster on very short sequences (two
> coordinate pairs, which is a common case for e.g. rectangles),
> and much faster on long sequences (polylines, polygons).
> 
> for example, for a 5000-point line, it's about 15 times faster.
> on a 10,000 point line, it's over 50 times faster.  etc.
> 
> comments?

Why not implement this in C and add it to _tkinter.c ?
It might even make a nice standard builtin...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Fri Jun 16 19:02:22 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 13:02:22 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
Message-ID: <14666.23966.437909.949260@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > if I don't hear anything, I'll post patches later this weekend.

  Sounds good to me!  If lists and tuples are special cased, it
shouldn't even matter if the sequence API is too slow -- that's new
functionality for [].extend(), and can be optimized later if it needs
to be.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Fri Jun 16 19:07:40 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 19:07:40 +0200
Subject: [Python-Dev] Q: is concatenation and append really the same thing?
References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid> <m3ln05wort.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <394A5EDC.7431C900@lemburg.com>

Michael Hudson wrote:
> 
> "Fredrik Lundh" <effbot at telia.com> writes:
> 
> > Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
> > >>> (1, 2, 3) + [1, 2, 3]
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > TypeError: can only append tuple (not "list") to tuple
> >
> > is "append" really the right word here?
> 
> My fault.  I have sent at least one patch to patches at python.org to
> change it to
> 
> can only concatenate tuple (not "list") to tuple
> 
> to bring it into line with listobject.c; here it is again:
> 
> Index: Objects/tupleobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v
> retrieving revision 2.34
> diff -u -r2.34 tupleobject.c
> --- Objects/tupleobject.c       2000/06/01 03:12:13     2.34
> +++ Objects/tupleobject.c       2000/06/06 16:30:39
> @@ -362,7 +362,7 @@
>         PyTupleObject *np;
>         if (!PyTuple_Check(bb)) {
>                 PyErr_Format(PyExc_TypeError,
> -                            "can only append tuple (not \"%.200s\") to tuple",
> +                            "can only concatenate tuple (not \"%.200s\") to tuple",
>                              bb->ob_type->tp_name);
>                 return NULL;
>         }
> 

Should be in CVS by now...

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Fri Jun 16 19:13:55 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 13:13:55 -0400 (EDT)
Subject: [Python-Dev] mailbox formats
Message-ID: <14666.24659.9174.717901@cj42289-a.reston1.va.home.com>

  I've been playing with a function to open a mailbox and return the
appropriate type of mailbox object from the mailbox module, but I
don't have examples of anything but mbox style mailboxes to test
with.
  Could anyone send real examples of MMDF, MH, maildir, and Babyl
mailboxes?  The mail can be junk; don't send anything I shouldn't see!
  Essentially, I'd like to see two new functions added to the mailbox
module:  open('name'), which returns a mailbox object opened for
reading, and which('name'), which returns the name of the mailbox
constructor, and possibly a flag indicating whether a
__builtin__.open() is needed.
  Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Fri Jun 16 20:59:39 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 20:59:39 +0200
Subject: [Python-Dev] Announcment list
Message-ID: <394A791B.17F5AEFF@lemburg.com>

Does anybody know about the state of the python-announce
mailing list ?

I've sent an announcement there (about mxCGIPython), but have
only received an error message and got no posting back 
from the list. I posted a note to the postmaster at beopen.com,
but have heard nothing from there yet.

Can somebody please look into this ?!

BTW, what about the announcement list -> c.l.p.a gateway ?
Will that happen anytime soon (or do I have to hack the
headers to post there ? ;-)

Here's the error message:
"""
Subject: 
        failure notice
   Date: 
        13 Jun 2000 11:34:39 -0000
   From: 
        MAILER-DAEMON at starship.beopen.com
     To: 
        mal at lemburg.com

Hi. This is the qmail-send program at starship.beopen.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<clpa at python.net>:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <mal at lemburg.com>
Received: (qmail 31495 invoked from network); 13 Jun 2000 11:34:38 -0000
Received: from dinsdale.cnri.reston.va.us (HELO dinsdale.python.org) (132.151.1.21)
  by starship.beopen.com with SMTP; 13 Jun 2000 11:34:38 -0000
Received: by dinsdale.python.org (Postfix)
        id AD6DD1CDE3; Tue, 13 Jun 2000 07:29:56 -0400 (EDT)
Delivered-To: python-announce-people at python.org
...
"""

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bwarsaw at python.org  Fri Jun 16 21:24:21 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Fri, 16 Jun 2000 15:24:21 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
	<14666.23966.437909.949260@cj42289-a.reston1.va.home.com>
Message-ID: <14666.32485.172984.122789@anthem.concentric.net>

>>>>> "Fred" == Fred L Drake, Jr <fdrake at beopen.com> writes:

    Fred>   Sounds good to me!  If lists and tuples are special cased,
    Fred> it shouldn't even matter if the sequence API is too slow --
    Fred> that's new functionality for [].extend(), and can be
    Fred> optimized later if it needs to be.

This has been a typical implementation strategy for a long while now,
and I think successfully so.  When I removed the distinction between
list and tuple unpacking to allow any sequence unpacking (and
incidently w/o special syntax), I did exactly this.  Special case for
tuples and lists, and if it was neither then use the sequence API.

Jeremy's right that this can get hairy if your as anal as I am about
error checking and refcounting.  In addition to PySequence_Length()
ability to lie, there are all sorts of errors that can happen, which
should abort the whole process and clean up any temporary objects.
Plus you've now got three very similar branches in the code, which
adds its own overhead.

So you should decide whether this situation will be used widely enough
to warrant the extra coding complexity for the performance win.
list.extend() is probably not used too often these days, but it should
be 'cause it's cool.  So maybe it's worth it in this case.

On the other hand, this is a situation that comes up often, and if we
were to really audit the APIs, we'd probably find even more cases
where restrictions to concrete lists or tuples should be relaxed to
accept any sequence.  Maybe there's a way we can factor this out in a
single function which handles this once and for all?

-Barry



From paul at prescod.net  Fri Jun 16 21:22:08 2000
From: paul at prescod.net (Paul Prescod)
Date: Fri, 16 Jun 2000 21:22:08 +0200
Subject: [Python-Dev] Augmented assignment
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <394A7E60.6F715424@prescod.net>

Many people have given examples where the augmented assignment version
is substantially more readable. Others have argued that it is more
explicit in that it says *exactly what you mean* rather than using a
more general operator in a specific (common) situation. Another
important argument is that augmented assignment allows *in place*
assignment for some types. That's really important for matrix math etc.

 All of these arguments convince me that this is not a simple matter of
"another notation for what we already do."

> Augmented assignments are unPythonic because they don't add any new
> functionality to the language.  From what I've seen, all people,
> who ever missed it, were experienced C-programmers.  

That's true, but we should not be ashamed to steal good ideas from other
languages. Probably the only people who would miss __getattr__ would be
SmallTalk programmers and the original proponents of the various
operator overloading features may well have come from C++.

> ...
> This feature must be learned
> additionally, where normal assignment are easiely understood from
> school mathematics.  

Not really!

a=a+1 is totally illegal in basic arithmetic.

> It also introduces many more possibilities to make
> subtle mistakes, since it is not obvious (at least to No-C-programmers)
> when and how often the index expression will be valuated.  

As I understand the proposal, the function will be called exactly as
many times as it is printed in the source code:

> versus
>         foo[bar()] += bar()
>         print foo

Presumably bar() gets called twice.

The only argument against this that is persusaive to me is that it makes
the core Python language larger and thus a (little) harder to learn. My
impression is that the design of the feature has been well done.

My personal opinion is that the cost in education probably outweighs the
benefits in clarity but others who work a lot with matrices etc. would
probably have a different view.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Music is the stuff between the notes." - Claude Debussy




From petrilli at amber.org  Fri Jun 16 21:42:46 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Fri, 16 Jun 2000 15:42:46 -0400
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <394A7E60.6F715424@prescod.net>; from paul@prescod.net on Fri, Jun 16, 2000 at 09:22:08PM +0200
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de> <394A7E60.6F715424@prescod.net>
Message-ID: <20000616154246.A5513@trump.amber.org>

Paul Prescod [paul at prescod.net] wrote:
> That's true, but we should not be ashamed to steal good ideas from other
> languages. Probably the only people who would miss __getattr__ would be
> SmallTalk programmers and the original proponents of the various
> operator overloading features may well have come from C++.

Actually as a good Talker, I write methods for everything, so I almost 
nver use __getattr__ except as a way to force people to use methods
and not directly access attributes. Long story.

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From fdrake at beopen.com  Fri Jun 16 21:42:12 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 15:42:12 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <14666.32485.172984.122789@anthem.concentric.net>
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
	<14666.23966.437909.949260@cj42289-a.reston1.va.home.com>
	<14666.32485.172984.122789@anthem.concentric.net>
Message-ID: <14666.33556.123258.252030@cj42289-a.reston1.va.home.com>

Barry A. Warsaw writes:
 > Jeremy's right that this can get hairy if your as anal as I am about
 > error checking and refcounting.  In addition to PySequence_Length()
 > ability to lie, there are all sorts of errors that can happen, which
 > should abort the whole process and clean up any temporary objects.
 > Plus you've now got three very similar branches in the code, which
 > adds its own overhead.
 > 
 > So you should decide whether this situation will be used widely enough
 > to warrant the extra coding complexity for the performance win.
 > list.extend() is probably not used too often these days, but it should
 > be 'cause it's cool.  So maybe it's worth it in this case.
 > 
 > On the other hand, this is a situation that comes up often, and if we
 > were to really audit the APIs, we'd probably find even more cases
 > where restrictions to concrete lists or tuples should be relaxed to
 > accept any sequence.  Maybe there's a way we can factor this out in a
 > single function which handles this once and for all?

  How about this: special case the list & tuple flavors (since that'll
be roughly what's in there now), and for other sequences, convert to
either a tuple or a list and let it pass through that special case,
keeping a flag to discard the temporary list when done?
  There are two APIs, PySequence_List() and PySequence_Tuple(), which
can take care of a lot of the machinery in dealing with sequences that
lie about their length or otherwise break (during __getitem__() calls
or whatever), that a large part of the work is done.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Fri Jun 16 21:45:16 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 21:45:16 +0200
Subject: [Python-Dev] Augmented assignment
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de> <394A7E60.6F715424@prescod.net>
Message-ID: <394A83CC.98F177DC@lemburg.com>

Paul Prescod wrote:
> > Augmented assignments are unPythonic because they don't add any new
> > functionality to the language.  From what I've seen, all people,
> > who ever missed it, were experienced C-programmers.
> 
> That's true, but we should not be ashamed to steal good ideas from other
> languages. Probably the only people who would miss __getattr__ would be
> SmallTalk programmers and the original proponents of the various
> operator overloading features may well have come from C++.

Don't forget the crowd of people doing environmental acquisition
(you know who they are ;-).

Honestly, I think that __getattr__ is one of the most useful
hooks available on Python objects.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jeremy at beopen.com  Fri Jun 16 22:01:18 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 16 Jun 2000 16:01:18 -0400 (EDT)
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <394A83CC.98F177DC@lemburg.com>
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de>
	<394A7E60.6F715424@prescod.net>
	<394A83CC.98F177DC@lemburg.com>
Message-ID: <14666.34702.801826.453565@localhost.localdomain>

I'm leery of acquisition, but we gotta have __getattr__.

Jeremy

>>>>> "MAL" == M -A Lemburg <mal at lemburg.com> writes:

  MAL> Paul Prescod wrote:
  >> > Augmented assignments are unPythonic because they don't add any
  >> > new functionality to the language.  From what I've seen, all
  >> > people, who ever missed it, were experienced C-programmers.
  >> 
  >> That's true, but we should not be ashamed to steal good ideas
  >> from other languages. Probably the only people who would miss
  >> __getattr__ would be SmallTalk programmers and the original
  >> proponents of the various operator overloading features may well
  >> have come from C++.

  MAL> Don't forget the crowd of people doing environmental
  MAL> acquisition (you know who they are ;-).

  MAL> Honestly, I think that __getattr__ is one of the most useful
  MAL> hooks available on Python objects.




From fdrake at beopen.com  Fri Jun 16 23:44:05 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 17:44:05 -0400 (EDT)
Subject: [Python-Dev] possible Tkinter speedup
In-Reply-To: <394A5BA7.F001E220@lemburg.com>
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid>
	<394A5BA7.F001E220@lemburg.com>
Message-ID: <14666.40869.331831.90682@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Why not implement this in C and add it to _tkinter.c ?

  I think this is the right approach; do you have an implementation?  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From effbot at telia.com  Fri Jun 16 23:50:58 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 23:50:58 +0200
Subject: [Python-Dev] possible Tkinter speedup
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com>
Message-ID: <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid>

mal wrote:
> > for example, for a 5000-point line, it's about 15 times faster.
> > on a 10,000 point line, it's over 50 times faster.  etc.
> > 
> > comments?
> 
> Why not implement this in C and add it to _tkinter.c ?
> It might even make a nice standard builtin...

bang for the buck?

getting a working C version is a whole lot of work, and I'd rather
spend that time on things that can speed things up a whole lot
more [1].  but if it's still raining tomorrow...

</F>

1) http://w1.132.telia.com/~u13208596/tkinter




From effbot at telia.com  Sat Jun 17 00:33:43 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 00:33:43 +0200
Subject: [Python-Dev] possible Tkinter speedup
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com> <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid>
Message-ID: <017101bfd7e2$f2d3a2c0$f2a6b5d4@hagrid>

eff-bot wrote:
> bang for the buck?
> 
> getting a working C version is a whole lot of work

okay, I just proved that I don't know what I'm talking about.  it wasn't
that hard, and the performance boost is rather interesting...

for 5000 vertices:

    Tkinter 1.6:
        10.44 seconds
    Tkinter 1.6 with new flatten:
        0.27 seconds
    Tkinter 1.6 with C version of flatten:
        2.57 milliseconds

patch follows.

</F>




From effbot at telia.com  Sat Jun 17 09:55:16 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 09:55:16 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> <14666.22931.521438.936776@localhost.localdomain>
Message-ID: <003501bfd831$8bb11a60$f2a6b5d4@hagrid>

jeremy wrote:

>   FL> has anyone benchmarked the abstract sequence API?  how much
>   FL> slower is it?  would it be a good idea to treat lists as a
>   FL> special case, to avoid slowing down existing code?
> 
> The abstract interface is fairly expensive.  The current code uses
> PyList_GET_ITEM to access the elements of the list.  The abstract
> interface adds two function calls (PySequence_GetItem,
> PyList_GetItem).  The first function just does a couple of sanity
> checks (verify arg is sequence & that it has get_item).  The second
> function verifies that the arg is a list, then does a bounds check.
> None of the work that either of these functions does is necessary for
> the list case!

just for the record, I just changed some generic sequence code
to something like:

    if (PyList_Check(seq) || PyTuple_Check(seq))
        Py_INCREF(seq);
    else if (PySequence_Check(seq)) {
        seq = PySequence_Tuple(seq);
        if (!seq)
            return NULL;
    } else {
        PyErr_SetString(PyExc_TypeError, "argument must be a sequence");
        return NULL;
    }

    ... allocate PyObject_Length(seq) slots ...

    if (PyList_Check(seq))
        ... list code using PyList_GET_ITEM
    else
        ... tuple code using PyTuple_GET_ITEM

    Py_DECREF(seq);

for the standard case (lists, in this case), this resulted in a
total speedup of 4 times (this includes some other overhead).

so in other words, this construct is more than 4 times faster
than plain use of PySequence_GetItem.

guess it's time to fix a couple of things in PIL...

</F>




From mhammond at skippinet.com.au  Sat Jun 17 10:16:18 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 17 Jun 2000 18:16:18 +1000
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <003501bfd831$8bb11a60$f2a6b5d4@hagrid>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au>

/F:
> just for the record, I just changed some generic sequence code
> to something like:
...
> so in other words, this construct is more than 4 times faster
> than plain use of PySequence_GetItem.

Good stuff!

> guess it's time to fix a couple of things in PIL...

Its a fair bit of code to duplicate everywhere you want the speed increase.
How can we add a similar scheme to the core, so the changes people need to
make are trivial (to the point where the change is zero!)?

Mark.




From effbot at telia.com  Sat Jun 17 10:40:20 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 10:40:20 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au>
Message-ID: <006a01bfd837$ac689840$f2a6b5d4@hagrid>

mark wrote:
> > so in other words, this construct is more than 4 times faster
> > than plain use of PySequence_GetItem.
> 
> Good stuff!
> 
> > guess it's time to fix a couple of things in PIL...
> 
> Its a fair bit of code to duplicate everywhere you want the speed increase.
> How can we add a similar scheme to the core, so the changes people need to
> make are trivial (to the point where the change is zero!)?

the first part is trivial; just add something like this to
Objects/abstract.c:

PyObject*
PySequence_TupleOrList(PyObject* seq)
{
    if (PyList_Check(seq) || PyTuple_Check(seq))
        Py_INCREF(seq);
    else if (PySequence_Check(seq))
        seq = PySequence_Tuple(seq);
    else {
        PyErr_SetString(PyExc_TypeError, "argument must be a sequence");
        seq = NULL;
    }
    return seq;
}

the second parts is harder -- and that's of course where the
real performance boost comes from.  as far as I'm aware, very
few C compilers can "specialize" loops for you...

</F>




From mal at lemburg.com  Sat Jun 17 10:41:25 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 10:41:25 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au>
Message-ID: <394B39B5.B478720E@lemburg.com>

Mark Hammond wrote:
> 
> /F:
> > just for the record, I just changed some generic sequence code
> > to something like:
> ...
> > so in other words, this construct is more than 4 times faster
> > than plain use of PySequence_GetItem.
> 
> Good stuff!
> 
> > guess it's time to fix a couple of things in PIL...
> 
> Its a fair bit of code to duplicate everywhere you want the speed increase.
> How can we add a similar scheme to the core, so the changes people need to
> make are trivial (to the point where the change is zero!)?

We could add special code the standard type to PySequence_GetItem()
et al., but it would still cause a C function call (not much,
but noticable in inner loops).

How about adding some inline markers to the most often
used (and small) routines in the medium level abstract interface
(PySequence_*, PyMapping_*, etc.) ?!

Together with the special code for the native Python types
this should yield a speedup for all extensions by simple
virtue of a recompile... OTOH, changes to these APIs would
need a recompile of the extensions too.

BTW, I've used the same approach as Fredrik in mx.Tools.
It does make great a difference...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From mal at lemburg.com  Sat Jun 17 10:53:20 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 10:53:20 +0200
Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)
References: <20000617000834.C29B41CF4A@dinsdale.python.org>
Message-ID: <394B3C80.248B4CB1@lemburg.com>

cfandrich at 8cs.com wrote:
> 
> Full_Name: Christopher Fandrich
> Version: 1.5.2
> OS: Windows
> Submission from: (NULL) (208.41.174.4)
> 
> I'm embedding Python in an application.  For now, all I'm doing is initializing
> and finalizing Python.
> 
> When I run my app I get a memory leak of 12288 bytes.  The memory is malloc'ed
> by dictresize() which is called by PyDict_SetItem() which is called by
> PyString_InternInPlace().
> 
> For now, I've added
>     PyDict_Clear(interned);
>     interned = NULL;
> to PyString_Fini().  So far it works fine, but I don't know if it's safe to do
> in the grand scheme of things.

I would suggest adding code to dealloc the interned dict
iff it is empty after the sweeping action in PyString_Fini().
I have a feeling that this is not the case though, since interned
strings are used quite a lot in the core interpreter (e.g. in
classobject.c) and these are usually not recovered.

Perhaps we ought to add some code which takes care of cleaning
up all remaining garbage left over after the call to
call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
of all interned strings and cached ints/floats and associated
free lists or dicts.

We'd need new APIs in string|float|intobject.c to implement this.

Thoughts ? Patches ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Sat Jun 17 14:45:57 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 14:45:57 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid>
Message-ID: <00d701bfd859$fd435300$f2a6b5d4@hagrid>

the eff-bot wrote:

> the first part is trivial; just add something like this to
> Objects/abstract.c:
> 
> PyObject*
> PySequence_TupleOrList(PyObject* seq)
> ...
> 
> the second parts is harder -- and that's of course where the
> real performance boost comes from.  as far as I'm aware, very
> few C compilers can "specialize" loops for you...

in the same test setup, moving the PyList_Check inside the
loop gives a 25-30% slowdown (or to look at it from the other
side, 3 times instead of 4 times faster than naive code).

a compromise solution could be to combine the above function
with a macro:

    #define PySequence_TupleOrList_GET_ITEM(seq, index)\
        (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\
        PyTuple_GET_ITEM(seq, index)

(anyone got a better name? ;-)

standard usage:

    seq = PySequence_TupleOrList(seq_in);

    size = PyObject_Length(seq);
    
    for (i = 0; i < size; i++) {
        PyObject* obj = PySequence_TupleOrList_GET_ITEM(seq, i);
        ...
    }

comments?

</F>




From mal at lemburg.com  Sat Jun 17 16:18:26 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 16:18:26 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid>
Message-ID: <394B88B2.EA116971@lemburg.com>

Fredrik Lundh wrote:
> 
> the eff-bot wrote:
> 
> > the first part is trivial; just add something like this to
> > Objects/abstract.c:
> >
> > PyObject*
> > PySequence_TupleOrList(PyObject* seq)
> > ...
> >
> > the second parts is harder -- and that's of course where the
> > real performance boost comes from.  as far as I'm aware, very
> > few C compilers can "specialize" loops for you...
> 
> in the same test setup, moving the PyList_Check inside the
> loop gives a 25-30% slowdown (or to look at it from the other
> side, 3 times instead of 4 times faster than naive code).
> 
> a compromise solution could be to combine the above function
> with a macro:
> 
>     #define PySequence_TupleOrList_GET_ITEM(seq, index)\
>         (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\
>         PyTuple_GET_ITEM(seq, index)
> 
> (anyone got a better name? ;-)
> 
> standard usage:
> 
>     seq = PySequence_TupleOrList(seq_in);
> 
>     size = PyObject_Length(seq);
> 
>     for (i = 0; i < size; i++) {
>         PyObject* obj = PySequence_TupleOrList_GET_ITEM(seq, i);
>         ...
>     }
> 
> comments?

The above looks a lot like an iterator... how about
providing a standard PySequence_Iterate(obj, callback)
with the callback being called for every element of the
sequence ?!

The iterator could then be optimized for lists and tuples.
Not as fast as inlining, but a more generic solution...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Sat Jun 17 16:42:52 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 16:42:52 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com>
Message-ID: <010401bfd86a$5282cca0$f2a6b5d4@hagrid>

mal wrote:
> The above looks a lot like an iterator... how about
> providing a standard PySequence_Iterate(obj, callback)
> with the callback being called for every element of the
> sequence ?!

PySequence_Enumerate, perhaps?

> The iterator could then be optimized for lists and tuples.
> Not as fast as inlining, but a more generic solution...

more generic than useful, imo:

    - it's slower.

    - it's awkward to use: you need to put the state in a
      structure, invert your program logic, etc.

    - it doesn't scale: what if you want to loop over two
      structures?  what if you want to loop over two objects,
      using two different indices?

</F>





From mal at lemburg.com  Sat Jun 17 16:44:47 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 16:44:47 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com> <010401bfd86a$5282cca0$f2a6b5d4@hagrid>
Message-ID: <394B8EDF.57630FE9@lemburg.com>

Fredrik Lundh wrote:
> 
> mal wrote:
> > The above looks a lot like an iterator... how about
> > providing a standard PySequence_Iterate(obj, callback)
> > with the callback being called for every element of the
> > sequence ?!
> 
> PySequence_Enumerate, perhaps?
>
> > The iterator could then be optimized for lists and tuples.
> > Not as fast as inlining, but a more generic solution...
> 
> more generic than useful, imo:
> 
>     - it's slower.
> 
>     - it's awkward to use: you need to put the state in a
>       structure, invert your program logic, etc.
> 
>     - it doesn't scale: what if you want to loop over two
>       structures?  what if you want to loop over two objects,
>       using two different indices?

Or perhaps, use a different iteration technique: the one
used by PyDict_Next(). It doesn't need a callback, but
instead plays with pointers you pass to it via output
variables.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Sat Jun 17 17:44:58 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 17:44:58 +0200
Subject: [Python-Dev] proposal: core support for "fast" sequence iteration
Message-ID: <011901bfd873$00632740$f2a6b5d4@hagrid>

mark wrote:

> Its a fair bit of code to duplicate everywhere you want the speed increase.
> How can we add a similar scheme to the core, so the changes people need to
> make are trivial (to the point where the change is zero!)?

okay, here's my current proposal:

    PyObject* PySequence_Fast(PyObject *o) 

        Return value: New reference. 

        Returns the o as a tuple or a list on success, and
        NULL on failure.  If o doesn't have the right type,
        it is converted to a tuple using PySequence_Tuple.

        This is equivalent to the following Python code:

            if type(o) in (ListType, TupleType):
                return o
            return tuple(o)

        This function is intended to be used together with
        PySequence_Fast_GET_ITEM, for functions that need
        to loop over a read-only sequence as fast as they
        possibly can, while still supporting any object that
        implements the sequence protocol.

    PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i)

        Return value: Borrowed reference. 

        Returns the object at position i, from the sequence
        seq (which must be a list or a tuple).  This is a
        macro, and has no error checking.

        If you need error checking, use PySequence_GetItem.

for the rationale, see my earlier posts in the "list.extend" thread.

unless somebody comes up with a more efficient solution, I'll wrap
this up together with the list.extend patch (first thing tomorrow).

</F>




From gstein at lyra.org  Sat Jun 17 22:52:31 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 17 Jun 2000 13:52:31 -0700
Subject: [Python-Dev] proposal: core support for "fast" sequence iteration
In-Reply-To: <011901bfd873$00632740$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jun 17, 2000 at 05:44:58PM +0200
References: <011901bfd873$00632740$f2a6b5d4@hagrid>
Message-ID: <20000617135231.E29590@lyra.org>

+1

coolness.


On Sat, Jun 17, 2000 at 05:44:58PM +0200, Fredrik Lundh wrote:
> mark wrote:
> 
> > Its a fair bit of code to duplicate everywhere you want the speed increase.
> > How can we add a similar scheme to the core, so the changes people need to
> > make are trivial (to the point where the change is zero!)?
> 
> okay, here's my current proposal:
> 
>     PyObject* PySequence_Fast(PyObject *o) 
> 
>         Return value: New reference. 
> 
>         Returns the o as a tuple or a list on success, and
>         NULL on failure.  If o doesn't have the right type,
>         it is converted to a tuple using PySequence_Tuple.
> 
>         This is equivalent to the following Python code:
> 
>             if type(o) in (ListType, TupleType):
>                 return o
>             return tuple(o)
> 
>         This function is intended to be used together with
>         PySequence_Fast_GET_ITEM, for functions that need
>         to loop over a read-only sequence as fast as they
>         possibly can, while still supporting any object that
>         implements the sequence protocol.
> 
>     PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i)
> 
>         Return value: Borrowed reference. 
> 
>         Returns the object at position i, from the sequence
>         seq (which must be a list or a tuple).  This is a
>         macro, and has no error checking.
> 
>         If you need error checking, use PySequence_GetItem.
> 
> for the rationale, see my earlier posts in the "list.extend" thread.
> 
> unless somebody comes up with a more efficient solution, I'll wrap
> this up together with the list.extend patch (first thing tomorrow).
> 
> </F>
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev

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



From gstein at lyra.org  Sun Jun 18 00:37:26 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 17 Jun 2000 15:37:26 -0700
Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)
In-Reply-To: <394B3C80.248B4CB1@lemburg.com>; from mal@lemburg.com on Sat, Jun 17, 2000 at 10:53:20AM +0200
References: <20000617000834.C29B41CF4A@dinsdale.python.org> <394B3C80.248B4CB1@lemburg.com>
Message-ID: <20000617153726.H29590@lyra.org>

On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote:
>...
> I would suggest adding code to dealloc the interned dict
> iff it is empty after the sweeping action in PyString_Fini().
> I have a feeling that this is not the case though, since interned
> strings are used quite a lot in the core interpreter (e.g. in
> classobject.c) and these are usually not recovered.
> 
> Perhaps we ought to add some code which takes care of cleaning
> up all remaining garbage left over after the call to
> call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
> of all interned strings and cached ints/floats and associated
> free lists or dicts.
> 
> We'd need new APIs in string|float|intobject.c to implement this.
> 
> Thoughts ? Patches ?

I would definitely like to see this, and suggested it to Guido about four
years ago :-)

During my threading work, I looked at all the globals, which includes the
pools and the one-off allocations in classobject.c and friends. I figured it
would be a Good Thing(tm) to write a general object pool API which could be
used by tuples, floats, frames, etc. Having the single implementation of a
pool would mean that we could add thread locks in a single place.

Similarly, for cleanup reasons, I also suggested a general API for
allocating the "constants" and torching them at shutdown.

As we all know, though... suggestions don't mean crap. Code counts. :-)

That said, I'll look into some of this with the free-threading work. That is
all post-1.6, though. It would be great if somebody could do it before then.

Cheers,
-g

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



From Vladimir.Marangozov at inrialpes.fr  Sun Jun 18 01:01:30 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Sun, 18 Jun 2000 01:01:30 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)
In-Reply-To: <20000617153726.H29590@lyra.org> from "Greg Stein" at Jun 17, 2000 03:37:26 PM
Message-ID: <200006172301.BAA01642@python.inrialpes.fr>

Greg Stein wrote:
> 
> On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote:
> >...
> > Perhaps we ought to add some code which takes care of cleaning
> > up all remaining garbage left over after the call to
> > call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
> > of all interned strings and cached ints/floats and associated
> > free lists or dicts.
> > 
> > We'd need new APIs in string|float|intobject.c to implement this.
> > 
> > Thoughts ? Patches ?
> 
> I would definitely like to see this, and suggested it to Guido about four
> years ago :-)
> 
> During my threading work, I looked at all the globals, which includes the
> pools and the one-off allocations in classobject.c and friends. I figured it
> would be a Good Thing(tm) to write a general object pool API which could be
> used by tuples, floats, frames, etc. Having the single implementation of a
> pool would mean that we could add thread locks in a single place.
> 
> Similarly, for cleanup reasons, I also suggested a general API for
> allocating the "constants" and torching them at shutdown.
> 
> As we all know, though... suggestions don't mean crap. Code counts. :-)

pymalloc (the debugging stuff put aside) is an efficient implementation
of this pool concept. The interface just needs to be exported under an
appropriate PyObject_ API, not as a general malloc replacement. Maybe
it needs some more work regarding finalization, but the code is there.
Per pool locking is there too. Maybe it needs to be adjusted wrt the
pool granularity we want.

The various core object allocators would use this API with PyObject_NEW
inlined.

> 
> That said, I'll look into some of this with the free-threading work. That is
> all post-1.6, though. It would be great if somebody could do it before then.

Voila.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From Vladimir.Marangozov at inrialpes.fr  Sun Jun 18 02:50:51 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Sun, 18 Jun 2000 02:50:51 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11
In-Reply-To: <200006172241.PAA02080@slayer.i.sourceforge.net> from "A.M. Kuchling" at Jun 17, 2000 03:41:24 PM
Message-ID: <200006180050.CAA07547@python.inrialpes.fr>

A.M. Kuchling wrote:
>
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060
>
> Modified Files:
>       mmapmodule.c
> Log Message:
> Fix the size() method to return the size of the file on Unix, not the
> size of the mapped area.  This seems to be what the Windows version does.
> This change requires keeping around the fd of the mapped file.

On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
It works okay without the MS_INVALIDATE flag though, so I'd suggest
removing it from msync in the flush and dealloc methods.

Also, it would probably be a good idea to allow optional flags for
flush, as it's done in new_mmap_object, the default being only MS_SYNC.

Given that this module is enabled by default, I think that it needs some
more stress-testing in test_mmap.py. I'll try to add a couple of tests
shortly.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From trentm at activestate.com  Sun Jun 18 05:20:09 2000
From: trentm at activestate.com (Trent Mick)
Date: Sat, 17 Jun 2000 20:20:09 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11
In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr>
References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr>
Message-ID: <20000617202009.A20019@activestate.com>

On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote:
> 
> A.M. Kuchling wrote:
> >
> > Update of /cvsroot/python/python/dist/src/Modules
> > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060
> >
> > Modified Files:
> >       mmapmodule.c
> > Log Message:
> > Fix the size() method to return the size of the file on Unix, not the
> > size of the mapped area.  This seems to be what the Windows version does.
> > This change requires keeping around the fd of the mapped file.
> 
> On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
> It works okay without the MS_INVALIDATE flag though, so I'd suggest
> removing it from msync in the flush and dealloc methods.
> 
> Also, it would probably be a good idea to allow optional flags for
> flush, as it's done in new_mmap_object, the default being only MS_SYNC.
> 
> Given that this module is enabled by default, I think that it needs some
> more stress-testing in test_mmap.py. I'll try to add a couple of tests
> shortly.
> 

Just to add to the mmap fray. The seek() method is broken for any 'whence'
value (seek from start, current, orend) other than the default. Ihave a patch
that fixes that as well as gets mmap'd files working on Linux64 and Win64.
The test_mmap was also extended. The patch is up on SourceForge for your
perusal. :)

https://sourceforge.net/patch/?func=detailpatch&patch_id=100515&group_id=5470

Cheers,
Trent

-- 
Trent Mick
trentm at activestate.com



From mhammond at skippinet.com.au  Sun Jun 18 05:35:00 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 18 Jun 2000 13:35:00 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1
In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEJKCNAA.mhammond@skippinet.com.au>

> Documentation for the mmap module: proofreaders welcomed

OK :-)


> the file handle \var{fileno}, and returns a mmap object.  If you have
> a Python file object, its
> \method{fileno()} method returns the file's handle, which is
> just an integer.

This could be a little clearer - on first reading, I thought you were
talking about the return value.  Maybe something like: "if you wish to pass
an existing Python file object for this parameter, use its
\method{fileno()} method to obtain the fileno."


> \var{tagname}, if specified, is a string giving a tag name for
> the mapping. XXX what is the purpose of the tag name?

Something like: Windows allows you to have many different mappings against
the same file.  If you specify the name of an existing tag, that tag is
opened, otherwise a new tag of this name is created.  If this parameter is
None, the mapping is created without a name.  Avoiding the use of the tag
parameter will assist in keeping your code portable between Unix and
Windows.

> \begin{funcdesc}{mmap}{file, size \optional{, flags, prot}}
> (Unix version) Maps \var{length} bytes from the file specified by the
> file handle \var{fileno}, and returns a mmap object.  If you have a
> Python file object, its \method{fileno()} method returns the file's
> handle, which is just an integer.

I believe you mean the signature to say "fileno" instead of "file" - this
makes it consistent with the Windows signature, and reinforces that this
param is indeed identical.

As a meta-comment, the structure of this implies that the param signatures
are more different than they are - eg, it should be possible to write
portable mmap code in most cases, without concern for the platform.  the
platform only becomes relevant when you use the optional params for each
platform?


> \begin{methoddesc}{read}{\var{num}}
> Return a string containing up to \var{num} bytes taken from the

"taken from" -> "starting from" ??

> \begin{methoddesc}{write_byte}{\var{byte}}
> Write \var{byte} into memory at the current position of
> the file pointer; the file position is advanced by 1.
> \end{methoddesc}

The type of "byte" should be explained - its never clear to me if a "byte"
should be an int or a string of size 1.  In this case, it is the latter.

Looks good!

Mark.




From mhammond at skippinet.com.au  Sun Jun 18 05:35:33 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 18 Jun 2000 13:35:33 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1
In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEJLCNAA.mhammond@skippinet.com.au>

Sorry about that - I meant to send it direct to Andrew...

Mark.




From Vladimir.Marangozov at inrialpes.fr  Sun Jun 18 06:24:05 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Sun, 18 Jun 2000 06:24:05 +0200 (CEST)
Subject: [Python-Dev] Towards selective compilation to native code?
Message-ID: <200006180424.GAA14040@python.inrialpes.fr>

There was a cool seminar the other day here, focusing on embedded &
real-time Java, so I'll throw here some impressions while they're fresh.
One of the presenters talked extensively about compilation strategies and
techniques for Java bytecode to native code, and while I know that Java
is not Python, it would be interesting to, at least, try to project some
of the ideas to Python in the long run, where applicable.

Needless to say, the guy & his environment (ex-OSF, now Silicomp) are
experts in compiler technology and I'm not in a position to comment on
everything, but you may find the second half of the slides enlightening: 
http://cgi-serv.inrialpes.fr/InTech/2000-06-15/ejava-silicomp.ppt

So, the interesting part of the talk was about a "new" compiler
architecture, built upon the concept of "Flash compiling" (quite
unappropriate name), which produces a mixture of the following:

  1. Bytecode
  2. Native code
  3. Native code is compiled selectively on demand and/or ahead of time
     (!= JIT) for "expensive" methods.
  4. Expensive methods are, on one hand, detected by dynamic profiling
     of the bytecode, and OTOH, determined ahead of time according to the
     following 2 simple creteria:
       - methods containing loops
       - methods calling native code from bytecode
           (to avoid bytecode to native and vice versa arg conversion paths
            which are expensive -- btw Python has the same perf. bottleneck)
  5. Everything relies on dyn loading & late binding of native code
     (front-end loads dynamically the back-end, native code is stored
     in the code stream, but linked incrementally & dynamically during
     execution)
  6. The whole thing is designed to avoid code explosion and to preserve
     the advantage of bytecode == small code size, and the presented
     preliminary results are quite optimistic -- the figures differ depending
     on the code size / speed tradeoff.

Of course, this is Java and there's static typing in there, but it
would be interesting to see whether Python can steal something from these
ideas. For instance, I'm trying to foresee what kind of static typing
(i.e. how much static info) would be appropriate in Python from this
point of view but I fail to obtain any realistic image :).
I see most parts of the dyn loading / late binding aspect though --
they are typical for Python.

Hm. Sounds like I'll be harrassing Tim to make him finally write something
valuable for Python ;-)

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From akuchlin at cnri.reston.va.us  Sun Jun 18 06:22:24 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sun, 18 Jun 2000 00:22:24 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11
In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 02:50:51AM +0200
References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr>
Message-ID: <20000618002224.A12729@newcnri.cnri.reston.va.us>

On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote:
>On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
>It works okay without the MS_INVALIDATE flag though, so I'd suggest
>removing it from msync in the flush and dealloc methods.

Ooh, you're right.  The Linux msync man page says "MS_ASYNC specifies
that an update be scheduled, but the call returns immediately.
MS_SYNC asks for an update and waits for it to complete.
MS_INVALIDATE asks to invalidate other mappings of the same file (so
that they can be updated with the fresh values just written)."  So
MS_INVALIDATE seems far too drastic.

>Also, it would probably be a good idea to allow optional flags for
>flush, as it's done in new_mmap_object, the default being only MS_SYNC.

The problem is: does Windows provide equivalent functionality?  (Is
there documentation available online for CreateFileMapping that I
could look at?)

>Given that this module is enabled by default, I think that it needs some
>more stress-testing in test_mmap.py. I'll try to add a couple of tests
>shortly.

Good idea.  I'll try to look at Trent Mick's patch and apply it ASAP
if it checks out.

--amk



From akuchlin at cnri.reston.va.us  Sun Jun 18 07:03:16 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sun, 18 Jun 2000 01:03:16 -0400
Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule
In-Reply-To: <Pine.LNX.4.10.10006171623520.11690-100000@sancho.ccd.uniroma2.it>; from lorenzo@sancho.ccd.uniroma2.it on Sat, Jun 17, 2000 at 04:29:14PM +0200
References: <Pine.LNX.4.10.10006171623520.11690-100000@sancho.ccd.uniroma2.it>
Message-ID: <20000618010316.D12729@newcnri.cnri.reston.va.us>

On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote:
>therefore, here is the change: if we are compiling for linux, define
>_GNU_SOURCE before including mman.h, and all is done. It seems the

Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present,
that doesn't imply that mremap() doesn't work at all; instead, a
resize may fail if the mapping would have to be moved to a different
virtual address.  Quoting from the Linux man page:

       MREMAP_MAYMOVE
              indicates  if  the operation should fail, or change
              the virtual address if the resize cannot be done at
              the current virtual address.

I think the correct fix is to simply specify MREMAP_MAYMOVE if it's
defined, but still support attempting to resize. Possibly the
configure script should also check for mremap()'s existence.

--amk



From lorenzo at sancho.ccd.uniroma2.it  Sun Jun 18 09:39:55 2000
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Sun, 18 Jun 2000 09:39:55 +0200 (CEST)
Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule
In-Reply-To: <20000618010316.D12729@newcnri.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10006180859570.2676-100000@sancho.ccd.uniroma2.it>

On Sun, 18 Jun 2000, Andrew Kuchling wrote:

AK> On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote:
AK> >therefore, here is the change: if we are compiling for linux, define
AK> >_GNU_SOURCE before including mman.h, and all is done. It seems the
AK> 
AK> Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present,
AK> that doesn't imply that mremap() doesn't work at all; instead, a
AK> resize may fail if the mapping would have to be moved to a different
AK> virtual address.  Quoting from the Linux man page:
AK> 
AK>        MREMAP_MAYMOVE
AK>               indicates  if  the operation should fail, or change
AK>               the virtual address if the resize cannot be done at
AK>               the current virtual address.
AK> 
AK> I think the correct fix is to simply specify MREMAP_MAYMOVE if it's
AK> defined, but still support attempting to resize. Possibly the
AK> configure script should also check for mremap()'s existence.
AK> 

I think I've been too dense... Here I see two problems: on one hand, from
what I have understood of python's object, it's much better if the c
pointers are movable in VM on the remap, and the MAYMOVE flag is only
defined in mman.h if _GNU_SOURCE is; on the other hand, we only know
about linux mremap semantics: for what I see in linix mremap(2)

"""
CONFORMING TO
       This  call  is  Linux-specific,  and should not be used in
       programs intended to be portable.   4.2BSD  had  a  (never
       actually  implemented) mremap(2) call with completely dif?
       ferent semantics.
"""

Therefore, I think that really checking for __linux__ and using the
MAYMOVE flag, which is thefined there, is going towards the right way. If
someone else comes out with another kernel supporting a mremap syscall[1],
I think we'll be able to add proper support afterwards. As for the
configure script, on linux we have both mremap and MAYMOVE; if you go to
the <a href="http://www.gnu.org/software/libc/all-M.html">Extended UNIX ABI, M*
</a> Page, 

you'll find:

	GNU Unix98 Unix95 POSIX ISO C SVID 3 4.3BSD XPG
mremap   X

It seems only the systems supported by GNU libc-2 (only linux systems,
then) support mremap...

Have a nice time.


lmc


* Just tried searching for mremap on 
http://www.FreeBSD.org/cgi/man.cgi?query=mmap
and looked around the various BSD derivatives whose man pages are
available there. 

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+




From petrilli at amber.org  Sun Jun 18 20:50:22 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Sun, 18 Jun 2000 14:50:22 -0400
Subject: [Python-Dev] Towards selective compilation to native code?
In-Reply-To: <200006180424.GAA14040@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 06:24:05AM +0200
References: <200006180424.GAA14040@python.inrialpes.fr>
Message-ID: <20000618145022.A13031@trump.amber.org>

Vladimir Marangozov [Vladimir.Marangozov at inrialpes.fr] wrote:
> 
> Of course, this is Java and there's static typing in there, but it
> would be interesting to see whether Python can steal something from these
> ideas. For instance, I'm trying to foresee what kind of static typing
> (i.e. how much static info) would be appropriate in Python from this
> point of view but I fail to obtain any realistic image :).
> I see most parts of the dyn loading / late binding aspect though --
> they are typical for Python.

One might take a look at Smalltalk/X which compiles into C, and has a
pretty (ney very) high performance reputation.  There are some other
Smalltalk implementations taht do this as well.  This would be closer
I think to what Python would use than Java will be.  

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From effbot at telia.com  Sun Jun 18 21:06:45 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sun, 18 Jun 2000 21:06:45 +0200
Subject: [Python-Dev] talking about performance...
Message-ID: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>

consider this little program:

import time, sre

k = u"foo"
p = sre.compile(k)
s = "*"*500 + k + "*"*500

def f1():
    p.search(s)

def f2():
    s.find(k)

def bench(f):
    t0 = time.clock()
    for i in range(100000):
        f()
    print f, time.clock() - t0

bench(f1)
bench(f2)

which prints:

    <function f1 at 7a0680> 2.94704487169
    <function f2 at 7a06a0> 10.5247875425

(Windows 95, 233 MHz)

if I change the k variable to an 8-bit string, it
prints:

    <function f1 at 7a0740> 2.47613520173
    <function f2 at 7a0760> 2.5178698939

(for some reason, sre is still slighty faster...)

so in other words, something in unicode land isn't
as efficient as it should...

</F>




From akuchlin at cnri.reston.va.us  Sun Jun 18 21:20:20 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sun, 18 Jun 2000 15:20:20 -0400
Subject: [Python-Dev] talking about performance...
In-Reply-To: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jun 18, 2000 at 09:06:45PM +0200
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>
Message-ID: <20000618152020.B14713@newcnri.cnri.reston.va.us>

On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote:
>so in other words, something in unicode land isn't
>as efficient as it should...

The relevant bit of findstring() in unicodeobject.c:

    if (direction < 0) {
        for (; end >= start; end--)
            if (Py_UNICODE_MATCH(self, end, substring))
                return end;
    } else {
        for (; start <= end; start++)
            if (Py_UNICODE_MATCH(self, start, substring))
                return start;
    }

And...

#define Py_UNICODE_MATCH(string, offset, substring)\
    (!memcmp((string)->str + (offset), (substring)->str,\
             (substring)->length*sizeof(Py_UNICODE)))

Proposed patch:

Index: unicodeobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
retrieving revision 2.26
diff -u -r2.26 unicodeobject.c
--- unicodeobject.c	2000/06/14 09:18:32	2.26
+++ unicodeobject.c	2000/06/18 19:18:01
@@ -2168,11 +2168,13 @@
 
     if (direction < 0) {
         for (; end >= start; end--)
-            if (Py_UNICODE_MATCH(self, end, substring))
+            if ( *(self->str + end) == *(substring->str) &&
+		 Py_UNICODE_MATCH(self, end, substring))
                 return end;
     } else {
         for (; start <= end; start++)
-            if (Py_UNICODE_MATCH(self, start, substring))
+            if (*(self->str + start) == *(substring->str) &&
+		Py_UNICODE_MATCH(self, start, substring))
                 return start;
     }
 

--amk




From amk1 at erols.com  Sun Jun 18 21:32:37 2000
From: amk1 at erols.com (A.M. Kuchling)
Date: Sun, 18 Jun 2000 15:32:37 -0400
Subject: [Python-Dev] Turning on sre?
Message-ID: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com>

Before 1.6a3, should the sre module be turned on, replacing re?  That
way it'll start getting tested; better we find problems sooner rather
than later...

--amk




From guido at python.org  Sun Jun 18 22:47:22 2000
From: guido at python.org (Guido van Rossum)
Date: Sun, 18 Jun 2000 15:47:22 -0500
Subject: [Python-Dev] Turning on sre?
In-Reply-To: Your message of "Sun, 18 Jun 2000 15:32:37 -0400."
             <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> 
References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> 
Message-ID: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>

> Before 1.6a3, should the sre module be turned on, replacing re?  That
> way it'll start getting tested; better we find problems sooner rather
> than later...

That would be nice.  If I replace re.py with "from sre import *" and
run test_re.py, I grt in trouble in the sub() test:

$ ./python ../Lib/test/test_re.py
Running tests on re.search and re.match
Running tests on re.sub
Traceback (most recent call last):
  File "../Lib/test/test_re.py", line 41, in ?
    assert re.sub(r'\d+', bump_num, '08.2 -2 23x99y') == '9.3 -3 24x100y'
  File "./../Lib/sre.py", line 35, in sub
    return _compile(pattern).sub(repl, string, count)
  File "./../Lib/sre.py", line 84, in _sub
    return _subn(pattern, template, string, count)[0]
  File "./../Lib/sre.py", line 114, in _subn
    return string[:0].join(s), n
TypeError: sequence item 0 not a string
$

It appears that the value of s is a list containing alternating zeros
and strings: [0, '.', 0, ' -', 0, ' ', 0, 'x', 0, 'y'].

No time to look into this further, but it could be a bug in sre._subn().

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



From akuchlin at cnri.reston.va.us  Sun Jun 18 22:28:59 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sun, 18 Jun 2000 16:28:59 -0400
Subject: [Python-Dev] Turning on sre?
In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>; from guido@python.org on Sun, Jun 18, 2000 at 03:47:22PM -0500
References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> <200006182047.PAA03008@cj20424-a.reston1.va.home.com>
Message-ID: <20000618162859.A15018@newcnri.cnri.reston.va.us>

On Sun, Jun 18, 2000 at 03:47:22PM -0500, Guido van Rossum wrote:
>No time to look into this further, but it could be a bug in sre._subn().

It's a typo; fixed.  However, test_re then runs into the fact that
_expand(), which should expand escapes in the replacement string,
isn't implemented yet.

--amk



From effbot at telia.com  Sun Jun 18 23:42:00 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sun, 18 Jun 2000 23:42:00 +0200
Subject: [Python-Dev] talking about performance...
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us>
Message-ID: <008301bfd96e$0bd98d20$f2a6b5d4@hagrid>

amk wrote:

> On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote:
> >so in other words, something in unicode land isn't
> >as efficient as it should...
> 
> The relevant bit of findstring() in unicodeobject.c:
> 
>     if (direction < 0) {
>         for (; end >= start; end--)
>             if (Py_UNICODE_MATCH(self, end, substring))
>                 return end;
>     } else {
>         for (; start <= end; start++)
>             if (Py_UNICODE_MATCH(self, start, substring))
>                 return start;
>     }
> 
> And...
> 
> #define Py_UNICODE_MATCH(string, offset, substring)\
>     (!memcmp((string)->str + (offset), (substring)->str,\
>              (substring)->length*sizeof(Py_UNICODE)))

heh.  it's my own code, of course...

> Proposed patch:
> 
> Index: unicodeobject.c

MATCH is used in a couple of places; it's probably a better idea
to change the macro (in Include/unicodeobject.h).  MAL?

</F>




From effbot at telia.com  Sun Jun 18 23:43:51 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sun, 18 Jun 2000 23:43:51 +0200
Subject: [Python-Dev] Turning on sre?
References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com>
Message-ID: <009501bfd96e$4d11b7e0$f2a6b5d4@hagrid>

amk wrote:


> Before 1.6a3, should the sre module be turned on, replacing re?  That
> way it'll start getting tested; better we find problems sooner rather
> than later...

in addition to the typo you noticed, there's a backtracking
(I think) problem that affects xmllib.py and tokenize.py...

I'm working on it.

</F>




From mal at lemburg.com  Sun Jun 18 23:48:32 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sun, 18 Jun 2000 23:48:32 +0200
Subject: [Python-Dev] talking about performance...
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid>
Message-ID: <394D43B0.8CC7070@lemburg.com>

Fredrik Lundh wrote:
> 
> amk wrote:
> 
> > On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote:
> > >so in other words, something in unicode land isn't
> > >as efficient as it should...
> >
> > The relevant bit of findstring() in unicodeobject.c:
> >
> >     if (direction < 0) {
> >         for (; end >= start; end--)
> >             if (Py_UNICODE_MATCH(self, end, substring))
> >                 return end;
> >     } else {
> >         for (; start <= end; start++)
> >             if (Py_UNICODE_MATCH(self, start, substring))
> >                 return start;
> >     }
> >
> > And...
> >
> > #define Py_UNICODE_MATCH(string, offset, substring)\
> >     (!memcmp((string)->str + (offset), (substring)->str,\
> >              (substring)->length*sizeof(Py_UNICODE)))
> 
> heh.  it's my own code, of course...
> 
> > Proposed patch:
> >
> > Index: unicodeobject.c
> 
> MATCH is used in a couple of places; it's probably a better idea
> to change the macro (in Include/unicodeobject.h).  MAL?

Right. I'll add Andrew's proposed patch to the macro def.

--
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Mon Jun 19 00:33:10 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 19 Jun 2000 00:33:10 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include unicodeobject.h,2.9,2.10
References: <200006182222.PAA19408@slayer.i.sourceforge.net>
Message-ID: <00c601bfd975$358d0aa0$f2a6b5d4@hagrid>

mal wrote:
>   
>   #define Py_UNICODE_MATCH(string, offset, substring)\
> !     ((*((string)->str + (offset)) == *((substring)->str)) &&\
> !      !memcmp((string)->str + (offset), (substring)->str,\
>                (substring)->length*sizeof(Py_UNICODE)))
>   

I completely forgot that this has different semantics if the
substring happens to be empty.

(substrings are null terminated, but "\0" isn't the same
thing as ""...)

don't have time to screen unicodeobject.c right now, but
maybe someone else can do it?  if not, maybe amk's patch
was a better idea after all...

</F>




From mwh21 at cam.ac.uk  Mon Jun 19 01:15:25 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 19 Jun 2000 00:15:25 +0100
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100
In-Reply-To: "A.M. Kuchling"'s message of "Sun, 18 Jun 2000 11:45:52 -0700"
References: <200006181845.LAA10182@slayer.i.sourceforge.net>
Message-ID: <m33dma7f8y.fsf@atrus.jesus.cam.ac.uk>

"A.M. Kuchling" <akuchling at users.sourceforge.net> writes:

> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv10064/Modules
> 
> Modified Files:
> 	_tkinter.c 
> Log Message:
> Patch from /F:
> this patch adds a fast _flatten function to the _tkinter
> module, and imports it from Tkinter.py (if available).
> 
> this speeds up canvas operations like create_line and
> create_polygon.  for example, a create_line with 5000
> vertices runs about 50 times faster with this patch in
> place.

Unfortunately this introduces another Way To Make Python Core:

[mwh21 at atrus build]$ ./python 
Python 1.6a2 (#4, Jun 18 2000, 23:57:36)  [GCC 2.95.1 19990816/Linux (release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> import Tkinter
>>> l = []
>>> l.append(l)
>>> Tkinter._flatten(l)
Segmentation fault (core dumped)

Here's a simple solution:

Index: _tkinter.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v
retrieving revision 1.100
diff -u -r1.100 _tkinter.c
--- _tkinter.c	2000/06/18 18:45:50	1.100
+++ _tkinter.c	2000/06/18 23:13:22
@@ -2001,13 +2001,16 @@
 }
 
 static int
-_flatten1(FlattenContext* context, PyObject* item)
+_flatten1(FlattenContext* context, PyObject* item, int depth)
 {
 	/* add tuple or list to argument tuple (recursively) */
 
 	int i, size;
 
-	if (PyList_Check(item)) {
+	if (depth > 1000) {
+		PyErr_SetString(PyExc_ValueError,"nesting too deep in _flatten");
+		return 0;
+	} else if (PyList_Check(item)) {
 		size = PyList_GET_SIZE(item);
 		/* preallocate (assume no nesting) */
 		if (context->size + size > context->maxsize && !_bump(context, size))
@@ -2016,7 +2019,7 @@
 		for (i = 0; i < size; i++) {
 			PyObject *o = PyList_GET_ITEM(item, i);
 			if (PyList_Check(o) || PyTuple_Check(o)) {
-				if (!_flatten1(context, o))
+				if (!_flatten1(context, o, depth + 1))
 					return 0;
 			} else if (o != Py_None) {
 				if (context->size + 1 > context->maxsize && !_bump(context, 1))
@@ -2033,7 +2036,7 @@
 		for (i = 0; i < size; i++) {
 			PyObject *o = PyTuple_GET_ITEM(item, i);
 			if (PyList_Check(o) || PyTuple_Check(o)) {
-				if (!_flatten1(context, o))
+				if (!_flatten1(context, o, depth + 1))
 					return 0;
 			} else if (o != Py_None) {
 				if (context->size + 1 > context->maxsize && !_bump(context, 1))
@@ -2068,7 +2071,7 @@
 	
 	context.size = 0;
 
-	if (!_flatten1(&context, item))
+	if (!_flatten1(&context, item,0))
 		return NULL;
 
 	if (_PyTuple_Resize(&context.tuple, context.size, 0))

"seems to work"; I've not tested it for performance, but I can't
believe this is too hard a hit.

Cheers,
M.




From mal at lemburg.com  Mon Jun 19 01:20:27 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 19 Jun 2000 01:20:27 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include
 unicodeobject.h,2.9,2.10
References: <200006182222.PAA19408@slayer.i.sourceforge.net> <00c601bfd975$358d0aa0$f2a6b5d4@hagrid>
Message-ID: <394D593B.DD4804E6@lemburg.com>

Fredrik Lundh wrote:
> 
> mal wrote:
> >
> >   #define Py_UNICODE_MATCH(string, offset, substring)\
> > !     ((*((string)->str + (offset)) == *((substring)->str)) &&\
> > !      !memcmp((string)->str + (offset), (substring)->str,\
> >                (substring)->length*sizeof(Py_UNICODE)))
> >
> 
> I completely forgot that this has different semantics if the
> substring happens to be empty.
> 
> (substrings are null terminated, but "\0" isn't the same
> thing as ""...)
> 
> don't have time to screen unicodeobject.c right now, but
> maybe someone else can do it?  if not, maybe amk's patch
> was a better idea after all...

I've checked the places where this macro is used: all
except the in .count() method showed the same behaviour
as for 8-bit strings.

The Unicode .count() method now also returns the same
value for empty substrings as the 8-bit strings.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Mon Jun 19 01:29:23 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 19 Jun 2000 01:29:23 +0200
Subject: [Python-Dev] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100
References: <200006181845.LAA10182@slayer.i.sourceforge.net> <m33dma7f8y.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <002701bfd97d$09d8b640$f2a6b5d4@hagrid>

michael wrote:
> > this patch adds a fast _flatten function to the _tkinter
> > module, and imports it from Tkinter.py (if available).
>
> Unfortunately this introduces another Way To Make Python Core:

well, there are lots of way to dump core through Tkinter/Tk, so I
convinced myself that it wasn't really worth the effort to prevent
it in _flatten...

either way, the patch looks okay to me.

</F>




From mwh21 at cam.ac.uk  Mon Jun 19 01:41:22 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 19 Jun 2000 00:41:22 +0100
Subject: [Python-Dev] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100
In-Reply-To: "Fredrik Lundh"'s message of "Mon, 19 Jun 2000 01:29:23 +0200"
References: <200006181845.LAA10182@slayer.i.sourceforge.net> <m33dma7f8y.fsf@atrus.jesus.cam.ac.uk> <002701bfd97d$09d8b640$f2a6b5d4@hagrid>
Message-ID: <m3zooi5zh9.fsf@atrus.jesus.cam.ac.uk>

"Fredrik Lundh" <effbot at telia.com> writes:

> michael wrote:
> > > this patch adds a fast _flatten function to the _tkinter
> > > module, and imports it from Tkinter.py (if available).
> >
> > Unfortunately this introduces another Way To Make Python Core:
> 
> well, there are lots of way to dump core through Tkinter/Tk, so I
> convinced myself that it wasn't really worth the effort to prevent
> it in _flatten...

Are there?  (I hardly know Tkinter).  Oh well.

I don't know of many "core" methods of doing it; the only one I can
think of is marshalling a recursive list, and as there seems to be a
loud party going on next door to me, I may write a patch for that this
evening...

Cheers,
M.




From mhammond at skippinet.com.au  Mon Jun 19 02:05:00 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 19 Jun 2000 10:05:00 +1000
Subject: [Python-Dev] Welcome back
In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEKGCNAA.mhammond@skippinet.com.au>

<To the tune from "Welcome back Kotter" :->

Welcome back, welcome back, welcome baaaaack - Welcome back, welcome back,
welcome baaaaack

Good to see you return.  Im sure you had a wonderful time!  From all
accounts, your wedding was beautiful, as Im sure your honeymoon was...

Now-were-just-waiting-for-the-baby-announcements-ly,

Mark.

> -----Original Message-----
> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Guido van Rossum
> Sent: Monday, 19 June 2000 6:47 AM
> To: akuchlin at mems-exchange.org
> Cc: python-dev at python.org
> Subject: Re: [Python-Dev] Turning on sre?




From tim_one at email.msn.com  Mon Jun 19 04:05:16 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 18 Jun 2000 22:05:16 -0400
Subject: [Python-Dev] Welcome back
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBCEKGCNAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEOKGEAA.tim_one@email.msn.com>

[Mark Hammond]
> ...
> Good to see you return.  Im sure you had a wonderful time!  From
> all accounts, your wedding was beautiful, as Im sure your
> honeymoon was...
>
> Now-were-just-waiting-for-the-baby-announcements-ly,

Guido & Kim just spent the last night of their honeymoon with Uncle Timmy
(who is now living in a Virginia motel room), and I can assure you no babies
were made by any pair of us tonight.  Unless Guido is quicker than he looks.

i'm-certainly-not-ly y'rs  - tim





From skip at mojam.com  Sat Jun 17 05:45:14 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 16 Jun 2000 22:45:14 -0500 (CDT)
Subject: [Python-Dev] list comprehensions
Message-ID: <14666.62538.988511.305499@beluga.mojam.com>

Did list comprehensions ever make it into 1.6?  I thought I submitted a
1.6-compatible update of Greg Ewing's mods awhile ago.  Should I resubmit?
To the patches list?

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395



From guido at python.org  Mon Jun 19 17:01:24 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 19 Jun 2000 10:01:24 -0500
Subject: [Python-Dev] list comprehensions
In-Reply-To: Your message of "Fri, 16 Jun 2000 22:45:14 EST."
             <14666.62538.988511.305499@beluga.mojam.com> 
References: <14666.62538.988511.305499@beluga.mojam.com> 
Message-ID: <200006191501.KAA02197@cj20424-a.reston1.va.home.com>

> Did list comprehensions ever make it into 1.6?

No (as far as I'm aware :-).

> I thought I submitted a
> 1.6-compatible update of Greg Ewing's mods awhile ago.  Should I resubmit?
> To the patches list?

It's rather late in the release cycle -- I'm trying to get alpha 3
released, and i'm still 1400 messages behind on my email.

But submitting a patch might be a good idea anyway so we won't forget
about it (and maybe it's of such baffling simplicity that it'll charm
its way past the guards :-).

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



From ping at lfw.org  Mon Jun 19 20:59:15 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Mon, 19 Jun 2000 13:59:15 -0500 (CDT)
Subject: [Python-Dev] list comprehensions
In-Reply-To: <200006191501.KAA02197@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10006191358330.10836-100000@server1.lfw.org>

On Mon, 19 Jun 2000, Guido van Rossum wrote:
> > Did list comprehensions ever make it into 1.6?
> 
> No (as far as I'm aware :-).
[...] 
> But submitting a patch might be a good idea anyway so we won't forget
> about it (and maybe it's of such baffling simplicity that it'll charm
> its way past the guards :-).

I just have to say i thought list comprehensions were
really cool.


-- ?!ng




From skip at mojam.com  Mon Jun 19 22:17:59 2000
From: skip at mojam.com (Skip Montanaro)
Date: Mon, 19 Jun 2000 15:17:59 -0500
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
Message-ID: <200006192017.PAA00690@beluga.mojam.com>

Python's sys module defines an exitfunc variable that is settable from
Python scripts.  At exit, that function will be called with no arguments.
While this is a good start at supporting standard cleanup activities, it
defines no protocol to be used by modules that wish to use sys.exitfunc,
which leads to one of two extremes: 1, two modules wishing to define cleanup
functions both clobber sys.exitfunc or 2, to avoid collisions they don't use
the functionality provided.

At an application level this is okay.  Within a single application you can
define an application-specific protocol to handle the situation.
Unfortunately, this still leaves Python's core modules without a good way to
register exit functions.

I ran into this problem today.  I would really like the rlcompleter module
to read and write readline history files from Python.  Reading a history
file at module startup is no problem, but deciding where to write the
history file is a problem.  The logical place is at the time sys.exitfunc is
executed.

For my own applications I long ago wrote a very simple module (called
exit.py, appended to this message) that defines two functions:

    * exit.register_exitfunc takes a function object and a set of optional
      arguments and appends them to a list.

    * exit._run_exitfuncs is bound to sys.exitfunc and executes the
      registered exit functions in the order they appear in the list.

I propose exit.py as the starting point for a well-defined protocol for
modules to register exit functions without collisions.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395


"""
allow programmer to define multiple exit functions to be executed upon normal
program termination.
"""

_exithandlers = []
def _run_exitfuncs():
    while _exithandlers:
        func, targs, kargs = _exithandlers[0]
        apply(func, targs, kargs)
        _exithandlers.remove(_exithandlers[0])

def register_exitfunc(func, *targs, **kargs):
    """register a function to be executed upon normal program termination

    arguments are a function object, and zero or more arguments to pass to
    it.
    """
    _exithandlers.append((func, targs, kargs))

import sys
try:
    x = sys.exitfunc
except AttributeError:
    sys.exitfunc = _run_exitfuncs
del sys

if __name__ == "__main__":
    def x1():
        print "running x1"
    def x2(n):
        print "running x2(%s)" % `n`
    def x3(n, kwd=None):
        print "running x3(%s, kwd=%s)" % (`n`, `kwd`)

    register_exitfunc(x1)
    register_exitfunc(x2, 12)
    register_exitfunc(x3, 5, "bar")
    register_exitfunc(x3, "no kwd args")




From DavidA at ActiveState.com  Mon Jun 19 22:27:48 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 19 Jun 2000 13:27:48 -0700
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <200006192017.PAA00690@beluga.mojam.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJCEPHCIAA.DavidA@ActiveState.com>

+1 on the idea.  I wonder if it makes sense to publish a mechanism to allow
de-registering of callbacks, or if that's featuritis.

Also, I'd change:

> try:
>     x = sys.exitfunc
> except AttributeError:
>     sys.exitfunc = _run_exitfuncs
> del sys

to:

try:
	register_exitfuncs(sys.exitfunc)
finally:
	sys.exitfunc = _run_exitfuncs

Or some such.

--david

> -----Original Message-----
> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Skip Montanaro
> Sent: Monday, June 19, 2000 1:18 PM
> To: python-dev at python.org
> Subject: [Python-Dev] Proposal: standard way of defining and executing
> "atexit" functions...
> Importance: Low
>
>
>
> Python's sys module defines an exitfunc variable that is settable from
> Python scripts.  At exit, that function will be called with no arguments.
> While this is a good start at supporting standard cleanup activities, it
> defines no protocol to be used by modules that wish to use sys.exitfunc,
> which leads to one of two extremes: 1, two modules wishing to
> define cleanup
> functions both clobber sys.exitfunc or 2, to avoid collisions
> they don't use
> the functionality provided.
>
> At an application level this is okay.  Within a single application you can
> define an application-specific protocol to handle the situation.
> Unfortunately, this still leaves Python's core modules without a
> good way to
> register exit functions.
>
> I ran into this problem today.  I would really like the rlcompleter module
> to read and write readline history files from Python.  Reading a history
> file at module startup is no problem, but deciding where to write the
> history file is a problem.  The logical place is at the time
> sys.exitfunc is
> executed.
>
> For my own applications I long ago wrote a very simple module (called
> exit.py, appended to this message) that defines two functions:
>
>     * exit.register_exitfunc takes a function object and a set of optional
>       arguments and appends them to a list.
>
>     * exit._run_exitfuncs is bound to sys.exitfunc and executes the
>       registered exit functions in the order they appear in the list.
>
> I propose exit.py as the starting point for a well-defined protocol for
> modules to register exit functions without collisions.
>
> --
> Skip Montanaro, skip at mojam.com, http://www.mojam.com/,
> http://www.musi-cal.com/
> On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always
> lived
> his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
>     https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395
>
>
> """
> allow programmer to define multiple exit functions to be executed upon
> normal
> program termination.
> """
>
> _exithandlers = []
> def _run_exitfuncs():
>     while _exithandlers:
>         func, targs, kargs = _exithandlers[0]
>         apply(func, targs, kargs)
>         _exithandlers.remove(_exithandlers[0])
>
> def register_exitfunc(func, *targs, **kargs):
>     """register a function to be executed upon normal program termination
>
>     arguments are a function object, and zero or more arguments to pass to
>     it.
>     """
>     _exithandlers.append((func, targs, kargs))
>
> import sys
> try:
>     x = sys.exitfunc
> except AttributeError:
>     sys.exitfunc = _run_exitfuncs
> del sys
>
> if __name__ == "__main__":
>     def x1():
>         print "running x1"
>     def x2(n):
>         print "running x2(%s)" % `n`
>     def x3(n, kwd=None):
>         print "running x3(%s, kwd=%s)" % (`n`, `kwd`)
>
>     register_exitfunc(x1)
>     register_exitfunc(x2, 12)
>     register_exitfunc(x3, 5, "bar")
>     register_exitfunc(x3, "no kwd args")
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
>




From skip at mojam.com  Mon Jun 19 22:55:09 2000
From: skip at mojam.com (Skip Montanaro)
Date: Mon, 19 Jun 2000 15:55:09 -0500 (CDT)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJCEPHCIAA.DavidA@ActiveState.com>
References: <200006192017.PAA00690@beluga.mojam.com>
	<PLEJJNOHDIGGLDPOGPJJCEPHCIAA.DavidA@ActiveState.com>
Message-ID: <14670.34989.887973.797947@beluga.mojam.com>

    David> +1 on the idea.  I wonder if it makes sense to publish a
    David> mechanism to allow de-registering of callbacks, or if that's
    David> featuritis.

While writing my message I thought, "I'll bet the first question asked will
be about unregistering exit functions."  I've been using the module I
appended to my message unchanged for a couple years and never needed such
functionality.  I'm sure there are applications that could use it, but I
think they'd be a small minority.  Since the only defined interface is a
single registration function (_run_exitfuncs is only used internally), I
think you'd be free to add some unregister function protocol at a later
time if it was deemed necessary.

    David> Also, I'd change:

    >> try:
    >>     x = sys.exitfunc
    >> except AttributeError:
    >>     sys.exitfunc = _run_exitfuncs
    >> del sys

    David> to:

    David> try:
    David> 	register_exitfuncs(sys.exitfunc)
    David> finally:
    David> 	sys.exitfunc = _run_exitfuncs

    David> Or some such.

register_exitfunc is only meant to be called by clients of the module, not
used internally.  You're assuming that if something else was already bound
to sys.exitfunc that it's not _run_exitfuncs.  With your try/finally code
try the following (mentally is fine):

    import exit
    def foo():
        print 1
    exit.register_exitfunc(foo)
    reload(exit)

I think you'll see that exit._run_exitfuncs is on its own list of exit
functions.  That could be bad.

The setup code:

    try:
        x = sys.exitfunc
    except AttributeError:
        sys.exitfunc = _run_exitfuncs

is meant to avoid doing anything if any other module beat us to
sys.exitfunc.  Perhaps it should just be

    sys.exitfunc = _run_exitfuncs

If someone fails to use the defined protocol, screw 'em... ;-)

Skip



From DavidA at ActiveState.com  Mon Jun 19 23:12:03 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 19 Jun 2000 14:12:03 -0700
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <14670.34989.887973.797947@beluga.mojam.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com>

> If someone fails to use the defined protocol, screw 'em... ;-)

That's unreasonable given that existing tools might include a library which
might be upgraded to use the new mechanism while the old code used its own
mechanism happily.  For example, I've used my own protocols in the past
which went something like...

def register_exitfunc(func):
    old_exitfunc = getattr(sys, 'exitfunc', None)
    def wrapper(old_exitfunc=old_exitfunc, new_func=func):
      if old_exitfunc is not None: old_exitfunc()
      new_func()
    sys.exitfunc = wrapper

or some such, creating a call chain instead of a sequence of calls, and it's
a 'fine' protocol in that it worked fine in the absence of a standard.  No
need to break code if we can avoid it.

The point of my pseudo-patch, if it wasn't clear, was that if a function is
already in sys.exitfunc, then it should still be called on exit after the
new exit module is imported.  You're right that my patch didn't properly
check that _run_exitfuncs might be that function.

--david




From skip at mojam.com  Mon Jun 19 23:41:54 2000
From: skip at mojam.com (Skip Montanaro)
Date: Mon, 19 Jun 2000 16:41:54 -0500 (CDT)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com>
References: <14670.34989.887973.797947@beluga.mojam.com>
	<PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com>
Message-ID: <14670.37794.998270.762852@beluga.mojam.com>

    >> If someone fails to use the defined protocol, screw 'em... ;-)

    David> That's unreasonable given that existing tools might include a
    David> library which might be upgraded to use the new mechanism while
    David> the old code used its own mechanism happily.  

Point taken.  I'll look at extending the module to accommodate other
sys.exitfunc callers.

Skip



From Vladimir.Marangozov at inrialpes.fr  Tue Jun 20 03:11:24 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Tue, 20 Jun 2000 03:11:24 +0200 (CEST)
Subject: [Python-Dev] mmapmodule.c,2.10,2.11
In-Reply-To: <20000618002224.A12729@newcnri.cnri.reston.va.us> from "Andrew Kuchling" at Jun 18, 2000 12:22:24 AM
Message-ID: <200006200111.DAA01591@python.inrialpes.fr>

Andrew Kuchling wrote:
> 
> On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote:
> >On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
> >It works okay without the MS_INVALIDATE flag though, so I'd suggest
> >removing it from msync in the flush and dealloc methods.
> 
> Ooh, you're right.  The Linux msync man page says "MS_ASYNC specifies
> that an update be scheduled, but the call returns immediately.
> MS_SYNC asks for an update and waits for it to complete.
> MS_INVALIDATE asks to invalidate other mappings of the same file (so
> that they can be updated with the fresh values just written)."  So
> MS_INVALIDATE seems far too drastic.

Yes.

> 
> >Also, it would probably be a good idea to allow optional flags for
> >flush, as it's done in new_mmap_object, the default being only MS_SYNC.
> 
> The problem is: does Windows provide equivalent functionality?  (Is
> there documentation available online for CreateFileMapping that I
> could look at?)

Well, I had a look at my Windows book. Although the mmap functionnality is
equivalent, overall, there are no equivalent flags in FlushViewOfFile, etc.
Maybe this is too subtle to be of any real use after all, so I retract the
idea. MS_SYNC alone is fine.

Another point: I'm not thrilled about the idea of raising a SystemError
for m.resize if native mremap is missing (which is also AIX's case).
unmap/mmap again with the new size is the emulation solution everybody
would do in Python when m.resize is not implemented. So I'd suggest
implementing it in C (which is what the Windows version does, btw).
Furthermore, having an unimplemented method makes little sense to me.
For implementing this emulation on Unix, however, we would need to
remember in additional slots the original mmap flags & rights, so that
the second (or any subsequent) mmap call uses the same flags & rights
as the first one.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From pf at artcom-gmbh.de  Tue Jun 20 09:32:33 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 20 Jun 2000 09:32:33 +0200 (MEST)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com> from David Ascher at "Jun 19, 2000  2:12: 3 pm"
Message-ID: <m134IWP-000DieC@artcom0.artcom-gmbh.de>

Hi Skip, Hi David,

David Ascher:
> > If someone fails to use the defined protocol, screw 'em... ;-)
> 
> That's unreasonable given that existing tools might include a library which
> might be upgraded to use the new mechanism while the old code used its own
> mechanism happily.  For example, I've used my own protocols in the past
> which went something like...
> 
> def register_exitfunc(func):
>     old_exitfunc = getattr(sys, 'exitfunc', None)
>     def wrapper(old_exitfunc=old_exitfunc, new_func=func):
>       if old_exitfunc is not None: old_exitfunc()
>       new_func()
>     sys.exitfunc = wrapper
> 
> or some such, creating a call chain instead of a sequence of calls, and it's
> a 'fine' protocol in that it worked fine in the absence of a standard.  No
> need to break code if we can avoid it.

Davids wrapper function implements a FIFO strategy for termination.  
I think this is not desired.  Normally you want LIFO, because higher level 
services in an application are initialized later during startup.  Those 
services usually depend on lower level services, which should still be 
available at termination time of the higher level services.  

I try to explain this by an example:
Module A provides some kind of network connections. 
Module B uses (imports) Module A to access a remote resource administration 
server to provide access to remote devices or resources.
During program termination Module B likes to release all resources reserved 
for (owned by) the program.  It uses Module A to submit a cleanup request to
the server.  Module A however wants to close all open network connections.

The following function (termination protocol) solves this by exchanging the 
sequence of calls within the wrapper:

def register_exit_func(func, *args, **kw):
    import sys
    previous_func = sys.exit_func
    def wrapped_func(previous_func=previous_func, func=func, args=args, kw=kw):
        try:
            apply(func, args, kw)
        finally:
            if previous_func is not None: 
                previous_func()
    sys.exit_func = wrapped_func

In the past I've placed such a function into a common base module of my apps.
But I think, Skip is right, that a termination protocol should be part of
the standard library.  

But a separate module 'exit.py' seems to be overkill for single basic 
function.  May be it should be put into the module 'os'?  Handling of 
program termination is something, which considered as a generic 
operating system service.  From the users point of view 'sys' would
be a better place, but this would require rewriting in C: ugly.

I also agree with Skip, that the possibility to unregister an exit_func is 
normally not needed.  The same effect can be achieved by doing nothing in 
the exit_func.

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)



From mhammond at skippinet.com.au  Tue Jun 20 10:02:14 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 20 Jun 2000 18:02:14 +1000
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <m134IWP-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <ECEPKNMJLHAPFFJHDOJBOEMCCNAA.mhammond@skippinet.com.au>

Peter:

> Davids wrapper function implements a FIFO strategy for termination.  
> I think this is not desired.  Normally you want LIFO,

Agreed.  LIFO is definately preferred IMO.

Mark.




From pf at artcom-gmbh.de  Tue Jun 20 10:08:16 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 20 Jun 2000 10:08:16 +0200 (MEST)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: From "(env:" "pf)" at "Jun 20, 2000  9:32:33 am"
Message-ID: <m134J4y-000DieC@artcom0.artcom-gmbh.de>

Hi, 

I wrote:
> def register_exit_func(func, *args, **kw):
>     import sys
>     previous_func = sys.exit_func

this should have been 'sys.exitfunc'.
I've also misssed to note, that I placed the following line into 
the module init code: 

import sys; def _nop(): pass; sys.exitfunc = _nop
Otherwise I had to use getattr(sys, 'exitfunc', None) as David suggested.

Next time I should actually cut'n'paste working code instead typing from
blurred memory. :-(

Another point I forgot, was that you usually want to install signal
handlers on unices, that handle the signal.SIGTERM, signal.SIGHUP and
signal.SIGINT signals and invoke exit function to do some final
cleanup.

Regards, Peter



From mal at lemburg.com  Tue Jun 20 11:01:50 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 20 Jun 2000 11:01:50 +0200
Subject: [Python-Dev] Proposal: standard way of defining and executing 
 "atexit" functions...
References: <m134J4y-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <394F32FE.B926C19A@lemburg.com>

Attached you find a similar module which I have used for years.
It has all the requested features, plus allows deregistration
and supports a more OO-like interface.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ExitFunctions.py
Type: text/python
Size: 2444 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000620/7fbaac90/attachment.bin>

From fredrik at pythonware.com  Tue Jun 20 12:15:01 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 12:15:01 +0200
Subject: [Python-Dev] talking about performance... [case closed]
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com>
Message-ID: <003101bfdaa0$693b4de0$0900a8c0@SPIFF>

mal wrote:
> > > Index: unicodeobject.c
> > 
> > MATCH is used in a couple of places; it's probably a better idea
> > to change the macro (in Include/unicodeobject.h).  MAL?
> 
> Right. I'll add Andrew's proposed patch to the macro def.

for the record, my little benchmark now runs about five
times faster than before -- which means that 16-bit find
is now ~30% faster than 8-bit find (barry? ;-)

cheers /F

footnote: for the exact figures, see:
http://hem.passagen.se/eff/2000_06_01_bot-archive.htm#361472




From mhammond at skippinet.com.au  Tue Jun 20 13:42:53 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 20 Jun 2000 21:42:53 +1000
Subject: [Python-Dev] Fw: Access violation when no memory
Message-ID: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au>


From gward at mems-exchange.org  Tue Jun 20 14:33:44 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Tue, 20 Jun 2000 08:33:44 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com>
Message-ID: <20000620083344.A3499@ludwig.cnri.reston.va.us>

On 09 June 2000, Eric S. Raymond said:
> I think it's time to consider including PIL in the core Python 1.6 release.
> I've been following the work being done over there, and I believe the 
> code has reached a sufficient level of maturity to justify this.

-1 from me.  What's the point of the Distutils if we just throw
everything "useful" into the standard distribution?

        Greg



From gward at mems-exchange.org  Tue Jun 20 14:40:41 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Tue, 20 Jun 2000 08:40:41 -0400
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <200006130237.EAA10373@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jun 13, 2000 at 04:37:23AM +0200
References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr>
Message-ID: <20000620084040.B3499@ludwig.cnri.reston.va.us>

On 13 June 2000, Vladimir Marangozov said:
> > - Fix ./ld_so_aix installation problem on AIX (anybody know more about
> >   this???)
> 
> Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem
> for building C extensions with distutils than an installation problem per se.
> Some time ago, I saw a workaround checked in by Greg. If this is still judged
> as a problem, I'd like to hear about it. This is a minor thing. I have yet
> to install & run the distutil package on AIX, though, and see what happens.

As I recall, my workaround didn't work.  (Would that make it a
failaround?)

Vladimir, *please* give the Distutils a whirl on AIX -- I suspect some
sort of hack is needed to get extension-building working there.  I don't
much care if the Makefile installed by Python is "fixed" to have an
absolute path to "ld_so_aix" instead of "./ld_so_aix" -- that should
make extension-building with the Distutils OK, but it will break the
relocatability of a Python installation on AIX.  Also, it won't fix
Distutils with Python 1.5.2.

Thanks --

       Greg



From paul at prescod.net  Tue Jun 20 15:30:13 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 20 Jun 2000 15:30:13 +0200
Subject: [Python-Dev] RFC: Including PIL in 1.6
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us>
Message-ID: <394F71E5.C7CEC32D@prescod.net>

Greg Ward wrote:
> 
> ...
> -1 from me.  What's the point of the Distutils if we just throw
> everything "useful" into the standard distribution?

One way to look at it is vertical versus horizontal. I think that that's
how the Java world works (unofficially). If Java is one extreme and ANSI
C is on the other, I prefer to err on the Java side (which we probably
do).

The big issue is configuration management. if we put PIL (or anything
else) in the standard distribution we are promising to keep that code in
sync with everything else. This is a big boon to users and a big
headache for maintainers. The question is when the boon is enough to
justify the headache.

It's one thing to tell a user: "Just type distutils and everything will
magically become available." But they usually come back: "I'm getting an
error message about append not taking that many arguments..." or
something like that. Libraries breaking libraries is actually the most
common case.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Music is the stuff between the notes." - Claude Debussy



From bwarsaw at python.org  Tue Jun 20 15:43:32 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Tue, 20 Jun 2000 09:43:32 -0400 (EDT)
Subject: [Python-Dev] talking about performance... [case closed]
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>
	<20000618152020.B14713@newcnri.cnri.reston.va.us>
	<008301bfd96e$0bd98d20$f2a6b5d4@hagrid>
	<394D43B0.8CC7070@lemburg.com>
	<003101bfdaa0$693b4de0$0900a8c0@SPIFF>
Message-ID: <14671.29956.819067.208771@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <fredrik at pythonware.com> writes:

    FL> for the record, my little benchmark now runs about five
    FL> times faster than before -- which means that 16-bit find
    FL> is now ~30% faster than 8-bit find (barry? ;-)

Awesome!



From akuchlin at cnri.reston.va.us  Tue Jun 20 15:53:09 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 09:53:09 -0400
Subject: [Python-Dev] talking about performance... [case closed]
In-Reply-To: <003101bfdaa0$693b4de0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jun 20, 2000 at 12:15:01PM +0200
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF>
Message-ID: <20000620095309.A3039@amarok.cnri.reston.va.us>

On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote:
>for the record, my little benchmark now runs about five
>times faster than before -- which means that 16-bit find
>is now ~30% faster than 8-bit find (barry? ;-)

Speculation: the code in stringobject.c looks like this:
                for (; i <= last; ++i)
                        if (s[i] == sub[0] &&
                            (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0))
                                return (long)i;
 
It checks the first character, and then does the memcmp() skipping the
first character, or succeeds if the substring length is 1; the Unicode
find is simpler, just doing the full memcmp.  I wonder if the extra n
== 1 and i+1, n-1 arithmetic costs more than it saves?  This is
probably delicately tied to the speed of your memcmp().  Anyone want
to try the simpler version and report on whether it makes a difference?

--amk



From effbot at telia.com  Tue Jun 20 17:26:42 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 17:26:42 +0200
Subject: [Python-Dev] faster 8-bit find/split (was: talking about performance...)
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> <20000620095309.A3039@amarok.cnri.reston.va.us>
Message-ID: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid>

[as discussed on python-dev]

amk wrote:
> On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote:
> >for the record, my little benchmark now runs about five
> >times faster than before -- which means that 16-bit find
> >is now ~30% faster than 8-bit find (barry? ;-)
> 
> Speculation: the code in stringobject.c looks like this:
>                 for (; i <= last; ++i)
>                         if (s[i] == sub[0] &&
>                             (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0))
>                                 return (long)i;
>  
> It checks the first character, and then does the memcmp() skipping the
> first character, or succeeds if the substring length is 1; the Unicode
> find is simpler, just doing the full memcmp.  I wonder if the extra n
> == 1 and i+1, n-1 arithmetic costs more than it saves?

at least on my box (win95, msvc 5)...  after simplifying the code,
string.find is now faster than sre.search.  it's still 15% slower than
the 16-bit string find, but I don't have time to dig into that right
now...

patches are included.  

</F>

I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under copyright,
patent or other rights or interests ("claims").  To the extent that I
have any such claims, I hereby grant to CNRI a nonexclusive,
irrevocable, royalty-free, worldwide license to reproduce, distribute,
perform and/or display publicly, prepare derivative versions, and
otherwise use this contribution as part of the Python software and its
related documentation, or any derivative versions thereof, at no cost to
CNRI or its licensed users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide whether or
not to incorporate this contribution in the Python software and its
related documentation.  I further grant CNRI permission to use my name
and other identifying information provided to CNRI by me for use in
connection with the Python software and its related documentation.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: string-patch.txt
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000620/b0496902/attachment.txt>

From fdrake at beopen.com  Tue Jun 20 17:47:35 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 20 Jun 2000 11:47:35 -0400 (EDT)
Subject: [Python-Dev] faster 8-bit find/split (was: talking about performance...)
In-Reply-To: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid>
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>
	<20000618152020.B14713@newcnri.cnri.reston.va.us>
	<008301bfd96e$0bd98d20$f2a6b5d4@hagrid>
	<394D43B0.8CC7070@lemburg.com>
	<003101bfdaa0$693b4de0$0900a8c0@SPIFF>
	<20000620095309.A3039@amarok.cnri.reston.va.us>
	<007701bfdacc$0d2e87c0$f2a6b5d4@hagrid>
Message-ID: <14671.37399.809253.945519@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > patches are included.  

  Now checked in, thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Tue Jun 20 18:47:47 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 20 Jun 2000 12:47:47 -0400
Subject: [Python-Dev] talking about performance... [case closed]
In-Reply-To: <20000620095309.A3039@amarok.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCGECFGFAA.tim_one@email.msn.com>

[Fredrik Lundh]
> for the record, my little benchmark now runs about five
> times faster than before -- which means that 16-bit find
> is now ~30% faster than 8-bit find (barry? ;-)

[Andrew M. Kuchling]/
> Speculation: the code in stringobject.c looks like this:
>                 for (; i <= last; ++i)
>                         if (s[i] == sub[0] &&
>                             (n == 1 || memcmp(&s[i+1], &sub[1],
> n-1) == 0))
>                                 return (long)i;
> ...
> the Unicode find is simpler, just doing the full memcmp.  I wonder
> if the extra n == 1 and i+1, n-1 arithmetic costs more than it
> saves?

So the intent of the code is to avoid the expense of calling memcmp if a
full n-character memcmp can't possibly find equality at i (due to mismatch
of first characters), and the assumption is that first characters mismatch
frequently.  Both seem like good calls to me!

> This is probably delicately tied to the speed of your memcmp().

Also on whether your memcmp() is an actual external function or a full or
partial inline expansion (e.g., the strcmp at KSR expanded into code much
like the "by-hand" stuff above, skipping "the real" strcmp if the first
characters weren't equal).

> Anyone want to try the simpler version and report on whether
> it makes a difference?

No <wink>.  But if someone does, a good compromise might be to split this
into two loops, one for the n==1 case and another for n>1.  The "+1/-1" are
dubious in any case (i.e., "memcmp(s+i, sub, n) == 0" saves the fiddly
arithmetic at the also-minor cost of making memcmp do one redundant
character compare).





From dan at cgsoftware.com  Tue Jun 20 18:55:11 2000
From: dan at cgsoftware.com (Daniel Berlin)
Date: Tue, 20 Jun 2000 09:55:11 -0700 (PDT)
Subject: [Python-Dev] talking about performance... [case closed]
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECFGFAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10006200953020.31239-100000@propylaea.anduin.com>

> So the intent of the code is to avoid the expense of calling memcmp if a
> full n-character memcmp can't possibly find equality at i (due to mismatch
> of first characters), and the assumption is that first characters mismatch
> frequently.  Both seem like good calls to me!

However, smart compilers (gcc 2.95+ fer instance) will produce an inline
memcmp call that is faster, and has no overhead (IE it's not making a
library call).
Thus, the first character mismatch test is useless.
We had the same thing in strcmp macros in GDB, where we tested the first
character, then strcmp'd.
It was faster to just strcmp, even when they *did* mismatch.

--Dan




From esr at thyrsus.com  Tue Jun 20 19:21:50 2000
From: esr at thyrsus.com (esr at thyrsus.com)
Date: Tue, 20 Jun 2000 13:21:50 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <Pine.LNX.4.10.10006191358330.10836-100000@server1.lfw.org>
References: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> <Pine.LNX.4.10.10006191358330.10836-100000@server1.lfw.org>
Message-ID: <20000620132150.O8678@thyrsus.com>

Ka-Ping Yee <ping at lfw.org>:
> On Mon, 19 Jun 2000, Guido van Rossum wrote:
> > But submitting a patch might be a good idea anyway so we won't forget
> > about it (and maybe it's of such baffling simplicity that it'll charm
> > its way past the guards :-).
> 
> I just have to say i thought list comprehensions were
> really cool.

Ditto.  I would like to see this in 1.6.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The men and women who founded our country knew, by experience, that there
are times when the free person's answer to oppressive government has to be
delivered with a bullet.  Thus, the right to bear arms is not just *a*
freedom; it's the mother of all freedoms.  Don't let them disarm you!



From esr at thyrsus.com  Tue Jun 20 20:04:19 2000
From: esr at thyrsus.com (esr at thyrsus.com)
Date: Tue, 20 Jun 2000 14:04:19 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620083344.A3499@ludwig.cnri.reston.va.us>
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us>
Message-ID: <20000620140419.C10038@thyrsus.com>

Greg Ward <gward at mems-exchange.org>:
> -1 from me.  What's the point of the Distutils if we just throw
> everything "useful" into the standard distribution?

Watch that argument -- it could turn and bite you.  What's the justification
for including, e.g. POP client classes in the standard distribution?

One of Python's most important strengths is the "batteries *are*
included" richness of the standard environment.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The two pillars of `political correctness' are, 
  a) willful ignorance, and
  b) a steadfast refusal to face the truth
	-- George MacDonald Fraser



From effbot at telia.com  Tue Jun 20 19:59:35 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 19:59:35 +0200
Subject: [Python-Dev] RFC: Including PIL in 1.6
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us>
Message-ID: <001101bfdae1$5094f7a0$f2a6b5d4@hagrid>

greg wrote:

> On 09 June 2000, Eric S. Raymond said:
> > I think it's time to consider including PIL in the core Python 1.6 release.
> > I've been following the work being done over there, and I believe the 
> > code has reached a sufficient level of maturity to justify this.
> 
> -1 from me.  What's the point of the Distutils if we just throw
> everything "useful" into the standard distribution?

strange argument.  what's the point of including *anything*
if we have distutils?

...

fwiw, I'm -0 on this one;

it might better to work on a "Python Standards Base" which
specifies a bunch of extensions that people are encouraged
to include in their distributions.

let's see: zlib, expat, (portions of) numpy, pil, piddle, ...

</F>




From effbot at telia.com  Tue Jun 20 20:02:24 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 20:02:24 +0200
Subject: [Python-Dev] talking about performance...
References: <LNBBLJKPBEHFEDALKOLCGECFGFAA.tim_one@email.msn.com>
Message-ID: <002001bfdae1$b28942e0$f2a6b5d4@hagrid>

tim wrote:

> No <wink>.  But if someone does, a good compromise might be to split this
> into two loops, one for the n==1 case and another for n>1.

how about this one:

    if (dir > 0) {
        char *p, *e;
        if (n == 0 && i <= last)
            return (long)i;
        e = s + last - n + 1;
        for (;;) {
            p = memchr(s, sub[0], e - s);
            if (p == NULL)
                break;
            if (n == 1 || memcmp(p, sub, n) == 0)
                return (long) (p - s);
            s = p + 1;
        }
    }

new record time: 1.6 seconds (down from 2.2)

</F>




From akuchlin at cnri.reston.va.us  Tue Jun 20 20:04:06 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 14:04:06 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com>
Message-ID: <20000620140406.B3142@amarok.cnri.reston.va.us>

>Watch that argument -- it could turn and bite you.  What's the justification
>for including, e.g. POP client classes in the standard distribution?
>One of Python's most important strengths is the "batteries *are*
>included" richness of the standard environment.

Once there are enough pieces to make finding and getting the software
near-automatic, I actually wouldn't mind splitting them out and
shipping a much smaller core distribution, perhaps with a script that
downloads the latest versions of what's in the standard library.
Debian did that for a while, with python-net, python-base,
python-text, &c.

I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the
binary, and install two packages of Elisp code (EFS and xemacs-base).
Then you run xemacs, do Options > Manage Packages > List and Install,
and you get a nice list containing GNUS, W3, programming language
modes, etc.  Pick the ones you want, it adds the ones needed by the
ones you selected, and it fetches and installs them.  Easy!  Now
imagine doing the same thing with Python modules.  Of course, we'd
have to design that feature first...

(ESR & Paul Prescod vs. AMK & GPW: the First Pythonic War! :) )

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
This is, after all, a book about reading, and the kind of reader I am
addressing does not care primarily about being in fashion.
  -- Robertson Davies, _A Voice from the Attic_




From DavidA at ActiveState.com  Tue Jun 20 20:16:40 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 20 Jun 2000 11:16:40 -0700
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEMCCNAA.mhammond@skippinet.com.au>
Message-ID: <PLEJJNOHDIGGLDPOGPJJCECJCJAA.DavidA@ActiveState.com>

> Peter:
>
> > Davids wrapper function implements a FIFO strategy for termination.
> > I think this is not desired.  Normally you want LIFO,
>
> Agreed.  LIFO is definately preferred IMO.

Agreed.  My wrapper was also from memory, and that was not at all the main
point of my post =).

--da




From akuchlin at cnri.reston.va.us  Tue Jun 20 20:17:47 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 14:17:47 -0400
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
In-Reply-To: <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 20, 2000 at 08:18:03PM +0200
References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid>
Message-ID: <20000620141747.D3142@amarok.cnri.reston.va.us>

On Tue, Jun 20, 2000 at 08:18:03PM +0200, Fredrik Lundh quoted FLD:
>>   What is "sip"?  Is it defined by an RFC (which?), or Internet Draft
>> (which?  what's the expected activity?).

Is there a canonical list of all the defined URL types anywhere?  I
notice that 'ldap' isn't there, and maybe there are more missing.
(Some of the ones in there are marginal: who cares about Prospero?)

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
That's so obvious that someone has already got a patent on it.
  -- Guido van Rossum, 12 Jan 1999

 



From DavidA at ActiveState.com  Tue Jun 20 20:29:26 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 20 Jun 2000 11:29:26 -0700
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
In-Reply-To: <20000620141747.D3142@amarok.cnri.reston.va.us>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAECLCJAA.DavidA@ActiveState.com>

> Is there a canonical list of all the defined URL types anywhere?  I
> notice that 'ldap' isn't there, and maybe there are more missing.
> (Some of the ones in there are marginal: who cares about Prospero?)

Mozilla defines a bunch, which I doubt are RFC anything. (chrome://,
component://, etc.).

--david




From jeremy at beopen.com  Tue Jun 20 20:33:59 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 20 Jun 2000 14:33:59 -0400 (EDT)
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620140406.B3142@amarok.cnri.reston.va.us>
References: <20000609215719.47624E2673@oratrix.oratrix.nl>
	<20000609181924.A15728@thyrsus.com>
	<20000620083344.A3499@ludwig.cnri.reston.va.us>
	<20000620140419.C10038@thyrsus.com>
	<20000620140406.B3142@amarok.cnri.reston.va.us>
Message-ID: <14671.47383.313007.531923@localhost.localdomain>

>>>>> "AMK" == Andrew M Kuchling <akuchlin at cnri.reston.va.us> writes:

  AMK> I just compiled XEmacs 21.1.10 on a new Linux machine; you
  AMK> compile the binary, and install two packages of Elisp code (EFS
  AMK> and xemacs-base).  Then you run xemacs, do Options > Manage
  AMK> Packages > List and Install, and you get a nice list containing
  AMK> GNUS, W3, programming language modes, etc.  Pick the ones you
  AMK> want, it adds the ones needed by the ones you selected, and it
  AMK> fetches and installs them.  Easy!  Now imagine doing the same
  AMK> thing with Python modules.  Of course, we'd have to design that
  AMK> feature first...

I did the same install on my new Linux box last month.  I was
similarly pleased with the ease of installation.  Let's get working on
a design for this feature!

Jeremy



From effbot at telia.com  Tue Jun 20 20:37:30 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 20:37:30 +0200
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us>
Message-ID: <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid>

amk wrote:
> Is there a canonical list of all the defined URL types anywhere?  I
> notice that 'ldap' isn't there, and maybe there are more missing.

your local search bot to the rescue:
http://www.isi.edu/in-notes/iana/assignments/url-schemes

(see http://www.iana.org/numbers.htm for a full list of things
they keep track of)

</F>




From akuchlin at cnri.reston.va.us  Tue Jun 20 20:44:40 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 14:44:40 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <14671.47383.313007.531923@localhost.localdomain>; from jeremy@beopen.com on Tue, Jun 20, 2000 at 02:33:59PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> <14671.47383.313007.531923@localhost.localdomain>
Message-ID: <20000620144440.E3142@amarok.cnri.reston.va.us>

On Tue, Jun 20, 2000 at 02:33:59PM -0400, Jeremy Hylton wrote:
>I did the same install on my new Linux box last month.  I was
>similarly pleased with the ease of installation.  Let's get working on
>a design for this feature!

I have some notes on this, but they're at home.  I'll post them tonight.

--amk



From paul at prescod.net  Tue Jun 20 20:42:21 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 20 Jun 2000 13:42:21 -0500
Subject: [Python-Dev] RFC: Including PIL in 1.6
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us>
Message-ID: <394FBB0D.96D88DBB@prescod.net>

"Andrew M. Kuchling" wrote:
> 
> ...
> 
> I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the
> binary, and install two packages of Elisp code (EFS and xemacs-base).
> Then you run xemacs, do Options > Manage Packages > List and Install,
> and you get a nice list containing GNUS, W3, programming language
> modes, etc.  Pick the ones you want, it adds the ones needed by the
> ones you selected, and it fetches and installs them.  Easy!  Now
> imagine doing the same thing with Python modules.  Of course, we'd
> have to design that feature first...

Let me repeat that I don't think that the main issue is whether it lives
in this tarfile versus that tarfile. It's 

 a) about agreeing to keep everything comptible.
 b) about being able to depend on the thing being there when you write a
module.

*In theory* Red Hat linux could be a kernel, a shell and the RPM engine.
In practice, people like to be able to say: "if you have Red Hat version
X then such and such will work because it comes with a functional
package Y."

Distutils is extremely important for vertical modules but if we start to
use it as an excuse for leaving out core modules then I have to go with
ESR and say: "where do we stop?" 

Unicode on demand? re on demand? pickle on demand?

I think that the more relevant criteria are the ones we have always
used:

 * how big is it
 * how easy is it to maintain
 * how integrated is it with everything else
 * how well-thought-out is it
 * and most important: how many people want it?

I think that PIL is not yet a clear home run.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Music is the stuff between the notes." - Claude Debussy



From guido at python.org  Tue Jun 20 22:09:05 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 20 Jun 2000 15:09:05 -0500
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: Your message of "Tue, 20 Jun 2000 14:04:06 -0400."
             <20000620140406.B3142@amarok.cnri.reston.va.us> 
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com>  
            <20000620140406.B3142@amarok.cnri.reston.va.us> 
Message-ID: <200006202009.PAA01064@cj20424-a.reston1.va.home.com>

> I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the
> binary, and install two packages of Elisp code (EFS and xemacs-base).
> Then you run xemacs, do Options > Manage Packages > List and Install,
> and you get a nice list containing GNUS, W3, programming language
> modes, etc.  Pick the ones you want, it adds the ones needed by the
> ones you selected, and it fetches and installs them.  Easy!  Now
> imagine doing the same thing with Python modules.  Of course, we'd
> have to design that feature first...

I just had to go through that process.  It was actually rather
painful, and I wouldn't have been able to succeed if it wasn't for
XEmax grandmaster Barry Warsaw standing next to me holding my hand for
a really long time...  The autofetcher appeared broken at first, then
had some unintuitive behavior next, before we finally got it running.
Finally I got the hang of it, but after that I still had about a week
where I occasionally used a familiar keystroke that triggered an
error, and usually it took an email to Barry to find out which package
contained the module defining the missing function.

Not to say that I'm against this kind of thing, but warning that even
in the best circumstances it can be a hurdle for newcomers...

Which is why there's a market for packagers like Red Hat.

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



From guido at python.org  Tue Jun 20 22:12:09 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 20 Jun 2000 15:12:09 -0500
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
In-Reply-To: Your message of "Tue, 20 Jun 2000 20:37:30 +0200."
             <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> 
References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us>  
            <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> 
Message-ID: <200006202012.PAA01130@cj20424-a.reston1.va.home.com>

> > Is there a canonical list of all the defined URL types anywhere?  I
> > notice that 'ldap' isn't there, and maybe there are more missing.
> 
> your local search bot to the rescue:
> http://www.isi.edu/in-notes/iana/assignments/url-schemes

Of course now the trick is which ones are still relevant (as the
doubt expressed about prospero exemplify).

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



From fdrake at beopen.com  Tue Jun 20 21:10:31 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 20 Jun 2000 15:10:31 -0400 (EDT)
Subject: [Python-Dev] David Ascher's compile.py script?
Message-ID: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>

  Does anyone have a copy of David Ascher's compile.py from his
starship pages?  The links there appear to be broken, and David
appearantly hasn't been able to find time to look for a copy, or can't
find it (I've sent him another mail about it in case it has turned
up), and documentation users are asking about it.  (There's a link
from the extending & embedding manual.)
  If anyone has a copy, perhaps I could find provide a temporary
location for it and revise the link in the online documentation to
point there, as a stop-gap measure.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From nascheme at enme.ucalgary.ca  Tue Jun 20 21:18:03 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Tue, 20 Jun 2000 13:18:03 -0600
Subject: [Python-Dev] David Ascher's compile.py script?
In-Reply-To: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jun 20, 2000 at 03:10:31PM -0400
References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>
Message-ID: <20000620131803.A13811@acs.ucalgary.ca>

On Tue, Jun 20, 2000 at 03:10:31PM -0400, Fred L. Drake, Jr. wrote:
>   Does anyone have a copy of David Ascher's compile.py from his
> starship pages?

I don't know how recent this copy is:

    http://www.enme.ucalgary.ca/~nascheme/python/compile.py

  Neil



From fdrake at beopen.com  Tue Jun 20 21:19:05 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 20 Jun 2000 15:19:05 -0400 (EDT)
Subject: [Python-Dev] David Ascher's compile.py script?
In-Reply-To: <20000620131803.A13811@acs.ucalgary.ca>
References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>
	<20000620131803.A13811@acs.ucalgary.ca>
Message-ID: <14671.50089.860177.145255@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > I don't know how recent this copy is:
 > 
 >     http://www.enme.ucalgary.ca/~nascheme/python/compile.py

  Thanks!  If nothing else shows up within the next day, I'll use this
one.
  David, is this sufficiently recent?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From skip at mojam.com  Tue Jun 20 21:33:20 2000
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 20 Jun 2000 14:33:20 -0500 (CDT)
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com>
References: <20000609215719.47624E2673@oratrix.oratrix.nl>
	<20000609181924.A15728@thyrsus.com>
	<20000620083344.A3499@ludwig.cnri.reston.va.us>
	<20000620140419.C10038@thyrsus.com>
	<20000620140406.B3142@amarok.cnri.reston.va.us>
	<200006202009.PAA01064@cj20424-a.reston1.va.home.com>
Message-ID: <14671.50944.796299.47756@beluga.mojam.com>

    Guido> I just had to go through that process.  It was actually rather
    Guido> painful ...

I will echo that sentiment.  Actually, the first time I upgraded to the
package stuff it went without a hitch.  The next time it took me awhile to
figure out why it didn't work.

I imagine it's just teething pain that will get worked out as the XEmacs
folks get more experience themselves, but auto-package install is definitely
something that would have to be pretty bulletproof.  I doubt the average
Python user will have a similar level of computer savvy as the average
XEmacs user.

On top of that, how will you know that you want package X until you download
it and try it out?  I presume that carried to its logical conclusion, a
package's documentation would be installed along with its source...

chicken-and-egg-ly y'rs,

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395



From paul at prescod.net  Tue Jun 20 22:09:18 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 20 Jun 2000 15:09:18 -0500
Subject: [Python-Dev] Argh...
Message-ID: <394FCF6E.85559D56@prescod.net>

Okay, this is blatantly off-topic. I'm trying to increase the noise
ratio so that people here will go back to comp.lang.python.

All I need is for someone to email me in private email what's the Java
equivalent of 

a=sys.argv[0]

(it's almost over, it's almost over, it's almost over)

Okay, here's an obPython: why doesn't the main module have an __file__
if it happens to be a file. I can understand why one piped in wouldn't
but the interpreter knows when the main module is a file.

-- 
 Paul Prescod
"Music is the stuff between the notes." - Claude Debussy



From guido at python.org  Tue Jun 20 23:31:00 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 20 Jun 2000 16:31:00 -0500
Subject: [Python-Dev] Argh...
In-Reply-To: Your message of "Tue, 20 Jun 2000 15:09:18 EST."
             <394FCF6E.85559D56@prescod.net> 
References: <394FCF6E.85559D56@prescod.net> 
Message-ID: <200006202131.QAA01631@cj20424-a.reston1.va.home.com>

> Okay, here's an obPython: why doesn't the main module have an __file__
> if it happens to be a file. I can understand why one piped in wouldn't
> but the interpreter knows when the main module is a file.

Mostly because it's tough to pass that information around all the way
to where it's needed.

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



From mhammond at skippinet.com.au  Wed Jun 21 01:06:57 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 21 Jun 2000 09:06:57 +1000
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBKENCCNAA.mhammond@skippinet.com.au>

[Guido]

> Not to say that I'm against this kind of thing, but warning that even
> in the best circumstances it can be a hurdle for newcomers...
>
> Which is why there's a market for packagers like Red Hat.

And even _then_ it is hard to get right.

My experience similar to this was with debian, and its xptselect package.
I was a Linux newbie, and the entire installation went pretty well until I
was asked which packages I want to fetch and install.

I was _soooo_ lost.  I found the interface a complete mystery.  It appeard
to make random selections of stuff I didnt want, then randomly de-select
stuff I didnt want.  I had no idea how to search for anything, and the help
was less than useful.  Sometimes it wanted to download nothing, other times
it wanted to download 400MB to complete the install!!!  I only just
resisted the temptation to go and buy a bunch of MS stock <wink>.

Of course, within a week, I understood what was going on, and the sofware
was indeed functioning correctly.

But it took me that entire week to have a Linux system with everything I
wanted installed and working correctly.

The point I am trying to make is that for stuff that should be considered
"core", the bar is very very high for these auto-configure applications.
The usual audience will be _complete_ newbies.  In my example, it was clear
that a complete linux newbie was never let loose on this program while
sitting in the same room as the author or the marketting team ;-)  But I
expect those with reasonable Linux experience quite like it, and themselves
would not be happy with the complete-newbie version.

The-included-batteries-were-the-wrong-size-ly,

Mark.




From Vladimir.Marangozov at inrialpes.fr  Wed Jun 21 01:34:31 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Wed, 21 Jun 2000 01:34:31 +0200 (CEST)
Subject: [Python-Dev] Fw: Access violation when no memory
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au> from "Mark Hammond" at Jun 20, 2000 09:42:53 PM
Message-ID: <200006202334.BAA03150@python.inrialpes.fr>

Mark Hammond wrote:
> 
> >From the newsgroup.  Any thoughts?
> 
> Mark.
> 
> "Phil Mayes" <nospam at bitbucket.com> wrote in message
> news:<olD35.82$_%.4481 at newsfeed.avtel.net>...
> > The following program progressively allocates all memory:
> >     size = 1 << 20
> >     list = [None,]
> >     while size:
> >         try:
> >             mem = [None] * size
> >             mem[0] = list
> >             list = mem
> >         except:
> >             size = size / 2
> >
> > It fails with an access violation.

The only immediate thought I have is that Python does not have builtin
emergency procedures for such extreme situations. Although there are some
safety checks, it is fairly easy to crash the interpreter in a number of
ways.

For example, with the introduction of the mmapmodule, there are even more
"risks", like managing to mmap the python executable and screw it up
completely (not speaking of the possibility to introduce Trojan horses
and similar if this is done on purpose). There would probably be more
checks, but complete safety is hard to achieve in the current state.

The proposed solution is not a solution. The example program dumps core
in different locations on my machine. We just do not have enough control
from Python for managing such extreme cases. Sad, but true...

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From amk1 at erols.com  Wed Jun 21 03:46:43 2000
From: amk1 at erols.com (A.M. Kuchling)
Date: Tue, 20 Jun 2000 21:46:43 -0400
Subject: [Python-Dev] Installation requirements
Message-ID: <200006210146.VAA01220@207-172-37-166.s166.tnt7.ann.va.dialup.rcn.com>

[Follow-up to the Distutils SIG, please.]

There are a few steps needed to find and install a package:
1) Discovery : which module does what I need?
2) Download  : where can I get a copy?
3) Security  : is this actually from the package author, and not a Trojan?
4) Installation : how do I set it up?
5) Checking for new versions: I have 1.0 installed; is a newer version 
   available?

Distutils focuses on the hardest and most complicated step, #4.  

For #1, you would need to browse through a list of available packages,
browse through a hierarchy like Parnassus, or do keyword searches.

#2 is pretty simple, since you just get one or more download URLs
corresponding to a given package name, using the same database as in
#1.

For #3, you'd have to check a signature on the downloaded package,
using something external like GnuPG.  This means this step has to be
skipped if the external tool isn't available.  We could implement our
own signature scheme with Python code, but that's a bad idea; security
is hard, and few people will bother to generate keys that are only
useful for this one application of distributing Python modules.  (Side
note: the sdist and bdist_* commands should have a --sign switch to
sign the generated .tgz, .rpm, or whatever file.)

For #5, the existing stuff in Tools/versioncheck might be partially
applicable, though it requires that every package have a text file
somewhere which gives the latest version.  You'd want to use the same
database for everything, to ensure that people actually use it!

To start off with, we'd need some sort of generic API to the above
functions, so that different interfaces can be written.  A
command-line interface would then be easiest.

I don't know how network communications should be handled: HTTP to CGI
scripts that return sets of RFC-822 headers, maybe?  Combined with a
DNS alias like modules.python.org, or modules.{us,uk,...}.python.org?

Some potential sources of inspiration:

Debian: apt
Perl: CPAM.pm
FreeBSD: ports system
RPMfind (rpmfind.net)
XEmacs: packages system

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
  "Jo, it's a pity escapology wasn't part of your curriculum."
  "Funny you should say that. Look." <shows untied hand>
  -- The Doctor and Jo, tied up, in "Terror of the Autons"



From tim_one at email.msn.com  Wed Jun 21 05:44:18 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 20 Jun 2000 23:44:18 -0400
Subject: [Python-Dev] talking about performance...
In-Reply-To: <002001bfdae1$b28942e0$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEDPGFAA.tim_one@email.msn.com>

[posted & mailed]

[Fredrik Lundh]
> how about this one:
>
>     if (dir > 0) {
>         char *p, *e;
>         if (n == 0 && i <= last)
>             return (long)i;
>         e = s + last - n + 1;
>         for (;;) {
>             p = memchr(s, sub[0], e - s);
>             if (p == NULL)
>                 break;
>             if (n == 1 || memcmp(p, sub, n) == 0)
>                 return (long) (p - s);
>             s = p + 1;
>         }
>     }
>
> new record time: 1.6 seconds (down from 2.2)

I expect that whether this is faster or slower depends on both the compiler
you're using and the exact strings you're using to time it.

In any case, it appears to be incorrect:  p & s both change inside the
infinite loop, and the innermost return computes their difference.  Surely
it should be returning the difference between p and the value s had *before*
the loop was entered.  If this passed your tests, then, it suggests you had
no "false hits" (i.e., that the inner loop returned on its first iteration,
else the return value would have been wrong), which are probably the cases
in which using memchr rather than the current code is least likely to slow
things down.

It's bad that the original code never bothered to document what it's
supposed to return, but that's no excuse to return probabilistically-correct
gibberish <wink>.





From tim_one at email.msn.com  Wed Jun 21 05:44:25 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 20 Jun 2000 23:44:25 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <20000620132150.O8678@thyrsus.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>

[Ka-Ping Yee]
> I just have to say i thought list comprehensions were
> really cool.

[Eric S. Raymond]
> Ditto.  I would like to see this in 1.6.

Nobody has been more vocal in support of these (& augmented assignments)
than me, but I very strongly doubt they'll be in 1.6.  In the interests of
getting that out the door, Guido considers the 1.6 feature set to be frozen
already.

I think part of the pressure to get one more feature in Python (again &
again & again) is that release cycles have been soooooo protracted, now
slobbering well over the full year mark.  If I accomplish nothing else at
BeOpen, I want to give that a major speed boost -- I don't think we should
ever let 6 months go by without at least pumping out a bugfix release.

there-are-other-things-guido-doesn't-yet-know-he-believes-too<wink>-ly
    y'rs  - tim





From skip at mojam.com  Wed Jun 21 06:33:12 2000
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 20 Jun 2000 23:33:12 -0500 (CDT)
Subject: [Python-Dev] feeble attempt at list comprehensions doc...
Message-ID: <14672.17800.994102.266619@beluga.mojam.com>


Attached to this message are two patches, one for Doc/ref/ref5.tex and one
for Doc/tut/tut.tex.  They provide minimal documentation for list
comprehensions.  I'm sure just about anyone else could do better.  Feel free 
to embellish.

The BNF used in the reference manual doesn't seem to match the BNF in the
Grammar file very well, so I'm not even certain I have the correct BNF or
have it in the correct place.  In particular, I'm pretty sure the
BNF for list_for and list_if are incorrect.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tut.diff
Type: application/octet-stream
Size: 1000 bytes
Desc: list comprehension diffs
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000620/2acdcca6/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ref5.diff
Type: application/octet-stream
Size: 1141 bytes
Desc: reference manual diff
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000620/2acdcca6/attachment-0001.obj>

From tim_one at email.msn.com  Wed Jun 21 06:53:59 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 21 Jun 2000 00:53:59 -0400
Subject: [Python-Dev] Warnings in mmapmodule
Message-ID: <LNBBLJKPBEHFEDALKOLCOEEDGFAA.tim_one@email.msn.com>

I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
mismatches:

Modules\mmapmodule.c(571) : warning C4018: '>=' : signed/unsigned mismatch
	if (i < 0 || i >= self->size) {
Modules\mmapmodule.c(586) : warning C4018: '>' : signed/unsigned mismatch
	else if (ilow > self->size)
Modules\mmapmodule.c(592) : warning C4018: '>' : signed/unsigned mismatch
	else if (ihigh > self->size)
Modules\mmapmodule.c(631) : warning C4018: '>' : signed/unsigned mismatch
	else if (ilow > self->size)
Modules\mmapmodule.c(637) : warning C4018: '>' : signed/unsigned mismatch
	else if (ihigh > self->size)
Modules\mmapmodule.c(664) : warning C4018: '>=' : signed/unsigned mismatch
	if (i < 0 || i >= self->size) {

I'll volunteer to fix these if nobody else does (although at the moment I'm
not able to produce either a patch or check in).

new-laptops-in-hotel-rooms-have-their-limitations-ly y'rs  - tim





From mhammond at skippinet.com.au  Wed Jun 21 06:57:54 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 21 Jun 2000 14:57:54 +1000
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEEDGFAA.tim_one@email.msn.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEOACNAA.mhammond@skippinet.com.au>

> I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
> mismatches:

Me too :-)

> I'll volunteer to fix these if nobody else does (although at the
> moment I'm
> not able to produce either a patch or check in).

I nearly did, but then couldnt find the time to chase up how Unix declared
the relevant items - I didnt want to assume they were identical to Windows.

My intention was to make the patch, then test it out on my gleaming Linux
box.

But-the-road-to-hell-is-paved-with-good-intentions-ly,

Mark.




From tim_one at email.msn.com  Wed Jun 21 07:22:37 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 21 Jun 2000 01:22:37 -0400
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBIEOACNAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>

[posted & mailed]

[Tim]
> I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
> mismatches:

[Mark Hammond]
> Me too :-)
>
> I nearly [fixed them], but then couldnt find the time to chase up how
> Unix declared the relevant items - I didnt want to assume they were
> identical to Windows.

They all involve mixing ints with mmap_object.size in comparisons, which
latter is declared size_t and so will resolve to *some* unsigned integral
type on all platforms.  The proper fix is to get rid of the ints before
making these tests -- ask Trent, he should be able to do this in his sleep
now <wink>.

> My intention was to make the patch, then test it out on my gleaming Linux
> box.
>
> But-the-road-to-hell-is-paved-with-good-intentions-ly,

No, it's paved with Linux:  I've been using Windows so long I forgot why
Unix is supposed to be more usable <0.9 wink>.  Mark, if you've figured out
how to do a SourceForge checkin from a Windows box, drop me a line offline!
It would save me from figuring out which one of the 10,000 SSH+Windows
search hits actually leads to something that works (and, no, so long as my
entire life is sitting on my laptop, I'm not getting another OS anywhere
near this box).

becoming-a-linux-true-believer-again-is-on-my-schedule-but-not-
    for-a-couple-months-ly y'rs  - tim





From DavidA at ActiveState.com  Wed Jun 21 07:40:36 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 20 Jun 2000 22:40:36 -0700
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>
Message-ID: <LMBBIEIJKMPMLBONJMFCIEBLCJAA.DavidA@ActiveState.com>

> No, it's paved with Linux:  I've been using Windows so long I forgot why
> Unix is supposed to be more usable <0.9 wink>.  Mark, if you've
> figured out
> how to do a SourceForge checkin from a Windows box, drop me a
> line offline!

No, please, drop us all a line online!  I've decided that I'm not going to
waste any more of my time dealing w/ SourceForge.  Luckily I seem to have
found some helpers for the PyOpenGL transition who are willing to deal with
that!

--david




From mhammond at skippinet.com.au  Wed Jun 21 07:49:45 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 21 Jun 2000 15:49:45 +1000
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <LMBBIEIJKMPMLBONJMFCIEBLCJAA.DavidA@ActiveState.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au>

[David]
> No, please, drop us all a line online!

OK - here it is, for what it is worth.  You will notice that I spent the
time to research my facts carefully before giving out this information
(NOT!)

Sure.  It is a bit of a PITA (surprise, surprise, surprise):

First, get the latest WinCVS.  Has some nice new features.  Mine shows as
1.1b13.  It has a slightly ?slicker? more windowsy look than the older one.
What we really want is the version with the Options/Preferences dialog that
allows you to supply the ?RAS identity? file when you select ?SSH Server?
as the auth method.  Previous versions allow you to select the SSH Server,
but give you nowhere to put the identity file.  Hence previous versions
used a batch file wrapper, which you probably saw reference to.  This
version makes it much simpler.

I use the standard SSH Version 1.2.14 binary set.  I cant recall the URL,
but it is quite small and only a few binary files.  ?ssh? shows usage -
?ssh -v? shows versbose usage, ?verbose? in this context apparently means
showing the version number (took me ages to work that one out :-)

There were only a few files, so I just dumped them all in the same
directory as the CVS binaries.

You then need to make a ?key? file - I cant recall the exact process, but
it is pretty simple.  This is creating the identify file you specify to
WinCVS, as well as the public key you upload to source-force.

NOTE - from memory, you MUST have a HOME env var set, and you MUST have a
?.ssh? directory under your home.  Otherwise you get cryptic errors from
SSH that give no clue that this is the problem.

After uploading the public key to source forge, you are nearly set.  The
last step is convinving CVS that you want to use this new SSH setting, and
not the setting CVS so kindly persists in its ?CVS\Root? files.  The only
way I found to do this was to either edit the Root files manually, or
remove the directories locally and force CVS to re-create them (and thereby
re-pull everything - I assume you have ADSL in that hotel room :-)
Alternatively, dig up that CVS script posted to py-dev recently and change
it - personally, I never trusted it :-)

All my root files look like:
:ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python

Yours almost certainly will be setup for anon access, not using ssh.

Hope that makes sense.  Im happy to chase anything else up I can for you...

Mark.




From effbot at telia.com  Wed Jun 21 09:58:06 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 21 Jun 2000 09:58:06 +0200
Subject: [Python-Dev] talking about performance...
References: <LNBBLJKPBEHFEDALKOLCAEDPGFAA.tim_one@email.msn.com>
Message-ID: <006401bfdb56$6f84ae60$f2a6b5d4@hagrid>

tim wrote:

> >             p = memchr(s, sub[0], e - s);
> >             if (p == NULL)
> >                 break;
> >             if (n == 1 || memcmp(p, sub, n) == 0)
> >                 return (long) (p - s);

> I expect that whether this is faster or slower depends on both the compiler
> you're using and the exact strings you're using to time it.

With test strings that contain false matches for every single
position, it's 30% slower than the old code in my tests.  With
test strings that contain no false matches, it's 50% faster.

But without more extensive tests on a variety of platforms, we
might as well forget about this one...

</F>




From mal at lemburg.com  Wed Jun 21 10:23:02 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Jun 2000 10:23:02 +0200
Subject: [Python-Dev] Proposal: standard way of defining and executing 
 "atexit" functions...
References: <PLEJJNOHDIGGLDPOGPJJCECJCJAA.DavidA@ActiveState.com>
Message-ID: <39507B66.763DB418@lemburg.com>

[Skip's exit.py module + David's extension to support already
 registered exitfunc'tions]

Looks like everyone agrees -- with a final word from Guido
we'd only need some docs to go with it and then check Skip's
module in as new standard module.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From skip at mojam.com  Wed Jun 21 15:38:01 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 21 Jun 2000 08:38:01 -0500 (CDT)
Subject: [Python-Dev] Proposal: standard way of defining and executing 
 "atexit" functions...
In-Reply-To: <39507B66.763DB418@lemburg.com>
References: <PLEJJNOHDIGGLDPOGPJJCECJCJAA.DavidA@ActiveState.com>
	<39507B66.763DB418@lemburg.com>
Message-ID: <14672.50489.611301.616242@beluga.mojam.com>

    MA> Looks like everyone agrees -- with a final word from Guido we'd only
    MA> need some docs to go with it and then check Skip's module in as new
    MA> standard module.

I'll try to get David's enhancement added to my code and write some simple
documentation today.  Is "exit.py" acceptable with everyone as the name of
the module?

Skip



From skip at mojam.com  Wed Jun 21 20:15:19 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 21 Jun 2000 13:15:19 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
Message-ID: <14673.1591.506532.170015@beluga.mojam.com>

This message contains four attached files:

    Lib/exit.py	- a module that allows users to register cleanup functions
    Lib/test/test_exit.py - a simple test script
    Lib/test/output/test_exit - expected test output
    Doc/lib/libexit.tex - library reference manual section

Besides adding documentation and a test script, the following two mods were
made to exit.py since I previously posted it:

    1. It implements a LIFO execution order
    2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is 
       treated as an exit function and appended to the exit function list.

Comments, please.  Also, can someone tell me how to coax CVS into creating a 
unified diff that actually contains new files?  I tried

    cvs diff -RNau

without success.

Thanks,

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exit.py
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000621/bf1b7236/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_exit.py
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000621/bf1b7236/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_exit
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000621/bf1b7236/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libexit.tex
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000621/bf1b7236/attachment-0001.asc>

From trentm at activestate.com  Wed Jun 21 21:20:12 2000
From: trentm at activestate.com (Trent Mick)
Date: Wed, 21 Jun 2000 12:20:12 -0700
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>
References: <ECEPKNMJLHAPFFJHDOJBIEOACNAA.mhammond@skippinet.com.au> <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>
Message-ID: <20000621122012.A28236@activestate.com>

On Wed, Jun 21, 2000 at 01:22:37AM -0400, Tim Peters wrote:
> [posted & mailed]
> 
> [Tim]
> > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
> > mismatches:
> 
> [Mark Hammond]
> > Me too :-)
> >
> > I nearly [fixed them], but then couldnt find the time to chase up how
> > Unix declared the relevant items - I didnt want to assume they were
> > identical to Windows.
> 
> They all involve mixing ints with mmap_object.size in comparisons, which
> latter is declared size_t and so will resolve to *some* unsigned integral
> type on all platforms.  The proper fix is to get rid of the ints before
> making these tests -- ask Trent, he should be able to do this in his sleep
> now <wink>.
> 

I wish I could do it in my sleep, then I would be much more well rested. Yes
I will clean these up. I was going to look at mmap a little anyway as
test_mmap currently fails on Win32 (probably as a resul of my mmpa patch).

Trent


-- 
Trent Mick
trentm at activestate.com



From DavidA at ActiveState.com  Wed Jun 21 19:25:07 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Wed, 21 Jun 2000 10:25:07 -0700
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>

> First, get the latest WinCVS.

	http://www.wincvs.org/download.html

> I use the standard SSH Version 1.2.14 binary set.  I cant recall the URL,

There's a version at:

      ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip

BUT...

> You then need to make a ?key? file - I cant recall the exact process, but
> it is pretty simple.  This is creating the identify file you specify to
> WinCVS, as well as the public key you upload to source-force.

	C:\WinCVS>ssh-keygen

I always get a 'gethostname: no such file or directory' so I had to create
the key on Linux (as is mentioned in the page
http://bmrc.berkeley.edu/people/chaffee/winntutil.html).

Maybe you have a better binary for ssh?

> NOTE - from memory, you MUST have a HOME env var set, and you MUST have a
> ?.ssh? directory under your home.  Otherwise you get cryptic errors from
> SSH that give no clue that this is the problem.
>
> After uploading the public key to source forge, you are nearly set.

How do you do that?

> The
> last step is convinving CVS that you want to use this new SSH setting, and
> not the setting CVS so kindly persists in its ?CVS\Root? files.  The only
> way I found to do this was to either edit the Root files manually, or
> remove the directories locally and force CVS to re-create them
> (and thereby
> re-pull everything - I assume you have ADSL in that hotel room :-)
> Alternatively, dig up that CVS script posted to py-dev recently and change
> it - personally, I never trusted it :-)
>
> All my root files look like:
> :ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python
>
> Yours almost certainly will be setup for anon access, not using ssh.
>
> Hope that makes sense.  Im happy to chase anything else up I can
> for you...
>
> Mark.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
>




From akuchlin at cnri.reston.va.us  Wed Jun 21 22:27:31 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Wed, 21 Jun 2000 16:27:31 -0400
Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400
References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEGHGFAA.tim_one@email.msn.com> <14673.158.183876.75480@localhost.localdomain>
Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us>

On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote:
>>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:
>  TP> + This mailing list doesn't work.  At least the SourceForge
>I agree that it's a complete mess, though.

While you're all admiring the difficulty of the problem, how about
actually checking in the pythonrun.c patch, assuming it's reasonable?

<flame> 

Frankly, I don't think the current mailing list is broken, *as long as
patches are handled with reasonable speed* so that the backlog doesn't
build up.  That hasn't been done, and I don't understand why.
Obviously the CNRI->BeOpen transaction resulted in some downtime for
everyone, but now it's a month later and there's still stagnation.
Why aren't incoming patches being handled now?  It's not like there
are very many patches per day; an hour or two should suffice to keep
the queue from growing.

At this point, the best fix is to do two things:

1) Someone downloads the mbox archives of the patches list, and goes
through all the past patches: apply them, discard them, send them back
for revision.

2) Commit to handling new patches that arrive, and either
apply/discard/revise them.

Worrying about patch management mechanism, while more patches pile up
and are ignored in the meantime, is not going to help and will just
results in continued stagnation.  
</flame>

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I couldn't think of one clever way to stop this guy, so I just trusted to
mindless violence.
  -- Cliff Steele in DOOM PATROL #21




From akuchlin at cnri.reston.va.us  Wed Jun 21 22:27:31 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Wed, 21 Jun 2000 16:27:31 -0400
Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400
References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEGHGFAA.tim_one@email.msn.com> <14673.158.183876.75480@localhost.localdomain>
Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us>

On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote:
>>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:
>  TP> + This mailing list doesn't work.  At least the SourceForge
>I agree that it's a complete mess, though.

While you're all admiring the difficulty of the problem, how about
actually checking in the pythonrun.c patch, assuming it's reasonable?

<flame> 

Frankly, I don't think the current mailing list is broken, *as long as
patches are handled with reasonable speed* so that the backlog doesn't
build up.  That hasn't been done, and I don't understand why.
Obviously the CNRI->BeOpen transaction resulted in some downtime for
everyone, but now it's a month later and there's still stagnation.
Why aren't incoming patches being handled now?  It's not like there
are very many patches per day; an hour or two should suffice to keep
the queue from growing.

At this point, the best fix is to do two things:

1) Someone downloads the mbox archives of the patches list, and goes
through all the past patches: apply them, discard them, send them back
for revision.

2) Commit to handling new patches that arrive, and either
apply/discard/revise them.

Worrying about patch management mechanism, while more patches pile up
and are ignored in the meantime, is not going to help and will just
results in continued stagnation.  
</flame>

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I couldn't think of one clever way to stop this guy, so I just trusted to
mindless violence.
  -- Cliff Steele in DOOM PATROL #21




From akuchlin at cnri.reston.va.us  Wed Jun 21 22:27:31 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Wed, 21 Jun 2000 16:27:31 -0400
Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400
References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEGHGFAA.tim_one@email.msn.com> <14673.158.183876.75480@localhost.localdomain>
Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us>

On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote:
>>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:
>  TP> + This mailing list doesn't work.  At least the SourceForge
>I agree that it's a complete mess, though.

While you're all admiring the difficulty of the problem, how about
actually checking in the pythonrun.c patch, assuming it's reasonable?

<flame> 

Frankly, I don't think the current mailing list is broken, *as long as
patches are handled with reasonable speed* so that the backlog doesn't
build up.  That hasn't been done, and I don't understand why.
Obviously the CNRI->BeOpen transaction resulted in some downtime for
everyone, but now it's a month later and there's still stagnation.
Why aren't incoming patches being handled now?  It's not like there
are very many patches per day; an hour or two should suffice to keep
the queue from growing.

At this point, the best fix is to do two things:

1) Someone downloads the mbox archives of the patches list, and goes
through all the past patches: apply them, discard them, send them back
for revision.

2) Commit to handling new patches that arrive, and either
apply/discard/revise them.

Worrying about patch management mechanism, while more patches pile up
and are ignored in the meantime, is not going to help and will just
results in continued stagnation.  
</flame>

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I couldn't think of one clever way to stop this guy, so I just trusted to
mindless violence.
  -- Cliff Steele in DOOM PATROL #21




From guido at python.org  Thu Jun 22 00:55:22 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 21 Jun 2000 17:55:22 -0500
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: Your message of "Wed, 21 Jun 2000 13:15:19 EST."
             <14673.1591.506532.170015@beluga.mojam.com> 
References: <14673.1591.506532.170015@beluga.mojam.com> 
Message-ID: <200006212255.RAA02444@cj20424-a.reston1.va.home.com>

If I had designed this, I might have called the module "onexit" or
"atexit" and the public function simply "register()".  But I've got
only a +0 for my own proposal.  A +1 for the general idea.

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



From paul at prescod.net  Thu Jun 22 00:13:39 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 21 Jun 2000 17:13:39 -0500
Subject: [Python-Dev] list comprehensions
References: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>
Message-ID: <39513E13.F8082811@prescod.net>

Tim Peters wrote:
> 
> ...
> Nobody has been more vocal in support of these (& augmented assignments)
> than me, but I very strongly doubt they'll be in 1.6.  In the interests of
> getting that out the door, Guido considers the 1.6 feature set to be frozen
> already.

Is there an argument for putting in features with flaming red neon
lights: "warning, experimental, use at your risk." We want to follow a
bazaar (if not outright bizarre) development strategy after all. Putting
a patch "out there" really doesn't do much about having people really
play with and comment on a feature. I would never have experimented (and
decided against using...) metaclasses if they hadn't popped up as an
experimental feature.

Of course if there is a decent chance of breaking something already in
there that works then that's another issue...

> I think part of the pressure to get one more feature in Python (again &
> again & again) is that release cycles have been soooooo protracted, now
> slobbering well over the full year mark.  

Nah, no matter how quick you do the turnarounds, nobody wants to wait
for their favorite feature. :)

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Floggings will continue until morale improves.



From DavidA at ActiveState.com  Wed Jun 21 19:25:07 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Wed, 21 Jun 2000 10:25:07 -0700
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>

> First, get the latest WinCVS.

	http://www.wincvs.org/download.html

> I use the standard SSH Version 1.2.14 binary set.  I cant recall the URL,

There's a version at:

      ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip

BUT...

> You then need to make a ?key? file - I cant recall the exact process, but
> it is pretty simple.  This is creating the identify file you specify to
> WinCVS, as well as the public key you upload to source-force.

	C:\WinCVS>ssh-keygen

I always get a 'gethostname: no such file or directory' so I had to create
the key on Linux (as is mentioned in the page
http://bmrc.berkeley.edu/people/chaffee/winntutil.html).

Maybe you have a better binary for ssh?

> NOTE - from memory, you MUST have a HOME env var set, and you MUST have a
> ?.ssh? directory under your home.  Otherwise you get cryptic errors from
> SSH that give no clue that this is the problem.
>
> After uploading the public key to source forge, you are nearly set.

How do you do that?

> The
> last step is convinving CVS that you want to use this new SSH setting, and
> not the setting CVS so kindly persists in its ?CVS\Root? files.  The only
> way I found to do this was to either edit the Root files manually, or
> remove the directories locally and force CVS to re-create them
> (and thereby
> re-pull everything - I assume you have ADSL in that hotel room :-)
> Alternatively, dig up that CVS script posted to py-dev recently and change
> it - personally, I never trusted it :-)
>
> All my root files look like:
> :ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python
>
> Yours almost certainly will be setup for anon access, not using ssh.
>
> Hope that makes sense.  Im happy to chase anything else up I can
> for you...
>
> Mark.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
>




From nascheme at enme.ucalgary.ca  Thu Jun 22 02:25:46 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Wed, 21 Jun 2000 18:25:46 -0600
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14673.1591.506532.170015@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 01:15:19PM -0500
References: <14673.1591.506532.170015@beluga.mojam.com>
Message-ID: <20000621182546.B25879@acs.ucalgary.ca>

On Wed, Jun 21, 2000 at 01:15:19PM -0500, Skip Montanaro wrote:
> Also, can someone tell me how to coax CVS into creating a 
> unified diff that actually contains new files?  I tried
> 
>     cvs diff -RNau
> 
> without success.

Did you "cvs add" them?

  Neil

-- 
"Simplicity does not precede complexity, but follows it." -- Alan Perlis



From skip at mojam.com  Thu Jun 22 02:39:03 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 21 Jun 2000 19:39:03 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <20000621182546.B25879@acs.ucalgary.ca>
References: <14673.1591.506532.170015@beluga.mojam.com>
	<20000621182546.B25879@acs.ucalgary.ca>
Message-ID: <14673.24615.291912.261214@beluga.mojam.com>

    >> Also, can someone tell me how to coax CVS into creating a unified
    >> diff that actually contains new files?  I tried
    >> 
    >> cvs diff -RNau
    >> 
    >> without success.

    Neil> Did you "cvs add" them?

Not something I could do, since I'm cvs'ing against the sourceforge
repository.  The best I guess I can do is to mirror the repository twice,
add the new files to one tree, then perform a regular diff...

Skip



From esr at thyrsus.com  Thu Jun 22 04:09:35 2000
From: esr at thyrsus.com (esr at thyrsus.com)
Date: Wed, 21 Jun 2000 22:09:35 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>
References: <20000620132150.O8678@thyrsus.com> <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>
Message-ID: <20000621220934.A1044@thyrsus.com>

Tim Peters <tim_one at email.msn.com>:
> Nobody has been more vocal in support of these (& augmented assignments)
> than me, but I very strongly doubt they'll be in 1.6.  In the interests of
> getting that out the door, Guido considers the 1.6 feature set to be frozen
> already.
> 
> I think part of the pressure to get one more feature in Python (again &
> again & again) is that release cycles have been soooooo protracted, now
> slobbering well over the full year mark.  If I accomplish nothing else at
> BeOpen, I want to give that a major speed boost -- I don't think we should
> ever let 6 months go by without at least pumping out a bugfix release.

OK, I can buy this.  Are there concrete plans (as in, a specified timeframe)
for a release in which new features will be admitted?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

What, then is law [government]? It is the collective organization of
the individual right to lawful defense."
	-- Frederic Bastiat, "The Law"



From mal at lemburg.com  Thu Jun 22 11:05:09 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 22 Jun 2000 11:05:09 +0200
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
References: <14673.1591.506532.170015@beluga.mojam.com>
Message-ID: <3951D6C5.BA31276B@lemburg.com>

> This message contains four attached files:
> 
>     Lib/exit.py - a module that allows users to register cleanup functions
>     Lib/test/test_exit.py - a simple test script
>     Lib/test/output/test_exit - expected test output
>     Doc/lib/libexit.tex - library reference manual section
> 
> Besides adding documentation and a test script, the following two mods were
> made to exit.py since I previously posted it:
> 
>     1. It implements a LIFO execution order
>     2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is 
>        treated as an exit function and appended to the exit function list.
> 
> Comments, please.

Looks ok to me, but since this is going to be a new standard
module I guess we should wait for Guido's ok before checking
it in.

> Also, can someone tell me how to coax CVS into creating a 
> unified diff that actually contains new files?  I tried
> 
>     cvs diff -RNau
> 
> without success.

I'm not an CVS expert, but I could imagine that you'll have to
add the files to CVS first and then run the above diff.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gstein at lyra.org  Thu Jun 22 15:30:53 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 22 Jun 2000 06:30:53 -0700
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>; from DavidA@ActiveState.com on Wed, Jun 21, 2000 at 10:25:07AM -0700
References: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au> <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>
Message-ID: <20000622063053.M29590@lyra.org>

On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote:
>...
> > You then need to make a ?key? file - I cant recall the exact process, but
> > it is pretty simple.  This is creating the identify file you specify to
> > WinCVS, as well as the public key you upload to source-force.
> 
> 	C:\WinCVS>ssh-keygen
> 
> I always get a 'gethostname: no such file or directory' so I had to create
> the key on Linux (as is mentioned in the page
> http://bmrc.berkeley.edu/people/chaffee/winntutil.html).
> 
> Maybe you have a better binary for ssh?

Nah. Mark just forgets that I generated the key for him from my Linux box :-)

hehe...

Cheers,
-g

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



From tim_one at email.msn.com  Thu Jun 22 15:46:15 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 22 Jun 2000 09:46:15 -0400
Subject: [Python-Dev] SourceForge vs Windows
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBCEOECNAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEINGFAA.tim_one@email.msn.com>

I have to get SourceForge developer access working with Windows (Win98SE,
specifically), so I'll write up detailed instructions along the way,
building on Mark Hammond's good clues.  Play along!  I'll accumulate
everyone's input & make a coherent how-to out of it.

Today's installment only covers the first step, as it took 12 hours for meto
complete it (rotten connectivity today, via 56K modem, requiring many
attempts at downloading before one succeeded):

[Mark Hammond]
> First, get the latest WinCVS.  Has some nice new features.  Mine shows
> as 1.1b13.  It has a slightly ?slicker? more windowsy look than the
> older one.  What we really want is the version with the
Options/Preferences
> dialog that allows you to supply the ?RAS identity? file when you select
> ?SSH Server? as the auth method.  Previous versions allow you to select
> the SSH Server, but give you nowhere to put the identity file.  Hence
> previous versions used a batch file wrapper, which you probably saw
> reference to.  This version makes it much simpler.

I picked up the 1.1b14 version, released 19 Jun 2000, from

    http://www.wincvs.org/download.html

It's a 3.21 Mb zip file.

hard-to-blow-it-so-far<wink>-ly y'rs  - tim






From tim_one at email.msn.com  Thu Jun 22 15:46:17 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 22 Jun 2000 09:46:17 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <20000621220934.A1044@thyrsus.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIOGFAA.tim_one@email.msn.com>

[Tim, sez the 1.6 feature set should be considered frozen, and that
 Python should move to a much less sloth-like release schedule
 thereafter]

[esr at thyrsus.com]
> OK, I can buy this.

Comes with a 30-day warranty, too <wink>.

> Are there concrete plans (as in, a specified timeframe)
> for a release in which new features will be admitted?

There damn well ought to be.  PythonLabs will be having its first all-hands
meeting tomorrow (Guido's been gone, I've been in this state less than a
week, & I'm still not sure Jeremy Hylton exists), and rational, timely
release schedules are certainly on my agenda.  I have no problem with new
features in minor releases either, provided they're 100% backward-compatible
(e.g., list comprehensions, yes (so long as they don't introduce new
bytecodes); having str(long) strip the trailing "L", no).  More when we know
more.

and-less-when-we-know-less-ly y'rs  - tim






From nascheme at enme.ucalgary.ca  Thu Jun 22 17:24:16 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 22 Jun 2000 09:24:16 -0600
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14673.24615.291912.261214@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 07:39:03PM -0500
References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> <14673.24615.291912.261214@beluga.mojam.com>
Message-ID: <20000622092416.A31223@acs.ucalgary.ca>

On Wed, Jun 21, 2000 at 07:39:03PM -0500, Skip Montanaro wrote:
>     Neil> Did you "cvs add" them?
> 
> Not something I could do, since I'm cvs'ing against the sourceforge
> repository.

That's okay.  "cvs add" only modifies things locally.  You have
to "cvs commit" to change things in the repository.

  Neil

-- 
The internet: Learn what you know.  Share what you don't.



From klm at digicool.com  Thu Jun 22 18:13:46 2000
From: klm at digicool.com (Ken Manheimer)
Date: Thu, 22 Jun 2000 12:13:46 -0400 (EDT)
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <20000622063053.M29590@lyra.org>
Message-ID: <Pine.LNX.4.21.0006221210510.19353-100000@korak.digicool.com>

A bit of a tangent, but MindTerm - http://www.mindbright.se/mindterm - is
a pretty nice java SSH client which you can use on windows to generate the
RSA identity.  (It also is a fine SSH client, with just about all the
nicities except compression - scp, x11 forwarding, arbitrary tunneling,
etc are all in there...)

Ken
klm at digicool.com

On Thu, 22 Jun 2000, Greg Stein wrote:

> On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote:
> >...
> > > You then need to make a ?key? file - I cant recall the exact process, but
> > > it is pretty simple.  This is creating the identify file you specify to
> > > WinCVS, as well as the public key you upload to source-force.
> > 
> > 	C:\WinCVS>ssh-keygen
> > 
> > I always get a 'gethostname: no such file or directory' so I had to create
> > the key on Linux (as is mentioned in the page
> > http://bmrc.berkeley.edu/people/chaffee/winntutil.html).
> > 
> > Maybe you have a better binary for ssh?
> 
> Nah. Mark just forgets that I generated the key for him from my Linux box :-)
> 
> hehe...
> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 




From skip at mojam.com  Thu Jun 22 19:21:04 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 22 Jun 2000 12:21:04 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <200006212255.RAA02444@cj20424-a.reston1.va.home.com>
References: <14673.1591.506532.170015@beluga.mojam.com>
	<200006212255.RAA02444@cj20424-a.reston1.va.home.com>
Message-ID: <14674.19200.325533.979792@beluga.mojam.com>

    Guido> If I had designed this, I might have called the module "onexit"
    Guido> or "atexit" and the public function simply "register()".  But
    Guido> I've got only a +0 for my own proposal.  A +1 for the general
    Guido> idea.

I'm happy to change things.  I was a bit curious if people would ask about
such a common word for a new module name.  What module name do people
prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not
careful), or something else?

Skip



From skip at mojam.com  Thu Jun 22 19:27:18 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 22 Jun 2000 12:27:18 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <20000622092416.A31223@acs.ucalgary.ca>
References: <14673.1591.506532.170015@beluga.mojam.com>
	<20000621182546.B25879@acs.ucalgary.ca>
	<14673.24615.291912.261214@beluga.mojam.com>
	<20000622092416.A31223@acs.ucalgary.ca>
Message-ID: <14674.19574.609843.392230@beluga.mojam.com>

    Neil> That's okay.  "cvs add" only modifies things locally.  You have to
    Neil> "cvs commit" to change things in the repository.

Ah, thanks for the tip.  I'll try that next time...

Skip



From tim_one at email.msn.com  Fri Jun 23 03:38:43 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 22 Jun 2000 21:38:43 -0400
Subject: [Python-Dev] RE: [Patches] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <20000621162731.B3918@amarok.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>

[Andrew M. Kuchling]
> While you're all admiring the difficulty of the problem, how about
> actually checking in the pythonrun.c patch, assuming it's reasonable?

I can't yet.  Be my guest!

> <flame>
>
> Frankly, I don't think the current mailing list is broken, *as long as
> patches are handled with reasonable speed* so that the backlog doesn't
> build up.

Andrew, this is saying that if it didn't display all the symptoms of
illness, it wouldn't be sick.  The consistent (this started long before
Guido's honeymoon!) lack of timely action here *is* the brokenness.

> That hasn't been done, and I don't understand why.

Why didn't you check in the pythonrun.c patch?  Multiply by 10 people and
100 patches.  There are no mechanisms in a mailing list for assigning,
recording or checking responsibility, neither for recording or querying
disposition status.  Nobody owns any part of the problem now, and it's
extraordinarly difficult to determine the status of any particular patch you
may be interested in via this mish-mash of archived all-topic email
scattered across patches and python-dev.

Prior to this mailing list, Guido owned every problem and the database was
in his head.  I think it's the lack of the "owned" and "database" parts
we're suffering from here, not especially the lack of the "Guido" part.
SourceForge provides rudimentary mechanisms for both of the former; a Python
replacement for Guido is one of BeOpen's highest secret priorities <wink>.

> ...
> Worrying about patch management mechanism, while more patches pile up
> and are ignored in the meantime, is not going to help and will just
> results in continued stagnation.

At an all-hands PythonLabs group mtg today, it was decided to move patch
activity to SourceForge and kill the patches list.  I'll send more about
that later.  There is absolutely nothing new stopping checkins while the
move to the SourceForge patch manager is in progress, so if the patches
continue to pile up it's certainly not the move's fault.  If the pythonrun.c
patch is still sitting untouched after the move, I'll assign it to you <0.7
wink>.

the-only-one-working-on-the-move-is-me-and-i-haven't-done-a-checkin-
    yet-anyway-ly y'rs  - tim





From mal at lemburg.com  Fri Jun 23 10:03:41 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 23 Jun 2000 10:03:41 +0200
Subject: [Python-Dev] Re: [Patches] Patch management (was: Warnings in pythonrun.c)
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>
Message-ID: <395319DD.F2584321@lemburg.com>

Tim Peters wrote:
> 
> > Worrying about patch management mechanism, while more patches pile up
> > and are ignored in the meantime, is not going to help and will just
> > results in continued stagnation.
> 
> At an all-hands PythonLabs group mtg today, it was decided to move patch
> activity to SourceForge and kill the patches list.  I'll send more about
> that later.  There is absolutely nothing new stopping checkins while the
> move to the SourceForge patch manager is in progress, so if the patches
> continue to pile up it's certainly not the move's fault.  If the pythonrun.c
> patch is still sitting untouched after the move, I'll assign it to you <0.7
> wink>.

But how are we going to discuss new patches from people outside
python-dev then ? I do see the use of moving patch submission
to SourceForge, but posting the patches on the list for
revision by everyone who listens is certainly better than
having to scan the patch manager entries... (push strategies
usually produce more feedback than pull ones).

A gateway from the patch manager to the patches list would
solve this nicely.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From Vladimir.Marangozov at inrialpes.fr  Fri Jun 23 12:00:23 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 23 Jun 2000 12:00:23 +0200 (CEST)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com> from "Skip Montanaro" at Jun 22, 2000 12:21:04 PM
Message-ID: <200006231000.MAA03550@python.inrialpes.fr>

Skip Montanaro wrote:
> 
> 
>     Guido> If I had designed this, I might have called the module "onexit"
>     Guido> or "atexit" and the public function simply "register()".  But
>     Guido> I've got only a +0 for my own proposal.  A +1 for the general
>     Guido> idea.
> 
> I'm happy to change things.  I was a bit curious if people would ask about
> such a common word for a new module name.  What module name do people
> prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not
> careful), or something else?
> 
> Skip

atexit.py

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From mal at lemburg.com  Fri Jun 23 12:08:46 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 23 Jun 2000 12:08:46 +0200
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
References: <200006231000.MAA03550@python.inrialpes.fr>
Message-ID: <3953372E.274907AB@lemburg.com>

Vladimir Marangozov wrote:
> 
> Skip Montanaro wrote:
> >
> >
> >     Guido> If I had designed this, I might have called the module "onexit"
> >     Guido> or "atexit" and the public function simply "register()".  But
> >     Guido> I've got only a +0 for my own proposal.  A +1 for the general
> >     Guido> idea.
> >
> > I'm happy to change things.  I was a bit curious if people would ask about
> > such a common word for a new module name.  What module name do people
> > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not
> > careful), or something else?
> >
> > Skip
> 
> atexit.py

How about exitfunc.py ? It would make the relation to sys.exitfunc
pretty clear.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From akuchlin at cnri.reston.va.us  Fri Jun 23 13:30:02 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Fri, 23 Jun 2000 07:30:02 -0400
Subject: [Python-Dev] Patch management 
In-Reply-To: <395319DD.F2584321@lemburg.com>; from mal@lemburg.com on Fri, Jun 23, 2000 at 10:03:41AM +0200
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com> <395319DD.F2584321@lemburg.com>
Message-ID: <20000623073002.B9385@newcnri.cnri.reston.va.us>

On Fri, Jun 23, 2000 at 10:03:41AM +0200, M.-A. Lemburg wrote:
>A gateway from the patch manager to the patches list would
>solve this nicely.

According to what was said to me, it's thought that mailing new
patches to an e-mail address is supported, and therefore setting up a

So, I no longer have much of a problem with moving patches to SF,
though I *still* think the mailing list would be sufficient with a bit
more focused effort; sorry, Tim!  But at least we're not going to burn
weeks looking at different patch manager products, and then arguing
about them, which is what I feared most.

--amk



From bwarsaw at python.org  Fri Jun 23 16:33:11 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Fri, 23 Jun 2000 10:33:11 -0400 (EDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
References: <14674.19200.325533.979792@beluga.mojam.com>
	<200006231000.MAA03550@python.inrialpes.fr>
Message-ID: <14675.29991.933911.446078@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:

    VM> atexit.py

+1



From gward at mems-exchange.org  Fri Jun 23 17:42:03 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Fri, 23 Jun 2000 11:42:03 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com>
Message-ID: <20000623114202.A1778@ludwig.cnri.reston.va.us>

On 20 June 2000, esr at thyrsus.com said:
> Watch that argument -- it could turn and bite you.  What's the justification
> for including, e.g. POP client classes in the standard distribution?
> 
> One of Python's most important strengths is the "batteries *are*
> included" richness of the standard environment.

I totally agree.  There are two extremes, both completely silly: include
nothing with Python (except string, re, os, and sys -- because Distutils
needs them ;-), and include every useful, working, documented module
under the sun.  I don't think anyone would seriously argue for either
approach.  (Although you could argue that a completely stripped-down
Python might be useful in certain environments, eg. a hand-held.  But I
don't think you'd win that argument.)

And I will be the first to admit that the Distutils still aren't good
enough: in most respects, they're better than MakeMaker (IMHO), but
there's nothing like CPAN.pm or the XEmacs package manager.  And I know
from personal experience that, amazing as CPAN.pm is, it's not The
Answer; and others have attested, that XEmacs is pretty damn good but
still not perfect.

But I still don't think PIL should be included in the core, if only
because it's one of the Distutils "test cases".  ;-)

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From gward at mems-exchange.org  Fri Jun 23 17:45:16 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Fri, 23 Jun 2000 11:45:16 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <39513E13.F8082811@prescod.net>; from paul@prescod.net on Wed, Jun 21, 2000 at 05:13:39PM -0500
References: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com> <39513E13.F8082811@prescod.net>
Message-ID: <20000623114516.B1778@ludwig.cnri.reston.va.us>

On 21 June 2000, Paul Prescod said:
> Is there an argument for putting in features with flaming red neon
> lights: "warning, experimental, use at your risk." We want to follow a
> bazaar (if not outright bizarre) development strategy after all. Putting
> a patch "out there" really doesn't do much about having people really
> play with and comment on a feature. I would never have experimented (and
> decided against using...) metaclasses if they hadn't popped up as an
> experimental feature.

Well, remember there will probably be a "--with-gc" option to the
configure script in 1.6.  That's a good example of getting an
experimental feature out there.

However, a "--with-list-comprehensions" option would be a really bad
idea; all of a sudden, it's no longer enough to say, "You need Python
1.6" to run this script/use this module, now you need to say, "You need
Python 1.6 built with list comprehensions".  Ugh.

Real language features should not be selectable: either the language is
Python 1.6 or it isn't.

       Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From akuchlin at cnri.reston.va.us  Fri Jun 23 17:54:02 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Fri, 23 Jun 2000 11:54:02 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <20000623114516.B1778@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Fri, Jun 23, 2000 at 11:45:16AM -0400
References: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com> <39513E13.F8082811@prescod.net> <20000623114516.B1778@ludwig.cnri.reston.va.us>
Message-ID: <20000623115402.B4805@amarok.cnri.reston.va.us>

On Fri, Jun 23, 2000 at 11:45:16AM -0400, Greg Ward wrote:
>idea; all of a sudden, it's no longer enough to say, "You need Python
>1.6" to run this script/use this module, now you need to say, "You need
>Python 1.6 built with list comprehensions".  Ugh.

The same argument applies to --with-gc, though, since people might
write code that creates cycles and needs GC to run without leaking
like a sieve.  Making GC optional is still the right solution, though,
because its performance effects are still unknown and might be costly.

--amk





From gvwilson at nevex.com  Fri Jun 23 18:09:36 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Fri, 23 Jun 2000 12:09:36 -0400 (EDT)
Subject: [Python-Dev] Re: list comprehensions / garbage collection / optional features
In-Reply-To: <20000623115402.B4805@amarok.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10006231159160.16185-100000@akbar.nevex.com>

> >Greg Ward wrote:

> >idea; all of a sudden, it's no longer enough to say, "You need Python
> >1.6" to run this script/use this module, now you need to say, "You need
> >Python 1.6 built with list comprehensions".  Ugh.

> Andrew Kuchling wrote:

> The same argument applies to --with-gc, though, since people might
> write code that creates cycles and needs GC to run without leaking
> like a sieve.  Making GC optional is still the right solution, though,
> because its performance effects are still unknown and might be costly.

Greg Wilson writes:

I'm really looking forward to recycling my rusty SETL idioms when list
comprehensions become part of the "official" release, and to creating
graphs in the obvious way if GC ever becomes standard.  However, the more
variations there are in the "standard" (as opposed to "developer")
release, the more expensive (in time and sweat) it is to manage Python at
large sites (like Los Alamos).  This in turn makes it harder to persuade
people that using Python will make their lives easier...

Thanks,

Greg

Footnote: The existence of JPython was one of the arguments in favor of
choosing Python for the Software Carpentry project. The fact that JPython
and CPython have very different memory management behaviors almost negated
that point: as one thirty-year veteran said, "It's no use having code that
runs in lots of places if it runs differently in each."




From nascheme at enme.ucalgary.ca  Fri Jun 23 19:12:51 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 23 Jun 2000 11:12:51 -0600
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects classobject.c,2.86,2.87 dictobject.c,2.52,2.53 funcobject.c,2.20,2.21 listobject.c,2.73,2.74 tupleobject.c,2.36,2.37
In-Reply-To: <200006231418.HAA02869@slayer.i.sourceforge.net>; from jhylton@users.sourceforge.net on Fri, Jun 23, 2000 at 07:18:13AM -0700
References: <200006231418.HAA02869@slayer.i.sourceforge.net>
Message-ID: <20000623111251.B10850@acs.ucalgary.ca>

On Fri, Jun 23, 2000 at 07:18:13AM -0700, Jeremy Hylton wrote:
> Round 1 of Neil Schemenauer's GC patches:

Yay.  :)

> + class_traverse(PyClassObject *o, visitproc visit, void *arg)
> + {
...
> + 	return 0;
> + }

> + instance_traverse(PyInstanceObject *o, visitproc visit, void *arg)
> + {
...
> + 	return 1;
> + }

Oops.  I think "return 0" is the proper thing to do.  There are a
few other functions that return 1 as well.

  Neil



From fdrake at acm.org  Fri Jun 23 20:08:06 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 23 Jun 2000 11:08:06 -0700 (PDT)
Subject: [Python-Dev] out of touch
Message-ID: <14675.42886.423185.310220@mailhost.beopen.com>

  My laptop has died, so I'm catching up with a couple of days of
mail.  I've not had time to look at Paul's proposed DOM-like additions
to the standard library.  Hopefully Andrew can (or has) summarized the
relevant portions of our discussion from yesterday; if I don't see it,
I'll try to get another message out later.  (But I don't have my saved
mail or files, so there's still not a lot I can do. ;( )


  -Fred


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




From fdrake at beopen.com  Fri Jun 23 21:04:55 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 23 Jun 2000 12:04:55 -0700 (PDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com>
References: <14673.1591.506532.170015@beluga.mojam.com>
	<200006212255.RAA02444@cj20424-a.reston1.va.home.com>
	<14674.19200.325533.979792@beluga.mojam.com>
Message-ID: <14675.46295.836727.117258@mailhost.beopen.com>

Skip Montanaro writes:
 > I'm happy to change things.  I was a bit curious if people would ask about
 > such a common word for a new module name.  What module name do people
 > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not

  I like "atexit" better.


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>




From guido at python.org  Fri Jun 23 22:08:36 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 23 Jun 2000 15:08:36 -0500
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: Your message of "Fri, 23 Jun 2000 12:04:55 MST."
             <14675.46295.836727.117258@mailhost.beopen.com> 
References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> <14674.19200.325533.979792@beluga.mojam.com>  
            <14675.46295.836727.117258@mailhost.beopen.com> 
Message-ID: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>

> Skip Montanaro writes:
>  > I'm happy to change things.  I was a bit curious if people would ask about
>  > such a common word for a new module name.  What module name do people
>  > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not

[fred]
>   I like "atexit" better.

OK, let it be atexit.  I'm glad this time the naming debate is at
least civilized. :-)

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



From DavidA at ActiveState.com  Fri Jun 23 21:30:31 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 23 Jun 2000 12:30:31 -0700
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJIEMMCJAA.DavidA@ActiveState.com>

> OK, let it be atexit.  I'm glad this time the naming debate is at
> least civilized. :-)

No, wait, i think it should be exit_AT!

Actually, I'm sick of this english-centricity.  You american jerks are all
the same!  Go home Yankee!  It should be en_sortant or nothing at all!

--david "I try..." ascher




From nascheme at enme.ucalgary.ca  Fri Jun 23 22:11:03 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 23 Jun 2000 14:11:03 -0600
Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed
Message-ID: <20000623141103.A13079@acs.ucalgary.ca>

Has this been addressed yet for 1.6?  It is probably an easy fix.
The original poster claimed it took 4 seconds to start Python on
his machine.

  Neil

----- Forwarded message from Johannes Stezenbach <yawyi at gmx.de> -----

Date: Thu, 22 Jun 2000 15:03:01 +0200
From: yawyi at gmx.de (Johannes Stezenbach)
Subject: Re: Linux/NT python startup speed

Niklas Frykholm <r2d2 at mao.acc.umu.se> wrote:
>Can someone explain this difference. (The processor on the Linux system is
>certainly not 40 times faster.)

This was discussed here a few months ago. The reason for the slow
startup is the winsound module (source: PC/winsound.c) which is
unnecessarily a builtin.  winsound causes Python to load the
Windows multimedia DLLs, which can be slow if your sound drivers
make it so.

Two solutions were discussed:
a) make winsound a .pyd
b) use some obscure "delayload" feature of the M$ linker. There
   is a ready to use python15.dll for Python 1.5.2 with this
   feature somewhere out there (I don't remember where, though,
   since I use Linux now)

IMHO solution a) should be standard in Python 1.6 (it isn't in
1.6a2).

Johannes



----- End forwarded message -----



From tim_one at email.msn.com  Fri Jun 23 22:11:47 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 23 Jun 2000 16:11:47 -0400
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJIEMMCJAA.DavidA@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEELLGFAA.tim_one@email.msn.com>

[Guido]
>> OK, let it be atexit.  I'm glad this time the naming debate is at
>> least civilized. :-)

{David Ascher]
> No, wait, i think it should be exit_AT!
>
> Actually, I'm sick of this english-centricity.  You american jerks are all
> the same!  Go home Yankee!  It should be en_sortant or nothing at all!

Oh, screw you and the frog you rode in, Frenchie.  Using an inferior
language is no excuse for poor grammar:  "exit at" reads like a freeway
sign, as in "Kentucky Fried Chicken, exit at 12B".  en_sortant is no
better -- worse, I have no idea what this has to do with arranging ants in
order (and what kind of algorithm is en_sort anyway?).
uponbutpriortoexiting is an idea that can't even be expressed in French, I
bet.

internationally y'rs  - tim





From guido at python.org  Fri Jun 23 23:49:05 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 23 Jun 2000 16:49:05 -0500
Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed
In-Reply-To: Your message of "Fri, 23 Jun 2000 14:11:03 CST."
             <20000623141103.A13079@acs.ucalgary.ca> 
References: <20000623141103.A13079@acs.ucalgary.ca> 
Message-ID: <200006232149.QAA03157@cj20424-a.reston1.va.home.com>

> Has this been addressed yet for 1.6?  It is probably an easy fix.
> The original poster claimed it took 4 seconds to start Python on
> his machine.

In 1.6, winsound is a separate subproject and hence a separately
loadable DLL, so it doesn't slow down the main code.  Ditto for
socket and a few others.

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




From jeremy at beopen.com  Sat Jun 24 00:01:19 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 23 Jun 2000 18:01:19 -0400
Subject: [Python-Dev] Python 1.6 planning
Message-ID: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>

We discussed plans for Python 1.6 at the all-hands PythonLabs staff meeting
yesterday.  (At this meeting, the PythonLabs staff closed ranks and agreed
to say that Tim Peters exists.)
I'd like to quickly summarize plans.

The target release date for Python 1.6 beta 1 is early July.  Any code that
is going to be in the beta must be checked in before July 1.

Tim Peters pushed us to take care of the patches backlog.  Our plan is to
close the patches list and move all patch management to Sourceforge.  We
know the list is broken; we don't know that Sourceforge is broken.

There are a bunch of modules and technical issues that must be resolved one
way or another.


SRE-- /F needs to finish this up.  Unanswered question is whether the beta
will ship with known bugs.

GC-- Neil's garbage collector will be shipped as experimental feature
requiring configure option.

XML-- Some parts of the XML package will be included in the library under
the xmlcore package.  SAX and DOM (provided that it is stable enough).
Andrew gets to decide, I believe.

List comprehensions -- Next release.  Despite the love fest at the meeting
(everyone seems to want them), there is no way an implementation will be
ready or stable enough.

httplib-- We will include Greg Stein's new httplib, provided that it
supports an old-style HTTPS class.

curses-- one return type needs to be implemented (5-tuple).  Andrew will
finish ASAP.  ESR's ascii module will be part of the curses package.

imputil-- The imputil module will be dropped in the std library to enable
wider distribution, but no changes will be made to the normal import
machinery.

Unicode shorthand-- Andrew will look at Bill Tutt's code. We intend to add
it.

Unicode compression-- We need to find out if Christian will be able to
provide a compressed database.

ldso_aix-- I still don't understand, but I didn't really try; Vladimir must
help

threads-- They will be on by default if the platform supports.

gettext-- Barry will check in his gettext module.

atexit.py-- add it

Jeremy





From nascheme at enme.ucalgary.ca  Sat Jun 24 00:22:50 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 23 Jun 2000 16:22:50 -0600
Subject: [Python-Dev] Python 1.6 planning
In-Reply-To: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400
References: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>
Message-ID: <20000623162250.A14311@acs.ucalgary.ca>

On Fri, Jun 23, 2000 at 06:01:19PM -0400, Jeremy Hylton wrote:
> threads-- They will be on by default if the platform supports.

Does the Linux thread/fork problem still exist?  It would be nice
to kill this before 1.6 final.  I will test this with the CVS
source this weekend.

  Neil



From skip at mojam.com  Sat Jun 24 03:09:04 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 23 Jun 2000 20:09:04 -0500
Subject: [Python-Dev] test failures...
Message-ID: <200006240109.UAA14738@beluga.mojam.com>

Using the latest CVS code, I get failures for three tests on my Linux
Mandrake 6.1 laptop:

  test test_exceptions failed -- Writing: 'spam', expected: 'Attr'
  test test_types crashed -- exceptions.OverflowError : long int too long to convert
  test test_long failed -- int(long(-sys.maxint-1)) overflowed!

Are these known/expected or unknown/unexpected failures?



From skip at mojam.com  Sat Jun 24 03:27:39 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 23 Jun 2000 20:27:39 -0500 (CDT)
Subject: [Python-Dev] atexit.py patch
Message-ID: <14676.3723.916135.602@beluga.mojam.com>

Here's the latest version of my exit module.  Per the earlier discussion,
the module has been renamed to atexit.py.  I also took the suggestion from
someone (Guido?) that the registration function be renamed to simply
"register".  Other than that everything else should be the same.

I'm only sending this to python-dev, operating under the assumption that the 
patches list is about to take a long vacation...

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: atexit.diff
Type: application/octet-stream
Size: 4402 bytes
Desc: atexit.py & doc
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000623/65cdf297/attachment.obj>

From trentm at activestate.com  Sat Jun 24 04:19:23 2000
From: trentm at activestate.com (Trent Mick)
Date: Fri, 23 Jun 2000 19:19:23 -0700
Subject: [Python-Dev] test failures...
In-Reply-To: <200006240109.UAA14738@beluga.mojam.com>
References: <200006240109.UAA14738@beluga.mojam.com>
Message-ID: <20000623191923.A25730@activestate.com>

On Fri, Jun 23, 2000 at 08:09:04PM -0500, Skip Montanaro wrote:
> Using the latest CVS code, I get failures for three tests on my Linux
> Mandrake 6.1 laptop:
> 
>   test test_exceptions failed -- Writing: 'spam', expected: 'Attr'

Don't know about this one.

>   test test_types crashed -- exceptions.OverflowError : long int too long to convert

This is related to some conversion checking that I added a while back, I
believe.


>   test test_long failed -- int(long(-sys.maxint-1)) overflowed!
> 
Same thing. Potentially this *should* overflow and the test should expect
that.


Don't take my word on this right now, only looked quickly. I will look at it
this weekend (hopefully). Skip, I don't get the test failures, although I am
a few days behind Python-CVS. Are these very new failures? Could you provide
the verbose output from running these tests indepedently? Thanks.


Trent


-- 
Trent Mick
trentm at activestate.com



From tim_one at email.msn.com  Sat Jun 24 04:32:46 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 23 Jun 2000 22:32:46 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <200006240109.UAA14738@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEMEGFAA.tim_one@email.msn.com>

[Skip Montanaro]
> Using the latest CVS code, I get failures for three tests on my Linux
> Mandrake 6.1 laptop:
>
>   test test_exceptions failed -- Writing: 'spam', expected: 'Attr'
>   test test_types crashed -- exceptions.OverflowError : long int
> too long to convert
>   test test_long failed -- int(long(-sys.maxint-1)) overflowed!
>
> Are these known/expected or unknown/unexpected failures?

First two don't ring a bell, last one has shown up several times & each time
traced to an optimization bug, usually in a particular older version of gcc.
Recompile with optimization off and see whether that makes all of them go
away.  If so, try using a recent gcc.





From tim_one at email.msn.com  Sat Jun 24 04:41:23 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 23 Jun 2000 22:41:23 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <20000623191923.A25730@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEMFGFAA.tim_one@email.msn.com>

>>   test test_types crashed -- exceptions.OverflowError : long
>> int too long to convert

> This is related to some conversion checking that I added a while back, I
> believe.

Possible but doubt it.

>>   test test_long failed -- int(long(-sys.maxint-1)) overflowed!

> Same thing. Potentially this *should* overflow and the test should expect
> that.

Definitely not on this one:  sys.maxint is by defn the largest positive
Python int, so on any 2's-comp machine -sys.maxint-1 should be a legit
Python int too.  This bogus failure has popped up due to compiler
optimization bugs under at least two older different compilers, though (gcc
being by far the more often reported culprit -- I think the other was one of
those HP compilers that seems to generate more bad code than good <0.3
wink>).

The first step in test failures like this is to recompile with optimization
off.





From skip at mojam.com  Sat Jun 24 05:45:04 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 23 Jun 2000 22:45:04 -0500 (CDT)
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEMEGFAA.tim_one@email.msn.com>
References: <200006240109.UAA14738@beluga.mojam.com>
	<LNBBLJKPBEHFEDALKOLCMEMEGFAA.tim_one@email.msn.com>
Message-ID: <14676.11968.263924.752216@beluga.mojam.com>

    >> test test_exceptions failed -- Writing: 'spam', expected: 'Attr'
    >> test test_types crashed -- exceptions.OverflowError : long int too long to convert
    >> test test_long failed -- int(long(-sys.maxint-1)) overflowed!

    Tim> First two don't ring a bell, last one has shown up several times &
    Tim> each time traced to an optimization bug, usually in a particular
    Tim> older version of gcc.  Recompile with optimization off and see
    Tim> whether that makes all of them go away.  If so, try using a recent
    Tim> gcc.

Turning off optimization got rid of the test_types and test_long failures.
The test_exceptins failure remains.  Here's a diff:

    diff test_exceptions.save test_exceptions
    2a3
    > spam
    3a5
    > spam
    4a7
    > spam
    5a9
    > spam
    6a11
    > spam
    7a13
    > spam
    8a15
    > spam
    10a18
    > spam
    12a21
    > spam
    13a23
    > spam
    14a25
    > spam
    16a28
    > spam
    17a30
    > spam
    19a33
    > spam
    20a35
    > spam
    21a37
    > spam
    22a39
    > spam
    23a41
    > spam

I'm not sure what that means, but it seems consistent. ;-)

As for the age of my gcc, I think I'm reasonably current (only a bit over a
year old):

    % gcc -v
    Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs
    gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)

I will try downloading a newer RPM.

Skip



From ping at lfw.org  Sat Jun 24 08:08:42 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Sat, 24 Jun 2000 01:08:42 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your
 perusal
In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>

On Fri, 23 Jun 2000, Guido van Rossum wrote:
> [fred]
> >   I like "atexit" better.
> 
> OK, let it be atexit.  I'm glad this time the naming debate is at
> least civilized. :-)

Sorry to confuddle things, but what happened to the idea of
sticking it in "sys"?  If sys.exitfunc lives there, doesn't
sys.atexit(...) also make sense?  It can't be very hard to do...


-- ?!ng




From guido at python.org  Sat Jun 24 18:03:07 2000
From: guido at python.org (Guido van Rossum)
Date: Sat, 24 Jun 2000 11:03:07 -0500
Subject: [Python-Dev] test failures...
In-Reply-To: Your message of "Fri, 23 Jun 2000 20:09:04 EST."
             <200006240109.UAA14738@beluga.mojam.com> 
References: <200006240109.UAA14738@beluga.mojam.com> 
Message-ID: <200006241603.LAA05123@cj20424-a.reston1.va.home.com>

>   test test_exceptions failed -- Writing: 'spam', expected: 'Attr'

There's a "print buf" at the end of the new function
test_raise_catch() that causes this.  Jeremy added this; either the
"print buf" shouldn't be there, or the file
Lib/test/output/test_exceptions should be updated.  It's up to Jeremy
now.

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




From skip at mojam.com  Sat Jun 24 17:11:18 2000
From: skip at mojam.com (Skip Montanaro)
Date: Sat, 24 Jun 2000 10:11:18 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your
 perusal
In-Reply-To: <Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
	<Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
Message-ID: <14676.53142.263320.435588@beluga.mojam.com>

    Ping> Sorry to confuddle things, but what happened to the idea of
    Ping> sticking it in "sys"?  If sys.exitfunc lives there, doesn't
    Ping> sys.atexit(...) also make sense?  It can't be very hard to do...

I like the general idea that stuff implemented in C is just a thin interface
layer on top of existing system services and that higher level protocols are
implemented in Python where there's no overriding need for them to be
written in C.  This fits that model, at least to a first approximation.  The
sys.exitfunc variable functions pretty much like calling the atexit(3)
library call (though that's not how sys.exitfunc is implemented), and the
atexit module provides a protocol that dictates how that mechanism is used
in a cooperative setting.

There's almost certainly no performance reason this code should be
implemented in C.  It's going to be easier to maintain and enhance if
written in Python, and won't add size to the interpreter for those
programmers who don't use it (or don't use other modules that do).

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From nascheme at enme.ucalgary.ca  Sat Jun 24 18:04:18 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Sat, 24 Jun 2000 10:04:18 -0600
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEMFGFAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Fri, Jun 23, 2000 at 10:41:23PM -0400
References: <20000623191923.A25730@activestate.com> <LNBBLJKPBEHFEDALKOLCMEMFGFAA.tim_one@email.msn.com>
Message-ID: <20000624100418.A20411@acs.ucalgary.ca>

On Fri, Jun 23, 2000 at 10:41:23PM -0400, Tim Peters wrote:
> The first step in test failures like this is to recompile with
> optimization off.

Mandrake is known for shipping bad compilers.  They used to ship
pgcc as the default compiler even though it was know to have a
lot of problems.

  Neil



From tim_one at email.msn.com  Sat Jun 24 19:27:19 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:27:19 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <14676.11968.263924.752216@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>

[Skip Montanaro]
> Turning off optimization got rid of the test_types and test_long failures.
> The test_exceptins failure remains.

Bingo, and Guido pinned test_exceptions on Jeremy.  You can likely get a
usable Python by disabling optimization only for longobject.c, if for some
reason you need to stick with that compiler.

> As for the age of my gcc, I think I'm reasonably current (only a
> bit over a year old):
>
>     % gcc -v
>     Reading specs from
> /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs
>     gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)

Well, I haven't had need of following the gcc/egcs soap opera, but I think
"a year" (& particularly the last one <wink>) is a lifetime in that saga.
"2.95" rings a vague bell, as the only compiler in that line my former
employer felt was usable for their development work under Linux.

unlike-python-so-far-they've-had-some-bad-releases-ly y'rs  - tim





From tim_one at email.msn.com  Sat Jun 24 19:30:54 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:30:54 -0400
Subject: [Python-Dev] atexit.py patch
In-Reply-To: <14676.3723.916135.602@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEMKGFAA.tim_one@email.msn.com>

[Skip]
> I'm only sending this to python-dev, operating under the
> assumption that the  patches list is about to take a long vacation...

Skip, if you can't put it on SourceForge for some reason (like what?), the
patches list is certainly better than python-dev!  I've got enough to do
trying to disentangle multi-megabytes of patches-list archives that I'm not
going to expand my search to other archives (like python-dev) too.





From gstein at lyra.org  Sat Jun 24 19:39:34 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 24 Jun 2000 10:39:34 -0700
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:27:19PM -0400
References: <14676.11968.263924.752216@beluga.mojam.com> <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>
Message-ID: <20000624103934.Y29590@lyra.org>

On Sat, Jun 24, 2000 at 01:27:19PM -0400, Tim Peters wrote:
> [Skip Montanaro]
> > Turning off optimization got rid of the test_types and test_long failures.
> > The test_exceptins failure remains.
> 
> Bingo, and Guido pinned test_exceptions on Jeremy.  You can likely get a
> usable Python by disabling optimization only for longobject.c, if for some
> reason you need to stick with that compiler.

Euh... shouldn't we insert some defensive code into longobject.c? Great,
Skip knows to disable opt for that file... what about all the other people?

Cheers,
-g

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



From tim_one at email.msn.com  Sat Jun 24 19:42:29 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:42:29 -0400
Subject: [Python-Dev] Patch management 
In-Reply-To: <20000623073002.B9385@newcnri.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMLGFAA.tim_one@email.msn.com>

[Andrew Kuchling]
> ...
> So, I no longer have much of a problem with moving patches to SF,
> though I *still* think the mailing list would be sufficient with a bit
> more focused effort; sorry, Tim!

"Do something" to supply that focus on this mailing list, and then I can
stop bothering with the move.  That would be great.  But repeating that if
the list worked, it wouldn't be broken <0.7 wink>, has not proven sufficient
to fix it.

> But at least we're not going to burn weeks looking at different patch
> manager products, and then arguing about them, which is what I feared
> most.

Same here.

well-actually-the-radio-on-the-drive-down-to-va-got-me-more-worried-
    about-lyme-disease-ly y'rs  - tim






From tim_one at email.msn.com  Sat Jun 24 19:51:14 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:51:14 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <20000624103934.Y29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMMGFAA.tim_one@email.msn.com>

[Greg Stein]
> Euh... shouldn't we insert some defensive code into longobject.c? Great,
> Skip knows to disable opt for that file... what about all the
> other people?

Don't understand what you want to see.  The compiler in question is both
broken & old.  At most I'd put a note in one of the readmes saying so.





From fdrake at beopen.com  Sat Jun 24 23:19:50 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Sat, 24 Jun 2000 14:19:50 -0700 (PDT)
Subject: [Python-Dev] updated exit.py and supporting files for your
 perusal
In-Reply-To: <Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
	<Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
Message-ID: <14677.9718.880695.265962@mailhost.beopen.com>

Ka-Ping Yee writes:
 > Sorry to confuddle things, but what happened to the idea of
 > sticking it in "sys"?  If sys.exitfunc lives there, doesn't
 > sys.atexit(...) also make sense?  It can't be very hard to do...

  I'd be happy with this as well, but I don't think it's required to
do it that way.


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>




From gstein at lyra.org  Sun Jun 25 00:18:24 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 24 Jun 2000 15:18:24 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37
In-Reply-To: <200006242040.NAA28315@slayer.i.sourceforge.net>; from gward@users.sourceforge.net on Sat, Jun 24, 2000 at 01:40:05PM -0700
References: <200006242040.NAA28315@slayer.i.sourceforge.net>
Message-ID: <20000624151824.A29590@lyra.org>

Would the "shlex" module be helpful here? It is in the standard library and
is (well?) maintained by ESR. It could help reduce the code inside
distutils.
[ I've always questioned the need for distutils' own "copy file" functions
  and whatnot... seems there is a bit of duplication occurring... ]

Cheers,
-g

On Sat, Jun 24, 2000 at 01:40:05PM -0700, Greg Ward wrote:
> Update of /cvsroot/python/distutils/distutils
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv28287
> 
> Modified Files:
> 	util.py 
> Log Message:
> Added 'split_quoted()' function to deal with strings that are quoted in 
> Unix shell-like syntax (eg. in Python's Makefile, for one thing -- now that
> I have this function, I'll probably allow quoted strings in config files too.
> 
> Index: util.py
> ===================================================================
> RCS file: /cvsroot/python/distutils/distutils/util.py,v
> retrieving revision 1.36
> retrieving revision 1.37
> diff -C2 -r1.36 -r1.37
> *** util.py	2000/06/18 15:45:55	1.36
> --- util.py	2000/06/24 20:40:02	1.37
> ***************
> *** 167,168 ****
> --- 167,235 ----
>   
>       return error
> + 
> + 
> + # Needed by 'split_quoted()'
> + _wordchars_re = re.compile(r'[^\\\'\"\ ]*')
> + _squote_re = re.compile(r"'(?:[^'\\]|\\.)*'")
> + _dquote_re = re.compile(r'"(?:[^"\\]|\\.)*"')
> + 
> + def split_quoted (s):
> +     """Split a string up according to Unix shell-like rules for quotes and
> +     backslashes.  In short: words are delimited by spaces, as long as those
> +     spaces are not escaped by a backslash, or inside a quoted string.
> +     Single and double quotes are equivalent, and the quote characters can
> +     be backslash-escaped.  The backslash is stripped from any two-character
> +     escape sequence, leaving only the escaped character.  The quote
> +     characters are stripped from any quoted string.  Returns a list of
> +     words.
> +     """
> + 
> +     # This is a nice algorithm for splitting up a single string, since it
> +     # doesn't require character-by-character examination.  It was a little
> +     # bit of a brain-bender to get it working right, though...
> + 
> +     s = string.strip(s)
> +     words = []
> +     pos = 0
> + 
> +     while s:
> +         m = _wordchars_re.match(s, pos)
> +         end = m.end()
> +         if end == len(s):
> +             words.append(s[:end])
> +             break
> + 
> +         if s[end] == ' ':               # unescaped, unquoted space: now
> +             words.append(s[:end])       # we definitely have a word delimiter
> +             s = string.lstrip(s[end:])
> +             pos = 0
> + 
> +         elif s[end] == '\\':            # preserve whatever is being escaped;
> +                                         # will become part of the current word
> +             s = s[:end] + s[end+1:]
> +             pos = end+1
> + 
> +         else:
> +             if s[end] == "'":           # slurp singly-quoted string
> +                 m = _squote_re.match(s, end)
> +             elif s[end] == '"':         # slurp doubly-quoted string
> +                 m = _dquote_re.match(s, end)
> +             else:
> +                 raise RuntimeError, \
> +                       "this can't happen (bad char '%c')" % s[end]
> + 
> +             if m is None:
> +                 raise ValueError, \
> +                       "bad string (mismatched %s quotes?)" % s[end]
> + 
> +             (beg, end) = m.span()
> +             s = s[:beg] + s[beg+1:end-1] + s[end:]
> +             pos = m.end() - 2
> + 
> +         if pos >= len(s):
> +             words.append(s)
> +             break
> + 
> +     return words
> + 
> + # split_quoted ()
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From gstein at lyra.org  Sun Jun 25 00:50:23 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 24 Jun 2000 15:50:23 -0700
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEMMGFAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:51:14PM -0400
References: <20000624103934.Y29590@lyra.org> <LNBBLJKPBEHFEDALKOLCAEMMGFAA.tim_one@email.msn.com>
Message-ID: <20000624155023.B29590@lyra.org>

On Sat, Jun 24, 2000 at 01:51:14PM -0400, Tim Peters wrote:
> [Greg Stein]
> > Euh... shouldn't we insert some defensive code into longobject.c? Great,
> > Skip knows to disable opt for that file... what about all the
> > other people?
> 
> Don't understand what you want to see.  The compiler in question is both
> broken & old.  At most I'd put a note in one of the readmes saying so.

The compiler Skip quoted was pgcc-2.91.66. The "pgcc" part may have
introduced the problem, but my RedHat 6.2 (i.e. the LATEST) has the
following:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)


Maybe 2.91.66 is "old" but that is the compiler being shipped on RedHat 6.2.

Having said that, I bet the pgcc people messed up the compiler :-). I set
-O9 on my box and recompiled longobject.c. It wouldn't reproduce the problem.

Cheers,
-g

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



From gmcm at hypernet.com  Sun Jun 25 01:01:05 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Sat, 24 Jun 2000 19:01:05 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>
References: <14676.11968.263924.752216@beluga.mojam.com>
Message-ID: <1250234786-20097552@hypernet.com>

Tim "The Windows Guy" Peters wrote:

> [Skip Montanaro]
> > /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs
> >     gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)
> 
> Well, I haven't had need of following the gcc/egcs soap opera,
> but I think "a year" (& particularly the last one <wink>) is a
> lifetime in that saga.

gcc 2.90 (egcs 1.0.3) that came with RH 5.2 was broken - but 
got fixed by rebuilding it from source.

- Gordon



From gstein at lyra.org  Sun Jun 25 10:40:23 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 25 Jun 2000 01:40:23 -0700
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache]
Message-ID: <20000625014023.D29590@lyra.org>

Woah... this is an interesting factoid about the number of committers for a
project. I had no idea PHP had this many...

Can this work with Python? Dunno. I think if a "true core" group pays
attention to the -checkins alias, then yah. If that review is ever lost,
then those "edge" committers could introduce crap.

I'm not asking for more committers to Python. But if some people were
worried about the "explosion" of committers from about six a couple months
ago to the current 13, then just look to PHP and count your thanks :-)
Mostly, this email is for pondering...

Cheers,
-g

----- Forwarded message from Rasmus Lerdorf <rasmus at apache.org> -----

Reply-To: members at apache.org
Date: Sat, 24 Jun 2000 20:52:01 -0700 (PDT)
From: Rasmus Lerdorf <rasmus at apache.org>
To: members at apache.org
Subject: Re: PMCs and Apache

> More relevant is the process by which I became a contributor.  For PHP, I
> sent a note describing what I was exploring, and I was sent a note with a
> password.  I didn't know CVS.  I didn't know PHP.  I didn't know open
> source.  But like a stranger offering to help at a barn raising, I was
> simply handed a hammer and expected to get busy.

That has always been the atmosphere.  It isn't quite as free as that.  We
get 10-20 cvs write account requests every week and tend to only hand out
1 or 2 actual accounts.  There are a lot of clueless people out there.  
However, if the person has shown any sign of being competent by explaining
in a rational manner what they plan on working on, I see no reason not to
let them bash away.  Reversing somebodys' changes and removing a cvs
account is trivial, and in the past 5 years we have yet to revoke an
account.  We have reversed changes of course, but even that doesn't happen
too often.

There are currently 165 people with write access to the PHP source tree.

This does also relate to the fact that the PHP project is a very broad
project.  No single person could possibly know all 16 supported low-level
database apis, for example.  

For other projects with a much more limited scope, this approach is
probably not optimal, but for PHP it works nicely.  Someone will write a
bit of broken code that shows some good ideas, and others will pounce on
it and fix it.  Often the people who fix it are poor sods who tried to use
the broken feature and had to dive in and fix it themselves.  They request
a cvs account to do this, and they are hooked.  They tend to never stop at
fixing just one thing once they have been given the golden keys.

This approach has also done wonders for the PHP documentation.  The
current manual is around 1100 pages long and has been fully translated to
German, Italian and Japanese with more languages on the way.  (check out
http://snaps.php.net/manual/)

-Rasmus

----- End forwarded message -----

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



From gstein at lyra.org  Mon Jun 26 01:20:43 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 25 Jun 2000 16:20:43 -0700
Subject: [Python-Dev] Python/Apache stuff (was: Re: [XML-SIG] speed question re DOM parsing)
In-Reply-To: <200006251540.JAA13556@localhost.localdomain>; from uogbuji@fourthought.com on Sun, Jun 25, 2000 at 09:40:59AM -0600
References: <gstein@lyra.org> <200006251540.JAA13556@localhost.localdomain>
Message-ID: <20000625162043.J29590@lyra.org>

On Sun, Jun 25, 2000 at 09:40:59AM -0600, Uche Ogbuji wrote:
> Greg Stein:
> > When could I get to it? eek. I *will*, but dunno when. It is amazing just
> > how much stuff can fall on a person's plate despite having no job :-). I've
> > got some layered I/O in Apache, mod_dav integration, a new httplib, imputil
> > issues, these qp_xml upgrades, ViewCVS stuff, edna releases, free threading
> > changes, Python/Apache integration, and coding for Subversion. Fuggin
> > frightening.
> 
> Ooh!  Ooh!  Can you tell us more about the Python/Apache integration item?  
> We've been discussing distributing a 4Suite kit bundled with PyApache, but 
> that package is quite complex and I'm not sure how strongly maintained.  Are 
> you talking about improvements to PyApache?  Another approach entirely 
> (PyApache still has much more overhead than, say mod_perl)?  Do you have an 
> approximate time-line?  A project URL?

There are several Python/Apache efforts (where Python is embedded into the
Apache process):

*) PyApache: essentially this is just a CGI accelerator. Take a standard CGI
   script and it will "run faster."
   (URL? dunno)

*) mod_python: similar to mod_perl. Built for Apache 1.3. Despite its
   version 2.4, it is still a bit rough. I've been working with the author
   to improve the code. I did a code review a while back with a lot of
   suggestions. It is reasonable, but not as mature as mod_perl.
   http://www.modpython.org/

*) mod_snake: obvious misnomer :-). This is a module built for Apache 2.0,
   with the intent of making use of Apache 2.0's threadedness (plus a few of
   A2's other internal features). The code is very good looking.
   - available at SourceForge

*) mod_slimpy: my name for an Apache 2.0 module which will be even lighter
   weight than mod_snake. There will be only the slimmest layer of C code to
   interface Apache and Python. Most/all operational logic will be deferred
   to the Python side. I've used this design to good effect in some of the
   Python/COM work and its univgw package in particular.

Obviously, the latter two will compete, but oh well :-). The first two fit
their problem environment without particular complications.

When I start the mod_slimpy work, I'm also going to push on setting up
python.apache.org. Essentially, it will host (under the ASF umbrella) the
mod_slimpy work plus any other efforts that may want to operate there. I'm
going to ask the authors of the other packages whether they would like to be
hosted there, too.

Of course, python.apache.org can host any Python project. It doesn't have to
be related to the web server, or any other ASF project for that matter.
Consider all the non-web stuff that operates under xml.apache.org,
java.apache.org, and jakarta.apache.org.

Cheers,
-g

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



From Vladimir.Marangozov at inrialpes.fr  Mon Jun 26 13:33:56 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Mon, 26 Jun 2000 13:33:56 +0200 (CEST)
Subject: [Python-Dev] Fw: Access violation when no memory
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au> from "Mark Hammond" at Jun 20, 2000 09:42:53 PM
Message-ID: <200006261133.NAA03073@python.inrialpes.fr>

Mark Hammond wrote:
> 
> >From the newsgroup.  Any thoughts?
> 
> Mark.
> 
> "Phil Mayes" <nospam at bitbucket.com> wrote in message
> news:<olD35.82$_%.4481 at newsfeed.avtel.net>...
> > The following program progressively allocates all memory:
> >     size = 1 << 20
> >     list = [None,]
> >     while size:
> >         try:
> >             mem = [None] * size
> >             mem[0] = list
> >             list = mem
> >         except:
> >             size = size / 2
> >
> > It fails with an access violation.  (Turn off virtual memory
> > to provoke it.)

I had a closer look at this report. It revealed a buglet in Instance_New
and raises a question on how to handle the possible NULL values pushed
on the stack in ceval.c, at the exception handling code block:

> > 3. the NULL pointer at tb is pushed here:
> >      ceval.c line 1816:    PUSH(tb);
> >      ceval.c line 1817:    PUSH(val);
> >      ceval.c line 1818:    PUSH(exc);

1. In PyInstance_New, when the inst->in_dict allocation fails, there's
   a DECREF(inst) which triggers the instance_dealloc function. The latter
   goes on checking whether __del__ is defined in the instance's dict
   (by calling getattr2) whithout checking first whether inst->in_dict
   is not NULL. I.e. the dealloc_function assumes the instance has been
   initialized successfully. The net effect is a segfault in PyDict_GetItem
   which is called with a NULL dict.

   There are two possible fixes, and I'm not sure which one is better:

   a) Fix the Instance_New code, by freeing the instance on inst->in_dict
      allocation failure (without decref'ing the instance).

   b) Fix the dealloc code, by checking whether in_dict is not NULL
      before proceeding with the __del__ finalization logic.

   Opinions?

2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on
   low-memory conditions. They are pushed on the stack, then popped with
   a segfault.  The only reasonable behavior I get, after some testing,
   is by setting the tb and exc to Py_None if any of them is NULL before
   pushing them onto the stack. The program succeeds or the process is
   killed by the OS (tested on Linux).

   However, I'm not sure that setting tb and/or exc to Py_None, if NULL,
   makes any sense and won't cause side effects.

   Any other suggestions?

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From guido at python.org  Mon Jun 26 16:49:11 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 09:49:11 -0500
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Fri, 23 Jun 2000 10:03:41 +0200."
             <395319DD.F2584321@lemburg.com> 
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>  
            <395319DD.F2584321@lemburg.com> 
Message-ID: <200006261449.JAA01684@cj20424-a.reston1.va.home.com>

It's official: I've changed the patch submission guidelines
(http://www.python.org/patches/) to point to the patch manager at
SourceForge.  We are no longer bound by CNRI's legal department, so
the requirement for disclaimers or wet signatures is gone.

We'll have to see how it works in practice.  I've set the address
where new patches are mailed to patches at python.org; this should send
notifications to the patches list.  We could change this to python-dev
perhaps, so we can retire the patches address completely (giving it an
auto-respond pointing to the SF patch manager, as barry suggested).

There are several tasks to be assigned now: we need a triage person
who should go through the list of new patches regularly to assign them
to developers; we need developers who are willing to have patches
assigned to them.

We also need a consensus process to decide which patches will be
allowed through.  I'm hoping to experiment with SF in the coming days
to come up with something.

Finally, we still need to do something about the existing backlog of
patches.  The PythonLabs team will try to do something reasonable
here.

This is not the end -- it's the beginning!

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



From jack at oratrix.nl  Mon Jun 26 16:29:05 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Mon, 26 Jun 2000 16:29:05 +0200
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] 
In-Reply-To: Message by Greg Stein <gstein@lyra.org> ,
	     Sun, 25 Jun 2000 01:40:23 -0700 , <20000625014023.D29590@lyra.org> 
Message-ID: <20000626142906.1DDBD37186E@snelboot.oratrix.nl>

> Woah... this is an interesting factoid about the number of committers for a
> project. I had no idea PHP had this many...
> 
> Can this work with Python? Dunno. I think if a "true core" group pays
> attention to the -checkins alias, then yah. If that review is ever lost,
> then those "edge" committers could introduce crap.

This is one of the reasons I never asked for committer status: the fewer 
people doing commits the better. I can live with the <2days delay we had upto 
recently, and for now I'm expecting it to go down to that again after all the 
turmoil is over.
--
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 guido at python.org  Mon Jun 26 17:43:38 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 10:43:38 -0500
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache]
In-Reply-To: Your message of "Mon, 26 Jun 2000 16:29:05 +0200."
             <20000626142906.1DDBD37186E@snelboot.oratrix.nl> 
References: <20000626142906.1DDBD37186E@snelboot.oratrix.nl> 
Message-ID: <200006261543.KAA02198@cj20424-a.reston1.va.home.com>

[Jack Jansen]
> This is one of the reasons I never asked for committer status: the
> fewer people doing commits the better. I can live with the <2days
> delay we had upto recently, and for now I'm expecting it to go down
> to that again after all the turmoil is over.

Actually, I'd be glad to give you committer status (your colleague
Sjoerd just got his :-).  I expect that the majority of the
subscribers to python-dev can be trusted as committers.

I fully expect that most committers won't be committing much -- I
don't expect a frenzy of work by committers on the source tree.
However the committer status offloads the responsibility of applying
the patches you submit after they have been approved -- you can now do
it yourself.  Less work for me and the others here at PythonLabs!

BTW, I would heartily recommend putting the Macintosh tree for Python
under SourceForge!

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



From mal at lemburg.com  Mon Jun 26 17:03:30 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 26 Jun 2000 17:03:30 +0200
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>  
	            <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
Message-ID: <395770C2.B903724A@lemburg.com>

Guido van Rossum wrote:
> 
> It's official: I've changed the patch submission guidelines
> (http://www.python.org/patches/) to point to the patch manager at
> SourceForge.  We are no longer bound by CNRI's legal department, so
> the requirement for disclaimers or wet signatures is gone.
> 
> We'll have to see how it works in practice.  I've set the address
> where new patches are mailed to patches at python.org; this should send
> notifications to the patches list.  We could change this to python-dev
> perhaps, so we can retire the patches address completely (giving it an
> auto-respond pointing to the SF patch manager, as barry suggested).

Will there be a list which gets the patches mailed to it
by SF ?

I'm just asking because the current setup of having the patches
available through mail really helps in discussing patch details.
 
> There are several tasks to be assigned now: we need a triage person
> who should go through the list of new patches regularly to assign them
> to developers; we need developers who are willing to have patches
> assigned to them.

I'll volunteer for the Unicode side of things :-)

> We also need a consensus process to decide which patches will be
> allowed through.  I'm hoping to experiment with SF in the coming days
> to come up with something.
> 
> Finally, we still need to do something about the existing backlog of
> patches.  The PythonLabs team will try to do something reasonable
> here.
> 
> This is not the end -- it's the beginning!

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jack at oratrix.nl  Mon Jun 26 17:13:54 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Mon, 26 Jun 2000 17:13:54 +0200
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] 
In-Reply-To: Message by Guido van Rossum <guido@python.org> ,
	     Mon, 26 Jun 2000 10:43:38 -0500 , <200006261543.KAA02198@cj20424-a.reston1.va.home.com> 
Message-ID: <20000626151355.3EF8C37186E@snelboot.oratrix.nl>

> Actually, I'd be glad to give you committer status (your colleague
> Sjoerd just got his :-).  I expect that the majority of the
> subscribers to python-dev can be trusted as committers.

Oww, grumble grumble... Okay, I'll apply for committer status. So there.

> BTW, I would heartily recommend putting the Macintosh tree for Python
> under SourceForge!

I don't think MacCVS can do ssh authorization, and if I followed the 
discussion here that is needed, right? But if that hurdle can be taken: fine!
--
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 guido at python.org  Mon Jun 26 18:32:37 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 11:32:37 -0500
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Mon, 26 Jun 2000 17:03:30 +0200."
             <395770C2.B903724A@lemburg.com> 
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com> <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com>  
            <395770C2.B903724A@lemburg.com> 
Message-ID: <200006261632.LAA02506@cj20424-a.reston1.va.home.com>

[MAL]
> Will there be a list which gets the patches mailed to it
> by SF ?
> 
> I'm just asking because the current setup of having the patches
> available through mail really helps in discussing patch details.

I don't think this feature is part of the SF Patch Manager just yet.
You could submit it as a request to the SF PM developers though --
apparently they're still working on it.

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



From paul at prescod.net  Mon Jun 26 17:43:31 2000
From: paul at prescod.net (Paul Prescod)
Date: Mon, 26 Jun 2000 08:43:31 -0700
Subject: [Python-Dev] winreg
Message-ID: <39577A23.EF7DE922@prescod.net>

[I'm having mail troubles so my response time may be slow...]

I've just had a chance to look at the winreg module. I think that it is
too low-level. I wrote a wrapper class that I feel is more Pythonic.
I'll outline the basic ideas and then if there is interest I'll develop
a test suite and send it out for eyeballing by Mark and others. Yes, I
am proposing this for 1.6. If we're going to put in a registry module,
it should be as Pythonic as possible.

First, about Winreg 1:

It was perfect when it was part of the win32 package and was supposed to
mirror the win32 APIs exactly (for reasons of documentation and
familiarity) but as the "standard" Python registry manipulation module
it seems too low-level to me.

I'm sure Mark would be the first to admit that it isn't very Pythonic.
It's more Microsoft-ic. In one part of the docs he says: "this API is
lame, lame, lame. Don't use it." :) 

There are also bogus parameters that Microsoft hasn't got around to
assigning values to, undocumented constants and so forth. My favorite is
"WHOLE_HIVE_VOLATILE".

Winreg 2:

The basic idea in the pythonic wrapper is that there are key "objects"
rather than just handles. winreg already has a primtive "handle object"
but for some reason most of the stuff that would logically be methods
are actually functions that take the handle as the first param.

Keys can have subkeys. So in winreg 1 you would say:

winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE,
"HARDWARE"), "DESCRIPTION" )

now you say:

winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey(
"DESCRIPTION" )

(you could also use a path syntax in either case)

You can get a complete list of existant subkeys with a getSubkeys()
method call. This list behaves like a Python mapping and also like a
sequence. You can use either string key names or integer ordinal
indexes. You can fetch and delete keys based on those indexes:

for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys():
	dosomething( key )

Before it was something like this:

for index in xrange( 0, sys.maxint ):
	try:
		dosomething( winreg.EnumKey( index ) )
	except WindowsError:
		break

"Values" (in the Microsoft sense) are handled the same basic way.
Looping, deleting, etc. is the same.

When you fetch a value, you get a (type,value) tuple. Types are objects
with properties:

typeobj.intval -> 0..10
typeobj.msname -> REG_SZ, REG_SZ_MULTI, ...
typeobj.friendlyname -> "String", "Sting List", ...

Type coercions are all done by the underlying module (the old winreg)
except that I've decided that binary data should be returned as an
array.array('c') rather than an 8-bit string.

-- 
 Paul Prescod
Out of timber so crooked as that which man is made nothing entirely
straight can be built. - Immanuel Kant



From fdrake at beopen.com  Mon Jun 26 18:04:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT)
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395770C2.B903724A@lemburg.com>
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>
	<395319DD.F2584321@lemburg.com>
	<200006261449.JAA01684@cj20424-a.reston1.va.home.com>
	<395770C2.B903724A@lemburg.com>
Message-ID: <14679.32536.133849.573542@mailhost.beopen.com>

M.-A. Lemburg writes:
 > Will there be a list which gets the patches mailed to it
 > by SF ?

  patches at python.org should get messages of patch manager activity (at
least certain actions; not sure which ones yet, but at least
additions).

 > I'm just asking because the current setup of having the patches
 > available through mail really helps in discussing patch details.

  Yes!  I'd really hate to lose notifications!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Mon Jun 26 18:04:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT)
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395770C2.B903724A@lemburg.com>
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>
	<395319DD.F2584321@lemburg.com>
	<200006261449.JAA01684@cj20424-a.reston1.va.home.com>
	<395770C2.B903724A@lemburg.com>
Message-ID: <14679.32536.133849.573542@mailhost.beopen.com>

M.-A. Lemburg writes:
 > Will there be a list which gets the patches mailed to it
 > by SF ?

  patches at python.org should get messages of patch manager activity (at
least certain actions; not sure which ones yet, but at least
additions).

 > I'm just asking because the current setup of having the patches
 > available through mail really helps in discussing patch details.

  Yes!  I'd really hate to lose notifications!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From paul at prescod.net  Mon Jun 26 17:43:31 2000
From: paul at prescod.net (Paul Prescod)
Date: Mon, 26 Jun 2000 08:43:31 -0700
Subject: [Python-Dev] winreg
Message-ID: <39577A23.EF7DE922@prescod.net>

[I'm having mail troubles so my response time may be slow...]

I've just had a chance to look at the winreg module. I think that it is
too low-level. I wrote a wrapper class that I feel is more Pythonic.
I'll outline the basic ideas and then if there is interest I'll develop
a test suite and send it out for eyeballing by Mark and others. Yes, I
am proposing this for 1.6. If we're going to put in a registry module,
it should be as Pythonic as possible.

First, about Winreg 1:

It was perfect when it was part of the win32 package and was supposed to
mirror the win32 APIs exactly (for reasons of documentation and
familiarity) but as the "standard" Python registry manipulation module
it seems too low-level to me.

I'm sure Mark would be the first to admit that it isn't very Pythonic.
It's more Microsoft-ic. In one part of the docs he says: "this API is
lame, lame, lame. Don't use it." :) 

There are also bogus parameters that Microsoft hasn't got around to
assigning values to, undocumented constants and so forth. My favorite is
"WHOLE_HIVE_VOLATILE".

Winreg 2:

The basic idea in the pythonic wrapper is that there are key "objects"
rather than just handles. winreg already has a primtive "handle object"
but for some reason most of the stuff that would logically be methods
are actually functions that take the handle as the first param.

Keys can have subkeys. So in winreg 1 you would say:

winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE,
"HARDWARE"), "DESCRIPTION" )

now you say:

winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey(
"DESCRIPTION" )

(you could also use a path syntax in either case)

You can get a complete list of existant subkeys with a getSubkeys()
method call. This list behaves like a Python mapping and also like a
sequence. You can use either string key names or integer ordinal
indexes. You can fetch and delete keys based on those indexes:

for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys():
	dosomething( key )

Before it was something like this:

for index in xrange( 0, sys.maxint ):
	try:
		dosomething( winreg.EnumKey( index ) )
	except WindowsError:
		break

"Values" (in the Microsoft sense) are handled the same basic way.
Looping, deleting, etc. is the same.

When you fetch a value, you get a (type,value) tuple. Types are objects
with properties:

typeobj.intval -> 0..10
typeobj.msname -> REG_SZ, REG_SZ_MULTI, ...
typeobj.friendlyname -> "String", "Sting List", ...

Type coercions are all done by the underlying module (the old winreg)
except that I've decided that binary data should be returned as an
array.array('c') rather than an 8-bit string.

-- 
 Paul Prescod
Out of timber so crooked as that which man is made nothing entirely
straight can be built. - Immanuel Kant



From fdrake at beopen.com  Mon Jun 26 17:46:23 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 08:46:23 -0700 (PDT)
Subject: [Python-Dev] Fw: Access violation when no memory
In-Reply-To: <200006261133.NAA03073@python.inrialpes.fr>
References: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au>
	<200006261133.NAA03073@python.inrialpes.fr>
Message-ID: <14679.31439.11309.105239@mailhost.beopen.com>

Vladimir Marangozov writes:
 >    There are two possible fixes, and I'm not sure which one is better:
 > 
 >    a) Fix the Instance_New code, by freeing the instance on inst->in_dict
 >       allocation failure (without decref'ing the instance).

  I think this is the right one; this *shold* be all that's ever
needed, and isolates the check to the cod ethat can experiance
failure.

 >    b) Fix the dealloc code, by checking whether in_dict is not NULL
 >       before proceeding with the __del__ finalization logic.

  This protects against bad C code elsewhere that makes a mess of
existing objects by stepping around the API (such as by setting
inst->in_dict to NULL).  I'm not sure we want to protect against that
since it could mask bugs (I doubt anyone would do that deliberatly, so
I feel safe calling it a bug!).

 >    Opinions?

  And for free!  So infer what you will about their worth.  :)

 > 2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on
 >    low-memory conditions. They are pushed on the stack, then popped with
 >    a segfault.  The only reasonable behavior I get, after some testing,
 >    is by setting the tb and exc to Py_None if any of them is NULL before
 >    pushing them onto the stack. The program succeeds or the process is
 >    killed by the OS (tested on Linux).
 > 
 >    However, I'm not sure that setting tb and/or exc to Py_None, if NULL,
 >    makes any sense and won't cause side effects.

  This doesn't seem like a situation where you'd be masking some other
kind of bug by using Py_None, and it avoids the core dump.  Since
you're not masking anything, I'd go ahead and use Py_None here.


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From esr at thyrsus.com  Mon Jun 26 20:01:25 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 26 Jun 2000 14:01:25 -0400
Subject: [Python-Dev] Now that the man is back...
Message-ID: <20000626140125.A3266@thyrsus.com>

Guido, can we get these into 1.6?  They're needed for the the ncurses 
extensions I'm working on.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"This country, with its institutions, belongs to the people who
inhabit it. Whenever they shall grow weary of the existing government,
they can exercise their constitutional right of amending it or their
revolutionary right to dismember it or overthrow it."
	-- Abraham Lincoln, 4 April 1861
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libascii.tex
Type: application/x-tex
Size: 4408 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000626/903a84b4/attachment.bin>
-------------- next part --------------
#
# ascii.py -- constants and memembership tests for ASCII characters
#

NUL	= 0x00	# ^@
SOH	= 0x01	# ^A
STX	= 0x02	# ^B
ETX	= 0x03	# ^C
EOT	= 0x04	# ^D
ENQ	= 0x05	# ^E
ACK	= 0x06	# ^F
BEL	= 0x07	# ^G
BS	= 0x08	# ^H
TAB	= 0x09	# ^I
HT	= 0x09	# ^I
LF	= 0x0a	# ^J
NL	= 0x0a	# ^J
VT	= 0x0b	# ^K
FF	= 0x0c	# ^L
CR	= 0x0d	# ^M
SO	= 0x0e	# ^N
SI	= 0x0f	# ^O
DLE	= 0x10	# ^P
DC1	= 0x11	# ^Q
DC2	= 0x12	# ^R
DC3	= 0x13	# ^S
DC4	= 0x14	# ^T
NAK	= 0x15	# ^U
SYN	= 0x16	# ^V
ETB	= 0x17	# ^W
CAN	= 0x18	# ^X
EM	= 0x19	# ^Y
SUB	= 0x1a	# ^Z
ESC	= 0x1b	# ^[
FS	= 0x1c	# ^\
GS	= 0x1d	# ^]
RS	= 0x1e	# ^^
US	= 0x1f	# ^_
SP	= 0x20	# space
DEL	= 0x7f	# delete

controlnames = [
"NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL",
"BS",  "HT",  "LF",  "VT",  "FF",  "CR",  "SO",  "SI",
"DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB",
"CAN", "EM",  "SUB", "ESC", "FS",  "GS",  "RS",  "US",
"SP"
]

def _ctoi(c):
    if type(c) == type(""):
        return ord(c)
    else:
        return c

def isalnum(c): return isalpha(c) or isdigit(c)
def isalpha(c): return isupper(c) or islower(c)
def isascii(c): return _ctoi(c) <= 127		# ?
def isblank(c): return _ctoi(c) in (8,32)
def iscntrl(c): return _ctoi(c) <= 31
def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57
def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126
def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122
def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126
def ispunct(c): return _ctoi(c) != 32 and not isalnum(c)
def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11)
def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90
def isxdigit(c): return isdigit(c) or \
    (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102)
def isctrl(c): return _ctoi(c) < 32
def ismeta(c): return _ctoi(c) > 127

def ascii(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x7f)
    else:
        return _ctoi(c) & 0x7f

def ctrl(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x1f)
    else:
        return _ctoi(c) & 0x1f

def alt(c):
    if type(c) == type(""):
        return chr(_ctoi(c) | 0x80)
    else:
        return _ctoi(c) | 0x80

def unctrl(c):
    bits = _ctoi(c)
    if bits == 0x7f:
        rep = "^?"
    elif bits & 0x20:
        rep = chr((bits & 0x7f) | 0x20)
    else:
        rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20)
    if bits & 0x80:
        return "!" + rep
    return rep


From tim_one at email.msn.com  Mon Jun 26 20:41:12 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 26 Jun 2000 14:41:12 -0400
Subject: [Python-Dev] RE: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>

[Guido]
> It's official: I've changed the patch submission guidelines
> (http://www.python.org/patches/) to point to the patch manager at
> SourceForge.  We are no longer bound by CNRI's legal department, so
> the requirement for disclaimers or wet signatures is gone.

Yay!  Wonder how long that will last <wink>.

Attached is a first cut at documenting the intended use of SourceForge's
patch status tags, and the workflow associated with patch status changes.
The areas in need of fleshing out are marked with "[xxx ...]".  Gripe at
will.

I don't think anyone expects this to work smoothly at first.  Strive for
patience, and let's work to make SF a really *good* place for patches!

never-thought-i'd-actually-miss-lotus-notes-ly y'rs  - tim

PS:  I'll move this (& related info) to a reasonable place eventually, so
don't bother griping about email for now.


Intended use of SourceForge patch status tags
---------------------------------------------
revision 1                        26-Jun-2000


Open
    The initial status of all patches.
    The patch is under consideration, but has not
    been reviewed yet.
    The status will normally change to Accepted or Rejected next.
    The person submitting the patch should (if they can) assign
    it to the person they most want to review it.
    Else the patch will be assigned via
        [xxx a list of expertise areas should be developed]
    Discussion of patches is carried out via
        [xxx Python-Dev?  patches list?  without a mail gateway,
             the SourceForge patch interface looks too clumsy
             to use for controversial patches]
Accepted
    The powers that be have accepted the patch, but it has not
        been applied yet.
        [xxx flesh out -- Guido Bottleneck avoidable here?]
    The status will normally change to Closed next.
    The person changing the status to Accepted should, at the
    same time, assign the patch to whoever they believe is most
    likely to be able & willing to apply it (the submitter if
    possible).
Closed
    The patch has been accepted and applied.
    The previous status was Accepted, or possibly Open if the
    submitter was Guido (or moral equivalent in some particular
    area of expertise).
    If possible, the submitter should apply the patch and change
    the status to Closed.
    Else anyone with sufficient power should feel encouraged to
    do these on the submitter's behalf.
Rejected
    The patch has been reviewed and rejected.
    When the objections are addressed, the status may change to
    Open again.
    Note that SourceForge allows the submitter to overwrite the patch
    with a new version.
Out of date
    Previous status was Open or Accepted or Postponed, but the
    patch no longer works.
    Please enter a comment when changing the status to "Out of date",
    to record the nature of the problem and the previous status.
Postponed
    The previous status was Open or Accepted, but for some reason
    (e.g., pending release) the patch should not be reviewed or
    applied until further notice.
    The status will normally change to Open or Accepted next.
    Please enter a comment when changing the status to Postponed,
    to record the reason, the previous status, and the conditions
    under which the patch should revert to Open or Accepted.
Deleted
    Bit bucket.
    Use only if it's OK for the patch and its SourceForge history
    to disappear.
    As of 26-June-2000, SF does not actually throw away Deleted
    patches, but that may change.





From DavidA at ActiveState.com  Mon Jun 26 21:10:04 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 26 Jun 2000 12:10:04 -0700
Subject: [Python-Dev] semaphore support in thread_*.h
Message-ID: <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com>

I noticed that the support for the semaphore calls in the various thread_*
is very very spotty, with a comment in the BeOS implementation that read:

 * Guido says not to implement this because it's not used anywhere;
 * I'll do it anyway, you never know when it might be handy, and it's
 * easy...

(that last bit is not true of all implementations, apparently =).

1) Is it true that the sema_ calls are never used?

2) If yes, shouldn't we remove the sema_ calls from the thread API and have
similar functionality on all platforms?

(There are related issues re: for example whether async thread locking is
available, whether threads are joinable or not (see thread_cthread.h), etc.)

--david




From tim_one at email.msn.com  Mon Jun 26 21:19:58 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 26 Jun 2000 15:19:58 -0400
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395770C2.B903724A@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEPFGFAA.tim_one@email.msn.com>

[MAL]
> Will there be a list which gets the patches mailed to it
> by SF ?
>
> I'm just asking because the current setup of having the patches
> available through mail really helps in discussing patch details.

I agree -- SF isn't (yet) good for patch discussions.  Plugging away, but
haven't yet figured out exactly when or how SF decides to send email.  In
particular, don't yet know how (or whether it's possible) to trick current
SF into populating a mailing list.





From guido at python.org  Mon Jun 26 22:24:57 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 15:24:57 -0500
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: Your message of "Mon, 26 Jun 2000 14:01:25 -0400."
             <20000626140125.A3266@thyrsus.com> 
References: <20000626140125.A3266@thyrsus.com> 
Message-ID: <200006262024.PAA01212@cj20424-a.reston1.va.home.com>

[ESR]
> Guido, can we get these into 1.6?  They're needed for the the ncurses 
> extensions I'm working on.

Eric,

We (PythonLabs + Andrew Kuchling & Greg Ward) discussed this at our
recent 1.6 planning meeting.  This doesn't have much use outside
curses.  Therefore, Andrew will check it in as a submodule of the new
curses package.

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



From fdrake at beopen.com  Mon Jun 26 21:24:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 12:24:40 -0700 (PDT)
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <20000626140125.A3266@thyrsus.com>
References: <20000626140125.A3266@thyrsus.com>
Message-ID: <14679.44536.931222.448738@mailhost.beopen.com>

Eric S. Raymond writes:
 > Guido, can we get these into 1.6?  They're needed for the the ncurses 
 > extensions I'm working on.

  This will be the curses.ascii module per a discussion last week
which included both Guido and Andrew.
  Andrew, my Unix machine is down for repairs; can you check these in
for me, changing the module name to curses.ascii in the documentation
file?  I don't want to hold up since Eric is still developing some of
the ncurses support.
  Thanks!


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From jeremy at beopen.com  Mon Jun 26 21:35:17 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 26 Jun 2000 15:35:17 -0400 (EDT)
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <20000626140125.A3266@thyrsus.com>
References: <20000626140125.A3266@thyrsus.com>
Message-ID: <14679.45173.439937.800007@bitdiddle.concentric.com>

The ascii module is going into the curses package.  Andrew Kuchling is
responsible for it.

Jeremy



From esr at thyrsus.com  Mon Jun 26 21:46:50 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 26 Jun 2000 15:46:50 -0400
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com>; from fdrake@beopen.com on Mon, Jun 26, 2000 at 12:24:40PM -0700
References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com>
Message-ID: <20000626154650.C3685@thyrsus.com>

Fred L. Drake, Jr. <fdrake at beopen.com>:
>   This will be the curses.ascii module per a discussion last week
> which included both Guido and Andrew.

OK, I guess.  It will be useful for more than curses, though, so I don't
understand the naming choice.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Hoplophobia (n.): The irrational fear of weapons, correctly described by 
Freud as "a sign of emotional and sexual immaturity".  Hoplophobia, like
homophobia, is a displacement symptom; hoplophobes fear their own
"forbidden" feelings and urges to commit violence.  This would be
harmless, except that they project these feelings onto others.  The
sequelae of this neurosis include irrational and dangerous behaviors
such as passing "gun-control" laws and trashing the Constitution.



From paul at prescod.net  Mon Jun 26 21:53:18 2000
From: paul at prescod.net (Paul Prescod)
Date: Mon, 26 Jun 2000 12:53:18 -0700
Subject: [Python-Dev] winreg
Message-ID: <3957B4AE.5562716C@prescod.net>

I haven't seen this message come through:

http://www.python.org/pipermail/python-dev/2000-June/006346.html

I'm not sure if I missed it due to an email problem.

 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
        - "This is your bill of rights...on drugs", Harpers, Dec. 1999



From fdrake at beopen.com  Mon Jun 26 21:59:10 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 12:59:10 -0700 (PDT)
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <20000626154650.C3685@thyrsus.com>
References: <20000626140125.A3266@thyrsus.com>
	<14679.44536.931222.448738@mailhost.beopen.com>
	<20000626154650.C3685@thyrsus.com>
Message-ID: <14679.46606.287276.330659@mailhost.beopen.com>

Eric S. Raymond writes:
 > OK, I guess.  It will be useful for more than curses, though, so I don't
 > understand the naming choice.

Eric,
  In theory, yes, but... there have not been a lot of requests for the
is*() functions (which are the ones I think you're referring to as
generally useful).  I think some of these are already take care of by
things like "if c in string.hexdigits:", and others can be handled by
making queries on the Unicode character properties.  Given the dearth
of requests for this, I don't see a clear need to place this
elsewhere.
  If feedback to the beta suggests a better location, we'll certainly
consider it!

  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Mon Jun 26 23:28:16 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 16:28:16 -0500
Subject: [Python-Dev] semaphore support in thread_*.h
In-Reply-To: Your message of "Mon, 26 Jun 2000 12:10:04 MST."
             <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com> 
References: <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com> 
Message-ID: <200006262128.QAA01518@cj20424-a.reston1.va.home.com>

> I noticed that the support for the semaphore calls in the various thread_*
> is very very spotty, with a comment in the BeOS implementation that read:
> 
>  * Guido says not to implement this because it's not used anywhere;
>  * I'll do it anyway, you never know when it might be handy, and it's
>  * easy...
> 
> (that last bit is not true of all implementations, apparently =).
> 
> 1) Is it true that the sema_ calls are never used?
> 
> 2) If yes, shouldn't we remove the sema_ calls from the thread API and have
> similar functionality on all platforms?
> 
> (There are related issues re: for example whether async thread locking is
> available, whether threads are joinable or not (see thread_cthread.h), etc.)

The sema_ calls aren't used anywhere in the current source.  I'd be
for removing them.  I'm not even sure why they are there -- maybe
Sjoerd remembers?  (This code was once part of something else than
Python.)

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



From akuchlin at mems-exchange.org  Mon Jun 26 23:28:26 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 26 Jun 2000 17:28:26 -0400
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com>
References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com>
Message-ID: <20000626172826.E2282@kronos.cnri.reston.va.us>

On Mon, Jun 26, 2000 at 12:24:40PM -0700, Fred L. Drake, Jr. wrote:
>  Andrew, my Unix machine is down for repairs; can you check these in
>for me, changing the module name to curses.ascii in the documentation
>file?  I don't want to hold up since Eric is still developing some of
>the ncurses support.

I'll do that tonight; I had no time for Python hacking over the weekend...

--amk



From mhammond at skippinet.com.au  Tue Jun 27 02:03:16 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 27 Jun 2000 10:03:16 +1000
Subject: [Python-Dev] winreg
In-Reply-To: <39577A23.EF7DE922@prescod.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au>

> I've just had a chance to look at the winreg module. I think that it is
> too low-level.

I agree.  There was a proposal (from Thomas Heller, IIRC) to do just this.
I successfully argued there should be _2_ modules for Python - the raw
low-level API, which guarantees you can do (almost) anything.  A
higher-level API could cover the 80% of cases.  It is probably worth
getting in touch with Thomas - he may be able to dig up his proposed
high-level API.  Ive CCd him on this message [I hope is _was_ you Thomas -
otherwise you will be wondering WTF I am on about :]

I was very keen to ensure the win32api code was used as the low-level API,
simply because it has been well tested and used.  We _know_ it has no
significant limitations.

Im happy to support a high-level API, but didnt have the inclination to
provide one.  Every one I have seen and every one I have tried to design
has started to fall-apart under real-world use - Ive needed to revert back
to the low-level.

> There are also bogus parameters that Microsoft hasn't got around to
> assigning values to, undocumented constants and so forth. My favorite is
> "WHOLE_HIVE_VOLATILE".

This is exactly my concern with a high-level API - you cant hope to capture
all this - especially the undocumented ones - so having a low-level API
means you can do anything, even stuff never dreamt of by the high-level
designer.

I have no real problem with your proposed design, as long as it it written
in Python, _using_ the low-level API.  It could be called "registry" or I
would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module
to be called "winreg.py"

Mark.




From tim_one at email.msn.com  Tue Jun 27 00:13:42 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 26 Jun 2000 18:13:42 -0400
Subject: [Python-Dev] semaphore support in thread_*.h
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEAGGGAA.tim_one@email.msn.com>

[David Ascher]
> I noticed that the support for the semaphore calls in the various thread_*
> is very very spotty, with a comment in the BeOS implementation that read:
>
>  * Guido says not to implement this because it's not used anywhere;
>  * I'll do it anyway, you never know when it might be handy, and it's
>  * easy...

> (that last bit is not true of all implementations, apparently =).
>
> 1) Is it true that the sema_ calls are never used?

Best I can tell, the following sema functions are indeed never used:

    PyThread_allocate_sema
    PyThread_free_sema
    PyThread_down_sema
    PyThread_up_sema

the following #define's are never used:

    WAIT_SEMA
    NOWAIT_SEMA

and the following non-sema pythread.h functions are not only never used,
they're defined only in thread_sgi.h:

    PyThread_create_key
    PyThread_delete_key
    PyThread_set_key_value
    PyThread_get_key_value

> 2) If yes, shouldn't we remove the sema_ calls from the thread
> API and have similar functionality on all platforms?

+1 from me.  If someone wants platform-specific thread functions, they
should be in a platform-specific extension module, not messing up the core.

> (There are related issues re: for example whether async thread locking is
> available, whether threads are joinable or not (see
> thread_cthread.h), etc.)

Sorry, don't know what you're getting at here (e.g., have any specific line
or function of thread_cthread.h in mind?).






From fdrake at beopen.com  Tue Jun 27 00:25:42 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 15:25:42 -0700 (PDT)
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com>
References: <14679.32536.133849.573542@mailhost.beopen.com>
	<LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com>
Message-ID: <14679.55398.996503.269852@mailhost.beopen.com>

Tim Peters writes:
 > Fred, would you please explain how that works or where that was set up?
 > I've puttered away many hours now playing with the SourceForge facilities

  From the "project page", go to "Project Admin" on the left
navigation bar, then "Edit Public Info" at the top of the page.  There
are places to edit some email addresses near the bottom of the page.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Mon Jun 26 23:38:51 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 26 Jun 2000 17:38:51 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <14679.32536.133849.573542@mailhost.beopen.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com>

[Fred]
>   patches at python.org should get messages of patch manager activity (at
> least certain actions; not sure which ones yet, but at least
> additions).

Fred, would you please explain how that works or where that was set up?
I've puttered away many hours now playing with the SourceForge facilities
(alas, most of that time waiting for web pages to load), but haven't
stumbled into anything that hints the patch manager knows anything about
patches at python.org.

so-stupid-in-so-many-ways-ly y'rs  - tim





From tim_one at email.msn.com  Tue Jun 27 01:14:06 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 26 Jun 2000 19:14:06 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <14679.55398.996503.269852@mailhost.beopen.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEALGGAA.tim_one@email.msn.com>

[Fred L. Drake, Jr.]
>   From the "project page", go to "Project Admin" on the left
> navigation bar, then "Edit Public Info" at the top of the page.  There
> are places to edit some email addresses near the bottom of the page.

Aha!  The one & only link I had never clicked -- I bet I could have figured
that out myself in another week or two <wink>.  Thank you.

Now why do we have "Use Bug Tracker" checked?  If nobody objects, I'll turn
that off -- we're still doing bugs w/ Jitterbug on python.org.

ten-stop-shopping-ly y'rs  - tim





From guido at beopen.com  Tue Jun 27 04:35:52 2000
From: guido at beopen.com (Guido van Rossum)
Date: Mon, 26 Jun 2000 21:35:52 -0500
Subject: [Python-Dev] ANN: Release schedule
Message-ID: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>

Here at BeOpen we're scrambling to get the release schedule for the
rest of Python 1.6 planned.  We're now looking at releasing Python
1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
This means that if SRE isn't ready, we'll go with an incomplete SRE.
Still better than no SRE!

Please, PLEASE, if you have pending patches that you think should go
into 1.6b1, submit them to SourceForge.  We'll do our best to have a
look at every patch submitted; but don't wait until the last moment.
(Trent Mick, it would be helpful if you assigned each of your patches
a potential reviewer from the list of existing developers -- that way
we can split up the review load.)

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



From trentm at activestate.com  Tue Jun 27 05:52:59 2000
From: trentm at activestate.com (Trent Mick)
Date: Mon, 26 Jun 2000 20:52:59 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pyexpat.py,1.2,1.3
In-Reply-To: <200006270037.RAA25539@slayer.i.sourceforge.net>
References: <200006270037.RAA25539@slayer.i.sourceforge.net>
Message-ID: <20000626205259.A3866@activestate.com>

On Mon, Jun 26, 2000 at 05:37:27PM -0700, A . M . Kuchling wrote:
> Update of /cvsroot/python/python/dist/src/Lib/test
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv25501
> 
> Modified Files:
> 	test_pyexpat.py 
> Log Message:
> Change pyexpat test suite to exercise the .returns_unicode attribute,
> parsing the sample data once with 8-bit strings and once with Unicode.
> 

Does this require a new Lib/test/output/test_pyexpat?


Trent


-- 
Trent Mick
trentm at activestate.com



From DavidA at ActiveState.com  Tue Jun 27 07:34:13 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 26 Jun 2000 22:34:13 -0700
Subject: [Python-Dev] semaphore support in thread_*.h
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEAGGGAA.tim_one@email.msn.com>
Message-ID: <LMBBIEIJKMPMLBONJMFCEEHJCJAA.DavidA@ActiveState.com>

> > (There are related issues re: for example whether async thread
> locking is
> > available, whether threads are joinable or not (see
> > thread_cthread.h), etc.)
>
> Sorry, don't know what you're getting at here (e.g., have any
> specific line
> or function of thread_cthread.h in mind?).

	/* looks like solaris detaches the thread to never rejoin
	 * so well do it here
	 */

in thread_cthread.h

The async thread locking comment was one of my personal issues -- I
considered briefly providing a thread layer on top of the NSPR (Netscape
Portable runtime) which is part of Mozilla.  It has locks, but no async
locking calls.

--david




From rob at hooft.net  Tue Jun 27 11:32:02 2000
From: rob at hooft.net (Rob W. W. Hooft)
Date: Tue, 27 Jun 2000 11:32:02 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1
In-Reply-To: <200006262355.QAA17089@slayer.i.sourceforge.net>
References: <200006262355.QAA17089@slayer.i.sourceforge.net>
Message-ID: <14680.29842.372192.274003@temoleh.chem.uu.nl>

 AMK> Update of /cvsroot/python/python/dist/src/Lib/curses
 AMK> In directory slayer.i.sourceforge.net:/tmp/cvs-serv17079

 AMK> Added Files:
 AMK> ascii.py textpad.py 
 AMK> Log Message:
 AMK> Added two modules for ASCII characters and a simple editing form (ESR)


 AMK> --- NEW FILE ---
 AMK> #
 AMK> # ascii.py -- constants and memembership tests for ASCII characters
 AMK> #
                                  ^^^^^ two letters too much?

Rob



From gvwilson at nevex.com  Tue Jun 27 12:30:55 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 27 Jun 2000 06:30:55 -0400 (EDT)
Subject: [Python-Dev] C# (new language from Microsoft)
Message-ID: <Pine.LNX.4.10.10006270630080.4977-100000@akbar.nevex.com>

I'm sure many of you will have seen this announcement already, but for
those who haven't, Microsoft is launching a new language to compete with
C, C++, and Java:

http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp

Greg




From effbot at telia.com  Tue Jun 27 12:35:22 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 12:35:22 +0200
Subject: [Python-Dev] ANN: Release schedule
References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>
Message-ID: <017501bfe023$684fca40$f2a6b5d4@hagrid>

guido wrote:


> Here at BeOpen we're scrambling to get the release schedule for the
> rest of Python 1.6 planned.  We're now looking at releasing Python
> 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
> This means that if SRE isn't ready, we'll go with an incomplete SRE.
> Still better than no SRE!

a major SRE patch is coming up later today.

btw, what would it take for me to check it in myself (assuming someone
will give me commit privs, of course)?  can I apply patches via sourceforge's
web interface, or do I have to figure out how to run cvs over ssh etc etc

(tim? where's the second installment of your sourceforge vs. windows series?)

</F>




From gmcm at hypernet.com  Tue Jun 27 12:36:07 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 27 Jun 2000 06:36:07 -0400
Subject: [Python-Dev] winreg
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au>
References: <39577A23.EF7DE922@prescod.net>
Message-ID: <1250020276-32999633@hypernet.com>

Mark wrote:

[Paul]
> > I've just had a chance to look at the winreg module. I think
> > that it is too low-level.
> 
> I agree.  There was a proposal (from Thomas Heller, IIRC) to do
> just this. I successfully argued there should be _2_ modules for
> Python - the raw low-level API, which guarantees you can do
> (almost) anything.  A higher-level API could cover the 80% of
> cases.  It is probably worth getting in touch with Thomas - he
> may be able to dig up his proposed high-level API.  

Found it.

------- Forwarded message follows -------
From:           	"Thomas Heller" <thomas.heller at ion-
tof.com>
To:             	<python-dev at python.org>, <distutil-
sig at python.org>
Date sent:      	Thu, 3 Feb 2000 14:27:00 +0100
Subject:        	[Python-Dev] Revised proposal (and 
preliminary implementation): Registry access module for 
Python on Windows

Ok, at least the first proposal did start the discussion.
Here is a revised one:

A preliminary implementation is available at
http://starship.python.net/crew/theller/

-----------------------------------------------------------------
----- winreg - windows registry access module

Exception:
  error - raised when a function fails. Will contain
    a windows error code and a textual description.

Objects:
  regnode object - represents a open key in the
  registry.

Functions:
  OpenKey (name) -> regnode object
    Opens an existing key with the specified access rights
    and returns a regnode object.
    name is specified like "HKLM\Software\Python"
    or "HKEY_LOCAL_MACHINE\Software\Python"

  CreateKey (name) -> regnode object
    Creates a new key or opens an existing one
    and returns a regnode object.
    For the name format see OpenKey

regnode object methods:
  Values () -> dict
    Returns a dictionary mapping names to values.
    The <default> or unnamed value has the key ''.
    The values are either strings or integers, depending
    on the REG_* type.

  GetValue ([name]) -> integer or string
    Returns a value specified by name or the default value.

  SetValue ([name,] value)
    Set a named or the <default> value.
    Named values must be integers or string (which are stored 
as
    REG_DWORD or REG_SZ). Should an optional third 
parameter be
    used, allowing to store in other REG_* typecodes? I dont
    think so.

  DeleteValue ([name])
    Deletes a named or the <default> value.

  SubKeys () -> sequence
    Returns a sequence containing the names of all subkeys.

  DeleteKey (name [,recursive=0])
    If recursive is 0, deletes the named key if no subkeys exist.
    If there are subkeys an error is raised.    If recursive is
    not 0, the named key is deleted including subkeys.

  OpenKey (name) -> regnode object
    Openes an existing subkey and returns a regnode
    object pointing to it.

  CreateKey (name) -> regnode object
    Creates a new or openes an existing subkey and
    returns a regnode object pointing to it.

regnode objects have the following properties:
  name - the name of the RegistryKey, something
    like "HKLM\Software\Python"
  hkey - the integer keyhandle

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

Thomas Heller





_______________________________________________
Python-Dev maillist  -  Python-Dev at python.org
http://www.python.org/mailman/listinfo/python-dev
------- End of forwarded message -------

- Gordon



From gstein at lyra.org  Tue Jun 27 12:52:02 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 03:52:02 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
In-Reply-To: <200006270050.RAA26210@slayer.i.sourceforge.net>; from akuchling@users.sourceforge.net on Mon, Jun 26, 2000 at 05:50:42PM -0700
References: <200006270050.RAA26210@slayer.i.sourceforge.net>
Message-ID: <20000627035202.M29590@lyra.org>

I just don't buy this.

Look at that code. Look at the definition of finally. That code simply
screams for the use of finally.

Eric: just what happens? What is "broke things"? Do you have a reproducible
test case that I can use?

In good conscience, I have to disagree with reverting this stuff. If we're
seeking to make the code the best possible, then this is a backward step.
Besides its redundancy, it also places the traceback into a local variable
and then raises an exception -- a perfect recipe for creating a ref loop.

Cheers,
-g

On Mon, Jun 26, 2000 at 05:50:42PM -0700, A.M. Kuchling wrote:
> Update of /cvsroot/python/python/dist/src/Lib/curses
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv26153
> 
> Modified Files:
> 	wrapper.py 
> Log Message:
> Drop back to old version of wrapper(); ESR reports that it broke things,
> and I lack the time to track down the cause.
> 
> 
> Index: wrapper.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/curses/wrapper.py,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -C2 -r1.2 -r1.3
> *** wrapper.py	2000/06/10 23:39:05	1.2
> --- wrapper.py	2000/06/27 00:50:40	1.3
> ***************
> *** 18,24 ****
> --- 18,26 ----
>       """
>       
> +     res = None
>       try:
>   	# Initialize curses
>   	stdscr=curses.initscr()
> +         
>   	# Turn off echoing of keys, and enter cbreak mode,
>   	# where no buffering is performed on keyboard input
> ***************
> *** 30,39 ****
>           stdscr.keypad(1)
>   
> ! 	return apply(func, (stdscr,) + rest)
> ! 
> !     finally:
> ! 	# Restore the terminal to a sane state on the way out.
>   	stdscr.keypad(0)
>   	curses.echo() ; curses.nocbreak()
>   	curses.endwin()
>   
> --- 32,51 ----
>           stdscr.keypad(1)
>   
> !         res = apply(func, (stdscr,) + rest)
> !     except:
> ! 	# In the event of an error, restore the terminal
> ! 	# to a sane state.
>   	stdscr.keypad(0)
>   	curses.echo() ; curses.nocbreak()
>   	curses.endwin()
> +         
> +         # Pass the exception upwards
> +         (exc_type, exc_value, exc_traceback) = sys.exc_info()
> +         raise exc_type, exc_value, exc_traceback
> +     else:
> + 	# Set everything back to normal
> + 	stdscr.keypad(0)
> + 	curses.echo() ; curses.nocbreak()
> + 	curses.endwin()		 # Terminate curses
>   
> +         return res
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From thomas.heller at ion-tof.com  Tue Jun 27 13:09:24 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Tue, 27 Jun 2000 13:09:24 +0200
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au>
Message-ID: <019601bfe028$281dab90$4500a8c0@thomasnb>

> > I've just had a chance to look at the winreg module. I think that it is
> > too low-level.
>
> I agree.  There was a proposal (from Thomas Heller, IIRC) to do just this.
> I successfully argued there should be _2_ modules for Python - the raw
> low-level API, which guarantees you can do (almost) anything.  A
> higher-level API could cover the 80% of cases.  It is probably worth
> getting in touch with Thomas - he may be able to dig up his proposed
> high-level API.  Ive CCd him on this message [I hope is _was_ you Thomas -
> otherwise you will be wondering WTF I am on about :]
Yes, it was me :-)

Here is the 3. (final?) proposal, earlier ones are in the archives:
http://www.python.org/pipermail/python-dev/2000-February/003417.html
and
http://www.python.org/pipermail/python-dev/2000-February/003472.html

----------------------------------------------------------------------
winreg - windows registry access module

Exception:
  error - raised when a function fails. Will contain
    a windows error code and a textual description.

Objects:
  regkey object - represents a open key in the
  registry.

Functions:
  OpenKey (name) -> regkey object
    Opens an existing key with the specified access rights
    and returns a regkey object.
    name is specified like "HKLM\Software\Python"
    or "HKEY_LOCAL_MACHINE\Software\Python"

  CreateKey (name) -> regkey object
    Creates a new key or opens an existing one
    and returns a regkey object.
    For the name format see OpenKey

regkey object methods:
  Standard Mapping protocol:
  len (r)
  r[k]
  r[k] = x
  del r[k]
  r.clear()
  r.has_key(k)
  r.items()
  r.keys()
  r.update(dict)
  r.values()
  r.get(k[, x])

  todict() -> dictionary
    Returns a dictionary mapping value names to values.

  SubKeys () -> sequence
    Returns a sequence containing the names of all subkeys.

  DeleteKey (name [,recursive=0])
    If recursive is 0, deletes the named key if no subkeys exist.
    If there are subkeys an error is raised.
    If recursive is not 0, the named key is deleted
    including subkeys.

  OpenKey (name) -> regkey object
    Openes an existing subkey and returns a regkey
    object pointing to it.

  CreateKey (name) -> regkey object
    Creates a new or openes an existing subkey and
    returns a regkey object pointing to it.

regkey objects have the following properties:
  name - the name of the RegistryKey, something
    like "HKLM\Software\Python"
  hkey - the integer keyhandle

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

It would not be too much work to implement it, but
I will be away the next 20 days...

> I have no real problem with your proposed design, as long as it it written
> in Python, _using_ the low-level API.  It could be called "registry" or I
> would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module
> to be called "winreg.py"
>
If we change the name of the low level api module, we have to change
Distutils,
because it is used there. Maybe we would better use the high level api then,
but there is still this 1.5 compatibility using the win32api module.

Thomas




From guido at beopen.com  Tue Jun 27 14:23:36 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 07:23:36 -0500
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: Your message of "Tue, 27 Jun 2000 12:35:22 +0200."
             <017501bfe023$684fca40$f2a6b5d4@hagrid> 
References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>  
            <017501bfe023$684fca40$f2a6b5d4@hagrid> 
Message-ID: <200006271223.HAA01391@cj20424-a.reston1.va.home.com>

[effbot]
> a major SRE patch is coming up later today.

Great!

> btw, what would it take for me to check it in myself (assuming someone
> will give me commit privs, of course)?  can I apply patches via sourceforge's
> web interface, or do I have to figure out how to run cvs over ssh etc etc

Erm, the latter.  From a Unix system it's a breeze.  From Windows,
it's a relative breeze to do an *anonymous* checkout (no SSH
required), but getting commit permission is a pain -- Tim will
research this.  (Do you have access to any Unix or Linux system at
all?)

I'll make you a developer anyway.

> (tim? where's the second installment of your sourceforge vs. windows series?)

I'm waiting too!

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



From guido at beopen.com  Tue Jun 27 16:30:30 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 09:30:30 -0500
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Mon, 26 Jun 2000 17:38:51 -0400."
             <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com> 
Message-ID: <200006271430.JAA01769@cj20424-a.reston1.va.home.com>

> [Fred]
> >   patches at python.org should get messages of patch manager activity (at
> > least certain actions; not sure which ones yet, but at least
> > additions).

[Tim]
> Fred, would you please explain how that works or where that was set up?
> I've puttered away many hours now playing with the SourceForge facilities
> (alas, most of that time waiting for web pages to load), but haven't
> stumbled into anything that hints the patch manager knows anything about
> patches at python.org.

Yes, it's hidden, and Fred had to show me too.

First, login to SourceForge.  Then, go to the Python Project.  In the
left sidebar, under Project: Python, go to Project Admin.  Near the
top, you now see some navigation links; go to Edit Public Info.
At the very bottom there are three text fields for email addresses.

The address for New Patches (a misnomer -- it's really all changes
made to the Patch Manager) says patches at python.org.

The address for New Bugs is currently set to guido at beopen.com.  I
suppose I should set it to pythoneers at beopen.com or even to
python-dev at python.org?

We're not using the Support manager yet.

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



From mhammond at skippinet.com.au  Tue Jun 27 16:45:07 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Jun 2000 00:45:07 +1000
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
In-Reply-To: <20000627035202.M29590@lyra.org>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEICCOAA.mhammond@skippinet.com.au>

> Besides its redundancy, it also places the traceback into a
> local variable
> and then raises an exception -- a perfect recipe for creating a ref loop.

Isnt it true that _every_ time you store a traceback object as a local
variable, and that traceback has a reference to the frame holding the
local, you _always_ get a reference loop, regardless of how you exit the
function?

ie, I believe that _every_ time you store a traceback obtained from inside
an except handler, you _always_ get a ref-loop, period.  The only way to
clean the cycle is to explictly unbind the local from the traceback.

Mark.





From mhammond at skippinet.com.au  Tue Jun 27 16:39:15 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Jun 2000 00:39:15 +1000
Subject: [Python-Dev] C# (new language from Microsoft)
In-Reply-To: <Pine.LNX.4.10.10006270630080.4977-100000@akbar.nevex.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEIBCOAA.mhammond@skippinet.com.au>

I cant say much, as I am still under NDA.  However, I probably can say:

* C Sharp is really not the interesting part of this technology.  MS are
controlling the way (the order, really) the information is coming out; as
more info comes out, C Sharp should move back into perspective for what is
really is.  Suffice it to say, hardly anyone on slashdot is even in the
ball-park!

* The MS PDC in a couple of weeks will be the official announcement of the
more interesting things.  After this, everyone involved in the project will
be completely free to discuss all they know, including me (and a few other
Pythoneers)

* Python has a very good and interesting story in all this - there is no
need to be alarmed.  If anything, be excited :-)

Mark.

> -----Original Message-----
> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Greg Wilson
> Sent: Tuesday, 27 June 2000 8:31 PM
> To: Python Developers
> Subject: [Python-Dev] C# (new language from Microsoft)
>
>
> I'm sure many of you will have seen this announcement already, but for
> those who haven't, Microsoft is launching a new language to compete with
> C, C++, and Java:
>
> http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp
>
> Greg
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
>




From paul at prescod.net  Tue Jun 27 17:15:29 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:15:29 -0700
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb>
Message-ID: <3958C511.17282EF7@prescod.net>

Mark, Thomas and whoever, thanks for your input and I hope you can spare
some more...

Thomas Heller wrote:
> 

This is similar to what I have implemented...

> ----------------------------------------------------------------------
> winreg - windows registry access module
> 
> Exception:
>   error - raised when a function fails. Will contain
>     a windows error code and a textual description.

As an aside, I notice that the winreg documentation says it will raise
an EnvironmentError but it actually raises a WindowsError. 

> Objects:
>   regkey object - represents a open key in the
>   registry.

Right. Even the same name.

My stance was that keys would always be created from keys, so you would
start with

HKEY_LOCAL_MACHINE.CreateKey("Software\Python")

That mirrors the underlying API a little closer and reduces the number
of functions to 0.

The question is whether the CreateKey and OpenKey functions are
important enough as "convenience functions".

> regkey object methods:
>   Standard Mapping protocol:
>   len (r)
>   r[k]
>   r[k] = x
>   del r[k]
>   r.clear()
>   r.has_key(k)
>   r.items()
>   r.keys()
>   r.update(dict)
>   r.values()
>   r.get(k[, x])

I had a separate object for values. I couldn't really justify elevating
either the Subkeys or the Values. I tried to treat them as alike as
possible.

>   todict() -> dictionary
>     Returns a dictionary mapping value names to values.

I called this getValues() and it returned an object that was both a
mapping and a sequence and allowed read/write/delete of values.

>   SubKeys () -> sequence
>     Returns a sequence containing the names of all subkeys.
> 
>   DeleteKey (name [,recursive=0])
>     If recursive is 0, deletes the named key if no subkeys exist.
>     If there are subkeys an error is raised.
>     If recursive is not 0, the named key is deleted
>     including subkeys.

I may or may not get around to implementing the recursive version. You
have to be VERY CAREFUL when you test such a thing. :)

>   OpenKey (name) -> regkey object
>     Openes an existing subkey and returns a regkey
>     object pointing to it.

Okay.

>   CreateKey (name) -> regkey object
>     Creates a new or openes an existing subkey and
>     returns a regkey object pointing to it.

Okay.

> regkey objects have the following properties:
>   name - the name of the RegistryKey, something
>     like "HKLM\Software\Python"

Okay.

>   hkey - the integer keyhandle

Is this really useful? Better to use the low-level API in that case...

> If we change the name of the low level api module, we have to change
> Distutils,
> because it is used there. Maybe we would better use the high level api then,
> but there is still this 1.5 compatibility using the win32api module.

The high level could probably be made compatible with 1.5 like this:

try:
    import _winreg
except ImportError:
    import win32api
    winreg=win32api

It would probably be good for DistUtils to use the high level API as
soon as it is possible for testing purposes.

I am considering doing away with the two enumeration interfaces. The
cost/benefit of having two more objects is probably low.

We can simplify the whole thing by just using methods on the regkey
object:

deleteValue(name) 
getValue(name)-> (type, value)
setValue(name,(type,value))
getValueNames() -> List of strings

getSubkey(name) -> regkey
deleteSubkey(name)
getSubkeyNames( ) -> List of strings

Iterating will be slightly less efficient because it will loop twice,
once to gather the names and once to do whatever you need to do but
that's not the typical registry use case anyhow. Anyone who needs
absolute performance can use the low-level API.

Recursive iteration under the existing model:

def doit( key ):
    for subkey in key.getSubkeyNames():
        doit( subkey )

Recursive iteration under the proposed model:

def doit( key ):
    for keyname in key.getSubkeyNames():
        doit( key.getSubkey( name ))

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From paul at prescod.net  Tue Jun 27 17:28:55 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:28:55 -0700
Subject: [Python-Dev] winreg features
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb>
Message-ID: <3958C837.ECD925CC@prescod.net>

There are a few features missing from the proposed API. I don't think
that this API should serve the 80%, but rather the 97%. The only things
I plan to exclude from the low level API are things that are
undocumented and a little bit of performance.

I see no reason not to add support for close, flush, save, remote keys
and REG_FOO types.

If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add
support for that too. :)

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From paul at prescod.net  Tue Jun 27 17:29:16 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:29:16 -0700
Subject: [Python-Dev] winreg features
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb>
Message-ID: <3958C84C.37C3EAD@prescod.net>

There are a few features missing from the proposed API. I don't think
that this API should serve the 80%, but rather the 97%. The only things
I plan to exclude from the low level API are things that are
undocumented and a little bit of performance. I want to simplify the
API, not dumb it down.

I see no reason not to add support for close, flush, save, remote keys
and REG_FOO types.

If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add
support for that too. :)

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From thomas.heller at ion-tof.com  Tue Jun 27 17:42:26 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Tue, 27 Jun 2000 17:42:26 +0200
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net>
Message-ID: <02e201bfe04e$4cecc700$4500a8c0@thomasnb>

(Hopefully it is ok to use the reply-all button)

> ...
> My stance was that keys would always be created from keys, so you would
> start with
>
> HKEY_LOCAL_MACHINE.CreateKey("Software\Python")
>
> That mirrors the underlying API a little closer and reduces the number
> of functions to 0.
Good idea!
Maybe HKLM and so on should be provided as aliases.

> >
> >   DeleteKey (name [,recursive=0])
> >     If recursive is 0, deletes the named key if no subkeys exist.
> >     If there are subkeys an error is raised.
> >     If recursive is not 0, the named key is deleted
> >     including subkeys.
>
> I may or may not get around to implementing the recursive version. You
> have to be VERY CAREFUL when you test such a thing. :)
Someone (I don't remember who) mentioned in the discussion
about my proposal that one should use SHDeleteKey for recursive
deletion of keys. See the MSDN docs on RegDeleteKey for details.
Don't know if this is exposed by the lowlevel module.

>
> > If we change the name of the low level api module, we have to change
> > Distutils,
> > because it is used there. Maybe we would better use the high level api
then,
> > but there is still this 1.5 compatibility using the win32api module.
>
> The high level could probably be made compatible with 1.5 like this:
>
> try:
>     import _winreg
> except ImportError:
>     import win32api
>     winreg=win32api
Currently it goes like this, because win32api and winreg (which
will soon be _winreg) have slightly different apis, but it will
doubtlessly be solved:

try:
    import winreg
    _can_read_reg = 1
    hkey_mod = winreg

    RegOpenKeyEx = winreg.OpenKeyEx
    RegEnumKey = winreg.EnumKey
    RegEnumValue = winreg.EnumValue
    RegError = winreg.error

except ImportError:
    try:
        import win32api
        import win32con
        _can_read_reg = 1
        hkey_mod = win32con

        RegOpenKeyEx = win32api.RegOpenKeyEx
        RegEnumKey = win32api.RegEnumKey
        RegEnumValue = win32api.RegEnumValue
        RegError = win32api.error

    except ImportError:
        pass

Thomas




From paul at prescod.net  Tue Jun 27 17:52:27 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:52:27 -0700
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb>
Message-ID: <3958CDBB.3F354C97@prescod.net>

Right now the Python list is a little slow (at least for me) so I
appreciate cc:s directly to me.

Thomas Heller wrote:
> 
> Good idea!
> Maybe HKLM and so on should be provided as aliases.

Sure.

> Someone (I don't remember who) mentioned in the discussion
> about my proposal that one should use SHDeleteKey for recursive
> deletion of keys. See the MSDN docs on RegDeleteKey for details.
> Don't know if this is exposed by the lowlevel module.

Don't think so.

> Currently it goes like this, because win32api and winreg (which
> will soon be _winreg) have slightly different apis, but it will
> doubtlessly be solved:

Ouch. I don't know if I have time to figure out all of the
correspondances. Are the only differences those four method names or are
those the only four differences that DistUtils happened to care about.
I'm not interested in 1.5 compatibility if it will take a lot of work.

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From thomas.heller at ion-tof.com  Tue Jun 27 18:03:30 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Tue, 27 Jun 2000 18:03:30 +0200
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net>
Message-ID: <02fe01bfe051$3df655b0$4500a8c0@thomasnb>

> Right now the Python list is a little slow (at least for me) so I
> appreciate cc:s directly to me.
Same for me: All python lists take hours to distribute the mails.

> > Someone (I don't remember who) mentioned in the discussion
> > about my proposal that one should use SHDeleteKey for recursive
> > deletion of keys. See the MSDN docs on RegDeleteKey for details.
> > Don't know if this is exposed by the lowlevel module.
>
> Don't think so.
The tricky thing is: Deletion of keys behaves differently
on Win95/98 and NT/2000.
(Quoting MSDN:)
The RegDeleteKey function deletes a subkey.

Windows 95/98: The function also deletes all subkeys and values. To delete a
key only if the key has no subkeys or values, use the SHDeleteEmptyKey
function.

Windows NT/2000: The subkey to be deleted must not have subkeys. To delete a
key and all its subkeys, you need to recursively enumerate the subkeys and
delete them individually. To recursively delete keys, use the SHDeleteKey
function.
(end quote)

The SHDelete* funtions require version 4.71 of shlwapi.dll, which
is included in Win98 or 2000 (or in IE 4.0).

>
> > Currently it goes like this, because win32api and winreg (which
> > will soon be _winreg) have slightly different apis, but it will
> > doubtlessly be solved:
>
> Ouch. I don't know if I have time to figure out all of the
> correspondances. Are the only differences those four method names or are
> those the only four differences that DistUtils happened to care about.
> I'm not interested in 1.5 compatibility if it will take a lot of work.
So you should simply ignore this. We will work it out on distutils.

Thomas
(I will disappear soon for holidays)




From Vladimir.Marangozov at inrialpes.fr  Tue Jun 27 18:23:52 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Tue, 27 Jun 2000 18:23:52 +0200 (CEST)
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 26, 2000 09:35:52 PM
Message-ID: <200006271623.SAA04926@python.inrialpes.fr>

Guido van Rossum wrote:
> 
> Here at BeOpen we're scrambling to get the release schedule for the
> rest of Python 1.6 planned.  We're now looking at releasing Python
> 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
> This means that if SRE isn't ready, we'll go with an incomplete SRE.
> Still better than no SRE!
> 
> Please, PLEASE, if you have pending patches that you think should go
> into 1.6b1, submit them to SourceForge.  We'll do our best to have a
> look at every patch submitted; but don't wait until the last moment.

So, to sum up (because I'm a bit lost after all this patch-related
messages), what should I do to avoid at best adding to the collective
burden :

1. Should I send patches to SF and be quiet until June 30 ?

2. Should I apply for privileges and spend <big time> installing
   an SSH client on my box (illegal in France ;), then make my Python
   way into the SF galaxy ?

3. If I volunteer for help with the patches backlog, what do I do ?

4. Other options presented to me ?

Context : I (will) have some patches lying around, there are some
patches of mine on the pile sent to patches at python.org that I'm
confident about, I have read the FAQ at SF which gave me 0 clues
on how things are being set up there (only general info about
who why and what for + terms of service), and I managed to create
an account with a personal page containing two bookmarks in it
(after being distracted with personal and project ratings + gobs of
links to gobs of stuff).

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From guido at beopen.com  Tue Jun 27 19:27:24 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 12:27:24 -0500
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: Your message of "Tue, 27 Jun 2000 18:23:52 +0200."
             <200006271623.SAA04926@python.inrialpes.fr> 
References: <200006271623.SAA04926@python.inrialpes.fr> 
Message-ID: <200006271727.MAA03564@cj20424-a.reston1.va.home.com>

> 1. Should I send patches to SF and be quiet until June 30 ?

Yes.  Not too quiet -- helping selecting which old patches are good
would help.  Also downloading patches from SF and commenting on them
(+1/-1) in the patches list would help.

> 2. Should I apply for privileges and spend <big time> installing
>    an SSH client on my box (illegal in France ;), then make my Python
>    way into the SF galaxy ?

Probably no.

> 3. If I volunteer for help with the patches backlog, what do I do ?

Go through the patches archives and review patches.  If you find one
for which you would vote +1 and which you think I might like, submit
it to SF.

> 4. Other options presented to me ?
> 
> Context : I (will) have some patches lying around, there are some
> patches of mine on the pile sent to patches at python.org that I'm
> confident about, I have read the FAQ at SF which gave me 0 clues
> on how things are being set up there (only general info about
> who why and what for + terms of service), and I managed to create
> an account with a personal page containing two bookmarks in it
> (after being distracted with personal and project ratings + gobs of
> links to gobs of stuff).

Go to the Python Project Summary, then to the Patch Manager.  At the
top, click on Submit Patch.

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



From mal at lemburg.com  Tue Jun 27 18:38:54 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 27 Jun 2000 18:38:54 +0200
Subject: [Python-Dev] SF patch manager...
Message-ID: <3958D89E.39D084C8@lemburg.com>

[Please excuse my ranting... :-)]

I've received the first round of notification message from the
patch manager and can't really say that I like them. Ok, I 
understand that the patch manager is still alpha or beta software,
but these messages really don't have any usable content at all:

"""
Patch #100646 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470
"""

Also, reviewing the patches has become a pain and discussing them
is nearly impossible (I don't consider the slashdot like comment
mechanism to be of any use: there's simply no audience for
discussion).

Is there any chance of tee'ing patches from SF to the patches
list or some other patch discussion and review forum ? I do
understand that the mechanism can help with patch *checkins*,
but it's certainly not going to help much with the discussion
step needed before conidering any actions. The independent
peer review principal doesn't work with this kind of setup.

Ok, enough whining, let's get on with business now ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From esr at thyrsus.com  Tue Jun 27 18:50:53 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 27 Jun 2000 12:50:53 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
In-Reply-To: <20000627035202.M29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 03:52:02AM -0700
References: <200006270050.RAA26210@slayer.i.sourceforge.net> <20000627035202.M29590@lyra.org>
Message-ID: <20000627125053.B6531@thyrsus.com>

Greg Stein <gstein at lyra.org>:
> I just don't buy this.
> 
> Look at that code. Look at the definition of finally. That code simply
> screams for the use of finally.
> 
> Eric: just what happens? What is "broke things"? Do you have a reproducible
> test case that I can use?

What happened is that your version failed to pass an error exception upwards
after fielding it.  My test case was a buggy version of cmlconfigure.py, bug
since fixed.

Cleanliness is good, but the code has to work first.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Faith may be defined briefly as an illogical belief in the occurrence
of the improbable...A man full of faith is simply one who has lost (or
never had) the capacity for clear and realistic thought. He is not a
mere ass: he is actually ill.
	-- H. L. Mencken 



From trentm at activestate.com  Tue Jun 27 18:46:58 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 09:46:58 -0700
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>
References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>
Message-ID: <20000627094658.B7257@activestate.com>

On Mon, Jun 26, 2000 at 09:35:52PM -0500, Guido van Rossum wrote:
> (Trent Mick, it would be helpful if you assigned each of your patches
> a potential reviewer from the list of existing developers -- that way
> we can split up the review load.)
> 

Do you mean I should reassigned patch-reviewing over and above the
assignments that you have done recently? I was just going to put up twenty
more patches and assign them all to Tim as well. :) Kidding.

If, "yes", then I will make a go at that today.


BTW I have answered a couple a questions on my patches. Does the person to
whom the patch is assigned get an update notification?

Trent


-- 
Trent Mick
trentm at activestate.com



From trentm at activestate.com  Tue Jun 27 18:57:38 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 09:57:38 -0700
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <14679.36964.766774.864078@localhost.localdomain>
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain>
Message-ID: <20000627095738.D7257@activestate.com>

On Mon, Jun 26, 2000 at 01:18:28PM -0400, Jeremy Hylton wrote:
> Ok.  I was looking for a test case to include in the test suite.  I've
> made the change, but it looks like it will have to go without an
> accompanying test.


I asked the question a while back if it would reasonable/useful/popular to
have a mechanism where parts of the Python/C Api could be tested directly.

My proposal used an extension module _testmodule (although I made it a core
module on UN*X it should not bog down the core) which exported a bunch o'
test_* routines that tested specific parts of the Python/C API. A
test_internal.py module would be added to the std regression test suite that
would import this module and call each of the exported test_* routines in
turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested.

Anybody have any opinions?


Trent

p.s. I have a patch largely (all except the above menntion limitation) ready
for this, including some tests that I used for my 64-bit porting stuff. 


-- 
Trent Mick
trentm at activestate.com



From skip at mojam.com  Tue Jun 27 19:11:33 2000
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 27 Jun 2000 12:11:33 -0500 (CDT)
Subject: [Python-Dev] semi-subtle atexit gotcha?
Message-ID: <14680.57413.385666.482385@beluga.mojam.com>

In thinking about the new atexit module a little more, it occurred to me
that I've handled the case where the atexit module gets loaded after another 
module that wants to set sys.exitfunc (it just incorporates that function
into its list of functions), but not if atexit gets loaded before another
modules that uses sys.exitfunc.  I see two possible choices:

    1. Punt and put a bit of verbiage in the atexit section of the library
       reference manual and the 1.6 release notes.

    2. Have atexit.register check each time it's called to see if
       sys.exitfunc is what it expects.  This isn't a perfect solution for a 
       couple reasons.  One, there's no guarantee that other sys.exitfunc- 
       modifying code isn't executed after the last call to
       atexit.register.  Two, there's no guarantee that the other code
       doesn't attempt to be "intelligent" in a fashion similar to atexit
       (can you say dueling banjos?).

I vote for option number one since there appears to be no guaranteed way to
make it work, but I'm open to other suggestions.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From trentm at activestate.com  Tue Jun 27 19:16:58 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 10:16:58 -0700
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>
References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>
Message-ID: <20000627101658.E7257@activestate.com>

On Mon, Jun 26, 2000 at 02:41:12PM -0400, Tim Peters wrote:
> Intended use of SourceForge patch status tags
> ---------------------------------------------
> revision 1                        26-Jun-2000
> 
> 
> Open
>     The initial status of all patches.
>     The patch is under consideration, but has not
>     been reviewed yet.
>     The status will normally change to Accepted or Rejected next.
>     The person submitting the patch should (if they can) assign
>     it to the person they most want to review it.
>     Else the patch will be assigned via
>         [xxx a list of expertise areas should be developed]

What are the chances of getting other meta data fields on patches, i.e.
changes to the patch manager? Categorizing patches could really help as a
filter. For instance, I may be a Unicode genius and would like to see the
patches associated with it.


>     Discussion of patches is carried out via
>         [xxx Python-Dev?  patches list?  without a mail gateway,
>              the SourceForge patch interface looks too clumsy
>              to use for controversial patches]

I like the separation of python-dev and patches, but it is not a biggie for
me.


> Postponed
>     The previous status was Open or Accepted, but for some reason
>     (e.g., pending release) the patch should not be reviewed or
>     applied until further notice.
>     The status will normally change to Open or Accepted next.
>     Please enter a comment when changing the status to Postponed,
>     to record the reason, the previous status, and the conditions
>     under which the patch should revert to Open or Accepted.

Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the
person responsible for later taking to patch out of 'postponed' status.



Trent


-- 
Trent Mick
trentm at activestate.com



From jeremy at beopen.com  Tue Jun 27 19:21:28 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 27 Jun 2000 13:21:28 -0400 (EDT)
Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <20000627095738.D7257@activestate.com>
References: <20000622193610.27452.qmail@eik.g.aas.no>
	<395272D0.B82A0353@lemburg.com>
	<m3r99pjvrx.fsf@eik.g.aas.no>
	<39531A20.1BEAA51E@lemburg.com>
	<m3hfak4tds.fsf@eik.g.aas.no>
	<14675.30233.658776.764865@localhost.localdomain>
	<m38zvwxn9u.fsf@eik.g.aas.no>
	<14679.36964.766774.864078@localhost.localdomain>
	<20000627095738.D7257@activestate.com>
Message-ID: <14680.58008.466802.160183@bitdiddle.concentric.com>

I think testing the C API directly is a great idea!  Sorry I missed it
the first time around.

I don't think I understand the suggested approach well enough to
critique it.  Most of the tests need to be written in C, right?  When
an error is encountered, it seems that you should check what the C API
returns *and* what happens at the Python level, i.e. whether the call
sets a Python exception (or clears an existing Python exception).

I guess you ought to show us the code.  I don't think it will go in
Python 1.6, but it sounds like a valuable component for future
releases. 

Jeremy



From trentm at activestate.com  Tue Jun 27 19:37:00 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 10:37:00 -0700
Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <14680.58008.466802.160183@bitdiddle.concentric.com>
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com>
Message-ID: <20000627103700.G7257@activestate.com>

On Tue, Jun 27, 2000 at 01:21:28PM -0400, Jeremy Hylton wrote:
> 
> I don't think I understand the suggested approach well enough to
> critique it.  Most of the tests need to be written in C, right?  When

All of the testing code would be in C, in the _testmodule.c, or whatever
name.

> an error is encountered, it seems that you should check what the C API
> returns *and* what happens at the Python level, i.e. whether the call
> sets a Python exception (or clears an existing Python exception).

Yes you are right. It depends on the API under test. Basically you just try
to test all conditions to ensure that the API behaves as expected/advertised.


> 
> I guess you ought to show us the code.  I don't think it will go in
> Python 1.6, but it sounds like a valuable component for future
> releases. 
> 

Okay. I agree that this would probably not make 1.6 so I will probably wait
on this for a little while. Busy.


Trent

-- 
Trent Mick
trentm at activestate.com



From trentm at activestate.com  Tue Jun 27 19:56:47 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 10:56:47 -0700
Subject: [Python-Dev] my dev status on SourceForge
In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com>
References: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com> <200006271430.JAA01769@cj20424-a.reston1.va.home.com>
Message-ID: <20000627105647.H7257@activestate.com>

SPeaking of surprising little SourceForge things:

I just made the mistake of clicking on the little garbage can beside "Python"
in "My Projects". I seem to have booted myself from the Python project. Can I
put myself back on? or can one of you with admin status please do that for
me?

my SourceForge username is: tmick

Sorry and thanks,
Trent




-- 
Trent Mick
trentm at activestate.com



From akuchlin at mems-exchange.org  Tue Jun 27 20:20:21 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 27 Jun 2000 14:20:21 -0400
Subject: [Python-Dev] curses/wrapper.py
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEICCOAA.mhammond@skippinet.com.au>
References: <20000627035202.M29590@lyra.org> <ECEPKNMJLHAPFFJHDOJBAEICCOAA.mhammond@skippinet.com.au>
Message-ID: <20000627142021.G19033@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 12:45:07AM +1000, Mark Hammond quoted:
>> Besides its redundancy, it also places the traceback into a
>> local variable
>> and then raises an exception -- a perfect recipe for creating a ref loop.

I think this is irrelevant for the curses.wrapper() function, which
simply restores the terminal state before re-raising the exception.
It probably won't ever be called repeatedly, making the question of a
memory leak moot.

Yes, I'd like to have wrapper() use Greg Stein's simpler and tidier
code.  Yes, I'd like to know why ESR claims the simpler version
doesn't work and have a replicable test case.  But right now there are
higher priority things to do, so I'm shelving this until after 1.6b1.
(Right now I'm trying to get the curses module compiling on Tru64, and
things don't look good.)

--amk




From pingster at ilm.com  Tue Jun 27 20:25:01 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Tue, 27 Jun 2000 11:25:01 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1
In-Reply-To: <14680.29842.372192.274003@temoleh.chem.uu.nl>
Message-ID: <Pine.SGI.3.96.1000627110923.621134C-100000@happy>

On Tue, 27 Jun 2000, Rob W. W. Hooft wrote:
>  AMK> --- NEW FILE ---
>  AMK> #
>  AMK> # ascii.py -- constants and memembership tests for ASCII characters
>  AMK> #
>                                   ^^^^^ two letters too much?

Grrrr... surely by now we should be getting docstrings instead of
comments at the top of modules!

In keeping with the format of most other modules, i also suggest
not repeating the module name.  Thus:

    """Constants and membership tests for ASCII characters."""



-- ?!ng

(166 irender improvements since May 1999)







From Vladimir.Marangozov at inrialpes.fr  Tue Jun 27 20:39:35 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Tue, 27 Jun 2000 20:39:35 +0200 (CEST)
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <no.id> from "Vladimir Marangozov" at Jun 27, 2000 06:23:52 PM
Message-ID: <200006271839.UAA05354@python.inrialpes.fr>

I'm resending this msg since it didn't seem to get through the 1st time
(and we're experiencing some major hw&sw router problems lately)

Vladimir Marangozov wrote:
> 
> Guido van Rossum wrote:
> > 
> > Here at BeOpen we're scrambling to get the release schedule for the
> > rest of Python 1.6 planned.  We're now looking at releasing Python
> > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
> > This means that if SRE isn't ready, we'll go with an incomplete SRE.
> > Still better than no SRE!
> > 
> > Please, PLEASE, if you have pending patches that you think should go
> > into 1.6b1, submit them to SourceForge.  We'll do our best to have a
> > look at every patch submitted; but don't wait until the last moment.
> 
> So, to sum up (because I'm a bit lost after all this patch-related
> messages), what should I do to avoid at best adding to the collective
> burden :
> 
> 1. Should I send patches to SF and be quiet until June 30 ?
> 
> 2. Should I apply for privileges and spend <big time> installing
>    an SSH client on my box (illegal in France ;), then make my Python
>    way into the SF galaxy ?
> 
> 3. If I volunteer for help with the patches backlog, what do I do ?
> 
> 4. Other options presented to me ?
> 
> Context : I (will) have some patches lying around, there are some
> patches of mine on the pile sent to patches at python.org that I'm
> confident about, I have read the FAQ at SF which gave me 0 clues
> on how things are being set up there (only general info about
> who why and what for + terms of service), and I managed to create
> an account with a personal page containing two bookmarks in it
> (after being distracted with personal and project ratings + gobs of
> links to gobs of stuff).
> 
> -- 
>        Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
> http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
> 


-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From paul at prescod.net  Tue Jun 27 20:46:40 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 11:46:40 -0700
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net> <02fe01bfe051$3df655b0$4500a8c0@thomasnb>
Message-ID: <3958F690.EDB27D07@prescod.net>

I'm trying to figure out all of the constants in _winreg. Some of them
seem related to functions that _winreg doesn't support. I won't put
those in new winreg because they can't be used. The only one I can't
figure out through web searches is REG_OPTION_OPEN_LINK.

RegNotifyChangeKeyValue (unsupported)
	REG_NOTIFY_CHANGE_NAME
	REG_NOTIFY_CHANGE_LAST_SET 
	REG_NOTIFY_CHANGE_SECURITY 
	REG_NOTIFY_CHANGE_ATTRIBUTES 

RegRestoreKey (unsupported)
	REG_FORCE_RESTORE
	REG_NO_LAZY_FLUSH
	REG_REFRESH_HIVE
	REG_WHOLE_HIVE_VOLATILE

RegCreateKeyEx (unxupported)
	REG_OPTION_RESERVED
	REG_OPTION_VOLATILE
	REG_OPTION_NON_VOLATILE
	REG_OPTION_BACKUP_RESTORE
	REG_CREATED_NEW_KEY
	REG_OPENED_EXISTING_KEY
	REG_OPTION_CREATE_LINK

I presume that nobody intends to add these three functions to _winreg in
time for Python 1.6!

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From effbot at telia.com  Tue Jun 27 21:25:23 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 21:25:23 +0200
Subject: [Python-Dev] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
References: <200006270050.RAA26210@slayer.i.sourceforge.net> <20000627035202.M29590@lyra.org> <20000627125053.B6531@thyrsus.com>
Message-ID: <001f01bfe06d$753492a0$f2a6b5d4@hagrid>

Eric S. Raymond wrote:
> What happened is that your version failed to pass an error exception upwards
> after fielding it.  My test case was a buggy version of cmlconfigure.py, bug
> since fixed.
> 
> Cleanliness is good, but the code has to work first.

umm.  as far as I can tell from the patch, there's no way your
code can work in a situation where try/finally wouldn't do exactly
the same thing.

if you *do* get different results (try inserting "raise whatever"
in the try clause to test this), it might be that you've stumbled
upon a real bug (either in Python or in the curses C bindings)...

</F>




From guido at beopen.com  Tue Jun 27 22:25:49 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 15:25:49 -0500
Subject: [Python-Dev] Re: my dev status on SourceForge
In-Reply-To: Your message of "Tue, 27 Jun 2000 10:56:47 MST."
             <20000627105647.H7257@activestate.com> 
References: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com> <200006271430.JAA01769@cj20424-a.reston1.va.home.com>  
            <20000627105647.H7257@activestate.com> 
Message-ID: <200006272025.PAA04010@cj20424-a.reston1.va.home.com>

> SPeaking of surprising little SourceForge things:
> 
> I just made the mistake of clicking on the little garbage can beside "Python"
> in "My Projects". I seem to have booted myself from the Python project. Can I
> put myself back on? or can one of you with admin status please do that for
> me?
> 
> my SourceForge username is: tmick

OK, you're back!

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



From pingster at ilm.com  Tue Jun 27 21:38:15 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Tue, 27 Jun 2000 12:38:15 -0700 (PDT)
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <3958D89E.39D084C8@lemburg.com>
Message-ID: <Pine.SGI.3.96.1000627123233.621134G-100000@happy>

On Tue, 27 Jun 2000, M.-A. Lemburg wrote:
> I've received the first round of notification message from the
> patch manager and can't really say that I like them.

I wish i could propose Roundup, but it currently lacks the
ability to decode e-mail attachments.  Aside from that, it
has reasonable (if basic) e-mail handling, colour-coded
status and priorities, and so on.

I would jump on it in a second except that the Software
Carpentry deadline is also this Friday and i'm still barely
pulling that thing together.

Of course, if you feel like hacking it up to do attachments
feel free to get it at http://pingster.com/roundup.html and
hack away!

Alternatively i suppose you could keep the patch files on
SourceForge and do the discussions in Roundup as an interim
solution?  Messy, i know, but it might be an improvement.



-- ?!ng




From paul at prescod.net  Tue Jun 27 21:45:16 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 12:45:16 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses 
 ascii.py,NONE,1.1 textpad.py,NONE,1.1
References: <Pine.SGI.3.96.1000627110923.621134C-100000@happy>
Message-ID: <3959044C.B5C537FA@prescod.net>

Ka-Ping Yee wrote:
> 
> -- ?!ng
> 
> (166 irender improvements since May 1999)

> Although some shots were composited with Sabre, ILM's extensions 
> to Discreet Logic's Flame and Inferno software, CompTime was 
> the compositing tool for the CG department, according to 
> Jeff Yost. First used for one shot in Saving Private Ryan, 
> CompTime is based on the studio's long-time scripted system, but 
> now boasts a graphical user interface and hooks for plug-ins that 
> can be written in Python or C++. 

Is it safe to say that "Without Python, Saving Private Ryan would not
have been possible, much less an Oscar winner?"

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From effbot at telia.com  Tue Jun 27 22:01:26 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 22:01:26 +0200
Subject: [Python-Dev] Re: testing the Python/C API
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com> <20000627103700.G7257@activestate.com>
Message-ID: <006801bfe072$7abc0820$f2a6b5d4@hagrid>

trent wrote:
> > I don't think I understand the suggested approach well enough to
> > critique it.  Most of the tests need to be written in C, right?  When
> 
> All of the testing code would be in C, in the _testmodule.c, or whatever
> name.

SWIG, anyone?

</F>




From effbot at telia.com  Tue Jun 27 22:06:30 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 22:06:30 +0200
Subject: [Python-Dev] SF patch manager...
References: <3958D89E.39D084C8@lemburg.com>
Message-ID: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>

mal wrote:

> I've received the first round of notification message from the
> patch manager and can't really say that I like them. Ok, I 
> understand that the patch manager is still alpha or beta software,
> but these messages really don't have any usable content at all:
> 
> """
> Patch #100646 has been updated. 
> Visit SourceForge.net for more info.
> 
> http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470
> """
> 
> Also, reviewing the patches has become a pain and discussing them
> is nearly impossible (I don't consider the slashdot like comment
> mechanism to be of any use: there's simply no audience for
> discussion).
> 
> Is there any chance of tee'ing patches from SF to the patches
> list or some other patch discussion and review forum ? I do
> understand that the mechanism can help with patch *checkins*,
> but it's certainly not going to help much with the discussion
> step needed before conidering any actions. The independent
> peer review principal doesn't work with this kind of setup.

I fully agree.

someone really needs to fuse the patch manager with roundup (that
we should use roundup for bug tracking goes without saying...)

how much work would it be to move the entire repository over to
pythonlabs, btw?  sourceforget is frustratingly slow...

</F>




From guido at beopen.com  Tue Jun 27 23:07:41 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:07:41 -0500
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names)
In-Reply-To: Your message of "Tue, 27 Jun 2000 09:57:38 MST."
             <20000627095738.D7257@activestate.com> 
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain>  
            <20000627095738.D7257@activestate.com> 
Message-ID: <200006272107.QAA04498@cj20424-a.reston1.va.home.com>

> I asked the question a while back if it would reasonable/useful/popular to
> have a mechanism where parts of the Python/C Api could be tested directly.
> 
> My proposal used an extension module _testmodule (although I made it a core
> module on UN*X it should not bog down the core) which exported a bunch o'
> test_* routines that tested specific parts of the Python/C API. A
> test_internal.py module would be added to the std regression test suite that
> would import this module and call each of the exported test_* routines in
> turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested.
> 
> Anybody have any opinions?
> 
> 
> Trent
> 
> p.s. I have a patch largely (all except the above menntion limitation) ready
> for this, including some tests that I used for my 64-bit porting stuff. 

Great idea.  Please wait for 1.7.  There *will* be releases after 1.6!

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



From guido at beopen.com  Tue Jun 27 23:08:42 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:08:42 -0500
Subject: [Python-Dev] semi-subtle atexit gotcha?
In-Reply-To: Your message of "Tue, 27 Jun 2000 12:11:33 EST."
             <14680.57413.385666.482385@beluga.mojam.com> 
References: <14680.57413.385666.482385@beluga.mojam.com> 
Message-ID: <200006272108.QAA04509@cj20424-a.reston1.va.home.com>

> In thinking about the new atexit module a little more, it occurred to me
> that I've handled the case where the atexit module gets loaded after another 
> module that wants to set sys.exitfunc (it just incorporates that function
> into its list of functions), but not if atexit gets loaded before another
> modules that uses sys.exitfunc.  I see two possible choices:
> 
>     1. Punt and put a bit of verbiage in the atexit section of the library
>        reference manual and the 1.6 release notes.
> 
>     2. Have atexit.register check each time it's called to see if
>        sys.exitfunc is what it expects.  This isn't a perfect solution for a 
>        couple reasons.  One, there's no guarantee that other sys.exitfunc- 
>        modifying code isn't executed after the last call to
>        atexit.register.  Two, there's no guarantee that the other code
>        doesn't attempt to be "intelligent" in a fashion similar to atexit
>        (can you say dueling banjos?).
> 
> I vote for option number one since there appears to be no guaranteed way to
> make it work, but I'm open to other suggestions.

Yes, #1 is good enough.  I don't think there will be lots of people
bitten by this...

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



From guido at beopen.com  Tue Jun 27 23:11:46 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:11:46 -0500
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Tue, 27 Jun 2000 10:16:58 MST."
             <20000627101658.E7257@activestate.com> 
References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>  
            <20000627101658.E7257@activestate.com> 
Message-ID: <200006272111.QAA04542@cj20424-a.reston1.va.home.com>

> What are the chances of getting other meta data fields on patches, i.e.
> changes to the patch manager? Categorizing patches could really help as a
> filter. For instance, I may be a Unicode genius and would like to see the
> patches associated with it.

Good idea.  The PM clearly needs work.  I see two places where you
could submit feature requests: (1) the "Report SF Bug" item in the
left side bar; (2) the "Feature Requests" discussion forum
(http://sourceforge.net/forum/forum.php?forum_id=4&et=0)

> I like the separation of python-dev and patches, but it is not a biggie for
> me.

For me it's just an annoyance, especially when cross-posting is used.

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



From guido at beopen.com  Tue Jun 27 23:36:57 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:36:57 -0500
Subject: [Python-Dev] python.org mail unclogged
Message-ID: <200006272136.QAA04723@cj20424-a.reston1.va.home.com>

It seems we've removed a major source of email cloggage on python.org
-- a site in France was hitting every page in the mailman membership
administration using a commercial crawler (Teleport Pro) that didn't
honor our robots.txt file, and forking a 4 Mb CGI script for each user
in each mailing list.  Thanks for Barry and Andrew!  This was on top
of problems caused when the Ultraseek crawler ran out of memory and
caused postfix or mailman to fail. :-(

Mail seems to be flowing again, the queues are emptying.  Once we're
happy, we'll turn on the Ultraseek crawler and search service.

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



From jeremy at beopen.com  Tue Jun 27 22:54:38 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 27 Jun 2000 16:54:38 -0400 (EDT)
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <Pine.SGI.3.96.1000627123233.621134G-100000@happy>
References: <3958D89E.39D084C8@lemburg.com>
	<Pine.SGI.3.96.1000627123233.621134G-100000@happy>
Message-ID: <14681.5262.464079.557095@bitdiddle.concentric.com>

Maybe the right solution is to work with the SourceForge maintainers
to make roundup part of the standard support software.  

jeremy



From fdrake at beopen.com  Tue Jun 27 23:01:54 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 27 Jun 2000 17:01:54 -0400 (EDT)
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <20000627101658.E7257@activestate.com>
References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>
	<20000627101658.E7257@activestate.com>
Message-ID: <14681.5698.732269.523890@cj42289-a.reston1.va.home.com>

Trent Mick writes:
 > Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the
 > person responsible for later taking to patch out of 'postponed' status.

  Agreed; assignment should be changed whenever the next person
required to deal with it changes.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From nascheme at enme.ucalgary.ca  Tue Jun 27 23:05:55 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Tue, 27 Jun 2000 15:05:55 -0600
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 27, 2000 at 10:06:30PM +0200
References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid>
Message-ID: <20000627150555.A3083@acs.ucalgary.ca>

On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote:
> how much work would it be to move the entire repository over to
> pythonlabs, btw?  sourceforget is frustratingly slow...

rsync access to the CVS repository would be nice too.  rsync
should be faster than "cvs update".  Also, once you have the
whole repository making diffs and checking out different versions
is much faster.

  Neil

-- 
"I saw `cout' being shifted "Hello world" times to the
left and stopped right there."  -- Steve Gonedes



From jeremy at beopen.com  Tue Jun 27 23:49:01 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 27 Jun 2000 17:49:01 -0400 (EDT)
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <20000627150555.A3083@acs.ucalgary.ca>
References: <3958D89E.39D084C8@lemburg.com>
	<007801bfe073$3008b0c0$f2a6b5d4@hagrid>
	<20000627150555.A3083@acs.ucalgary.ca>
Message-ID: <14681.8525.343786.194271@bitdiddle.concentric.com>

>>>>> "NS" == Neil Schemenauer <nascheme at enme.ucalgary.ca> writes:

  NS> On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote:
  >> how much work would it be to move the entire repository over to
  >> pythonlabs, btw?  sourceforget is frustratingly slow...

  NS> rsync access to the CVS repository would be nice too.  rsync
  NS> should be faster than "cvs update".  Also, once you have the
  NS> whole repository making diffs and checking out different
  NS> versions is much faster.

Absolutely!  OpenSSL works this way and I find it much more convenient
than using a remote CVS server.  I use commands like diff, log, and
annotate frequently during development.

Have you suggested that as a SourceForge feature?

Jeremy



From akuchlin at mems-exchange.org  Tue Jun 27 23:47:07 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 27 Jun 2000 17:47:07 -0400
Subject: [Python-Dev] Testdrive systems
Message-ID: <20000627174707.P19033@kronos.cnri.reston.va.us>

Portability-related note: I've just fixed a reported compilation
problem with the curses module on Tru64 Unix using a machine made
available by Compaq.  If you go to http://www.testdrive.compaq.com/,
you can sign up for a free 30-day account on a variety of machines:
Alphas running Tru64, FreeBSD, and Linux, and Intel machines running
BSD or Linux.  A nice way to fix reported problems quickly...  The
environment on the systems is a bit Spartan; emacs is there, but no
fancy shells and no CVS (which is especially annoying).

--amk



From nascheme at enme.ucalgary.ca  Wed Jun 28 00:56:09 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Tue, 27 Jun 2000 16:56:09 -0600
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <14681.8525.343786.194271@bitdiddle.concentric.com>; from jeremy@beopen.com on Tue, Jun 27, 2000 at 05:49:01PM -0400
References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <20000627150555.A3083@acs.ucalgary.ca> <14681.8525.343786.194271@bitdiddle.concentric.com>
Message-ID: <20000627165609.A3941@acs.ucalgary.ca>

On Tue, Jun 27, 2000 at 05:49:01PM -0400, Jeremy Hylton wrote:
> Have you suggested [rsync access to CVS] as a SourceForge feature?

Nope.  Be my guest. :)

  Neil



From tim_one at email.msn.com  Wed Jun 28 02:11:44 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Jun 2000 20:11:44 -0400
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <3958D89E.39D084C8@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEMBGGAA.tim_one@email.msn.com>

[MAL]
> [Please excuse my ranting... :-)]

No problem -- you're not complaining about *our* software <wink>.

> I've received the first round of notification message from the
> patch manager and can't really say that I like them. Ok, I
> understand that the patch manager is still alpha or beta software,
> but these messages really don't have any usable content at all:
>
> """
> Patch #100646 has been updated.
> Visit SourceForge.net for more info.
>
>
http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470
> """

I expect the title of the patch was also in the Subject line, yes?  And a
live link to the patch is certainly "usable".  I've found both those right
on target as I've been assigned or deassigned to patches so far, although
I'd sure like to see something in the body saying exactly *what* about the
patch "has been updated".

Not saying I think it's good enough, am saying it's (barely) a start.

> Also, reviewing the patches has become a pain

I don't understand that, in that the text of the patch is what you got
before, and what you can get now.  Is your complaint here specifically that
patches don't show up in your mailbox by magic?  Or something else?

> and discussing them is nearly impossible (I don't consider the
> slashdot like comment mechanism to be of any use: there's simply
> no audience for discussion).

Wholly agreed there.  So use python-dev for discussions for now; I agree too
with Guido that the rampant but inconsistent x-posting between patches and
python-dev was part of the problem.

> Is there any chance of tee'ing patches from SF to the patches
> list or some other patch discussion and review forum ?

I expect you know as much about SF's possibilities as anyone <0.5 wink>:
don't know.  The SF docs are either non-existent or inadequate, far as I can
tell, and I believe I share a mistaken belief with Fred Drake that new
patches "should" *already* be showing up on the patches list.

> I do understand that the mechanism can help with patch *checkins*,

Yes, but not yet as much as it should (e.g., the default view of patches
lacks basic info like the patch current status, and there's apparently not
yet any way to define a different view).

> but it's certainly not going to help much with the discussion
> step needed before conidering any actions.

Python-Dev now, possibly roundup later.  OTOH, it's perfectly adequate for
tiny little principal-reviewer <-> submitter give-and-take; many patches are
really quite trivial.

> The independent peer review principal doesn't work with this
> kind of setup.

I think your view is warped on this one, as you've been in the extremely
favored position of pumping out crucial patches for a hot area.  Most other
peoples' patches have been flatly ignored for *months* now.  It's not
necessarily bad if other people get some attention now too <wink>.





From tim_one at email.msn.com  Wed Jun 28 02:11:52 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Jun 2000 20:11:52 -0400
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEMBGGAA.tim_one@email.msn.com>

[Fredrik Lundh]
> ...
> how much work would it be to move the entire repository over to
> pythonlabs, btw?

Impossibly more than we could make time for soon.

> sourceforget is frustratingly slow...

'Tis very erratic indeed.  It *can* be speedy, but that seems much more the
exception than the rule.





From pingster at ilm.com  Wed Jun 28 01:29:04 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Tue, 27 Jun 2000 16:29:04 -0700 (PDT)
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <200006272111.QAA04542@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.SGI.3.96.1000627144959.621134U-100000@happy>

Fredrik Lundh wrote:
> someone really needs to fuse the patch manager with roundup (that
> we should use roundup for bug tracking goes without saying...)

How sweet!  Why, thank you. :)

Trent Mick wrote:
> What are the chances of getting other meta data fields on patches, i.e.
> changes to the patch manager? Categorizing patches could really help as a
> filter. For instance, I may be a Unicode genius and would like to see the
> patches associated with it.

I agree that doing that kind of filtering is very useful.  I have
a discussion thingie (based on Roundup) at http://headspaces.com/.
(Also prototype -- very prototype.)  I hacked out the "status" and
"fixer" fields and added a "keywords" field.  Not much volume yet,
but i think it will work well.

Perhaps something like that for discussing patches?

Jeremy Hylton wrote:
> Maybe the right solution is to work with the SourceForge maintainers
> to make roundup part of the standard support software.  

Hmmm... maybe i should look into that after i've figured out how
super-Roundup is going to work.


-- ?!ng





From gward at python.net  Wed Jun 28 02:58:43 2000
From: gward at python.net (Greg Ward)
Date: Tue, 27 Jun 2000 20:58:43 -0400
Subject: [Python-Dev] DOS text files and CVS
Message-ID: <20000627205843.A1607@beelzebub>

Hi all --

can anyone enlighten me on the right way to check in DOS text files to a 
CVS repository?  I have Thomas Heller's C source for his simple
graphical installer for Python modules, and it should definitely be in
the Distutils CVS tree.  But I don't want to check it in if it'll screw
up line-endings for anyone.  Is there a Right Way to do this?

Thanks --

        Greg
-- 
Greg Ward - Linux nerd                                  gward at python.net
http://starship.python.net/~gward/
Just because you're paranoid doesn't mean they *aren't* out to get you.



From tim_one at email.msn.com  Wed Jun 28 03:13:54 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Jun 2000 21:13:54 -0400
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <017501bfe023$684fca40$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEMFGGAA.tim_one@email.msn.com>

[Fredrik Lundh]
> (tim? where's the second installment of your sourceforge vs.
> windows series?)

Waiting for you to finish SRE <wink>.  Seriously, I don't *need* to get
Windows checkin access for the imminent release, so I moved this down my
priority list.  I needed to move *something* down because finding a place to
live around here is both urgent & consuming much more time than I had
planned on (vacancy rate:  0%).  Windows vs SourceForge is still on my
plate, and I'm not giving up on it, just slipping it.

just-carrying-my-plans-between-the-bathroom-&-the-bed-is-
    invigorating-exercise-ly y'rs  - tim





From mhammond at skippinet.com.au  Wed Jun 28 03:18:44 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Jun 2000 11:18:44 +1000
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEMFGGAA.tim_one@email.msn.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEJECOAA.mhammond@skippinet.com.au>

> just-carrying-my-plans-between-the-bathroom-&-the-bed-is-
>     invigorating-exercise-ly y'rs  - tim

Your plans, or your pans?

I-knew-you-were-old-but-not-that-old-<wink>-ly,

Mark.




From tim_one at email.msn.com  Wed Jun 28 03:39:31 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Jun 2000 21:39:31 -0400
Subject: [Python-Dev] RE: [Distutils] DOS text files and CVS
In-Reply-To: <20000627205843.A1607@beelzebub>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMIGGAA.tim_one@email.msn.com>

[Greg Ward]
> can anyone enlighten me on the right way to check in DOS text files to a
> CVS repository?

Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe
you need to convince CVS that it's a binary (not text) file.  Then it will
skip line-end conversions.

not-a-solution-but-maybe-a-clue-ly y'rs  - tim





From gstein at lyra.org  Wed Jun 28 03:46:15 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 18:46:15 -0700
Subject: [Python-Dev] add Demo/imputil/importers.py ?
Message-ID: <20000627184615.A29590@lyra.org>

A while back, I pulled the "demo" importers out of imputil.py. I think those
should be added into Demo/imputil/.

It would also be Goodness to include JimA's zipimporter. Where would that go?

Cheers,
-g

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



From gmcm at hypernet.com  Wed Jun 28 03:47:30 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 27 Jun 2000 21:47:30 -0400
Subject: [Python-Dev] DOS text files and CVS
In-Reply-To: <20000627205843.A1607@beelzebub>
Message-ID: <1249965584-36289880@hypernet.com>

Greg Ward asks:

> can anyone enlighten me on the right way to check in DOS text
> files to a CVS repository?  I have Thomas Heller's C source for
> his simple graphical installer for Python modules, and it should
> definitely be in the Distutils CVS tree.  But I don't want to
> check it in if it'll screw up line-endings for anyone.  Is there
> a Right Way to do this?

Well, if you checked it in from a Windows box, CVS would 
translate line endings to native, then a Windows checkout 
would translate back to Windows endings.

So assuming you don't want to get your fingers dirty, give it 
*n*x line endings and check it in.

CVS does understand text, you know :-).

(And about the only Windows editor that barfs on *n*x line 
endings is Notepad.)


- Gordon



From arnold at dstc.monash.edu.au  Wed Jun 28 03:50:24 2000
From: arnold at dstc.monash.edu.au (David Arnold)
Date: Wed, 28 Jun 2000 11:50:24 +1000
Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS
In-Reply-To: Your message of "Tue, 27 Jun 2000 21:39:31 -0400."
             <LNBBLJKPBEHFEDALKOLCAEMIGGAA.tim_one@email.msn.com> 
Message-ID: <200006280150.LAA17759@xevious.dstc.monash.edu.au>

-->"Tim" == Tim Peters <tim_one at email.msn.com> writes:

  Tim> Aargh, I haven't used CVS in about 6 years ... somehow or
  Tim> other, I believe you need to convince CVS that it's a binary
  Tim> (not text) file.  Then it will skip line-end conversions.

cvs add -kb file

should work to add a binary file.  not sure that this is the best way
to deal with DOS files, but it should work ...



d



From amk1 at erols.com  Wed Jun 28 04:04:53 2000
From: amk1 at erols.com (A.M. Kuchling)
Date: Tue, 27 Jun 2000 22:04:53 -0400
Subject: [Python-Dev] Text about cycle GC
Message-ID: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>

I've written some text for the What's New article on the GCing of
cycles, but it wasn't a topic I paid close attention to at the time,
so I'd like corrections.  Here's what I've got; please send me
comments privately. 

                       6. Optional Collection of Cycles

   The C implementation of Python uses reference counting to implement
   garbage collection. Every Python object maintains a count of the
   number of references pointing to itself, and adjusts the count as
   references are created or destroyed. Once the reference count reaches
   zero, the object is no longer accessible, since you need to have a
   reference to an object to access it, and if the count is zero, no
   references exist any longer.

   Reference counting has some pleasant properties: it's easy to
   understand and implement, and the resulting implementation is
   portable, fairly fast, and reacts well with other libraries that
   implement their own memory handling schemes. The major problem with
   reference counting is that it sometimes doesn't realise that objects
   are no longer accessible, resulting in a memory leak. This happens
   when there are cycles of references.

   Consider the simplest possible cycle, a class instance which has a
   reference to itself:

instance = SomeClass()
instance.myself = instance

   After the above two lines of code have been executed, the reference
   count of instance is 2; one reference is from the variable named
   "'instance'", and the other is from the "myself"attribute of the
   instance.

   If the next line of code is del instance, what happens? The reference
   count of instance is decreased by 1, so it has a reference count of 1;
   the reference in the "myself" attribute still exists. Yet the instance
   is no longer accessible through Python code, and it could be deleted.
   Several objects can participate in a cycle if they have references to
   each other, causing all of the objects to be leaked.

   An experimental step has been made toward fixing this problem. When
   compiling Python, the -with-cycle-gc (XXX correct option flag?) option
   can be specified. This causes a cycle detection algorithm to be
   periodically executed, which looks for inaccessible cycles and deletes
   the objects involved.

   Why isn't this enabled by default? Running the cycle detection
   algorithm takes some time, and some tuning will be required to
   minimize the overhead cost. It's not yet obvious how much performance
   is lost, because benchmarking this is tricky and depends sensitively
   on how often the program creates and destroys objects. XXX is this
   actually the correct reason? Or is it fear of breaking software that
   runs happily while leaving garbage?

   Several people worked on this problem. Early versions were written by
   XXX1, XXX2. (I vaguely remember several people writing first cuts at
   this. Anyone recall who?) The implementation that's in Python 1.6 is a
   rewritten version, this time done by Neil Schemenauer. Lots of other
   people offered suggestions along the way, such as (in alphabetical
   order) Marc-Andr? Lemburg, Tim Peters, Greg Stein, Eric Tiedemann. 
   (XXX other names?  If you feel you should be added, e-mail me).  The
   March 2000 archives of the python-dev mailing list contain most of the
   relevant discussion, especially in the threads titled ``Reference
   cycle collection for Python'' and ``Finalization again''.




From ians at amc.com  Wed Jun 28 03:51:45 2000
From: ians at amc.com (Ian Searle)
Date: Tue, 27 Jun 2000 18:51:45 -0700
Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS
References: <LNBBLJKPBEHFEDALKOLCAEMIGGAA.tim_one@email.msn.com>
Message-ID: <39595A31.6462CA42@amc.com>

The best way to check DOS text files into CVS is from a Windows/DOS
machine using the CVS client/pserver route.  Using this method, the
files are stored in canonical format.  When someone checks them out from
a Unix client they get /n only.  And, when someone checks them out from
a Windows/DOS client, they get /r/n.  And, everyone is happy (well, as
much as can be expected :-)  

If you do a 'cvs add -kb foo.dos-txt' then CVS will treat the file as
binary and forego the keyword substitutions and end of line
translations.  But, folks checking them out will always get the /r/n
regardless of platform.

-Ian

Tim Peters wrote:
> 
> [Greg Ward]
> > can anyone enlighten me on the right way to check in DOS text files to a
> > CVS repository?
> 
> Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe
> you need to convince CVS that it's a binary (not text) file.  Then it will
> skip line-end conversions.
> 
> not-a-solution-but-maybe-a-clue-ly y'rs  - tim
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://www.python.org/mailman/listinfo/distutils-sig



From akuchlin at cnri.reston.va.us  Wed Jun 28 04:04:15 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Tue, 27 Jun 2000 22:04:15 -0400
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <20000627184615.A29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 06:46:15PM -0700
References: <20000627184615.A29590@lyra.org>
Message-ID: <20000627220415.A22246@newcnri.cnri.reston.va.us>

On Tue, Jun 27, 2000 at 06:46:15PM -0700, Greg Stein wrote:
>A while back, I pulled the "demo" importers out of imputil.py. I think those
>should be added into Demo/imputil/.

While on the subject of adding demo directories, I'd like to add a
Demo/curses directory.  (Not going to happen until after b1, though;
cute little demos aren't a high priority at the moment.)

--amk



From bwarsaw at beopen.com  Wed Jun 28 04:25:47 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 27 Jun 2000 22:25:47 -0400 (EDT)
Subject: [Python-Dev] DOS text files and CVS
References: <20000627205843.A1607@beelzebub>
Message-ID: <14681.25131.166235.152210@anthem.concentric.net>

>>>>> "GW" == Greg Ward <gward at python.net> writes:

    GW> can anyone enlighten me on the right way to check in DOS text
    GW> files to a CVS repository?  I have Thomas Heller's C source
    GW> for his simple graphical installer for Python modules, and it
    GW> should definitely be in the Distutils CVS tree.  But I don't
    GW> want to check it in if it'll screw up line-endings for anyone.
    GW> Is there a Right Way to do this?

If there's no reason why it /has/ to be DOS text, convert it to Unix
line endings first.  XEmacs will even do the conversion for you!  That
is, if the other suggestions people have made don't help.

-Barry



From skip at mojam.com  Wed Jun 28 04:51:03 2000
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 27 Jun 2000 21:51:03 -0500 (CDT)
Subject: [Python-Dev] readline history read/write
Message-ID: <14681.26647.228866.236111@beluga.mojam.com>


The original thing that motivated me to propose what became atexit.py was my 
desire to read and write readline history files.  The two attached context
diffs patch Modules/readline.c and Lib/rlcompleter.py to do that.  Two new
functions are added to the readline module and rlcompleter is tweaked to
read the history file referenced by the PYTHONHISTORY environment variable
(if it's defined) and automatically save it when the interpreter exits.

I'm looking for a little feedback.  Here are a few things that jumped to my
mind:

    1. Is it okay to add the read and register/write code to rlcompleter.py?
       Reading and writing readline history files doesn't have anything
       directly to do with identifier completion, but they both have to do
       with readline.

    2. Assuming that history file read/write is desired, should it be
       predicated on the presence of an environment variable or (as in bash
       and other readline-aware programs) should it just happen?

    3. Am I correct in assuming that this capability will only be available
       to Unix/Linux environments, or is readline generally available, thus
       forcing me to think about cross-platform issues?

    4. Is there some mechanism already present in IDLE and/or PythonWin I
       should be aware of and try to emulate?

The two context diffs are both short.  You should be able to follow
everything just by reading the bits of code.  Offering your thoughts on the
above questions shouldn't require actually modifying your interpreter.

Thx,

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: readline.dif
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000627/c023ec0e/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rlcompleter.dif
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000627/c023ec0e/attachment.asc>

From gstein at lyra.org  Wed Jun 28 05:08:46 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 20:08:46 -0700
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEMBGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 08:11:52PM -0400
References: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEMBGGAA.tim_one@email.msn.com>
Message-ID: <20000627200846.D29590@lyra.org>

On Tue, Jun 27, 2000 at 08:11:52PM -0400, Tim Peters wrote:
> [Fredrik Lundh]
> > ...
> > how much work would it be to move the entire repository over to
> > pythonlabs, btw?
> 
> Impossibly more than we could make time for soon.
> 
> > sourceforget is frustratingly slow...
> 
> 'Tis very erratic indeed.  It *can* be speedy, but that seems much more the
> exception than the rule.

hehe... I have 30ms pings and have observed multiple Mb/sec :-)

download.sourceforge.net is excellent given those stats...

Of course, I'm practically just down the street.

Cheers,
-g

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



From tim_one at email.msn.com  Wed Jun 28 05:13:52 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Jun 2000 23:13:52 -0400
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <20000627200846.D29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>

[Greg Stein]
> hehe... I have 30ms pings and have observed multiple Mb/sec :-)
>
> download.sourceforge.net is excellent given those stats...
>
> Of course, I'm practically just down the street.

Would please send me the Python script you use to configure Win98 so that I
can get multiple Mb/sec too?  Thanks in advance.  I always *knew* there was
a secret way to boost these 56K laptop modems <wink>.

keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's-
    basement-ly y'rs  - tim





From gstein at lyra.org  Wed Jun 28 05:25:31 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 20:25:31 -0700
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 11:13:52PM -0400
References: <20000627200846.D29590@lyra.org> <LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>
Message-ID: <20000627202531.G29590@lyra.org>

On Tue, Jun 27, 2000 at 11:13:52PM -0400, Tim Peters wrote:
> [Greg Stein]
> > hehe... I have 30ms pings and have observed multiple Mb/sec :-)
> >
> > download.sourceforge.net is excellent given those stats...
> >
> > Of course, I'm practically just down the street.
> 
> Would please send me the Python script you use to configure Win98 so that I
> can get multiple Mb/sec too?  Thanks in advance.  I always *knew* there was
> a secret way to boost these 56K laptop modems <wink>.

DSL big boy! DSL!

And I use a real OS :-)

> keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's-
>     basement-ly y'rs  - tim

eek!

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



From tim_one at email.msn.com  Wed Jun 28 06:11:22 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 00:11:22 -0400
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBCEJECOAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCGENEGGAA.tim_one@email.msn.com>

>> just-carrying-my-plans-between-the-bathroom-&-the-bed-is-
>>     invigorating-exercise-ly y'rs  - tim

[Mark Hammond]
> Your plans, or your pans?
>
> I-knew-you-were-old-but-not-that-old-<wink>-ly,

My pans are in storage somewhere in Baltimore, so I can't report on their
possible growth.  Or is this an Australian thing <wink>?

put-another-pan-on-the-barbie-mate?-ly y'rs  - tim


PS:  My testicles *have* grown since I moved to VA!  I'm wondering whether
it's an early symptom of Lyme disease.  They're still easy to carry from
room to room, though, provided simply I'm careful not to trip over them.





From bwarsaw at beopen.com  Wed Jun 28 06:13:32 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 00:13:32 -0400 (EDT)
Subject: [Python-Dev] SF patch manager...
References: <20000627200846.D29590@lyra.org>
	<LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>
Message-ID: <14681.31596.221693.491788@anthem.concentric.net>

>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:

    TP> keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's-
    TP> basement-ly y'rs - tim

Say the word, send me some hardware, and I'll clear a space between
the drums, bass rig, and litter boxes.

cover-it-in-sisal-and-even-the-cats'll-be-happy-ly y'rs,
-Barry



From tim_one at email.msn.com  Wed Jun 28 07:04:36 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 01:04:36 -0400
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <20000627095738.D7257@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMENGGGAA.tim_one@email.msn.com>

[Trent Mick]
> I asked the question a while back if it would reasonable/useful/popular
> to have a mechanism where parts of the Python/C Api could be tested
> directly.

Not only reasonable, IMO it's essential.  "If it's not tested, it's broken."
Tattoo that on your neighbor's forehead so it's always in mind <wink>.
Every time we get a legit bug report on Python, I view it as a failure of
the test suite.  That's one of the things I hope to spend a lot of time on
(but have not been promised I can spend any time on -- aren't startups great
<wink>?).

> My proposal used an extension module _testmodule (although I made
> it a core module on UN*X it should not bog down the core) which exported
> a bunch o' test_* routines that tested specific parts of the Python/C
> API. A test_internal.py module would be added to the std regression test
> suite that would import this module and call each of the exported test_*
> routines in turn. This would allow things like the _GetAttr/_SetAttr
> behaviour to be tested.
>
> Anybody have any opinions?

Great start!  But the people who most need to take this seriously (including
but not limited to me) have no bandwidth to spare before 1.6 is out the
door.

focus!-it's-not-just-for-breakfast-anymore-ly y'rs  - tim





From DavidA at ActiveState.com  Wed Jun 28 07:33:37 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 27 Jun 2000 22:33:37 -0700
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMENGGGAA.tim_one@email.msn.com>
Message-ID: <LMBBIEIJKMPMLBONJMFCOEKFCJAA.DavidA@ActiveState.com>

> [Trent Mick]
> > I asked the question a while back if it would reasonable/useful/popular
> > to have a mechanism where parts of the Python/C Api could be tested
> > directly.
>
> Not only reasonable, IMO it's essential.  "If it's not tested,
> it's broken." Tattoo that on your neighbor's forehead so it's always in
mind <wink>.

Stay _off_ my forehead, thank you very much.  My hairline is receding enough
without ink stains killing off hair follicles.

Besides, I like my lobster-colored forehead just fine.

--da




From tim_one at email.msn.com  Wed Jun 28 08:23:38 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 02:23:38 -0400
Subject: [Python-Dev] C# (new language from Microsoft)
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBGEIBCOAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENKGGAA.tim_one@email.msn.com>

[Mark Hammond]
> ...
> * Python has a very good and interesting story in all this - there is no
> need to be alarmed.  If anything, be excited :-)

I was never worried about Python, but I lay awake at night worrying about
MS -- I'm still an MS shareholder, so don't screw this up <wink>.

every-new-c#-programmer-is-a-potential-python-convert-ly y'rs  - tim





From tim_one at email.msn.com  Wed Jun 28 08:23:40 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 02:23:40 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>

[Guido van Rossum]
> ...
> The address for New Bugs is currently set to guido at beopen.com.  I
> suppose I should set it to pythoneers at beopen.com or even to
> python-dev at python.org?

Since we (PythonLabs, last week) decided to continue using Jitterbug (on
python.org) for now, should the SF Bug Manager even be enabled?  If it is
enabled, and we are using Jitterbug, then someone has to own reentering SF
bugs into the Jitterbug system.

obviously y'rs  - tim





From gstein at lyra.org  Wed Jun 28 08:47:06 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 23:47:06 -0700
Subject: [Python-Dev] C# (new language from Microsoft)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCENKGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 02:23:38AM -0400
References: <ECEPKNMJLHAPFFJHDOJBGEIBCOAA.mhammond@skippinet.com.au> <LNBBLJKPBEHFEDALKOLCCENKGGAA.tim_one@email.msn.com>
Message-ID: <20000627234706.N29590@lyra.org>

On Wed, Jun 28, 2000 at 02:23:38AM -0400, Tim Peters wrote:
> [Mark Hammond]
> > ...
> > * Python has a very good and interesting story in all this - there is no
> > need to be alarmed.  If anything, be excited :-)
> 
> I was never worried about Python, but I lay awake at night worrying about
> MS -- I'm still an MS shareholder, so don't screw this up <wink>.

I'm an MS shareholder, too.

Oh. Wait. Did I say I was involved? Don't think so...

ahem.

-g

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



From andy at reportlab.com  Wed Jun 28 09:03:07 2000
From: andy at reportlab.com (Andy Robinson)
Date: Wed, 28 Jun 2000 08:03:07 +0100
Subject: [Python-Dev] SourceForge win32 HOWTO
Message-ID: <PGECLPOBGNBNKHNAGIJHCEPDCCAA.andy@reportlab.com>

Sorry, I've been offline and missed this thread.  I could have saved you
some time. These are the instructions we've used at ReportLab to work with
SourceForge on Win32.  No problems so far despite several Unix and CVS
newbies, myself included.    They are adapted from an article by Jay Andrew
Kay somewhere on Sourceforge and are generic rather than specific to the
Python source.

I have used the ReportLab project and my user name as an example but I'm
sure you guys can adapt that....

1. Get ftp.reportlab.com/tools/cvs-1.10-win.zip and
ftp.reportlab.com/tools/ssh-1.2.14-win32bin.zip

(copied from somewhere obscure for safety, I forget where)

2. Unzip these to a location on your path.  Type 'cvs'
or 'shh' from somewhere else to verify.

3. Choose where to keep your CVS projects; let's assume
C:\code

4. Create a subdirectory c:\code\.ssh  (yes, dot-ssh)

5. Create two environment variables:
	HOME=C:\CODE
	CVS_RSH=SSH
On Win9x, this can be done in a batch file or autoexec.bat;
on NT or 2000, go to Control Panel | System | Environment
and set them at either user or machine level.
The first must point to the directory above your .ssh directory.

6. If not done so, get a Sourceforge account and a project
you can log in to.

7. Test SSH independently by doing
	SSH -l username myproject.sourceforge.net
It should prompt for a password, then tell you that
"myproject.sourceforge.net" is added to the list of known hosts;
then give you a shell.

8. You will need either a lengthy command line or a batch file
for each sourceforge project.  I set cvsroot in a batch file
in my 'c:\code' directory, and have one such file for each
CVS project I use (about ten of them!):

------cvsreportlab.bat--------------
set HOME=C:\CODE
set CVS_RSH=SSH
set CVSROOT=:ext:my_user_name at cvs.myproject.sourceforge.net:/cvsroot/dirname
---------------------------------------
'dirname' is the top level directory in the CVS tree; a project can have
several, but usually there is just one.

9. execute this batch file.  You can now go to C:\Code and do
	cvs -z7 checkout myproject
(z7 means 'compress network traffic', handy over dialup lines)

10. From now on, just use CVS normally.  I wouldn't survive without
Karl Fogel's book "Open Source Development with CVS", Coriolis Press.

Footnote: for anonymous checkout, I think you just omit
the 'my_user_name@' part from the CVSROOT variable.

I hope this helps; let me know if people have any problems
with the instructions.

-
Andy Robinson
ReportLab




From andy at robanal.demon.co.uk  Wed Jun 28 09:03:08 2000
From: andy at robanal.demon.co.uk (Andy Robinson)
Date: Wed, 28 Jun 2000 08:03:08 +0100
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <20000628025304.BB64A1CE0D@dinsdale.python.org>
Message-ID: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>

I missed all the SourceForge discussions, but ReportLab have been running
all our development on SourceForge for five months and I'd like to share
some concerns.

First, we all use command line CVS, mostly from Windows; I just posted our
setup instructions.  It works fine but a bit slowly.

I find the web interface totally unusable from IE5 and Netscape 4.XX,
working over 64k lines or dialup lines.  Once one logs in via SSL, only
about one click in five ever returns a sensible page, and most just time out
and give an error message.  Many other people on the reportlab-users list
and my team report similar problems.   On the other hand, many are
incredulous and say they have never had a problem.  I found no complaints on
the SF discussion groups, but as far as I can tell hardly anyone uses them.
It seems to be better over big corporate connections.  I don't think it is
because I am in Europe; we never have trouble with our US ISPs.

As a result of this, we have not used the wonderful looking bug tracking,
to-do-list, patch manager etc.

How many people here have actually created accounts for themselves on
SourceForge and tried to do stuff when logged in - raise bugs and so on?
Did it work for you?  We ought to get a few data points before making this
the way Python is managed.

- Andy Robinson






From nhodgson at bigpond.net.au  Wed Jun 28 09:23:52 2000
From: nhodgson at bigpond.net.au (Neil Hodgson)
Date: Wed, 28 Jun 2000 17:23:52 +1000
Subject: [Python-Dev] Sourceforge Interface Concerns
References: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <002401bfe0d1$d05a9fd0$e3cb8490@neil>

> How many people here have actually created accounts for themselves on
> SourceForge and tried to do stuff when logged in - raise bugs and so on?
> Did it work for you?  We ought to get a few data points before making this
> the way Python is managed.

   Its generally quite good for me now that I've upgraded from a modem to a
cable connection although there are brown-out periods. The only web browser
I have any success with is Navigator 4.6 and 4.7. Both IE and Mozilla give
poor results with SSL login. As far as getting other people to use the bug
logger, its been a complete failure. Its much easier to email me or the
mailing list.

   Some parts of SourceForge such as the file release upload are quite
poorly designed and are too unpleasant to use on a slow connection if you
have several packages for each release.

   Neil





From tim_one at email.msn.com  Wed Jun 28 09:28:10 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 03:28:10 -0400
Subject: [Python-Dev] SourceForge win32 HOWTO
In-Reply-To: <PGECLPOBGNBNKHNAGIJHCEPDCCAA.andy@reportlab.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENOGGAA.tim_one@email.msn.com>

[Andy Robinson]
> Sorry, I've been offline and missed this thread.  I could have saved you
> some time. These are the instructions we've used at ReportLab to work with
> SourceForge on Win32.  No problems so far despite several Unix and CVS
> newbies, myself included. ...

Thanks, Andy!  I just *knew* that if I sat on my ass, someone would solve
this one for me <wink>.  I'll give these instructions a try, and also see
what it takes to adapt them to wincvs.  Note that I'm going to be putting
similar (perhaps, by an amazing coincidence, even identical) instructions up
on pythonlabs.com, so if you want to stop maintaining this, dump it on me.





From tim_one at email.msn.com  Wed Jun 28 09:28:26 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 03:28:26 -0400
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENOGGAA.tim_one@email.msn.com>

[Andy Robinson]
> ...
> I find the web interface totally unusable from IE5 and Netscape 4.XX,
> working over 64k lines or dialup lines.  Once one logs in via SSL, only
> about one click in five ever returns a sensible page, and most
> just time out and give an error message.  Many other people on the
> reportlab-users list and my team report similar problems.   On the other
> hand, many are incredulous and say they have never had a problem.
> I found no complaints on the SF discussion groups, but as far as I can
> tell hardly anyone uses them.   It seems to be better over big corporate
> connections.  I don't think it is because I am in Europe; we never have
> trouble with our US ISPs.

I'm in the middle:  sometimes it works great, sometimes slow as molasses
(IE5 via 56K modem on the other side of the country), and an error each one
of two clicks.  Greg Stein lives near it, and reports wonderful access via
DSL.

> As a result of this, we have not used the wonderful looking bug tracking,
> to-do-list, patch manager etc.

They're actually pretty feeble.

> How many people here have actually created accounts for themselves on
> SourceForge and tried to do stuff when logged in - raise bugs and so on?
> Did it work for you?  We ought to get a few data points before making this
> the way Python is managed.

We're not using the bug tracker, task list, news, forum or support managers.
Just the CVS tree and the patch manager.  There are particular reasons for
using those particular two, and I doubt we'll be moving more there until SF
gets better.  OTOH, we're also interested in *helping* SF get better!  SF is
as much an Open Source project as Python, and it could become an incredible
resource for the entire OS community.

doesn't-mean-i-won't-gripe-too-though-ly y'rs  - tim





From gstein at lyra.org  Wed Jun 28 10:04:07 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 01:04:07 -0700
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCENOGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 03:28:26AM -0400
References: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk> <LNBBLJKPBEHFEDALKOLCCENOGGAA.tim_one@email.msn.com>
Message-ID: <20000628010407.T29590@lyra.org>

On Wed, Jun 28, 2000 at 03:28:26AM -0400, Tim Peters wrote:
>...
> We're not using the bug tracker, task list, news, forum or support managers.
> Just the CVS tree and the patch manager.  There are particular reasons for
> using those particular two, and I doubt we'll be moving more there until SF
> gets better.  OTOH, we're also interested in *helping* SF get better!  SF is
> as much an Open Source project as Python, and it could become an incredible
> resource for the entire OS community.

This last statement is (unfortunately) not quite true. SourceForge is
developed in a closed, cathedral environment. There is no CVS access to it,
and all the developers work at VA Linux. Strictly speaking, the *output* of
this closed development is GPL'd. But it isn't what you would expect.

The documentation for SF is separate. Apparently, there was an independent
effort to help do some documentation and they got a good ways. Then the VA
guys suddenly popped out the "SFDocs" project, ignoring the work from the
other people. Not sure where I read that, so I can't provide a reference to
the stories/threads :-(

btw, there is a survey about SF that you can fill out:
  http://sourceforge.net/survey/survey.php?group_id=1&survey_id=10599

Cheers,
-g

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



From mal at lemburg.com  Wed Jun 28 10:03:00 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Jun 2000 10:03:00 +0200
Subject: [Python-Dev] SF patch manager...
References: <LNBBLJKPBEHFEDALKOLCIEMBGGAA.tim_one@email.msn.com>
Message-ID: <3959B134.1538B4B7@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > [Please excuse my ranting... :-)]
> 
> No problem -- you're not complaining about *our* software <wink>.
> 
> > I've received the first round of notification message from the
> > patch manager and can't really say that I like them. Ok, I
> > understand that the patch manager is still alpha or beta software,
> > but these messages really don't have any usable content at all:
> >
> > """
> > Patch #100646 has been updated.
> > Visit SourceForge.net for more info.
> >
> >
> http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470
> > """
> 
> I expect the title of the patch was also in the Subject line, yes? 

Right, but that's just about all the information you get:
the title, the fact that something changed and a link to the
patch page.

> And a
> live link to the patch is certainly "usable".  I've found both those right
> on target as I've been assigned or deassigned to patches so far, although
> I'd sure like to see something in the body saying exactly *what* about the
> patch "has been updated".
> 
> Not saying I think it's good enough, am saying it's (barely) a start.

True and I don't want to put this down. The only reason for
my ranting is that I'd rather get more infos in mail than
via some link to a page. Discussing patches via quoting email
is just so much more convenient -- opening two or three 
browsers to get at the hard facts isn't and, as others have
already noted, is rather slow too.
 
> > Also, reviewing the patches has become a pain
> 
> I don't understand that, in that the text of the patch is what you got
> before, and what you can get now.  Is your complaint here specifically that
> patches don't show up in your mailbox by magic?  Or something else?

I would very much prefer to get the patches or changes
appended to the update messages (much like was manually done
on patches at python.org). That way I can read the patch and
then reply to the sender and the list community from within
the mail application -- without copy&paste, looking up
email addresses in SF etc.
 
> > and discussing them is nearly impossible (I don't consider the
> > slashdot like comment mechanism to be of any use: there's simply
> > no audience for discussion).
> 
> Wholly agreed there.  So use python-dev for discussions for now; I agree too
> with Guido that the rampant but inconsistent x-posting between patches and
> python-dev was part of the problem.
>
> > Is there any chance of tee'ing patches from SF to the patches
> > list or some other patch discussion and review forum ?
> 
> I expect you know as much about SF's possibilities as anyone <0.5 wink>:
> don't know.  The SF docs are either non-existent or inadequate, far as I can
> tell, and I believe I share a mistaken belief with Fred Drake that new
> patches "should" *already* be showing up on the patches list.

They are showing up there... at least new ones are. Discussions
(via posting comments on the patch page) are not relayed to the
list though: only the comment authors get an email.
 
> > I do understand that the mechanism can help with patch *checkins*,
> 
> Yes, but not yet as much as it should (e.g., the default view of patches
> lacks basic info like the patch current status, and there's apparently not
> yet any way to define a different view).
> 
> > but it's certainly not going to help much with the discussion
> > step needed before conidering any actions.
> 
> Python-Dev now, possibly roundup later.  OTOH, it's perfectly adequate for
> tiny little principal-reviewer <-> submitter give-and-take; many patches are
> really quite trivial.

True, but even small patches occasionally need peer review from 
more people than just the assigned developer.
 
> > The independent peer review principal doesn't work with this
> > kind of setup.
> 
> I think your view is warped on this one, as you've been in the extremely
> favored position of pumping out crucial patches for a hot area.  Most other
> peoples' patches have been flatly ignored for *months* now.  It's not
> necessarily bad if other people get some attention now too <wink>.

Oops, did it shine through that much ? ;-)

Seriously, I would like to see a processing speedup too, it's
just the workflow that bothers me a bit.

BTW, another great feature for the patch manager would be
a button to perform the actual checkin via the web interface.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From rob at hooft.net  Wed Jun 28 11:27:18 2000
From: rob at hooft.net (Rob W. W. Hooft)
Date: Wed, 28 Jun 2000 11:27:18 +0200 (CEST)
Subject: [Python-Dev] Typo's
Message-ID: <14681.50422.966321.780406@temoleh.chem.uu.nl>

I located some typo's in the CVS. Here is a patch.

Warning: I'm a non-native English speaker. Please verify fixes.

Rob

Index: Demo/pdist/rcslib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Demo/pdist/rcslib.py,v
retrieving revision 1.6
diff -u -r1.6 rcslib.py
--- Demo/pdist/rcslib.py	1998/09/14 16:43:57	1.6
+++ Demo/pdist/rcslib.py	2000/06/28 07:42:50
@@ -296,7 +296,7 @@
     def _system(self, cmd):
         """INTERNAL: run COMMAND in a subshell.
 
-        Standard input for the command is taken fron /dev/null.
+        Standard input for the command is taken from /dev/null.
 
         Raise IOError when the exit status is not zero.
 
Index: Demo/sgi/video/Vcopy.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vcopy.py,v
retrieving revision 1.7
diff -u -r1.7 Vcopy.py
--- Demo/sgi/video/Vcopy.py	1996/11/27 19:50:07	1.7
+++ Demo/sgi/video/Vcopy.py	2000/06/28 07:42:50
@@ -8,7 +8,7 @@
 # - Manipulate the time base:
 #   = resample at a fixed rate
 #   = divide the time codes by a speed factor (to make it go faster/slower)
-#   = drop frames that are less than n msec apart (to accomodate slow players)
+#   = drop frames that are less than n msec apart (to accommodate slow players)
 # - Convert to a different format
 # - Magnify (scale) the image
 
Index: Demo/sgi/video/Vtime.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vtime.py,v
retrieving revision 1.4
diff -u -r1.4 Vtime.py
--- Demo/sgi/video/Vtime.py	1996/11/27 19:50:28	1.4
+++ Demo/sgi/video/Vtime.py	2000/06/28 07:42:50
@@ -7,7 +7,7 @@
 #
 # - resample at a fixed rate
 # - divide the time codes by a speed factor (to make it go faster/slower)
-# - drop frames that are less than n msec apart (to accomodate slow players)
+# - drop frames that are less than n msec apart (to accommodate slow players)
 
 
 # Usage:
Index: Lib/Queue.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/Queue.py,v
retrieving revision 1.10
diff -u -r1.10 Queue.py
--- Lib/Queue.py	2000/02/02 15:10:14	1.10
+++ Lib/Queue.py	2000/06/28 07:42:51
@@ -119,7 +119,7 @@
     def _qsize(self):
         return len(self.queue)
 
-    # Check wheter the queue is empty
+    # Check whether the queue is empty
     def _empty(self):
         return not self.queue
 
Index: Lib/binhex.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/binhex.py,v
retrieving revision 1.12
diff -u -r1.12 binhex.py
--- Lib/binhex.py	2000/02/04 15:39:29	1.12
+++ Lib/binhex.py	2000/06/28 07:42:51
@@ -13,7 +13,7 @@
 # XXXX Note: currently, textfiles appear in mac-form on all platforms.
 # We seem to lack a simple character-translate in python.
 # (we should probably use ISO-Latin-1 on all but the mac platform).
-# XXXX The simeple routines are too simple: they expect to hold the complete
+# XXXX The simple routines are too simple: they expect to hold the complete
 # files in-core. Should be fixed.
 # XXXX It would be nice to handle AppleDouble format on unix
 # (for servers serving macs).
@@ -48,7 +48,7 @@
     try:
         openrf = MacOS.openrf
     except AttributeError:
-        # Backward compatability
+        # Backward compatibility
         openrf = open
     
     def FInfo():
Index: Lib/calendar.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/calendar.py,v
retrieving revision 1.15
diff -u -r1.15 calendar.py
--- Lib/calendar.py	2000/02/02 15:10:14	1.15
+++ Lib/calendar.py	2000/06/28 07:42:51
@@ -1,6 +1,6 @@
 """Calendar printing functions"""
 
-# Revision 2: uses funtions from built-in time module
+# Revision 2: uses functions from built-in time module
 
 # Import functions and variables from time module
 from time import localtime, mktime
Index: Lib/fnmatch.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/fnmatch.py,v
retrieving revision 1.7
diff -u -r1.7 fnmatch.py
--- Lib/fnmatch.py	1997/10/22 20:57:40	1.7
+++ Lib/fnmatch.py	2000/06/28 07:42:51
@@ -36,7 +36,7 @@
 	return fnmatchcase(name, pat)
 
 def fnmatchcase(name, pat):
-	"""Test wheter FILENAME matches PATTERN, including case.
+	"""Test whether FILENAME matches PATTERN, including case.
 	
 	This is a version of fnmatch() which doesn't case-normalize
 	its arguments.
Index: Lib/locale.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/locale.py,v
retrieving revision 1.6
diff -u -r1.6 locale.py
--- Lib/locale.py	2000/06/08 17:49:41	1.6
+++ Lib/locale.py	2000/06/28 07:42:52
@@ -220,7 +220,7 @@
 
         The language code corresponds to RFC 1766.  code and encoding
         can be None in case the values cannot be determined or are
-        unkown to this implementation.
+        unknown to this implementation.
 
     """
     code = normalize(localename)
@@ -229,7 +229,7 @@
     elif code == 'C':
         return None, None
     else:
-        raise ValueError,'unkown locale: %s' % localename
+        raise ValueError,'unknown locale: %s' % localename
     return l
 
 def _build_localename(localetuple):
Index: Lib/posixpath.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/posixpath.py,v
retrieving revision 1.30
diff -u -r1.30 posixpath.py
--- Lib/posixpath.py	2000/02/29 13:31:16	1.30
+++ Lib/posixpath.py	2000/06/28 07:42:52
@@ -24,7 +24,7 @@
     return s
 
 
-# Return wheter a path is absolute.
+# Return whether a path is absolute.
 # Trivial in Posix, harder on the Mac or MS-DOS.
 
 def isabs(s):
@@ -304,7 +304,7 @@
 
 # Expand paths containing shell variable substitutions.
 # This expands the forms $variable and ${variable} only.
-# Non-existant variables are left unchanged.
+# Non-existent variables are left unchanged.
 
 _varprog = None
 
Index: Lib/sgmllib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/sgmllib.py,v
retrieving revision 1.19
diff -u -r1.19 sgmllib.py
--- Lib/sgmllib.py	2000/02/04 15:28:40	1.19
+++ Lib/sgmllib.py	2000/06/28 07:42:53
@@ -47,7 +47,7 @@
 # <foo> and </foo>, respectively, or do_foo to handle <foo> by itself.
 # (Tags are converted to lower case for this purpose.)  The data
 # between tags is passed to the parser by calling self.handle_data()
-# with some data as argument (the data may be split up in arbutrary
+# with some data as argument (the data may be split up in arbitrary
 # chunks).  Entity references are passed by calling
 # self.handle_entityref() with the entity reference as argument.
 
Index: Lib/site.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/site.py,v
retrieving revision 1.11
diff -u -r1.11 site.py
--- Lib/site.py	2000/06/07 09:12:09	1.11
+++ Lib/site.py	2000/06/28 07:42:53
@@ -122,7 +122,7 @@
 #
 # Set the string encoding used by the Unicode implementation to the
 # encoding used by the default locale of this system. If the default
-# encoding cannot be determined or is unkown, it defaults to 'ascii'.
+# encoding cannot be determined or is unknown, it defaults to 'ascii'.
 #
 def locale_aware_defaultencoding():
     import locale
Index: Lib/urllib2.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/urllib2.py,v
retrieving revision 1.3
diff -u -r1.3 urllib2.py
--- Lib/urllib2.py	2000/02/10 17:17:14	1.3
+++ Lib/urllib2.py	2000/06/28 07:42:54
@@ -141,7 +141,7 @@
     _opener = opener
 
 # do these error classes make sense?
-# make sure all of the IOError stuff is overriden.  we just want to be 
+# make sure all of the IOError stuff is overridden.  we just want to be 
  # subtypes.
 
 class URLError(IOError):
Index: Lib/xmllib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/xmllib.py,v
retrieving revision 1.18
diff -u -r1.18 xmllib.py
--- Lib/xmllib.py	2000/06/21 20:01:10	1.18
+++ Lib/xmllib.py	2000/06/28 07:42:54
@@ -79,7 +79,7 @@
 # special names to handle tags: start_foo and end_foo to handle <foo>
 # and </foo>, respectively.  The data between tags is passed to the
 # parser by calling self.handle_data() with some data as argument (the
-# data may be split up in arbutrary chunks).
+# data may be split up in arbitrary chunks).
 
 class XMLParser:
     attributes = {}                     # default, to be overridden
Index: Lib/distutils/cmd.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/cmd.py,v
retrieving revision 1.18
diff -u -r1.18 cmd.py
--- Lib/distutils/cmd.py	2000/06/08 00:02:36	1.18
+++ Lib/distutils/cmd.py	2000/06/28 07:42:55
@@ -323,7 +323,7 @@
         should be disabled by the "dry run" flag, and should announce
         themselves if the current verbosity level is high enough.  This
         method takes care of all that bureaucracy for you; all you have to
-        do is supply the funtion to call and an argument tuple for it (to
+        do is supply the function to call and an argument tuple for it (to
         embody the "external action" being performed), a message to print
         if the verbosity level is high enough, and an optional verbosity
         threshold.
Index: Lib/distutils/util.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/util.py,v
retrieving revision 1.37
diff -u -r1.37 util.py
--- Lib/distutils/util.py	2000/06/24 20:40:02	1.37
+++ Lib/distutils/util.py	2000/06/28 07:42:55
@@ -28,7 +28,7 @@
         return os.path.normpath(path)
 
 
-# More backwards compatability hacks
+# More backwards compatibility hacks
 def extend (list, new_list):
     """Appends the list 'new_list' to 'list', just like the 'extend()'
        list method does in Python 1.5.2 -- but this works on earlier
Index: Lib/distutils/version.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/version.py,v
retrieving revision 1.1
diff -u -r1.1 version.py
--- Lib/distutils/version.py	1998/12/18 22:00:30	1.1
+++ Lib/distutils/version.py	2000/06/28 07:42:55
@@ -207,7 +207,7 @@
 # provides enough benefit to be worth using, and will submit their
 # version numbering scheme to its domination.  The free-thinking
 # anarchists in the lot will never give in, though, and something needs
-# to be done to accomodate them.
+# to be done to accommodate them.
 # 
 # Perhaps a "moderately strict" version class could be implemented that
 # lets almost anything slide (syntactically), and makes some heuristic
Index: Lib/distutils/command/build_ext.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/build_ext.py,v
retrieving revision 1.51
diff -u -r1.51 build_ext.py
--- Lib/distutils/command/build_ext.py	2000/06/28 01:29:37	1.51
+++ Lib/distutils/command/build_ext.py	2000/06/28 07:42:56
@@ -1,7 +1,7 @@
 """distutils.command.build_ext
 
 Implements the Distutils 'build_ext' command, for building extension
-modules (currently limited to C extensions, should accomodate C++
+modules (currently limited to C extensions, should accommodate C++
 extensions ASAP)."""
 
 # created 1999/08/09, Greg Ward
@@ -385,7 +385,7 @@
             # Next, compile the source code to object files.
 
             # XXX not honouring 'define_macros' or 'undef_macros' -- the
-            # CCompiler API needs to change to accomodate this, and I
+            # CCompiler API needs to change to accommodate this, and I
             # want to do one thing at a time!
 
             # Two possible sources for extra compiler arguments:
Index: Lib/dos-8x3/posixpat.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/posixpat.py,v
retrieving revision 1.10
diff -u -r1.10 posixpat.py
--- Lib/dos-8x3/posixpat.py	2000/05/08 17:31:00	1.10
+++ Lib/dos-8x3/posixpat.py	2000/06/28 07:42:56
@@ -24,7 +24,7 @@
     return s
 
 
-# Return wheter a path is absolute.
+# Return whether a path is absolute.
 # Trivial in Posix, harder on the Mac or MS-DOS.
 
 def isabs(s):
@@ -304,7 +304,7 @@
 
 # Expand paths containing shell variable substitutions.
 # This expands the forms $variable and ${variable} only.
-# Non-existant variables are left unchanged.
+# Non-existent variables are left unchanged.
 
 _varprog = None
 
Index: Lib/dos-8x3/queue.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/queue.py,v
retrieving revision 1.7
diff -u -r1.7 queue.py
--- Lib/dos-8x3/queue.py	2000/05/08 17:31:00	1.7
+++ Lib/dos-8x3/queue.py	2000/06/28 07:42:56
@@ -119,7 +119,7 @@
     def _qsize(self):
         return len(self.queue)
 
-    # Check wheter the queue is empty
+    # Check whether the queue is empty
     def _empty(self):
         return not self.queue
 
Index: Lib/dos-8x3/test_win.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_win.py,v
retrieving revision 1.1
diff -u -r1.1 test_win.py
--- Lib/dos-8x3/test_win.py	2000/05/08 17:31:03	1.1
+++ Lib/dos-8x3/test_win.py	2000/06/28 07:42:57
@@ -115,7 +115,7 @@
     # Opening should now fail!
     try:
         key = OpenKey(root_key, test_key_name)
-        assert 0, "Could open the non-existant key"
+        assert 0, "Could open the non-existent key"
     except WindowsError: # Use this error name this time
         pass
 
Index: Lib/dos-8x3/test_zli.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_zli.py,v
retrieving revision 1.5
diff -u -r1.5 test_zli.py
--- Lib/dos-8x3/test_zli.py	2000/05/08 17:31:03	1.5
+++ Lib/dos-8x3/test_zli.py	2000/06/28 07:42:57
@@ -11,7 +11,7 @@
 buf = file.read() * 8
 file.close()
 
-# test the chucksums (hex so the test doesn't break on 64-bit machines)
+# test the checksums (hex so the test doesn't break on 64-bit machines)
 print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1))
 print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1))
 
Index: Lib/plat-irix5/CL_old.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/CL_old.py,v
retrieving revision 1.1
diff -u -r1.1 CL_old.py
--- Lib/plat-irix5/CL_old.py	1995/05/17 11:18:22	1.1
+++ Lib/plat-irix5/CL_old.py	2000/06/28 07:42:57
@@ -200,7 +200,7 @@
 BOTTOM_UP = 1
 
 #
-# SGI Proprietaty Algorithm Header Start Code
+# SGI Proprietary Algorithm Header Start Code
 #
 HEADER_START_CODE = 0xc1C0DEC
 
Index: Lib/plat-irix5/flp.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/flp.py,v
retrieving revision 1.17
diff -u -r1.17 flp.py
--- Lib/plat-irix5/flp.py	1998/03/26 20:22:58	1.17
+++ Lib/plat-irix5/flp.py	2000/06/28 07:42:57
@@ -203,7 +203,7 @@
     return datum[1]
 #
 # Internal: parse fd form, or skip if name doesn't match.
-# the special value None means 'allways parse it'.
+# the special value None means 'always parse it'.
 #
 def _parse_fd_form(file, name):
     datum = _parse_1_line(file)
@@ -222,7 +222,7 @@
     return None
 
 #
-# Internal class: a convient place to store object info fields
+# Internal class: a convenient place to store object info fields
 #
 class _newobj:
     def add(self, name, value):
Index: Lib/plat-irix5/panel.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/panel.py,v
retrieving revision 1.4
diff -u -r1.4 panel.py
--- Lib/plat-irix5/panel.py	1995/09/18 22:00:37	1.4
+++ Lib/plat-irix5/panel.py	2000/06/28 07:42:58
@@ -2,7 +2,7 @@
 #
 # Support for the Panel library.
 # Uses built-in module 'pnl'.
-# Applciations should use 'panel.function' instead of 'pnl.function';
+# Applications should use 'panel.function' instead of 'pnl.function';
 # most 'pnl' functions are transparently exported by 'panel',
 # but dopanel() is overridden and you have to use this version
 # if you want to use callbacks.
@@ -137,7 +137,7 @@
 					print 'assign failed:', stmt
 
 
-# Build a real actuator from an actuator descriptior.
+# Build a real actuator from an actuator description.
 # Return a pair (actuator, name).
 #
 def build_actuator(descr):
Index: Lib/plat-irix6/flp.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/flp.py,v
retrieving revision 1.4
diff -u -r1.4 flp.py
--- Lib/plat-irix6/flp.py	1998/03/26 20:23:01	1.4
+++ Lib/plat-irix6/flp.py	2000/06/28 07:42:58
@@ -203,7 +203,7 @@
     return datum[1]
 #
 # Internal: parse fd form, or skip if name doesn't match.
-# the special value None means 'allways parse it'.
+# the special value None means 'always parse it'.
 #
 def _parse_fd_form(file, name):
     datum = _parse_1_line(file)
@@ -222,7 +222,7 @@
     return None
 
 #
-# Internal class: a convient place to store object info fields
+# Internal class: a convenient place to store object info fields
 #
 class _newobj:
     def add(self, name, value):
Index: Lib/plat-irix6/panel.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/panel.py,v
retrieving revision 1.1
diff -u -r1.1 panel.py
--- Lib/plat-irix6/panel.py	1997/01/15 19:19:11	1.1
+++ Lib/plat-irix6/panel.py	2000/06/28 07:42:58
@@ -2,7 +2,7 @@
 #
 # Support for the Panel library.
 # Uses built-in module 'pnl'.
-# Applciations should use 'panel.function' instead of 'pnl.function';
+# Applications should use 'panel.function' instead of 'pnl.function';
 # most 'pnl' functions are transparently exported by 'panel',
 # but dopanel() is overridden and you have to use this version
 # if you want to use callbacks.
@@ -137,7 +137,7 @@
 					print 'assign failed:', stmt
 
 
-# Build a real actuator from an actuator descriptior.
+# Build a real actuator from an actuator description.
 # Return a pair (actuator, name).
 #
 def build_actuator(descr):
Index: Lib/test/test_al.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_al.py,v
retrieving revision 1.2
diff -u -r1.2 test_al.py
--- Lib/test/test_al.py	1998/03/26 19:41:38	1.2
+++ Lib/test/test_al.py	2000/06/28 07:42:58
@@ -8,7 +8,7 @@
 alattrs = ['__doc__', '__name__', 'getdefault', 'getminmax', 'getname', 'getparams',
            'newconfig', 'openport', 'queryparams', 'setparams']
 
-# This is a very inobstrusive test for the existance of the al module and all it's
+# This is a very inobtrusive test for the existence of the al module and all it's
 # attributes.  More comprehensive examples can be found in Demo/al
 
 def main():
Index: Lib/test/test_b1.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_b1.py,v
retrieving revision 1.22
diff -u -r1.22 test_b1.py
--- Lib/test/test_b1.py	2000/04/14 19:13:22	1.22
+++ Lib/test/test_b1.py	2000/06/28 07:42:58
@@ -270,7 +270,7 @@
 # Different base:
 if int("10",16) <> 16L: raise TestFailed, 'int("10",16)'
 if int(u"10",16) <> 16L: raise TestFailed, 'int(u"10",16)'
-# Test conversion fron strings and various anomalies
+# Test conversion from strings and various anomalies
 L = [
         ('0', 0),
         ('1', 1),
Index: Lib/test/test_cd.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cd.py,v
retrieving revision 1.2
diff -u -r1.2 test_cd.py
--- Lib/test/test_cd.py	1998/03/26 19:41:49	1.2
+++ Lib/test/test_cd.py	2000/06/28 07:42:58
@@ -10,7 +10,7 @@
            'ident', 'index', 'msftoframe', 'open', 'pnum', 'ptime']
 
 
-# This is a very inobstrusive test for the existance of the cd module and all it's
+# This is a very inobtrusive test for the existence of the cd module and all it's
 # attributes.  More comprehensive examples can be found in Demo/cd and
 # require that you have a CD and a CD ROM drive
 
Index: Lib/test/test_cl.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cl.py,v
retrieving revision 1.2
diff -u -r1.2 test_cl.py
--- Lib/test/test_cl.py	1998/03/26 19:41:52	1.2
+++ Lib/test/test_cl.py	2000/06/28 07:42:58
@@ -63,7 +63,7 @@
 'YUV422DC', 'YUV422HC', '__doc__', '__name__', 'cvt_type', 'error']
 
 
-# This is a very inobstrusive test for the existance of the cl
+# This is a very inobtrusive test for the existence of the cl
 # module and all it's attributes.
 
 def main():
Index: Lib/test/test_pwd.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_pwd.py,v
retrieving revision 1.5
diff -u -r1.5 test_pwd.py
--- Lib/test/test_pwd.py	1998/03/26 19:42:32	1.5
+++ Lib/test/test_pwd.py	2000/06/28 07:42:58
@@ -59,7 +59,7 @@
 else:
     print 'fakename', fakename, 'did not except pwd.getpwnam()'
 
-# Choose a non-existant uid.
+# Choose a non-existent uid.
 fakeuid = 4127
 while byuids.has_key(fakeuid):
     fakeuid = (fakeuid * 3) % 0x10000
Index: Lib/test/test_winreg.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_winreg.py,v
retrieving revision 1.2
diff -u -r1.2 test_winreg.py
--- Lib/test/test_winreg.py	2000/04/01 05:25:57	1.2
+++ Lib/test/test_winreg.py	2000/06/28 07:42:58
@@ -115,7 +115,7 @@
     # Opening should now fail!
     try:
         key = OpenKey(root_key, test_key_name)
-        assert 0, "Could open the non-existant key"
+        assert 0, "Could open the non-existent key"
     except WindowsError: # Use this error name this time
         pass
 
Index: Lib/test/test_zlib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_zlib.py,v
retrieving revision 1.7
diff -u -r1.7 test_zlib.py
--- Lib/test/test_zlib.py	2000/02/10 15:31:07	1.7
+++ Lib/test/test_zlib.py	2000/06/28 07:42:59
@@ -11,7 +11,7 @@
 buf = file.read() * 8
 file.close()
 
-# test the chucksums (hex so the test doesn't break on 64-bit machines)
+# test the checksums (hex so the test doesn't break on 64-bit machines)
 print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1))
 print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1))
 
Index: Python/exceptions.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/exceptions.c,v
retrieving revision 1.2
diff -u -r1.2 exceptions.c
--- Python/exceptions.c	2000/06/20 18:36:26	1.2
+++ Python/exceptions.c	2000/06/28 07:42:59
@@ -189,7 +189,7 @@
  *
  * First thing we create is the base class for all exceptions, called
  * appropriately enough: Exception.  Creation of this class makes no
- * assumptions about the existance of any other exception class -- except
+ * assumptions about the existence of any other exception class -- except
  * for TypeError, which can conditionally exist.
  *
  * Next, StandardError is created (which is quite simple) followed by
Index: Python/import.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/import.c,v
retrieving revision 2.134
diff -u -r2.134 import.c
--- Python/import.c	2000/05/03 23:44:39	2.134
+++ Python/import.c	2000/06/28 07:43:01
@@ -87,7 +87,7 @@
 #define MAGIC (50428 | ((long)'\r'<<16) | ((long)'\n'<<24))
 
 /* Magic word as global; note that _PyImport_Init() can change the
-   value of this global to accomodate for alterations of how the
+   value of this global to accommodate for alterations of how the
    compiler works which are enabled by command line switches. */
 static long pyc_magic = MAGIC;
 



From effbot at telia.com  Wed Jun 28 11:47:32 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 11:47:32 +0200
Subject: [Python-Dev] Typo's
References: <14681.50422.966321.780406@temoleh.chem.uu.nl>
Message-ID: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid>

> I located some typo's in the CVS. Here is a patch.

wow!

just one nit:

"inobstrusive" should be "unobtrusive" (not "inobtrusive")

(and it's not clear if "descriptior" means "description" or
"descriptor"...)

> Warning: I'm a non-native English speaker.

same here.

</F>




From effbot at telia.com  Wed Jun 28 13:07:24 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 13:07:24 +0200
Subject: [Python-Dev] OT: A Day in the Life of p5p
Message-ID: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>

http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

unfortunately, his "What is it with those Python fucks anyway" talk
isn't posted... ;-)

</F>




From fdrake at beopen.com  Wed Jun 28 13:16:53 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 07:16:53 -0400 (EDT)
Subject: [Python-Dev] back up & running
Message-ID: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com>

  My mega-laptop got fixed faster than I'd expected, so I'm back up to
doing useful work.  My top priorities are handling patches and going
back through my email to find all the documentation patches that have
sat idle for too long.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mwh21 at cam.ac.uk  Wed Jun 28 13:54:27 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 28 Jun 2000 12:54:27 +0100
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: "Andy Robinson"'s message of "Wed, 28 Jun 2000 08:03:08 +0100"
References: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <m3vgyu9g24.fsf@atrus.jesus.cam.ac.uk>

"Andy Robinson" <andy at robanal.demon.co.uk> writes:

> It seems to be better over big corporate connections.  I don't think it is
> because I am in Europe; we never have trouble with our US ISPs.

FWIW, it's pretty good from here (but then the university has pretty
serious bandwidth).  It seems a bit odd that it's so much worse with
lower badwidth (in particular that people on modems get more errors).
Oh well.

Cheers,
M.




From Vladimir.Marangozov at inrialpes.fr  Wed Jun 28 14:22:56 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Wed, 28 Jun 2000 14:22:56 +0200 (CEST)
Subject: [Python-Dev] back up & running
In-Reply-To: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jun 28, 2000 07:16:53 AM
Message-ID: <200006281222.OAA03150@python.inrialpes.fr>

Fred L. Drake, Jr. wrote:
> 
>   My mega-laptop got fixed faster than I'd expected, so I'm back up to
> doing useful work.  My top priorities are handling patches and going
> back through my email to find all the documentation patches that have
> sat idle for too long.

Excellent!

Finally someone who cares to checkin patches. I've been disappointed
to see that the June 30 intent-date was announced, but people keep
chewing-gumming about SourceForge caveats while the patches backlog
grows and the number of closed patches stays invariably to 3, of which
one is a test!

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From bwarsaw at beopen.com  Wed Jun 28 15:27:12 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 09:27:12 -0400 (EDT)
Subject: [Python-Dev] Sourceforge Interface Concerns
References: <20000628025304.BB64A1CE0D@dinsdale.python.org>
	<PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <14681.64816.561341.920024@anthem.concentric.net>

>>>>> "AR" == Andy Robinson <andy at robanal.demon.co.uk> writes:

    AR> How many people here have actually created accounts for
    AR> themselves on SourceForge and tried to do stuff when logged in
    AR> - raise bugs and so on?  Did it work for you?  We ought to get
    AR> a few data points before making this the way Python is
    AR> managed.

In general SF's web has been fine for me, although it is sometimes
unavailable due to routing problems.  I'm on a fairly reliable DSL
line now, though I don't remember significantly more SF-blamable
problems when I was on a 56K line.

It's often quite slow to do CVS/SSH to SF.  Sometimes I'll have to
spin for several minutes just to do an update or a diff.  That sucks.

-Barry



From fdrake at beopen.com  Wed Jun 28 15:30:22 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 09:30:22 -0400 (EDT)
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
References: <20000628025304.BB64A1CE0D@dinsdale.python.org>
	<PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com>

Andy Robinson writes:
 > I find the web interface totally unusable from IE5 and Netscape 4.XX,
 > working over 64k lines or dialup lines.  Once one logs in via SSL, only
 > about one click in five ever returns a sensible page, and most just time out

  I've not been able to reproduce this behavior; the Web interface
seems to work well with IE5 and Netscape 4.XX for me; the only problem
I've had with IE5 is accessing a project's anonymous FTP area from the
project page (IE5 just froze completely).  Netscape didn't exhibit
that problem for me and allowed perfectly reasonable use.
  Sometimes it seems a little slow, but I attribute that to load and
the public-key crypto using SSH for CVS access; I understand that CVS
doesn't have the most efficient wire-protocol either.
  I should note that I've mostly used it over T1 and cable modem
links; I don't know that smaller pipes would make a huge difference
though.  I'd be more suspicious of trans-Atlantic linkage than
anything else without having more information.  Routing can do strange
things, so you may be getting the worst-possible link for SourceForge
while other things get better routes, but I wouldn't expect that to be
terribly consistent.

 > How many people here have actually created accounts for themselves on
 > SourceForge and tried to do stuff when logged in - raise bugs and so on?
 > Did it work for you?  We ought to get a few data points before making this
 > the way Python is managed.

  I've never had the kind of problems you describe.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From Vladimir.Marangozov at inrialpes.fr  Wed Jun 28 15:58:26 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Wed, 28 Jun 2000 15:58:26 +0200 (CEST)
Subject: [Python-Dev] Typo's
In-Reply-To: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 28, 2000 11:47:32 AM
Message-ID: <200006281358.PAA03368@python.inrialpes.fr>

Fredrik Lundh wrote:
> 
> > I located some typo's in the CVS. Here is a patch.
> 
> wow!

Wow, indeed.
+1

I've uploaded this patch to SourceForge.

> 
> just one nit:
> 
> "inobstrusive" should be "unobtrusive" (not "inobtrusive")

fixed in the patch.

> 
> (and it's not clear if "descriptior" means "description" or
> "descriptor"...)

I examined the patched file - it's "description".


> 
> > Warning: I'm a non-native English speaker.
> 
> same here.

same here :-)

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From guido at beopen.com  Wed Jun 28 16:55:00 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 09:55:00 -0500
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: Your message of "Tue, 27 Jun 2000 18:46:15 MST."
             <20000627184615.A29590@lyra.org> 
References: <20000627184615.A29590@lyra.org> 
Message-ID: <200006281455.JAA01690@cj20424-a.reston1.va.home.com>

> A while back, I pulled the "demo" importers out of imputil.py. I think those
> should be added into Demo/imputil/.

OK.  Go ahead and create that directory and add the demo importers.

> It would also be Goodness to include JimA's zipimporter. Where would that go?

Same place I'd hope?  Can you check that it works?

We're dependent on you volunteers to maintain relatively non-core
things like this -- I don't want to extend the feature freeze to
Demo/, but I also don't have the time to keep the stuff there up to
date.  Maybe at some point the Demo directory should become a separate
distribution, or just a collection of stuff on the web?

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



From akuchlin at mems-exchange.org  Wed Jun 28 16:07:22 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 10:07:22 -0400
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com>
References: <20000628025304.BB64A1CE0D@dinsdale.python.org> <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk> <14681.65006.782463.491824@cj42289-a.reston1.va.home.com>
Message-ID: <20000628100722.A9063@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 09:30:22AM -0400, Fred L. Drake, Jr. wrote:
>  I should note that I've mostly used it over T1 and cable modem
>links; I don't know that smaller pipes would make a huge difference
>though. 

At home I have a 28.8 modem (never figured out how to upgrade it to
56K), and while CVS operations are fairly slow, there usually aren't
any problems.  The same goes for accessing the Web pages through SSL;
somewhat slow, but reliable.

--amk



From gward at mems-exchange.org  Wed Jun 28 16:18:12 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 28 Jun 2000 10:18:12 -0400
Subject: [Python-Dev] Python 1.6 planning
In-Reply-To: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400
References: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>
Message-ID: <20000628101812.A15643@ludwig.cnri.reston.va.us>

On 23 June 2000, Jeremy Hylton said:
> ldso_aix-- I still don't understand, but I didn't really try; Vladimir must
> help

This has been fixed in the Distutils.  AFAIK it's still broken for
Makefile.pre.in builds -- as long as the installed Makefile is fixed
(not the actual installation location of ld_so_aix), then Distutils
builds will continue to work.

(Thanks to Rene Liebscher for providing the Distutils fix, and Vladimir
for testing it.)

        Greg



From gward at mems-exchange.org  Wed Jun 28 16:29:02 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 28 Jun 2000 10:29:02 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37
In-Reply-To: <20000624151824.A29590@lyra.org>; from gstein@lyra.org on Sat, Jun 24, 2000 at 03:18:24PM -0700
References: <200006242040.NAA28315@slayer.i.sourceforge.net> <20000624151824.A29590@lyra.org>
Message-ID: <20000628102901.B15643@ludwig.cnri.reston.va.us>

On 24 June 2000, Greg Stein said:
> Would the "shlex" module be helpful here? It is in the standard library and
> is (well?) maintained by ESR. It could help reduce the code inside
> distutils.

I looked at "shlex", but didn't like the fact that it 1) does
character-by-character analysis of input, and 2) requires a file-like
object.  Just a performance concern, really.

> [ I've always questioned the need for distutils' own "copy file" functions
>   and whatnot... seems there is a bit of duplication occurring... ]

Two reasons for that: bugs in the standard library versions, and missing
features in the standard library versions.  I think the first argument
goes away now that I've given up on 1.5.1 compatibility (shutil.py was
really broken in 1.5.1), but the fact remains that the copy functions in
shutil.py don't have a dry_run option, don't have a verbose option,
don't have a preserve_times option, don't have a preserve_symlinks
option, etc.  All of these things are somewhere between useful and
necessary.

I'm always open for ideas on reducing the amount of code in the
Distutils; it really is getting ridiculous.  It cracked 10k lines of
code+comments+doc this weekend -- about 5300 lines of straight code, I
think.  Anyways, the basic required functionality is now in place, so
I'm open to clever refactoring/reduction/simplification patches.

        Greg



From guido at beopen.com  Wed Jun 28 17:41:26 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 10:41:26 -0500
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Wed, 28 Jun 2000 02:23:40 -0400."
             <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> 
Message-ID: <200006281541.KAA02041@cj20424-a.reston1.va.home.com>

> Since we (PythonLabs, last week) decided to continue using Jitterbug (on
> python.org) for now, should the SF Bug Manager even be enabled?  If it is
> enabled, and we are using Jitterbug, then someone has to own reentering SF
> bugs into the Jitterbug system.

OK, I've disabled the SF bugs manager.  There were two bugs submitted
so far.  I've assigned one to you (about os.listdir on Windows) and
one to MAL (about -U vs. exec/eval).  You two can take care of
entering these into JB.  You can still access the bugs database via
this URL:

https://sourceforge.net/bugs/?group_id=5470

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



From gward at mems-exchange.org  Wed Jun 28 17:35:05 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 28 Jun 2000 11:35:05 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 01:07:24PM +0200
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
Message-ID: <20000628113505.C15643@ludwig.cnri.reston.va.us>

On 28 June 2000, Fredrik Lundh said:
> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt
> 
> unfortunately, his "What is it with those Python fucks anyway" talk
> isn't posted... ;-)

But the "Conclusion" of his "Lies We Tell" talk:

   Perl sucks. Use Python.

Presumably tongue-in-cheek, but you never know...

        Greg



From trentm at activestate.com  Wed Jun 28 18:53:19 2000
From: trentm at activestate.com (Trent Mick)
Date: Wed, 28 Jun 2000 09:53:19 -0700
Subject: [Python-Dev] back up & running
In-Reply-To: <200006281222.OAA03150@python.inrialpes.fr>
References: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> <200006281222.OAA03150@python.inrialpes.fr>
Message-ID: <20000628095319.C14129@activestate.com>

On Wed, Jun 28, 2000 at 02:22:56PM +0200, Vladimir Marangozov wrote:
> Fred L. Drake, Jr. wrote:
> > 
> >   My mega-laptop got fixed faster than I'd expected, so I'm back up to
> > doing useful work.  My top priorities are handling patches and going
> > back through my email to find all the documentation patches that have
> > sat idle for too long.
> 
> Excellent!
> 
> Finally someone who cares to checkin patches. I've been disappointed
> to see that the June 30 intent-date was announced, but people keep
> chewing-gumming about SourceForge caveats while the patches backlog
> grows and the number of closed patches stays invariably to 3, of which
> one is a test!
> 

You can count me as one of the significatn bottlenecks here. Tim and Guido
have accepted some of my patches, I just have to check them in. Real Soon Now
(tm).


Trent Mick (also tm)

-- 
Trent Mick
trentm at activestate.com



From mal at lemburg.com  Wed Jun 28 18:57:35 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Jun 2000 18:57:35 +0200
Subject: [Python-Dev] Named Unicode Characters
Message-ID: <395A2E7F.A1DDEC35@lemburg.com>

I've just checked in the patches by Bill Tutt, which add
support for \N{NAMED UNICODE CHARACTERS}. The new escape
code is available per default in the standard unicode-escape
codec. The (big) hash table needed to drive the mapping
is loaded on demand to reduce memory overhead.

The patch also includes a new tool called perfecthash which
is used to generate the hash table (and function) from 
names to ordinals. I'm sure this can be of use in other
areas too... but it needs some more work to become more
generic (currently you have to edit the source code to generate
other mapping modules).

Thanks to Bill Tutt -- this is great work !

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From paul at prescod.net  Wed Jun 28 19:11:19 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:11:19 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
Message-ID: <395A31B7.911D9BC2@prescod.net>

Fredrik Lundh wrote:
> 
> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

How about this one:

http://gisle.aas.no/perl/illguts/

Just thank your lucky stars...

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From paul at prescod.net  Wed Jun 28 19:16:45 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:16:45 -0700
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>
Message-ID: <395A32FD.D3C58B23@prescod.net>

I don't want to be paranoid, but are we putting any important
information into SourceForge that we are not backing up elsewhere? I
mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust
suit...) would we have backups of our patches, bugs, wish lists and so
forth? I hope that's a criteria in deciding what services to move to
SourceForge. I am in the business of preserving investments in data and
of telling customers to avoid software that does not keep them in
complete control of their data. SF makes me nervous that way....

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From mal at lemburg.com  Wed Jun 28 19:22:40 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Jun 2000 19:22:40 +0200
Subject: [Python-Dev] Checkin Utility
Message-ID: <395A3460.3FF013F0@lemburg.com>

I thought you might have some use for the attached utility. It's
a simple script which helps with checking in patches which I've
been using for a while now. It also hides the CVS options and
parameters away as far as possible, so that CVS knowledge is
not really needed to complete the task.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: checkin.py
Type: text/python
Size: 8070 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000628/3e29b91c/attachment.bin>

From esr at thyrsus.com  Wed Jun 28 19:38:05 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 28 Jun 2000 13:38:05 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:11:19AM -0700
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net>
Message-ID: <20000628133805.D20855@thyrsus.com>

Paul Prescod <paul at prescod.net>:
> http://gisle.aas.no/perl/illguts/
> 
> Just thank your lucky stars...

Ghods.  Reading that just about ruined my lunch.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"The power to tax involves the power to destroy;...the power to
destroy may defeat and render useless the power to create...."
	-- Chief Justice John Marshall, 1819.



From paul at prescod.net  Wed Jun 28 19:27:54 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:27:54 -0700
Subject: [Python-Dev] Text about cycle GC
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>
Message-ID: <395A359A.2CF0CA70@prescod.net>

"A.M. Kuchling" wrote:
> 
> ...
> 
>    An experimental step has been made toward fixing this problem. When
>    compiling Python, the -with-cycle-gc (XXX correct option flag?) option
>    can be specified. This causes a cycle detection algorithm to be
>    periodically executed, which looks for inaccessible cycles and deletes
>    the objects involved.

I propose (without any investigation into the difficulty of
implementation) that 

import cyclicgc

should turn on the -with-cycle-gc flag.

Then you could do a 

import cyclicgc
import someDOM

And not worry about cycles. If it's too slow, you remove the line and
take responsibility for cycle checking. The important thing is that you
don't have to tell YOUR USERS to turn on GC in order for your code to
work.

I think that this model will get more people actively using (and
depending upon!) GC and thus give us a better idea about usage patterns,
stability and performance. This is especially important in the beta
period when we are trying to shake out bugs.

Really, this comes back to Greg's point that we should not have
incompatible sub-languages running around. A module depends on the
feature or it doesn't. The end-user should not be responsible for
knowing whether any module in a whole program needs GC.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From paul at prescod.net  Wed Jun 28 19:34:35 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:34:35 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com>
Message-ID: <395A372B.34E15A62@prescod.net>

"Eric S. Raymond" wrote:
> 
> Ghods.  Reading that just about ruined my lunch.

You read it? Eric, I was just kidding!

Actually, my theory is that the whole thing is a big, extended, April
Fools joke.

Not the document. The language. (rimshot)

 SvOOK-vs-SvIV-and-SvNV-indeed-ly 'yrs

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From gmcm at hypernet.com  Wed Jun 28 19:37:07 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 28 Jun 2000 13:37:07 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
Message-ID: <1249908601-39717068@hypernet.com>

> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

What I noticed is that Tim is mentioned in every other 
paragraph.

Where-does-he-find-the-time?-ly y'rs

- Gordon



From jeremy at beopen.com  Wed Jun 28 19:41:50 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 28 Jun 2000 13:41:50 -0400 (EDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
	<395A31B7.911D9BC2@prescod.net>
Message-ID: <14682.14558.380773.307392@bitdiddle.concentric.net>

>>>>> "PP" == Paul Prescod <paul at prescod.net> writes:

  PP> Fredrik Lundh wrote:
  >>  http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

  PP> How about this one:

  PP> http://gisle.aas.no/perl/illguts/

  PP> Just thank your lucky stars...

What beautiful diagrams!  It almost makes me wish Python was
complicated enough to require such pretty pictures.

Jeremy



From guido at beopen.com  Wed Jun 28 20:41:48 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 13:41:48 -0500
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Wed, 28 Jun 2000 10:16:45 MST."
             <395A32FD.D3C58B23@prescod.net> 
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>  
            <395A32FD.D3C58B23@prescod.net> 
Message-ID: <200006281841.NAA03154@cj20424-a.reston1.va.home.com>

[PP]
> I don't want to be paranoid, but are we putting any important
> information into SourceForge that we are not backing up elsewhere? I
> mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust
> suit...) would we have backups of our patches, bugs, wish lists and so
> forth? I hope that's a criteria in deciding what services to move to
> SourceForge. I am in the business of preserving investments in data and
> of telling customers to avoid software that does not keep them in
> complete control of their data. SF makes me nervous that way....

Good point.

SF has a way to get a nightly snapshot of the CVS tree.  We should
suggest that they provide snapshots (in XML of course!) of the bugs
database too.

Note that I have no bandwidth left to communicate to SF folks so this
is up to the user community.  (I'm also very optimistic and trusting
in nature. :-)

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



From jeremy at beopen.com  Wed Jun 28 19:49:32 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 28 Jun 2000 13:49:32 -0400 (EDT)
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <395A359A.2CF0CA70@prescod.net>
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>
	<395A359A.2CF0CA70@prescod.net>
Message-ID: <14682.15020.589514.702145@bitdiddle.concentric.net>

>>>>> "PP" == Paul Prescod <paul at prescod.net> writes:

  PP> "A.M. Kuchling" wrote:
  >>  ...
  >> 
  >> An experimental step has been made toward fixing this
  >> problem. When compiling Python, the -with-cycle-gc (XXX correct
  >> option flag?) option can be specified. This causes a cycle
  >> detection algorithm to be periodically executed, which looks for
  >> inaccessible cycles and deletes the objects involved.

  PP> I propose (without any investigation into the difficulty of
  PP> implementation) that

  PP> import cyclicgc

  PP> should turn on the -with-cycle-gc flag.

The -with-cycle-gc flag is an option to configure when you build
Python.  It can't be turned on or off at runtime.

We hope that everyone will build with the -with-cycle-gc flag during
the beta testing, but we don't expect to have enough confidence in it
by final release to make it anything other than an experimental
option. 

Jeremy



From esr at thyrsus.com  Wed Jun 28 20:02:37 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 28 Jun 2000 14:02:37 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A372B.34E15A62@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:34:35AM -0700
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> <395A372B.34E15A62@prescod.net>
Message-ID: <20000628140237.A21043@thyrsus.com>

Paul Prescod <paul at prescod.net>:
> "Eric S. Raymond" wrote:
> > 
> > Ghods.  Reading that just about ruined my lunch.
> 
> You read it? Eric, I was just kidding!

Yes, I read it.  Un-fscking-believable.  I knew Perl was complicated and
ugly on the inside, but the full horror had not obtruded itself on me
before now.  If I'm any judge, that's an implementation on the brink of
collapsing under its own weight.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Non-cooperation with evil is as much a duty as cooperation with good.
	-- Mohandas Gandhi



From paul at prescod.net  Wed Jun 28 19:53:16 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:53:16 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
		<395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net>
Message-ID: <395A3B8B.B6117DA1@prescod.net>

Note that the document doesn't yet cover the regular expression engine
or the "PerlInterpreter". 

I can't think of a disclaimer that doesn't sound like it is tongue in
cheek but I do feel bad about beating up on a design which, in its own
way, has a certain kind of quality (just not one I happen to prefer).
When you optimize the snot out of things they tend to start looking
ugly. Perl runs faster than Python. That's probably not a coincidence.

Jeremy Hylton wrote:
> 
> What beautiful diagrams!  It almost makes me wish Python was
> complicated enough to require such pretty pictures.

To be fair, our internals documentation needs some work. I'll bet there
are a lot of people in comp.lang.python that would be interested in a
project like that or another one, such as adding a full warning
infrastructure to Python. I wonder how we could do a Software Carpentry
like deal (no money) where we get people to submit designs and ideas and
then "award" the job to someone. They could do it for reputational
capital and an opportunity to join "the team" (of CVS committers,
PythonDev denizens etc.).

It's probably better to give people ideas rather than have them
implement random things that we will need to turn down. Like stackless.
<duck and cover!!!>
-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From paul at prescod.net  Wed Jun 28 20:09:38 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 11:09:38 -0700
Subject: [Python-Dev] Text about cycle GC
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>
		<395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net>
Message-ID: <395A3F62.EA1E8B89@prescod.net>

Jeremy Hylton wrote:
> 
> ....
> 
> The -with-cycle-gc flag is an option to configure when you build
> Python.  It can't be turned on or off at runtime.

Doh! Sorry. Andrew's text does say that but I didn't read carefully and
testing it with my stuff hasn't floated to the top yet (because when I
looked into it, I realized I'd have to recompile...double doh!)
Compiling is really slow on my "transitional" computer.

I'm a little disappointed that it will be so difficult for people to
test with GC on, but I'm not going to claim that there is some easy way
to make it a runtime option because I haven't looked at it at all. There
probably isn't.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From nascheme at enme.ucalgary.ca  Wed Jun 28 20:27:25 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Wed, 28 Jun 2000 12:27:25 -0600
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <395A3F62.EA1E8B89@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 11:09:38AM -0700
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net>
Message-ID: <20000628122725.A13473@acs.ucalgary.ca>

On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote:
> I'm a little disappointed that it will be so difficult for people to
> test with GC on, but I'm not going to claim that there is some easy way
> to make it a runtime option because I haven't looked at it at all. There
> probably isn't.

There isn't.  With an interpreter compiled --with-cycle-gc you can
turn off the collection with gc.set_threshold(0) but that's not
the same thing.

  Neil



From bwarsaw at beopen.com  Wed Jun 28 20:33:23 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 14:33:23 -0400 (EDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
	<395A31B7.911D9BC2@prescod.net>
	<20000628133805.D20855@thyrsus.com>
	<395A372B.34E15A62@prescod.net>
	<20000628140237.A21043@thyrsus.com>
Message-ID: <14682.17651.552666.318592@anthem.concentric.net>

>>>>> "ESR" == Eric S Raymond <esr at thyrsus.com> writes:

    ESR> Yes, I read it.  Un-fscking-believable.  I knew Perl was
    ESR> complicated and ugly on the inside, but the full horror had
    ESR> not obtruded itself on me before now.  If I'm any judge,
    ESR> that's an implementation on the brink of collapsing under its
    ESR> own weight.

And of course, we'll be right there to pick up the pieces. :)



From guido at beopen.com  Wed Jun 28 21:43:06 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 14:43:06 -0500
Subject: [Python-Dev] Python 1.6 schedule
Message-ID: <200006281943.OAA03414@cj20424-a.reston1.va.home.com>

I've updated the 1.6 page on python.org (http://www.python.org/1.6/)
to include the latest schedule for 1.6.  I've also included a link to
Andrew's "what's new" article.  Here's the new schedule in text form:

  July 1: beta 1; feature freeze. 

  July 14: beta 2, in time for the O'Reilly Open Source Software Convention. 

  August 1: release candidate. 

  August 15: final release. 

I'm happy with how the patches are coming along today (/F even
submitted the SRE patch...).  We may actually have a release party
Saturday!

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



From guido at beopen.com  Wed Jun 28 22:27:43 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 15:27:43 -0500
Subject: [Python-Dev] Named Unicode Characters
In-Reply-To: Your message of "Wed, 28 Jun 2000 18:57:35 +0200."
             <395A2E7F.A1DDEC35@lemburg.com> 
References: <395A2E7F.A1DDEC35@lemburg.com> 
Message-ID: <200006282027.PAA04607@cj20424-a.reston1.va.home.com>

> I've just checked in the patches by Bill Tutt, which add
> support for \N{NAMED UNICODE CHARACTERS}. The new escape
> code is available per default in the standard unicode-escape
> codec. The (big) hash table needed to drive the mapping
> is loaded on demand to reduce memory overhead.
> 
> The patch also includes a new tool called perfecthash which
> is used to generate the hash table (and function) from 
> names to ordinals. I'm sure this can be of use in other
> areas too... but it needs some more work to become more
> generic (currently you have to edit the source code to generate
> other mapping modules).
> 
> Thanks to Bill Tutt -- this is great work !

Thanks Bill and Marc-Andre!

I've closed the patch in SF now.

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



From tim_one at email.msn.com  Wed Jun 28 21:40:18 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 15:40:18 -0400
Subject: [Python-Dev] back up & running
In-Reply-To: <20000628095319.C14129@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEPMGGAA.tim_one@email.msn.com>

[Vladimir Marangozov]
> ...
> I've been disappointed to see that the June 30 intent-date was
> announced, but people keep chewing-gumming about SourceForge
> caveats while the patches backlog grows and the number of closed
> patches stays invariably to 3, of which one is a test!

Absolutely on-target, Vladimir!  The current state of our world is
embarrassing.  Someday when the bosses aren't listening, I'll explain to you
how it got this way <0.9 wink>.

[Trent Mick]
> You can count me as one of the significant bottlenecks here. Tim and
> Guido have accepted some of my patches, I just have to check them in.
> Real Soon Now (tm).

Trent, you are *not* a bottleneck!  You've cooperated with the process (or
lack thereof) every step of the way, and it hasn't even been 12 hours since
I accepted some of your patches.  And the bulk of them are still on my plate
to review.

I don't think we have an actual bottleneck now, but we do have a large
backlog to work off, and people with too many things that need to be done.

perseverance-and-patience-will-probably-work-better-than-their-opposites-ly
    y'rs  - tim





From gstein at lyra.org  Wed Jun 28 21:46:06 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 12:46:06 -0700
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <200006281455.JAA01690@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 09:55:00AM -0500
References: <20000627184615.A29590@lyra.org> <200006281455.JAA01690@cj20424-a.reston1.va.home.com>
Message-ID: <20000628124606.K29590@lyra.org>

On Wed, Jun 28, 2000 at 09:55:00AM -0500, Guido van Rossum wrote:
> > A while back, I pulled the "demo" importers out of imputil.py. I think those
> > should be added into Demo/imputil/.
> 
> OK.  Go ahead and create that directory and add the demo importers.

Will do.

> > It would also be Goodness to include JimA's zipimporter. Where would that go?
> 
> Same place I'd hope?  Can you check that it works?

Yup and yup.

> We're dependent on you volunteers to maintain relatively non-core
> things like this -- I don't want to extend the feature freeze to
> Demo/, but I also don't have the time to keep the stuff there up to
> date.

Not a problem, and I had figured on being the "point man" on keeping it
working. My query here was more along the lines of "is Demo/imputil/ a good
idea? If so, then I'll run with it." You said "yes", so I'll go put on my
shoes.

> Maybe at some point the Demo directory should become a separate
> distribution, or just a collection of stuff on the web?

I believe a separate distribution. Unpacking the bugger to the main web site
would also be a good option, but that would be a second priority.

I'd throw Tools into the same thing. As a separate distro, you can have a
faster release cycle. ... you could release Idle updates easily and
distinctly from the Python core.

Note: by a "collection on the web", the only view that I have, is that the
collection exists on the python.org web site. Distributed pieces "here and
there" is handled by the Vaults (and similar). The Demo/ directory is a bit
more newbie-ish, so (IMO) it ought to get bundled up somehow since the
Vaults are a bit daunting to find "example of embedding". If the bundle also
happens to reside in an obvious area on python.org? Great.

Cheers,
-g

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



From tim_one at email.msn.com  Wed Jun 28 21:54:42 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 15:54:42 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEABGHAA.tim_one@email.msn.com>

[Paul Prescod]
> How about this one:
>
> http://gisle.aas.no/perl/illguts/

> Just thank your lucky stars...

Ack, don't get me started -- well, I'd love to, but have real work to do.
I've posted about that before.  I'm not infrequently amazed that they manage
to keep Perl running at all.  The amazing thing about the PerlGuts doc above
is that it was apparently reverse-engineered by staring at Perl's
implementation code.  You can't find any of it explained in the source!

either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter-
    than-us-and-i-know-which-of-those-i'm-more-likely-to-
    believe<wink>-ly y'rs  - tim





From guido at beopen.com  Wed Jun 28 22:59:46 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 15:59:46 -0500
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: Your message of "Wed, 28 Jun 2000 12:27:25 CST."
             <20000628122725.A13473@acs.ucalgary.ca> 
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net>  
            <20000628122725.A13473@acs.ucalgary.ca> 
Message-ID: <200006282059.PAA04852@cj20424-a.reston1.va.home.com>

> On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote:
> > I'm a little disappointed that it will be so difficult for people to
> > test with GC on, but I'm not going to claim that there is some easy way
> > to make it a runtime option because I haven't looked at it at all. There
> > probably isn't.
> 
> There isn't.  With an interpreter compiled --with-cycle-gc you can
> turn off the collection with gc.set_threshold(0) but that's not
> the same thing.
> 
>   Neil

I wonder if we should turn this option *on* during beta testing?

That way we gather a lot more experience with its use!  Maybe nobody
complains and we can leave it on in the final release...

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



From akuchlin at mems-exchange.org  Wed Jun 28 22:10:28 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 16:10:28 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A3B8B.B6117DA1@prescod.net>
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net> <395A3B8B.B6117DA1@prescod.net>
Message-ID: <20000628161028.C23352@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 10:53:16AM -0700, Paul Prescod wrote:
>Note that the document doesn't yet cover the regular expression engine
>or the "PerlInterpreter". 

The regex engine's pretty hard to read, mostly because comments are
infrequent and not very helpful, and disentangling it from the rest of
Perl would require a skilled wizard.  (PCRE, if slower, is at least
much clearer and easier to understand, though the compile() function
is pretty ugly.)  A while ago I saw a p5p post from Ilya Zakharevich
who did most of the recent regex hacking; he draw attention to one
flag variable in the code and said basically "I don't know what this
flag means; I think it's some sort of UTF-8 setting, but Larry didn't
explain it."

>I can't think of a disclaimer that doesn't sound like it is tongue in
>cheek but I do feel bad about beating up on a design which, in its own
>way, has a certain kind of quality (just not one I happen to prefer).

Agreed; it could be made much simpler, but maybe at a performance
cost.  (Though performance is tricky, and maybe the extra work costs
more than it saves.)

For example, note the flag bits in SvNULL, which have values like
GMAGICAL.  You could imagine a Python implementation that added flag
bits to every object, and set a bit if there was a __getattr__ method
defined; code could then do 'if (obj->flags & GMAGICAL) ...'  instead
of the more complicated 'if (PyObject_HasAttrString(obj,
"__getattr__")'.  It would be interesting to know if Topaz, Chip
Salzenberg's experimental C++ implementation, preserves this
complexity or aims to cut it away.  The use of several levels of C
structs is also reminiscent of the way you do OO in C, as in X
toolkits.

You can also see the importance of text processing in the SvPVBM type,
for attaching a Boyer-Moore related table to a string and speeding up
regex searches.  

--amk



From tim_one at email.msn.com  Wed Jun 28 22:15:34 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 16:15:34 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A3B8B.B6117DA1@prescod.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com>

[Paul Prescod]
> ...
> When you optimize the snot out of things they tend to start looking
> ugly. Perl runs faster than Python. That's probably not a coincidence.

More, IMO it's not even true.  I can't make time for this now, but on
several occasions I've coded the same algorithm in idiomatic Perl and
Python, and Python was invariably faster (not talking orders of magnitude,
but 10-40%).

The catch is that I know something about both implementations, and avoided
the sweet spots in both.  Perl gets enormous bang out of its line-at-a-time
text file input "cheating", and its integrated regexps.  Avoid those, and
it's generally *slower* in my experience, which is perfectly consistent with
the relative messiness of its implementation (all those magic flags aren't
passive, they need runtime conditionals to use!  Perl can't even inline its
refcount manipulations because they're so complicated due to the flags).

Against that, line-at-a-time text file input in particular is something that
every newbie bumps into at once, and Perl does have a monster advantage
there (at least 2x faster, probably closer to 3 on most platforms).  Perl
doesn't really look like it was designed to "be fast" in general -- it looks
like it was designed to be supernaturally fast in specific situations.  Best
I've been able to tell, that's how it *acts*, too.

I'm keen to add comparable (but limited) internal warts to Python, but for
*general* speedup ideas we'll be much better off looking to, e.g., Dylan and
Squeak.

all-that-said-python-is-fast-enough-for-me-already!-ly y'rs  - tim





From DavidA at ActiveState.com  Wed Jun 28 22:17:46 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Wed, 28 Jun 2000 13:17:46 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEABGHAA.tim_one@email.msn.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJKENKCKAA.DavidA@ActiveState.com>

> either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter-
>     than-us-and-i-know-which-of-those-i'm-more-likely-to-
>     believe<wink>-ly y'rs  - tim

I was sitting next to Gisle (the author of said document) when he started to
work on the Perl methods work for Zope. Within a day, starting w/ not
knowing anything about Python, he had Perl embedded in Python.  It says much
about the cleanliness of Python's design and the quality of its
documentation that Gisle could do that.  It also says a lot about Gisle, as
does the perlguts document

Not saying anything about anyone being nuts, especially when responding to
someone who talks about his in public. <ha&bang;/>

--david





From pingster at ilm.com  Wed Jun 28 22:22:15 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Wed, 28 Jun 2000 13:22:15 -0700 (PDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <20000628161028.C23352@kronos.cnri.reston.va.us>
Message-ID: <Pine.SGI.3.96.1000628131524.621134y-100000@happy>

On Wed, 28 Jun 2000, Andrew Kuchling wrote:
> You could imagine a Python implementation that added flag
> bits to every object, and set a bit if there was a __getattr__ method
> defined; code could then do 'if (obj->flags & GMAGICAL) ...'  instead
> of the more complicated 'if (PyObject_HasAttrString(obj,
> "__getattr__")'.

That looks like a reasonable sort of optimization to me, though
as far as i can tell it looks like that optimization has already
been done:

in PyClass_New(bases, dict, name):
    [...]
    op->cl_getattr = class_lookup(op, getattrstr, &dummy);
    [...]

in instance_getattr(inst, name):
    if (res == NULL && (func = inst->in_class->cl_getattr) != NULL) {
        [...special __getattr__ handling...]
    }

In general, optimizations of the form "add a flag to avoid a
frequent expensive test" seem okay to me, as long they are a
demonstrable win and the flag can be given a clear, simple name.


-- ?!ng

"To be human is to continually change.  Your desire to remain what
you are is what ultimately limits you."
    -- The Puppet Master, Ghost in the Shell




From akuchlin at mems-exchange.org  Wed Jun 28 22:25:54 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 16:25:54 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <Pine.SGI.3.96.1000628131524.621134y-100000@happy>
References: <20000628161028.C23352@kronos.cnri.reston.va.us> <Pine.SGI.3.96.1000628131524.621134y-100000@happy>
Message-ID: <20000628162554.E23352@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 01:22:15PM -0700, Ka-Ping Yee wrote:
>That looks like a reasonable sort of optimization to me, though
>as far as i can tell it looks like that optimization has already
>been done:

Damn time machine again...

--amk



From tim_one at email.msn.com  Wed Jun 28 22:31:58 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 16:31:58 -0400
Subject: SourceForge patch notifications (was RE: [Python-Dev] ANN: Release schedule)
In-Reply-To: <20000628090230.A14129@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEAIGHAA.tim_one@email.msn.com>

[Trent Mick]
> ...
> BTW I have answered a couple a questions on my patches. Does
> the person to whom the patch is assigned get an update notification?

Trent & I investigated this offline:  he added a comment to one of his
patches to which I am assigned.  I did indeed get prompt email notification,
although as everyone has noticed by now, there's no indication from SF about
*why* I was getting notified; just:

From: noreply at sourceforge.net [mailto:noreply at sourceforge.net]
Sent: Wednesday, June 28, 2000 12:01 PM
To: tmick at mail.com; tim_one at email.msn.com
Subject: [Patch #100513] fix posixmodule for 64-bit systems (mainly Win64)


Patch #100513 has been updated.
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100513&group_id=5470


So the outcome could have been worse <wink>.

a-new-criterion-for-excellence-ly y'rs  - tim





From effbot at telia.com  Wed Jun 28 22:42:56 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 22:42:56 +0200
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com>
Message-ID: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>

tim wrote:
> Against that, line-at-a-time text file input in particular is something that
> every newbie bumps into at once, and Perl does have a monster advantage
> there (at least 2x faster, probably closer to 3 on most platforms).

and 2-3x is what you get if you replace readline with readlines,
as described in this note:
http://w1.132.telia.com/~u13208596/notes/readline-performance.htm

it would be very nice if the file object could do something similar
internally (only in text mode, perhaps).  maybe in 1.7?

(as I've mentioned earlier, SRE+faster IO can result in a 10x speedup
for a straightforward while/readline/match loop...)

</F>




From jack at oratrix.nl  Wed Jun 28 22:58:27 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 28 Jun 2000 22:58:27 +0200
Subject: [Python-Dev] ucnhash module
Message-ID: <20000628205832.C3234E2673@oratrix.oratrix.nl>

I'm a bit worried about the ucnhash module and its huge size. I didn't 
follow the discussion closely at the time, because I thought I could
always exclude it from the Pythons without dynamic linking, but now it 
seems that if i don't include it test_unicode doesn't run anymore.

Is this a problem with test_unicode, or should I consider ucnhash a
mandatory module?

(BTW: there were also a couple of bugs in the module, include <> in
stead of include "", and static in stead of staticforward
declarations, I'll submit patches for those 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/ ++++



From gstein at lyra.org  Wed Jun 28 23:03:42 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 14:03:42 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com> <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>
Message-ID: <20000628140342.Q29590@lyra.org>

On Wed, Jun 28, 2000 at 10:42:56PM +0200, Fredrik Lundh wrote:
> tim wrote:
> > Against that, line-at-a-time text file input in particular is something that
> > every newbie bumps into at once, and Perl does have a monster advantage
> > there (at least 2x faster, probably closer to 3 on most platforms).
> 
> and 2-3x is what you get if you replace readline with readlines,
> as described in this note:
> http://w1.132.telia.com/~u13208596/notes/readline-performance.htm
> 
> it would be very nice if the file object could do something similar
> internally (only in text mode, perhaps).  maybe in 1.7?

That could be troublesome. It should only be done if the file is seekable so
that you can rewind. If a readline() on (say) a socket moved you *past* the
newline, then you could be in big trouble. Or what happens in said socket is
blocking? etc.

Now... please don't start a thread about this now. Wait for post 1.6. Maybe
I'm totally off, and some smart guy here can say so. But it just doesn't
matter, so I'd rather not have to read a whole thread on the stuff :-)

Cheers,
-g

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



From gstein at lyra.org  Wed Jun 28 23:14:41 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 14:14:41 -0700
Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69)
In-Reply-To: <200006281553.IAA11238@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 08:53:17AM -0700
References: <200006281553.IAA11238@slayer.i.sourceforge.net>
Message-ID: <20000628141441.R29590@lyra.org>

Woah. Never knew this was in Python.

It is quite interesting, as there is a very similar concept within Apache.
In that model, you register a cleanup function for the particular data that
needs to be cleaned post-fork. After the fork occurs, the cleanups are
called.

In essence, Python would register PyOS_AfterFork. Of course, any schmoe can
call fork() and avoid the cleanups, so it bungs up the whole scheme. In
Apache, the "only" way to fork is to call an APR function, which guarantees
the cleanups.

Cheers,
-g

On Wed, Jun 28, 2000 at 08:53:17AM -0700, Fred L. Drake wrote:
> Update of /cvsroot/python/python/dist/src/Doc/api
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv11228/api
> 
> Modified Files:
> 	api.tex 
> Log Message:
> 
> Added documentation for PyOS_AfterFork().
> 
> 
> Index: api.tex
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Doc/api/api.tex,v
> retrieving revision 1.68
> retrieving revision 1.69
> diff -C2 -r1.68 -r1.69
> *** api.tex	2000/06/18 05:21:21	1.68
> --- api.tex	2000/06/28 15:53:13	1.69
> ***************
> *** 1034,1037 ****
> --- 1034,1044 ----
>   \end{cfuncdesc}
>   
> + \begin{cfuncdesc}{void}{PyOS_AfterFork}{}
> + Function to update some internal state after a process fork; this
> + should be called in the new process if the Python interpreter will
> + continue to be used.  If a new executable is loaded into the new
> + process, this function does not need to be called.
> + \end{cfuncdesc}
> + 
>   
>   \section{Process Control \label{processControl}}
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From effbot at telia.com  Wed Jun 28 23:19:36 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 23:19:36 +0200
Subject: [Python-Dev] exceptions trouble
Message-ID: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>

import traceback
try:
    raise SyntaxError, "argument"
except:
    traceback.print_exc()

prints:

Traceback (most recent call last):
  File "test.py", line 3, in ?
    raise SyntaxError, "argument"
Traceback (most recent call last):
  File "test.py", line 5, in ?
    traceback.print_exc()
  File "C:\py16\lib\traceback.py", line 182, in print_exc
    print_exception(etype, value, tb, limit, file)
  File "C:\py16\lib\traceback.py", line 110, in print_exception
    lines = format_exception_only(etype, value)
  File "C:\py16\lib\traceback.py", line 169, in format_exception_only
    list.append('%s: %s\n' % (str(stype), str(value)))
SystemError: new style getargs format but argument is not a tuple

not really what I expected.  am I out of sync, or have I
stumbled upon a bug in the new exceptions code?

</F>




From tim_one at email.msn.com  Wed Jun 28 23:21:52 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 17:21:52 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <20000628140342.Q29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEAMGHAA.tim_one@email.msn.com>

[Greg Stein]
> ...
> Now... please don't start a thread about this now. Wait for post
> 1.6.

Amen.

> Maybe I'm totally off, and some smart guy here can say so. But it
> just doesn't matter, so I'd rather not have to read a whole thread
> on the stuff :-)

If you change your mind, you can go back in the archives and read at least
two old threads on the topic -- it's not like there's actually anything new
here <wink>.





From akuchlin at mems-exchange.org  Wed Jun 28 23:30:38 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 17:30:38 -0400
Subject: [Python-Dev] exceptions trouble
In-Reply-To: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>
References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>
Message-ID: <20000628173038.B28659@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 11:19:36PM +0200, Fredrik Lundh wrote:
>SystemError: new style getargs format but argument is not a tuple
>not really what I expected.  am I out of sync, or have I
>stumbled upon a bug in the new exceptions code?

It works fine in my current copy of the CVS tree, and I think I
rebuilt everything this morning.

--amk



From fdrake at beopen.com  Wed Jun 28 23:32:36 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 17:32:36 -0400 (EDT)
Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69)
In-Reply-To: <20000628141441.R29590@lyra.org>
References: <200006281553.IAA11238@slayer.i.sourceforge.net>
	<20000628141441.R29590@lyra.org>
Message-ID: <14682.28404.125379.249287@cj42289-a.reston1.va.home.com>

Greg Stein writes:
 > Woah. Never knew this was in Python.

  I didn't either, until I read a patch that used it.  That's one way
to keep the documentation up to date!  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From gstein at lyra.org  Wed Jun 28 23:48:00 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 14:48:00 -0700
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <200006282112.OAA03095@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:12:28PM -0700
References: <200006282112.OAA03095@slayer.i.sourceforge.net>
Message-ID: <20000628144800.T29590@lyra.org>

On Wed, Jun 28, 2000 at 02:12:28PM -0700, Guido van Rossum wrote:
>...
> - chunk #2: 
> The id() function guarantees a unique return value for different
> objects.  It does this by returning the pointer to the object. By
> returning a PyInt, on Win64 (sizeof(long) < sizeof(void*)) the pointer
> is truncated and the guarantee may be proven false. The appropriate
> return function is PyLong_FromVoidPtr, this returns a PyLong if that
> is necessary to return the pointer without truncation.
> 
> [GvR: note that this means that id() can now return a long on Win32
> platforms.  This *might* break some code...]

Strictly speaking: the Long only occurs on Win64 platforms.

I would guess that it is also possible on say, an Alpha running Linux.
Presuming that has 64-bit pointers(?).

Regardless: yes, it can certainly break some code. IMO, if any code out
there makes any kinds of assumptions about id(), then they deserve to be
broken :-)

Cheers,
-g

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



From paul at prescod.net  Wed Jun 28 23:44:33 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 14:44:33 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com> <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> <20000628140342.Q29590@lyra.org>
Message-ID: <395A71C1.A4E332D@prescod.net>

Re: Performance

At the very least this readlines() optimization should be in FileInput
which was invented, after all, in order to compete with Perl.
---
Re: Inline Unicode smily faces

Bill and Mark-Andre, you rock. Another feature stolen from Perl.

If only it were as easy to steal cleanliness and elegance. :)
---
Re: GC

On by default in beta would be peachy.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From bwarsaw at beopen.com  Thu Jun 29 00:01:00 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 18:01:00 -0400 (EDT)
Subject: [Python-Dev] exceptions trouble
References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>
	<20000628173038.B28659@kronos.cnri.reston.va.us>
Message-ID: <14682.30108.714768.740415@anthem.concentric.net>

>>>>> "AK" == Andrew Kuchling <akuchlin at mems-exchange.org> writes:

    AK> It works fine in my current copy of the CVS tree, and I think
    AK> I rebuilt everything this morning.

Same here.



From trentm at activestate.com  Thu Jun 29 00:04:28 2000
From: trentm at activestate.com (Trent Mick)
Date: Wed, 28 Jun 2000 15:04:28 -0700
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <20000628144800.T29590@lyra.org>
References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org>
Message-ID: <20000628150428.E17875@activestate.com>

On Wed, Jun 28, 2000 at 02:48:00PM -0700, Greg Stein wrote:
> Regardless: yes, it can certainly break some code. IMO, if any code out
> there makes any kinds of assumptions about id(), then they deserve to be
> broken :-)

Amen.

Trent

-- 
Trent Mick
trentm at activestate.com



From nascheme at enme.ucalgary.ca  Thu Jun 29 00:07:43 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Wed, 28 Jun 2000 16:07:43 -0600
Subject: [Python-Dev] id() on Win64
Message-ID: <20000628160743.A16262@acs.ucalgary.ca>

[Greg Stein]
>Strictly speaking: the Long only occurs on Win64 platforms.
>
>I would guess that it is also possible on say, an Alpha running
>Linux.  Presuming that has 64-bit pointers(?).

I think the Alpha is okay. The problem is strange type models
were int is 32 bits and pointers are 64.  AFAIK, the Alpha uses
64 bits for both.

  Neil



From guido at beopen.com  Thu Jun 29 01:10:52 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 18:10:52 -0500
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: Your message of "Wed, 28 Jun 2000 14:48:00 MST."
             <20000628144800.T29590@lyra.org> 
References: <200006282112.OAA03095@slayer.i.sourceforge.net>  
            <20000628144800.T29590@lyra.org> 
Message-ID: <200006282310.SAA05850@cj20424-a.reston1.va.home.com>

> > [GvR: note that this means that id() can now return a long on Win32
> > platforms.  This *might* break some code...]
> 
> Strictly speaking: the Long only occurs on Win64 platforms.

You're right.

> I would guess that it is also possible on say, an Alpha running Linux.
> Presuming that has 64-bit pointers(?).

No, because their longs are also 64 bits, and hence so are Python ints.

> Regardless: yes, it can certainly break some code. IMO, if any code out
> there makes any kinds of assumptions about id(), then they deserve to be
> broken :-)

That depends.  It is documented as an integer -- which may be vague
enough to encompass longs, but that's weasel-wording. ;-)

I do think that the likelihood of this breaking significant code is low.

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



From gstein at lyra.org  Thu Jun 29 00:17:58 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 15:17:58 -0700
Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
In-Reply-To: <200006282157.OAA05880@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:57:20PM -0700
References: <200006282157.OAA05880@slayer.i.sourceforge.net>
Message-ID: <20000628151758.X29590@lyra.org>

On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote:
> Update of /cvsroot/python/python/dist/src/Objects
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838
> 
> Modified Files:
> 	classobject.c object.c 
> Log Message:
> Trent Mick: change a few casts for Win64 compatibility.
> 
> 
> Index: classobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v
> retrieving revision 2.89
> retrieving revision 2.90
> diff -C2 -r2.89 -r2.90
> *** classobject.c	2000/06/23 19:37:01	2.89
> --- classobject.c	2000/06/28 21:57:18	2.90
> ***************
> *** 284,288 ****
>   	if (v == NULL || !PyString_Check(v))
>   		return "__name__ must be a string object";
> ! 	if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v))
>   		return "__name__ must not contain null bytes";
>   	set_slot(&c->cl_name, v);
> --- 284,288 ----
>   	if (v == NULL || !PyString_Check(v))
>   		return "__name__ must be a string object";
> ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
>   		return "__name__ must not contain null bytes";
>   	set_slot(&c->cl_name, v);

Actually, it would seem to make more sense to place the cast *inside* the
PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.

May as well start some ANSI-fication while we can...

Guido: any problem with my changing the macro?

Cheers,
-g

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



From gstein at lyra.org  Thu Jun 29 00:16:17 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 15:16:17 -0700
Subject: [Python-Dev] httplib doc (was: CVS: python/dist/src/Doc/lib libhttplib.tex,1.19,1.20)
In-Reply-To: <200006282151.OAA05489@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 02:51:46PM -0700
References: <200006282151.OAA05489@slayer.i.sourceforge.net>
Message-ID: <20000628151617.W29590@lyra.org>

Please mark me for a TODO to update the httplib doc. For example, the code
below is more effectively written as:

h = httplib.HTTPConnection('www.musi-cal.com')
h.request('POST', '/cgi-bin/query', paramstring, {'Accept': 'text/plain'})
response = h.getresponse()
print response.status   # should be 200
data = response.read()  # get the raw HTML

Note that 'Accept' is usually not a required header and can be omitted in
most scenarios. I left it in the example simply to show how to fully map
between the old/new APIs.

[ Content-Length and Host are sent automatically by HTTPConnection. ]

Cheers,
-g

On Wed, Jun 28, 2000 at 02:51:46PM -0700, Fred L. Drake wrote:
> Update of /cvsroot/python/python/dist/src/Doc/lib
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv5474/lib
> 
> Modified Files:
> 	libhttplib.tex 
> Log Message:
> 
> Skip Montanaro <skip at mojam.com>:
> Added an example of using an HTTP POST request.
> 
> 
> Index: libhttplib.tex
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Doc/lib/libhttplib.tex,v
> retrieving revision 1.19
> retrieving revision 1.20
> diff -C2 -r1.19 -r1.20
> *** libhttplib.tex	1999/04/22 16:47:27	1.19
> --- libhttplib.tex	2000/06/28 21:51:43	1.20
> ***************
> *** 115,119 ****
>   \nodename{HTTP Example}
>   
> ! Here is an example session:
>   
>   \begin{verbatim}
> --- 115,119 ----
>   \nodename{HTTP Example}
>   
> ! Here is an example session that uses the \samp{GET} method:
>   
>   \begin{verbatim}
> ***************
> *** 129,131 ****
> --- 129,148 ----
>   >>> data = f.read() # Get the raw HTML
>   >>> f.close()
> + \end{verbatim}
> + 
> + Here is an example session that shows how to \samp{POST} requests:
> + 
> + \begin{verbatim}
> + >>> import httplib, urllib
> + >>> params = urllib.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})
> + >>> h = httplib.HTTP("www.musi-cal.com:80")
> + >>> h.putrequest("POST", "/cgi-bin/query")
> + >>> h.putheader("Content-length", "%d" % len(params))
> + >>> h.putheader('Accept', 'text/plain')
> + >>> h.putheader('Host', 'www.musi-cal.com')
> + >>> h.endheaders()
> + >>> h.send(paramstring)
> + >>> reply, msg, hdrs = h.getreply()
> + >>> print errcode # should be 200
> + >>> data = h.getfile().read() # get the raw HTML
>   \end{verbatim}
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From mal at lemburg.com  Thu Jun 29 00:38:29 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 00:38:29 +0200
Subject: [Python-Dev] ucnhash module
References: <20000628205832.C3234E2673@oratrix.oratrix.nl>
Message-ID: <395A7E65.2271C723@lemburg.com>

Jack Jansen wrote:
> 
> I'm a bit worried about the ucnhash module and its huge size. I didn't
> follow the discussion closely at the time, because I thought I could
> always exclude it from the Pythons without dynamic linking, but now it
> seems that if i don't include it test_unicode doesn't run anymore.
> 
> Is this a problem with test_unicode, or should I consider ucnhash a
> mandatory module?

The ucnhash module is loaded on demand to avoid memory bloat.
In practice the difference is not really noticeable since 
loading a shared module or swapping in a few pages of static
C data result in pretty much the same overall memory usage.

If no-one complains, I'll fix the test suite though to make
the tests of the named Unicode characters optional.

Is this ok with you, Bill ?
 
> (BTW: there were also a couple of bugs in the module, include <> in
> stead of include "", and static in stead of staticforward
> declarations, I'll submit patches for those shortly).

I didn't have any problem compiling the module (don't even get
warnings when compiling with -Wall) ... but you're right:
these ought to get fixed.

BTW, since ucnhash.h|c are generated using the scripts
in Tools/perfecthash/ your patch should probably also fix the
instances of the problems found in there.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From tim_one at email.msn.com  Thu Jun 29 00:47:04 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 18:47:04 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <20000628150428.E17875@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>

[Greg Stein]
> Regardless: yes, it can certainly break some code. IMO, if any code out
> there makes any kinds of assumptions about id(), then they deserve to be
> broken :-)

[Trent Mick]
> Amen.

Guys, it's almost never that simple, and developers are the last ones to
think of the reasonable cases that may break.  In this case, e.g., code may
be doing something as harmless as printing an id() via a "... %d ..." format
in a log, and-- BOOM! --that blows up with an OverflowError if you feed it a
Python long larger than a C long.

I'd rather fix %d formats than leave id() broken, though!  id() has to
return a unique value.

but-i'll-sympathize-with-the-users-even-in-public<wink>-ly y'rs  - tim





From trentm at activestate.com  Thu Jun 29 01:49:55 2000
From: trentm at activestate.com (Trent Mick)
Date: Wed, 28 Jun 2000 16:49:55 -0700
Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
In-Reply-To: <20000628151758.X29590@lyra.org>
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org>
Message-ID: <20000628164955.B19053@activestate.com>

On Wed, Jun 28, 2000 at 03:17:58PM -0700, Greg Stein wrote:
> On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote:
> > Update of /cvsroot/python/python/dist/src/Objects
> > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838
> > 
> > Modified Files:
> > 	classobject.c object.c 
> > Log Message:
> > Trent Mick: change a few casts for Win64 compatibility.
> > 
> > 
> > Index: classobject.c
> > ===================================================================
> > RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v
> > retrieving revision 2.89
> > retrieving revision 2.90
> > diff -C2 -r2.89 -r2.90
> > *** classobject.c	2000/06/23 19:37:01	2.89
> > --- classobject.c	2000/06/28 21:57:18	2.90
> > ***************
> > *** 284,288 ****
> >   	if (v == NULL || !PyString_Check(v))
> >   		return "__name__ must be a string object";
> > ! 	if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v))
> >   		return "__name__ must not contain null bytes";
> >   	set_slot(&c->cl_name, v);
> > --- 284,288 ----
> >   	if (v == NULL || !PyString_Check(v))
> >   		return "__name__ must be a string object";
> > ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
> >   		return "__name__ must not contain null bytes";
> >   	set_slot(&c->cl_name, v);
> 
> Actually, it would seem to make more sense to place the cast *inside* the
> PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
> 
> May as well start some ANSI-fication while we can...
> 

I agree. Go to town, Greg. :)

Trent

-- 
Trent Mick
trentm at activestate.com



From gstein at lyra.org  Thu Jun 29 02:08:40 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:08:40 -0700
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 03:59:46PM -0500
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> <200006282059.PAA04852@cj20424-a.reston1.va.home.com>
Message-ID: <20000628170840.E29590@lyra.org>

On Wed, Jun 28, 2000 at 03:59:46PM -0500, Guido van Rossum wrote:
> > On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote:
> > > I'm a little disappointed that it will be so difficult for people to
> > > test with GC on, but I'm not going to claim that there is some easy way
> > > to make it a runtime option because I haven't looked at it at all. There
> > > probably isn't.
> > 
> > There isn't.  With an interpreter compiled --with-cycle-gc you can
> > turn off the collection with gc.set_threshold(0) but that's not
> > the same thing.
> > 
> >   Neil
> 
> I wonder if we should turn this option *on* during beta testing?
> 
> That way we gather a lot more experience with its use!  Maybe nobody
> complains and we can leave it on in the final release...

That presumes an adequate number of testers and a wide variety of
deployment/usage scenarios. Given the relatively short timeframe, that may
be a bit aggressive.

I *do* agree with enabling it during the beta. But I'm just not sure about
leaving it on.

Cheers,
-g

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



From tim_one at email.msn.com  Thu Jun 29 02:07:20 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 20:07:20 -0400
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <20000628124606.K29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEBGGHAA.tim_one@email.msn.com>

[Greg Stein]
> ...
> I'd throw Tools into the same thing [as Demos]. As a separate distro,
> you can have a faster release cycle. ... you could release Idle
> updates easily and distinctly from the Python core.

Note that Guido gave his blessing for a "wide open" policy on IDLE (== its
own project in SourceForge, and anyone can be a developer).  If that's a
success (& I predict it will be, provided someone actually bothers to set up
the SF project!), I'd like to see it spread to Tools and Demos too.

ignoring-the-downsides-cuz-they'll-make-themselves-known-ly y'rs  - tim





From guido at beopen.com  Thu Jun 29 03:11:36 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 20:11:36 -0500
Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
In-Reply-To: Your message of "Wed, 28 Jun 2000 15:17:58 MST."
             <20000628151758.X29590@lyra.org> 
References: <200006282157.OAA05880@slayer.i.sourceforge.net>  
            <20000628151758.X29590@lyra.org> 
Message-ID: <200006290111.UAA08357@cj20424-a.reston1.va.home.com>

> > ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
> 
> Actually, it would seem to make more sense to place the cast *inside* the
> PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
> 
> May as well start some ANSI-fication while we can...
> 
> Guido: any problem with my changing the macro?

Please leave the macro alone.  The type of the macro should be the
same as the type of the function -- PyString_Size() -- which is int.
If you change this, you potentially get tons of warnings because of
the signed / unsigned nature.

ANSI-fication is a good project for after 1.6.  But even then, it's a
separate decision whether the size of a string should be a size_t
instead of an int.  (The ob_size field should also change, if so --
with even more consequences.)

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



From gstein at lyra.org  Thu Jun 29 02:29:20 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:29:20 -0700
Subject: [Python-Dev] PyString_GET_SIZE()
In-Reply-To: <200006290111.UAA08357@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 08:11:36PM -0500
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com>
Message-ID: <20000628172919.G29590@lyra.org>

On Wed, Jun 28, 2000 at 08:11:36PM -0500, Guido van Rossum wrote:
> > > ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
> > 
> > Actually, it would seem to make more sense to place the cast *inside* the
> > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
> > 
> > May as well start some ANSI-fication while we can...
> > 
> > Guido: any problem with my changing the macro?
> 
> Please leave the macro alone.  The type of the macro should be the
> same as the type of the function -- PyString_Size() -- which is int.
> If you change this, you potentially get tons of warnings because of
> the signed / unsigned nature.
> 
> ANSI-fication is a good project for after 1.6.  But even then, it's a
> separate decision whether the size of a string should be a size_t
> instead of an int.  (The ob_size field should also change, if so --
> with even more consequences.)

Post 1.6, yes... I had figured on ob_size changing. Certainly not now :-)

But I understand the point about different return types. No problem.

[ of course, I would state that PyString_Size should also change and we fix
  those warnings... but I'll be patient :-) ]

How about removing Py_PROTO() usage, and changing function definitions from
K&R arg declaration to ANSI declarations? That kind of work is pretty
simple, straight-forward, and if somebody has free time to plod through the
work... so much the better. I believe that these changes would not introduce
any stability problems, and could be done independently from your busy
schedule.

Hmm. Is there a good place to start listing these todo items? One that we
can truly use for communicating this info? In Apache, we have a file named
STATUS that everybody uses for dropping ideas, patch references, critical
bugs, etc. As that file gets changed, we see it in the -checkins alias, so
everybody is aware of the suggested changes/problems/available patches/etc.
It also holds people's votes on particular changes.

Can we institute something similar? Possibly Misc/STATUS? Should I post
Apache's STATUS file as an example?

Cheers,
-g

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



From gstein at lyra.org  Thu Jun 29 02:34:24 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:34:24 -0700
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395A32FD.D3C58B23@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:16:45AM -0700
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net>
Message-ID: <20000628173424.H29590@lyra.org>

I think you are being paranoid :-)

Consider that this same issue applies to all 5900 projects and 38000
developers at SourceForge. VA Linux has a brand identity entirely built on
the trust and support of the Linux (and Open Source) communities. If they
blow away that trust, they are simply screwed.

That said: it would still be a good thing to have export capabilities. I
recall that certain portions of the data (the Trove map?) can be exported in
XML format. I don't recall the magic URL for that, however.

Cheers,
-g

On Wed, Jun 28, 2000 at 10:16:45AM -0700, Paul Prescod wrote:
> I don't want to be paranoid, but are we putting any important
> information into SourceForge that we are not backing up elsewhere? I
> mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust
> suit...) would we have backups of our patches, bugs, wish lists and so
> forth? I hope that's a criteria in deciding what services to move to
> SourceForge. I am in the business of preserving investments in data and
> of telling customers to avoid software that does not keep them in
> complete control of their data. SF makes me nervous that way....
> 
> -- 
>  Paul Prescod - Not encumbered by corporate consensus
> The calculus and the rich body of mathematical analysis to which it 
> gave rise made modern science possible, but it was the algorithm that 
> made the modern world possible.
> 	- The Advent of the Algorithm (pending), by David Berlinski
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev

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



From gstein at lyra.org  Thu Jun 29 02:36:41 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:36:41 -0700
Subject: [Python-Dev] RTFM: SourceForge access for Win32
Message-ID: <20000628173641.I29590@lyra.org>

All right guys... all this banter about setting up CVS access for Win32
users has been quite silly. Did anybody even stop to look at the docs?

http://sfdocs.sourceforge.net/sfdocs/

In particular:

http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=19
http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=20
http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=46

There is also a new tool available (released today);

http://sfsetup.sourceforge.net/


Cheers,
-g

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



From gstein at lyra.org  Thu Jun 29 03:01:40 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 18:01:40 -0700
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEBGGHAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 08:07:20PM -0400
References: <20000628124606.K29590@lyra.org> <LNBBLJKPBEHFEDALKOLCAEBGGHAA.tim_one@email.msn.com>
Message-ID: <20000628180140.M29590@lyra.org>

On Wed, Jun 28, 2000 at 08:07:20PM -0400, Tim Peters wrote:
> [Greg Stein]
> > ...
> > I'd throw Tools into the same thing [as Demos]. As a separate distro,
> > you can have a faster release cycle. ... you could release Idle
> > updates easily and distinctly from the Python core.
> 
> Note that Guido gave his blessing for a "wide open" policy on IDLE (== its
> own project in SourceForge, and anyone can be a developer).  If that's a
> success (& I predict it will be, provided someone actually bothers to set up
> the SF project!), I'd like to see it spread to Tools and Demos too.

Are you suggesting that IDLE be separate from a Tools/Demo package, or that
the whole bunch be shoved out into the wild?

Hmm... I guess that I don't much have an opinion one way or the other, but
was mostly looking for clarification.

Cheers,
-g

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



From jeremy at beopen.com  Thu Jun 29 04:08:51 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 28 Jun 2000 22:08:51 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
Message-ID: <14682.44979.673881.83798@bitdiddle.concentric.net>

Setup.in contains the following comment:

# (Note: the expat build process doesn't yet build a libexpat.a; you can
# do this manually while we try convince the author to add it.)

I've got expat, and I've built it, but I don't have any idea how to
build libexpat.a.  It may be possible to do it manually, but it would
help a lot if the comments could say how to build it or contain a link
to instructions on how to build it.

Jeremy



From gward at python.net  Thu Jun 29 04:37:08 2000
From: gward at python.net (Greg Ward)
Date: Wed, 28 Jun 2000 22:37:08 -0400
Subject: [Python-Dev] Just spotted on SourceForge main page
Message-ID: <20000628223707.A1168@beelzebub>

Maybe this is what all you Windows folks are looking for.

  SFSetup v1 released 
  mhearn - 06/28/00 11:00   -   SourceForge Setup for Win32 

  SFSetup is a program to automatically setup SSH and WinCVS for
  SourceForge projects under the Windows 32 platform. It's now available
  for download so if you have not yet set up SSH and WinCVS and want it
  done for you, you can use this program. Go to sfsetup.sourceforge.net
  to find out how to use it. It's open source and written in Delphi -
  the code is in CVS and any improvements are welcome! Thanks -mike
                
-- 
Greg Ward - Linux nerd                                  gward at python.net
http://starship.python.net/~gward/
I love ROCK 'N ROLL!  I memorized the all WORDS to "WIPE-OUT" in 1965!!



From fdrake at beopen.com  Thu Jun 29 05:26:55 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 23:26:55 -0400 (EDT)
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <200006282310.SAA05850@cj20424-a.reston1.va.home.com>
References: <200006282112.OAA03095@slayer.i.sourceforge.net>
	<20000628144800.T29590@lyra.org>
	<200006282310.SAA05850@cj20424-a.reston1.va.home.com>
Message-ID: <14682.49663.208158.88794@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > That depends.  It is documented as an integer -- which may be vague
 > enough to encompass longs, but that's weasel-wording. ;-)

  The 1.6 documentation will make it clear that this may be a long
integer, but I don't think we need to promise on which platforms this
will be the case.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From paul at prescod.net  Thu Jun 29 06:21:41 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 21:21:41 -0700
Subject: [Python-Dev] how do I build pyexpat?
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
Message-ID: <395ACED5.83764D45@prescod.net>

I don't know where you got your expat or how new it is, but with the one
I got from the xml-sig, I can type

"make libexpat.a"

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From tim_one at email.msn.com  Thu Jun 29 06:55:22 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 00:55:22 -0400
Subject: [Python-Dev] PyString_GET_SIZE()
In-Reply-To: <20000628172919.G29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEBPGHAA.tim_one@email.msn.com>

[Greg Stein]
> ...
> How about removing Py_PROTO() usage, and changing function
> definitions from K&R arg declaration to ANSI declarations? That
> kind of work is pretty simple, straight-forward, and if somebody
> has free time to plod through the work... so much the better.

I think it's too late in the cycle to suggest work for others to do and get
any payback from that.  Unless you're the one with the free time -- in which
case full speed ahead and God bless!  I previously volunteered to take the
Py_PROTO crap on, as I use an editor with a symbol database that gets
confused by that stuff, but I'm sure not going to start that this week.

> ...
> Hmm. Is there a good place to start listing these todo items?

Not that I know of.  "Group whiteboards" and shared journals etc are darned
useful, though.

> One that we can truly use for communicating this info? In Apache, we
> have a file named STATUS that everybody uses for dropping ideas, patch
> references, critical bugs, etc. As that file gets changed, we see it
> in the -checkins alias, so everybody is aware of the suggested
> changes/problems/available patches/etc.  It also holds people's votes
> on particular changes.
>
> Can we institute something similar? Possibly Misc/STATUS? Should I post
> Apache's STATUS file as an example?

Yes, sure, no:  just check one in!  If Guido hates it, we can remove it
later.  In the meantime, I bet we'll find great ways to use it.  In the
spirit of Unix, maybe it should be called Misc/gwtbd <wink>.

let-a-thousand-idiosyncracies-bloom-ly y'rs  - tim





From tim_one at email.msn.com  Thu Jun 29 06:55:24 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 00:55:24 -0400
Subject: [Python-Dev] RTFM: SourceForge access for Win32
In-Reply-To: <20000628173641.I29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEBPGHAA.tim_one@email.msn.com>

> All right guys... all this banter about setting up CVS access for Win32
> users has been quite silly.

It's been a valuable object lesson, Greg:  I showed everyone the value of
sitting on their ass until someone who knows what they're doing can't stand
it anymore <0.8 wink>.

> Did anybody even stop to look at the docs?

Didn't seem so to me.  I personally never found any docs, despite looking
for them.

> http://sfdocs.sourceforge.net/sfdocs/

Great!  Thank you.

> ...
> There is also a new tool available (released today);
>
> http://sfsetup.sourceforge.net/





From tim_one at email.msn.com  Thu Jun 29 07:08:27 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 01:08:27 -0400
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <20000628180140.M29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCOECAGHAA.tim_one@email.msn.com>

[Greg Stein]
> Are you suggesting that IDLE be separate from a Tools/Demo
> package, or that the whole bunch be shoved out into the wild?

There's already an IDLE distribution distinct from Python's:

    http://www.python.org/idle/

Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not
clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack
of time).

> Hmm... I guess that I don't much have an opinion one way or the other, but
> was mostly looking for clarification.

I don't have a specific plan in mind either -- just "me too"ing on the idea
that it would do no harm and possibly do real good to let these peripheral
(to the core) things live on their own schedules.  I don't see any harm in
including "the latest" snapshot of them with the core distribution,
though -- it's handy for newcomers to get these things without needing to
search for them.  I know I learned a lot about Python at the start from
browsing these directories.





From skip at mojam.com  Thu Jun 29 07:27:02 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 00:27:02 -0500 (CDT)
Subject: [Python-Dev] Another Python-based company makes good...
Message-ID: <14682.56870.790737.261865@beluga.mojam.com>

Saw this on InfoBeat today:

    ** Yahoo to buy EGroups

    Yahoo said it would buy e-mail service provider EGroups
    (www.egroups.com) for $437.5 million in stock to enhance the
    Internet giant's communications services. Yahoo (YHOO) said it
    would issue 3.43 million shares of stock for all of EGroups
    shares, options, and warrants. The purchase will be accounted for
    as a pooling of interests and is expected to close in the third
    quarter. Yahoo said it would report a one-time charge during the
    third quarter for expenses to cover the takeover.

Looks like Scott Hassan can safely drop out of grad school now (if he hasn't
already)... ;-)

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From skip at mojam.com  Thu Jun 29 07:39:09 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 00:39:09 -0500 (CDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
	<395A31B7.911D9BC2@prescod.net>
Message-ID: <14682.57597.600123.167311@beluga.mojam.com>

    Paul> http://gisle.aas.no/perl/illguts/

The author of all those pretty diagrams is going to be really pissed when
they rename all the data structures in Perl 6... :-/

Skip



From tim_one at email.msn.com  Thu Jun 29 08:47:41 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 02:47:41 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <200006281541.KAA02041@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKECGGHAA.tim_one@email.msn.com>

[Guido]
> OK, I've disabled the SF bugs manager.  There were two bugs submitted
> so far.  I've assigned one to you (about os.listdir on Windows) and
> one to MAL (about -U vs. exec/eval).  You two can take care of
> entering these into JB.  You can still access the bugs database via
> this URL:
>
> https://sourceforge.net/bugs/?group_id=5470

I moved "my" bug to Jitterbug, and moved Marc-Andre's too to save him the
bother.  Marked them "Closed" and "Duplicate" on SourceForge, so that if we
reenable bug management there someday they won't confuse us.





From moshez at math.huji.ac.il  Thu Jun 29 09:12:17 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Thu, 29 Jun 2000 10:12:17 +0300 (IDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <200006282213.PAA13365@slayer.i.sourceforge.net>
Message-ID: <Pine.GSO.4.10.10006290943150.15938-100000@sundial>

On Wed, 28 Jun 2000, Fred L. Drake wrote:

> + * Update the filecmp documentation (Moshe?).

I'm waiting for Gordon to check-in his directory comparisons to filecmp.
Gordon?
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From effbot at telia.com  Thu Jun 29 10:19:42 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 10:19:42 +0200
Subject: [Python-Dev] id() on Win64
References: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>
Message-ID: <00d501bfe1a2$c93f8cc0$f2a6b5d4@hagrid>

tim wrote:
> [Greg Stein]
> > Regardless: yes, it can certainly break some code. IMO, if any code out
> > there makes any kinds of assumptions about id(), then they deserve to be
> > broken :-)
> 
> [Trent Mick]
> > Amen.
> 
> Guys, it's almost never that simple, and developers are the last ones to
> think of the reasonable cases that may break.

especially since it's documented to be an integer:

    id (object) 
    Return the `identity' of an object. This is an integer which is
    guaranteed to be unique and constant for this object during
    its lifetime.

(section 2.1.4 says that "integer" is the same thing as a "plain
integer", and that "long integer" is something different).

</F>




From gstein at lyra.org  Thu Jun 29 11:15:08 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 02:15:08 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.4,2.5
In-Reply-To: <200006290857.BAA11219@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 01:57:57AM -0700
References: <200006290857.BAA11219@slayer.i.sourceforge.net>
Message-ID: <20000629021508.P29590@lyra.org>

Euh... can we get a bit more information in that checkin message. "towards
1.6b1" says zippo about what is changing or why.

Cheers,
-g

On Thu, Jun 29, 2000 at 01:57:57AM -0700, Fredrik Lundh wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv11206
> 
> Modified Files:
> 	_sre.c 
> Log Message:
> towards 1.6b1
> 
> Index: _sre.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/_sre.c,v
> retrieving revision 2.4
> retrieving revision 2.5
> diff -C2 -r2.4 -r2.5
> *** _sre.c	2000/06/01 17:34:20	2.4
> --- _sre.c	2000/06/29 08:57:54	2.5
> ***************
> *** 4,20 ****
>    * $Id$
>    *
> !  * simple regular expression matching engine
>    *
>    * partial history:
> !  * 99-10-24 fl	created (based on the template matcher)
>    * 99-11-13 fl	added categories, branching, and more (0.2)
>    * 99-11-16 fl	some tweaks to compile on non-Windows platforms
>    * 99-12-18 fl	non-literals, generic maximizing repeat (0.3)
> !  * 99-02-28 fl	tons of changes (not all to the better ;-) (0.4)
> [...1589 lines suppressed...]
>   
>   void
> ! #if defined(WIN32)
>   __declspec(dllexport)
>   #endif
> ***************
> *** 1708,1713 ****
>           Cursor_Type.ob_type = &PyType_Type;
>   
> ! 	Py_InitModule("_sre", _functions);
>   }
>   
> ! #endif
> --- 1846,1851 ----
>           Cursor_Type.ob_type = &PyType_Type;
>   
> ! 	Py_InitModule("_" MODULE, _functions);
>   }
>   
> ! #endif /* !defined(SRE_RECURSIVE) */
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From effbot at telia.com  Thu Jun 29 11:29:11 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 11:29:11 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.4,2.5
References: <200006290857.BAA11219@slayer.i.sourceforge.net> <20000629021508.P29590@lyra.org>
Message-ID: <005601bfe1ac$7e014460$f2a6b5d4@hagrid>

greg wrote:

> Euh... can we get a bit more information in that checkin message. "towards
> 1.6b1" says zippo about what is changing or why.

just bringing the repository in sync with the current development
snapshot -- I promise to provide more info when the checkins are
more focused...

just gotta reach "1.6b1 quality" first...

</F>




From bckfnn at worldonline.dk  Thu Jun 29 11:42:03 2000
From: bckfnn at worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 09:42:03 GMT
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>
Message-ID: <395b1528.5978476@smtp.worldonline.dk>

[Tim Peters]

>id() has to return a unique value.

This property of id() does not hold in JPython. When used with hotspot,
id() is not unique.

regards,
finn



From Vladimir.Marangozov at inrialpes.fr  Thu Jun 29 12:05:12 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Thu, 29 Jun 2000 12:05:12 +0200 (CEST)
Subject: [Python-Dev] id() on Win64
In-Reply-To: <395b1528.5978476@smtp.worldonline.dk> from "Finn Bock" at Jun 29, 2000 09:42:03 AM
Message-ID: <200006291005.MAA20940@python.inrialpes.fr>

Finn Bock wrote:
> 
> [Tim Peters]
> 
> >id() has to return a unique value.
> 
> This property of id() does not hold in JPython. When used with hotspot,
> id() is not unique.

Is it?
Not unique or not persistent during the object's lifetime?

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From effbot at telia.com  Thu Jun 29 12:07:42 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 12:07:42 +0200
Subject: [Python-Dev] build problems under MSVC 5.0
Message-ID: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid>

Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier
Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv'
Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier
Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type'
Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier

in MSVC 5.0, _beginthread returns an "unsigned long" (this is also
how it's documented in MSDN).

I suggest changing the declaration in thread_nt.h to:

#if _MSC_VER >= 1200
 INT_PTR rv;
#else
 unsigned long rv;
#endif

on the other hand, the same docs claim that it returns -1 on errors.
doesn't exactly look like an unsigned long to me, but that's another
story...

</F>




From effbot at telia.com  Thu Jun 29 12:21:22 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 12:21:22 +0200
Subject: [Python-Dev] arraymodule still broken?
Message-ID: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid>

just checked everything out and rebuilt, the exceptions
problem sure disappeared, but I still get this error:

>>> import array
>>> array.array("H", [60000])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: signed short integer is greater than maximum

second opinion, anyone?

</F>




From bckfnn at worldonline.dk  Thu Jun 29 12:43:55 2000
From: bckfnn at worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 10:43:55 GMT
Subject: [Python-Dev] id() on Win64
In-Reply-To: <200006291005.MAA20940@python.inrialpes.fr>
References: <200006291005.MAA20940@python.inrialpes.fr>
Message-ID: <395b26e6.10520397@smtp.worldonline.dk>

[Finn Bock]

> This property of id() does not hold in JPython. When used with hotspot,
> id() is not unique.

[Vladimir Marangozov}

>Is it?
>Not unique or not persistent during the object's lifetime?

Not unique. Two different objects can return the same value from
System.identityHashCode().

The HTML java docs have this to say about hashCodes:

"""
  As much as is reasonably practical, the hashCode method defined by class
  Object does return distinct integers for distinct objects. (This is
  typically implemented by converting the internal address of the object
  into an integer, but this implementation technique is not required by the
  JavaTM programming language.)
"""

Its just one of those small difference that we have to live with. In
pratical term I have seen it cause problems in pickle.py and
copy.deepcopy()

regards,
finn



From gmcm at hypernet.com  Thu Jun 29 14:22:12 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 29 Jun 2000 08:22:12 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <Pine.GSO.4.10.10006290943150.15938-100000@sundial>
References: <200006282213.PAA13365@slayer.i.sourceforge.net>
Message-ID: <1249841091-43777448@hypernet.com>

Moshe wrote:

> On Wed, 28 Jun 2000, Fred L. Drake wrote:
> 
> > + * Update the filecmp documentation (Moshe?).
> 
> I'm waiting for Gordon to check-in his directory comparisons to
> filecmp. Gordon? 

Looking at CVS, my stuff was there in filecmp revision 1.2 
(+299 -38) and wiped out by 1.3 (+38 -299) which was done 
the following day.

- Gordon



From akuchlin at cnri.reston.va.us  Thu Jun 29 14:25:19 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Thu, 29 Jun 2000 08:25:19 -0400
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <395ACED5.83764D45@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 09:21:41PM -0700
References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net>
Message-ID: <20000629082519.A13839@newcnri.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 09:21:41PM -0700, Paul Prescod wrote:
>I don't know where you got your expat or how new it is, but with the one
>I got from the xml-sig, I can type
>"make libexpat.a"

That's a patch I made to the Makefile and submitted to James Clark.
For Modules/Setup.in, I can change it to explicitly list the 8 files
from Expat that need to be linked to.  The problem is that one of the
files will vary:

# Use one of the next two lines; unixfilemap is better if it works.
FILEMAP_OBJ=xmlwf/unixfilemap.o
#FILEMAP_OBJ=xmlwf/readfilemap.o

--amk



From gward at mems-exchange.org  Thu Jun 29 14:26:47 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 08:26:47 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com> <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>
Message-ID: <20000629082647.A27322@ludwig.cnri.reston.va.us>

On 28 June 2000, Fredrik Lundh said:
> it would be very nice if the file object could do something similar
> internally (only in text mode, perhaps).  maybe in 1.7?

Oddly enough, I've been idly contemplating writing an extension type
(hypothetically called "superfile") that makes most of Perl's
file-handling semantics, and maybe some of the speedup, available in
Python.  At one level, it would be a rewrite of my 'text_file'
module/TextFile class in C.

But this is all speculation, mainly predicated on the theory that I
*really* should be eating my own dogfood and distributing some Python
extension, instead of just telling other people how to do it.  ;-)

        Greg



From gward at mems-exchange.org  Thu Jun 29 14:33:39 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 08:33:39 -0400
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <14682.15020.589514.702145@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Jun 28, 2000 at 01:49:32PM -0400
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net>
Message-ID: <20000629083339.B27322@ludwig.cnri.reston.va.us>

On 28 June 2000, Jeremy Hylton said:
>   PP> import cyclicgc
> 
>   PP> should turn on the -with-cycle-gc flag.
> 
> The -with-cycle-gc flag is an option to configure when you build
> Python.  It can't be turned on or off at runtime.

No, no, *obviously* Paul meant that "import cyclicgc" should configure
and compile a new Python interpreter with "--with-cycle-gc" and 'exec()'
it for you.  What else would it mean?

;-)

        Greg

(PS. if this were Perl, you could say

   use cyclegc;

to turn it on, and then elsewhere in your code

   no cyclegc;

to turn it off.  Maybe Python needs an "unimport" command?)

(Kidding!)



From gward at mems-exchange.org  Thu Jun 29 14:39:08 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 08:39:08 -0400
Subject: [Python-Dev] ucnhash module
In-Reply-To: <395A7E65.2271C723@lemburg.com>; from mal@lemburg.com on Thu, Jun 29, 2000 at 12:38:29AM +0200
References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com>
Message-ID: <20000629083908.D27322@ludwig.cnri.reston.va.us>

On 29 June 2000, M.-A. Lemburg said:
> The ucnhash module is loaded on demand to avoid memory bloat.
> In practice the difference is not really noticeable since 
> loading a shared module or swapping in a few pages of static
> C data result in pretty much the same overall memory usage.
> 
> If no-one complains, I'll fix the test suite though to make
> the tests of the named Unicode characters optional.

How 'bout a separate "test_ucn" to test this feature?

...of course, this is yet another case of language syntax features
becoming optional and selectable at compile-time, which I still think is
a bad idea.  Hmmm.

        Greg



From guido at beopen.com  Thu Jun 29 15:39:59 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 08:39:59 -0500
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: Your message of "Thu, 29 Jun 2000 01:08:27 -0400."
             <LNBBLJKPBEHFEDALKOLCOECAGHAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCOECAGHAA.tim_one@email.msn.com> 
Message-ID: <200006291339.IAA09887@cj20424-a.reston1.va.home.com>

> There's already an IDLE distribution distinct from Python's:
> 
>     http://www.python.org/idle/
> 
> Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not
> clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack
> of time).

Yes.

> > Hmm... I guess that I don't much have an opinion one way or the other, but
> > was mostly looking for clarification.
> 
> I don't have a specific plan in mind either -- just "me too"ing on the idea
> that it would do no harm and possibly do real good to let these peripheral
> (to the core) things live on their own schedules.  I don't see any harm in
> including "the latest" snapshot of them with the core distribution,
> though -- it's handy for newcomers to get these things without needing to
> search for them.  I know I learned a lot about Python at the start from
> browsing these directories.

Additionally, it's great for Python on Windows to come with a working
GUI.  Pythonwin may be more like Windows, but it's much more fragile
than (recent versions of) IDLE in my experience.

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



From guido at beopen.com  Thu Jun 29 15:49:32 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 08:49:32 -0500
Subject: [Python-Dev] PyString_GET_SIZE()
In-Reply-To: Your message of "Wed, 28 Jun 2000 17:29:20 MST."
             <20000628172919.G29590@lyra.org> 
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com>  
            <20000628172919.G29590@lyra.org> 
Message-ID: <200006291349.IAA09962@cj20424-a.reston1.va.home.com>

> Hmm. Is there a good place to start listing these todo items? One that we
> can truly use for communicating this info? In Apache, we have a file named
> STATUS that everybody uses for dropping ideas, patch references, critical
> bugs, etc. As that file gets changed, we see it in the -checkins alias, so
> everybody is aware of the suggested changes/problems/available patches/etc.
> It also holds people's votes on particular changes.
> 
> Can we institute something similar? Possibly Misc/STATUS? Should I post
> Apache's STATUS file as an example?

Possibly, but I'm somewhat skeptical.  I used to have a large TODO
file -- still have it -- but it's so full of long-term ideas that
never happened that I rarely look in it any more.  I never got into
the discipline of using it for my day-to-day priorities -- it was more
of a place to write down long-term ideas so I could forget about
them.  I'll append it.  I appreciate a copy of Apache's STATUS file.

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

NEW TODO LIST FOR 1.6
=====================

IDLE: set window class?
socket/ssl version mystery

UNIFIED TODO LIST
=================


From effbot at telia.com  Thu Jun 29 14:58:13 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 14:58:13 +0200
Subject: [Python-Dev] PyString_GET_SIZE()
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com>             <20000628172919.G29590@lyra.org>  <200006291349.IAA09962@cj20424-a.reston1.va.home.com>
Message-ID: <006201bfe1c9$b928d400$f2a6b5d4@hagrid>

guido wrote:

> > Hmm. Is there a good place to start listing these todo items? One that we
> > can truly use for communicating this info? In Apache, we have a file named
> > STATUS that everybody uses for dropping ideas, patch references, critical
> > bugs, etc. As that file gets changed, we see it in the -checkins alias, so
> > everybody is aware of the suggested changes/problems/available patches/etc.
> > It also holds people's votes on particular changes.
> > 
> > Can we institute something similar? Possibly Misc/STATUS? Should I post
> > Apache's STATUS file as an example?
> 
> Possibly, but I'm somewhat skeptical.  I used to have a large TODO
> file -- still have it -- but it's so full of long-term ideas that
> never happened that I rarely look in it any more.

instead of a file, I suggest taking a look at ?!ng's Roundup
(once 1.6 final is out, of course).

</F>




From guido at beopen.com  Thu Jun 29 15:58:00 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 08:58:00 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: Your message of "Thu, 29 Jun 2000 08:22:12 -0400."
             <1249841091-43777448@hypernet.com> 
References: <200006282213.PAA13365@slayer.i.sourceforge.net>  
            <1249841091-43777448@hypernet.com> 
Message-ID: <200006291358.IAA10045@cj20424-a.reston1.va.home.com>

> Moshe wrote:
> 
> > On Wed, 28 Jun 2000, Fred L. Drake wrote:
> > 
> > > + * Update the filecmp documentation (Moshe?).
> > 
> > I'm waiting for Gordon to check-in his directory comparisons to
> > filecmp. Gordon? 
> 
> Looking at CVS, my stuff was there in filecmp revision 1.2 
> (+299 -38) and wiped out by 1.3 (+38 -299) which was done 
> the following day.

Argh!  An inappropriate side effect of Ping's cleanup -- thanks for
catching this.  Apparently Ping didn't do a CVS update before
generating his diffs.

I can restore version 1.2 easily, but I'm not sure what to do with
/F's changes (1.3 -> 1.4).  Gordon, can you look at this and suggest
what to do?

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



From mal at lemburg.com  Thu Jun 29 15:04:24 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 15:04:24 +0200
Subject: [Python-Dev] ucnhash module
References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com> <20000629083908.D27322@ludwig.cnri.reston.va.us>
Message-ID: <395B4958.C9909145@lemburg.com>

Greg Ward wrote:
> 
> On 29 June 2000, M.-A. Lemburg said:
> > The ucnhash module is loaded on demand to avoid memory bloat.
> > In practice the difference is not really noticeable since
> > loading a shared module or swapping in a few pages of static
> > C data result in pretty much the same overall memory usage.
> >
> > If no-one complains, I'll fix the test suite though to make
> > the tests of the named Unicode characters optional.
> 
> How 'bout a separate "test_ucn" to test this feature?

Good idea.
 
> ...of course, this is yet another case of language syntax features
> becoming optional and selectable at compile-time, which I still think is
> a bad idea.  Hmmm.

It's not selectable at run-time: either you have compiled the
module or not. It is enabled per default.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From Vladimir.Marangozov at inrialpes.fr  Thu Jun 29 15:31:21 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Thu, 29 Jun 2000 15:31:21 +0200 (CEST)
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 28, 2000 03:59:46 PM
Message-ID: <200006291331.PAA21571@python.inrialpes.fr>

Guido van Rossum wrote:
> 
> I wonder if we should turn this option *on* during beta testing?

Why not, as long as --without-gc does not suffer from bugs hidden by
--with-gc.

> 
> That way we gather a lot more experience with its use!  Maybe nobody
> complains and we can leave it on in the final release...

This is risky. We don't have enough experience with this implementation.
All we know is that things get slower and consume more memory. Without
a clear picture of the impact of this GC implementation, it's probably
a bad idea to enable (i.e. impose) it by default.  

The "optional experimental feature" label is good and IMO it complies
with anybody's expectations. Interested people will jump in and will
eventually contribute with improvements, those who don't care won't
and will live happily without it (at least until the day the feature
and its implementation reach their expected maturity).

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From gmcm at hypernet.com  Thu Jun 29 15:27:01 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 29 Jun 2000 09:27:01 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com>
References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400."             <1249841091-43777448@hypernet.com> 
Message-ID: <1249837203-44011365@hypernet.com>

[Gordon] 
> > Looking at CVS, my stuff was there in filecmp revision 1.2
> > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the
> > following day.
[Guido]
> Argh!  An inappropriate side effect of Ping's cleanup -- thanks
> for catching this.  Apparently Ping didn't do a CVS update before
> generating his diffs.
> 
> I can restore version 1.2 easily, but I'm not sure what to do
> with /F's changes (1.3 -> 1.4).  Gordon, can you look at this and
> suggest what to do?

If you have the eff-bot's diff, it should apply to 1.2 (my changes 
are all below there - basically I added a rewritten dircmp). I 
think a CVS merge would do the right thing, too.

- Gordon



From mal at lemburg.com  Thu Jun 29 15:33:36 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 15:33:36 +0200
Subject: [Python-Dev] CVS locks on SF
Message-ID: <395B5030.C0F08E82@lemburg.com>

I'm getting loads of lock messages during CVS checkins recently.
Is this due to overload ? (I wonder why anoncvs access causes
locking at all -- there is no write access so why should there
be file locking ?):

[06:31:40] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test
cvs server: [06:32:10] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test
cvs server: [06:32:41] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test
cvs server: [06:33:11] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Thu Jun 29 15:52:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 09:52:40 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <20000629082519.A13839@newcnri.cnri.reston.va.us>
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
	<395ACED5.83764D45@prescod.net>
	<20000629082519.A13839@newcnri.cnri.reston.va.us>
Message-ID: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com>

Andrew Kuchling writes:
 > That's a patch I made to the Makefile and submitted to James Clark.
 > For Modules/Setup.in, I can change it to explicitly list the 8 files
 > from Expat that need to be linked to.  The problem is that one of the

  It's not in the stable version I picked up last night; I'll dig up
the experimental version today.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From paul at prescod.net  Thu Jun 29 15:52:21 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 29 Jun 2000 06:52:21 -0700
Subject: [Python-Dev] Text about cycle GC
References: <200006291331.PAA21571@python.inrialpes.fr>
Message-ID: <395B5495.CF274583@prescod.net>

Vladimir Marangozov wrote:
> 
>...
>
> This is risky. We don't have enough experience with this implementation.
> All we know is that things get slower and consume more memory. Without
> a clear picture of the impact of this GC implementation, it's probably
> a bad idea to enable (i.e. impose) it by default.

Won't we have a clear picture by the end of the beta period?

> The "optional experimental feature" label is good and IMO it complies
> with anybody's expectations. Interested people will jump in and will
> eventually contribute with improvements, those who don't care won't
> and will live happily without it (at least until the day the feature
> and its implementation reach their expected maturity).

A million Window users will live unhappily without it because they don't
know how to recompile to get it!

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From billtut at microsoft.com  Thu Jun 29 15:54:21 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Thu, 29 Jun 2000 06:54:21 -0700
Subject: [Python-Dev] re: ucnhash
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50>

Re: ucnhash and where the stuff gets tested

Doesn't matter to me where the test goes.

WRT how big it is, thats why its dynamically loaded at run time.
If you don't compile it at all, then the \N{...} syntax just won't owrk.

Re: static vs. staticforward
I can actually do a patch for that, and regen ucnhash.c for you.

Re: "" vs. <>
Whats wrong with what I'm currently doing?

All of the .h files I'm including are on the include file path. "" usage
just means stick "." before everything else in your include path.
None of the files need that. :) If there's a diffferent policy in the Python
source 'bout that that I'm not aware of, then I can fix that issue too.

Bill



From guido at beopen.com  Thu Jun 29 17:03:36 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 10:03:36 -0500
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: Your message of "Thu, 29 Jun 2000 15:33:36 +0200."
             <395B5030.C0F08E82@lemburg.com> 
References: <395B5030.C0F08E82@lemburg.com> 
Message-ID: <200006291503.KAA10324@cj20424-a.reston1.va.home.com>

> I'm getting loads of lock messages during CVS checkins recently.
> Is this due to overload ? (I wonder why anoncvs access causes
> locking at all -- there is no write access so why should there
> be file locking ?):

I haven't seen this myself.  Could be you were just unlucky.  Could be
someone was doing a full checkout over a slow connection.

I think the anon checkouts still use (read) locks because they need to
get a consistent version.

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



From gstein at lyra.org  Thu Jun 29 16:10:51 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 07:10:51 -0700
Subject: [Python-Dev] STATUS files (was: PyString_GET_SIZE())
In-Reply-To: <200006291349.IAA09962@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 08:49:32AM -0500
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> <200006291349.IAA09962@cj20424-a.reston1.va.home.com>
Message-ID: <20000629071051.T29590@lyra.org>

On Thu, Jun 29, 2000 at 08:49:32AM -0500, Guido van Rossum wrote:
> > Hmm. Is there a good place to start listing these todo items? One that we
> > can truly use for communicating this info? In Apache, we have a file named
> > STATUS that everybody uses for dropping ideas, patch references, critical
> > bugs, etc. As that file gets changed, we see it in the -checkins alias, so
> > everybody is aware of the suggested changes/problems/available patches/etc.
> > It also holds people's votes on particular changes.
> > 
> > Can we institute something similar? Possibly Misc/STATUS? Should I post
> > Apache's STATUS file as an example?
> 
> Possibly, but I'm somewhat skeptical.  I used to have a large TODO
> file -- still have it -- but it's so full of long-term ideas that
> never happened that I rarely look in it any more.  I never got into
> the discipline of using it for my day-to-day priorities -- it was more
> of a place to write down long-term ideas so I could forget about
> them.  I'll append it.  I appreciate a copy of Apache's STATUS file.

Attached below...

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

Apache 2.0 STATUS:
Last modified at [$Date: 2000/06/28 11:41:14 $]

Release:

    2.0a5   : ???
    2.0a4   : released June 7, 2000
    2.0a3   : released April 28, 2000
    2.0a2   : released March 31, 2000
    2.0a1   : released March 10, 2000

RELEASE SHOWSTOPPERS:
    * Win32: Get mod_auth_digest working under win32
      - APR_HAS_RANDOM should be defined on windows and there is a 
      lib/apr/misc/win32/rand.c which is basically a copy of what
      mod_auth_digest used to use.

    * Re-work configuration for top level Apache.  Work should start with
      trying to clean the autoconf stuff.  If and only if this proves
      impossible to do (very unlikely), autoconf should be removed and we
      will roll our own config implementation.

    * suEXEC doesn't work
        Status: Manoj has posted an patch to fix this.
        <19991103003605.A20612 at samosa.mindspring.com>

    * Win32: Enable the Windows MPM to honor max_requests_per_child
        Status: Bill will fix this.

    * Win32: Get Apache working on Windows 95/98. The following work
	(at least) needs to be done:
	- winnt MPM: Fix 95/98 code paths in the winnt MPM. There is some NT
	specific code that is still not in NT only code paths
	- IOL binds to APR sendfile, implemented with TransmitFile, which 
        is not available on 95/98.

    * Win32: Test access logging with multiple threads. Will the 
	native file I/O calls serialize automagically like the 
	CRT calls or do we need to add region locking each time 
	we access the logs?
	Status: 

    * Win32: Complete the revamp the service environment and relocation
        into the WinNT MPM.  Changes ServerRoot service registry 
        parameter into ConfigArgs for multiple service startup parameters.
        Problems to fix in the revamp: -k shutdown/restart are broken, 
        signals are not being acknowledged.  Close window and shutdown 
        also seem out of sorts.
        OtherBill is working on this

    * Win32: fix build/run time environment to remove ApacheCore.dll 
        linkage from ab.exe and htdigest.exe.
    
    * We need a thread-safe resolver, at least on Unix.
        Status: The best known candidate would be something from
	BIND v9.
        Status: Greg asks, "why? doesn't gethostbyname_r() handle this?"

    * Modify mod_cgi and mod_cgid to deal with directories.  This allows
      a lot of directives to be removed from the core.

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
    * OS/2: Get loadable modules working again. Requires shared core support
      which doesn't appear to be catered for in the current build system.

    * OS/2: Make mod_status work for spmt_os2 MPM.

    * Build scripts do not recognise AIX 4.2.1 pthreads, so the
      pthread MPMs will not build.

    * Win32: Reuse accept socket after transmitfile/close
	This is not a bug, but would be nice to get this feature in 
	before ship.

    * Win32: Enable the winnt MPM to use the new scoreboard API

    * Win32: Implement ap_shm_ functions in APR.

    * Win32: Win9x console window still won't play nice with the
        close window, logoff and shutdown scenarios.

    * Win32: Add a simple hold console open patch (wait for close or
        the ESC key, with a nice message) if the server died a bad 
        death (non-zero exit code) in console mode.

    * Platforms that do not support fork (primarily Win32 and AS/400)
      Consider introducing HAVE_FORK feature macro. Architect start-up code
      that avoids initializing all the modules in the parent process on
      platforms that do not support fork.

    * Clean the code.  There are a lot of places we used APR but didn't 
      remove the hacks that were required for the cross-platform code in
      1.3.  We need to make the code look like APR was supposed to be there. 

    * Go throught the 1.3 Bug DB and research the bugs marked "suspended".
      People were told these would be considered for inclusion in Apache 2.0,
      it would be nice to actually do so.

    * Win32: Migrate the MPM over to use APR thread/process calls. This
      would eliminate some code in the Win32 branch that essentially
      duplicates what is in APR.

      Bill says we need a new procattr, APR_CREATE_SUSPENDED (or
      something similar) to direct ap_create_process to create the
      process suspended. We also need a call to wake up the suspended 
      process This may not be able to be implemented everywhere though.

        Status: 

    * Move I/O layering into APR.

    * There are still a number of places in the code where we are
      loosing error status (i.e. throwing away the error returned by a
      system call and replacing it with a generic error code)

    * Win32: Implement reliable piped logs on Windows
        Status: 
          
    * Use APR to get rid of more platform dependancies.
        Status: Ryan Bloom <rbb at covalenet.net> is working on this.

    * The connection status table is not very efficient. Also, very few stats
      are exported to the connection status table (easy to fix), and mod_status
      is ugly.

    * Mass vhosting version of suEXEC.

    * Replace tables with a proper opaque ADT that has pluggable
      implementations (including something like the existing data type,
      plus hash tables for speed, with options for more later).
	Status: fanf is working on this.

    * configuration option to use *DBM
      Status: Greg +1 (volunteers)

    * add SDBM into src/lib/sdbm/ as a default/fallback DBM implementation.
      SDBM is used by Perl, mod_dav, mod_sssl, others for basic DBM support.
      Status: Greg +1 (volunteers)

    * Integrate mod_dav.
        Message-id: <20000625173247.M29590 at lyra.org>
        Status: in process.
        - APR does not provide a couple needed things: chmod()
          and ap_finfo_t.st_dev.
	- expat-lite needs to be brought up to parity with the 1.3
	  vsn and inserted into the config/build process
	- SDBM needs to go into the config/build process
	- fix up include dirs to pick up expat-lite, sdbm, dav/main
	- APR-ization to the dav/fs/ stuff
	- case_preserved_filename stuff

    * ap_core_translate() and its use by mod_mmap_static are a bit wonky.
      The function should probably be exposed as a utility function (such
      as ap_translate_url2fs() or ap_validate_fs_url() or something).
      Another approach would be a new hook phase after "translate" which
      would allow mod_mmap_static to munge what the translation has
      decided to do.
        Status: Greg +1 (volunteers), Ryan +1

    * Go through ap_config.h and namespace-protect the symbols (e.g. USE_*).
      Some symbols can/should move to mpm_common.h where possible.

    * Explore use of a post-config hook for the code in http_main.c which
      calls ap_fixup_virutal_hosts(), ap_fini_vhost_config(), and
      ap_sort_hooks()  [to reduce the logic in main()]

    * read the config tree just once, and process N times (as necessary)

    * add a version number to ap_initialize() as an extra failsafe against
      (APR) library version skew.
      MsgID: <Pine.LNX.4.10.10005231712380.31927-100000 at nebula.lyra.org>
      Status: Greg +1 (volunteers), Jeff +1, Ryan +1, Tony -0(?)

    * mod_info to use the configuration tree

    * add output filtering. there are a couple variants for this.
      - The "link-based" variant is ready to go:
        MsgID: <20000627044436.N29590 at lyra.org>   (patch)
	MsgID: <20000627053302.O29590 at lyra.org>   (demo usage)
	MsgID: <Pine.LNX.4.21.0006270731240.4006-100000 at koj.rkbloom.net>
                             (problems with the patch)
        Status: Greg +1, Ryan -1
        

Other bugs that need fixing:

    * MaxRequestsPerChild measures connections, not requests.
        Until someone has a better way, we'll probably just rename it
        "MaxConnectionsPerChild".
    
    * Regex containers don't work in an intutive way
        Status: No one has come up with an efficient way to fix this
        behavior. Dean has suggested getting rid of regex containers
        completely.

    * SIGSEGV on Linux (glibc 2.1.2) isn't caught properly by a
      sigwaiting thread. We need to work around this, perhaps unless
      there is hope soon for a fixed glibc.

    * The mod_cgid daemon process isn't always cleaned up when httpd
      gets SIGTERM.  Jeff thinks it may be as simple as registering
      the daemon process for cleanup with the proper pool, but he hasn't
      looked at it in enough detail.

    * The MM library is built as static and shared library. This should
      be set up to build only the required version.

Other features that need writing:

    * Finish infrastructure in core for async MPMs
        Status: post 2.0

    * TODO in source -- just do an egrep on "TODO" and see what's there

Documentation that needs writing:
    * Mod_status docs are needed.

    * The concept of MPMs, especially if we ship more than one MPM for a
      given platform

    * New directives in the various MPMs and appropriate links from
	obsolete directives in core.html to the MPM documentation.

    * Revise manual/stopping.html and the last part of
	manual/misc/perf-tuning.html to take account of the MPMs.

    * API documentation
        Status: Ben Laurie has written some hooks documentation
        (apache-2.0/htdocs/hooks.html)

    * Changes since 1.3.9 can be more easily seen in the commitlog file
         dev.apache.org:/home/cvs/CVSROOT/commitlogs/apache-2.0
      which includes some of Roy's comments when the changes were
      committed in rough change-sets by purpose.  Note that the commitlog
      does not show the contents of new files until later.

    * mod_dav documentation (once integrated)

Available Patches:

   * Mike Abbott's <mja at trudge.engr.sgi.com> patches to improve
     performance
       Status: These were written for 1.3, and are awaiting a port to
       2.0
 
   * Jim Winstead's <jimw at trainedmonkey.com> patch to add CookieDomain and 
     other small mod_usertrack features

Open issues:

   * What do we do about mod_proxy?

   * Which MPMs will be included with Apache 2.0?

   * Is conf/highperformance.conf-dist obsolete?  It looks obsolete.




From fredrik at pythonware.com  Thu Jun 29 16:11:26 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 16:11:26 +0200
Subject: [Python-Dev] Text about cycle GC
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net>             <20000628122725.A13473@acs.ucalgary.ca>  <200006282059.PAA04852@cj20424-a.reston1.va.home.com>
Message-ID: <016a01bfe1d3$ea2474b0$0900a8c0@SPIFF>

guido wrote:
> I wonder if we should turn this option *on* during beta testing?

+1 from me.

> That way we gather a lot more experience with its use!  Maybe nobody
> complains and we can leave it on in the final release...

I won't mind (unless it breaks my code, of course).

</F>




From mal at lemburg.com  Thu Jun 29 16:10:28 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 16:10:28 +0200
Subject: [Python-Dev] re: ucnhash
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50>
Message-ID: <395B58D4.E52CBBD6@lemburg.com>

Bill Tutt wrote:
> 
> Re: ucnhash and where the stuff gets tested
> 
> Doesn't matter to me where the test goes.

I'm currently trying to check these changes in... doesn't work
though due to some obscure CVS locks.
 
> WRT how big it is, thats why its dynamically loaded at run time.
> If you don't compile it at all, then the \N{...} syntax just won't owrk.
> 
> Re: static vs. staticforward
> I can actually do a patch for that, and regen ucnhash.c for you.

Someone (Fred ?) already patches those places for you. He didn't
send patches for the perfect hash tool though.
 
> Re: "" vs. <>
> Whats wrong with what I'm currently doing?

<> uses a differnt header file lookup path... normally doesn't
hurt, but...
 
> All of the .h files I'm including are on the include file path. "" usage
> just means stick "." before everything else in your include path.
> None of the files need that. :) If there's a diffferent policy in the Python
> source 'bout that that I'm not aware of, then I can fix that issue too.

... you already know that ;-)

Again, these are already fixed :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at beopen.com  Thu Jun 29 17:15:09 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 10:15:09 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: Your message of "Thu, 29 Jun 2000 09:27:01 -0400."
             <1249837203-44011365@hypernet.com> 
References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com>  
            <1249837203-44011365@hypernet.com> 
Message-ID: <200006291515.KAA10374@cj20424-a.reston1.va.home.com>

> [Gordon] 
> > > Looking at CVS, my stuff was there in filecmp revision 1.2
> > > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the
> > > following day.
> [Guido]
> > Argh!  An inappropriate side effect of Ping's cleanup -- thanks
> > for catching this.  Apparently Ping didn't do a CVS update before
> > generating his diffs.
> > 
> > I can restore version 1.2 easily, but I'm not sure what to do
> > with /F's changes (1.3 -> 1.4).  Gordon, can you look at this and
> > suggest what to do?

[Gordon]
> If you have the eff-bot's diff, it should apply to 1.2 (my changes 
> are all below there - basically I added a rewritten dircmp). I 
> think a CVS merge would do the right thing, too.

There was a change in indent style, so effbot's diff didn't apply
cleanly -- but your suggestion made me realize that it was easy to
re-apply manually.

It's all fixed now.  Thanks all!

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



From mal at lemburg.com  Thu Jun 29 16:15:23 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 16:15:23 +0200
Subject: [Python-Dev] CVS locks on SF
References: <395B5030.C0F08E82@lemburg.com> <200006291503.KAA10324@cj20424-a.reston1.va.home.com>
Message-ID: <395B59FB.1CD472AE@lemburg.com>

Guido van Rossum wrote:
> 
> > I'm getting loads of lock messages during CVS checkins recently.
> > Is this due to overload ? (I wonder why anoncvs access causes
> > locking at all -- there is no write access so why should there
> > be file locking ?):
> 
> I haven't seen this myself.  Could be you were just unlucky.  Could be
> someone was doing a full checkout over a slow connection.
> 
> I think the anon checkouts still use (read) locks because they need to
> get a consistent version.

Looks like someone is using a 9.6kBaud mobile phone connection ;-)
The problem still persists and I've been trying for about
half an hour now.

I'll try again later today...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at beopen.com  Thu Jun 29 17:21:47 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 10:21:47 -0500
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: Your message of "Thu, 29 Jun 2000 06:52:21 MST."
             <395B5495.CF274583@prescod.net> 
References: <200006291331.PAA21571@python.inrialpes.fr>  
            <395B5495.CF274583@prescod.net> 
Message-ID: <200006291521.KAA10440@cj20424-a.reston1.va.home.com>

> Won't we have a clear picture by the end of the beta period?

Not clear.  Unfortunately, few people who run important apps will
download a beta and try it.  But they *will* download a new release
labeled "final" and install it without making sure it works for their
app.  This has been my experience throughout Python's life.  I've
become pretty conservative about staying backwards compatible as a
result...

> > The "optional experimental feature" label is good and IMO it complies
> > with anybody's expectations. Interested people will jump in and will
> > eventually contribute with improvements, those who don't care won't
> > and will live happily without it (at least until the day the feature
> > and its implementation reach their expected maturity).
> 
> A million Window users will live unhappily without it because they don't
> know how to recompile to get it!

This can be solved the way we solve everything for Windows users: give
them two distributions to choose from -- or maybe one distribution
with a checkbox to choose which version to use.

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



From skip at mojam.com  Thu Jun 29 15:38:20 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 08:38:20 -0500 (CDT)
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
References: <20000628025304.BB64A1CE0D@dinsdale.python.org>
	<PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <14683.20812.615266.196934@beluga.mojam.com>

    Andy> How many people here have actually created accounts for themselves
    Andy> on SourceForge and tried to do stuff when logged in - raise bugs
    Andy> and so on?  Did it work for you?

I've submitted a few patches with no problems.  My usual connections are a
corporate T1-ish connection or cable modem access from home, however.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From jeremy at beopen.com  Thu Jun 29 16:45:27 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 29 Jun 2000 10:45:27 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com>
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
	<395ACED5.83764D45@prescod.net>
	<20000629082519.A13839@newcnri.cnri.reston.va.us>
	<14683.21672.414396.364125@cj42289-a.reston1.va.home.com>
Message-ID: <14683.24839.650558.23732@bitdiddle.concentric.net>

>>>>> "FLD" == Fred L Drake, <fdrake at beopen.com> writes:

  FLD> Andrew Kuchling writes:
  >> That's a patch I made to the Makefile and submitted to James
  >> Clark.  For Modules/Setup.in, I can change it to explicitly list
  >> the 8 files from Expat that need to be linked to.  The problem is
  >> that one of the

  FLD>   It's not in the stable version I picked up last night; I'll
  FLD> dig up the experimental version today.

I downloaded version 1.1 from the expat home page.  The URL for the
download is ftp://ftp.jclark.com/pub/xml/expat.zip.  This version
hasn't changed in the last two weeks. 

The instructions Fred include worked almost just right.  I checked in
the corrected ar command and it looks good.

Jeremy



From fdrake at beopen.com  Thu Jun 29 16:46:48 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 10:46:48 -0400 (EDT)
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <200006291503.KAA10324@cj20424-a.reston1.va.home.com>
References: <395B5030.C0F08E82@lemburg.com>
	<200006291503.KAA10324@cj20424-a.reston1.va.home.com>
Message-ID: <14683.24920.264911.840500@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > I think the anon checkouts still use (read) locks because they need to
 > get a consistent version.

  Yes; you need a directory lock to avoid files getting modified or
deleted underneath you while checking out/updating.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Thu Jun 29 16:48:38 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 10:48:38 -0400 (EDT)
Subject: [Python-Dev] re: ucnhash
In-Reply-To: <395B58D4.E52CBBD6@lemburg.com>
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50>
	<395B58D4.E52CBBD6@lemburg.com>
Message-ID: <14683.25030.205960.13328@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Someone (Fred ?) already patches those places for you. He didn't
 > send patches for the perfect hash tool though.

  Not this Fred...


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Thu Jun 29 16:52:28 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 10:52:28 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <14683.24839.650558.23732@bitdiddle.concentric.net>
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
	<395ACED5.83764D45@prescod.net>
	<20000629082519.A13839@newcnri.cnri.reston.va.us>
	<14683.21672.414396.364125@cj42289-a.reston1.va.home.com>
	<14683.24839.650558.23732@bitdiddle.concentric.net>
Message-ID: <14683.25260.182929.808330@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > The instructions Fred include worked almost just right.  I checked in
 > the corrected ar command and it looks good.

  That's what I get for typing in the dark on a dark keyboard.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Thu Jun 29 18:23:54 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 12:23:54 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <395b1528.5978476@smtp.worldonline.dk>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>

[posted & mailed]

[Tim]
> id() has to return a unique value.

[Finn Bock]
> This property of id() does not hold in JPython. When used with hotspot,
> id() is not unique.

So it's possible there for one of these be true:

    id(x) == id(y) and x is not y
    id(x) != id(x)

?  Then that's a bug in JPython or hotspot.  Know which?  Filed a bug
report?

In CPython, we just use the address of an object's header, and as CPython
never moves an object's header in memory, the good stuff follows trivially.
Don't know what JPython tries to do, but it's bound to be harder there (as
Java can move memory around).





From bckfnn at worldonline.dk  Thu Jun 29 18:43:09 2000
From: bckfnn at worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 16:43:09 GMT
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>
Message-ID: <395b79a7.31704869@smtp.worldonline.dk>

[Tim]

>So it's possible there for one of these be true:
>
>    id(x) == id(y) and x is not y
>    id(x) != id(x)
>
>?

Yes, the first.


d = {}
cnt = 0

for i in xrange(100000):
    s = "test" + `i`
    j = id(s)
    if d.has_key(j):
        cnt = cnt + 1
    d[j] = s

print cnt, "failures"

Will print 500+ failures when run by JPython & JDK1.3 on win2k.

>Then that's a bug in JPython or hotspot.  Know which?

JPython.

> Filed a bug report?

Years ago <wink>:
  http://www.python.org/jpython-bugs/incoming?id=118

>In CPython, we just use the address of an object's header, and as CPython
>never moves an object's header in memory, the good stuff follows trivially.
>Don't know what JPython tries to do, but it's bound to be harder there (as
>Java can move memory around).

That is also my guess. I cannot see what we can do about it, except inform
users that not all python platform behave exactly the same. Which is why I
brought it up.

regards,
finn



From trentm at activestate.com  Thu Jun 29 18:42:56 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 09:42:56 -0700
Subject: [Python-Dev] arraymodule still broken?
In-Reply-To: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid>
References: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid>
Message-ID: <20000629094256.A21926@activestate.com>

On Thu, Jun 29, 2000 at 12:21:22PM +0200, Fredrik Lundh wrote:
> just checked everything out and rebuilt, the exceptions
> problem sure disappeared, but I still get this error:
> 
> >>> import array
> >>> array.array("H", [60000])
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> OverflowError: signed short integer is greater than maximum
> 
> second opinion, anyone?
> 

I think this is because we are in the middling state where all of my patches
have not gotten in yet. I say this because this is what I get with my version
that has all of my patches applied:

Python 1.6a2 (#1, Jun 29 2000, 09:28:15)  [GCC egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> import array
>>> array.array("H", [60000])
array('H', [60000])
>>>


Specifically, I haven't looked for the issue. Is it alright if I look at this
this weekend?


Trent


-- 
Trent Mick
trentm at activestate.com



From trentm at activestate.com  Thu Jun 29 18:53:43 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 09:53:43 -0700
Subject: [Python-Dev] build problems under MSVC 5.0
In-Reply-To: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid>
References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid>
Message-ID: <20000629095343.B21926@activestate.com>

On Thu, Jun 29, 2000 at 12:07:42PM +0200, Fredrik Lundh wrote:
> Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier
> Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv'
> Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier
> Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type'
> Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier
> 
This is a result of one of my patches. I was using MSVC 6.0, where INT_PTR is
defined as you would expect. I did not realize that it was new to that
version of the headers.

BTW, INT_PTR, UINT_PTR, etc are the standard defines that I saw Microsoft
suggesting in their Win64 docs. I don't like those names, because they are
not portable. I should have used the (ANSI?) equivalents: intptr_t,
uintptr_t. In fact, I *did* use those in some of my patches where the code
portability was required (as obviously it is not in thread_*nt*.h).


> in MSVC 5.0, _beginthread returns an "unsigned long" (this is also
> how it's documented in MSDN).

Yup. And in the Win64 headers _beginthread returns uintptr_t, which makes me
wonder why I picked INT_PTR.


> 
> I suggest changing the declaration in thread_nt.h to:
> 
> #if _MSC_VER >= 1200
>  INT_PTR rv;
> #else
>  unsigned long rv;
> #endif
> 

As I said above, I acknowledge that I should not have used INT_PTR.
Win32: unsigned long _beginthread()
Win64: uintptr_t _beginthread()

I think (am I wrong?) to generalize that the intention for both Win32 and
Win64 is to have _beginthread return an unsigned pointer-sized integer: hence
uintptr_t.

This would eliminate the #ifdef but would require a typedef for uintptr_t on
Win32. This can be done in PC/config.h (I already did this for intptr_t,
because I needed *that* elsewhere.) Does this also need to be generalized to
typedef uintptr_t whereever it is not defined, i.e. in the autoconf files.

I can look at this this weekend, if that is soon enough.



> on the other hand, the same docs claim that it returns -1 on errors.
> doesn't exactly look like an unsigned long to me, but that's another
> story...
> 

Yes, strange.



Trent

-- 
Trent Mick
trentm at activestate.com



From effbot at telia.com  Thu Jun 29 19:07:02 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 19:07:02 +0200
Subject: [Python-Dev] build problems under MSVC 5.0
References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> <20000629095343.B21926@activestate.com>
Message-ID: <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid>

trent wrote:
> I think (am I wrong?) to generalize that the intention for both Win32 and
> Win64 is to have _beginthread return an unsigned pointer-sized integer: hence
> uintptr_t.
> 
> This would eliminate the #ifdef but would require a typedef for uintptr_t on
> Win32. This can be done in PC/config.h (I already did this for intptr_t,
> because I needed *that* elsewhere.) Does this also need to be generalized to
> typedef uintptr_t whereever it is not defined, i.e. in the autoconf files.
> 
> I can look at this this weekend, if that is soon enough.

I suggest checking in the #ifdef as a stopgap measure, if you
promise to come up with the right thing (whatever that is) in
time for 1.6 final.

Should I go ahead and check it in?

</F>




From tim_one at email.msn.com  Thu Jun 29 19:15:08 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 13:15:08 -0400
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <395B5030.C0F08E82@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com>

[MAL]
> I'm getting loads of lock messages during CVS checkins recently.
> Is this due to overload ? (I wonder why anoncvs access causes
> locking at all -- there is no write access so why should there
> be file locking ?):

IIRC, CVS maintains the illusion of being a multi-user system by using
per-*directory* locks.  That means it gives you the warm fuzzy feeling that
you're being protected against (e.g.) getting an inconsistent snapshot while
someone else is committing, but in fact you're not protected at all
(inter-directory).  It locks per-directory to ensure the integrity of its
own data files, but users are subject to the luck of the draw.

Note that Perl is maintained under (the commercial, alas) Perforce, which is
one of the few SCMs to take multi-developer multi-directory issues
seriously.

So the good news is that when you see a CVS lock gripe, that means CVS is
protecting itself from corruption.  The bad news is that if we used a system
that protected *us* against inconsistencies too, we'd probably see lock
gripes even more often.





From gmcm at hypernet.com  Thu Jun 29 19:19:51 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 29 Jun 2000 13:19:51 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>
References: <395b1528.5978476@smtp.worldonline.dk>
Message-ID: <1249823239-44851587@hypernet.com>

[Finn Bock]
> > This property of id() does not hold in JPython. When used with
> > hotspot, id() is not unique.
[Tim] 
> So it's possible there for one of these be true:
> 
>     id(x) == id(y) and x is not y
>     id(x) != id(x)
> 
> ?  Then that's a bug in JPython or hotspot.  Know which?  Filed a
> bug report?

Oh, you silly boy. There are (by definition) no bugs in hotspot.

it's-only-'cause-Guido's-a-weenie-that-Python-has-'em-ly y'rs

- Gordon



From tim_one at email.msn.com  Thu Jun 29 19:44:45 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 13:44:45 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <395b79a7.31704869@smtp.worldonline.dk>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>

[Finn Bock, says id() is buggy under JPython]

[Tim]
>> Filed a bug report?

[Finn]
> Years ago <wink>:
>   http://www.python.org/jpython-bugs/incoming?id=118

>> In CPython, we just use the address of an object's header, and as CPython
>> never moves an object's header in memory, the good stuff follows
>> trivially.  Don't know what JPython tries to do, but it's bound to be
>> harder there (as Java can move memory around).

> That is also my guess. I cannot see what we can do about it, except
> inform users that not all python platform behave exactly the same. Which
> is why I brought it up.

Well, neither Java's hashCode nor identityHashCode are correct
implementations of Python's id(), so JPython's id() is simply wrong.  I
don't know anything about the internals of JPython.  If there's a "choke
point" for allocating Python objects, the quickest way out may be to add a
write-once "id" field to each Python object under JPython, and simply fill
it with an integer that's (safely) incremented by 1 on each allocation.

Python doesn't guarantee you'll get the *same* id(x) across implementations,
or even across runs under a single implementation, so the implementations of
id() in CPython and JPython can do entirely different things.  They have to
meet the promises in the Python docs, though, and JPython's currently
doesn't.






From effbot at telia.com  Thu Jun 29 19:51:32 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 19:51:32 +0200
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org>
Message-ID: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>

greg wrote:
> I think you are being paranoid :-)
> 
> Consider that this same issue applies to all 5900 projects and 38000
> developers at SourceForge. VA Linux has a brand identity entirely built on
> the trust and support of the Linux (and Open Source) communities. If they
> blow away that trust, they are simply screwed.

on the other hand, lots of people thought that dejanews
would store usenet postings forever...

http://salon.com/tech/log/2000/06/20/deja/index.html

</F>




From pingster at ilm.com  Thu Jun 29 19:47:13 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 10:47:13 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.SGI.3.96.1000629104223.621134m-100000@happy>

On Thu, 29 Jun 2000, Guido van Rossum wrote:
> 
> Argh!  An inappropriate side effect of Ping's cleanup -- thanks for
> catching this.  Apparently Ping didn't do a CVS update before
> generating his diffs.

My apologies!  I'm pretty sure i did an update, but i must have
left too long a gap during which 1.2 got checked in.  You'd think
somehow a version-control system would have noticed the inconsistency
between ancestor versions...

Anyway, very sorry for the trouble.  Glad it appears to be cleared
up now.


-- ?!ng




From effbot at telia.com  Thu Jun 29 19:56:02 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 19:56:02 +0200
Subject: [Python-Dev] id() on Win64
References: <20000628160743.A16262@acs.ucalgary.ca>
Message-ID: <027101bfe1f3$4d478ae0$f2a6b5d4@hagrid>

neil wrote:
> [Greg Stein]
> >Strictly speaking: the Long only occurs on Win64 platforms.
> >
> >I would guess that it is also possible on say, an Alpha running
> >Linux.  Presuming that has 64-bit pointers(?).
> 
> I think the Alpha is okay. The problem is strange type models
> were int is 32 bits and pointers are 64.  AFAIK, the Alpha uses
> 64 bits for both.

is this true for linux alpha too?

it's definitely true for tru64; we've been using python
extensively on that platform since 1995:
http://www.smhi.se/weather/satelitbilder/satellitbilder.htm
(in swedish, but I suppose you all can figure out what
it is anyway ;-)

</F>




From gward at mems-exchange.org  Thu Jun 29 19:55:25 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 13:55:25 -0400
Subject: [Python-Dev] Test results of linuxaudiodev.c
Message-ID: <20000629135525.A5221@ludwig.cnri.reston.va.us>

Hi --

here are results from testing linuxaudiodev from the latest CVS Python
1.6.  This is on a Dell Dimension with on-board audio hardware: the
Yamaha YMF724 chipset.  I'm using the ALSA 0.5.8a driver (the latest as
of a week or two ago, and the only one that supports the YMF724).

Bottom line: the test sound plays, but it sounds horrible when played by 
linuxaudiodev.  If I do this:

  $ play Lib/test/audiotest.au

then Cardinal Fang comes through loud and clear.  ("play" is a shell
script wrapper for "sox", writing to /dev/dsp.)  But if I do this:

  $ ./python Lib/test/regrtest.py test_linuxaudiodev

he's still audible (and at the same volume), but very scratchy.  Sounds
kind of like a very over-driven amp, or like a cheap car radio that
somebody attacked with a knife.

[...some time passes...]

OK, I just tried it on another machine, also a Dell but with a different
sound chip: the Crystal CS4232.  I'm pretty sure this one is using the
OSS drivers included with the kernel, which is probably the second most
important difference after the chipset itself.  Bottom line: it also
sounds horrible.

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From bwarsaw at beopen.com  Thu Jun 29 19:57:27 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 13:57:27 -0400 (EDT)
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
References: <395b79a7.31704869@smtp.worldonline.dk>
	<LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>
Message-ID: <14683.36359.864478.495915@anthem.concentric.net>

>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:

    TP> Well, neither Java's hashCode nor identityHashCode are correct
    TP> implementations of Python's id(), so JPython's id() is simply
    TP> wrong.  I don't know anything about the internals of JPython.
    TP> If there's a "choke point" for allocating Python objects, the
    TP> quickest way out may be to add a write-once "id" field to each
    TP> Python object under JPython, and simply fill it with an
    TP> integer that's (safely) incremented by 1 on each allocation.

    TP> Python doesn't guarantee you'll get the *same* id(x) across
    TP> implementations, or even across runs under a single
    TP> implementation, so the implementations of id() in CPython and
    TP> JPython can do entirely different things.  They have to meet
    TP> the promises in the Python docs, though, and JPython's
    TP> currently doesn't.

I can't generate patches right now, but what you need to change is in
__builtin__.java, the id() function.  It should probably call
object.id() which would fill in the monotonically incrementing id as
Tim suggestions.

One question is what to do about Java proxies.  Currently built-in
id() returns the identityHashCode() of the proxy object, which is just
an Object.  I'm not sure sticking the id in the wrapper is the right
thing or not.

-Barry



From effbot at telia.com  Thu Jun 29 20:18:26 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 20:18:26 +0200
Subject: [Python-Dev] Re: sourceforge data (was: Let's use the SourceForge Patch Manager)
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> <20000629110557.W29590@lyra.org>
Message-ID: <02d901bfe1f6$720ca920$f2a6b5d4@hagrid>

greg wrote:
> > on the other hand, lots of people thought that dejanews
> > would store usenet postings forever...
> 
> Different problem space. They weren't holding people's data.

well, they dropped a few thousand eff-bot postings ;-)

> Worrying about it is a useless exercise, IMO.

well, I'm not worried.  but in the internet universe, strange
things happen all the time...

(checked out http://www.fuckedcompany.com/ lately?)

...

btw, has anyone checked what's in:
http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz 

(with ping times somewhere around one second, it's too
large for me to check out...)

</F>




From effbot at telia.com  Thu Jun 29 20:05:34 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 20:05:34 +0200
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <20000628113505.C15643@ludwig.cnri.reston.va.us>
Message-ID: <02cd01bfe1f4$a271cca0$f2a6b5d4@hagrid>

greg wrote:


> On 28 June 2000, Fredrik Lundh said:
> > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt
> > 
> > unfortunately, his "What is it with those Python fucks anyway" talk
> > isn't posted... ;-)
> 
> But the "Conclusion" of his "Lies We Tell" talk:
> 
>    Perl sucks. Use Python.
> 
> Presumably tongue-in-cheek, but you never know...

note that all lies he mentioned earlier in that talk
was quoted; this one wasn't.  in other words, it's
a fact.  but we already know that, don't we ;-)

</F>




From bwarsaw at beopen.com  Thu Jun 29 20:56:52 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 14:56:52 -0400 (EDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
References: <20000629135525.A5221@ludwig.cnri.reston.va.us>
Message-ID: <14683.39924.477408.233069@anthem.concentric.net>

>>>>> "GW" == Greg Ward <gward at mems-exchange.org> writes:

    GW> then Cardinal Fang comes through loud and clear.  ("play" is a
    GW> shell script wrapper for "sox", writing to /dev/dsp.)  But if
    GW> I do this:

    GW>   $ ./python Lib/test/regrtest.py test_linuxaudiodev

    GW> he's still audible (and at the same volume), but very
    GW> scratchy.  Sounds kind of like a very over-driven amp, or like
    GW> a cheap car radio that somebody attacked with a knife.

I don't even get that.  play works fine for me too, but on this Dell
Optiplex GX110 with unknown sound chip set, test_linuxaudiodev gives
me nothing.

-Barry



From gstein at lyra.org  Thu Jun 29 20:05:57 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 11:05:57 -0700
Subject: [Python-Dev] sourceforge data (was: Let's use the SourceForge Patch Manager)
In-Reply-To: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>; from effbot@telia.com on Thu, Jun 29, 2000 at 07:51:32PM +0200
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>
Message-ID: <20000629110557.W29590@lyra.org>

On Thu, Jun 29, 2000 at 07:51:32PM +0200, Fredrik Lundh wrote:
> greg wrote:
> > I think you are being paranoid :-)
> > 
> > Consider that this same issue applies to all 5900 projects and 38000
> > developers at SourceForge. VA Linux has a brand identity entirely built on
> > the trust and support of the Linux (and Open Source) communities. If they
> > blow away that trust, they are simply screwed.
> 
> on the other hand, lots of people thought that dejanews
> would store usenet postings forever...

Different problem space. They weren't holding people's data.

If SourceForge were ever to close, then I have 100% faith that they would
make sure to provide a way for everybody to get their data off the machines.

Worrying about it is a useless exercise, IMO.

Cheers,
-g

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



From guido at beopen.com  Thu Jun 29 21:05:11 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 14:05:11 -0500
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: Your message of "Thu, 29 Jun 2000 13:15:08 -0400."
             <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com> 
Message-ID: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>

> [MAL]
> > I'm getting loads of lock messages during CVS checkins recently.
> > Is this due to overload ? (I wonder why anoncvs access causes
> > locking at all -- there is no write access so why should there
> > be file locking ?):
> 
> IIRC, CVS maintains the illusion of being a multi-user system by using
> per-*directory* locks.  That means it gives you the warm fuzzy feeling that
> you're being protected against (e.g.) getting an inconsistent snapshot while
> someone else is committing, but in fact you're not protected at all
> (inter-directory).  It locks per-directory to ensure the integrity of its
> own data files, but users are subject to the luck of the draw.

Yes, that's how it works...

> Note that Perl is maintained under (the commercial, alas) Perforce, which is
> one of the few SCMs to take multi-developer multi-directory issues
> seriously.

We tried Perforce at CNRI.  It's really neat, but somehow it was
lacking some stuff we were used to and we never converted.

Note that Perforce is free for open source projects -- at least at the
time it was.  (CNRI paid a license fee, but that was just an
expression of CNRI's reluctance against free software. :-)

There's also bitkeeper.  It stayed in beta so long that we gave up
(and they have a weird license) -- but it's out of beta since May 4:
see http://www.bitkeeper.com/.  But there's no immediate download!
You must sign up and they send you instructions in the mail...

> So the good news is that when you see a CVS lock gripe, that means CVS is
> protecting itself from corruption.  The bad news is that if we used a system
> that protected *us* against inconsistencies too, we'd probably see lock
> gripes even more often.

Well, the implementation could save the previous consistent version
and give you that while an update was under way...  There are other
ways to protect against inconsistencies.  But I'm not sure that you
always *want* this -- as a system grows, it's better to be able to
deal with inconsistencies than to try to avoid them (and have the
world blow up in your face when the avoidance fails).

Anyway, I submitted a service request to have the lock in the Lib/test
lock removed.  (Apparently some process didn't clear up its lock.
That's rare, but sometimes it happens.)  It's been fixed now, so
checkins in the Lib/test directory should move forward again.

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



From bckfnn at worldonline.dk  Thu Jun 29 21:15:45 2000
From: bckfnn at worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 19:15:45 GMT
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>
Message-ID: <395b9f71.41379240@smtp.worldonline.dk>

[Tim]

>Well, neither Java's hashCode nor identityHashCode are correct
>implementations of Python's id(), so JPython's id() is simply wrong. 

I agree.

>I don't know anything about the internals of JPython.  If there's a "choke  
>point" for allocating Python objects, 

The constructor of PyObject should do nicely.

>the quickest way out may be to add a
>write-once "id" field to each Python object under JPython, and simply fill
>it with an integer that's (safely) incremented by 1 on each allocation.

Properly have to be a java long to avoid overflowing.

>Python doesn't guarantee you'll get the *same* id(x) across implementations,
>or even across runs under a single implementation, so the implementations of
>id() in CPython and JPython can do entirely different things.  They have to
>meet the promises in the Python docs, though, and JPython's currently
>doesn't.

I haven't considered it to be so important. It is possible to fix the std
modules so it doesn't cause problems (as is done in cPickle.java). 

[Barry]

>One question is what to do about Java proxies.  Currently built-in
>id() returns the identityHashCode() of the proxy object, which is just
>an Object.  I'm not sure sticking the id in the wrapper is the right
>thing or not.

It properly isn't. New wrappers can be created for the same object. F.ex
when a java object is passed from python into java code and returned back
into python, two wrappers will exists for the same java object. Since these
two wrappers represent the same object they should (as it does now) return
the same id() value.

regards,
finn



From bwarsaw at beopen.com  Thu Jun 29 21:23:48 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 15:23:48 -0400 (EDT)
Subject: [Python-Dev] Re: sourceforge data (was: Let's use the SourceForge Patch Manager)
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>
	<395A32FD.D3C58B23@prescod.net>
	<20000628173424.H29590@lyra.org>
	<025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>
	<20000629110557.W29590@lyra.org>
	<02d901bfe1f6$720ca920$f2a6b5d4@hagrid>
Message-ID: <14683.41540.530581.459708@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <effbot at telia.com> writes:

    FL> btw, has anyone checked what's in:
    FL> http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz 

I suck down nightly copies of that file and the corresponding Mailman
tarball.  I looked at them when I first set up my script, but haven't
checked them lately.

-Barry



From nascheme at enme.ucalgary.ca  Thu Jun 29 22:02:02 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 29 Jun 2000 14:02:02 -0600
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com> <200006291905.OAA17265@cj20424-a.reston1.va.home.com>
Message-ID: <20000629140201.A20446@acs.ucalgary.ca>

I recently made the conversion from CVS to PRCS.  I like PRCS
much better.  It is easier to use, implemented indepentant of
rcs, faster, more flexible and has versioned project meta-data.
Branching and merging is much simpiler than CVS.  Operations on
project versions are atomic.  Renaming and moving files is easy.
It is well documented.

Unfortunately version 1 does not support distributed
repositories.  Josh has informed my that version to is coming
(hopefully this year) and will support distributed repositories.

For Python I don't think that a multi-user version control system
is strictly necessary anyhow.  The PRCS repository could be made
available via rsync and a process could be setup for checking
patches into the central repository.  It should actually be more
efficient than the current CVS setup.

I just looked at the webpage and the beta for 2.0 is out:

    http://www.xcf.berkeley.edu/~jmacd/prcs.html

If PythonLabs is interested in using PRCS I will even volunteer
to make sure those Windows weenies have a good port. :)

  Neil




From jeremy at beopen.com  Thu Jun 29 22:40:14 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 29 Jun 2000 16:40:14 -0400 (EDT)
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <20000629140201.A20446@acs.ucalgary.ca>
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com>
	<200006291905.OAA17265@cj20424-a.reston1.va.home.com>
	<20000629140201.A20446@acs.ucalgary.ca>
Message-ID: <14683.46126.19856.447975@bitdiddle.concentric.net>

I was just looking at Josh's work last week, and thought it looks
quite interesting.  Despite my interest, I don't expect we would use
it for Python unless SourceForge adopted it.  We moved the Python CVS
tree to SourceForge to avoid maintaing a large installation of
software development/management tools.

Jeremy



From klm at digicool.com  Thu Jun 29 22:53:21 2000
From: klm at digicool.com (Ken Manheimer)
Date: Thu, 29 Jun 2000 16:53:21 -0400 (EDT)
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEBPGHAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>

On Thu, 29 Jun 2000, Tim Peters wrote:

> > ...
> > Hmm. Is there a good place to start listing these todo items?
> 
> Not that I know of.  "Group whiteboards" and shared journals etc are darned
> useful, though.

Wiki = Group whiteboard

Zope could do a lot of this stuff well.  As is, ZWiki offers some
organizational features.  I've held off on pushing them because they're
still baking - things like change notifications, discretion about change
privileges, versions (with differences, based on your ndiff.py), etc are
coming soonish.  (Exactly how soonish is hard to say, the way time and
more direct business obligations are - but this stuff actually is
important to us, we're using them a lot for collaboration, and need for
the dynamics to scale...)

I also have the feeling that our tracker would be good for patch
management - except, i don't really know what the requirements are, there,
and once again, tracker only gives notifications via email, it doesn't
take input that way.

Anyway, to see leads on both zwikis and tracker, see:

  http://www.zope.org/Members/klm/TrackerWiki

Oh, and it would be easy to set up a wiki for python dev on zope.org
somewhere - i could put it in my account, or we could situate one more
centrally, in a storage that's never packed, so the version history is
maintained.  Or any of you could get a zope.org membership and set some
up, yerselves.  Or set up a zope somewhere - it'd be !cool! if sourceforge
were willing...

Ken
klm at zope.org




From klm at digicool.com  Thu Jun 29 23:25:55 2000
From: klm at digicool.com (Ken Manheimer)
Date: Thu, 29 Jun 2000 17:25:55 -0400 (EDT)
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>
Message-ID: <Pine.LNX.4.21.0006291723370.4495-100000@korak.digicool.com>

On Thu, 29 Jun 2000, Ken Manheimer wrote:

> Wiki = Group whiteboard
> [...]
> Oh, and it would be easy to set up a wiki for python dev on zope.org
> somewhere - i could put it in my account, or we could situate one more

http://www.zope.org/Members/klm/PythonDev/TodoLists

There's nothing else of substance there, but anyone who's a member at
zope.org can edit and add pages...

Ken




From guido at python.org  Fri Jun 30 01:25:09 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 29 Jun 2000 18:25:09 -0500
Subject: [Python-Dev] New PythonLabs site revealed!
Message-ID: <200006292325.SAA19744@cj20424-a.reston1.va.home.com>

Today, without much fanfare, we opened the new PythonLabs website.
The design is by BeOpen's creative Director, Jun Simmons.  Thanks to
Jeremy Hylton, who did most of the actual HTML editing to get our
contents in place.

The new beta will be released via this site.

And since you python-dev folks will find this out through my checkins
anyway, let this be an advance warning that it will be called Python
2.0.  Here's my explanation for the version bump (soon to be checked
in to README):

"""
While Pythoneers have grown fond of Python's exceedingly slow version
incrementing, that same quality makes parts of the rest of the world
think Python is barely out of its first alpha test.  Especially
enterprise customers are often fearful of anything that's version 1.x!
The new version number also clearly marks Python's departure from
CNRI.

Previously, the version number 2.0 was associated with a mythical and
elusive incompatible future release.  That release (still ways off,
and not as incompatible as people fear!) is now referred to as Python
3000.
"""

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



From mwh21 at cam.ac.uk  Fri Jun 30 00:53:39 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 29 Jun 2000 23:53:39 +0100
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: Greg Ward's message of "Thu, 29 Jun 2000 13:55:25 -0400"
References: <20000629135525.A5221@ludwig.cnri.reston.va.us>
Message-ID: <m33dlw85fw.fsf@atrus.jesus.cam.ac.uk>

Greg Ward <gward at mems-exchange.org> writes:

> Hi --
> 
> here are results from testing linuxaudiodev from the latest CVS Python
> 1.6.  This is on a Dell Dimension with on-board audio hardware: the
> Yamaha YMF724 chipset.  I'm using the ALSA 0.5.8a driver (the latest as
> of a week or two ago, and the only one that supports the YMF724).
> 
> Bottom line: the test sound plays, but it sounds horrible when played by 
> linuxaudiodev.  If I do this:
> 
>   $ play Lib/test/audiotest.au
> 
> then Cardinal Fang comes through loud and clear.  ("play" is a shell
> script wrapper for "sox", writing to /dev/dsp.)  But if I do this:
> 
>   $ ./python Lib/test/regrtest.py test_linuxaudiodev
> 
> he's still audible (and at the same volume), but very scratchy.  Sounds
> kind of like a very over-driven amp, or like a cheap car radio that
> somebody attacked with a knife.
> 
> [...some time passes...]
> 
> OK, I just tried it on another machine, also a Dell but with a different
> sound chip: the Crystal CS4232.  I'm pretty sure this one is using the
> OSS drivers included with the kernel, which is probably the second most
> important difference after the chipset itself.  Bottom line: it also
> sounds horrible.

Just tried that here; ouch.  I have a Dell Dimension XPS D233 (which
has an on-board Yamaha chipset - the OPL2, I believe).  I use the
sound driver that comes with the redhat built kernel (which is the OSS
one I think).

$ play audiotest.au

sounds fine,

$  ../../../build/python regrtest.py test_linuxaudiodev.py \
test_linuxaudiodev

sounds horrible; it sounds like it's being rammed through at far too
high a volume, but playing with the PCM or volume sliders in gmix has
no appreciable effect on the quality.  This suggests somewhat that the
problem lies in linuxaudiodev.c, doesn't it?

Is this stuff, like, documented anywhere?  I can't find any helpful
manpages...

I presume this module must work better than this for some people?

Cheers,
M.





From guido at python.org  Fri Jun 30 02:20:15 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 29 Jun 2000 19:20:15 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: Your message of "Thu, 29 Jun 2000 16:05:01 MST."
             <200006292305.QAA11929@slayer.i.sourceforge.net> 
References: <200006292305.QAA11929@slayer.i.sourceforge.net> 
Message-ID: <200006300020.TAA21877@cj20424-a.reston1.va.home.com>

> On second thought, first try for _winreg, and then winreg.  Only if both
> fail do we try for win32api/win32con.  If *those* both fail, then we don't
> have registry access.  Phew!

Is this smart?  Doesn't the new winreg have a very different I/F than
the old one?

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



From pingster at ilm.com  Fri Jun 30 01:24:28 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 16:24:28 -0700 (PDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: <m33dlw85fw.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <Pine.SGI.3.96.1000629162303.621134p-100000@happy>

On 29 Jun 2000, Michael Hudson wrote:
> $ play audiotest.au
> 
> sounds fine,
> 
> $  ../../../build/python regrtest.py test_linuxaudiodev.py \
> test_linuxaudiodev
> 
> sounds horrible; it sounds like it's being rammed through at far too
> high a volume

Sounds like u-law to me.  linuxaudiodev.c selects /dev/dsp by
default, which accepts raw data, not .au format.

Try setting the environment variable AUDIODEV to /dev/audio
before running the test script.  Does that work any better?


-- ?!ng




From fdrake at beopen.com  Fri Jun 30 01:29:42 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 19:29:42 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: <200006300020.TAA21877@cj20424-a.reston1.va.home.com>
References: <200006292305.QAA11929@slayer.i.sourceforge.net>
	<200006300020.TAA21877@cj20424-a.reston1.va.home.com>
Message-ID: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>

Greg Ward wrote in a checkin message:
 > On second thought, first try for _winreg, and then winreg.  Only if both
 > fail do we try for win32api/win32con.  If *those* both fail, then we don't
 > have registry access.  Phew!

Guido van Rossum writes on python-dev:
 > Is this smart?  Doesn't the new winreg have a very different I/F than
 > the old one?

  No, this is bad.  It *will* break with winreg; if _winreg isn't
available, it should use the win32api/win32con/whatever stuff; it's a
Python 1.5.2 interpreter at that point.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From skip at mojam.com  Fri Jun 30 00:22:18 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 17:22:18 -0500 (CDT)
Subject: [Python-Dev] Mysterious SF message...
Message-ID: <14683.52250.789900.357275@beluga.mojam.com>

I just submitted a patch for lib/libatexit.tex.  In the response page it
displayed a list of patches, then the following cryptic message:

    Patch Uploaded Successfully Added Patch Could Not Send Patch Update

Any idea what that means?

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From tim_one at email.msn.com  Fri Jun 30 01:32:42 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 19:32:42 -0400
Subject: [Python-Dev] Controversial patch (cmath)
Message-ID: <LNBBLJKPBEHFEDALKOLCAEFBGHAA.tim_one@email.msn.com>

I just voted to accept a patch that's broken.  If you want to argue it, be
my guest, but I'm out of it now <wink>.

Here's the patch:

https://sourceforge.net/patch/?func=detailpatch&patch_id=100651&group_id=547
0

Here's my comment (also available on that page):

Accepted (but reluctantly; see below), and assigned back to Guido for
checkin.

cmathmodule is not production quality, and this patch isn't either, but its
asinh and acosh are better than what's there now.

The author avoided some of the numerical foolishness in the original, but
didn't avoid all of it.  For example, it's harder to get asinh to do
something ridiculous now than it was before, but still possible:

>>> cmath.acosh(1e200)
(461.210165779+0j)
>>> cmath.asinh(1e200)
(1.#INF+0j)
>>>

asinh should have returned something approximately equal to what acosh
returned.

That may not be the patch's problem, though!  I suspect that's due to one of
the module's other functions that's too naive about the limits of floating
point.  In any case, it is much easier to provoke the *current* cmath
functions into cases like this one.

Another possible problem has to do with principal values.  My reference
books are in storage, so about the best I can do right now is compare what
this code does to Macsyma (which I have on my laptop).  The acosh in this
patch often returns the negative of what Macysma computes.  For example,

>>> cmath.acosh(-1-1j)
(1.06127506191-2.23703575929j)
>>>

Macsyma returns the negation of that.  On the other hand, the *original*
acosh doesn't agree with Macsyma on some signs where this acosh does.  So
call this one a wash.

I may have mentioned this before <wink>:  robust math libraries are
extremely difficult to get right.  It would take several months to write a
production-quality cmath module from scratch, which is several months more
than were devoted to Python's current cmath <wink>.  I vote we check this in
anyway (since it *is*, overall, an improvement), and look into borrowing
some other language's complex math library later (note in particular that
C9X adds complex numbers and these functions on them, so if we sit on our
asses long enough, we can inherit libc's!).





From mwh21 at cam.ac.uk  Fri Jun 30 01:33:37 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 30 Jun 2000 00:33:37 +0100
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:24:28 -0700 (PDT)"
References: <Pine.SGI.3.96.1000629162303.621134p-100000@happy>
Message-ID: <m3ya3o6p0u.fsf@atrus.jesus.cam.ac.uk>

Ka-Ping Yee <pingster at ilm.com> writes:

> On 29 Jun 2000, Michael Hudson wrote:
> > $ play audiotest.au
> > 
> > sounds fine,
> > 
> > $  ../../../build/python regrtest.py test_linuxaudiodev.py \
> > test_linuxaudiodev
> > 
> > sounds horrible; it sounds like it's being rammed through at far too
> > high a volume
> 
> Sounds like u-law to me.  linuxaudiodev.c selects /dev/dsp by
> default, which accepts raw data, not .au format.
> 
> Try setting the environment variable AUDIODEV to /dev/audio
> before running the test script.  Does that work any better?

That's the ticket.  "play" and the test now sound identical, modulo
some pops & cracks at the start and end of the test.  I presume what
follows is thus a good idea?

Index: test_linuxaudiodev.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_linuxaudiodev.py,v
retrieving revision 1.1
diff -u -r1.1 test_linuxaudiodev.py
--- test_linuxaudiodev.py       2000/06/10 04:22:57     1.1
+++ test_linuxaudiodev.py       2000/06/29 23:32:55
@@ -17,4 +17,6 @@
 def test():
     play_sound_file(findfile('audiotest.au'))
 
+os.environ["AUDIODEV"] = "/dev/audio"
+
 test()

Cheers,
M.




From Vladimir.Marangozov at inrialpes.fr  Fri Jun 30 01:38:19 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 01:38:19 +0200 (CEST)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <200006292325.SAA19744@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 29, 2000 06:25:09 PM
Message-ID: <200006292338.BAA07798@python.inrialpes.fr>

Guido van Rossum wrote:
> 
> Today, without much fanfare, we opened the new PythonLabs website.
> The design is by BeOpen's creative Director, Jun Simmons.  Thanks to
> Jeremy Hylton, who did most of the actual HTML editing to get our
> contents in place.
> 
> The new beta will be released via this site.
> 
> And since you python-dev folks will find this out through my checkins
> anyway, let this be an advance warning that it will be called Python
> 2.0.  Here's my explanation for the version bump (soon to be checked
> in to README):

Guido van Rossum just won't stop surprising us! :-) Witness the three
shocking news that arrived in one day: (1) very strict self-discipline
about "long-term" TODO's full of short-term and less than medium-term
topics that were very logically left behind, (2) major version number
revision one day before the official beta-cycle, (3) a new PythonLabs
corporate-style Web site with a flashing color palette & tutti quanti.
I am really (positively) amazed! :-)

spanish-inquisition-is-all-we-deserve-<wink>-ly y'rs

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From fdrake at beopen.com  Fri Jun 30 01:39:48 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 19:39:48 -0400 (EDT)
Subject: [Python-Dev] documentation patch guidelines
Message-ID: <14683.56900.433607.125111@cj42289-a.reston1.va.home.com>

  I've updated the patch guidelines for documentation to match other
patches, and added a patch category for documentation.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From pingster at ilm.com  Fri Jun 30 01:46:32 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 16:46:32 -0700 (PDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: <Pine.SGI.3.96.1000629162303.621134p-100000@happy>
Message-ID: <Pine.SGI.3.96.1000629163112.621134r-100000@happy>

On Thu, 29 Jun 2000, Ka-Ping Yee wrote:
> Try setting the environment variable AUDIODEV to /dev/audio
> before running the test script.  Does that work any better?

Even if that works, i realize that's not the way the interface
was intended to be used.  To play an AU file, the routine should
look something like this (not tested, as i don't have a working
Linux box)...

def play_au_file(path):

    fp = open(path, "r")

    # Read the .au file header.
    header = fp.read(24)
    hdrsize, length, encoding, rate, channels = \
        struct.unpack(">xxxxiiiii", header)
    fp.read(hdrsize - 24)
    
    data = fp.read()
    fp.close()

    # Set the data format according to the code in the .au header.
    if encoding == 1:
        size, fmt = 8, linuxaudiodev.AFMT_MU_LAW
    elif encoding == 2:
        size, fmt = 8, linuxaudiodev.AFMT_S8
    elif encoding == 3:
        size, fmt = 16, linuxaudiodev.AFMT_S16_BE
    else:
        raise "audio format not supported"
        
    dsp = linuxaudiodev.open("w")
    dsp.setparameters(rate, size, channels, fmt)
    dsp.write(data)
    dsp.close()


-- ?!ng

Explicit hoc totum;            This completes the whole;
Pro Christo da mihi potum.     For Christ's sake give me a drink.
    -- from the colophon of a 12th-century copyist




From nascheme at enme.ucalgary.ca  Fri Jun 30 02:00:37 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 29 Jun 2000 18:00:37 -0600
Subject: [Python-Dev] Mysterious SF message...
In-Reply-To: <14683.52250.789900.357275@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 05:22:18PM -0500
References: <14683.52250.789900.357275@beluga.mojam.com>
Message-ID: <20000629180037.A22566@acs.ucalgary.ca>

On Thu, Jun 29, 2000 at 05:22:18PM -0500, Skip Montanaro wrote:
> 
> I just submitted a patch for lib/libatexit.tex.  In the response page it
> displayed a list of patches, then the following cryptic message:
> 
>     Patch Uploaded Successfully Added Patch Could Not Send Patch Update
> 
> Any idea what that means?

SourceForge sucks?  Seriously though, I think it means:

  Patch Uploaded Successfully, Added Patch, Could Not Send Patch Update
  
For some reason it couldn't email out the patch update URL.


  Neil



From mwh21 at cam.ac.uk  Fri Jun 30 02:06:04 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 30 Jun 2000 01:06:04 +0100
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:46:32 -0700 (PDT)"
References: <Pine.SGI.3.96.1000629163112.621134r-100000@happy>
Message-ID: <m3u2ec6nir.fsf@atrus.jesus.cam.ac.uk>

Ka-Ping Yee <pingster at ilm.com> writes:

> On Thu, 29 Jun 2000, Ka-Ping Yee wrote:
> > Try setting the environment variable AUDIODEV to /dev/audio
> > before running the test script.  Does that work any better?
> 
> Even if that works, i realize that's not the way the interface
> was intended to be used.  To play an AU file, the routine should
> look something like this (not tested, as i don't have a working
> Linux box)...
[snip]

Yup, that works fine.  Don't understand the details - and as I have my
graduation ceremony tomorrow I'm going to go to bed and leave learning
them until some other occasion!

Cheers,
M.

PS: my Lib/test/test_linuxaudiodev.py is now this:

from test_support import verbose, findfile, TestFailed
import linuxaudiodev
import os,struct

def play_au_file(path):

    fp = open(path, "r")

    # Read the .au file header.
    header = fp.read(24)
    hdrsize, length, encoding, rate, channels = \
        struct.unpack(">xxxxiiiii", header)
    fp.read(hdrsize - 24)
    
    data = fp.read()
    fp.close()

    # Set the data format according to the code in the .au header.
    if encoding == 1:
        size, fmt = 8, linuxaudiodev.AFMT_MU_LAW
    elif encoding == 2:
        size, fmt = 8, linuxaudiodev.AFMT_S8
    elif encoding == 3:
        size, fmt = 16, linuxaudiodev.AFMT_S16_BE
    else:
        raise "audio format not supported"
        
    dsp = linuxaudiodev.open("w")
    dsp.setparameters(rate, size, channels, fmt)
    dsp.write(data)
    dsp.close()


def test():
    play_au_file(findfile('audiotest.au'))

test()

... which is an improvement on what's there now.




From pingster at ilm.com  Fri Jun 30 02:44:35 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 17:44:35 -0700 (PDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: <m3u2ec6nir.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <Pine.SGI.3.96.1000629173646.621134u-100000@happy>

On 30 Jun 2000, Michael Hudson wrote:
> Yup, that works fine.  Don't understand the details - and as I have my
> graduation ceremony tomorrow I'm going to go to bed and leave learning
> them until some other occasion!

Cool.

Okay, i just discovered sunau.py.  Here's my real shot at
test_linuxaudiodev.py.  Can you give this a try?


---- test_linuxaudiodev.py ----
from test_support import verbose, findfile, TestFailed
import linuxaudiodev
import os, sunau

formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW,
           ("NONE", 1): linuxaudiodev.AFMT_S8,
           ("NONE", 2): linuxaudiodev.AFMT_S16_BE}

def play_au_file(path):
    au = sunau.open(path, "r")
    data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE)
    au.close()

    spec = (au.getcomptype(), au.getsampwidth())
    if not has_key(formats, spec):
        raise "audio format not supported by linuxaudiodev"
        
    dsp = linuxaudiodev.open("w")
    dsp.setparameters(au.getframerate(), au.getsampwidth() * 8,
                      au.getnchannels(), formats[spec])
    dsp.write(data)
    dsp.close()

def test():
    play_au_file(findfile('audiotest.au'))

test()
---- test_linuxaudiodev.py ----



-- ?!ng




From gstein at lyra.org  Fri Jun 30 03:03:11 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 18:03:11 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8
In-Reply-To: <200006291238.FAA01061@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 05:38:48AM -0700
References: <200006291238.FAA01061@slayer.i.sourceforge.net>
Message-ID: <20000629180311.I29590@lyra.org>

Fredrik,

Something you are doing is forcing CVS to issue a new revision for some of
those files, even when you are not changing them. These "false" revisions
are probably not a good thing.

Could you review your checkin process to see what is up? I would guess that
you have the "-f" option in your commit line.

Cheers,
-g

On Thu, Jun 29, 2000 at 05:38:48AM -0700, Fredrik Lundh wrote:
> Update of /cvsroot/python/python/dist/src/Lib
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv899/Lib
> 
> Modified Files:
> 	sre.py sre_compile.py sre_constants.py sre_parse.py 
> Log Message:
> 
> 
> - make sure group names are valid identifiers
>   (closes the "SRE: symbolic reference" bug)
> 
> Index: sre.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre.py,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -C2 -r1.9 -r1.10
> 
> Index: sre_compile.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre_compile.py,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -C2 -r1.7 -r1.8
> 
> Index: sre_constants.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre_constants.py,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -C2 -r1.7 -r1.8
> 
> Index: sre_parse.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre_parse.py,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -C2 -r1.7 -r1.8
> *** sre_parse.py	2000/06/29 11:34:27	1.7
> --- sre_parse.py	2000/06/29 12:38:45	1.8
> ***************
> *** 169,172 ****
> --- 169,190 ----
>   	return this
>   
> + def isident(char):
> +     return "a" <= char <= "z" or "A" <= char <= "Z" or char == "_"
> + 
> + def isdigit(char):
> +     return "0" <= char <= "9"
> + 
> + def isname(name):
> +     # check that group name is a valid string
> +     # FIXME: <fl> this code is really lame.  should use a regular
> +     # expression instead, but I seem to have certain bootstrapping
> +     # problems here ;-)
> +     if not isident(name[0]):
> + 	return 0
> +     for char in name:
> + 	if not isident(char) and not isdigit(char):
> + 	    return 0
> +     return 1
> + 
>   def _group(escape, state):
>       # check if the escape string represents a valid group
> ***************
> *** 419,425 ****
>   			    if char == ">":
>   				break
> - 			    # FIXME: check for valid character
>   			    name = name + char
>   			group = 1
>   		    elif source.match("="):
>   			# named backreference
> --- 437,444 ----
>   			    if char == ">":
>   				break
>   			    name = name + char
>   			group = 1
> + 			if not isname(name):
> + 			    raise error, "illegal character in group name"
>   		    elif source.match("="):
>   			# named backreference
> ***************
> *** 523,540 ****
>   			char = s.get()
>   			if char is None:
> ! 			    raise error, "unterminated index"
>   			if char == ">":
>   			    break
> - 			# FIXME: check for valid character
>   			name = name + char
>   		if not name:
> ! 		    raise error, "bad index"
>   		try:
>   		    index = int(name)
>   		except ValueError:
>   		    try:
>   			index = pattern.groupindex[name]
>   		    except KeyError:
> ! 			raise IndexError, "unknown index"
>   		a((MARK, index))
>   	    elif len(this) > 1 and this[1] in DIGITS:
> --- 542,560 ----
>   			char = s.get()
>   			if char is None:
> ! 			    raise error, "unterminated group name"
>   			if char == ">":
>   			    break
>   			name = name + char
>   		if not name:
> ! 		    raise error, "bad group name"
>   		try:
>   		    index = int(name)
>   		except ValueError:
> + 		    if not isname(name):
> + 			raise error, "illegal character in group name"
>   		    try:
>   			index = pattern.groupindex[name]
>   		    except KeyError:
> ! 			raise IndexError, "unknown group name"
>   		a((MARK, index))
>   	    elif len(this) > 1 and this[1] in DIGITS:
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From akuchlin at cnri.reston.va.us  Fri Jun 30 03:29:41 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Thu, 29 Jun 2000 21:29:41 -0400
Subject: [Python-Dev] Removing modules
Message-ID: <20000629212941.A21563@newcnri.cnri.reston.va.us>

For the "deleted modules" section of the 2.0 article, I drew up a list
of modules that might be outdated, mostly the SGI-specific ones.  Are
those modules still useful, and do the libraries they were written for
still exist?

For your cogitation, here's the list: sgimodule.c, glmodule.c (and
hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c,
almodule.c, clmodule.c,  knee.py.

Also, can someone explain why importing a third party extension built
for Python 1.5.x is supposed to result in an immediate crash on
Windows?  I'd like to explain why this happens...

--amk





From guido at python.org  Fri Jun 30 05:13:13 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 29 Jun 2000 22:13:13 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8
In-Reply-To: Your message of "Thu, 29 Jun 2000 18:03:11 MST."
             <20000629180311.I29590@lyra.org> 
References: <200006291238.FAA01061@slayer.i.sourceforge.net>  
            <20000629180311.I29590@lyra.org> 
Message-ID: <200006300313.WAA22134@cj20424-a.reston1.va.home.com>

> Fredrik,
> 
> Something you are doing is forcing CVS to issue a new revision for some of
> those files, even when you are not changing them. These "false" revisions
> are probably not a good thing.
> 
> Could you review your checkin process to see what is up? I would guess that
> you have the "-f" option in your commit line.
> 
> Cheers,
> -g

Greg, we already know why this is.  It's the $ID$.

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



From mhammond at skippinet.com.au  Fri Jun 30 04:49:06 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 12:49:06 +1000
Subject: [Python-Dev] Removing modules
In-Reply-To: <20000629212941.A21563@newcnri.cnri.reston.va.us>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEPMCOAA.mhammond@skippinet.com.au>

> Also, can someone explain why importing a third party extension built
> for Python 1.5.x is supposed to result in an immediate crash on
> Windows?  I'd like to explain why this happens...

The 1.5 module is linked against Python15.dll.  When Python.exe (linked
against Python16.dll) starts up, it initializes the Python data structures
in Python16.dll.  When Python then imports foo.pyd (linked against
Python15.dll), it immediately tries to call the functions in that DLL (such
as getting the thread state).  As Python has not been initialized in that
DLL, we immediately die.

Ironically, if Python1x.dll was simply named "Python.dll", there is a
_reasonable_ chance it would work fine.  The cost of doing this tho, is
that you can not have Python 1.5 and Python 1.6 "side by side" on the same
machine.

There are a few possibilities for magic tricks we could pull, but to be
honest Im not too inclined to bother with them myself...  They would also
require a commitment to a fully backwards compatible C API, which I dont
think we can afford to commit to!

Mark.




From gward at python.net  Fri Jun 30 05:30:03 2000
From: gward at python.net (Greg Ward)
Date: Thu, 29 Jun 2000 23:30:03 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
Message-ID: <20000629233003.A1766@beelzebub>

Curses!

I just noticed that sys.platform in 1.6a2 (and the latest CVS from this
morning) returns "linux2" on my PC, not "linux-i386".  As I recall this
decision is made in the configure script.  Does anyone know why it
changed?  This is not the end of the world, but the OS name alone is not
really enough on a multi-architecture OS...

...back to calling os.uname() myself, I guess.  ;-(

        Greg
-- 
Greg Ward - programmer-at-big                           gward at python.net
http://starship.python.net/~gward/
God made machine language; all the rest is the work of man.



From fdrake at beopen.com  Fri Jun 30 05:33:45 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 23:33:45 -0400 (EDT)
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <20000629233003.A1766@beelzebub>
References: <20000629233003.A1766@beelzebub>
Message-ID: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>

Greg Ward writes:
 > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this
 > morning) returns "linux2" on my PC, not "linux-i386".  As I recall this

  I didn't know it ever returned linux-i386; perhaps you're thinking
of Marc-Andre's platform module?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From trentm at activestate.com  Fri Jun 30 05:34:17 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 20:34:17 -0700
Subject: [Python-Dev] Controversial patch (cmath)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEFBGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCAEFBGHAA.tim_one@email.msn.com>
Message-ID: <20000629203417.B23077@activestate.com>

[Tim discusses god awful math details]
Would you want to foward this to python-list to see if any lurking
mathematicians might be spurred to action?

Trent

-- 
Trent Mick
trentm at activestate.com



From gward at python.net  Fri Jun 30 05:53:34 2000
From: gward at python.net (Greg Ward)
Date: Thu, 29 Jun 2000 23:53:34 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 11:33:45PM -0400
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
Message-ID: <20000629235334.B1294@beelzebub>

On 29 June 2000, Fred L. Drake, Jr. said:
>   I didn't know it ever returned linux-i386; perhaps you're thinking
> of Marc-Andre's platform module?

D'ohh!  That appears to be an artifact of Red Hat's build -- I was using
/usr/bin/python (theirs), not /usr/local/bin/python (mine).

  $ /usr/bin/python
  Python 1.5.2 (#1, Feb  1 2000, 16:32:16)  [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> sys.platform
  'linux-i386'

Sorry for getting alarmist.  Guess I never should have started using
sys.platform in the first place (or just not worry about getting the CPU
in there too).

        Greg
-- 
Greg Ward - geek                                        gward at python.net
http://starship.python.net/~gward/
Support bacteria -- it's the only culture some people have!



From skip at mojam.com  Fri Jun 30 04:57:47 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 21:57:47 -0500 (CDT)
Subject: [Python-Dev] available to look at bugs and patches...
Message-ID: <14684.3243.480545.880199@beluga.mojam.com>

Barry added me as a developer yesterday.  Those people assigning bugs and
patches can use me as a resource...

Skip



From gward at python.net  Fri Jun 30 06:26:20 2000
From: gward at python.net (Greg Ward)
Date: Fri, 30 Jun 2000 00:26:20 -0400
Subject: [Python-Dev] ANNOUNCE: Distutils 0.9
Message-ID: <20000630002620.A2329@beelzebub>

                     Python Distribution Utilities
                              release 0.9
                             June 29, 2000

The Python Distribution Utilities, or Distutils for short, are a
collection of modules that aid in the development, distribution, and
installation of Python modules.  (It is intended that ultimately the
Distutils will grow up into a system for distributing and installing
whole Python applications, but for now their scope is limited to module
distributions.)

The Distutils are a standard part of Python 2.0; if you are running 2.0
(or one of the 1.6 alpha releases that preceded it), you don't need to
install the Distutils separately.  This release is primarily so that you
can add the Distutils to a Python 1.5.2 installation -- you will then be
able to install modules that require the Distutils, or use the Distutils
to distribute your own modules.

More information is available at the Distutils web page:

    http://www.python.org/sigs/distutils-sig/

and in the README.txt included in the Distutils source distribution.

You can download the Distutils from

    http://www.python.org/sigs/distutils-sig/download.html

Trivial patches can be sent to me (Greg Ward) at gward at python.net.
Larger patches should be discussed on the Distutils mailing list:
distutils-sig at python.org.



From tim_one at email.msn.com  Fri Jun 30 07:05:32 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 01:05:32 -0400
Subject: [Python-Dev] Controversial patch (cmath)
In-Reply-To: <20000629203417.B23077@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEFLGHAA.tim_one@email.msn.com>

[Trent Mick]

> [Tim discusses god awful math details]
> Would you want to foward this to python-list to see if any lurking
> mathematicians might be spurred to action?

God, please no!  This requires a numerical analyst, not a mathematician.
Voting by talented amateurs is only going to make things worse <0.5 wink>.
I was an NA in a previous life, and know what needs to be done to resolve
all this.  But that takes way more time than we have before 2.0b1.  The
patch in question makes life better for the world's only known user of cmath
<ahem>.

may-as-well-ask-c.l.py-to-discuss-python's-version-number<wink>-ly
    y'rs  - tim





From jeremy at beopen.com  Fri Jun 30 07:08:30 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 01:08:30 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include objimpl.h,2.16,2.17
In-Reply-To: <200006300502.WAA03256@slayer.i.sourceforge.net>
References: <200006300502.WAA03256@slayer.i.sourceforge.net>
Message-ID: <14684.11086.47325.776691@bitdiddle.concentric.net>

These patches should catch up with Neil's latest submissions, but may
not have the very latest changes suggested by Neil and Vladimir.  I
will double-check with them in the morning.  I will also change
configure.in to enable GC by default for the beta test phase, unless
there is strong objection.

Jeremy



From skip at mojam.com  Fri Jun 30 06:00:29 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 23:00:29 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1
In-Reply-To: <200006300502.WAA03286@slayer.i.sourceforge.net>
References: <200006300502.WAA03286@slayer.i.sourceforge.net>
Message-ID: <14684.7005.661874.713000@beluga.mojam.com>

    Jeremy> Log Message:
    Jeremy> final patches from Neil Schemenauer for garbage collection

    Jeremy> --- NEW FILE ---
    Jeremy> test_gc
    Jeremy> list 0x831a754
    Jeremy> dict 0x831a754
    ...
    Jeremy> dict 0x831a9bc
    Jeremy> func 0x831d9e4

I can all but guarantee you this test will always fail.  Printing absolute
machine addresses (via calls to id() in this case) in test cases should be
verboten.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From trentm at activestate.com  Fri Jun 30 08:05:50 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 23:05:50 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7
In-Reply-To: <200006300502.WAA03275@slayer.i.sourceforge.net>
References: <200006300502.WAA03275@slayer.i.sourceforge.net>
Message-ID: <20000629230550.A24811@activestate.com>

On Thu, Jun 29, 2000 at 10:02:55PM -0700, Jeremy Hylton wrote:
> Update of /cvsroot/python/python/dist/src/PCbuild
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv3220/PCbuild
> 
> Modified Files:
> 	python16.dsp 
> Log Message:
> final patches from Neil Schemenauer for garbage collection
> 
> 
> Index: python16.dsp
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/PCbuild/python16.dsp,v
> retrieving revision 1.6
> retrieving revision 1.7
> diff -C2 -r1.6 -r1.7
> *** python16.dsp	2000/06/06 23:29:09	1.6
> --- python16.dsp	2000/06/30 05:02:53	1.7
> ***************
> *** 660,663 ****
> --- 660,677 ----
>   # End Source File
>   # Begin Source File
> + SOURCE=..\Modules\gcmodule.c
> + 
> + !IF  "$(CFG)" == "python16 - Win32 Release"
> + 
> + !ELSEIF  "$(CFG)" == "python16 - Win32 Debug"
> + 
> + !ELSEIF  "$(CFG)" == "python16 - Win32 Alpha Debug"
> + 
> + !ELSEIF  "$(CFG)" == "python16 - Win32 Alpha Release"
> + 
> + !ENDIF 
> + 
> + # End Source File
> + # Begin Source File
>   
>   SOURCE=..\Python\getargs.c
> 

Pardon me if I am wrong (I have not actually checked the repository) but is
this correct now that the version number is 2.0?

Trent


-- 
Trent Mick
trentm at activestate.com



From trentm at activestate.com  Fri Jun 30 08:27:33 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 23:27:33 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <200006300608.XAA13124@slayer.i.sourceforge.net>
References: <200006300608.XAA13124@slayer.i.sourceforge.net>
Message-ID: <20000629232733.D24811@activestate.com>

Cool

On Thu, Jun 29, 2000 at 11:08:38PM -0700, Skip Montanaro wrote:
> 
> --- NEW FILE ---
> 			 Writing Python Test Cases
> 			 -------------------------
> 			       Skip Montanaro
> 
> 
> To run the entire test suite, make the "test" target at the top level:
> 
>     cd ...
>     make test

This is a UN*Xism, on Windows and UN*X:
cd ...\Lib\test
python regrtest.py



A sample walk through to create a test might make it more approachable for
people. As well, it would be helpful to mention
test_support.{verbose|TESTFN|...}.  But I have no right to bitch about good
work.


Trent



-- 
Trent Mick
trentm at activestate.com



From tim_one at email.msn.com  Fri Jun 30 08:39:15 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 02:39:15 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <20000629232733.D24811@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com>

[Trent Mick]
> ...
> But I have no right to bitch about good work.

How do you figure that?  We do it to you enough <wink>.

BTW, I'd just like to say what a delight it is to work with *all* of you
folks!  I wanted to say that before I can be accused of pimping for my
employer -- so far, BeOpen hasn't paid me a dime, so you know my opinion
hasn't yet been bought.

well-maybe-on-credit<wink>-ly y'rs  - tim





From tim_one at email.msn.com  Fri Jun 30 08:39:12 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 02:39:12 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7
In-Reply-To: <20000629230550.A24811@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEFPGHAA.tim_one@email.msn.com>

[Trent Mick, on Guido's late-night (for him <wink>) checkin of
 python16.dsp]

> Pardon me if I am wrong (I have not actually checked the
> repository) but is this correct now that the version number is 2.0?

No, it is not, and the Windows build is slightly damaged now.  I've already
yelled at Guido about this, but I suspect he's asleep.  I'm sure it will get
sorted out in the morning.





From trentm at activestate.com  Fri Jun 30 08:52:47 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 23:52:47 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com>
References: <20000629232733.D24811@activestate.com> <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com>
Message-ID: <20000629235247.A25090@activestate.com>

On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote:
> BTW, I'd just like to say what a delight it is to work with *all* of you
> folks!

I feel a group hug coming on in the morning. Or maybe I am just moved by the
beer that I had for dinner. :) Likewise, Tim. As my first foray into
community development I find this, Python dev, a refreshing pleasure.

Trent

-- 
Trent Mick
trentm at activestate.com



From tim_one at email.msn.com  Fri Jun 30 09:41:28 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 03:41:28 -0400
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEGBGHAA.tim_one@email.msn.com>

[Tim]
> ... "Group whiteboards" and shared journals etc are darned
> useful, though.

[Ken Manheimer]
> Wiki = Group whiteboard

Ya, I kind of picked that up from your last passionate advertisement for
this stuff <wink>.  Not knocking it!  Never tried it.  Believe it or not, I
spend as little time on the web as possible.  After I've gotten into a place
to live here, and this current release crunch is behind us, I'm definitely
going to check out your leads.

For the past several years my development group worked thru Lotus Notes,
which I didn't much care for at the time, but I'm increasingly realizing
just how essential group-modifiable shared persistent documents were to our
productivity.  Notes is the purest example of a whole being greater than the
sum of its parts I've ever seen (lousy mail system, lousy database, lousy
change manager, lousy bug tracker, lousy workflow manager, worse than lousy
native scripting ... but they all sucked in ways that were downright
synergistic <0.9 wink>).

> ...
> Anyway, to see leads on both zwikis and tracker, see:
>
>   http://www.zope.org/Members/klm/TrackerWiki

can-beopen-zwiki-2.0-be-far-behind<wink>?-ly y'rs  - tim





From pingster at ilm.com  Fri Jun 30 10:21:08 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Fri, 30 Jun 2000 01:21:08 -0700 (PDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <200006292338.BAA07798@python.inrialpes.fr>
Message-ID: <Pine.SGI.3.96.1000630010709.621134O-100000@happy>

Guido van Rossum wrote:
> let this be an advance warning that it will be called Python 2.0.

On Fri, 30 Jun 2000, Vladimir Marangozov wrote:
> Guido van Rossum just won't stop surprising us! :-)

Will many be spooked by the jump in version number into fearing
incompatibility with older scripts...?

I wonder if we'll end up trying to persuade the user community that
the changes are small ("no, don't worry, your scripts will still
work") and yet big ("honest, it really deserves to be called 2.0,
it's not just a ploy") at the same time.

Perl 5 was basically incompatible with Perl 4.  Some things run,
but a lot don't.  (Actually many microversions of Perl 5 were
mutually incompatible with each other, but i'll ignore that. :) )

I've thought of the jump to Python3k (lowercase "k", please) much
like the Perl-4-to-Perl-5 jump: simple stuff is still okay but a lot
of guts have changed.  If i hadn't been "on the inside" watching
development activity, i might expect something of similar magnitude
upon hearing of going from Python 1.x to 2.0.

I guess we can point at Unicode and SRE as big things.


-- ?!ng




From effbot at telia.com  Fri Jun 30 10:33:10 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 10:33:10 +0200
Subject: [Python-Dev] SRE status report
Message-ID: <005001bfe26d$d3dc3540$f2a6b5d4@hagrid>

just checked in a test script for sre.  the test_sre file is a
copy of test_re, with some minor changes:

-- disabled one test (caused by bug #8; see below)

-- added T (template mode, experimental, unsupported)
   and U (unicode locale) flags to the flag test

-- removed keyword arguments in pattern test loop:

    result = obj.search(s, pos=result.start(0), endpos=result.end(0)+1)

was changed to:

    result = obj.search(s, result.start(0), result.end(0)+1)

as far as I can tell, the docs don't mention anything about keyword
arguments...

-- added unicode pattern / target string / locale tests to
   the pattern test loop.

however, the current version SRE doesn't fully pass the test.
here's an annotated version of Lib/test/output/test_sre:

1) test_support -- test failed re module pickle
2) test_support -- test failed re module cPickle

under SRE, patterns are C objects, not class instances.
to allow pickling, I need to modify copy_reg (either by
modifing the file itself, or by updating the registry when
SRE is first imported).  see patch #100650 for more info,

3) === Syntax error: ('(?P<foo_123>a)(?P=foo_123)', 'aa', 0, 'g1', 'a')

this is a bug in the SRE parser.  should be easy to fix.

4) === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A')

this is a bug in the engine (nested repetitions). needs
further research.

5) === Failed incorrectly ('(a+)+\\1', 'aa', 0, 'found+"-"+g1', 'aa-a')

this is a bug in the engine or in the parser.  needs further
research.

6) === grouping error ('([^/]*/)*sub1/', 'd:msgs/tdir/sub1/trial/away.cpp', 0, 'found+"-"+g1', 'd:msgs/tdir/sub1/-tdir/') 'd:msgs/tdir/sub1/-trial/' should be 'd:msgs/tdir/sub1/-tdir/'

same as #5.

7) === Syntax error: ('(?P<id>aa)(?P=id)', 'aaaa', 0, 'found+"-"+id', 'aaaa-aa')

same as #3.

8) === grouping error ('([abc])*bcd', 'abcd', 0, 'found+"-"+g1', 'abcd-a') 'abcd-c' should be 'abcd-a'

this is a bug in the engine.  should be easy to fix, I think.
in fact, I could have sworn that I'd fixed it already.

9) === grouping error ('(?i)([abc])*bcd', 'ABCD', 0, 'found+"-"+g1', 'ABCD-A') 'ABCD-C' should be 'ABCD-A'

same as #8

10) === Syntax error: ('a(?!b).', 'abad', 0, 'found', 'ad')

this is bug in the parser.  should be easy to fix.

11) === Syntax error: ('a(?=d).', 'abad', 0, 'found', 'ad')

same as (or at least related to) #10

12) === Syntax error: ('a(?=c|d).', 'abad', 0, 'found', 'ad')

same as #11

13) === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A')

same as #4 (literally!).

...

fwiw, *all* RE-based code I've played with seem to
work.  ymmv.  let me know asap if it does.

</F>




From mhammond at skippinet.com.au  Fri Jun 30 10:41:44 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 18:41:44 +1000
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <Pine.SGI.3.96.1000630010709.621134O-100000@happy>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>

> Will many be spooked by the jump in version number into fearing
> incompatibility with older scripts...?
>
> I wonder if we'll end up trying to persuade the user community that
> the changes are small ("no, don't worry, your scripts will still
> work") and yet big ("honest, it really deserves to be called 2.0,
> it's not just a ploy") at the same time.

I see your concerns, but I think the trick is to be honest, just as Guido
was.  We simply say it was bumped to V2 for the reasons of percieved
maturity, and a clear break from CNRI Python.

Both seem reasonable.  I believe many people will simply wait for some form
of consensus on the newsgroup, regardless of the version number.

Personally, Im a little - umm - lets just say that I can see the irony in
the fact that I recently changed a few bits of code that were dependent on
a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x
family.  I figured there was no point trying to predict the packaging
details of the 2.x family, seeing it as still some time off.  Nothing like
foresight :-)

And-"foresight"-isnt-an-excuse-for-Tim-to-get-back-on-the-topic-of-his-geni
tals-<wink>-ly,

Mark.




From effbot at telia.com  Fri Jun 30 10:55:01 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 10:55:01 +0200
Subject: [Python-Dev] New PythonLabs site revealed!
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>
Message-ID: <005801bfe270$e140d440$f2a6b5d4@hagrid>

mark wrote:
> Personally, Im a little - umm - lets just say that I can see the irony in
> the fact that I recently changed a few bits of code that were dependent on
> a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x
> family.

heh.  you're not the only one...

btw, now that we're bumping to 2.0, maybe we can break
socket.connect and friends once again?  if somebody com-
plains, just tell them "it's a major release, dammit" ;-)

</F>




From gstein at lyra.org  Fri Jun 30 10:59:56 2000
From: gstein at lyra.org (Greg Stein)
Date: Fri, 30 Jun 2000 01:59:56 -0700
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com> <200006291905.OAA17265@cj20424-a.reston1.va.home.com>
Message-ID: <20000630015956.S29590@lyra.org>

On Thu, Jun 29, 2000 at 02:05:11PM -0500, Guido van Rossum wrote:
>...
> > Note that Perl is maintained under (the commercial, alas) Perforce, which is
> > one of the few SCMs to take multi-developer multi-directory issues
> > seriously.
> 
> We tried Perforce at CNRI.  It's really neat, but somehow it was
> lacking some stuff we were used to and we never converted.
> 
> Note that Perforce is free for open source projects -- at least at the
> time it was.  (CNRI paid a license fee, but that was just an
> expression of CNRI's reluctance against free software. :-)
> 
> There's also bitkeeper.  It stayed in beta so long that we gave up
> (and they have a weird license) -- but it's out of beta since May 4:
> see http://www.bitkeeper.com/.  But there's no immediate download!
> You must sign up and they send you instructions in the mail...

And coming down the pipe (end of the year) is Subversion:

    http://subversion.tigris.org/

Cheers,
-g

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



From mhammond at skippinet.com.au  Fri Jun 30 11:23:53 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 19:23:53 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6
In-Reply-To: <200006300904.CAA04151@slayer.i.sourceforge.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEBACPAA.mhammond@skippinet.com.au>

> Making a tiny change to figure out what I'm going to screw up
> by trying to use CVS under Windows at all ...

Congratulations :-)

Mark.




From mhammond at skippinet.com.au  Fri Jun 30 11:25:39 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 19:25:39 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBGEBACPAA.mhammond@skippinet.com.au>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEBACPAA.mhammond@skippinet.com.au>

> To: python-dev at python.org

Damn damn damn - did it again.  Sorry.

[I wishing mailing-lists would agree on how they handle reply-to :-]

Mark.



From mal at lemburg.com  Fri Jun 30 11:27:57 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 11:27:57 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
Message-ID: <395C681D.C3211F6@lemburg.com>

"Fred L. Drake, Jr." wrote:
> 
> Greg Ward writes:
>  > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this
>  > morning) returns "linux2" on my PC, not "linux-i386".  As I recall this
> 
>   I didn't know it ever returned linux-i386; perhaps you're thinking
> of Marc-Andre's platform module?

Python has returned 'linux2' on my machine ever since I moved
to a 2.x kernel -- why should it return 'linux-i386' (without
any indication of version) ?

As Fred mentioned, you should probably use platform.py to
access the information you have in mind. It supports loads
of different architectures and has pretty much all the
information you need for distutils warpped in nice APIs.

Why not simply include it in distutils ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Fri Jun 30 12:04:00 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 12:04:00 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2
References: <200006300953.CAA14782@slayer.i.sourceforge.net>
Message-ID: <00b001bfe27a$845f7880$f2a6b5d4@hagrid>

MAL wrote:
>     out.write(header)
>     out = open(cFileName, "w")
> !   out.write("#include "%s"\n" % headerFileName)
>     out.write(code)
>     perfHash.generate_graph(out)

umm.  I suppose you meant:

> !   out.write('#include "%s"\n' % headerFileName)

or possibly:

> !   out.write("#include \"%s\"\n" % headerFileName)

</F>




From mal at lemburg.com  Fri Jun 30 12:15:23 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 12:15:23 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: 
 python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2
References: <200006300953.CAA14782@slayer.i.sourceforge.net> <00b001bfe27a$845f7880$f2a6b5d4@hagrid>
Message-ID: <395C733B.4E2AFFA3@lemburg.com>

Fredrik Lundh wrote:
> 
> MAL wrote:
> >     out.write(header)
> >     out = open(cFileName, "w")
> > !   out.write("#include "%s"\n" % headerFileName)
> >     out.write(code)
> >     perfHash.generate_graph(out)
> 
> umm.  I suppose you meant:
> 
> > !   out.write('#include "%s"\n' % headerFileName)
> 
> or possibly:
> 
> > !   out.write("#include \"%s\"\n" % headerFileName)

Oops, you're right.

Thanks.
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Fri Jun 30 15:20:23 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:20:23 -0400 (EDT)
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEGBGHAA.tim_one@email.msn.com>
References: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>
	<LNBBLJKPBEHFEDALKOLCMEGBGHAA.tim_one@email.msn.com>
Message-ID: <14684.40599.135974.497497@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > productivity.  Notes is the purest example of a whole being greater than the
 > sum of its parts I've ever seen (lousy mail system, lousy database, lousy
 > change manager, lousy bug tracker, lousy workflow manager, worse than lousy
 > native scripting ... but they all sucked in ways that were downright
 > synergistic <0.9 wink>).

  I had to use Notes before working at CNRI, and wouldn't have
described all those sucky components as "synergistic".  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Fri Jun 30 15:26:15 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:26:15 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <Pine.SGI.3.96.1000630010709.621134O-100000@happy>
References: <200006292338.BAA07798@python.inrialpes.fr>
	<Pine.SGI.3.96.1000630010709.621134O-100000@happy>
Message-ID: <14684.40951.644965.274278@cj42289-a.reston1.va.home.com>

Ka-Ping Yee writes:
 > Will many be spooked by the jump in version number into fearing
 > incompatibility with older scripts...?
 > 
 > I wonder if we'll end up trying to persuade the user community that
 > the changes are small ("no, don't worry, your scripts will still
 > work") and yet big ("honest, it really deserves to be called 2.0,
 > it's not just a ploy") at the same time.

Ping,
  Haven't we heard our users complain about the conservative version
numbering a lot?  Pushing to 2.0 allows us to make the next release
2.1, which neither the "never 1.x!" crowd nor the "never x.0!" will
worry about.  Sounds like a good move to me!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Fri Jun 30 15:28:15 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:28:15 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <005801bfe270$e140d440$f2a6b5d4@hagrid>
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>
	<005801bfe270$e140d440$f2a6b5d4@hagrid>
Message-ID: <14684.41071.958061.743836@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > btw, now that we're bumping to 2.0, maybe we can break
 > socket.connect and friends once again?  if somebody com-
 > plains, just tell them "it's a major release, dammit" ;-)

  If by "break" you mean "tightly conform to the documentation", I'm
all for it!  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Fri Jun 30 15:32:24 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:32:24 -0400 (EDT)
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <395C681D.C3211F6@lemburg.com>
References: <20000629233003.A1766@beelzebub>
	<14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
	<395C681D.C3211F6@lemburg.com>
Message-ID: <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>

Regarding platform.py:

M.-A. Lemburg writes:
 > Why not simply include it in distutils ?

  Why not include it in the standard library?
  Guido?  I'll document it if Marc-Andre is willing to provide the
module and the regression test.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Fri Jun 30 15:40:36 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 15:40:36 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub>
		<14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
		<395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>
Message-ID: <395CA354.16AC5B7E@lemburg.com>

"Fred L. Drake, Jr." wrote:
> 
> Regarding platform.py:
> 
> M.-A. Lemburg writes:
>  > Why not simply include it in distutils ?
> 
>   Why not include it in the standard library?
>   Guido?  I'll document it if Marc-Andre is willing to provide the
> module and the regression test.

No objection from here.

I've attached my most recent copy to this mail. I'm not sure
how to write the regr. test though since output is dependent
on the platform running the functions... perhaps I'll just
add something like the audio thingie: "This string ought
to identify the platform you are currently running... if not,
then something is wrong ;-)".

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bwarsaw at beopen.com  Fri Jun 30 15:42:19 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 09:42:19 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules gcmodule.c,NONE,2.1 Setup.thread.in,2.2,2.3 cPickle.c,2.43,2.44 newmodule.c,2.20,2.21
References: <200006300502.WAA03262@slayer.i.sourceforge.net>
Message-ID: <14684.41915.59835.325026@anthem.concentric.net>

So, Setup.thread.in isn't used just for threads anymore.  Perhaps it
should be renamed?  At the very least, a comment should be added to
the top that this file is for configure enabled modules.

-Barry

Index: Setup.thread.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/Setup.thread.in,v
retrieving revision 2.2
retrieving revision 2.3
diff -C2 -r2.2 -r2.3
*** Setup.thread.in	2000/06/29 16:08:28	2.2
--- Setup.thread.in	2000/06/30 05:02:53	2.3
***************
*** 11,12 ****
--- 11,15 ----
  
  @USE_THREAD_MODULE at thread threadmodule.c
+ 
+ # Garbage collection enabled with --with-cycle-gc
+ @USE_GC_MODULE at gc gcmodule.c



From mal at lemburg.com  Fri Jun 30 15:42:06 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 15:42:06 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub>
			<14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
			<395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com>
Message-ID: <395CA3AE.8A5800F1@lemburg.com>

Ooops, forgot the attachement...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: platform.py
Type: text/python
Size: 36884 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000630/2c97c250/attachment.bin>

From guido at python.org  Fri Jun 30 16:47:29 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 09:47:29 -0500
Subject: [Python-Dev] Removing modules
In-Reply-To: Your message of "Thu, 29 Jun 2000 21:29:41 -0400."
             <20000629212941.A21563@newcnri.cnri.reston.va.us> 
References: <20000629212941.A21563@newcnri.cnri.reston.va.us> 
Message-ID: <200006301447.JAA30671@cj20424-a.reston1.va.home.com>

> For the "deleted modules" section of the 2.0 article, I drew up a list
> of modules that might be outdated, mostly the SGI-specific ones.  Are
> those modules still useful, and do the libraries they were written for
> still exist?

Doubtful.  I've asked Sjoerd and Jack, who were most involved in using
these.

> For your cogitation, here's the list: sgimodule.c, glmodule.c (and
> hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c,
> almodule.c, clmodule.c,  knee.py.

I'd like to keep knee.py -- it's a nice piece of *documentation* of
the package import.

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



From guido at python.org  Fri Jun 30 16:55:08 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 09:55:08 -0500
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: Your message of "Fri, 30 Jun 2000 15:40:36 +0200."
             <395CA354.16AC5B7E@lemburg.com> 
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>  
            <395CA354.16AC5B7E@lemburg.com> 
Message-ID: <200006301455.JAA30721@cj20424-a.reston1.va.home.com>

> > Regarding platform.py:
> > 
> > M.-A. Lemburg writes:
> >  > Why not simply include it in distutils ?
> > 
> >   Why not include it in the standard library?
> >   Guido?  I'll document it if Marc-Andre is willing to provide the
> > module and the regression test.
> 
> No objection from here.
> 
> I've attached my most recent copy to this mail. I'm not sure
> how to write the regr. test though since output is dependent
> on the platform running the functions... perhaps I'll just
> add something like the audio thingie: "This string ought
> to identify the platform you are currently running... if not,
> then something is wrong ;-)".

You didn't include it!

But I vote -1 on this one anyway -- it's too much code and almost by
its very nature not something that belongs in a "standard" library.
Plus, I don't want to be responsible for maintaining it.  Sorry,

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



From bwarsaw at beopen.com  Fri Jun 30 15:57:47 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 09:57:47 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>
	<005801bfe270$e140d440$f2a6b5d4@hagrid>
Message-ID: <14684.42843.472230.609828@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <effbot at telia.com> writes:

    FL> btw, now that we're bumping to 2.0, maybe we can break
    FL> socket.connect and friends once again?  if somebody com-
    FL> plains, just tell them "it's a major release, dammit" ;-)

That's a good point.  A bump in major rev number is an /opportunity/
to break things, like a bone that hasn't healed right, so that they
can be fixed correctly.  We'll lose that for 2.0, mostly likely
because of the tight release schedule.  There's always 3.0 though,
which will mesh nicely with the mythical Py3k.

-Barry



From effbot at telia.com  Fri Jun 30 16:08:13 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 16:08:13 +0200
Subject: [Python-Dev] New PythonLabs site revealed!
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au><005801bfe270$e140d440$f2a6b5d4@hagrid> <14684.42843.472230.609828@anthem.concentric.net>
Message-ID: <016e01bfe29c$a2e8bb00$f2a6b5d4@hagrid>

barry wrote:
> >>>>> "FL" == Fredrik Lundh <effbot at telia.com> writes:
> 
>     FL> btw, now that we're bumping to 2.0, maybe we can break
>     FL> socket.connect and friends once again?  if somebody com-
>     FL> plains, just tell them "it's a major release, dammit" ;-)
> 
> That's a good point.  A bump in major rev number is an /opportunity/
> to break things, like a bone that hasn't healed right, so that they
> can be fixed correctly.  We'll lose that for 2.0, mostly likely
> because of the tight release schedule.

yeah, but I'm sure Guido has the patches somewhere (after
all, the 1.6 release notes still mention this change).  if not,
the mad patcher volunteers to fix (or rather, break) this.

Guido?

</F>




From bwarsaw at beopen.com  Fri Jun 30 16:07:47 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 10:07:47 -0400 (EDT)
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6
References: <ECEPKNMJLHAPFFJHDOJBGEBACPAA.mhammond@skippinet.com.au>
	<ECEPKNMJLHAPFFJHDOJBMEBACPAA.mhammond@skippinet.com.au>
Message-ID: <14684.43443.919858.897738@anthem.concentric.net>

>>>>> "MH" == Mark Hammond <mhammond at skippinet.com.au> writes:

    MH> [I wishing mailing-lists would agree on how they handle
    MH> reply-to :-]

It's fundamentally broken, but the problem is in the mail readers
(MUA).  There's no header (that I'm aware of) that portably tells an
MUA - "Hey, for a group follow up, don't go to the original list, go
to THIS one instead, but for an individual followup (i.e. reply) still
address that to the original author."

This is one reason why munging reply-to is evil.  But in this case
we've agreed that following up to python-dev is more important than
preserving the ability to reply to the author.

-Barry



From mal at lemburg.com  Fri Jun 30 16:11:54 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 16:11:54 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>  
	            <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com>
Message-ID: <395CAAAA.5975A617@lemburg.com>

Guido van Rossum wrote:
> 
> > > Regarding platform.py:
> > >
> > > M.-A. Lemburg writes:
> > >  > Why not simply include it in distutils ?
> > >
> > >   Why not include it in the standard library?
> > >   Guido?  I'll document it if Marc-Andre is willing to provide the
> > > module and the regression test.
> >
> > No objection from here.
> >
> > I've attached my most recent copy to this mail. I'm not sure
> > how to write the regr. test though since output is dependent
> > on the platform running the functions... perhaps I'll just
> > add something like the audio thingie: "This string ought
> > to identify the platform you are currently running... if not,
> > then something is wrong ;-)".
> 
> You didn't include it!

I posted a reply to fix this ;-)
 
> But I vote -1 on this one anyway -- it's too much code and almost by
> its very nature not something that belongs in a "standard" library.
> Plus, I don't want to be responsible for maintaining it.  Sorry,

You don't have to maintain it... I will anyway since it's part
of mxCGIPython.

Anyway, perhaps Greg Ward can find some use for it in
distutils.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Fri Jun 30 16:18:13 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 16:18:13 +0200
Subject: [Python-Dev] SRE incompatibility
Message-ID: <018401bfe29e$07f26720$f2a6b5d4@hagrid>

my latest changes fixed a couple of things, but broke
one of the old RE tests, namely:

    re.match('\\x00ffffffffffffff', '\377') != None

or in other words, long hexadecimal escapes are cast
down to 8-bit characters in RE.

in SRE (after the latest change), they're cast down to
the size of the engine's internal word size (currently 16
bits).

is the old behaviour worth keeping?  I'd rather not make
the engine dependent on string types; it shouldn't really
matter if you're using unicode patterns on 8-bit target
strings, or vice versa.

</F>




From gward at mems-exchange.org  Fri Jun 30 16:13:40 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Fri, 30 Jun 2000 10:13:40 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 07:29:42PM -0400
References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>
Message-ID: <20000630101340.A16350@ludwig.cnri.reston.va.us>

On 29 June 2000, Fred L. Drake, Jr. said:
> 
> Greg Ward wrote in a checkin message:
>  > On second thought, first try for _winreg, and then winreg.  Only if both
>  > fail do we try for win32api/win32con.  If *those* both fail, then we don't
>  > have registry access.  Phew!
> 
> Guido van Rossum writes on python-dev:
>  > Is this smart?  Doesn't the new winreg have a very different I/F than
>  > the old one?
> 
>   No, this is bad.  It *will* break with winreg; if _winreg isn't
> available, it should use the win32api/win32con/whatever stuff; it's a
> Python 1.5.2 interpreter at that point.

What if it's a 1.6a1 or 1.6a2 interpreter?  Presumably people will try
Distutils 0.9 with them.  Should I remove that feature now that 0.9 is
out, but before Python 2.0b1?

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From esr at thyrsus.com  Fri Jun 30 16:27:07 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 30 Jun 2000 10:27:07 -0400
Subject: [Python-Dev] Removing modules
In-Reply-To: <200006301447.JAA30671@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 09:47:29AM -0500
References: <20000629212941.A21563@newcnri.cnri.reston.va.us> <200006301447.JAA30671@cj20424-a.reston1.va.home.com>
Message-ID: <20000630102707.A27830@thyrsus.com>

Guido van Rossum <guido at python.org>:
> > For the "deleted modules" section of the 2.0 article, I drew up a list
> > of modules that might be outdated, mostly the SGI-specific ones.  Are
> > those modules still useful, and do the libraries they were written for
> > still exist?
> 
> Doubtful.  I've asked Sjoerd and Jack, who were most involved in using
> these.
> 
> > For your cogitation, here's the list: sgimodule.c, glmodule.c (and
> > hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c,
> > almodule.c, clmodule.c,  knee.py.
> 
> I'd like to keep knee.py -- it's a nice piece of *documentation* of
> the package import.

+1 on giving the SGI-specific modules the heave-ho.  

Their presence has always struck me as a sort of vermiform appendix in
a core library otherwise clearly aimed at being as platform-independent
as rdeasonably possible (e.g. given the Unix-vs.Windows differences).
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Power concedes nothing without a demand. It never did, and it never will.
Find out just what people will submit to, and you have found out the exact
amount of injustice and wrong which will be imposed upon them; and these will
continue until they are resisted with either words or blows, or with both.
The limits of tyrants are prescribed by the endurance of those whom they
oppress.
	-- Frederick Douglass, August 4, 1857



From gward at mems-exchange.org  Fri Jun 30 16:22:42 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Fri, 30 Jun 2000 10:22:42 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <395CAAAA.5975A617@lemburg.com>; from mal@lemburg.com on Fri, Jun 30, 2000 at 04:11:54PM +0200
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com>
Message-ID: <20000630102242.B16350@ludwig.cnri.reston.va.us>

On 30 June 2000, M.-A. Lemburg said:
> > But I vote -1 on this one anyway -- it's too much code and almost by
> > its very nature not something that belongs in a "standard" library.
> > Plus, I don't want to be responsible for maintaining it.  Sorry,
> 
> You don't have to maintain it... I will anyway since it's part
> of mxCGIPython.
> 
> Anyway, perhaps Greg Ward can find some use for it in
> distutils.

I looked at platform.py once briefly, and my impression was similar to
Guido's: too big!  All I want(ed) is "osname-cpu" -- linux-i386,
solaris-sparc, whatever.  osversion is optional.

But, consider that that the Distutils might want to know if it should
generate RPMs or Debian packages... then the stuff about grokking which
Linux distribution it's running on is relevant.  Argh!

Anyways, I'm already taking static about too much code in the Distutils,
and I partly agree.  (I agree there's a *lot* of code, I know there are
bits that can be refactored and reduced, but I'm not sure it's too
much.)  So I'll stick with sys.platform for now -- it's good enough.

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From sjoerd at oratrix.nl  Fri Jun 30 16:21:53 2000
From: sjoerd at oratrix.nl (Sjoerd Mullender)
Date: Fri, 30 Jun 2000 16:21:53 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32
In-Reply-To: Your message of Fri, 30 Jun 2000 03:29:59 -0700.
             <200006301029.DAA25494@slayer.i.sourceforge.net> 
References: <200006301029.DAA25494@slayer.i.sourceforge.net> 
Message-ID: <20000630142154.968F831047C@bireme.oratrix.nl>

Why was the change that occurred in revision 2.31 reverted?  Accident?

The change log said:
Jack Jansen: Use include "" instead of <>; and staticforward declarations

On Fri, Jun 30 2000 "M.-A. Lemburg" wrote:

> Update of /cvsroot/python/python/dist/src/Objects
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv25442/Objects
> 
> Modified Files:
> 	unicodeobject.c 
> Log Message:
> Marc-Andre Lemburg <mal at lemburg.com>:
> New buffer overflow checks for formatting strings.
> 
> By Trent Mick.
> 
> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.31
> retrieving revision 2.32
> diff -C2 -r2.31 -r2.32
> *** unicodeobject.c	2000/06/29 00:06:39	2.31
> --- unicodeobject.c	2000/06/30 10:29:57	2.32
> ***************
> *** 67,71 ****
>   #include "mymath.h"
>   #include "unicodeobject.h"
> ! #include "ucnhash.h"
>   
>   #if defined(HAVE_LIMITS_H)
> --- 67,71 ----
>   #include "mymath.h"
>   #include "unicodeobject.h"
> ! #include <ucnhash.h>
>   
>   #if defined(HAVE_LIMITS_H)
> ***************
> *** 1245,1249 ****
>   ucnFallthrough:
>               /* fall through on purpose */
> !         default:
>               *p++ = '\\';
>               *p++ = (unsigned char)s[-1];
> --- 1245,1249 ----
>   ucnFallthrough:
>               /* fall through on purpose */
> ! 		default:
>               *p++ = '\\';
>               *p++ = (unsigned char)s[-1];
> ***************
> *** 1252,1256 ****
>       }
>       if (_PyUnicode_Resize(v, (int)(p - buf)))
> ! 	goto onError;
>       return (PyObject *)v;
>       
> --- 1252,1256 ----
>       }
>       if (_PyUnicode_Resize(v, (int)(p - buf)))
> ! 		goto onError;
>       return (PyObject *)v;
>       
> ***************
> *** 4374,4377 ****
> --- 4374,4378 ----
>   static int
>   formatfloat(Py_UNICODE *buf,
> + 	    size_t buflen,
>   	    int flags,
>   	    int prec,
> ***************
> *** 4379,4382 ****
> --- 4380,4385 ----
>   	    PyObject *v)
>   {
> +     /* fmt = '%#.' + `prec` + `type`
> +        worst case length = 3 + 10 (len of INT_MAX) + 1 = 14 (use 20)*/
>       char fmt[20];
>       double x;
> ***************
> *** 4387,4395 ****
>       if (prec < 0)
>   	prec = 6;
> -     if (prec > 50)
> - 	prec = 50; /* Arbitrary limitation */
>       if (type == 'f' && (fabs(x) / 1e25) >= 1e25)
>   	type = 'g';
>       sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type);
>       return usprintf(buf, fmt, x);
>   }
> --- 4390,4408 ----
>       if (prec < 0)
>   	prec = 6;
>       if (type == 'f' && (fabs(x) / 1e25) >= 1e25)
>   	type = 'g';
>       sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type);
> +     /* worst case length calc to ensure no buffer overrun:
> +          fmt = %#.<prec>g
> +          buf = '-' + [0-9]*prec + '.' + 'e+' + (longest exp
> +             for any double rep.)
> +          len = 1 + prec + 1 + 2 + 5 = 9 + prec
> +        If prec=0 the effective precision is 1 (the leading digit is
> +        always given), therefore increase by one to 10+prec. */
> +     if (buflen <= (size_t)10 + (size_t)prec) {
> + 	PyErr_SetString(PyExc_OverflowError,
> + 	    "formatted float is too long (precision too long?)");
> + 	return -1;
> +     }
>       return usprintf(buf, fmt, x);
>   }
> ***************
> *** 4397,4400 ****
> --- 4410,4414 ----
>   static int
>   formatint(Py_UNICODE *buf,
> + 	  size_t buflen,
>   	  int flags,
>   	  int prec,
> ***************
> *** 4402,4405 ****
> --- 4416,4421 ----
>   	  PyObject *v)
>   {
> +     /* fmt = '%#.' + `prec` + 'l' + `type`
> +        worst case length = 3 + 10 (len of INT_MAX) + 1 + 1 = 15 (use 20)*/
>       char fmt[20];
>       long x;
> ***************
> *** 4410,4413 ****
> --- 4426,4436 ----
>       if (prec < 0)
>   	prec = 1;
> +     /* buf = '+'/'-'/'0'/'0x' + '[0-9]'*max(prec,len(x in octal))
> +        worst case buf = '0x' + [0-9]*prec, where prec >= 11 */
> +     if (buflen <= 13 || buflen <= (size_t)2+(size_t)prec) {
> +         PyErr_SetString(PyExc_OverflowError,
> +             "formatted integer is too long (precision too long?)");
> +         return -1;
> +     }
>       sprintf(fmt, "%%%s.%dl%c", (flags & F_ALT) ? "#" : "", prec, type);
>       return usprintf(buf, fmt, x);
> ***************
> *** 4416,4421 ****
>   static int
>   formatchar(Py_UNICODE *buf,
> ! 	   PyObject *v)
>   {
>       if (PyUnicode_Check(v)) {
>   	if (PyUnicode_GET_SIZE(v) != 1)
> --- 4439,4446 ----
>   static int
>   formatchar(Py_UNICODE *buf,
> !            size_t buflen,
> !            PyObject *v)
>   {
> +     /* presume that the buffer is at least 2 characters long */
>       if (PyUnicode_Check(v)) {
>   	if (PyUnicode_GET_SIZE(v) != 1)
> ***************
> *** 4447,4450 ****
> --- 4472,4485 ----
>   }
>   
> + /* fmt%(v1,v2,...) is roughly equivalent to sprintf(fmt, v1, v2, ...)
> + 
> +    FORMATBUFLEN is the length of the buffer in which the floats, ints, &
> +    chars are formatted. XXX This is a magic number. Each formatting
> +    routine does bounds checking to ensure no overflow, but a better
> +    solution may be to malloc a buffer of appropriate size for each
> +    format. For now, the current solution is sufficient.
> + */
> + #define FORMATBUFLEN (size_t)120
> + 
>   PyObject *PyUnicode_Format(PyObject *format,
>   			   PyObject *args)
> ***************
> *** 4506,4513 ****
>   	    PyObject *v = NULL;
>   	    PyObject *temp = NULL;
> ! 	    Py_UNICODE *buf;
>   	    Py_UNICODE sign;
>   	    int len;
> ! 	    Py_UNICODE tmpbuf[120]; /* For format{float,int,char}() */
>   
>   	    fmt++;
> --- 4541,4548 ----
>   	    PyObject *v = NULL;
>   	    PyObject *temp = NULL;
> ! 	    Py_UNICODE *pbuf;
>   	    Py_UNICODE sign;
>   	    int len;
> ! 	    Py_UNICODE formatbuf[FORMATBUFLEN]; /* For format{float,int,char}() */
>   
>   	    fmt++;
> ***************
> *** 4659,4664 ****
>   
>   	    case '%':
> ! 		buf = tmpbuf;
> ! 		buf[0] = '%';
>   		len = 1;
>   		break;
> --- 4694,4700 ----
>   
>   	    case '%':
> ! 		pbuf = formatbuf;
> ! 		/* presume that buffer length is at least 1 */
> ! 		pbuf[0] = '%';
>   		len = 1;
>   		break;
> ***************
> *** 4696,4700 ****
>   			goto onError;
>   		}
> ! 		buf = PyUnicode_AS_UNICODE(temp);
>   		len = PyUnicode_GET_SIZE(temp);
>   		if (prec >= 0 && len > prec)
> --- 4732,4736 ----
>   			goto onError;
>   		}
> ! 		pbuf = PyUnicode_AS_UNICODE(temp);
>   		len = PyUnicode_GET_SIZE(temp);
>   		if (prec >= 0 && len > prec)
> ***************
> *** 4710,4715 ****
>   		if (c == 'i')
>   		    c = 'd';
> ! 		buf = tmpbuf;
> ! 		len = formatint(buf, flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> --- 4746,4752 ----
>   		if (c == 'i')
>   		    c = 'd';
> ! 		pbuf = formatbuf;
> ! 		len = formatint(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE),
> ! 			flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> ***************
> *** 4719,4725 ****
>   		    if ((flags&F_ALT) &&
>   			(c == 'x' || c == 'X') &&
> ! 			buf[0] == '0' && buf[1] == c) {
> ! 			*res++ = *buf++;
> ! 			*res++ = *buf++;
>   			rescnt -= 2;
>   			len -= 2;
> --- 4756,4762 ----
>   		    if ((flags&F_ALT) &&
>   			(c == 'x' || c == 'X') &&
> ! 			pbuf[0] == '0' && pbuf[1] == c) {
> ! 			*res++ = *pbuf++;
> ! 			*res++ = *pbuf++;
>   			rescnt -= 2;
>   			len -= 2;
> ***************
> *** 4736,4741 ****
>   	    case 'g':
>   	    case 'G':
> ! 		buf = tmpbuf;
> ! 		len = formatfloat(buf, flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> --- 4773,4779 ----
>   	    case 'g':
>   	    case 'G':
> ! 		pbuf = formatbuf;
> ! 		len = formatfloat(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE),
> ! 			flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> ***************
> *** 4746,4751 ****
>   
>   	    case 'c':
> ! 		buf = tmpbuf;
> ! 		len = formatchar(buf, v);
>   		if (len < 0)
>   		    goto onError;
> --- 4784,4789 ----
>   
>   	    case 'c':
> ! 		pbuf = formatbuf;
> ! 		len = formatchar(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), v);
>   		if (len < 0)
>   		    goto onError;
> ***************
> *** 4759,4764 ****
>   	    }
>   	    if (sign) {
> ! 		if (*buf == '-' || *buf == '+') {
> ! 		    sign = *buf++;
>   		    len--;
>   		}
> --- 4797,4802 ----
>   	    }
>   	    if (sign) {
> ! 		if (*pbuf == '-' || *pbuf == '+') {
> ! 		    sign = *pbuf++;
  		    len--;
>   		}
> ***************
> *** 4796,4800 ****
>   	    if (sign && fill == ' ')
>   		*res++ = sign;
> ! 	    memcpy(res, buf, len * sizeof(Py_UNICODE));
>   	    res += len;
>   	    rescnt -= len;
> --- 4834,4838 ----
>   	    if (sign && fill == ' ')
>   		*res++ = sign;
> ! 	    memcpy(res, pbuf, len * sizeof(Py_UNICODE));
>   	    res += len;
>   	    rescnt -= len;
> 
> 

-- Sjoerd Mullender <sjoerd.mullender at oratrix.com>



From akuchlin at mems-exchange.org  Fri Jun 30 16:29:00 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 30 Jun 2000 10:29:00 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jun 30, 2000 at 04:18:13PM +0200
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid>
Message-ID: <20000630102900.A19597@kronos.cnri.reston.va.us>

On Fri, Jun 30, 2000 at 04:18:13PM +0200, Fredrik Lundh wrote:
>    re.match('\\x00ffffffffffffff', '\377') != None
>or in other words, long hexadecimal escapes are cast
>down to 8-bit characters in RE.

This is for compatibility with Python string literals:

kronos Python-1.6>./python
>>> '\x00fffffff'
'\377'
>>> u'\x00fffffff'
u'\uFFFF'

(Where do these semantics come from, BTW?  C's \x seems to take any
number of hex digits but then reports an error if the character is
greater than 256, too large to fit into a byte.)

Note that the \u escape for Unicode characters uses exactly 4 digits,
no more, no less.  It would certainly be simpler and clearer to only
support a fixed number of digits with \x, since I find the casting
down behaviour is magical and not obvious.  But I don't know if we
want to make that change now.  (Guido now realizes the downside to
numbering it 2.0, as everyone hurries to suggest their favorite
backward-incompatible change.)

That doesn't help with regexes, of course, since a pattern might be
written as a regular string but be intended to match Unicode.  Maybe
the simplest rule is the best; always take 4 digits, even if it winds
up being incompatible with the \x in string literals.

--amk



From fdrake at beopen.com  Fri Jun 30 16:33:47 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 10:33:47 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: <20000630101340.A16350@ludwig.cnri.reston.va.us>
References: <200006292305.QAA11929@slayer.i.sourceforge.net>
	<200006300020.TAA21877@cj20424-a.reston1.va.home.com>
	<14683.56294.836295.923883@cj42289-a.reston1.va.home.com>
	<20000630101340.A16350@ludwig.cnri.reston.va.us>
Message-ID: <14684.45003.193701.382599@cj42289-a.reston1.va.home.com>

Greg Ward writes:
 > What if it's a 1.6a1 or 1.6a2 interpreter?  Presumably people will try
 > Distutils 0.9 with them.  Should I remove that feature now that 0.9 is
 > out, but before Python 2.0b1?

  You're placing too much value on code labelled "alpha". ;)  There
are two interesting versions -- 1.5.2 (since you scrapped support for
versions before that), and 2.0.  And the CVS version is the closest
approximation to 2.0 that anyone has.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Fri Jun 30 16:38:51 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 10:38:51 -0400 (EDT)
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <20000630102242.B16350@ludwig.cnri.reston.va.us>
References: <20000629233003.A1766@beelzebub>
	<14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
	<395C681D.C3211F6@lemburg.com>
	<14684.41320.38954.833643@cj42289-a.reston1.va.home.com>
	<395CA354.16AC5B7E@lemburg.com>
	<200006301455.JAA30721@cj20424-a.reston1.va.home.com>
	<395CAAAA.5975A617@lemburg.com>
	<20000630102242.B16350@ludwig.cnri.reston.va.us>
Message-ID: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>

Greg Ward writes:
 > But, consider that that the Distutils might want to know if it should
 > generate RPMs or Debian packages... then the stuff about grokking which
 > Linux distribution it's running on is relevant.  Argh!

  Why would you need to figure this out?  Are you selecting a
platform-specific packaging system automatically?  In that case, I'd
search for the presence of the tools rather than asking what sort of
distribution you're running on -- several distros use RPM, a few use
.deb packages, etc.  When the user specifies one on the command line,
just use the one they name and be done with it.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Fri Jun 30 16:53:31 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 16:53:31 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects
 unicodeobject.c,2.31,2.32
References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl>
Message-ID: <395CB46B.34053D3E@lemburg.com>

> Why was the change that occurred in revision 2.31 reverted?  Accident?
> 
> The change log said:
> Jack Jansen: Use include "" instead of <>; and staticforward declarations

Accident... I'll revert that change.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Fri Jun 30 18:07:16 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 11:07:16 -0500
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: Your message of "Fri, 30 Jun 2000 16:18:13 +0200."
             <018401bfe29e$07f26720$f2a6b5d4@hagrid> 
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> 
Message-ID: <200006301607.LAA10829@cj20424-a.reston1.va.home.com>

> my latest changes fixed a couple of things, but broke
> one of the old RE tests, namely:
> 
>     re.match('\\x00ffffffffffffff', '\377') != None
> 
> or in other words, long hexadecimal escapes are cast
> down to 8-bit characters in RE.
> 
> in SRE (after the latest change), they're cast down to
> the size of the engine's internal word size (currently 16
> bits).
> 
> is the old behaviour worth keeping?  I'd rather not make
> the engine dependent on string types; it shouldn't really
> matter if you're using unicode patterns on 8-bit target
> strings, or vice versa.

To someone familiar with '\x00ffffffffffffff' == '\377', the failure
is surprising.  What Would Larry Do?  (I.e. is this in Perl?)

Maybe make it dependent on the type of the searched string ('\377')
rather than on the type of the pattern?

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



From skip at mojam.com  Fri Jun 30 15:54:49 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 30 Jun 2000 08:54:49 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <20000629232733.D24811@activestate.com>
References: <200006300608.XAA13124@slayer.i.sourceforge.net>
	<20000629232733.D24811@activestate.com>
Message-ID: <14684.42665.221905.911205@beluga.mojam.com>

    Trent> Cool

Thanks.

    >> To run the entire test suite, make the "test" target at the top level:
    >> 
    >> cd ...
    >> make test

    Trent> This is a UN*Xism, on Windows and UN*X:
    Trent> cd ...\Lib\test
    Trent> python regrtest.py

Thanks, I'll check into it.  I'm a Unix weenie so am (blissfully) unaware of 
how Windows weenies do these things... ;-)

    Trent> A sample walk through to create a test might make it more
    Trent> approachable for people. As well, it would be helpful to mention
    Trent> test_support.{verbose|TESTFN|...}.  But I have no right to bitch
    Trent> about good work.

I'll check into that as well.  The README file was created in about 30
minutes and was a good excuse to test my checkin capabilities on something
that wouldn't break anything. ;-)

Skip



From mhammond at skippinet.com.au  Fri Jun 30 17:48:43 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 1 Jul 2000 01:48:43 +1000
Subject: [Python-Dev] Checked in new PC\config.h
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEBPCPAA.mhammond@skippinet.com.au>

Hi all,
	I noticed that PC\config.h still had a reference to "Python16.lib".  I
simply checked in a new version without submitting a patch or following any
other process.  I hope this was appropriate.

Mark.




From akuchlin at mems-exchange.org  Fri Jun 30 18:03:48 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 30 Jun 2000 12:03:48 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <200006301607.LAA10829@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 11:07:16AM -0500
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com>
Message-ID: <20000630120348.C19597@kronos.cnri.reston.va.us>

On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote:
>To someone familiar with '\x00ffffffffffffff' == '\377', the failure
>is surprising.  What Would Larry Do?  (I.e. is this in Perl?)

It uses two digits: "\x00ffff" is the string "<binary 0>ffff".

>Maybe make it dependent on the type of the searched string ('\377')
>rather than on the type of the pattern?

Won't work; you could just be compiling a pattern to make a regex
object, and have no idea what you're matching against.

--amk



From jeremy at beopen.com  Fri Jun 30 18:10:09 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 12:10:09 -0400 (EDT)
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid>
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid>
Message-ID: <14684.50785.245652.345591@bitdiddle.concentric.net>

I don't know if this is related, exactly, but there is some kind of
problem with the current test.

When I run make test, I see:

test test_sre crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation

tabnanny thinks test_sre.py is fine, so I'm not sure what the problem
is.

Jeremy



From tim_one at email.msn.com  Fri Jun 30 18:18:03 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 12:18:03 -0400
Subject: [Python-Dev] Checked in new PC\config.h
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEBPCPAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEHDGHAA.tim_one@email.msn.com>

[Mark Hammond]
> 	I noticed that PC\config.h still had a reference to
> "Python16.lib".  I simply checked in a new version without
> submitting a patch or following any other process.  I hope
> this was appropriate.

IMO, if you're an expert in an area and need to make a change in that area
that indeed needs to be made and isn't going to screw anybody (and because
you're an expert in that area, you're not wrong in your judgment of that
<wink>), just do it!  We'll see the diffs come by later.  Guido, Barry,
Jeremy, & Fred have been working that way a long time now.  If they didn't
want us to work that way too, they shouldn't have given us the ability to
commit.

empowering-the-masses-ly y'rs  - tim





From guido at python.org  Fri Jun 30 19:18:10 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 12:18:10 -0500
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: Your message of "Fri, 30 Jun 2000 12:03:48 -0400."
             <20000630120348.C19597@kronos.cnri.reston.va.us> 
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com>  
            <20000630120348.C19597@kronos.cnri.reston.va.us> 
Message-ID: <200006301718.MAA12448@cj20424-a.reston1.va.home.com>

> On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote:
> >To someone familiar with '\x00ffffffffffffff' == '\377', the failure
> >is surprising.  What Would Larry Do?  (I.e. is this in Perl?)
> 
> It uses two digits: "\x00ffff" is the string "<binary 0>ffff".
> 
> >Maybe make it dependent on the type of the searched string ('\377')
> >rather than on the type of the pattern?
> 
> Won't work; you could just be compiling a pattern to make a regex
> object, and have no idea what you're matching against.

OK.  Let's change our spec.

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



From guido at python.org  Fri Jun 30 19:26:51 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 12:26:51 -0500
Subject: [Python-Dev] Checked in new PC\config.h
In-Reply-To: Your message of "Fri, 30 Jun 2000 12:18:03 -0400."
             <LNBBLJKPBEHFEDALKOLCMEHDGHAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCMEHDGHAA.tim_one@email.msn.com> 
Message-ID: <200006301726.MAA12560@cj20424-a.reston1.va.home.com>

> IMO, if you're an expert in an area and need to make a change in that area
> that indeed needs to be made and isn't going to screw anybody (and because
> you're an expert in that area, you're not wrong in your judgment of that
> <wink>), just do it!  We'll see the diffs come by later.  Guido, Barry,
> Jeremy, & Fred have been working that way a long time now.  If they didn't
> want us to work that way too, they shouldn't have given us the ability to
> commit.

Exactly!

So far it's working like a charm!

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



From tim_one at email.msn.com  Fri Jun 30 18:38:21 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 12:38:21 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <20000630102900.A19597@kronos.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEHFGHAA.tim_one@email.msn.com>

[Andrew Kuchling]
> ...
> This is for compatibility with Python string literals:
>
> kronos Python-1.6>./python
> >>> '\x00fffffff'
> '\377'
> >>> u'\x00fffffff'
> u'\uFFFF'
>
> (Where do these semantics come from, BTW?  C's \x seems to take any
> number of hex digits but then reports an error if the character is
> greater than 256, too large to fit into a byte.)

The behavior of \x in C is mostly implementation-defined.  The committee
knew that C had to do *something* to support "large characters" down the
road, but in those early days they had no clear idea exactly what.  So,
rather than do something sensible <0.5 wink>, they invented a perfectly
general mechanism without portable semantics.  "C itself" isn't complaining
if the character "is greater than 256", it's the specific implementation of
C you're using that's complaining.  A different implementation is free to (&
probably will!) do something different.

Guido adopted the most commonly implemented semantics (ignore all but the
last byte) in Python, apparently under the delusion that this would be a
Good Thing <wink>.  Marc-Andre followed suit by generalizing this madness to
Unicode.

> Note that the \u escape for Unicode characters uses exactly 4 digits,
> no more, no less.

I pushed for that obnoxiously.  Glad you appreciate it <wink>.  Java does
the same.

> It would certainly be simpler and clearer to only support a fixed
> number of digits with \x, since I find the casting down behaviour is
> magical and not obvious.

Yes, it's basically nuts.

> But I don't know if we want to make that change now.

No from me, because it may break stuff.  Wait for Python 2.0 <ahem>.

> (Guido now realizes the downside to numbering it 2.0, as everyone
> hurries to suggest their favorite backward-incompatible change.)

Guido always realized that, I believe.  It's a "least of evils" kind of
thing, mixed with a celebration, not a pure win.

> That doesn't help with regexes, of course, since a pattern might be
> written as a regular string but be intended to match Unicode.  Maybe
> the simplest rule is the best; always take 4 digits, even if it winds
> up being incompatible with the \x in string literals.

I vote for backward compatibility for now, and not only because that will
irritate /F the most.





From bwarsaw at beopen.com  Fri Jun 30 18:51:15 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 12:51:15 -0400 (EDT)
Subject: [Python-Dev] --with-cycle-gc switch
Message-ID: <14684.53251.309942.13110@anthem.concentric.net>

I don't like --with-cycle-gc as the configure switch, and
unfortunately configure is explicitly designed not to complain about
bogus switches.  I just typed --without-gc and was momentarily
surprised that the module was still enabled.

I propose to change the switch to --with(out)-gc and to not recognize
--with(out)-cycle-gc.  The switch hasn't been there long enough to
support both.

-Barry



From jeremy at beopen.com  Fri Jun 30 19:02:42 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 13:02:42 -0400 (EDT)
Subject: [Python-Dev] --with-cycle-gc switch
In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net>
References: <14684.53251.309942.13110@anthem.concentric.net>
Message-ID: <14684.53938.307841.921051@bitdiddle.concentric.net>

The problem with the name --without-gc is that it suggests a build
without any garbage collection.  The new patch only handles one
special case of garbage collection.  The name --without-cycle-gc is a
little unwieldy, but clearer.

Jeremy



From Vladimir.Marangozov at inrialpes.fr  Fri Jun 30 19:11:50 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 19:11:50 +0200 (CEST)
Subject: [Python-Dev] --with-cycle-gc switch
In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 12:51:15 PM
Message-ID: <200006301711.TAA21382@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> I propose to change the switch to --with(out)-gc and to not recognize
> --with(out)-cycle-gc.  The switch hasn't been there long enough to
> support both.

-0

for the reason summarized by Jeremy

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From effbot at telia.com  Fri Jun 30 19:33:55 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 19:33:55 +0200
Subject: [Python-Dev] SRE: a minor glitch in re.py
References: <200006301625.JAA32503@slayer.i.sourceforge.net>
Message-ID: <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid>

from the new re.py:

> ! # change this to "pre" if your regexps stopped working.  don't
> ! # forget to send a bug report to <some suitable address>

is bugs-py at python.org suitable?

or should we refer people to 
http://www.python.org/search/search_bugs.html

or should they pester me directly? (i.e. effbot at telia.com)

</F>





From guido at python.org  Fri Jun 30 20:33:46 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 13:33:46 -0500
Subject: [Python-Dev] SRE: a minor glitch in re.py
In-Reply-To: Your message of "Fri, 30 Jun 2000 19:33:55 +0200."
             <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> 
References: <200006301625.JAA32503@slayer.i.sourceforge.net>  
            <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> 
Message-ID: <200006301833.NAA18667@cj20424-a.reston1.va.home.com>

> from the new re.py:
> 
> > ! # change this to "pre" if your regexps stopped working.  don't
> > ! # forget to send a bug report to <some suitable address>
> 
> is bugs-py at python.org suitable?
> 
> or should we refer people to 
> http://www.python.org/search/search_bugs.html
> 
> or should they pester me directly? (i.e. effbot at telia.com)

Probably.  You decide and check it in!

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



From bwarsaw at beopen.com  Fri Jun 30 19:39:12 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 13:39:12 -0400 (EDT)
Subject: [Python-Dev] --with-cycle-gc switch
References: <14684.53251.309942.13110@anthem.concentric.net>
	<200006301711.TAA21382@python.inrialpes.fr>
Message-ID: <14684.56128.700037.255534@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:

    VM> -0

    VM> for the reason summarized by Jeremy

Okay, I'll leave it alone.



From Vladimir.Marangozov at inrialpes.fr  Fri Jun 30 19:52:15 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 19:52:15 +0200 (CEST)
Subject: [Python-Dev] Oops on AIX
Message-ID: <200006301752.TAA22474@python.inrialpes.fr>

After the CVS commit storm that occurred during the last 3 days,
I wanted to validate the current build on AIX. And I am stalled.

I am not sure, but it seems like the errors I get relate with the
latest 64-bit support patches, and I don't dare to suggest corrections
in this area, so I welcome any help...


        xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c
"methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed.

        xlc_r  -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c
"./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined.
"./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h.
make: 1254-004 The error code from the last command is 1.

Thanks.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From effbot at telia.com  Fri Jun 30 19:53:45 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 19:53:45 +0200
Subject: [Python-Dev] SRE incompatibility
References: <LNBBLJKPBEHFEDALKOLCAEHFGHAA.tim_one@email.msn.com>
Message-ID: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid>

tim wrote:
> > That doesn't help with regexes, of course, since a pattern might be
> > written as a regular string but be intended to match Unicode.  Maybe
> > the simplest rule is the best; always take 4 digits, even if it winds
> > up being incompatible with the \x in string literals.
> 
> I vote for backward compatibility for now, and not only because that will
> irritate /F the most.

backward compatibility with what?  8-bit string literals or unicode
string literals?

the problem here is that the pattern is compiled once (from either
8-bit or unicode strings), and can then be used on either 8-bit or
unicode targets.  to be fully backwards compatible, this means that
the compiler should use 8 bits, no matter what string type you're
using.

another solution would be to use the type of the pattern string to
choose between 8 and 16 bits.  I almost implemented that, before
I realized that it broke the following rather nice property:

    sre.compile("some pattern") == sre.compile(u"some pattern")

(well, the pattern type doesn't implement __cmp__, but you get the
idea).  the current implementation guarantees "==", but I'm planning
to change that to "is" (!).

anyway, I suspect it's too late to change this in 2.0b1.  if enough
people complain about this, we can always label it a "critical bug",
and do something about it in b2.

</F>




From bwarsaw at beopen.com  Fri Jun 30 20:04:06 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 14:04:06 -0400 (EDT)
Subject: [Python-Dev] Odd behavior with `make test'
Message-ID: <14684.57622.9807.868551@anthem.concentric.net>

make test is behaving strangely.  The first time I ran it I got

test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation

which I believe Jeremy has seen with test_sre.  tabnanny says
everything's fine, and running the module manually (and individually
w/ regrtest) shows no problems with the test.

Similarly, I got a different crash in test_sre.  It says:

test test_sre failed -- sre.search

and I also get

test test_re failed -- re.search

I'm also getting bizare stuff like

test test_strftime crashed -- exceptions.AttributeError : match
test test_tokenize crashed -- exceptions.AttributeError : compile
test test_xmllib crashed -- exceptions.AttributeError : compile

This is all with a CVS updated Python 2.0b1.

Now if I run "./python Lib/test/test_mmap.py" manually, this succeeds,
and now either the failures go away or are transmorgrified into
something more reasonable:

mmap, strftime, tokenize, sre, and xmllib all pass.

test_re still fails, but this time with

test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou"

Blowing away the Lib/test/*.pyc's doesn't seem to re-trigger the
problem once it's fixed, but doing a `make distclean' and `make test'
gets me back to the initial situation.

Weird!
-Barry



From effbot at telia.com  Fri Jun 30 20:12:11 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:12:11 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
References: <20000629232733.D24811@activestate.com> <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com> <20000629235247.A25090@activestate.com>
Message-ID: <037e01bfe2be$b814d5a0$f2a6b5d4@hagrid>

trent wrote:
> On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote:
> > BTW, I'd just like to say what a delight it is to work with *all* of you
> > folks!
> 
> I feel a group hug coming on in the morning. Or maybe I am just moved by the
> beer that I had for dinner. :)

beer for dinner?  what an excellent idea.  didn't I have
some strong lager somewhere?

ah, yes...

hey, maybe I should rewrite the SRE core again, to get
rid of those last glitches...




From effbot at telia.com  Fri Jun 30 20:15:37 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:15:37 +0200
Subject: [Python-Dev] Odd behavior with `make test'
References: <14684.57622.9807.868551@anthem.concentric.net>
Message-ID: <038601bfe2bf$31c52da0$f2a6b5d4@hagrid>

> test_re still fails, but this time with
> 
> test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou"

note that test_re should fail; someone (me?) needs to
regenerate the output file.

the rest looks a bit scary, to say the least.  does someone (sre?)
overwrite something? does anyone have purify (dmalloc, fences,
whatever) within reach?

</F>




From Vladimir.Marangozov at inrialpes.fr  Fri Jun 30 20:22:03 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 20:22:03 +0200 (CEST)
Subject: [Python-Dev] Odd behavior with `make test'
In-Reply-To: <14684.57622.9807.868551@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 02:04:06 PM
Message-ID: <200006301822.UAA22606@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> make test is behaving strangely.  The first time I ran it I got

On which platform? Linux seems to do fine with most of this.
On AIX (after some hacking related to my previous msg "Oops on AIX",
I managed to compile everything but I'll dump an error log on Trent :-)

> 
> test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation

same here

> test test_sre failed -- sre.search
> ...
> test test_re failed -- re.search
> ...
> test test_strftime crashed -- exceptions.AttributeError : match
> test test_tokenize crashed -- exceptions.AttributeError : compile
> test test_xmllib crashed -- exceptions.AttributeError : compile

same here. I believe Guido & al. are aware as per the checkin msg,
saying that  /F promises to fix this.

But on AIX I get in addition to the above failures:

test test_array failed -- array('b') overflowed assigning -128L


-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From tim_one at email.msn.com  Fri Jun 30 20:20:46 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 14:20:46 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEHLGHAA.tim_one@email.msn.com>

[Tim]
> I vote for backward compatibility for now, and not only because
> that will irritate /F the most.

[/F]
> backward compatibility with what?

1.5.2.

> 8-bit string literals

At least, because they were in 1.5.2.

> or unicode string literals?

I'm sorry \x escapes are even allowed in those -- \x notation is a gimmick
for making strings hold arbitrary binary data, which we're trying to get
away from.  To the extent that they make any sense at all in Unicode
strings, \u should be used instead.

> the problem here is that the pattern is compiled once (from either
> 8-bit or unicode strings), and can then be used on either 8-bit or
> unicode targets.  to be fully backwards compatible, this means that
> the compiler should use 8 bits, no matter what string type you're
> using.

Unicode strings weren't in 1.5.2, so there can't possibly be a backwards
compatibility issue with them -- at least not in the sense I'm using the
phrase here.

> another solution would be to use the type of the pattern string to
> choose between 8 and 16 bits.  I almost implemented that, before
> I realized that it broke the following rather nice property:
>
>     sre.compile("some pattern") == sre.compile(u"some pattern")
>
> (well, the pattern type doesn't implement __cmp__, but you get the
> idea).  the current implementation guarantees "==", but I'm planning
> to change that to "is" (!).

Do you mean that, e.g.,

    sre.compile("\u0045") == sre.compile(u"\u0045")

too?  If so, that doesn't make any sense to me (interpreting \u in 8-bit
strings is even more confused than interpreting \x in Unicode strings).  But
if you didn't mean to include this case, then the equality doesn't actually
hold now, so there's nothing to preserve <wink>.

> anyway, I suspect it's too late to change this in 2.0b1.  if enough
> people complain about this, we can always label it a "critical bug",
> and do something about it in b2.

I think the real problem here was MAL's generalization of \x to 2-byte stuff
in Unicode strings.  If Unicode strings *have* to support \x, then

    \x0123456789abcdef

in Unicode strings should act like

    \u00ef

in Unicode strings, and SRE should play along with that too.  \x was broken
to begin with; better to wipe it out than try to generalize it.

OTOH, I didn't get much sleep last night <0.8 wink>.





From effbot at telia.com  Fri Jun 30 20:29:54 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:29:54 +0200
Subject: [Python-Dev] Odd behavior with `make test'
References: <200006301822.UAA22606@python.inrialpes.fr>
Message-ID: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid>

> > test test_sre failed -- sre.search
> > ...
> > test test_re failed -- re.search
> > ...
> > test test_strftime crashed -- exceptions.AttributeError : match
> > test test_tokenize crashed -- exceptions.AttributeError : compile
> > test test_xmllib crashed -- exceptions.AttributeError : compile
> 
> same here. I believe Guido & al. are aware as per the checkin msg,
> saying that  /F promises to fix this.

I have no idea what causes this.

however, I just noticed that evil tabs had snucked their way into
sre_parse and sre_compile.  new, properly untabified versions are
on their way to the repository.

maybe the interpreter messes up badly once -tt has reported an
error?  try removing -tt from the TESTPYTHON line in the makefile,
and see what happens.

</F>




From gward at mems-exchange.org  Fri Jun 30 20:26:51 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Fri, 30 Jun 2000 14:26:51 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jun 30, 2000 at 10:38:51AM -0400
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> <20000630102242.B16350@ludwig.cnri.reston.va.us> <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>
Message-ID: <20000630142650.B16028@ludwig.cnri.reston.va.us>

On 30 June 2000, Fred L. Drake, Jr. said:
>   Why would you need to figure this out?  Are you selecting a
> platform-specific packaging system automatically?  In that case, I'd
> search for the presence of the tools rather than asking what sort of
> distribution you're running on -- several distros use RPM, a few use
> .deb packages, etc.  When the user specifies one on the command line,
> just use the one they name and be done with it.

Currently it's up to the user to decide which kind of built distribution
they want, with stupid defaults: dumb tarball for Unix, dumb ZIP file
for Windows.  If you want an RPM or a Windows installer, you have to say 
so explicitly.  This is not a big deal, but it might be nice to detect
automatically if we can build (say) RPMs and do so.

This is not a high-priority feature, though.  I'll accept a patch if
someone out there is interested enough to implement it.

        Greg



From effbot at telia.com  Fri Jun 30 20:37:16 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:37:16 +0200
Subject: [Python-Dev] SRE incompatibility
References: <LNBBLJKPBEHFEDALKOLCEEHLGHAA.tim_one@email.msn.com>
Message-ID: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid>

tim wrote:
> > to be fully backwards compatible, this means that the compiler
> > should use 8 bits, no matter what string type you're using.
...
> I think the real problem here was MAL's generalization of \x to 2-byte stuff
> in Unicode strings.  If Unicode strings *have* to support \x, then
> 
>     \x0123456789abcdef
> 
> in Unicode strings should act like
> 
>     \u00ef
> 
> in Unicode strings, and SRE should play along with that too.  \x was broken
> to begin with; better to wipe it out than try to generalize it.

I think this means that we agree -- \x is a wart that can only
be used to embed *binary bytes* in a string.

</F>




From Vladimir.Marangozov at inrialpes.fr  Fri Jun 30 20:37:35 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 20:37:35 +0200 (CEST)
Subject: [Python-Dev] Odd behavior with `make test'
In-Reply-To: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 30, 2000 08:29:54 PM
Message-ID: <200006301837.UAA22688@python.inrialpes.fr>

Fredrik Lundh wrote:
> 
> maybe the interpreter messes up badly once -tt has reported an
> error?  try removing -tt from the TESTPYTHON line in the makefile,
> and see what happens.

Matches Barry's report exactly.
To which I'll add the array('b') failure which is not due to an
optimization of arraymodule.c. Will investigate this tonight.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From DavidA at ActiveState.com  Fri Jun 30 20:43:14 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 30 Jun 2000 11:43:14 -0700
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <200006301455.JAA30721@cj20424-a.reston1.va.home.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJEEGJCLAA.DavidA@ActiveState.com>

> But I vote -1 on this one anyway -- it's too much code and almost by
> its very nature not something that belongs in a "standard" library.
> Plus, I don't want to be responsible for maintaining it.  Sorry,
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Not that I hope to override the heavy -1, but I don't agree with the second
point.  It embodies a huge amount of knowledge that is needed to write
portable code.  As such, IMO, it _does_ belong in the standard library.  How
is it different in its nature from sys.platform, which is only a much weaker
version of the same concept?

--david




From skip at mojam.com  Fri Jun 30 19:35:20 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 30 Jun 2000 12:35:20 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5
In-Reply-To: <200006301841.LAA20523@slayer.i.sourceforge.net>
References: <200006301841.LAA20523@slayer.i.sourceforge.net>
Message-ID: <14684.55896.890339.982232@beluga.mojam.com>

    Fred> The new copyright / license.
    ...
    Fred> ! ...  IN NO EVENT SHALL THE REGENTS OR
    Fred> ! CONTRIBUTORS BE LIABLE FOR ...

Who are the "regents" and the "contributors"?  Should those terms be
defined somewhere?

not-a-lawyer-and-never-wanted-to-be-ly y'rs,

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From nascheme at enme.ucalgary.ca  Fri Jun 30 20:53:06 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 12:53:06 -0600
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1
In-Reply-To: <14684.7005.661874.713000@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 11:00:29PM -0500
References: <200006300502.WAA03286@slayer.i.sourceforge.net> <14684.7005.661874.713000@beluga.mojam.com>
Message-ID: <20000630125306.B32568@acs.ucalgary.ca>

On Thu, Jun 29, 2000 at 11:00:29PM -0500, Skip Montanaro wrote:
> I can all but guarantee you this test will always fail.  Printing absolute
> machine addresses (via calls to id() in this case) in test cases should be
> verboten.

This test script should be better.  It doesn't generate any
output (the stuff the old script printed was pretty useless
anyhow).

  Neil
-------------- next part --------------
import gc
from test_support import *

def test_list():
    l = []
    l.append(l)
    gc.collect()
    del l
    assert gc.collect() == 1

def test_dict():
    d = {}
    d[1] = d
    gc.collect()
    del d
    assert gc.collect() == 1

def test_tuple():
    l = []
    t = (l,)
    l.append(t)
    gc.collect()
    del t
    del l
    assert gc.collect() == 2

def test_class():
    class A:
        pass
    A.a = A
    gc.collect()
    del A
    assert gc.collect() > 0

def test_instance():
    class A:
        pass
    a = A()
    a.a = a
    gc.collect()
    del a
    assert gc.collect() > 0

def test_method():
    class A:
        def __init__(self):
            self.init = self.__init__
    a = A()
    gc.collect()
    del a
    assert gc.collect() > 0

def test_finalizer():
    class A:
        def __del__(self): pass
    class B:
        pass
    a = A()
    a.a = a
    id_a = id(a)
    b = B()
    b.b = b
    gc.collect()
    del a
    del b
    assert gc.collect() > 0
    for obj in gc.garbage:
        if id(obj) == id_a:
            return
    raise TestFailed

def test_function():
    d = {}
    exec("def f(): pass\n") in d
    gc.collect()
    del d
    assert gc.collect() > 0


def test_all():
    threshold = gc.get_threshold()
    gc.set_threshold(0) # disable automatic collection
    gc.collect()
    test_list()
    test_dict()
    test_tuple()
    test_class()
    test_instance()
    test_method()
    test_finalizer()
    test_function()
    apply(gc.set_threshold, threshold)

test_all()

From tim_one at email.msn.com  Fri Jun 30 20:51:59 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 14:51:59 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEHOGHAA.tim_one@email.msn.com>

[/F]
> I think this means that we agree -- \x is a wart that can only
> be used to embed *binary bytes* in a string.

We certainly agree about that part!  I thought my

> I'm sorry \x escapes are even allowed in [u-strings] -- \x notation
> is a gimmick for making strings hold arbitrary binary data, which
> we're trying to get away from.  To the extent that they make any
> sense at all in Unicode strings, \u should be used instead.

was pretty explicit <wink>.

What we may still disagree on is how SRE should deal with the \x mess.  I'm
in favor of making \x mean "just the last byte" in plain and Unicode
strings -- do the least harm with this (mis)feature.  Making \x mean
anything other than that for plain strings, regardless of context, is not
backward compatible (with 1.5.2).  And since Unicode strings haven't been
released yet, it's not too late to change what they do with \x.

That would make SRE's job clear here, yes?  And in a way that allows the
now-failing test to pass again?





From skip at mojam.com  Fri Jun 30 19:43:21 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 30 Jun 2000 12:43:21 -0500 (CDT)
Subject: [Python-Dev] "make test" vs. "-tt"
Message-ID: <14684.56377.293211.329273@beluga.mojam.com>

Per Fredrik's suggestion, I changed "-tt" to simply "-t".  I've not yet done
a "cvs update" to grab the tab-corrected versions of whatever files were
causing the indigestion.  I'm down to a single test failure (test_re) now
when running "make test" before .py[co] files have been created.

I noticed a couple warnings when test_mmap was running though:

    ./Lib/sre_compile.py: inconsistent tab/space usage
    ./Lib/sre_parse.py: inconsistent tab/space usage

Could it be that when "-tt" detects a problem it causes a broken .py[co]
file to be generated?

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From DavidA at ActiveState.com  Fri Jun 30 20:58:20 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 30 Jun 2000 11:58:20 -0700
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <14684.42843.472230.609828@anthem.concentric.net>
Message-ID: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>

> That's a good point.  A bump in major rev number is an /opportunity/
> to break things, like a bone that hasn't healed right, so that they
> can be fixed correctly.  We'll lose that for 2.0, mostly likely
> because of the tight release schedule.

Yes, I find that frustrating.  The story for months (years?) has been that
we don't break things because it's a 'dot-release', and so we've shelved
improvements left and right.  Now we don't have time to do those things even
when it _is_ a major release.

Some advance notice would have been nice.

--david




From fdrake at beopen.com  Fri Jun 30 21:05:42 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 15:05:42 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
References: <14684.42843.472230.609828@anthem.concentric.net>
	<PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
Message-ID: <14684.61318.668529.402341@cj42289-a.reston1.va.home.com>

David Ascher writes:
 > Yes, I find that frustrating.  The story for months (years?) has been that
 > we don't break things because it's a 'dot-release', and so we've shelved
 > improvements left and right.  Now we don't have time to do those things even
 > when it _is_ a major release.
 > 
 > Some advance notice would have been nice.

  I agree, but this was news to at least some of us even Wednesday.
The upside is that major releases are more likely to happen now that
the precedent has been set.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Fri Jun 30 21:06:04 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 15:06:04 -0400
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIBGHAA.tim_one@email.msn.com>

[David Ascher, wishing he had had the opportunity to break things with 2.0]
> ...
> Some advance notice would have been nice.

David, it would have been nice for us too <0.3 wink>.

we're-not-keeping-secrets-we're-just-another-thrashing-startup-ly y'rs
    - tim





From nascheme at enme.ucalgary.ca  Fri Jun 30 21:50:52 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 13:50:52 -0600
Subject: [Python-Dev] Windows build issues
Message-ID: <20000630135052.A405@acs.ucalgary.ca>

A couple of things:

PCbuild/readme.txt

    Should be updated for the new release.

PC/config.h 

    VC++ 5.0 will not compile python20 unless "#include
    <basetsd.h>" is commented out.  Trent?

    WITH_CYCLE_GC should be uncommented if we want to have GC
    enabled in the beta.

PCbuild/python20.dsp

    Line endings seem to be incorrect.  Someone probably edited
    the file on a Unix machine and munched things up.  VC++ 5.0
    likes DOS line endings otherwise it refuses to load the
    project.

Also, I get a few warnings when compiling.  One is about an /IZ
(I think) option being ignored.  There are a few other warnings
as well which I didn't write down.

  Neil



From effbot at telia.com  Fri Jun 30 21:53:05 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 21:53:05 +0200
Subject: [Python-Dev] SRE incompatibility
References: <LNBBLJKPBEHFEDALKOLCKEHOGHAA.tim_one@email.msn.com>
Message-ID: <03f501bfe2cc$cf5dcce0$f2a6b5d4@hagrid>

tim wrote:
> That would make SRE's job clear here, yes?  And in a way that allows the
> now-failing test to pass again?

sure.  quoting from python-checkins:

RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_sre,v
...
  test_sre
- === Failed incorrectly ('\\x00ffffffffffffff', '\377', 0, 'found', '\377')
  === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A')
...

still messes up on nested repetitions, but that's entirely
different problem...

</F>




From fdrake at beopen.com  Fri Jun 30 22:23:35 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 16:23:35 -0400 (EDT)
Subject: [Python-Dev] 2.0b1 documentation online
Message-ID: <14685.455.115147.446238@cj42289-a.reston1.va.home.com>

  See it at:

  http://www.python.org/doc/devel/


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Fri Jun 30 23:23:09 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 16:23:09 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5
In-Reply-To: Your message of "Fri, 30 Jun 2000 12:35:20 EST."
             <14684.55896.890339.982232@beluga.mojam.com> 
References: <200006301841.LAA20523@slayer.i.sourceforge.net>  
            <14684.55896.890339.982232@beluga.mojam.com> 
Message-ID: <200006302123.QAA20537@cj20424-a.reston1.va.home.com>

>     Fred> The new copyright / license.
>     ...
>     Fred> ! ...  IN NO EVENT SHALL THE REGENTS OR
>     Fred> ! CONTRIBUTORS BE LIABLE FOR ...
> 
> Who are the "regents" and the "contributors"?  Should those terms be
> defined somewhere?

Oops.  I thought I caught all the regents and replaced them with a
more politically correct term.  Seems one got away.  Fixed now.

> not-a-lawyer-and-never-wanted-to-be-ly y'rs,

Ditto,

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



From guido at python.org  Fri Jun 30 23:26:21 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 16:26:21 -0500
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: Your message of "Fri, 30 Jun 2000 11:58:20 MST."
             <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com> 
References: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com> 
Message-ID: <200006302126.QAA20621@cj20424-a.reston1.va.home.com>

> > That's a good point.  A bump in major rev number is an /opportunity/
> > to break things, like a bone that hasn't healed right, so that they
> > can be fixed correctly.  We'll lose that for 2.0, mostly likely
> > because of the tight release schedule.

[David Ascher]
> Yes, I find that frustrating.  The story for months (years?) has been that
> we don't break things because it's a 'dot-release', and so we've shelved
> improvements left and right.  Now we don't have time to do those things even
> when it _is_ a major release.

You have no idea how frustration it is for me!  But sometimes the
marketing people force us engineers to act quickly.  Just be glad I'm
not following the release schedule that they had *wanted* me to
use... :-)

> Some advance notice would have been nice.

Same here. :-)

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



From nascheme at enme.ucalgary.ca  Fri Jun 30 22:31:48 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 14:31:48 -0600
Subject: [Python-Dev] Idle breakage
Message-ID: <20000630143148.A9725@acs.ucalgary.ca>

Caused by _sre perhaps?

$ python Tools/idle/idle.py
Traceback (most recent call last):
  File "Tools/idle/idle.py", line 8, in ?
    IdleConf.load(idle_dir)
  File "Tools/idle/IdleConf.py", line 109, in load
    idleconf.read((os.path.join(dir, "config.txt"), genplatfile, platfile,
  File "/usr/local/lib/python2.0/ConfigParser.py", line 207, in read
    self.__read(fp, filename)
  File "/usr/local/lib/python2.0/ConfigParser.py", line 382, in __read
    raise e
ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt
        [line 21]: 'width= 80\012'
        [line 22]: 'height= 24\012'
        [line 26]: 'normal-foreground= black\012'
        [line 27]: 'normal-background= white\012'
        [line 29]: 'keyword-foreground= #ff7700\012'
        [line 30]: 'comment-foreground= #dd0000\012'
        [line 31]: 'string-foreground= #00aa00\012'
        [line 32]: 'definition-foreground= #0000ff\012'
        [line 33]: 'hilite-foreground= #000068\012'
        [line 34]: 'hilite-background= #006868\012'
        [line 35]: 'break-foreground= #ff7777\012'
        [line 36]: 'hit-foreground= #ffffff\012'
        [line 37]: 'hit-background= #000000\012'
        [line 38]: 'stdout-foreground= blue\012'
        [line 39]: 'stderr-foreground= red\012'
        [line 40]: 'console-foreground= #770000\012'
        [line 41]: 'error-background= #ff7777\012'
        [line 42]: 'cursor-background= black\012'
        [line 59]: 'enable= 0\012'
        [line 60]: 'style= expression\012'
        [line 61]: 'flash-delay= 500\012'
        [line 62]: 'bell= 1\012'
        [line 63]: 'hilite-foreground= black\012'
        [line 64]: 'hilite-background= #43cd80\012'



From jeremy at beopen.com  Fri Jun 30 22:33:01 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 16:33:01 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <200006302126.QAA20621@cj20424-a.reston1.va.home.com>
References: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
	<200006302126.QAA20621@cj20424-a.reston1.va.home.com>
Message-ID: <14685.1021.870885.796187@bitdiddle.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

  >> That's a good point.  A bump in major rev number is an
  >> /opportunity/ to break things, like a bone that hasn't healed
  >> right, so that they can be fixed correctly.  We'll lose that
  >> for 2.0, mostly likely because of the tight release schedule.

  GvR> [David Ascher]
  >> Yes, I find that frustrating.  The story for months (years?) has
  >> been that we don't break things because it's a 'dot-release', and
  >> so we've shelved improvements left and right.  Now we don't have
  >> time to do those things even when it _is_ a major release.

  GvR> You have no idea how frustration it is for me!  But sometimes
  GvR> the marketing people force us engineers to act quickly.  Just
  GvR> be glad I'm not following the release schedule that they had
  GvR> *wanted* me to use... :-)

Perhaps I am too easy-going, but I consider the 2.0 release a
'dot-release' masquerading as a major revision.  It might be a little
silly, but it seems even sillier to preserve a naming scheme that
makes users think that the technology is immature.

Jeremy



From guido at python.org  Fri Jun 30 23:33:52 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 16:33:52 -0500
Subject: [Python-Dev] Windows build issues
In-Reply-To: Your message of "Fri, 30 Jun 2000 13:50:52 CST."
             <20000630135052.A405@acs.ucalgary.ca> 
References: <20000630135052.A405@acs.ucalgary.ca> 
Message-ID: <200006302133.QAA20696@cj20424-a.reston1.va.home.com>

> A couple of things:
> 
> PCbuild/readme.txt
> 
>     Should be updated for the new release.

Tim will do this.

> PC/config.h 
> 
>     VC++ 5.0 will not compile python20 unless "#include
>     <basetsd.h>" is commented out.  Trent?

I'll leave this to Trent -- I don't know how to check for VC 5.0
vs. 6.0.

>     WITH_CYCLE_GC should be uncommented if we want to have GC
>     enabled in the beta.

Done.

> PCbuild/python20.dsp
> 
>     Line endings seem to be incorrect.  Someone probably edited
>     the file on a Unix machine and munched things up.  VC++ 5.0
>     likes DOS line endings otherwise it refuses to load the
>     project.

There was one missing CR.  Fixed now.

> Also, I get a few warnings when compiling.  One is about an /IZ
> (I think) option being ignored.  There are a few other warnings
> as well which I didn't write down.

Probably 6.0 flags that 5.0 doesn't have.  What can we do?

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



From nascheme at enme.ucalgary.ca  Fri Jun 30 22:40:21 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 14:40:21 -0600
Subject: [Python-Dev] Idle breakage
In-Reply-To: <20000630143148.A9725@acs.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Fri, Jun 30, 2000 at 02:31:48PM -0600
References: <20000630143148.A9725@acs.ucalgary.ca>
Message-ID: <20000630144021.A9847@acs.ucalgary.ca>

Changing to pre fixes the problem.

  Neil



From mwh21 at cam.ac.uk  Fri Jun 30 22:50:37 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 30 Jun 2000 21:50:37 +0100
Subject: [Python-Dev] Re: Test results of linuxaudiodev.c
In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 17:44:35 -0700 (PDT)"
References: <Pine.SGI.3.96.1000629173646.621134u-100000@happy>
Message-ID: <m3r99e7v1e.fsf@atrus.jesus.cam.ac.uk>

To python-dev: Sorry for the hiatus.

To python-list: does someone who knows about audio and can run linux
want to play with this (Ping and I fall into just one of these
categories each!).

Ka-Ping Yee <pingster at ilm.com> writes:

> On 30 Jun 2000, Michael Hudson wrote:
> > Yup, that works fine.  Don't understand the details - and as I have my
> > graduation ceremony tomorrow I'm going to go to bed and leave learning
> > them until some other occasion!
> 
> Cool.
> 
> Okay, i just discovered sunau.py.  Here's my real shot at
> test_linuxaudiodev.py.  Can you give this a try?
> 
> 
> ---- test_linuxaudiodev.py ----
> from test_support import verbose, findfile, TestFailed
> import linuxaudiodev
> import os, sunau
> 
> formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW,
>            ("NONE", 1): linuxaudiodev.AFMT_S8,
>            ("NONE", 2): linuxaudiodev.AFMT_S16_BE}
> 
> def play_au_file(path):
>     au = sunau.open(path, "r")
>     data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE)
>     au.close()
> 
>     spec = (au.getcomptype(), au.getsampwidth())
>     if not has_key(formats, spec):
             ^^^^^^^
Oops?

>         raise "audio format not supported by linuxaudiodev"

Maybe you mean:

        raise TestFailed, "audio format not supported by linuxaudiodev"

?  I thought string exceptions were deprecated...
         
>     dsp = linuxaudiodev.open("w")
>     dsp.setparameters(au.getframerate(), au.getsampwidth() * 8,
>                       au.getnchannels(), formats[spec])
>     dsp.write(data)
>     dsp.close()
> 
> def test():
>     play_au_file(findfile('audiotest.au'))
> 
> test()

This doesn't work.  I don't really understand why.

For audiotest.au, |spec| is ("ULAW",2), which I don't think is right;
file(1) says 

audiotest.au: Sun/NeXT audio data: 8-bit ISDN u-law, mono, 8000 Hz

So I think this could be a bug in sunau.

The other data (au.getframerate(), au.getnchannels()) agrees with
file(1).

Anybody have a better idea?

Cheers,
Michael Hudson, BA (as of today! woohoo!)




From jeremy at beopen.com  Fri Jun 30 22:57:44 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 16:57:44 -0400 (EDT)
Subject: [Python-Dev] last minute GC questions
Message-ID: <14685.2504.722378.79294@bitdiddle.concentric.net>

I've got two last minute questions.

Does it look to you like I checked in all of the changes that you and
Vladimir discussed?

Might we change the strategy for deciding when to collect?

There are two parts of the strategy that could probably change.  The
first is what kind of allocation events we count to determine when to
collect.  

Right now, the gc is counting the net effect of allocations and
deallocations.  This isn't effective for at least a couple of cases.
If we allocate N objects and don't deallocate anything, then no
garbage is going to be created.  If we have many objects currently
allocated and then dealloc N objects without allocating any, we could
create collectible garbage, but the collector won't run because there
haven't been any allocations.

It seems to me that counting deallocations only would be more
effective.  It is only the deallocations that cause a live object to
become garbage.

The other part of the strategy that might be changed is the collection
frequency.  Right now, the threshold is 100 net allocations &
dealloactions.  On the compiler benchmark, this leads to some 2600
collections, which seems like a lot.  (I have no idea why it seems
like a lot, but it does.)

I experimented with a policy that runs the collected every N
deallocations (not counting deallocations the occur during a
collection).  I set N == 1000 and got 1600 collections on the compiler
benchmark.  

There is only a small speedup (just a few percent), so maybe this
change doesn't have a big effect.  I don't recall much about the
cost/complexity of various GC approaches.

Jeremy



From nascheme at enme.ucalgary.ca  Fri Jun 30 23:12:06 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 15:12:06 -0600
Subject: [Python-Dev] Re: last minute GC questions
In-Reply-To: <14685.2504.722378.79294@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jun 30, 2000 at 04:57:44PM -0400
References: <14685.2504.722378.79294@bitdiddle.concentric.net>
Message-ID: <20000630151206.A10333@acs.ucalgary.ca>

On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote:
> I've got two last minute questions.
> 
> Does it look to you like I checked in all of the changes that you and
> Vladimir discussed?

Nope.

  Neil


Index: 0.13/Include/objimpl.h
*** 0.13/Include/objimpl.h Fri, 30 Jun 2000 13:05:40 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644)
--- 0.13(w)/Include/objimpl.h Fri, 30 Jun 2000 15:09:51 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644)
***************
*** 204,209 ****
--- 204,211 ----
  	(PyVarObject *) PyObject_MALLOC( _PyObject_VAR_SIZE((typeobj),(n)) ),\
  	(typeobj), (n)) )
  
+ #define PyObject_DEL(op) PyObject_FREE(op)
+ 
  /* This example code implements an object constructor with a custom
     allocator, where PyObject_New is inlined, and shows the important
     distinction between two steps (at least):
***************
*** 242,248 ****
     PyObject_{New, VarNew, Del} to manage the memory.  Set the type flag
     Py_TPFLAGS_GC and define the type method tp_recurse.  You should also
     add the method tp_clear if your object is mutable.  Include
!    PyGC_INFO_SIZE in the calculation of tp_basicsize.  Call
     PyObject_GC_Init after the pointers followed by tp_recurse become
     valid (usually just before returning the object from the allocation
     method.  Call PyObject_GC_Fini before those pointers become invalid
--- 244,250 ----
     PyObject_{New, VarNew, Del} to manage the memory.  Set the type flag
     Py_TPFLAGS_GC and define the type method tp_recurse.  You should also
     add the method tp_clear if your object is mutable.  Include
!    PyGC_HEAD_SIZE in the calculation of tp_basicsize.  Call
     PyObject_GC_Init after the pointers followed by tp_recurse become
     valid (usually just before returning the object from the allocation
     method.  Call PyObject_GC_Fini before those pointers become invalid
***************
*** 255,261 ****
  #define PyObject_GC_Fini(op)
  #define PyObject_AS_GC(op) (op)
  #define PyObject_FROM_GC(op) (op)
- #define PyObject_DEL(op) PyObject_FREE(op)
   
  #else
  
--- 257,262 ----
***************
*** 289,295 ****
  /* Get the object given the PyGC_Head */
  #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1))
  
! #define PyObject_DEL(op) PyObject_FREE( PyObject_IS_GC(op) ? \
  					(ANY *)PyObject_AS_GC(op) : \
  					(ANY *)(op) )
  
--- 290,297 ----
  /* Get the object given the PyGC_Head */
  #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1))
  
! #undef PyObject_DEL
! #define PyObject_DEL(op) PyObject_FREE( (op && PyObject_IS_GC(op)) ? \
  					(ANY *)PyObject_AS_GC(op) : \
  					(ANY *)(op) )
  
Index: 0.13/Objects/object.c
*** 0.13/Objects/object.c Fri, 30 Jun 2000 13:05:40 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644)
--- 0.13(w)/Objects/object.c Fri, 30 Jun 2000 15:05:26 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644)
***************
*** 192,205 ****
  	PyObject *op;
  {
  #ifdef WITH_CYCLE_GC
! 	if (PyType_IS_GC(op->ob_type)) {
! 		PyGC_Head *g = PyObject_AS_GC(op);
! 		PyObject_FREE(g);
! 	} else
! #endif
! 	{
! 		PyObject_FREE(op);
  	}
  }
  
  #ifndef WITH_CYCLE_GC
--- 192,202 ----
  	PyObject *op;
  {
  #ifdef WITH_CYCLE_GC
! 	if (op && PyType_IS_GC(op->ob_type)) {
! 		op = (PyObject *) PyObject_AS_GC(op);
  	}
+ #endif
+ 	PyObject_FREE(op);
  }
  
  #ifndef WITH_CYCLE_GC



From effbot at telia.com  Fri Jun 30 23:20:20 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 23:20:20 +0200
Subject: [Python-Dev] Windows build issues
References: <20000630135052.A405@acs.ucalgary.ca>  <200006302133.QAA20696@cj20424-a.reston1.va.home.com>
Message-ID: <044b01bfe2d9$01dcee60$f2a6b5d4@hagrid>

guido wrote:

> > PC/config.h 
> > 
> >     VC++ 5.0 will not compile python20 unless "#include
> >     <basetsd.h>" is commented out.  Trent?
> 
> I'll leave this to Trent -- I don't know how to check for VC 5.0
> vs. 6.0.

#if _MSC_VER >= 1200
    VC 6.0
#else
    VC 5.0 or earlier    
#endif

(we added a similar workaround to Python/thread_nt.c)

> > Also, I get a few warnings when compiling.  One is about an /IZ
> > (I think) option being ignored.  There are a few other warnings
> > as well which I didn't write down.
> 
> Probably 6.0 flags that 5.0 doesn't have.  What can we do?

ignore it, for now.  I remember seeing a few type warnings, but
nothing critical.  there's plenty of time to sort that out on the
way to 2.0 final.

</F>




From effbot at telia.com  Fri Jun 30 23:24:06 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 23:24:06 +0200
Subject: [Python-Dev] Idle breakage
References: <20000630143148.A9725@acs.ucalgary.ca>
Message-ID: <046a01bfe2d9$88302360$f2a6b5d4@hagrid>

neil wrote:


> Caused by _sre perhaps?
> 
> ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt
>         [line 21]: 'width= 80\012'

probably; I'll dig into this.

when's the 2.0 deadline?

</F>




From nascheme at enme.ucalgary.ca  Fri Jun 30 23:30:08 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 15:30:08 -0600
Subject: [Python-Dev] Fwd: Re: last minute GC questions
Message-ID: <20000630153008.C10333@acs.ucalgary.ca>

Oops, should have cc python-dev.

----- Forwarded message from Neil Schemenauer <nascheme at enme.ucalgary.ca> -----

Date: Fri, 30 Jun 2000 15:27:48 -0600
From: Neil Schemenauer <nascheme at enme.ucalgary.ca>
Subject: Re: last minute GC questions
To: Jeremy Hylton <jeremy at beopen.com>
X-Url: http://www.enme.ucalgary.ca/~nascheme/

On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote:
> Might we change the strategy for deciding when to collect?

We might. :)

> It seems to me that counting deallocations only would be more
> effective.  It is only the deallocations that cause a live object to
> become garbage.

You can easily run out of memory with that strategy though:

    N = 10000
    while 1:
        l = []
        for i in xrange(N):
            l.append([])
        l[0] = l

You only get a couple of deallocations while a large amount of
garbage is created.  Think of large cyclic structures like graphs
being created and then becoming garbage due to one deallocation.
By counting the net new objects we guarantee that this doesn't
happen.

> The other part of the strategy that might be changed is the collection
> frequency.  Right now, the threshold is 100 net allocations &
> dealloactions.  On the compiler benchmark, this leads to some 2600
> collections, which seems like a lot.  (I have no idea why it seems
> like a lot, but it does.)

Try setting the threshold to zero.  The major part of the GC
overhead does not seem to be running the collector.  OTOH, the
frequency could probably be decreased without the risk of running
out of memory.  No Python applications currently exist that
create that amount of garbage anyhow.

  Neil

----- End forwarded message -----



From effbot at telia.com  Fri Jun 30 23:39:26 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 23:39:26 +0200
Subject: [Python-Dev] Idle breakage
References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid>
Message-ID: <049601bfe2db$acea1380$f2a6b5d4@hagrid>

I wrote:

> > Caused by _sre perhaps?
> > 
> > ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt
> >         [line 21]: 'width= 80\012'
> 
> probably; I'll dig into this.

confirmed.  SRE implements $ exactly as described in
the library reference, RE doesn't ;-)

patch coming within 30 minutes.

</F>




From bwarsaw at beopen.com  Fri Jun 30 23:57:19 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 17:57:19 -0400 (EDT)
Subject: [Python-Dev] Odd behavior with `make test'
References: <14684.57622.9807.868551@anthem.concentric.net>
	<038601bfe2bf$31c52da0$f2a6b5d4@hagrid>
Message-ID: <14685.6079.779817.674190@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <effbot at telia.com> writes:

    FL> the rest looks a bit scary, to say the least.  does someone
    FL> (sre?)  overwrite something? does anyone have purify (dmalloc,
    FL> fences, whatever) within reach?

I will very soon.  I found a Solaris box on which I could load up an
eval copy of Purify.  Will report back soon.

-Barry



From klm at digicool.com  Thu Jun  1 00:03:31 2000
From: klm at digicool.com (Ken Manheimer)
Date: Wed, 31 May 2000 18:03:31 -0400 (EDT)
Subject: [Python-Dev] SIG: python-lang
In-Reply-To: <643145F79272D211914B0020AFF640190BAA8F@gandalf.digicool.com>
Message-ID: <Pine.LNX.4.21.0005311755420.9023-100000@korak.digicool.com>

On Wed, 31 May 2000, Ka-Ping Yee wrote:

> Hey, i admit it's a bit primitive, but it seems significantly
> better than nothing.  The software people at ILM have coped
> with it fairly well for a year, and for the most part we like it.

I'm not sure about the requirements - particularly, submissions and
correspondence about bugs via email, which my zope "tracker" doesn't do -
but the tracker may be worth looking at, also:

  http://www.zope.org/Members/klm/SoftwareCarpentry

(See the prototype tracker, mentioned there, or my "tracker tracker" at
http://www.zope.org/Members/klm/Tracker , for flagrant, embarrassing
exposure of the outstanding tracker complaints...)

(I haven't had the time to take care of the tracker as i would like, or to
look at how tracker and roundup could inform eachother - but i haven't
even gotten as far as examining that.  I get the feeling they take fairly
different approaches - which could mean neat synergy, or total
disconnection.  Ping, any thoughts?)

Ken
klm at digicool.com




From fdrake at acm.org  Thu Jun  1 00:17:02 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 31 May 2000 18:17:02 -0400 (EDT)
Subject: [Python-Dev] Adding LDAP to the Python core... ?!
In-Reply-To: <Pine.LNX.4.10.10005311452150.30220-100000@nebula.lyra.org>
References: <14645.17446.749848.895965@anthem.python.org>
	<Pine.LNX.4.10.10005311452150.30220-100000@nebula.lyra.org>
Message-ID: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com>

Greg Stein writes:
 > My WebDAV module implements an established protocol (an RFC tends to do
 > that :-), but the API within the module is still in flux (IMO).

  I'd love to see this sort of thing added to the standard library,
esp. once packages are used there.  Especially if the implementation
is pure Python (which I think your WebDAV stuff is, right?)

 > Is the LDAP module's API pretty solid? Is it changing?

  This I don't know.

 > And is this module a C extension, or a pure Python implementation?

  Mixed, I think.  There is definately a C component.  I'd rather it
be pure Python, but I think it's a SWIGged wrapper around a C client
library.
  Is anyone talking to the developer about this yet?


  -Fred

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




From gstein at lyra.org  Thu Jun  1 00:27:04 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 31 May 2000 15:27:04 -0700 (PDT)
Subject: [Python-Dev] Adding LDAP to the Python core... ?!
In-Reply-To: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10005311522480.30220-100000@nebula.lyra.org>

On Wed, 31 May 2000, Fred L. Drake, Jr. wrote:
> Greg Stein writes:
>  > My WebDAV module implements an established protocol (an RFC tends to do
>  > that :-), but the API within the module is still in flux (IMO).
> 
>   I'd love to see this sort of thing added to the standard library,
> esp. once packages are used there.  Especially if the implementation
> is pure Python (which I think your WebDAV stuff is, right?)

davlib.py is pure Python, building upon my upgraded httplib.py and
xml.utils.qp_xml (and pyexpat)

[ and recall my email last week that I've updated httplib.py and posted it
  to my web pages; it is awaiting review for integration into the Python
  core; it still needs docs and more testing scenarios, tho

  http://www.python.org/pipermail/python-dev/2000-May/005643.html
]

davlib will probably be a 1.7 item. It still needs some heavy work to
easily deal with authentication (which is usually going to be required for
DAV operations).

Cheers,
-g

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




From mhammond at skippinet.com.au  Thu Jun  1 00:53:15 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Thu, 1 Jun 2000 08:53:15 +1000
Subject: [Python-Dev] SIG: python-lang
In-Reply-To: <Pine.LNX.4.21.0005311755420.9023-100000@korak.digicool.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEAKCMAA.mhammond@skippinet.com.au>

[Ken writes]
> I'm not sure about the requirements - particularly, submissions and
> correspondence about bugs via email, which my zope "tracker" doesn't do -
> but the tracker may be worth looking at, also:
>
>   http://www.zope.org/Members/klm/SoftwareCarpentry
>

Another alternative could be Bugzilla:

http://bugzilla.mozilla.org/

Sources at:

http://www.mozilla.org/bugs/source.html

Has many of the features people seem to want, and obviously supports large
projects - which may be the biggest problem - it may be too "heavy" for our
requirement...

Mark.




From fdrake at acm.org  Thu Jun  1 03:30:28 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 31 May 2000 21:30:28 -0400 (EDT)
Subject: [Python-Dev] Adding LDAP to the Python core... ?!
In-Reply-To: <Pine.LNX.4.10.10005311522480.30220-100000@nebula.lyra.org>
References: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com>
	<Pine.LNX.4.10.10005311522480.30220-100000@nebula.lyra.org>
Message-ID: <14645.48308.347086.279280@cj42289-a.reston1.va.home.com>

Greg Stein writes:
 > davlib.py is pure Python, building upon my upgraded httplib.py and
 > xml.utils.qp_xml (and pyexpat)

  So the dependencies are definately an issue.

 > [ and recall my email last week that I've updated httplib.py and posted it
 >   to my web pages; it is awaiting review for integration into the Python
 >   core; it still needs docs and more testing scenarios, tho
 > 
 >   http://www.python.org/pipermail/python-dev/2000-May/005643.html
 > ]

  Jeremy, were you looking at this?

 > davlib will probably be a 1.7 item. It still needs some heavy work to
 > easily deal with authentication (which is usually going to be required for

  Sounds good to me; let's take a look at it in 3 or 4 months.  I'd
hope to have at least preliminary reference documentation for review.


  -Fred

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




From skip at mojam.com  Thu Jun  1 15:48:41 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 1 Jun 2000 08:48:41 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34
In-Reply-To: <200006010312.UAA10844@slayer.i.sourceforge.net>
References: <200006010312.UAA10844@slayer.i.sourceforge.net>
Message-ID: <14646.27065.279988.93102@beluga.mojam.com>

    Fred> Log Message:
    Fred> Michael Hudson <mwh21 at cam.ac.uk>:
    Fred> Removed PyErr_BadArgument() calls and replaced them with more
    Fred> useful error messages.

    ...
    Fred> --- 389,395 ----
    Fred>   	PyListObject *np;
    Fred>   	if (!PyList_Check(bb)) {
    Fred> ! 		PyErr_Format(PyExc_TypeError,
    Fred> ! 			     "can only append list (not \"%.200s\") to list",
    Fred> ! 			     bb->ob_type->tp_name);
    Fred>   		return NULL;
    Fred>   	}
    Fred> ***************
    ...

I've seen this new error message cross my mailbox a few times.  On the face
of it, it's incorrect, because you can append any sort of object to a list,
right?  This message appears in the list_concat method.  Shouldn't it be
something like

    can't concatenate \"%.200s\" object with list

?  I would consider this change very picky except for the fact that it's
making a statement about the properties of lists that is clearly not true.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
"We have become ... the stewards of life's continuity on earth.  We did not
ask for this role...  We may not be suited to it, but here we are."
- Stephen Jay Gould



From fdrake at acm.org  Thu Jun  1 16:29:17 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 1 Jun 2000 10:29:17 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34
In-Reply-To: <14646.27065.279988.93102@beluga.mojam.com>
References: <200006010312.UAA10844@slayer.i.sourceforge.net>
	<14646.27065.279988.93102@beluga.mojam.com>
Message-ID: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com>

Skip Montanaro writes:
 > I've seen this new error message cross my mailbox a few times.  On the face
 > of it, it's incorrect, because you can append any sort of object to a list,
 > right?  This message appears in the list_concat method.  Shouldn't it be
 > something like
 > 
 >     can't concatenate \"%.200s\" object with list

Skip,
  You're right!  How about:

       can only concatenate list (not \"%.200s\") to list

  If you don't object by the time this mail reaches you, I'll check it
in.  ;)


  -Fred

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




From mwh21 at cam.ac.uk  Thu Jun  1 17:39:59 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: Thu, 1 Jun 2000 16:39:59 +0100 (BST)
Subject: [Python-Dev] CVS: python/dist/src/Objects listobject.c,2.69,2.70 and friends
In-Reply-To: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10006011637320.13221-100000@localhost.localdomain>

On Thu, 1 Jun 2000, Fred L. Drake, Jr. wrote:

> 
> Skip Montanaro writes:
>  > I've seen this new error message cross my mailbox a few times.  On the face
>  > of it, it's incorrect, because you can append any sort of object to a list,
>  > right?  This message appears in the list_concat method.  Shouldn't it be
>  > something like
>  > 
>  >     can't concatenate \"%.200s\" object with list
> 
> Skip,
>   You're right!  How about:
> 
>        can only concatenate list (not \"%.200s\") to list
> 
>   If you don't object by the time this mail reaches you, I'll check it
> in.  ;)

Then you'd better do something about tupleobject.c as well; I'd also say

       can only concatenate list (not \"%.200s\") and list
       can only concatenate tuple (not \"%.200s\") and tuple

are slightly preferable, on reflection (note the s/to/and/).

Cheers,
Michael




From andy at reportlab.com  Thu Jun  1 18:23:36 2000
From: andy at reportlab.com (Andy Robinson)
Date: Thu, 1 Jun 2000 17:23:36 +0100
Subject: [Python-Dev] SIG: python-lang
Message-ID: <PGECLPOBGNBNKHNAGIJHIEDNCCAA.andy@reportlab.com>

It seems to me that the main problem is that
comp.lang.python is too big to follow.  So why 
not split it?  I don't know the right subgroups,
but if (say) comp.lang.python.language focusses 
on the core language, it might enable people to 
start reading it again.  

I asked this twice on c.l.p, one year ago and 
two years ago, and the answer was always "the 
traffic is too low".  I used to subscribe to
the NeXTSteap groups, and splitting worked
really well there.

- Andy Robinson



From mal at lemburg.com  Thu Jun  1 15:10:42 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 01 Jun 2000 15:10:42 +0200
Subject: [Python-Dev] Adding LDAP to the Python core... ?!
References: <Pine.LNX.4.10.10005311452150.30220-100000@nebula.lyra.org>
Message-ID: <393660D2.4926E5C1@lemburg.com>

Greg Stein wrote:
> 
> On Wed, 31 May 2000, Barry A. Warsaw wrote:
> > >>>>> "M" == M  <mal at lemburg.com> writes:
> >
> >     M> Would there be interest in adding the python-ldap module
> >     M> (http://sourceforge.net/project/?group_id=2072) to the
> >     M> core distribution ?
> >
> > I haven't looked at this stuff, but yes, I think a standard LDAP
> > module would be quite useful.  It's a well enough established
> > protocol, and it would be good to be able to count on it "being
> > there".
> 
> My WebDAV module implements an established protocol (an RFC tends to do
> that :-), but the API within the module is still in flux (IMO).
> 
> Is the LDAP module's API pretty solid? Is it changing?

It is closing in on version 2.0 -- not sure how much it
still changes. I just thought I'd query here before asking
Daniel about his thoughts on including the module in the
core (wouldn't make much sense if there was no interest).
 
> And is this module a C extension, or a pure Python implementation?

It's a Python module which uses a C wrapper to interface
to OpenLDAP, which is a portable C lib dealing with
all aspects of LDAP.

There are at least two other projects built on top of
python-ldap (see Parnassus for infos).

I just thought I'd mention it here, because  LDAP is certainly
a widely used protocol in the corporate world and many 
decision makers have this on their list of buzz words.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From gward at mems-exchange.org  Thu Jun  1 23:01:41 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 1 Jun 2000 17:01:41 -0400
Subject: [Python-Dev] What's that sound?
In-Reply-To: <393547A2.30CB7113@prescod.net>; from paul@prescod.net on Wed, May 31, 2000 at 12:10:58PM -0500
References: <39353CCD.1F3E9A0B@prescod.net> <14645.17611.318538.986772@anthem.python.org> <393547A2.30CB7113@prescod.net>
Message-ID: <20000601170140.A24794@mems-exchange.org>

On 31 May 2000, Paul Prescod said:
> Look closer, big-egoed-four-stringed-guitar-playing-one. It could just
> as easily be a J.
> 
> And you know what you get when you put P and J together?

Pajamas!

Yes, that's right, when Python takes over the world, we'll all have to
sleep BUCK NAKED!!!

(What was that about "zero noise" on python-dev?  Oh well, we must have
our fun...)

        Greg



From esr at snark.thyrsus.com  Fri Jun  2 00:36:29 2000
From: esr at snark.thyrsus.com (Eric S. Raymond)
Date: Thu, 1 Jun 2000 18:36:29 -0400
Subject: [Python-Dev] ascii.py?
Message-ID: <200006012236.SAA03578@snark.thyrsus.com>

There has been a vast and echoing silence about the ascii.py module I
posted here at Fred Drake's request.  Is it really such a  bad idea?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"Those who make peaceful revolution impossible 
will make violent revolution inevitable."
	-- John F. Kennedy



From pingster at ilm.com  Fri Jun  2 00:33:19 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 1 Jun 2000 15:33:19 -0700 (PDT)
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <Pine.SGI.3.96.1000601153039.30600P-100000@happy>

On Thu, 1 Jun 2000, Eric S. Raymond wrote:
> There has been a vast and echoing silence about the ascii.py module I
> posted here at Fred Drake's request.  Is it really such a  bad idea?

Don't look at me.  I'm busy working on inspect and htmldoc. :)

Actually, i guess i probably didn't respond because it isn't
of immediate use to me.  Maybe this is the sort of thing that
might come in handy one day but that hordes of people aren't
desperate for.

Hmm.  Perhaps it's because people are used to saying "in string.digits"
instead of wanting isdigit() &c.

Hmm.  Perhaps it's also something that ought to be eventually
handled via the Unicode character property route.

Dunno.


-- ?!ng

"China is a big country, inhabited by many Chinese."
    -- Former French President Charles de Gaulle





From gstein at lyra.org  Fri Jun  2 00:34:13 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 1 Jun 2000 15:34:13 -0700 (PDT)
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <Pine.LNX.4.10.10006011531500.6088-100000@nebula.lyra.org>

On Thu, 1 Jun 2000, Eric S. Raymond wrote:
> There has been a vast and echoing silence about the ascii.py module I
> posted here at Fred Drake's request.  Is it really such a  bad idea?

hehe...

I'd say silence implies a +0 from people ("seems reasonable to go in, but
I wouldn't be upset if it doesn't").

If people thought it was bad, then you'd hear about it :-)

I took a quick look at it. Doesn't seem too bad, but I can't think of
anything that I've done in a long while that would require it. So I can't
really say "wow! put that baby in the distro!"

YMMV, of course :-)

Cheers,
-g

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




From esr at thyrsus.com  Fri Jun  2 00:51:45 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 1 Jun 2000 18:51:45 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <Pine.LNX.4.10.10006011531500.6088-100000@nebula.lyra.org>; from gstein@lyra.org on Thu, Jun 01, 2000 at 03:34:13PM -0700
References: <200006012236.SAA03578@snark.thyrsus.com> <Pine.LNX.4.10.10006011531500.6088-100000@nebula.lyra.org>
Message-ID: <20000601185145.A3667@thyrsus.com>

Greg Stein <gstein at lyra.org>:
> I took a quick look at it. Doesn't seem too bad, but I can't think of
> anything that I've done in a long while that would require it. So I can't
> really say "wow! put that baby in the distro!"

It starts to get pretty useful in conjunction with curses -- for example, in
writing interpreters for character-at-a-time command loops.

I have a new version that adds the following:

\begin{funcdesc}{ascii}{c}
Return the ASCII value corresponding to the low 7 bits of c.
\end{funcdesc}

The following function takes either a single-character string or
integer byte value; it returns a string.

\begin{funcdesc}{unctrl}{c}
Return a string representation of the ASCII character c.  If c is
printable, this string is the character itself.  If the character
is a control character (0x00-0x1f) the string consists of a caret
(^) followed by the corresponding uppercase letter.  If the character
is an ASCII delete (0x7f) the string is "^?".  If the character has
its meta bit (0x80) set, the meta bit is stripped, the preceding rules
applied, and "!" prepended to the result.
\end{funcdesc}

Finally, the module supplies a 33-element string array 
called controlnames that contains the ASCII mnemonics for the
thirty-two ASCII control characters from 0 (NUL) to 0x1f (US),
in order, plus the mnemonic "SP" for space.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Certainly one of the chief guarantees of freedom under any government,
no matter how popular and respected, is the right of the citizens to
keep and bear arms.  [...] the right of the citizens to bear arms is
just one guarantee against arbitrary government and one more safeguard
against a tyranny which now appears remote in America, but which
historically has proved to be always possible.
        -- Hubert H. Humphrey, 1960



From akuchlin at cnri.reston.va.us  Fri Jun  2 01:32:32 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Thu, 1 Jun 2000 19:32:32 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>; from esr@snark.thyrsus.com on Thu, Jun 01, 2000 at 06:36:29PM -0400
References: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <20000601193232.A12831@newcnri.cnri.reston.va.us>

On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
>There has been a vast and echoing silence about the ascii.py module I
>posted here at Fred Drake's request.  Is it really such a  bad idea?

One misgiving I had was locales; is it a bug or a feature that locales
aren't supported, as they are for the C isdigit(), isalpha(), &c,
functions?  I'm not entirely sure which it is.  (The locale module
doesn't expose the C is*() functions, though I think they're used in
constructing string.letters.)

--amk



From esr at thyrsus.com  Fri Jun  2 01:45:11 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 1 Jun 2000 19:45:11 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <20000601193232.A12831@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Thu, Jun 01, 2000 at 07:32:32PM -0400
References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us>
Message-ID: <20000601194511.A3948@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
> >There has been a vast and echoing silence about the ascii.py module I
> >posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> One misgiving I had was locales; is it a bug or a feature that locales
> aren't supported, as they are for the C isdigit(), isalpha(), &c,
> functions?  I'm not entirely sure which it is.  (The locale module
> doesn't expose the C is*() functions, though I think they're used in
> constructing string.letters.)

It's a feature.  That's why this module is called ascii, not string :-)
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

  "...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
        -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),



From paul at prescod.net  Fri Jun  2 05:53:41 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 01 Jun 2000 22:53:41 -0500
Subject: [Python-Dev] ascii.py?
References: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <39372FC5.DE1CE8EA@prescod.net>

"Eric S. Raymond" wrote:
> 
> There has been a vast and echoing silence about the ascii.py module I
> posted here at Fred Drake's request.  Is it really such a  bad idea?

Without looking closely, or even being particularly knowledgable (how's
that for a disclaimer!) my instinctive reaction was: "does the ASCII
subset of Unicode need its own module just before we add Unicode to the
language?"

It may be that there are some semantics of ASCII that are not captured
in the Unicode spec. and thus are not generalizable. I'm pretty
confident that these ones ARE generalizable:

isalnum
isalpha
isascii
islower
isupper
isspace
isxdigit

How do Unicode users get this information from the famous Unicode
database and why not merge the Unicode and ASCII versions in 1.6?

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/~perlis-alan/quotes.html



From esr at thyrsus.com  Fri Jun  2 07:43:54 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 2 Jun 2000 01:43:54 -0400
Subject: [Python-Dev] ascii.py?
In-Reply-To: <39372FC5.DE1CE8EA@prescod.net>; from paul@prescod.net on Thu, Jun 01, 2000 at 10:53:41PM -0500
References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net>
Message-ID: <20000602014353.A5211@thyrsus.com>

Paul Prescod <paul at prescod.net>:
> "Eric S. Raymond" wrote:
> > 
> > There has been a vast and echoing silence about the ascii.py module I
> > posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> Without looking closely, or even being particularly knowledgable (how's
> that for a disclaimer!) my instinctive reaction was: "does the ASCII
> subset of Unicode need its own module just before we add Unicode to the
> language?"
> 
> It may be that there are some semantics of ASCII that are not captured
> in the Unicode spec. and thus are not generalizable.

ascii.ctrl is one such.

>                                                       I'm pretty
> confident that these ones ARE generalizable:
> 
> isalnum
> isalpha
> isascii
> islower
> isupper
> isspace
> isxdigit
> 
> How do Unicode users get this information from the famous Unicode
> database and why not merge the Unicode and ASCII versions in 1.6?

Answer: ascii.py is not designed for text processing.  I wrote it to package
some functions useful for classifying *ASCII* data, especially in the
context of roguelike programs that interpret keystrokes coming in through
a curses interface.

(Where this all touches ground is CML2, my replacement configuration 
system for the Linux kernel.)
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

..every Man has a Property in his own Person. This no Body has any
Right to but himself.  The Labour of his Body, and the Work of his
Hands, we may say, are properly his. .... The great and chief end
therefore, of Mens uniting into Commonwealths, and putting themselves
under Government, is the Preservation of their Property.
	-- John Locke, "A Treatise Concerning Civil Government"



From gstein at lyra.org  Fri Jun  2 10:43:13 2000
From: gstein at lyra.org (Greg Stein)
Date: Fri, 2 Jun 2000 01:43:13 -0700 (PDT)
Subject: [Python-Dev] httplib (was: Adding LDAP to the Python core... ?!)
In-Reply-To: <14645.51445.963154.817309@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.10006020134050.17073-100000@nebula.lyra.org>

It looks like a definite bug. I have *no* idea, tho, why it is doing
that... I did quite a bit of testing with chunked replies. Admittedly,
though, I didn't stack up requests like you've done in your test. I'm
wrapping up mod_dav at the moment, so I don't really have time to look
deeply into this. Mebbe next week?

Regarding the pipeline request thing. I think it would probably be best to
just drop the whole "hold the previous response and wait for it to be
closed" thing. I don't know why that is in there; probably a leftover
(converted) semantic from the old-style HTTP() class. I'd be quite fine
just axing it and allowing the client to shove ten requests down the pipe
before pulling the first response back out.

Oh. Wait. Maybe that was it. You can't read the "next" response until the
first one has been read. Well... no need to block putting new responses;
we just need to create a way to "get the next reply" and/or "can I get the
next reply yet?"

Cheers,
-g

p.s. Moshe also had a short list of review items. I read thru them, but
not with the code in hand to understand some of his specifics.


On Wed, 31 May 2000, Jeremy Hylton wrote:
> >>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
> 
>   GS> [ and recall my email last week that I've updated httplib.py and
>   GS> posted it to my web pages; it is awaiting review for integration
>   GS> into the Python core; it still needs docs and more testing
>   GS> scenarios, tho
> 
> I've been looking at the httplib code, and I found what may be a bug.
> Not sure, because I'm not sure how the API works for pipelined
> requests. 
> 
> I've got some test code that looks a bit like this:
> 
> def test_new_interface_series(urls):
>     paths = []
>     the_host = None
>     for url in urls:
>         host, path = get_host_and_path(url)
>         if the_host is None:
>             the_host = host
>         else:
>             assert host == the_host
>         paths.append(path)
>         
>     conn = httplib.HTTPConnection(the_host)
>     for path in paths:
>         conn.request('GET', path, headers={'User-Agent': 'httplib/Python'})
>     for path in paths:
>         errcode, errmsg, resp = conn.getreply()
>         buf = resp.read()
>         if errcode == 200:
>             print errcode, resp.headers
>         else:
>             print errcode, `errmsg`, resp
>         print resp.getheader('Content-Length'), len(buf)
>         print repr(buf[:40])
>         print repr(buf[-40:])
>         print
>     conn.close()
> 
> test_new_interface_series(['http://www.python.org/',
>                         'http://www.python.org/pics/PyBanner054.gif',
>                         'http://www.python.org/pics/PythonHi.gif',
>                         'http://www.python.org/Jobs.html',
>                         'http://www.python.org/doc/',
>                         'http://www.python.org/doc/current/',
>                            ])
> 
> The second loop that reads the replies gets fouled up after a couple
> of responses.  I added even more debugging and found that the first
> line of the corrupted response is
> 
> > 'ontent-Type: text/html\015\012'
> 
> It looks like some part of the program is consuming too much input.  I
> haven't been able to figure out what part yet.  Hoping that you might
> have some good ideas.
> 
> Thinking about this issue, I came up with a potential API problem.
> You must read the body after calling getreply and before calling
> getreply a second time.  This kind of implicit requirement is a bit
> tricky.  It would help if the implementation could raise an error if
> this happens.  It might be even better if it just worked, although it
> seems a bit too magical.
> 
> Jeremy
> 

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






From mal at lemburg.com  Fri Jun  2 10:11:05 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 10:11:05 +0200
Subject: [Python-Dev] Re: [Patches] Translating doc strings
References: <200006020701.JAA28620@pandora>
Message-ID: <39376C19.53A01A27@lemburg.com>

Martin von Loewis wrote:
> 
> To simplify usage of Python for people who don't speak English well,
> I'd like to start a project translating the doc strings in the Python
> library. This has two aspects:
> 
> 1. there must be a simple way to access the translated doc strings

Do you plan to use GNU gettext here ? (This would cause the
translated version of Python to fall under GPL, AFAIK)

I'd propose to use the existing doc-strings as keys to 
a translation mapping. This assures that existing doc-strings
remain intact and that the actual translation process is
done at query time, e.g. by using a help() built-in function.

> 2. there must be actual translations to the various native languages
>    of Python users.
> 
> Since the second task is much more complicated, I submit a snapshot of
> this project, namely, a message catalog of the doc strings in the
> Python libraries, taken from the CVS; along with a snapshot of the
> German translations. I intend to complete the German translations in
> the coming weeks, but I want to give other translators a chance to
> also start working on that.
> 
> Please note that extracting the docstrings was not straight-forward;
> I've used Fran?ois Pinard's most excellent po-utils 0.5 as a starting
> point, and enhanced it with the capability to recognize __doc__[] in C
> code, so that I would also get (most of) the doc strings in C modules.
> I plan to update this catalog a few times before Python 1.6 is
> released, so that translators can update their translations.
> 
> A key point is finding translators. I propose to use the
> infrastructure of the GNU translation project for that: There are
> established teams for all major languages, and an infrastructure (also
> maintained by Fran?ois) where notifications about new catalogs are
> automatically distributed to the teams. That should not stop
> volunteers which don't currently participate in the GNU translation
> project from translating - however, they should announce that they
> plan to work on translating these messages to avoid duplication of
> work.

This will only work iff the translations can be submitted
via the usual "post to patches with dislcaimer" method...
aren't the GNU people interested in putting the translations
under the GPL ?

> Another matter is where the catalogs should live in the Python source
> tree. I propose to have a Misc/po directory, which will contain both
> the PO catalogues, as well as the binary .mo objects; only the latter
> will be installed during the installation process.
> 
> Please let me know what you think, in particular, whether I can submit
> the catalog to the translation teams.
> 
> Regards,
> Martin
> 
>   ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>               Name: doc.tgz
>    doc.tgz    Type: unspecified type (application/octet-stream)
>           Encoding: base64

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From mal at lemburg.com  Fri Jun  2 09:55:04 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 09:55:04 +0200
Subject: [Python-Dev] ascii.py?
References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us>
Message-ID: <39376858.55D4F778@lemburg.com>

Andrew Kuchling wrote:
> 
> On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
> >There has been a vast and echoing silence about the ascii.py module I
> >posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> One misgiving I had was locales; is it a bug or a feature that locales
> aren't supported, as they are for the C isdigit(), isalpha(), &c,
> functions?  I'm not entirely sure which it is.  (The locale module
> doesn't expose the C is*() functions, though I think they're used in
> constructing string.letters.)

FYI, both strings and Unicode object already have a few
.isXXX() methods:

	isdigit(), islower(), isspace(), istitle(), isupper()

For strings these use the C APIs (which are locale aware),
for Unicode the built in mappings are used.

BTW, I haven't looked at the docs lately, but are the string
and Unicode methods already documented ? All of them
have doc-strings, so it should be easy extracting the data
to build a TeX-file.

On the topic of adding ascii.py, I'm +0 -- I don't currently
have a need for it, but writing .append(ascii.CR + ascii.LF)
does add to the readability of scripts.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From mal at lemburg.com  Fri Jun  2 10:02:35 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 10:02:35 +0200
Subject: [I18n-sig] Re: [Python-Dev] ascii.py?
References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net>
Message-ID: <39376A1B.10E45C7B@lemburg.com>

Paul Prescod wrote:
> 
> "Eric S. Raymond" wrote:
> >
> > There has been a vast and echoing silence about the ascii.py module I
> > posted here at Fred Drake's request.  Is it really such a  bad idea?
> 
> Without looking closely, or even being particularly knowledgable (how's
> that for a disclaimer!) my instinctive reaction was: "does the ASCII
> subset of Unicode need its own module just before we add Unicode to the
> language?"
> 
> It may be that there are some semantics of ASCII that are not captured
> in the Unicode spec. and thus are not generalizable. I'm pretty
> confident that these ones ARE generalizable:
> 
> isalnum
> isalpha
> isascii
> islower
> isupper
> isspace
> isxdigit
> 
> How do Unicode users get this information from the famous Unicode
> database and why not merge the Unicode and ASCII versions in 1.6?

Note that many of the above are already implemented as
string|Unicode methods.

The Unicode database is accessible via the unicodedata
module. The specs for the used APIs and constants can
be found in the Unicode database description file
on www.unicode.org.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From loewis at informatik.hu-berlin.de  Fri Jun  2 14:33:07 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 14:33:07 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <39376C19.53A01A27@lemburg.com> (mal@lemburg.com)
References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com>
Message-ID: <200006021233.OAA16962@pandora>

> Do you plan to use GNU gettext here ? (This would cause the
> translated version of Python to fall under GPL, AFAIK)

No, I plan to use the Python gettext module, which is currently being
integrated into Python. It will either use the system's gettext
library, or read mo files using pure Python.

> I'd propose to use the existing doc-strings as keys to 
> a translation mapping. This assures that existing doc-strings
> remain intact and that the actual translation process is
> done at query time, e.g. by using a help() built-in function.

This is more or less what I've planned. I'd propose to call the
function doc, with an interface like

>>> doc(time.time)
time() -> Gleitkommazahl

Gib die aktuelle Zeit in Sekunden seit Beginn der Epoche zur?ck.
Sekundenbruchteile sind vorhanden, falls die Systemuhr sie bereitstellt.

It won't use a dictionary, though, but the underlying gettext query
mechanism. Exact naming and parameters are certainly subject to
discussion, my proposal would be

doc(object, doprint=1, translate=1)

so that users save quite some typing over

>>> print time.time.__doc__ 
time() -> floating point number

Return the current time in seconds since the Epoch.
Fractions of a second may be present if the system clock provides them.

> This will only work iff the translations can be submitted
> via the usual "post to patches with dislcaimer" method...
> aren't the GNU people interested in putting the translations
> under the GPL ?

Is it really necessary to have the translations posted to
patches at python.org? Or would it be sufficient if translators express
their disclaimer in some other way.

I don't think the translation teams are "the GNU people"; the
translators accepted to assign their copyright to the FSF for the
translations they did - I'd assume at least some of them would also
accept maintaining the copyright, or assigning it to the Python
Consortium (or whoever else wants it). It's more that the Python
distributor would need to make suggestions what the copyright on
translations should be - I'm sure that could be clearly communicated
to the translators.

Regards,
Martin



From fdrake at acm.org  Fri Jun  2 14:50:35 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 2 Jun 2000 08:50:35 -0400 (EDT)
Subject: [Python-Dev] ascii.py?
In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>
References: <200006012236.SAA03578@snark.thyrsus.com>
Message-ID: <14647.44443.651246.979946@cj42289-a.reston1.va.home.com>

Eric S. Raymond writes:
 > There has been a vast and echoing silence about the ascii.py module I
 > posted here at Fred Drake's request.  Is it really such a  bad idea?

  Did you get my comments?


  -Fred

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




From bwarsaw at python.org  Fri Jun  2 15:37:42 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Fri, 2 Jun 2000 09:37:42 -0400 (EDT)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
References: <200006020701.JAA28620@pandora>
	<39376C19.53A01A27@lemburg.com>
	<200006021233.OAA16962@pandora>
Message-ID: <14647.47270.330318.807347@anthem.python.org>

>>>>> "MvL" == Martin von Loewis <loewis at informatik.hu-berlin.de> writes:

    MvL> No, I plan to use the Python gettext module, which is
    MvL> currently being integrated into Python. It will either use
    MvL> the system's gettext library, or read mo files using pure
    MvL> Python.

pygettext is in Tools/i18n, and I've been working with James
Henstridge and Peter Funk on getting a standard gettext module
integrated into the core.  A few other things have bumped that down on
my list, but it's still there.

We'll still need xgettext to scan the C code.  Also, marking Python
module docstrings is a bit problematic.  I've resorted to Something
Really Ugly:

-------------------- snip snip --------------------
try:
    import fintl
    _ = fintl.gettext
except ImportError:
    def _(s): return s


__doc__ = _("""pygettext -- Python equivalent of xgettext(1)
...")
-------------------- snip snip --------------------

Yuck.

-Barry



From pf at artcom-gmbh.de  Fri Jun  2 15:57:32 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Fri, 2 Jun 2000 15:57:32 +0200 (MEST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <14647.47270.330318.807347@anthem.python.org> from "Barry A. Warsaw" at "Jun 2, 2000  9:37:42 am"
Message-ID: <m12xrx6-000DifC@artcom0.artcom-gmbh.de>

Hi, 

[Barry A. Warsaw]:
> pygettext is in Tools/i18n, and I've been working with James
> Henstridge and Peter Funk on getting a standard gettext module
> integrated into the core.  A few other things have bumped that down on
> my list, but it's still there.

I will try to make some progress.  Currently I'm not sure how to
define a class 'Translator' ...  I'm open for suggestions.  James
has also made some interesting points.

> We'll still need xgettext to scan the C code.  Also, marking Python
> module docstrings is a bit problematic.  I've resorted to Something
> Really Ugly:
> 
> -------------------- snip snip --------------------
> try:
>     import fintl
>     _ = fintl.gettext
> except ImportError:
>     def _(s): return s
> 
> 
> __doc__ = _("""pygettext -- Python equivalent of xgettext(1)
> ...")
> -------------------- snip snip --------------------
> 
> Yuck.

I agree: this is really ugly.  Since doc-strings are something special,
I don't think, we should travel further down this road.  I believe,
we should use a special doc-string extration-tool (possibly build
on top of ping's 'inspect.py'?), which will then create a .pot-file
solely out of __doc__-strings.

Regards, Peter.



From loewis at informatik.hu-berlin.de  Fri Jun  2 17:03:50 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 17:03:50 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <14647.47270.330318.807347@anthem.python.org>
	(bwarsaw@python.org)
References: <200006020701.JAA28620@pandora>
	<39376C19.53A01A27@lemburg.com>
	<200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org>
Message-ID: <200006021503.RAA26314@pandora>

> We'll still need xgettext to scan the C code.

Please have a look at my lib.pot; I've been using xpot to extract the
C doc strings, which aren't currently marked-up in the Python source.

As for module docstrings: xpot doesn't recognize them either, but I
think it could be improved to do so. However, that would give a
substantial increase of the catalogs, so I'd recommend to add them
only when the translators are done with the first round of
translation. Having the full set of distutils doc strings in the
catalog is already a substantial amount of text to translate...

Regards,
Martin



From loewis at informatik.hu-berlin.de  Fri Jun  2 17:05:35 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 17:05:35 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <m12xrx6-000DifC@artcom0.artcom-gmbh.de> (pf@artcom-gmbh.de)
References: <m12xrx6-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <200006021505.RAA26338@pandora>

> I agree: this is really ugly.  Since doc-strings are something special,
> I don't think, we should travel further down this road.  I believe,
> we should use a special doc-string extration-tool (possibly build
> on top of ping's 'inspect.py'?), which will then create a .pot-file
> solely out of __doc__-strings.

I agree. Again, I'd like to advertise Fran?ois Pinard's xpot, which
can extract doc strings from both Python code and C code.

Regards,
Martin



From moshez at math.huji.ac.il  Fri Jun  2 19:52:59 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Fri, 2 Jun 2000 20:52:59 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
Message-ID: <Pine.GSO.4.10.10006022048430.9466-100000@sundial>

Trusting OS-based mtimes for .pyc caching has some inherent problems.
(Clock syncing and similar) Frankly, though I've never been bitten by
this, it does give me an uncomfortable feeling. What if, instead, we'd use
md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
problems is miniscule compared to the real problems clock syncing has
already caused. (I think I remember some problem with .pyc's on IIS, but
I may just be hallucinating)

Problems:
.pyc size would increase by 24 bytes <wink>

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From trentm at activestate.com  Fri Jun  2 20:14:17 2000
From: trentm at activestate.com (Trent Mick)
Date: Fri, 2 Jun 2000 11:14:17 -0700
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer?
Message-ID: <20000602111417.A17233@activestate.com>

So, is PyMarshal_WriteLongToFile intended to write a C long, regardless of
its size, or is it intended to alway write 32-bits?

Currently it just writes 32-bits and if sizeof(long) > 4 for that platform
then it is silently truncated. PyMarshal_WriteLongToFile is currently only
used (in the core anyway) to write the magic number and timestamp for .pyc
files in import.c.

The current situation is pretty misleading. If you write a long directly with
PyMarshal_WriteLongToFile your long is truncated to 32-bits. However, if you
write a long indirectly by PyMarshal_WriteObjectToFile, where that Python
object is or contains a PyInt (C long), then the long is *not* truncated.

Options:

1. leave it, who cares

2. - change PyMarshal_WriteLongToFile to write 64-bits if long is 64-bits
   - add something like PyMarshal_WriteInt32ToFile for the benefit of users
	 like import.c that want to control exactly how many bytes get written

3. - change PyMarshal_WriteLongToFile to raise an exception if the long
	 overflows a 32-bit range

Thanks,
Trent


-- 
Trent Mick
trentm at activestate.com



From pf at artcom-gmbh.de  Fri Jun  2 21:21:30 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Fri, 2 Jun 2000 21:21:30 +0200 (MEST)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006022048430.9466-100000@sundial> from Moshe Zadka at "Jun 2, 2000  8:52:59 pm"
Message-ID: <m12xx0c-000DifC@artcom0.artcom-gmbh.de>

hi,

Moshe Zadka wrote:
> Trusting OS-based mtimes for .pyc caching has some inherent problems.
> (Clock syncing and similar) Frankly, though I've never been bitten by
> this, it does give me an uncomfortable feeling. What if, instead, we'd use
> md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
> problems is miniscule compared to the real problems clock syncing has
> already caused. (I think I remember some problem with .pyc's on IIS, but
> I may just be hallucinating)

The timestamp is returned by simply 'stat'ing the .py file.  If you
want more, you actually would have to open the .py files all the time.
This would be trading a big performance penalty for a security, that
will almost always not needed.  In Unix many sub systems (for example
'make' depend on a monotone system clock.  A random jumping clock
would break many of them anyway.

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)



From gstein at lyra.org  Fri Jun  2 21:53:21 2000
From: gstein at lyra.org (Greg Stein)
Date: Fri, 2 Jun 2000 12:53:21 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006022048430.9466-100000@sundial>
Message-ID: <Pine.LNX.4.10.10006021251140.20995-100000@nebula.lyra.org>

On Fri, 2 Jun 2000, Moshe Zadka wrote:
> Trusting OS-based mtimes for .pyc caching has some inherent problems.
> (Clock syncing and similar) Frankly, though I've never been bitten by
> this, it does give me an uncomfortable feeling. What if, instead, we'd use
> md5- or sha-based approach?

That is an expensive computation. You'd have to read the whole file in and
compute the hash.

Today, we simply stat() each file. If the .pyc looks valid, we open it and
check the date stamp against one of those stat's.

You would be adding an open(), a read of the full file, and compute a
hash -- to every import of a .pyc.


-1

Cheers,
-g

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




From mal at lemburg.com  Fri Jun  2 21:13:20 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Jun 2000 21:13:20 +0200
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
References: <Pine.GSO.4.10.10006022048430.9466-100000@sundial>
Message-ID: <39380750.97CD3BA0@lemburg.com>

Moshe Zadka wrote:
> 
> Trusting OS-based mtimes for .pyc caching has some inherent problems.
> (Clock syncing and similar) Frankly, though I've never been bitten by
> this, it does give me an uncomfortable feeling. What if, instead, we'd use
> md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
> problems is miniscule compared to the real problems clock syncing has
> already caused. (I think I remember some problem with .pyc's on IIS, but
> I may just be hallucinating)
> 
> Problems:
> .pyc size would increase by 24 bytes <wink>

Much worse: you'd have to recalculate the MD5-sum every time
you import the .pyc file...

Frankly, I don't think this is needed at all ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From loewis at informatik.hu-berlin.de  Fri Jun  2 22:46:34 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 2 Jun 2000 22:46:34 +0200 (MET DST)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <Pine.SGI.3.96.1000602115722.30600f-100000@happy> (message from
	Ka-Ping Yee on Fri, 2 Jun 2000 12:07:22 -0700 (PDT))
References: <Pine.SGI.3.96.1000602115722.30600f-100000@happy>
Message-ID: <200006022046.WAA29600@pandora>

> But presumably we want to get all the strings, don't we?

Certainly not. For example, in ftplib, the string "anonymous" should
not be translated - it would end up as "anonym" in German, and that
would not be accepted by FTP servers. In general, great care is needed
to select translatable strings. 

For example, the GNU ls program was localized to print the month names
in German. Pretty safe, eh? Now, the emacs dired mode wouldn't
recognize any file names in the list output anymore, because it
had a regular expression to detect the various fields, which involved
an alternative list for all the month names...

Regards,
Martin



From pingster at ilm.com  Fri Jun  2 21:07:22 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Fri, 2 Jun 2000 12:07:22 -0700 (PDT)
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <m12xrx6-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.SGI.3.96.1000602115722.30600f-100000@happy>

On Fri, 2 Jun 2000, Peter Funk wrote:
> 
> I agree: this is really ugly.  Since doc-strings are something special,
> I don't think, we should travel further down this road.  I believe,
> we should use a special doc-string extration-tool (possibly build
> on top of ping's 'inspect.py'?), which will then create a .pot-file
> solely out of __doc__-strings.

Getting __doc__ strings is pretty easy (inspect.py is one possibility).
But presumably we want to get all the strings, don't we?

That should be trivial with tokenize, right?

    ---- getstrings.py -----

    import sys, tokenize
    strings = []
    def tokeneater(type, token, start, end, line):
        if type == tokenize.STRING: strings.append(eval(token))
            
    file = open(sys.argv[1])
    tokenize.tokenize(file.readline, tokeneater)
    print strings

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

    % ./getstrings.py /usr/local/lib/python1.5/calendar.py 
    ['calendar.error', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday', 'Sunday', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun', '', 'January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'No
vember', 'December', '   ', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec', 'bad month number', ' ', ' ', '', '', ' ', ' ', '\012', '\012', '\012', ' ', '', '', ' ']

Am i missing something?


-- ?!ng




From gstein at lyra.org  Fri Jun  2 23:32:52 2000
From: gstein at lyra.org (Greg Stein)
Date: Fri, 2 Jun 2000 14:32:52 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <m12xx0c-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>

On Fri, 2 Jun 2000, Peter Funk wrote:
> Moshe Zadka wrote:
> > Trusting OS-based mtimes for .pyc caching has some inherent problems.
> > (Clock syncing and similar) Frankly, though I've never been bitten by
> > this, it does give me an uncomfortable feeling. What if, instead, we'd use
> > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
> > problems is miniscule compared to the real problems clock syncing has
> > already caused. (I think I remember some problem with .pyc's on IIS, but
> > I may just be hallucinating)
> 
> The timestamp is returned by simply 'stat'ing the .py file.  If you
> want more, you actually would have to open the .py files all the time.
> This would be trading a big performance penalty for a security, that
> will almost always not needed.  In Unix many sub systems (for example
> 'make' depend on a monotone system clock.  A random jumping clock
> would break many of them anyway.

He does have a point, but I think the wrong solution :-)

While the clock may be monotonically increasing on one system, it isn't
always the case when things like NFS come into play.

I recall a case back '95 when I was editing a .py over an NFS mount and
running the code on the target machine. The clocks on the two boxes were
off by about three seconds. I was going thru the edit/run/edit/run cycle
so quickly, that at one point, I saved a .py file that was older than the
associated .pyc file.

Needless to say, I was really confused that my recent edit didn't produce
the desired result :-)

Cheers,
-g

p.s. and no, I don't know why the internal timestamp didn't take effect

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




From pingster at ilm.com  Sat Jun  3 01:10:01 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Fri, 2 Jun 2000 16:10:01 -0700 (PDT)
Subject: [Python-Dev] Protecting __name__ &c.
Message-ID: <Pine.SGI.3.96.1000602160710.30600q-100000@happy>

Would it be too much trouble to prevent replacing
double-underscore attributes like __name__ and __file__?

I'll accept a "consenting adults" argument -- it's just
that somehow this makes me uneasy:

    Python 1.5.2 (#54, Jul 14 1999, 12:50:51) [C] on irix6
    Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
    >>> import foo
    >>> foo.__name__
    'bar'
    >>> foo.__file__
    'bar.py'
    >>> foo
    <module 'bar' from 'bar.py'>

Of course, there is no 'bar.py'.  'foo.py' just contains

    __file__ = 'bar.py'
    __name__ = 'bar'

(If you say i deserved to be punished for such heresy, fine...)



-- ?!ng




From mhammond at skippinet.com.au  Sat Jun  3 01:21:07 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 3 Jun 2000 09:21:07 +1000
Subject: [Python-Dev] Protecting __name__ &c.
In-Reply-To: <Pine.SGI.3.96.1000602160710.30600q-100000@happy>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEECCMAA.mhammond@skippinet.com.au>

> Would it be too much trouble to prevent replacing
> double-underscore attributes like __name__ and __file__?

This can be handy sometimes.

> I'll accept a "consenting adults" argument -- it's just
> that somehow this makes me uneasy:

OK - accept it :-)  Just dont do it if it makes you uneasy.

>     >>> import foo
>     >>> foo.__name__
>     'bar'
>     >>> foo.__file__
>     'bar.py'
>     >>> foo
>     <module 'bar' from 'bar.py'>

That is no worse than, say:

>>> a=1
>>> globals()['a']=2
>>> a
2

So you could make the same argument that globals() should be read-only, to
force you to do the "normal" thing.

To me, this is one of Python's big features.  I dont want it holding my
hand so tightly it cuts circulation :-)

Mark.




From akuchlin at cnri.reston.va.us  Sat Jun  3 05:15:50 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Fri, 2 Jun 2000 23:15:50 -0400
Subject: [Python-Dev] What's New (first draft)
Message-ID: <20000602231550.A986@newcnri.cnri.reston.va.us>

I've put up the crude first draft of a "What's New in Python 1.6" article,
co-written with Moshe Zadka.  Please offer comments (or even patches to the
LaTeX!). 

http://www.python.net/crew/amk/python/writing/new-python/

PDF, DVI, ASCII, and the LaTeX source are in:
	ftp://www.python.net/pub/crew/amk/new/

Various people are mentioned by name in the document ("effbot did
this; MAL did that; Christian did that other thing...") because I want to
emphasize the number of contributors to this release; does everyone think
this is a good idea?  If I've missed your name, or credited you wrongly,
please let me know.

--amk



From akuchlin at cnri.reston.va.us  Sat Jun  3 05:25:21 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Fri, 2 Jun 2000 23:25:21 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
Message-ID: <20000602232521.B986@newcnri.cnri.reston.va.us>

I've slightly revised the 1.6 jobs list
at http://www.python.net/crew/amk/python/1.6-jobs.html .
Things still on the TODO list, maybe:

Import hooks revamp (or is this a post-1.6 thing?) 
Update the documentation to match 1.6 changes. 
Document more undocumented modules (goes without saying, really...) : codecs,
	unicodedata, mmap, pyexpat, curses, regrtest. 
Unicode: Compress the size of unicodedatabase 
Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch)
Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?)
Delete obsolete subdirectories in Demo/ directory 
Refurbish Demo subdirectories to be properly documented, match modern coding
	style, etc. 
Fix ./ld_so_aix installation problem on AIX 
Make test.regrtest.py more usable outside of thePython test suite 
Conservative garbage collection of cycles (maybe -- I don't know what GvR
	thinks about this)
Changes to PyExpat module
Test the hell out of SRE

The end of coding may be in sight, leaving only the job of documenting
everything new.  I'm getting kind of worried about the lengthening backlog
of patches, though; maybe next week we can start cutting it down? (Quick,
while Guido's away, everyone come up with new keywords and check them in!)

--amk



From esr at thyrsus.com  Sat Jun  3 05:49:16 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 2 Jun 2000 23:49:16 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Fri, Jun 02, 2000 at 11:25:21PM -0400
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <20000602234916.B9680@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> Document more undocumented modules (goes without saying, really...) : codecs,
> 	unicodedata, mmap, pyexpat, curses, regrtest. 

About curses.  Have you got the entry points listed and dxescribed yet?
If so, I'll flesh out the docs with my tutorial stuff.

We have a volunteer maintainer for curses after release, now, BTW.  It's
new Pythoneer Jim Dennis, the "Answer Guy" from the Linux Gazette.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The end move in politics is always to pick up a gun.
	-- R. Buckminster Fuller



From bwarsaw at python.org  Sat Jun  3 06:41:42 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Sat, 3 Jun 2000 00:41:42 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <14648.35974.486959.379543@anthem.python.org>

Did we ever decide on building in thread support by default?  I'd
really like to see threads enabled by default in 1.6 and I /think/
it'll just take some autoconf hacking, which I'm willing to do.  Are
there any objections to building in threads support by default if
autoconf detects threads?

-Barry



From moshez at math.huji.ac.il  Sat Jun  3 08:05:09 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 3 Jun 2000 09:05:09 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>
Message-ID: <Pine.GSO.4.10.10006030900030.14749-100000@sundial>

On Fri, 2 Jun 2000, Greg Stein wrote:

> He does have a point, but I think the wrong solution :-)

In my defense, it was after spending the whole day on my feet giving a
lecture, or driving (for 12 hours).

But it does bother me, even if the solution is terrible.
How about having, in addition to the time-stamp, the size of the file?
At least on UNIX, it comes for free with the same stat call.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From moshez at math.huji.ac.il  Sat Jun  3 09:56:15 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 3 Jun 2000 10:56:15 +0300 (IDT)
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit
 integer?
In-Reply-To: <20000602111417.A17233@activestate.com>
Message-ID: <Pine.GSO.4.10.10006030833470.14749-100000@sundial>

On Fri, 2 Jun 2000, Trent Mick wrote:

> 3. - change PyMarshal_WriteLongToFile to raise an exception if the long
> 	 overflows a 32-bit range

+1 on that, finally non-portable integers will cause an exception.

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com





From moshez at math.huji.ac.il  Sat Jun  3 10:11:45 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 3 Jun 2000 11:11:45 +0300 (IDT)
Subject: [Python-Dev] Protecting __name__ &c.
In-Reply-To: <Pine.SGI.3.96.1000602160710.30600q-100000@happy>
Message-ID: <Pine.GSO.4.10.10006031109180.14749-100000@sundial>

On Fri, 2 Jun 2000, Ka-Ping Yee wrote:

> Would it be too much trouble to prevent replacing
> double-underscore attributes like __name__ and __file__?

Well, special casing seems like a bad idea on the face of it. Where does
it stop? The correct way to "solve" this, is to add declarations to
Python, including "constant" declaration, and then saying that __name__
and __file__ are "implicitly declared" constants.

please-scatter-IMHOs-generously-throughtout-the-mail-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From gstein at lyra.org  Sat Jun  3 11:52:39 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 02:52:39 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14648.35974.486959.379543@anthem.python.org>
Message-ID: <Pine.LNX.4.10.10006030252230.28613-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Barry A. Warsaw wrote:
> Did we ever decide on building in thread support by default?  I'd
> really like to see threads enabled by default in 1.6 and I /think/
> it'll just take some autoconf hacking, which I'm willing to do.  Are
> there any objections to building in threads support by default if
> autoconf detects threads?

+1 -- if they are there, then build them in!

Cheers,
-g

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




From gmcm at hypernet.com  Sat Jun  3 13:26:18 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Sat, 3 Jun 2000 07:26:18 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <1252090883-19062603@hypernet.com>

Andrew Kuchling wrote:

> I've slightly revised the 1.6 jobs list
> at http://www.python.net/crew/amk/python/1.6-jobs.html .
> Things still on the TODO list, maybe:
> 
> Import hooks revamp (or is this a post-1.6 thing?) 

The import SIG was created to resolve the controversies 
around imputils. The archives of the import SIG contain 
absolutely no controversy. So I say do it.

- Gordon



From skip at mojam.com  Sat Jun  3 14:15:28 2000
From: skip at mojam.com (Skip Montanaro)
Date: Sat, 3 Jun 2000 07:15:28 -0500 (CDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>
References: <m12xx0c-000DifC@artcom0.artcom-gmbh.de>
	<Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org>
Message-ID: <14648.63200.850429.304545@beluga.mojam.com>

    Greg> I recall a case back '95 when I was editing a .py over an NFS
    Greg> mount and running the code on the target machine. The clocks on
    Greg> the two boxes were off by about three seconds. I was going thru
    Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved
    Greg> a .py file that was older than the associated .pyc file.

A help I think would be to compare the mtimes of the .py and .pyc files with 
the current system clock and squawk if either appears to have been created
in the future.  I believe this is what GNU make does.

Of course, the best solution to all of this is the non-Python solution: use
NTP so your clocks stay sync'd.  It's even available out-of-the-box on my
iMac...

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
"We have become ... the stewards of life's continuity on earth.  We did not
ask for this role...  We may not be suited to it, but here we are."
- Stephen Jay Gould



From moshez at math.huji.ac.il  Sat Jun  3 14:53:47 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 3 Jun 2000 15:53:47 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com>
Message-ID: <Pine.GSO.4.10.10006031551470.17983-100000@sundial>

On Sat, 3 Jun 2000, Skip Montanaro wrote:

> Of course, the best solution to all of this is the non-Python solution: use
> NTP so your clocks stay sync'd.  It's even available out-of-the-box on my
> iMac...

But the "Python Way" was always to adapt: not to require One True Way, but
to use the facilities where it finds itself.

In any case, is there any objection to storing the size of the .py
alongside it's mtime in the .pyc, and regenerating if either is changed?
This is just as efficient, and much more reliable.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From mal at lemburg.com  Sat Jun  3 11:55:26 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 03 Jun 2000 11:55:26 +0200
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
Message-ID: <3938D60E.391AAF31@lemburg.com>

Andrew Kuchling wrote:
> 
> I've slightly revised the 1.6 jobs list
> at http://www.python.net/crew/amk/python/1.6-jobs.html .
> Things still on the TODO list, maybe:
> 
> Import hooks revamp (or is this a post-1.6 thing?)
> Update the documentation to match 1.6 changes.
> Document more undocumented modules (goes without saying, really...) : codecs,
>         unicodedata, mmap, pyexpat, curses, regrtest.

I would appreciate some help with codec and unicodedata.
codec.py has quite a bit of __doc__ string documentation
which can be used more or less directly for the TeX docs.

> Unicode: Compress the size of unicodedatabase

Christian was working on this one, but I never got the
patches ... Chris ?

> Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch)

I wonder why that patch hasn't been accepted yet -- I guess
the patches list needs some more people willing to review things
and of course people with check in permissions.

I would volunteer to handle the above for the Unicode parts
of the distribution if someone would explain to me how to
checkin new code into SourceForge CVS.

> Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?)

Hmm, there are no XXX markings left in my version of that
file -- perhaps I've missed adding it to the patch sets...

Anyway, the file will have to undergo some rewrite now that
the default encoding strategy has changed. I'll fix that next
week.

> Delete obsolete subdirectories in Demo/ directory
> Refurbish Demo subdirectories to be properly documented, match modern coding
>         style, etc.
> Fix ./ld_so_aix installation problem on AIX
> Make test.regrtest.py more usable outside of thePython test suite
> Conservative garbage collection of cycles (maybe -- I don't know what GvR
>         thinks about this)
> Changes to PyExpat module
> Test the hell out of SRE
> 
> The end of coding may be in sight, leaving only the job of documenting
> everything new.  I'm getting kind of worried about the lengthening backlog
> of patches, though; maybe next week we can start cutting it down? (Quick,
> while Guido's away, everyone come up with new keywords and check them in!)

:-)

Still, you've got a point there: Trent's patches are getting
piled up and due to the fact that they touch many different
parts of the code, they are likely to get in the way of other
patches.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From jeremy at beopen.com  Sat Jun  3 18:11:48 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Sat, 3 Jun 2000 12:11:48 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <3938D60E.391AAF31@lemburg.com>
Message-ID: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>

M.-A. Lemburg wrote:
>I wonder why that patch hasn't been accepted yet -- I guess
>the patches list needs some more people willing to review things
>and of course people with check in permissions.

One of the problems I'm having is keeping track of which patches
are still outstanding.  This is really a management/tools problem.
I have a mailbox full of messages from the patches list -- some
of the messages are patches, others are discussion.  Some patches
supercede others or are duplicates.  It would help if we had better
tools for managing the submitted/pending patches.

SourceForge makes it a little more inconvenient to check which
patches have been applied.  Under the old CVS arrangement, it was
a local operation to do a cvs log or diff.  Now it's a slow network
operation that requires authentication.  (I really want a local
mirror of the entire CVS repository!)

Sorry for the excuses.  I think better tools would help a lot, but
we'll have to get more people checkin privileges regardless.

Jeremy







From tismer at tismer.com  Sat Jun  3 18:43:51 2000
From: tismer at tismer.com (Christian Tismer)
Date: Sat, 03 Jun 2000 18:43:51 +0200
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com>
Message-ID: <393935C7.7624448A@tismer.com>


"M.-A. Lemburg" wrote:

> > Unicode: Compress the size of unicodedatabase
> 
> Christian was working on this one, but I never got the
> patches ... Chris ?

Schmurpel :->

Something came in between where I couldn't resist
to work on... yes, the microthread stuff was it.

Ok, it is a pain for me to go for a sub-optimum solution,
but yep, I'll force me to write the code gen now.

...
> Still, you've got a point there: Trent's patches are getting
> piled up and due to the fact that they touch many different
> parts of the code, they are likely to get in the way of other
> patches.

patch-as-patch-can-ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com



From tismer at tismer.com  Sat Jun  3 18:44:31 2000
From: tismer at tismer.com (Christian Tismer)
Date: Sat, 03 Jun 2000 18:44:31 +0200
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com>
Message-ID: <393935EF.89AA40DF@tismer.com>


"M.-A. Lemburg" wrote:

> > Unicode: Compress the size of unicodedatabase
> 
> Christian was working on this one, but I never got the
> patches ... Chris ?

Schmurpel :->

Something came in between where I couldn't resist
to work on... yes, the microthread stuff was it.

Not to talk of the starship mess, which will hopefully
end by this weekend...

Ok, it is a pain for me to go for a sub-optimum solution,
but yep, I'll force me to write the code gen now.

...
> Still, you've got a point there: Trent's patches are getting
> piled up and due to the fact that they touch many different
> parts of the code, they are likely to get in the way of other
> patches.

patch-as-patch-can-ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com



From gstein at lyra.org  Sat Jun  3 21:41:19 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 12:41:19 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com>
Message-ID: <Pine.LNX.4.10.10006031236430.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Skip Montanaro wrote:
>     Greg> I recall a case back '95 when I was editing a .py over an NFS
>     Greg> mount and running the code on the target machine. The clocks on
>     Greg> the two boxes were off by about three seconds. I was going thru
>     Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved
>     Greg> a .py file that was older than the associated .pyc file.
> 
> A help I think would be to compare the mtimes of the .py and .pyc files with 
> the current system clock and squawk if either appears to have been created
> in the future.  I believe this is what GNU make does.

Sure, but to the target machine, the .pyc was fine and the .py was in the
past. :-)

Of course, the proper solution is to introduce compile/link stages into
Python so that we don't get bitten by 3-second clock differences.

:-)

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




From gstein at lyra.org  Sat Jun  3 22:26:00 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 13:26:00 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.8,2.9
In-Reply-To: <200006031941.MAA21418@slayer.i.sourceforge.net>
Message-ID: <Pine.LNX.4.10.10006031324470.29036-100000@nebula.lyra.org>

Actually, PyArg_ParseTuple() is a better call for this. It allows you to
specify the method name:

    if (!PyArg_ParseTuple(args, ":close")) return NULL;


Cheers,,
-g

On Sat, 3 Jun 2000, A.M. Kuchling wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv21410
> 
> Modified Files:
> 	mmapmodule.c 
> Log Message:
> Add missing PyArg_NoArgs() calls to methods that didn't take arguments
>    (Pointed out by Moshe Zadka)
> 
> 
> Index: mmapmodule.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/mmapmodule.c,v
> retrieving revision 2.8
> retrieving revision 2.9
> diff -C2 -r2.8 -r2.9
> *** mmapmodule.c	2000/05/03 23:44:32	2.8
> --- mmapmodule.c	2000/06/03 19:41:42	2.9
> ***************
> *** 2,6 ****
>    /  Author: Sam Rushing <rushing at nightmare.com>
>    /  Hacked for Unix by A.M. Kuchling <amk1 at bigfoot.com> 
> !  /  $Id: mmapmodule.c,v 2.8 2000/05/03 23:44:32 guido Exp $
>   
>    / mmapmodule.cpp -- map a view of a file into memory
> --- 2,6 ----
>    /  Author: Sam Rushing <rushing at nightmare.com>
>    /  Hacked for Unix by A.M. Kuchling <amk1 at bigfoot.com> 
> !  /  $Id: mmapmodule.c,v 2.9 2000/06/03 19:41:42 akuchling Exp $
>   
>    / mmapmodule.cpp -- map a view of a file into memory
> ***************
> *** 76,79 ****
> --- 76,81 ----
>   mmap_close_method (mmap_object * self, PyObject * args)
>   {
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   #ifdef MS_WIN32
>   	UnmapViewOfFile (self->data);
> ***************
> *** 119,122 ****
> --- 121,126 ----
>   	char * where;
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   	if (self->pos >= 0 && self->pos < self->size) {
>   	        where = self->data + self->pos;
> ***************
> *** 132,136 ****
>   static PyObject *
>   mmap_read_line_method (mmap_object * self,
> ! 			   PyObject * args)
>   {
>   	char * start = self->data+self->pos;
> --- 136,140 ----
>   static PyObject *
>   mmap_read_line_method (mmap_object * self,
> ! 		       PyObject * args)
>   {
>   	char * start = self->data+self->pos;
> ***************
> *** 140,143 ****
> --- 144,149 ----
>   
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   
>   	eol = memchr(start, '\n', self->size - self->pos);
> ***************
> *** 154,158 ****
>   static PyObject *
>   mmap_read_method (mmap_object * self,
> ! 		      PyObject * args)
>   {
>   	long num_bytes;
> --- 160,164 ----
>   static PyObject *
>   mmap_read_method (mmap_object * self,
> ! 		  PyObject * args)
>   {
>   	long num_bytes;
> ***************
> *** 226,230 ****
>   static PyObject *
>   mmap_write_byte_method (mmap_object * self,
> ! 			    PyObject * args)
>   {
>   	char value;
> --- 232,236 ----
>   static PyObject *
>   mmap_write_byte_method (mmap_object * self,
> ! 			PyObject * args)
>   {
>   	char value;
> ***************
> *** 242,248 ****
>   static PyObject *
>   mmap_size_method (mmap_object * self,
> ! 		      PyObject * args)
>   {
>   	CHECK_VALID(NULL);
>   
>   #ifdef MS_WIN32
> --- 248,256 ----
>   static PyObject *
>   mmap_size_method (mmap_object * self,
> ! 		  PyObject * args)
>   {
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   
>   #ifdef MS_WIN32
> ***************
> *** 347,350 ****
> --- 355,360 ----
>   {
>   	CHECK_VALID(NULL);
> +         if (!PyArg_NoArgs(args))
> + 		return NULL;
>   	return (Py_BuildValue ("l", self->pos) );
>   }
> ***************
> *** 463,470 ****
>   
>   static int
> ! mmap_buffer_getreadbuf(self, index, ptr)
> ! 	mmap_object *self;
> ! int index;
> ! const void **ptr;
>   {
>   	CHECK_VALID(-1);
> --- 473,477 ----
>   
>   static int
> ! mmap_buffer_getreadbuf(mmap_object *self, int index, const void **ptr)
>   {
>   	CHECK_VALID(-1);
> ***************
> *** 868,869 ****
> --- 875,877 ----
>   
>   }
> + 
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins
> 

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




From gstein at lyra.org  Sat Jun  3 22:34:26 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 13:34:26 -0700 (PDT)
Subject: [Python-Dev] autoconf macros (was: RE: [Patches] Patch to Modules/pcre.h)
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBMEEMCMAA.mhammond@skippinet.com.au>
Message-ID: <Pine.LNX.4.10.10006031326320.29036-100000@nebula.lyra.org>

[moving to python-dev]

On Sun, 4 Jun 2000, Mark Hammond wrote:
> > I don't even see where DONT_HAVE_SYS_TYPES_H is ever defined:
> ...
> > Is it defined in some Mac-specific project file?
> 
> A few existed before, but I know I submitted a couple of the listed ones
> for Windows CE.  However, the CE config.h has never made it into the core,
> hence you can't find that particular definition...

Well, as I pointed out, the best way to do this is to add sys/types.h,
sys/stat.h, and stat.h to the AC_CHECK_HEADER() macro in configure.in. The
HAVE_SYS_TYPES_H macro and friends could then be checked.

PC/wince_config.h (or whatever it is called) would just #undef the 
HAVE_* macros.

The underlying issue here, is that autoconf can take care of these things
for us quite easily -- that we don't need manual maintenance of the
macros. For the odd platform without sys/types.h, autoconf will handle it,
rather than Python needing to do a special-case declaration.

Cheers,
-g

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




From gstein at lyra.org  Sat Jun  3 22:44:07 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 13:44:07 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
Message-ID: <Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Jeremy Hylton wrote:
>...
> Sorry for the excuses.  I think better tools would help a lot, but
> we'll have to get more people checkin privileges regardless.

There are several issues with expanded checkin privs:

1) trust: will the person make sure it is Right And Proper to do the
   checkin? (have they reviewed the code? is a a Good Change? etc) The
   counter here is that we don't want people that will simply take stuff
   arriving at patches@ and checking them in.

2) more people reviewing changes on the -checkins mailing list. Assuming
   that you want more than one pair of eyeballs looking at patches/code,
   that more people with commit privs increases the rate of commits, then
   you need more reviewers to keep up (because the reviewers probably are
   not going to review ALL checkins)

3) increasing dependence on -checkins means that patches MUST be smaller
   chunks. they MUST be single-purpose patches. practically nobody will
   review a 200k patch, or patches that fix N different things at once. A
   small, focused patch is easily reviewed.

   For example: Trent has recently mailed a bunch of patches to the
   patches list. This is Goodness: each one is focused and can be
   individually reviewed. Since they are not a single, giant blob, it also
   keeps them short and reviewable... each can have a +1/-1 independent of
   the others.


Cheers,
-g

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




From gstein at lyra.org  Sat Jun  3 23:14:49 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 14:14:49 -0700 (PDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006031551470.17983-100000@sundial>
Message-ID: <Pine.LNX.4.10.10006031412460.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Moshe Zadka wrote:
>...
> In any case, is there any objection to storing the size of the .py
> alongside it's mtime in the .pyc, and regenerating if either is changed?
> This is just as efficient, and much more reliable.

If we change the header size, then this would be fine. At the moment, I
don't think that anybody is suggesting a change to the .pyc header format
because of the number of tool breakages that would ensue.

People have seemed interested in my idea to update the marshal format to
record a version number -- it doesn't require a change to the .pyc header.

Cheers,
-g

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




From gstein at lyra.org  Sun Jun  4 00:53:18 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 15:53:18 -0700 (PDT)
Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!)
In-Reply-To: <Pine.LNX.4.10.10006020134050.17073-100000@nebula.lyra.org>
Message-ID: <Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>

I found the problem. Sneaky...

sock.makefile() does a dup() on the file descriptor, then opens a FILE*
with that. See it coming yet? ...

FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd
file descriptor. When we went to grab another chunk on the *original*
descriptor, we missed input [that is now sitting in the FILE* buffer].

Answer: change the .makefile() in getreply() to:

    file = self.sock.makefile('rb', 0)

This problem is going to affect the original httplib, too. IMO, we're
about to replace the sucker, so no worries...

Cheers,
-g

On Fri, 2 Jun 2000, Greg Stein wrote:
> It looks like a definite bug. I have *no* idea, tho, why it is doing
> that... I did quite a bit of testing with chunked replies. Admittedly,
> though, I didn't stack up requests like you've done in your test. I'm
> wrapping up mod_dav at the moment, so I don't really have time to look
> deeply into this. Mebbe next week?
> 
> Regarding the pipeline request thing. I think it would probably be best to
> just drop the whole "hold the previous response and wait for it to be
> closed" thing. I don't know why that is in there; probably a leftover
> (converted) semantic from the old-style HTTP() class. I'd be quite fine
> just axing it and allowing the client to shove ten requests down the pipe
> before pulling the first response back out.
> 
> Oh. Wait. Maybe that was it. You can't read the "next" response until the
> first one has been read. Well... no need to block putting new responses;
> we just need to create a way to "get the next reply" and/or "can I get the
> next reply yet?"
> 
> Cheers,
> -g
> 
> p.s. Moshe also had a short list of review items. I read thru them, but
> not with the code in hand to understand some of his specifics.
> 
> 
> On Wed, 31 May 2000, Jeremy Hylton wrote:
> > >>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
> > 
> >   GS> [ and recall my email last week that I've updated httplib.py and
> >   GS> posted it to my web pages; it is awaiting review for integration
> >   GS> into the Python core; it still needs docs and more testing
> >   GS> scenarios, tho
> > 
> > I've been looking at the httplib code, and I found what may be a bug.
> > Not sure, because I'm not sure how the API works for pipelined
> > requests. 
> > 
> > I've got some test code that looks a bit like this:
> > 
> > def test_new_interface_series(urls):
> >     paths = []
> >     the_host = None
> >     for url in urls:
> >         host, path = get_host_and_path(url)
> >         if the_host is None:
> >             the_host = host
> >         else:
> >             assert host == the_host
> >         paths.append(path)
> >         
> >     conn = httplib.HTTPConnection(the_host)
> >     for path in paths:
> >         conn.request('GET', path, headers={'User-Agent': 'httplib/Python'})
> >     for path in paths:
> >         errcode, errmsg, resp = conn.getreply()
> >         buf = resp.read()
> >         if errcode == 200:
> >             print errcode, resp.headers
> >         else:
> >             print errcode, `errmsg`, resp
> >         print resp.getheader('Content-Length'), len(buf)
> >         print repr(buf[:40])
> >         print repr(buf[-40:])
> >         print
> >     conn.close()
> > 
> > test_new_interface_series(['http://www.python.org/',
> >                         'http://www.python.org/pics/PyBanner054.gif',
> >                         'http://www.python.org/pics/PythonHi.gif',
> >                         'http://www.python.org/Jobs.html',
> >                         'http://www.python.org/doc/',
> >                         'http://www.python.org/doc/current/',
> >                            ])
> > 
> > The second loop that reads the replies gets fouled up after a couple
> > of responses.  I added even more debugging and found that the first
> > line of the corrupted response is
> > 
> > > 'ontent-Type: text/html\015\012'
> > 
> > It looks like some part of the program is consuming too much input.  I
> > haven't been able to figure out what part yet.  Hoping that you might
> > have some good ideas.
> > 
> > Thinking about this issue, I came up with a potential API problem.
> > You must read the body after calling getreply and before calling
> > getreply a second time.  This kind of implicit requirement is a bit
> > tricky.  It would help if the implementation could raise an error if
> > this happens.  It might be even better if it just worked, although it
> > seems a bit too magical.
> > 
> > Jeremy
> > 
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 
> 
> 
> 

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




From thomas at xs4all.net  Sun Jun  4 00:56:01 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 4 Jun 2000 00:56:01 +0200
Subject: [Python-Dev] Re: Is it just Syntactic Sugar ?
In-Reply-To: <3935B383.469032AE@python.org>; from guido@python.org on Wed, May 31, 2000 at 11:49:57PM +0000
References: <k7lW4.96338$E85.1941352@news1.rdc1.md.home.com> <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <mt4s7f7q62.fsf@astron.berkeley.edu> <m3u2ffydwy.fsf@atrus.jesus.cam.ac.uk> <mtog5n68ak.fsf@astron.berkeley.edu> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org>
Message-ID: <20000604005601.T469@xs4all.nl>

On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum wrote:

> I know I shouldn't be posting in this thread, and I won't be there to read
> the responses, but here's what I thought would be cool.

As the 'lucky, lucky bastard' is probably standing before the altar about
now, I'll send this to the dev-list instead. Not that I expect anyone *not*
to be at the wedding, but I bet the rest is back sooner ;-)

> x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means "and becomes"
> (an old Algol-68 naming convention; we could pick something better later
> but this will do for the explanation).

> For immutable types, this is defined as

>   def __add_ab__(self, other):
>       return self+other

> For mutable types, this is defined as a self-mutating operation,
> e.g. for lists it could be

>   def __add_ab__(self, other):
>       self.extend(other)
>       return self

This was what I had in mind, and was trying to explain. Does you voicing
your opinion mean someone (you ? someone else ?) is working on this, or soon
going to work on this ? I had a chat with Michael about fixing up his patch
to work all the way (it's currently a proof-of-concept-quick-hack that only
works for builtin types) which prompted me to study Python's internals a bit
closer. (I hope I dont sound too patronizing when I say I was impressed ;-)

I'm curious what should happen with index-assignment and slice-assignment:

x[y] += z
x[:y] += z

(Obviously this wont make sense for a lot of types, or will be too
un-obvious to include, but I can imagine matrix-types to happily add this.)

Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, y, z) ? Or
would x[y] += z always call x[y].__add_item_ab__() and x[:y] create a new
object, a slice of x, and call its __add_ab__() method ? Or would it try all
of them, or more, until it gets a good result ? Or am I running ahead of
things and should we wait for a working patch first ? :)

If I suddenly grow a deep understanding of Python's internals (not ruled
out, it's fairly obvious) and hack-up something that works before anyone
else, I'll be sure to mail ;)

oh-and-congratulations-to-Mrs.-van-Rossum-too-ly yr's,
-- 
Thomas Wouters <thomas at xs4all.net>

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



From gstein at lyra.org  Sun Jun  4 01:06:07 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 16:06:07 -0700 (PDT)
Subject: [Python-Dev] httplib
In-Reply-To: <Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>
Message-ID: <Pine.LNX.4.10.10006031605000.29036-100000@nebula.lyra.org>

On Sat, 3 Jun 2000, Greg Stein wrote:
> I found the problem. Sneaky...
> 
> sock.makefile() does a dup() on the file descriptor, then opens a FILE*
> with that. See it coming yet? ...
> 
> FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd
> file descriptor. When we went to grab another chunk on the *original*
> descriptor, we missed input [that is now sitting in the FILE* buffer].
> 
> Answer: change the .makefile() in getreply() to:
> 
>     file = self.sock.makefile('rb', 0)
> 
> This problem is going to affect the original httplib, too. IMO, we're
> about to replace the sucker, so no worries...

Oh... actually it won't affect the original since that doesn't pipeline
requests.

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




From gstein at lyra.org  Sun Jun  4 01:13:55 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 3 Jun 2000 16:13:55 -0700 (PDT)
Subject: [Python-Dev] more on httplib
Message-ID: <Pine.LNX.4.10.10006031606100.29036-100000@nebula.lyra.org>

I would like to propose a few changes to the (new) httplib:

*) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to
   provide backwards-compat for it

*) revamp the pipeline support:

   - record the "last response object" ... when a new getreply() is done,
     then we store the "last" into response.prior
   - reading of the "HTTP/1.1 <code> <msg>" line is deferred, and
     performed by the response object
   - the read of that line is lazy
   - if the response line is read *before* the "prior" response (if any) 
     is "closed", then an exception is raised: ResponseNotReady

*) address some of Moshe's concerns:

   - use class-based exceptions
   - clarify that HTTPConnection is designed for *blocking* sockets
   - conn.close() followed by conn.send() will reopen the socket. This
     could lead to programming errors. I'll add a class-based default flag
     to disable this behavior.
   - in request(), we check for errno==32 ... what to do on Windows?


I will implement these changes in small chunks so that each can be
reviewed in my CVS repository. The history is available at:

    http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/


Cheers,
-g

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





From mhammond at skippinet.com.au  Sun Jun  4 04:03:34 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 4 Jun 2000 12:03:34 +1000
Subject: [Python-Dev] What's New (first draft)
In-Reply-To: <20000602231550.A986@newcnri.cnri.reston.va.us>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEFCCMAA.mhammond@skippinet.com.au>

> emphasize the number of contributors to this release; does everyone think
> this is a good idea?  If I've missed your name, or credited you wrongly,
> please let me know.

OK - as you insist :-)

Bill Tutt and I could do with a credit for the new winreg module.

Thanks,

Mark.




From tim_one at email.msn.com  Sun Jun  4 06:09:02 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 4 Jun 2000 00:09:02 -0400
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.GSO.4.10.10006030900030.14749-100000@sundial>
Message-ID: <000a01bfcdda$9e876060$1d2d153f@tim>

[Moshe]
> How about having, in addition to the time-stamp, the size of the file?
> At least on UNIX, it comes for free with the same stat call.

+1 from me.  Note that, besides inter-machine clock skew, some filesystems
have a timestamp granularity too coarse to distinguish close-in-time writes.
For those (& related) reasons, the attentive Pythoneer will have noted that
all of the winning 1st-round Software Carpentry "make"-replacement designs
provide for alternatives to timestamps.  Tom Tromey's has the clearest
discussion of the problems with timestamps:

http://software-carpentry.codesourcery.com/entries/build/Tromey/Tromey.html

In my industrial experience, (timestamp, size) pairs have never failed in
practice.  However, "my industrial experience" has been entirely in projects
where source-control wrappers add a checkin comment block to every
checked-in file, and that alone made it exceedingly unlikely that any two
successive versions of a file would have the same size.

In Python I'm still (a little) worried about cases like

SOME_GLOBAL_CONFIG_OPTION = 0

where "0" gets replaced by "1" or "2" or ... there are lots of interesting
things you can do to Python programs without changing their size.  At
Dragon, checked-in Python files were also subject to the "checkin comment
block" rule, so no project under source control suffered from this.  I
suspect it burned people in their pre-source-controlled development
projects, though!  One group in particular had a project that involved acres
of machine-generated Python modules, and I know they suffered from coarse
timestamps on their flavor of Unix (so part of their "make" procedure was to
nuke all .pyc's on each build).

it's-easy-to-laugh-at-problems-you-don't-have<wink>-ly y'rs  - tim





From moshez at math.huji.ac.il  Sun Jun  4 06:59:31 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sun, 4 Jun 2000 07:59:31 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <000a01bfcdda$9e876060$1d2d153f@tim>
Message-ID: <Pine.GSO.4.10.10006040757010.23740-100000@sundial>

On Sun, 4 Jun 2000, Tim Peters wrote:

[Moshe]
> How about having, in addition to the time-stamp, the size of the file?
> At least on UNIX, it comes for free with the same stat call.

 
[Tim]
> +1 from me.
<even more reasons>

Now there is the big problem, that this will be changing the header size.
I thought that this would be a good time anyway, since 1.5.2 pycs aren't
compatible with 1.6, but changing the header size is a bigger thing.

so-this-waits-until-guido-comes-back-i-guess-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From bwarsaw at python.org  Sun Jun  4 22:51:30 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Sun, 4 Jun 2000 16:51:30 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <3938D60E.391AAF31@lemburg.com>
	<AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
Message-ID: <14650.49490.725648.798719@anthem.python.org>

>>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:

    JH> One of the problems I'm having is keeping track of which
    JH> patches are still outstanding.

SF has a patch manager but I haven't played with it much.  In fact, I
can't seem to find it for the Python project, but it's there in the
Mailman project.

-Barry



From gstein at lyra.org  Sun Jun  4 22:55:09 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 13:55:09 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14650.49490.725648.798719@anthem.python.org>
Message-ID: <Pine.LNX.4.10.10006041353020.29036-100000@nebula.lyra.org>

On Sun, 4 Jun 2000, Barry A. Warsaw wrote:
> >>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:
> 
>     JH> One of the problems I'm having is keeping track of which
>     JH> patches are still outstanding.
> 
> SF has a patch manager but I haven't played with it much.  In fact, I
> can't seem to find it for the Python project, but it's there in the
> Mailman project.

You can administratively turn those things on/off, I thought. You're an
admin, Barry, so you should be able to turn the thing on.

Cheers,
-g

p.s. and yah.. there are damn too many projects at SF that are just a
project name. no code, no description, all features enabled for no
purpose, etc... Newbie coders, me thinks. Python is Goodness because it
does disable the unused items.

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




From gstein at lyra.org  Mon Jun  5 01:30:08 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 16:30:08 -0700 (PDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total
 reference count in debug builds.)
Message-ID: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>

Given the New World Order, how does that impact the need for these release
statements and/or wet signatures?

Or a better way to put it, who "owns" Python now? Given a "who", then we
can ask that person/entity whether they want release statements.

Given that Python is now on SourceForge, and there are multiple people (at
CNRI and otherwise) that can directly make modifications, then the release
below is certainly a bit "off". For example, David Ascher has commit
privs, so at his "sole discretion, [he may] decide whether or not to
incorporiate this contribution..." :-)

Thoughts?

Cheers,
-g

p.s. IMO, I'd like to see Guido own the Copyright for all current and
future Python development

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

---------- Forwarded message ----------
Date: Mon, 5 Jun 2000 09:18:30 +1000
From: Mark Hammond <mhammond at skippinet.com.au>
To: patches at python.org
Subject: [Patches] New sys method to return total reference count in debug
    builds.

[... snip ...]

Release info:

I confirm that, to the best of my knowledge and belief, this contribution
is free of any claims of third parties under copyright, patent or other
rights or interests ("claims").  To the extent that I have any such claims,
I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide
license to reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part of the
Python software and its related documentation, or any derivative versions
thereof, at no cost to CNRI or its licensed users, and to authorize others
to do so.

I acknowledge that CNRI may, at its sole discretion, decide whether or not
to incorporate this contribution in the Python software and its related
documentation.  I further grant CNRI permission to use my name and other
identifying information provided to CNRI by me for use in connection with
the Python software and its related documentation.

Mark.


_______________________________________________
Patches mailing list
Patches at python.org
http://www.python.org/mailman/listinfo/patches




From bwarsaw at python.org  Mon Jun  5 05:09:36 2000
From: bwarsaw at python.org (bwarsaw at python.org)
Date: Sun, 4 Jun 2000 23:09:36 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <14650.49490.725648.798719@anthem.python.org>
	<Pine.LNX.4.10.10006041353020.29036-100000@nebula.lyra.org>
Message-ID: <14651.6640.709657.306682@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

    GS> You can administratively turn those things on/off, I
    GS> thought. You're an admin, Barry, so you should be able to turn
    GS> the thing on.

I'm happy to if people think it will help.  SF's patch management is a
durn site better than Python's is now <wink>.  I'd also consider
shutting off Jitterbug on python.org but I'm not sure how to (or if we
should) migrate the current bug set to SF.

-Barry



From gstein at lyra.org  Mon Jun  5 08:13:39 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 23:13:39 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.6640.709657.306682@anthem.python.org>
Message-ID: <Pine.LNX.4.10.10006042311500.29036-100000@nebula.lyra.org>

On Sun, 4 Jun 2000 bwarsaw at python.org wrote:
> >>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
> 
>     GS> You can administratively turn those things on/off, I
>     GS> thought. You're an admin, Barry, so you should be able to turn
>     GS> the thing on.
> 
> I'm happy to if people think it will help.  SF's patch management is a
> durn site better than Python's is now <wink>.  I'd also consider
> shutting off Jitterbug on python.org but I'm not sure how to (or if we
> should) migrate the current bug set to SF.

IMO, use the provided tools. The Patch Manager is more than we have now.
It also allows assignment, which can be nice :-)  (compared to the
arbitrary "who is taking care of this patch?" thing today)

The SF bug database certainly works, and it provides additional "locality"
for the code + bugs + patches.

Cheers,
-g

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




From jeremy at beopen.com  Mon Jun  5 06:43:45 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 00:43:45 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <3938D60E.391AAF31@lemburg.com>
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
	<3938D60E.391AAF31@lemburg.com>
Message-ID: <14651.12289.191631.704477@localhost.localdomain>

[Entry from AMK's 1.6 jobs list:]
> Conservative garbage collection of cycles (maybe -- I don't know what GvR
>         thinks about this)

I believe Guido would like to see a version of Neil's patches
integrated into Python 1.6, most likely turned off by default but with
a configure flag to enable.

I would like to check the patch in soon but I have had some trouble
with segfaults.  I ran a simple benchmark using the compiler code in
the nondist tree to compile itself.  I get a crash during a routine
collect pass, where it looks like the GC header info is getting
trashed.  I haven't had much time to track it any farther.

If anyone else is interested, I'd love to hear about successes using
the GC patch with other large programs.  I'd like to run at least
Gadfly and Grail successfully before committing the patch.

I wonder if "conservative" is the right word to describe the GC
approach?  I think conservative means that the garbage collector is
not told what is a pointer and what is not, so it must conservatively
assume that every bit pattern could represent a pointer.  The GC patch
is not conservative in this sense.  It does have a mechanism that is
"conservative" in a very broad sense, i.e. it does not attempt to
trace every reference, but depends on the ref count fields to account
for references held in untraced variables on the C stack.  I'm not
sure what the right terminology for this approach is.

I also worry that the performance impact of the GC patch is not at all
understood.  I don't know what informed the choice of heuristics for
deciding how often to collect and how to move objects between
generations.  (The current scheme has three generations.)  It would be
good to get a working patch in before the next alpha release and then
gather a lot of data to help make good choices about these parameters.

Jeremy

PS Even if Guido doesn't think the GC patch should go in, we've got a
golden opportunity.  I caught him in a state of newly-wedded bliss
this morning and convinced him to let me check in my non-optional
braces patch while he's on his honeymoon.  He's so happy he'll let us
get away with anything.

PPS I don't know if we should really carry on about personal matters
on a development list, but I hope no one minds if I indulge briefly:
Guido & Kim's wedding yesterday was beautiful and fun, held outside in
meadow looking out on hills and woods.  They are great couple and I'm
sure they'll be very happy.




From jeremy at beopen.com  Mon Jun  5 06:58:11 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 00:58:11 -0400 (EDT)
Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!)
In-Reply-To: <Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>
References: <Pine.LNX.4.10.10006020134050.17073-100000@nebula.lyra.org>
	<Pine.LNX.4.10.10006031549470.29036-100000@nebula.lyra.org>
Message-ID: <14651.13155.253651.575394@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

  GS> I found the problem. Sneaky...  sock.makefile() does a dup() on
  GS> the file descriptor, then opens a FILE* with that. See it coming
  GS> yet? ...

Bingo!  I was suspicious of all these dup'd file descriptors, but
missed the connection to a FILE* object.

  [In a previous message you wrote:]
  >> 
  >> Regarding the pipeline request thing. I think it would probably
  >> be best to just drop the whole "hold the previous response and
  >> wait for it to be closed" thing.
  [...]
  >> 
  >> Oh. Wait. Maybe that was it. You can't read the "next" response
  >> until the first one has been read. Well... no need to block
  >> putting new responses; we just need to create a way to "get the
  >> next reply" and/or "can I get the next reply yet?"
  >> 

Maybe I should clarify the concern I had here.  I think we're on the
same page, but I'm not sure.

The problem with pipelined requests is that the client must be sure to
read all of response I before it can call getreply to get response
I+1.  I imagine that it could add a lot of complexity to use code to
implement this requirement, e.g. when multiple threads are sharing a
single connection.  It would be good if the library could do something
reasonable about the multiplexing.  In the absence of making it just
work, the library could raise an error that makes clear what has gone
wrong -- that the client isn't using the interface properly.

Jeremy



From jeremy at beopen.com  Mon Jun  5 07:00:06 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 01:00:06 -0400 (EDT)
Subject: [Python-Dev] Re: Is it just Syntactic Sugar ?
In-Reply-To: <20000604005601.T469@xs4all.nl>
References: <k7lW4.96338$E85.1941352@news1.rdc1.md.home.com>
	<3929E47E.993727CF@roguewave.com>
	<3933F800.9CCE3B6D@cs.byu.edu>
	<20000530213957.E469@xs4all.nl>
	<mt4s7f7q62.fsf@astron.berkeley.edu>
	<m3u2ffydwy.fsf@atrus.jesus.cam.ac.uk>
	<mtog5n68ak.fsf@astron.berkeley.edu>
	<20000531090045.I469@xs4all.nl>
	<3935B383.469032AE@python.org>
	<20000604005601.T469@xs4all.nl>
Message-ID: <14651.13270.353056.246432@localhost.localdomain>

>>>>> "TW" == Thomas Wouters <thomas at xs4all.net> writes:

  TW> On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum
  TW> wrote:
  >> I know I shouldn't be posting in this thread, and I won't be
  >> there to read the responses, but here's what I thought would be
  >> cool.

  >> x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means
  >> "and becomes" (an old Algol-68 naming convention; we could pick
  >> something better later but this will do for the explanation).

  [...]

  TW> This was what I had in mind, and was trying to explain. Does you
  TW> voicing your opinion mean someone (you ? someone else ?) is
  TW> working on this, or soon going to work on this ? 

I don't believe anyone at PythonLabs is working on this now, certainly
not Guido or I.

Jeremy



From jeremy at beopen.com  Mon Jun  5 06:53:32 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 00:53:32 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>
References: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
	<Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>
Message-ID: <14651.12876.575925.701737@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

  GS> On Sat, 3 Jun 2000, Jeremy Hylton wrote:
  >> ...  Sorry for the excuses.  I think better tools would help a
  >> lot, but we'll have to get more people checkin privileges
  >> regardless.

  GS> There are several issues with expanded checkin privs:

  GS> 1) trust: will the person make sure it is Right And Proper to do
  GS> the checkin? (have they reviewed the code? is a a Good Change?
  GS> etc) The counter here is that we don't want people that will
  GS> simply take stuff arriving at patches@ and checking them in.

Many of the people who ultimately have checkin privileges should limit
themselves to their particular domains.  There are a bunch of modules
that are owned by other people, e.g. Eric's netrc module, your new
httplib, MAL for Unicode, etc.

We'll probably develop a second group of developers who have broader
privileges to make changes, but they'll know how they are.

Ultimately, I think I agree with Mark's suggestion that we be a little
more liberal with changes and risk backing out the occasional
changes.  (For some definition of "a little more" :-).

  GS> 2) more people reviewing changes on the -checkins mailing
  GS> list. Assuming that you want more than one pair of eyeballs
  GS> looking at patches/code, that more people with commit privs
  GS> increases the rate of commits, then you need more reviewers to
  GS> keep up (because the reviewers probably are not going to review
  GS> ALL checkins)

You're doing a great job so far.  We'll just have to get you to spend
more time on it <0.8 wink>.

  GS> 3) increasing dependence on -checkins means that patches MUST be
  GS> smaller chunks. they MUST be single-purpose patches. practically
  GS> nobody will review a 200k patch, or patches that fix N different
  GS> things at once. A small, focused patch is easily reviewed.

  GS>    For example: Trent has recently mailed a bunch of patches to
  GS> the patches list. This is Goodness: each one is focused and can
  GS> be individually reviewed. Since they are not a single, giant
  GS> blob, it also keeps them short and reviewable... each can have a
  GS> +1/-1 independent of the others.

I agree in principle, but there are times when it will make more sense
to commit a set of changes as one big patch.  The GC patches are going
to affect a bunch of files, but probably ought to be done as one big
commit. 

Jeremy



From jeremy at beopen.com  Mon Jun  5 07:03:46 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 01:03:46 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total
 reference count in debug builds.)
In-Reply-To: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
References: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
Message-ID: <14651.13490.858960.390030@localhost.localdomain>

Off the top of my head, I'd say that your questions aren't going to
get answered until Guido gets back and gets a chance to answer them.
In the interim, I think we should stick with the current approach.  In
the long run, of course, you won't need to grant CNRI permission to do
anything with a submission.

Jeremy



From nascheme at enme.ucalgary.ca  Mon Jun  5 08:35:00 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Mon, 5 Jun 2000 00:35:00 -0600
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.12289.191631.704477@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 12:43:45AM -0400
References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> <14651.12289.191631.704477@localhost.localdomain>
Message-ID: <20000605003500.B6169@acs.ucalgary.ca>

On Mon, Jun 05, 2000 at 12:43:45AM -0400, Jeremy Hylton wrote:
> [Entry from AMK's 1.6 jobs list:]
> > Conservative garbage collection of cycles (maybe -- I don't know what GvR
> >         thinks about this)
> 
> I believe Guido would like to see a version of Neil's patches
> integrated into Python 1.6, most likely turned off by default but with
> a configure flag to enable.

Okay, I was thinking he had passed it over for 1.6 since I didn't
hear any comments from him for a long time.

> I would like to check the patch in soon but I have had some trouble
> with segfaults.  I ran a simple benchmark using the compiler code in
> the nondist tree to compile itself.  I get a crash during a routine
> collect pass, where it looks like the GC header info is getting
> trashed.  I haven't had much time to track it any farther.

Yow.  I will try to see if I can reproduce this.  What platform?

> If anyone else is interested, I'd love to hear about successes using
> the GC patch with other large programs.  I'd like to run at least
> Gadfly and Grail successfully before committing the patch.

I've used it with Grail, Sketch, IDLE as well as some of my own
software.  I may have introduced that SEGV bug when porting the
patch to a newer version of the CVS sources.  I will check it
out.

> I also worry that the performance impact of the GC patch is not
> at all understood.

Me too.

> I don't know what informed the choice of heuristics for
> deciding how often to collect and how to move objects between
> generations. (The current scheme has three generations.) It
> would be good to get a working patch in before the next alpha
> release and then gather a lot of data to help make good choices
> about these parameters.

Getting good performance will be a matter of tuning how often the
collector runs.  I don't think there is any substitute for
running real programs and collecting data.  Programs that
allocate lots of objects will be most interesting.  It would
probably be a good idea to add more support for keeping
collection statistics.  Unfortunately my time is very limited
right now.

> PS Even if Guido doesn't think the GC patch should go in, we've got a
> golden opportunity.  I caught him in a state of newly-wedded bliss
> this morning and convinced him to let me check in my non-optional
> braces patch while he's on his honeymoon.  He's so happy he'll let us
> get away with anything.

I wonder if he will be scowling less at the conferences now that
he is hitched. :)

    Neil



From gstein at lyra.org  Mon Jun  5 08:42:35 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 4 Jun 2000 23:42:35 -0700 (PDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.12876.575925.701737@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.10006042329020.29036-100000@nebula.lyra.org>

On Mon, 5 Jun 2000, Jeremy Hylton wrote:
> >>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
>...
>   GS> 1) trust: will the person make sure it is Right And Proper to do
>   GS> the checkin? (have they reviewed the code? is a a Good Change?
>   GS> etc) The counter here is that we don't want people that will
>   GS> simply take stuff arriving at patches@ and checking them in.
> 
> Many of the people who ultimately have checkin privileges should limit
> themselves to their particular domains.  There are a bunch of modules
> that are owned by other people, e.g. Eric's netrc module, your new
> httplib, MAL for Unicode, etc.

Agreed. Each person with commit privs will definitely need to operate
under the premise of "<this> is the area that I'm allowed to commit
changes for." For example, I believe that Guido made it very clear, at
some point in the past, that *nobody* but Guido will have commit access to
the Parser/ area.

Note that when I say "commit access" here, this is the same as "areas that
I can commit for." In fact, it is really just an extension of the Basic
Python Principle, "we're all adults here, don't do what you know you
shouldn't be doing." :-)

>...
> Ultimately, I think I agree with Mark's suggestion that we be a little
> more liberal with changes and risk backing out the occasional
> changes.  (For some definition of "a little more" :-).

This only works if you have reasonably assurance of review via the
-checkins alias. Otherwise, you simply need to accept that instabilities
will creep in. (and that broader alpha/beta/etc cycles may be desirable)

In the Apache group, we have a very good set of eyeballs watching the
checkins. I'd say that each checkin is reviewed by two or three people in
detail. Invariably, there are several checkins each week that result in a
thread discussing: (a) you broke it, (b) why was it done that way, (c)
couldn't it be done this way, (d) this appears to be missing, (e) etc.

IMO, for that to happen several (or more!) times every week means that we
have a good set of eyeballs. Maybe it also means the committers just suck
lollipops, but I'd like to think otherwise :-)

>   GS> 2) more people reviewing changes on the -checkins mailing
>   GS> list. Assuming that you want more than one pair of eyeballs
>   GS> looking at patches/code, that more people with commit privs
>   GS> increases the rate of commits, then you need more reviewers to
>   GS> keep up (because the reviewers probably are not going to review
>   GS> ALL checkins)
> 
> You're doing a great job so far.  We'll just have to get you to spend
> more time on it <0.8 wink>.

hehe...

well, I just completed a big-ass wave of mod_dav work. In fact, I don't
know what else to do to the thing. I made a snapshot and am waiting for
feedback, if any, before declaring it 1.0. Maybe I'll add some comments to
the code :-)

Anyways... that's why I've been working on httplib. Free time! :-)

>   GS> 3) increasing dependence on -checkins means that patches MUST be
>   GS> smaller chunks. they MUST be single-purpose patches. practically
>   GS> nobody will review a 200k patch, or patches that fix N different
>   GS> things at once. A small, focused patch is easily reviewed.
> 
>   GS>    For example: Trent has recently mailed a bunch of patches to
>   GS> the patches list. This is Goodness: each one is focused and can
>   GS> be individually reviewed. Since they are not a single, giant
>   GS> blob, it also keeps them short and reviewable... each can have a
>   GS> +1/-1 independent of the others.
> 
> I agree in principle, but there are times when it will make more sense
> to commit a set of changes as one big patch.  The GC patches are going
> to affect a bunch of files, but probably ought to be done as one big
> commit. 

Actually, I will disagree here. I've reviewed the GC patch a couple times.
There are a number of changes in there that can/should be done separately
from the "real" GC patch.

For example, there were a number of changes to use PyMem_Allco() instead
of PyMEM_Alloc(). Or whatever. Point being, that they had *nothing* to do
with GC -- they could be checked in *independent* of the actual GC work.
The changes to the PyTypeObject declaration (adding tp_clean) can also be
done without doing the "real work".

After these "zero impact" changes are completed, then the GC patch will be
greatly reduced in size and complexity. It makes it much more reviewable.

The point being: even big patches can usually be broken down into layers.
One layer after another, adding "platform" functionality until you get to
the meat of the matter. The GC patch was a definite case of this.

Really huge patches are okay if they have a *seriously* narrow focus. For
example, Skip's patch to use PyArg_ParseTuple() with the ":method" stuff.
That was pretty brain-dead to review. The hardest part was that the
context-diff wasn't contextual enough to verify that the name in the
ParseTuple matched the method that it occurred in.
[ I found a case where they did not match. not easy... ]

Cheers,
-g

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




From pf at artcom-gmbh.de  Mon Jun  5 09:28:38 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Mon, 5 Jun 2000 09:28:38 +0200 (MEST)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <Pine.LNX.4.10.10006021430030.20995-100000@nebula.lyra.org> from Greg Stein at "Jun 2, 2000  2:32:52 pm"
Message-ID: <m12yrJO-000DifC@artcom0.artcom-gmbh.de>

Hi,

Greg Stein:
> He does have a point, but I think the wrong solution :-)
> 
> While the clock may be monotonically increasing on one system, it isn't
> always the case when things like NFS come into play.

That is a well known and common trap.  Don't use NFS for Software
development unless you've read and understood RFC 868. ;-)

BTW.: Last year someone posted a pure Python implementation of RFC 868
time server and clients to c.l.p.  This might be useful on those WinXX boxes.

> I recall a case back '95 when I was editing a .py over an NFS mount and
> running the code on the target machine. The clocks on the two boxes were
> off by about three seconds. I was going thru the edit/run/edit/run cycle
> so quickly, that at one point, I saved a .py file that was older than the
> associated .pyc file.
> 
> Needless to say, I was really confused that my recent edit didn't produce
> the desired result :-)

Sure. ;-)  But the same would have happenend, if you edited a .c source
file and if your target computer has C-compiler/linker, which is fast
enough to have a edit/compile/run cycle completed faster than the clock 
difference.  This is not uncommon today.

So the problem is not Python's fault and so I see no need to fix it there.
One thing could be added though: If Python 'stat's a .py file, which has
a time stamp in the future, it could issue a warning similar to that
displayed by 'make':
*** Warning: File `%s' has modification time in the future (%ld > %ld

Possibly this message could point the user to RFC 868 and the 'netdate' 
Unix command.  But that would be sugar on the cake.

Regards, Peter



From moshez at math.huji.ac.il  Mon Jun  5 12:21:32 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Mon, 5 Jun 2000 13:21:32 +0300 (IDT)
Subject: [Python-Dev] Suggestion: stopping to trust os mtimes
In-Reply-To: <m12yrJO-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.GSO.4.10.10006051318060.12591-100000@sundial>

On Mon, 5 Jun 2000, Peter Funk wrote:

> Greg Stein:
> > He does have a point, but I think the wrong solution :-)
> > 
> > While the clock may be monotonically increasing on one system, it isn't
> > always the case when things like NFS come into play.
> 
> That is a well known and common trap.  Don't use NFS for Software
> development unless you've read and understood RFC 868. ;-)

"Make"'s philosphy for basing the decision on which files need to be
remade on the timestapmps is not necessarily the best -- but the user can
replace mkae if it doesn't "do the right thing".

Since Python takes on some of Make's roles (regenrating files only if
those need to be regenerated), it is subject to the same problems. So it
is Python's fault, and that's where the problem should be fixed.

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From bwarsaw at python.org  Mon Jun  5 15:21:05 2000
From: bwarsaw at python.org (bwarsaw at python.org)
Date: Mon, 5 Jun 2000 09:21:05 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <14651.6640.709657.306682@anthem.python.org>
	<Pine.LNX.4.10.10006042311500.29036-100000@nebula.lyra.org>
Message-ID: <14651.43329.783797.949349@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

    GS> IMO, use the provided tools. The Patch Manager is more than we
    GS> have now.  It also allows assignment, which can be nice :-)
    GS> (compared to the arbitrary "who is taking care of this patch?"
    GS> thing today)

    GS> The SF bug database certainly works, and it provides
    GS> additional "locality" for the code + bugs + patches.

I've turned on the SF patch manager and bug database.

-Barry



From bwarsaw at python.org  Mon Jun  5 15:32:54 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:32:54 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
	<Pine.LNX.4.10.10006031337440.29036-100000@nebula.lyra.org>
	<14651.12876.575925.701737@localhost.localdomain>
Message-ID: <14651.44038.828370.123514@anthem.python.org>

>>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:

    JH> Many of the people who ultimately have checkin privileges
    JH> should limit themselves to their particular domains.  There
    JH> are a bunch of modules that are owned by other people,
    JH> e.g. Eric's netrc module, your new httplib, MAL for Unicode,
    JH> etc.

Right.  I think GregS was the one advocating a more Apache-like model,
where people have the ability to check into the whole tree, but
generally don't or risk the derision of their peers.  Python's big
enough for people to assert their expertise over various corners.

    JH> Ultimately, I think I agree with Mark's suggestion that we be
    JH> a little more liberal with changes and risk backing out the
    JH> occasional changes.  (For some definition of "a little more"
    JH> :-).

It all depends on the scope of the changes.  If it's fairly localized
to a single library module, then we don't worry as much.  More
important there will be the API design.  If it's a more sweeping
change like GC or Unicode, or a change in the language definition,
then there /has/ to be broader support.

For Big Changes, I really like the RFC idea someone suggested.  Gets
everything documented for newbies and posterity.  Has a shelf life,
etc.

-Barry



From bwarsaw at python.org  Mon Jun  5 15:36:28 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:36:28 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <14651.12876.575925.701737@localhost.localdomain>
	<Pine.LNX.4.10.10006042329020.29036-100000@nebula.lyra.org>
Message-ID: <14651.44252.78362.195436@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

    GS> In the Apache group, we have a very good set of eyeballs
    GS> watching the checkins. I'd say that each checkin is reviewed
    GS> by two or three people in detail. Invariably, there are
    GS> several checkins each week that result in a thread discussing:
    GS> (a) you broke it, (b) why was it done that way, (c) couldn't
    GS> it be done this way, (d) this appears to be missing, (e) etc.

Maybe we also need to expand on the test suite, do nightly builds, and
post the results.  Kind of the way Mozilla does it.  Well, Python
probably doesn't change so radically every night, but a more expanded
test suite with web based feedback would be cool.

-Barry



From bwarsaw at python.org  Mon Jun  5 15:38:20 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:38:20 -0400 (EDT)
Subject: [Python-Dev] Re: Is it just Syntactic Sugar ?
References: <k7lW4.96338$E85.1941352@news1.rdc1.md.home.com>
	<3929E47E.993727CF@roguewave.com>
	<3933F800.9CCE3B6D@cs.byu.edu>
	<20000530213957.E469@xs4all.nl>
	<mt4s7f7q62.fsf@astron.berkeley.edu>
	<m3u2ffydwy.fsf@atrus.jesus.cam.ac.uk>
	<mtog5n68ak.fsf@astron.berkeley.edu>
	<20000531090045.I469@xs4all.nl>
	<3935B383.469032AE@python.org>
	<20000604005601.T469@xs4all.nl>
	<14651.13270.353056.246432@localhost.localdomain>
Message-ID: <14651.44364.408119.422821@anthem.python.org>

>>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:

>>>>> "TW" == Thomas Wouters <thomas at xs4all.net> writes:

    TW> This was what I had in mind, and was trying to explain. Does
    TW> you voicing your opinion mean someone (you ? someone else ?)
    TW> is working on this, or soon going to work on this ?

    JH> I don't believe anyone at PythonLabs is working on this now,
    JH> certainly not Guido or I.

I'm not tracking this either.
-Barry



From bwarsaw at python.org  Mon Jun  5 15:41:39 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 09:41:39 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total
 reference count in debug builds.)
References: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
Message-ID: <14651.44563.556790.469651@anthem.python.org>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

    GS> Given the New World Order, how does that impact the need for
    GS> these release statements and/or wet signatures?

    GS> Or a better way to put it, who "owns" Python now? Given a
    GS> "who", then we can ask that person/entity whether they want
    GS> release statements.

    GS> Given that Python is now on SourceForge, and there are
    GS> multiple people (at CNRI and otherwise) that can directly make
    GS> modifications, then the release below is certainly a bit
    GS> "off". For example, David Ascher has commit privs, so at his
    GS> "sole discretion, [he may] decide whether or not to
    GS> incorporiate this contribution..." :-)

I talked to Guido briefly about this.  Since 1.6 is the last "CNRI
release", he wants to continue along the current path for the time
being.  I'm sure he'll be just as happy to chuck all this crap as
Greg, and we probably will for 1.7.

-Barry



From fdrake at beopen.com  Mon Jun  5 18:40:26 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 5 Jun 2000 12:40:26 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14648.35974.486959.379543@anthem.python.org>
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
	<14648.35974.486959.379543@anthem.python.org>
Message-ID: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com>

Barry A. Warsaw writes:
 > Did we ever decide on building in thread support by default?  I'd
 > really like to see threads enabled by default in 1.6 and I /think/
 > it'll just take some autoconf hacking, which I'm willing to do.  Are
 > there any objections to building in threads support by default if
 > autoconf detects threads?

  test_fork1 fails on Linux with threads on SMP machines.  (It's
irrelevant without threads.)  This is a hard failure -- the process
can either SEGV or hang forever.
  Is this a showstopper?  SMP boxes are becoming increasingly common
both as servers and workstations.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From bwarsaw at python.org  Mon Jun  5 18:55:49 2000
From: bwarsaw at python.org (bwarsaw at python.org)
Date: Mon, 5 Jun 2000 12:55:49 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <20000602232521.B986@newcnri.cnri.reston.va.us>
	<14648.35974.486959.379543@anthem.python.org>
	<14651.55290.728256.183107@cj42289-a.reston1.va.home.com>
Message-ID: <14651.56213.661929.481476@anthem.python.org>

>>>>> "Fred" == Fred L Drake, Jr <fdrake at beopen.com> writes:

    Fred>   test_fork1 fails on Linux with threads on SMP machines.
    Fred> (It's irrelevant without threads.)  This is a hard failure
    Fred> -- the process can either SEGV or hang forever.  Is this a
    Fred> showstopper?

I would think so, regardless of whether threads are built-in by
default or not.



From fdrake at beopen.com  Mon Jun  5 19:59:31 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 5 Jun 2000 13:59:31 -0400 (EDT)
Subject: [Python-Dev] What's New (first draft)
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBIEFCCMAA.mhammond@skippinet.com.au>
References: <20000602231550.A986@newcnri.cnri.reston.va.us>
	<ECEPKNMJLHAPFFJHDOJBIEFCCMAA.mhammond@skippinet.com.au>
Message-ID: <14651.60035.502321.510452@cj42289-a.reston1.va.home.com>

Mark Hammond writes:
 > Bill Tutt and I could do with a credit for the new winreg module.

  The documentation for winreg could stand to be written as well --
care to extract the docstrings, or is that in my court?  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From DavidA at ActiveState.com  Mon Jun  5 21:26:13 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 5 Jun 2000 12:26:13 -0700
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJCEIKCGAA.DavidA@ActiveState.com>

>   test_fork1 fails on Linux with threads on SMP machines.  (It's
> irrelevant without threads.)  This is a hard failure -- the process
> can either SEGV or hang forever.
>   Is this a showstopper?  SMP boxes are becoming increasingly common
> both as servers and workstations.

Why does the test fail?  I'd hate to see the thousands (nay, hundreds of
thousands) of users complain that foo isn't working just because the test
for a rarely used feature on a rare platform is broken.

--david




From nascheme at enme.ucalgary.ca  Mon Jun  5 23:03:13 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Mon, 5 Jun 2000 15:03:13 -0600
Subject: [Python-Dev] Re: Revised 1.6 jobs list
Message-ID: <20000605150313.A15917@acs.ucalgary.ca>

[David Ascher]
>> test_fork1 fails on Linux with threads on SMP machines. (It's
>> irrelevant without threads.) This is a hard failure -- the
>> process can either SEGV or hang forever. Is this a showstopper?
>> SMP boxes are becoming increasingly common both as servers and
>> workstations.
>
> Why does the test fail? I'd hate to see the thousands (nay,
> hundreds of thousands) of users complain that foo isn't working
> just because the test for a rarely used feature on a rare
> platform is broken.

Threads and fork() don't seem to mix on Linux.  Even on a
UP machine things seem strange:

    http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=613477888&fmt=text

I tried to reproduce the problem with a C program but could not.
When things hang the forking thread is stuck in wait4() while the
child process is suspended:

    #0  0x4027d9ba in sigsuspend () from /lib/libc.so.6
    #1  0x40232c77 in __pthread_wait_for_restart_signal ()
       from /lib/libpthread.so.0
    #2  0x4023406e in __pthread_lock () from /lib/libpthread.so.0
    #3  0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0
    #4  0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at
    thread_pthread.h:339
    #5  0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64,
    locals=0x0, 
        args=0x81be278, argcount=0, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, 
        owner=0x0) at ceval.c:630
    #6  0x805ac19 in call_function (func=0x81ebb2c, arg=0x81be26c,
    kw=0x0)
        at ceval.c:2552
    #7  0x805a5a4 in PyEval_CallObjectWithKeywords (func=0x81ebb2c,
    arg=0x81be26c, 
        kw=0x0) at ceval.c:2390
    #8  0x80b2c7b in t_bootstrap (boot_raw=0x81ebb50) at
    ./threadmodule.c:224
    #9  0x40230c8f in pthread_start_thread () from
    /lib/libpthread.so.0

I don't know if this is a LinuxThread problem or a Python
problem.

    Neil

-- 
The internet: Learn what you know.  Share what you don't.



From DavidA at ActiveState.com  Mon Jun  5 23:23:11 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 5 Jun 2000 14:23:11 -0700
Subject: [Python-Dev] RE: Revised 1.6 jobs list
In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca>
Message-ID: <PLEJJNOHDIGGLDPOGPJJKEJACGAA.DavidA@ActiveState.com>

> Threads and fork() don't seem to mix on Linux.  Even on a
> UP machine things seem strange:

I believe it.  My general point however is that even if the problem can't be
fixed because Linux is broken in some way, the test suite should be fixed
even if it means to ignore failures of test_fork1 if the system was
configured --with-thread.

--david




From mhammond at skippinet.com.au  Tue Jun  6 01:47:44 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 6 Jun 2000 09:47:44 +1000
Subject: [Python-Dev] Re: Revised 1.6 jobs list
In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEHJCMAA.mhammond@skippinet.com.au>

> I tried to reproduce the problem with a C program but could not.
> When things hang the forking thread is stuck in wait4() while the
> child process is suspended:

This looks very suspect.

>
>     #0  0x4027d9ba in sigsuspend () from /lib/libc.so.6
>     #1  0x40232c77 in __pthread_wait_for_restart_signal ()
>        from /lib/libpthread.so.0
>     #2  0x4023406e in __pthread_lock () from /lib/libpthread.so.0
>     #3  0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0
>     #4  0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at
>     thread_pthread.h:339
>     #5  0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64,

And very much like the Python thread-state is not being managed correctly
with fork.  From my understanding of fork (which is small), and of the
Python thread-state management, this doesnt surprise me.

Given the stack trace, it appears that Python is doing its periodic
thread-release as part of running around the main loop.

In the process of _releasing_ the thread-lock, it needs to _acquire_ a
mutex.  I dont know the Python threading on pthreads at all - would this be
correct (it would seem likely that such an implementation would be done).

But in the process of acquiring that mutex, we call

__pthread_wait_for_restart_signal()

Is it possible that is is something as simple as thread-idents changing
underneath Python when using fork?  It seems to me that the thread thinks
it is either new, or stale?

Just my 2c worth - and given my knowledge of Linux and pthreads, plus the
state of our dollar at the moment, it has better be AUD $0.02 :-)

Mark.





From trentm at activestate.com  Tue Jun  6 02:14:03 2000
From: trentm at activestate.com (Trent Mick)
Date: Mon, 5 Jun 2000 17:14:03 -0700
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer?
In-Reply-To: <Pine.GSO.4.10.10006030833470.14749-100000@sundial>
References: <20000602111417.A17233@activestate.com> <Pine.GSO.4.10.10006030833470.14749-100000@sundial>
Message-ID: <20000605171403.A21808@activestate.com>

On Sat, Jun 03, 2000 at 10:56:15AM +0300, Moshe Zadka wrote:
> On Fri, 2 Jun 2000, Trent Mick wrote:
> 
> > 3. - change PyMarshal_WriteLongToFile to raise an exception if the long
> > 	 overflows a 32-bit range
> 
> +1 on that, finally non-portable integers will cause an exception.
> 

Okay, I have to reiterate and ask again because I have the suspicion that I
may be missing the point and you all may not realize that. Stop me when I go
astray:

- the PyMarshal interface is used for all the .pyc content writing
- PyMarshal_WriteLongToFile is only used for writing the magic number and the
  time stamp
- the rest of the .pyc is written via PyMarshal_WriteObjectToFile


- PyMarshal_WriteLongToFile will currently silently truncate a 64-bit long to
  32-bits
- PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will
  *NOT* truncate the 64-bit integer but will write the whole thing

- On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr
  when a 64-bit integral value is read and the current platform is 32-bit.


The question is: Do we want PyMarshal_WriteLongToFile *AND*
PyMarshal_WriteObjectToFile to raise an exception when a long value overflows
32-bits? Up til now I was only proposing the former.


Trent

-- 
Trent Mick
trentm at activestate.com



From esr at thyrsus.com  Tue Jun  6 03:02:31 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 5 Jun 2000 21:02:31 -0400
Subject: [Python-Dev] ascii.py
Message-ID: <20000605210231.A25895@thyrsus.com>

Latest version.  Adds isctrl() and ismeta() functions (because I use them...)

Um.  What's the checkin procedure for library modules?  And do I have
permissions to do it?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"Guard with jealous attention the public liberty.  Suspect every one
who approaches that jewel.  Unfortunately, nothing will preserve it
but downright force.  Whenever you give up that force, you are
inevitably ruined."
	-- Patrick Henry, speech of June 5 1788
-------------- next part --------------
#
# ascii.py -- constants and memembership tests for ASCII characters
#

NUL	= 0x00	# ^@
SOH	= 0x01	# ^A
STX	= 0x02	# ^B
ETX	= 0x03	# ^C
EOT	= 0x04	# ^D
ENQ	= 0x05	# ^E
ACK	= 0x06	# ^F
BEL	= 0x07	# ^G
BS	= 0x08	# ^H
TAB	= 0x09	# ^I
HT	= 0x09	# ^I
LF	= 0x0a	# ^J
NL	= 0x0a	# ^J
VT	= 0x0b	# ^K
FF	= 0x0c	# ^L
CR	= 0x0d	# ^M
SO	= 0x0e	# ^N
SI	= 0x0f	# ^O
DLE	= 0x10	# ^P
DC1	= 0x11	# ^Q
DC2	= 0x12	# ^R
DC3	= 0x13	# ^S
DC4	= 0x14	# ^T
NAK	= 0x15	# ^U
SYN	= 0x16	# ^V
ETB	= 0x17	# ^W
CAN	= 0x18	# ^X
EM	= 0x19	# ^Y
SUB	= 0x1a	# ^Z
ESC	= 0x1b	# ^[
FS	= 0x1c	# ^\
GS	= 0x1d	# ^]
RS	= 0x1e	# ^^
US	= 0x1f	# ^_
SP	= 0x20	# space
DEL	= 0x7f	# delete

controlnames = [
"NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL",
"BS",  "HT",  "LF",  "VT",  "FF",  "CR",  "SO",  "SI",
"DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB",
"CAN", "EM",  "SUB", "ESC", "FS",  "GS",  "RS",  "US",
"SP"
]

def _ctoi(c):
    if type(c) == type(""):
        return ord(c)
    else:
        return c

def isalnum(c): return isalpha(c) or isdigit(c)
def isalpha(c): return isupper(c) or islower(c)
def isascii(c): return _ctoi(c) <= 127		# ?
def isblank(c): return _ctoi(c) in (8,32)
def iscntrl(c): return _ctoi(c) <= 31
def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57
def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126
def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122
def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126
def ispunct(c): return _ctoi(c) != 32 and not isalnum(c)
def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11)
def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90
def isxdigit(c): return isdigit(c) or \
    (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102)
def isctrl(c): return _ctoi(c) < 32
def ismeta(c): return _ctoi(c) > 127

def ascii(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x7f)
    else:
        return _ctoi(c) & 0x7f

def ctrl(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x1f)
    else:
        return _ctoi(c) & 0x1f

def alt(c):
    if type(c) == type(""):
        return chr(_ctoi(c) | 0x80)
    else:
        return _ctoi(c) | 0x80

def unctrl(c):
    bits = _ctoi(c)
    if bits == 0x7f:
        rep = "^?"
    elif bits & 0x20:
        rep = chr((bits & 0x7f) | 0x20)
    else:
        rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20)
    if bits & 0x80:
        return "!" + rep
    return rep

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libascii.tex
Type: application/x-tex
Size: 4408 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000605/22747858/attachment-0001.bin>

From gstein at lyra.org  Tue Jun  6 03:10:17 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 5 Jun 2000 18:10:17 -0700 (PDT)
Subject: [Python-Dev] ascii.py
In-Reply-To: <20000605210231.A25895@thyrsus.com>
Message-ID: <Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>

On Mon, 5 Jun 2000, Eric S. Raymond wrote:
> Latest version.  Adds isctrl() and ismeta() functions (because I use them...)
> 
> Um.  What's the checkin procedure for library modules?

Guido has to give his blessing -- that he finds this useful and
appropriate for the Python library. He does that using his own criteria
and feedback from people here.

For example, I'm "+0" on it. (meaning that it seems okay, but I can also
live without it)

The actual mechanics are outlined at SourceForge:

  http://sourceforge.net/cvs/?group_id=5470


> And do I have permissions to do it?

Nope.

There are ten people with checkin privs:
  http://sourceforge.net/project/memberlist.php?group_id=5470

Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They use
<whatever> policy to determine whether a given person should become a SF
project member. That policy is probably just a gut feeling rather than
concrete rules, so I can't say "X, Y, and Z." I also don't know what kinds
of policies that they are asserting on people with privs.

Cheers,
-g

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




From jeremy at beopen.com  Tue Jun  6 03:23:40 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 21:23:40 -0400 (EDT)
Subject: [Python-Dev] ascii.py
In-Reply-To: <Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>
References: <20000605210231.A25895@thyrsus.com>
	<Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>
Message-ID: <14652.21148.139774.192634@localhost.localdomain>

Greg seems to understand this process better than the admins -- or at
least he can explain it quickly and clearly :-).  I apologize for the
rather confused state of affairs.  We'll clean up the process and
document it soon.

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
  GS> On Mon, 5 Jun 2000, Eric S. Raymond wrote:
  >> Latest version.  Adds isctrl() and ismeta() functions (because I
  >> use them...)
  >> 
  >> Um.  What's the checkin procedure for library modules?

  GS> Guido has to give his blessing -- that he finds this useful and
  GS> appropriate for the Python library. He does that using his own
  GS> criteria and feedback from people here.

I think I can safely speak for the admins when I say that we're not
sure what the process is other than securing Guido's blessing.  We
need to work out a clearer policy, but that will have to wait until
Guido gets back from his honeymoon.  Any new checkins we are making
are limited for the most part to modules we've already gotten his
blessing for.

There won't be another alpha release until he returns, so it's not
like we have to worry about getting new code in before a code freeze.

  GS> For example, I'm "+0" on it. (meaning that it seems okay, but I
  GS> can also live without it)

I'm in the same boat.  

  GS> There are ten people with checkin privs:
  GS> http://sourceforge.net/project/memberlist.php?group_id=5470

  GS> Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They
  GS> use <whatever> policy to determine whether a given person should
  GS> become a SF project member. That policy is probably just a gut
  GS> feeling rather than concrete rules, so I can't say "X, Y, and
  GS> Z." I also don't know what kinds of policies that they are
  GS> asserting on people with privs.

Another policy that needs to be defined.  "<whatever>" is surprisingly
close to what we actually have written down in our policies and
procedures manual.  I expect we will arrive at a policy where people
own pieces of the library and are free to maintain it.  Guido will
probably retain control over what modules come and go.

-- Jeremy Hylton <http://www.python.org/~jeremy/>




From esr at thyrsus.com  Tue Jun  6 03:33:24 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 5 Jun 2000 21:33:24 -0400
Subject: [Python-Dev] ascii.py
In-Reply-To: <14652.21148.139774.192634@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 09:23:40PM -0400
References: <20000605210231.A25895@thyrsus.com> <Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org> <14652.21148.139774.192634@localhost.localdomain>
Message-ID: <20000605213324.A26055@thyrsus.com>

Jeremy Hylton <jeremy at beopen.com>:
> Another policy that needs to be defined.  "<whatever>" is surprisingly
> close to what we actually have written down in our policies and
> procedures manual.  I expect we will arrive at a policy where people
> own pieces of the library and are free to maintain it.  Guido will
> probably retain control over what modules come and go.

Pretty much as I expected.  OK.  Let us know when things settle out
a little.  
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Before a standing army can rule, the people must be disarmed, as they
are in almost every kingdom in Europe. The supreme power in America
cannot enforce unjust laws by the sword, because the people are armed,
and constitute a force superior to any band of regular troops.
	-- Noah Webster



From tim_one at email.msn.com  Tue Jun  6 04:09:22 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 5 Jun 2000 22:09:22 -0400
Subject: Augmented assignment (was RE: [Python-Dev] Re: Is it just Syntactic Sugar ?)
In-Reply-To: <20000604005601.T469@xs4all.nl>
Message-ID: <001601bfcf5c$3bcb8e00$0ca0143f@tim>

[posted & mailed]

[Thomas Wouters, asking about Guido's sketch]
> This was what I had in mind, and was trying to explain. Does you
> voicing your opinion mean someone (you ? someone else ?) is working
> on this, or soon going to work on this ?

It's the same scheme he sketched the last time he was provoked into writing
about this <wink>, and that was at least a year ago.

> ...
> I'm curious what should happen with index-assignment and
> slice-assignment:

Nothing special!  You're reading far too much into Guido's sketch -- it
doesn't have all these convolutions.  Try reading his msg again, but this
time thinking like him too <wink>.

> x[y] += z

temp1 = x  # perhaps the first three are permuted, though
temp2 = y
temp3 = z
temp1[temp2] = temp1[temp2].__add_ab__(temp3)

And, yes, indexing is done twice (although "x" and "y" are evaluated only
once each).

> x[:y] += z

temp1 = x
temp2 = y
temp3 = z
temp1[:temp2] = temp1[:temp2].__add_ab__(temp3)

Similarly slicing is done twice.

> (Obviously this wont make sense for a lot of types, or will be too
> un-obvious to include, but I can imagine matrix-types to happily
> add this.)

Every type is free to implement __add_ab__ or not, in whatever way it likes.
But Python can't tell at compile-time which types do and don't implement it,
so chances are great that doing

   x += y

for x of a type that does not implement __add_ab__ will raise a runtime
AttributeError.

> Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0,
> y, z) ?

No.  *All* instances of "+=" are mapped straightforwardly to __add_ab__.
Context is irrelevent; indexing and slicing are not special cases (except to
the extent that they are already ...).

> Or would x[y] += z always call x[y].__add_item_ab__()

No.

> and x[:y] create a new object, a slice of x

What x[:y] means is entirely up to the type of x, and has no connection to
augmented assignment (except in that the author of the type may design both
to work smoothly together).

> and call its __add_ab__() method ?

__add_ab__ would be invoked on whatever x[:y] returns; whether that's "a new
object" or not is x.__get_slice__'s choice to make.

> Or would it try all of them, or more, until it gets a good result ?

No.  It works or it doesn't.

> Or am I running ahead of things and should we wait for a working
> patch first ? :)

No, you're running a few years behind things <wink>, and imagining
complications Guido would never sign up for.

and-now-the-spirits-must-rest-ly y'rs  - tim





From bwarsaw at python.org  Tue Jun  6 04:27:42 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 22:27:42 -0400 (EDT)
Subject: [Python-Dev] ascii.py
References: <20000605210231.A25895@thyrsus.com>
	<Pine.LNX.4.10.10006051804050.14292-100000@nebula.lyra.org>
	<14652.21148.139774.192634@localhost.localdomain>
Message-ID: <14652.24990.563016.976820@anthem.python.org>

>>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:

    JH> I think I can safely speak for the admins when I say that
    JH> we're not sure what the process is other than securing Guido's
    JH> blessing.  We need to work out a clearer policy, but that will
    JH> have to wait until Guido gets back from his honeymoon.  Any
    JH> new checkins we are making are limited for the most part to
    JH> modules we've already gotten his blessing for.

My suggestion would be to upload to the SourceForge patch manager, any
patches or code you care about that you don't want us to lose track
of.  Things get buried in my inbox pretty easily, but at least with
the patch manager, we've got a record of it, and can eventually assign
a developer to tracking it.

-Barry



From trentm at activestate.com  Tue Jun  6 04:52:44 2000
From: trentm at activestate.com (Trent Mick)
Date: Mon, 5 Jun 2000 19:52:44 -0700
Subject: [Python-Dev] about patches on SourceForge
Message-ID: <20000605195244.A25437@activestate.com>

I just put up one my patches from this past week on SOurceForge. Question:
WWould you all prefer to have the "raw patch" just include the actually
patch/diff and for the first comment to be the patch description (and legal
stuff?) or would you prefer for the patch description and legal stuff to be
part of the "raw patch".

I am inclined to think that the former would be preferable. Is there some
"apply patch" button in SourceForge that would require the "raw patch" to
actually be raw?

Go check it out and you will know what I am talking about.

http://sourceforge.net/patch/?func=browse&group_id=5470&set=open


When I get an good opinion from some of you I will send up my other patches.




Trent

-- 
Trent Mick
trentm at activestate.com



From gstein at lyra.org  Tue Jun  6 05:32:27 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 5 Jun 2000 20:32:27 -0700 (PDT)
Subject: [Python-Dev] Re: httplib
In-Reply-To: <14651.13155.253651.575394@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.10006052025390.14292-100000@nebula.lyra.org>

On Mon, 5 Jun 2000, Jeremy Hylton wrote:
> >>>>> "GS" == Greg Stein <gstein at lyra.org> writes:
>...
>   >> Oh. Wait. Maybe that was it. You can't read the "next" response
>   >> until the first one has been read. Well... no need to block
>   >> putting new responses; we just need to create a way to "get the
>   >> next reply" and/or "can I get the next reply yet?"
> 
> Maybe I should clarify the concern I had here.  I think we're on the
> same page, but I'm not sure.
> 
> The problem with pipelined requests is that the client must be sure to
> read all of response I before it can call getreply to get response
> I+1.

Actually, you can issue a getreply() after you've read the prior
response's headers, but before you completely read its body. Once you have
the header, then you know whether the connection will remain open or not.
Assuming it *will* remain open, then you can go ahead and do a
request/reply sequence. If the connection is going to close, then you have
to fail at request time.

> I imagine that it could add a lot of complexity to use code to
> implement this requirement, e.g. when multiple threads are sharing a
> single connection.  It would be good if the library could do something
> reasonable about the multiplexing.  In the absence of making it just
> work, the library could raise an error that makes clear what has gone
> wrong -- that the client isn't using the interface properly.

I'm working through this stuff right now. It is a bit tricky to get it
right *and* have it clear. I'm concentrating on the latter as much as
possible.

At the moment, HTTPResponse instances can be created without problems. I'm
locating the "can you issue a request [and get a response]" logic in the
connection object itself.

Another detail that I'm trying to work through is where the connection is
allowed to get the HTTPResponse to read the HTTP header. Reading off the
network could block, so we need to be a bit more careful about what
methods can block (if any).

In any case, the current httplib (at www.lyra.org/greg/python/) has got
just about everything. The next checkin will deal with this pipelining
issue.


QUESTION #2: I *really* want to get rid of the HTTPS() class. It is
introducing excessive complexity, with the only purpose being
compatibility against the post-1.5.2 CVS.

Anyone? Thoughts on removal?


Cheers,
-g

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




From mhammond at skippinet.com.au  Tue Jun  6 05:43:15 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 6 Jun 2000 13:43:15 +1000
Subject: [Python-Dev] about patches on SourceForge
In-Reply-To: <20000605195244.A25437@activestate.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au>

> When I get an good opinion from some of you I will send up my
> other patches.

How do you qualify a "good" opinion?  One that matches yours? <wink>

This is all too hard until Guido gets back.  But personally I believe the
raw patch should be just the CVS diff output, and the comments should
reflect all other text, including the release notice while it is still
necessary.

I hope my opinion is good enough :-)

Mark.




From jeremy at beopen.com  Tue Jun  6 05:46:01 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 5 Jun 2000 23:46:01 -0400 (EDT)
Subject: [Python-Dev] Re: httplib
In-Reply-To: <Pine.LNX.4.10.10006052025390.14292-100000@nebula.lyra.org>
References: <14651.13155.253651.575394@localhost.localdomain>
	<Pine.LNX.4.10.10006052025390.14292-100000@nebula.lyra.org>
Message-ID: <14652.29689.663218.777234@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

  GS> QUESTION #2: I *really* want to get rid of the HTTPS() class. It
  GS> is introducing excessive complexity, with the only purpose being
  GS> compatibility against the post-1.5.2 CVS.

  GS> Anyone? Thoughts on removal?

I've got two answers.  I don't particularly like the old-style HTTP
interface, so I'm happy to see it replaced with a better one.  I say
who cares about HTTPS. 

On the other hand, there is a lot of existing code that uses the old
interface.  It would be good if that code could be modified to use the
new SSL interface without having to also re-write the code to use the
new http interface.  Perhaps we should keep it to provide a future
upgrade path for all the legacy code.  

I could probably be convinced that the amount of effort to change from
the old interface to the new interface is fairly small.  If you're
going to make one change to the code anyway, might as well start using
the modern interface, too.

Is there anyone who actually has http code to maintain that has an
opinion? 

Jeremy



From fdrake at beopen.com  Tue Jun  6 05:45:54 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 5 Jun 2000 23:45:54 -0400 (EDT)
Subject: [Python-Dev] about patches on SourceForge
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au>
References: <20000605195244.A25437@activestate.com>
	<ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au>
Message-ID: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com>

Mark Hammond writes:
 > This is all too hard until Guido gets back.  But personally I believe the
 > raw patch should be just the CVS diff output, and the comments should
 > reflect all other text, including the release notice while it is still
 > necessary.

  Sounds good to me.  Let's do it this way until there's a god reason
to do it differently.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From pf at artcom-gmbh.de  Tue Jun  6 11:05:58 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 6 Jun 2000 11:05:58 +0200 (MEST)
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer?
In-Reply-To: <20000605171403.A21808@activestate.com> from Trent Mick at "Jun 5, 2000  5:14: 3 pm"
Message-ID: <m12zFJ8-000DifC@artcom0.artcom-gmbh.de>

Hi,

[Trent Mick]:
[...]
> - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will
>   *NOT* truncate the 64-bit integer but will write the whole thing
> 
> - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr
>   when a 64-bit integral value is read and the current platform is 32-bit.
[...]
> The question is: Do we want PyMarshal_WriteLongToFile *AND*
> PyMarshal_WriteObjectToFile to raise an exception when a long value overflows
> 32-bits? Up til now I was only proposing the former.

Yes.  This should at least be the default behaviour of Python.

The current behaviour would otherwise cause great damage in the
following scenario, where an innocent software developer working on
a 64-Bit system trusts on the cross platform portability of Pythons
bytecode files and unintentional uses a huge integer literal.

If some people really don't care about portability, there could be 
switch/option/pragma/whatever to disable this behaviour.

IMO the portability of Python bytecode files is a *very* valuable property,
which we shouldn't give up on.

Regards, Peter



From gstein at lyra.org  Tue Jun  6 11:58:44 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 6 Jun 2000 02:58:44 -0700 (PDT)
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit
 integer?
In-Reply-To: <m12zFJ8-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <Pine.LNX.4.10.10006060257010.14292-100000@nebula.lyra.org>

On Tue, 6 Jun 2000, Peter Funk wrote:
> [Trent Mick]:
> [...]
> > - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will
> >   *NOT* truncate the 64-bit integer but will write the whole thing
> > 
> > - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr
> >   when a 64-bit integral value is read and the current platform is 32-bit.
> [...]
> > The question is: Do we want PyMarshal_WriteLongToFile *AND*
> > PyMarshal_WriteObjectToFile to raise an exception when a long value overflows
> > 32-bits? Up til now I was only proposing the former.
> 
> Yes.  This should at least be the default behaviour of Python.
> 
> The current behaviour would otherwise cause great damage in the
> following scenario, where an innocent software developer working on
> a 64-Bit system trusts on the cross platform portability of Pythons
> bytecode files and unintentional uses a huge integer literal.
> 
> If some people really don't care about portability, there could be 
> switch/option/pragma/whatever to disable this behaviour.
> 
> IMO the portability of Python bytecode files is a *very* valuable property,
> which we shouldn't give up on.

It isn't only bytecodes. As I mentioned before, marshal byte streams are
specified as portable. Therefore, they are used all the time for passing
over the network, for persistence mechanisms, etc.

Having a marshal stream that is *not* cross-platform is just plain busted.

So... you can silently truncate to 32-bits or you can raise an exception.
You cannot, however, marshal a 64-bit value when the definition of an
"marshal integer" is only 32.

Cheers,
-g

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




From gvwilson at nevex.com  Tue Jun  6 16:40:25 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 6 Jun 2000 10:40:25 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
Message-ID: <Pine.LNX.4.10.10006061035250.29478-100000@akbar.nevex.com>

Hi, everyone.  We're a month away from final submissions in the Software
Carpentry design competition, which means we're two months away from
announcing winners and starting implementation effort, and we're wondering
whether there are generally-accepted coding standards, naming conventions,
or other guidelines that we should adopt.  If so, URLs would be welcome...

Also, it appears that there are two implementations of the xUnit testing
framework in Python:

Steve Purcell: http://sourceforge.net/project/?group_id=3912
Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip

We'd be grateful for comments on either.

Thanks,
Greg Wilson
Software Carpentry Project Coordinator





From klm at digicool.com  Tue Jun  6 18:16:58 2000
From: klm at digicool.com (Ken Manheimer)
Date: Tue, 6 Jun 2000 12:16:58 -0400 (EDT)
Subject: [Python-Dev] Guido and Kim married
Message-ID: <14653.9210.757666.324583@korak.digicool.com>

Guido van Rossum and Kim Knapp were married Saturday afternoon on the
lawn of a graceful southern estate, Claymont Court, in West Virginia,
USA.  The weather was *stunningly* fine - a great boon, considering
the rain the night before (a torrential downpour in nearby DC) - and
the couple left for their honeymoon sunday.  Hooray!

The crowd consisted of i would guess 70 to 100 people, a mixture of
hollanders (including several van rossum relatives - hiya Just!),
knapps, pythoners, contact improvisors, economists, martial artists,
and sundry other friends and family.

I leave to others to quibble about whether or not this qualifies as a
"python development".  (I probably made enough of a fool of myself at
the wedding, with pronouncements of good will and dancing and such,
that i can't do any more harm...-)

Yay!

Ken
klm at digicool.com



From tim_one at email.msn.com  Tue Jun  6 19:20:49 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 6 Jun 2000 13:20:49 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.LNX.4.10.10006061035250.29478-100000@akbar.nevex.com>
Message-ID: <001001bfcfdb$8f64d240$48a2143f@tim>

[Greg Wilson]
> Hi, everyone.  We're a month away from final submissions in the
> Software Carpentry design competition, which means we're two months
> away from announcing winners and starting implementation effort,

Yay!  This is a wonderful competition, and if nobody yet has bothered to
thank you for spearheading it, let me know & I'll find someone who will
<wink>.

> and we're wondering whether there are generally-accepted coding
> standards, naming conventions, or other guidelines that we should
> adopt.  If so, URLs would be welcome...

When you can't fight about where to put curly braces, there's not much left
to argue.  The only serious attempt at a Python style guide I've seen is
Guido's:

    http://www.python.org/doc/essays/styleguide.html

Two from there large numbers of people will still argue about, but to no
avail:

+ No hard tabs.  Indents are 4 spaces, period.

+ Keep lines strictly less than 80 characters wide (I happen to keep them
under 77, to allow for one level of "> " mail quoting).

These rules ensure that code is readable as intended across all platforms.

> Also, it appears that there are two implementations of the xUnit
> testing framework in Python:
>
> Steve Purcell: http://sourceforge.net/project/?group_id=3912
> Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip
>
> We'd be grateful for comments on either.

Sorry, unfamiliar with these.





From pingster at ilm.com  Tue Jun  6 19:25:57 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Tue, 6 Jun 2000 10:25:57 -0700 (PDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <Pine.SGI.3.96.1000606102423.30600j-100000@happy>

On Tue, 6 Jun 2000, Tim Peters wrote:
> 
> Yay!  This is a wonderful competition, and if nobody yet has bothered to
> thank you for spearheading it, let me know & I'll find someone who will
> <wink>.

Yeah, what he said. :)

> The only serious attempt at a Python style guide I've seen is Guido's:
> 
>     http://www.python.org/doc/essays/styleguide.html

I love this style guide.  I know it's a strange reaction to
have to a style guide, but i agree with basically everything
in it, which is probably pretty rare for these sorts of things.

> + No hard tabs.  Indents are 4 spaces, period.

Tab characters are the work of the devil.


-- ?!ng

"China is a big country, inhabited by many Chinese."
    -- Former French President Charles de Gaulle




From gvwilson at nevex.com  Tue Jun  6 19:31:32 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 6 Jun 2000 13:31:32 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <Pine.LNX.4.10.10006061328070.32393-100000@akbar.nevex.com>

> Tim Peters wrote:
> When you can't fight about where to put curly braces, there's not much
> left to argue.  The only serious attempt at a Python style guide I've
> seen is Guido's:
>     http://www.python.org/doc/essays/styleguide.html

Yes, I've seen this.  I was wondering (a) whether it's up to date (i.e.
whether common practice has moved on), and (b) whether there is now a
consensus about module structure --- we're expecting several packages that
will be shared between tools, plus multiple modules within tools.  I've
been tracking the occasional message about re-organizing the standard
Python library, and would like whatever we do to be in line with wherever
Python itself is going.

Thanks,
Greg





From esr at thyrsus.com  Tue Jun  6 19:47:13 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 6 Jun 2000 13:47:13 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.SGI.3.96.1000606102423.30600j-100000@happy>; from pingster@ilm.com on Tue, Jun 06, 2000 at 10:25:57AM -0700
References: <001001bfcfdb$8f64d240$48a2143f@tim> <Pine.SGI.3.96.1000606102423.30600j-100000@happy>
Message-ID: <20000606134713.A29204@thyrsus.com>

Ka-Ping Yee <pingster at ilm.com>:
> > The only serious attempt at a Python style guide I've seen is Guido's:
> > 
> >     http://www.python.org/doc/essays/styleguide.html
> 
> I love this style guide.  I know it's a strange reaction to
> have to a style guide, but i agree with basically everything
> in it, which is probably pretty rare for these sorts of things.

Likewise.  I never read this before, but it's spooky how closely the
style I evolved myself tracks it.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

If a thousand men were not to pay their tax-bills this year, that would
... [be] the definition of a peaceable revolution, if any such is possible.
	-- Henry David Thoreau



From petrilli at amber.org  Tue Jun  6 19:52:50 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Tue, 6 Jun 2000 13:52:50 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>; from tim_one@email.msn.com on Tue, Jun 06, 2000 at 01:20:49PM -0400
References: <Pine.LNX.4.10.10006061035250.29478-100000@akbar.nevex.com> <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <20000606135250.A25856@trump.amber.org>

Tim Peters [tim_one at email.msn.com] wrote:

> When you can't fight about where to put curly braces, there's not much left
> to argue.  The only serious attempt at a Python style guide I've seen is
> Guido's:
> 
>     http://www.python.org/doc/essays/styleguide.html

The only thing that might be added (I haven't looked in a while, but
didn't see it last time I did), is some naming convention issues.  I
follow pretty standard Smalltalk guidelines:

       - No '_', use camelCase for seps

       - Capitalize all Classes, and also global variables

       - Lowercase for all methods (i.e. setNewBreakpoint)

This is just me, and obviously not everyone does this :-)

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From gvwilson at nevex.com  Tue Jun  6 19:50:38 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 6 Jun 2000 13:50:38 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <20000606135250.A25856@trump.amber.org>
Message-ID: <Pine.LNX.4.10.10006061347510.32673-100000@akbar.nevex.com>

> > Tim Peters:
> > http://www.python.org/doc/essays/styleguide.html

> On Tue, 6 Jun 2000, Christopher Petrilli wrote:
> The only thing that might be added (I haven't looked in a while, but
> didn't see it last time I did), is some naming convention issues.  I
> follow pretty standard Smalltalk guidelines:
> 
>        - No '_', use camelCase for seps

I know this is become common practice, but I've been told by two different
HCI specialists that studies have shown CamelBackNotation to be harder for
non-native speakers to read than underbar_separated_text, particularly
when acronyms are part of the name.  If anyone has a pointer to an
original reference for this, I'd be grateful.

Thanks,
Greg





From klm at digicool.com  Tue Jun  6 20:32:12 2000
From: klm at digicool.com (Ken Manheimer)
Date: Tue, 6 Jun 2000 14:32:12 -0400 (EDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.SGI.3.96.1000606102423.30600j-100000@happy>
Message-ID: <Pine.LNX.4.21.0006061431040.675-100000@korak.digicool.com>

On Tue, 6 Jun 2000, Ka-Ping Yee wrote:

> > The only serious attempt at a Python style guide I've seen is Guido's:
> > 
> >     http://www.python.org/doc/essays/styleguide.html
> 
> I love this style guide.  I know it's a strange reaction to
> have to a style guide, but i agree with basically everything
> in it, which is probably pretty rare for these sorts of things.

Me too!  (Or three, or four by now...)

Ken
klm at digicool.com




From tim_one at email.msn.com  Tue Jun  6 20:36:26 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 6 Jun 2000 14:36:26 -0400
Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bitinteger?
In-Reply-To: <Pine.LNX.4.10.10006060257010.14292-100000@nebula.lyra.org>
Message-ID: <001201bfcfe6$1fe51dc0$48a2143f@tim>

[GregS]
> It isn't only bytecodes. As I mentioned before, marshal byte streams are
> specified as portable. Therefore, they are used all the time for passing
> over the network, for persistence mechanisms, etc.
>
> Having a marshal stream that is *not* cross-platform is just plain busted.
>
> So... you can silently truncate to 32-bits or you can raise an exception.

But in either of those cases it's not cross-platform == it's just plain
busted.

> You cannot, however, marshal a 64-bit value when the definition of an
> "marshal integer" is only 32.

The current code is insane.  Long-term the visible distinction between
(Python) ints and longs should vanish.  Short-term the PyInt_Check case of
w_object should see whether the int fits in 4 bytes, and if so write it as a
C long, and if not write the thing as a Python long (that's the only way to
keep the marshal portable!).  Any code keying off the SIZEOF_LONG symbol is
highly suspect, piling another layer of "convenient but wrong" assumptions
on top of the current layer.  Code in marshal should *never* try to exploit
that C longs happen to be bigger than 4 bytes on the current platform.
PyMarshal_WriteLongToFile should be changed to raise an exception if passed
something that doesn't fit in 4 bytes, and should be declared obsolete.  The
Python core should be changed now never to call PyMarshal_WriteLongToFile
(in answer to Trent's original question, the intent of that code can't be
distinguished from what it does, which is to blindly write exactly 4 bytes
no matter what).

Most of this crap is in support of a bad assumption about mtimes, and,
sorry, but it sure looks to me like the .pyc header format is "just plain
busted" too.  Let's bite the bullet and fix the header -- then all the rest
of this will be clearly seen as the broken hackery it really is.





From trentm at activestate.com  Tue Jun  6 20:57:52 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 6 Jun 2000 11:57:52 -0700
Subject: [Python-Dev] about patches on SourceForge
In-Reply-To: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com>
References: <20000605195244.A25437@activestate.com> <ECEPKNMJLHAPFFJHDOJBGEIBCMAA.mhammond@skippinet.com.au> <14652.29682.819341.881773@cj42289-a.reston1.va.home.com>
Message-ID: <20000606115752.D28943@activestate.com>

On Mon, Jun 05, 2000 at 11:45:54PM -0400, Fred L. Drake, Jr. wrote:
> 
> Mark Hammond writes:
>  > This is all too hard until Guido gets back.  But personally I believe the
>  > raw patch should be just the CVS diff output, and the comments should
>  > reflect all other text, including the release notice while it is still
>  > necessary.
> 
>   Sounds good to me.  Let's do it this way until there's a god reason
                                                             ^^^
> to do it differently.
> 

I think maybe that you meant 'good', but I am not so sure. ;-)

Trent


-- 
Trent Mick
trentm at activestate.com



From gmcm at hypernet.com  Tue Jun  6 20:59:49 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 6 Jun 2000 14:59:49 -0400
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.LNX.4.10.10006061328070.32393-100000@akbar.nevex.com>
References: <001001bfcfdb$8f64d240$48a2143f@tim>
Message-ID: <1251804473-5567942@hypernet.com>

Greg Wilson wrote:

> > Tim Peters wrote:
[Guido's style guide]

> Yes, I've seen this.  I was wondering 
> ... whether
> there is now a consensus about module structure ...

No, there's not. And if you ask me, (which you didn't) there's 
some very bad precedents getting set in the misguided pursuit 
of "ease of use".

Time to call out the PSU before things get out of hand...


- Gordon



From gstein at lyra.org  Tue Jun  6 21:04:25 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 6 Jun 2000 12:04:25 -0700 (PDT)
Subject: [Python-Dev] req: Software Carpentry / coding standards
In-Reply-To: <Pine.LNX.4.10.10006061347510.32673-100000@akbar.nevex.com>
Message-ID: <Pine.LNX.4.10.10006061201340.14292-100000@nebula.lyra.org>

On Tue, 6 Jun 2000, Greg Wilson wrote:
> > > Tim Peters:
> > > http://www.python.org/doc/essays/styleguide.html
> 
> > On Tue, 6 Jun 2000, Christopher Petrilli wrote:
> > The only thing that might be added (I haven't looked in a while, but
> > didn't see it last time I did), is some naming convention issues.  I
> > follow pretty standard Smalltalk guidelines:
> > 
> >        - No '_', use camelCase for seps
> 
> I know this is become common practice, but I've been told by two different
> HCI specialists that studies have shown CamelBackNotation to be harder for
> non-native speakers to read than underbar_separated_text, particularly
> when acronyms are part of the name.  If anyone has a pointer to an
> original reference for this, I'd be grateful.

Actually, the "camel case" for identifiers is not a standard Python style.
I've seen three forms:

- no separator or case usage (e.g. getattr())
- mixed case
- lower case with underscores

Chris' other points: upper-case-initial classes and lower-case-initial
methods are *definitely* standard.

Globals are a bit different. I don't think it is standard to capitalize
them as Chris mentioned (they might look like classes in that case). There
isn't much of a standard there.

Definitely another point is the use of "_" for the initial character to
signify "private -- don't touch"

Cheers,
-g

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






From gstein at lyra.org  Tue Jun  6 21:29:56 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 6 Jun 2000 12:29:56 -0700 (PDT)
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errors
 in signalmodule.c and bufferobject.c)
In-Reply-To: <001c01bfcfea$b73a2040$48a2143f@tim>
Message-ID: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org>

On Tue, 6 Jun 2000, Tim Peters wrote:
>...
> [on K&R style declarations failing to act as prototypes]
> > ...
> > Give the man a prize. That was it. We'll just forget that part of the
> > patch then and thank you Tim for changing all function declarations
> > from K&R to ANSI. :)
> 
> Believe it or not, I do intend to do that, although I expect resistance from
> Guido <0.5 wink>.  Python's infrastructure is creaking from age, and an
> update to ANSI C is l-o-n-g overdue.  It appears to me that a very large
> part of your "Win64" efforts have amounted to fighting long-obsolete K&R C
> assumptions!

Euh... I thought Guido was entirely supportive of ANSI-fying the source.
Something like changing from K&R functions over to ANSI declarations is
"brain-dead" that should not introduce errors.

Going through and revamping the protoypes (e.g. PyString_FromStringAndSize
to now use size_t) is a bit different, though...

I shouldn't think Guido would be upset about prototypes.

Cheers,
-g

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




From effbot at telia.com  Tue Jun  6 22:23:19 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 6 Jun 2000 22:23:19 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org>
Message-ID: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid>

greg wrote:
> Euh... I thought Guido was entirely supportive of ANSI-fying the source.

note that 1.6 won't build on non-ANSI platforms; lots of new
stuff, including the unicode type, the builtin exceptions, and
SRE are pure ANSI.

(btw, what are all those "register" declarations doing in MAL's
version of unicodeobject.c?  does any modern compiler even
care about that keyword?)

</F>




From tim_one at email.msn.com  Tue Jun  6 23:00:33 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 6 Jun 2000 17:00:33 -0400
Subject: [Python-Dev] RE: ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c)
In-Reply-To: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org>
Message-ID: <001f01bfcffa$41ed2f20$48a2143f@tim>

[Greg Stein]
> Euh... I thought Guido was entirely supportive of ANSI-fying the source.
> Something like changing from K&R functions over to ANSI declarations is
> "brain-dead" that should not introduce errors. ...

He'll be less & less in favor of it when it hits home how time-consuming and
massive the changes will be.  They won't be viewed as "a feature" to BeOpen,
so BeOpen will give him grief about it too.  Etc.  I've fought the same
stinking infrastructure battles for 20+ years, and don't expect that having
a new boss will make any material difference to that <0.7 wink>.  Testing is
expensive, robustness is expensive, portability is expensive (and C doesn't
help!  honest to God, it's much worse than Fortran for portability).

> Going through and revamping the protoypes (e.g. PyString_FromStringAndSize
> to now use size_t) is a bit different, though...
>
> I shouldn't think Guido would be upset about prototypes.

Nobody should get upset about *having* them, it's getting them done that
takes away from getting everything else done.  That's why every project I've
ever seen puts it off year after year.  Note that if Guido valued this
*highly*, it would already have been done.

been-there-done-that-been-there-done-that-been-there-done-that-ly y'rs  -
tim





From jack at oratrix.nl  Tue Jun  6 23:14:10 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Tue, 06 Jun 2000 23:14:10 +0200
Subject: [Python-Dev] Trying again:  [Patches] Patch to import.c
Message-ID: <20000606211416.10B6ED8397@oratrix.oratrix.nl>

Folks,
I posted this message to the patches mailing list last week, but
either I missed the reply (we had full disks over the weekend) or
nobody replied yet. And I am waiting for these patches, or rather
other people who want to play with MacPython and MacOSX are, so I'd
really like to know whether I should revise the patches and in what
direction or have them checked in....

Hmm, that may all sound a bit pushy, but that isn't the intention. I
really just want to know (a) what the status of my patches is and (b)
what I can expect in the future....

	Jack
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: no subject
Date: no date
Size: 38
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000606/00891a7f/attachment-0001.eml>

From mal at lemburg.com  Wed Jun  7 00:53:02 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Jun 2000 00:53:02 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit 
 warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org> <01b101bfcff5$1000faa0$f2a6b5d4@hagrid>
Message-ID: <393D80CE.D6C387AA@lemburg.com>

Fredrik Lundh wrote:
> 
> note that 1.6 won't build on non-ANSI platforms; lots of new
> stuff, including the unicode type, the builtin exceptions, and
> SRE are pure ANSI.
> 
> (btw, what are all those "register" declarations doing in MAL's
> version of unicodeobject.c?  does any modern compiler even
> care about that keyword?)

"register" helps compilers in situations where normal
optimizations don't give satisfying results, e.g. to aid
in keeping often used variables or counters in registers
rather than on the stack. It can also help with inling
functions and can speed up parameter passing.

GCC is one such modern compiler that does care, not sure
about MSVC++. IBM's OS/2 compilers did (last time
I looked some 5 years ago ;).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From pf at artcom-gmbh.de  Wed Jun  7 00:47:41 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 00:47:41 +0200 (MEST)
Subject: Style guide (was Re: [Python-Dev] req: Software Carpentry / coding standards)
In-Reply-To: <Pine.LNX.4.10.10006061347510.32673-100000@akbar.nevex.com> from Greg Wilson at "Jun 6, 2000  1:50:38 pm"
Message-ID: <m12zS8L-000DifC@artcom0.artcom-gmbh.de>

Hi,

Greg Wilson:
> > > Tim Peters:
> > > http://www.python.org/doc/essays/styleguide.html
> 
> > On Tue, 6 Jun 2000, Christopher Petrilli wrote:
> > The only thing that might be added (I haven't looked in a while, but
> > didn't see it last time I did), is some naming convention issues.  I
> > follow pretty standard Smalltalk guidelines:
> > 
> >        - No '_', use camelCase for seps
> 
> I know this is become common practice, but I've been told by two different
> HCI specialists that studies have shown CamelBackNotation to be harder for
> non-native speakers to read than underbar_separated_text, particularly
> when acronyms are part of the name.  If anyone has a pointer to an
> original reference for this, I'd be grateful.

This would be indeed very interesting.  

But my own experiences support this POV:

This naming style issue is similar in Python and one of its early
anchestors Modula-2.

In 1985 we started our company programming in Modula-2.  At that
time we decided to code conforming to the original Modula-2 language
definition as published by N.Wirth in March, 1980:  underscores were 
not allowed in identifiers!  German: '_' verboten! ;-)

The software is in use until today and several of our employees still
have to use Modula-2 for maintainance.  The code base is currently
about 1 Mio. LOC.

We tried to use english identifiers, although all programmers are 
native german speakers.

We too adopted a style using first char lowercase or uppercase to
distinguish identifier classes (modules and procedure names uppercase
and all other identifiers lowercase) and later we ran into the
problems described above.

A few years ago we allowed the use of '_' in identifiers, because
the compiler support was available.  This has improved the situation
somewhat.  All our programmers like the possibility to occasionally
use '_' in identifiers, especially if idents contain acronyms.

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)



From pf at artcom-gmbh.de  Wed Jun  7 11:34:12 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 11:34:12 +0200 (MEST)
Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5)
In-Reply-To: <200006070911.CAA17368@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000  2:11:43 am"
Message-ID: <m12zcE0-000DifC@artcom0.artcom-gmbh.de>

Hi,

Marc-Andre Lemburg:
[...]
> Added a new locale name aliasing engine which also supports
> locale encodings, a feature which is used by the new default
> encoding support in site.py.
> 
> Index: locale.py
[...]
> + ### C lib locale APIs
> + 
> + from _locale import *

Wouldn't it be clever to provide some dummy stubs on those platforms, where 
the _locale module was not enabled?  

try:
    from _locale import *
except:
    def setlocale(....
    def localeconv(....
    ...

Especially the MacOS 1.5.2 release provided by Jack Jansen was
compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
is still disabled per default in 'Modules/Setup.in'.  I didn't had
a look into the current CVS though, so this may have changed.

I think the name aliasing tables might be also useful on those
systems lacking locale support in their C-library.

Regards, Peter



From pf at artcom-gmbh.de  Wed Jun  7 11:40:17 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 11:40:17 +0200 (MEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules Setup.in,1.100,1.101
In-Reply-To: <200006070912.CAA17814@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000  2:12:56 am"
Message-ID: <m12zcJt-000DifC@artcom0.artcom-gmbh.de>

Uoooppps....
I was just too fast with my previous email about _locale emulation.

Marc-Andre Lemburg:
> *** Setup.in	2000/05/26 19:02:42	1.100
> --- Setup.in	2000/06/07 09:12:54	1.101
> ***************
> *** 141,145 ****
>                           # static Unicode character database
>   
> ! #_locale _localemodule.c  # access to ISO C locale support
>   
>   
> --- 141,145 ----
>                           # static Unicode character database
>   
> ! _locale _localemodule.c  # access to ISO C locale support
>   

Is this likely to work on the Mac with C-libraries coming with
Metrowerks CodeWarrior?  Jack?

Regards, Peter



From fredrik at pythonware.com  Wed Jun  7 12:24:46 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 7 Jun 2000 12:24:46 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org> <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com>
Message-ID: <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com>

MAL wrote:
> > (btw, what are all those "register" declarations doing in MAL's
> > version of unicodeobject.c?  does any modern compiler even
> > care about that keyword?)
> 
> "register" helps compilers in situations where normal
> optimizations don't give satisfying results, e.g. to aid
> in keeping often used variables or counters in registers
> rather than on the stack. It can also help with inling
> functions and can speed up parameter passing.

Yeah, I know what register is supposed to do.

But common knowledge (at least where I live) is that modern optimizers
know better than you, and usually ignore "register" altogether if you use
higher optimization levels... (and if they don't, using "register" is likely to
make things worse on some platforms).  In other words, "register" should
not be used in portable code.

fwiw, a certain Linux kernel hacker seem to agree with me on that one:

    http://www2.linuxjournal.com/lj-issues/issue17/1138.html
    ...
    #define register
    ...
    "Gcc, the normal Linux C compiler, understands the register keyword,
    but the code optimiser is sufficiently good that using register is normally
    a bad idea."
    ...

(If it's good enough for Alan Cox etc).

But never mind.  I doubt that removing them would matter on any con-
temporary platform, but on the other hand, keeping them in there won't
hurt much either.  It just makes the source code a little bit more ver-
bose than it has to be...

</F>




From mal at lemburg.com  Wed Jun  7 12:25:08 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Jun 2000 12:25:08 +0200
Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: 
 python/dist/src/Lib locale.py,1.4,1.5)
References: <m12zcE0-000DifC@artcom0.artcom-gmbh.de>
Message-ID: <393E2304.4BE8CDE0@lemburg.com>

Peter Funk wrote:
> 
> Hi,
> 
> Marc-Andre Lemburg:
> [...]
> > Added a new locale name aliasing engine which also supports
> > locale encodings, a feature which is used by the new default
> > encoding support in site.py.
> >
> > Index: locale.py
> [...]
> > + ### C lib locale APIs
> > +
> > + from _locale import *
> 
> Wouldn't it be clever to provide some dummy stubs on those platforms, where
> the _locale module was not enabled?
> 
> try:
>     from _locale import *
> except:
>     def setlocale(....
>     def localeconv(....
>     ...
> 
> Especially the MacOS 1.5.2 release provided by Jack Jansen was
> compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
> is still disabled per default in 'Modules/Setup.in'.  I didn't had
> a look into the current CVS though, so this may have changed.
> 
> I think the name aliasing tables might be also useful on those
> systems lacking locale support in their C-library.

setlocale and localeconv are ANSI C and Python requires an ANSI C
compiler, so there should be no problem (at least in theory).

If there is a problem, adding the missing symbols would
be no problem: the APIs could always report locale 'C'
and its numeric settings.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From mal at lemburg.com  Wed Jun  7 12:40:24 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Jun 2000 12:40:24 +0200
Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit 
 warnings/errorsin signalmodule.c and bufferobject.c)
References: <Pine.LNX.4.10.10006061228220.14292-100000@nebula.lyra.org> <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com> <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com>
Message-ID: <393E2698.D2DFFC91@lemburg.com>

Fredrik Lundh wrote:
> 
> MAL wrote:
> > > (btw, what are all those "register" declarations doing in MAL's
> > > version of unicodeobject.c?  does any modern compiler even
> > > care about that keyword?)
> >
> > "register" helps compilers in situations where normal
> > optimizations don't give satisfying results, e.g. to aid
> > in keeping often used variables or counters in registers
> > rather than on the stack. It can also help with inling
> > functions and can speed up parameter passing.
> 
> Yeah, I know what register is supposed to do.

I know you know, but I find adding some explanations for others
which might not know is good practice.
 
> But common knowledge (at least where I live) is that modern optimizers
> know better than you, and usually ignore "register" altogether if you use
> higher optimization levels... (and if they don't, using "register" is likely to
> make things worse on some platforms).  In other words, "register" should
> not be used in portable code.
> 
> fwiw, a certain Linux kernel hacker seem to agree with me on that one:
> 
>     http://www2.linuxjournal.com/lj-issues/issue17/1138.html
>     ...
>     #define register
>     ...
>     "Gcc, the normal Linux C compiler, understands the register keyword,
>     but the code optimiser is sufficiently good that using register is normally
>     a bad idea."
>     ...

Well, make that "normally not needed": gcc sometimes doesn't inline
functions because it thinks that the function needs parameters to be
on the stack. The register keyword can do wonders here.

Adding "register" is like adding salt & pepper: things usually
taste better than before ;-).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gward at mems-exchange.org  Wed Jun  7 15:19:06 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 09:19:06 -0400
Subject: [Python-Dev] Re: [Patches] Translating doc strings
In-Reply-To: <200006021503.RAA26314@pandora>; from loewis@informatik.hu-berlin.de on Fri, Jun 02, 2000 at 05:03:50PM +0200
References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org> <200006021503.RAA26314@pandora>
Message-ID: <20000607091906.A5559@ludwig.cnri.reston.va.us>

On 02 June 2000, Martin von Loewis said:
> Having the full set of distutils doc strings in the
> catalog is already a substantial amount of text to translate...

Most of those docstrings in the Distutils are not really for public
consumption; they're there so that Distutils developers can remember (or
learn) what the heck such-and-such a method is supposed to do.

Also, they're a moving target; things are still changing in the
Distutils, and trying to keep on top of translating internal docstrings
would be a hopeless and frustrating task.

        Greg



From jack at oratrix.nl  Wed Jun  7 15:51:54 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 07 Jun 2000 15:51:54 +0200
Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] 
 CVS: python/dist/src/Lib locale.py,1.4,1.5)
In-Reply-To: Message by "M.-A. Lemburg" <mal@lemburg.com> ,
	     Wed, 07 Jun 2000 12:25:08 +0200 , <393E2304.4BE8CDE0@lemburg.com> 
Message-ID: <20000607135154.8DCFD370CF2@snelboot.oratrix.nl>

The locale stuff in the CodeWarrior libraries is basically a dummy 
placeholder, that's why I didn't export it to Python. But it appears that it's 
better to export it anyway, if I understand the dsicussion correctly, so I'll 
do so from the next release.
--
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 gward at mems-exchange.org  Wed Jun  7 15:56:38 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 09:56:38 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>; from jeremy@beopen.com on Sat, Jun 03, 2000 at 12:11:48PM -0400
References: <3938D60E.391AAF31@lemburg.com> <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
Message-ID: <20000607095638.B5559@ludwig.cnri.reston.va.us>

On 03 June 2000, Jeremy Hylton said:
> SourceForge makes it a little more inconvenient to check which
> patches have been applied.  Under the old CVS arrangement, it was
> a local operation to do a cvs log or diff.  Now it's a slow network
> operation that requires authentication.  (I really want a local
> mirror of the entire CVS repository!)

I have come up with a partial solution to the inconvenience of accessing
SourceForge, specifically the need for constant authentication.  I
generated a new, unencrypted SSH key and put it in ~/.ssh/alt-identity.
Then I wrote a little C program (source attached) that does the
equivalent of

  os.exec ("ssh", "-i", "$HOME/.ssh/alt-identity")

(in an imaginary dialect of Python that interpolates environment
variables ;-).  Then I set CVS_RSH to this little C program
(~/bin/alt_ssh).  (It could have easily been a script, but I wanted to
avoid the overhead of launching an interpreter for every
authentication.)

So now CVS operations against SF are just s..l..o..w, and I'm not
forever typing in my SSH passphrase.  Of course, anyone with root access
at CNRI could now steal my unencrypted key -- which I *only* use for CVS
access to SF -- and use it to impersonate me for checkins.  But I think
the only person who knows how to do that already has Python checkin
privilege.  ;-)

But yeah, remote CVS still bites the big one.  Very painful over a 28.8k 
modem line.  (It sucks being a cheap bastard!)

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From gward at mems-exchange.org  Wed Jun  7 15:57:41 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 09:57:41 -0400
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us>; from gward@ludwig.cnri.reston.va.us on Wed, Jun 07, 2000 at 09:56:38AM -0400
References: <3938D60E.391AAF31@lemburg.com> <AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com> <20000607095638.B5559@ludwig.cnri.reston.va.us>
Message-ID: <20000607095741.C5559@ludwig.cnri.reston.va.us>

On 07 June 2000, I said:
> Then I wrote a little C program (source attached) that does the
> equivalent of

Oops, forgot the attachment.  Here 'tis.
-------------- next part --------------
/*
 * alt_ssh
 *
 * exec ssh with an alternate "identity" (key pair) -- needed since
 * the CVS_RSH variable can't include options for the rsh-like
 * command.
 *
 * GPW 2000/05/28
 *
 * $Id: alt_ssh.c,v 1.3 2000/06/07 13:54:19 gward Exp $
 */

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main (int argc, char * argv[])
{
    char * keyfile = "/.ssh/alt-identity";
    char * keyfile_full;
    char * home;
    int  num_args;
    char ** ssh_args;
    int i;

    home = getenv("HOME");
    keyfile_full = (char *) malloc (strlen(home) + strlen(keyfile) + 1);
    assert (home != NULL && keyfile_full != NULL);
    strcpy(keyfile_full, home);
    strcat(keyfile_full, keyfile);

    num_args = argc + 2;                /* -i, identity-file */
    ssh_args = (char **) calloc (num_args+1, sizeof(char *));
    ssh_args[0] = "ssh";
    ssh_args[1] = "-i";
    ssh_args[2] = keyfile_full;

    for (i = 3; i < num_args; i++)
        ssh_args[i] = argv[i-2];
    ssh_args[i] = NULL;

    for (i = 0; i < num_args; i++)
    {
        printf(ssh_args[i]);
        if (i < num_args)
            printf(" ");
    }
    printf("\n");
    
    execvp("ssh", ssh_args);
    perror("couldn't exec ssh");
    exit(1);
}

From jeremy at beopen.com  Wed Jun  7 16:04:12 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 10:04:12 -0400 (EDT)
Subject: [Python-Dev] Fwd: Hmmmm... (Jim Anderson)
Message-ID: <14654.22108.959934.552869@localhost.localdomain>

You guys haven't seen more Perl traffic on this list have you? :-)

Jeremy

-------------- next part --------------
An embedded message was scrubbed...
From: "Jim Anderson" <jander at ml.com>
Subject: Hmmmm...
Date: Tue, 6 Jun 2000 12:09:53 -0400 (EDT)
Size: 490
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000607/d27a0195/attachment-0001.eml>

From gward at mems-exchange.org  Wed Jun  7 16:11:46 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 7 Jun 2000 10:11:46 -0400
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.)
In-Reply-To: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>; from gstein@lyra.org on Sun, Jun 04, 2000 at 04:30:08PM -0700
References: <Pine.LNX.4.10.10006041624040.29036-100000@nebula.lyra.org>
Message-ID: <20000607101146.D5559@ludwig.cnri.reston.va.us>

On 04 June 2000, Greg Stein said:
> p.s. IMO, I'd like to see Guido own the Copyright for all current and
> future Python development

Second that.  Given that I work for CNRI and was forced (at gunpoint, as
I recall) to sign an incredibly draconian IP agreement -- along the
lines of "everything you have ever created, or will ever consider
creating, in any medium whatsoever, no matter where you did it or who
pays for it, is the property of CNRI for all time" -- I'd have a hard
time getting away with slapping "Copyright (c) 1999-2000 Gregory
P. Ward" all over the Distutils code.  And given that fair chunks of
that code have been contributed by other people, I couldn't even
ethically do that.

So, given that I probably can't claim ownership in the code, and that
CNRI has absolutely no moral right to it (although probably some legal
right), I'd prefer to sign it away to Guido.  Or optionally, to some
legal fiction that represents the Python community; preferably *not* the
Python Consortium, as long as CNRI is in any way connected.

Death to the lawyers!

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From moshez at math.huji.ac.il  Wed Jun  7 16:33:10 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 7 Jun 2000 17:33:10 +0300 (IDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to
 return total reference count in debug builds.)
In-Reply-To: <20000607101146.D5559@ludwig.cnri.reston.va.us>
Message-ID: <Pine.GSO.4.10.10006071731200.2293-100000@sundial>

On Wed, 7 Jun 2000, Greg Ward wrote:

> CNRI has absolutely no moral right to it (although probably some legal
> right), I'd prefer to sign it away to Guido.  Or optionally, to some
> legal fiction that represents the Python community; preferably *not* the
> Python Consortium, as long as CNRI is in any way connected.

Who's in charge of the PSA?
Or should we form *another* non-profit, and sign it over to it?
(Personally, I couldn't care less who I transfer copyright over my Python
contributions to -- I'd put it in the public domain if that's what it
took)

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From pf at artcom-gmbh.de  Wed Jun  7 16:44:30 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Wed, 7 Jun 2000 16:44:30 +0200 (MEST)
Subject: [Python-Dev] Revised 1.6 jobs list
In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us> from Greg Ward at "Jun 7, 2000  9:56:38 am"
Message-ID: <m12zh4J-000DifC@artcom0.artcom-gmbh.de>

Hi,

Greg Ward:
> But yeah, remote CVS still bites the big one.  Very painful over a 28.8k 
> modem line.  (It sucks being a cheap bastard!)

Certainly you know about 'rsync'?  Would this help here?  
Let me quote a small section from the 'rsync' man page:

"""    To synchronize my samba source trees I use  the  following
       Makefile targets:

              get:
              	rsync -avuzb --exclude ?*~? samba:samba/ .

              put:
              	rsync -Cavuzb . samba:samba/

              sync: get put

       this  allows  me to sync with a CVS directory at the other
       end of the link. I then do cvs operations  on  the  remote
       machine,  which saves a lot of time as the remote cvs pro?
       tocol isn?t very efficient.  """

I can't access CVS because of our restrictive HTTP/UUCP only firewall, 
but in our company we use 'rsync' a lot.

Regards, Peter



From bwarsaw at python.org  Wed Jun  7 17:06:42 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Wed, 7 Jun 2000 11:06:42 -0400 (EDT)
Subject: [Python-Dev] Revised 1.6 jobs list
References: <3938D60E.391AAF31@lemburg.com>
	<AJEAKILOCCJMDILAPGJNKEEECAAA.jeremy@beopen.com>
	<20000607095638.B5559@ludwig.cnri.reston.va.us>
Message-ID: <14654.25858.564089.574043@anthem.python.org>

>>>>> "GW" == Greg Ward <gward at mems-exchange.org> writes:

    GW> I have come up with a partial solution to the inconvenience of
    GW> accessing SourceForge, specifically the need for constant
    GW> authentication.

Greg, are you aware of ssh-agent?  Same convenience, same possible
exploits, but at least they've done the hard work for ya. :)

I usually just run XEmacs under ssh-agent.  First thing you do is fire
up a shell buffer, run ssh-add to authenticate once, and from there
on, all your ssh interactions (not just with SF) yank the private key
out of the ssh-agent process and never bother you with a passphrase
prompt.

-Barry



From bwarsaw at python.org  Wed Jun  7 17:22:20 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Wed, 7 Jun 2000 11:22:20 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to
 return total reference count in debug builds.)
References: <20000607101146.D5559@ludwig.cnri.reston.va.us>
	<Pine.GSO.4.10.10006071731200.2293-100000@sundial>
Message-ID: <14654.26796.936980.875783@anthem.python.org>

>>>>> "MZ" == Moshe Zadka <moshez at math.huji.ac.il> writes:

    MZ> Who's in charge of the PSA?  Or should we form *another*
    MZ> non-profit, and sign it over to it?  (Personally, I couldn't
    MZ> care less who I transfer copyright over my Python
    MZ> contributions to -- I'd put it in the public domain if that's
    MZ> what it took)

Please remember that the copyright holder can release the code under
whatever license they want, even multiple different licenses.
Copyright != license.

I'm not sure what the right thing to do here is.  On the one hand, Bob
Kahn always said nobody would use Python if its heritage
(i.e. copyright ownership) were not nailed down like Java.  On the
other hand, there's a lot of nobodies out there right now :).

For GNU projects, the FSF wants to own all the copyrights to the code.
They actually want you to legally assign the copyright to them.  Their
explanation for this onerous requirement is that if they were not the
copyright holder, they would not have the legal standing to defend GPL
violations, or would have to coordinate with a ton of developers,
making such legal defenses practically impossible.

Python is in a different situation, IMO, because it has a /less/
restrictive license than the GPL, so there's less to get all huffy
about in court.  If someone builds a binary-only proprietary blend of
Python and starts selling it without source code, well, there's no
license violation there, so what's to defend?

The argument has been made that without clear legal title, someone
could claim that some of the donated code in Python violated a
copyright or patent and try to stop 3rd parties from using Python.
Who knows what the actual legal possibility of that happening are, but
I don't see how 1) we could take any real defense against this or 2)
it affects Python any differently than any other large
multi-contributor open source system.

-Barry



From andy at robanal.demon.co.uk  Wed Jun  7 22:48:48 2000
From: andy at robanal.demon.co.uk (Andy Robinson)
Date: Wed, 07 Jun 2000 20:48:48 GMT
Subject: [Python-Dev] Package ambiguities
Message-ID: <393eb52b.47053339@post.demon.co.uk>

We hit some very weird behaviour recently while setting up a package
hierarchy.  Robin Becker managed to distil this into a simple example.
Can anyone shed any light on what is happening below?  Is Python
behaving as it should?

Create a package A, empty __init__.py, with modules as follows:
--------parent.py----------
class Parent:
    pass

--------child.py------------
from parent import Parent
class Child(Parent):
    pass

---------test.py--------
from parent import *
class Examiner:
    def examine(self, arg):
        print 'examining argument:'
        print 'class of arg =', arg.__class__
        print 'bases of arg =', arg.__class__.__bases__
        print 'arg =', arg
        if isinstance(arg, Parent):
            print "arg is an instance of Parent"
        else:
            print "arg IS NOT an instance of Parent"
        print
        
if __name__=='__main__':
        from traceback import print_exc
        import sys
        def run0():
                from A.child import Child
                e = Examiner()
                e.examine(Child())

        def run1():
                from A.child import Child
                from A.test import Examiner
                e = Examiner()
                e.examine(Child())
        run0()
        run1()


Running this script produces the following output:

  C:\users\andy\A>test.py
  examining argument:
  class of arg = A.child.Child
  bases of arg = (<class A.parent.Parent at 7f9150>,)
  arg = <A.child.Child instance at 7f9410>
  arg IS NOT an instance of Parent

  examining argument:
  class of arg = A.child.Child
  bases of arg = (<class A.parent.Parent at 7f9150>,)
  arg = <A.child.Child instance at 7f83c0>
  arg is an instance of Parent


Many thanks,

Andy Robinson





From pingster at ilm.com  Wed Jun  7 23:05:26 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Wed, 7 Jun 2000 14:05:26 -0700 (PDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <393eb52b.47053339@post.demon.co.uk>
Message-ID: <Pine.SGI.3.96.1000607135723.428158j-100000@happy>

On Wed, 7 Jun 2000, Andy Robinson wrote:
> We hit some very weird behaviour recently while setting up a package
> hierarchy.  Robin Becker managed to distil this into a simple example.
> Can anyone shed any light on what is happening below?  Is Python
> behaving as it should?

It looks to me like you have two "parent" modules.

When you run "test.py" directly from the command line, the
first "from parent import *" imports parent.py as module "parent".
But subsequently parent.py is imported again as module "A.parent".

Similarly, you have two "Examiner" classes.  In run0() you
get Examiner from __main__, which contains the Parent class
from module "parent".  In run1() you get Examiner from A.test,
which contains the Parent class imported from module "A.parent".

If you insert

        print 'in module', __name__, 'parent is', repr(Parent)

at the beginning of the examine() method, it should make things
clear.

The solution is to avoid directly running scripts that are
inside packages; the confusion is produced by the fact that
you're running "test.py" from within the A/ directory.


-- ?!ng




From jeremy at beopen.com  Wed Jun  7 23:25:53 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 17:25:53 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
Message-ID: <14654.48609.710990.321688@localhost.localdomain>

Say a startup company decided to put some resources behind the Python
Web site -- a full-time Web master, some content developers, etc.
What would you have them do?  What could be done to open up the site
to the community and make it more responsive to developers and users?
What's your wish list for content, services, etc.?

If you've got any ideas, please get back to me soon.

Jeremy




From esr at thyrsus.com  Wed Jun  7 23:41:48 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 7 Jun 2000 17:41:48 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14654.48609.710990.321688@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 07, 2000 at 05:25:53PM -0400
References: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <20000607174148.A6801@thyrsus.com>

Jeremy Hylton <jeremy at beopen.com>:
> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?

I think it's pretty good as is -- lots of content, pretty well 
organized.  My top wishlist item is "Burn all your GIFs".
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The right of self-defense is the first law of nature: in most
governments it has been the study of rulers to confine this right
within the narrowest limits possible.  Wherever standing armies
are kept up, and when the right of the people to keep and bear
arms is, under any color or pretext whatsoever, prohibited,
liberty, if not already annihilated, is on the brink of
destruction." 
	-- Henry St. George Tucker (in Blackstone's Commentaries)



From jack at oratrix.nl  Wed Jun  7 23:47:01 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 07 Jun 2000 23:47:01 +0200
Subject: [Python-Dev] hey, who broke the array module? 
In-Reply-To: Message by Guido van Rossum <guido@python.org> ,
	     Thu, 18 May 2000 15:05:45 -0700 , <200005182205.PAA12830@cj20424-a.reston1.va.home.com> 
Message-ID: <20000607214706.65CB2D8397@oratrix.oratrix.nl>

Recently, Guido van Rossum <guido at python.org> said:
> > On Thu, May 18, 2000 at 12:01:16PM +0200, Jack Jansen wrote:
> > > > I broke it with my patches to test overflow for some of the PyArg_Parse
> *()
> > > > formatting characters. The upshot of testing for overflow is that now t
> hose
> > > > formatting characters ('b', 'h', 'i', 'l') enforce signed-ness or
> > > > unsigned-ness as appropriate (you have to know if the value is signed o
> r
> > > > unsigned to know what limits to check against for overflow). Two
> > > > possibilities presented themselves:
> > > 
> > > I think this is a _very_ bad idea. I have a few thousand (literally) rout
> ines 
> > > calling to Macintosh system calls that use "h" for 16 bit flag-word value
> s, 
> > > and the constants are all of the form
> > > 
> > > kDoSomething = 0x0001
> > > kDoSomethingElse = 0x0002
> > > ...
> > > kDoSomethingEvenMoreBrilliant = 0x8000
> > > 
> > > I'm pretty sure other operating systems have lots of calls with similar 
> > > problems. I would strongly suggest using a new format char if you want 
> > > overflow-tested integers.
> > 
> > Sigh. What do you think Guido? This is your call.
> > 
> > 1. go back to no bounds testing
> > 2. bounds check for [SHRT_MIN, USHRT_MAX] etc (this would allow signed and
> > unsigned values but is sort of false security for bounds checking)
> > 3. keep it the way it is: 'b' is unsigned and the rest are signed
> > 4. add new format characters or a modifying character for signed and unsign
> ed
> > versions of these.
> 
> Sigh indeed.  Ideally, we'd introduce H for unsigned and then lock
> Jack in a room with his Macintosh computer for 48 hours to fix all his
> code...

Hmm, hmm. As stated before I'm not too fond of this as it is a
gratuitous change that breaks lots of things (not only in Mac modules: 
the array module was what started this discussion, test_cPickle
and test_pkg crash, socketmodule, os.stat() and I assume all code that
uses structmodule will also have to be looked at, and quite possibly
there's a lot more) and for which I don't really see all that much
benefit.

As a datapoint: a quick search for 8-digit hex numbers starting with
digit 8-F and not suffixed with an L throughout the Python files in
the distribution found a stunning 464 matches. Add another 1147
4-digit hex numbers with the sign bit on and there are an awful lot of 
candidates for breaking...
--
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 gmcm at hypernet.com  Wed Jun  7 23:59:20 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 7 Jun 2000 17:59:20 -0400
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <Pine.SGI.3.96.1000607135723.428158j-100000@happy>
References: <393eb52b.47053339@post.demon.co.uk>
Message-ID: <1251707300-11412775@hypernet.com>

Ka-Ping wrote:

> On Wed, 7 Jun 2000, Andy Robinson wrote:
> > We hit some very weird behaviour recently while setting up a
> > package hierarchy.  Robin Becker managed to distil this into a
> > simple example. Can anyone shed any light on what is happening
> > below?  Is Python behaving as it should?

[snip entirely correct analysis]

> The solution is to avoid directly running scripts that are
> inside packages; the confusion is produced by the fact that
> you're running "test.py" from within the A/ directory.

I disagree with the moral.

If test.py uses "import A.parent" and changes references 
accordingly, it works.

So my version of the moral is that import * is EVIL. Not only 
that, but relative imports are EVIL.

This is what I meant when I said (in reply to Greg Wilson's 
inquiry about package structures) that there are some very 
bad precedents getting set.

Doing this junk (usually in __init__.py) not only makes your 
package fragile, it also makes the package structure 
mysterious to the user (who's a developer - making things 
mysterious to him/her is just making both your lives harder!). If 
you want to make it friendly to lazy coders, then something 
like:

import A.parent
Parent = A.parent.Parent

also works, (leaving references as Parent). I'm not terribly fond 
of this, either, but at least the coder has a reasonable hope of 
tracking down what "Parent" actually is.

I'm not necessarily yelling at you, Andy. It seems that most 
package developers are going down this slope. It stinks.


- Gordon



From jeremy at beopen.com  Thu Jun  8 00:06:29 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 18:06:29 -0400 (EDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <1251707300-11412775@hypernet.com>
References: <393eb52b.47053339@post.demon.co.uk>
	<1251707300-11412775@hypernet.com>
Message-ID: <14654.51045.18807.74677@localhost.localdomain>

Gordon's comments are on the money.  An import in a module inside a
package should be fully qualified.  I'd put that in the style guide if
it were up to me (and, of course, it's not).

Jeremy



From bwarsaw at python.org  Thu Jun  8 00:38:02 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Wed, 7 Jun 2000 18:38:02 -0400 (EDT)
Subject: [Python-Dev] Package ambiguities
References: <393eb52b.47053339@post.demon.co.uk>
	<1251707300-11412775@hypernet.com>
	<14654.51045.18807.74677@localhost.localdomain>
Message-ID: <14654.52938.139406.371556@anthem.concentric.net>

>>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:

    JH> Gordon's comments are on the money.  An import in a module
    JH> inside a package should be fully qualified.  I'd put that in
    JH> the style guide if it were up to me (and, of course, it's
    JH> not).

I concur on both points.  BTW, one of the Things I'd Like To Do, is
update and flesh out the style guide.  It's incomplete in places and
out of date in others.  If someone else has the gumption to lead this
effort, I'd be happy to send my comments instead.

-Barry



From pingster at ilm.com  Thu Jun  8 00:39:28 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Wed, 7 Jun 2000 15:39:28 -0700 (PDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <1251707300-11412775@hypernet.com>
Message-ID: <Pine.SGI.3.96.1000607150444.428158l-100000@happy>

On Wed, 7 Jun 2000, Gordon McMillan wrote:
> I disagree with the moral.
> 
> If test.py uses "import A.parent" and changes references 
> accordingly, it works.

Correct.

Well, maybe there are two things going on here.

I agree that import * isn't usually a very good idea.

However, notice that the problem occurs even if the first line
of test.py is "import parent" (no star).  When you talk about
changing references accordingly, the real issue is referencing
"A.parent" rather than "parent".

In fact, if you change the first line to "from A.parent import *"
(not that i am advocating this!) -- it works.  In short:

    from parent import *    ...  Parent             doesn't work
    import parent           ...  parent.Parent      doesn't work
    
    from A.parent import *  ...  Parent             works
    import A.parent         ...  A.parent.Parent    works

The first two cases -- attempting to import "parent" -- are
only made possible by the fact that we're executing test.py
from within the A/ directory, and hence the confusion.


This problem is an "advanced" version of a simpler issue
which a friend of mine discovered and complained about
recently to me: the __main__ vs. module-name conflict.
Allow me to paraphrase his example.

Exhibit A:

    ---- spam.py ----
    import eggs

    def go():
        print "was", eggs.a
        eggs.a = 3
        print "now", eggs.a

    ---- eggs.py ----
    import spam

    a = 1

    def go():
        spam.go()
        print "finally", a

    if __name__ == "__main__": go()

    --- watch what happens ----
    % python eggs.py
    was 1
    now 3
    finally 1

    % python
    >>> import eggs
    >>> eggs.go()
    was 1
    now 3
    finally 3


Exhibit B:

    ---- one.py ----
    import two
    def go(): pass

    ---- two.py ----
    import one
    one.go()

    ---- watch what happens ----
    % python one.py

    % python two.py
    Traceback (innermost last):
      File "two.py", line 1, in ?
        import one
      File "./one.py", line 1, in ?
        import two
      File "./two.py", line 2, in ?
        one.go()
    AttributeError: go
    Exit 1

    % python
    >>> import one
    Traceback (innermost last):
      File "<stdin>", line 1, in ?
      File "./one.py", line 1, in ?
        import two
      File "./two.py", line 2, in ?
        one.go()
    AttributeError: go
    >>> import two
    >>> 


The facts that eggs.a appears to behave differently in Exhibit A,
and that one.py can be run but two.py cannot, yet "two" can be
imported and "one" cannot, in Exhibit B, both result from the
duplication namespaces in __main__ and in a module.

Normally, this only affects the main file that you are running,
the one with the __main__ namespace.  However, attempting to run
scripts in package directories allows this problem to propagate
further into the duplication of other modules:

    __main__ imports parent which imports child
    A.test imports A.parent which imports A.child

...and that can cause duplicate classes all over the place,
which is what happened to Andy.


My friend was quite irked by the existence of __main__, citing
it as the culprit for this duplication.  But naturally Python
can't always know the name of the script being run -- in the
case of a file ending in .py, perhaps, it's easy, but the script
might come from a pipe, for example.  So eliminating __main__
doesn't seem like a feasible response.

Depending how "real" you consider this problem, leaving things
as they are and instructing people in the discipline of keeping
modules and scripts separated may be the best response.

I bet this crops up all the time in those "testing" sections
of modules that use the 'if __name__ == "__main__"' convention,
though...


-- ?!ng

"Computers are useless.  They can only give you answers."
    -- Pablo Picasso




From petrilli at amber.org  Thu Jun  8 00:51:50 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Wed, 7 Jun 2000 18:51:50 -0400
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <14654.52938.139406.371556@anthem.concentric.net>; from bwarsaw@python.org on Wed, Jun 07, 2000 at 06:38:02PM -0400
References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> <14654.52938.139406.371556@anthem.concentric.net>
Message-ID: <20000607185150.A29156@trump.amber.org>

Barry A. Warsaw [bwarsaw at python.org] wrote:
> 
> >>>>> "JH" == Jeremy Hylton <jeremy at beopen.com> writes:
> 
>     JH> Gordon's comments are on the money.  An import in a module
>     JH> inside a package should be fully qualified.  I'd put that in
>     JH> the style guide if it were up to me (and, of course, it's
>     JH> not).
> 
> I concur on both points.  BTW, one of the Things I'd Like To Do, is
> update and flesh out the style guide.  It's incomplete in places and
> out of date in others.  If someone else has the gumption to lead this
> effort, I'd be happy to send my comments instead.

Something we futzed with at Digital Creations was "commentable" or
discussable web pages.  This would be a great use for this.  If you
took and made each basic topic/issue a page, and let people "discuss"
them.  A nice threaded discussion could add a lot of insight.   This
is versus a wiki where it's more "free for all", which isn't really
appropraiate for a "guide".

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From pingster at ilm.com  Thu Jun  8 00:48:29 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Wed, 7 Jun 2000 15:48:29 -0700 (PDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <20000607185150.A29156@trump.amber.org>
Message-ID: <Pine.SGI.3.96.1000607154751.428158n-100000@happy>

On Wed, 7 Jun 2000, Christopher Petrilli wrote:
> Something we futzed with at Digital Creations was "commentable" or
> discussable web pages.  This would be a great use for this.  If you
> took and made each basic topic/issue a page, and let people "discuss"
> them.  A nice threaded discussion could add a lot of insight.   This
> is versus a wiki where it's more "free for all", which isn't really
> appropraiate for a "guide".

Well, y'all could go nuts marking up the style guide with Crit.

    http://crit.org/


...or marking up anything else on the whole Web, for that matter. :)



-- ?!ng

"To be human is to continually change.  Your desire to remain what
you are is what ultimately limits you."
    -- The Puppet Master, Ghost in the Shell




From jeremy at beopen.com  Thu Jun  8 01:00:36 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 7 Jun 2000 19:00:36 -0400 (EDT)
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <Pine.SGI.3.96.1000607150444.428158l-100000@happy>
References: <1251707300-11412775@hypernet.com>
	<Pine.SGI.3.96.1000607150444.428158l-100000@happy>
Message-ID: <14654.54292.711289.254224@localhost.localdomain>

>In fact, if you change the first line to "from A.parent import *"
>(not that i am advocating this!) -- it works.  In short:
>
>    from parent import *    ...  Parent             doesn't work
>    import parent           ...  parent.Parent      doesn't work
>    
>    from A.parent import *  ...  Parent             works
>    import A.parent         ...  A.parent.Parent    works

One other possibility that ought to work (?)

    from A import parent

Jeremy



From gmcm at hypernet.com  Thu Jun  8 01:47:47 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 7 Jun 2000 19:47:47 -0400
Subject: [Python-Dev] Package ambiguities
In-Reply-To: <Pine.SGI.3.96.1000607150444.428158l-100000@happy>
References: <1251707300-11412775@hypernet.com>
Message-ID: <1251700795-11803988@hypernet.com>

Ka-Ping wrote:

> ... In short:
> 
>     from parent import *    ...  Parent             doesn't work
>     import parent           ...  parent.Parent      doesn't work
> 
>     from A.parent import *  ...  Parent             works
>     import A.parent         ...  A.parent.Parent    works

Right. That's why I cast relative imports as evil.

> This problem is an "advanced" version of a simpler issue
> which a friend of mine discovered and complained about
> recently to me: the __main__ vs. module-name conflict.

This comes up a whole lot. In those periods where I have the 
time, energy and patience to monitor c.l.py closely, I've seen 
this come up 4 or 5 times in one week. Almost always in 
conjunction with import *.

I can live with explaining how __main__ is special. That's one 
of those "you only have to explain it once" problems.

But the import * problems (name hiding, the fact that 
assignments aren't seen) and relative imports are things that 
come up over and over again, and trip up even experienced 
people (and them more than once).



- Gordon



From gstein at lyra.org  Thu Jun  8 04:30:14 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 19:30:14 -0700
Subject: [Python-Dev] Idea: emulating _locale
In-Reply-To: <393E2304.4BE8CDE0@lemburg.com>; from mal@lemburg.com on Wed, Jun 07, 2000 at 12:25:08PM +0200
References: <m12zcE0-000DifC@artcom0.artcom-gmbh.de> <393E2304.4BE8CDE0@lemburg.com>
Message-ID: <20000607193014.P3348@lyra.org>

On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote:
>...
> Peter Funk wrote:
>...
> > > + ### C lib locale APIs
> > > +
> > > + from _locale import *
> > 
> > Wouldn't it be clever to provide some dummy stubs on those platforms, where
> > the _locale module was not enabled?
> > 
> > try:
> >     from _locale import *
> > except:
> >     def setlocale(....
> >     def localeconv(....
> >     ...
> > 
> > Especially the MacOS 1.5.2 release provided by Jack Jansen was
> > compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
> > is still disabled per default in 'Modules/Setup.in'.  I didn't had
> > a look into the current CVS though, so this may have changed.
> > 
> > I think the name aliasing tables might be also useful on those
> > systems lacking locale support in their C-library.
> 
> setlocale and localeconv are ANSI C and Python requires an ANSI C
> compiler, so there should be no problem (at least in theory).
> 
> If there is a problem, adding the missing symbols would
> be no problem: the APIs could always report locale 'C'
> and its numeric settings.

An ANSI C compiler and the ANSI C library are very different. Just because
Python requires an ANSI compiler (or close to it), does NOT mean that we can
or should depend upon particular elements in the library.

IMO, we should follow Peter's advice and have stubs for the platforms where
_locale is not built.

Cheers,
-g

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



From gstein at lyra.org  Thu Jun  8 04:35:37 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 19:35:37 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.21,2.22
In-Reply-To: <200006070913.CAA18060@slayer.i.sourceforge.net>; from lemburg@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 02:13:24AM -0700
References: <200006070913.CAA18060@slayer.i.sourceforge.net>
Message-ID: <20000607193537.Q3348@lyra.org>

On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote:
> Update of /cvsroot/python/python/dist/src/Objects
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects
> 
> Modified Files:
> 	unicodeobject.c 
> Log Message:
> Marc-Andre Lemburg <mal at lemburg.com>:
> Change the default encoding to 'ascii' (it was previously
> defined as UTF-8).
> 
> Note: The implementation still uses UTF-8 to implement
> the buffer protocol, so C APIs will still see UTF-8. This
> is on purpose: rather than fixing the Unicode implementation,
> the C APIs should be made Unicode aware.

I'm a little confused on where this gets applied. Is this when somebody says
"str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when
somebody says "unicode(str)" and we expect <str> to be ASCII?

Cheers,
-g

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



From gstein at lyra.org  Thu Jun  8 05:06:24 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 20:06:24 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26
In-Reply-To: <200006080008.RAA15980@slayer.i.sourceforge.net>; from gward@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 05:08:17PM -0700
References: <200006080008.RAA15980@slayer.i.sourceforge.net>
Message-ID: <20000607200624.R3348@lyra.org>

On Wed, Jun 07, 2000 at 05:08:17PM -0700, Greg Ward wrote:
> Update of /cvsroot/python/distutils/distutils/command
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv15881
> 
> Modified Files:
> 	sdist.py 
> Log Message:
> Made all debug output go through the 'debug_print()' method instead of
> directly printing to stdout.  This was a bit more work than it sounds like
> it should have been:
>   * turned 'select_pattern()' and 'exclude_pattern()' from functions into
>     methods, so they can refer to 'self' to access the method

You wouldn't have to do this if you make debug_print() a function. There is
nothing in debug_print() that requires "self", so its existence as a method
is suspect in the first place. Considering the fallout changes, I'd say move
debug_print() to a plain function (in "utils").

Unless you were planning on more stuff in there; if so, then a comment in
debug_print would be nice.

>...
> ***************
> *** 297,301 ****
>               if (cur_dir == dir and
>                   (pattern_re is None or pattern_re.match (cur_base))):
> !                 print "removing %s" % self.files[i]
>                   del self.files[i]
>   
> --- 298,302 ----
>               if (cur_dir == dir and
>                   (pattern_re is None or pattern_re.match (cur_base))):
> !                 self.debug_print("removing %s" % self.files[i])
>                   del self.files[i]

Gah... "pattern_re.match (cur_base)" ...

You do realize that God intended there to be no spaces between a function
name and the opening paren? Heretic!

:-)

Really -- I have noticed this throughout a lot of the distutils code. That
space in there is really awful. It reduces the "binding" of the name to the
paren, which changes the meaning during a quick read. Put another way: when
you skim code, NAME( is a function call and NAME ( is something else. A
space after a name usually indicates the name is participating in an
expression, rather than being used as a function name. Then, you hit the
paren and go "what the heck? <pause> oh. a function call."

Please... can they be removed?

Cheers,
-g

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



From gstein at lyra.org  Thu Jun  8 06:05:55 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 7 Jun 2000 21:05:55 -0700
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.)
In-Reply-To: <Pine.GSO.4.10.10006071731200.2293-100000@sundial>; from moshez@math.huji.ac.il on Wed, Jun 07, 2000 at 05:33:10PM +0300
References: <20000607101146.D5559@ludwig.cnri.reston.va.us> <Pine.GSO.4.10.10006071731200.2293-100000@sundial>
Message-ID: <20000607210555.X3348@lyra.org>

On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote:
> On Wed, 7 Jun 2000, Greg Ward wrote:
> 
> > CNRI has absolutely no moral right to it (although probably some legal
> > right), I'd prefer to sign it away to Guido.  Or optionally, to some
> > legal fiction that represents the Python community; preferably *not* the
> > Python Consortium, as long as CNRI is in any way connected.
> 
> Who's in charge of the PSA?

CNRI

Effectively, the PSA is a legal fiction for collecting donations to further
the development of Python. The Consortium is similar, but members have the
actual/explicit capability to steer Python's development. I believe this
ability to steer the development is (was?) rooted in the fact that CNRI
employed Guido. I have no idea how that will work now -- the "steering" will
(essentially) have to rely entirely on Guido's good graces. Guido is an
excellent listener to people's needs, so there is no immediate problem here.

> Or should we form *another* non-profit, and sign it over to it?

The Apache Software Foundation is already a legal, formed, non-profit
corporation. If the desire is to transfer copyright to a non-profit, then
I'd recommend reusing the ASF rather than trying to start a new one.
Recognize that running a company (even a non-profit) is not a "zero cost"
item. Somebody would have to put that time in.

CNRI is also non-profit, but its members/board/directors/etc are not as Open
Source minded as the ASF.

> (Personally, I couldn't care less who I transfer copyright over my Python
> contributions to -- I'd put it in the public domain if that's what it
> took)

As Barry said: license and copyright are different. Since you own the
copyright, then you *can* put it into the public domain Right Now. I've done
that with some of my modules (e.g. qp_xml and imputil).

Here is the header from qp_xml.py:

#
# qp_xml: Quick Parsing for XML
#
# Written by Greg Stein. Public Domain.
# No Copyright, no Rights Reserved, and no Warranties.
#

Fun, huh? :-)

On the other hand, I have given Guido two pieces of code: httplib.py and
davlib.py:

#
# DAV client library
#
# Copyright (C) 1998-1999 Guido van Rossum. All Rights Reserved.
# Written by Greg Stein. Given to Guido. Licensed using the Python license.
#

Oh. I need to update his copyright year :-)

Want to know something really funny? Presuming my httplib.py goes into the
Python distribution, that will be the first piece of code that Guido truly
owns in Python. All the other code he wrote is owned by CWI or CNRI....

Cheers,
-g

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



From fredrik at pythonware.com  Thu Jun  8 10:30:39 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 8 Jun 2000 10:30:39 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26
References: <200006080008.RAA15980@slayer.i.sourceforge.net> <20000607200624.R3348@lyra.org>
Message-ID: <009501bfd123$d4b2c750$0500a8c0@secret.pythonware.com>

greg wrote:
> Gah... "pattern_re.match (cur_base)" ...
> 
> You do realize that God intended there to be no spaces between a function
> name and the opening paren? Heretic!

http://www.python.org/doc/essays/styleguide.html

    ...
    I hate whitespace in the following places: 
    ...
    Immediately before the open parenthesis that starts the argument
    list of a function call, as in spam (1). Always write this as spam(1).
    ...
    Don't bother to argue with me on any of the above
    ...

</F>




From andy at robanal.demon.co.uk  Thu Jun  8 10:42:46 2000
From: andy at robanal.demon.co.uk (Andy Robinson)
Date: Thu, 8 Jun 2000 09:42:46 +0100
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <20000608030555.532221CDEF@dinsdale.python.org>
Message-ID: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk>

Thanks for all the replies.  We really need a 'style guide'
on package use, so I hope this example can be thrashed
out and used to help others.  We need to decide something
and release next week, and also provide good docs for
other users who will be new to Python.

Apart from the ambiguity, which was a surprise but which 
we can work around, I have some general questions on the
"right thing".  Here are my examples:

1. use of __init__ to save users work
------------------------------------ 
ReportLab has a subpackage called 'platypus' which we have
just reorganized and not yet released.  The division
into subpackages is clear - each exposes a different
kind of functionality - but the division of each
package into modules is based on keeping a sane 
length for each and not on providing a friendly
user interface.

reportlab
    pdfgen
        canvas.py  defines class Canvas
        textobject.py defines class TextObject
        pathobject.py defines class PathObject
    platypus
        (the same problem, but 3x worse)
    lib
        (loads of modules, all independent)

We reached a point where users need to import eight or 
ten classes to do useful work and were having to put eight 
or ten different import lines at the top of every script.  
This just feels dumb and wrong.

So, the 'least messy' idea was to put __init__.py
methods in each subpackage which explicitly import
what they need.  (We have not used "import *")

---reportlab/pdfgen/__init__.py--------
from canvas import Canvas
from textobject.py import TextObject
from pathobject.py impory PathObject

Then users can just do:
from reportlab.pdfgen import Canvas, PathObject, TextObject

It seems that this (a) makes life easier for users, and
(b) gives us freedom to refactor code as it grows, without
changing the user interface.  

Is this style evil?  If so, why? 


2. Ambiguities running scripts within package
---------------------------------------------
We have various test functions scattered 
throughout our distribution.  A control script iterates
through the lot and kicks them off before every release,
executing everything with an 'if __name__=='__main__'
handler.  If these were standalone scripts just for 
testing, they could import "reportlab.platypus.tables"
or whatever.  But if I just want to put a test
routine at the end of "reportlab.platypus.tables"
then I seem destined to run into exactly the ambiguity
outlined before.  

Should test scripts all be moved out of the package?  
Indeed, is Python behaving the way it ought to?

3. Preferred subpackage import technique
----------------------------------------
I have two scripts 'spam.py' and 'eggs.py' in
subpackage 'A.B'.  spam imports eggs.
Should it say...
   import eggs
or...
   import A.B.eggs?

Both work sometimes, but can lead to different
behavious sometimes.  Which is the preferred style?

Thanks,

Andy Robinson




From pf at artcom-gmbh.de  Thu Jun  8 11:35:14 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Thu, 8 Jun 2000 11:35:14 +0200 (MEST)
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk> from Andy Robinson at "Jun 8, 2000  9:42:46 am"
Message-ID: <m12zyiZ-000DieC@artcom0.artcom-gmbh.de>

Hi Andy,  

> Thanks for all the replies.  
> We really need a 'style guide' on package use, 

On 'import', packages and modules:
----------------------------------
You should definitely have a look at the approach used by Greg
McFarlane in his 'Pmw' package.  In particular at his PmwLoader class
and the Pmw.def.  For my own project I've simplified and somewhat
generalized his approach to dynamic and lazy importing.  I posted a
preliminary implemantation of this to comp.lang.python a while ago
but didn't got much feedback.  May be due to fact, that I had to repost
the thing, because the TABs went wrong in the first try :-(

[...]
> Is this style evil?  If so, why? 

I believe it will get really hard to come up with a 'namespace style guide' 
which everybody can aggree on.  But who cares: let's start a rant:

-->  IMO 'from ... import ...' is EVIL and its use should be banned!  <--

Why?  Because if software becomes bigger (> 100k LOC), these
unqualified names definitely become a maintaince nightmare, since you
didn't know what names are defined in the module you are currently
staring at and what names come from the "outside world".

I believe Python inherited two of its three forms of import syntax at 
least in part from its anchestors Modula-2 and Modula-3.  

My perception of this import-problem may be blurred by programming in
Modula-2 in our company since 1985, where the code base now is about ~1
Mio. LOC.  Some of the older code contains still modules using a lot of
'FROM foobar IMPORT ....;' lines in the header.  These have usually
been harder to read and understand by new employees than those having
'IMPORT foobar;' in the header and than using 'foobar.component'
everywhere in the code body below.

from .... import * is *EVEN MORE EVIL*.

Well: at least if people use 'from' to import arbitrary objects and
classes.  Using 'from package.subpackage import module' is an idiom,
with which I can live with comfortably.

> Should test scripts all be moved out of the package?  

This would defeat the use of Tim Peters wonderful 'doctest' module.
I'm still thinking, 'doctest' should be made part of the standard
library in order to give the publicity this elegant approach deserves.

Regards, Peter



From Vladimir.Marangozov at inrialpes.fr  Thu Jun  8 12:27:10 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Thu, 8 Jun 2000 12:27:10 +0200 (CEST)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <20000607174148.A6801@thyrsus.com> from "Eric S. Raymond" at Jun 07, 2000 05:41:48 PM
Message-ID: <200006081027.MAA02445@python.inrialpes.fr>

[Jeremy Hylton]
>
> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?

The content is good. Some wishes on its presentation, not taking into
account any cosmetic changes.

With my webmaster's hat, I would say:

1. Make the content accessible, i.e. compliant to the standards
   HTML tidy does a pretty good job in cleaning up existing Web pages
   I would suggest sticking with valid XHTML 1.0 transitional or HTML 4.x
   transitional.

2. Use CSS -- not too much, though, given its growing but still limited
   support. I am using myself parts of CSS1. My approach is to use styles
   *and* attributes (which is redundant, for now). Browsers that understand
   styles would honor them, while those that don't would take into account
   the attributes. The aim is to have the same end result. With the evolution
   of the browsers, the attributes would disappear.

   A compromise that introduces styles smoothly.

3. Have a comprehensible site map for direct access to the major topics.
   I tend to like ours which is convenient for small to medium sized sites
   (http://www.inrialpes.fr/plansite.html)

4. Do not use frames, do not use JavaScript or similar, do not use anything
   that hurts content accessibility.

[Eric S. Raymond]
> 
>  My top wishlist item is "Burn all your GIFs".

This seems to be an important symbol for an organization with an Open Source
spirit.  Hopefully, a gif2png batch processing should make things easier.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From gstein at lyra.org  Thu Jun  8 13:43:24 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 8 Jun 2000 04:43:24 -0700
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <m12zyiZ-000DieC@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Thu, Jun 08, 2000 at 11:35:14AM +0200
References: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk> <m12zyiZ-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <20000608044324.L3348@lyra.org>

On Thu, Jun 08, 2000 at 11:35:14AM +0200, Peter Funk wrote:
>...
> > Is this style evil?  If so, why? 
> 
> I believe it will get really hard to come up with a 'namespace style guide' 
> which everybody can aggree on.  But who cares: let's start a rant:
> 
> -->  IMO 'from ... import ...' is EVIL and its use should be banned!  <--

You are being overly strict here. I use this all the time:

from module import submodule
...
submodule.Class()

or even

from module.submodule import subsub
...
subsub.Blargle()

In other words, "from package import module" is a Fine Thing. It can
simplify your code without hiding where the symbols come from.

In general, I agree with you: importing symbols from a module into your
namespace is a Bad Thing.

Cheers,
-g

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



From fdrake at beopen.com  Thu Jun  8 14:37:04 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 8 Jun 2000 08:37:04 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <200006081027.MAA02445@python.inrialpes.fr>
References: <20000607174148.A6801@thyrsus.com>
	<200006081027.MAA02445@python.inrialpes.fr>
Message-ID: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>

Vladimir Marangozov writes:
 > 2. Use CSS -- not too much, though, given its growing but still limited
 >    support. I am using myself parts of CSS1. My approach is to use styles
 >    *and* attributes (which is redundant, for now). Browsers that understand
 >    styles would honor them, while those that don't would take into account
 >    the attributes. The aim is to have the same end result. With the evolution
 >    of the browsers, the attributes would disappear.

  The approach to CSS I've taken with the documentation is to use
attributes for anything that's really needed to make the presentation
readable and then an external CSS stylesheet for everything else.
This seems like a reasonable approach to me, and avoids including too
much duplicate information.  This also seems like the best way to
maintain support for older browsers.
  Perhaps we should collect browser statistics on python.org so we'll
know how many "legacy" browsers are in use?  I would be surprised if
many of the text-mode browsers support CSS well (and there are several
being actively worked on these days, so please don't tell me they
don't count!).

 > 4. Do not use frames, do not use JavaScript or similar, do not use anything
 >    that hurts content accessibility.

  I do have some JavaScript on python.org, but it's only to make data
entry in a form a little easier by making adjustments to related
fields, so it remains completely operational without JavaScript.  I
don't think there's currently any required JavaScript.  And I have yet
to see a frame, thank goodness!

[Eric S. Raymond]
 > 
 >  My top wishlist item is "Burn all your GIFs".

  Is it more important than accessibility?  This is a real issue for
legacy browsers, especially on minority platforms.  One of the big
wins for Python is that it is as portable as it is.  Does that matter
if information is hard to get to?
  A good reason to avoid using images for anything that isn't
cosmetic!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From pf at artcom-gmbh.de  Thu Jun  8 14:28:11 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Thu, 8 Jun 2000 14:28:11 +0200 (MEST)
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <20000608044324.L3348@lyra.org> from Greg Stein at "Jun 8, 2000  4:43:24 am"
Message-ID: <m1301Pv-000DieC@artcom0.artcom-gmbh.de>

Hi Greg,

[me]
> > -->  IMO 'from ... import ...' is EVIL and its use should be banned!  <--

[Greg Stein]:
> You are being overly strict here. I use this all the time:
> 
> from module import submodule
> ...
> submodule.Class()
> 
> or even
> 
> from module.submodule import subsub
> ...
> subsub.Blargle()

Okay.  Later in my rant I wrote:

< Well: at least if people use 'from' to import arbitrary objects and
< classes.  Using 'from package.subpackage import module' is an idiom,
< with which I can live with comfortably.

[Greg Stein]:
> In other words, "from package import module" is a Fine Thing. It can
> simplify your code without hiding where the symbols come from.

Yes, you are right.

But if you put the facade pattern[*] into use within such packages,
this will even simplify your live, if you later have to redesign
the internal substructure of your package.

[*] Design patterns and especially the "facade pattern" were AFAIK 
    introduced in the so called "Gang of four" book: "Design Patterns -
    Elements of Reusable Object-Oriented Software", Addison Wesley, 1995.

    The somewhat similar "whole part" design pattern is discussed 
    in the book "A System of Patterns" written by Buschmann, Meunier, 
    Rohnert, Sommerlad, Stal; published by John Wiley & Sons, New York; 1996; 
    ISBN 0 471 95869 7

> In general, I agree with you: importing symbols from a module into your
> namespace is a Bad Thing.

Fine.  Consensus gives a warm and fuzzy feeling. ;-)

Regards, Peter



From esr at thyrsus.com  Thu Jun  8 14:53:51 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 8 Jun 2000 08:53:51 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 08, 2000 at 08:37:04AM -0400
References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>
Message-ID: <20000608085351.A9299@thyrsus.com>

Fred L. Drake, Jr. <fdrake at beopen.com>:
> [Eric S. Raymond]
>  > 
>  >  My top wishlist item is "Burn all your GIFs".
> 
>   Is it more important than accessibility?  This is a real issue for
> legacy browsers, especially on minority platforms.  One of the big
> wins for Python is that it is as portable as it is.  Does that matter
> if information is hard to get to?

Go check out the PNG site's census of PNG support in "legacy"
browsers. Basically, as long as your PNGs don't use transparency or
animation, you're fine.  You've already had the good taste to eschew
animation. I don't think you're using transparency anywhere that 
simply matteing the image on a white background won't fix it -- and
gif2png has an option to do that.

>   A good reason to avoid using images for anything that isn't
> cosmetic!

I agree with that.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Sometimes the law defends plunder and participates in it. Sometimes
the law places the whole apparatus of judges, police, prisons and
gendarmes at the service of the plunderers, and treats the victim --
when he defends himself -- as a criminal.
	-- Frederic Bastiat, "The Law"



From jeremy at beopen.com  Thu Jun  8 15:58:42 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 8 Jun 2000 09:58:42 -0400 (EDT)
Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.)
In-Reply-To: <20000607210555.X3348@lyra.org>
References: <20000607101146.D5559@ludwig.cnri.reston.va.us>
	<Pine.GSO.4.10.10006071731200.2293-100000@sundial>
	<20000607210555.X3348@lyra.org>
Message-ID: <14655.42642.608768.433695@localhost.localdomain>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

  GS> On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote:
  >> On Wed, 7 Jun 2000, Greg Ward wrote:
  >> 
  >> > CNRI has absolutely no moral right to it (although probably
  >> some legal > right), I'd prefer to sign it away to Guido.  Or
  >> optionally, to some > legal fiction that represents the Python
  >> community; preferably *not* the > Python Consortium, as long as
  >> CNRI is in any way connected.
  >> 
  >> Who's in charge of the PSA?

  GS> CNRI

  GS> Effectively, the PSA is a legal fiction for collecting donations
  GS> to further the development of Python. The Consortium is similar,
  GS> but members have the actual/explicit capability to steer
  GS> Python's development. I believe this ability to steer the
  GS> development is (was?) rooted in the fact that CNRI employed
  GS> Guido. I have no idea how that will work now -- the "steering"
  GS> will (essentially) have to rely entirely on Guido's good
  GS> graces. Guido is an excellent listener to people's needs, so
  GS> there is no immediate problem here.

The description of the PSA isn't exactly right.  The PSA FAQ has an
official explanation, which may not be right either, but at least it's
what CNRI wants you to think.  (And it may be right; I don't mean to
suggest a nefarious plot, just that the relationship is convoluted
enough that the explanation could be wrong.)

http://www.python.org/psa/FAQ.html

An abbreviated version follows:

|Where does the money from membership fees go and who pays the rest?
|
|    The money goes towards the salary of those who maintain and
|    coordinate the Python web site, ftp server, mailing lists,
|    conference expenses etc....  The case for these expenditures is
|    that a seed community is being incubated. CNRI officers and
|    directors see proof of the existence of such a community from the
|    fact that some members of that community are willing to pay some
|    of their own money to foster the activity.
|
|Who funds Python's development?
|    PSA fees do not fund the Python development effort....


CNRI is no longer maintaining python.org, although it still owns the
domain and maintains the equipment it runs on.  The existence of a
community should be obvious now, without the need for people to pay
money to prove it.

Jeremy

    



From skip at mojam.com  Thu Jun  8 16:08:13 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 8 Jun 2000 09:08:13 -0500
Subject: [Python-Dev] impact of cycle gc...
Message-ID: <200006081408.JAA03136@beluga.mojam.com>

I spent a little time poking around with a very simple test script
(appended) that makes use of Neil's cycle gc patch.  It measures the time it
takes to instantiate and delete a cycle-producing instance 100,000 times
(based upon a report in python-bugs).  For vanilla 1.6a2 ("./configure" ;
make") I got the following (last of six runs):

    memory usage @ start: 5560
    clock: 1.33 elapsed: 1.34805500507
    memory usage @ end: 18816

For 1.6a2 configured --with-cycle-gc ("./configure --with-cycle-gc ; make")
I got the following (also the last of six runs):

    memory usage @ start: 5576
    clock: 2.34 elapsed: 2.33785700798
    memory usage @ end: 5576

I was very impressed with the memory usage, but dismayed at the increased
execution time (about 75% more).  Of course, this is a test script that is
bound to show the potential performance penalty in the worst possible light.
Maybe pystone will be more indicative of the performance hit we can expect
from it.  (There's a new one - pystone.py being a better indicator of true
system performance than some other test script!)

Plain:

    Pystone(1.1) time for 10000 passes = 1.76
    This machine benchmarks at 5681.82 pystones/second

--with-cycle-gc:

    Pystone(1.1) time for 10000 passes = 1.83
    This machine benchmarks at 5464.48 pystones/second

That suggests something more like a 4% performance penalty.  I suspect that
may be the lower limit.  While I haven't looked at pystone recently, I doubt
it creates any cyclic garbage.

My next step will be to try it out on my development database server and see 
what happens.

just-another-data-point-ly y'rs,

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
"We have become ... the stewards of life's continuity on earth.  We did not
ask for this role...  We may not be suited to it, but here we are."
- Stephen Jay Gould



class fred:
    def __init__(self):
        self.indirectFunc = self.theFunc

    def theFunc(self):
        return "blah"

def test():
    f = fred()
    del f


if __name__ == "__main__":
    import os, time, sys
    sys.stdout.write("memory usage @ start: ")
    sys.stdout.flush()
    os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'")
    t = time.clock(), time.time()
    for x in xrange(100000):
        test()
    print "clock:", time.clock()-t[0], "elapsed:", time.time()-t[1]
    sys.stdout.write("memory usage @ end: ")
    sys.stdout.flush()
    os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'")



From gmcm at hypernet.com  Thu Jun  8 16:48:01 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 8 Jun 2000 10:48:01 -0400
Subject: [Python-Dev] Package Style Guide
In-Reply-To: <PGECLPOBGNBNKHNAGIJHIEILCCAA.andy@robanal.demon.co.uk>
References: <20000608030555.532221CDEF@dinsdale.python.org>
Message-ID: <1251646781-15052905@hypernet.com>

Andy wrote:

> 1. use of __init__ to save users work
[package structure]
> reportlab
>     pdfgen
>         canvas.py  defines class Canvas
>         textobject.py defines class TextObject
>         pathobject.py defines class PathObject
>     platypus
>         (the same problem, but 3x worse)
>     lib
>         (loads of modules, all independent)

> ---reportlab/pdfgen/__init__.py--------
> from canvas import Canvas
> from textobject.py import TextObject
> from pathobject.py impory PathObject

I would suggest that these not use relative names. 

from reportlab.pdfgen.canvas import Canvas

will ensure that Canvas is only found in one way (no matter 
where the script is, or rather, what sys.path[0] evaluates to at 
import time).

Your other choice is to disallow any scripts within reportlab/ 
and deliver 220 V shocks to any user who starts Python 
anyplace within reportlab/ (or otherwise lets any part of 
sys.path evaluate to anything within reportlab/).
 
> Then users can just do:
> from reportlab.pdfgen import Canvas, PathObject, TextObject
> 
> It seems that this (a) makes life easier for users, and
> (b) gives us freedom to refactor code as it grows, without
> changing the user interface.  

Since you're doing this for "convenience", another option is to 
provide convenience methods:

def newCanvas():
  return reportlab.pdfgen.canvas.Canvas()

> 2. Ambiguities running scripts within package
> ---------------------------------------------

> Should test scripts all be moved out of the package?  
> Indeed, is Python behaving the way it ought to?

If you use relative imports, yes. But even so, you incur a risk 
in using relative imports (see above). And you only do it from 
laziness. So I say don't use relative imports.

> 3. Preferred subpackage import technique
> ----------------------------------------
> I have two scripts 'spam.py' and 'eggs.py' in
> subpackage 'A.B'.  spam imports eggs.
> Should it say...
>    import eggs
> or...
>    import A.B.eggs?

You know what I'm going to say...

- Gordon



From mal at lemburg.com  Thu Jun  8 16:48:49 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 16:48:49 +0200
Subject: [Python-Dev] revamped Python web site
References: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <393FB251.6100175B@lemburg.com>

Jeremy Hylton wrote:
> 
> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?
> 
> If you've got any ideas, please get back to me soon.

Why not turn python.org into a Python portal site with all the
jazz that goes with it, e.g. newsletters, browsable news
forums for different news aspects (business news, new developments,
press references, Python related meetings, etc.), customization
of the information layout, email notification when things
change, chat forums, a Python knowledge base, etc. etc.

The reasoning is that Python is starting to go business and
the site should reflect this move. As more
companies start producing Python tools, I think it might
even be worthwhile considering Python related marketing
on the Python site, e.g. small banners, external links, etc.
This would help finance the site and its administrators.

As far as content goes, I think Python.org is hardly beatable :-)
What's missing is some more service to push its fun factor
which in return pushes Python's acceptance.

Anyway, just a thought...
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From mal at lemburg.com  Thu Jun  8 16:54:01 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 16:54:01 +0200
Subject: [Python-Dev] Package ambiguities
References: <393eb52b.47053339@post.demon.co.uk>
		<1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain>
Message-ID: <393FB389.893D20E3@lemburg.com>

Jeremy Hylton wrote:
> 
> Gordon's comments are on the money.  An import in a module inside a
> package should be fully qualified.  I'd put that in the style guide if
> it were up to me (and, of course, it's not).

+1 from here :-)

I usually write things like this:

from mx.DateTime import now
print 'The time is', now()

If you don't do so, you'll run into strange problems, the most
subtle one I've encountered is with pickled objects... if unpickled
inside the same package they can cause the same module to
be loaded *twice* with all the consequences attached to this 
(e.g. issubclass() no longer works).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From mal at lemburg.com  Thu Jun  8 17:20:23 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 17:20:23 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects 
 unicodeobject.c,2.21,2.22
References: <200006070913.CAA18060@slayer.i.sourceforge.net> <20000607193537.Q3348@lyra.org>
Message-ID: <393FB9B7.B93A7C61@lemburg.com>

Greg Stein wrote:
> 
> On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote:
> > Update of /cvsroot/python/python/dist/src/Objects
> > In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects
> >
> > Modified Files:
> >       unicodeobject.c
> > Log Message:
> > Marc-Andre Lemburg <mal at lemburg.com>:
> > Change the default encoding to 'ascii' (it was previously
> > defined as UTF-8).
> >
> > Note: The implementation still uses UTF-8 to implement
> > the buffer protocol, so C APIs will still see UTF-8. This
> > is on purpose: rather than fixing the Unicode implementation,
> > the C APIs should be made Unicode aware.
> 
> I'm a little confused on where this gets applied. Is this when somebody says
> "str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when
> somebody says "unicode(str)" and we expect <str> to be ASCII?

The buffer protocol is used for "s", "t" and "s#" argument
parsing in C. Since these pass back pointers to internal
buffers of the object which must be kept alive until the
object is GCed, there's no easy way to change the
encoding of that buffer. 

To play safe I left that buffer
encoded in UTF-8 (the hash value is also computed from the
UTF-8 encoding of the unicode value to make it compatible to
ASCII 8-bit strings).

Note that both str(unicode) and unicode(str) will use
the default encoding. %-formatting and comparisons also
use the default encoding.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From mal at lemburg.com  Thu Jun  8 17:08:45 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Jun 2000 17:08:45 +0200
Subject: [Python-Dev] Idea: emulating _locale
References: <m12zcE0-000DifC@artcom0.artcom-gmbh.de> <393E2304.4BE8CDE0@lemburg.com> <20000607193014.P3348@lyra.org>
Message-ID: <393FB6FD.AB0124E2@lemburg.com>

Greg Stein wrote:
> 
> On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote:
> >...
> > Peter Funk wrote:
> >...
> > > > + ### C lib locale APIs
> > > > +
> > > > + from _locale import *
> > >
> > > Wouldn't it be clever to provide some dummy stubs on those platforms, where
> > > the _locale module was not enabled?
> > >
> > > try:
> > >     from _locale import *
> > > except:
> > >     def setlocale(....
> > >     def localeconv(....
> > >     ...
> > >
> > > Especially the MacOS 1.5.2 release provided by Jack Jansen was
> > > compiled without '_locale'.  And at least in Python 1.6a2 '_locale'
> > > is still disabled per default in 'Modules/Setup.in'.  I didn't had
> > > a look into the current CVS though, so this may have changed.
> > >
> > > I think the name aliasing tables might be also useful on those
> > > systems lacking locale support in their C-library.
> >
> > setlocale and localeconv are ANSI C and Python requires an ANSI C
> > compiler, so there should be no problem (at least in theory).
> >
> > If there is a problem, adding the missing symbols would
> > be no problem: the APIs could always report locale 'C'
> > and its numeric settings.
> 
> An ANSI C compiler and the ANSI C library are very different. Just because
> Python requires an ANSI compiler (or close to it), does NOT mean that we can
> or should depend upon particular elements in the library.

Well, ok, it's POSIX.1 too, but...
 
> IMO, we should follow Peter's advice and have stubs for the platforms where
> _locale is not built.

...ok, since it doesn't hurt, I'll add some dummies to locale.py
which return the same thing as the 'C' locale.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From pingster at ilm.com  Thu Jun  8 19:10:46 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 8 Jun 2000 10:10:46 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26
In-Reply-To: <20000607200624.R3348@lyra.org>
Message-ID: <Pine.SGI.3.96.1000608100602.428158D-100000@happy>

On Wed, 7 Jun 2000, Greg Stein wrote:
> Gah... "pattern_re.match (cur_base)" ...
> 
> You do realize that God intended there to be no spaces between a function
> name and the opening paren? Heretic!
[...]
> Put another way: when
> you skim code, NAME( is a function call and NAME ( is something else. A
> space after a name usually indicates the name is participating in an
> expression, rather than being used as a function name.

Yesyesyes!

This is an absolute rule for me (in other languages too: in C, for
example, *always* a space between "if" or "for" and the open-paren).

I colourize based on this.  It's great -- the one green word on the
line stands out; it's the verb, and that lets me know what's going
on at a quick glance.

(My "Principle of Syntax Highlighting" is to highlight not by what
things are, but by what *role* they play.  Defining occurrence of
anything is a biggie.  Comments and docstrings are coloured alike;
docstrings are not data.  And so on.)


-- ?!ng




From klm at digicool.com  Thu Jun  8 20:38:32 2000
From: klm at digicool.com (Ken Manheimer)
Date: Thu, 8 Jun 2000 14:38:32 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com>

On Wed, 7 Jun 2000, Jeremy Hylton wrote:

> Say a startup company decided to put some resources behind the Python
> Web site -- a full-time Web master, some content developers, etc.
> What would you have them do?  What could be done to open up the site
> to the community and make it more responsive to developers and users?
> What's your wish list for content, services, etc.?
> 
> If you've got any ideas, please get back to me soon.

Here's some suggestions - i put things more important to me closer to the
top, more or less.

1. Delegation of sections to individuals or groups.  Eg:

  - topic guides - particular people get management of areas.  (Of
    course, i'd do this with zope, including zwiki pages as well as
    regular zope documents for the respective topic-guide managers
    to use in constructing their content - and for delegating or openning
    up portions of *their* sections to others...)

  - The humor page (i'm sad to see that languishing)

  - Other incidental stuff in the Documentation section of the current
    site

2. Community-contributed news and hints - portal-style membership/
   contribution of news items, reviewed for release or rejection (maybe
   with community-based reviewers voting) 

3. Vaults of parnassus already does this, but i'll still mention - 
   Contributed software/docs/etc - managed similar to moderated news
   postings, but with classification/cataloguing of artifacts, ability for
   people to vote on desirability for ranking purposes

5. Jobs board - job postings possibly also managed with news-style
   reviewing process

6. Subscription to pages, to get notifcations when they change (probably
   batched, so people don't get too many as something is undergoing
   development).

7. Discussion "area" for coordinating and collecting logs of IRC-style
   chats when hot-topics arise that need rendezvous.

8. Open community wiki(s) for growing interesting little worlds (and with
   my new zwiki nesting-organization features, it may not be too chaotic).

Ken
klm at digicool.com




From gvwilson at nevex.com  Thu Jun  8 20:45:37 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Thu, 8 Jun 2000 14:45:37 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com>
Message-ID: <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>

> Ken Manheimer said
> 3. Vaults of parnassus already does this, but i'll still mention - 
>    Contributed software/docs/etc - managed similar to moderated news
>    postings, but with classification/cataloguing of artifacts, ability for
>    people to vote on desirability for ranking purposes

I'd like to see the Vaults, Starship, and other sub-sites folded into, or
become subsections of, a larger Python site, so that I've got the same
kind of one-stop shopping that CPAN gives me.

Thanks,

Greg





From esr at thyrsus.com  Thu Jun  8 20:54:45 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 8 Jun 2000 14:54:45 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400
References: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com> <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>
Message-ID: <20000608145445.A10500@thyrsus.com>

Greg Wilson <gvwilson at nevex.com>:
> > Ken Manheimer said
> > 3. Vaults of parnassus already does this, but i'll still mention - 
> >    Contributed software/docs/etc - managed similar to moderated news
> >    postings, but with classification/cataloguing of artifacts, ability for
> >    people to vote on desirability for ranking purposes
> 
> I'd like to see the Vaults, Starship, and other sub-sites folded into, or
> become subsections of, a larger Python site, so that I've got the same
> kind of one-stop shopping that CPAN gives me.

Second that.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Such are a well regulated militia, composed of the freeholders,
citizen and husbandman, who take up arms to preserve their property,
as individuals, and their rights as freemen.
        -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" 
            referred to in the Second Amendment to the Constitution.



From gmcm at hypernet.com  Thu Jun  8 20:57:51 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 8 Jun 2000 14:57:51 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com>
References: <14654.48609.710990.321688@localhost.localdomain>
Message-ID: <1251631791-15954519@hypernet.com>


From fdrake at beopen.com  Thu Jun  8 21:46:00 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 8 Jun 2000 15:46:00 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <20000608085351.A9299@thyrsus.com>
References: <20000607174148.A6801@thyrsus.com>
	<200006081027.MAA02445@python.inrialpes.fr>
	<14655.37744.352128.72841@cj42289-a.reston1.va.home.com>
	<20000608085351.A9299@thyrsus.com>
Message-ID: <14655.63480.384525.129125@cj42289-a.reston1.va.home.com>

Eric S. Raymond writes:
 > Go check out the PNG site's census of PNG support in "legacy"
 > browsers. Basically, as long as your PNGs don't use transparency or
 > animation, you're fine.  You've already had the good taste to eschew

  Excellent!  I'll review the list next week probably.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From jeremy at beopen.com  Thu Jun  8 22:24:51 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 8 Jun 2000 16:24:51 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <1251631791-15954519@hypernet.com>
References: <14654.48609.710990.321688@localhost.localdomain>
	<1251631791-15954519@hypernet.com>
Message-ID: <14656.275.83488.186898@localhost.localdomain>

>>>>> "GM" == Gordon McMillan <gmcm at hypernet.com> writes:

  >> From Ken Manheimer's Python web site wishlist: - The humor page
  >> (i'm sad to see that languishing)

  GM> A weekly nude Tim Peters jpeg!

We were going to keep those on the pythonlabs.com internal site, but
if Tim doesn't object...

Jeremy




From jeremy at beopen.com  Thu Jun  8 23:19:49 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 8 Jun 2000 17:19:49 -0400 (EDT)
Subject: [Python-Dev] impact of cycle gc...
In-Reply-To: <200006081408.JAA03136@beluga.mojam.com>
References: <200006081408.JAA03136@beluga.mojam.com>
Message-ID: <14656.3573.754658.791617@localhost.localdomain>

Skip,

I don't have time today to look at your post in detail, but one thing
you said rtiggered a pretty immediate response: We should worry more
about the GC performance on examples like the one you posted, and less
about pystone.  

pystone is a good benchmark for testing the overhead in cases when the
garbage collector isn't invoked.  There's so little memory allocation
that nothing interesting happens.  The GC patch ought to have no
effect in this case.  I suppose 4% is okay.

The worry is about programs that allocate a lot of objects, even if
they never create circular references.  The compiler test is one
example, because the parser tree consumes an enormous number of tuples
and objects.

I suspect big slowdowns like the one you posted just mean we don't
know how to adjust the tuneable parameters.

Jeremy




From gstein at lyra.org  Fri Jun  9 02:01:08 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 8 Jun 2000 17:01:08 -0700
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400
References: <Pine.LNX.4.21.0006081407260.675-100000@korak.digicool.com> <Pine.LNX.4.10.10006081442510.16229-100000@akbar.nevex.com>
Message-ID: <20000608170108.B16880@lyra.org>

On Thu, Jun 08, 2000 at 02:45:37PM -0400, Greg Wilson wrote:
> > Ken Manheimer said
> > 3. Vaults of parnassus already does this, but i'll still mention - 
> >    Contributed software/docs/etc - managed similar to moderated news
> >    postings, but with classification/cataloguing of artifacts, ability for
> >    people to vote on desirability for ranking purposes
> 
> I'd like to see the Vaults, Starship, and other sub-sites folded into, or
> become subsections of, a larger Python site, so that I've got the same
> kind of one-stop shopping that CPAN gives me.

+1 on that!

If python.org opens up (beyond what was possible w.r.t CNRI's security
policy), then I see a lot of the impetus for separate sites, such as
Starship and Parnassus, simply disappearing.

While we're at it: Python-URL has some funny location that I can't ever
remember. Providing a way for the organizers to publish those onto
python.org (and maintain the archive there) would be good. If /F is still
doing the daily URL, then it could go there, too...

Cheers,
-g

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



From nascheme at enme.ucalgary.ca  Fri Jun  9 03:29:00 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 8 Jun 2000 19:29:00 -0600
Subject: [Python-Dev] impact of cycle gc...
Message-ID: <20000608192900.A21668@acs.ucalgary.ca>

Just a few points and then I will get off python-dev. :)

First of all, I don't think it is very meaningful to use leaking
applications to do timing comparisons.  The collector has be
quite careful when freeing structures containing reference
cycles.  However, using something other than pystone is
definitely a good idea.

Here the pybench results for the latest patch:

PYBENCH 0.6

Benchmark: b_nogc (rounds=4, warp=30)

Tests:                              per run    per oper.  diff *
------------------------------------------------------------------------
          BuiltinFunctionCalls:     286.25 ms    3.37 us   -4.22%
           BuiltinMethodLookup:     367.50 ms    1.05 us   -4.55%
                 ConcatStrings:     368.37 ms    3.68 us  +42.50%
               CreateInstances:     477.87 ms   17.07 us   -4.45%
       CreateStringsWithConcat:     322.12 ms    2.42 us  +10.27%
                  DictCreation:     382.75 ms    3.83 us   +1.29%
                      ForLoops:     536.88 ms   80.73 us   +0.99%
                    IfThenElse:     432.75 ms    0.96 us   -3.21%
                   ListSlicing:     236.87 ms  104.12 us  +11.73%
                NestedForLoops:     320.00 ms    1.28 us   +0.16%
          NormalClassAttribute:     386.50 ms    0.97 us   +0.00%
           PythonFunctionCalls:     477.87 ms    4.34 us   -3.51%
             PythonMethodCalls:     379.12 ms    7.59 us  -12.67%
                     Recursion:     280.75 ms   33.70 us   -0.88%
                  SecondImport:     206.62 ms   12.41 us   -5.76%
           SecondPackageImport:     216.75 ms   13.02 us   -4.41%
         SecondSubmoduleImport:     279.25 ms   16.77 us   -2.57%
       SimpleComplexArithmetic:     351.00 ms    2.39 us   +0.72%
        SimpleDictManipulation:     320.75 ms    1.60 us   -2.99%
         SimpleFloatArithmetic:     361.50 ms    0.99 us  -20.37%
      SimpleIntFloatArithmetic:     336.00 ms    0.76 us   +0.04%
       SimpleIntegerArithmetic:     328.38 ms    0.75 us   -0.76%
        SimpleListManipulation:     312.88 ms    1.74 us   -1.61%
          SimpleLongArithmetic:     308.75 ms    2.81 us   +9.88%
                    SmallLists:     470.13 ms    2.77 us   -5.05%
                   SmallTuples:     374.62 ms    2.34 us  -15.74%
         SpecialClassAttribute:     384.00 ms    0.96 us   -1.88%
      SpecialInstanceAttribute:     446.38 ms    1.12 us   -2.75%
                 StringSlicing:     315.50 ms    2.70 us  +16.58%
                     TryExcept:     585.37 ms    0.59 us   -1.70%
                TryRaiseExcept:     312.75 ms   31.28 us   -5.30%
                  TupleSlicing:     299.38 ms    4.39 us  +12.18%
------------------------------------------------------------------------
            Average round time:   13615.00 ms              -1.13%

My AMD-K6-II processor is a pretty quirky beast so I don't think
you can conclude too much for those results.  Here are the
median timings from running Jeremy's compiler on its own source:

	$ time python compile.py `find . -name '*.py'`

Python 1.6 without GC:

	real    0m16.926s
	user    0m16.810s
	sys     0m0.110s

Python 1.6 with GC:

	real    0m21.593s
	user    0m21.470s
	sys     0m0.080s

Python 1.6 with GC, collection disabled (ie. gc.set_threshold(0)):

	real    0m18.441s
	user    0m18.220s
	sys     0m0.220s

We can tune the collection frequency all we want but we won't do
any better than the last numbers.  Those numbers reflect the cost
of keeping track of the objects and the increase in object size.

On a related note, I would like to cleanup the PyGC_{NEW,
VAR_NEW} macros but I can't figure out a way to transform this
code into a macro:

    op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp));
    if (op)
        op = PyGC_OBJ((PyGCInfo *)op);

If C's || operator was like the Python or I could do something
like:

    #define PyGC_OBJ_SAFE(g) ((PyGCInfo *)(((g) || -1) + 1))

Any ideas?  Using an inline function in the header file would
be nice but of course it is not portable.  GCC has statement
expressions but again they are not portable.

    Neil



From Vladimir.Marangozov at inrialpes.fr  Fri Jun  9 04:03:59 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 9 Jun 2000 04:03:59 +0200 (CEST)
Subject: [Python-Dev] impact of cycle gc...
In-Reply-To: <20000608192900.A21668@acs.ucalgary.ca> from "Neil Schemenauer" at Jun 08, 2000 07:29:00 PM
Message-ID: <200006090204.EAA11518@python.inrialpes.fr>

Neil Schemenauer wrote:
> 
> On a related note, I would like to cleanup the PyGC_{NEW,
> VAR_NEW} macros but I can't figure out a way to transform this
> code into a macro:
> 
>     op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp));
>     if (op)
>         op = PyGC_OBJ((PyGCInfo *)op);

The correct thing to do, IMO, is to reflect the sizeof(PyGCInfo)
mem increment in the tp_basicsize slot of the type object. Thus, we can
reuse the current PyObject_New/NEW code, which boils down to
PyObject_MALLOC(_PyObject_SIZE(tp)).  There is no need for PyGC_NEW/NEW_VAR.

This would imply some additional changes to PyObject_Init when the
GC_FLAG is set for a given typeobj.

I had a closer look at the patch today. It looks good, but I think it
needs some more work for a smooth integration with the existing APIs.
There's room for optimisations (there are lots of function calls in there,
so I am not surprised about the performance hit), but they'll come
later on, once the big chunks of the patch fit in their places.

One thing that bothered me is that the current gc object allocation
code won't fly with C++, where the object storage is allocated (and its
size is computed) automatically. There is no PyObject_New, and a C++
object constructor is supposed to begin with PyObject_Init.

Another thing is the function names: PyGC_NEW, PyGC_Info, PyGC_Insert, etc.
It would be better if they reflect the fact that we're talking about GC
on PyObjects, and not about GC in general (on arbitrary mem chunks).

I would suggest renaming them along these lines:

PyGC_Info -> PyGC_ObjectHead
PyGC_Insert -> PyGC_ObjectInit
PyGC_Remove -> PyGC_ObjectFini
...

All this needs some more thought though...

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From mal at lemburg.com  Fri Jun  9 13:03:56 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 09 Jun 2000 13:03:56 +0200
Subject: [Python-Dev] Japanese Codecs
Message-ID: <3940CF1C.2C625624@lemburg.com>

Python currently supports lots of different code pages and
other more specific codecs. I was wondering what your thoughts
on this are: should we proceed to include an even wider range
of codecs or limit the available number to an absolute minimum ?

I'm asking this, because Tamito KAJIYAMA wrote a set of
codecs for EUC-JP and Shift_JIS which would probably
be very useful for Japanese Python users -- I just don't
know how many there are and whether inclusion of an extra
650k of source code would hurt or not.

Thoughts ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From akuchlin at cnri.reston.va.us  Fri Jun  9 17:08:46 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Fri, 9 Jun 2000 11:08:46 -0400
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <3940CF1C.2C625624@lemburg.com>; from mal@lemburg.com on Fri, Jun 09, 2000 at 01:03:56PM +0200
References: <3940CF1C.2C625624@lemburg.com>
Message-ID: <20000609110846.C10688@amarok.cnri.reston.va.us>

On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote:
>I'm asking this, because Tamito KAJIYAMA wrote a set of
>codecs for EUC-JP and Shift_JIS which would probably
>be very useful for Japanese Python users -- I just don't
>know how many there are and whether inclusion of an extra
>650k of source code would hurt or not.

This seems too much code added that would only be of use to a limited
audience, so -1 from me.  Japanese packagers of Python would probably
include them, of course.

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I confidently expect it to be a fairly resounding failure.
  -- John Cleese, on the Monty Python reunion planned for 1999







From skip at mojam.com  Fri Jun  9 17:19:59 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 9 Jun 2000 10:19:59 -0500 (CDT)
Subject: [Python-Dev] impact of cycle gc...
In-Reply-To: <14656.3573.754658.791617@localhost.localdomain>
References: <200006081408.JAA03136@beluga.mojam.com>
	<14656.3573.754658.791617@localhost.localdomain>
Message-ID: <14657.2847.914770.368965@beluga.mojam.com>

    Jeremy> I don't have time today to look at your post in detail, but one
    Jeremy> thing you said rtiggered a pretty immediate response: We should
    Jeremy> worry more about the GC performance on examples like the one you
    Jeremy> posted, and less about pystone.

I wasn't really worried about pystone, just looking for something quick that
didn't generate cycles... ;-)

Your suggestion is an excellent one.  To try and account for the typical
case, I modified the test slightly.  I added a new class, ethyl:

    def foo():
	pass

    class ethyl:
	def __init__(self):
	    self.indirectFunc = foo

	def theFunc(self):
	    return "blah"

which performs essentially the same work at instantiation time as fred, but
doesn't create a cycle.  The time (in seconds) to create and delete 100,000
freds and ethyls with and without cycle-gc enabled looks like (last of six
consecutive runs):

			./python		./python-cycle-gc
    fred (cycle)	1.4			2.51
    ethyl (no cycle)	1.39			1.55

The memory consumption is as you would expect - leaky when creating fred's
without using cycle-gc, stable otherwise.

So, the penalty for creating and deleting objects that don't contain cycles
would appear to be reasonable (about 10-15%).  As more experience is gained
with it, I imagine it can be reduced further.

Skip




From mal at lemburg.com  Fri Jun  9 17:32:41 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 09 Jun 2000 17:32:41 +0200
Subject: [Python-Dev] Japanese Codecs
References: <3940CF1C.2C625624@lemburg.com> <20000609110846.C10688@amarok.cnri.reston.va.us>
Message-ID: <39410E19.4E4B1EE7@lemburg.com>

"Andrew M. Kuchling" wrote:
> 
> On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote:
> >I'm asking this, because Tamito KAJIYAMA wrote a set of
> >codecs for EUC-JP and Shift_JIS which would probably
> >be very useful for Japanese Python users -- I just don't
> >know how many there are and whether inclusion of an extra
> >650k of source code would hurt or not.
> 
> This seems too much code added that would only be of use to a limited
> audience, so -1 from me.  Japanese packagers of Python would probably
> include them, of course.

I just wish that these packagers actually become a reality
some day... the concept is good, but there currently seem to
be no volunteers or companies jumping in :-(

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From DavidA at ActiveState.com  Fri Jun  9 20:54:03 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 9 Jun 2000 11:54:03 -0700
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <39410E19.4E4B1EE7@lemburg.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com>

> I just wish that these packagers actually become a reality
> some day... the concept is good, but there currently seem to
> be no volunteers or companies jumping in :-(

I can't speak for Japanese packagers, but ActiveState will be packaging
Python in various ways.

--david




From klm at digicool.com  Fri Jun  9 20:59:26 2000
From: klm at digicool.com (Ken Manheimer)
Date: Fri, 9 Jun 2000 14:59:26 -0400 (EDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <14656.275.83488.186898@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0006081731080.675-100000@korak.digicool.com>

On Thu, 8 Jun 2000, Jeremy Hylton wrote:

> >>>>> "GM" == Gordon McMillan <gmcm at hypernet.com> writes:
> 
>   >> From Ken Manheimer's Python web site wishlist: - The humor page
>   >> (i'm sad to see that languishing)
> 
>   GM> A weekly nude Tim Peters jpeg!
> 
> We were going to keep those on the pythonlabs.com internal site, but
> if Tim doesn't object...

Anything for a buck, ay, now that you're in the commercial world?-)

Ken
klm at digicool.com




From tim_one at email.msn.com  Fri Jun  9 21:11:42 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 9 Jun 2000 15:11:42 -0400
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <Pine.LNX.4.21.0006081731080.675-100000@korak.digicool.com>
Message-ID: <000c01bfd246$8c02ca40$a12d153f@tim>

[KenM]
> - The humor page (i'm sad to see that languishing)

[Gordon, as always, guides our youth]
> A weekly nude Tim Peters jpeg!

[JeremyH]
> We were going to keep those on the pythonlabs.com internal site, but
> if Tim doesn't object...

[KenM]
> Anything for a buck, ay, now that you're in the commercial world?-)

After one of my recent "going away" parties here (I "get to" move to VA next
week), a group of old chums were sitting around the restaurant table,
belching up bad Italian cooking and speculating on our places in God's
Inscrutable Plan.  When it came time to pick on me, one naturally pugnacious
fellow-- emboldened beyond his normal aggression by wine --looked me
straight in the eye and demanded to know if there's *anything* I wouldn't do
for money.  Well, in point of fact I believe there are a great many such
things, but in the moment God only inspired me with one, and so I heard
myself retorting:  "Ya, sure, I'd fuck a dog for science ... but I wouldn't
take a job at Microsoft!".

strangely-enough-i-think-that's-backwards-ly y'rs  - tim





From moshez at math.huji.ac.il  Fri Jun  9 21:20:17 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Fri, 9 Jun 2000 22:20:17 +0300 (IDT)
Subject: [Python-Dev] revamped Python web site
In-Reply-To: <000c01bfd246$8c02ca40$a12d153f@tim>
Message-ID: <Pine.GSO.4.10.10006092217350.28979-100000@sundial>

On Fri, 9 Jun 2000, Tim Peters wrote:

> In the moment God only inspired me with one, and so I heard
> myself retorting:  "Ya, sure, I'd fuck a dog for science ... but I wouldn't
> take a job at Microsoft!".
> 
> strangely-enough-i-think-that's-backwards-ly y'rs  - tim

Backwards? You mean you'd fuck Microsoft for science but wouldn't take a
job at a dog? Or you'd fuck a dog for Microsoft but wouldn't take a job at
science? Or you'd take a job for science, but wouldn't fuck at Microsoft?

misunderstanding-tim-seems-to-be-a-common-pass-time-around-here-ly y'rs, Z

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com



Return-Path: <moshez at math.huji.ac.il>
Delivered-To: python-dev at python.org
Received: from math.ma.huji.ac.il (ma.huji.ac.il [132.64.32.5])
	by dinsdale.python.org (Postfix) with ESMTP
	id C19A61CD28; Fri,  9 Jun 2000 14:37:53 -0400 (EDT)
Received: from localhost (moshez at localhost)
	by math.ma.huji.ac.il (8.9.1b+Sun/8.9.3) with ESMTP id VAA28640;
	Fri, 9 Jun 2000 21:37:03 +0300 (IDT)
Date: Fri, 9 Jun 2000 21:37:03 +0300 (IDT)
From: Moshe Zadka <moshez at math.huji.ac.il>
X-Sender: moshez at sundial
Reply-To: Moshe Zadka <moshez at math.huji.ac.il>
To: perl_monkey at my-deja.com
Cc: python-list at python.org, s2mdalle at titan.vcu.edu
In-Reply-To: <8hrbph$a4n$1 at nnrp1.deja.com>
Message-ID: <Pine.GSO.4.10.10006092133190.28574-100000 at sundial>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Python-Dev] Re: Porting CPython
Sender: python-dev-admin at python.org
Errors-To: python-dev-admin at python.org
X-BeenThere: python-dev at python.org
X-Mailman-Version: 2.0beta3
Precedence: bulk
List-Id: Python core developers <python-dev.python.org>

Not a lot I can help you with, but:

On Fri, 9 Jun 2000 perl_monkey at my-deja.com wrote:

> - Excluding Modules
> 
> What is the build procedure for omitting certain built in C modules?
> (I"m talking about the stuff in Modules/)

Edit the "Setup.in" file. Instructions for how are inside the file, but if
you have any more specific questions, please ask again.

> Any help on any of these issues would be appreciated.  Also, when/if I
> finish this, I'd be willing to diff the source and put it into the main
> python branch if that's something people would be interested in.

I'm CCing Python-Dev on this, so hopefully someone from the BeOpen team
can respond. I can just say I'm for it. (Python-dev is on BCC so replies
to this won't automatically go there.)

--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From jeremy at beopen.com  Fri Jun  9 23:00:09 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 9 Jun 2000 17:00:09 -0400 (EDT)
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com>
References: <39410E19.4E4B1EE7@lemburg.com>
	<PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com>
Message-ID: <14657.23257.478479.141319@localhost.localdomain>

>>>>> "DA" == David Ascher <DavidA at ActiveState.com> writes:

  >> I just wish that these packagers actually become a reality some
  >> day... the concept is good, but there currently seem to be no
  >> volunteers or companies jumping in :-(

  DA> I can't speak for Japanese packagers, but ActiveState will be
  DA> packaging Python in various ways.

BeOpen also has packaging plans :-).

Jeremy



From mal at lemburg.com  Fri Jun  9 23:49:37 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 09 Jun 2000 23:49:37 +0200
Subject: [Python-Dev] Japanese Codecs
References: <39410E19.4E4B1EE7@lemburg.com>
		<PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com> <14657.23257.478479.141319@localhost.localdomain>
Message-ID: <39416671.AF78100F@lemburg.com>

Jeremy Hylton wrote:
> 
> >>>>> "DA" == David Ascher <DavidA at ActiveState.com> writes:
> 
>   >> I just wish that these packagers actually become a reality some
>   >> day... the concept is good, but there currently seem to be no
>   >> volunteers or companies jumping in :-(
> 
>   DA> I can't speak for Japanese packagers, but ActiveState will be
>   DA> packaging Python in various ways.
> 
> BeOpen also has packaging plans :-).

Sounds cool.

I just hope that someone will hint me of the first Python IPO
*before* it hits NASDAQ ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From effbot at telia.com  Fri Jun  9 23:59:18 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 9 Jun 2000 23:59:18 +0200
Subject: [Python-Dev] Japanese Codecs
References: <39410E19.4E4B1EE7@lemburg.com><PLEJJNOHDIGGLDPOGPJJAEGPCHAA.DavidA@ActiveState.com> <14657.23257.478479.141319@localhost.localdomain>
Message-ID: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid>

> I can't speak for Japanese packagers, but ActiveState will be
> packaging Python in various ways.
> 
> BeOpen also has packaging plans :-).

get in line, guys ;-)

</F>




From esr at thyrsus.com  Sat Jun 10 00:19:24 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 9 Jun 2000 18:19:24 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000609215719.47624E2673@oratrix.oratrix.nl>; from jack@oratrix.nl on Fri, Jun 09, 2000 at 11:57:14PM +0200
References: <20000609215719.47624E2673@oratrix.oratrix.nl>
Message-ID: <20000609181924.A15728@thyrsus.com>

Jack Jansen <jack at oratrix.nl>:
> I include PIL in the standard MacPython and Mac users are apparently
> very happy with that [...]

I think it's time to consider including PIL in the core Python 1.6 release.
I've been following the work being done over there, and I believe the 
code has reached a sufficient level of maturity to justify this.

The "Batteries are included" philosophy seems to me to imply that we
ought to be looking for application libraries to promote into the core
once we're satisfied that they meet core-Pythonic standards of good
API design, stability, general usefulness, and documentation quality.
PIL seems to me like a good candidate on all counts.

Guido has to make the final call, of course.  But let's have the discussion
now so we can develop a yea or nay consensus on ther list.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Society in every state is a blessing, but government even in its best
state is but a necessary evil; in its worst state an intolerable one;
for when we suffer, or are exposed to the same miseries *by a
government*, which we might expect in a country *without government*,
our calamities is heightened by reflecting that we furnish the means
by which we suffer."
	-- Thomas Paine



From pingster at ilm.com  Sat Jun 10 00:28:27 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Fri, 9 Jun 2000 15:28:27 -0700 (PDT)
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000609181924.A15728@thyrsus.com>
Message-ID: <Pine.SGI.3.96.1000609151846.621134V-100000@happy>

On Fri, 9 Jun 2000, Eric S. Raymond wrote:
> Jack Jansen <jack at oratrix.nl>:
> > I include PIL in the standard MacPython and Mac users are apparently
> > very happy with that [...]
> 
> I think it's time to consider including PIL in the core Python 1.6 release.
> I've been following the work being done over there, and I believe the 
> code has reached a sufficient level of maturity to justify this.

I'm +0.  Well, perhaps +0.1.

I guess what i would really be "+" about is something to the effect
of "a popular Linux distribution decides to throw in the .so for PIL".
Then it wouldn't really matter to me whether it was in the "real"
standard distribution.


-- ?!ng

"The police are not here to create disorder. They're here to preserve
disorder."
    -- Former Chicago mayor Daley




From akuchlin at cnri.reston.va.us  Sat Jun 10 03:52:23 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Fri, 9 Jun 2000 21:52:23 -0400
Subject: [Python-Dev] Re: [Image-SIG] RFC: Including PIL in 1.6
In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com>
Message-ID: <20000609215223.A23230@newcnri.cnri.reston.va.us>

On Fri, Jun 09, 2000 at 06:19:24PM -0400, Eric S. Raymond wrote:
>I think it's time to consider including PIL in the core Python 1.6 release.

-1 unless Fredrik says there's a C and Python API for extending PIL that
he's happy with, in which case it's +0.  I've written a few extensions for
PIL and it required a fair amount of grubbing around inside of C structures;
it isn't clear that the structures will be the same in future versions of
PIL.  We don't want to add something that people will extend messily, which
will then make fixing the API more difficult because of backward
compatibility.  (Disclaimer: I haven't looked at PIL 1.1 yet; maybe /F has
documented an API, or maybe he's pretty sure the data structures will remain
the same.)

OTOH, given that the Distutils is making good progress on building RPMs for
an arbitrary Python package, installing PIL may get much easier in future,
reducing the need to add it to the core.  But then Paul always yells at me
for that argument.  :) 

-- 
A.M. Kuchling			akuchlin at mems-exchange.org
Posting "Please send e-mail, since I don't read this group": Poster is
rendered illiterate by a simple trepanation.
  -- Kibo, in the Happynet Manifesto



From akuchlin at cnri.reston.va.us  Sat Jun 10 04:50:08 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Fri, 9 Jun 2000 22:50:08 -0400
Subject: [Python-Dev] What's New: 2nd draft
Message-ID: <20000609225008.A23369@newcnri.cnri.reston.va.us>

We've made a second pass at the "What's New in 1.6" document; the only
unwritten section is IDLE, and I don't think either Moshe or I use IDLE.
Can anyone tell us what the new features are?

Again, suggestions on style, forgotten changes, *anything*, are welcomed:
http://starship.python.net/crew/amk/python/writing/new-python/

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
  "How about you -- what're you up to?"
  "Issue #3."
      -- Vic and Zot, in ZOT! #3
      



From moshez at math.huji.ac.il  Sat Jun 10 07:29:56 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 10 Jun 2000 08:29:56 +0300 (IDT)
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid>
Message-ID: <Pine.GSO.4.10.10006100828230.1511-100000@sundial>

On Fri, 9 Jun 2000, Fredrik Lundh wrote:

> > I can't speak for Japanese packagers, but ActiveState will be
> > packaging Python in various ways.
> > 
> > BeOpen also has packaging plans :-).
> 
> get in line, guys ;-)

I wonder if next we'll see threads on slashdot about "PythonOne is just
trying to get on the Python hype. It has nothing to offer except for a 
trivial installer anyone can write in 5 minutes in Python"

(cf: the LinuxOne fiasco)
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From paul at prescod.net  Thu Jun  8 23:32:27 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 08 Jun 2000 23:32:27 +0200
Subject: [Python-Dev] [Fwd: Re: Case sensitivity]
Message-ID: <394010EB.DBCBC5FD@prescod.net>

Here's a good summary of how XML's case sensitivity came to be.

-------- Original Message --------
Subject: Re: Case sensitivity
Date: Mon, 3 Apr 2000 12:44:37 -0400
From: Steve DeRose <Steven_DeRose at brown.edu>
To: xml-dev at lists.oasis-open.org
References: <B50E2EFA.1B57%soord at vda.nl>

Languages with no need for case folding are not much of  a problem: the
case-folding table or program would merely have no effect on characters
belonging to such languages: It would change 26 of our 26 alphabetic
code
points, and no others. After all, in English we already use lots of
characters that don't get case-folded (like digits).

The serious problems are subtler:

The practical problem that with Unicode your folding table gets really
big;
on the order of 128Kbytes instead of 256 bytes (barring compresson):
this
is a pain on small devices (like a cell-phone browser), a pain to load,
a
pain to implement compression for, etc.

The theoretical problem is more important: it's not the caseless
languages
that pose problems, but the complicated case-folding ones. For example,
lots of languages only apply diacritical marks to lower-case letters:
for
example, "a" may come with 6 different accents, but "A" takes none --
which
makes case-folding unreversible. If there are languages that operate the
other way as well, then neither fold-to-upper nor fold-to-lower can work
for all languages: either way would trash some languages.


That said, I think it incumbent on XML *search engines* to support
case-folding (as well as decent treatment of accents, types of hyphens,
etc) for text content searches: Making English speakers search for

  "the" | "thE" | "tHe" | "tHE" | "The" | "ThE" | "THe" | "THE"
or
  "[tT][hH][eE]

is patently absurd; and besides, there is no user cost to (say) a
Japanese
speaker if an engine *does* case-fold. Also, many languages use Roman
characters occasionally, as for acronyms; so their speakers also pay a
price if searches aren't smart enough. And the primary problems with
case-folding do not weigh so heavily in the search engine world (for
example, AltaVista isn't likely to run their main servers on cell phones
for a while yet).





From esr at thyrsus.com  Sat Jun 10 17:42:27 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 11:42:27 -0400
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
Message-ID: <20000610114227.A19052@thyrsus.com>

Last night I sent the following patch for urllib to python-patches:

# Support for launching a browser

if os.environ.has_key("BROWSER"):
    _browsers = string.split(os.environ["BROWSER"], ":")
else:
    _browsers = ["mozilla %s &",
                "netscape -remote 'openURL(%s)'",
                "netscape %s &",
                "lynx %s &",
                "w3m %s &"]

def urlbrowse(url):
    """Launch a browser, in background, pointed at the given URL.
    Accept either a string or a parsed URL tuple. 
    Interpret the BROWSER environment variable, if it exists,
    as a colon-separated list of browser commands to try.
    """
    from urlparse import urlunparse 
    if type(url) == ():
        url = urlunparse(url)
    for browser in _browsers:
        if not os.system('which 1>/dev/null 2>&1 '+string.split(browser)[0]):
            if os.system((browser % url)) == 0:
                return 1
    return 0

Obviously this is not portable off Unix.  Equally obviously it should
be possible to do an equivalent thing under Windows (at least).  For
anybody writing interactive programs in this Web-mad era, this
function is just too useful not to have in the toolbox.  So this is a
nudge to any Windows and Mac wizards on this list -- let's make this
function available cross-platform.

I've also copied this note to Chip Salzenberg.  Perl ought to have
this capability too -- and I'm sufficiently serious about that to
(gasp) code in Perl myself to make it happen if I have to.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

(Those) who are trying to read the Second Amendment out of the Constitution by
claiming it's not an individual right (are) courting disaster by encouraging
others to use the same means to eliminate portions of the Constitution they
don't like.
	-- Alan Dershowitz, Harvard Law School



From akuchlin at cnri.reston.va.us  Sat Jun 10 17:42:50 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sat, 10 Jun 2000 11:42:50 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610113124.B18982@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 11:31:24AM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com>
Message-ID: <20000610114250.A25014@newcnri.cnri.reston.va.us>

[Redirecting a private conversation to python-dev]

On Sat, Jun 10, 2000 at 11:31:24AM -0400, Eric S. Raymond wrote:
>I found a workaround.  The two curses enhancements (traceback wrapper
>and text pad) are now working and ready to be integrated into the
>1.6 library.  How should we proceed?

OK; python-dev has discussed creating a curses package, and reaction
seemed favorable.  So, my plan of action is:

1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv'
inside the SourceForge CVS repository so the complete history of the
module doesn't get lost with the renaming?)

2) Create a Lib/curses/
directory; __init__.py does 'from _curses import *'.  

3) The traceback wrapper can then be put into __init__.py, since I
assume it's fairly small and everyone should use it.  The text pad
stuff could then go in another module in the curses package.

Seem reasonable to everyone?  

--amk



From esr at thyrsus.com  Sat Jun 10 18:01:48 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 12:01:48 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 11:42:50AM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us>
Message-ID: <20000610120148.A19168@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> OK; python-dev has discussed creating a curses package, and reaction
> seemed favorable.  So, my plan of action is:
> 
> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv'
> inside the SourceForge CVS repository so the complete history of the
> module doesn't get lost with the renaming?)
> 
> 2) Create a Lib/curses/
> directory; __init__.py does 'from _curses import *'.  
> 
> 3) The traceback wrapper can then be put into __init__.py, since I
> assume it's fairly small and everyone should use it.  The text pad
> stuff could then go in another module in the curses package.
> 
> Seem reasonable to everyone?  

Works for me.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

We shall not cease from exploration, and the end of all our exploring will be
to arrive where we started and know the place for the first time.
	-- T.S. Eliot



From moshez at math.huji.ac.il  Sat Jun 10 19:03:51 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 10 Jun 2000 20:03:51 +0300 (IDT)
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us>
Message-ID: <Pine.GSO.4.10.10006102000540.6989-100000@sundial>

On Sat, 10 Jun 2000, Andrew Kuchling wrote:

> OK; python-dev has discussed creating a curses package, and reaction
> seemed favorable.  So, my plan of action is:
> 
> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv'
> inside the SourceForge CVS repository so the complete history of the
> module doesn't get lost with the renaming?)
> 
> 2) Create a Lib/curses/
> directory; __init__.py does 'from _curses import *'.  
> 
> 3) The traceback wrapper can then be put into __init__.py, since I
> assume it's fairly small and everyone should use it.  The text pad
> stuff could then go in another module in the curses package.
> 
> Seem reasonable to everyone?  

I'm +1, except for some nagging doubt about the traceback wrapper.
Why not put it in its own (small, granted) module? 
There are no backward compatabilities to worry here, so there shouldn't be
any excuse to put code in __init__.py. But it is so small, that I don't
really feel strongly about it.

i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com





From esr at thyrsus.com  Sat Jun 10 19:24:18 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 13:24:18 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <Pine.GSO.4.10.10006102000540.6989-100000@sundial>; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 08:03:51PM +0300
References: <20000610114250.A25014@newcnri.cnri.reston.va.us> <Pine.GSO.4.10.10006102000540.6989-100000@sundial>
Message-ID: <20000610132418.A19442@thyrsus.com>

Moshe Zadka <moshez at math.huji.ac.il>:
> I'm +1, except for some nagging doubt about the traceback wrapper.
> Why not put it in its own (small, granted) module? 

I don't understand.  Whuy do you want to do this?

> i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z.

You can try it out now:

#
# Curses extensions -- these are expected to be in the 1.6 Python library
#
import sys, curses, ascii

def wrapper(func, *rest):
    "Wrapper function that restores normal keyboard/screen behavior on error."
    res = None
    try:
	# Initialize curses
	stdscr=curses.initscr()
	# Turn off echoing of keys, and enter cbreak mode,
	# where no buffering is performed on keyboard input
	curses.noecho() ; curses.cbreak()

	# In keypad mode, escape sequences for special keys
	# (like the cursor keys) will be interpreted and
	# a special value like curses.KEY_LEFT will be returned
        stdscr.keypad(1)

        res = apply(func, (stdscr,) + rest)
    except:
	# In the event of an error, restore the terminal
	# to a sane state.
	stdscr.keypad(0)
	curses.echo() ; curses.nocbreak()
	curses.endwin()
        # Pass the exception upwards
        (exc_type, exc_value, exc_traceback) = sys.exc_info()
        raise exc_type, exc_value, exc_traceback
    else:
	# Set everything back to normal
	stdscr.keypad(0)
	curses.echo() ; curses.nocbreak()
	curses.endwin()		 # Terminate curses

        return res

def rectangle(win, uly, ulx, lry, lrx):
    "Draw a rectangle."
    win.vline(uly+1, ulx, curses.ACS_VLINE, lry - uly - 1)
    win.hline(uly, ulx+1, curses.ACS_HLINE, lrx - ulx - 1)
    win.hline(lry, ulx+1, curses.ACS_HLINE, lrx - ulx - 1)
    win.vline(uly+1, lrx, curses.ACS_VLINE, lry - uly - 1)
    win.addch(uly, ulx, curses.ACS_ULCORNER)
    win.addch(uly, lrx, curses.ACS_URCORNER)
    win.addch(lry, lrx, curses.ACS_LRCORNER)
    win.addch(lry, ulx, curses.ACS_LLCORNER)

class textbox:
    """Editing widget using the interior of a window object.
    Supports the following Emacs-like key bindings:

    Ctrl-A      Go to left edge of window.
    Ctrl-B      Cursor left, wrapping to previous line if appropriate.
    Ctrl-D      Delete character under cursor.
    Ctrl-E      Go to right edge (nospaces off) or end of line (nospaces on).
    Ctrl-F      Cursor right, wrapping to next line when appropriate.
    Ctrl-G      Terminate, returning the window contents.
    Ctrl-J      Terminate if the window is 1 line, otherwise insert newline.
    Ctrl-K      If line is blank, delete it, otherwise clear to end of line.
    Ctrl-L      Refresh screen
    Ctrl-N      Cursor down; move down one line.
    Ctrl-O      Insert a blank line at cursor location.
    Ctrl-P      Cursor up; move up one line.

    Move operations do nothing if the cursor is at an edge where the movement
    is not possible.  The following synonyms are supported where possible:

    KEY_LEFT = Ctrl-B, KEY_RIGHT = Ctrl-F, KEY_UP = Ctrl-P, KEY_DOWN = Ctrl-N
    """
    def __init__(self, win):
        self.win = win
        (self.maxy, self.maxx) = win.getmaxyx()
        self.maxy = self.maxy - 1
        self.maxx = self.maxx - 1
        self.stripspaces = 1
        win.keypad(1)

    def firstblank(self, y):
        "Go to the location of the first blank on the given line."
        (oldy, oldx) = self.win.getyx()
        self.win.move(y, self.maxx-1)
        last = self.maxx-1
        while 1:
            if last == 0:
                break
            if ascii.ascii(self.win.inch(y, last)) != ascii.SP:
                last = last + 1
                break
            last = last - 1
        self.win.move(oldy, oldx)
        return last

    def do_command(self, ch):
        "Process a single editing command."
        (y, x) = self.win.getyx()
        if ascii.isprint(ch):
            if y < self.maxy or x < self.maxx:
                # The try-catch ignores the error we trigger from some curses
                # versions by trying to write into the lowest-rightmost spot
                # in the self.window.
                try:
                    self.win.addch(ch)
                except ERR:
                    pass
        elif ch == ascii.SOH:				# Ctrl-a
            self.win.move(y, 0)
        elif ch in (ascii.STX, curses.KEY_LEFT):	# Ctrl-b
            if x > 0:
                self.win.move(y, x-1)
            elif y == 0:
                pass
            elif self.stripspaces:
                self.win.move(y-1, self.firstblank(y-1))
            else:
                self.win.move(y-1, self.maxx)
        elif ch == ascii.EOT:				# Ctrl-d
            self.win.delch()
        elif ch == ascii.ENQ:				# Ctrl-e
            if self.stripspaces:
                self.win.move(y, self.firstblank(y, maxx))
            else:
                self.win.move(y, self.maxx)
        elif ch in (ascii.ACK, curses.KEY_RIGHT):	# Ctrl-f
            if x < self.maxx:
                self.win.move(y, x+1)
            elif y == self.maxx:
                pass
            else:
                self.win.move(y+1, 0)
        elif ch == ascii.BEL:				# Ctrl-g
            return 0
        elif ch == ascii.NL:				# Ctrl-j
            if self.maxy == 0:
                return 0
            elif y < self.maxy:
                self.win.move(y+1, 0)
        elif ch == ascii.VT:				# Ctrl-k
            if x == 0 and self.firstblank(y) == 0:
                self.win.deleteln()
            else:
                self.win.clrtoeol()
        elif ch == ascii.FF:				# Ctrl-l
            self.win.refresh()
        elif ch in (ascii.SO, curses.KEY_DOWN):		# Ctrl-n
            if y < self.maxy:
                self.win.move(y+1, x)
        elif ch == ascii.SI:				# Ctrl-o
            self.win.insertln()
        elif ch in (ascii.DLE, curses.KEY_UP):		# Ctrl-p
            if y > 0:
                self.win.move(y-1, x)
        self.win.refresh()
        return 1
        
    def gather(self):
        "Collect and return the contents of the window."
        result = ""
        for y in range(self.maxy+1):
            self.win.move(y, 0)
            stop = self.firstblank(y)
            if stop == 0 and self.stripspaces:
                continue
            for x in range(self.maxx+1):
                if self.stripspaces and x == stop:
                    break
                result = result + chr(ascii.ascii(self.win.inch(y, x)))
            if self.maxy > 0:
                result = result + "\n"
        return result

    def edit(self, validate=None):
        "Edit in the widget window and collect the results."
        while 1:
            ch = self.win.getch()
            if self.validate:
                ch = validate(ch)
            if not self.do_command(ch):
                break
        return self.gather()

if __name__ == '__main__':
    def test_editbox(stdscr):
        win = curses.newwin(4, 9, 15, 20)
        rectangle(stdscr, 14, 19, 19, 29)
        stdscr.refresh()
        return textbox(win).edit()

    str = wrapper(test_editbox)
    print str
-- 
		<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 bwarsaw at python.org  Sat Jun 10 19:58:04 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Sat, 10 Jun 2000 13:58:04 -0400 (EDT)
Subject: [Python-Dev] Creating curses package: OK?
References: <200006100748.DAA17920@snark.thyrsus.com>
	<20000610111323.A24895@newcnri.cnri.reston.va.us>
	<20000610113124.B18982@thyrsus.com>
	<20000610114250.A25014@newcnri.cnri.reston.va.us>
Message-ID: <14658.33196.426211.329070@anthem.concentric.net>

>>>>> "AK" == Andrew Kuchling <akuchlin at cnri.reston.va.us> writes:

    AK> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you
    AK> do a 'mv' inside the SourceForge CVS repository so the
    AK> complete history of the module doesn't get lost with the
    AK> renaming?)

Not easily (IOW, I have to play several rounds of ugly loginfo games
which are hard to get right).  Best thing to do would be to submit a
SF admin request, which I think since you're a developer you can do.

-Barry



From moshez at math.huji.ac.il  Sat Jun 10 22:12:32 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 10 Jun 2000 23:12:32 +0300 (IDT)
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610132418.A19442@thyrsus.com>
Message-ID: <Pine.GSO.4.10.10006102308380.9354-100000@sundial>

[Moshe Zadka]
> I'm +1, except for some nagging doubt about the traceback wrapper.
> Why not put it in its own (small, granted) module? 

[Eric S. Raymond]
> I don't understand.  Why do you want to do this?

I have religious beliefs, and I follow them without thinking. Like
"HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting
real code in __init__.py bad".

(I think that should go in the package style guide, BTW)

religions-are-bad-of-course-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From esr at thyrsus.com  Sat Jun 10 22:24:40 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 16:24:40 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <Pine.GSO.4.10.10006102308380.9354-100000@sundial>; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:12:32PM +0300
References: <20000610132418.A19442@thyrsus.com> <Pine.GSO.4.10.10006102308380.9354-100000@sundial>
Message-ID: <20000610162440.A19859@thyrsus.com>

Moshe Zadka <moshez at math.huji.ac.il>:
> [Eric S. Raymond]
> > I don't understand.  Why do you want to do this?
> 
> I have religious beliefs, and I follow them without thinking. Like
> "HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting
> real code in __init__.py bad".

I'm even more confused now.  Why would the traceback wrapper I'm proposing
go in __init__.py?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The Bible is not my book, and Christianity is not my religion.  I could never
give assent to the long, complicated statements of Christian dogma.
	-- Abraham Lincoln



From moshez at math.huji.ac.il  Sat Jun 10 22:21:57 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sat, 10 Jun 2000 23:21:57 +0300 (IDT)
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610162440.A19859@thyrsus.com>
Message-ID: <Pine.GSO.4.10.10006102319051.9354-100000@sundial>

On Sat, 10 Jun 2000, Eric S. Raymond wrote:

> I'm even more confused now.  Why would the traceback wrapper I'm proposing
> go in __init__.py?

Maybe I'm confused here. I thought that was what AMK suggested, no?
Where would you want it to go? There are currently 3 planned files in 
the curses package:

__init__.py: apparently not
textpad.py: why here? it has nothing to do with text pads
_curses.so: certainly not here...you don't want to code in C more then you
            have to

I'm proposing:

wrapper.py: put it here

i-hope-i-managed-to-confuse-everyone-further-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From akuchlin at cnri.reston.va.us  Sun Jun 11 00:25:14 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sat, 10 Jun 2000 18:25:14 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <Pine.GSO.4.10.10006102319051.9354-100000@sundial>; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:21:57PM +0300
References: <20000610162440.A19859@thyrsus.com> <Pine.GSO.4.10.10006102319051.9354-100000@sundial>
Message-ID: <20000610182514.A25949@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote:
>Maybe I'm confused here. I thought that was what AMK suggested, no?

I did in fact suggest that, since the wrapper is small, and we ideally
want every Python/curses application using it, so they don't leave the
terminal in a wacky state if they raise an exception.  But it's not a
big deal and could easily go in wrapper.py, though __init__.py might
still import it automatically.

--amk



From esr at thyrsus.com  Sun Jun 11 00:38:06 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 18:38:06 -0400
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400
References: <20000610162440.A19859@thyrsus.com> <Pine.GSO.4.10.10006102319051.9354-100000@sundial> <20000610182514.A25949@newcnri.cnri.reston.va.us>
Message-ID: <20000610183806.A20280@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote:
> >Maybe I'm confused here. I thought that was what AMK suggested, no?
> 
> I did in fact suggest that, since the wrapper is small, and we ideally
> want every Python/curses application using it, so they don't leave the
> terminal in a wacky state if they raise an exception.  But it's not a
> big deal and could easily go in wrapper.py, though __init__.py might
> still import it automatically.

The traceback wrapper is not the only Python code I'll be supplying...
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

I do not find in orthodox Christianity one redeeming feature.
	-- Thomas Jefferson



From gstein at lyra.org  Sun Jun 11 00:33:20 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 15:33:20 -0700
Subject: [Python-Dev] Creating curses package: OK?
In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400
References: <20000610162440.A19859@thyrsus.com> <Pine.GSO.4.10.10006102319051.9354-100000@sundial> <20000610182514.A25949@newcnri.cnri.reston.va.us>
Message-ID: <20000610153320.A19484@lyra.org>

On Sat, Jun 10, 2000 at 06:25:14PM -0400, Andrew Kuchling wrote:
> On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote:
> >Maybe I'm confused here. I thought that was what AMK suggested, no?
> 
> I did in fact suggest that, since the wrapper is small, and we ideally
> want every Python/curses application using it, so they don't leave the
> terminal in a wacky state if they raise an exception.  But it's not a
> big deal and could easily go in wrapper.py, though __init__.py might
> still import it automatically.

Yes, I think we'd want it to import the stuff; just organizationally to
place the source code outside of __init__.py

I'd agree that real code should not go into __init__. It should preload some
standard modules, maybe expose some symbols, but otherwise no code.

Cheers,
-g

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



From gstein at lyra.org  Sun Jun 11 01:30:13 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 16:30:13 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <200006102306.QAA18088@slayer.i.sourceforge.net>; from akuchling@slayer.i.sourceforge.net on Sat, Jun 10, 2000 at 04:06:55PM -0700
References: <200006102306.QAA18088@slayer.i.sourceforge.net>
Message-ID: <20000610163013.B19484@lyra.org>

On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote:
>...
> def wrapper(func, *rest):
>     """Wrapper function that initializes curses and calls another function,
>     restoring normal keyboard/screen behavior on error.
>     The callable object 'func' is then passed the main window 'stdscr'
>     as its first argument, followed by any other arguments passed to
>     wrapper().
>     """
>     
>     res = None
>     try:
> 	# Initialize curses
> 	stdscr=curses.initscr()
> 	# Turn off echoing of keys, and enter cbreak mode,
> 	# where no buffering is performed on keyboard input
> 	curses.noecho() ; curses.cbreak()
> 
> 	# In keypad mode, escape sequences for special keys
> 	# (like the cursor keys) will be interpreted and
> 	# a special value like curses.KEY_LEFT will be returned
>         stdscr.keypad(1)
> 
>         res = apply(func, (stdscr,) + rest)
>     except:
> 	# In the event of an error, restore the terminal
> 	# to a sane state.
> 	stdscr.keypad(0)
> 	curses.echo() ; curses.nocbreak()
> 	curses.endwin()
>         # Pass the exception upwards
>         (exc_type, exc_value, exc_traceback) = sys.exc_info()
>         raise exc_type, exc_value, exc_traceback
>     else:
> 	# Set everything back to normal
> 	stdscr.keypad(0)
> 	curses.echo() ; curses.nocbreak()
> 	curses.endwin()		 # Terminate curses
> 
>         return res

This is too complicated. It should read:

   ...
   return apply(func, (stdscr,) + rest)
 finally:
   # Set everything back to normal
   stdscr.keypad(0)
   curses.echo()
   curses.nocbreak()
   curses.endwin()

Andrew: can you make this change?


Separate from the above simplification, it is important to note:

    exc_type, exc_value, exc_traceback = sys.exc_info()
    raise exc_type, exc_value, exc_traceback
    
and

    raise
    
are equivalent in (most) function. The difference is that the former places
the traceback into local variable storage (exc_traceback) which then
introduces a reference loop.

Whenever sys.exc_info() is used, it is very important to watch out for loops
caused by the traceback object. "del exc_traceback" is very handy :-)

Cheers,
-g

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



From gstein at lyra.org  Sun Jun 11 01:33:05 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 16:33:05 -0700
Subject: [Python-Dev] curses wrapper checkin
In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org>
Message-ID: <20000610163305.C19484@lyra.org>

On Sat, Jun 10, 2000 at 04:30:13PM -0700, Greg Stein wrote:
> On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote:
> >...
> > def wrapper(func, *rest):
> >     """Wrapper function that initializes curses and calls another function,
> >     restoring normal keyboard/screen behavior on error.
> >     The callable object 'func' is then passed the main window 'stdscr'
> >     as its first argument, followed by any other arguments passed to
> >     wrapper().
> >     """
> >     
> >     res = None

Oh. This line can disappear, too.

Cheers,
-g

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



From akuchlin at cnri.reston.va.us  Sun Jun 11 01:33:12 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sat, 10 Jun 2000 19:33:12 -0400
Subject: [Python-Dev] Creating curses package: done
In-Reply-To: <14658.33196.426211.329070@anthem.concentric.net>; from bwarsaw@python.org on Sat, Jun 10, 2000 at 01:58:04PM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net>
Message-ID: <20000610193312.A26098@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 01:58:04PM -0400, Barry A. Warsaw wrote:
>which are hard to get right).  Best thing to do would be to submit a
>SF admin request, which I think since you're a developer you can do.

I've submitted a support request to rename the file, and checked in
the Lib/curses subdirectory, containing only __init__.py and
wrapper.py, along with the required Makefile.in and Setup.in changes.
If you compile the CVS tree right now, you'll need to rename
cursesmodule.c to _cursesmodule.c manually.

The textbox stuff poses two problems.  First, it requires ascii.py,
and wasn't the decision to wait for GvR on adding that module?
Second, Eric, I'm not sure what you want as the module name for the
textbox stuff: textbox.py?  Your call...  (I'll check it in, and if
ascii.py is vetoed, it can be rewritten to not require ascii.py, or
we can have curses.ascii.)

--amk



From esr at thyrsus.com  Sun Jun 11 01:48:22 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 19:48:22 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org>
Message-ID: <20000610194822.A882@thyrsus.com>

Greg Stein <gstein at lyra.org>:
> This is too complicated. It should read:
> 
>    ...
>    return apply(func, (stdscr,) + rest)
>  finally:
>    # Set everything back to normal
>    stdscr.keypad(0)
>    curses.echo()
>    curses.nocbreak()
>    curses.endwin()
> 
> Andrew: can you make this change?

I'll test it and make the change in my masters if it works for both
cases.  I haven't actually shipped the box of goodies yet...
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Alcohol still kills more people every year than all `illegal' drugs put
together, and Prohibition only made it worse.  Oppose the War On Some Drugs!



From esr at thyrsus.com  Sun Jun 11 01:50:27 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 19:50:27 -0400
Subject: [Python-Dev] Creating curses package: done
In-Reply-To: <20000610193312.A26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:33:12PM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us>
Message-ID: <20000610195027.B882@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> The textbox stuff poses two problems.  First, it requires ascii.py,
> and wasn't the decision to wait for GvR on adding that module?
> Second, Eric, I'm not sure what you want as the module name for the
> textbox stuff: textbox.py?  Your call...  (I'll check it in, and if
> ascii.py is vetoed, it can be rewritten to not require ascii.py, or
> we can have curses.ascii.)

I thought it was going to become part of curses from the user's point
of view, so that "import curses" brings it in.  That seemed to be the 
intent of the request at the end of the curses HOWTO.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"Taking my gun away because I might shoot someone is like cutting my tongue
out because I might yell `Fire!' in a crowded theater."
        -- Peter Venetoklis



From akuchlin at cnri.reston.va.us  Sun Jun 11 01:44:54 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sat, 10 Jun 2000 19:44:54 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <20000610194822.A882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:48:22PM -0400
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com>
Message-ID: <20000610194454.B26098@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote:
>I'll test it and make the change in my masters if it works for both
>cases.  I haven't actually shipped the box of goodies yet...

Already tested and checked in.  If you make other changes, just ship
me the new version.  

(Oh, I forgot about the stupid legal stuff; you should probably send
wrapper.py and textbox.py to patches at python.org with the requisite
legal disclaimer.)

--amk



From esr at thyrsus.com  Sun Jun 11 01:59:31 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 19:59:31 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1
In-Reply-To: <20000610194454.B26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:44:54PM -0400
References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com> <20000610194454.B26098@newcnri.cnri.reston.va.us>
Message-ID: <20000610195931.A985@thyrsus.com>

Andrew Kuchling <akuchlin at cnri.reston.va.us>:
> On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote:
> >I'll test it and make the change in my masters if it works for both
> >cases.  I haven't actually shipped the box of goodies yet...
> 
> Already tested and checked in.  If you make other changes, just ship
> me the new version.  

Well, dang.  Didn't you want me to document it first? :-)
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Rifles, muskets, long-bows and hand-grenades are inherently democratic
weapons.  A complex weapon makes the strong stronger, while a simple
weapon -- so long as there is no answer to it -- gives claws to the
weak.
        -- George Orwell, "You and the Atom Bomb", 1945



From akuchlin at cnri.reston.va.us  Sun Jun 11 01:51:30 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sat, 10 Jun 2000 19:51:30 -0400
Subject: [Python-Dev] Creating curses package: done
In-Reply-To: <20000610195027.B882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:50:27PM -0400
References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us> <20000610195027.B882@thyrsus.com>
Message-ID: <20000610195130.C26098@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 07:50:27PM -0400, Eric S. Raymond wrote:
>I thought it was going to become part of curses from the user's point
>of view, so that "import curses" brings it in.  That seemed to be the 
>intent of the request at the end of the curses HOWTO.

Ooh, no; that text is saying that an editor would make a good example
to put in the HOWTO.  I'd rather have the curses module contain only a
fairly close mapping of the C API, and extensions written in Python
would be in submodules like curses.editor, curses.textbox, whatever.
Similar to how socketmodule.c is a thin veneer over the BSD socket API, 
and the spiffy extensions are in asyncore.py, httplib.py, &c.

--amk




From nhodgson at bigpond.net.au  Sun Jun 11 02:04:53 2000
From: nhodgson at bigpond.net.au (Neil Hodgson)
Date: Sun, 11 Jun 2000 10:04:53 +1000
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
References: <20000610114227.A19052@thyrsus.com>
Message-ID: <016301bfd338$ab8458f0$e3cb8490@neil>

> Obviously this is not portable off Unix.  Equally obviously it should
> be possible to do an equivalent thing under Windows (at least).  For
> anybody writing interactive programs in this Web-mad era, this
> function is just too useful not to have in the toolbox.  So this is a
> nudge to any Windows and Mac wizards on this list -- let's make this
> function available cross-platform.

   The most common way on Windows to launch the user's preferred browser
with an URL would be:

>>> import win32api
>>> win32api.ShellExecute(0,None,"http://www.python.org",None,"",1)

# Note to Mark - more of the parameters should be optional

   However this, like most process control stuff, requires the Win32
extensions, not the base Python distribution. Trying to hack this up with
os.system would be unpleasant. ShellExecute knows when to do icky stuff like
use DDE to open the correct URL.

   Does this type of UI operation really belong in urllib?

   Neil




From esr at thyrsus.com  Sun Jun 11 03:26:08 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 21:26:08 -0400
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
In-Reply-To: <016301bfd338$ab8458f0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 10:04:53AM +1000
References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil>
Message-ID: <20000610212608.A1109@thyrsus.com>

Neil Hodgson <nhodgson at bigpond.net.au>:
>    Does this type of UI operation really belong in urllib?

It fetches the contents of an URL for inspection.  Where else would you put it?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

It would be thought a hard government that should tax its people one tenth 
part.
	-- Benjamin Franklin



From nhodgson at bigpond.net.au  Sun Jun 11 03:51:34 2000
From: nhodgson at bigpond.net.au (Neil Hodgson)
Date: Sun, 11 Jun 2000 11:51:34 +1000
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com>
Message-ID: <01af01bfd347$937b3fd0$e3cb8490@neil>

> >    Does this type of UI operation really belong in urllib?
>
> It fetches the contents of an URL for inspection.  Where else would you
put it?

   os?
   Or a submodule of os.

   The current os has a bunch of executable-oriented process creation and
managment functions. On Macintosh and Windows, data-oriented process
creation would be useful.

   os.process.open("http://www.python.org")

   os.process.print("c:\src\map.png")

   Neil





From esr at thyrsus.com  Sun Jun 11 04:14:56 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 10 Jun 2000 22:14:56 -0400
Subject: [Python-Dev] Suggestion to Windows- and Mac-library people
In-Reply-To: <01af01bfd347$937b3fd0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 11:51:34AM +1000
References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com> <01af01bfd347$937b3fd0$e3cb8490@neil>
Message-ID: <20000610221456.A1223@thyrsus.com>

Neil Hodgson <nhodgson at bigpond.net.au>:
> > It fetches the contents of an URL for inspection.  Where else would you
> put it?
> 
>    os?
>    Or a submodule of os.
> 
>    The current os has a bunch of executable-oriented process creation and
> managment functions. On Macintosh and Windows, data-oriented process
> creation would be useful.

I don't really care where it lives, and will cheerfully defer to those 
with religious beliefs about the namespace ;-).

If it's not obvious, this flurry of library suggestions you've been
seeing from me lately all come straight out of the CML2 project.  I
use the urlbrowse() function to make URLs in help windows into live
objects that you can click on.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

This would be the best of all possible worlds, if there were
no religion in it.
	-- John Adams, in a letter to Thomas Jefferson.



From esr at snark.thyrsus.com  Sun Jun 11 06:29:37 2000
From: esr at snark.thyrsus.com (Eric S. Raymond)
Date: Sun, 11 Jun 2000 00:29:37 -0400
Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper
Message-ID: <200006110429.AAA01719@snark.thyrsus.com>

Greg Stein's correction broke my traceback wrapper.  I now do *not*
see a traceback on an exit due to Python runtime errors.  I don't know
why this is.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

No one who's seen it in action can say the phrase "government help" without
either laughing or crying.



From gstein at lyra.org  Sun Jun 11 07:44:30 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 10 Jun 2000 22:44:30 -0700
Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper
In-Reply-To: <200006110429.AAA01719@snark.thyrsus.com>; from esr@snark.thyrsus.com on Sun, Jun 11, 2000 at 12:29:37AM -0400
References: <200006110429.AAA01719@snark.thyrsus.com>
Message-ID: <20000610224430.E19484@lyra.org>

On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote:
> Greg Stein's correction broke my traceback wrapper.  I now do *not*
> see a traceback on an exit due to Python runtime errors.  I don't know
> why this is.

That's strange... a "finally" does not munge tracebacks at all. An exception
from a lower level should propagate outwards without interference.

Do you still have an "except:" in your code somewhere? (that could be eating
your exception) Maybe your test case isn't failing as expected :-) If you'd
like, post a copy of the test, and we can debug the wrapper and/or test.

Cheers,
-g

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



From gstein at lyra.org  Sun Jun 11 13:01:50 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 11 Jun 2000 04:01:50 -0700
Subject: [Python-Dev] more on httplib
In-Reply-To: <Pine.LNX.4.10.10006031606100.29036-100000@nebula.lyra.org>; from gstein@lyra.org on Sat, Jun 03, 2000 at 04:13:55PM -0700
References: <Pine.LNX.4.10.10006031606100.29036-100000@nebula.lyra.org>
Message-ID: <20000611040150.K19484@lyra.org>

All of the work below has been completed except for the errno==32 stuff.

Module:  http://www.lyra.org/greg/python/httplib.py
History: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/

There are three items left, that I know of:
  1) need doc for new stuff
  2) need new test cases
  3) I want to remove a "feature" of the old HTTP class. This would be a
     change in behavior, but (IMO) minor. Specifically, if the Status-Line
     is malformed, the old httplib.py would return (-1, <malformed line>,
     None) and store <file ob hooked to socket> into self.file. Nominally,
     that file object allows a client to read more data from the socket
     after the parse problem on the malformed Status-Line. I think it is
     useless, unused by any clients out there, and it causes me pain to
     provide it :-)  I'd like to just store None into self.file

Thoughts? Comments? I'd like to get this thing into Python RSN.

Cheers,
-g

On Sat, Jun 03, 2000 at 04:13:55PM -0700, Greg Stein wrote:
> I would like to propose a few changes to the (new) httplib:
> 
> *) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to
>    provide backwards-compat for it
> 
> *) revamp the pipeline support:
> 
>    - record the "last response object" ... when a new getreply() is done,
>      then we store the "last" into response.prior
>    - reading of the "HTTP/1.1 <code> <msg>" line is deferred, and
>      performed by the response object
>    - the read of that line is lazy
>    - if the response line is read *before* the "prior" response (if any) 
>      is "closed", then an exception is raised: ResponseNotReady
> 
> *) address some of Moshe's concerns:
> 
>    - use class-based exceptions
>    - clarify that HTTPConnection is designed for *blocking* sockets
>    - conn.close() followed by conn.send() will reopen the socket. This
>      could lead to programming errors. I'll add a class-based default flag
>      to disable this behavior.
>    - in request(), we check for errno==32 ... what to do on Windows?
> 
> 
> I will implement these changes in small chunks so that each can be
> reviewed in my CVS repository. The history is available at:
> 
>     http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/

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



From moshez at math.huji.ac.il  Sun Jun 11 13:58:28 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sun, 11 Jun 2000 14:58:28 +0300 (IDT)
Subject: [Python-Dev] more on httplib
In-Reply-To: <20000611040150.K19484@lyra.org>
Message-ID: <Pine.GSO.4.10.10006111414220.12067-100000@sundial>

On Sun, 11 Jun 2000, Greg Stein wrote:

>   3) I want to remove a "feature" of the old HTTP class. This would be a
>      change in behavior, but (IMO) minor. Specifically, if the Status-Line
>      is malformed, the old httplib.py would return (-1, <malformed line>,
>      None) and store <file ob hooked to socket> into self.file. Nominally,
>      that file object allows a client to read more data from the socket
>      after the parse problem on the malformed Status-Line. I think it is
>      useless, unused by any clients out there, and it causes me pain to
>      provide it :-)  I'd like to just store None into self.file

What do the old docs say about this?

\begin{methoddesc}{getfile}{}
Return a file object from which the data returned by the server can be
read, using the \method{read()}, \method{readline()} or
\method{readlines()} methods.
\end{methoddesc}

So why not put a "dummy" file: one whose read(), readline() or readlines() 
act as if it was at EOF?
(IOW, the Pythonic equivalent of open("/dev/null"))


-- 
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From akuchlin at cnri.reston.va.us  Sun Jun 11 15:19:48 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sun, 11 Jun 2000 09:19:48 -0400
Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper
In-Reply-To: <20000610224430.E19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 10:44:30PM -0700
References: <200006110429.AAA01719@snark.thyrsus.com> <20000610224430.E19484@lyra.org>
Message-ID: <20000611091948.A27835@newcnri.cnri.reston.va.us>

On Sat, Jun 10, 2000 at 10:44:30PM -0700, Greg Stein wrote:
>On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote:
>> Greg Stein's correction broke my traceback wrapper.  
>If you'd like, post a copy of the test, and we can debug the wrapper
>and/or test.

I'll leave it to the two of you to figure out what's going on and
submit a corrected version, if necessary.  I did test the simplified
version and it seemed fine, though maybe there's a subtle problem.
I'm off to CA, and will be back on Wednesday.  (Mmmm... hours of plane
hacking...)

--amk



From gstein at lyra.org  Sun Jun 11 21:18:26 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 11 Jun 2000 12:18:26 -0700
Subject: [Python-Dev] more on httplib
In-Reply-To: <Pine.GSO.4.10.10006111414220.12067-100000@sundial>; from moshez@math.huji.ac.il on Sun, Jun 11, 2000 at 02:58:28PM +0300
References: <20000611040150.K19484@lyra.org> <Pine.GSO.4.10.10006111414220.12067-100000@sundial>
Message-ID: <20000611121826.L19484@lyra.org>

On Sun, Jun 11, 2000 at 02:58:28PM +0300, Moshe Zadka wrote:
> On Sun, 11 Jun 2000, Greg Stein wrote:
> 
> >   3) I want to remove a "feature" of the old HTTP class. This would be a
> >      change in behavior, but (IMO) minor. Specifically, if the Status-Line
> >      is malformed, the old httplib.py would return (-1, <malformed line>,
> >      None) and store <file ob hooked to socket> into self.file. Nominally,
> >      that file object allows a client to read more data from the socket
> >      after the parse problem on the malformed Status-Line. I think it is
> >      useless, unused by any clients out there, and it causes me pain to
> >      provide it :-)  I'd like to just store None into self.file
> 
> What do the old docs say about this?
> 
> \begin{methoddesc}{getfile}{}
> Return a file object from which the data returned by the server can be
> read, using the \method{read()}, \method{readline()} or
> \method{readlines()} methods.
> \end{methoddesc}
> 
> So why not put a "dummy" file: one whose read(), readline() or readlines() 
> act as if it was at EOF?
> (IOW, the Pythonic equivalent of open("/dev/null"))

Sure, I can put different things there, but that would also be a change in
semantics.

The backwards compat class, HTTP, preserves the API completely -- even down
to how it reacts in error situations. (although, it *can* raise errors that
it didn't before, when you use methods in the wrong order)

I'd like to make a change in the semantics for this particular error
condition. Where a client used to be able to do:

    errcode, errmsg, hdrs = h.getreply()
    if errcode == -1:
        file = h.getfile()
	print 'ERROR: some kind of error occurred'
	print '    partial read:', `errmsg`
	print '    next 100 bytes:', `file.read(100)`

I'd like to eliminate that "next 100 bytes" ability, and just close the
socket when a protocol error occurs. Before making a change in behavior for
this (central) class, I'd like to get some feedback. Some voting?

Cheers,
-g

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



From andy at robanal.demon.co.uk  Mon Jun 12 13:45:57 2000
From: andy at robanal.demon.co.uk (Andy Robinson)
Date: Mon, 12 Jun 2000 12:45:57 +0100
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <20000610160032.0004A1CFA2@dinsdale.python.org>
Message-ID: <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>


>
> Message: 2
> From: "David Ascher" <DavidA at ActiveState.com>
> To: "Python Developers @ python.org" <python-dev at python.org>
> Subject: RE: [Python-Dev] Japanese Codecs
> Date: Fri, 9 Jun 2000 11:54:03 -0700
> charset="US-ASCII"
>
> > I just wish that these packagers actually become a reality
> > some day... the concept is good, but there currently seem to
> > be no volunteers or companies jumping in :-(
>
> I can't speak for Japanese packagers, but ActiveState will be packaging
> Python in various ways.
>
The handful of Python users who know some Japanese are kind of busy at the
moment, and the codec work takes more than a night or two; I was hoping to
tackle it myself, but as the only Python startup without any venture
funding, it is hard to clear aside the time without a customer; and it also
needs C skills.

I believe we should try and put resources together to fund this work and
ensure it gets done this year.  I can tell you that HP are now well and
truly out of the picture as a sponsor.  AFAIK the organisations who should
talk are at least...
   PythonLabs/BeOpen
   ActiveState
   Digital Garage
   PythonWare / Secret Labs ??? (not sure how rapid their global plans are)
   ReportLab

Are there any others?  Please get in touch with me...

feeling-rather-guilty-as-i18n-sig-coordinator-ly-yrs,

Andy Robinson






From mal at lemburg.com  Mon Jun 12 14:51:11 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 12 Jun 2000 14:51:11 +0200
Subject: [Python-Dev] Japanese Codecs
References: <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>
Message-ID: <3944DCBF.34DA9E4B@lemburg.com>

Andy Robinson wrote:
> 
> > > I just wish that these packagers actually become a reality
> > > some day... the concept is good, but there currently seem to
> > > be no volunteers or companies jumping in :-(
> >
> > I can't speak for Japanese packagers, but ActiveState will be packaging
> > Python in various ways.
> >
> The handful of Python users who know some Japanese are kind of busy at the
> moment, and the codec work takes more than a night or two; I was hoping to
> tackle it myself, but as the only Python startup without any venture
> funding, it is hard to clear aside the time without a customer; and it also
> needs C skills.
>
> I believe we should try and put resources together to fund this work and
> ensure it gets done this year.  I can tell you that HP are now well and
> truly out of the picture as a sponsor. 

How come ...wheren't they the initial sponsors for the i18n of
Python ? 

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From gstein at lyra.org  Mon Jun 12 20:19:07 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 12 Jun 2000 11:19:07 -0700
Subject: [Python-Dev] Japanese Codecs
In-Reply-To: <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>; from andy@robanal.demon.co.uk on Mon, Jun 12, 2000 at 12:45:57PM +0100
References: <20000610160032.0004A1CFA2@dinsdale.python.org> <PGECLPOBGNBNKHNAGIJHAEKICCAA.andy@robanal.demon.co.uk>
Message-ID: <20000612111907.B19484@lyra.org>

On Mon, Jun 12, 2000 at 12:45:57PM +0100, Andy Robinson wrote:
> > Message: 2
> > From: "David Ascher" <DavidA at ActiveState.com>
> > To: "Python Developers @ python.org" <python-dev at python.org>
> > Subject: RE: [Python-Dev] Japanese Codecs
> > Date: Fri, 9 Jun 2000 11:54:03 -0700
> > charset="US-ASCII"
> >
> > > I just wish that these packagers actually become a reality
> > > some day... the concept is good, but there currently seem to
> > > be no volunteers or companies jumping in :-(
> >
> > I can't speak for Japanese packagers, but ActiveState will be packaging
> > Python in various ways.
> >
> The handful of Python users who know some Japanese are kind of busy at the
> moment, and the codec work takes more than a night or two; I was hoping to
> tackle it myself, but as the only Python startup without any venture
> funding, it is hard to clear aside the time without a customer; and it also
> needs C skills.
> 
> I believe we should try and put resources together to fund this work and
> ensure it gets done this year.

Um... why is it incumbent upon "us" (for whatever definition of "us" you
want to apply :-) to find/fund the work for the Japanese codecs? Why isn't
this up to the people who want/need it?

Yes, being proactive is a very nice thing to do, but I don't see that we
must be, in this case.

> I can tell you that HP are now well and truly out of the picture as a
> sponsor.

eh? What's going on with that?

Cheers,
-g

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



From bwarsaw at python.org  Mon Jun 12 22:53:10 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Mon, 12 Jun 2000 16:53:10 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
Message-ID: <14661.19894.465676.770545@anthem.concentric.net>

Okay, let me just preface this by saying none of the following has
been blessed by Guido in any way.  I'm sure he's still getting nice
and tan and drinking exotic tropical alcohol-based beverages, and not
thinking about Python one little bit. :)

Fred and Jeremy and I had a meeting today and thought about a schedule
/we'd/ like to see for Python 1.6 final.  This may or may not be
feasible but I throw it out here for discussion anyway.

The O'Reilly Open Source conference[1] starts July 17th and it would
be a nice target to release 1.6 final on the 14th, the Friday before
the conference.  We all plan on being there.n

What do we need to do to hit this target?  If we figure a 2 week beta
cycle, 1.6beta1 would have to be released June 30, with probably the
last alpha on June 23.  This is a tight schedule; is it even
feasible?.  Looking at Andrew's TODO list[2], here's what we came up
with:

- import hooks revamped (push this to 1.7)
- update docos to match 1.6 changes (Fred is going to integrate what's
  sitting in his inbox)
- document more undocumented modules (codes - done; unicodedata -
  needs work; mmap & pyexpat - Fred to integrate; curses - needs
  updates; regrtest - push to 1.7, see below)
- Unicode: Compress the size of unicodedatabase (waiting for Chris
  Tismer patches?)
- Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch,
  but none of us know what the state of this is -- is it crucial
  anyway?).
- Unicode: the various XXX items in Misc/unicode.txt (we didn't
  actually find such outstanding issues in this file).
- Delete obsolete subdirs in Demo/ directory (done)
- Refurbish Demo subdirs to be properly documented, match modern
  coding style, etc. (???)
- Fix ./ld_so_aix installation problem on AIX (anybody know more about
  this???)
- Make test/regrtest.py more usable outside of the Python test suite &
  document it.  (push to 1.7)
- Conservative GC, of cycles (this is basically done but needs a lot
  more testing)
- Changes to PyExpat module (Fred says this is done)
- Test the hell out of SRE.  (waiting for /F's complete implementation)
- enable threads by default if OS supports it
- integrate intl/gettext module
- clear the patches and bugs backlog

As we saw it the most critical things that need to get done are
testing the GC stuff and the SRE module.  Of those, the most critical
is SRE since AFAIK, we're still waiting for the final complete code
from /F.  I could be wrong about that.

The last three weren't on Andrew's list.  I'm on the hook for enabling
threads support by default and integrating intl/gettext.  I think
those will just be a couple of days work.

The final one requires Us to go through the outstanding bug and
patches lists and address the critical bugs.

Thoughts?  What have I missed?
-Barry

[1] http://conferences.oreilly.com/oscon2000/

[2] http://starship.python.net/crew/amk/python/1.6-jobs.html



From gstein at lyra.org  Tue Jun 13 02:32:14 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 12 Jun 2000 17:32:14 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <20000612173214.F19484@lyra.org>

On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
> ... disclaimers applied ...
>
> - import hooks revamped (push this to 1.7)

The latest thought had two items here:

1) incorporate feedback into imputil.py.
   [ the feedback is visible at the end of the most recent version:
       http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/
   ]
2) drop imputil into the standard library, but don't go down the "replace
   Python's default mechanism with imputil"

Essentially, this gets imputil out there and usable, but it doesn't directly
impact Python's operation in 1.6.

>...
> - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch,
>   but none of us know what the state of this is -- is it crucial
>   anyway?).

Bill posted some patches. Little feedback. He will be reposting an updated
patch.

>...
> - Conservative GC, of cycles (this is basically done but needs a lot
>   more testing)

I would recommend doing this in small, reviewable steps. I believe there are
a lot of "framework" changes that can occur without actually changing Python
itself. After that first round, which will make adding GC easier, then we
can do Step 2 and add the real GC stuff.

>...

New item:
  - replace httplib.py with Greg's new module. plus docs/test.

>...
> As we saw it the most critical things that need to get done are
> testing the GC stuff and the SRE module.  Of those, the most critical
> is SRE since AFAIK, we're still waiting for the final complete code
> from /F.  I could be wrong about that.

I believe his recent patch (which AMK applied) brings it up to "current".

Cheers,
-g

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



From Vladimir.Marangozov at inrialpes.fr  Tue Jun 13 04:37:23 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Tue, 13 Jun 2000 04:37:23 +0200 (CEST)
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net> from "Barry A. Warsaw" at Jun 12, 2000 04:53:10 PM
Message-ID: <200006130237.EAA10373@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> - document more undocumented modules (codes - done; unicodedata -
>   needs work; mmap & pyexpat - Fred to integrate; curses - needs
>   updates; regrtest - push to 1.7, see below)

+ Write missing bits in the extend/embed docs (me)

Also, last time I ran the 1.6 alpha on AIX, test_mmap failed.
I have to take a closer look at this...

> - Fix ./ld_so_aix installation problem on AIX (anybody know more about
>   this???)

Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem
for building C extensions with distutils than an installation problem per se.
Some time ago, I saw a workaround checked in by Greg. If this is still judged
as a problem, I'd like to hear about it. This is a minor thing. I have yet
to install & run the distutil package on AIX, though, and see what happens.

> - enable threads by default if OS supports it

Who's going to champion this? I recall Greg Stein volunteering for it ;)
(or for something related)

> - Test the hell out of SRE.  (waiting for /F's complete implementation)
...
> As we saw it the most critical things that need to get done are
> testing the GC stuff and the SRE module.  Of those, the most critical
> is SRE since AFAIK, we're still waiting for the final complete code
> from /F.  I could be wrong about that.

It thas been my impression that people are pushing /F for SRE deliveries,
but he feels uncomfortable with a number of Unicode compromises (affecting
the SRE code and/or design???) and has some implementation hesitations.
Add to this the pression of the recent PythonWorks' release. In this context,
if there's something to be finished, it would be nice to stop pushing him
and help him finishing this project. Unfortunately, I can't offer any help
as I don't know much about RE engines.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From bwarsaw at python.org  Tue Jun 13 15:17:07 2000
From: bwarsaw at python.org (bwarsaw at python.org)
Date: Tue, 13 Jun 2000 09:17:07 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
	<200006130237.EAA10373@python.inrialpes.fr>
Message-ID: <14662.13395.520180.272688@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:

    >> - enable threads by default if OS supports it

    VM> Who's going to champion this? I recall Greg Stein volunteering
    VM> for it ;) (or for something related)

This isn't the free-threading stuff, which I think we're pushing back
to 1.7, right?  Just making --with-threads turned on by default if the
OS supports it.

    >> - Test the hell out of SRE.  (waiting for /F's complete
    >> implementation)
    VM> ...
    >> As we saw it the most critical things that need to get done are
    >> testing the GC stuff and the SRE module.  Of those, the most
    >> critical is SRE since AFAIK, we're still waiting for the final
    >> complete code from /F.  I could be wrong about that.

    VM> It thas been my impression that people are pushing /F for SRE
    VM> deliveries, but he feels uncomfortable with a number of
    VM> Unicode compromises (affecting the SRE code and/or design???)
    VM> and has some implementation hesitations.  Add to this the
    VM> pression of the recent PythonWorks' release. In this context,
    VM> if there's something to be finished, it would be nice to stop
    VM> pushing him and help him finishing this
    VM> project. Unfortunately, I can't offer any help as I don't know
    VM> much about RE engines.

Neither do I.  /F, how can we help?

-Barry



From mal at lemburg.com  Tue Jun 13 15:18:59 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 15:18:59 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
		<200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net>
Message-ID: <394634C3.9C217913@lemburg.com>

bwarsaw at python.org wrote:
> 
> >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:
> 
>     >> - enable threads by default if OS supports it
> 
>     VM> Who's going to champion this? I recall Greg Stein volunteering
>     VM> for it ;) (or for something related)
> 
> This isn't the free-threading stuff, which I think we're pushing back
> to 1.7, right?  Just making --with-threads turned on by default if the
> OS supports it.

Ehm, didn't we agree on not enabling this by default ? From what
I've heard there are simply too many problems with thread
implementations which cause Python to break in different ways
(not necessarily Python's faults).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gstein at lyra.org  Tue Jun 13 15:26:08 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 13 Jun 2000 06:26:08 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <394634C3.9C217913@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 03:18:59PM +0200
References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com>
Message-ID: <20000613062608.A19484@lyra.org>

On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote:
> bwarsaw at python.org wrote:
> > 
> > >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:
> > 
> >     >> - enable threads by default if OS supports it
> > 
> >     VM> Who's going to champion this? I recall Greg Stein volunteering
> >     VM> for it ;) (or for something related)
> > 
> > This isn't the free-threading stuff, which I think we're pushing back
> > to 1.7, right?  Just making --with-threads turned on by default if the
> > OS supports it.
> 
> Ehm, didn't we agree on not enabling this by default ? From what
> I've heard there are simply too many problems with thread
> implementations which cause Python to break in different ways
> (not necessarily Python's faults).

Threads are quite fine nowadays. Windows has enabled threads for years.
Recent Linux distros all turn it on.

etc

No sense in being afraid any more. :-)

Cheers,
-g

p.s. and yes: free-threading is post 1.6

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



From jim at interet.com  Tue Jun 13 15:32:33 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Tue, 13 Jun 2000 09:32:33 -0400
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <394637F1.73E24380@interet.com>

Just a heads up that there is a patch in
patches at python.org to fix a bug in zipfile.py.

JimA



From mal at lemburg.com  Tue Jun 13 15:35:26 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 15:35:26 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com> <20000613062608.A19484@lyra.org>
Message-ID: <3946389E.B9C5E2F5@lemburg.com>

Greg Stein wrote:
> 
> On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote:
> > bwarsaw at python.org wrote:
> > >
> > > >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:
> > >
> > >     >> - enable threads by default if OS supports it
> > >
> > >     VM> Who's going to champion this? I recall Greg Stein volunteering
> > >     VM> for it ;) (or for something related)
> > >
> > > This isn't the free-threading stuff, which I think we're pushing back
> > > to 1.7, right?  Just making --with-threads turned on by default if the
> > > OS supports it.
> >
> > Ehm, didn't we agree on not enabling this by default ? From what
> > I've heard there are simply too many problems with thread
> > implementations which cause Python to break in different ways
> > (not necessarily Python's faults).
> 
> Threads are quite fine nowadays. Windows has enabled threads for years.
> Recent Linux distros all turn it on.

Ok, then make it default on Linux and Windows... but leave it
turned off on other platforms which still have problems
such as AIX.

> No sense in being afraid any more. :-)

Naa, not being afraid :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jim at interet.com  Tue Jun 13 15:49:36 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Tue, 13 Jun 2000 09:49:36 -0400
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org>
Message-ID: <39463BF0.823C0366@interet.com>

Greg Stein wrote:
> 
> On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
> > ... disclaimers applied ...
> >
> > - import hooks revamped (push this to 1.7)
> 
> The latest thought had two items here:
> 
> 1) incorporate feedback into imputil.py.
>    [ the feedback is visible at the end of the most recent version:
>        http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/
>    ]
> 2) drop imputil into the standard library, but don't go down the "replace
>    Python's default mechanism with imputil"
> 
> Essentially, this gets imputil out there and usable, but it doesn't directly
> impact Python's operation in 1.6.

I would very much like to see imputil.py in the distribution.  I
currently
use ZIP importing, and I have the ZIP importer class done, except that
it
is based on the old imputil.py.  I think ZIP importing could be a
popular feature.

JimA



From Vladimir.Marangozov at inrialpes.fr  Tue Jun 13 15:54:13 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Tue, 13 Jun 2000 15:54:13 +0200 (CEST)
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <3946389E.B9C5E2F5@lemburg.com> from "M.-A. Lemburg" at Jun 13, 2000 03:35:26 PM
Message-ID: <200006131354.PAA11656@python.inrialpes.fr>

M.-A. Lemburg wrote:
> 
> Ok, then make it default on Linux and Windows... but leave it
> turned off on other platforms which still have problems
> such as AIX.

No, I'd suggest turning it on by default everywhere and provide a
--without-thread configure option if it isn't there yet.

On AIX there are identified compiler/libthread combinations that work
or don't work. They can be detected though and since the compiler is
detected earlier, --with-thread can be automatically disabled with a
notification message about the conflict.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From mal at lemburg.com  Tue Jun 13 16:05:55 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 16:05:55 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
Message-ID: <39463FC3.16D6718@lemburg.com>

Vladimir Marangozov wrote:
> 
> M.-A. Lemburg wrote:
> >
> > Ok, then make it default on Linux and Windows... but leave it
> > turned off on other platforms which still have problems
> > such as AIX.
> 
> No, I'd suggest turning it on by default everywhere and provide a
> --without-thread configure option if it isn't there yet.
> 
> On AIX there are identified compiler/libthread combinations that work
> or don't work. They can be detected though and since the compiler is
> detected earlier, --with-thread can be automatically disabled with a
> notification message about the conflict.

Ok, let me drop in another argument:

How you are going to sell the performance loss due to
enabled thread support even when a script doesn't 
need threads at all ?

How about building two versions of the interpreter per default:
one with threads enabled and one without threads ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gstein at lyra.org  Tue Jun 13 16:09:02 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 13 Jun 2000 07:09:02 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <39463FC3.16D6718@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 04:05:55PM +0200
References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com>
Message-ID: <20000613070902.G19484@lyra.org>

On Tue, Jun 13, 2000 at 04:05:55PM +0200, M.-A. Lemburg wrote:
> Vladimir Marangozov wrote:
> > 
> > M.-A. Lemburg wrote:
> > >
> > > Ok, then make it default on Linux and Windows... but leave it
> > > turned off on other platforms which still have problems
> > > such as AIX.
> > 
> > No, I'd suggest turning it on by default everywhere and provide a
> > --without-thread configure option if it isn't there yet.
> > 
> > On AIX there are identified compiler/libthread combinations that work
> > or don't work. They can be detected though and since the compiler is
> > detected earlier, --with-thread can be automatically disabled with a
> > notification message about the conflict.
> 
> Ok, let me drop in another argument:
> 
> How you are going to sell the performance loss due to
> enabled thread support even when a script doesn't 
> need threads at all ?
> 
> How about building two versions of the interpreter per default:
> one with threads enabled and one without threads ?

Hey, the sky is falling, too.

If people are concerned with the performance and want to eek that gain out,
then they can build with --without-threads

Not a problem.

"Gee. My operating system is too slow because it deals with all these
process and threads. Why can't I have a single-process OS like DOS? It runs
*so* much faster."

:-)

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



From bwarsaw at python.org  Tue Jun 13 16:34:34 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Tue, 13 Jun 2000 10:34:34 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <3946389E.B9C5E2F5@lemburg.com>
	<200006131354.PAA11656@python.inrialpes.fr>
Message-ID: <14662.18042.397439.614107@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:

    VM> On AIX there are identified compiler/libthread combinations
    VM> that work or don't work. They can be detected though and since
    VM> the compiler is detected earlier, --with-thread can be
    VM> automatically disabled with a notification message about the
    VM> conflict.

Can you provide a list of such combinations?

-Barry



From mal at lemburg.com  Tue Jun 13 16:44:20 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 16:44:20 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org>
Message-ID: <394648C4.2A701B5B@lemburg.com>

[enabling threads per default]
> >
> > How you are going to sell the performance loss due to
> > enabled thread support even when a script doesn't
> > need threads at all ?
> >
> > How about building two versions of the interpreter per default:
> > one with threads enabled and one without threads ?
> 
> Hey, the sky is falling, too.
> 
> If people are concerned with the performance and want to eek that gain out,
> then they can build with --without-threads
> 
> Not a problem.
> 
> "Gee. My operating system is too slow because it deals with all these
> process and threads. Why can't I have a single-process OS like DOS? It runs
> *so* much faster."

Oh well... never mind, as long as I can still build my
Python without threads, I'm fine :-)

BTW, what about the idea of adding threads at Python level
that was tossed around a few years ago ? Should be easy to
do given Christian's stackless patches together with the
asyncore libs...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bwarsaw at python.org  Tue Jun 13 16:47:21 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Tue, 13 Jun 2000 10:47:21 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
	<39463FC3.16D6718@lemburg.com>
Message-ID: <14662.18809.468033.931803@anthem.concentric.net>

>>>>> "M" == M  <mal at lemburg.com> writes:

    M> How about building two versions of the interpreter per default:
    M> one with threads enabled and one without threads ?

Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1.

with threads: 8547.01 pystones/second
without threads: 9259.26 pystones/second

So an 8% hit isn't negligible but I think it's acceptable for the
benefit of being confidently able to distribute threaded apps.

-Barry



From petrilli at amber.org  Tue Jun 13 17:02:01 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Tue, 13 Jun 2000 11:02:01 -0400
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14662.18809.468033.931803@anthem.concentric.net>; from bwarsaw@python.org on Tue, Jun 13, 2000 at 10:47:21AM -0400
References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <14662.18809.468033.931803@anthem.concentric.net>
Message-ID: <20000613110201.B25344@trump.amber.org>

Barry A. Warsaw [bwarsaw at python.org] wrote:
> 
> >>>>> "M" == M  <mal at lemburg.com> writes:
> 
>     M> How about building two versions of the interpreter per default:
>     M> one with threads enabled and one without threads ?
> 
> Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1.
> 
> with threads: 8547.01 pystones/second
> without threads: 9259.26 pystones/second
> 
> So an 8% hit isn't negligible but I think it's acceptable for the
> benefit of being confidently able to distribute threaded apps.

Just as a data point, in the "Python problems" with Zope, this, along
with soe idiocy in packaging of RPMs in RedHat are the two biggest
problems we have a the Python level.  People not compiling with
threads turned on, and RedHat's decision to ship the header files
separate than the regular Python files. BLAH!

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From bwarsaw at python.org  Tue Jun 13 16:52:24 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Tue, 13 Jun 2000 10:52:24 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
	<39463FC3.16D6718@lemburg.com>
	<20000613070902.G19484@lyra.org>
	<394648C4.2A701B5B@lemburg.com>
Message-ID: <14662.19112.118940.63296@anthem.concentric.net>

>>>>> "M" == M  <mal at lemburg.com> writes:

    M> BTW, what about the idea of adding threads at Python level
    M> that was tossed around a few years ago ? Should be easy to
    M> do given Christian's stackless patches together with the
    M> asyncore libs...

Definitely not for 1.6!



From mal at lemburg.com  Tue Jun 13 17:17:13 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 17:17:13 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <200006131354.PAA11656@python.inrialpes.fr>
		<39463FC3.16D6718@lemburg.com>
		<20000613070902.G19484@lyra.org>
		<394648C4.2A701B5B@lemburg.com> <14662.19112.118940.63296@anthem.concentric.net>
Message-ID: <39465079.64174882@lemburg.com>

"Barry A. Warsaw" wrote:
> 
> >>>>> "M" == M  <mal at lemburg.com> writes:
> 
>     M> BTW, what about the idea of adding threads at Python level
>     M> that was tossed around a few years ago ? Should be easy to
>     M> do given Christian's stackless patches together with the
>     M> asyncore libs...
> 
> Definitely not for 1.6!

Sure... just wanted to add a hint for 1.7 :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From DavidA at ActiveState.com  Tue Jun 13 19:31:32 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 13 Jun 2000 10:31:32 -0700
Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming
Message-ID: <PLEJJNOHDIGGLDPOGPJJMEMMCHAA.DavidA@ActiveState.com>

It's that time of year again, the O'Reilly Open Source Convention, including
the Python track, is fast approaching.   You can save up to $280 if you
register by Friday July 16. The event will be held this July 17-20 in
Monterey, California.

Meet all the key Python players, meet fellow Python enthusiasts, learn about
new Python developments, find Python-related jobs, and have fun at this
yearly event in sunny Monterey, CA.

For details on the Python tutorials, see
http://www.oreillynet.com/pub/w/python_tutorials.html

For details on the Python talks, see
http://www.oreillynet.com/pub/w/python_presentations.html

For details on the Conference as a whole, see
http://conferences.oreilly.com/oscon2000/index.html

Looking forward to meeting you there,


-- David Ascher
   OSCON Python Track Program Chair
   Senior Developer, ActiveState Tool Corporation

Students and academics should remember to sign up for reduced fees:
http://conferences.oreilly.com/oscon2000/register/




From DavidA at ActiveState.com  Tue Jun 13 20:00:41 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 13 Jun 2000 11:00:41 -0700
Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJMEMMCHAA.DavidA@ActiveState.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJMEMOCHAA.DavidA@ActiveState.com>

> It's that time of year again, the O'Reilly Open Source 
> Convention, including the Python track, is fast approaching.
> You can save up to $280 if you register by Friday July 16. 

Make that June 19.  Sorry about that.

--david ascher



From mal at lemburg.com  Tue Jun 13 21:25:04 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 13 Jun 2000 21:25:04 +0200
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <39468A90.697D1CE5@lemburg.com>

"Barry A. Warsaw" wrote:
> 
> The O'Reilly Open Source conference[1] starts July 17th and it would
> be a nice target to release 1.6 final on the 14th, the Friday before
> the conference.  We all plan on being there.n
> 
> What do we need to do to hit this target?  If we figure a 2 week beta
> cycle, 1.6beta1 would have to be released June 30, with probably the
> last alpha on June 23.  This is a tight schedule; is it even
> feasible?.  Looking at Andrew's TODO list[2], here's what we came up
> with:
> 
> [...]
> - document more undocumented modules (codes - done; unicodedata -
>   needs work; mmap & pyexpat - Fred to integrate; curses - needs
>   updates; regrtest - push to 1.7, see below)

I'll take care of unicodedata. What's "codes" -- or did you mean
codecs ?

> - Unicode: Compress the size of unicodedatabase (waiting for Chris
>   Tismer patches?)

Right...

> - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch,
>   but none of us know what the state of this is -- is it crucial
>   anyway?).

Not crucial, but would be nice to have.

> - Unicode: the various XXX items in Misc/unicode.txt (we didn't
>   actually find such outstanding issues in this file).

There are no more discussion points... at least not in that
file ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bwarsaw at python.org  Tue Jun 13 21:31:51 2000
From: bwarsaw at python.org (bwarsaw at python.org)
Date: Tue, 13 Jun 2000 15:31:51 -0400 (EDT)
Subject: [Python-Dev] Towards 1.6 Final
References: <14661.19894.465676.770545@anthem.concentric.net>
	<39468A90.697D1CE5@lemburg.com>
Message-ID: <14662.35879.156976.61686@anthem.concentric.net>

>>>>> "M" == M  <mal at lemburg.com> writes:

    M> I'll take care of unicodedata. What's "codes" -- or did you
    M> mean codecs ?

Oops, yes, "codecs".

    M> There are no more discussion points... at least not in that
    M> file ;-)

<shudder> :)

-Barry



From gstein at lyra.org  Tue Jun 13 22:11:45 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 13 Jun 2000 13:11:45 -0700
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <39463BF0.823C0366@interet.com>; from jim@interet.com on Tue, Jun 13, 2000 at 09:49:36AM -0400
References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org> <39463BF0.823C0366@interet.com>
Message-ID: <20000613131145.O19484@lyra.org>

On Tue, Jun 13, 2000 at 09:49:36AM -0400, James C. Ahlstrom wrote:
> Greg Stein wrote:
> > On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
> > > ... disclaimers applied ...
> > >
> > > - import hooks revamped (push this to 1.7)
> > 
> > The latest thought had two items here:
> > 
> > 1) incorporate feedback into imputil.py.
> >    [ the feedback is visible at the end of the most recent version:
> >        http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/
> >    ]
> > 2) drop imputil into the standard library, but don't go down the "replace
> >    Python's default mechanism with imputil"
> > 
> > Essentially, this gets imputil out there and usable, but it doesn't directly
> > impact Python's operation in 1.6.
> 
> I would very much like to see imputil.py in the distribution.  I
> currently
> use ZIP importing, and I have the ZIP importer class done, except that
> it
> is based on the old imputil.py.  I think ZIP importing could be a
> popular feature.

Yes, this should happen.

In my current setup, I've got a second module named "importers.py" that has
some of the "standard" importers. It would go into there.

Oh, so I guess we'd also want to include importers.py into the distro.

All of this is preconditioned on getting at least some of that imputil work
done that is listed in the TODO area at the bottom of the file... I'm not
sure how soon I'll be able to get to that.

Cheers,
-g

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



From Vladimir.Marangozov at inrialpes.fr  Wed Jun 14 02:57:05 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Wed, 14 Jun 2000 02:57:05 +0200 (CEST)
Subject: [Python-Dev] --with-threads by default (was: Towards 1.6 Final)
In-Reply-To: <14662.18042.397439.614107@anthem.concentric.net> from "Barry A. Warsaw" at Jun 13, 2000 10:34:34 AM
Message-ID: <200006140057.CAA12560@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> 
> >>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:
> 
>     VM> On AIX there are identified compiler/libthread combinations
>     VM> that work or don't work. They can be detected though and since
>     VM> the compiler is detected earlier, --with-thread can be
>     VM> automatically disabled with a notification message about the
>     VM> conflict.
> 
> Can you provide a list of such combinations?
> 

This is outlined in Misc/AIX-NOTES, section thread support.
I've heard that recent versions of gcc work as well, so long as the
executable is linked with AIX ld (not GNU ld).

Ideally, IMO, there should be an appropriate AC_TRY_RUN little threaded
program (or a program suite corresponding to different thread libs and or
standards for a given platform) that would disable threads on failure.
This approach has the merit of being applicable to all Unix flavors.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From trentm at activestate.com  Wed Jun 14 07:21:42 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 13 Jun 2000 22:21:42 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <394701D6.37E6F560@yahoo.com>
References: <394701D6.37E6F560@yahoo.com>
Message-ID: <20000613222142.A27523@activestate.com>

On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote:
> Is this a bug or a feature?:
> 
> Python 1.6a2 (#4, Jun  9 2000, 02:22:41)  [GCC 2.95.2 19991024
> (release)] on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
> 
> >>> ''.isdigit()
> 1
> >>> ''.isspace()
> 1
> 

Good point, maybe. The __docs__ say:

"S.isdigit() -> int\n\
\n\
Return 1 if there are only digit characters in S,\n\
0 otherwise.";


static char isspace__doc__[] =
"S.isspace() -> int\n\
\n\
Return 1 if there are only whitespace characters in S,\n\
0 otherwise.";


I am not an English language lawyer so I could see both interpretations from
the doc strings. I agree, that the result with a zero length string is
surprising. 


Hi All,
Which should it be? Sorry, if this has been covered.



Trent


-- 
Trent Mick
trentm at activestate.com



From mal at lemburg.com  Wed Jun 14 10:43:45 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 10:43:45 +0200
Subject: [Python-Dev] Re: stringobject question
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com>
Message-ID: <394745C1.7FA27DCB@lemburg.com>

Trent Mick wrote:
> 
> On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote:
> > Is this a bug or a feature?:
> >
> > Python 1.6a2 (#4, Jun  9 2000, 02:22:41)  [GCC 2.95.2 19991024
> > (release)] on linux2
> > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
> >
> > >>> ''.isdigit()
> > 1
> > >>> ''.isspace()
> > 1
> >
> 
> Good point, maybe. The __docs__ say:
> 
> "S.isdigit() -> int\n\
> \n\
> Return 1 if there are only digit characters in S,\n\
> 0 otherwise.";
> 
> static char isspace__doc__[] =
> "S.isspace() -> int\n\
> \n\
> Return 1 if there are only whitespace characters in S,\n\
> 0 otherwise.";
> 
> I am not an English language lawyer so I could see both interpretations from
> the doc strings. I agree, that the result with a zero length string is
> surprising.
> 
> Hi All,
> Which should it be? Sorry, if this has been covered.

I guess it's a bug... a subtle one though, because in a
certain sense both 1 and 0 are acceptable. But since
'' is considered to be false, I think that returning 0
makes more sense.

I'll fix this to return 0 for emtpy strings and Unicode objects.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From moshez at math.huji.ac.il  Wed Jun 14 10:46:48 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 14 Jun 2000 11:46:48 +0300 (IDT)
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <394745C1.7FA27DCB@lemburg.com>
Message-ID: <Pine.GSO.4.10.10006141145320.2269-100000@sundial>

On Wed, 14 Jun 2000, M.-A. Lemburg wrote:

> > > >>> ''.isdigit()
> > > 1
> > > >>> ''.isspace()
> > > 1
> > >
> > 
> > Good point, maybe. The __docs__ say:
> > 
> > "S.isdigit() -> int\n\
> > \n\
> > Return 1 if there are only digit characters in S,\n\
> > 0 otherwise.";
> > 
> > static char isspace__doc__[] =
> > "S.isspace() -> int\n\
> > \n\
> > Return 1 if there are only whitespace characters in S,\n\
> > 0 otherwise.";
> > 
> > I am not an English language lawyer so I could see both interpretations from
> > the doc strings. I agree, that the result with a zero length string is
> > surprising.
> > 
> > Hi All,
> > Which should it be? Sorry, if this has been covered.
> 
> I guess it's a bug... a subtle one though, because in a
> certain sense both 1 and 0 are acceptable. But since
> '' is considered to be false, I think that returning 0
> makes more sense.
> 
> I'll fix this to return 0 for emtpy strings and Unicode objects.

I just realized something: if you change the semantics to mean "number of
digits", you'll get the right answer for all 0- and 1- length strings
and unicode objects.

just-an-observation-ly y'rs, Z.
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From mal at lemburg.com  Wed Jun 14 11:18:10 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 11:18:10 +0200
Subject: [Python-Dev] Re: stringobject question
References: <Pine.GSO.4.10.10006141145320.2269-100000@sundial>
Message-ID: <39474DD2.BF51C872@lemburg.com>

Moshe Zadka wrote:
> 
> On Wed, 14 Jun 2000, M.-A. Lemburg wrote:
> 
> > > > >>> ''.isdigit()
> > > > 1
> > > > >>> ''.isspace()
> > > > 1
> > > >
> > >
> > > Good point, maybe. The __docs__ say:
> > >
> > > "S.isdigit() -> int\n\
> > > \n\
> > > Return 1 if there are only digit characters in S,\n\
> > > 0 otherwise.";
> > >
> > > static char isspace__doc__[] =
> > > "S.isspace() -> int\n\
> > > \n\
> > > Return 1 if there are only whitespace characters in S,\n\
> > > 0 otherwise.";
> > >
> > > I am not an English language lawyer so I could see both interpretations from
> > > the doc strings. I agree, that the result with a zero length string is
> > > surprising.
> > >
> > > Hi All,
> > > Which should it be? Sorry, if this has been covered.
> >
> > I guess it's a bug... a subtle one though, because in a
> > certain sense both 1 and 0 are acceptable. But since
> > '' is considered to be false, I think that returning 0
> > makes more sense.
> >
> > I'll fix this to return 0 for emtpy strings and Unicode objects.
> 
> I just realized something: if you change the semantics to mean "number of
> digits", you'll get the right answer for all 0- and 1- length strings
> and unicode objects.

Hmm, the .isXXX() tests should return 1/0 since they test
properties rather than count characters.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From billtut at microsoft.com  Wed Jun 14 12:12:48 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:12:48 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50>

Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?

From mal at lemburg.com  Wed Jun 14 12:19:44 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 12:19:44 +0200
Subject: [Python-Dev] AIX shared library support
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50>
Message-ID: <39475C40.EF9CE51B@lemburg.com>

Bill Tutt wrote:
> 
> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?
> >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> 4.xxx.
> 
> I was all set to integrate the \N{...} support into the Unicode-escape
> encoding, and dynamically load the hash table data in on demand, but
> dynload_aix only cares about module entry points and won't let you specify
> an explicit function name.

Uhm, why do you need to go that deep into the internals
of the import mechanism ? 

Wouldn't is suffice to put the hash table into a _ucnhash module
which get imported on demand (the import mechanism would then
take care of the rest) ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From billtut at microsoft.com  Wed Jun 14 12:12:48 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:12:48 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50>

Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?

From billtut at microsoft.com  Wed Jun 14 12:33:11 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:33:11 -0700
Subject: [Python-Dev] unicode character name patch status
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50>

I was all set to integrate the \N{...} support into the Unicode-escape
encoding, and dynamically load the hash table data in on demand, but
dynload_aix only cares about module entry points and won't let you specify
an explicit function name.

Ugh. So, its question and answer time folks:
1)	If we can't dynamically load the hash table data, is it that big of
a deal?
		Probably only for WinCE, palm pilot, etc, and they already
have patches against CVS.
2)	Or, should I just have a separate encoding?

I'd prefer to pick option #1 since Perl natively supports the syntax in
their strings. The data is all constant read/only data that will be mmapped
directly from the binary, so it only effects working set if the feature is
used.

Barry, Greg, Guido?
The only feedback I got last time I submitted the patch was from MAL, it'd
help if some other folks would comment on it.

Thanks,
Bill










From mal at lemburg.com  Wed Jun 14 12:45:01 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 12:45:01 +0200
Subject: [Python-Dev] unicode character name patch status
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50>
Message-ID: <3947622D.9995572E@lemburg.com>

[Me again, hope you don't mind ;-)]

Bill Tutt wrote:
> 
> I was all set to integrate the \N{...} support into the Unicode-escape
> encoding, and dynamically load the hash table data in on demand, but
> dynload_aix only cares about module entry points and won't let you specify
> an explicit function name.
> 
> Ugh. So, its question and answer time folks:
> 1)      If we can't dynamically load the hash table data, is it that big of
> a deal?
>                 Probably only for WinCE, palm pilot, etc, and they already
> have patches against CVS.
> 2)      Or, should I just have a separate encoding?
> 
> I'd prefer to pick option #1 since Perl natively supports the syntax in
> their strings. The data is all constant read/only data that will be mmapped
> directly from the binary, so it only effects working set if the feature is
> used.

Why can't you use PyImport_Import() to do the dynamic loading and
combine this with the standard unicode-escape codec ?
If it fails (e.g. the user has disabled the module entry in
Setup), then simply raise an exception.

I wouldn't want the hash table around linked statically -- it's
simply to big.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From billtut at microsoft.com  Wed Jun 14 12:48:49 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 03:48:49 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50>

MAL wrote:

> Bill Tutt wrote:
> > 
> > Is there any particular reason that dynload_aix.c doesn't use AIX's
dlopen?
> > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> > 4.xxx.
> 
> > I was all set to integrate the \N{...} support into the Unicode-escape
> > encoding, and dynamically load the hash table data in on demand, but
> > dynload_aix only cares about module entry points and won't let you
specify
> > an explicit function name.

> Uhm, why do you need to go that deep into the internals
> of the import mechanism ? 

> Wouldn't is suffice to put the hash table into a _ucnhash module
> which get imported on demand (the import mechanism would then
> take care of the rest) ?

It would suffice, but it'd be less efficient (and more work) since I'd then
have to access the data/hash functions through the normal PyObject
mechanisms instead of directly as C functions. That is, I'm trying to avoid
creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then
again, maybe I'm just being too performance sensitive.

The import mechanism got redone weirdly, all of the ways of doing dynamic
loading except AIX encode the idea that the function name must be preceeded
by "init".
Dynload_xxx.c is the wrong place to put that requirement. Whomever calls
_PyImport_GetDynLoadFunc() should handle that issue.

Just as an FYI, the only problem I've found so far with my last patch was
wrt handling Unicode characters with values in the UCS-4 code space. (Not
that there are any yet, but the code must handle that case anyway, sine I
don't want to have to go change it later.)

Bill




From mal at lemburg.com  Wed Jun 14 13:00:50 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 13:00:50 +0200
Subject: [Python-Dev] AIX shared library support
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50>
Message-ID: <394765E2.BFBEA135@lemburg.com>

Bill Tutt wrote:
> 
> MAL wrote:
> 
> > Bill Tutt wrote:
> > >
> > > Is there any particular reason that dynload_aix.c doesn't use AIX's
> dlopen?
> > > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> > > 4.xxx.
> >
> > > I was all set to integrate the \N{...} support into the Unicode-escape
> > > encoding, and dynamically load the hash table data in on demand, but
> > > dynload_aix only cares about module entry points and won't let you
> specify
> > > an explicit function name.
> 
> > Uhm, why do you need to go that deep into the internals
> > of the import mechanism ?
> 
> > Wouldn't is suffice to put the hash table into a _ucnhash module
> > which get imported on demand (the import mechanism would then
> > take care of the rest) ?
> 
> It would suffice, but it'd be less efficient (and more work) since I'd then
> have to access the data/hash functions through the normal PyObject
> mechanisms instead of directly as C functions. That is, I'm trying to avoid
> creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then
> again, maybe I'm just being too performance sensitive.

You could pass a pointer to the char* via a PyCObject. 

I usually export the whole module C API via such an object and it works
great: you can rely on module import to get the magic right and
still have a C API around which you can call directly from
C -- without the need to wrap anything in Python objects.

FYI, mxODBC and mxDateTime are tied together using this mechanism;
look in the mxDateTime.h|c files for details.
 
> The import mechanism got redone weirdly, all of the ways of doing dynamic
> loading except AIX encode the idea that the function name must be preceeded
> by "init".
> Dynload_xxx.c is the wrong place to put that requirement. Whomever calls
> _PyImport_GetDynLoadFunc() should handle that issue.

That's to Greg's address, I guess ;-)
 
> Just as an FYI, the only problem I've found so far with my last patch was
> wrt handling Unicode characters with values in the UCS-4 code space. (Not
> that there are any yet, but the code must handle that case anyway, sine I
> don't want to have to go change it later.)

Why is there a problem there ? Python currently uses UTF16
as native format. UTF-16 surrogates are not supported though...
and probably won't be for a while.

I don't see much of a problem here.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From billtut at microsoft.com  Wed Jun 14 13:10:44 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 04:10:44 -0700
Subject: [Python-Dev] AIX shared library support
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50>

MAL:
> Bill:
> > Just as an FYI, the only problem I've found so far with my last patch
was
> > wrt handling Unicode characters with values in the UCS-4 code space.
(Not
> > that there are any yet, but the code must handle that case anyway, sine
I
> > don't want to have to go change it later.)

> Why is there a problem there ? Python currently uses UTF16
> as native format. UTF-16 surrogates are not supported though...
> and probably won't be for a while.

The rest of Python may not care about UTF-16, but that's no particular
reason to not have this code support generating surrogates if an input
UnicodeData.txt happens to have character names for code points that require
surrogates.

Bill




From mwh21 at cam.ac.uk  Wed Jun 14 13:18:27 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 14 Jun 2000 12:18:27 +0100
Subject: [Python-Dev] Can starship please have its front page back?
Message-ID: <m3d7lk33zw.fsf@atrus.jesus.cam.ac.uk>

I'm not sure if I should ask this here, but I've tried crew at starship
and comp.lang.python, so forgive me please.

There are links all over the place (eg. python.org, oriellynet) to
"http://starship.python.net/", which currently gets the gentle
browsing newbie a rather forbidding, somewhat out-of-date status page.
I don't really think this gives a good impression.  Particularly as
said page is no longer on the machine that had the hard disc
failure...

Cheers,
M.




From mal at lemburg.com  Wed Jun 14 13:36:25 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Jun 2000 13:36:25 +0200
Subject: [Python-Dev] AIX shared library support
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50>
Message-ID: <39476E39.E4163D20@lemburg.com>

Bill Tutt wrote:
> 
> MAL:
> > Bill:
> > > Just as an FYI, the only problem I've found so far with my last patch
> was
> > > wrt handling Unicode characters with values in the UCS-4 code space.
> (Not
> > > that there are any yet, but the code must handle that case anyway, sine
> I
> > > don't want to have to go change it later.)
> 
> > Why is there a problem there ? Python currently uses UTF16
> > as native format. UTF-16 surrogates are not supported though...
> > and probably won't be for a while.
> 
> The rest of Python may not care about UTF-16, but that's no particular
> reason to not have this code support generating surrogates if an input
> UnicodeData.txt happens to have character names for code points that require
> surrogates.

True. As long as the design permitts generating surrogates,
there should be no problem.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From Vladimir.Marangozov at inrialpes.fr  Wed Jun 14 16:48:01 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Wed, 14 Jun 2000 16:48:01 +0200 (CEST)
Subject: [Python-Dev] AIX shared library support
In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> from "Bill Tutt" at Jun 14, 2000 03:12:48 AM
Message-ID: <200006141448.QAA14090@python.inrialpes.fr>

Bill Tutt wrote:
> 
> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen?
> >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX
> 4.xxx.

Historically, the dlopen interface (originally a Sun thing) was included
as a standard library (libdl.a) starting from AIX 4.3 (or 4.2). It doesn't
exist on AIX 3.x and AIX 4.1.x. There was a dlopen emulation library,
though, written by an old AIX guru, but it had to be installed manually
on these versions of AIX.

Then, slowly, IBM started to be more receptive about some defacto standards,
included libdl.a in the standard AIX distribution and introduced the -G flag
in ld (a la Sun and others) which adds -ldl to the link automatically.
But all this really works on AIX 4.3 and up.

So what is implemented in Python relies on lower-level dynamic linker
primitives that exist on all AIX releases. Furthermore, our original
goal was not to provide a complete (per symbol) runtime linker, hence
the current state of affairs. The 'init' entry point convention is a
Python convention.  It can be changed at link time, but still, there is
no a full featured dynamic linker and there is no reason to have it in
Python. Python wisely limits itself to the loading of a shared object (lib)
in memory, then to invoke an init function, without going into subtle
per-platform dynlinking details, which would have been a royal pain to
maintain anyway.

I second MAL's opinions: you really don't want to be so deep about
dynloads and it's better to fit in the current architecture. Personnally,
I won't care if my smiley takes half a second to load in memory. :-)

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From gstein at lyra.org  Wed Jun 14 17:00:23 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 14 Jun 2000 08:00:23 -0700
Subject: [Python-Dev] unicode character name patch status
In-Reply-To: <3947622D.9995572E@lemburg.com>; from mal@lemburg.com on Wed, Jun 14, 2000 at 12:45:01PM +0200
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> <3947622D.9995572E@lemburg.com>
Message-ID: <20000614080023.L27338@lyra.org>

On Wed, Jun 14, 2000 at 12:45:01PM +0200, M.-A. Lemburg wrote:
>...
> Bill Tutt wrote:
> > I was all set to integrate the \N{...} support into the Unicode-escape
> > encoding, and dynamically load the hash table data in on demand, but
> > dynload_aix only cares about module entry points and won't let you specify
> > an explicit function name.
> > 
> > Ugh. So, its question and answer time folks:
> > 1)      If we can't dynamically load the hash table data, is it that big of
> > a deal?
> >                 Probably only for WinCE, palm pilot, etc, and they already
> > have patches against CVS.
> > 2)      Or, should I just have a separate encoding?
> > 
> > I'd prefer to pick option #1 since Perl natively supports the syntax in
> > their strings. The data is all constant read/only data that will be mmapped
> > directly from the binary, so it only effects working set if the feature is
> > used.
> 
> Why can't you use PyImport_Import() to do the dynamic loading and
> combine this with the standard unicode-escape codec ?
> If it fails (e.g. the user has disabled the module entry in
> Setup), then simply raise an exception.
> 
> I wouldn't want the hash table around linked statically -- it's
> simply to big.

I'm with MAL. Use Python's import mechanism. That gets you the dynamic load
stuff no problem. It *also* handles the case where the module is statically
linked.

If you go play games with the dynload stuff, then it would be a bitch to
build a single, statically-linked executable.

Cheers,
-g

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



From akuchlin at cnri.reston.va.us  Wed Jun 14 18:13:23 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Wed, 14 Jun 2000 12:13:23 -0400
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400
References: <14661.19894.465676.770545@anthem.concentric.net>
Message-ID: <20000614121323.A13993@amarok.cnri.reston.va.us>

On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote:
>If we figure a 2 week beta cycle, ...

Unicode support, a new regex engine, various minor backward
incompatible changes that may or may not cause people problems...  a 2-week
beta seems too short.

--amk



From billtut at microsoft.com  Wed Jun 14 18:29:30 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Wed, 14 Jun 2000 09:29:30 -0700
Subject: [Python-Dev] unicode character name patch status
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>


> From: Greg Stein [mailto:gstein at lyra.org]

> I'm with MAL. Use Python's import mechanism. That gets you 
> the dynamic load
> stuff no problem. It *also* handles the case where the module 
> is statically
> linked.
> 

Ok, ok, so much for the idea about modifying as few lines as possible in my
patch. :)

> If you go play games with the dynload stuff, then it would be 
> a bitch to
> build a single, statically-linked executable.
> 

Nah, thats what the config.h hAVE_... for dynamic load support #define is
for. :)

Bill



From trentm at activestate.com  Wed Jun 14 19:36:32 2000
From: trentm at activestate.com (Trent Mick)
Date: Wed, 14 Jun 2000 10:36:32 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <394745C1.7FA27DCB@lemburg.com>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com>
Message-ID: <20000614103632.C29778@activestate.com>

On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote:
> 
> I guess it's a bug... a subtle one though, because in a
> certain sense both 1 and 0 are acceptable. But since
> '' is considered to be false, I think that returning 0
> makes more sense.
> 
> I'll fix this to return 0 for emtpy strings and Unicode objects.

These are copied from Java, are they not? What do the Java equivalents
return?

Trent



-- 
Trent Mick
trentm at activestate.com



From gstein at lyra.org  Wed Jun 14 23:52:08 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 14 Jun 2000 14:52:08 -0700
Subject: [Python-Dev] unicode character name patch status
In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>; from billtut@microsoft.com on Wed, Jun 14, 2000 at 09:29:30AM -0700
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>
Message-ID: <20000614145208.D28280@lyra.org>

On Wed, Jun 14, 2000 at 09:29:30AM -0700, Bill Tutt wrote:
> > From: Greg Stein [mailto:gstein at lyra.org]
>...
> > If you go play games with the dynload stuff, then it would be 
> > a bitch to
> > build a single, statically-linked executable.
> 
> Nah, thats what the config.h hAVE_... for dynamic load support #define is
> for. :)

Just to beat a dead horse here: no. Just because config.h says that I
*could* dynamically load doesn't mean that I *want* to. If I want to build a
mother, static Python and I want the name table bundled in, then any dynamic
loading that you make explicit is just going to gum up the process.

Now shut up, and drink your Kool-Aid. :-)

Cheers,
-g

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



From thomas at xs4all.net  Thu Jun 15 19:53:27 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 15 Jun 2000 19:53:27 +0200
Subject: [Python-Dev] Augmented assignment
Message-ID: <20000615195327.R8000@xs4all.nl>

I'd like some (minor) feedback on the augmented assignment thing I'm working
on. I understand Guido is the only one who accepts patches like this, and
appreciate that, but I'm hoping someone can at least tell me what I'm doing
wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
flap, just tell me so and I'll calm down.

I also appreciate the fact that the patch is quite large, and not many
people have the time to scrutinize each version, so I'll summerize the
issues I'm uncertain about.

 * The patch needs to add a new type of opcode, one that takes 2 arguments.
This is because the opcodes that load, change and store a name need one
argument for the index in the name table (or local variable number), and one
argument for the actual operation.

It could also work by using PyInt or another PyObject to pass the extra
argument on the stack, but I don't think pushing a non-PyObject-pointer onto
the stack is a good idea. Adding 2-argument opcodes seemed the easiest
solution.

However, I'm not really into Python-hacking (or was, I should say, because
it's great fun) and the python-dev list doesn't seem to be searchable ;) so
I can't know if this issue has come up before. Has it ? Would the new
opcode-type be an unsurpassable problem ? should I use the stack instead ?

* The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries
in the PyNumberMethods struct and 2 new entries in the PySequenceMethods
struct. Would that conceivably be a problem ? I've heard people on the
python-list complain about this ;-P

 * Should I start sending the patch, in pieces, to the patches-list, or is
it a wasted effort because noone will touch it until Guido is back ? If I
should send it, should I send it in one large patch (minus autogenerated
files) or in nice functionality-sized pieces ?

 * How 'cool' does Guido actually think this syntax is ? Apparently the
subject has come up a few times ;) and I got positive signals from both Tim
and Guido, but if the patch won't go in as a patch, and won't actually be
used other than some inspiration for a future rewrite of the CPython core,
I'm not going to worry too much about the patch ;)

I'm trying to get my boss to send me to OSCON2000 to harass Guido about
these issues himself, but he (my boss) isn't co-operating ;-P (Not
suprising, as Python isn't quite part of my job description, *snif*)

Regards,

-- 
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  Thu Jun 15 20:12:50 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 15 Jun 2000 20:12:50 +0200
Subject: [Python-Dev] Augmented assignment
References: <20000615195327.R8000@xs4all.nl>
Message-ID: <39491CA2.2BDC0DDC@lemburg.com>

Thomas Wouters wrote:
> 
> I'd like some (minor) feedback on the augmented assignment thing I'm working
> on. I understand Guido is the only one who accepts patches like this, and
> appreciate that, but I'm hoping someone can at least tell me what I'm doing
> wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> flap, just tell me so and I'll calm down.

I'd make this a 1.7 issue. 1.6 should go into the stabilization
phase and big complicated patches like yours should receive some
more design and concept discussion before getting checked in.

BTW, with "augmented assign" I suppose you mean things like
a += 1 and b *= 2, right ?

> I also appreciate the fact that the patch is quite large, and not many
> people have the time to scrutinize each version, so I'll summerize the
> issues I'm uncertain about.
> 
>  * The patch needs to add a new type of opcode, one that takes 2 arguments.
> This is because the opcodes that load, change and store a name need one
> argument for the index in the name table (or local variable number), and one
> argument for the actual operation.
> 
> It could also work by using PyInt or another PyObject to pass the extra
> argument on the stack, but I don't think pushing a non-PyObject-pointer onto
> the stack is a good idea. Adding 2-argument opcodes seemed the easiest
> solution.
> 
> However, I'm not really into Python-hacking (or was, I should say, because
> it's great fun) and the python-dev list doesn't seem to be searchable ;) so
> I can't know if this issue has come up before. Has it ? Would the new
> opcode-type be an unsurpassable problem ? should I use the stack instead ?

Any reason you can't do this with the existing op codes ?

E.g. a += b

1. load a
2. load b
3. add
4. store a

> * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries
> in the PyNumberMethods struct and 2 new entries in the PySequenceMethods
> struct. Would that conceivably be a problem ? I've heard people on the
> python-list complain about this ;-P

More generic solutions are usually more accepted.

BTW, before hacking too much into this, you ought to consider
that we are planning for rich comparisons and decentralized
coercion in 1.7 (this was planned for 1.6, but David and I
got carried away with other things).
 
I wouldn't want to have to hack 11 new slots to get this right...

>  * Should I start sending the patch, in pieces, to the patches-list, or is
> it a wasted effort because noone will touch it until Guido is back ? If I
> should send it, should I send it in one large patch (minus autogenerated
> files) or in nice functionality-sized pieces ?

Better put it on a web page and inform python-dev of new features,
enhancements, etc.
 
>  * How 'cool' does Guido actually think this syntax is ? Apparently the
> subject has come up a few times ;) and I got positive signals from both Tim
> and Guido, but if the patch won't go in as a patch, and won't actually be
> used other than some inspiration for a future rewrite of the CPython core,
> I'm not going to worry too much about the patch ;)

Having a patch is good for discussion, whether it gets incorporated
is a different issue ;-)
 
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bckfnn at worldonline.dk  Thu Jun 15 20:16:03 2000
From: bckfnn at worldonline.dk (Finn Bock)
Date: Thu, 15 Jun 2000 18:16:03 GMT
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <20000614103632.C29778@activestate.com>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com>
Message-ID: <39491d4f.4591422@smtp.worldonline.dk>

>On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote:
>> 
>> I guess it's a bug... a subtle one though, because in a
>> certain sense both 1 and 0 are acceptable. But since
>> '' is considered to be false, I think that returning 0
>> makes more sense.
>> 
>> I'll fix this to return 0 for emtpy strings and Unicode objects.

[Trent Mick]

>These are copied from Java, are they not? What do the Java equivalents
>return?

The .isXX methods does not exists on java strings, only on the Character
class. So in java they can never be called on anything with length 0.

regards,
finn



From trentm at activestate.com  Thu Jun 15 20:28:57 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 15 Jun 2000 11:28:57 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <39491d4f.4591422@smtp.worldonline.dk>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk>
Message-ID: <20000615112857.A4508@activestate.com>

On Thu, Jun 15, 2000 at 06:16:03PM +0000, Finn Bock wrote:
> >These are copied from Java, are they not? What do the Java equivalents
> >return?
> 
> The .isXX methods does not exists on java strings, only on the Character
> class. So in java they can never be called on anything with length 0.
> 

Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
unless others have any opposition.

Trent

-- 
Trent Mick
trentm at activestate.com



From fdrake at beopen.com  Thu Jun 15 20:34:02 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 15 Jun 2000 14:34:02 -0400 (EDT)
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <20000615112857.A4508@activestate.com>
References: <394701D6.37E6F560@yahoo.com>
	<20000613222142.A27523@activestate.com>
	<394745C1.7FA27DCB@lemburg.com>
	<20000614103632.C29778@activestate.com>
	<39491d4f.4591422@smtp.worldonline.dk>
	<20000615112857.A4508@activestate.com>
Message-ID: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com>

Trent Mick writes:
 > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
 > unless others have any opposition.

  This sounds good to me.
  Marc-Andre, go ahead and checkin anything that isn't already in
whenever you're ready; I've not seen any hints of opposition yet, and
there's been enough waiting to just check it in.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From trentm at activestate.com  Thu Jun 15 20:58:27 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 15 Jun 2000 11:58:27 -0700
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com>
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com>
Message-ID: <20000615115827.A4657@activestate.com>

On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote:
> 
> Trent Mick writes:
>  > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
>  > unless others have any opposition.
> 
>   This sounds good to me.
>   Marc-Andre, go ahead and checkin anything that isn't already in
> whenever you're ready; I've not seen any hints of opposition yet, and
> there's been enough waiting to just check it in.
> 


From mal at lemburg.com  Thu Jun 15 21:10:43 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 15 Jun 2000 21:10:43 +0200
Subject: [Python-Dev] Re: stringobject question
References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> <20000615115827.A4657@activestate.com>
Message-ID: <39492A33.75440AA4@lemburg.com>

Trent Mick wrote:
> 
> On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote:
> >
> > Trent Mick writes:
> >  > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0,
> >  > unless others have any opposition.
> >
> >   This sounds good to me.
> >   Marc-Andre, go ahead and checkin anything that isn't already in
> > whenever you're ready; I've not seen any hints of opposition yet, and
> > there's been enough waiting to just check it in.
> >
> 
> >From what I have seen it is already in.

Right ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Thu Jun 15 21:21:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 15 Jun 2000 15:21:40 -0400 (EDT)
Subject: [Python-Dev] Re: stringobject question
In-Reply-To: <39492A33.75440AA4@lemburg.com>
References: <394701D6.37E6F560@yahoo.com>
	<20000613222142.A27523@activestate.com>
	<394745C1.7FA27DCB@lemburg.com>
	<20000614103632.C29778@activestate.com>
	<39491d4f.4591422@smtp.worldonline.dk>
	<20000615112857.A4508@activestate.com>
	<14665.8602.65230.481663@cj42289-a.reston1.va.home.com>
	<20000615115827.A4657@activestate.com>
	<39492A33.75440AA4@lemburg.com>
Message-ID: <14665.11460.597390.222317@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Trent Mick wrote:
 > > >From what I have seen it is already in.
 > 
 > Right ;-)

  I may have mentioned that I've been losing track of all the
patches.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From thomas at xs4all.net  Thu Jun 15 23:41:53 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 15 Jun 2000 23:41:53 +0200
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <39491CA2.2BDC0DDC@lemburg.com>; from mal@lemburg.com on Thu, Jun 15, 2000 at 08:12:50PM +0200
References: <20000615195327.R8000@xs4all.nl> <39491CA2.2BDC0DDC@lemburg.com>
Message-ID: <20000615234153.S8000@xs4all.nl>

On Thu, Jun 15, 2000 at 08:12:50PM +0200, M.-A. Lemburg wrote:

> > I'd like some (minor) feedback on the augmented assignment thing I'm working
> > on. I understand Guido is the only one who accepts patches like this, and
> > appreciate that, but I'm hoping someone can at least tell me what I'm doing
> > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> > flap, just tell me so and I'll calm down.

> I'd make this a 1.7 issue. 1.6 should go into the stabilization
> phase and big complicated patches like yours should receive some
> more design and concept discussion before getting checked in.

That's more or less what I figured, though I wasn't aware of the revised
schedule on 1.6 ;)

> BTW, with "augmented assign" I suppose you mean things like
> a += 1 and b *= 2, right ?

Yes; All binary operands, to be exact:

'+=' | '-=' | '*=' | '/=' | '%=' | '&=' | '|=' | '^=' | '<<=' | '>>=' | '**='

> Any reason you can't do this with the existing op codes ?
> 
> E.g. a += b
> 
> 1. load a
> 2. load b
> 3. add
> 4. store a

Yes: It wouldn't be thread-safe, and it would be impossible (or at least
very hard and complicated) to see the difference between 'a += b' and 'a = a
+ b', which would make it very hard to make them functionally different.

The patch not only adds the syntax (Michael Hudsons' patch did that, roughly
how you describe it) but also adds generic semantics for in-place operations
on builtin types, extension types and classes.

> > * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries
> > in the PyNumberMethods struct and 2 new entries in the PySequenceMethods
> > struct. Would that conceivably be a problem ? I've heard people on the
> > python-list complain about this ;-P

> More generic solutions are usually more accepted.

I thought so, but I didn't see a good, simple addition to the API that
wasn't too complicated. What it adds now is 'PyNumber_InPlaceAdd()', which
is functionally the same as 'PyNumber_Add()', except that the left-hand-side
object is given the chance to define the operation in-place. That's also
where the new PyNumberMethods/PySequenceMethods members come in.

> BTW, before hacking too much into this, you ought to consider
> that we are planning for rich comparisons and decentralized
> coercion in 1.7 (this was planned for 1.6, but David and I
> got carried away with other things).

Too late. Most, if not all, of the patch is already written. Not that that's
a reason to accept it, not at all ;)

> I wouldn't want to have to hack 11 new slots to get this right...

I'm not sure if that's necessary, but I'll have to look into your
comparison/coercion work before I can say that for sure. In any case, I'd be
perfectly happy with adjusting the augmented-assignment patch to the
comparison/coercion change, instead of the other way 'round ;)

> >  * Should I start sending the patch, in pieces, to the patches-list, or is
> > it a wasted effort because noone will touch it until Guido is back ? If I
> > should send it, should I send it in one large patch (minus autogenerated
> > files) or in nice functionality-sized pieces ?

> Better put it on a web page and inform python-dev of new features,
> enhancements, etc.

The webpage is already there, with the version I sent to python-list last
Friday. That patch is missing quite a few things, but it serves as an
example of what it should do: http://www.xs4all.nl/~thomas/python/
I hope to upload an almost-finished version tomorrow morning (Amsterdam
time) - if work doesn't intervene again.

> >  * How 'cool' does Guido actually think this syntax is ? Apparently the
> > subject has come up a few times ;) and I got positive signals from both Tim
> > and Guido, but if the patch won't go in as a patch, and won't actually be
> > used other than some inspiration for a future rewrite of the CPython core,
> > I'm not going to worry too much about the patch ;)

> Having a patch is good for discussion, whether it gets incorporated
> is a different issue ;-)

Of course :) The thing is, the patch is actually quite done. What I'm doing
now is more or less auditing and optimizing it, and that is probably a waste
of time if the patch is going to need a complete rewrite anyway. On the
other hand, I'm getting a couple of ideas for optimization of the 'normal'
operations too, so it's not like it's wasted time. I guess I'll start a new
thread on that issue if/when I reach it ;)

Thanx for the feedback!
-- 
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  Thu Jun 15 23:30:45 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Thu, 15 Jun 2000 23:30:45 +0200 (MEST)
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000  7:53:27 pm"
Message-ID: <m132hDp-000DieC@artcom0.artcom-gmbh.de>

Hi!

Thomas Wouters:
> I'd like some (minor) feedback on the augmented assignment thing I'm working
> on. I understand Guido is the only one who accepts patches like this, and
> appreciate that, but I'm hoping someone can at least tell me what I'm doing
> wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> flap, just tell me so and I'll calm down.

Disclaimer: The following is only *my* personal opinion.
But since you have asked for it. ;-)

I don't like this augmented assignment syntax at all! (independent 
from your particular implementation, which I didn't had a look at).  

Augmented assignments are unPythonic because they don't add any new 
functionality to the language.  From what I've seen, all people, 
who ever missed it, were experienced C-programmers.  And C shows 
its inheritance from various assembler languages in its 
augmented assignment and its ++pre and post increment++ and decrement--
operators.  Many of these features were born in the 70s of the
last century:  At that time optimizing was very important and 
compilers were relatively dumb.  This applies in no way to the
situation we have today with Python.

What remains is, that augmented assignments are only a short cut
notation, which introduces more variability to express the same
algorithms and so they hurt readability.  This feature must be learned
additionally, where normal assignment are easiely understood from
school mathematics.  It also introduces many more possibilities to make
subtle mistakes, since it is not obvious (at least to No-C-programmers)
when and how often the index expression will be valuated.  Look at
the following example:

        class Bar:
	    def __init__(self):
	        self.val = 0
	    def __call__(self):
	        self.val = self.val + 1
		return self.val
	bar = Bar()
	foo = range(4)
and than
	foo[bar()] = foo[bar()] + bar()
	print foo
versus
	foo[bar()] += bar()
	print foo

Todays Python forces the programmer to explicitly say, what should happen.

So I think these +=,-=,*= features are evil.  In the same sense as macro
preprocessors are evil in 'C' and 'from module import *' is already evil
in Python.  Add more and more of this stuff and you end up on the dark 
side of programming.

If augmented assignments will ever become part of Python, I would at least
like to see a strong recommendation added to the styleguide not to use 
this feature.

Enough with this rant.

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)



From nascheme at enme.ucalgary.ca  Fri Jun 16 00:26:35 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 15 Jun 2000 16:26:35 -0600
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <m132hDp-000DieC@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200
References: <20000615195327.R8000@xs4all.nl> <m132hDp-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <20000615162635.B11507@acs.ucalgary.ca>

On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote:
> Augmented assignments are unPythonic because they don't add any new 
> functionality to the language.
[...]
> 	foo[bar()] = foo[bar()] + bar()
> versus
> 	foo[bar()] += bar()

Not quite.  I think with the proposed implementation += could
modify the LHS object in place.  This could be a big performance
win for things like NumPy objects.  OTOH, the same effect can be
achieved with a method call:

    foo[bar()].add(bar())

  Neil



From thomas at xs4all.net  Fri Jun 16 00:25:23 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 16 Jun 2000 00:25:23 +0200
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <m132hDp-000DieC@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200
References: <20000615195327.R8000@xs4all.nl> <m132hDp-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <20000616002523.T8000@xs4all.nl>

On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote:

> Thomas Wouters:
> > I'd like some (minor) feedback on the augmented assignment thing I'm working
> > on. I understand Guido is the only one who accepts patches like this, and
> > appreciate that, but I'm hoping someone can at least tell me what I'm doing
> > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> > flap, just tell me so and I'll calm down.

> I don't like this augmented assignment syntax at all! (independent 
> from your particular implementation, which I didn't had a look at).  

> Augmented assignments are unPythonic because they don't add any new 
> functionality to the language. 

[ snip quite good summary of the problems with augmented assignment ]

I agree with almost all of the above, except the statement that they do not
add anything. If augmented assignment was only syntactic sugar I would not
have taken Michael's patch and rewritten it; I do not propose auto-increment
operators, and would have a hard time accepting them.

However, augmented assignment *does* add new functionality, because it is a
way to inform the object that is being operated on, that it can do the
operation in-place if it so wants. Instead of having to create a new object,
which might be costly in cpu and/or memory, and doing the operation on that,
the object can choose to do the operation on itself, and return 'self'. If
the object doesn't want to do that, it doesn't have to be any different from
'x = x + 1'. (In fact, augmented assignment should, and does, fall back to
that.)

>
>
> [ snip good example of indexes-with-sideffect ]
>
>

This actually proves the point of augmented assignment. With the syntax

foo[bar()] += 1

You can see that bar() is only called once, so you *know* what index is
being retrieved, and that the new value is stored in the same place. Using

foo[bar()] = foo[bar()] + 1

you can't see by the expression which value is being retrieved and where the
result is stored. You have to remember the rules about operand evaluation to
see that. Yes, 

foo[bar()] += bar()

is indeed more complicated than the above example, but absolutely not more
complicated than the normal-add version that calls bar() three times.

The augmented assignment syntax is actually clearer and more easy to
explain, in my opinion. You can only (accurately) explain

a = a + 1 

as 'add a and 1, and store the result in a'. However,

a += 1

is simply 'add 1 to a'. 

> So I think these +=,-=,*= features are evil.  In the same sense as macro
> preprocessors are evil in 'C' and 'from module import *' is already evil
> in Python.  Add more and more of this stuff and you end up on the dark 
> side of programming.

Well, I like the odd Star Wars film, but I do not believe that the Dark Side
lies opposite the Right Way. The Right Way can't help but be very close to
the Dark Side. You may dislike macro preprocessors in C, but CPython (and
almost all other C code) do use them alot, for functionality which would
otherwise be very hard (or complicated and unreadable) to achieve. The same
goes for 'from module import *' in Python.

The funny thing is that augmented assignment operators and auto in/decrement
operators might be added to C because they were easier to optimize (I dont
think that was the main reason, but I wasn't there ;) but any halfway decent
C compiler doesn't need that explicitness, and can optimize the 'x = x + 1'
expression directly. Python, however, can (currently) not do that, and
*does* need the added syntax to be able to do optimization, even if only to
let the object know it's safe to operate on itself.

Of course, once there are semantics for inplace-operations, it _might_ be
possible to optimize 'x = x + 1' into 'x += 1' ;)

> If augmented assignments will ever become part of Python, I would at least
> like to see a strong recommendation added to the styleguide not to use 
> this feature.

If such a recommendation was added, the change would be useless. Better get
Guido to not add this feature instead, or Python will end up like Perl ;)
I honestly do not care much wether it gets added or not. If Guido decides
not to add it, I'm certain he has very valid rasons for it, and I dont
assume to know as much about Python, the applicability of Python, the
average usage of Python or the Future of Python as he sees it, as him ;)

I-don't-know-any-of-that-in-fact-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 gmcm at hypernet.com  Fri Jun 16 02:44:38 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 15 Jun 2000 20:44:38 -0400
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <m132hDp-000DieC@artcom0.artcom-gmbh.de>
References: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000  7:53:27 pm"
Message-ID: <1251006162-53585376@hypernet.com>

Peter Funk wrote:

> Augmented assignments are unPythonic because they don't add any
> new functionality to the language.  

Most changes to Python are nothing but syntactic sugar.

In concept, I'm +0.9 on simple "name += val".

I'm -0.9 on "expr += val" if the behavior requires an 
understanding of Python internals, and +0 otherwise (since I 
avoid "expr = expr + val" if possible).

Thomas's statement that the complexity is largely due to 
problems of thread safety is eminently believable, and I doubt 
that the syntactic sugar (which is at least somewhat 
desirable) is worth the price. 

> ....  Many of these features were born in the
> 70s of the last century:  At that time optimizing was very
> important and compilers were relatively dumb.  This applies in no
> way to the situation we have today with Python.

Actually, Python's compiler is very dumb, and optimization is 
still important. So where I would use "expr" 3 times in 3 lines 
in C / C++ and *expect* the compiler to optimize it into one 
evaluation, I have to remind myself to use an extra line and 
compute it once in Python myself. One might argue that that's 
unPythonic, because it inhibits the direct expression of the 
idea. One might, but I won't.
 
> What remains is, that augmented assignments are only a short cut
> notation, which introduces more variability to express the same
> algorithms and so they hurt readability.  

It definitely *improves* the readability of incrementing very-long-
expression. Just not to the point of readability ;-).

> ...  It also introduces many more
> possibilities to make subtle mistakes,

and eliminates othes, such as typos...

> since it is not obvious
> (at least to No-C-programmers) when and how often the index
> expression will be valuated.  Look at the following example:
> 
>         class Bar:
>      def __init__(self):
>          self.val = 0
>      def __call__(self):
>          self.val = self.val + 1
>   return self.val
>  bar = Bar()
>  foo = range(4)
> and than
>  foo[bar()] = foo[bar()] + bar()
>  print foo
> versus
>  foo[bar()] += bar()
>  print foo

To understand the first requires a sufficiently deep 
understanding of how Python works that I doubt the 2nd is 
really much worse. They're both the other side of horrid.
 
I don't care very much myself, but none of these arguments 
are without strong counters (which we've all read many times 
on c.l.py). The only real basis, I think, is whether the changes 
complexify things too much.

- Gordon



From pf at artcom-gmbh.de  Fri Jun 16 09:11:57 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Fri, 16 Jun 2000 09:11:57 +0200 (MEST)
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <1251006162-53585376@hypernet.com> from Gordon McMillan at "Jun 15, 2000  8:44:38 pm"
Message-ID: <m132qIH-000DieC@artcom0.artcom-gmbh.de>

Hi,

[...]
[me]:
> > What remains is, that augmented assignments are only a short cut
> > notation, which introduces more variability to express the same
> > algorithms and so they hurt readability.  

[Gordon McMillan]:
> It definitely *improves* the readability of incrementing very-long-
> expression. Just not to the point of readability ;-).

I agree, that very complicated multidimensional expressions, (possible
mixing tuples, lists, dicts and computations) are even more errorprone
, if you have to repeat them twice just to increment an element.
But than you would use an helper variable to hold the index expression
anyway.

example:

   foo = range(3); bar = range(3); cols = ('red', 'green', 'blue')
   chans = {'red':2, 'green':1, 'blue':0}

   foo[chans[cols[2-bar[0]]]] = foo[chans[cols[2-bar[0]]]] + 1

is indeed ugly.  But

   i = chans[cols[2-bar[0]]]; foo[i] = foo[i] + 1

is at least just as (un)readable as 

   foo[chans[cols[bar[0]]]] += 1

with the exception, that even newbies get a chance to figure out, 
what the former line is supposed to do without having to read a language 
reference manual telling them something about augmented assignments.

But you are right:  This has been discussed often enough on c.l.p.

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)



From effbot at telia.com  Fri Jun 16 18:24:26 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 18:24:26 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
Message-ID: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>

(the eff-bot is back!)

is there any special reason for this restriction:

Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> a = [1, 2, 3]
>>> a.extend((4, 5, 6))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: list.extend() argument must be a list

from the look of it, it should be trivial to change list.extend
to use the abstract sequence API instead of the list API.

has anyone benchmarked the abstract sequence API?  how
much slower is it?  would it be a good idea to treat lists as
a special case, to avoid slowing down existing code?

other comments?

if I don't hear anything, I'll post patches later this weekend.

</F>




From effbot at telia.com  Fri Jun 16 18:41:36 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 18:41:36 +0200
Subject: [Python-Dev] possible Tkinter speedup
Message-ID: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid>

the _flatten method in Tkinter is one of the major performance
bottlenecks for Python/Tk programmers.  the method "flattens"
a nested sequence, by repeatedly adding tuples to each other.

obviously, this isn't very efficient if the sequences are longer
than, say, five to ten items...  and has of course led to claims
like "wxPython is a thousand times faster than Tkinter".

anyway, taking recent changes to Python into account, it should
be possible to speed this up quite a bit.

the old code looked like this:

    def _flatten(tuple):
        res = ()
        for item in tuple:
            if type(item) in (TupleType, ListType):
                res = res + _flatten(item)
            elif item is not None:
                res = res + (item,)
        return res

after a some trials and errors, here's my proposed replacement:

    def _flatten1(seq):
        res = []
        for item in seq:
            if type(item) in (TupleType, ListType):
                res.extend(_flatten1(item))
            elif item is not None:
                res.append(item)
        return res
    
    def _flatten(seq):
        return tuple(_flatten1(seq))

in my tests, this is slighly faster on very short sequences (two
coordinate pairs, which is a common case for e.g. rectangles),
and much faster on long sequences (polylines, polygons).

for example, for a 5000-point line, it's about 15 times faster.
on a 10,000 point line, it's over 50 times faster.  etc.

comments?

can anyone come up with an even faster way to do this?

if I don't hear anything negative, I'll post patches (etc)

</F>

PS. even after this optimization, uiToolkit is still about 100 times
faster than Tkinter, but that's another story ;-)




From effbot at telia.com  Fri Jun 16 18:47:01 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 18:47:01 +0200
Subject: [Python-Dev] Q: is concatenation and append really the same thing?
Message-ID: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid>

Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
>>> (1, 2, 3) + [1, 2, 3]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only append tuple (not "list") to tuple

is "append" really the right word here?

sure confused the hell out of yours truly...  ("there's no
friggin' append call in this code")

</F>




From jeremy at beopen.com  Fri Jun 16 18:45:07 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 16 Jun 2000 12:45:07 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
Message-ID: <14666.22931.521438.936776@localhost.localdomain>

>>>>> "FL" == Fredrik Lundh <effbot at telia.com> writes:

  FL> has anyone benchmarked the abstract sequence API?  how much
  FL> slower is it?  would it be a good idea to treat lists as a
  FL> special case, to avoid slowing down existing code?

The abstract interface is fairly expensive.  The current code uses
PyList_GET_ITEM to access the elements of the list.  The abstract
interface adds two function calls (PySequence_GetItem,
PyList_GetItem).  The first function just does a couple of sanity
checks (verify arg is sequence & that it has get_item).  The second
function verifies that the arg is a list, then does a bounds check.
None of the work that either of these functions does is necessary for
the list case!

In the extended call syntax implementation, I used PySequence_Tuple to
handle non-standard sequences.  Once converted to a tuple, they can be
processed using the macros.  If you support user-defined sequences,
the sanity checking can get pretty hairy if you don't coerce to a
tuple; e.g. the PySequence_Length method can lie!  

I don't remember considering the cost of allocating the new tuple,
which is only used internally.

Jeremy







From thomas at xs4all.net  Fri Jun 16 18:45:14 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 16 Jun 2000 18:45:14 +0200
Subject: [Python-Dev] Augmented assignment, update
Message-ID: <20000616184514.Q26436@xs4all.nl>

I've more or less finished the augmented-assignment patch I posted last
week. It can be found, including a longish explanation, here:

http://www.xs4all.nl/~thomas/python/

(For those who missed it, the previous posting is here:
http://www.python.org/pipermail/python-list/2000-June/060680.html
The link in the posting, however, points to the new patch.)

I do not know if augmented assignment will every be incorporated into Python
(this patch or something entirely different) but at least noone can claim the
groundwork is missing :-)

Feel free to send questions, comments and verbal abuse my way ;)

-- 
Thomas Wouters <thomas at xs4all.net>

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



From mwh21 at cam.ac.uk  Fri Jun 16 18:53:42 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 16 Jun 2000 17:53:42 +0100
Subject: [Python-Dev] Q: is concatenation and append really the same thing?
In-Reply-To: "Fredrik Lundh"'s message of "Fri, 16 Jun 2000 18:47:01 +0200"
References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid>
Message-ID: <m3ln05wort.fsf@atrus.jesus.cam.ac.uk>

"Fredrik Lundh" <effbot at telia.com> writes:

> Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
> >>> (1, 2, 3) + [1, 2, 3]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: can only append tuple (not "list") to tuple
> 
> is "append" really the right word here?

My fault.  I have sent at least one patch to patches at python.org to
change it to

can only concatenate tuple (not "list") to tuple

to bring it into line with listobject.c; here it is again:

Index: Objects/tupleobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v
retrieving revision 2.34
diff -u -r2.34 tupleobject.c
--- Objects/tupleobject.c	2000/06/01 03:12:13	2.34
+++ Objects/tupleobject.c	2000/06/06 16:30:39
@@ -362,7 +362,7 @@
 	PyTupleObject *np;
 	if (!PyTuple_Check(bb)) {
 		PyErr_Format(PyExc_TypeError,
-       		     "can only append tuple (not \"%.200s\") to tuple",
+       		     "can only concatenate tuple (not \"%.200s\") to tuple",
 			     bb->ob_type->tp_name);
 		return NULL;
 	}

HTH, HAND,
Michael




From mal at lemburg.com  Fri Jun 16 18:53:59 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 18:53:59 +0200
Subject: [Python-Dev] possible Tkinter speedup
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid>
Message-ID: <394A5BA7.F001E220@lemburg.com>

Fredrik Lundh wrote:
> 
> the _flatten method in Tkinter is one of the major performance
> bottlenecks for Python/Tk programmers.  the method "flattens"
> a nested sequence, by repeatedly adding tuples to each other.
> 
> obviously, this isn't very efficient if the sequences are longer
> than, say, five to ten items...  and has of course led to claims
> like "wxPython is a thousand times faster than Tkinter".
> 
> anyway, taking recent changes to Python into account, it should
> be possible to speed this up quite a bit.
> 
> the old code looked like this:
> 
>     def _flatten(tuple):
>         res = ()
>         for item in tuple:
>             if type(item) in (TupleType, ListType):
>                 res = res + _flatten(item)
>             elif item is not None:
>                 res = res + (item,)
>         return res
> 
> after a some trials and errors, here's my proposed replacement:
> 
>     def _flatten1(seq):
>         res = []
>         for item in seq:
>             if type(item) in (TupleType, ListType):
>                 res.extend(_flatten1(item))
>             elif item is not None:
>                 res.append(item)
>         return res
> 
>     def _flatten(seq):
>         return tuple(_flatten1(seq))
> 
> in my tests, this is slighly faster on very short sequences (two
> coordinate pairs, which is a common case for e.g. rectangles),
> and much faster on long sequences (polylines, polygons).
> 
> for example, for a 5000-point line, it's about 15 times faster.
> on a 10,000 point line, it's over 50 times faster.  etc.
> 
> comments?

Why not implement this in C and add it to _tkinter.c ?
It might even make a nice standard builtin...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Fri Jun 16 19:02:22 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 13:02:22 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
Message-ID: <14666.23966.437909.949260@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > if I don't hear anything, I'll post patches later this weekend.

  Sounds good to me!  If lists and tuples are special cased, it
shouldn't even matter if the sequence API is too slow -- that's new
functionality for [].extend(), and can be optimized later if it needs
to be.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Fri Jun 16 19:07:40 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 19:07:40 +0200
Subject: [Python-Dev] Q: is concatenation and append really the same thing?
References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid> <m3ln05wort.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <394A5EDC.7431C900@lemburg.com>

Michael Hudson wrote:
> 
> "Fredrik Lundh" <effbot at telia.com> writes:
> 
> > Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32
> > >>> (1, 2, 3) + [1, 2, 3]
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > TypeError: can only append tuple (not "list") to tuple
> >
> > is "append" really the right word here?
> 
> My fault.  I have sent at least one patch to patches at python.org to
> change it to
> 
> can only concatenate tuple (not "list") to tuple
> 
> to bring it into line with listobject.c; here it is again:
> 
> Index: Objects/tupleobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v
> retrieving revision 2.34
> diff -u -r2.34 tupleobject.c
> --- Objects/tupleobject.c       2000/06/01 03:12:13     2.34
> +++ Objects/tupleobject.c       2000/06/06 16:30:39
> @@ -362,7 +362,7 @@
>         PyTupleObject *np;
>         if (!PyTuple_Check(bb)) {
>                 PyErr_Format(PyExc_TypeError,
> -                            "can only append tuple (not \"%.200s\") to tuple",
> +                            "can only concatenate tuple (not \"%.200s\") to tuple",
>                              bb->ob_type->tp_name);
>                 return NULL;
>         }
> 

Should be in CVS by now...

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Fri Jun 16 19:13:55 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 13:13:55 -0400 (EDT)
Subject: [Python-Dev] mailbox formats
Message-ID: <14666.24659.9174.717901@cj42289-a.reston1.va.home.com>

  I've been playing with a function to open a mailbox and return the
appropriate type of mailbox object from the mailbox module, but I
don't have examples of anything but mbox style mailboxes to test
with.
  Could anyone send real examples of MMDF, MH, maildir, and Babyl
mailboxes?  The mail can be junk; don't send anything I shouldn't see!
  Essentially, I'd like to see two new functions added to the mailbox
module:  open('name'), which returns a mailbox object opened for
reading, and which('name'), which returns the name of the mailbox
constructor, and possibly a flag indicating whether a
__builtin__.open() is needed.
  Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Fri Jun 16 20:59:39 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 20:59:39 +0200
Subject: [Python-Dev] Announcment list
Message-ID: <394A791B.17F5AEFF@lemburg.com>

Does anybody know about the state of the python-announce
mailing list ?

I've sent an announcement there (about mxCGIPython), but have
only received an error message and got no posting back 
from the list. I posted a note to the postmaster at beopen.com,
but have heard nothing from there yet.

Can somebody please look into this ?!

BTW, what about the announcement list -> c.l.p.a gateway ?
Will that happen anytime soon (or do I have to hack the
headers to post there ? ;-)

Here's the error message:
"""
Subject: 
        failure notice
   Date: 
        13 Jun 2000 11:34:39 -0000
   From: 
        MAILER-DAEMON at starship.beopen.com
     To: 
        mal at lemburg.com

Hi. This is the qmail-send program at starship.beopen.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<clpa at python.net>:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <mal at lemburg.com>
Received: (qmail 31495 invoked from network); 13 Jun 2000 11:34:38 -0000
Received: from dinsdale.cnri.reston.va.us (HELO dinsdale.python.org) (132.151.1.21)
  by starship.beopen.com with SMTP; 13 Jun 2000 11:34:38 -0000
Received: by dinsdale.python.org (Postfix)
        id AD6DD1CDE3; Tue, 13 Jun 2000 07:29:56 -0400 (EDT)
Delivered-To: python-announce-people at python.org
...
"""

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bwarsaw at python.org  Fri Jun 16 21:24:21 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Fri, 16 Jun 2000 15:24:21 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
	<14666.23966.437909.949260@cj42289-a.reston1.va.home.com>
Message-ID: <14666.32485.172984.122789@anthem.concentric.net>

>>>>> "Fred" == Fred L Drake, Jr <fdrake at beopen.com> writes:

    Fred>   Sounds good to me!  If lists and tuples are special cased,
    Fred> it shouldn't even matter if the sequence API is too slow --
    Fred> that's new functionality for [].extend(), and can be
    Fred> optimized later if it needs to be.

This has been a typical implementation strategy for a long while now,
and I think successfully so.  When I removed the distinction between
list and tuple unpacking to allow any sequence unpacking (and
incidently w/o special syntax), I did exactly this.  Special case for
tuples and lists, and if it was neither then use the sequence API.

Jeremy's right that this can get hairy if your as anal as I am about
error checking and refcounting.  In addition to PySequence_Length()
ability to lie, there are all sorts of errors that can happen, which
should abort the whole process and clean up any temporary objects.
Plus you've now got three very similar branches in the code, which
adds its own overhead.

So you should decide whether this situation will be used widely enough
to warrant the extra coding complexity for the performance win.
list.extend() is probably not used too often these days, but it should
be 'cause it's cool.  So maybe it's worth it in this case.

On the other hand, this is a situation that comes up often, and if we
were to really audit the APIs, we'd probably find even more cases
where restrictions to concrete lists or tuples should be relaxed to
accept any sequence.  Maybe there's a way we can factor this out in a
single function which handles this once and for all?

-Barry



From paul at prescod.net  Fri Jun 16 21:22:08 2000
From: paul at prescod.net (Paul Prescod)
Date: Fri, 16 Jun 2000 21:22:08 +0200
Subject: [Python-Dev] Augmented assignment
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <394A7E60.6F715424@prescod.net>

Many people have given examples where the augmented assignment version
is substantially more readable. Others have argued that it is more
explicit in that it says *exactly what you mean* rather than using a
more general operator in a specific (common) situation. Another
important argument is that augmented assignment allows *in place*
assignment for some types. That's really important for matrix math etc.

 All of these arguments convince me that this is not a simple matter of
"another notation for what we already do."

> Augmented assignments are unPythonic because they don't add any new
> functionality to the language.  From what I've seen, all people,
> who ever missed it, were experienced C-programmers.  

That's true, but we should not be ashamed to steal good ideas from other
languages. Probably the only people who would miss __getattr__ would be
SmallTalk programmers and the original proponents of the various
operator overloading features may well have come from C++.

> ...
> This feature must be learned
> additionally, where normal assignment are easiely understood from
> school mathematics.  

Not really!

a=a+1 is totally illegal in basic arithmetic.

> It also introduces many more possibilities to make
> subtle mistakes, since it is not obvious (at least to No-C-programmers)
> when and how often the index expression will be valuated.  

As I understand the proposal, the function will be called exactly as
many times as it is printed in the source code:

> versus
>         foo[bar()] += bar()
>         print foo

Presumably bar() gets called twice.

The only argument against this that is persusaive to me is that it makes
the core Python language larger and thus a (little) harder to learn. My
impression is that the design of the feature has been well done.

My personal opinion is that the cost in education probably outweighs the
benefits in clarity but others who work a lot with matrices etc. would
probably have a different view.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Music is the stuff between the notes." - Claude Debussy




From petrilli at amber.org  Fri Jun 16 21:42:46 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Fri, 16 Jun 2000 15:42:46 -0400
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <394A7E60.6F715424@prescod.net>; from paul@prescod.net on Fri, Jun 16, 2000 at 09:22:08PM +0200
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de> <394A7E60.6F715424@prescod.net>
Message-ID: <20000616154246.A5513@trump.amber.org>

Paul Prescod [paul at prescod.net] wrote:
> That's true, but we should not be ashamed to steal good ideas from other
> languages. Probably the only people who would miss __getattr__ would be
> SmallTalk programmers and the original proponents of the various
> operator overloading features may well have come from C++.

Actually as a good Talker, I write methods for everything, so I almost 
nver use __getattr__ except as a way to force people to use methods
and not directly access attributes. Long story.

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From fdrake at beopen.com  Fri Jun 16 21:42:12 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 15:42:12 -0400 (EDT)
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <14666.32485.172984.122789@anthem.concentric.net>
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid>
	<14666.23966.437909.949260@cj42289-a.reston1.va.home.com>
	<14666.32485.172984.122789@anthem.concentric.net>
Message-ID: <14666.33556.123258.252030@cj42289-a.reston1.va.home.com>

Barry A. Warsaw writes:
 > Jeremy's right that this can get hairy if your as anal as I am about
 > error checking and refcounting.  In addition to PySequence_Length()
 > ability to lie, there are all sorts of errors that can happen, which
 > should abort the whole process and clean up any temporary objects.
 > Plus you've now got three very similar branches in the code, which
 > adds its own overhead.
 > 
 > So you should decide whether this situation will be used widely enough
 > to warrant the extra coding complexity for the performance win.
 > list.extend() is probably not used too often these days, but it should
 > be 'cause it's cool.  So maybe it's worth it in this case.
 > 
 > On the other hand, this is a situation that comes up often, and if we
 > were to really audit the APIs, we'd probably find even more cases
 > where restrictions to concrete lists or tuples should be relaxed to
 > accept any sequence.  Maybe there's a way we can factor this out in a
 > single function which handles this once and for all?

  How about this: special case the list & tuple flavors (since that'll
be roughly what's in there now), and for other sequences, convert to
either a tuple or a list and let it pass through that special case,
keeping a flag to discard the temporary list when done?
  There are two APIs, PySequence_List() and PySequence_Tuple(), which
can take care of a lot of the machinery in dealing with sequences that
lie about their length or otherwise break (during __getitem__() calls
or whatever), that a large part of the work is done.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Fri Jun 16 21:45:16 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Jun 2000 21:45:16 +0200
Subject: [Python-Dev] Augmented assignment
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de> <394A7E60.6F715424@prescod.net>
Message-ID: <394A83CC.98F177DC@lemburg.com>

Paul Prescod wrote:
> > Augmented assignments are unPythonic because they don't add any new
> > functionality to the language.  From what I've seen, all people,
> > who ever missed it, were experienced C-programmers.
> 
> That's true, but we should not be ashamed to steal good ideas from other
> languages. Probably the only people who would miss __getattr__ would be
> SmallTalk programmers and the original proponents of the various
> operator overloading features may well have come from C++.

Don't forget the crowd of people doing environmental acquisition
(you know who they are ;-).

Honestly, I think that __getattr__ is one of the most useful
hooks available on Python objects.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jeremy at beopen.com  Fri Jun 16 22:01:18 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 16 Jun 2000 16:01:18 -0400 (EDT)
Subject: [Python-Dev] Augmented assignment
In-Reply-To: <394A83CC.98F177DC@lemburg.com>
References: <m132hDp-000DieC@artcom0.artcom-gmbh.de>
	<394A7E60.6F715424@prescod.net>
	<394A83CC.98F177DC@lemburg.com>
Message-ID: <14666.34702.801826.453565@localhost.localdomain>

I'm leery of acquisition, but we gotta have __getattr__.

Jeremy

>>>>> "MAL" == M -A Lemburg <mal at lemburg.com> writes:

  MAL> Paul Prescod wrote:
  >> > Augmented assignments are unPythonic because they don't add any
  >> > new functionality to the language.  From what I've seen, all
  >> > people, who ever missed it, were experienced C-programmers.
  >> 
  >> That's true, but we should not be ashamed to steal good ideas
  >> from other languages. Probably the only people who would miss
  >> __getattr__ would be SmallTalk programmers and the original
  >> proponents of the various operator overloading features may well
  >> have come from C++.

  MAL> Don't forget the crowd of people doing environmental
  MAL> acquisition (you know who they are ;-).

  MAL> Honestly, I think that __getattr__ is one of the most useful
  MAL> hooks available on Python objects.




From fdrake at beopen.com  Fri Jun 16 23:44:05 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 16 Jun 2000 17:44:05 -0400 (EDT)
Subject: [Python-Dev] possible Tkinter speedup
In-Reply-To: <394A5BA7.F001E220@lemburg.com>
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid>
	<394A5BA7.F001E220@lemburg.com>
Message-ID: <14666.40869.331831.90682@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Why not implement this in C and add it to _tkinter.c ?

  I think this is the right approach; do you have an implementation?  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From effbot at telia.com  Fri Jun 16 23:50:58 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 16 Jun 2000 23:50:58 +0200
Subject: [Python-Dev] possible Tkinter speedup
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com>
Message-ID: <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid>

mal wrote:
> > for example, for a 5000-point line, it's about 15 times faster.
> > on a 10,000 point line, it's over 50 times faster.  etc.
> > 
> > comments?
> 
> Why not implement this in C and add it to _tkinter.c ?
> It might even make a nice standard builtin...

bang for the buck?

getting a working C version is a whole lot of work, and I'd rather
spend that time on things that can speed things up a whole lot
more [1].  but if it's still raining tomorrow...

</F>

1) http://w1.132.telia.com/~u13208596/tkinter




From effbot at telia.com  Sat Jun 17 00:33:43 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 00:33:43 +0200
Subject: [Python-Dev] possible Tkinter speedup
References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com> <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid>
Message-ID: <017101bfd7e2$f2d3a2c0$f2a6b5d4@hagrid>

eff-bot wrote:
> bang for the buck?
> 
> getting a working C version is a whole lot of work

okay, I just proved that I don't know what I'm talking about.  it wasn't
that hard, and the performance boost is rather interesting...

for 5000 vertices:

    Tkinter 1.6:
        10.44 seconds
    Tkinter 1.6 with new flatten:
        0.27 seconds
    Tkinter 1.6 with C version of flatten:
        2.57 milliseconds

patch follows.

</F>




From effbot at telia.com  Sat Jun 17 09:55:16 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 09:55:16 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> <14666.22931.521438.936776@localhost.localdomain>
Message-ID: <003501bfd831$8bb11a60$f2a6b5d4@hagrid>

jeremy wrote:

>   FL> has anyone benchmarked the abstract sequence API?  how much
>   FL> slower is it?  would it be a good idea to treat lists as a
>   FL> special case, to avoid slowing down existing code?
> 
> The abstract interface is fairly expensive.  The current code uses
> PyList_GET_ITEM to access the elements of the list.  The abstract
> interface adds two function calls (PySequence_GetItem,
> PyList_GetItem).  The first function just does a couple of sanity
> checks (verify arg is sequence & that it has get_item).  The second
> function verifies that the arg is a list, then does a bounds check.
> None of the work that either of these functions does is necessary for
> the list case!

just for the record, I just changed some generic sequence code
to something like:

    if (PyList_Check(seq) || PyTuple_Check(seq))
        Py_INCREF(seq);
    else if (PySequence_Check(seq)) {
        seq = PySequence_Tuple(seq);
        if (!seq)
            return NULL;
    } else {
        PyErr_SetString(PyExc_TypeError, "argument must be a sequence");
        return NULL;
    }

    ... allocate PyObject_Length(seq) slots ...

    if (PyList_Check(seq))
        ... list code using PyList_GET_ITEM
    else
        ... tuple code using PyTuple_GET_ITEM

    Py_DECREF(seq);

for the standard case (lists, in this case), this resulted in a
total speedup of 4 times (this includes some other overhead).

so in other words, this construct is more than 4 times faster
than plain use of PySequence_GetItem.

guess it's time to fix a couple of things in PIL...

</F>




From mhammond at skippinet.com.au  Sat Jun 17 10:16:18 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 17 Jun 2000 18:16:18 +1000
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
In-Reply-To: <003501bfd831$8bb11a60$f2a6b5d4@hagrid>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au>

/F:
> just for the record, I just changed some generic sequence code
> to something like:
...
> so in other words, this construct is more than 4 times faster
> than plain use of PySequence_GetItem.

Good stuff!

> guess it's time to fix a couple of things in PIL...

Its a fair bit of code to duplicate everywhere you want the speed increase.
How can we add a similar scheme to the core, so the changes people need to
make are trivial (to the point where the change is zero!)?

Mark.




From effbot at telia.com  Sat Jun 17 10:40:20 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 10:40:20 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au>
Message-ID: <006a01bfd837$ac689840$f2a6b5d4@hagrid>

mark wrote:
> > so in other words, this construct is more than 4 times faster
> > than plain use of PySequence_GetItem.
> 
> Good stuff!
> 
> > guess it's time to fix a couple of things in PIL...
> 
> Its a fair bit of code to duplicate everywhere you want the speed increase.
> How can we add a similar scheme to the core, so the changes people need to
> make are trivial (to the point where the change is zero!)?

the first part is trivial; just add something like this to
Objects/abstract.c:

PyObject*
PySequence_TupleOrList(PyObject* seq)
{
    if (PyList_Check(seq) || PyTuple_Check(seq))
        Py_INCREF(seq);
    else if (PySequence_Check(seq))
        seq = PySequence_Tuple(seq);
    else {
        PyErr_SetString(PyExc_TypeError, "argument must be a sequence");
        seq = NULL;
    }
    return seq;
}

the second parts is harder -- and that's of course where the
real performance boost comes from.  as far as I'm aware, very
few C compilers can "specialize" loops for you...

</F>




From mal at lemburg.com  Sat Jun 17 10:41:25 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 10:41:25 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au>
Message-ID: <394B39B5.B478720E@lemburg.com>

Mark Hammond wrote:
> 
> /F:
> > just for the record, I just changed some generic sequence code
> > to something like:
> ...
> > so in other words, this construct is more than 4 times faster
> > than plain use of PySequence_GetItem.
> 
> Good stuff!
> 
> > guess it's time to fix a couple of things in PIL...
> 
> Its a fair bit of code to duplicate everywhere you want the speed increase.
> How can we add a similar scheme to the core, so the changes people need to
> make are trivial (to the point where the change is zero!)?

We could add special code the standard type to PySequence_GetItem()
et al., but it would still cause a C function call (not much,
but noticable in inner loops).

How about adding some inline markers to the most often
used (and small) routines in the medium level abstract interface
(PySequence_*, PyMapping_*, etc.) ?!

Together with the special code for the native Python types
this should yield a speedup for all extensions by simple
virtue of a recompile... OTOH, changes to these APIs would
need a recompile of the extensions too.

BTW, I've used the same approach as Fredrik in mx.Tools.
It does make great a difference...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From mal at lemburg.com  Sat Jun 17 10:53:20 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 10:53:20 +0200
Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)
References: <20000617000834.C29B41CF4A@dinsdale.python.org>
Message-ID: <394B3C80.248B4CB1@lemburg.com>

cfandrich at 8cs.com wrote:
> 
> Full_Name: Christopher Fandrich
> Version: 1.5.2
> OS: Windows
> Submission from: (NULL) (208.41.174.4)
> 
> I'm embedding Python in an application.  For now, all I'm doing is initializing
> and finalizing Python.
> 
> When I run my app I get a memory leak of 12288 bytes.  The memory is malloc'ed
> by dictresize() which is called by PyDict_SetItem() which is called by
> PyString_InternInPlace().
> 
> For now, I've added
>     PyDict_Clear(interned);
>     interned = NULL;
> to PyString_Fini().  So far it works fine, but I don't know if it's safe to do
> in the grand scheme of things.

I would suggest adding code to dealloc the interned dict
iff it is empty after the sweeping action in PyString_Fini().
I have a feeling that this is not the case though, since interned
strings are used quite a lot in the core interpreter (e.g. in
classobject.c) and these are usually not recovered.

Perhaps we ought to add some code which takes care of cleaning
up all remaining garbage left over after the call to
call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
of all interned strings and cached ints/floats and associated
free lists or dicts.

We'd need new APIs in string|float|intobject.c to implement this.

Thoughts ? Patches ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Sat Jun 17 14:45:57 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 14:45:57 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid>
Message-ID: <00d701bfd859$fd435300$f2a6b5d4@hagrid>

the eff-bot wrote:

> the first part is trivial; just add something like this to
> Objects/abstract.c:
> 
> PyObject*
> PySequence_TupleOrList(PyObject* seq)
> ...
> 
> the second parts is harder -- and that's of course where the
> real performance boost comes from.  as far as I'm aware, very
> few C compilers can "specialize" loops for you...

in the same test setup, moving the PyList_Check inside the
loop gives a 25-30% slowdown (or to look at it from the other
side, 3 times instead of 4 times faster than naive code).

a compromise solution could be to combine the above function
with a macro:

    #define PySequence_TupleOrList_GET_ITEM(seq, index)\
        (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\
        PyTuple_GET_ITEM(seq, index)

(anyone got a better name? ;-)

standard usage:

    seq = PySequence_TupleOrList(seq_in);

    size = PyObject_Length(seq);
    
    for (i = 0; i < size; i++) {
        PyObject* obj = PySequence_TupleOrList_GET_ITEM(seq, i);
        ...
    }

comments?

</F>




From mal at lemburg.com  Sat Jun 17 16:18:26 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 16:18:26 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid>
Message-ID: <394B88B2.EA116971@lemburg.com>

Fredrik Lundh wrote:
> 
> the eff-bot wrote:
> 
> > the first part is trivial; just add something like this to
> > Objects/abstract.c:
> >
> > PyObject*
> > PySequence_TupleOrList(PyObject* seq)
> > ...
> >
> > the second parts is harder -- and that's of course where the
> > real performance boost comes from.  as far as I'm aware, very
> > few C compilers can "specialize" loops for you...
> 
> in the same test setup, moving the PyList_Check inside the
> loop gives a 25-30% slowdown (or to look at it from the other
> side, 3 times instead of 4 times faster than naive code).
> 
> a compromise solution could be to combine the above function
> with a macro:
> 
>     #define PySequence_TupleOrList_GET_ITEM(seq, index)\
>         (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\
>         PyTuple_GET_ITEM(seq, index)
> 
> (anyone got a better name? ;-)
> 
> standard usage:
> 
>     seq = PySequence_TupleOrList(seq_in);
> 
>     size = PyObject_Length(seq);
> 
>     for (i = 0; i < size; i++) {
>         PyObject* obj = PySequence_TupleOrList_GET_ITEM(seq, i);
>         ...
>     }
> 
> comments?

The above looks a lot like an iterator... how about
providing a standard PySequence_Iterate(obj, callback)
with the callback being called for every element of the
sequence ?!

The iterator could then be optimized for lists and tuples.
Not as fast as inlining, but a more generic solution...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Sat Jun 17 16:42:52 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 16:42:52 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com>
Message-ID: <010401bfd86a$5282cca0$f2a6b5d4@hagrid>

mal wrote:
> The above looks a lot like an iterator... how about
> providing a standard PySequence_Iterate(obj, callback)
> with the callback being called for every element of the
> sequence ?!

PySequence_Enumerate, perhaps?

> The iterator could then be optimized for lists and tuples.
> Not as fast as inlining, but a more generic solution...

more generic than useful, imo:

    - it's slower.

    - it's awkward to use: you need to put the state in a
      structure, invert your program logic, etc.

    - it doesn't scale: what if you want to loop over two
      structures?  what if you want to loop over two objects,
      using two different indices?

</F>





From mal at lemburg.com  Sat Jun 17 16:44:47 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 17 Jun 2000 16:44:47 +0200
Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface?
References: <ECEPKNMJLHAPFFJHDOJBAEJDCNAA.mhammond@skippinet.com.au> <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com> <010401bfd86a$5282cca0$f2a6b5d4@hagrid>
Message-ID: <394B8EDF.57630FE9@lemburg.com>

Fredrik Lundh wrote:
> 
> mal wrote:
> > The above looks a lot like an iterator... how about
> > providing a standard PySequence_Iterate(obj, callback)
> > with the callback being called for every element of the
> > sequence ?!
> 
> PySequence_Enumerate, perhaps?
>
> > The iterator could then be optimized for lists and tuples.
> > Not as fast as inlining, but a more generic solution...
> 
> more generic than useful, imo:
> 
>     - it's slower.
> 
>     - it's awkward to use: you need to put the state in a
>       structure, invert your program logic, etc.
> 
>     - it doesn't scale: what if you want to loop over two
>       structures?  what if you want to loop over two objects,
>       using two different indices?

Or perhaps, use a different iteration technique: the one
used by PyDict_Next(). It doesn't need a callback, but
instead plays with pointers you pass to it via output
variables.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Sat Jun 17 17:44:58 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 17 Jun 2000 17:44:58 +0200
Subject: [Python-Dev] proposal: core support for "fast" sequence iteration
Message-ID: <011901bfd873$00632740$f2a6b5d4@hagrid>

mark wrote:

> Its a fair bit of code to duplicate everywhere you want the speed increase.
> How can we add a similar scheme to the core, so the changes people need to
> make are trivial (to the point where the change is zero!)?

okay, here's my current proposal:

    PyObject* PySequence_Fast(PyObject *o) 

        Return value: New reference. 

        Returns the o as a tuple or a list on success, and
        NULL on failure.  If o doesn't have the right type,
        it is converted to a tuple using PySequence_Tuple.

        This is equivalent to the following Python code:

            if type(o) in (ListType, TupleType):
                return o
            return tuple(o)

        This function is intended to be used together with
        PySequence_Fast_GET_ITEM, for functions that need
        to loop over a read-only sequence as fast as they
        possibly can, while still supporting any object that
        implements the sequence protocol.

    PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i)

        Return value: Borrowed reference. 

        Returns the object at position i, from the sequence
        seq (which must be a list or a tuple).  This is a
        macro, and has no error checking.

        If you need error checking, use PySequence_GetItem.

for the rationale, see my earlier posts in the "list.extend" thread.

unless somebody comes up with a more efficient solution, I'll wrap
this up together with the list.extend patch (first thing tomorrow).

</F>




From gstein at lyra.org  Sat Jun 17 22:52:31 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 17 Jun 2000 13:52:31 -0700
Subject: [Python-Dev] proposal: core support for "fast" sequence iteration
In-Reply-To: <011901bfd873$00632740$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jun 17, 2000 at 05:44:58PM +0200
References: <011901bfd873$00632740$f2a6b5d4@hagrid>
Message-ID: <20000617135231.E29590@lyra.org>

+1

coolness.


On Sat, Jun 17, 2000 at 05:44:58PM +0200, Fredrik Lundh wrote:
> mark wrote:
> 
> > Its a fair bit of code to duplicate everywhere you want the speed increase.
> > How can we add a similar scheme to the core, so the changes people need to
> > make are trivial (to the point where the change is zero!)?
> 
> okay, here's my current proposal:
> 
>     PyObject* PySequence_Fast(PyObject *o) 
> 
>         Return value: New reference. 
> 
>         Returns the o as a tuple or a list on success, and
>         NULL on failure.  If o doesn't have the right type,
>         it is converted to a tuple using PySequence_Tuple.
> 
>         This is equivalent to the following Python code:
> 
>             if type(o) in (ListType, TupleType):
>                 return o
>             return tuple(o)
> 
>         This function is intended to be used together with
>         PySequence_Fast_GET_ITEM, for functions that need
>         to loop over a read-only sequence as fast as they
>         possibly can, while still supporting any object that
>         implements the sequence protocol.
> 
>     PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i)
> 
>         Return value: Borrowed reference. 
> 
>         Returns the object at position i, from the sequence
>         seq (which must be a list or a tuple).  This is a
>         macro, and has no error checking.
> 
>         If you need error checking, use PySequence_GetItem.
> 
> for the rationale, see my earlier posts in the "list.extend" thread.
> 
> unless somebody comes up with a more efficient solution, I'll wrap
> this up together with the list.extend patch (first thing tomorrow).
> 
> </F>
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev

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



From gstein at lyra.org  Sun Jun 18 00:37:26 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 17 Jun 2000 15:37:26 -0700
Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)
In-Reply-To: <394B3C80.248B4CB1@lemburg.com>; from mal@lemburg.com on Sat, Jun 17, 2000 at 10:53:20AM +0200
References: <20000617000834.C29B41CF4A@dinsdale.python.org> <394B3C80.248B4CB1@lemburg.com>
Message-ID: <20000617153726.H29590@lyra.org>

On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote:
>...
> I would suggest adding code to dealloc the interned dict
> iff it is empty after the sweeping action in PyString_Fini().
> I have a feeling that this is not the case though, since interned
> strings are used quite a lot in the core interpreter (e.g. in
> classobject.c) and these are usually not recovered.
> 
> Perhaps we ought to add some code which takes care of cleaning
> up all remaining garbage left over after the call to
> call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
> of all interned strings and cached ints/floats and associated
> free lists or dicts.
> 
> We'd need new APIs in string|float|intobject.c to implement this.
> 
> Thoughts ? Patches ?

I would definitely like to see this, and suggested it to Guido about four
years ago :-)

During my threading work, I looked at all the globals, which includes the
pools and the one-off allocations in classobject.c and friends. I figured it
would be a Good Thing(tm) to write a general object pool API which could be
used by tuples, floats, frames, etc. Having the single implementation of a
pool would mean that we could add thread locks in a single place.

Similarly, for cleanup reasons, I also suggested a general API for
allocating the "constants" and torching them at shutdown.

As we all know, though... suggestions don't mean crap. Code counts. :-)

That said, I'll look into some of this with the free-threading work. That is
all post-1.6, though. It would be great if somebody could do it before then.

Cheers,
-g

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



From Vladimir.Marangozov at inrialpes.fr  Sun Jun 18 01:01:30 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Sun, 18 Jun 2000 01:01:30 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)
In-Reply-To: <20000617153726.H29590@lyra.org> from "Greg Stein" at Jun 17, 2000 03:37:26 PM
Message-ID: <200006172301.BAA01642@python.inrialpes.fr>

Greg Stein wrote:
> 
> On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote:
> >...
> > Perhaps we ought to add some code which takes care of cleaning
> > up all remaining garbage left over after the call to
> > call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
> > of all interned strings and cached ints/floats and associated
> > free lists or dicts.
> > 
> > We'd need new APIs in string|float|intobject.c to implement this.
> > 
> > Thoughts ? Patches ?
> 
> I would definitely like to see this, and suggested it to Guido about four
> years ago :-)
> 
> During my threading work, I looked at all the globals, which includes the
> pools and the one-off allocations in classobject.c and friends. I figured it
> would be a Good Thing(tm) to write a general object pool API which could be
> used by tuples, floats, frames, etc. Having the single implementation of a
> pool would mean that we could add thread locks in a single place.
> 
> Similarly, for cleanup reasons, I also suggested a general API for
> allocating the "constants" and torching them at shutdown.
> 
> As we all know, though... suggestions don't mean crap. Code counts. :-)

pymalloc (the debugging stuff put aside) is an efficient implementation
of this pool concept. The interface just needs to be exported under an
appropriate PyObject_ API, not as a general malloc replacement. Maybe
it needs some more work regarding finalization, but the code is there.
Per pool locking is there too. Maybe it needs to be adjusted wrt the
pool granularity we want.

The various core object allocators would use this API with PyObject_NEW
inlined.

> 
> That said, I'll look into some of this with the free-threading work. That is
> all post-1.6, though. It would be great if somebody could do it before then.

Voila.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From Vladimir.Marangozov at inrialpes.fr  Sun Jun 18 02:50:51 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Sun, 18 Jun 2000 02:50:51 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11
In-Reply-To: <200006172241.PAA02080@slayer.i.sourceforge.net> from "A.M. Kuchling" at Jun 17, 2000 03:41:24 PM
Message-ID: <200006180050.CAA07547@python.inrialpes.fr>

A.M. Kuchling wrote:
>
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060
>
> Modified Files:
>       mmapmodule.c
> Log Message:
> Fix the size() method to return the size of the file on Unix, not the
> size of the mapped area.  This seems to be what the Windows version does.
> This change requires keeping around the fd of the mapped file.

On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
It works okay without the MS_INVALIDATE flag though, so I'd suggest
removing it from msync in the flush and dealloc methods.

Also, it would probably be a good idea to allow optional flags for
flush, as it's done in new_mmap_object, the default being only MS_SYNC.

Given that this module is enabled by default, I think that it needs some
more stress-testing in test_mmap.py. I'll try to add a couple of tests
shortly.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From trentm at activestate.com  Sun Jun 18 05:20:09 2000
From: trentm at activestate.com (Trent Mick)
Date: Sat, 17 Jun 2000 20:20:09 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11
In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr>
References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr>
Message-ID: <20000617202009.A20019@activestate.com>

On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote:
> 
> A.M. Kuchling wrote:
> >
> > Update of /cvsroot/python/python/dist/src/Modules
> > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060
> >
> > Modified Files:
> >       mmapmodule.c
> > Log Message:
> > Fix the size() method to return the size of the file on Unix, not the
> > size of the mapped area.  This seems to be what the Windows version does.
> > This change requires keeping around the fd of the mapped file.
> 
> On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
> It works okay without the MS_INVALIDATE flag though, so I'd suggest
> removing it from msync in the flush and dealloc methods.
> 
> Also, it would probably be a good idea to allow optional flags for
> flush, as it's done in new_mmap_object, the default being only MS_SYNC.
> 
> Given that this module is enabled by default, I think that it needs some
> more stress-testing in test_mmap.py. I'll try to add a couple of tests
> shortly.
> 

Just to add to the mmap fray. The seek() method is broken for any 'whence'
value (seek from start, current, orend) other than the default. Ihave a patch
that fixes that as well as gets mmap'd files working on Linux64 and Win64.
The test_mmap was also extended. The patch is up on SourceForge for your
perusal. :)

https://sourceforge.net/patch/?func=detailpatch&patch_id=100515&group_id=5470

Cheers,
Trent

-- 
Trent Mick
trentm at activestate.com



From mhammond at skippinet.com.au  Sun Jun 18 05:35:00 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 18 Jun 2000 13:35:00 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1
In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEJKCNAA.mhammond@skippinet.com.au>

> Documentation for the mmap module: proofreaders welcomed

OK :-)


> the file handle \var{fileno}, and returns a mmap object.  If you have
> a Python file object, its
> \method{fileno()} method returns the file's handle, which is
> just an integer.

This could be a little clearer - on first reading, I thought you were
talking about the return value.  Maybe something like: "if you wish to pass
an existing Python file object for this parameter, use its
\method{fileno()} method to obtain the fileno."


> \var{tagname}, if specified, is a string giving a tag name for
> the mapping. XXX what is the purpose of the tag name?

Something like: Windows allows you to have many different mappings against
the same file.  If you specify the name of an existing tag, that tag is
opened, otherwise a new tag of this name is created.  If this parameter is
None, the mapping is created without a name.  Avoiding the use of the tag
parameter will assist in keeping your code portable between Unix and
Windows.

> \begin{funcdesc}{mmap}{file, size \optional{, flags, prot}}
> (Unix version) Maps \var{length} bytes from the file specified by the
> file handle \var{fileno}, and returns a mmap object.  If you have a
> Python file object, its \method{fileno()} method returns the file's
> handle, which is just an integer.

I believe you mean the signature to say "fileno" instead of "file" - this
makes it consistent with the Windows signature, and reinforces that this
param is indeed identical.

As a meta-comment, the structure of this implies that the param signatures
are more different than they are - eg, it should be possible to write
portable mmap code in most cases, without concern for the platform.  the
platform only becomes relevant when you use the optional params for each
platform?


> \begin{methoddesc}{read}{\var{num}}
> Return a string containing up to \var{num} bytes taken from the

"taken from" -> "starting from" ??

> \begin{methoddesc}{write_byte}{\var{byte}}
> Write \var{byte} into memory at the current position of
> the file pointer; the file position is advanced by 1.
> \end{methoddesc}

The type of "byte" should be explained - its never clear to me if a "byte"
should be an int or a string of size 1.  In this case, it is the latter.

Looks good!

Mark.




From mhammond at skippinet.com.au  Sun Jun 18 05:35:33 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 18 Jun 2000 13:35:33 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1
In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEJLCNAA.mhammond@skippinet.com.au>

Sorry about that - I meant to send it direct to Andrew...

Mark.




From Vladimir.Marangozov at inrialpes.fr  Sun Jun 18 06:24:05 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Sun, 18 Jun 2000 06:24:05 +0200 (CEST)
Subject: [Python-Dev] Towards selective compilation to native code?
Message-ID: <200006180424.GAA14040@python.inrialpes.fr>

There was a cool seminar the other day here, focusing on embedded &
real-time Java, so I'll throw here some impressions while they're fresh.
One of the presenters talked extensively about compilation strategies and
techniques for Java bytecode to native code, and while I know that Java
is not Python, it would be interesting to, at least, try to project some
of the ideas to Python in the long run, where applicable.

Needless to say, the guy & his environment (ex-OSF, now Silicomp) are
experts in compiler technology and I'm not in a position to comment on
everything, but you may find the second half of the slides enlightening: 
http://cgi-serv.inrialpes.fr/InTech/2000-06-15/ejava-silicomp.ppt

So, the interesting part of the talk was about a "new" compiler
architecture, built upon the concept of "Flash compiling" (quite
unappropriate name), which produces a mixture of the following:

  1. Bytecode
  2. Native code
  3. Native code is compiled selectively on demand and/or ahead of time
     (!= JIT) for "expensive" methods.
  4. Expensive methods are, on one hand, detected by dynamic profiling
     of the bytecode, and OTOH, determined ahead of time according to the
     following 2 simple creteria:
       - methods containing loops
       - methods calling native code from bytecode
           (to avoid bytecode to native and vice versa arg conversion paths
            which are expensive -- btw Python has the same perf. bottleneck)
  5. Everything relies on dyn loading & late binding of native code
     (front-end loads dynamically the back-end, native code is stored
     in the code stream, but linked incrementally & dynamically during
     execution)
  6. The whole thing is designed to avoid code explosion and to preserve
     the advantage of bytecode == small code size, and the presented
     preliminary results are quite optimistic -- the figures differ depending
     on the code size / speed tradeoff.

Of course, this is Java and there's static typing in there, but it
would be interesting to see whether Python can steal something from these
ideas. For instance, I'm trying to foresee what kind of static typing
(i.e. how much static info) would be appropriate in Python from this
point of view but I fail to obtain any realistic image :).
I see most parts of the dyn loading / late binding aspect though --
they are typical for Python.

Hm. Sounds like I'll be harrassing Tim to make him finally write something
valuable for Python ;-)

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From akuchlin at cnri.reston.va.us  Sun Jun 18 06:22:24 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sun, 18 Jun 2000 00:22:24 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11
In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 02:50:51AM +0200
References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr>
Message-ID: <20000618002224.A12729@newcnri.cnri.reston.va.us>

On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote:
>On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
>It works okay without the MS_INVALIDATE flag though, so I'd suggest
>removing it from msync in the flush and dealloc methods.

Ooh, you're right.  The Linux msync man page says "MS_ASYNC specifies
that an update be scheduled, but the call returns immediately.
MS_SYNC asks for an update and waits for it to complete.
MS_INVALIDATE asks to invalidate other mappings of the same file (so
that they can be updated with the fresh values just written)."  So
MS_INVALIDATE seems far too drastic.

>Also, it would probably be a good idea to allow optional flags for
>flush, as it's done in new_mmap_object, the default being only MS_SYNC.

The problem is: does Windows provide equivalent functionality?  (Is
there documentation available online for CreateFileMapping that I
could look at?)

>Given that this module is enabled by default, I think that it needs some
>more stress-testing in test_mmap.py. I'll try to add a couple of tests
>shortly.

Good idea.  I'll try to look at Trent Mick's patch and apply it ASAP
if it checks out.

--amk



From akuchlin at cnri.reston.va.us  Sun Jun 18 07:03:16 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sun, 18 Jun 2000 01:03:16 -0400
Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule
In-Reply-To: <Pine.LNX.4.10.10006171623520.11690-100000@sancho.ccd.uniroma2.it>; from lorenzo@sancho.ccd.uniroma2.it on Sat, Jun 17, 2000 at 04:29:14PM +0200
References: <Pine.LNX.4.10.10006171623520.11690-100000@sancho.ccd.uniroma2.it>
Message-ID: <20000618010316.D12729@newcnri.cnri.reston.va.us>

On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote:
>therefore, here is the change: if we are compiling for linux, define
>_GNU_SOURCE before including mman.h, and all is done. It seems the

Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present,
that doesn't imply that mremap() doesn't work at all; instead, a
resize may fail if the mapping would have to be moved to a different
virtual address.  Quoting from the Linux man page:

       MREMAP_MAYMOVE
              indicates  if  the operation should fail, or change
              the virtual address if the resize cannot be done at
              the current virtual address.

I think the correct fix is to simply specify MREMAP_MAYMOVE if it's
defined, but still support attempting to resize. Possibly the
configure script should also check for mremap()'s existence.

--amk



From lorenzo at sancho.ccd.uniroma2.it  Sun Jun 18 09:39:55 2000
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Sun, 18 Jun 2000 09:39:55 +0200 (CEST)
Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule
In-Reply-To: <20000618010316.D12729@newcnri.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10006180859570.2676-100000@sancho.ccd.uniroma2.it>

On Sun, 18 Jun 2000, Andrew Kuchling wrote:

AK> On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote:
AK> >therefore, here is the change: if we are compiling for linux, define
AK> >_GNU_SOURCE before including mman.h, and all is done. It seems the
AK> 
AK> Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present,
AK> that doesn't imply that mremap() doesn't work at all; instead, a
AK> resize may fail if the mapping would have to be moved to a different
AK> virtual address.  Quoting from the Linux man page:
AK> 
AK>        MREMAP_MAYMOVE
AK>               indicates  if  the operation should fail, or change
AK>               the virtual address if the resize cannot be done at
AK>               the current virtual address.
AK> 
AK> I think the correct fix is to simply specify MREMAP_MAYMOVE if it's
AK> defined, but still support attempting to resize. Possibly the
AK> configure script should also check for mremap()'s existence.
AK> 

I think I've been too dense... Here I see two problems: on one hand, from
what I have understood of python's object, it's much better if the c
pointers are movable in VM on the remap, and the MAYMOVE flag is only
defined in mman.h if _GNU_SOURCE is; on the other hand, we only know
about linux mremap semantics: for what I see in linix mremap(2)

"""
CONFORMING TO
       This  call  is  Linux-specific,  and should not be used in
       programs intended to be portable.   4.2BSD  had  a  (never
       actually  implemented) mremap(2) call with completely dif?
       ferent semantics.
"""

Therefore, I think that really checking for __linux__ and using the
MAYMOVE flag, which is thefined there, is going towards the right way. If
someone else comes out with another kernel supporting a mremap syscall[1],
I think we'll be able to add proper support afterwards. As for the
configure script, on linux we have both mremap and MAYMOVE; if you go to
the <a href="http://www.gnu.org/software/libc/all-M.html">Extended UNIX ABI, M*
</a> Page, 

you'll find:

	GNU Unix98 Unix95 POSIX ISO C SVID 3 4.3BSD XPG
mremap   X

It seems only the systems supported by GNU libc-2 (only linux systems,
then) support mremap...

Have a nice time.


lmc


* Just tried searching for mremap on 
http://www.FreeBSD.org/cgi/man.cgi?query=mmap
and looked around the various BSD derivatives whose man pages are
available there. 

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+




From petrilli at amber.org  Sun Jun 18 20:50:22 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Sun, 18 Jun 2000 14:50:22 -0400
Subject: [Python-Dev] Towards selective compilation to native code?
In-Reply-To: <200006180424.GAA14040@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 06:24:05AM +0200
References: <200006180424.GAA14040@python.inrialpes.fr>
Message-ID: <20000618145022.A13031@trump.amber.org>

Vladimir Marangozov [Vladimir.Marangozov at inrialpes.fr] wrote:
> 
> Of course, this is Java and there's static typing in there, but it
> would be interesting to see whether Python can steal something from these
> ideas. For instance, I'm trying to foresee what kind of static typing
> (i.e. how much static info) would be appropriate in Python from this
> point of view but I fail to obtain any realistic image :).
> I see most parts of the dyn loading / late binding aspect though --
> they are typical for Python.

One might take a look at Smalltalk/X which compiles into C, and has a
pretty (ney very) high performance reputation.  There are some other
Smalltalk implementations taht do this as well.  This would be closer
I think to what Python would use than Java will be.  

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From effbot at telia.com  Sun Jun 18 21:06:45 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sun, 18 Jun 2000 21:06:45 +0200
Subject: [Python-Dev] talking about performance...
Message-ID: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>

consider this little program:

import time, sre

k = u"foo"
p = sre.compile(k)
s = "*"*500 + k + "*"*500

def f1():
    p.search(s)

def f2():
    s.find(k)

def bench(f):
    t0 = time.clock()
    for i in range(100000):
        f()
    print f, time.clock() - t0

bench(f1)
bench(f2)

which prints:

    <function f1 at 7a0680> 2.94704487169
    <function f2 at 7a06a0> 10.5247875425

(Windows 95, 233 MHz)

if I change the k variable to an 8-bit string, it
prints:

    <function f1 at 7a0740> 2.47613520173
    <function f2 at 7a0760> 2.5178698939

(for some reason, sre is still slighty faster...)

so in other words, something in unicode land isn't
as efficient as it should...

</F>




From akuchlin at cnri.reston.va.us  Sun Jun 18 21:20:20 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sun, 18 Jun 2000 15:20:20 -0400
Subject: [Python-Dev] talking about performance...
In-Reply-To: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jun 18, 2000 at 09:06:45PM +0200
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>
Message-ID: <20000618152020.B14713@newcnri.cnri.reston.va.us>

On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote:
>so in other words, something in unicode land isn't
>as efficient as it should...

The relevant bit of findstring() in unicodeobject.c:

    if (direction < 0) {
        for (; end >= start; end--)
            if (Py_UNICODE_MATCH(self, end, substring))
                return end;
    } else {
        for (; start <= end; start++)
            if (Py_UNICODE_MATCH(self, start, substring))
                return start;
    }

And...

#define Py_UNICODE_MATCH(string, offset, substring)\
    (!memcmp((string)->str + (offset), (substring)->str,\
             (substring)->length*sizeof(Py_UNICODE)))

Proposed patch:

Index: unicodeobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
retrieving revision 2.26
diff -u -r2.26 unicodeobject.c
--- unicodeobject.c	2000/06/14 09:18:32	2.26
+++ unicodeobject.c	2000/06/18 19:18:01
@@ -2168,11 +2168,13 @@
 
     if (direction < 0) {
         for (; end >= start; end--)
-            if (Py_UNICODE_MATCH(self, end, substring))
+            if ( *(self->str + end) == *(substring->str) &&
+		 Py_UNICODE_MATCH(self, end, substring))
                 return end;
     } else {
         for (; start <= end; start++)
-            if (Py_UNICODE_MATCH(self, start, substring))
+            if (*(self->str + start) == *(substring->str) &&
+		Py_UNICODE_MATCH(self, start, substring))
                 return start;
     }
 

--amk




From amk1 at erols.com  Sun Jun 18 21:32:37 2000
From: amk1 at erols.com (A.M. Kuchling)
Date: Sun, 18 Jun 2000 15:32:37 -0400
Subject: [Python-Dev] Turning on sre?
Message-ID: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com>

Before 1.6a3, should the sre module be turned on, replacing re?  That
way it'll start getting tested; better we find problems sooner rather
than later...

--amk




From guido at python.org  Sun Jun 18 22:47:22 2000
From: guido at python.org (Guido van Rossum)
Date: Sun, 18 Jun 2000 15:47:22 -0500
Subject: [Python-Dev] Turning on sre?
In-Reply-To: Your message of "Sun, 18 Jun 2000 15:32:37 -0400."
             <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> 
References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> 
Message-ID: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>

> Before 1.6a3, should the sre module be turned on, replacing re?  That
> way it'll start getting tested; better we find problems sooner rather
> than later...

That would be nice.  If I replace re.py with "from sre import *" and
run test_re.py, I grt in trouble in the sub() test:

$ ./python ../Lib/test/test_re.py
Running tests on re.search and re.match
Running tests on re.sub
Traceback (most recent call last):
  File "../Lib/test/test_re.py", line 41, in ?
    assert re.sub(r'\d+', bump_num, '08.2 -2 23x99y') == '9.3 -3 24x100y'
  File "./../Lib/sre.py", line 35, in sub
    return _compile(pattern).sub(repl, string, count)
  File "./../Lib/sre.py", line 84, in _sub
    return _subn(pattern, template, string, count)[0]
  File "./../Lib/sre.py", line 114, in _subn
    return string[:0].join(s), n
TypeError: sequence item 0 not a string
$

It appears that the value of s is a list containing alternating zeros
and strings: [0, '.', 0, ' -', 0, ' ', 0, 'x', 0, 'y'].

No time to look into this further, but it could be a bug in sre._subn().

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



From akuchlin at cnri.reston.va.us  Sun Jun 18 22:28:59 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Sun, 18 Jun 2000 16:28:59 -0400
Subject: [Python-Dev] Turning on sre?
In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>; from guido@python.org on Sun, Jun 18, 2000 at 03:47:22PM -0500
References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> <200006182047.PAA03008@cj20424-a.reston1.va.home.com>
Message-ID: <20000618162859.A15018@newcnri.cnri.reston.va.us>

On Sun, Jun 18, 2000 at 03:47:22PM -0500, Guido van Rossum wrote:
>No time to look into this further, but it could be a bug in sre._subn().

It's a typo; fixed.  However, test_re then runs into the fact that
_expand(), which should expand escapes in the replacement string,
isn't implemented yet.

--amk



From effbot at telia.com  Sun Jun 18 23:42:00 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sun, 18 Jun 2000 23:42:00 +0200
Subject: [Python-Dev] talking about performance...
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us>
Message-ID: <008301bfd96e$0bd98d20$f2a6b5d4@hagrid>

amk wrote:

> On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote:
> >so in other words, something in unicode land isn't
> >as efficient as it should...
> 
> The relevant bit of findstring() in unicodeobject.c:
> 
>     if (direction < 0) {
>         for (; end >= start; end--)
>             if (Py_UNICODE_MATCH(self, end, substring))
>                 return end;
>     } else {
>         for (; start <= end; start++)
>             if (Py_UNICODE_MATCH(self, start, substring))
>                 return start;
>     }
> 
> And...
> 
> #define Py_UNICODE_MATCH(string, offset, substring)\
>     (!memcmp((string)->str + (offset), (substring)->str,\
>              (substring)->length*sizeof(Py_UNICODE)))

heh.  it's my own code, of course...

> Proposed patch:
> 
> Index: unicodeobject.c

MATCH is used in a couple of places; it's probably a better idea
to change the macro (in Include/unicodeobject.h).  MAL?

</F>




From effbot at telia.com  Sun Jun 18 23:43:51 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sun, 18 Jun 2000 23:43:51 +0200
Subject: [Python-Dev] Turning on sre?
References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com>
Message-ID: <009501bfd96e$4d11b7e0$f2a6b5d4@hagrid>

amk wrote:


> Before 1.6a3, should the sre module be turned on, replacing re?  That
> way it'll start getting tested; better we find problems sooner rather
> than later...

in addition to the typo you noticed, there's a backtracking
(I think) problem that affects xmllib.py and tokenize.py...

I'm working on it.

</F>




From mal at lemburg.com  Sun Jun 18 23:48:32 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sun, 18 Jun 2000 23:48:32 +0200
Subject: [Python-Dev] talking about performance...
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid>
Message-ID: <394D43B0.8CC7070@lemburg.com>

Fredrik Lundh wrote:
> 
> amk wrote:
> 
> > On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote:
> > >so in other words, something in unicode land isn't
> > >as efficient as it should...
> >
> > The relevant bit of findstring() in unicodeobject.c:
> >
> >     if (direction < 0) {
> >         for (; end >= start; end--)
> >             if (Py_UNICODE_MATCH(self, end, substring))
> >                 return end;
> >     } else {
> >         for (; start <= end; start++)
> >             if (Py_UNICODE_MATCH(self, start, substring))
> >                 return start;
> >     }
> >
> > And...
> >
> > #define Py_UNICODE_MATCH(string, offset, substring)\
> >     (!memcmp((string)->str + (offset), (substring)->str,\
> >              (substring)->length*sizeof(Py_UNICODE)))
> 
> heh.  it's my own code, of course...
> 
> > Proposed patch:
> >
> > Index: unicodeobject.c
> 
> MATCH is used in a couple of places; it's probably a better idea
> to change the macro (in Include/unicodeobject.h).  MAL?

Right. I'll add Andrew's proposed patch to the macro def.

--
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Mon Jun 19 00:33:10 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 19 Jun 2000 00:33:10 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include unicodeobject.h,2.9,2.10
References: <200006182222.PAA19408@slayer.i.sourceforge.net>
Message-ID: <00c601bfd975$358d0aa0$f2a6b5d4@hagrid>

mal wrote:
>   
>   #define Py_UNICODE_MATCH(string, offset, substring)\
> !     ((*((string)->str + (offset)) == *((substring)->str)) &&\
> !      !memcmp((string)->str + (offset), (substring)->str,\
>                (substring)->length*sizeof(Py_UNICODE)))
>   

I completely forgot that this has different semantics if the
substring happens to be empty.

(substrings are null terminated, but "\0" isn't the same
thing as ""...)

don't have time to screen unicodeobject.c right now, but
maybe someone else can do it?  if not, maybe amk's patch
was a better idea after all...

</F>




From mwh21 at cam.ac.uk  Mon Jun 19 01:15:25 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 19 Jun 2000 00:15:25 +0100
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100
In-Reply-To: "A.M. Kuchling"'s message of "Sun, 18 Jun 2000 11:45:52 -0700"
References: <200006181845.LAA10182@slayer.i.sourceforge.net>
Message-ID: <m33dma7f8y.fsf@atrus.jesus.cam.ac.uk>

"A.M. Kuchling" <akuchling at users.sourceforge.net> writes:

> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv10064/Modules
> 
> Modified Files:
> 	_tkinter.c 
> Log Message:
> Patch from /F:
> this patch adds a fast _flatten function to the _tkinter
> module, and imports it from Tkinter.py (if available).
> 
> this speeds up canvas operations like create_line and
> create_polygon.  for example, a create_line with 5000
> vertices runs about 50 times faster with this patch in
> place.

Unfortunately this introduces another Way To Make Python Core:

[mwh21 at atrus build]$ ./python 
Python 1.6a2 (#4, Jun 18 2000, 23:57:36)  [GCC 2.95.1 19990816/Linux (release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> import Tkinter
>>> l = []
>>> l.append(l)
>>> Tkinter._flatten(l)
Segmentation fault (core dumped)

Here's a simple solution:

Index: _tkinter.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v
retrieving revision 1.100
diff -u -r1.100 _tkinter.c
--- _tkinter.c	2000/06/18 18:45:50	1.100
+++ _tkinter.c	2000/06/18 23:13:22
@@ -2001,13 +2001,16 @@
 }
 
 static int
-_flatten1(FlattenContext* context, PyObject* item)
+_flatten1(FlattenContext* context, PyObject* item, int depth)
 {
 	/* add tuple or list to argument tuple (recursively) */
 
 	int i, size;
 
-	if (PyList_Check(item)) {
+	if (depth > 1000) {
+		PyErr_SetString(PyExc_ValueError,"nesting too deep in _flatten");
+		return 0;
+	} else if (PyList_Check(item)) {
 		size = PyList_GET_SIZE(item);
 		/* preallocate (assume no nesting) */
 		if (context->size + size > context->maxsize && !_bump(context, size))
@@ -2016,7 +2019,7 @@
 		for (i = 0; i < size; i++) {
 			PyObject *o = PyList_GET_ITEM(item, i);
 			if (PyList_Check(o) || PyTuple_Check(o)) {
-				if (!_flatten1(context, o))
+				if (!_flatten1(context, o, depth + 1))
 					return 0;
 			} else if (o != Py_None) {
 				if (context->size + 1 > context->maxsize && !_bump(context, 1))
@@ -2033,7 +2036,7 @@
 		for (i = 0; i < size; i++) {
 			PyObject *o = PyTuple_GET_ITEM(item, i);
 			if (PyList_Check(o) || PyTuple_Check(o)) {
-				if (!_flatten1(context, o))
+				if (!_flatten1(context, o, depth + 1))
 					return 0;
 			} else if (o != Py_None) {
 				if (context->size + 1 > context->maxsize && !_bump(context, 1))
@@ -2068,7 +2071,7 @@
 	
 	context.size = 0;
 
-	if (!_flatten1(&context, item))
+	if (!_flatten1(&context, item,0))
 		return NULL;
 
 	if (_PyTuple_Resize(&context.tuple, context.size, 0))

"seems to work"; I've not tested it for performance, but I can't
believe this is too hard a hit.

Cheers,
M.




From mal at lemburg.com  Mon Jun 19 01:20:27 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 19 Jun 2000 01:20:27 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include
 unicodeobject.h,2.9,2.10
References: <200006182222.PAA19408@slayer.i.sourceforge.net> <00c601bfd975$358d0aa0$f2a6b5d4@hagrid>
Message-ID: <394D593B.DD4804E6@lemburg.com>

Fredrik Lundh wrote:
> 
> mal wrote:
> >
> >   #define Py_UNICODE_MATCH(string, offset, substring)\
> > !     ((*((string)->str + (offset)) == *((substring)->str)) &&\
> > !      !memcmp((string)->str + (offset), (substring)->str,\
> >                (substring)->length*sizeof(Py_UNICODE)))
> >
> 
> I completely forgot that this has different semantics if the
> substring happens to be empty.
> 
> (substrings are null terminated, but "\0" isn't the same
> thing as ""...)
> 
> don't have time to screen unicodeobject.c right now, but
> maybe someone else can do it?  if not, maybe amk's patch
> was a better idea after all...

I've checked the places where this macro is used: all
except the in .count() method showed the same behaviour
as for 8-bit strings.

The Unicode .count() method now also returns the same
value for empty substrings as the 8-bit strings.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Mon Jun 19 01:29:23 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 19 Jun 2000 01:29:23 +0200
Subject: [Python-Dev] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100
References: <200006181845.LAA10182@slayer.i.sourceforge.net> <m33dma7f8y.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <002701bfd97d$09d8b640$f2a6b5d4@hagrid>

michael wrote:
> > this patch adds a fast _flatten function to the _tkinter
> > module, and imports it from Tkinter.py (if available).
>
> Unfortunately this introduces another Way To Make Python Core:

well, there are lots of way to dump core through Tkinter/Tk, so I
convinced myself that it wasn't really worth the effort to prevent
it in _flatten...

either way, the patch looks okay to me.

</F>




From mwh21 at cam.ac.uk  Mon Jun 19 01:41:22 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 19 Jun 2000 00:41:22 +0100
Subject: [Python-Dev] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100
In-Reply-To: "Fredrik Lundh"'s message of "Mon, 19 Jun 2000 01:29:23 +0200"
References: <200006181845.LAA10182@slayer.i.sourceforge.net> <m33dma7f8y.fsf@atrus.jesus.cam.ac.uk> <002701bfd97d$09d8b640$f2a6b5d4@hagrid>
Message-ID: <m3zooi5zh9.fsf@atrus.jesus.cam.ac.uk>

"Fredrik Lundh" <effbot at telia.com> writes:

> michael wrote:
> > > this patch adds a fast _flatten function to the _tkinter
> > > module, and imports it from Tkinter.py (if available).
> >
> > Unfortunately this introduces another Way To Make Python Core:
> 
> well, there are lots of way to dump core through Tkinter/Tk, so I
> convinced myself that it wasn't really worth the effort to prevent
> it in _flatten...

Are there?  (I hardly know Tkinter).  Oh well.

I don't know of many "core" methods of doing it; the only one I can
think of is marshalling a recursive list, and as there seems to be a
loud party going on next door to me, I may write a patch for that this
evening...

Cheers,
M.




From mhammond at skippinet.com.au  Mon Jun 19 02:05:00 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 19 Jun 2000 10:05:00 +1000
Subject: [Python-Dev] Welcome back
In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEKGCNAA.mhammond@skippinet.com.au>

<To the tune from "Welcome back Kotter" :->

Welcome back, welcome back, welcome baaaaack - Welcome back, welcome back,
welcome baaaaack

Good to see you return.  Im sure you had a wonderful time!  From all
accounts, your wedding was beautiful, as Im sure your honeymoon was...

Now-were-just-waiting-for-the-baby-announcements-ly,

Mark.

> -----Original Message-----
> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Guido van Rossum
> Sent: Monday, 19 June 2000 6:47 AM
> To: akuchlin at mems-exchange.org
> Cc: python-dev at python.org
> Subject: Re: [Python-Dev] Turning on sre?




From tim_one at email.msn.com  Mon Jun 19 04:05:16 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 18 Jun 2000 22:05:16 -0400
Subject: [Python-Dev] Welcome back
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBCEKGCNAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEOKGEAA.tim_one@email.msn.com>

[Mark Hammond]
> ...
> Good to see you return.  Im sure you had a wonderful time!  From
> all accounts, your wedding was beautiful, as Im sure your
> honeymoon was...
>
> Now-were-just-waiting-for-the-baby-announcements-ly,

Guido & Kim just spent the last night of their honeymoon with Uncle Timmy
(who is now living in a Virginia motel room), and I can assure you no babies
were made by any pair of us tonight.  Unless Guido is quicker than he looks.

i'm-certainly-not-ly y'rs  - tim





From skip at mojam.com  Sat Jun 17 05:45:14 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 16 Jun 2000 22:45:14 -0500 (CDT)
Subject: [Python-Dev] list comprehensions
Message-ID: <14666.62538.988511.305499@beluga.mojam.com>

Did list comprehensions ever make it into 1.6?  I thought I submitted a
1.6-compatible update of Greg Ewing's mods awhile ago.  Should I resubmit?
To the patches list?

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395



From guido at python.org  Mon Jun 19 17:01:24 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 19 Jun 2000 10:01:24 -0500
Subject: [Python-Dev] list comprehensions
In-Reply-To: Your message of "Fri, 16 Jun 2000 22:45:14 EST."
             <14666.62538.988511.305499@beluga.mojam.com> 
References: <14666.62538.988511.305499@beluga.mojam.com> 
Message-ID: <200006191501.KAA02197@cj20424-a.reston1.va.home.com>

> Did list comprehensions ever make it into 1.6?

No (as far as I'm aware :-).

> I thought I submitted a
> 1.6-compatible update of Greg Ewing's mods awhile ago.  Should I resubmit?
> To the patches list?

It's rather late in the release cycle -- I'm trying to get alpha 3
released, and i'm still 1400 messages behind on my email.

But submitting a patch might be a good idea anyway so we won't forget
about it (and maybe it's of such baffling simplicity that it'll charm
its way past the guards :-).

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



From ping at lfw.org  Mon Jun 19 20:59:15 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Mon, 19 Jun 2000 13:59:15 -0500 (CDT)
Subject: [Python-Dev] list comprehensions
In-Reply-To: <200006191501.KAA02197@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10006191358330.10836-100000@server1.lfw.org>

On Mon, 19 Jun 2000, Guido van Rossum wrote:
> > Did list comprehensions ever make it into 1.6?
> 
> No (as far as I'm aware :-).
[...] 
> But submitting a patch might be a good idea anyway so we won't forget
> about it (and maybe it's of such baffling simplicity that it'll charm
> its way past the guards :-).

I just have to say i thought list comprehensions were
really cool.


-- ?!ng




From skip at mojam.com  Mon Jun 19 22:17:59 2000
From: skip at mojam.com (Skip Montanaro)
Date: Mon, 19 Jun 2000 15:17:59 -0500
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
Message-ID: <200006192017.PAA00690@beluga.mojam.com>

Python's sys module defines an exitfunc variable that is settable from
Python scripts.  At exit, that function will be called with no arguments.
While this is a good start at supporting standard cleanup activities, it
defines no protocol to be used by modules that wish to use sys.exitfunc,
which leads to one of two extremes: 1, two modules wishing to define cleanup
functions both clobber sys.exitfunc or 2, to avoid collisions they don't use
the functionality provided.

At an application level this is okay.  Within a single application you can
define an application-specific protocol to handle the situation.
Unfortunately, this still leaves Python's core modules without a good way to
register exit functions.

I ran into this problem today.  I would really like the rlcompleter module
to read and write readline history files from Python.  Reading a history
file at module startup is no problem, but deciding where to write the
history file is a problem.  The logical place is at the time sys.exitfunc is
executed.

For my own applications I long ago wrote a very simple module (called
exit.py, appended to this message) that defines two functions:

    * exit.register_exitfunc takes a function object and a set of optional
      arguments and appends them to a list.

    * exit._run_exitfuncs is bound to sys.exitfunc and executes the
      registered exit functions in the order they appear in the list.

I propose exit.py as the starting point for a well-defined protocol for
modules to register exit functions without collisions.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395


"""
allow programmer to define multiple exit functions to be executed upon normal
program termination.
"""

_exithandlers = []
def _run_exitfuncs():
    while _exithandlers:
        func, targs, kargs = _exithandlers[0]
        apply(func, targs, kargs)
        _exithandlers.remove(_exithandlers[0])

def register_exitfunc(func, *targs, **kargs):
    """register a function to be executed upon normal program termination

    arguments are a function object, and zero or more arguments to pass to
    it.
    """
    _exithandlers.append((func, targs, kargs))

import sys
try:
    x = sys.exitfunc
except AttributeError:
    sys.exitfunc = _run_exitfuncs
del sys

if __name__ == "__main__":
    def x1():
        print "running x1"
    def x2(n):
        print "running x2(%s)" % `n`
    def x3(n, kwd=None):
        print "running x3(%s, kwd=%s)" % (`n`, `kwd`)

    register_exitfunc(x1)
    register_exitfunc(x2, 12)
    register_exitfunc(x3, 5, "bar")
    register_exitfunc(x3, "no kwd args")




From DavidA at ActiveState.com  Mon Jun 19 22:27:48 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 19 Jun 2000 13:27:48 -0700
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <200006192017.PAA00690@beluga.mojam.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJCEPHCIAA.DavidA@ActiveState.com>

+1 on the idea.  I wonder if it makes sense to publish a mechanism to allow
de-registering of callbacks, or if that's featuritis.

Also, I'd change:

> try:
>     x = sys.exitfunc
> except AttributeError:
>     sys.exitfunc = _run_exitfuncs
> del sys

to:

try:
	register_exitfuncs(sys.exitfunc)
finally:
	sys.exitfunc = _run_exitfuncs

Or some such.

--david

> -----Original Message-----
> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Skip Montanaro
> Sent: Monday, June 19, 2000 1:18 PM
> To: python-dev at python.org
> Subject: [Python-Dev] Proposal: standard way of defining and executing
> "atexit" functions...
> Importance: Low
>
>
>
> Python's sys module defines an exitfunc variable that is settable from
> Python scripts.  At exit, that function will be called with no arguments.
> While this is a good start at supporting standard cleanup activities, it
> defines no protocol to be used by modules that wish to use sys.exitfunc,
> which leads to one of two extremes: 1, two modules wishing to
> define cleanup
> functions both clobber sys.exitfunc or 2, to avoid collisions
> they don't use
> the functionality provided.
>
> At an application level this is okay.  Within a single application you can
> define an application-specific protocol to handle the situation.
> Unfortunately, this still leaves Python's core modules without a
> good way to
> register exit functions.
>
> I ran into this problem today.  I would really like the rlcompleter module
> to read and write readline history files from Python.  Reading a history
> file at module startup is no problem, but deciding where to write the
> history file is a problem.  The logical place is at the time
> sys.exitfunc is
> executed.
>
> For my own applications I long ago wrote a very simple module (called
> exit.py, appended to this message) that defines two functions:
>
>     * exit.register_exitfunc takes a function object and a set of optional
>       arguments and appends them to a list.
>
>     * exit._run_exitfuncs is bound to sys.exitfunc and executes the
>       registered exit functions in the order they appear in the list.
>
> I propose exit.py as the starting point for a well-defined protocol for
> modules to register exit functions without collisions.
>
> --
> Skip Montanaro, skip at mojam.com, http://www.mojam.com/,
> http://www.musi-cal.com/
> On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always
> lived
> his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
>     https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395
>
>
> """
> allow programmer to define multiple exit functions to be executed upon
> normal
> program termination.
> """
>
> _exithandlers = []
> def _run_exitfuncs():
>     while _exithandlers:
>         func, targs, kargs = _exithandlers[0]
>         apply(func, targs, kargs)
>         _exithandlers.remove(_exithandlers[0])
>
> def register_exitfunc(func, *targs, **kargs):
>     """register a function to be executed upon normal program termination
>
>     arguments are a function object, and zero or more arguments to pass to
>     it.
>     """
>     _exithandlers.append((func, targs, kargs))
>
> import sys
> try:
>     x = sys.exitfunc
> except AttributeError:
>     sys.exitfunc = _run_exitfuncs
> del sys
>
> if __name__ == "__main__":
>     def x1():
>         print "running x1"
>     def x2(n):
>         print "running x2(%s)" % `n`
>     def x3(n, kwd=None):
>         print "running x3(%s, kwd=%s)" % (`n`, `kwd`)
>
>     register_exitfunc(x1)
>     register_exitfunc(x2, 12)
>     register_exitfunc(x3, 5, "bar")
>     register_exitfunc(x3, "no kwd args")
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
>




From skip at mojam.com  Mon Jun 19 22:55:09 2000
From: skip at mojam.com (Skip Montanaro)
Date: Mon, 19 Jun 2000 15:55:09 -0500 (CDT)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJCEPHCIAA.DavidA@ActiveState.com>
References: <200006192017.PAA00690@beluga.mojam.com>
	<PLEJJNOHDIGGLDPOGPJJCEPHCIAA.DavidA@ActiveState.com>
Message-ID: <14670.34989.887973.797947@beluga.mojam.com>

    David> +1 on the idea.  I wonder if it makes sense to publish a
    David> mechanism to allow de-registering of callbacks, or if that's
    David> featuritis.

While writing my message I thought, "I'll bet the first question asked will
be about unregistering exit functions."  I've been using the module I
appended to my message unchanged for a couple years and never needed such
functionality.  I'm sure there are applications that could use it, but I
think they'd be a small minority.  Since the only defined interface is a
single registration function (_run_exitfuncs is only used internally), I
think you'd be free to add some unregister function protocol at a later
time if it was deemed necessary.

    David> Also, I'd change:

    >> try:
    >>     x = sys.exitfunc
    >> except AttributeError:
    >>     sys.exitfunc = _run_exitfuncs
    >> del sys

    David> to:

    David> try:
    David> 	register_exitfuncs(sys.exitfunc)
    David> finally:
    David> 	sys.exitfunc = _run_exitfuncs

    David> Or some such.

register_exitfunc is only meant to be called by clients of the module, not
used internally.  You're assuming that if something else was already bound
to sys.exitfunc that it's not _run_exitfuncs.  With your try/finally code
try the following (mentally is fine):

    import exit
    def foo():
        print 1
    exit.register_exitfunc(foo)
    reload(exit)

I think you'll see that exit._run_exitfuncs is on its own list of exit
functions.  That could be bad.

The setup code:

    try:
        x = sys.exitfunc
    except AttributeError:
        sys.exitfunc = _run_exitfuncs

is meant to avoid doing anything if any other module beat us to
sys.exitfunc.  Perhaps it should just be

    sys.exitfunc = _run_exitfuncs

If someone fails to use the defined protocol, screw 'em... ;-)

Skip



From DavidA at ActiveState.com  Mon Jun 19 23:12:03 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 19 Jun 2000 14:12:03 -0700
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <14670.34989.887973.797947@beluga.mojam.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com>

> If someone fails to use the defined protocol, screw 'em... ;-)

That's unreasonable given that existing tools might include a library which
might be upgraded to use the new mechanism while the old code used its own
mechanism happily.  For example, I've used my own protocols in the past
which went something like...

def register_exitfunc(func):
    old_exitfunc = getattr(sys, 'exitfunc', None)
    def wrapper(old_exitfunc=old_exitfunc, new_func=func):
      if old_exitfunc is not None: old_exitfunc()
      new_func()
    sys.exitfunc = wrapper

or some such, creating a call chain instead of a sequence of calls, and it's
a 'fine' protocol in that it worked fine in the absence of a standard.  No
need to break code if we can avoid it.

The point of my pseudo-patch, if it wasn't clear, was that if a function is
already in sys.exitfunc, then it should still be called on exit after the
new exit module is imported.  You're right that my patch didn't properly
check that _run_exitfuncs might be that function.

--david




From skip at mojam.com  Mon Jun 19 23:41:54 2000
From: skip at mojam.com (Skip Montanaro)
Date: Mon, 19 Jun 2000 16:41:54 -0500 (CDT)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com>
References: <14670.34989.887973.797947@beluga.mojam.com>
	<PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com>
Message-ID: <14670.37794.998270.762852@beluga.mojam.com>

    >> If someone fails to use the defined protocol, screw 'em... ;-)

    David> That's unreasonable given that existing tools might include a
    David> library which might be upgraded to use the new mechanism while
    David> the old code used its own mechanism happily.  

Point taken.  I'll look at extending the module to accommodate other
sys.exitfunc callers.

Skip



From Vladimir.Marangozov at inrialpes.fr  Tue Jun 20 03:11:24 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Tue, 20 Jun 2000 03:11:24 +0200 (CEST)
Subject: [Python-Dev] mmapmodule.c,2.10,2.11
In-Reply-To: <20000618002224.A12729@newcnri.cnri.reston.va.us> from "Andrew Kuchling" at Jun 18, 2000 12:22:24 AM
Message-ID: <200006200111.DAA01591@python.inrialpes.fr>

Andrew Kuchling wrote:
> 
> On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote:
> >On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method.
> >It works okay without the MS_INVALIDATE flag though, so I'd suggest
> >removing it from msync in the flush and dealloc methods.
> 
> Ooh, you're right.  The Linux msync man page says "MS_ASYNC specifies
> that an update be scheduled, but the call returns immediately.
> MS_SYNC asks for an update and waits for it to complete.
> MS_INVALIDATE asks to invalidate other mappings of the same file (so
> that they can be updated with the fresh values just written)."  So
> MS_INVALIDATE seems far too drastic.

Yes.

> 
> >Also, it would probably be a good idea to allow optional flags for
> >flush, as it's done in new_mmap_object, the default being only MS_SYNC.
> 
> The problem is: does Windows provide equivalent functionality?  (Is
> there documentation available online for CreateFileMapping that I
> could look at?)

Well, I had a look at my Windows book. Although the mmap functionnality is
equivalent, overall, there are no equivalent flags in FlushViewOfFile, etc.
Maybe this is too subtle to be of any real use after all, so I retract the
idea. MS_SYNC alone is fine.

Another point: I'm not thrilled about the idea of raising a SystemError
for m.resize if native mremap is missing (which is also AIX's case).
unmap/mmap again with the new size is the emulation solution everybody
would do in Python when m.resize is not implemented. So I'd suggest
implementing it in C (which is what the Windows version does, btw).
Furthermore, having an unimplemented method makes little sense to me.
For implementing this emulation on Unix, however, we would need to
remember in additional slots the original mmap flags & rights, so that
the second (or any subsequent) mmap call uses the same flags & rights
as the first one.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From pf at artcom-gmbh.de  Tue Jun 20 09:32:33 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 20 Jun 2000 09:32:33 +0200 (MEST)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJEEPKCIAA.DavidA@ActiveState.com> from David Ascher at "Jun 19, 2000  2:12: 3 pm"
Message-ID: <m134IWP-000DieC@artcom0.artcom-gmbh.de>

Hi Skip, Hi David,

David Ascher:
> > If someone fails to use the defined protocol, screw 'em... ;-)
> 
> That's unreasonable given that existing tools might include a library which
> might be upgraded to use the new mechanism while the old code used its own
> mechanism happily.  For example, I've used my own protocols in the past
> which went something like...
> 
> def register_exitfunc(func):
>     old_exitfunc = getattr(sys, 'exitfunc', None)
>     def wrapper(old_exitfunc=old_exitfunc, new_func=func):
>       if old_exitfunc is not None: old_exitfunc()
>       new_func()
>     sys.exitfunc = wrapper
> 
> or some such, creating a call chain instead of a sequence of calls, and it's
> a 'fine' protocol in that it worked fine in the absence of a standard.  No
> need to break code if we can avoid it.

Davids wrapper function implements a FIFO strategy for termination.  
I think this is not desired.  Normally you want LIFO, because higher level 
services in an application are initialized later during startup.  Those 
services usually depend on lower level services, which should still be 
available at termination time of the higher level services.  

I try to explain this by an example:
Module A provides some kind of network connections. 
Module B uses (imports) Module A to access a remote resource administration 
server to provide access to remote devices or resources.
During program termination Module B likes to release all resources reserved 
for (owned by) the program.  It uses Module A to submit a cleanup request to
the server.  Module A however wants to close all open network connections.

The following function (termination protocol) solves this by exchanging the 
sequence of calls within the wrapper:

def register_exit_func(func, *args, **kw):
    import sys
    previous_func = sys.exit_func
    def wrapped_func(previous_func=previous_func, func=func, args=args, kw=kw):
        try:
            apply(func, args, kw)
        finally:
            if previous_func is not None: 
                previous_func()
    sys.exit_func = wrapped_func

In the past I've placed such a function into a common base module of my apps.
But I think, Skip is right, that a termination protocol should be part of
the standard library.  

But a separate module 'exit.py' seems to be overkill for single basic 
function.  May be it should be put into the module 'os'?  Handling of 
program termination is something, which considered as a generic 
operating system service.  From the users point of view 'sys' would
be a better place, but this would require rewriting in C: ugly.

I also agree with Skip, that the possibility to unregister an exit_func is 
normally not needed.  The same effect can be achieved by doing nothing in 
the exit_func.

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)



From mhammond at skippinet.com.au  Tue Jun 20 10:02:14 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 20 Jun 2000 18:02:14 +1000
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <m134IWP-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <ECEPKNMJLHAPFFJHDOJBOEMCCNAA.mhammond@skippinet.com.au>

Peter:

> Davids wrapper function implements a FIFO strategy for termination.  
> I think this is not desired.  Normally you want LIFO,

Agreed.  LIFO is definately preferred IMO.

Mark.




From pf at artcom-gmbh.de  Tue Jun 20 10:08:16 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 20 Jun 2000 10:08:16 +0200 (MEST)
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: From "(env:" "pf)" at "Jun 20, 2000  9:32:33 am"
Message-ID: <m134J4y-000DieC@artcom0.artcom-gmbh.de>

Hi, 

I wrote:
> def register_exit_func(func, *args, **kw):
>     import sys
>     previous_func = sys.exit_func

this should have been 'sys.exitfunc'.
I've also misssed to note, that I placed the following line into 
the module init code: 

import sys; def _nop(): pass; sys.exitfunc = _nop
Otherwise I had to use getattr(sys, 'exitfunc', None) as David suggested.

Next time I should actually cut'n'paste working code instead typing from
blurred memory. :-(

Another point I forgot, was that you usually want to install signal
handlers on unices, that handle the signal.SIGTERM, signal.SIGHUP and
signal.SIGINT signals and invoke exit function to do some final
cleanup.

Regards, Peter



From mal at lemburg.com  Tue Jun 20 11:01:50 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 20 Jun 2000 11:01:50 +0200
Subject: [Python-Dev] Proposal: standard way of defining and executing 
 "atexit" functions...
References: <m134J4y-000DieC@artcom0.artcom-gmbh.de>
Message-ID: <394F32FE.B926C19A@lemburg.com>

Attached you find a similar module which I have used for years.
It has all the requested features, plus allows deregistration
and supports a more OO-like interface.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ExitFunctions.py
Type: text/python
Size: 2444 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000620/7fbaac90/attachment-0001.bin>

From fredrik at pythonware.com  Tue Jun 20 12:15:01 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 12:15:01 +0200
Subject: [Python-Dev] talking about performance... [case closed]
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com>
Message-ID: <003101bfdaa0$693b4de0$0900a8c0@SPIFF>

mal wrote:
> > > Index: unicodeobject.c
> > 
> > MATCH is used in a couple of places; it's probably a better idea
> > to change the macro (in Include/unicodeobject.h).  MAL?
> 
> Right. I'll add Andrew's proposed patch to the macro def.

for the record, my little benchmark now runs about five
times faster than before -- which means that 16-bit find
is now ~30% faster than 8-bit find (barry? ;-)

cheers /F

footnote: for the exact figures, see:
http://hem.passagen.se/eff/2000_06_01_bot-archive.htm#361472




From mhammond at skippinet.com.au  Tue Jun 20 13:42:53 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 20 Jun 2000 21:42:53 +1000
Subject: [Python-Dev] Fw: Access violation when no memory
Message-ID: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au>


From gward at mems-exchange.org  Tue Jun 20 14:33:44 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Tue, 20 Jun 2000 08:33:44 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com>
Message-ID: <20000620083344.A3499@ludwig.cnri.reston.va.us>

On 09 June 2000, Eric S. Raymond said:
> I think it's time to consider including PIL in the core Python 1.6 release.
> I've been following the work being done over there, and I believe the 
> code has reached a sufficient level of maturity to justify this.

-1 from me.  What's the point of the Distutils if we just throw
everything "useful" into the standard distribution?

        Greg



From gward at mems-exchange.org  Tue Jun 20 14:40:41 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Tue, 20 Jun 2000 08:40:41 -0400
Subject: [Python-Dev] Towards 1.6 Final
In-Reply-To: <200006130237.EAA10373@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jun 13, 2000 at 04:37:23AM +0200
References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr>
Message-ID: <20000620084040.B3499@ludwig.cnri.reston.va.us>

On 13 June 2000, Vladimir Marangozov said:
> > - Fix ./ld_so_aix installation problem on AIX (anybody know more about
> >   this???)
> 
> Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem
> for building C extensions with distutils than an installation problem per se.
> Some time ago, I saw a workaround checked in by Greg. If this is still judged
> as a problem, I'd like to hear about it. This is a minor thing. I have yet
> to install & run the distutil package on AIX, though, and see what happens.

As I recall, my workaround didn't work.  (Would that make it a
failaround?)

Vladimir, *please* give the Distutils a whirl on AIX -- I suspect some
sort of hack is needed to get extension-building working there.  I don't
much care if the Makefile installed by Python is "fixed" to have an
absolute path to "ld_so_aix" instead of "./ld_so_aix" -- that should
make extension-building with the Distutils OK, but it will break the
relocatability of a Python installation on AIX.  Also, it won't fix
Distutils with Python 1.5.2.

Thanks --

       Greg



From paul at prescod.net  Tue Jun 20 15:30:13 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 20 Jun 2000 15:30:13 +0200
Subject: [Python-Dev] RFC: Including PIL in 1.6
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us>
Message-ID: <394F71E5.C7CEC32D@prescod.net>

Greg Ward wrote:
> 
> ...
> -1 from me.  What's the point of the Distutils if we just throw
> everything "useful" into the standard distribution?

One way to look at it is vertical versus horizontal. I think that that's
how the Java world works (unofficially). If Java is one extreme and ANSI
C is on the other, I prefer to err on the Java side (which we probably
do).

The big issue is configuration management. if we put PIL (or anything
else) in the standard distribution we are promising to keep that code in
sync with everything else. This is a big boon to users and a big
headache for maintainers. The question is when the boon is enough to
justify the headache.

It's one thing to tell a user: "Just type distutils and everything will
magically become available." But they usually come back: "I'm getting an
error message about append not taking that many arguments..." or
something like that. Libraries breaking libraries is actually the most
common case.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Music is the stuff between the notes." - Claude Debussy



From bwarsaw at python.org  Tue Jun 20 15:43:32 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Tue, 20 Jun 2000 09:43:32 -0400 (EDT)
Subject: [Python-Dev] talking about performance... [case closed]
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>
	<20000618152020.B14713@newcnri.cnri.reston.va.us>
	<008301bfd96e$0bd98d20$f2a6b5d4@hagrid>
	<394D43B0.8CC7070@lemburg.com>
	<003101bfdaa0$693b4de0$0900a8c0@SPIFF>
Message-ID: <14671.29956.819067.208771@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <fredrik at pythonware.com> writes:

    FL> for the record, my little benchmark now runs about five
    FL> times faster than before -- which means that 16-bit find
    FL> is now ~30% faster than 8-bit find (barry? ;-)

Awesome!



From akuchlin at cnri.reston.va.us  Tue Jun 20 15:53:09 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 09:53:09 -0400
Subject: [Python-Dev] talking about performance... [case closed]
In-Reply-To: <003101bfdaa0$693b4de0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jun 20, 2000 at 12:15:01PM +0200
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF>
Message-ID: <20000620095309.A3039@amarok.cnri.reston.va.us>

On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote:
>for the record, my little benchmark now runs about five
>times faster than before -- which means that 16-bit find
>is now ~30% faster than 8-bit find (barry? ;-)

Speculation: the code in stringobject.c looks like this:
                for (; i <= last; ++i)
                        if (s[i] == sub[0] &&
                            (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0))
                                return (long)i;
 
It checks the first character, and then does the memcmp() skipping the
first character, or succeeds if the substring length is 1; the Unicode
find is simpler, just doing the full memcmp.  I wonder if the extra n
== 1 and i+1, n-1 arithmetic costs more than it saves?  This is
probably delicately tied to the speed of your memcmp().  Anyone want
to try the simpler version and report on whether it makes a difference?

--amk



From effbot at telia.com  Tue Jun 20 17:26:42 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 17:26:42 +0200
Subject: [Python-Dev] faster 8-bit find/split (was: talking about performance...)
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> <20000620095309.A3039@amarok.cnri.reston.va.us>
Message-ID: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid>

[as discussed on python-dev]

amk wrote:
> On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote:
> >for the record, my little benchmark now runs about five
> >times faster than before -- which means that 16-bit find
> >is now ~30% faster than 8-bit find (barry? ;-)
> 
> Speculation: the code in stringobject.c looks like this:
>                 for (; i <= last; ++i)
>                         if (s[i] == sub[0] &&
>                             (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0))
>                                 return (long)i;
>  
> It checks the first character, and then does the memcmp() skipping the
> first character, or succeeds if the substring length is 1; the Unicode
> find is simpler, just doing the full memcmp.  I wonder if the extra n
> == 1 and i+1, n-1 arithmetic costs more than it saves?

at least on my box (win95, msvc 5)...  after simplifying the code,
string.find is now faster than sre.search.  it's still 15% slower than
the 16-bit string find, but I don't have time to dig into that right
now...

patches are included.  

</F>

I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under copyright,
patent or other rights or interests ("claims").  To the extent that I
have any such claims, I hereby grant to CNRI a nonexclusive,
irrevocable, royalty-free, worldwide license to reproduce, distribute,
perform and/or display publicly, prepare derivative versions, and
otherwise use this contribution as part of the Python software and its
related documentation, or any derivative versions thereof, at no cost to
CNRI or its licensed users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide whether or
not to incorporate this contribution in the Python software and its
related documentation.  I further grant CNRI permission to use my name
and other identifying information provided to CNRI by me for use in
connection with the Python software and its related documentation.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: string-patch.txt
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000620/b0496902/attachment-0001.txt>

From fdrake at beopen.com  Tue Jun 20 17:47:35 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 20 Jun 2000 11:47:35 -0400 (EDT)
Subject: [Python-Dev] faster 8-bit find/split (was: talking about performance...)
In-Reply-To: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid>
References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>
	<20000618152020.B14713@newcnri.cnri.reston.va.us>
	<008301bfd96e$0bd98d20$f2a6b5d4@hagrid>
	<394D43B0.8CC7070@lemburg.com>
	<003101bfdaa0$693b4de0$0900a8c0@SPIFF>
	<20000620095309.A3039@amarok.cnri.reston.va.us>
	<007701bfdacc$0d2e87c0$f2a6b5d4@hagrid>
Message-ID: <14671.37399.809253.945519@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > patches are included.  

  Now checked in, thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Tue Jun 20 18:47:47 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 20 Jun 2000 12:47:47 -0400
Subject: [Python-Dev] talking about performance... [case closed]
In-Reply-To: <20000620095309.A3039@amarok.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCGECFGFAA.tim_one@email.msn.com>

[Fredrik Lundh]
> for the record, my little benchmark now runs about five
> times faster than before -- which means that 16-bit find
> is now ~30% faster than 8-bit find (barry? ;-)

[Andrew M. Kuchling]/
> Speculation: the code in stringobject.c looks like this:
>                 for (; i <= last; ++i)
>                         if (s[i] == sub[0] &&
>                             (n == 1 || memcmp(&s[i+1], &sub[1],
> n-1) == 0))
>                                 return (long)i;
> ...
> the Unicode find is simpler, just doing the full memcmp.  I wonder
> if the extra n == 1 and i+1, n-1 arithmetic costs more than it
> saves?

So the intent of the code is to avoid the expense of calling memcmp if a
full n-character memcmp can't possibly find equality at i (due to mismatch
of first characters), and the assumption is that first characters mismatch
frequently.  Both seem like good calls to me!

> This is probably delicately tied to the speed of your memcmp().

Also on whether your memcmp() is an actual external function or a full or
partial inline expansion (e.g., the strcmp at KSR expanded into code much
like the "by-hand" stuff above, skipping "the real" strcmp if the first
characters weren't equal).

> Anyone want to try the simpler version and report on whether
> it makes a difference?

No <wink>.  But if someone does, a good compromise might be to split this
into two loops, one for the n==1 case and another for n>1.  The "+1/-1" are
dubious in any case (i.e., "memcmp(s+i, sub, n) == 0" saves the fiddly
arithmetic at the also-minor cost of making memcmp do one redundant
character compare).





From dan at cgsoftware.com  Tue Jun 20 18:55:11 2000
From: dan at cgsoftware.com (Daniel Berlin)
Date: Tue, 20 Jun 2000 09:55:11 -0700 (PDT)
Subject: [Python-Dev] talking about performance... [case closed]
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGECFGFAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10006200953020.31239-100000@propylaea.anduin.com>

> So the intent of the code is to avoid the expense of calling memcmp if a
> full n-character memcmp can't possibly find equality at i (due to mismatch
> of first characters), and the assumption is that first characters mismatch
> frequently.  Both seem like good calls to me!

However, smart compilers (gcc 2.95+ fer instance) will produce an inline
memcmp call that is faster, and has no overhead (IE it's not making a
library call).
Thus, the first character mismatch test is useless.
We had the same thing in strcmp macros in GDB, where we tested the first
character, then strcmp'd.
It was faster to just strcmp, even when they *did* mismatch.

--Dan




From esr at thyrsus.com  Tue Jun 20 19:21:50 2000
From: esr at thyrsus.com (esr at thyrsus.com)
Date: Tue, 20 Jun 2000 13:21:50 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <Pine.LNX.4.10.10006191358330.10836-100000@server1.lfw.org>
References: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> <Pine.LNX.4.10.10006191358330.10836-100000@server1.lfw.org>
Message-ID: <20000620132150.O8678@thyrsus.com>

Ka-Ping Yee <ping at lfw.org>:
> On Mon, 19 Jun 2000, Guido van Rossum wrote:
> > But submitting a patch might be a good idea anyway so we won't forget
> > about it (and maybe it's of such baffling simplicity that it'll charm
> > its way past the guards :-).
> 
> I just have to say i thought list comprehensions were
> really cool.

Ditto.  I would like to see this in 1.6.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The men and women who founded our country knew, by experience, that there
are times when the free person's answer to oppressive government has to be
delivered with a bullet.  Thus, the right to bear arms is not just *a*
freedom; it's the mother of all freedoms.  Don't let them disarm you!



From esr at thyrsus.com  Tue Jun 20 20:04:19 2000
From: esr at thyrsus.com (esr at thyrsus.com)
Date: Tue, 20 Jun 2000 14:04:19 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620083344.A3499@ludwig.cnri.reston.va.us>
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us>
Message-ID: <20000620140419.C10038@thyrsus.com>

Greg Ward <gward at mems-exchange.org>:
> -1 from me.  What's the point of the Distutils if we just throw
> everything "useful" into the standard distribution?

Watch that argument -- it could turn and bite you.  What's the justification
for including, e.g. POP client classes in the standard distribution?

One of Python's most important strengths is the "batteries *are*
included" richness of the standard environment.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The two pillars of `political correctness' are, 
  a) willful ignorance, and
  b) a steadfast refusal to face the truth
	-- George MacDonald Fraser



From effbot at telia.com  Tue Jun 20 19:59:35 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 19:59:35 +0200
Subject: [Python-Dev] RFC: Including PIL in 1.6
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us>
Message-ID: <001101bfdae1$5094f7a0$f2a6b5d4@hagrid>

greg wrote:

> On 09 June 2000, Eric S. Raymond said:
> > I think it's time to consider including PIL in the core Python 1.6 release.
> > I've been following the work being done over there, and I believe the 
> > code has reached a sufficient level of maturity to justify this.
> 
> -1 from me.  What's the point of the Distutils if we just throw
> everything "useful" into the standard distribution?

strange argument.  what's the point of including *anything*
if we have distutils?

...

fwiw, I'm -0 on this one;

it might better to work on a "Python Standards Base" which
specifies a bunch of extensions that people are encouraged
to include in their distributions.

let's see: zlib, expat, (portions of) numpy, pil, piddle, ...

</F>




From effbot at telia.com  Tue Jun 20 20:02:24 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 20:02:24 +0200
Subject: [Python-Dev] talking about performance...
References: <LNBBLJKPBEHFEDALKOLCGECFGFAA.tim_one@email.msn.com>
Message-ID: <002001bfdae1$b28942e0$f2a6b5d4@hagrid>

tim wrote:

> No <wink>.  But if someone does, a good compromise might be to split this
> into two loops, one for the n==1 case and another for n>1.

how about this one:

    if (dir > 0) {
        char *p, *e;
        if (n == 0 && i <= last)
            return (long)i;
        e = s + last - n + 1;
        for (;;) {
            p = memchr(s, sub[0], e - s);
            if (p == NULL)
                break;
            if (n == 1 || memcmp(p, sub, n) == 0)
                return (long) (p - s);
            s = p + 1;
        }
    }

new record time: 1.6 seconds (down from 2.2)

</F>




From akuchlin at cnri.reston.va.us  Tue Jun 20 20:04:06 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 14:04:06 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com>
Message-ID: <20000620140406.B3142@amarok.cnri.reston.va.us>

>Watch that argument -- it could turn and bite you.  What's the justification
>for including, e.g. POP client classes in the standard distribution?
>One of Python's most important strengths is the "batteries *are*
>included" richness of the standard environment.

Once there are enough pieces to make finding and getting the software
near-automatic, I actually wouldn't mind splitting them out and
shipping a much smaller core distribution, perhaps with a script that
downloads the latest versions of what's in the standard library.
Debian did that for a while, with python-net, python-base,
python-text, &c.

I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the
binary, and install two packages of Elisp code (EFS and xemacs-base).
Then you run xemacs, do Options > Manage Packages > List and Install,
and you get a nice list containing GNUS, W3, programming language
modes, etc.  Pick the ones you want, it adds the ones needed by the
ones you selected, and it fetches and installs them.  Easy!  Now
imagine doing the same thing with Python modules.  Of course, we'd
have to design that feature first...

(ESR & Paul Prescod vs. AMK & GPW: the First Pythonic War! :) )

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
This is, after all, a book about reading, and the kind of reader I am
addressing does not care primarily about being in fashion.
  -- Robertson Davies, _A Voice from the Attic_




From DavidA at ActiveState.com  Tue Jun 20 20:16:40 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 20 Jun 2000 11:16:40 -0700
Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions...
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEMCCNAA.mhammond@skippinet.com.au>
Message-ID: <PLEJJNOHDIGGLDPOGPJJCECJCJAA.DavidA@ActiveState.com>

> Peter:
>
> > Davids wrapper function implements a FIFO strategy for termination.
> > I think this is not desired.  Normally you want LIFO,
>
> Agreed.  LIFO is definately preferred IMO.

Agreed.  My wrapper was also from memory, and that was not at all the main
point of my post =).

--da




From akuchlin at cnri.reston.va.us  Tue Jun 20 20:17:47 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 14:17:47 -0400
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
In-Reply-To: <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 20, 2000 at 08:18:03PM +0200
References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid>
Message-ID: <20000620141747.D3142@amarok.cnri.reston.va.us>

On Tue, Jun 20, 2000 at 08:18:03PM +0200, Fredrik Lundh quoted FLD:
>>   What is "sip"?  Is it defined by an RFC (which?), or Internet Draft
>> (which?  what's the expected activity?).

Is there a canonical list of all the defined URL types anywhere?  I
notice that 'ldap' isn't there, and maybe there are more missing.
(Some of the ones in there are marginal: who cares about Prospero?)

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
That's so obvious that someone has already got a patent on it.
  -- Guido van Rossum, 12 Jan 1999

 



From DavidA at ActiveState.com  Tue Jun 20 20:29:26 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 20 Jun 2000 11:29:26 -0700
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
In-Reply-To: <20000620141747.D3142@amarok.cnri.reston.va.us>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAECLCJAA.DavidA@ActiveState.com>

> Is there a canonical list of all the defined URL types anywhere?  I
> notice that 'ldap' isn't there, and maybe there are more missing.
> (Some of the ones in there are marginal: who cares about Prospero?)

Mozilla defines a bunch, which I doubt are RFC anything. (chrome://,
component://, etc.).

--david




From jeremy at beopen.com  Tue Jun 20 20:33:59 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 20 Jun 2000 14:33:59 -0400 (EDT)
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620140406.B3142@amarok.cnri.reston.va.us>
References: <20000609215719.47624E2673@oratrix.oratrix.nl>
	<20000609181924.A15728@thyrsus.com>
	<20000620083344.A3499@ludwig.cnri.reston.va.us>
	<20000620140419.C10038@thyrsus.com>
	<20000620140406.B3142@amarok.cnri.reston.va.us>
Message-ID: <14671.47383.313007.531923@localhost.localdomain>

>>>>> "AMK" == Andrew M Kuchling <akuchlin at cnri.reston.va.us> writes:

  AMK> I just compiled XEmacs 21.1.10 on a new Linux machine; you
  AMK> compile the binary, and install two packages of Elisp code (EFS
  AMK> and xemacs-base).  Then you run xemacs, do Options > Manage
  AMK> Packages > List and Install, and you get a nice list containing
  AMK> GNUS, W3, programming language modes, etc.  Pick the ones you
  AMK> want, it adds the ones needed by the ones you selected, and it
  AMK> fetches and installs them.  Easy!  Now imagine doing the same
  AMK> thing with Python modules.  Of course, we'd have to design that
  AMK> feature first...

I did the same install on my new Linux box last month.  I was
similarly pleased with the ease of installation.  Let's get working on
a design for this feature!

Jeremy



From effbot at telia.com  Tue Jun 20 20:37:30 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 20 Jun 2000 20:37:30 +0200
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us>
Message-ID: <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid>

amk wrote:
> Is there a canonical list of all the defined URL types anywhere?  I
> notice that 'ldap' isn't there, and maybe there are more missing.

your local search bot to the rescue:
http://www.isi.edu/in-notes/iana/assignments/url-schemes

(see http://www.iana.org/numbers.htm for a full list of things
they keep track of)

</F>




From akuchlin at cnri.reston.va.us  Tue Jun 20 20:44:40 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Tue, 20 Jun 2000 14:44:40 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <14671.47383.313007.531923@localhost.localdomain>; from jeremy@beopen.com on Tue, Jun 20, 2000 at 02:33:59PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> <14671.47383.313007.531923@localhost.localdomain>
Message-ID: <20000620144440.E3142@amarok.cnri.reston.va.us>

On Tue, Jun 20, 2000 at 02:33:59PM -0400, Jeremy Hylton wrote:
>I did the same install on my new Linux box last month.  I was
>similarly pleased with the ease of installation.  Let's get working on
>a design for this feature!

I have some notes on this, but they're at home.  I'll post them tonight.

--amk



From paul at prescod.net  Tue Jun 20 20:42:21 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 20 Jun 2000 13:42:21 -0500
Subject: [Python-Dev] RFC: Including PIL in 1.6
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us>
Message-ID: <394FBB0D.96D88DBB@prescod.net>

"Andrew M. Kuchling" wrote:
> 
> ...
> 
> I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the
> binary, and install two packages of Elisp code (EFS and xemacs-base).
> Then you run xemacs, do Options > Manage Packages > List and Install,
> and you get a nice list containing GNUS, W3, programming language
> modes, etc.  Pick the ones you want, it adds the ones needed by the
> ones you selected, and it fetches and installs them.  Easy!  Now
> imagine doing the same thing with Python modules.  Of course, we'd
> have to design that feature first...

Let me repeat that I don't think that the main issue is whether it lives
in this tarfile versus that tarfile. It's 

 a) about agreeing to keep everything comptible.
 b) about being able to depend on the thing being there when you write a
module.

*In theory* Red Hat linux could be a kernel, a shell and the RPM engine.
In practice, people like to be able to say: "if you have Red Hat version
X then such and such will work because it comes with a functional
package Y."

Distutils is extremely important for vertical modules but if we start to
use it as an excuse for leaving out core modules then I have to go with
ESR and say: "where do we stop?" 

Unicode on demand? re on demand? pickle on demand?

I think that the more relevant criteria are the ones we have always
used:

 * how big is it
 * how easy is it to maintain
 * how integrated is it with everything else
 * how well-thought-out is it
 * and most important: how many people want it?

I think that PIL is not yet a clear home run.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Music is the stuff between the notes." - Claude Debussy



From guido at python.org  Tue Jun 20 22:09:05 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 20 Jun 2000 15:09:05 -0500
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: Your message of "Tue, 20 Jun 2000 14:04:06 -0400."
             <20000620140406.B3142@amarok.cnri.reston.va.us> 
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com>  
            <20000620140406.B3142@amarok.cnri.reston.va.us> 
Message-ID: <200006202009.PAA01064@cj20424-a.reston1.va.home.com>

> I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the
> binary, and install two packages of Elisp code (EFS and xemacs-base).
> Then you run xemacs, do Options > Manage Packages > List and Install,
> and you get a nice list containing GNUS, W3, programming language
> modes, etc.  Pick the ones you want, it adds the ones needed by the
> ones you selected, and it fetches and installs them.  Easy!  Now
> imagine doing the same thing with Python modules.  Of course, we'd
> have to design that feature first...

I just had to go through that process.  It was actually rather
painful, and I wouldn't have been able to succeed if it wasn't for
XEmax grandmaster Barry Warsaw standing next to me holding my hand for
a really long time...  The autofetcher appeared broken at first, then
had some unintuitive behavior next, before we finally got it running.
Finally I got the hang of it, but after that I still had about a week
where I occasionally used a familiar keystroke that triggered an
error, and usually it took an email to Barry to find out which package
contained the module defining the missing function.

Not to say that I'm against this kind of thing, but warning that even
in the best circumstances it can be a hurdle for newcomers...

Which is why there's a market for packagers like Red Hat.

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



From guido at python.org  Tue Jun 20 22:12:09 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 20 Jun 2000 15:12:09 -0500
Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse
In-Reply-To: Your message of "Tue, 20 Jun 2000 20:37:30 +0200."
             <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> 
References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us>  
            <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> 
Message-ID: <200006202012.PAA01130@cj20424-a.reston1.va.home.com>

> > Is there a canonical list of all the defined URL types anywhere?  I
> > notice that 'ldap' isn't there, and maybe there are more missing.
> 
> your local search bot to the rescue:
> http://www.isi.edu/in-notes/iana/assignments/url-schemes

Of course now the trick is which ones are still relevant (as the
doubt expressed about prospero exemplify).

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



From fdrake at beopen.com  Tue Jun 20 21:10:31 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 20 Jun 2000 15:10:31 -0400 (EDT)
Subject: [Python-Dev] David Ascher's compile.py script?
Message-ID: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>

  Does anyone have a copy of David Ascher's compile.py from his
starship pages?  The links there appear to be broken, and David
appearantly hasn't been able to find time to look for a copy, or can't
find it (I've sent him another mail about it in case it has turned
up), and documentation users are asking about it.  (There's a link
from the extending & embedding manual.)
  If anyone has a copy, perhaps I could find provide a temporary
location for it and revise the link in the online documentation to
point there, as a stop-gap measure.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From nascheme at enme.ucalgary.ca  Tue Jun 20 21:18:03 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Tue, 20 Jun 2000 13:18:03 -0600
Subject: [Python-Dev] David Ascher's compile.py script?
In-Reply-To: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jun 20, 2000 at 03:10:31PM -0400
References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>
Message-ID: <20000620131803.A13811@acs.ucalgary.ca>

On Tue, Jun 20, 2000 at 03:10:31PM -0400, Fred L. Drake, Jr. wrote:
>   Does anyone have a copy of David Ascher's compile.py from his
> starship pages?

I don't know how recent this copy is:

    http://www.enme.ucalgary.ca/~nascheme/python/compile.py

  Neil



From fdrake at beopen.com  Tue Jun 20 21:19:05 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 20 Jun 2000 15:19:05 -0400 (EDT)
Subject: [Python-Dev] David Ascher's compile.py script?
In-Reply-To: <20000620131803.A13811@acs.ucalgary.ca>
References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>
	<20000620131803.A13811@acs.ucalgary.ca>
Message-ID: <14671.50089.860177.145255@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > I don't know how recent this copy is:
 > 
 >     http://www.enme.ucalgary.ca/~nascheme/python/compile.py

  Thanks!  If nothing else shows up within the next day, I'll use this
one.
  David, is this sufficiently recent?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From skip at mojam.com  Tue Jun 20 21:33:20 2000
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 20 Jun 2000 14:33:20 -0500 (CDT)
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com>
References: <20000609215719.47624E2673@oratrix.oratrix.nl>
	<20000609181924.A15728@thyrsus.com>
	<20000620083344.A3499@ludwig.cnri.reston.va.us>
	<20000620140419.C10038@thyrsus.com>
	<20000620140406.B3142@amarok.cnri.reston.va.us>
	<200006202009.PAA01064@cj20424-a.reston1.va.home.com>
Message-ID: <14671.50944.796299.47756@beluga.mojam.com>

    Guido> I just had to go through that process.  It was actually rather
    Guido> painful ...

I will echo that sentiment.  Actually, the first time I upgraded to the
package stuff it went without a hitch.  The next time it took me awhile to
figure out why it didn't work.

I imagine it's just teething pain that will get worked out as the XEmacs
folks get more experience themselves, but auto-package install is definitely
something that would have to be pretty bulletproof.  I doubt the average
Python user will have a similar level of computer savvy as the average
XEmacs user.

On top of that, how will you know that you want package X until you download
it and try it out?  I presume that carried to its logical conclusion, a
package's documentation would be installed along with its source...

chicken-and-egg-ly y'rs,

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395



From paul at prescod.net  Tue Jun 20 22:09:18 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 20 Jun 2000 15:09:18 -0500
Subject: [Python-Dev] Argh...
Message-ID: <394FCF6E.85559D56@prescod.net>

Okay, this is blatantly off-topic. I'm trying to increase the noise
ratio so that people here will go back to comp.lang.python.

All I need is for someone to email me in private email what's the Java
equivalent of 

a=sys.argv[0]

(it's almost over, it's almost over, it's almost over)

Okay, here's an obPython: why doesn't the main module have an __file__
if it happens to be a file. I can understand why one piped in wouldn't
but the interpreter knows when the main module is a file.

-- 
 Paul Prescod
"Music is the stuff between the notes." - Claude Debussy



From guido at python.org  Tue Jun 20 23:31:00 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 20 Jun 2000 16:31:00 -0500
Subject: [Python-Dev] Argh...
In-Reply-To: Your message of "Tue, 20 Jun 2000 15:09:18 EST."
             <394FCF6E.85559D56@prescod.net> 
References: <394FCF6E.85559D56@prescod.net> 
Message-ID: <200006202131.QAA01631@cj20424-a.reston1.va.home.com>

> Okay, here's an obPython: why doesn't the main module have an __file__
> if it happens to be a file. I can understand why one piped in wouldn't
> but the interpreter knows when the main module is a file.

Mostly because it's tough to pass that information around all the way
to where it's needed.

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



From mhammond at skippinet.com.au  Wed Jun 21 01:06:57 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 21 Jun 2000 09:06:57 +1000
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBKENCCNAA.mhammond@skippinet.com.au>

[Guido]

> Not to say that I'm against this kind of thing, but warning that even
> in the best circumstances it can be a hurdle for newcomers...
>
> Which is why there's a market for packagers like Red Hat.

And even _then_ it is hard to get right.

My experience similar to this was with debian, and its xptselect package.
I was a Linux newbie, and the entire installation went pretty well until I
was asked which packages I want to fetch and install.

I was _soooo_ lost.  I found the interface a complete mystery.  It appeard
to make random selections of stuff I didnt want, then randomly de-select
stuff I didnt want.  I had no idea how to search for anything, and the help
was less than useful.  Sometimes it wanted to download nothing, other times
it wanted to download 400MB to complete the install!!!  I only just
resisted the temptation to go and buy a bunch of MS stock <wink>.

Of course, within a week, I understood what was going on, and the sofware
was indeed functioning correctly.

But it took me that entire week to have a Linux system with everything I
wanted installed and working correctly.

The point I am trying to make is that for stuff that should be considered
"core", the bar is very very high for these auto-configure applications.
The usual audience will be _complete_ newbies.  In my example, it was clear
that a complete linux newbie was never let loose on this program while
sitting in the same room as the author or the marketting team ;-)  But I
expect those with reasonable Linux experience quite like it, and themselves
would not be happy with the complete-newbie version.

The-included-batteries-were-the-wrong-size-ly,

Mark.




From Vladimir.Marangozov at inrialpes.fr  Wed Jun 21 01:34:31 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Wed, 21 Jun 2000 01:34:31 +0200 (CEST)
Subject: [Python-Dev] Fw: Access violation when no memory
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au> from "Mark Hammond" at Jun 20, 2000 09:42:53 PM
Message-ID: <200006202334.BAA03150@python.inrialpes.fr>

Mark Hammond wrote:
> 
> >From the newsgroup.  Any thoughts?
> 
> Mark.
> 
> "Phil Mayes" <nospam at bitbucket.com> wrote in message
> news:<olD35.82$_%.4481 at newsfeed.avtel.net>...
> > The following program progressively allocates all memory:
> >     size = 1 << 20
> >     list = [None,]
> >     while size:
> >         try:
> >             mem = [None] * size
> >             mem[0] = list
> >             list = mem
> >         except:
> >             size = size / 2
> >
> > It fails with an access violation.

The only immediate thought I have is that Python does not have builtin
emergency procedures for such extreme situations. Although there are some
safety checks, it is fairly easy to crash the interpreter in a number of
ways.

For example, with the introduction of the mmapmodule, there are even more
"risks", like managing to mmap the python executable and screw it up
completely (not speaking of the possibility to introduce Trojan horses
and similar if this is done on purpose). There would probably be more
checks, but complete safety is hard to achieve in the current state.

The proposed solution is not a solution. The example program dumps core
in different locations on my machine. We just do not have enough control
from Python for managing such extreme cases. Sad, but true...

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From amk1 at erols.com  Wed Jun 21 03:46:43 2000
From: amk1 at erols.com (A.M. Kuchling)
Date: Tue, 20 Jun 2000 21:46:43 -0400
Subject: [Python-Dev] Installation requirements
Message-ID: <200006210146.VAA01220@207-172-37-166.s166.tnt7.ann.va.dialup.rcn.com>

[Follow-up to the Distutils SIG, please.]

There are a few steps needed to find and install a package:
1) Discovery : which module does what I need?
2) Download  : where can I get a copy?
3) Security  : is this actually from the package author, and not a Trojan?
4) Installation : how do I set it up?
5) Checking for new versions: I have 1.0 installed; is a newer version 
   available?

Distutils focuses on the hardest and most complicated step, #4.  

For #1, you would need to browse through a list of available packages,
browse through a hierarchy like Parnassus, or do keyword searches.

#2 is pretty simple, since you just get one or more download URLs
corresponding to a given package name, using the same database as in
#1.

For #3, you'd have to check a signature on the downloaded package,
using something external like GnuPG.  This means this step has to be
skipped if the external tool isn't available.  We could implement our
own signature scheme with Python code, but that's a bad idea; security
is hard, and few people will bother to generate keys that are only
useful for this one application of distributing Python modules.  (Side
note: the sdist and bdist_* commands should have a --sign switch to
sign the generated .tgz, .rpm, or whatever file.)

For #5, the existing stuff in Tools/versioncheck might be partially
applicable, though it requires that every package have a text file
somewhere which gives the latest version.  You'd want to use the same
database for everything, to ensure that people actually use it!

To start off with, we'd need some sort of generic API to the above
functions, so that different interfaces can be written.  A
command-line interface would then be easiest.

I don't know how network communications should be handled: HTTP to CGI
scripts that return sets of RFC-822 headers, maybe?  Combined with a
DNS alias like modules.python.org, or modules.{us,uk,...}.python.org?

Some potential sources of inspiration:

Debian: apt
Perl: CPAM.pm
FreeBSD: ports system
RPMfind (rpmfind.net)
XEmacs: packages system

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
  "Jo, it's a pity escapology wasn't part of your curriculum."
  "Funny you should say that. Look." <shows untied hand>
  -- The Doctor and Jo, tied up, in "Terror of the Autons"



From tim_one at email.msn.com  Wed Jun 21 05:44:18 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 20 Jun 2000 23:44:18 -0400
Subject: [Python-Dev] talking about performance...
In-Reply-To: <002001bfdae1$b28942e0$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEDPGFAA.tim_one@email.msn.com>

[posted & mailed]

[Fredrik Lundh]
> how about this one:
>
>     if (dir > 0) {
>         char *p, *e;
>         if (n == 0 && i <= last)
>             return (long)i;
>         e = s + last - n + 1;
>         for (;;) {
>             p = memchr(s, sub[0], e - s);
>             if (p == NULL)
>                 break;
>             if (n == 1 || memcmp(p, sub, n) == 0)
>                 return (long) (p - s);
>             s = p + 1;
>         }
>     }
>
> new record time: 1.6 seconds (down from 2.2)

I expect that whether this is faster or slower depends on both the compiler
you're using and the exact strings you're using to time it.

In any case, it appears to be incorrect:  p & s both change inside the
infinite loop, and the innermost return computes their difference.  Surely
it should be returning the difference between p and the value s had *before*
the loop was entered.  If this passed your tests, then, it suggests you had
no "false hits" (i.e., that the inner loop returned on its first iteration,
else the return value would have been wrong), which are probably the cases
in which using memchr rather than the current code is least likely to slow
things down.

It's bad that the original code never bothered to document what it's
supposed to return, but that's no excuse to return probabilistically-correct
gibberish <wink>.





From tim_one at email.msn.com  Wed Jun 21 05:44:25 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 20 Jun 2000 23:44:25 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <20000620132150.O8678@thyrsus.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>

[Ka-Ping Yee]
> I just have to say i thought list comprehensions were
> really cool.

[Eric S. Raymond]
> Ditto.  I would like to see this in 1.6.

Nobody has been more vocal in support of these (& augmented assignments)
than me, but I very strongly doubt they'll be in 1.6.  In the interests of
getting that out the door, Guido considers the 1.6 feature set to be frozen
already.

I think part of the pressure to get one more feature in Python (again &
again & again) is that release cycles have been soooooo protracted, now
slobbering well over the full year mark.  If I accomplish nothing else at
BeOpen, I want to give that a major speed boost -- I don't think we should
ever let 6 months go by without at least pumping out a bugfix release.

there-are-other-things-guido-doesn't-yet-know-he-believes-too<wink>-ly
    y'rs  - tim





From skip at mojam.com  Wed Jun 21 06:33:12 2000
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 20 Jun 2000 23:33:12 -0500 (CDT)
Subject: [Python-Dev] feeble attempt at list comprehensions doc...
Message-ID: <14672.17800.994102.266619@beluga.mojam.com>


Attached to this message are two patches, one for Doc/ref/ref5.tex and one
for Doc/tut/tut.tex.  They provide minimal documentation for list
comprehensions.  I'm sure just about anyone else could do better.  Feel free 
to embellish.

The BNF used in the reference manual doesn't seem to match the BNF in the
Grammar file very well, so I'm not even certain I have the correct BNF or
have it in the correct place.  In particular, I'm pretty sure the
BNF for list_for and list_if are incorrect.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tut.diff
Type: application/octet-stream
Size: 1000 bytes
Desc: list comprehension diffs
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000620/2acdcca6/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ref5.diff
Type: application/octet-stream
Size: 1141 bytes
Desc: reference manual diff
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000620/2acdcca6/attachment-0003.obj>

From tim_one at email.msn.com  Wed Jun 21 06:53:59 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 21 Jun 2000 00:53:59 -0400
Subject: [Python-Dev] Warnings in mmapmodule
Message-ID: <LNBBLJKPBEHFEDALKOLCOEEDGFAA.tim_one@email.msn.com>

I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
mismatches:

Modules\mmapmodule.c(571) : warning C4018: '>=' : signed/unsigned mismatch
	if (i < 0 || i >= self->size) {
Modules\mmapmodule.c(586) : warning C4018: '>' : signed/unsigned mismatch
	else if (ilow > self->size)
Modules\mmapmodule.c(592) : warning C4018: '>' : signed/unsigned mismatch
	else if (ihigh > self->size)
Modules\mmapmodule.c(631) : warning C4018: '>' : signed/unsigned mismatch
	else if (ilow > self->size)
Modules\mmapmodule.c(637) : warning C4018: '>' : signed/unsigned mismatch
	else if (ihigh > self->size)
Modules\mmapmodule.c(664) : warning C4018: '>=' : signed/unsigned mismatch
	if (i < 0 || i >= self->size) {

I'll volunteer to fix these if nobody else does (although at the moment I'm
not able to produce either a patch or check in).

new-laptops-in-hotel-rooms-have-their-limitations-ly y'rs  - tim





From mhammond at skippinet.com.au  Wed Jun 21 06:57:54 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 21 Jun 2000 14:57:54 +1000
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEEDGFAA.tim_one@email.msn.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEOACNAA.mhammond@skippinet.com.au>

> I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
> mismatches:

Me too :-)

> I'll volunteer to fix these if nobody else does (although at the
> moment I'm
> not able to produce either a patch or check in).

I nearly did, but then couldnt find the time to chase up how Unix declared
the relevant items - I didnt want to assume they were identical to Windows.

My intention was to make the patch, then test it out on my gleaming Linux
box.

But-the-road-to-hell-is-paved-with-good-intentions-ly,

Mark.




From tim_one at email.msn.com  Wed Jun 21 07:22:37 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 21 Jun 2000 01:22:37 -0400
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBIEOACNAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>

[posted & mailed]

[Tim]
> I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
> mismatches:

[Mark Hammond]
> Me too :-)
>
> I nearly [fixed them], but then couldnt find the time to chase up how
> Unix declared the relevant items - I didnt want to assume they were
> identical to Windows.

They all involve mixing ints with mmap_object.size in comparisons, which
latter is declared size_t and so will resolve to *some* unsigned integral
type on all platforms.  The proper fix is to get rid of the ints before
making these tests -- ask Trent, he should be able to do this in his sleep
now <wink>.

> My intention was to make the patch, then test it out on my gleaming Linux
> box.
>
> But-the-road-to-hell-is-paved-with-good-intentions-ly,

No, it's paved with Linux:  I've been using Windows so long I forgot why
Unix is supposed to be more usable <0.9 wink>.  Mark, if you've figured out
how to do a SourceForge checkin from a Windows box, drop me a line offline!
It would save me from figuring out which one of the 10,000 SSH+Windows
search hits actually leads to something that works (and, no, so long as my
entire life is sitting on my laptop, I'm not getting another OS anywhere
near this box).

becoming-a-linux-true-believer-again-is-on-my-schedule-but-not-
    for-a-couple-months-ly y'rs  - tim





From DavidA at ActiveState.com  Wed Jun 21 07:40:36 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 20 Jun 2000 22:40:36 -0700
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>
Message-ID: <LMBBIEIJKMPMLBONJMFCIEBLCJAA.DavidA@ActiveState.com>

> No, it's paved with Linux:  I've been using Windows so long I forgot why
> Unix is supposed to be more usable <0.9 wink>.  Mark, if you've
> figured out
> how to do a SourceForge checkin from a Windows box, drop me a
> line offline!

No, please, drop us all a line online!  I've decided that I'm not going to
waste any more of my time dealing w/ SourceForge.  Luckily I seem to have
found some helpers for the PyOpenGL transition who are willing to deal with
that!

--david




From mhammond at skippinet.com.au  Wed Jun 21 07:49:45 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 21 Jun 2000 15:49:45 +1000
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <LMBBIEIJKMPMLBONJMFCIEBLCJAA.DavidA@ActiveState.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au>

[David]
> No, please, drop us all a line online!

OK - here it is, for what it is worth.  You will notice that I spent the
time to research my facts carefully before giving out this information
(NOT!)

Sure.  It is a bit of a PITA (surprise, surprise, surprise):

First, get the latest WinCVS.  Has some nice new features.  Mine shows as
1.1b13.  It has a slightly ?slicker? more windowsy look than the older one.
What we really want is the version with the Options/Preferences dialog that
allows you to supply the ?RAS identity? file when you select ?SSH Server?
as the auth method.  Previous versions allow you to select the SSH Server,
but give you nowhere to put the identity file.  Hence previous versions
used a batch file wrapper, which you probably saw reference to.  This
version makes it much simpler.

I use the standard SSH Version 1.2.14 binary set.  I cant recall the URL,
but it is quite small and only a few binary files.  ?ssh? shows usage -
?ssh -v? shows versbose usage, ?verbose? in this context apparently means
showing the version number (took me ages to work that one out :-)

There were only a few files, so I just dumped them all in the same
directory as the CVS binaries.

You then need to make a ?key? file - I cant recall the exact process, but
it is pretty simple.  This is creating the identify file you specify to
WinCVS, as well as the public key you upload to source-force.

NOTE - from memory, you MUST have a HOME env var set, and you MUST have a
?.ssh? directory under your home.  Otherwise you get cryptic errors from
SSH that give no clue that this is the problem.

After uploading the public key to source forge, you are nearly set.  The
last step is convinving CVS that you want to use this new SSH setting, and
not the setting CVS so kindly persists in its ?CVS\Root? files.  The only
way I found to do this was to either edit the Root files manually, or
remove the directories locally and force CVS to re-create them (and thereby
re-pull everything - I assume you have ADSL in that hotel room :-)
Alternatively, dig up that CVS script posted to py-dev recently and change
it - personally, I never trusted it :-)

All my root files look like:
:ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python

Yours almost certainly will be setup for anon access, not using ssh.

Hope that makes sense.  Im happy to chase anything else up I can for you...

Mark.




From effbot at telia.com  Wed Jun 21 09:58:06 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 21 Jun 2000 09:58:06 +0200
Subject: [Python-Dev] talking about performance...
References: <LNBBLJKPBEHFEDALKOLCAEDPGFAA.tim_one@email.msn.com>
Message-ID: <006401bfdb56$6f84ae60$f2a6b5d4@hagrid>

tim wrote:

> >             p = memchr(s, sub[0], e - s);
> >             if (p == NULL)
> >                 break;
> >             if (n == 1 || memcmp(p, sub, n) == 0)
> >                 return (long) (p - s);

> I expect that whether this is faster or slower depends on both the compiler
> you're using and the exact strings you're using to time it.

With test strings that contain false matches for every single
position, it's 30% slower than the old code in my tests.  With
test strings that contain no false matches, it's 50% faster.

But without more extensive tests on a variety of platforms, we
might as well forget about this one...

</F>




From mal at lemburg.com  Wed Jun 21 10:23:02 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Jun 2000 10:23:02 +0200
Subject: [Python-Dev] Proposal: standard way of defining and executing 
 "atexit" functions...
References: <PLEJJNOHDIGGLDPOGPJJCECJCJAA.DavidA@ActiveState.com>
Message-ID: <39507B66.763DB418@lemburg.com>

[Skip's exit.py module + David's extension to support already
 registered exitfunc'tions]

Looks like everyone agrees -- with a final word from Guido
we'd only need some docs to go with it and then check Skip's
module in as new standard module.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From skip at mojam.com  Wed Jun 21 15:38:01 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 21 Jun 2000 08:38:01 -0500 (CDT)
Subject: [Python-Dev] Proposal: standard way of defining and executing 
 "atexit" functions...
In-Reply-To: <39507B66.763DB418@lemburg.com>
References: <PLEJJNOHDIGGLDPOGPJJCECJCJAA.DavidA@ActiveState.com>
	<39507B66.763DB418@lemburg.com>
Message-ID: <14672.50489.611301.616242@beluga.mojam.com>

    MA> Looks like everyone agrees -- with a final word from Guido we'd only
    MA> need some docs to go with it and then check Skip's module in as new
    MA> standard module.

I'll try to get David's enhancement added to my code and write some simple
documentation today.  Is "exit.py" acceptable with everyone as the name of
the module?

Skip



From skip at mojam.com  Wed Jun 21 20:15:19 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 21 Jun 2000 13:15:19 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
Message-ID: <14673.1591.506532.170015@beluga.mojam.com>

This message contains four attached files:

    Lib/exit.py	- a module that allows users to register cleanup functions
    Lib/test/test_exit.py - a simple test script
    Lib/test/output/test_exit - expected test output
    Doc/lib/libexit.tex - library reference manual section

Besides adding documentation and a test script, the following two mods were
made to exit.py since I previously posted it:

    1. It implements a LIFO execution order
    2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is 
       treated as an exit function and appended to the exit function list.

Comments, please.  Also, can someone tell me how to coax CVS into creating a 
unified diff that actually contains new files?  I tried

    cvs diff -RNau

without success.

Thanks,

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation:
    https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exit.py
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000621/bf1b7236/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_exit.py
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000621/bf1b7236/attachment-0002.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_exit
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000621/bf1b7236/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libexit.tex
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000621/bf1b7236/attachment-0003.asc>

From trentm at activestate.com  Wed Jun 21 21:20:12 2000
From: trentm at activestate.com (Trent Mick)
Date: Wed, 21 Jun 2000 12:20:12 -0700
Subject: [Python-Dev] Warnings in mmapmodule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>
References: <ECEPKNMJLHAPFFJHDOJBIEOACNAA.mhammond@skippinet.com.au> <LNBBLJKPBEHFEDALKOLCOEEFGFAA.tim_one@email.msn.com>
Message-ID: <20000621122012.A28236@activestate.com>

On Wed, Jun 21, 2000 at 01:22:37AM -0400, Tim Peters wrote:
> [posted & mailed]
> 
> [Tim]
> > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned
> > mismatches:
> 
> [Mark Hammond]
> > Me too :-)
> >
> > I nearly [fixed them], but then couldnt find the time to chase up how
> > Unix declared the relevant items - I didnt want to assume they were
> > identical to Windows.
> 
> They all involve mixing ints with mmap_object.size in comparisons, which
> latter is declared size_t and so will resolve to *some* unsigned integral
> type on all platforms.  The proper fix is to get rid of the ints before
> making these tests -- ask Trent, he should be able to do this in his sleep
> now <wink>.
> 

I wish I could do it in my sleep, then I would be much more well rested. Yes
I will clean these up. I was going to look at mmap a little anyway as
test_mmap currently fails on Win32 (probably as a resul of my mmpa patch).

Trent


-- 
Trent Mick
trentm at activestate.com



From DavidA at ActiveState.com  Wed Jun 21 19:25:07 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Wed, 21 Jun 2000 10:25:07 -0700
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>

> First, get the latest WinCVS.

	http://www.wincvs.org/download.html

> I use the standard SSH Version 1.2.14 binary set.  I cant recall the URL,

There's a version at:

      ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip

BUT...

> You then need to make a ?key? file - I cant recall the exact process, but
> it is pretty simple.  This is creating the identify file you specify to
> WinCVS, as well as the public key you upload to source-force.

	C:\WinCVS>ssh-keygen

I always get a 'gethostname: no such file or directory' so I had to create
the key on Linux (as is mentioned in the page
http://bmrc.berkeley.edu/people/chaffee/winntutil.html).

Maybe you have a better binary for ssh?

> NOTE - from memory, you MUST have a HOME env var set, and you MUST have a
> ?.ssh? directory under your home.  Otherwise you get cryptic errors from
> SSH that give no clue that this is the problem.
>
> After uploading the public key to source forge, you are nearly set.

How do you do that?

> The
> last step is convinving CVS that you want to use this new SSH setting, and
> not the setting CVS so kindly persists in its ?CVS\Root? files.  The only
> way I found to do this was to either edit the Root files manually, or
> remove the directories locally and force CVS to re-create them
> (and thereby
> re-pull everything - I assume you have ADSL in that hotel room :-)
> Alternatively, dig up that CVS script posted to py-dev recently and change
> it - personally, I never trusted it :-)
>
> All my root files look like:
> :ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python
>
> Yours almost certainly will be setup for anon access, not using ssh.
>
> Hope that makes sense.  Im happy to chase anything else up I can
> for you...
>
> Mark.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
>




From akuchlin at cnri.reston.va.us  Wed Jun 21 22:27:31 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Wed, 21 Jun 2000 16:27:31 -0400
Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400
References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEGHGFAA.tim_one@email.msn.com> <14673.158.183876.75480@localhost.localdomain>
Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us>

On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote:
>>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:
>  TP> + This mailing list doesn't work.  At least the SourceForge
>I agree that it's a complete mess, though.

While you're all admiring the difficulty of the problem, how about
actually checking in the pythonrun.c patch, assuming it's reasonable?

<flame> 

Frankly, I don't think the current mailing list is broken, *as long as
patches are handled with reasonable speed* so that the backlog doesn't
build up.  That hasn't been done, and I don't understand why.
Obviously the CNRI->BeOpen transaction resulted in some downtime for
everyone, but now it's a month later and there's still stagnation.
Why aren't incoming patches being handled now?  It's not like there
are very many patches per day; an hour or two should suffice to keep
the queue from growing.

At this point, the best fix is to do two things:

1) Someone downloads the mbox archives of the patches list, and goes
through all the past patches: apply them, discard them, send them back
for revision.

2) Commit to handling new patches that arrive, and either
apply/discard/revise them.

Worrying about patch management mechanism, while more patches pile up
and are ignored in the meantime, is not going to help and will just
results in continued stagnation.  
</flame>

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I couldn't think of one clever way to stop this guy, so I just trusted to
mindless violence.
  -- Cliff Steele in DOOM PATROL #21




From akuchlin at cnri.reston.va.us  Wed Jun 21 22:27:31 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Wed, 21 Jun 2000 16:27:31 -0400
Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400
References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEGHGFAA.tim_one@email.msn.com> <14673.158.183876.75480@localhost.localdomain>
Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us>

On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote:
>>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:
>  TP> + This mailing list doesn't work.  At least the SourceForge
>I agree that it's a complete mess, though.

While you're all admiring the difficulty of the problem, how about
actually checking in the pythonrun.c patch, assuming it's reasonable?

<flame> 

Frankly, I don't think the current mailing list is broken, *as long as
patches are handled with reasonable speed* so that the backlog doesn't
build up.  That hasn't been done, and I don't understand why.
Obviously the CNRI->BeOpen transaction resulted in some downtime for
everyone, but now it's a month later and there's still stagnation.
Why aren't incoming patches being handled now?  It's not like there
are very many patches per day; an hour or two should suffice to keep
the queue from growing.

At this point, the best fix is to do two things:

1) Someone downloads the mbox archives of the patches list, and goes
through all the past patches: apply them, discard them, send them back
for revision.

2) Commit to handling new patches that arrive, and either
apply/discard/revise them.

Worrying about patch management mechanism, while more patches pile up
and are ignored in the meantime, is not going to help and will just
results in continued stagnation.  
</flame>

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I couldn't think of one clever way to stop this guy, so I just trusted to
mindless violence.
  -- Cliff Steele in DOOM PATROL #21




From akuchlin at cnri.reston.va.us  Wed Jun 21 22:27:31 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Wed, 21 Jun 2000 16:27:31 -0400
Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400
References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEGHGFAA.tim_one@email.msn.com> <14673.158.183876.75480@localhost.localdomain>
Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us>

On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote:
>>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:
>  TP> + This mailing list doesn't work.  At least the SourceForge
>I agree that it's a complete mess, though.

While you're all admiring the difficulty of the problem, how about
actually checking in the pythonrun.c patch, assuming it's reasonable?

<flame> 

Frankly, I don't think the current mailing list is broken, *as long as
patches are handled with reasonable speed* so that the backlog doesn't
build up.  That hasn't been done, and I don't understand why.
Obviously the CNRI->BeOpen transaction resulted in some downtime for
everyone, but now it's a month later and there's still stagnation.
Why aren't incoming patches being handled now?  It's not like there
are very many patches per day; an hour or two should suffice to keep
the queue from growing.

At this point, the best fix is to do two things:

1) Someone downloads the mbox archives of the patches list, and goes
through all the past patches: apply them, discard them, send them back
for revision.

2) Commit to handling new patches that arrive, and either
apply/discard/revise them.

Worrying about patch management mechanism, while more patches pile up
and are ignored in the meantime, is not going to help and will just
results in continued stagnation.  
</flame>

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I couldn't think of one clever way to stop this guy, so I just trusted to
mindless violence.
  -- Cliff Steele in DOOM PATROL #21




From guido at python.org  Thu Jun 22 00:55:22 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 21 Jun 2000 17:55:22 -0500
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: Your message of "Wed, 21 Jun 2000 13:15:19 EST."
             <14673.1591.506532.170015@beluga.mojam.com> 
References: <14673.1591.506532.170015@beluga.mojam.com> 
Message-ID: <200006212255.RAA02444@cj20424-a.reston1.va.home.com>

If I had designed this, I might have called the module "onexit" or
"atexit" and the public function simply "register()".  But I've got
only a +0 for my own proposal.  A +1 for the general idea.

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



From paul at prescod.net  Thu Jun 22 00:13:39 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 21 Jun 2000 17:13:39 -0500
Subject: [Python-Dev] list comprehensions
References: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>
Message-ID: <39513E13.F8082811@prescod.net>

Tim Peters wrote:
> 
> ...
> Nobody has been more vocal in support of these (& augmented assignments)
> than me, but I very strongly doubt they'll be in 1.6.  In the interests of
> getting that out the door, Guido considers the 1.6 feature set to be frozen
> already.

Is there an argument for putting in features with flaming red neon
lights: "warning, experimental, use at your risk." We want to follow a
bazaar (if not outright bizarre) development strategy after all. Putting
a patch "out there" really doesn't do much about having people really
play with and comment on a feature. I would never have experimented (and
decided against using...) metaclasses if they hadn't popped up as an
experimental feature.

Of course if there is a decent chance of breaking something already in
there that works then that's another issue...

> I think part of the pressure to get one more feature in Python (again &
> again & again) is that release cycles have been soooooo protracted, now
> slobbering well over the full year mark.  

Nah, no matter how quick you do the turnarounds, nobody wants to wait
for their favorite feature. :)

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Floggings will continue until morale improves.



From DavidA at ActiveState.com  Wed Jun 21 19:25:07 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Wed, 21 Jun 2000 10:25:07 -0700
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au>
Message-ID: <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>

> First, get the latest WinCVS.

	http://www.wincvs.org/download.html

> I use the standard SSH Version 1.2.14 binary set.  I cant recall the URL,

There's a version at:

      ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip

BUT...

> You then need to make a ?key? file - I cant recall the exact process, but
> it is pretty simple.  This is creating the identify file you specify to
> WinCVS, as well as the public key you upload to source-force.

	C:\WinCVS>ssh-keygen

I always get a 'gethostname: no such file or directory' so I had to create
the key on Linux (as is mentioned in the page
http://bmrc.berkeley.edu/people/chaffee/winntutil.html).

Maybe you have a better binary for ssh?

> NOTE - from memory, you MUST have a HOME env var set, and you MUST have a
> ?.ssh? directory under your home.  Otherwise you get cryptic errors from
> SSH that give no clue that this is the problem.
>
> After uploading the public key to source forge, you are nearly set.

How do you do that?

> The
> last step is convinving CVS that you want to use this new SSH setting, and
> not the setting CVS so kindly persists in its ?CVS\Root? files.  The only
> way I found to do this was to either edit the Root files manually, or
> remove the directories locally and force CVS to re-create them
> (and thereby
> re-pull everything - I assume you have ADSL in that hotel room :-)
> Alternatively, dig up that CVS script posted to py-dev recently and change
> it - personally, I never trusted it :-)
>
> All my root files look like:
> :ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python
>
> Yours almost certainly will be setup for anon access, not using ssh.
>
> Hope that makes sense.  Im happy to chase anything else up I can
> for you...
>
> Mark.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
>




From nascheme at enme.ucalgary.ca  Thu Jun 22 02:25:46 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Wed, 21 Jun 2000 18:25:46 -0600
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14673.1591.506532.170015@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 01:15:19PM -0500
References: <14673.1591.506532.170015@beluga.mojam.com>
Message-ID: <20000621182546.B25879@acs.ucalgary.ca>

On Wed, Jun 21, 2000 at 01:15:19PM -0500, Skip Montanaro wrote:
> Also, can someone tell me how to coax CVS into creating a 
> unified diff that actually contains new files?  I tried
> 
>     cvs diff -RNau
> 
> without success.

Did you "cvs add" them?

  Neil

-- 
"Simplicity does not precede complexity, but follows it." -- Alan Perlis



From skip at mojam.com  Thu Jun 22 02:39:03 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 21 Jun 2000 19:39:03 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <20000621182546.B25879@acs.ucalgary.ca>
References: <14673.1591.506532.170015@beluga.mojam.com>
	<20000621182546.B25879@acs.ucalgary.ca>
Message-ID: <14673.24615.291912.261214@beluga.mojam.com>

    >> Also, can someone tell me how to coax CVS into creating a unified
    >> diff that actually contains new files?  I tried
    >> 
    >> cvs diff -RNau
    >> 
    >> without success.

    Neil> Did you "cvs add" them?

Not something I could do, since I'm cvs'ing against the sourceforge
repository.  The best I guess I can do is to mirror the repository twice,
add the new files to one tree, then perform a regular diff...

Skip



From esr at thyrsus.com  Thu Jun 22 04:09:35 2000
From: esr at thyrsus.com (esr at thyrsus.com)
Date: Wed, 21 Jun 2000 22:09:35 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>
References: <20000620132150.O8678@thyrsus.com> <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com>
Message-ID: <20000621220934.A1044@thyrsus.com>

Tim Peters <tim_one at email.msn.com>:
> Nobody has been more vocal in support of these (& augmented assignments)
> than me, but I very strongly doubt they'll be in 1.6.  In the interests of
> getting that out the door, Guido considers the 1.6 feature set to be frozen
> already.
> 
> I think part of the pressure to get one more feature in Python (again &
> again & again) is that release cycles have been soooooo protracted, now
> slobbering well over the full year mark.  If I accomplish nothing else at
> BeOpen, I want to give that a major speed boost -- I don't think we should
> ever let 6 months go by without at least pumping out a bugfix release.

OK, I can buy this.  Are there concrete plans (as in, a specified timeframe)
for a release in which new features will be admitted?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

What, then is law [government]? It is the collective organization of
the individual right to lawful defense."
	-- Frederic Bastiat, "The Law"



From mal at lemburg.com  Thu Jun 22 11:05:09 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 22 Jun 2000 11:05:09 +0200
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
References: <14673.1591.506532.170015@beluga.mojam.com>
Message-ID: <3951D6C5.BA31276B@lemburg.com>

> This message contains four attached files:
> 
>     Lib/exit.py - a module that allows users to register cleanup functions
>     Lib/test/test_exit.py - a simple test script
>     Lib/test/output/test_exit - expected test output
>     Doc/lib/libexit.tex - library reference manual section
> 
> Besides adding documentation and a test script, the following two mods were
> made to exit.py since I previously posted it:
> 
>     1. It implements a LIFO execution order
>     2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is 
>        treated as an exit function and appended to the exit function list.
> 
> Comments, please.

Looks ok to me, but since this is going to be a new standard
module I guess we should wait for Guido's ok before checking
it in.

> Also, can someone tell me how to coax CVS into creating a 
> unified diff that actually contains new files?  I tried
> 
>     cvs diff -RNau
> 
> without success.

I'm not an CVS expert, but I could imagine that you'll have to
add the files to CVS first and then run the above diff.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gstein at lyra.org  Thu Jun 22 15:30:53 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 22 Jun 2000 06:30:53 -0700
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>; from DavidA@ActiveState.com on Wed, Jun 21, 2000 at 10:25:07AM -0700
References: <ECEPKNMJLHAPFFJHDOJBKEOECNAA.mhammond@skippinet.com.au> <PLEJJNOHDIGGLDPOGPJJAEGLCJAA.DavidA@ActiveState.com>
Message-ID: <20000622063053.M29590@lyra.org>

On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote:
>...
> > You then need to make a ?key? file - I cant recall the exact process, but
> > it is pretty simple.  This is creating the identify file you specify to
> > WinCVS, as well as the public key you upload to source-force.
> 
> 	C:\WinCVS>ssh-keygen
> 
> I always get a 'gethostname: no such file or directory' so I had to create
> the key on Linux (as is mentioned in the page
> http://bmrc.berkeley.edu/people/chaffee/winntutil.html).
> 
> Maybe you have a better binary for ssh?

Nah. Mark just forgets that I generated the key for him from my Linux box :-)

hehe...

Cheers,
-g

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



From tim_one at email.msn.com  Thu Jun 22 15:46:15 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 22 Jun 2000 09:46:15 -0400
Subject: [Python-Dev] SourceForge vs Windows
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBCEOECNAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEINGFAA.tim_one@email.msn.com>

I have to get SourceForge developer access working with Windows (Win98SE,
specifically), so I'll write up detailed instructions along the way,
building on Mark Hammond's good clues.  Play along!  I'll accumulate
everyone's input & make a coherent how-to out of it.

Today's installment only covers the first step, as it took 12 hours for meto
complete it (rotten connectivity today, via 56K modem, requiring many
attempts at downloading before one succeeded):

[Mark Hammond]
> First, get the latest WinCVS.  Has some nice new features.  Mine shows
> as 1.1b13.  It has a slightly ?slicker? more windowsy look than the
> older one.  What we really want is the version with the
Options/Preferences
> dialog that allows you to supply the ?RAS identity? file when you select
> ?SSH Server? as the auth method.  Previous versions allow you to select
> the SSH Server, but give you nowhere to put the identity file.  Hence
> previous versions used a batch file wrapper, which you probably saw
> reference to.  This version makes it much simpler.

I picked up the 1.1b14 version, released 19 Jun 2000, from

    http://www.wincvs.org/download.html

It's a 3.21 Mb zip file.

hard-to-blow-it-so-far<wink>-ly y'rs  - tim






From tim_one at email.msn.com  Thu Jun 22 15:46:17 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 22 Jun 2000 09:46:17 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <20000621220934.A1044@thyrsus.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIOGFAA.tim_one@email.msn.com>

[Tim, sez the 1.6 feature set should be considered frozen, and that
 Python should move to a much less sloth-like release schedule
 thereafter]

[esr at thyrsus.com]
> OK, I can buy this.

Comes with a 30-day warranty, too <wink>.

> Are there concrete plans (as in, a specified timeframe)
> for a release in which new features will be admitted?

There damn well ought to be.  PythonLabs will be having its first all-hands
meeting tomorrow (Guido's been gone, I've been in this state less than a
week, & I'm still not sure Jeremy Hylton exists), and rational, timely
release schedules are certainly on my agenda.  I have no problem with new
features in minor releases either, provided they're 100% backward-compatible
(e.g., list comprehensions, yes (so long as they don't introduce new
bytecodes); having str(long) strip the trailing "L", no).  More when we know
more.

and-less-when-we-know-less-ly y'rs  - tim






From nascheme at enme.ucalgary.ca  Thu Jun 22 17:24:16 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 22 Jun 2000 09:24:16 -0600
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14673.24615.291912.261214@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 07:39:03PM -0500
References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> <14673.24615.291912.261214@beluga.mojam.com>
Message-ID: <20000622092416.A31223@acs.ucalgary.ca>

On Wed, Jun 21, 2000 at 07:39:03PM -0500, Skip Montanaro wrote:
>     Neil> Did you "cvs add" them?
> 
> Not something I could do, since I'm cvs'ing against the sourceforge
> repository.

That's okay.  "cvs add" only modifies things locally.  You have
to "cvs commit" to change things in the repository.

  Neil

-- 
The internet: Learn what you know.  Share what you don't.



From klm at digicool.com  Thu Jun 22 18:13:46 2000
From: klm at digicool.com (Ken Manheimer)
Date: Thu, 22 Jun 2000 12:13:46 -0400 (EDT)
Subject: [Python-Dev] CVS and SSH under windows.
In-Reply-To: <20000622063053.M29590@lyra.org>
Message-ID: <Pine.LNX.4.21.0006221210510.19353-100000@korak.digicool.com>

A bit of a tangent, but MindTerm - http://www.mindbright.se/mindterm - is
a pretty nice java SSH client which you can use on windows to generate the
RSA identity.  (It also is a fine SSH client, with just about all the
nicities except compression - scp, x11 forwarding, arbitrary tunneling,
etc are all in there...)

Ken
klm at digicool.com

On Thu, 22 Jun 2000, Greg Stein wrote:

> On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote:
> >...
> > > You then need to make a ?key? file - I cant recall the exact process, but
> > > it is pretty simple.  This is creating the identify file you specify to
> > > WinCVS, as well as the public key you upload to source-force.
> > 
> > 	C:\WinCVS>ssh-keygen
> > 
> > I always get a 'gethostname: no such file or directory' so I had to create
> > the key on Linux (as is mentioned in the page
> > http://bmrc.berkeley.edu/people/chaffee/winntutil.html).
> > 
> > Maybe you have a better binary for ssh?
> 
> Nah. Mark just forgets that I generated the key for him from my Linux box :-)
> 
> hehe...
> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 




From skip at mojam.com  Thu Jun 22 19:21:04 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 22 Jun 2000 12:21:04 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <200006212255.RAA02444@cj20424-a.reston1.va.home.com>
References: <14673.1591.506532.170015@beluga.mojam.com>
	<200006212255.RAA02444@cj20424-a.reston1.va.home.com>
Message-ID: <14674.19200.325533.979792@beluga.mojam.com>

    Guido> If I had designed this, I might have called the module "onexit"
    Guido> or "atexit" and the public function simply "register()".  But
    Guido> I've got only a +0 for my own proposal.  A +1 for the general
    Guido> idea.

I'm happy to change things.  I was a bit curious if people would ask about
such a common word for a new module name.  What module name do people
prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not
careful), or something else?

Skip



From skip at mojam.com  Thu Jun 22 19:27:18 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 22 Jun 2000 12:27:18 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <20000622092416.A31223@acs.ucalgary.ca>
References: <14673.1591.506532.170015@beluga.mojam.com>
	<20000621182546.B25879@acs.ucalgary.ca>
	<14673.24615.291912.261214@beluga.mojam.com>
	<20000622092416.A31223@acs.ucalgary.ca>
Message-ID: <14674.19574.609843.392230@beluga.mojam.com>

    Neil> That's okay.  "cvs add" only modifies things locally.  You have to
    Neil> "cvs commit" to change things in the repository.

Ah, thanks for the tip.  I'll try that next time...

Skip



From tim_one at email.msn.com  Fri Jun 23 03:38:43 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 22 Jun 2000 21:38:43 -0400
Subject: [Python-Dev] RE: [Patches] Patch management (was: Warnings in pythonrun.c)
In-Reply-To: <20000621162731.B3918@amarok.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>

[Andrew M. Kuchling]
> While you're all admiring the difficulty of the problem, how about
> actually checking in the pythonrun.c patch, assuming it's reasonable?

I can't yet.  Be my guest!

> <flame>
>
> Frankly, I don't think the current mailing list is broken, *as long as
> patches are handled with reasonable speed* so that the backlog doesn't
> build up.

Andrew, this is saying that if it didn't display all the symptoms of
illness, it wouldn't be sick.  The consistent (this started long before
Guido's honeymoon!) lack of timely action here *is* the brokenness.

> That hasn't been done, and I don't understand why.

Why didn't you check in the pythonrun.c patch?  Multiply by 10 people and
100 patches.  There are no mechanisms in a mailing list for assigning,
recording or checking responsibility, neither for recording or querying
disposition status.  Nobody owns any part of the problem now, and it's
extraordinarly difficult to determine the status of any particular patch you
may be interested in via this mish-mash of archived all-topic email
scattered across patches and python-dev.

Prior to this mailing list, Guido owned every problem and the database was
in his head.  I think it's the lack of the "owned" and "database" parts
we're suffering from here, not especially the lack of the "Guido" part.
SourceForge provides rudimentary mechanisms for both of the former; a Python
replacement for Guido is one of BeOpen's highest secret priorities <wink>.

> ...
> Worrying about patch management mechanism, while more patches pile up
> and are ignored in the meantime, is not going to help and will just
> results in continued stagnation.

At an all-hands PythonLabs group mtg today, it was decided to move patch
activity to SourceForge and kill the patches list.  I'll send more about
that later.  There is absolutely nothing new stopping checkins while the
move to the SourceForge patch manager is in progress, so if the patches
continue to pile up it's certainly not the move's fault.  If the pythonrun.c
patch is still sitting untouched after the move, I'll assign it to you <0.7
wink>.

the-only-one-working-on-the-move-is-me-and-i-haven't-done-a-checkin-
    yet-anyway-ly y'rs  - tim





From mal at lemburg.com  Fri Jun 23 10:03:41 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 23 Jun 2000 10:03:41 +0200
Subject: [Python-Dev] Re: [Patches] Patch management (was: Warnings in pythonrun.c)
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>
Message-ID: <395319DD.F2584321@lemburg.com>

Tim Peters wrote:
> 
> > Worrying about patch management mechanism, while more patches pile up
> > and are ignored in the meantime, is not going to help and will just
> > results in continued stagnation.
> 
> At an all-hands PythonLabs group mtg today, it was decided to move patch
> activity to SourceForge and kill the patches list.  I'll send more about
> that later.  There is absolutely nothing new stopping checkins while the
> move to the SourceForge patch manager is in progress, so if the patches
> continue to pile up it's certainly not the move's fault.  If the pythonrun.c
> patch is still sitting untouched after the move, I'll assign it to you <0.7
> wink>.

But how are we going to discuss new patches from people outside
python-dev then ? I do see the use of moving patch submission
to SourceForge, but posting the patches on the list for
revision by everyone who listens is certainly better than
having to scan the patch manager entries... (push strategies
usually produce more feedback than pull ones).

A gateway from the patch manager to the patches list would
solve this nicely.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From Vladimir.Marangozov at inrialpes.fr  Fri Jun 23 12:00:23 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 23 Jun 2000 12:00:23 +0200 (CEST)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com> from "Skip Montanaro" at Jun 22, 2000 12:21:04 PM
Message-ID: <200006231000.MAA03550@python.inrialpes.fr>

Skip Montanaro wrote:
> 
> 
>     Guido> If I had designed this, I might have called the module "onexit"
>     Guido> or "atexit" and the public function simply "register()".  But
>     Guido> I've got only a +0 for my own proposal.  A +1 for the general
>     Guido> idea.
> 
> I'm happy to change things.  I was a bit curious if people would ask about
> such a common word for a new module name.  What module name do people
> prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not
> careful), or something else?
> 
> Skip

atexit.py

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From mal at lemburg.com  Fri Jun 23 12:08:46 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 23 Jun 2000 12:08:46 +0200
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
References: <200006231000.MAA03550@python.inrialpes.fr>
Message-ID: <3953372E.274907AB@lemburg.com>

Vladimir Marangozov wrote:
> 
> Skip Montanaro wrote:
> >
> >
> >     Guido> If I had designed this, I might have called the module "onexit"
> >     Guido> or "atexit" and the public function simply "register()".  But
> >     Guido> I've got only a +0 for my own proposal.  A +1 for the general
> >     Guido> idea.
> >
> > I'm happy to change things.  I was a bit curious if people would ask about
> > such a common word for a new module name.  What module name do people
> > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not
> > careful), or something else?
> >
> > Skip
> 
> atexit.py

How about exitfunc.py ? It would make the relation to sys.exitfunc
pretty clear.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From akuchlin at cnri.reston.va.us  Fri Jun 23 13:30:02 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Fri, 23 Jun 2000 07:30:02 -0400
Subject: [Python-Dev] Patch management 
In-Reply-To: <395319DD.F2584321@lemburg.com>; from mal@lemburg.com on Fri, Jun 23, 2000 at 10:03:41AM +0200
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com> <395319DD.F2584321@lemburg.com>
Message-ID: <20000623073002.B9385@newcnri.cnri.reston.va.us>

On Fri, Jun 23, 2000 at 10:03:41AM +0200, M.-A. Lemburg wrote:
>A gateway from the patch manager to the patches list would
>solve this nicely.

According to what was said to me, it's thought that mailing new
patches to an e-mail address is supported, and therefore setting up a

So, I no longer have much of a problem with moving patches to SF,
though I *still* think the mailing list would be sufficient with a bit
more focused effort; sorry, Tim!  But at least we're not going to burn
weeks looking at different patch manager products, and then arguing
about them, which is what I feared most.

--amk



From bwarsaw at python.org  Fri Jun 23 16:33:11 2000
From: bwarsaw at python.org (Barry A. Warsaw)
Date: Fri, 23 Jun 2000 10:33:11 -0400 (EDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
References: <14674.19200.325533.979792@beluga.mojam.com>
	<200006231000.MAA03550@python.inrialpes.fr>
Message-ID: <14675.29991.933911.446078@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:

    VM> atexit.py

+1



From gward at mems-exchange.org  Fri Jun 23 17:42:03 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Fri, 23 Jun 2000 11:42:03 -0400
Subject: [Python-Dev] RFC: Including PIL in 1.6
In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400
References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com>
Message-ID: <20000623114202.A1778@ludwig.cnri.reston.va.us>

On 20 June 2000, esr at thyrsus.com said:
> Watch that argument -- it could turn and bite you.  What's the justification
> for including, e.g. POP client classes in the standard distribution?
> 
> One of Python's most important strengths is the "batteries *are*
> included" richness of the standard environment.

I totally agree.  There are two extremes, both completely silly: include
nothing with Python (except string, re, os, and sys -- because Distutils
needs them ;-), and include every useful, working, documented module
under the sun.  I don't think anyone would seriously argue for either
approach.  (Although you could argue that a completely stripped-down
Python might be useful in certain environments, eg. a hand-held.  But I
don't think you'd win that argument.)

And I will be the first to admit that the Distutils still aren't good
enough: in most respects, they're better than MakeMaker (IMHO), but
there's nothing like CPAN.pm or the XEmacs package manager.  And I know
from personal experience that, amazing as CPAN.pm is, it's not The
Answer; and others have attested, that XEmacs is pretty damn good but
still not perfect.

But I still don't think PIL should be included in the core, if only
because it's one of the Distutils "test cases".  ;-)

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From gward at mems-exchange.org  Fri Jun 23 17:45:16 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Fri, 23 Jun 2000 11:45:16 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <39513E13.F8082811@prescod.net>; from paul@prescod.net on Wed, Jun 21, 2000 at 05:13:39PM -0500
References: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com> <39513E13.F8082811@prescod.net>
Message-ID: <20000623114516.B1778@ludwig.cnri.reston.va.us>

On 21 June 2000, Paul Prescod said:
> Is there an argument for putting in features with flaming red neon
> lights: "warning, experimental, use at your risk." We want to follow a
> bazaar (if not outright bizarre) development strategy after all. Putting
> a patch "out there" really doesn't do much about having people really
> play with and comment on a feature. I would never have experimented (and
> decided against using...) metaclasses if they hadn't popped up as an
> experimental feature.

Well, remember there will probably be a "--with-gc" option to the
configure script in 1.6.  That's a good example of getting an
experimental feature out there.

However, a "--with-list-comprehensions" option would be a really bad
idea; all of a sudden, it's no longer enough to say, "You need Python
1.6" to run this script/use this module, now you need to say, "You need
Python 1.6 built with list comprehensions".  Ugh.

Real language features should not be selectable: either the language is
Python 1.6 or it isn't.

       Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From akuchlin at cnri.reston.va.us  Fri Jun 23 17:54:02 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Fri, 23 Jun 2000 11:54:02 -0400
Subject: [Python-Dev] list comprehensions
In-Reply-To: <20000623114516.B1778@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Fri, Jun 23, 2000 at 11:45:16AM -0400
References: <LNBBLJKPBEHFEDALKOLCEEDPGFAA.tim_one@email.msn.com> <39513E13.F8082811@prescod.net> <20000623114516.B1778@ludwig.cnri.reston.va.us>
Message-ID: <20000623115402.B4805@amarok.cnri.reston.va.us>

On Fri, Jun 23, 2000 at 11:45:16AM -0400, Greg Ward wrote:
>idea; all of a sudden, it's no longer enough to say, "You need Python
>1.6" to run this script/use this module, now you need to say, "You need
>Python 1.6 built with list comprehensions".  Ugh.

The same argument applies to --with-gc, though, since people might
write code that creates cycles and needs GC to run without leaking
like a sieve.  Making GC optional is still the right solution, though,
because its performance effects are still unknown and might be costly.

--amk





From gvwilson at nevex.com  Fri Jun 23 18:09:36 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Fri, 23 Jun 2000 12:09:36 -0400 (EDT)
Subject: [Python-Dev] Re: list comprehensions / garbage collection / optional features
In-Reply-To: <20000623115402.B4805@amarok.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10006231159160.16185-100000@akbar.nevex.com>

> >Greg Ward wrote:

> >idea; all of a sudden, it's no longer enough to say, "You need Python
> >1.6" to run this script/use this module, now you need to say, "You need
> >Python 1.6 built with list comprehensions".  Ugh.

> Andrew Kuchling wrote:

> The same argument applies to --with-gc, though, since people might
> write code that creates cycles and needs GC to run without leaking
> like a sieve.  Making GC optional is still the right solution, though,
> because its performance effects are still unknown and might be costly.

Greg Wilson writes:

I'm really looking forward to recycling my rusty SETL idioms when list
comprehensions become part of the "official" release, and to creating
graphs in the obvious way if GC ever becomes standard.  However, the more
variations there are in the "standard" (as opposed to "developer")
release, the more expensive (in time and sweat) it is to manage Python at
large sites (like Los Alamos).  This in turn makes it harder to persuade
people that using Python will make their lives easier...

Thanks,

Greg

Footnote: The existence of JPython was one of the arguments in favor of
choosing Python for the Software Carpentry project. The fact that JPython
and CPython have very different memory management behaviors almost negated
that point: as one thirty-year veteran said, "It's no use having code that
runs in lots of places if it runs differently in each."




From nascheme at enme.ucalgary.ca  Fri Jun 23 19:12:51 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 23 Jun 2000 11:12:51 -0600
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects classobject.c,2.86,2.87 dictobject.c,2.52,2.53 funcobject.c,2.20,2.21 listobject.c,2.73,2.74 tupleobject.c,2.36,2.37
In-Reply-To: <200006231418.HAA02869@slayer.i.sourceforge.net>; from jhylton@users.sourceforge.net on Fri, Jun 23, 2000 at 07:18:13AM -0700
References: <200006231418.HAA02869@slayer.i.sourceforge.net>
Message-ID: <20000623111251.B10850@acs.ucalgary.ca>

On Fri, Jun 23, 2000 at 07:18:13AM -0700, Jeremy Hylton wrote:
> Round 1 of Neil Schemenauer's GC patches:

Yay.  :)

> + class_traverse(PyClassObject *o, visitproc visit, void *arg)
> + {
...
> + 	return 0;
> + }

> + instance_traverse(PyInstanceObject *o, visitproc visit, void *arg)
> + {
...
> + 	return 1;
> + }

Oops.  I think "return 0" is the proper thing to do.  There are a
few other functions that return 1 as well.

  Neil



From fdrake at acm.org  Fri Jun 23 20:08:06 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 23 Jun 2000 11:08:06 -0700 (PDT)
Subject: [Python-Dev] out of touch
Message-ID: <14675.42886.423185.310220@mailhost.beopen.com>

  My laptop has died, so I'm catching up with a couple of days of
mail.  I've not had time to look at Paul's proposed DOM-like additions
to the standard library.  Hopefully Andrew can (or has) summarized the
relevant portions of our discussion from yesterday; if I don't see it,
I'll try to get another message out later.  (But I don't have my saved
mail or files, so there's still not a lot I can do. ;( )


  -Fred


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




From fdrake at beopen.com  Fri Jun 23 21:04:55 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 23 Jun 2000 12:04:55 -0700 (PDT)
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com>
References: <14673.1591.506532.170015@beluga.mojam.com>
	<200006212255.RAA02444@cj20424-a.reston1.va.home.com>
	<14674.19200.325533.979792@beluga.mojam.com>
Message-ID: <14675.46295.836727.117258@mailhost.beopen.com>

Skip Montanaro writes:
 > I'm happy to change things.  I was a bit curious if people would ask about
 > such a common word for a new module name.  What module name do people
 > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not

  I like "atexit" better.


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>




From guido at python.org  Fri Jun 23 22:08:36 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 23 Jun 2000 15:08:36 -0500
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: Your message of "Fri, 23 Jun 2000 12:04:55 MST."
             <14675.46295.836727.117258@mailhost.beopen.com> 
References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> <14674.19200.325533.979792@beluga.mojam.com>  
            <14675.46295.836727.117258@mailhost.beopen.com> 
Message-ID: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>

> Skip Montanaro writes:
>  > I'm happy to change things.  I was a bit curious if people would ask about
>  > such a common word for a new module name.  What module name do people
>  > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not

[fred]
>   I like "atexit" better.

OK, let it be atexit.  I'm glad this time the naming debate is at
least civilized. :-)

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



From DavidA at ActiveState.com  Fri Jun 23 21:30:31 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 23 Jun 2000 12:30:31 -0700
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJIEMMCJAA.DavidA@ActiveState.com>

> OK, let it be atexit.  I'm glad this time the naming debate is at
> least civilized. :-)

No, wait, i think it should be exit_AT!

Actually, I'm sick of this english-centricity.  You american jerks are all
the same!  Go home Yankee!  It should be en_sortant or nothing at all!

--david "I try..." ascher




From nascheme at enme.ucalgary.ca  Fri Jun 23 22:11:03 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 23 Jun 2000 14:11:03 -0600
Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed
Message-ID: <20000623141103.A13079@acs.ucalgary.ca>

Has this been addressed yet for 1.6?  It is probably an easy fix.
The original poster claimed it took 4 seconds to start Python on
his machine.

  Neil

----- Forwarded message from Johannes Stezenbach <yawyi at gmx.de> -----

Date: Thu, 22 Jun 2000 15:03:01 +0200
From: yawyi at gmx.de (Johannes Stezenbach)
Subject: Re: Linux/NT python startup speed

Niklas Frykholm <r2d2 at mao.acc.umu.se> wrote:
>Can someone explain this difference. (The processor on the Linux system is
>certainly not 40 times faster.)

This was discussed here a few months ago. The reason for the slow
startup is the winsound module (source: PC/winsound.c) which is
unnecessarily a builtin.  winsound causes Python to load the
Windows multimedia DLLs, which can be slow if your sound drivers
make it so.

Two solutions were discussed:
a) make winsound a .pyd
b) use some obscure "delayload" feature of the M$ linker. There
   is a ready to use python15.dll for Python 1.5.2 with this
   feature somewhere out there (I don't remember where, though,
   since I use Linux now)

IMHO solution a) should be standard in Python 1.6 (it isn't in
1.6a2).

Johannes



----- End forwarded message -----



From tim_one at email.msn.com  Fri Jun 23 22:11:47 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 23 Jun 2000 16:11:47 -0400
Subject: [Python-Dev] updated exit.py and supporting files for your perusal
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJIEMMCJAA.DavidA@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEELLGFAA.tim_one@email.msn.com>

[Guido]
>> OK, let it be atexit.  I'm glad this time the naming debate is at
>> least civilized. :-)

{David Ascher]
> No, wait, i think it should be exit_AT!
>
> Actually, I'm sick of this english-centricity.  You american jerks are all
> the same!  Go home Yankee!  It should be en_sortant or nothing at all!

Oh, screw you and the frog you rode in, Frenchie.  Using an inferior
language is no excuse for poor grammar:  "exit at" reads like a freeway
sign, as in "Kentucky Fried Chicken, exit at 12B".  en_sortant is no
better -- worse, I have no idea what this has to do with arranging ants in
order (and what kind of algorithm is en_sort anyway?).
uponbutpriortoexiting is an idea that can't even be expressed in French, I
bet.

internationally y'rs  - tim





From guido at python.org  Fri Jun 23 23:49:05 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 23 Jun 2000 16:49:05 -0500
Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed
In-Reply-To: Your message of "Fri, 23 Jun 2000 14:11:03 CST."
             <20000623141103.A13079@acs.ucalgary.ca> 
References: <20000623141103.A13079@acs.ucalgary.ca> 
Message-ID: <200006232149.QAA03157@cj20424-a.reston1.va.home.com>

> Has this been addressed yet for 1.6?  It is probably an easy fix.
> The original poster claimed it took 4 seconds to start Python on
> his machine.

In 1.6, winsound is a separate subproject and hence a separately
loadable DLL, so it doesn't slow down the main code.  Ditto for
socket and a few others.

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




From jeremy at beopen.com  Sat Jun 24 00:01:19 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 23 Jun 2000 18:01:19 -0400
Subject: [Python-Dev] Python 1.6 planning
Message-ID: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>

We discussed plans for Python 1.6 at the all-hands PythonLabs staff meeting
yesterday.  (At this meeting, the PythonLabs staff closed ranks and agreed
to say that Tim Peters exists.)
I'd like to quickly summarize plans.

The target release date for Python 1.6 beta 1 is early July.  Any code that
is going to be in the beta must be checked in before July 1.

Tim Peters pushed us to take care of the patches backlog.  Our plan is to
close the patches list and move all patch management to Sourceforge.  We
know the list is broken; we don't know that Sourceforge is broken.

There are a bunch of modules and technical issues that must be resolved one
way or another.


SRE-- /F needs to finish this up.  Unanswered question is whether the beta
will ship with known bugs.

GC-- Neil's garbage collector will be shipped as experimental feature
requiring configure option.

XML-- Some parts of the XML package will be included in the library under
the xmlcore package.  SAX and DOM (provided that it is stable enough).
Andrew gets to decide, I believe.

List comprehensions -- Next release.  Despite the love fest at the meeting
(everyone seems to want them), there is no way an implementation will be
ready or stable enough.

httplib-- We will include Greg Stein's new httplib, provided that it
supports an old-style HTTPS class.

curses-- one return type needs to be implemented (5-tuple).  Andrew will
finish ASAP.  ESR's ascii module will be part of the curses package.

imputil-- The imputil module will be dropped in the std library to enable
wider distribution, but no changes will be made to the normal import
machinery.

Unicode shorthand-- Andrew will look at Bill Tutt's code. We intend to add
it.

Unicode compression-- We need to find out if Christian will be able to
provide a compressed database.

ldso_aix-- I still don't understand, but I didn't really try; Vladimir must
help

threads-- They will be on by default if the platform supports.

gettext-- Barry will check in his gettext module.

atexit.py-- add it

Jeremy





From nascheme at enme.ucalgary.ca  Sat Jun 24 00:22:50 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 23 Jun 2000 16:22:50 -0600
Subject: [Python-Dev] Python 1.6 planning
In-Reply-To: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400
References: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>
Message-ID: <20000623162250.A14311@acs.ucalgary.ca>

On Fri, Jun 23, 2000 at 06:01:19PM -0400, Jeremy Hylton wrote:
> threads-- They will be on by default if the platform supports.

Does the Linux thread/fork problem still exist?  It would be nice
to kill this before 1.6 final.  I will test this with the CVS
source this weekend.

  Neil



From skip at mojam.com  Sat Jun 24 03:09:04 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 23 Jun 2000 20:09:04 -0500
Subject: [Python-Dev] test failures...
Message-ID: <200006240109.UAA14738@beluga.mojam.com>

Using the latest CVS code, I get failures for three tests on my Linux
Mandrake 6.1 laptop:

  test test_exceptions failed -- Writing: 'spam', expected: 'Attr'
  test test_types crashed -- exceptions.OverflowError : long int too long to convert
  test test_long failed -- int(long(-sys.maxint-1)) overflowed!

Are these known/expected or unknown/unexpected failures?



From skip at mojam.com  Sat Jun 24 03:27:39 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 23 Jun 2000 20:27:39 -0500 (CDT)
Subject: [Python-Dev] atexit.py patch
Message-ID: <14676.3723.916135.602@beluga.mojam.com>

Here's the latest version of my exit module.  Per the earlier discussion,
the module has been renamed to atexit.py.  I also took the suggestion from
someone (Guido?) that the registration function be renamed to simply
"register".  Other than that everything else should be the same.

I'm only sending this to python-dev, operating under the assumption that the 
patches list is about to take a long vacation...

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: atexit.diff
Type: application/octet-stream
Size: 4402 bytes
Desc: atexit.py & doc
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000623/65cdf297/attachment-0001.obj>

From trentm at activestate.com  Sat Jun 24 04:19:23 2000
From: trentm at activestate.com (Trent Mick)
Date: Fri, 23 Jun 2000 19:19:23 -0700
Subject: [Python-Dev] test failures...
In-Reply-To: <200006240109.UAA14738@beluga.mojam.com>
References: <200006240109.UAA14738@beluga.mojam.com>
Message-ID: <20000623191923.A25730@activestate.com>

On Fri, Jun 23, 2000 at 08:09:04PM -0500, Skip Montanaro wrote:
> Using the latest CVS code, I get failures for three tests on my Linux
> Mandrake 6.1 laptop:
> 
>   test test_exceptions failed -- Writing: 'spam', expected: 'Attr'

Don't know about this one.

>   test test_types crashed -- exceptions.OverflowError : long int too long to convert

This is related to some conversion checking that I added a while back, I
believe.


>   test test_long failed -- int(long(-sys.maxint-1)) overflowed!
> 
Same thing. Potentially this *should* overflow and the test should expect
that.


Don't take my word on this right now, only looked quickly. I will look at it
this weekend (hopefully). Skip, I don't get the test failures, although I am
a few days behind Python-CVS. Are these very new failures? Could you provide
the verbose output from running these tests indepedently? Thanks.


Trent


-- 
Trent Mick
trentm at activestate.com



From tim_one at email.msn.com  Sat Jun 24 04:32:46 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 23 Jun 2000 22:32:46 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <200006240109.UAA14738@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEMEGFAA.tim_one@email.msn.com>

[Skip Montanaro]
> Using the latest CVS code, I get failures for three tests on my Linux
> Mandrake 6.1 laptop:
>
>   test test_exceptions failed -- Writing: 'spam', expected: 'Attr'
>   test test_types crashed -- exceptions.OverflowError : long int
> too long to convert
>   test test_long failed -- int(long(-sys.maxint-1)) overflowed!
>
> Are these known/expected or unknown/unexpected failures?

First two don't ring a bell, last one has shown up several times & each time
traced to an optimization bug, usually in a particular older version of gcc.
Recompile with optimization off and see whether that makes all of them go
away.  If so, try using a recent gcc.





From tim_one at email.msn.com  Sat Jun 24 04:41:23 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 23 Jun 2000 22:41:23 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <20000623191923.A25730@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEMFGFAA.tim_one@email.msn.com>

>>   test test_types crashed -- exceptions.OverflowError : long
>> int too long to convert

> This is related to some conversion checking that I added a while back, I
> believe.

Possible but doubt it.

>>   test test_long failed -- int(long(-sys.maxint-1)) overflowed!

> Same thing. Potentially this *should* overflow and the test should expect
> that.

Definitely not on this one:  sys.maxint is by defn the largest positive
Python int, so on any 2's-comp machine -sys.maxint-1 should be a legit
Python int too.  This bogus failure has popped up due to compiler
optimization bugs under at least two older different compilers, though (gcc
being by far the more often reported culprit -- I think the other was one of
those HP compilers that seems to generate more bad code than good <0.3
wink>).

The first step in test failures like this is to recompile with optimization
off.





From skip at mojam.com  Sat Jun 24 05:45:04 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 23 Jun 2000 22:45:04 -0500 (CDT)
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEMEGFAA.tim_one@email.msn.com>
References: <200006240109.UAA14738@beluga.mojam.com>
	<LNBBLJKPBEHFEDALKOLCMEMEGFAA.tim_one@email.msn.com>
Message-ID: <14676.11968.263924.752216@beluga.mojam.com>

    >> test test_exceptions failed -- Writing: 'spam', expected: 'Attr'
    >> test test_types crashed -- exceptions.OverflowError : long int too long to convert
    >> test test_long failed -- int(long(-sys.maxint-1)) overflowed!

    Tim> First two don't ring a bell, last one has shown up several times &
    Tim> each time traced to an optimization bug, usually in a particular
    Tim> older version of gcc.  Recompile with optimization off and see
    Tim> whether that makes all of them go away.  If so, try using a recent
    Tim> gcc.

Turning off optimization got rid of the test_types and test_long failures.
The test_exceptins failure remains.  Here's a diff:

    diff test_exceptions.save test_exceptions
    2a3
    > spam
    3a5
    > spam
    4a7
    > spam
    5a9
    > spam
    6a11
    > spam
    7a13
    > spam
    8a15
    > spam
    10a18
    > spam
    12a21
    > spam
    13a23
    > spam
    14a25
    > spam
    16a28
    > spam
    17a30
    > spam
    19a33
    > spam
    20a35
    > spam
    21a37
    > spam
    22a39
    > spam
    23a41
    > spam

I'm not sure what that means, but it seems consistent. ;-)

As for the age of my gcc, I think I'm reasonably current (only a bit over a
year old):

    % gcc -v
    Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs
    gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)

I will try downloading a newer RPM.

Skip



From ping at lfw.org  Sat Jun 24 08:08:42 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Sat, 24 Jun 2000 01:08:42 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your
 perusal
In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>

On Fri, 23 Jun 2000, Guido van Rossum wrote:
> [fred]
> >   I like "atexit" better.
> 
> OK, let it be atexit.  I'm glad this time the naming debate is at
> least civilized. :-)

Sorry to confuddle things, but what happened to the idea of
sticking it in "sys"?  If sys.exitfunc lives there, doesn't
sys.atexit(...) also make sense?  It can't be very hard to do...


-- ?!ng




From guido at python.org  Sat Jun 24 18:03:07 2000
From: guido at python.org (Guido van Rossum)
Date: Sat, 24 Jun 2000 11:03:07 -0500
Subject: [Python-Dev] test failures...
In-Reply-To: Your message of "Fri, 23 Jun 2000 20:09:04 EST."
             <200006240109.UAA14738@beluga.mojam.com> 
References: <200006240109.UAA14738@beluga.mojam.com> 
Message-ID: <200006241603.LAA05123@cj20424-a.reston1.va.home.com>

>   test test_exceptions failed -- Writing: 'spam', expected: 'Attr'

There's a "print buf" at the end of the new function
test_raise_catch() that causes this.  Jeremy added this; either the
"print buf" shouldn't be there, or the file
Lib/test/output/test_exceptions should be updated.  It's up to Jeremy
now.

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




From skip at mojam.com  Sat Jun 24 17:11:18 2000
From: skip at mojam.com (Skip Montanaro)
Date: Sat, 24 Jun 2000 10:11:18 -0500 (CDT)
Subject: [Python-Dev] updated exit.py and supporting files for your
 perusal
In-Reply-To: <Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
	<Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
Message-ID: <14676.53142.263320.435588@beluga.mojam.com>

    Ping> Sorry to confuddle things, but what happened to the idea of
    Ping> sticking it in "sys"?  If sys.exitfunc lives there, doesn't
    Ping> sys.atexit(...) also make sense?  It can't be very hard to do...

I like the general idea that stuff implemented in C is just a thin interface
layer on top of existing system services and that higher level protocols are
implemented in Python where there's no overriding need for them to be
written in C.  This fits that model, at least to a first approximation.  The
sys.exitfunc variable functions pretty much like calling the atexit(3)
library call (though that's not how sys.exitfunc is implemented), and the
atexit module provides a protocol that dictates how that mechanism is used
in a cooperative setting.

There's almost certainly no performance reason this code should be
implemented in C.  It's going to be easier to maintain and enhance if
written in Python, and won't add size to the interpreter for those
programmers who don't use it (or don't use other modules that do).

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From nascheme at enme.ucalgary.ca  Sat Jun 24 18:04:18 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Sat, 24 Jun 2000 10:04:18 -0600
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEMFGFAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Fri, Jun 23, 2000 at 10:41:23PM -0400
References: <20000623191923.A25730@activestate.com> <LNBBLJKPBEHFEDALKOLCMEMFGFAA.tim_one@email.msn.com>
Message-ID: <20000624100418.A20411@acs.ucalgary.ca>

On Fri, Jun 23, 2000 at 10:41:23PM -0400, Tim Peters wrote:
> The first step in test failures like this is to recompile with
> optimization off.

Mandrake is known for shipping bad compilers.  They used to ship
pgcc as the default compiler even though it was know to have a
lot of problems.

  Neil



From tim_one at email.msn.com  Sat Jun 24 19:27:19 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:27:19 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <14676.11968.263924.752216@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>

[Skip Montanaro]
> Turning off optimization got rid of the test_types and test_long failures.
> The test_exceptins failure remains.

Bingo, and Guido pinned test_exceptions on Jeremy.  You can likely get a
usable Python by disabling optimization only for longobject.c, if for some
reason you need to stick with that compiler.

> As for the age of my gcc, I think I'm reasonably current (only a
> bit over a year old):
>
>     % gcc -v
>     Reading specs from
> /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs
>     gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)

Well, I haven't had need of following the gcc/egcs soap opera, but I think
"a year" (& particularly the last one <wink>) is a lifetime in that saga.
"2.95" rings a vague bell, as the only compiler in that line my former
employer felt was usable for their development work under Linux.

unlike-python-so-far-they've-had-some-bad-releases-ly y'rs  - tim





From tim_one at email.msn.com  Sat Jun 24 19:30:54 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:30:54 -0400
Subject: [Python-Dev] atexit.py patch
In-Reply-To: <14676.3723.916135.602@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEMKGFAA.tim_one@email.msn.com>

[Skip]
> I'm only sending this to python-dev, operating under the
> assumption that the  patches list is about to take a long vacation...

Skip, if you can't put it on SourceForge for some reason (like what?), the
patches list is certainly better than python-dev!  I've got enough to do
trying to disentangle multi-megabytes of patches-list archives that I'm not
going to expand my search to other archives (like python-dev) too.





From gstein at lyra.org  Sat Jun 24 19:39:34 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 24 Jun 2000 10:39:34 -0700
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:27:19PM -0400
References: <14676.11968.263924.752216@beluga.mojam.com> <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>
Message-ID: <20000624103934.Y29590@lyra.org>

On Sat, Jun 24, 2000 at 01:27:19PM -0400, Tim Peters wrote:
> [Skip Montanaro]
> > Turning off optimization got rid of the test_types and test_long failures.
> > The test_exceptins failure remains.
> 
> Bingo, and Guido pinned test_exceptions on Jeremy.  You can likely get a
> usable Python by disabling optimization only for longobject.c, if for some
> reason you need to stick with that compiler.

Euh... shouldn't we insert some defensive code into longobject.c? Great,
Skip knows to disable opt for that file... what about all the other people?

Cheers,
-g

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



From tim_one at email.msn.com  Sat Jun 24 19:42:29 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:42:29 -0400
Subject: [Python-Dev] Patch management 
In-Reply-To: <20000623073002.B9385@newcnri.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMLGFAA.tim_one@email.msn.com>

[Andrew Kuchling]
> ...
> So, I no longer have much of a problem with moving patches to SF,
> though I *still* think the mailing list would be sufficient with a bit
> more focused effort; sorry, Tim!

"Do something" to supply that focus on this mailing list, and then I can
stop bothering with the move.  That would be great.  But repeating that if
the list worked, it wouldn't be broken <0.7 wink>, has not proven sufficient
to fix it.

> But at least we're not going to burn weeks looking at different patch
> manager products, and then arguing about them, which is what I feared
> most.

Same here.

well-actually-the-radio-on-the-drive-down-to-va-got-me-more-worried-
    about-lyme-disease-ly y'rs  - tim






From tim_one at email.msn.com  Sat Jun 24 19:51:14 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sat, 24 Jun 2000 13:51:14 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <20000624103934.Y29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMMGFAA.tim_one@email.msn.com>

[Greg Stein]
> Euh... shouldn't we insert some defensive code into longobject.c? Great,
> Skip knows to disable opt for that file... what about all the
> other people?

Don't understand what you want to see.  The compiler in question is both
broken & old.  At most I'd put a note in one of the readmes saying so.





From fdrake at beopen.com  Sat Jun 24 23:19:50 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Sat, 24 Jun 2000 14:19:50 -0700 (PDT)
Subject: [Python-Dev] updated exit.py and supporting files for your
 perusal
In-Reply-To: <Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com>
	<Pine.LNX.4.10.10006240106220.28051-100000@server1.lfw.org>
Message-ID: <14677.9718.880695.265962@mailhost.beopen.com>

Ka-Ping Yee writes:
 > Sorry to confuddle things, but what happened to the idea of
 > sticking it in "sys"?  If sys.exitfunc lives there, doesn't
 > sys.atexit(...) also make sense?  It can't be very hard to do...

  I'd be happy with this as well, but I don't think it's required to
do it that way.


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>




From gstein at lyra.org  Sun Jun 25 00:18:24 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 24 Jun 2000 15:18:24 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37
In-Reply-To: <200006242040.NAA28315@slayer.i.sourceforge.net>; from gward@users.sourceforge.net on Sat, Jun 24, 2000 at 01:40:05PM -0700
References: <200006242040.NAA28315@slayer.i.sourceforge.net>
Message-ID: <20000624151824.A29590@lyra.org>

Would the "shlex" module be helpful here? It is in the standard library and
is (well?) maintained by ESR. It could help reduce the code inside
distutils.
[ I've always questioned the need for distutils' own "copy file" functions
  and whatnot... seems there is a bit of duplication occurring... ]

Cheers,
-g

On Sat, Jun 24, 2000 at 01:40:05PM -0700, Greg Ward wrote:
> Update of /cvsroot/python/distutils/distutils
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv28287
> 
> Modified Files:
> 	util.py 
> Log Message:
> Added 'split_quoted()' function to deal with strings that are quoted in 
> Unix shell-like syntax (eg. in Python's Makefile, for one thing -- now that
> I have this function, I'll probably allow quoted strings in config files too.
> 
> Index: util.py
> ===================================================================
> RCS file: /cvsroot/python/distutils/distutils/util.py,v
> retrieving revision 1.36
> retrieving revision 1.37
> diff -C2 -r1.36 -r1.37
> *** util.py	2000/06/18 15:45:55	1.36
> --- util.py	2000/06/24 20:40:02	1.37
> ***************
> *** 167,168 ****
> --- 167,235 ----
>   
>       return error
> + 
> + 
> + # Needed by 'split_quoted()'
> + _wordchars_re = re.compile(r'[^\\\'\"\ ]*')
> + _squote_re = re.compile(r"'(?:[^'\\]|\\.)*'")
> + _dquote_re = re.compile(r'"(?:[^"\\]|\\.)*"')
> + 
> + def split_quoted (s):
> +     """Split a string up according to Unix shell-like rules for quotes and
> +     backslashes.  In short: words are delimited by spaces, as long as those
> +     spaces are not escaped by a backslash, or inside a quoted string.
> +     Single and double quotes are equivalent, and the quote characters can
> +     be backslash-escaped.  The backslash is stripped from any two-character
> +     escape sequence, leaving only the escaped character.  The quote
> +     characters are stripped from any quoted string.  Returns a list of
> +     words.
> +     """
> + 
> +     # This is a nice algorithm for splitting up a single string, since it
> +     # doesn't require character-by-character examination.  It was a little
> +     # bit of a brain-bender to get it working right, though...
> + 
> +     s = string.strip(s)
> +     words = []
> +     pos = 0
> + 
> +     while s:
> +         m = _wordchars_re.match(s, pos)
> +         end = m.end()
> +         if end == len(s):
> +             words.append(s[:end])
> +             break
> + 
> +         if s[end] == ' ':               # unescaped, unquoted space: now
> +             words.append(s[:end])       # we definitely have a word delimiter
> +             s = string.lstrip(s[end:])
> +             pos = 0
> + 
> +         elif s[end] == '\\':            # preserve whatever is being escaped;
> +                                         # will become part of the current word
> +             s = s[:end] + s[end+1:]
> +             pos = end+1
> + 
> +         else:
> +             if s[end] == "'":           # slurp singly-quoted string
> +                 m = _squote_re.match(s, end)
> +             elif s[end] == '"':         # slurp doubly-quoted string
> +                 m = _dquote_re.match(s, end)
> +             else:
> +                 raise RuntimeError, \
> +                       "this can't happen (bad char '%c')" % s[end]
> + 
> +             if m is None:
> +                 raise ValueError, \
> +                       "bad string (mismatched %s quotes?)" % s[end]
> + 
> +             (beg, end) = m.span()
> +             s = s[:beg] + s[beg+1:end-1] + s[end:]
> +             pos = m.end() - 2
> + 
> +         if pos >= len(s):
> +             words.append(s)
> +             break
> + 
> +     return words
> + 
> + # split_quoted ()
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From gstein at lyra.org  Sun Jun 25 00:50:23 2000
From: gstein at lyra.org (Greg Stein)
Date: Sat, 24 Jun 2000 15:50:23 -0700
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEMMGFAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:51:14PM -0400
References: <20000624103934.Y29590@lyra.org> <LNBBLJKPBEHFEDALKOLCAEMMGFAA.tim_one@email.msn.com>
Message-ID: <20000624155023.B29590@lyra.org>

On Sat, Jun 24, 2000 at 01:51:14PM -0400, Tim Peters wrote:
> [Greg Stein]
> > Euh... shouldn't we insert some defensive code into longobject.c? Great,
> > Skip knows to disable opt for that file... what about all the
> > other people?
> 
> Don't understand what you want to see.  The compiler in question is both
> broken & old.  At most I'd put a note in one of the readmes saying so.

The compiler Skip quoted was pgcc-2.91.66. The "pgcc" part may have
introduced the problem, but my RedHat 6.2 (i.e. the LATEST) has the
following:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)


Maybe 2.91.66 is "old" but that is the compiler being shipped on RedHat 6.2.

Having said that, I bet the pgcc people messed up the compiler :-). I set
-O9 on my box and recompiled longobject.c. It wouldn't reproduce the problem.

Cheers,
-g

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



From gmcm at hypernet.com  Sun Jun 25 01:01:05 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Sat, 24 Jun 2000 19:01:05 -0400
Subject: [Python-Dev] test failures...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEMJGFAA.tim_one@email.msn.com>
References: <14676.11968.263924.752216@beluga.mojam.com>
Message-ID: <1250234786-20097552@hypernet.com>

Tim "The Windows Guy" Peters wrote:

> [Skip Montanaro]
> > /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs
> >     gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)
> 
> Well, I haven't had need of following the gcc/egcs soap opera,
> but I think "a year" (& particularly the last one <wink>) is a
> lifetime in that saga.

gcc 2.90 (egcs 1.0.3) that came with RH 5.2 was broken - but 
got fixed by rebuilding it from source.

- Gordon



From gstein at lyra.org  Sun Jun 25 10:40:23 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 25 Jun 2000 01:40:23 -0700
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache]
Message-ID: <20000625014023.D29590@lyra.org>

Woah... this is an interesting factoid about the number of committers for a
project. I had no idea PHP had this many...

Can this work with Python? Dunno. I think if a "true core" group pays
attention to the -checkins alias, then yah. If that review is ever lost,
then those "edge" committers could introduce crap.

I'm not asking for more committers to Python. But if some people were
worried about the "explosion" of committers from about six a couple months
ago to the current 13, then just look to PHP and count your thanks :-)
Mostly, this email is for pondering...

Cheers,
-g

----- Forwarded message from Rasmus Lerdorf <rasmus at apache.org> -----

Reply-To: members at apache.org
Date: Sat, 24 Jun 2000 20:52:01 -0700 (PDT)
From: Rasmus Lerdorf <rasmus at apache.org>
To: members at apache.org
Subject: Re: PMCs and Apache

> More relevant is the process by which I became a contributor.  For PHP, I
> sent a note describing what I was exploring, and I was sent a note with a
> password.  I didn't know CVS.  I didn't know PHP.  I didn't know open
> source.  But like a stranger offering to help at a barn raising, I was
> simply handed a hammer and expected to get busy.

That has always been the atmosphere.  It isn't quite as free as that.  We
get 10-20 cvs write account requests every week and tend to only hand out
1 or 2 actual accounts.  There are a lot of clueless people out there.  
However, if the person has shown any sign of being competent by explaining
in a rational manner what they plan on working on, I see no reason not to
let them bash away.  Reversing somebodys' changes and removing a cvs
account is trivial, and in the past 5 years we have yet to revoke an
account.  We have reversed changes of course, but even that doesn't happen
too often.

There are currently 165 people with write access to the PHP source tree.

This does also relate to the fact that the PHP project is a very broad
project.  No single person could possibly know all 16 supported low-level
database apis, for example.  

For other projects with a much more limited scope, this approach is
probably not optimal, but for PHP it works nicely.  Someone will write a
bit of broken code that shows some good ideas, and others will pounce on
it and fix it.  Often the people who fix it are poor sods who tried to use
the broken feature and had to dive in and fix it themselves.  They request
a cvs account to do this, and they are hooked.  They tend to never stop at
fixing just one thing once they have been given the golden keys.

This approach has also done wonders for the PHP documentation.  The
current manual is around 1100 pages long and has been fully translated to
German, Italian and Japanese with more languages on the way.  (check out
http://snaps.php.net/manual/)

-Rasmus

----- End forwarded message -----

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



From gstein at lyra.org  Mon Jun 26 01:20:43 2000
From: gstein at lyra.org (Greg Stein)
Date: Sun, 25 Jun 2000 16:20:43 -0700
Subject: [Python-Dev] Python/Apache stuff (was: Re: [XML-SIG] speed question re DOM parsing)
In-Reply-To: <200006251540.JAA13556@localhost.localdomain>; from uogbuji@fourthought.com on Sun, Jun 25, 2000 at 09:40:59AM -0600
References: <gstein@lyra.org> <200006251540.JAA13556@localhost.localdomain>
Message-ID: <20000625162043.J29590@lyra.org>

On Sun, Jun 25, 2000 at 09:40:59AM -0600, Uche Ogbuji wrote:
> Greg Stein:
> > When could I get to it? eek. I *will*, but dunno when. It is amazing just
> > how much stuff can fall on a person's plate despite having no job :-). I've
> > got some layered I/O in Apache, mod_dav integration, a new httplib, imputil
> > issues, these qp_xml upgrades, ViewCVS stuff, edna releases, free threading
> > changes, Python/Apache integration, and coding for Subversion. Fuggin
> > frightening.
> 
> Ooh!  Ooh!  Can you tell us more about the Python/Apache integration item?  
> We've been discussing distributing a 4Suite kit bundled with PyApache, but 
> that package is quite complex and I'm not sure how strongly maintained.  Are 
> you talking about improvements to PyApache?  Another approach entirely 
> (PyApache still has much more overhead than, say mod_perl)?  Do you have an 
> approximate time-line?  A project URL?

There are several Python/Apache efforts (where Python is embedded into the
Apache process):

*) PyApache: essentially this is just a CGI accelerator. Take a standard CGI
   script and it will "run faster."
   (URL? dunno)

*) mod_python: similar to mod_perl. Built for Apache 1.3. Despite its
   version 2.4, it is still a bit rough. I've been working with the author
   to improve the code. I did a code review a while back with a lot of
   suggestions. It is reasonable, but not as mature as mod_perl.
   http://www.modpython.org/

*) mod_snake: obvious misnomer :-). This is a module built for Apache 2.0,
   with the intent of making use of Apache 2.0's threadedness (plus a few of
   A2's other internal features). The code is very good looking.
   - available at SourceForge

*) mod_slimpy: my name for an Apache 2.0 module which will be even lighter
   weight than mod_snake. There will be only the slimmest layer of C code to
   interface Apache and Python. Most/all operational logic will be deferred
   to the Python side. I've used this design to good effect in some of the
   Python/COM work and its univgw package in particular.

Obviously, the latter two will compete, but oh well :-). The first two fit
their problem environment without particular complications.

When I start the mod_slimpy work, I'm also going to push on setting up
python.apache.org. Essentially, it will host (under the ASF umbrella) the
mod_slimpy work plus any other efforts that may want to operate there. I'm
going to ask the authors of the other packages whether they would like to be
hosted there, too.

Of course, python.apache.org can host any Python project. It doesn't have to
be related to the web server, or any other ASF project for that matter.
Consider all the non-web stuff that operates under xml.apache.org,
java.apache.org, and jakarta.apache.org.

Cheers,
-g

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



From Vladimir.Marangozov at inrialpes.fr  Mon Jun 26 13:33:56 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Mon, 26 Jun 2000 13:33:56 +0200 (CEST)
Subject: [Python-Dev] Fw: Access violation when no memory
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au> from "Mark Hammond" at Jun 20, 2000 09:42:53 PM
Message-ID: <200006261133.NAA03073@python.inrialpes.fr>

Mark Hammond wrote:
> 
> >From the newsgroup.  Any thoughts?
> 
> Mark.
> 
> "Phil Mayes" <nospam at bitbucket.com> wrote in message
> news:<olD35.82$_%.4481 at newsfeed.avtel.net>...
> > The following program progressively allocates all memory:
> >     size = 1 << 20
> >     list = [None,]
> >     while size:
> >         try:
> >             mem = [None] * size
> >             mem[0] = list
> >             list = mem
> >         except:
> >             size = size / 2
> >
> > It fails with an access violation.  (Turn off virtual memory
> > to provoke it.)

I had a closer look at this report. It revealed a buglet in Instance_New
and raises a question on how to handle the possible NULL values pushed
on the stack in ceval.c, at the exception handling code block:

> > 3. the NULL pointer at tb is pushed here:
> >      ceval.c line 1816:    PUSH(tb);
> >      ceval.c line 1817:    PUSH(val);
> >      ceval.c line 1818:    PUSH(exc);

1. In PyInstance_New, when the inst->in_dict allocation fails, there's
   a DECREF(inst) which triggers the instance_dealloc function. The latter
   goes on checking whether __del__ is defined in the instance's dict
   (by calling getattr2) whithout checking first whether inst->in_dict
   is not NULL. I.e. the dealloc_function assumes the instance has been
   initialized successfully. The net effect is a segfault in PyDict_GetItem
   which is called with a NULL dict.

   There are two possible fixes, and I'm not sure which one is better:

   a) Fix the Instance_New code, by freeing the instance on inst->in_dict
      allocation failure (without decref'ing the instance).

   b) Fix the dealloc code, by checking whether in_dict is not NULL
      before proceeding with the __del__ finalization logic.

   Opinions?

2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on
   low-memory conditions. They are pushed on the stack, then popped with
   a segfault.  The only reasonable behavior I get, after some testing,
   is by setting the tb and exc to Py_None if any of them is NULL before
   pushing them onto the stack. The program succeeds or the process is
   killed by the OS (tested on Linux).

   However, I'm not sure that setting tb and/or exc to Py_None, if NULL,
   makes any sense and won't cause side effects.

   Any other suggestions?

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From guido at python.org  Mon Jun 26 16:49:11 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 09:49:11 -0500
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Fri, 23 Jun 2000 10:03:41 +0200."
             <395319DD.F2584321@lemburg.com> 
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>  
            <395319DD.F2584321@lemburg.com> 
Message-ID: <200006261449.JAA01684@cj20424-a.reston1.va.home.com>

It's official: I've changed the patch submission guidelines
(http://www.python.org/patches/) to point to the patch manager at
SourceForge.  We are no longer bound by CNRI's legal department, so
the requirement for disclaimers or wet signatures is gone.

We'll have to see how it works in practice.  I've set the address
where new patches are mailed to patches at python.org; this should send
notifications to the patches list.  We could change this to python-dev
perhaps, so we can retire the patches address completely (giving it an
auto-respond pointing to the SF patch manager, as barry suggested).

There are several tasks to be assigned now: we need a triage person
who should go through the list of new patches regularly to assign them
to developers; we need developers who are willing to have patches
assigned to them.

We also need a consensus process to decide which patches will be
allowed through.  I'm hoping to experiment with SF in the coming days
to come up with something.

Finally, we still need to do something about the existing backlog of
patches.  The PythonLabs team will try to do something reasonable
here.

This is not the end -- it's the beginning!

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



From jack at oratrix.nl  Mon Jun 26 16:29:05 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Mon, 26 Jun 2000 16:29:05 +0200
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] 
In-Reply-To: Message by Greg Stein <gstein@lyra.org> ,
	     Sun, 25 Jun 2000 01:40:23 -0700 , <20000625014023.D29590@lyra.org> 
Message-ID: <20000626142906.1DDBD37186E@snelboot.oratrix.nl>

> Woah... this is an interesting factoid about the number of committers for a
> project. I had no idea PHP had this many...
> 
> Can this work with Python? Dunno. I think if a "true core" group pays
> attention to the -checkins alias, then yah. If that review is ever lost,
> then those "edge" committers could introduce crap.

This is one of the reasons I never asked for committer status: the fewer 
people doing commits the better. I can live with the <2days delay we had upto 
recently, and for now I'm expecting it to go down to that again after all the 
turmoil is over.
--
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 guido at python.org  Mon Jun 26 17:43:38 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 10:43:38 -0500
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache]
In-Reply-To: Your message of "Mon, 26 Jun 2000 16:29:05 +0200."
             <20000626142906.1DDBD37186E@snelboot.oratrix.nl> 
References: <20000626142906.1DDBD37186E@snelboot.oratrix.nl> 
Message-ID: <200006261543.KAA02198@cj20424-a.reston1.va.home.com>

[Jack Jansen]
> This is one of the reasons I never asked for committer status: the
> fewer people doing commits the better. I can live with the <2days
> delay we had upto recently, and for now I'm expecting it to go down
> to that again after all the turmoil is over.

Actually, I'd be glad to give you committer status (your colleague
Sjoerd just got his :-).  I expect that the majority of the
subscribers to python-dev can be trusted as committers.

I fully expect that most committers won't be committing much -- I
don't expect a frenzy of work by committers on the source tree.
However the committer status offloads the responsibility of applying
the patches you submit after they have been approved -- you can now do
it yourself.  Less work for me and the others here at PythonLabs!

BTW, I would heartily recommend putting the Macintosh tree for Python
under SourceForge!

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



From mal at lemburg.com  Mon Jun 26 17:03:30 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 26 Jun 2000 17:03:30 +0200
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>  
	            <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
Message-ID: <395770C2.B903724A@lemburg.com>

Guido van Rossum wrote:
> 
> It's official: I've changed the patch submission guidelines
> (http://www.python.org/patches/) to point to the patch manager at
> SourceForge.  We are no longer bound by CNRI's legal department, so
> the requirement for disclaimers or wet signatures is gone.
> 
> We'll have to see how it works in practice.  I've set the address
> where new patches are mailed to patches at python.org; this should send
> notifications to the patches list.  We could change this to python-dev
> perhaps, so we can retire the patches address completely (giving it an
> auto-respond pointing to the SF patch manager, as barry suggested).

Will there be a list which gets the patches mailed to it
by SF ?

I'm just asking because the current setup of having the patches
available through mail really helps in discussing patch details.
 
> There are several tasks to be assigned now: we need a triage person
> who should go through the list of new patches regularly to assign them
> to developers; we need developers who are willing to have patches
> assigned to them.

I'll volunteer for the Unicode side of things :-)

> We also need a consensus process to decide which patches will be
> allowed through.  I'm hoping to experiment with SF in the coming days
> to come up with something.
> 
> Finally, we still need to do something about the existing backlog of
> patches.  The PythonLabs team will try to do something reasonable
> here.
> 
> This is not the end -- it's the beginning!

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jack at oratrix.nl  Mon Jun 26 17:13:54 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Mon, 26 Jun 2000 17:13:54 +0200
Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] 
In-Reply-To: Message by Guido van Rossum <guido@python.org> ,
	     Mon, 26 Jun 2000 10:43:38 -0500 , <200006261543.KAA02198@cj20424-a.reston1.va.home.com> 
Message-ID: <20000626151355.3EF8C37186E@snelboot.oratrix.nl>

> Actually, I'd be glad to give you committer status (your colleague
> Sjoerd just got his :-).  I expect that the majority of the
> subscribers to python-dev can be trusted as committers.

Oww, grumble grumble... Okay, I'll apply for committer status. So there.

> BTW, I would heartily recommend putting the Macintosh tree for Python
> under SourceForge!

I don't think MacCVS can do ssh authorization, and if I followed the 
discussion here that is needed, right? But if that hurdle can be taken: fine!
--
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 guido at python.org  Mon Jun 26 18:32:37 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 11:32:37 -0500
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Mon, 26 Jun 2000 17:03:30 +0200."
             <395770C2.B903724A@lemburg.com> 
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com> <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com>  
            <395770C2.B903724A@lemburg.com> 
Message-ID: <200006261632.LAA02506@cj20424-a.reston1.va.home.com>

[MAL]
> Will there be a list which gets the patches mailed to it
> by SF ?
> 
> I'm just asking because the current setup of having the patches
> available through mail really helps in discussing patch details.

I don't think this feature is part of the SF Patch Manager just yet.
You could submit it as a request to the SF PM developers though --
apparently they're still working on it.

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



From paul at prescod.net  Mon Jun 26 17:43:31 2000
From: paul at prescod.net (Paul Prescod)
Date: Mon, 26 Jun 2000 08:43:31 -0700
Subject: [Python-Dev] winreg
Message-ID: <39577A23.EF7DE922@prescod.net>

[I'm having mail troubles so my response time may be slow...]

I've just had a chance to look at the winreg module. I think that it is
too low-level. I wrote a wrapper class that I feel is more Pythonic.
I'll outline the basic ideas and then if there is interest I'll develop
a test suite and send it out for eyeballing by Mark and others. Yes, I
am proposing this for 1.6. If we're going to put in a registry module,
it should be as Pythonic as possible.

First, about Winreg 1:

It was perfect when it was part of the win32 package and was supposed to
mirror the win32 APIs exactly (for reasons of documentation and
familiarity) but as the "standard" Python registry manipulation module
it seems too low-level to me.

I'm sure Mark would be the first to admit that it isn't very Pythonic.
It's more Microsoft-ic. In one part of the docs he says: "this API is
lame, lame, lame. Don't use it." :) 

There are also bogus parameters that Microsoft hasn't got around to
assigning values to, undocumented constants and so forth. My favorite is
"WHOLE_HIVE_VOLATILE".

Winreg 2:

The basic idea in the pythonic wrapper is that there are key "objects"
rather than just handles. winreg already has a primtive "handle object"
but for some reason most of the stuff that would logically be methods
are actually functions that take the handle as the first param.

Keys can have subkeys. So in winreg 1 you would say:

winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE,
"HARDWARE"), "DESCRIPTION" )

now you say:

winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey(
"DESCRIPTION" )

(you could also use a path syntax in either case)

You can get a complete list of existant subkeys with a getSubkeys()
method call. This list behaves like a Python mapping and also like a
sequence. You can use either string key names or integer ordinal
indexes. You can fetch and delete keys based on those indexes:

for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys():
	dosomething( key )

Before it was something like this:

for index in xrange( 0, sys.maxint ):
	try:
		dosomething( winreg.EnumKey( index ) )
	except WindowsError:
		break

"Values" (in the Microsoft sense) are handled the same basic way.
Looping, deleting, etc. is the same.

When you fetch a value, you get a (type,value) tuple. Types are objects
with properties:

typeobj.intval -> 0..10
typeobj.msname -> REG_SZ, REG_SZ_MULTI, ...
typeobj.friendlyname -> "String", "Sting List", ...

Type coercions are all done by the underlying module (the old winreg)
except that I've decided that binary data should be returned as an
array.array('c') rather than an 8-bit string.

-- 
 Paul Prescod
Out of timber so crooked as that which man is made nothing entirely
straight can be built. - Immanuel Kant



From fdrake at beopen.com  Mon Jun 26 18:04:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT)
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395770C2.B903724A@lemburg.com>
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>
	<395319DD.F2584321@lemburg.com>
	<200006261449.JAA01684@cj20424-a.reston1.va.home.com>
	<395770C2.B903724A@lemburg.com>
Message-ID: <14679.32536.133849.573542@mailhost.beopen.com>

M.-A. Lemburg writes:
 > Will there be a list which gets the patches mailed to it
 > by SF ?

  patches at python.org should get messages of patch manager activity (at
least certain actions; not sure which ones yet, but at least
additions).

 > I'm just asking because the current setup of having the patches
 > available through mail really helps in discussing patch details.

  Yes!  I'd really hate to lose notifications!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Mon Jun 26 18:04:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT)
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395770C2.B903724A@lemburg.com>
References: <LNBBLJKPBEHFEDALKOLCKEKGGFAA.tim_one@email.msn.com>
	<395319DD.F2584321@lemburg.com>
	<200006261449.JAA01684@cj20424-a.reston1.va.home.com>
	<395770C2.B903724A@lemburg.com>
Message-ID: <14679.32536.133849.573542@mailhost.beopen.com>

M.-A. Lemburg writes:
 > Will there be a list which gets the patches mailed to it
 > by SF ?

  patches at python.org should get messages of patch manager activity (at
least certain actions; not sure which ones yet, but at least
additions).

 > I'm just asking because the current setup of having the patches
 > available through mail really helps in discussing patch details.

  Yes!  I'd really hate to lose notifications!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From paul at prescod.net  Mon Jun 26 17:43:31 2000
From: paul at prescod.net (Paul Prescod)
Date: Mon, 26 Jun 2000 08:43:31 -0700
Subject: [Python-Dev] winreg
Message-ID: <39577A23.EF7DE922@prescod.net>

[I'm having mail troubles so my response time may be slow...]

I've just had a chance to look at the winreg module. I think that it is
too low-level. I wrote a wrapper class that I feel is more Pythonic.
I'll outline the basic ideas and then if there is interest I'll develop
a test suite and send it out for eyeballing by Mark and others. Yes, I
am proposing this for 1.6. If we're going to put in a registry module,
it should be as Pythonic as possible.

First, about Winreg 1:

It was perfect when it was part of the win32 package and was supposed to
mirror the win32 APIs exactly (for reasons of documentation and
familiarity) but as the "standard" Python registry manipulation module
it seems too low-level to me.

I'm sure Mark would be the first to admit that it isn't very Pythonic.
It's more Microsoft-ic. In one part of the docs he says: "this API is
lame, lame, lame. Don't use it." :) 

There are also bogus parameters that Microsoft hasn't got around to
assigning values to, undocumented constants and so forth. My favorite is
"WHOLE_HIVE_VOLATILE".

Winreg 2:

The basic idea in the pythonic wrapper is that there are key "objects"
rather than just handles. winreg already has a primtive "handle object"
but for some reason most of the stuff that would logically be methods
are actually functions that take the handle as the first param.

Keys can have subkeys. So in winreg 1 you would say:

winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE,
"HARDWARE"), "DESCRIPTION" )

now you say:

winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey(
"DESCRIPTION" )

(you could also use a path syntax in either case)

You can get a complete list of existant subkeys with a getSubkeys()
method call. This list behaves like a Python mapping and also like a
sequence. You can use either string key names or integer ordinal
indexes. You can fetch and delete keys based on those indexes:

for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys():
	dosomething( key )

Before it was something like this:

for index in xrange( 0, sys.maxint ):
	try:
		dosomething( winreg.EnumKey( index ) )
	except WindowsError:
		break

"Values" (in the Microsoft sense) are handled the same basic way.
Looping, deleting, etc. is the same.

When you fetch a value, you get a (type,value) tuple. Types are objects
with properties:

typeobj.intval -> 0..10
typeobj.msname -> REG_SZ, REG_SZ_MULTI, ...
typeobj.friendlyname -> "String", "Sting List", ...

Type coercions are all done by the underlying module (the old winreg)
except that I've decided that binary data should be returned as an
array.array('c') rather than an 8-bit string.

-- 
 Paul Prescod
Out of timber so crooked as that which man is made nothing entirely
straight can be built. - Immanuel Kant



From fdrake at beopen.com  Mon Jun 26 17:46:23 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 08:46:23 -0700 (PDT)
Subject: [Python-Dev] Fw: Access violation when no memory
In-Reply-To: <200006261133.NAA03073@python.inrialpes.fr>
References: <ECEPKNMJLHAPFFJHDOJBKEMECNAA.mhammond@skippinet.com.au>
	<200006261133.NAA03073@python.inrialpes.fr>
Message-ID: <14679.31439.11309.105239@mailhost.beopen.com>

Vladimir Marangozov writes:
 >    There are two possible fixes, and I'm not sure which one is better:
 > 
 >    a) Fix the Instance_New code, by freeing the instance on inst->in_dict
 >       allocation failure (without decref'ing the instance).

  I think this is the right one; this *shold* be all that's ever
needed, and isolates the check to the cod ethat can experiance
failure.

 >    b) Fix the dealloc code, by checking whether in_dict is not NULL
 >       before proceeding with the __del__ finalization logic.

  This protects against bad C code elsewhere that makes a mess of
existing objects by stepping around the API (such as by setting
inst->in_dict to NULL).  I'm not sure we want to protect against that
since it could mask bugs (I doubt anyone would do that deliberatly, so
I feel safe calling it a bug!).

 >    Opinions?

  And for free!  So infer what you will about their worth.  :)

 > 2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on
 >    low-memory conditions. They are pushed on the stack, then popped with
 >    a segfault.  The only reasonable behavior I get, after some testing,
 >    is by setting the tb and exc to Py_None if any of them is NULL before
 >    pushing them onto the stack. The program succeeds or the process is
 >    killed by the OS (tested on Linux).
 > 
 >    However, I'm not sure that setting tb and/or exc to Py_None, if NULL,
 >    makes any sense and won't cause side effects.

  This doesn't seem like a situation where you'd be masking some other
kind of bug by using Py_None, and it avoids the core dump.  Since
you're not masking anything, I'd go ahead and use Py_None here.


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From esr at thyrsus.com  Mon Jun 26 20:01:25 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 26 Jun 2000 14:01:25 -0400
Subject: [Python-Dev] Now that the man is back...
Message-ID: <20000626140125.A3266@thyrsus.com>

Guido, can we get these into 1.6?  They're needed for the the ncurses 
extensions I'm working on.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"This country, with its institutions, belongs to the people who
inhabit it. Whenever they shall grow weary of the existing government,
they can exercise their constitutional right of amending it or their
revolutionary right to dismember it or overthrow it."
	-- Abraham Lincoln, 4 April 1861
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libascii.tex
Type: application/x-tex
Size: 4408 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000626/903a84b4/attachment-0001.bin>
-------------- next part --------------
#
# ascii.py -- constants and memembership tests for ASCII characters
#

NUL	= 0x00	# ^@
SOH	= 0x01	# ^A
STX	= 0x02	# ^B
ETX	= 0x03	# ^C
EOT	= 0x04	# ^D
ENQ	= 0x05	# ^E
ACK	= 0x06	# ^F
BEL	= 0x07	# ^G
BS	= 0x08	# ^H
TAB	= 0x09	# ^I
HT	= 0x09	# ^I
LF	= 0x0a	# ^J
NL	= 0x0a	# ^J
VT	= 0x0b	# ^K
FF	= 0x0c	# ^L
CR	= 0x0d	# ^M
SO	= 0x0e	# ^N
SI	= 0x0f	# ^O
DLE	= 0x10	# ^P
DC1	= 0x11	# ^Q
DC2	= 0x12	# ^R
DC3	= 0x13	# ^S
DC4	= 0x14	# ^T
NAK	= 0x15	# ^U
SYN	= 0x16	# ^V
ETB	= 0x17	# ^W
CAN	= 0x18	# ^X
EM	= 0x19	# ^Y
SUB	= 0x1a	# ^Z
ESC	= 0x1b	# ^[
FS	= 0x1c	# ^\
GS	= 0x1d	# ^]
RS	= 0x1e	# ^^
US	= 0x1f	# ^_
SP	= 0x20	# space
DEL	= 0x7f	# delete

controlnames = [
"NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL",
"BS",  "HT",  "LF",  "VT",  "FF",  "CR",  "SO",  "SI",
"DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB",
"CAN", "EM",  "SUB", "ESC", "FS",  "GS",  "RS",  "US",
"SP"
]

def _ctoi(c):
    if type(c) == type(""):
        return ord(c)
    else:
        return c

def isalnum(c): return isalpha(c) or isdigit(c)
def isalpha(c): return isupper(c) or islower(c)
def isascii(c): return _ctoi(c) <= 127		# ?
def isblank(c): return _ctoi(c) in (8,32)
def iscntrl(c): return _ctoi(c) <= 31
def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57
def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126
def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122
def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126
def ispunct(c): return _ctoi(c) != 32 and not isalnum(c)
def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11)
def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90
def isxdigit(c): return isdigit(c) or \
    (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102)
def isctrl(c): return _ctoi(c) < 32
def ismeta(c): return _ctoi(c) > 127

def ascii(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x7f)
    else:
        return _ctoi(c) & 0x7f

def ctrl(c):
    if type(c) == type(""):
        return chr(_ctoi(c) & 0x1f)
    else:
        return _ctoi(c) & 0x1f

def alt(c):
    if type(c) == type(""):
        return chr(_ctoi(c) | 0x80)
    else:
        return _ctoi(c) | 0x80

def unctrl(c):
    bits = _ctoi(c)
    if bits == 0x7f:
        rep = "^?"
    elif bits & 0x20:
        rep = chr((bits & 0x7f) | 0x20)
    else:
        rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20)
    if bits & 0x80:
        return "!" + rep
    return rep


From tim_one at email.msn.com  Mon Jun 26 20:41:12 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 26 Jun 2000 14:41:12 -0400
Subject: [Python-Dev] RE: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>

[Guido]
> It's official: I've changed the patch submission guidelines
> (http://www.python.org/patches/) to point to the patch manager at
> SourceForge.  We are no longer bound by CNRI's legal department, so
> the requirement for disclaimers or wet signatures is gone.

Yay!  Wonder how long that will last <wink>.

Attached is a first cut at documenting the intended use of SourceForge's
patch status tags, and the workflow associated with patch status changes.
The areas in need of fleshing out are marked with "[xxx ...]".  Gripe at
will.

I don't think anyone expects this to work smoothly at first.  Strive for
patience, and let's work to make SF a really *good* place for patches!

never-thought-i'd-actually-miss-lotus-notes-ly y'rs  - tim

PS:  I'll move this (& related info) to a reasonable place eventually, so
don't bother griping about email for now.


Intended use of SourceForge patch status tags
---------------------------------------------
revision 1                        26-Jun-2000


Open
    The initial status of all patches.
    The patch is under consideration, but has not
    been reviewed yet.
    The status will normally change to Accepted or Rejected next.
    The person submitting the patch should (if they can) assign
    it to the person they most want to review it.
    Else the patch will be assigned via
        [xxx a list of expertise areas should be developed]
    Discussion of patches is carried out via
        [xxx Python-Dev?  patches list?  without a mail gateway,
             the SourceForge patch interface looks too clumsy
             to use for controversial patches]
Accepted
    The powers that be have accepted the patch, but it has not
        been applied yet.
        [xxx flesh out -- Guido Bottleneck avoidable here?]
    The status will normally change to Closed next.
    The person changing the status to Accepted should, at the
    same time, assign the patch to whoever they believe is most
    likely to be able & willing to apply it (the submitter if
    possible).
Closed
    The patch has been accepted and applied.
    The previous status was Accepted, or possibly Open if the
    submitter was Guido (or moral equivalent in some particular
    area of expertise).
    If possible, the submitter should apply the patch and change
    the status to Closed.
    Else anyone with sufficient power should feel encouraged to
    do these on the submitter's behalf.
Rejected
    The patch has been reviewed and rejected.
    When the objections are addressed, the status may change to
    Open again.
    Note that SourceForge allows the submitter to overwrite the patch
    with a new version.
Out of date
    Previous status was Open or Accepted or Postponed, but the
    patch no longer works.
    Please enter a comment when changing the status to "Out of date",
    to record the nature of the problem and the previous status.
Postponed
    The previous status was Open or Accepted, but for some reason
    (e.g., pending release) the patch should not be reviewed or
    applied until further notice.
    The status will normally change to Open or Accepted next.
    Please enter a comment when changing the status to Postponed,
    to record the reason, the previous status, and the conditions
    under which the patch should revert to Open or Accepted.
Deleted
    Bit bucket.
    Use only if it's OK for the patch and its SourceForge history
    to disappear.
    As of 26-June-2000, SF does not actually throw away Deleted
    patches, but that may change.





From DavidA at ActiveState.com  Mon Jun 26 21:10:04 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 26 Jun 2000 12:10:04 -0700
Subject: [Python-Dev] semaphore support in thread_*.h
Message-ID: <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com>

I noticed that the support for the semaphore calls in the various thread_*
is very very spotty, with a comment in the BeOS implementation that read:

 * Guido says not to implement this because it's not used anywhere;
 * I'll do it anyway, you never know when it might be handy, and it's
 * easy...

(that last bit is not true of all implementations, apparently =).

1) Is it true that the sema_ calls are never used?

2) If yes, shouldn't we remove the sema_ calls from the thread API and have
similar functionality on all platforms?

(There are related issues re: for example whether async thread locking is
available, whether threads are joinable or not (see thread_cthread.h), etc.)

--david




From tim_one at email.msn.com  Mon Jun 26 21:19:58 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 26 Jun 2000 15:19:58 -0400
Subject: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395770C2.B903724A@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEPFGFAA.tim_one@email.msn.com>

[MAL]
> Will there be a list which gets the patches mailed to it
> by SF ?
>
> I'm just asking because the current setup of having the patches
> available through mail really helps in discussing patch details.

I agree -- SF isn't (yet) good for patch discussions.  Plugging away, but
haven't yet figured out exactly when or how SF decides to send email.  In
particular, don't yet know how (or whether it's possible) to trick current
SF into populating a mailing list.





From guido at python.org  Mon Jun 26 22:24:57 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 15:24:57 -0500
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: Your message of "Mon, 26 Jun 2000 14:01:25 -0400."
             <20000626140125.A3266@thyrsus.com> 
References: <20000626140125.A3266@thyrsus.com> 
Message-ID: <200006262024.PAA01212@cj20424-a.reston1.va.home.com>

[ESR]
> Guido, can we get these into 1.6?  They're needed for the the ncurses 
> extensions I'm working on.

Eric,

We (PythonLabs + Andrew Kuchling & Greg Ward) discussed this at our
recent 1.6 planning meeting.  This doesn't have much use outside
curses.  Therefore, Andrew will check it in as a submodule of the new
curses package.

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



From fdrake at beopen.com  Mon Jun 26 21:24:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 12:24:40 -0700 (PDT)
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <20000626140125.A3266@thyrsus.com>
References: <20000626140125.A3266@thyrsus.com>
Message-ID: <14679.44536.931222.448738@mailhost.beopen.com>

Eric S. Raymond writes:
 > Guido, can we get these into 1.6?  They're needed for the the ncurses 
 > extensions I'm working on.

  This will be the curses.ascii module per a discussion last week
which included both Guido and Andrew.
  Andrew, my Unix machine is down for repairs; can you check these in
for me, changing the module name to curses.ascii in the documentation
file?  I don't want to hold up since Eric is still developing some of
the ncurses support.
  Thanks!


  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From jeremy at beopen.com  Mon Jun 26 21:35:17 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 26 Jun 2000 15:35:17 -0400 (EDT)
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <20000626140125.A3266@thyrsus.com>
References: <20000626140125.A3266@thyrsus.com>
Message-ID: <14679.45173.439937.800007@bitdiddle.concentric.com>

The ascii module is going into the curses package.  Andrew Kuchling is
responsible for it.

Jeremy



From esr at thyrsus.com  Mon Jun 26 21:46:50 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 26 Jun 2000 15:46:50 -0400
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com>; from fdrake@beopen.com on Mon, Jun 26, 2000 at 12:24:40PM -0700
References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com>
Message-ID: <20000626154650.C3685@thyrsus.com>

Fred L. Drake, Jr. <fdrake at beopen.com>:
>   This will be the curses.ascii module per a discussion last week
> which included both Guido and Andrew.

OK, I guess.  It will be useful for more than curses, though, so I don't
understand the naming choice.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Hoplophobia (n.): The irrational fear of weapons, correctly described by 
Freud as "a sign of emotional and sexual immaturity".  Hoplophobia, like
homophobia, is a displacement symptom; hoplophobes fear their own
"forbidden" feelings and urges to commit violence.  This would be
harmless, except that they project these feelings onto others.  The
sequelae of this neurosis include irrational and dangerous behaviors
such as passing "gun-control" laws and trashing the Constitution.



From paul at prescod.net  Mon Jun 26 21:53:18 2000
From: paul at prescod.net (Paul Prescod)
Date: Mon, 26 Jun 2000 12:53:18 -0700
Subject: [Python-Dev] winreg
Message-ID: <3957B4AE.5562716C@prescod.net>

I haven't seen this message come through:

http://www.python.org/pipermail/python-dev/2000-June/006346.html

I'm not sure if I missed it due to an email problem.

 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
        - "This is your bill of rights...on drugs", Harpers, Dec. 1999



From fdrake at beopen.com  Mon Jun 26 21:59:10 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 12:59:10 -0700 (PDT)
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <20000626154650.C3685@thyrsus.com>
References: <20000626140125.A3266@thyrsus.com>
	<14679.44536.931222.448738@mailhost.beopen.com>
	<20000626154650.C3685@thyrsus.com>
Message-ID: <14679.46606.287276.330659@mailhost.beopen.com>

Eric S. Raymond writes:
 > OK, I guess.  It will be useful for more than curses, though, so I don't
 > understand the naming choice.

Eric,
  In theory, yes, but... there have not been a lot of requests for the
is*() functions (which are the ones I think you're referring to as
generally useful).  I think some of these are already take care of by
things like "if c in string.hexdigits:", and others can be handled by
making queries on the Unicode character properties.  Given the dearth
of requests for this, I don't see a clear need to place this
elsewhere.
  If feedback to the beta suggests a better location, we'll certainly
consider it!

  -Fred


-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Mon Jun 26 23:28:16 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Jun 2000 16:28:16 -0500
Subject: [Python-Dev] semaphore support in thread_*.h
In-Reply-To: Your message of "Mon, 26 Jun 2000 12:10:04 MST."
             <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com> 
References: <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com> 
Message-ID: <200006262128.QAA01518@cj20424-a.reston1.va.home.com>

> I noticed that the support for the semaphore calls in the various thread_*
> is very very spotty, with a comment in the BeOS implementation that read:
> 
>  * Guido says not to implement this because it's not used anywhere;
>  * I'll do it anyway, you never know when it might be handy, and it's
>  * easy...
> 
> (that last bit is not true of all implementations, apparently =).
> 
> 1) Is it true that the sema_ calls are never used?
> 
> 2) If yes, shouldn't we remove the sema_ calls from the thread API and have
> similar functionality on all platforms?
> 
> (There are related issues re: for example whether async thread locking is
> available, whether threads are joinable or not (see thread_cthread.h), etc.)

The sema_ calls aren't used anywhere in the current source.  I'd be
for removing them.  I'm not even sure why they are there -- maybe
Sjoerd remembers?  (This code was once part of something else than
Python.)

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



From akuchlin at mems-exchange.org  Mon Jun 26 23:28:26 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 26 Jun 2000 17:28:26 -0400
Subject: [Python-Dev] Now that the man is back...
In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com>
References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com>
Message-ID: <20000626172826.E2282@kronos.cnri.reston.va.us>

On Mon, Jun 26, 2000 at 12:24:40PM -0700, Fred L. Drake, Jr. wrote:
>  Andrew, my Unix machine is down for repairs; can you check these in
>for me, changing the module name to curses.ascii in the documentation
>file?  I don't want to hold up since Eric is still developing some of
>the ncurses support.

I'll do that tonight; I had no time for Python hacking over the weekend...

--amk



From mhammond at skippinet.com.au  Tue Jun 27 02:03:16 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 27 Jun 2000 10:03:16 +1000
Subject: [Python-Dev] winreg
In-Reply-To: <39577A23.EF7DE922@prescod.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au>

> I've just had a chance to look at the winreg module. I think that it is
> too low-level.

I agree.  There was a proposal (from Thomas Heller, IIRC) to do just this.
I successfully argued there should be _2_ modules for Python - the raw
low-level API, which guarantees you can do (almost) anything.  A
higher-level API could cover the 80% of cases.  It is probably worth
getting in touch with Thomas - he may be able to dig up his proposed
high-level API.  Ive CCd him on this message [I hope is _was_ you Thomas -
otherwise you will be wondering WTF I am on about :]

I was very keen to ensure the win32api code was used as the low-level API,
simply because it has been well tested and used.  We _know_ it has no
significant limitations.

Im happy to support a high-level API, but didnt have the inclination to
provide one.  Every one I have seen and every one I have tried to design
has started to fall-apart under real-world use - Ive needed to revert back
to the low-level.

> There are also bogus parameters that Microsoft hasn't got around to
> assigning values to, undocumented constants and so forth. My favorite is
> "WHOLE_HIVE_VOLATILE".

This is exactly my concern with a high-level API - you cant hope to capture
all this - especially the undocumented ones - so having a low-level API
means you can do anything, even stuff never dreamt of by the high-level
designer.

I have no real problem with your proposed design, as long as it it written
in Python, _using_ the low-level API.  It could be called "registry" or I
would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module
to be called "winreg.py"

Mark.




From tim_one at email.msn.com  Tue Jun 27 00:13:42 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 26 Jun 2000 18:13:42 -0400
Subject: [Python-Dev] semaphore support in thread_*.h
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJCEANCKAA.DavidA@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEAGGGAA.tim_one@email.msn.com>

[David Ascher]
> I noticed that the support for the semaphore calls in the various thread_*
> is very very spotty, with a comment in the BeOS implementation that read:
>
>  * Guido says not to implement this because it's not used anywhere;
>  * I'll do it anyway, you never know when it might be handy, and it's
>  * easy...

> (that last bit is not true of all implementations, apparently =).
>
> 1) Is it true that the sema_ calls are never used?

Best I can tell, the following sema functions are indeed never used:

    PyThread_allocate_sema
    PyThread_free_sema
    PyThread_down_sema
    PyThread_up_sema

the following #define's are never used:

    WAIT_SEMA
    NOWAIT_SEMA

and the following non-sema pythread.h functions are not only never used,
they're defined only in thread_sgi.h:

    PyThread_create_key
    PyThread_delete_key
    PyThread_set_key_value
    PyThread_get_key_value

> 2) If yes, shouldn't we remove the sema_ calls from the thread
> API and have similar functionality on all platforms?

+1 from me.  If someone wants platform-specific thread functions, they
should be in a platform-specific extension module, not messing up the core.

> (There are related issues re: for example whether async thread locking is
> available, whether threads are joinable or not (see
> thread_cthread.h), etc.)

Sorry, don't know what you're getting at here (e.g., have any specific line
or function of thread_cthread.h in mind?).






From fdrake at beopen.com  Tue Jun 27 00:25:42 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 26 Jun 2000 15:25:42 -0700 (PDT)
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com>
References: <14679.32536.133849.573542@mailhost.beopen.com>
	<LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com>
Message-ID: <14679.55398.996503.269852@mailhost.beopen.com>

Tim Peters writes:
 > Fred, would you please explain how that works or where that was set up?
 > I've puttered away many hours now playing with the SourceForge facilities

  From the "project page", go to "Project Admin" on the left
navigation bar, then "Edit Public Info" at the top of the page.  There
are places to edit some email addresses near the bottom of the page.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Mon Jun 26 23:38:51 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 26 Jun 2000 17:38:51 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <14679.32536.133849.573542@mailhost.beopen.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com>

[Fred]
>   patches at python.org should get messages of patch manager activity (at
> least certain actions; not sure which ones yet, but at least
> additions).

Fred, would you please explain how that works or where that was set up?
I've puttered away many hours now playing with the SourceForge facilities
(alas, most of that time waiting for web pages to load), but haven't
stumbled into anything that hints the patch manager knows anything about
patches at python.org.

so-stupid-in-so-many-ways-ly y'rs  - tim





From tim_one at email.msn.com  Tue Jun 27 01:14:06 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 26 Jun 2000 19:14:06 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <14679.55398.996503.269852@mailhost.beopen.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEALGGAA.tim_one@email.msn.com>

[Fred L. Drake, Jr.]
>   From the "project page", go to "Project Admin" on the left
> navigation bar, then "Edit Public Info" at the top of the page.  There
> are places to edit some email addresses near the bottom of the page.

Aha!  The one & only link I had never clicked -- I bet I could have figured
that out myself in another week or two <wink>.  Thank you.

Now why do we have "Use Bug Tracker" checked?  If nobody objects, I'll turn
that off -- we're still doing bugs w/ Jitterbug on python.org.

ten-stop-shopping-ly y'rs  - tim





From guido at beopen.com  Tue Jun 27 04:35:52 2000
From: guido at beopen.com (Guido van Rossum)
Date: Mon, 26 Jun 2000 21:35:52 -0500
Subject: [Python-Dev] ANN: Release schedule
Message-ID: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>

Here at BeOpen we're scrambling to get the release schedule for the
rest of Python 1.6 planned.  We're now looking at releasing Python
1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
This means that if SRE isn't ready, we'll go with an incomplete SRE.
Still better than no SRE!

Please, PLEASE, if you have pending patches that you think should go
into 1.6b1, submit them to SourceForge.  We'll do our best to have a
look at every patch submitted; but don't wait until the last moment.
(Trent Mick, it would be helpful if you assigned each of your patches
a potential reviewer from the list of existing developers -- that way
we can split up the review load.)

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



From trentm at activestate.com  Tue Jun 27 05:52:59 2000
From: trentm at activestate.com (Trent Mick)
Date: Mon, 26 Jun 2000 20:52:59 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pyexpat.py,1.2,1.3
In-Reply-To: <200006270037.RAA25539@slayer.i.sourceforge.net>
References: <200006270037.RAA25539@slayer.i.sourceforge.net>
Message-ID: <20000626205259.A3866@activestate.com>

On Mon, Jun 26, 2000 at 05:37:27PM -0700, A . M . Kuchling wrote:
> Update of /cvsroot/python/python/dist/src/Lib/test
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv25501
> 
> Modified Files:
> 	test_pyexpat.py 
> Log Message:
> Change pyexpat test suite to exercise the .returns_unicode attribute,
> parsing the sample data once with 8-bit strings and once with Unicode.
> 

Does this require a new Lib/test/output/test_pyexpat?


Trent


-- 
Trent Mick
trentm at activestate.com



From DavidA at ActiveState.com  Tue Jun 27 07:34:13 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 26 Jun 2000 22:34:13 -0700
Subject: [Python-Dev] semaphore support in thread_*.h
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEAGGGAA.tim_one@email.msn.com>
Message-ID: <LMBBIEIJKMPMLBONJMFCEEHJCJAA.DavidA@ActiveState.com>

> > (There are related issues re: for example whether async thread
> locking is
> > available, whether threads are joinable or not (see
> > thread_cthread.h), etc.)
>
> Sorry, don't know what you're getting at here (e.g., have any
> specific line
> or function of thread_cthread.h in mind?).

	/* looks like solaris detaches the thread to never rejoin
	 * so well do it here
	 */

in thread_cthread.h

The async thread locking comment was one of my personal issues -- I
considered briefly providing a thread layer on top of the NSPR (Netscape
Portable runtime) which is part of Mozilla.  It has locks, but no async
locking calls.

--david




From rob at hooft.net  Tue Jun 27 11:32:02 2000
From: rob at hooft.net (Rob W. W. Hooft)
Date: Tue, 27 Jun 2000 11:32:02 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1
In-Reply-To: <200006262355.QAA17089@slayer.i.sourceforge.net>
References: <200006262355.QAA17089@slayer.i.sourceforge.net>
Message-ID: <14680.29842.372192.274003@temoleh.chem.uu.nl>

 AMK> Update of /cvsroot/python/python/dist/src/Lib/curses
 AMK> In directory slayer.i.sourceforge.net:/tmp/cvs-serv17079

 AMK> Added Files:
 AMK> ascii.py textpad.py 
 AMK> Log Message:
 AMK> Added two modules for ASCII characters and a simple editing form (ESR)


 AMK> --- NEW FILE ---
 AMK> #
 AMK> # ascii.py -- constants and memembership tests for ASCII characters
 AMK> #
                                  ^^^^^ two letters too much?

Rob



From gvwilson at nevex.com  Tue Jun 27 12:30:55 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 27 Jun 2000 06:30:55 -0400 (EDT)
Subject: [Python-Dev] C# (new language from Microsoft)
Message-ID: <Pine.LNX.4.10.10006270630080.4977-100000@akbar.nevex.com>

I'm sure many of you will have seen this announcement already, but for
those who haven't, Microsoft is launching a new language to compete with
C, C++, and Java:

http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp

Greg




From effbot at telia.com  Tue Jun 27 12:35:22 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 12:35:22 +0200
Subject: [Python-Dev] ANN: Release schedule
References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>
Message-ID: <017501bfe023$684fca40$f2a6b5d4@hagrid>

guido wrote:


> Here at BeOpen we're scrambling to get the release schedule for the
> rest of Python 1.6 planned.  We're now looking at releasing Python
> 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
> This means that if SRE isn't ready, we'll go with an incomplete SRE.
> Still better than no SRE!

a major SRE patch is coming up later today.

btw, what would it take for me to check it in myself (assuming someone
will give me commit privs, of course)?  can I apply patches via sourceforge's
web interface, or do I have to figure out how to run cvs over ssh etc etc

(tim? where's the second installment of your sourceforge vs. windows series?)

</F>




From gmcm at hypernet.com  Tue Jun 27 12:36:07 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 27 Jun 2000 06:36:07 -0400
Subject: [Python-Dev] winreg
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au>
References: <39577A23.EF7DE922@prescod.net>
Message-ID: <1250020276-32999633@hypernet.com>

Mark wrote:

[Paul]
> > I've just had a chance to look at the winreg module. I think
> > that it is too low-level.
> 
> I agree.  There was a proposal (from Thomas Heller, IIRC) to do
> just this. I successfully argued there should be _2_ modules for
> Python - the raw low-level API, which guarantees you can do
> (almost) anything.  A higher-level API could cover the 80% of
> cases.  It is probably worth getting in touch with Thomas - he
> may be able to dig up his proposed high-level API.  

Found it.

------- Forwarded message follows -------
From:           	"Thomas Heller" <thomas.heller at ion-
tof.com>
To:             	<python-dev at python.org>, <distutil-
sig at python.org>
Date sent:      	Thu, 3 Feb 2000 14:27:00 +0100
Subject:        	[Python-Dev] Revised proposal (and 
preliminary implementation): Registry access module for 
Python on Windows

Ok, at least the first proposal did start the discussion.
Here is a revised one:

A preliminary implementation is available at
http://starship.python.net/crew/theller/

-----------------------------------------------------------------
----- winreg - windows registry access module

Exception:
  error - raised when a function fails. Will contain
    a windows error code and a textual description.

Objects:
  regnode object - represents a open key in the
  registry.

Functions:
  OpenKey (name) -> regnode object
    Opens an existing key with the specified access rights
    and returns a regnode object.
    name is specified like "HKLM\Software\Python"
    or "HKEY_LOCAL_MACHINE\Software\Python"

  CreateKey (name) -> regnode object
    Creates a new key or opens an existing one
    and returns a regnode object.
    For the name format see OpenKey

regnode object methods:
  Values () -> dict
    Returns a dictionary mapping names to values.
    The <default> or unnamed value has the key ''.
    The values are either strings or integers, depending
    on the REG_* type.

  GetValue ([name]) -> integer or string
    Returns a value specified by name or the default value.

  SetValue ([name,] value)
    Set a named or the <default> value.
    Named values must be integers or string (which are stored 
as
    REG_DWORD or REG_SZ). Should an optional third 
parameter be
    used, allowing to store in other REG_* typecodes? I dont
    think so.

  DeleteValue ([name])
    Deletes a named or the <default> value.

  SubKeys () -> sequence
    Returns a sequence containing the names of all subkeys.

  DeleteKey (name [,recursive=0])
    If recursive is 0, deletes the named key if no subkeys exist.
    If there are subkeys an error is raised.    If recursive is
    not 0, the named key is deleted including subkeys.

  OpenKey (name) -> regnode object
    Openes an existing subkey and returns a regnode
    object pointing to it.

  CreateKey (name) -> regnode object
    Creates a new or openes an existing subkey and
    returns a regnode object pointing to it.

regnode objects have the following properties:
  name - the name of the RegistryKey, something
    like "HKLM\Software\Python"
  hkey - the integer keyhandle

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

Thomas Heller





_______________________________________________
Python-Dev maillist  -  Python-Dev at python.org
http://www.python.org/mailman/listinfo/python-dev
------- End of forwarded message -------

- Gordon



From gstein at lyra.org  Tue Jun 27 12:52:02 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 03:52:02 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
In-Reply-To: <200006270050.RAA26210@slayer.i.sourceforge.net>; from akuchling@users.sourceforge.net on Mon, Jun 26, 2000 at 05:50:42PM -0700
References: <200006270050.RAA26210@slayer.i.sourceforge.net>
Message-ID: <20000627035202.M29590@lyra.org>

I just don't buy this.

Look at that code. Look at the definition of finally. That code simply
screams for the use of finally.

Eric: just what happens? What is "broke things"? Do you have a reproducible
test case that I can use?

In good conscience, I have to disagree with reverting this stuff. If we're
seeking to make the code the best possible, then this is a backward step.
Besides its redundancy, it also places the traceback into a local variable
and then raises an exception -- a perfect recipe for creating a ref loop.

Cheers,
-g

On Mon, Jun 26, 2000 at 05:50:42PM -0700, A.M. Kuchling wrote:
> Update of /cvsroot/python/python/dist/src/Lib/curses
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv26153
> 
> Modified Files:
> 	wrapper.py 
> Log Message:
> Drop back to old version of wrapper(); ESR reports that it broke things,
> and I lack the time to track down the cause.
> 
> 
> Index: wrapper.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/curses/wrapper.py,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -C2 -r1.2 -r1.3
> *** wrapper.py	2000/06/10 23:39:05	1.2
> --- wrapper.py	2000/06/27 00:50:40	1.3
> ***************
> *** 18,24 ****
> --- 18,26 ----
>       """
>       
> +     res = None
>       try:
>   	# Initialize curses
>   	stdscr=curses.initscr()
> +         
>   	# Turn off echoing of keys, and enter cbreak mode,
>   	# where no buffering is performed on keyboard input
> ***************
> *** 30,39 ****
>           stdscr.keypad(1)
>   
> ! 	return apply(func, (stdscr,) + rest)
> ! 
> !     finally:
> ! 	# Restore the terminal to a sane state on the way out.
>   	stdscr.keypad(0)
>   	curses.echo() ; curses.nocbreak()
>   	curses.endwin()
>   
> --- 32,51 ----
>           stdscr.keypad(1)
>   
> !         res = apply(func, (stdscr,) + rest)
> !     except:
> ! 	# In the event of an error, restore the terminal
> ! 	# to a sane state.
>   	stdscr.keypad(0)
>   	curses.echo() ; curses.nocbreak()
>   	curses.endwin()
> +         
> +         # Pass the exception upwards
> +         (exc_type, exc_value, exc_traceback) = sys.exc_info()
> +         raise exc_type, exc_value, exc_traceback
> +     else:
> + 	# Set everything back to normal
> + 	stdscr.keypad(0)
> + 	curses.echo() ; curses.nocbreak()
> + 	curses.endwin()		 # Terminate curses
>   
> +         return res
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From thomas.heller at ion-tof.com  Tue Jun 27 13:09:24 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Tue, 27 Jun 2000 13:09:24 +0200
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au>
Message-ID: <019601bfe028$281dab90$4500a8c0@thomasnb>

> > I've just had a chance to look at the winreg module. I think that it is
> > too low-level.
>
> I agree.  There was a proposal (from Thomas Heller, IIRC) to do just this.
> I successfully argued there should be _2_ modules for Python - the raw
> low-level API, which guarantees you can do (almost) anything.  A
> higher-level API could cover the 80% of cases.  It is probably worth
> getting in touch with Thomas - he may be able to dig up his proposed
> high-level API.  Ive CCd him on this message [I hope is _was_ you Thomas -
> otherwise you will be wondering WTF I am on about :]
Yes, it was me :-)

Here is the 3. (final?) proposal, earlier ones are in the archives:
http://www.python.org/pipermail/python-dev/2000-February/003417.html
and
http://www.python.org/pipermail/python-dev/2000-February/003472.html

----------------------------------------------------------------------
winreg - windows registry access module

Exception:
  error - raised when a function fails. Will contain
    a windows error code and a textual description.

Objects:
  regkey object - represents a open key in the
  registry.

Functions:
  OpenKey (name) -> regkey object
    Opens an existing key with the specified access rights
    and returns a regkey object.
    name is specified like "HKLM\Software\Python"
    or "HKEY_LOCAL_MACHINE\Software\Python"

  CreateKey (name) -> regkey object
    Creates a new key or opens an existing one
    and returns a regkey object.
    For the name format see OpenKey

regkey object methods:
  Standard Mapping protocol:
  len (r)
  r[k]
  r[k] = x
  del r[k]
  r.clear()
  r.has_key(k)
  r.items()
  r.keys()
  r.update(dict)
  r.values()
  r.get(k[, x])

  todict() -> dictionary
    Returns a dictionary mapping value names to values.

  SubKeys () -> sequence
    Returns a sequence containing the names of all subkeys.

  DeleteKey (name [,recursive=0])
    If recursive is 0, deletes the named key if no subkeys exist.
    If there are subkeys an error is raised.
    If recursive is not 0, the named key is deleted
    including subkeys.

  OpenKey (name) -> regkey object
    Openes an existing subkey and returns a regkey
    object pointing to it.

  CreateKey (name) -> regkey object
    Creates a new or openes an existing subkey and
    returns a regkey object pointing to it.

regkey objects have the following properties:
  name - the name of the RegistryKey, something
    like "HKLM\Software\Python"
  hkey - the integer keyhandle

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

It would not be too much work to implement it, but
I will be away the next 20 days...

> I have no real problem with your proposed design, as long as it it written
> in Python, _using_ the low-level API.  It could be called "registry" or I
> would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module
> to be called "winreg.py"
>
If we change the name of the low level api module, we have to change
Distutils,
because it is used there. Maybe we would better use the high level api then,
but there is still this 1.5 compatibility using the win32api module.

Thomas




From guido at beopen.com  Tue Jun 27 14:23:36 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 07:23:36 -0500
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: Your message of "Tue, 27 Jun 2000 12:35:22 +0200."
             <017501bfe023$684fca40$f2a6b5d4@hagrid> 
References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>  
            <017501bfe023$684fca40$f2a6b5d4@hagrid> 
Message-ID: <200006271223.HAA01391@cj20424-a.reston1.va.home.com>

[effbot]
> a major SRE patch is coming up later today.

Great!

> btw, what would it take for me to check it in myself (assuming someone
> will give me commit privs, of course)?  can I apply patches via sourceforge's
> web interface, or do I have to figure out how to run cvs over ssh etc etc

Erm, the latter.  From a Unix system it's a breeze.  From Windows,
it's a relative breeze to do an *anonymous* checkout (no SSH
required), but getting commit permission is a pain -- Tim will
research this.  (Do you have access to any Unix or Linux system at
all?)

I'll make you a developer anyway.

> (tim? where's the second installment of your sourceforge vs. windows series?)

I'm waiting too!

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



From guido at beopen.com  Tue Jun 27 16:30:30 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 09:30:30 -0500
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Mon, 26 Jun 2000 17:38:51 -0400."
             <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com> 
Message-ID: <200006271430.JAA01769@cj20424-a.reston1.va.home.com>

> [Fred]
> >   patches at python.org should get messages of patch manager activity (at
> > least certain actions; not sure which ones yet, but at least
> > additions).

[Tim]
> Fred, would you please explain how that works or where that was set up?
> I've puttered away many hours now playing with the SourceForge facilities
> (alas, most of that time waiting for web pages to load), but haven't
> stumbled into anything that hints the patch manager knows anything about
> patches at python.org.

Yes, it's hidden, and Fred had to show me too.

First, login to SourceForge.  Then, go to the Python Project.  In the
left sidebar, under Project: Python, go to Project Admin.  Near the
top, you now see some navigation links; go to Edit Public Info.
At the very bottom there are three text fields for email addresses.

The address for New Patches (a misnomer -- it's really all changes
made to the Patch Manager) says patches at python.org.

The address for New Bugs is currently set to guido at beopen.com.  I
suppose I should set it to pythoneers at beopen.com or even to
python-dev at python.org?

We're not using the Support manager yet.

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



From mhammond at skippinet.com.au  Tue Jun 27 16:45:07 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Jun 2000 00:45:07 +1000
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
In-Reply-To: <20000627035202.M29590@lyra.org>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEICCOAA.mhammond@skippinet.com.au>

> Besides its redundancy, it also places the traceback into a
> local variable
> and then raises an exception -- a perfect recipe for creating a ref loop.

Isnt it true that _every_ time you store a traceback object as a local
variable, and that traceback has a reference to the frame holding the
local, you _always_ get a reference loop, regardless of how you exit the
function?

ie, I believe that _every_ time you store a traceback obtained from inside
an except handler, you _always_ get a ref-loop, period.  The only way to
clean the cycle is to explictly unbind the local from the traceback.

Mark.





From mhammond at skippinet.com.au  Tue Jun 27 16:39:15 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Jun 2000 00:39:15 +1000
Subject: [Python-Dev] C# (new language from Microsoft)
In-Reply-To: <Pine.LNX.4.10.10006270630080.4977-100000@akbar.nevex.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEIBCOAA.mhammond@skippinet.com.au>

I cant say much, as I am still under NDA.  However, I probably can say:

* C Sharp is really not the interesting part of this technology.  MS are
controlling the way (the order, really) the information is coming out; as
more info comes out, C Sharp should move back into perspective for what is
really is.  Suffice it to say, hardly anyone on slashdot is even in the
ball-park!

* The MS PDC in a couple of weeks will be the official announcement of the
more interesting things.  After this, everyone involved in the project will
be completely free to discuss all they know, including me (and a few other
Pythoneers)

* Python has a very good and interesting story in all this - there is no
need to be alarmed.  If anything, be excited :-)

Mark.

> -----Original Message-----
> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Greg Wilson
> Sent: Tuesday, 27 June 2000 8:31 PM
> To: Python Developers
> Subject: [Python-Dev] C# (new language from Microsoft)
>
>
> I'm sure many of you will have seen this announcement already, but for
> those who haven't, Microsoft is launching a new language to compete with
> C, C++, and Java:
>
> http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp
>
> Greg
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
>




From paul at prescod.net  Tue Jun 27 17:15:29 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:15:29 -0700
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb>
Message-ID: <3958C511.17282EF7@prescod.net>

Mark, Thomas and whoever, thanks for your input and I hope you can spare
some more...

Thomas Heller wrote:
> 

This is similar to what I have implemented...

> ----------------------------------------------------------------------
> winreg - windows registry access module
> 
> Exception:
>   error - raised when a function fails. Will contain
>     a windows error code and a textual description.

As an aside, I notice that the winreg documentation says it will raise
an EnvironmentError but it actually raises a WindowsError. 

> Objects:
>   regkey object - represents a open key in the
>   registry.

Right. Even the same name.

My stance was that keys would always be created from keys, so you would
start with

HKEY_LOCAL_MACHINE.CreateKey("Software\Python")

That mirrors the underlying API a little closer and reduces the number
of functions to 0.

The question is whether the CreateKey and OpenKey functions are
important enough as "convenience functions".

> regkey object methods:
>   Standard Mapping protocol:
>   len (r)
>   r[k]
>   r[k] = x
>   del r[k]
>   r.clear()
>   r.has_key(k)
>   r.items()
>   r.keys()
>   r.update(dict)
>   r.values()
>   r.get(k[, x])

I had a separate object for values. I couldn't really justify elevating
either the Subkeys or the Values. I tried to treat them as alike as
possible.

>   todict() -> dictionary
>     Returns a dictionary mapping value names to values.

I called this getValues() and it returned an object that was both a
mapping and a sequence and allowed read/write/delete of values.

>   SubKeys () -> sequence
>     Returns a sequence containing the names of all subkeys.
> 
>   DeleteKey (name [,recursive=0])
>     If recursive is 0, deletes the named key if no subkeys exist.
>     If there are subkeys an error is raised.
>     If recursive is not 0, the named key is deleted
>     including subkeys.

I may or may not get around to implementing the recursive version. You
have to be VERY CAREFUL when you test such a thing. :)

>   OpenKey (name) -> regkey object
>     Openes an existing subkey and returns a regkey
>     object pointing to it.

Okay.

>   CreateKey (name) -> regkey object
>     Creates a new or openes an existing subkey and
>     returns a regkey object pointing to it.

Okay.

> regkey objects have the following properties:
>   name - the name of the RegistryKey, something
>     like "HKLM\Software\Python"

Okay.

>   hkey - the integer keyhandle

Is this really useful? Better to use the low-level API in that case...

> If we change the name of the low level api module, we have to change
> Distutils,
> because it is used there. Maybe we would better use the high level api then,
> but there is still this 1.5 compatibility using the win32api module.

The high level could probably be made compatible with 1.5 like this:

try:
    import _winreg
except ImportError:
    import win32api
    winreg=win32api

It would probably be good for DistUtils to use the high level API as
soon as it is possible for testing purposes.

I am considering doing away with the two enumeration interfaces. The
cost/benefit of having two more objects is probably low.

We can simplify the whole thing by just using methods on the regkey
object:

deleteValue(name) 
getValue(name)-> (type, value)
setValue(name,(type,value))
getValueNames() -> List of strings

getSubkey(name) -> regkey
deleteSubkey(name)
getSubkeyNames( ) -> List of strings

Iterating will be slightly less efficient because it will loop twice,
once to gather the names and once to do whatever you need to do but
that's not the typical registry use case anyhow. Anyone who needs
absolute performance can use the low-level API.

Recursive iteration under the existing model:

def doit( key ):
    for subkey in key.getSubkeyNames():
        doit( subkey )

Recursive iteration under the proposed model:

def doit( key ):
    for keyname in key.getSubkeyNames():
        doit( key.getSubkey( name ))

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From paul at prescod.net  Tue Jun 27 17:28:55 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:28:55 -0700
Subject: [Python-Dev] winreg features
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb>
Message-ID: <3958C837.ECD925CC@prescod.net>

There are a few features missing from the proposed API. I don't think
that this API should serve the 80%, but rather the 97%. The only things
I plan to exclude from the low level API are things that are
undocumented and a little bit of performance.

I see no reason not to add support for close, flush, save, remote keys
and REG_FOO types.

If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add
support for that too. :)

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From paul at prescod.net  Tue Jun 27 17:29:16 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:29:16 -0700
Subject: [Python-Dev] winreg features
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb>
Message-ID: <3958C84C.37C3EAD@prescod.net>

There are a few features missing from the proposed API. I don't think
that this API should serve the 80%, but rather the 97%. The only things
I plan to exclude from the low level API are things that are
undocumented and a little bit of performance. I want to simplify the
API, not dumb it down.

I see no reason not to add support for close, flush, save, remote keys
and REG_FOO types.

If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add
support for that too. :)

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From thomas.heller at ion-tof.com  Tue Jun 27 17:42:26 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Tue, 27 Jun 2000 17:42:26 +0200
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net>
Message-ID: <02e201bfe04e$4cecc700$4500a8c0@thomasnb>

(Hopefully it is ok to use the reply-all button)

> ...
> My stance was that keys would always be created from keys, so you would
> start with
>
> HKEY_LOCAL_MACHINE.CreateKey("Software\Python")
>
> That mirrors the underlying API a little closer and reduces the number
> of functions to 0.
Good idea!
Maybe HKLM and so on should be provided as aliases.

> >
> >   DeleteKey (name [,recursive=0])
> >     If recursive is 0, deletes the named key if no subkeys exist.
> >     If there are subkeys an error is raised.
> >     If recursive is not 0, the named key is deleted
> >     including subkeys.
>
> I may or may not get around to implementing the recursive version. You
> have to be VERY CAREFUL when you test such a thing. :)
Someone (I don't remember who) mentioned in the discussion
about my proposal that one should use SHDeleteKey for recursive
deletion of keys. See the MSDN docs on RegDeleteKey for details.
Don't know if this is exposed by the lowlevel module.

>
> > If we change the name of the low level api module, we have to change
> > Distutils,
> > because it is used there. Maybe we would better use the high level api
then,
> > but there is still this 1.5 compatibility using the win32api module.
>
> The high level could probably be made compatible with 1.5 like this:
>
> try:
>     import _winreg
> except ImportError:
>     import win32api
>     winreg=win32api
Currently it goes like this, because win32api and winreg (which
will soon be _winreg) have slightly different apis, but it will
doubtlessly be solved:

try:
    import winreg
    _can_read_reg = 1
    hkey_mod = winreg

    RegOpenKeyEx = winreg.OpenKeyEx
    RegEnumKey = winreg.EnumKey
    RegEnumValue = winreg.EnumValue
    RegError = winreg.error

except ImportError:
    try:
        import win32api
        import win32con
        _can_read_reg = 1
        hkey_mod = win32con

        RegOpenKeyEx = win32api.RegOpenKeyEx
        RegEnumKey = win32api.RegEnumKey
        RegEnumValue = win32api.RegEnumValue
        RegError = win32api.error

    except ImportError:
        pass

Thomas




From paul at prescod.net  Tue Jun 27 17:52:27 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 08:52:27 -0700
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb>
Message-ID: <3958CDBB.3F354C97@prescod.net>

Right now the Python list is a little slow (at least for me) so I
appreciate cc:s directly to me.

Thomas Heller wrote:
> 
> Good idea!
> Maybe HKLM and so on should be provided as aliases.

Sure.

> Someone (I don't remember who) mentioned in the discussion
> about my proposal that one should use SHDeleteKey for recursive
> deletion of keys. See the MSDN docs on RegDeleteKey for details.
> Don't know if this is exposed by the lowlevel module.

Don't think so.

> Currently it goes like this, because win32api and winreg (which
> will soon be _winreg) have slightly different apis, but it will
> doubtlessly be solved:

Ouch. I don't know if I have time to figure out all of the
correspondances. Are the only differences those four method names or are
those the only four differences that DistUtils happened to care about.
I'm not interested in 1.5 compatibility if it will take a lot of work.

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From thomas.heller at ion-tof.com  Tue Jun 27 18:03:30 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Tue, 27 Jun 2000 18:03:30 +0200
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net>
Message-ID: <02fe01bfe051$3df655b0$4500a8c0@thomasnb>

> Right now the Python list is a little slow (at least for me) so I
> appreciate cc:s directly to me.
Same for me: All python lists take hours to distribute the mails.

> > Someone (I don't remember who) mentioned in the discussion
> > about my proposal that one should use SHDeleteKey for recursive
> > deletion of keys. See the MSDN docs on RegDeleteKey for details.
> > Don't know if this is exposed by the lowlevel module.
>
> Don't think so.
The tricky thing is: Deletion of keys behaves differently
on Win95/98 and NT/2000.
(Quoting MSDN:)
The RegDeleteKey function deletes a subkey.

Windows 95/98: The function also deletes all subkeys and values. To delete a
key only if the key has no subkeys or values, use the SHDeleteEmptyKey
function.

Windows NT/2000: The subkey to be deleted must not have subkeys. To delete a
key and all its subkeys, you need to recursively enumerate the subkeys and
delete them individually. To recursively delete keys, use the SHDeleteKey
function.
(end quote)

The SHDelete* funtions require version 4.71 of shlwapi.dll, which
is included in Win98 or 2000 (or in IE 4.0).

>
> > Currently it goes like this, because win32api and winreg (which
> > will soon be _winreg) have slightly different apis, but it will
> > doubtlessly be solved:
>
> Ouch. I don't know if I have time to figure out all of the
> correspondances. Are the only differences those four method names or are
> those the only four differences that DistUtils happened to care about.
> I'm not interested in 1.5 compatibility if it will take a lot of work.
So you should simply ignore this. We will work it out on distutils.

Thomas
(I will disappear soon for holidays)




From Vladimir.Marangozov at inrialpes.fr  Tue Jun 27 18:23:52 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Tue, 27 Jun 2000 18:23:52 +0200 (CEST)
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 26, 2000 09:35:52 PM
Message-ID: <200006271623.SAA04926@python.inrialpes.fr>

Guido van Rossum wrote:
> 
> Here at BeOpen we're scrambling to get the release schedule for the
> rest of Python 1.6 planned.  We're now looking at releasing Python
> 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
> This means that if SRE isn't ready, we'll go with an incomplete SRE.
> Still better than no SRE!
> 
> Please, PLEASE, if you have pending patches that you think should go
> into 1.6b1, submit them to SourceForge.  We'll do our best to have a
> look at every patch submitted; but don't wait until the last moment.

So, to sum up (because I'm a bit lost after all this patch-related
messages), what should I do to avoid at best adding to the collective
burden :

1. Should I send patches to SF and be quiet until June 30 ?

2. Should I apply for privileges and spend <big time> installing
   an SSH client on my box (illegal in France ;), then make my Python
   way into the SF galaxy ?

3. If I volunteer for help with the patches backlog, what do I do ?

4. Other options presented to me ?

Context : I (will) have some patches lying around, there are some
patches of mine on the pile sent to patches at python.org that I'm
confident about, I have read the FAQ at SF which gave me 0 clues
on how things are being set up there (only general info about
who why and what for + terms of service), and I managed to create
an account with a personal page containing two bookmarks in it
(after being distracted with personal and project ratings + gobs of
links to gobs of stuff).

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From guido at beopen.com  Tue Jun 27 19:27:24 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 12:27:24 -0500
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: Your message of "Tue, 27 Jun 2000 18:23:52 +0200."
             <200006271623.SAA04926@python.inrialpes.fr> 
References: <200006271623.SAA04926@python.inrialpes.fr> 
Message-ID: <200006271727.MAA03564@cj20424-a.reston1.va.home.com>

> 1. Should I send patches to SF and be quiet until June 30 ?

Yes.  Not too quiet -- helping selecting which old patches are good
would help.  Also downloading patches from SF and commenting on them
(+1/-1) in the patches list would help.

> 2. Should I apply for privileges and spend <big time> installing
>    an SSH client on my box (illegal in France ;), then make my Python
>    way into the SF galaxy ?

Probably no.

> 3. If I volunteer for help with the patches backlog, what do I do ?

Go through the patches archives and review patches.  If you find one
for which you would vote +1 and which you think I might like, submit
it to SF.

> 4. Other options presented to me ?
> 
> Context : I (will) have some patches lying around, there are some
> patches of mine on the pile sent to patches at python.org that I'm
> confident about, I have read the FAQ at SF which gave me 0 clues
> on how things are being set up there (only general info about
> who why and what for + terms of service), and I managed to create
> an account with a personal page containing two bookmarks in it
> (after being distracted with personal and project ratings + gobs of
> links to gobs of stuff).

Go to the Python Project Summary, then to the Patch Manager.  At the
top, click on Submit Patch.

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



From mal at lemburg.com  Tue Jun 27 18:38:54 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 27 Jun 2000 18:38:54 +0200
Subject: [Python-Dev] SF patch manager...
Message-ID: <3958D89E.39D084C8@lemburg.com>

[Please excuse my ranting... :-)]

I've received the first round of notification message from the
patch manager and can't really say that I like them. Ok, I 
understand that the patch manager is still alpha or beta software,
but these messages really don't have any usable content at all:

"""
Patch #100646 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470
"""

Also, reviewing the patches has become a pain and discussing them
is nearly impossible (I don't consider the slashdot like comment
mechanism to be of any use: there's simply no audience for
discussion).

Is there any chance of tee'ing patches from SF to the patches
list or some other patch discussion and review forum ? I do
understand that the mechanism can help with patch *checkins*,
but it's certainly not going to help much with the discussion
step needed before conidering any actions. The independent
peer review principal doesn't work with this kind of setup.

Ok, enough whining, let's get on with business now ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From esr at thyrsus.com  Tue Jun 27 18:50:53 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 27 Jun 2000 12:50:53 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
In-Reply-To: <20000627035202.M29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 03:52:02AM -0700
References: <200006270050.RAA26210@slayer.i.sourceforge.net> <20000627035202.M29590@lyra.org>
Message-ID: <20000627125053.B6531@thyrsus.com>

Greg Stein <gstein at lyra.org>:
> I just don't buy this.
> 
> Look at that code. Look at the definition of finally. That code simply
> screams for the use of finally.
> 
> Eric: just what happens? What is "broke things"? Do you have a reproducible
> test case that I can use?

What happened is that your version failed to pass an error exception upwards
after fielding it.  My test case was a buggy version of cmlconfigure.py, bug
since fixed.

Cleanliness is good, but the code has to work first.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Faith may be defined briefly as an illogical belief in the occurrence
of the improbable...A man full of faith is simply one who has lost (or
never had) the capacity for clear and realistic thought. He is not a
mere ass: he is actually ill.
	-- H. L. Mencken 



From trentm at activestate.com  Tue Jun 27 18:46:58 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 09:46:58 -0700
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>
References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com>
Message-ID: <20000627094658.B7257@activestate.com>

On Mon, Jun 26, 2000 at 09:35:52PM -0500, Guido van Rossum wrote:
> (Trent Mick, it would be helpful if you assigned each of your patches
> a potential reviewer from the list of existing developers -- that way
> we can split up the review load.)
> 

Do you mean I should reassigned patch-reviewing over and above the
assignments that you have done recently? I was just going to put up twenty
more patches and assign them all to Tim as well. :) Kidding.

If, "yes", then I will make a go at that today.


BTW I have answered a couple a questions on my patches. Does the person to
whom the patch is assigned get an update notification?

Trent


-- 
Trent Mick
trentm at activestate.com



From trentm at activestate.com  Tue Jun 27 18:57:38 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 09:57:38 -0700
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <14679.36964.766774.864078@localhost.localdomain>
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain>
Message-ID: <20000627095738.D7257@activestate.com>

On Mon, Jun 26, 2000 at 01:18:28PM -0400, Jeremy Hylton wrote:
> Ok.  I was looking for a test case to include in the test suite.  I've
> made the change, but it looks like it will have to go without an
> accompanying test.


I asked the question a while back if it would reasonable/useful/popular to
have a mechanism where parts of the Python/C Api could be tested directly.

My proposal used an extension module _testmodule (although I made it a core
module on UN*X it should not bog down the core) which exported a bunch o'
test_* routines that tested specific parts of the Python/C API. A
test_internal.py module would be added to the std regression test suite that
would import this module and call each of the exported test_* routines in
turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested.

Anybody have any opinions?


Trent

p.s. I have a patch largely (all except the above menntion limitation) ready
for this, including some tests that I used for my 64-bit porting stuff. 


-- 
Trent Mick
trentm at activestate.com



From skip at mojam.com  Tue Jun 27 19:11:33 2000
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 27 Jun 2000 12:11:33 -0500 (CDT)
Subject: [Python-Dev] semi-subtle atexit gotcha?
Message-ID: <14680.57413.385666.482385@beluga.mojam.com>

In thinking about the new atexit module a little more, it occurred to me
that I've handled the case where the atexit module gets loaded after another 
module that wants to set sys.exitfunc (it just incorporates that function
into its list of functions), but not if atexit gets loaded before another
modules that uses sys.exitfunc.  I see two possible choices:

    1. Punt and put a bit of verbiage in the atexit section of the library
       reference manual and the 1.6 release notes.

    2. Have atexit.register check each time it's called to see if
       sys.exitfunc is what it expects.  This isn't a perfect solution for a 
       couple reasons.  One, there's no guarantee that other sys.exitfunc- 
       modifying code isn't executed after the last call to
       atexit.register.  Two, there's no guarantee that the other code
       doesn't attempt to be "intelligent" in a fashion similar to atexit
       (can you say dueling banjos?).

I vote for option number one since there appears to be no guaranteed way to
make it work, but I'm open to other suggestions.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From trentm at activestate.com  Tue Jun 27 19:16:58 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 10:16:58 -0700
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>
References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>
Message-ID: <20000627101658.E7257@activestate.com>

On Mon, Jun 26, 2000 at 02:41:12PM -0400, Tim Peters wrote:
> Intended use of SourceForge patch status tags
> ---------------------------------------------
> revision 1                        26-Jun-2000
> 
> 
> Open
>     The initial status of all patches.
>     The patch is under consideration, but has not
>     been reviewed yet.
>     The status will normally change to Accepted or Rejected next.
>     The person submitting the patch should (if they can) assign
>     it to the person they most want to review it.
>     Else the patch will be assigned via
>         [xxx a list of expertise areas should be developed]

What are the chances of getting other meta data fields on patches, i.e.
changes to the patch manager? Categorizing patches could really help as a
filter. For instance, I may be a Unicode genius and would like to see the
patches associated with it.


>     Discussion of patches is carried out via
>         [xxx Python-Dev?  patches list?  without a mail gateway,
>              the SourceForge patch interface looks too clumsy
>              to use for controversial patches]

I like the separation of python-dev and patches, but it is not a biggie for
me.


> Postponed
>     The previous status was Open or Accepted, but for some reason
>     (e.g., pending release) the patch should not be reviewed or
>     applied until further notice.
>     The status will normally change to Open or Accepted next.
>     Please enter a comment when changing the status to Postponed,
>     to record the reason, the previous status, and the conditions
>     under which the patch should revert to Open or Accepted.

Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the
person responsible for later taking to patch out of 'postponed' status.



Trent


-- 
Trent Mick
trentm at activestate.com



From jeremy at beopen.com  Tue Jun 27 19:21:28 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 27 Jun 2000 13:21:28 -0400 (EDT)
Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <20000627095738.D7257@activestate.com>
References: <20000622193610.27452.qmail@eik.g.aas.no>
	<395272D0.B82A0353@lemburg.com>
	<m3r99pjvrx.fsf@eik.g.aas.no>
	<39531A20.1BEAA51E@lemburg.com>
	<m3hfak4tds.fsf@eik.g.aas.no>
	<14675.30233.658776.764865@localhost.localdomain>
	<m38zvwxn9u.fsf@eik.g.aas.no>
	<14679.36964.766774.864078@localhost.localdomain>
	<20000627095738.D7257@activestate.com>
Message-ID: <14680.58008.466802.160183@bitdiddle.concentric.com>

I think testing the C API directly is a great idea!  Sorry I missed it
the first time around.

I don't think I understand the suggested approach well enough to
critique it.  Most of the tests need to be written in C, right?  When
an error is encountered, it seems that you should check what the C API
returns *and* what happens at the Python level, i.e. whether the call
sets a Python exception (or clears an existing Python exception).

I guess you ought to show us the code.  I don't think it will go in
Python 1.6, but it sounds like a valuable component for future
releases. 

Jeremy



From trentm at activestate.com  Tue Jun 27 19:37:00 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 10:37:00 -0700
Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <14680.58008.466802.160183@bitdiddle.concentric.com>
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com>
Message-ID: <20000627103700.G7257@activestate.com>

On Tue, Jun 27, 2000 at 01:21:28PM -0400, Jeremy Hylton wrote:
> 
> I don't think I understand the suggested approach well enough to
> critique it.  Most of the tests need to be written in C, right?  When

All of the testing code would be in C, in the _testmodule.c, or whatever
name.

> an error is encountered, it seems that you should check what the C API
> returns *and* what happens at the Python level, i.e. whether the call
> sets a Python exception (or clears an existing Python exception).

Yes you are right. It depends on the API under test. Basically you just try
to test all conditions to ensure that the API behaves as expected/advertised.


> 
> I guess you ought to show us the code.  I don't think it will go in
> Python 1.6, but it sounds like a valuable component for future
> releases. 
> 

Okay. I agree that this would probably not make 1.6 so I will probably wait
on this for a little while. Busy.


Trent

-- 
Trent Mick
trentm at activestate.com



From trentm at activestate.com  Tue Jun 27 19:56:47 2000
From: trentm at activestate.com (Trent Mick)
Date: Tue, 27 Jun 2000 10:56:47 -0700
Subject: [Python-Dev] my dev status on SourceForge
In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com>
References: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com> <200006271430.JAA01769@cj20424-a.reston1.va.home.com>
Message-ID: <20000627105647.H7257@activestate.com>

SPeaking of surprising little SourceForge things:

I just made the mistake of clicking on the little garbage can beside "Python"
in "My Projects". I seem to have booted myself from the Python project. Can I
put myself back on? or can one of you with admin status please do that for
me?

my SourceForge username is: tmick

Sorry and thanks,
Trent




-- 
Trent Mick
trentm at activestate.com



From akuchlin at mems-exchange.org  Tue Jun 27 20:20:21 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 27 Jun 2000 14:20:21 -0400
Subject: [Python-Dev] curses/wrapper.py
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEICCOAA.mhammond@skippinet.com.au>
References: <20000627035202.M29590@lyra.org> <ECEPKNMJLHAPFFJHDOJBAEICCOAA.mhammond@skippinet.com.au>
Message-ID: <20000627142021.G19033@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 12:45:07AM +1000, Mark Hammond quoted:
>> Besides its redundancy, it also places the traceback into a
>> local variable
>> and then raises an exception -- a perfect recipe for creating a ref loop.

I think this is irrelevant for the curses.wrapper() function, which
simply restores the terminal state before re-raising the exception.
It probably won't ever be called repeatedly, making the question of a
memory leak moot.

Yes, I'd like to have wrapper() use Greg Stein's simpler and tidier
code.  Yes, I'd like to know why ESR claims the simpler version
doesn't work and have a replicable test case.  But right now there are
higher priority things to do, so I'm shelving this until after 1.6b1.
(Right now I'm trying to get the curses module compiling on Tru64, and
things don't look good.)

--amk




From pingster at ilm.com  Tue Jun 27 20:25:01 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Tue, 27 Jun 2000 11:25:01 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1
In-Reply-To: <14680.29842.372192.274003@temoleh.chem.uu.nl>
Message-ID: <Pine.SGI.3.96.1000627110923.621134C-100000@happy>

On Tue, 27 Jun 2000, Rob W. W. Hooft wrote:
>  AMK> --- NEW FILE ---
>  AMK> #
>  AMK> # ascii.py -- constants and memembership tests for ASCII characters
>  AMK> #
>                                   ^^^^^ two letters too much?

Grrrr... surely by now we should be getting docstrings instead of
comments at the top of modules!

In keeping with the format of most other modules, i also suggest
not repeating the module name.  Thus:

    """Constants and membership tests for ASCII characters."""



-- ?!ng

(166 irender improvements since May 1999)







From Vladimir.Marangozov at inrialpes.fr  Tue Jun 27 20:39:35 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Tue, 27 Jun 2000 20:39:35 +0200 (CEST)
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <no.id> from "Vladimir Marangozov" at Jun 27, 2000 06:23:52 PM
Message-ID: <200006271839.UAA05354@python.inrialpes.fr>

I'm resending this msg since it didn't seem to get through the 1st time
(and we're experiencing some major hw&sw router problems lately)

Vladimir Marangozov wrote:
> 
> Guido van Rossum wrote:
> > 
> > Here at BeOpen we're scrambling to get the release schedule for the
> > rest of Python 1.6 planned.  We're now looking at releasing Python
> > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30!
> > This means that if SRE isn't ready, we'll go with an incomplete SRE.
> > Still better than no SRE!
> > 
> > Please, PLEASE, if you have pending patches that you think should go
> > into 1.6b1, submit them to SourceForge.  We'll do our best to have a
> > look at every patch submitted; but don't wait until the last moment.
> 
> So, to sum up (because I'm a bit lost after all this patch-related
> messages), what should I do to avoid at best adding to the collective
> burden :
> 
> 1. Should I send patches to SF and be quiet until June 30 ?
> 
> 2. Should I apply for privileges and spend <big time> installing
>    an SSH client on my box (illegal in France ;), then make my Python
>    way into the SF galaxy ?
> 
> 3. If I volunteer for help with the patches backlog, what do I do ?
> 
> 4. Other options presented to me ?
> 
> Context : I (will) have some patches lying around, there are some
> patches of mine on the pile sent to patches at python.org that I'm
> confident about, I have read the FAQ at SF which gave me 0 clues
> on how things are being set up there (only general info about
> who why and what for + terms of service), and I managed to create
> an account with a personal page containing two bookmarks in it
> (after being distracted with personal and project ratings + gobs of
> links to gobs of stuff).
> 
> -- 
>        Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
> http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
> 


-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From paul at prescod.net  Tue Jun 27 20:46:40 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 11:46:40 -0700
Subject: [Python-Dev] winreg
References: <ECEPKNMJLHAPFFJHDOJBEEGICOAA.mhammond@skippinet.com.au> <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net> <02fe01bfe051$3df655b0$4500a8c0@thomasnb>
Message-ID: <3958F690.EDB27D07@prescod.net>

I'm trying to figure out all of the constants in _winreg. Some of them
seem related to functions that _winreg doesn't support. I won't put
those in new winreg because they can't be used. The only one I can't
figure out through web searches is REG_OPTION_OPEN_LINK.

RegNotifyChangeKeyValue (unsupported)
	REG_NOTIFY_CHANGE_NAME
	REG_NOTIFY_CHANGE_LAST_SET 
	REG_NOTIFY_CHANGE_SECURITY 
	REG_NOTIFY_CHANGE_ATTRIBUTES 

RegRestoreKey (unsupported)
	REG_FORCE_RESTORE
	REG_NO_LAZY_FLUSH
	REG_REFRESH_HIVE
	REG_WHOLE_HIVE_VOLATILE

RegCreateKeyEx (unxupported)
	REG_OPTION_RESERVED
	REG_OPTION_VOLATILE
	REG_OPTION_NON_VOLATILE
	REG_OPTION_BACKUP_RESTORE
	REG_CREATED_NEW_KEY
	REG_OPENED_EXISTING_KEY
	REG_OPTION_CREATE_LINK

I presume that nobody intends to add these three functions to _winreg in
time for Python 1.6!

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From effbot at telia.com  Tue Jun 27 21:25:23 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 21:25:23 +0200
Subject: [Python-Dev] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
References: <200006270050.RAA26210@slayer.i.sourceforge.net> <20000627035202.M29590@lyra.org> <20000627125053.B6531@thyrsus.com>
Message-ID: <001f01bfe06d$753492a0$f2a6b5d4@hagrid>

Eric S. Raymond wrote:
> What happened is that your version failed to pass an error exception upwards
> after fielding it.  My test case was a buggy version of cmlconfigure.py, bug
> since fixed.
> 
> Cleanliness is good, but the code has to work first.

umm.  as far as I can tell from the patch, there's no way your
code can work in a situation where try/finally wouldn't do exactly
the same thing.

if you *do* get different results (try inserting "raise whatever"
in the try clause to test this), it might be that you've stumbled
upon a real bug (either in Python or in the curses C bindings)...

</F>




From guido at beopen.com  Tue Jun 27 22:25:49 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 15:25:49 -0500
Subject: [Python-Dev] Re: my dev status on SourceForge
In-Reply-To: Your message of "Tue, 27 Jun 2000 10:56:47 MST."
             <20000627105647.H7257@activestate.com> 
References: <LNBBLJKPBEHFEDALKOLCAEAFGGAA.tim_one@email.msn.com> <200006271430.JAA01769@cj20424-a.reston1.va.home.com>  
            <20000627105647.H7257@activestate.com> 
Message-ID: <200006272025.PAA04010@cj20424-a.reston1.va.home.com>

> SPeaking of surprising little SourceForge things:
> 
> I just made the mistake of clicking on the little garbage can beside "Python"
> in "My Projects". I seem to have booted myself from the Python project. Can I
> put myself back on? or can one of you with admin status please do that for
> me?
> 
> my SourceForge username is: tmick

OK, you're back!

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



From pingster at ilm.com  Tue Jun 27 21:38:15 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Tue, 27 Jun 2000 12:38:15 -0700 (PDT)
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <3958D89E.39D084C8@lemburg.com>
Message-ID: <Pine.SGI.3.96.1000627123233.621134G-100000@happy>

On Tue, 27 Jun 2000, M.-A. Lemburg wrote:
> I've received the first round of notification message from the
> patch manager and can't really say that I like them.

I wish i could propose Roundup, but it currently lacks the
ability to decode e-mail attachments.  Aside from that, it
has reasonable (if basic) e-mail handling, colour-coded
status and priorities, and so on.

I would jump on it in a second except that the Software
Carpentry deadline is also this Friday and i'm still barely
pulling that thing together.

Of course, if you feel like hacking it up to do attachments
feel free to get it at http://pingster.com/roundup.html and
hack away!

Alternatively i suppose you could keep the patch files on
SourceForge and do the discussions in Roundup as an interim
solution?  Messy, i know, but it might be an improvement.



-- ?!ng




From paul at prescod.net  Tue Jun 27 21:45:16 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 27 Jun 2000 12:45:16 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses 
 ascii.py,NONE,1.1 textpad.py,NONE,1.1
References: <Pine.SGI.3.96.1000627110923.621134C-100000@happy>
Message-ID: <3959044C.B5C537FA@prescod.net>

Ka-Ping Yee wrote:
> 
> -- ?!ng
> 
> (166 irender improvements since May 1999)

> Although some shots were composited with Sabre, ILM's extensions 
> to Discreet Logic's Flame and Inferno software, CompTime was 
> the compositing tool for the CG department, according to 
> Jeff Yost. First used for one shot in Saving Private Ryan, 
> CompTime is based on the studio's long-time scripted system, but 
> now boasts a graphical user interface and hooks for plug-ins that 
> can be written in Python or C++. 

Is it safe to say that "Without Python, Saving Private Ryan would not
have been possible, much less an Oscar winner?"

-- 
 Paul Prescod - Not encumbered by corporate consensus
When George Bush entered office, a Washington Post-ABC News poll found
that 62 percent of Americans "would be willing to give up a few of the
freedoms we have" for the war effort. They have gotten their wish.
	- "This is your bill of rights...on drugs", Harpers, Dec. 1999



From effbot at telia.com  Tue Jun 27 22:01:26 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 22:01:26 +0200
Subject: [Python-Dev] Re: testing the Python/C API
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com> <20000627103700.G7257@activestate.com>
Message-ID: <006801bfe072$7abc0820$f2a6b5d4@hagrid>

trent wrote:
> > I don't think I understand the suggested approach well enough to
> > critique it.  Most of the tests need to be written in C, right?  When
> 
> All of the testing code would be in C, in the _testmodule.c, or whatever
> name.

SWIG, anyone?

</F>




From effbot at telia.com  Tue Jun 27 22:06:30 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 27 Jun 2000 22:06:30 +0200
Subject: [Python-Dev] SF patch manager...
References: <3958D89E.39D084C8@lemburg.com>
Message-ID: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>

mal wrote:

> I've received the first round of notification message from the
> patch manager and can't really say that I like them. Ok, I 
> understand that the patch manager is still alpha or beta software,
> but these messages really don't have any usable content at all:
> 
> """
> Patch #100646 has been updated. 
> Visit SourceForge.net for more info.
> 
> http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470
> """
> 
> Also, reviewing the patches has become a pain and discussing them
> is nearly impossible (I don't consider the slashdot like comment
> mechanism to be of any use: there's simply no audience for
> discussion).
> 
> Is there any chance of tee'ing patches from SF to the patches
> list or some other patch discussion and review forum ? I do
> understand that the mechanism can help with patch *checkins*,
> but it's certainly not going to help much with the discussion
> step needed before conidering any actions. The independent
> peer review principal doesn't work with this kind of setup.

I fully agree.

someone really needs to fuse the patch manager with roundup (that
we should use roundup for bug tracking goes without saying...)

how much work would it be to move the entire repository over to
pythonlabs, btw?  sourceforget is frustratingly slow...

</F>




From guido at beopen.com  Tue Jun 27 23:07:41 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:07:41 -0500
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names)
In-Reply-To: Your message of "Tue, 27 Jun 2000 09:57:38 MST."
             <20000627095738.D7257@activestate.com> 
References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <m3r99pjvrx.fsf@eik.g.aas.no> <39531A20.1BEAA51E@lemburg.com> <m3hfak4tds.fsf@eik.g.aas.no> <14675.30233.658776.764865@localhost.localdomain> <m38zvwxn9u.fsf@eik.g.aas.no> <14679.36964.766774.864078@localhost.localdomain>  
            <20000627095738.D7257@activestate.com> 
Message-ID: <200006272107.QAA04498@cj20424-a.reston1.va.home.com>

> I asked the question a while back if it would reasonable/useful/popular to
> have a mechanism where parts of the Python/C Api could be tested directly.
> 
> My proposal used an extension module _testmodule (although I made it a core
> module on UN*X it should not bog down the core) which exported a bunch o'
> test_* routines that tested specific parts of the Python/C API. A
> test_internal.py module would be added to the std regression test suite that
> would import this module and call each of the exported test_* routines in
> turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested.
> 
> Anybody have any opinions?
> 
> 
> Trent
> 
> p.s. I have a patch largely (all except the above menntion limitation) ready
> for this, including some tests that I used for my 64-bit porting stuff. 

Great idea.  Please wait for 1.7.  There *will* be releases after 1.6!

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



From guido at beopen.com  Tue Jun 27 23:08:42 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:08:42 -0500
Subject: [Python-Dev] semi-subtle atexit gotcha?
In-Reply-To: Your message of "Tue, 27 Jun 2000 12:11:33 EST."
             <14680.57413.385666.482385@beluga.mojam.com> 
References: <14680.57413.385666.482385@beluga.mojam.com> 
Message-ID: <200006272108.QAA04509@cj20424-a.reston1.va.home.com>

> In thinking about the new atexit module a little more, it occurred to me
> that I've handled the case where the atexit module gets loaded after another 
> module that wants to set sys.exitfunc (it just incorporates that function
> into its list of functions), but not if atexit gets loaded before another
> modules that uses sys.exitfunc.  I see two possible choices:
> 
>     1. Punt and put a bit of verbiage in the atexit section of the library
>        reference manual and the 1.6 release notes.
> 
>     2. Have atexit.register check each time it's called to see if
>        sys.exitfunc is what it expects.  This isn't a perfect solution for a 
>        couple reasons.  One, there's no guarantee that other sys.exitfunc- 
>        modifying code isn't executed after the last call to
>        atexit.register.  Two, there's no guarantee that the other code
>        doesn't attempt to be "intelligent" in a fashion similar to atexit
>        (can you say dueling banjos?).
> 
> I vote for option number one since there appears to be no guaranteed way to
> make it work, but I'm open to other suggestions.

Yes, #1 is good enough.  I don't think there will be lots of people
bitten by this...

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



From guido at beopen.com  Tue Jun 27 23:11:46 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:11:46 -0500
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Tue, 27 Jun 2000 10:16:58 MST."
             <20000627101658.E7257@activestate.com> 
References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>  
            <20000627101658.E7257@activestate.com> 
Message-ID: <200006272111.QAA04542@cj20424-a.reston1.va.home.com>

> What are the chances of getting other meta data fields on patches, i.e.
> changes to the patch manager? Categorizing patches could really help as a
> filter. For instance, I may be a Unicode genius and would like to see the
> patches associated with it.

Good idea.  The PM clearly needs work.  I see two places where you
could submit feature requests: (1) the "Report SF Bug" item in the
left side bar; (2) the "Feature Requests" discussion forum
(http://sourceforge.net/forum/forum.php?forum_id=4&et=0)

> I like the separation of python-dev and patches, but it is not a biggie for
> me.

For me it's just an annoyance, especially when cross-posting is used.

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



From guido at beopen.com  Tue Jun 27 23:36:57 2000
From: guido at beopen.com (Guido van Rossum)
Date: Tue, 27 Jun 2000 16:36:57 -0500
Subject: [Python-Dev] python.org mail unclogged
Message-ID: <200006272136.QAA04723@cj20424-a.reston1.va.home.com>

It seems we've removed a major source of email cloggage on python.org
-- a site in France was hitting every page in the mailman membership
administration using a commercial crawler (Teleport Pro) that didn't
honor our robots.txt file, and forking a 4 Mb CGI script for each user
in each mailing list.  Thanks for Barry and Andrew!  This was on top
of problems caused when the Ultraseek crawler ran out of memory and
caused postfix or mailman to fail. :-(

Mail seems to be flowing again, the queues are emptying.  Once we're
happy, we'll turn on the Ultraseek crawler and search service.

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



From jeremy at beopen.com  Tue Jun 27 22:54:38 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 27 Jun 2000 16:54:38 -0400 (EDT)
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <Pine.SGI.3.96.1000627123233.621134G-100000@happy>
References: <3958D89E.39D084C8@lemburg.com>
	<Pine.SGI.3.96.1000627123233.621134G-100000@happy>
Message-ID: <14681.5262.464079.557095@bitdiddle.concentric.com>

Maybe the right solution is to work with the SourceForge maintainers
to make roundup part of the standard support software.  

jeremy



From fdrake at beopen.com  Tue Jun 27 23:01:54 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 27 Jun 2000 17:01:54 -0400 (EDT)
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <20000627101658.E7257@activestate.com>
References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCAEPCGFAA.tim_one@email.msn.com>
	<20000627101658.E7257@activestate.com>
Message-ID: <14681.5698.732269.523890@cj42289-a.reston1.va.home.com>

Trent Mick writes:
 > Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the
 > person responsible for later taking to patch out of 'postponed' status.

  Agreed; assignment should be changed whenever the next person
required to deal with it changes.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From nascheme at enme.ucalgary.ca  Tue Jun 27 23:05:55 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Tue, 27 Jun 2000 15:05:55 -0600
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 27, 2000 at 10:06:30PM +0200
References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid>
Message-ID: <20000627150555.A3083@acs.ucalgary.ca>

On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote:
> how much work would it be to move the entire repository over to
> pythonlabs, btw?  sourceforget is frustratingly slow...

rsync access to the CVS repository would be nice too.  rsync
should be faster than "cvs update".  Also, once you have the
whole repository making diffs and checking out different versions
is much faster.

  Neil

-- 
"I saw `cout' being shifted "Hello world" times to the
left and stopped right there."  -- Steve Gonedes



From jeremy at beopen.com  Tue Jun 27 23:49:01 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 27 Jun 2000 17:49:01 -0400 (EDT)
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <20000627150555.A3083@acs.ucalgary.ca>
References: <3958D89E.39D084C8@lemburg.com>
	<007801bfe073$3008b0c0$f2a6b5d4@hagrid>
	<20000627150555.A3083@acs.ucalgary.ca>
Message-ID: <14681.8525.343786.194271@bitdiddle.concentric.com>

>>>>> "NS" == Neil Schemenauer <nascheme at enme.ucalgary.ca> writes:

  NS> On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote:
  >> how much work would it be to move the entire repository over to
  >> pythonlabs, btw?  sourceforget is frustratingly slow...

  NS> rsync access to the CVS repository would be nice too.  rsync
  NS> should be faster than "cvs update".  Also, once you have the
  NS> whole repository making diffs and checking out different
  NS> versions is much faster.

Absolutely!  OpenSSL works this way and I find it much more convenient
than using a remote CVS server.  I use commands like diff, log, and
annotate frequently during development.

Have you suggested that as a SourceForge feature?

Jeremy



From akuchlin at mems-exchange.org  Tue Jun 27 23:47:07 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 27 Jun 2000 17:47:07 -0400
Subject: [Python-Dev] Testdrive systems
Message-ID: <20000627174707.P19033@kronos.cnri.reston.va.us>

Portability-related note: I've just fixed a reported compilation
problem with the curses module on Tru64 Unix using a machine made
available by Compaq.  If you go to http://www.testdrive.compaq.com/,
you can sign up for a free 30-day account on a variety of machines:
Alphas running Tru64, FreeBSD, and Linux, and Intel machines running
BSD or Linux.  A nice way to fix reported problems quickly...  The
environment on the systems is a bit Spartan; emacs is there, but no
fancy shells and no CVS (which is especially annoying).

--amk



From nascheme at enme.ucalgary.ca  Wed Jun 28 00:56:09 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Tue, 27 Jun 2000 16:56:09 -0600
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <14681.8525.343786.194271@bitdiddle.concentric.com>; from jeremy@beopen.com on Tue, Jun 27, 2000 at 05:49:01PM -0400
References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <20000627150555.A3083@acs.ucalgary.ca> <14681.8525.343786.194271@bitdiddle.concentric.com>
Message-ID: <20000627165609.A3941@acs.ucalgary.ca>

On Tue, Jun 27, 2000 at 05:49:01PM -0400, Jeremy Hylton wrote:
> Have you suggested [rsync access to CVS] as a SourceForge feature?

Nope.  Be my guest. :)

  Neil



From tim_one at email.msn.com  Wed Jun 28 02:11:44 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Jun 2000 20:11:44 -0400
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <3958D89E.39D084C8@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEMBGGAA.tim_one@email.msn.com>

[MAL]
> [Please excuse my ranting... :-)]

No problem -- you're not complaining about *our* software <wink>.

> I've received the first round of notification message from the
> patch manager and can't really say that I like them. Ok, I
> understand that the patch manager is still alpha or beta software,
> but these messages really don't have any usable content at all:
>
> """
> Patch #100646 has been updated.
> Visit SourceForge.net for more info.
>
>
http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470
> """

I expect the title of the patch was also in the Subject line, yes?  And a
live link to the patch is certainly "usable".  I've found both those right
on target as I've been assigned or deassigned to patches so far, although
I'd sure like to see something in the body saying exactly *what* about the
patch "has been updated".

Not saying I think it's good enough, am saying it's (barely) a start.

> Also, reviewing the patches has become a pain

I don't understand that, in that the text of the patch is what you got
before, and what you can get now.  Is your complaint here specifically that
patches don't show up in your mailbox by magic?  Or something else?

> and discussing them is nearly impossible (I don't consider the
> slashdot like comment mechanism to be of any use: there's simply
> no audience for discussion).

Wholly agreed there.  So use python-dev for discussions for now; I agree too
with Guido that the rampant but inconsistent x-posting between patches and
python-dev was part of the problem.

> Is there any chance of tee'ing patches from SF to the patches
> list or some other patch discussion and review forum ?

I expect you know as much about SF's possibilities as anyone <0.5 wink>:
don't know.  The SF docs are either non-existent or inadequate, far as I can
tell, and I believe I share a mistaken belief with Fred Drake that new
patches "should" *already* be showing up on the patches list.

> I do understand that the mechanism can help with patch *checkins*,

Yes, but not yet as much as it should (e.g., the default view of patches
lacks basic info like the patch current status, and there's apparently not
yet any way to define a different view).

> but it's certainly not going to help much with the discussion
> step needed before conidering any actions.

Python-Dev now, possibly roundup later.  OTOH, it's perfectly adequate for
tiny little principal-reviewer <-> submitter give-and-take; many patches are
really quite trivial.

> The independent peer review principal doesn't work with this
> kind of setup.

I think your view is warped on this one, as you've been in the extremely
favored position of pumping out crucial patches for a hot area.  Most other
peoples' patches have been flatly ignored for *months* now.  It's not
necessarily bad if other people get some attention now too <wink>.





From tim_one at email.msn.com  Wed Jun 28 02:11:52 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Jun 2000 20:11:52 -0400
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEMBGGAA.tim_one@email.msn.com>

[Fredrik Lundh]
> ...
> how much work would it be to move the entire repository over to
> pythonlabs, btw?

Impossibly more than we could make time for soon.

> sourceforget is frustratingly slow...

'Tis very erratic indeed.  It *can* be speedy, but that seems much more the
exception than the rule.





From pingster at ilm.com  Wed Jun 28 01:29:04 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Tue, 27 Jun 2000 16:29:04 -0700 (PDT)
Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager
In-Reply-To: <200006272111.QAA04542@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.SGI.3.96.1000627144959.621134U-100000@happy>

Fredrik Lundh wrote:
> someone really needs to fuse the patch manager with roundup (that
> we should use roundup for bug tracking goes without saying...)

How sweet!  Why, thank you. :)

Trent Mick wrote:
> What are the chances of getting other meta data fields on patches, i.e.
> changes to the patch manager? Categorizing patches could really help as a
> filter. For instance, I may be a Unicode genius and would like to see the
> patches associated with it.

I agree that doing that kind of filtering is very useful.  I have
a discussion thingie (based on Roundup) at http://headspaces.com/.
(Also prototype -- very prototype.)  I hacked out the "status" and
"fixer" fields and added a "keywords" field.  Not much volume yet,
but i think it will work well.

Perhaps something like that for discussing patches?

Jeremy Hylton wrote:
> Maybe the right solution is to work with the SourceForge maintainers
> to make roundup part of the standard support software.  

Hmmm... maybe i should look into that after i've figured out how
super-Roundup is going to work.


-- ?!ng





From gward at python.net  Wed Jun 28 02:58:43 2000
From: gward at python.net (Greg Ward)
Date: Tue, 27 Jun 2000 20:58:43 -0400
Subject: [Python-Dev] DOS text files and CVS
Message-ID: <20000627205843.A1607@beelzebub>

Hi all --

can anyone enlighten me on the right way to check in DOS text files to a 
CVS repository?  I have Thomas Heller's C source for his simple
graphical installer for Python modules, and it should definitely be in
the Distutils CVS tree.  But I don't want to check it in if it'll screw
up line-endings for anyone.  Is there a Right Way to do this?

Thanks --

        Greg
-- 
Greg Ward - Linux nerd                                  gward at python.net
http://starship.python.net/~gward/
Just because you're paranoid doesn't mean they *aren't* out to get you.



From tim_one at email.msn.com  Wed Jun 28 03:13:54 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Jun 2000 21:13:54 -0400
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <017501bfe023$684fca40$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEMFGGAA.tim_one@email.msn.com>

[Fredrik Lundh]
> (tim? where's the second installment of your sourceforge vs.
> windows series?)

Waiting for you to finish SRE <wink>.  Seriously, I don't *need* to get
Windows checkin access for the imminent release, so I moved this down my
priority list.  I needed to move *something* down because finding a place to
live around here is both urgent & consuming much more time than I had
planned on (vacancy rate:  0%).  Windows vs SourceForge is still on my
plate, and I'm not giving up on it, just slipping it.

just-carrying-my-plans-between-the-bathroom-&-the-bed-is-
    invigorating-exercise-ly y'rs  - tim





From mhammond at skippinet.com.au  Wed Jun 28 03:18:44 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Jun 2000 11:18:44 +1000
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEMFGGAA.tim_one@email.msn.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEJECOAA.mhammond@skippinet.com.au>

> just-carrying-my-plans-between-the-bathroom-&-the-bed-is-
>     invigorating-exercise-ly y'rs  - tim

Your plans, or your pans?

I-knew-you-were-old-but-not-that-old-<wink>-ly,

Mark.




From tim_one at email.msn.com  Wed Jun 28 03:39:31 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Jun 2000 21:39:31 -0400
Subject: [Python-Dev] RE: [Distutils] DOS text files and CVS
In-Reply-To: <20000627205843.A1607@beelzebub>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEMIGGAA.tim_one@email.msn.com>

[Greg Ward]
> can anyone enlighten me on the right way to check in DOS text files to a
> CVS repository?

Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe
you need to convince CVS that it's a binary (not text) file.  Then it will
skip line-end conversions.

not-a-solution-but-maybe-a-clue-ly y'rs  - tim





From gstein at lyra.org  Wed Jun 28 03:46:15 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 18:46:15 -0700
Subject: [Python-Dev] add Demo/imputil/importers.py ?
Message-ID: <20000627184615.A29590@lyra.org>

A while back, I pulled the "demo" importers out of imputil.py. I think those
should be added into Demo/imputil/.

It would also be Goodness to include JimA's zipimporter. Where would that go?

Cheers,
-g

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



From gmcm at hypernet.com  Wed Jun 28 03:47:30 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 27 Jun 2000 21:47:30 -0400
Subject: [Python-Dev] DOS text files and CVS
In-Reply-To: <20000627205843.A1607@beelzebub>
Message-ID: <1249965584-36289880@hypernet.com>

Greg Ward asks:

> can anyone enlighten me on the right way to check in DOS text
> files to a CVS repository?  I have Thomas Heller's C source for
> his simple graphical installer for Python modules, and it should
> definitely be in the Distutils CVS tree.  But I don't want to
> check it in if it'll screw up line-endings for anyone.  Is there
> a Right Way to do this?

Well, if you checked it in from a Windows box, CVS would 
translate line endings to native, then a Windows checkout 
would translate back to Windows endings.

So assuming you don't want to get your fingers dirty, give it 
*n*x line endings and check it in.

CVS does understand text, you know :-).

(And about the only Windows editor that barfs on *n*x line 
endings is Notepad.)


- Gordon



From arnold at dstc.monash.edu.au  Wed Jun 28 03:50:24 2000
From: arnold at dstc.monash.edu.au (David Arnold)
Date: Wed, 28 Jun 2000 11:50:24 +1000
Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS
In-Reply-To: Your message of "Tue, 27 Jun 2000 21:39:31 -0400."
             <LNBBLJKPBEHFEDALKOLCAEMIGGAA.tim_one@email.msn.com> 
Message-ID: <200006280150.LAA17759@xevious.dstc.monash.edu.au>

-->"Tim" == Tim Peters <tim_one at email.msn.com> writes:

  Tim> Aargh, I haven't used CVS in about 6 years ... somehow or
  Tim> other, I believe you need to convince CVS that it's a binary
  Tim> (not text) file.  Then it will skip line-end conversions.

cvs add -kb file

should work to add a binary file.  not sure that this is the best way
to deal with DOS files, but it should work ...



d



From amk1 at erols.com  Wed Jun 28 04:04:53 2000
From: amk1 at erols.com (A.M. Kuchling)
Date: Tue, 27 Jun 2000 22:04:53 -0400
Subject: [Python-Dev] Text about cycle GC
Message-ID: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>

I've written some text for the What's New article on the GCing of
cycles, but it wasn't a topic I paid close attention to at the time,
so I'd like corrections.  Here's what I've got; please send me
comments privately. 

                       6. Optional Collection of Cycles

   The C implementation of Python uses reference counting to implement
   garbage collection. Every Python object maintains a count of the
   number of references pointing to itself, and adjusts the count as
   references are created or destroyed. Once the reference count reaches
   zero, the object is no longer accessible, since you need to have a
   reference to an object to access it, and if the count is zero, no
   references exist any longer.

   Reference counting has some pleasant properties: it's easy to
   understand and implement, and the resulting implementation is
   portable, fairly fast, and reacts well with other libraries that
   implement their own memory handling schemes. The major problem with
   reference counting is that it sometimes doesn't realise that objects
   are no longer accessible, resulting in a memory leak. This happens
   when there are cycles of references.

   Consider the simplest possible cycle, a class instance which has a
   reference to itself:

instance = SomeClass()
instance.myself = instance

   After the above two lines of code have been executed, the reference
   count of instance is 2; one reference is from the variable named
   "'instance'", and the other is from the "myself"attribute of the
   instance.

   If the next line of code is del instance, what happens? The reference
   count of instance is decreased by 1, so it has a reference count of 1;
   the reference in the "myself" attribute still exists. Yet the instance
   is no longer accessible through Python code, and it could be deleted.
   Several objects can participate in a cycle if they have references to
   each other, causing all of the objects to be leaked.

   An experimental step has been made toward fixing this problem. When
   compiling Python, the -with-cycle-gc (XXX correct option flag?) option
   can be specified. This causes a cycle detection algorithm to be
   periodically executed, which looks for inaccessible cycles and deletes
   the objects involved.

   Why isn't this enabled by default? Running the cycle detection
   algorithm takes some time, and some tuning will be required to
   minimize the overhead cost. It's not yet obvious how much performance
   is lost, because benchmarking this is tricky and depends sensitively
   on how often the program creates and destroys objects. XXX is this
   actually the correct reason? Or is it fear of breaking software that
   runs happily while leaving garbage?

   Several people worked on this problem. Early versions were written by
   XXX1, XXX2. (I vaguely remember several people writing first cuts at
   this. Anyone recall who?) The implementation that's in Python 1.6 is a
   rewritten version, this time done by Neil Schemenauer. Lots of other
   people offered suggestions along the way, such as (in alphabetical
   order) Marc-Andr? Lemburg, Tim Peters, Greg Stein, Eric Tiedemann. 
   (XXX other names?  If you feel you should be added, e-mail me).  The
   March 2000 archives of the python-dev mailing list contain most of the
   relevant discussion, especially in the threads titled ``Reference
   cycle collection for Python'' and ``Finalization again''.




From ians at amc.com  Wed Jun 28 03:51:45 2000
From: ians at amc.com (Ian Searle)
Date: Tue, 27 Jun 2000 18:51:45 -0700
Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS
References: <LNBBLJKPBEHFEDALKOLCAEMIGGAA.tim_one@email.msn.com>
Message-ID: <39595A31.6462CA42@amc.com>

The best way to check DOS text files into CVS is from a Windows/DOS
machine using the CVS client/pserver route.  Using this method, the
files are stored in canonical format.  When someone checks them out from
a Unix client they get /n only.  And, when someone checks them out from
a Windows/DOS client, they get /r/n.  And, everyone is happy (well, as
much as can be expected :-)  

If you do a 'cvs add -kb foo.dos-txt' then CVS will treat the file as
binary and forego the keyword substitutions and end of line
translations.  But, folks checking them out will always get the /r/n
regardless of platform.

-Ian

Tim Peters wrote:
> 
> [Greg Ward]
> > can anyone enlighten me on the right way to check in DOS text files to a
> > CVS repository?
> 
> Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe
> you need to convince CVS that it's a binary (not text) file.  Then it will
> skip line-end conversions.
> 
> not-a-solution-but-maybe-a-clue-ly y'rs  - tim
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://www.python.org/mailman/listinfo/distutils-sig



From akuchlin at cnri.reston.va.us  Wed Jun 28 04:04:15 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Tue, 27 Jun 2000 22:04:15 -0400
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <20000627184615.A29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 06:46:15PM -0700
References: <20000627184615.A29590@lyra.org>
Message-ID: <20000627220415.A22246@newcnri.cnri.reston.va.us>

On Tue, Jun 27, 2000 at 06:46:15PM -0700, Greg Stein wrote:
>A while back, I pulled the "demo" importers out of imputil.py. I think those
>should be added into Demo/imputil/.

While on the subject of adding demo directories, I'd like to add a
Demo/curses directory.  (Not going to happen until after b1, though;
cute little demos aren't a high priority at the moment.)

--amk



From bwarsaw at beopen.com  Wed Jun 28 04:25:47 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 27 Jun 2000 22:25:47 -0400 (EDT)
Subject: [Python-Dev] DOS text files and CVS
References: <20000627205843.A1607@beelzebub>
Message-ID: <14681.25131.166235.152210@anthem.concentric.net>

>>>>> "GW" == Greg Ward <gward at python.net> writes:

    GW> can anyone enlighten me on the right way to check in DOS text
    GW> files to a CVS repository?  I have Thomas Heller's C source
    GW> for his simple graphical installer for Python modules, and it
    GW> should definitely be in the Distutils CVS tree.  But I don't
    GW> want to check it in if it'll screw up line-endings for anyone.
    GW> Is there a Right Way to do this?

If there's no reason why it /has/ to be DOS text, convert it to Unix
line endings first.  XEmacs will even do the conversion for you!  That
is, if the other suggestions people have made don't help.

-Barry



From skip at mojam.com  Wed Jun 28 04:51:03 2000
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 27 Jun 2000 21:51:03 -0500 (CDT)
Subject: [Python-Dev] readline history read/write
Message-ID: <14681.26647.228866.236111@beluga.mojam.com>


The original thing that motivated me to propose what became atexit.py was my 
desire to read and write readline history files.  The two attached context
diffs patch Modules/readline.c and Lib/rlcompleter.py to do that.  Two new
functions are added to the readline module and rlcompleter is tweaked to
read the history file referenced by the PYTHONHISTORY environment variable
(if it's defined) and automatically save it when the interpreter exits.

I'm looking for a little feedback.  Here are a few things that jumped to my
mind:

    1. Is it okay to add the read and register/write code to rlcompleter.py?
       Reading and writing readline history files doesn't have anything
       directly to do with identifier completion, but they both have to do
       with readline.

    2. Assuming that history file read/write is desired, should it be
       predicated on the presence of an environment variable or (as in bash
       and other readline-aware programs) should it just happen?

    3. Am I correct in assuming that this capability will only be available
       to Unix/Linux environments, or is readline generally available, thus
       forcing me to think about cross-platform issues?

    4. Is there some mechanism already present in IDLE and/or PythonWin I
       should be aware of and try to emulate?

The two context diffs are both short.  You should be able to follow
everything just by reading the bits of code.  Offering your thoughts on the
above questions shouldn't require actually modifying your interpreter.

Thx,

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: readline.dif
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000627/c023ec0e/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rlcompleter.dif
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000627/c023ec0e/attachment-0001.asc>

From gstein at lyra.org  Wed Jun 28 05:08:46 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 20:08:46 -0700
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEMBGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 08:11:52PM -0400
References: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <LNBBLJKPBEHFEDALKOLCKEMBGGAA.tim_one@email.msn.com>
Message-ID: <20000627200846.D29590@lyra.org>

On Tue, Jun 27, 2000 at 08:11:52PM -0400, Tim Peters wrote:
> [Fredrik Lundh]
> > ...
> > how much work would it be to move the entire repository over to
> > pythonlabs, btw?
> 
> Impossibly more than we could make time for soon.
> 
> > sourceforget is frustratingly slow...
> 
> 'Tis very erratic indeed.  It *can* be speedy, but that seems much more the
> exception than the rule.

hehe... I have 30ms pings and have observed multiple Mb/sec :-)

download.sourceforge.net is excellent given those stats...

Of course, I'm practically just down the street.

Cheers,
-g

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



From tim_one at email.msn.com  Wed Jun 28 05:13:52 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Jun 2000 23:13:52 -0400
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <20000627200846.D29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>

[Greg Stein]
> hehe... I have 30ms pings and have observed multiple Mb/sec :-)
>
> download.sourceforge.net is excellent given those stats...
>
> Of course, I'm practically just down the street.

Would please send me the Python script you use to configure Win98 so that I
can get multiple Mb/sec too?  Thanks in advance.  I always *knew* there was
a secret way to boost these 56K laptop modems <wink>.

keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's-
    basement-ly y'rs  - tim





From gstein at lyra.org  Wed Jun 28 05:25:31 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 20:25:31 -0700
Subject: [Python-Dev] SF patch manager...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 11:13:52PM -0400
References: <20000627200846.D29590@lyra.org> <LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>
Message-ID: <20000627202531.G29590@lyra.org>

On Tue, Jun 27, 2000 at 11:13:52PM -0400, Tim Peters wrote:
> [Greg Stein]
> > hehe... I have 30ms pings and have observed multiple Mb/sec :-)
> >
> > download.sourceforge.net is excellent given those stats...
> >
> > Of course, I'm practically just down the street.
> 
> Would please send me the Python script you use to configure Win98 so that I
> can get multiple Mb/sec too?  Thanks in advance.  I always *knew* there was
> a secret way to boost these 56K laptop modems <wink>.

DSL big boy! DSL!

And I use a real OS :-)

> keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's-
>     basement-ly y'rs  - tim

eek!

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



From tim_one at email.msn.com  Wed Jun 28 06:11:22 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 00:11:22 -0400
Subject: [Python-Dev] ANN: Release schedule
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBCEJECOAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCGENEGGAA.tim_one@email.msn.com>

>> just-carrying-my-plans-between-the-bathroom-&-the-bed-is-
>>     invigorating-exercise-ly y'rs  - tim

[Mark Hammond]
> Your plans, or your pans?
>
> I-knew-you-were-old-but-not-that-old-<wink>-ly,

My pans are in storage somewhere in Baltimore, so I can't report on their
possible growth.  Or is this an Australian thing <wink>?

put-another-pan-on-the-barbie-mate?-ly y'rs  - tim


PS:  My testicles *have* grown since I moved to VA!  I'm wondering whether
it's an early symptom of Lyme disease.  They're still easy to carry from
room to room, though, provided simply I'm careful not to trip over them.





From bwarsaw at beopen.com  Wed Jun 28 06:13:32 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 00:13:32 -0400 (EDT)
Subject: [Python-Dev] SF patch manager...
References: <20000627200846.D29590@lyra.org>
	<LNBBLJKPBEHFEDALKOLCEENAGGAA.tim_one@email.msn.com>
Message-ID: <14681.31596.221693.491788@anthem.concentric.net>

>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:

    TP> keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's-
    TP> basement-ly y'rs - tim

Say the word, send me some hardware, and I'll clear a space between
the drums, bass rig, and litter boxes.

cover-it-in-sisal-and-even-the-cats'll-be-happy-ly y'rs,
-Barry



From tim_one at email.msn.com  Wed Jun 28 07:04:36 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 01:04:36 -0400
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <20000627095738.D7257@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMENGGGAA.tim_one@email.msn.com>

[Trent Mick]
> I asked the question a while back if it would reasonable/useful/popular
> to have a mechanism where parts of the Python/C Api could be tested
> directly.

Not only reasonable, IMO it's essential.  "If it's not tested, it's broken."
Tattoo that on your neighbor's forehead so it's always in mind <wink>.
Every time we get a legit bug report on Python, I view it as a failure of
the test suite.  That's one of the things I hope to spend a lot of time on
(but have not been promised I can spend any time on -- aren't startups great
<wink>?).

> My proposal used an extension module _testmodule (although I made
> it a core module on UN*X it should not bog down the core) which exported
> a bunch o' test_* routines that tested specific parts of the Python/C
> API. A test_internal.py module would be added to the std regression test
> suite that would import this module and call each of the exported test_*
> routines in turn. This would allow things like the _GetAttr/_SetAttr
> behaviour to be tested.
>
> Anybody have any opinions?

Great start!  But the people who most need to take this seriously (including
but not limited to me) have no bandwidth to spare before 1.6 is out the
door.

focus!-it's-not-just-for-breakfast-anymore-ly y'rs  - tim





From DavidA at ActiveState.com  Wed Jun 28 07:33:37 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 27 Jun 2000 22:33:37 -0700
Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given   non-string names)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMENGGGAA.tim_one@email.msn.com>
Message-ID: <LMBBIEIJKMPMLBONJMFCOEKFCJAA.DavidA@ActiveState.com>

> [Trent Mick]
> > I asked the question a while back if it would reasonable/useful/popular
> > to have a mechanism where parts of the Python/C Api could be tested
> > directly.
>
> Not only reasonable, IMO it's essential.  "If it's not tested,
> it's broken." Tattoo that on your neighbor's forehead so it's always in
mind <wink>.

Stay _off_ my forehead, thank you very much.  My hairline is receding enough
without ink stains killing off hair follicles.

Besides, I like my lobster-colored forehead just fine.

--da




From tim_one at email.msn.com  Wed Jun 28 08:23:38 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 02:23:38 -0400
Subject: [Python-Dev] C# (new language from Microsoft)
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBGEIBCOAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENKGGAA.tim_one@email.msn.com>

[Mark Hammond]
> ...
> * Python has a very good and interesting story in all this - there is no
> need to be alarmed.  If anything, be excited :-)

I was never worried about Python, but I lay awake at night worrying about
MS -- I'm still an MS shareholder, so don't screw this up <wink>.

every-new-c#-programmer-is-a-potential-python-convert-ly y'rs  - tim





From tim_one at email.msn.com  Wed Jun 28 08:23:40 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 02:23:40 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>

[Guido van Rossum]
> ...
> The address for New Bugs is currently set to guido at beopen.com.  I
> suppose I should set it to pythoneers at beopen.com or even to
> python-dev at python.org?

Since we (PythonLabs, last week) decided to continue using Jitterbug (on
python.org) for now, should the SF Bug Manager even be enabled?  If it is
enabled, and we are using Jitterbug, then someone has to own reentering SF
bugs into the Jitterbug system.

obviously y'rs  - tim





From gstein at lyra.org  Wed Jun 28 08:47:06 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 27 Jun 2000 23:47:06 -0700
Subject: [Python-Dev] C# (new language from Microsoft)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCENKGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 02:23:38AM -0400
References: <ECEPKNMJLHAPFFJHDOJBGEIBCOAA.mhammond@skippinet.com.au> <LNBBLJKPBEHFEDALKOLCCENKGGAA.tim_one@email.msn.com>
Message-ID: <20000627234706.N29590@lyra.org>

On Wed, Jun 28, 2000 at 02:23:38AM -0400, Tim Peters wrote:
> [Mark Hammond]
> > ...
> > * Python has a very good and interesting story in all this - there is no
> > need to be alarmed.  If anything, be excited :-)
> 
> I was never worried about Python, but I lay awake at night worrying about
> MS -- I'm still an MS shareholder, so don't screw this up <wink>.

I'm an MS shareholder, too.

Oh. Wait. Did I say I was involved? Don't think so...

ahem.

-g

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



From andy at reportlab.com  Wed Jun 28 09:03:07 2000
From: andy at reportlab.com (Andy Robinson)
Date: Wed, 28 Jun 2000 08:03:07 +0100
Subject: [Python-Dev] SourceForge win32 HOWTO
Message-ID: <PGECLPOBGNBNKHNAGIJHCEPDCCAA.andy@reportlab.com>

Sorry, I've been offline and missed this thread.  I could have saved you
some time. These are the instructions we've used at ReportLab to work with
SourceForge on Win32.  No problems so far despite several Unix and CVS
newbies, myself included.    They are adapted from an article by Jay Andrew
Kay somewhere on Sourceforge and are generic rather than specific to the
Python source.

I have used the ReportLab project and my user name as an example but I'm
sure you guys can adapt that....

1. Get ftp.reportlab.com/tools/cvs-1.10-win.zip and
ftp.reportlab.com/tools/ssh-1.2.14-win32bin.zip

(copied from somewhere obscure for safety, I forget where)

2. Unzip these to a location on your path.  Type 'cvs'
or 'shh' from somewhere else to verify.

3. Choose where to keep your CVS projects; let's assume
C:\code

4. Create a subdirectory c:\code\.ssh  (yes, dot-ssh)

5. Create two environment variables:
	HOME=C:\CODE
	CVS_RSH=SSH
On Win9x, this can be done in a batch file or autoexec.bat;
on NT or 2000, go to Control Panel | System | Environment
and set them at either user or machine level.
The first must point to the directory above your .ssh directory.

6. If not done so, get a Sourceforge account and a project
you can log in to.

7. Test SSH independently by doing
	SSH -l username myproject.sourceforge.net
It should prompt for a password, then tell you that
"myproject.sourceforge.net" is added to the list of known hosts;
then give you a shell.

8. You will need either a lengthy command line or a batch file
for each sourceforge project.  I set cvsroot in a batch file
in my 'c:\code' directory, and have one such file for each
CVS project I use (about ten of them!):

------cvsreportlab.bat--------------
set HOME=C:\CODE
set CVS_RSH=SSH
set CVSROOT=:ext:my_user_name at cvs.myproject.sourceforge.net:/cvsroot/dirname
---------------------------------------
'dirname' is the top level directory in the CVS tree; a project can have
several, but usually there is just one.

9. execute this batch file.  You can now go to C:\Code and do
	cvs -z7 checkout myproject
(z7 means 'compress network traffic', handy over dialup lines)

10. From now on, just use CVS normally.  I wouldn't survive without
Karl Fogel's book "Open Source Development with CVS", Coriolis Press.

Footnote: for anonymous checkout, I think you just omit
the 'my_user_name@' part from the CVSROOT variable.

I hope this helps; let me know if people have any problems
with the instructions.

-
Andy Robinson
ReportLab




From andy at robanal.demon.co.uk  Wed Jun 28 09:03:08 2000
From: andy at robanal.demon.co.uk (Andy Robinson)
Date: Wed, 28 Jun 2000 08:03:08 +0100
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <20000628025304.BB64A1CE0D@dinsdale.python.org>
Message-ID: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>

I missed all the SourceForge discussions, but ReportLab have been running
all our development on SourceForge for five months and I'd like to share
some concerns.

First, we all use command line CVS, mostly from Windows; I just posted our
setup instructions.  It works fine but a bit slowly.

I find the web interface totally unusable from IE5 and Netscape 4.XX,
working over 64k lines or dialup lines.  Once one logs in via SSL, only
about one click in five ever returns a sensible page, and most just time out
and give an error message.  Many other people on the reportlab-users list
and my team report similar problems.   On the other hand, many are
incredulous and say they have never had a problem.  I found no complaints on
the SF discussion groups, but as far as I can tell hardly anyone uses them.
It seems to be better over big corporate connections.  I don't think it is
because I am in Europe; we never have trouble with our US ISPs.

As a result of this, we have not used the wonderful looking bug tracking,
to-do-list, patch manager etc.

How many people here have actually created accounts for themselves on
SourceForge and tried to do stuff when logged in - raise bugs and so on?
Did it work for you?  We ought to get a few data points before making this
the way Python is managed.

- Andy Robinson






From nhodgson at bigpond.net.au  Wed Jun 28 09:23:52 2000
From: nhodgson at bigpond.net.au (Neil Hodgson)
Date: Wed, 28 Jun 2000 17:23:52 +1000
Subject: [Python-Dev] Sourceforge Interface Concerns
References: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <002401bfe0d1$d05a9fd0$e3cb8490@neil>

> How many people here have actually created accounts for themselves on
> SourceForge and tried to do stuff when logged in - raise bugs and so on?
> Did it work for you?  We ought to get a few data points before making this
> the way Python is managed.

   Its generally quite good for me now that I've upgraded from a modem to a
cable connection although there are brown-out periods. The only web browser
I have any success with is Navigator 4.6 and 4.7. Both IE and Mozilla give
poor results with SSL login. As far as getting other people to use the bug
logger, its been a complete failure. Its much easier to email me or the
mailing list.

   Some parts of SourceForge such as the file release upload are quite
poorly designed and are too unpleasant to use on a slow connection if you
have several packages for each release.

   Neil





From tim_one at email.msn.com  Wed Jun 28 09:28:10 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 03:28:10 -0400
Subject: [Python-Dev] SourceForge win32 HOWTO
In-Reply-To: <PGECLPOBGNBNKHNAGIJHCEPDCCAA.andy@reportlab.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENOGGAA.tim_one@email.msn.com>

[Andy Robinson]
> Sorry, I've been offline and missed this thread.  I could have saved you
> some time. These are the instructions we've used at ReportLab to work with
> SourceForge on Win32.  No problems so far despite several Unix and CVS
> newbies, myself included. ...

Thanks, Andy!  I just *knew* that if I sat on my ass, someone would solve
this one for me <wink>.  I'll give these instructions a try, and also see
what it takes to adapt them to wincvs.  Note that I'm going to be putting
similar (perhaps, by an amazing coincidence, even identical) instructions up
on pythonlabs.com, so if you want to stop maintaining this, dump it on me.





From tim_one at email.msn.com  Wed Jun 28 09:28:26 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 03:28:26 -0400
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENOGGAA.tim_one@email.msn.com>

[Andy Robinson]
> ...
> I find the web interface totally unusable from IE5 and Netscape 4.XX,
> working over 64k lines or dialup lines.  Once one logs in via SSL, only
> about one click in five ever returns a sensible page, and most
> just time out and give an error message.  Many other people on the
> reportlab-users list and my team report similar problems.   On the other
> hand, many are incredulous and say they have never had a problem.
> I found no complaints on the SF discussion groups, but as far as I can
> tell hardly anyone uses them.   It seems to be better over big corporate
> connections.  I don't think it is because I am in Europe; we never have
> trouble with our US ISPs.

I'm in the middle:  sometimes it works great, sometimes slow as molasses
(IE5 via 56K modem on the other side of the country), and an error each one
of two clicks.  Greg Stein lives near it, and reports wonderful access via
DSL.

> As a result of this, we have not used the wonderful looking bug tracking,
> to-do-list, patch manager etc.

They're actually pretty feeble.

> How many people here have actually created accounts for themselves on
> SourceForge and tried to do stuff when logged in - raise bugs and so on?
> Did it work for you?  We ought to get a few data points before making this
> the way Python is managed.

We're not using the bug tracker, task list, news, forum or support managers.
Just the CVS tree and the patch manager.  There are particular reasons for
using those particular two, and I doubt we'll be moving more there until SF
gets better.  OTOH, we're also interested in *helping* SF get better!  SF is
as much an Open Source project as Python, and it could become an incredible
resource for the entire OS community.

doesn't-mean-i-won't-gripe-too-though-ly y'rs  - tim





From gstein at lyra.org  Wed Jun 28 10:04:07 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 01:04:07 -0700
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCENOGGAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 03:28:26AM -0400
References: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk> <LNBBLJKPBEHFEDALKOLCCENOGGAA.tim_one@email.msn.com>
Message-ID: <20000628010407.T29590@lyra.org>

On Wed, Jun 28, 2000 at 03:28:26AM -0400, Tim Peters wrote:
>...
> We're not using the bug tracker, task list, news, forum or support managers.
> Just the CVS tree and the patch manager.  There are particular reasons for
> using those particular two, and I doubt we'll be moving more there until SF
> gets better.  OTOH, we're also interested in *helping* SF get better!  SF is
> as much an Open Source project as Python, and it could become an incredible
> resource for the entire OS community.

This last statement is (unfortunately) not quite true. SourceForge is
developed in a closed, cathedral environment. There is no CVS access to it,
and all the developers work at VA Linux. Strictly speaking, the *output* of
this closed development is GPL'd. But it isn't what you would expect.

The documentation for SF is separate. Apparently, there was an independent
effort to help do some documentation and they got a good ways. Then the VA
guys suddenly popped out the "SFDocs" project, ignoring the work from the
other people. Not sure where I read that, so I can't provide a reference to
the stories/threads :-(

btw, there is a survey about SF that you can fill out:
  http://sourceforge.net/survey/survey.php?group_id=1&survey_id=10599

Cheers,
-g

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



From mal at lemburg.com  Wed Jun 28 10:03:00 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Jun 2000 10:03:00 +0200
Subject: [Python-Dev] SF patch manager...
References: <LNBBLJKPBEHFEDALKOLCIEMBGGAA.tim_one@email.msn.com>
Message-ID: <3959B134.1538B4B7@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > [Please excuse my ranting... :-)]
> 
> No problem -- you're not complaining about *our* software <wink>.
> 
> > I've received the first round of notification message from the
> > patch manager and can't really say that I like them. Ok, I
> > understand that the patch manager is still alpha or beta software,
> > but these messages really don't have any usable content at all:
> >
> > """
> > Patch #100646 has been updated.
> > Visit SourceForge.net for more info.
> >
> >
> http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470
> > """
> 
> I expect the title of the patch was also in the Subject line, yes? 

Right, but that's just about all the information you get:
the title, the fact that something changed and a link to the
patch page.

> And a
> live link to the patch is certainly "usable".  I've found both those right
> on target as I've been assigned or deassigned to patches so far, although
> I'd sure like to see something in the body saying exactly *what* about the
> patch "has been updated".
> 
> Not saying I think it's good enough, am saying it's (barely) a start.

True and I don't want to put this down. The only reason for
my ranting is that I'd rather get more infos in mail than
via some link to a page. Discussing patches via quoting email
is just so much more convenient -- opening two or three 
browsers to get at the hard facts isn't and, as others have
already noted, is rather slow too.
 
> > Also, reviewing the patches has become a pain
> 
> I don't understand that, in that the text of the patch is what you got
> before, and what you can get now.  Is your complaint here specifically that
> patches don't show up in your mailbox by magic?  Or something else?

I would very much prefer to get the patches or changes
appended to the update messages (much like was manually done
on patches at python.org). That way I can read the patch and
then reply to the sender and the list community from within
the mail application -- without copy&paste, looking up
email addresses in SF etc.
 
> > and discussing them is nearly impossible (I don't consider the
> > slashdot like comment mechanism to be of any use: there's simply
> > no audience for discussion).
> 
> Wholly agreed there.  So use python-dev for discussions for now; I agree too
> with Guido that the rampant but inconsistent x-posting between patches and
> python-dev was part of the problem.
>
> > Is there any chance of tee'ing patches from SF to the patches
> > list or some other patch discussion and review forum ?
> 
> I expect you know as much about SF's possibilities as anyone <0.5 wink>:
> don't know.  The SF docs are either non-existent or inadequate, far as I can
> tell, and I believe I share a mistaken belief with Fred Drake that new
> patches "should" *already* be showing up on the patches list.

They are showing up there... at least new ones are. Discussions
(via posting comments on the patch page) are not relayed to the
list though: only the comment authors get an email.
 
> > I do understand that the mechanism can help with patch *checkins*,
> 
> Yes, but not yet as much as it should (e.g., the default view of patches
> lacks basic info like the patch current status, and there's apparently not
> yet any way to define a different view).
> 
> > but it's certainly not going to help much with the discussion
> > step needed before conidering any actions.
> 
> Python-Dev now, possibly roundup later.  OTOH, it's perfectly adequate for
> tiny little principal-reviewer <-> submitter give-and-take; many patches are
> really quite trivial.

True, but even small patches occasionally need peer review from 
more people than just the assigned developer.
 
> > The independent peer review principal doesn't work with this
> > kind of setup.
> 
> I think your view is warped on this one, as you've been in the extremely
> favored position of pumping out crucial patches for a hot area.  Most other
> peoples' patches have been flatly ignored for *months* now.  It's not
> necessarily bad if other people get some attention now too <wink>.

Oops, did it shine through that much ? ;-)

Seriously, I would like to see a processing speedup too, it's
just the workflow that bothers me a bit.

BTW, another great feature for the patch manager would be
a button to perform the actual checkin via the web interface.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From rob at hooft.net  Wed Jun 28 11:27:18 2000
From: rob at hooft.net (Rob W. W. Hooft)
Date: Wed, 28 Jun 2000 11:27:18 +0200 (CEST)
Subject: [Python-Dev] Typo's
Message-ID: <14681.50422.966321.780406@temoleh.chem.uu.nl>

I located some typo's in the CVS. Here is a patch.

Warning: I'm a non-native English speaker. Please verify fixes.

Rob

Index: Demo/pdist/rcslib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Demo/pdist/rcslib.py,v
retrieving revision 1.6
diff -u -r1.6 rcslib.py
--- Demo/pdist/rcslib.py	1998/09/14 16:43:57	1.6
+++ Demo/pdist/rcslib.py	2000/06/28 07:42:50
@@ -296,7 +296,7 @@
     def _system(self, cmd):
         """INTERNAL: run COMMAND in a subshell.
 
-        Standard input for the command is taken fron /dev/null.
+        Standard input for the command is taken from /dev/null.
 
         Raise IOError when the exit status is not zero.
 
Index: Demo/sgi/video/Vcopy.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vcopy.py,v
retrieving revision 1.7
diff -u -r1.7 Vcopy.py
--- Demo/sgi/video/Vcopy.py	1996/11/27 19:50:07	1.7
+++ Demo/sgi/video/Vcopy.py	2000/06/28 07:42:50
@@ -8,7 +8,7 @@
 # - Manipulate the time base:
 #   = resample at a fixed rate
 #   = divide the time codes by a speed factor (to make it go faster/slower)
-#   = drop frames that are less than n msec apart (to accomodate slow players)
+#   = drop frames that are less than n msec apart (to accommodate slow players)
 # - Convert to a different format
 # - Magnify (scale) the image
 
Index: Demo/sgi/video/Vtime.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vtime.py,v
retrieving revision 1.4
diff -u -r1.4 Vtime.py
--- Demo/sgi/video/Vtime.py	1996/11/27 19:50:28	1.4
+++ Demo/sgi/video/Vtime.py	2000/06/28 07:42:50
@@ -7,7 +7,7 @@
 #
 # - resample at a fixed rate
 # - divide the time codes by a speed factor (to make it go faster/slower)
-# - drop frames that are less than n msec apart (to accomodate slow players)
+# - drop frames that are less than n msec apart (to accommodate slow players)
 
 
 # Usage:
Index: Lib/Queue.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/Queue.py,v
retrieving revision 1.10
diff -u -r1.10 Queue.py
--- Lib/Queue.py	2000/02/02 15:10:14	1.10
+++ Lib/Queue.py	2000/06/28 07:42:51
@@ -119,7 +119,7 @@
     def _qsize(self):
         return len(self.queue)
 
-    # Check wheter the queue is empty
+    # Check whether the queue is empty
     def _empty(self):
         return not self.queue
 
Index: Lib/binhex.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/binhex.py,v
retrieving revision 1.12
diff -u -r1.12 binhex.py
--- Lib/binhex.py	2000/02/04 15:39:29	1.12
+++ Lib/binhex.py	2000/06/28 07:42:51
@@ -13,7 +13,7 @@
 # XXXX Note: currently, textfiles appear in mac-form on all platforms.
 # We seem to lack a simple character-translate in python.
 # (we should probably use ISO-Latin-1 on all but the mac platform).
-# XXXX The simeple routines are too simple: they expect to hold the complete
+# XXXX The simple routines are too simple: they expect to hold the complete
 # files in-core. Should be fixed.
 # XXXX It would be nice to handle AppleDouble format on unix
 # (for servers serving macs).
@@ -48,7 +48,7 @@
     try:
         openrf = MacOS.openrf
     except AttributeError:
-        # Backward compatability
+        # Backward compatibility
         openrf = open
     
     def FInfo():
Index: Lib/calendar.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/calendar.py,v
retrieving revision 1.15
diff -u -r1.15 calendar.py
--- Lib/calendar.py	2000/02/02 15:10:14	1.15
+++ Lib/calendar.py	2000/06/28 07:42:51
@@ -1,6 +1,6 @@
 """Calendar printing functions"""
 
-# Revision 2: uses funtions from built-in time module
+# Revision 2: uses functions from built-in time module
 
 # Import functions and variables from time module
 from time import localtime, mktime
Index: Lib/fnmatch.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/fnmatch.py,v
retrieving revision 1.7
diff -u -r1.7 fnmatch.py
--- Lib/fnmatch.py	1997/10/22 20:57:40	1.7
+++ Lib/fnmatch.py	2000/06/28 07:42:51
@@ -36,7 +36,7 @@
 	return fnmatchcase(name, pat)
 
 def fnmatchcase(name, pat):
-	"""Test wheter FILENAME matches PATTERN, including case.
+	"""Test whether FILENAME matches PATTERN, including case.
 	
 	This is a version of fnmatch() which doesn't case-normalize
 	its arguments.
Index: Lib/locale.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/locale.py,v
retrieving revision 1.6
diff -u -r1.6 locale.py
--- Lib/locale.py	2000/06/08 17:49:41	1.6
+++ Lib/locale.py	2000/06/28 07:42:52
@@ -220,7 +220,7 @@
 
         The language code corresponds to RFC 1766.  code and encoding
         can be None in case the values cannot be determined or are
-        unkown to this implementation.
+        unknown to this implementation.
 
     """
     code = normalize(localename)
@@ -229,7 +229,7 @@
     elif code == 'C':
         return None, None
     else:
-        raise ValueError,'unkown locale: %s' % localename
+        raise ValueError,'unknown locale: %s' % localename
     return l
 
 def _build_localename(localetuple):
Index: Lib/posixpath.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/posixpath.py,v
retrieving revision 1.30
diff -u -r1.30 posixpath.py
--- Lib/posixpath.py	2000/02/29 13:31:16	1.30
+++ Lib/posixpath.py	2000/06/28 07:42:52
@@ -24,7 +24,7 @@
     return s
 
 
-# Return wheter a path is absolute.
+# Return whether a path is absolute.
 # Trivial in Posix, harder on the Mac or MS-DOS.
 
 def isabs(s):
@@ -304,7 +304,7 @@
 
 # Expand paths containing shell variable substitutions.
 # This expands the forms $variable and ${variable} only.
-# Non-existant variables are left unchanged.
+# Non-existent variables are left unchanged.
 
 _varprog = None
 
Index: Lib/sgmllib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/sgmllib.py,v
retrieving revision 1.19
diff -u -r1.19 sgmllib.py
--- Lib/sgmllib.py	2000/02/04 15:28:40	1.19
+++ Lib/sgmllib.py	2000/06/28 07:42:53
@@ -47,7 +47,7 @@
 # <foo> and </foo>, respectively, or do_foo to handle <foo> by itself.
 # (Tags are converted to lower case for this purpose.)  The data
 # between tags is passed to the parser by calling self.handle_data()
-# with some data as argument (the data may be split up in arbutrary
+# with some data as argument (the data may be split up in arbitrary
 # chunks).  Entity references are passed by calling
 # self.handle_entityref() with the entity reference as argument.
 
Index: Lib/site.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/site.py,v
retrieving revision 1.11
diff -u -r1.11 site.py
--- Lib/site.py	2000/06/07 09:12:09	1.11
+++ Lib/site.py	2000/06/28 07:42:53
@@ -122,7 +122,7 @@
 #
 # Set the string encoding used by the Unicode implementation to the
 # encoding used by the default locale of this system. If the default
-# encoding cannot be determined or is unkown, it defaults to 'ascii'.
+# encoding cannot be determined or is unknown, it defaults to 'ascii'.
 #
 def locale_aware_defaultencoding():
     import locale
Index: Lib/urllib2.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/urllib2.py,v
retrieving revision 1.3
diff -u -r1.3 urllib2.py
--- Lib/urllib2.py	2000/02/10 17:17:14	1.3
+++ Lib/urllib2.py	2000/06/28 07:42:54
@@ -141,7 +141,7 @@
     _opener = opener
 
 # do these error classes make sense?
-# make sure all of the IOError stuff is overriden.  we just want to be 
+# make sure all of the IOError stuff is overridden.  we just want to be 
  # subtypes.
 
 class URLError(IOError):
Index: Lib/xmllib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/xmllib.py,v
retrieving revision 1.18
diff -u -r1.18 xmllib.py
--- Lib/xmllib.py	2000/06/21 20:01:10	1.18
+++ Lib/xmllib.py	2000/06/28 07:42:54
@@ -79,7 +79,7 @@
 # special names to handle tags: start_foo and end_foo to handle <foo>
 # and </foo>, respectively.  The data between tags is passed to the
 # parser by calling self.handle_data() with some data as argument (the
-# data may be split up in arbutrary chunks).
+# data may be split up in arbitrary chunks).
 
 class XMLParser:
     attributes = {}                     # default, to be overridden
Index: Lib/distutils/cmd.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/cmd.py,v
retrieving revision 1.18
diff -u -r1.18 cmd.py
--- Lib/distutils/cmd.py	2000/06/08 00:02:36	1.18
+++ Lib/distutils/cmd.py	2000/06/28 07:42:55
@@ -323,7 +323,7 @@
         should be disabled by the "dry run" flag, and should announce
         themselves if the current verbosity level is high enough.  This
         method takes care of all that bureaucracy for you; all you have to
-        do is supply the funtion to call and an argument tuple for it (to
+        do is supply the function to call and an argument tuple for it (to
         embody the "external action" being performed), a message to print
         if the verbosity level is high enough, and an optional verbosity
         threshold.
Index: Lib/distutils/util.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/util.py,v
retrieving revision 1.37
diff -u -r1.37 util.py
--- Lib/distutils/util.py	2000/06/24 20:40:02	1.37
+++ Lib/distutils/util.py	2000/06/28 07:42:55
@@ -28,7 +28,7 @@
         return os.path.normpath(path)
 
 
-# More backwards compatability hacks
+# More backwards compatibility hacks
 def extend (list, new_list):
     """Appends the list 'new_list' to 'list', just like the 'extend()'
        list method does in Python 1.5.2 -- but this works on earlier
Index: Lib/distutils/version.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/version.py,v
retrieving revision 1.1
diff -u -r1.1 version.py
--- Lib/distutils/version.py	1998/12/18 22:00:30	1.1
+++ Lib/distutils/version.py	2000/06/28 07:42:55
@@ -207,7 +207,7 @@
 # provides enough benefit to be worth using, and will submit their
 # version numbering scheme to its domination.  The free-thinking
 # anarchists in the lot will never give in, though, and something needs
-# to be done to accomodate them.
+# to be done to accommodate them.
 # 
 # Perhaps a "moderately strict" version class could be implemented that
 # lets almost anything slide (syntactically), and makes some heuristic
Index: Lib/distutils/command/build_ext.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/build_ext.py,v
retrieving revision 1.51
diff -u -r1.51 build_ext.py
--- Lib/distutils/command/build_ext.py	2000/06/28 01:29:37	1.51
+++ Lib/distutils/command/build_ext.py	2000/06/28 07:42:56
@@ -1,7 +1,7 @@
 """distutils.command.build_ext
 
 Implements the Distutils 'build_ext' command, for building extension
-modules (currently limited to C extensions, should accomodate C++
+modules (currently limited to C extensions, should accommodate C++
 extensions ASAP)."""
 
 # created 1999/08/09, Greg Ward
@@ -385,7 +385,7 @@
             # Next, compile the source code to object files.
 
             # XXX not honouring 'define_macros' or 'undef_macros' -- the
-            # CCompiler API needs to change to accomodate this, and I
+            # CCompiler API needs to change to accommodate this, and I
             # want to do one thing at a time!
 
             # Two possible sources for extra compiler arguments:
Index: Lib/dos-8x3/posixpat.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/posixpat.py,v
retrieving revision 1.10
diff -u -r1.10 posixpat.py
--- Lib/dos-8x3/posixpat.py	2000/05/08 17:31:00	1.10
+++ Lib/dos-8x3/posixpat.py	2000/06/28 07:42:56
@@ -24,7 +24,7 @@
     return s
 
 
-# Return wheter a path is absolute.
+# Return whether a path is absolute.
 # Trivial in Posix, harder on the Mac or MS-DOS.
 
 def isabs(s):
@@ -304,7 +304,7 @@
 
 # Expand paths containing shell variable substitutions.
 # This expands the forms $variable and ${variable} only.
-# Non-existant variables are left unchanged.
+# Non-existent variables are left unchanged.
 
 _varprog = None
 
Index: Lib/dos-8x3/queue.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/queue.py,v
retrieving revision 1.7
diff -u -r1.7 queue.py
--- Lib/dos-8x3/queue.py	2000/05/08 17:31:00	1.7
+++ Lib/dos-8x3/queue.py	2000/06/28 07:42:56
@@ -119,7 +119,7 @@
     def _qsize(self):
         return len(self.queue)
 
-    # Check wheter the queue is empty
+    # Check whether the queue is empty
     def _empty(self):
         return not self.queue
 
Index: Lib/dos-8x3/test_win.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_win.py,v
retrieving revision 1.1
diff -u -r1.1 test_win.py
--- Lib/dos-8x3/test_win.py	2000/05/08 17:31:03	1.1
+++ Lib/dos-8x3/test_win.py	2000/06/28 07:42:57
@@ -115,7 +115,7 @@
     # Opening should now fail!
     try:
         key = OpenKey(root_key, test_key_name)
-        assert 0, "Could open the non-existant key"
+        assert 0, "Could open the non-existent key"
     except WindowsError: # Use this error name this time
         pass
 
Index: Lib/dos-8x3/test_zli.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_zli.py,v
retrieving revision 1.5
diff -u -r1.5 test_zli.py
--- Lib/dos-8x3/test_zli.py	2000/05/08 17:31:03	1.5
+++ Lib/dos-8x3/test_zli.py	2000/06/28 07:42:57
@@ -11,7 +11,7 @@
 buf = file.read() * 8
 file.close()
 
-# test the chucksums (hex so the test doesn't break on 64-bit machines)
+# test the checksums (hex so the test doesn't break on 64-bit machines)
 print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1))
 print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1))
 
Index: Lib/plat-irix5/CL_old.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/CL_old.py,v
retrieving revision 1.1
diff -u -r1.1 CL_old.py
--- Lib/plat-irix5/CL_old.py	1995/05/17 11:18:22	1.1
+++ Lib/plat-irix5/CL_old.py	2000/06/28 07:42:57
@@ -200,7 +200,7 @@
 BOTTOM_UP = 1
 
 #
-# SGI Proprietaty Algorithm Header Start Code
+# SGI Proprietary Algorithm Header Start Code
 #
 HEADER_START_CODE = 0xc1C0DEC
 
Index: Lib/plat-irix5/flp.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/flp.py,v
retrieving revision 1.17
diff -u -r1.17 flp.py
--- Lib/plat-irix5/flp.py	1998/03/26 20:22:58	1.17
+++ Lib/plat-irix5/flp.py	2000/06/28 07:42:57
@@ -203,7 +203,7 @@
     return datum[1]
 #
 # Internal: parse fd form, or skip if name doesn't match.
-# the special value None means 'allways parse it'.
+# the special value None means 'always parse it'.
 #
 def _parse_fd_form(file, name):
     datum = _parse_1_line(file)
@@ -222,7 +222,7 @@
     return None
 
 #
-# Internal class: a convient place to store object info fields
+# Internal class: a convenient place to store object info fields
 #
 class _newobj:
     def add(self, name, value):
Index: Lib/plat-irix5/panel.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/panel.py,v
retrieving revision 1.4
diff -u -r1.4 panel.py
--- Lib/plat-irix5/panel.py	1995/09/18 22:00:37	1.4
+++ Lib/plat-irix5/panel.py	2000/06/28 07:42:58
@@ -2,7 +2,7 @@
 #
 # Support for the Panel library.
 # Uses built-in module 'pnl'.
-# Applciations should use 'panel.function' instead of 'pnl.function';
+# Applications should use 'panel.function' instead of 'pnl.function';
 # most 'pnl' functions are transparently exported by 'panel',
 # but dopanel() is overridden and you have to use this version
 # if you want to use callbacks.
@@ -137,7 +137,7 @@
 					print 'assign failed:', stmt
 
 
-# Build a real actuator from an actuator descriptior.
+# Build a real actuator from an actuator description.
 # Return a pair (actuator, name).
 #
 def build_actuator(descr):
Index: Lib/plat-irix6/flp.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/flp.py,v
retrieving revision 1.4
diff -u -r1.4 flp.py
--- Lib/plat-irix6/flp.py	1998/03/26 20:23:01	1.4
+++ Lib/plat-irix6/flp.py	2000/06/28 07:42:58
@@ -203,7 +203,7 @@
     return datum[1]
 #
 # Internal: parse fd form, or skip if name doesn't match.
-# the special value None means 'allways parse it'.
+# the special value None means 'always parse it'.
 #
 def _parse_fd_form(file, name):
     datum = _parse_1_line(file)
@@ -222,7 +222,7 @@
     return None
 
 #
-# Internal class: a convient place to store object info fields
+# Internal class: a convenient place to store object info fields
 #
 class _newobj:
     def add(self, name, value):
Index: Lib/plat-irix6/panel.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/panel.py,v
retrieving revision 1.1
diff -u -r1.1 panel.py
--- Lib/plat-irix6/panel.py	1997/01/15 19:19:11	1.1
+++ Lib/plat-irix6/panel.py	2000/06/28 07:42:58
@@ -2,7 +2,7 @@
 #
 # Support for the Panel library.
 # Uses built-in module 'pnl'.
-# Applciations should use 'panel.function' instead of 'pnl.function';
+# Applications should use 'panel.function' instead of 'pnl.function';
 # most 'pnl' functions are transparently exported by 'panel',
 # but dopanel() is overridden and you have to use this version
 # if you want to use callbacks.
@@ -137,7 +137,7 @@
 					print 'assign failed:', stmt
 
 
-# Build a real actuator from an actuator descriptior.
+# Build a real actuator from an actuator description.
 # Return a pair (actuator, name).
 #
 def build_actuator(descr):
Index: Lib/test/test_al.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_al.py,v
retrieving revision 1.2
diff -u -r1.2 test_al.py
--- Lib/test/test_al.py	1998/03/26 19:41:38	1.2
+++ Lib/test/test_al.py	2000/06/28 07:42:58
@@ -8,7 +8,7 @@
 alattrs = ['__doc__', '__name__', 'getdefault', 'getminmax', 'getname', 'getparams',
            'newconfig', 'openport', 'queryparams', 'setparams']
 
-# This is a very inobstrusive test for the existance of the al module and all it's
+# This is a very inobtrusive test for the existence of the al module and all it's
 # attributes.  More comprehensive examples can be found in Demo/al
 
 def main():
Index: Lib/test/test_b1.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_b1.py,v
retrieving revision 1.22
diff -u -r1.22 test_b1.py
--- Lib/test/test_b1.py	2000/04/14 19:13:22	1.22
+++ Lib/test/test_b1.py	2000/06/28 07:42:58
@@ -270,7 +270,7 @@
 # Different base:
 if int("10",16) <> 16L: raise TestFailed, 'int("10",16)'
 if int(u"10",16) <> 16L: raise TestFailed, 'int(u"10",16)'
-# Test conversion fron strings and various anomalies
+# Test conversion from strings and various anomalies
 L = [
         ('0', 0),
         ('1', 1),
Index: Lib/test/test_cd.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cd.py,v
retrieving revision 1.2
diff -u -r1.2 test_cd.py
--- Lib/test/test_cd.py	1998/03/26 19:41:49	1.2
+++ Lib/test/test_cd.py	2000/06/28 07:42:58
@@ -10,7 +10,7 @@
            'ident', 'index', 'msftoframe', 'open', 'pnum', 'ptime']
 
 
-# This is a very inobstrusive test for the existance of the cd module and all it's
+# This is a very inobtrusive test for the existence of the cd module and all it's
 # attributes.  More comprehensive examples can be found in Demo/cd and
 # require that you have a CD and a CD ROM drive
 
Index: Lib/test/test_cl.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cl.py,v
retrieving revision 1.2
diff -u -r1.2 test_cl.py
--- Lib/test/test_cl.py	1998/03/26 19:41:52	1.2
+++ Lib/test/test_cl.py	2000/06/28 07:42:58
@@ -63,7 +63,7 @@
 'YUV422DC', 'YUV422HC', '__doc__', '__name__', 'cvt_type', 'error']
 
 
-# This is a very inobstrusive test for the existance of the cl
+# This is a very inobtrusive test for the existence of the cl
 # module and all it's attributes.
 
 def main():
Index: Lib/test/test_pwd.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_pwd.py,v
retrieving revision 1.5
diff -u -r1.5 test_pwd.py
--- Lib/test/test_pwd.py	1998/03/26 19:42:32	1.5
+++ Lib/test/test_pwd.py	2000/06/28 07:42:58
@@ -59,7 +59,7 @@
 else:
     print 'fakename', fakename, 'did not except pwd.getpwnam()'
 
-# Choose a non-existant uid.
+# Choose a non-existent uid.
 fakeuid = 4127
 while byuids.has_key(fakeuid):
     fakeuid = (fakeuid * 3) % 0x10000
Index: Lib/test/test_winreg.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_winreg.py,v
retrieving revision 1.2
diff -u -r1.2 test_winreg.py
--- Lib/test/test_winreg.py	2000/04/01 05:25:57	1.2
+++ Lib/test/test_winreg.py	2000/06/28 07:42:58
@@ -115,7 +115,7 @@
     # Opening should now fail!
     try:
         key = OpenKey(root_key, test_key_name)
-        assert 0, "Could open the non-existant key"
+        assert 0, "Could open the non-existent key"
     except WindowsError: # Use this error name this time
         pass
 
Index: Lib/test/test_zlib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_zlib.py,v
retrieving revision 1.7
diff -u -r1.7 test_zlib.py
--- Lib/test/test_zlib.py	2000/02/10 15:31:07	1.7
+++ Lib/test/test_zlib.py	2000/06/28 07:42:59
@@ -11,7 +11,7 @@
 buf = file.read() * 8
 file.close()
 
-# test the chucksums (hex so the test doesn't break on 64-bit machines)
+# test the checksums (hex so the test doesn't break on 64-bit machines)
 print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1))
 print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1))
 
Index: Python/exceptions.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/exceptions.c,v
retrieving revision 1.2
diff -u -r1.2 exceptions.c
--- Python/exceptions.c	2000/06/20 18:36:26	1.2
+++ Python/exceptions.c	2000/06/28 07:42:59
@@ -189,7 +189,7 @@
  *
  * First thing we create is the base class for all exceptions, called
  * appropriately enough: Exception.  Creation of this class makes no
- * assumptions about the existance of any other exception class -- except
+ * assumptions about the existence of any other exception class -- except
  * for TypeError, which can conditionally exist.
  *
  * Next, StandardError is created (which is quite simple) followed by
Index: Python/import.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/import.c,v
retrieving revision 2.134
diff -u -r2.134 import.c
--- Python/import.c	2000/05/03 23:44:39	2.134
+++ Python/import.c	2000/06/28 07:43:01
@@ -87,7 +87,7 @@
 #define MAGIC (50428 | ((long)'\r'<<16) | ((long)'\n'<<24))
 
 /* Magic word as global; note that _PyImport_Init() can change the
-   value of this global to accomodate for alterations of how the
+   value of this global to accommodate for alterations of how the
    compiler works which are enabled by command line switches. */
 static long pyc_magic = MAGIC;
 



From effbot at telia.com  Wed Jun 28 11:47:32 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 11:47:32 +0200
Subject: [Python-Dev] Typo's
References: <14681.50422.966321.780406@temoleh.chem.uu.nl>
Message-ID: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid>

> I located some typo's in the CVS. Here is a patch.

wow!

just one nit:

"inobstrusive" should be "unobtrusive" (not "inobtrusive")

(and it's not clear if "descriptior" means "description" or
"descriptor"...)

> Warning: I'm a non-native English speaker.

same here.

</F>




From effbot at telia.com  Wed Jun 28 13:07:24 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 13:07:24 +0200
Subject: [Python-Dev] OT: A Day in the Life of p5p
Message-ID: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>

http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

unfortunately, his "What is it with those Python fucks anyway" talk
isn't posted... ;-)

</F>




From fdrake at beopen.com  Wed Jun 28 13:16:53 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 07:16:53 -0400 (EDT)
Subject: [Python-Dev] back up & running
Message-ID: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com>

  My mega-laptop got fixed faster than I'd expected, so I'm back up to
doing useful work.  My top priorities are handling patches and going
back through my email to find all the documentation patches that have
sat idle for too long.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mwh21 at cam.ac.uk  Wed Jun 28 13:54:27 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 28 Jun 2000 12:54:27 +0100
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: "Andy Robinson"'s message of "Wed, 28 Jun 2000 08:03:08 +0100"
References: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <m3vgyu9g24.fsf@atrus.jesus.cam.ac.uk>

"Andy Robinson" <andy at robanal.demon.co.uk> writes:

> It seems to be better over big corporate connections.  I don't think it is
> because I am in Europe; we never have trouble with our US ISPs.

FWIW, it's pretty good from here (but then the university has pretty
serious bandwidth).  It seems a bit odd that it's so much worse with
lower badwidth (in particular that people on modems get more errors).
Oh well.

Cheers,
M.




From Vladimir.Marangozov at inrialpes.fr  Wed Jun 28 14:22:56 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Wed, 28 Jun 2000 14:22:56 +0200 (CEST)
Subject: [Python-Dev] back up & running
In-Reply-To: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jun 28, 2000 07:16:53 AM
Message-ID: <200006281222.OAA03150@python.inrialpes.fr>

Fred L. Drake, Jr. wrote:
> 
>   My mega-laptop got fixed faster than I'd expected, so I'm back up to
> doing useful work.  My top priorities are handling patches and going
> back through my email to find all the documentation patches that have
> sat idle for too long.

Excellent!

Finally someone who cares to checkin patches. I've been disappointed
to see that the June 30 intent-date was announced, but people keep
chewing-gumming about SourceForge caveats while the patches backlog
grows and the number of closed patches stays invariably to 3, of which
one is a test!

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From bwarsaw at beopen.com  Wed Jun 28 15:27:12 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 09:27:12 -0400 (EDT)
Subject: [Python-Dev] Sourceforge Interface Concerns
References: <20000628025304.BB64A1CE0D@dinsdale.python.org>
	<PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <14681.64816.561341.920024@anthem.concentric.net>

>>>>> "AR" == Andy Robinson <andy at robanal.demon.co.uk> writes:

    AR> How many people here have actually created accounts for
    AR> themselves on SourceForge and tried to do stuff when logged in
    AR> - raise bugs and so on?  Did it work for you?  We ought to get
    AR> a few data points before making this the way Python is
    AR> managed.

In general SF's web has been fine for me, although it is sometimes
unavailable due to routing problems.  I'm on a fairly reliable DSL
line now, though I don't remember significantly more SF-blamable
problems when I was on a 56K line.

It's often quite slow to do CVS/SSH to SF.  Sometimes I'll have to
spin for several minutes just to do an update or a diff.  That sucks.

-Barry



From fdrake at beopen.com  Wed Jun 28 15:30:22 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 09:30:22 -0400 (EDT)
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
References: <20000628025304.BB64A1CE0D@dinsdale.python.org>
	<PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com>

Andy Robinson writes:
 > I find the web interface totally unusable from IE5 and Netscape 4.XX,
 > working over 64k lines or dialup lines.  Once one logs in via SSL, only
 > about one click in five ever returns a sensible page, and most just time out

  I've not been able to reproduce this behavior; the Web interface
seems to work well with IE5 and Netscape 4.XX for me; the only problem
I've had with IE5 is accessing a project's anonymous FTP area from the
project page (IE5 just froze completely).  Netscape didn't exhibit
that problem for me and allowed perfectly reasonable use.
  Sometimes it seems a little slow, but I attribute that to load and
the public-key crypto using SSH for CVS access; I understand that CVS
doesn't have the most efficient wire-protocol either.
  I should note that I've mostly used it over T1 and cable modem
links; I don't know that smaller pipes would make a huge difference
though.  I'd be more suspicious of trans-Atlantic linkage than
anything else without having more information.  Routing can do strange
things, so you may be getting the worst-possible link for SourceForge
while other things get better routes, but I wouldn't expect that to be
terribly consistent.

 > How many people here have actually created accounts for themselves on
 > SourceForge and tried to do stuff when logged in - raise bugs and so on?
 > Did it work for you?  We ought to get a few data points before making this
 > the way Python is managed.

  I've never had the kind of problems you describe.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From Vladimir.Marangozov at inrialpes.fr  Wed Jun 28 15:58:26 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Wed, 28 Jun 2000 15:58:26 +0200 (CEST)
Subject: [Python-Dev] Typo's
In-Reply-To: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 28, 2000 11:47:32 AM
Message-ID: <200006281358.PAA03368@python.inrialpes.fr>

Fredrik Lundh wrote:
> 
> > I located some typo's in the CVS. Here is a patch.
> 
> wow!

Wow, indeed.
+1

I've uploaded this patch to SourceForge.

> 
> just one nit:
> 
> "inobstrusive" should be "unobtrusive" (not "inobtrusive")

fixed in the patch.

> 
> (and it's not clear if "descriptior" means "description" or
> "descriptor"...)

I examined the patched file - it's "description".


> 
> > Warning: I'm a non-native English speaker.
> 
> same here.

same here :-)

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From guido at beopen.com  Wed Jun 28 16:55:00 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 09:55:00 -0500
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: Your message of "Tue, 27 Jun 2000 18:46:15 MST."
             <20000627184615.A29590@lyra.org> 
References: <20000627184615.A29590@lyra.org> 
Message-ID: <200006281455.JAA01690@cj20424-a.reston1.va.home.com>

> A while back, I pulled the "demo" importers out of imputil.py. I think those
> should be added into Demo/imputil/.

OK.  Go ahead and create that directory and add the demo importers.

> It would also be Goodness to include JimA's zipimporter. Where would that go?

Same place I'd hope?  Can you check that it works?

We're dependent on you volunteers to maintain relatively non-core
things like this -- I don't want to extend the feature freeze to
Demo/, but I also don't have the time to keep the stuff there up to
date.  Maybe at some point the Demo directory should become a separate
distribution, or just a collection of stuff on the web?

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



From akuchlin at mems-exchange.org  Wed Jun 28 16:07:22 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 10:07:22 -0400
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com>
References: <20000628025304.BB64A1CE0D@dinsdale.python.org> <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk> <14681.65006.782463.491824@cj42289-a.reston1.va.home.com>
Message-ID: <20000628100722.A9063@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 09:30:22AM -0400, Fred L. Drake, Jr. wrote:
>  I should note that I've mostly used it over T1 and cable modem
>links; I don't know that smaller pipes would make a huge difference
>though. 

At home I have a 28.8 modem (never figured out how to upgrade it to
56K), and while CVS operations are fairly slow, there usually aren't
any problems.  The same goes for accessing the Web pages through SSL;
somewhat slow, but reliable.

--amk



From gward at mems-exchange.org  Wed Jun 28 16:18:12 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 28 Jun 2000 10:18:12 -0400
Subject: [Python-Dev] Python 1.6 planning
In-Reply-To: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400
References: <AJEAKILOCCJMDILAPGJNMEHGCAAA.jeremy@beopen.com>
Message-ID: <20000628101812.A15643@ludwig.cnri.reston.va.us>

On 23 June 2000, Jeremy Hylton said:
> ldso_aix-- I still don't understand, but I didn't really try; Vladimir must
> help

This has been fixed in the Distutils.  AFAIK it's still broken for
Makefile.pre.in builds -- as long as the installed Makefile is fixed
(not the actual installation location of ld_so_aix), then Distutils
builds will continue to work.

(Thanks to Rene Liebscher for providing the Distutils fix, and Vladimir
for testing it.)

        Greg



From gward at mems-exchange.org  Wed Jun 28 16:29:02 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 28 Jun 2000 10:29:02 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37
In-Reply-To: <20000624151824.A29590@lyra.org>; from gstein@lyra.org on Sat, Jun 24, 2000 at 03:18:24PM -0700
References: <200006242040.NAA28315@slayer.i.sourceforge.net> <20000624151824.A29590@lyra.org>
Message-ID: <20000628102901.B15643@ludwig.cnri.reston.va.us>

On 24 June 2000, Greg Stein said:
> Would the "shlex" module be helpful here? It is in the standard library and
> is (well?) maintained by ESR. It could help reduce the code inside
> distutils.

I looked at "shlex", but didn't like the fact that it 1) does
character-by-character analysis of input, and 2) requires a file-like
object.  Just a performance concern, really.

> [ I've always questioned the need for distutils' own "copy file" functions
>   and whatnot... seems there is a bit of duplication occurring... ]

Two reasons for that: bugs in the standard library versions, and missing
features in the standard library versions.  I think the first argument
goes away now that I've given up on 1.5.1 compatibility (shutil.py was
really broken in 1.5.1), but the fact remains that the copy functions in
shutil.py don't have a dry_run option, don't have a verbose option,
don't have a preserve_times option, don't have a preserve_symlinks
option, etc.  All of these things are somewhere between useful and
necessary.

I'm always open for ideas on reducing the amount of code in the
Distutils; it really is getting ridiculous.  It cracked 10k lines of
code+comments+doc this weekend -- about 5300 lines of straight code, I
think.  Anyways, the basic required functionality is now in place, so
I'm open to clever refactoring/reduction/simplification patches.

        Greg



From guido at beopen.com  Wed Jun 28 17:41:26 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 10:41:26 -0500
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Wed, 28 Jun 2000 02:23:40 -0400."
             <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> 
Message-ID: <200006281541.KAA02041@cj20424-a.reston1.va.home.com>

> Since we (PythonLabs, last week) decided to continue using Jitterbug (on
> python.org) for now, should the SF Bug Manager even be enabled?  If it is
> enabled, and we are using Jitterbug, then someone has to own reentering SF
> bugs into the Jitterbug system.

OK, I've disabled the SF bugs manager.  There were two bugs submitted
so far.  I've assigned one to you (about os.listdir on Windows) and
one to MAL (about -U vs. exec/eval).  You two can take care of
entering these into JB.  You can still access the bugs database via
this URL:

https://sourceforge.net/bugs/?group_id=5470

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



From gward at mems-exchange.org  Wed Jun 28 17:35:05 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 28 Jun 2000 11:35:05 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 01:07:24PM +0200
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
Message-ID: <20000628113505.C15643@ludwig.cnri.reston.va.us>

On 28 June 2000, Fredrik Lundh said:
> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt
> 
> unfortunately, his "What is it with those Python fucks anyway" talk
> isn't posted... ;-)

But the "Conclusion" of his "Lies We Tell" talk:

   Perl sucks. Use Python.

Presumably tongue-in-cheek, but you never know...

        Greg



From trentm at activestate.com  Wed Jun 28 18:53:19 2000
From: trentm at activestate.com (Trent Mick)
Date: Wed, 28 Jun 2000 09:53:19 -0700
Subject: [Python-Dev] back up & running
In-Reply-To: <200006281222.OAA03150@python.inrialpes.fr>
References: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> <200006281222.OAA03150@python.inrialpes.fr>
Message-ID: <20000628095319.C14129@activestate.com>

On Wed, Jun 28, 2000 at 02:22:56PM +0200, Vladimir Marangozov wrote:
> Fred L. Drake, Jr. wrote:
> > 
> >   My mega-laptop got fixed faster than I'd expected, so I'm back up to
> > doing useful work.  My top priorities are handling patches and going
> > back through my email to find all the documentation patches that have
> > sat idle for too long.
> 
> Excellent!
> 
> Finally someone who cares to checkin patches. I've been disappointed
> to see that the June 30 intent-date was announced, but people keep
> chewing-gumming about SourceForge caveats while the patches backlog
> grows and the number of closed patches stays invariably to 3, of which
> one is a test!
> 

You can count me as one of the significatn bottlenecks here. Tim and Guido
have accepted some of my patches, I just have to check them in. Real Soon Now
(tm).


Trent Mick (also tm)

-- 
Trent Mick
trentm at activestate.com



From mal at lemburg.com  Wed Jun 28 18:57:35 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Jun 2000 18:57:35 +0200
Subject: [Python-Dev] Named Unicode Characters
Message-ID: <395A2E7F.A1DDEC35@lemburg.com>

I've just checked in the patches by Bill Tutt, which add
support for \N{NAMED UNICODE CHARACTERS}. The new escape
code is available per default in the standard unicode-escape
codec. The (big) hash table needed to drive the mapping
is loaded on demand to reduce memory overhead.

The patch also includes a new tool called perfecthash which
is used to generate the hash table (and function) from 
names to ordinals. I'm sure this can be of use in other
areas too... but it needs some more work to become more
generic (currently you have to edit the source code to generate
other mapping modules).

Thanks to Bill Tutt -- this is great work !

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From paul at prescod.net  Wed Jun 28 19:11:19 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:11:19 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
Message-ID: <395A31B7.911D9BC2@prescod.net>

Fredrik Lundh wrote:
> 
> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

How about this one:

http://gisle.aas.no/perl/illguts/

Just thank your lucky stars...

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From paul at prescod.net  Wed Jun 28 19:16:45 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:16:45 -0700
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>
Message-ID: <395A32FD.D3C58B23@prescod.net>

I don't want to be paranoid, but are we putting any important
information into SourceForge that we are not backing up elsewhere? I
mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust
suit...) would we have backups of our patches, bugs, wish lists and so
forth? I hope that's a criteria in deciding what services to move to
SourceForge. I am in the business of preserving investments in data and
of telling customers to avoid software that does not keep them in
complete control of their data. SF makes me nervous that way....

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From mal at lemburg.com  Wed Jun 28 19:22:40 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Jun 2000 19:22:40 +0200
Subject: [Python-Dev] Checkin Utility
Message-ID: <395A3460.3FF013F0@lemburg.com>

I thought you might have some use for the attached utility. It's
a simple script which helps with checking in patches which I've
been using for a while now. It also hides the CVS options and
parameters away as far as possible, so that CVS knowledge is
not really needed to complete the task.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: checkin.py
Type: text/python
Size: 8070 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000628/3e29b91c/attachment-0001.bin>

From esr at thyrsus.com  Wed Jun 28 19:38:05 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 28 Jun 2000 13:38:05 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:11:19AM -0700
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net>
Message-ID: <20000628133805.D20855@thyrsus.com>

Paul Prescod <paul at prescod.net>:
> http://gisle.aas.no/perl/illguts/
> 
> Just thank your lucky stars...

Ghods.  Reading that just about ruined my lunch.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"The power to tax involves the power to destroy;...the power to
destroy may defeat and render useless the power to create...."
	-- Chief Justice John Marshall, 1819.



From paul at prescod.net  Wed Jun 28 19:27:54 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:27:54 -0700
Subject: [Python-Dev] Text about cycle GC
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>
Message-ID: <395A359A.2CF0CA70@prescod.net>

"A.M. Kuchling" wrote:
> 
> ...
> 
>    An experimental step has been made toward fixing this problem. When
>    compiling Python, the -with-cycle-gc (XXX correct option flag?) option
>    can be specified. This causes a cycle detection algorithm to be
>    periodically executed, which looks for inaccessible cycles and deletes
>    the objects involved.

I propose (without any investigation into the difficulty of
implementation) that 

import cyclicgc

should turn on the -with-cycle-gc flag.

Then you could do a 

import cyclicgc
import someDOM

And not worry about cycles. If it's too slow, you remove the line and
take responsibility for cycle checking. The important thing is that you
don't have to tell YOUR USERS to turn on GC in order for your code to
work.

I think that this model will get more people actively using (and
depending upon!) GC and thus give us a better idea about usage patterns,
stability and performance. This is especially important in the beta
period when we are trying to shake out bugs.

Really, this comes back to Greg's point that we should not have
incompatible sub-languages running around. A module depends on the
feature or it doesn't. The end-user should not be responsible for
knowing whether any module in a whole program needs GC.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From paul at prescod.net  Wed Jun 28 19:34:35 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:34:35 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com>
Message-ID: <395A372B.34E15A62@prescod.net>

"Eric S. Raymond" wrote:
> 
> Ghods.  Reading that just about ruined my lunch.

You read it? Eric, I was just kidding!

Actually, my theory is that the whole thing is a big, extended, April
Fools joke.

Not the document. The language. (rimshot)

 SvOOK-vs-SvIV-and-SvNV-indeed-ly 'yrs

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From gmcm at hypernet.com  Wed Jun 28 19:37:07 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 28 Jun 2000 13:37:07 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
Message-ID: <1249908601-39717068@hypernet.com>

> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

What I noticed is that Tim is mentioned in every other 
paragraph.

Where-does-he-find-the-time?-ly y'rs

- Gordon



From jeremy at beopen.com  Wed Jun 28 19:41:50 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 28 Jun 2000 13:41:50 -0400 (EDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
	<395A31B7.911D9BC2@prescod.net>
Message-ID: <14682.14558.380773.307392@bitdiddle.concentric.net>

>>>>> "PP" == Paul Prescod <paul at prescod.net> writes:

  PP> Fredrik Lundh wrote:
  >>  http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt

  PP> How about this one:

  PP> http://gisle.aas.no/perl/illguts/

  PP> Just thank your lucky stars...

What beautiful diagrams!  It almost makes me wish Python was
complicated enough to require such pretty pictures.

Jeremy



From guido at beopen.com  Wed Jun 28 20:41:48 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 13:41:48 -0500
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: Your message of "Wed, 28 Jun 2000 10:16:45 MST."
             <395A32FD.D3C58B23@prescod.net> 
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>  
            <395A32FD.D3C58B23@prescod.net> 
Message-ID: <200006281841.NAA03154@cj20424-a.reston1.va.home.com>

[PP]
> I don't want to be paranoid, but are we putting any important
> information into SourceForge that we are not backing up elsewhere? I
> mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust
> suit...) would we have backups of our patches, bugs, wish lists and so
> forth? I hope that's a criteria in deciding what services to move to
> SourceForge. I am in the business of preserving investments in data and
> of telling customers to avoid software that does not keep them in
> complete control of their data. SF makes me nervous that way....

Good point.

SF has a way to get a nightly snapshot of the CVS tree.  We should
suggest that they provide snapshots (in XML of course!) of the bugs
database too.

Note that I have no bandwidth left to communicate to SF folks so this
is up to the user community.  (I'm also very optimistic and trusting
in nature. :-)

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



From jeremy at beopen.com  Wed Jun 28 19:49:32 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 28 Jun 2000 13:49:32 -0400 (EDT)
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <395A359A.2CF0CA70@prescod.net>
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>
	<395A359A.2CF0CA70@prescod.net>
Message-ID: <14682.15020.589514.702145@bitdiddle.concentric.net>

>>>>> "PP" == Paul Prescod <paul at prescod.net> writes:

  PP> "A.M. Kuchling" wrote:
  >>  ...
  >> 
  >> An experimental step has been made toward fixing this
  >> problem. When compiling Python, the -with-cycle-gc (XXX correct
  >> option flag?) option can be specified. This causes a cycle
  >> detection algorithm to be periodically executed, which looks for
  >> inaccessible cycles and deletes the objects involved.

  PP> I propose (without any investigation into the difficulty of
  PP> implementation) that

  PP> import cyclicgc

  PP> should turn on the -with-cycle-gc flag.

The -with-cycle-gc flag is an option to configure when you build
Python.  It can't be turned on or off at runtime.

We hope that everyone will build with the -with-cycle-gc flag during
the beta testing, but we don't expect to have enough confidence in it
by final release to make it anything other than an experimental
option. 

Jeremy



From esr at thyrsus.com  Wed Jun 28 20:02:37 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 28 Jun 2000 14:02:37 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A372B.34E15A62@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:34:35AM -0700
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> <395A372B.34E15A62@prescod.net>
Message-ID: <20000628140237.A21043@thyrsus.com>

Paul Prescod <paul at prescod.net>:
> "Eric S. Raymond" wrote:
> > 
> > Ghods.  Reading that just about ruined my lunch.
> 
> You read it? Eric, I was just kidding!

Yes, I read it.  Un-fscking-believable.  I knew Perl was complicated and
ugly on the inside, but the full horror had not obtruded itself on me
before now.  If I'm any judge, that's an implementation on the brink of
collapsing under its own weight.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Non-cooperation with evil is as much a duty as cooperation with good.
	-- Mohandas Gandhi



From paul at prescod.net  Wed Jun 28 19:53:16 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 10:53:16 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
		<395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net>
Message-ID: <395A3B8B.B6117DA1@prescod.net>

Note that the document doesn't yet cover the regular expression engine
or the "PerlInterpreter". 

I can't think of a disclaimer that doesn't sound like it is tongue in
cheek but I do feel bad about beating up on a design which, in its own
way, has a certain kind of quality (just not one I happen to prefer).
When you optimize the snot out of things they tend to start looking
ugly. Perl runs faster than Python. That's probably not a coincidence.

Jeremy Hylton wrote:
> 
> What beautiful diagrams!  It almost makes me wish Python was
> complicated enough to require such pretty pictures.

To be fair, our internals documentation needs some work. I'll bet there
are a lot of people in comp.lang.python that would be interested in a
project like that or another one, such as adding a full warning
infrastructure to Python. I wonder how we could do a Software Carpentry
like deal (no money) where we get people to submit designs and ideas and
then "award" the job to someone. They could do it for reputational
capital and an opportunity to join "the team" (of CVS committers,
PythonDev denizens etc.).

It's probably better to give people ideas rather than have them
implement random things that we will need to turn down. Like stackless.
<duck and cover!!!>
-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From paul at prescod.net  Wed Jun 28 20:09:38 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 11:09:38 -0700
Subject: [Python-Dev] Text about cycle GC
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com>
		<395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net>
Message-ID: <395A3F62.EA1E8B89@prescod.net>

Jeremy Hylton wrote:
> 
> ....
> 
> The -with-cycle-gc flag is an option to configure when you build
> Python.  It can't be turned on or off at runtime.

Doh! Sorry. Andrew's text does say that but I didn't read carefully and
testing it with my stuff hasn't floated to the top yet (because when I
looked into it, I realized I'd have to recompile...double doh!)
Compiling is really slow on my "transitional" computer.

I'm a little disappointed that it will be so difficult for people to
test with GC on, but I'm not going to claim that there is some easy way
to make it a runtime option because I haven't looked at it at all. There
probably isn't.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From nascheme at enme.ucalgary.ca  Wed Jun 28 20:27:25 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Wed, 28 Jun 2000 12:27:25 -0600
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <395A3F62.EA1E8B89@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 11:09:38AM -0700
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net>
Message-ID: <20000628122725.A13473@acs.ucalgary.ca>

On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote:
> I'm a little disappointed that it will be so difficult for people to
> test with GC on, but I'm not going to claim that there is some easy way
> to make it a runtime option because I haven't looked at it at all. There
> probably isn't.

There isn't.  With an interpreter compiled --with-cycle-gc you can
turn off the collection with gc.set_threshold(0) but that's not
the same thing.

  Neil



From bwarsaw at beopen.com  Wed Jun 28 20:33:23 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 14:33:23 -0400 (EDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
	<395A31B7.911D9BC2@prescod.net>
	<20000628133805.D20855@thyrsus.com>
	<395A372B.34E15A62@prescod.net>
	<20000628140237.A21043@thyrsus.com>
Message-ID: <14682.17651.552666.318592@anthem.concentric.net>

>>>>> "ESR" == Eric S Raymond <esr at thyrsus.com> writes:

    ESR> Yes, I read it.  Un-fscking-believable.  I knew Perl was
    ESR> complicated and ugly on the inside, but the full horror had
    ESR> not obtruded itself on me before now.  If I'm any judge,
    ESR> that's an implementation on the brink of collapsing under its
    ESR> own weight.

And of course, we'll be right there to pick up the pieces. :)



From guido at beopen.com  Wed Jun 28 21:43:06 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 14:43:06 -0500
Subject: [Python-Dev] Python 1.6 schedule
Message-ID: <200006281943.OAA03414@cj20424-a.reston1.va.home.com>

I've updated the 1.6 page on python.org (http://www.python.org/1.6/)
to include the latest schedule for 1.6.  I've also included a link to
Andrew's "what's new" article.  Here's the new schedule in text form:

  July 1: beta 1; feature freeze. 

  July 14: beta 2, in time for the O'Reilly Open Source Software Convention. 

  August 1: release candidate. 

  August 15: final release. 

I'm happy with how the patches are coming along today (/F even
submitted the SRE patch...).  We may actually have a release party
Saturday!

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



From guido at beopen.com  Wed Jun 28 22:27:43 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 15:27:43 -0500
Subject: [Python-Dev] Named Unicode Characters
In-Reply-To: Your message of "Wed, 28 Jun 2000 18:57:35 +0200."
             <395A2E7F.A1DDEC35@lemburg.com> 
References: <395A2E7F.A1DDEC35@lemburg.com> 
Message-ID: <200006282027.PAA04607@cj20424-a.reston1.va.home.com>

> I've just checked in the patches by Bill Tutt, which add
> support for \N{NAMED UNICODE CHARACTERS}. The new escape
> code is available per default in the standard unicode-escape
> codec. The (big) hash table needed to drive the mapping
> is loaded on demand to reduce memory overhead.
> 
> The patch also includes a new tool called perfecthash which
> is used to generate the hash table (and function) from 
> names to ordinals. I'm sure this can be of use in other
> areas too... but it needs some more work to become more
> generic (currently you have to edit the source code to generate
> other mapping modules).
> 
> Thanks to Bill Tutt -- this is great work !

Thanks Bill and Marc-Andre!

I've closed the patch in SF now.

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



From tim_one at email.msn.com  Wed Jun 28 21:40:18 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 15:40:18 -0400
Subject: [Python-Dev] back up & running
In-Reply-To: <20000628095319.C14129@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEPMGGAA.tim_one@email.msn.com>

[Vladimir Marangozov]
> ...
> I've been disappointed to see that the June 30 intent-date was
> announced, but people keep chewing-gumming about SourceForge
> caveats while the patches backlog grows and the number of closed
> patches stays invariably to 3, of which one is a test!

Absolutely on-target, Vladimir!  The current state of our world is
embarrassing.  Someday when the bosses aren't listening, I'll explain to you
how it got this way <0.9 wink>.

[Trent Mick]
> You can count me as one of the significant bottlenecks here. Tim and
> Guido have accepted some of my patches, I just have to check them in.
> Real Soon Now (tm).

Trent, you are *not* a bottleneck!  You've cooperated with the process (or
lack thereof) every step of the way, and it hasn't even been 12 hours since
I accepted some of your patches.  And the bulk of them are still on my plate
to review.

I don't think we have an actual bottleneck now, but we do have a large
backlog to work off, and people with too many things that need to be done.

perseverance-and-patience-will-probably-work-better-than-their-opposites-ly
    y'rs  - tim





From gstein at lyra.org  Wed Jun 28 21:46:06 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 12:46:06 -0700
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <200006281455.JAA01690@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 09:55:00AM -0500
References: <20000627184615.A29590@lyra.org> <200006281455.JAA01690@cj20424-a.reston1.va.home.com>
Message-ID: <20000628124606.K29590@lyra.org>

On Wed, Jun 28, 2000 at 09:55:00AM -0500, Guido van Rossum wrote:
> > A while back, I pulled the "demo" importers out of imputil.py. I think those
> > should be added into Demo/imputil/.
> 
> OK.  Go ahead and create that directory and add the demo importers.

Will do.

> > It would also be Goodness to include JimA's zipimporter. Where would that go?
> 
> Same place I'd hope?  Can you check that it works?

Yup and yup.

> We're dependent on you volunteers to maintain relatively non-core
> things like this -- I don't want to extend the feature freeze to
> Demo/, but I also don't have the time to keep the stuff there up to
> date.

Not a problem, and I had figured on being the "point man" on keeping it
working. My query here was more along the lines of "is Demo/imputil/ a good
idea? If so, then I'll run with it." You said "yes", so I'll go put on my
shoes.

> Maybe at some point the Demo directory should become a separate
> distribution, or just a collection of stuff on the web?

I believe a separate distribution. Unpacking the bugger to the main web site
would also be a good option, but that would be a second priority.

I'd throw Tools into the same thing. As a separate distro, you can have a
faster release cycle. ... you could release Idle updates easily and
distinctly from the Python core.

Note: by a "collection on the web", the only view that I have, is that the
collection exists on the python.org web site. Distributed pieces "here and
there" is handled by the Vaults (and similar). The Demo/ directory is a bit
more newbie-ish, so (IMO) it ought to get bundled up somehow since the
Vaults are a bit daunting to find "example of embedding". If the bundle also
happens to reside in an obvious area on python.org? Great.

Cheers,
-g

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



From tim_one at email.msn.com  Wed Jun 28 21:54:42 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 15:54:42 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEABGHAA.tim_one@email.msn.com>

[Paul Prescod]
> How about this one:
>
> http://gisle.aas.no/perl/illguts/

> Just thank your lucky stars...

Ack, don't get me started -- well, I'd love to, but have real work to do.
I've posted about that before.  I'm not infrequently amazed that they manage
to keep Perl running at all.  The amazing thing about the PerlGuts doc above
is that it was apparently reverse-engineered by staring at Perl's
implementation code.  You can't find any of it explained in the source!

either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter-
    than-us-and-i-know-which-of-those-i'm-more-likely-to-
    believe<wink>-ly y'rs  - tim





From guido at beopen.com  Wed Jun 28 22:59:46 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 15:59:46 -0500
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: Your message of "Wed, 28 Jun 2000 12:27:25 CST."
             <20000628122725.A13473@acs.ucalgary.ca> 
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net>  
            <20000628122725.A13473@acs.ucalgary.ca> 
Message-ID: <200006282059.PAA04852@cj20424-a.reston1.va.home.com>

> On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote:
> > I'm a little disappointed that it will be so difficult for people to
> > test with GC on, but I'm not going to claim that there is some easy way
> > to make it a runtime option because I haven't looked at it at all. There
> > probably isn't.
> 
> There isn't.  With an interpreter compiled --with-cycle-gc you can
> turn off the collection with gc.set_threshold(0) but that's not
> the same thing.
> 
>   Neil

I wonder if we should turn this option *on* during beta testing?

That way we gather a lot more experience with its use!  Maybe nobody
complains and we can leave it on in the final release...

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



From akuchlin at mems-exchange.org  Wed Jun 28 22:10:28 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 16:10:28 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A3B8B.B6117DA1@prescod.net>
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net> <395A3B8B.B6117DA1@prescod.net>
Message-ID: <20000628161028.C23352@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 10:53:16AM -0700, Paul Prescod wrote:
>Note that the document doesn't yet cover the regular expression engine
>or the "PerlInterpreter". 

The regex engine's pretty hard to read, mostly because comments are
infrequent and not very helpful, and disentangling it from the rest of
Perl would require a skilled wizard.  (PCRE, if slower, is at least
much clearer and easier to understand, though the compile() function
is pretty ugly.)  A while ago I saw a p5p post from Ilya Zakharevich
who did most of the recent regex hacking; he draw attention to one
flag variable in the code and said basically "I don't know what this
flag means; I think it's some sort of UTF-8 setting, but Larry didn't
explain it."

>I can't think of a disclaimer that doesn't sound like it is tongue in
>cheek but I do feel bad about beating up on a design which, in its own
>way, has a certain kind of quality (just not one I happen to prefer).

Agreed; it could be made much simpler, but maybe at a performance
cost.  (Though performance is tricky, and maybe the extra work costs
more than it saves.)

For example, note the flag bits in SvNULL, which have values like
GMAGICAL.  You could imagine a Python implementation that added flag
bits to every object, and set a bit if there was a __getattr__ method
defined; code could then do 'if (obj->flags & GMAGICAL) ...'  instead
of the more complicated 'if (PyObject_HasAttrString(obj,
"__getattr__")'.  It would be interesting to know if Topaz, Chip
Salzenberg's experimental C++ implementation, preserves this
complexity or aims to cut it away.  The use of several levels of C
structs is also reminiscent of the way you do OO in C, as in X
toolkits.

You can also see the importance of text processing in the SvPVBM type,
for attaching a Boyer-Moore related table to a string and speeding up
regex searches.  

--amk



From tim_one at email.msn.com  Wed Jun 28 22:15:34 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 16:15:34 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A3B8B.B6117DA1@prescod.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com>

[Paul Prescod]
> ...
> When you optimize the snot out of things they tend to start looking
> ugly. Perl runs faster than Python. That's probably not a coincidence.

More, IMO it's not even true.  I can't make time for this now, but on
several occasions I've coded the same algorithm in idiomatic Perl and
Python, and Python was invariably faster (not talking orders of magnitude,
but 10-40%).

The catch is that I know something about both implementations, and avoided
the sweet spots in both.  Perl gets enormous bang out of its line-at-a-time
text file input "cheating", and its integrated regexps.  Avoid those, and
it's generally *slower* in my experience, which is perfectly consistent with
the relative messiness of its implementation (all those magic flags aren't
passive, they need runtime conditionals to use!  Perl can't even inline its
refcount manipulations because they're so complicated due to the flags).

Against that, line-at-a-time text file input in particular is something that
every newbie bumps into at once, and Perl does have a monster advantage
there (at least 2x faster, probably closer to 3 on most platforms).  Perl
doesn't really look like it was designed to "be fast" in general -- it looks
like it was designed to be supernaturally fast in specific situations.  Best
I've been able to tell, that's how it *acts*, too.

I'm keen to add comparable (but limited) internal warts to Python, but for
*general* speedup ideas we'll be much better off looking to, e.g., Dylan and
Squeak.

all-that-said-python-is-fast-enough-for-me-already!-ly y'rs  - tim





From DavidA at ActiveState.com  Wed Jun 28 22:17:46 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Wed, 28 Jun 2000 13:17:46 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEABGHAA.tim_one@email.msn.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJKENKCKAA.DavidA@ActiveState.com>

> either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter-
>     than-us-and-i-know-which-of-those-i'm-more-likely-to-
>     believe<wink>-ly y'rs  - tim

I was sitting next to Gisle (the author of said document) when he started to
work on the Perl methods work for Zope. Within a day, starting w/ not
knowing anything about Python, he had Perl embedded in Python.  It says much
about the cleanliness of Python's design and the quality of its
documentation that Gisle could do that.  It also says a lot about Gisle, as
does the perlguts document

Not saying anything about anyone being nuts, especially when responding to
someone who talks about his in public. <ha&bang;/>

--david





From pingster at ilm.com  Wed Jun 28 22:22:15 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Wed, 28 Jun 2000 13:22:15 -0700 (PDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <20000628161028.C23352@kronos.cnri.reston.va.us>
Message-ID: <Pine.SGI.3.96.1000628131524.621134y-100000@happy>

On Wed, 28 Jun 2000, Andrew Kuchling wrote:
> You could imagine a Python implementation that added flag
> bits to every object, and set a bit if there was a __getattr__ method
> defined; code could then do 'if (obj->flags & GMAGICAL) ...'  instead
> of the more complicated 'if (PyObject_HasAttrString(obj,
> "__getattr__")'.

That looks like a reasonable sort of optimization to me, though
as far as i can tell it looks like that optimization has already
been done:

in PyClass_New(bases, dict, name):
    [...]
    op->cl_getattr = class_lookup(op, getattrstr, &dummy);
    [...]

in instance_getattr(inst, name):
    if (res == NULL && (func = inst->in_class->cl_getattr) != NULL) {
        [...special __getattr__ handling...]
    }

In general, optimizations of the form "add a flag to avoid a
frequent expensive test" seem okay to me, as long they are a
demonstrable win and the flag can be given a clear, simple name.


-- ?!ng

"To be human is to continually change.  Your desire to remain what
you are is what ultimately limits you."
    -- The Puppet Master, Ghost in the Shell




From akuchlin at mems-exchange.org  Wed Jun 28 22:25:54 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 16:25:54 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <Pine.SGI.3.96.1000628131524.621134y-100000@happy>
References: <20000628161028.C23352@kronos.cnri.reston.va.us> <Pine.SGI.3.96.1000628131524.621134y-100000@happy>
Message-ID: <20000628162554.E23352@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 01:22:15PM -0700, Ka-Ping Yee wrote:
>That looks like a reasonable sort of optimization to me, though
>as far as i can tell it looks like that optimization has already
>been done:

Damn time machine again...

--amk



From tim_one at email.msn.com  Wed Jun 28 22:31:58 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 16:31:58 -0400
Subject: SourceForge patch notifications (was RE: [Python-Dev] ANN: Release schedule)
In-Reply-To: <20000628090230.A14129@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEAIGHAA.tim_one@email.msn.com>

[Trent Mick]
> ...
> BTW I have answered a couple a questions on my patches. Does
> the person to whom the patch is assigned get an update notification?

Trent & I investigated this offline:  he added a comment to one of his
patches to which I am assigned.  I did indeed get prompt email notification,
although as everyone has noticed by now, there's no indication from SF about
*why* I was getting notified; just:

From: noreply at sourceforge.net [mailto:noreply at sourceforge.net]
Sent: Wednesday, June 28, 2000 12:01 PM
To: tmick at mail.com; tim_one at email.msn.com
Subject: [Patch #100513] fix posixmodule for 64-bit systems (mainly Win64)


Patch #100513 has been updated.
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100513&group_id=5470


So the outcome could have been worse <wink>.

a-new-criterion-for-excellence-ly y'rs  - tim





From effbot at telia.com  Wed Jun 28 22:42:56 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 22:42:56 +0200
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com>
Message-ID: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>

tim wrote:
> Against that, line-at-a-time text file input in particular is something that
> every newbie bumps into at once, and Perl does have a monster advantage
> there (at least 2x faster, probably closer to 3 on most platforms).

and 2-3x is what you get if you replace readline with readlines,
as described in this note:
http://w1.132.telia.com/~u13208596/notes/readline-performance.htm

it would be very nice if the file object could do something similar
internally (only in text mode, perhaps).  maybe in 1.7?

(as I've mentioned earlier, SRE+faster IO can result in a 10x speedup
for a straightforward while/readline/match loop...)

</F>




From jack at oratrix.nl  Wed Jun 28 22:58:27 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 28 Jun 2000 22:58:27 +0200
Subject: [Python-Dev] ucnhash module
Message-ID: <20000628205832.C3234E2673@oratrix.oratrix.nl>

I'm a bit worried about the ucnhash module and its huge size. I didn't 
follow the discussion closely at the time, because I thought I could
always exclude it from the Pythons without dynamic linking, but now it 
seems that if i don't include it test_unicode doesn't run anymore.

Is this a problem with test_unicode, or should I consider ucnhash a
mandatory module?

(BTW: there were also a couple of bugs in the module, include <> in
stead of include "", and static in stead of staticforward
declarations, I'll submit patches for those 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/ ++++



From gstein at lyra.org  Wed Jun 28 23:03:42 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 14:03:42 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com> <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>
Message-ID: <20000628140342.Q29590@lyra.org>

On Wed, Jun 28, 2000 at 10:42:56PM +0200, Fredrik Lundh wrote:
> tim wrote:
> > Against that, line-at-a-time text file input in particular is something that
> > every newbie bumps into at once, and Perl does have a monster advantage
> > there (at least 2x faster, probably closer to 3 on most platforms).
> 
> and 2-3x is what you get if you replace readline with readlines,
> as described in this note:
> http://w1.132.telia.com/~u13208596/notes/readline-performance.htm
> 
> it would be very nice if the file object could do something similar
> internally (only in text mode, perhaps).  maybe in 1.7?

That could be troublesome. It should only be done if the file is seekable so
that you can rewind. If a readline() on (say) a socket moved you *past* the
newline, then you could be in big trouble. Or what happens in said socket is
blocking? etc.

Now... please don't start a thread about this now. Wait for post 1.6. Maybe
I'm totally off, and some smart guy here can say so. But it just doesn't
matter, so I'd rather not have to read a whole thread on the stuff :-)

Cheers,
-g

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



From gstein at lyra.org  Wed Jun 28 23:14:41 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 14:14:41 -0700
Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69)
In-Reply-To: <200006281553.IAA11238@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 08:53:17AM -0700
References: <200006281553.IAA11238@slayer.i.sourceforge.net>
Message-ID: <20000628141441.R29590@lyra.org>

Woah. Never knew this was in Python.

It is quite interesting, as there is a very similar concept within Apache.
In that model, you register a cleanup function for the particular data that
needs to be cleaned post-fork. After the fork occurs, the cleanups are
called.

In essence, Python would register PyOS_AfterFork. Of course, any schmoe can
call fork() and avoid the cleanups, so it bungs up the whole scheme. In
Apache, the "only" way to fork is to call an APR function, which guarantees
the cleanups.

Cheers,
-g

On Wed, Jun 28, 2000 at 08:53:17AM -0700, Fred L. Drake wrote:
> Update of /cvsroot/python/python/dist/src/Doc/api
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv11228/api
> 
> Modified Files:
> 	api.tex 
> Log Message:
> 
> Added documentation for PyOS_AfterFork().
> 
> 
> Index: api.tex
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Doc/api/api.tex,v
> retrieving revision 1.68
> retrieving revision 1.69
> diff -C2 -r1.68 -r1.69
> *** api.tex	2000/06/18 05:21:21	1.68
> --- api.tex	2000/06/28 15:53:13	1.69
> ***************
> *** 1034,1037 ****
> --- 1034,1044 ----
>   \end{cfuncdesc}
>   
> + \begin{cfuncdesc}{void}{PyOS_AfterFork}{}
> + Function to update some internal state after a process fork; this
> + should be called in the new process if the Python interpreter will
> + continue to be used.  If a new executable is loaded into the new
> + process, this function does not need to be called.
> + \end{cfuncdesc}
> + 
>   
>   \section{Process Control \label{processControl}}
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From effbot at telia.com  Wed Jun 28 23:19:36 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 28 Jun 2000 23:19:36 +0200
Subject: [Python-Dev] exceptions trouble
Message-ID: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>

import traceback
try:
    raise SyntaxError, "argument"
except:
    traceback.print_exc()

prints:

Traceback (most recent call last):
  File "test.py", line 3, in ?
    raise SyntaxError, "argument"
Traceback (most recent call last):
  File "test.py", line 5, in ?
    traceback.print_exc()
  File "C:\py16\lib\traceback.py", line 182, in print_exc
    print_exception(etype, value, tb, limit, file)
  File "C:\py16\lib\traceback.py", line 110, in print_exception
    lines = format_exception_only(etype, value)
  File "C:\py16\lib\traceback.py", line 169, in format_exception_only
    list.append('%s: %s\n' % (str(stype), str(value)))
SystemError: new style getargs format but argument is not a tuple

not really what I expected.  am I out of sync, or have I
stumbled upon a bug in the new exceptions code?

</F>




From tim_one at email.msn.com  Wed Jun 28 23:21:52 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 17:21:52 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <20000628140342.Q29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEAMGHAA.tim_one@email.msn.com>

[Greg Stein]
> ...
> Now... please don't start a thread about this now. Wait for post
> 1.6.

Amen.

> Maybe I'm totally off, and some smart guy here can say so. But it
> just doesn't matter, so I'd rather not have to read a whole thread
> on the stuff :-)

If you change your mind, you can go back in the archives and read at least
two old threads on the topic -- it's not like there's actually anything new
here <wink>.





From akuchlin at mems-exchange.org  Wed Jun 28 23:30:38 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Jun 2000 17:30:38 -0400
Subject: [Python-Dev] exceptions trouble
In-Reply-To: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>
References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>
Message-ID: <20000628173038.B28659@kronos.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 11:19:36PM +0200, Fredrik Lundh wrote:
>SystemError: new style getargs format but argument is not a tuple
>not really what I expected.  am I out of sync, or have I
>stumbled upon a bug in the new exceptions code?

It works fine in my current copy of the CVS tree, and I think I
rebuilt everything this morning.

--amk



From fdrake at beopen.com  Wed Jun 28 23:32:36 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 17:32:36 -0400 (EDT)
Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69)
In-Reply-To: <20000628141441.R29590@lyra.org>
References: <200006281553.IAA11238@slayer.i.sourceforge.net>
	<20000628141441.R29590@lyra.org>
Message-ID: <14682.28404.125379.249287@cj42289-a.reston1.va.home.com>

Greg Stein writes:
 > Woah. Never knew this was in Python.

  I didn't either, until I read a patch that used it.  That's one way
to keep the documentation up to date!  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From gstein at lyra.org  Wed Jun 28 23:48:00 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 14:48:00 -0700
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <200006282112.OAA03095@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:12:28PM -0700
References: <200006282112.OAA03095@slayer.i.sourceforge.net>
Message-ID: <20000628144800.T29590@lyra.org>

On Wed, Jun 28, 2000 at 02:12:28PM -0700, Guido van Rossum wrote:
>...
> - chunk #2: 
> The id() function guarantees a unique return value for different
> objects.  It does this by returning the pointer to the object. By
> returning a PyInt, on Win64 (sizeof(long) < sizeof(void*)) the pointer
> is truncated and the guarantee may be proven false. The appropriate
> return function is PyLong_FromVoidPtr, this returns a PyLong if that
> is necessary to return the pointer without truncation.
> 
> [GvR: note that this means that id() can now return a long on Win32
> platforms.  This *might* break some code...]

Strictly speaking: the Long only occurs on Win64 platforms.

I would guess that it is also possible on say, an Alpha running Linux.
Presuming that has 64-bit pointers(?).

Regardless: yes, it can certainly break some code. IMO, if any code out
there makes any kinds of assumptions about id(), then they deserve to be
broken :-)

Cheers,
-g

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



From paul at prescod.net  Wed Jun 28 23:44:33 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 14:44:33 -0700
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com> <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> <20000628140342.Q29590@lyra.org>
Message-ID: <395A71C1.A4E332D@prescod.net>

Re: Performance

At the very least this readlines() optimization should be in FileInput
which was invented, after all, in order to compete with Perl.
---
Re: Inline Unicode smily faces

Bill and Mark-Andre, you rock. Another feature stolen from Perl.

If only it were as easy to steal cleanliness and elegance. :)
---
Re: GC

On by default in beta would be peachy.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From bwarsaw at beopen.com  Thu Jun 29 00:01:00 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 18:01:00 -0400 (EDT)
Subject: [Python-Dev] exceptions trouble
References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid>
	<20000628173038.B28659@kronos.cnri.reston.va.us>
Message-ID: <14682.30108.714768.740415@anthem.concentric.net>

>>>>> "AK" == Andrew Kuchling <akuchlin at mems-exchange.org> writes:

    AK> It works fine in my current copy of the CVS tree, and I think
    AK> I rebuilt everything this morning.

Same here.



From trentm at activestate.com  Thu Jun 29 00:04:28 2000
From: trentm at activestate.com (Trent Mick)
Date: Wed, 28 Jun 2000 15:04:28 -0700
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <20000628144800.T29590@lyra.org>
References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org>
Message-ID: <20000628150428.E17875@activestate.com>

On Wed, Jun 28, 2000 at 02:48:00PM -0700, Greg Stein wrote:
> Regardless: yes, it can certainly break some code. IMO, if any code out
> there makes any kinds of assumptions about id(), then they deserve to be
> broken :-)

Amen.

Trent

-- 
Trent Mick
trentm at activestate.com



From nascheme at enme.ucalgary.ca  Thu Jun 29 00:07:43 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Wed, 28 Jun 2000 16:07:43 -0600
Subject: [Python-Dev] id() on Win64
Message-ID: <20000628160743.A16262@acs.ucalgary.ca>

[Greg Stein]
>Strictly speaking: the Long only occurs on Win64 platforms.
>
>I would guess that it is also possible on say, an Alpha running
>Linux.  Presuming that has 64-bit pointers(?).

I think the Alpha is okay. The problem is strange type models
were int is 32 bits and pointers are 64.  AFAIK, the Alpha uses
64 bits for both.

  Neil



From guido at beopen.com  Thu Jun 29 01:10:52 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 18:10:52 -0500
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: Your message of "Wed, 28 Jun 2000 14:48:00 MST."
             <20000628144800.T29590@lyra.org> 
References: <200006282112.OAA03095@slayer.i.sourceforge.net>  
            <20000628144800.T29590@lyra.org> 
Message-ID: <200006282310.SAA05850@cj20424-a.reston1.va.home.com>

> > [GvR: note that this means that id() can now return a long on Win32
> > platforms.  This *might* break some code...]
> 
> Strictly speaking: the Long only occurs on Win64 platforms.

You're right.

> I would guess that it is also possible on say, an Alpha running Linux.
> Presuming that has 64-bit pointers(?).

No, because their longs are also 64 bits, and hence so are Python ints.

> Regardless: yes, it can certainly break some code. IMO, if any code out
> there makes any kinds of assumptions about id(), then they deserve to be
> broken :-)

That depends.  It is documented as an integer -- which may be vague
enough to encompass longs, but that's weasel-wording. ;-)

I do think that the likelihood of this breaking significant code is low.

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



From gstein at lyra.org  Thu Jun 29 00:17:58 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 15:17:58 -0700
Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
In-Reply-To: <200006282157.OAA05880@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:57:20PM -0700
References: <200006282157.OAA05880@slayer.i.sourceforge.net>
Message-ID: <20000628151758.X29590@lyra.org>

On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote:
> Update of /cvsroot/python/python/dist/src/Objects
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838
> 
> Modified Files:
> 	classobject.c object.c 
> Log Message:
> Trent Mick: change a few casts for Win64 compatibility.
> 
> 
> Index: classobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v
> retrieving revision 2.89
> retrieving revision 2.90
> diff -C2 -r2.89 -r2.90
> *** classobject.c	2000/06/23 19:37:01	2.89
> --- classobject.c	2000/06/28 21:57:18	2.90
> ***************
> *** 284,288 ****
>   	if (v == NULL || !PyString_Check(v))
>   		return "__name__ must be a string object";
> ! 	if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v))
>   		return "__name__ must not contain null bytes";
>   	set_slot(&c->cl_name, v);
> --- 284,288 ----
>   	if (v == NULL || !PyString_Check(v))
>   		return "__name__ must be a string object";
> ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
>   		return "__name__ must not contain null bytes";
>   	set_slot(&c->cl_name, v);

Actually, it would seem to make more sense to place the cast *inside* the
PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.

May as well start some ANSI-fication while we can...

Guido: any problem with my changing the macro?

Cheers,
-g

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



From gstein at lyra.org  Thu Jun 29 00:16:17 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 15:16:17 -0700
Subject: [Python-Dev] httplib doc (was: CVS: python/dist/src/Doc/lib libhttplib.tex,1.19,1.20)
In-Reply-To: <200006282151.OAA05489@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 02:51:46PM -0700
References: <200006282151.OAA05489@slayer.i.sourceforge.net>
Message-ID: <20000628151617.W29590@lyra.org>

Please mark me for a TODO to update the httplib doc. For example, the code
below is more effectively written as:

h = httplib.HTTPConnection('www.musi-cal.com')
h.request('POST', '/cgi-bin/query', paramstring, {'Accept': 'text/plain'})
response = h.getresponse()
print response.status   # should be 200
data = response.read()  # get the raw HTML

Note that 'Accept' is usually not a required header and can be omitted in
most scenarios. I left it in the example simply to show how to fully map
between the old/new APIs.

[ Content-Length and Host are sent automatically by HTTPConnection. ]

Cheers,
-g

On Wed, Jun 28, 2000 at 02:51:46PM -0700, Fred L. Drake wrote:
> Update of /cvsroot/python/python/dist/src/Doc/lib
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv5474/lib
> 
> Modified Files:
> 	libhttplib.tex 
> Log Message:
> 
> Skip Montanaro <skip at mojam.com>:
> Added an example of using an HTTP POST request.
> 
> 
> Index: libhttplib.tex
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Doc/lib/libhttplib.tex,v
> retrieving revision 1.19
> retrieving revision 1.20
> diff -C2 -r1.19 -r1.20
> *** libhttplib.tex	1999/04/22 16:47:27	1.19
> --- libhttplib.tex	2000/06/28 21:51:43	1.20
> ***************
> *** 115,119 ****
>   \nodename{HTTP Example}
>   
> ! Here is an example session:
>   
>   \begin{verbatim}
> --- 115,119 ----
>   \nodename{HTTP Example}
>   
> ! Here is an example session that uses the \samp{GET} method:
>   
>   \begin{verbatim}
> ***************
> *** 129,131 ****
> --- 129,148 ----
>   >>> data = f.read() # Get the raw HTML
>   >>> f.close()
> + \end{verbatim}
> + 
> + Here is an example session that shows how to \samp{POST} requests:
> + 
> + \begin{verbatim}
> + >>> import httplib, urllib
> + >>> params = urllib.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})
> + >>> h = httplib.HTTP("www.musi-cal.com:80")
> + >>> h.putrequest("POST", "/cgi-bin/query")
> + >>> h.putheader("Content-length", "%d" % len(params))
> + >>> h.putheader('Accept', 'text/plain')
> + >>> h.putheader('Host', 'www.musi-cal.com')
> + >>> h.endheaders()
> + >>> h.send(paramstring)
> + >>> reply, msg, hdrs = h.getreply()
> + >>> print errcode # should be 200
> + >>> data = h.getfile().read() # get the raw HTML
>   \end{verbatim}
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From mal at lemburg.com  Thu Jun 29 00:38:29 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 00:38:29 +0200
Subject: [Python-Dev] ucnhash module
References: <20000628205832.C3234E2673@oratrix.oratrix.nl>
Message-ID: <395A7E65.2271C723@lemburg.com>

Jack Jansen wrote:
> 
> I'm a bit worried about the ucnhash module and its huge size. I didn't
> follow the discussion closely at the time, because I thought I could
> always exclude it from the Pythons without dynamic linking, but now it
> seems that if i don't include it test_unicode doesn't run anymore.
> 
> Is this a problem with test_unicode, or should I consider ucnhash a
> mandatory module?

The ucnhash module is loaded on demand to avoid memory bloat.
In practice the difference is not really noticeable since 
loading a shared module or swapping in a few pages of static
C data result in pretty much the same overall memory usage.

If no-one complains, I'll fix the test suite though to make
the tests of the named Unicode characters optional.

Is this ok with you, Bill ?
 
> (BTW: there were also a couple of bugs in the module, include <> in
> stead of include "", and static in stead of staticforward
> declarations, I'll submit patches for those shortly).

I didn't have any problem compiling the module (don't even get
warnings when compiling with -Wall) ... but you're right:
these ought to get fixed.

BTW, since ucnhash.h|c are generated using the scripts
in Tools/perfecthash/ your patch should probably also fix the
instances of the problems found in there.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From tim_one at email.msn.com  Thu Jun 29 00:47:04 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 18:47:04 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <20000628150428.E17875@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>

[Greg Stein]
> Regardless: yes, it can certainly break some code. IMO, if any code out
> there makes any kinds of assumptions about id(), then they deserve to be
> broken :-)

[Trent Mick]
> Amen.

Guys, it's almost never that simple, and developers are the last ones to
think of the reasonable cases that may break.  In this case, e.g., code may
be doing something as harmless as printing an id() via a "... %d ..." format
in a log, and-- BOOM! --that blows up with an OverflowError if you feed it a
Python long larger than a C long.

I'd rather fix %d formats than leave id() broken, though!  id() has to
return a unique value.

but-i'll-sympathize-with-the-users-even-in-public<wink>-ly y'rs  - tim





From trentm at activestate.com  Thu Jun 29 01:49:55 2000
From: trentm at activestate.com (Trent Mick)
Date: Wed, 28 Jun 2000 16:49:55 -0700
Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
In-Reply-To: <20000628151758.X29590@lyra.org>
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org>
Message-ID: <20000628164955.B19053@activestate.com>

On Wed, Jun 28, 2000 at 03:17:58PM -0700, Greg Stein wrote:
> On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote:
> > Update of /cvsroot/python/python/dist/src/Objects
> > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838
> > 
> > Modified Files:
> > 	classobject.c object.c 
> > Log Message:
> > Trent Mick: change a few casts for Win64 compatibility.
> > 
> > 
> > Index: classobject.c
> > ===================================================================
> > RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v
> > retrieving revision 2.89
> > retrieving revision 2.90
> > diff -C2 -r2.89 -r2.90
> > *** classobject.c	2000/06/23 19:37:01	2.89
> > --- classobject.c	2000/06/28 21:57:18	2.90
> > ***************
> > *** 284,288 ****
> >   	if (v == NULL || !PyString_Check(v))
> >   		return "__name__ must be a string object";
> > ! 	if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v))
> >   		return "__name__ must not contain null bytes";
> >   	set_slot(&c->cl_name, v);
> > --- 284,288 ----
> >   	if (v == NULL || !PyString_Check(v))
> >   		return "__name__ must be a string object";
> > ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
> >   		return "__name__ must not contain null bytes";
> >   	set_slot(&c->cl_name, v);
> 
> Actually, it would seem to make more sense to place the cast *inside* the
> PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
> 
> May as well start some ANSI-fication while we can...
> 

I agree. Go to town, Greg. :)

Trent

-- 
Trent Mick
trentm at activestate.com



From gstein at lyra.org  Thu Jun 29 02:08:40 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:08:40 -0700
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 03:59:46PM -0500
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> <200006282059.PAA04852@cj20424-a.reston1.va.home.com>
Message-ID: <20000628170840.E29590@lyra.org>

On Wed, Jun 28, 2000 at 03:59:46PM -0500, Guido van Rossum wrote:
> > On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote:
> > > I'm a little disappointed that it will be so difficult for people to
> > > test with GC on, but I'm not going to claim that there is some easy way
> > > to make it a runtime option because I haven't looked at it at all. There
> > > probably isn't.
> > 
> > There isn't.  With an interpreter compiled --with-cycle-gc you can
> > turn off the collection with gc.set_threshold(0) but that's not
> > the same thing.
> > 
> >   Neil
> 
> I wonder if we should turn this option *on* during beta testing?
> 
> That way we gather a lot more experience with its use!  Maybe nobody
> complains and we can leave it on in the final release...

That presumes an adequate number of testers and a wide variety of
deployment/usage scenarios. Given the relatively short timeframe, that may
be a bit aggressive.

I *do* agree with enabling it during the beta. But I'm just not sure about
leaving it on.

Cheers,
-g

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



From tim_one at email.msn.com  Thu Jun 29 02:07:20 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 28 Jun 2000 20:07:20 -0400
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <20000628124606.K29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEBGGHAA.tim_one@email.msn.com>

[Greg Stein]
> ...
> I'd throw Tools into the same thing [as Demos]. As a separate distro,
> you can have a faster release cycle. ... you could release Idle
> updates easily and distinctly from the Python core.

Note that Guido gave his blessing for a "wide open" policy on IDLE (== its
own project in SourceForge, and anyone can be a developer).  If that's a
success (& I predict it will be, provided someone actually bothers to set up
the SF project!), I'd like to see it spread to Tools and Demos too.

ignoring-the-downsides-cuz-they'll-make-themselves-known-ly y'rs  - tim





From guido at beopen.com  Thu Jun 29 03:11:36 2000
From: guido at beopen.com (Guido van Rossum)
Date: Wed, 28 Jun 2000 20:11:36 -0500
Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
In-Reply-To: Your message of "Wed, 28 Jun 2000 15:17:58 MST."
             <20000628151758.X29590@lyra.org> 
References: <200006282157.OAA05880@slayer.i.sourceforge.net>  
            <20000628151758.X29590@lyra.org> 
Message-ID: <200006290111.UAA08357@cj20424-a.reston1.va.home.com>

> > ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
> 
> Actually, it would seem to make more sense to place the cast *inside* the
> PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
> 
> May as well start some ANSI-fication while we can...
> 
> Guido: any problem with my changing the macro?

Please leave the macro alone.  The type of the macro should be the
same as the type of the function -- PyString_Size() -- which is int.
If you change this, you potentially get tons of warnings because of
the signed / unsigned nature.

ANSI-fication is a good project for after 1.6.  But even then, it's a
separate decision whether the size of a string should be a size_t
instead of an int.  (The ob_size field should also change, if so --
with even more consequences.)

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



From gstein at lyra.org  Thu Jun 29 02:29:20 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:29:20 -0700
Subject: [Python-Dev] PyString_GET_SIZE()
In-Reply-To: <200006290111.UAA08357@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 08:11:36PM -0500
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com>
Message-ID: <20000628172919.G29590@lyra.org>

On Wed, Jun 28, 2000 at 08:11:36PM -0500, Guido van Rossum wrote:
> > > ! 	if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
> > 
> > Actually, it would seem to make more sense to place the cast *inside* the
> > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
> > 
> > May as well start some ANSI-fication while we can...
> > 
> > Guido: any problem with my changing the macro?
> 
> Please leave the macro alone.  The type of the macro should be the
> same as the type of the function -- PyString_Size() -- which is int.
> If you change this, you potentially get tons of warnings because of
> the signed / unsigned nature.
> 
> ANSI-fication is a good project for after 1.6.  But even then, it's a
> separate decision whether the size of a string should be a size_t
> instead of an int.  (The ob_size field should also change, if so --
> with even more consequences.)

Post 1.6, yes... I had figured on ob_size changing. Certainly not now :-)

But I understand the point about different return types. No problem.

[ of course, I would state that PyString_Size should also change and we fix
  those warnings... but I'll be patient :-) ]

How about removing Py_PROTO() usage, and changing function definitions from
K&R arg declaration to ANSI declarations? That kind of work is pretty
simple, straight-forward, and if somebody has free time to plod through the
work... so much the better. I believe that these changes would not introduce
any stability problems, and could be done independently from your busy
schedule.

Hmm. Is there a good place to start listing these todo items? One that we
can truly use for communicating this info? In Apache, we have a file named
STATUS that everybody uses for dropping ideas, patch references, critical
bugs, etc. As that file gets changed, we see it in the -checkins alias, so
everybody is aware of the suggested changes/problems/available patches/etc.
It also holds people's votes on particular changes.

Can we institute something similar? Possibly Misc/STATUS? Should I post
Apache's STATUS file as an example?

Cheers,
-g

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



From gstein at lyra.org  Thu Jun 29 02:34:24 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:34:24 -0700
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <395A32FD.D3C58B23@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:16:45AM -0700
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net>
Message-ID: <20000628173424.H29590@lyra.org>

I think you are being paranoid :-)

Consider that this same issue applies to all 5900 projects and 38000
developers at SourceForge. VA Linux has a brand identity entirely built on
the trust and support of the Linux (and Open Source) communities. If they
blow away that trust, they are simply screwed.

That said: it would still be a good thing to have export capabilities. I
recall that certain portions of the data (the Trove map?) can be exported in
XML format. I don't recall the magic URL for that, however.

Cheers,
-g

On Wed, Jun 28, 2000 at 10:16:45AM -0700, Paul Prescod wrote:
> I don't want to be paranoid, but are we putting any important
> information into SourceForge that we are not backing up elsewhere? I
> mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust
> suit...) would we have backups of our patches, bugs, wish lists and so
> forth? I hope that's a criteria in deciding what services to move to
> SourceForge. I am in the business of preserving investments in data and
> of telling customers to avoid software that does not keep them in
> complete control of their data. SF makes me nervous that way....
> 
> -- 
>  Paul Prescod - Not encumbered by corporate consensus
> The calculus and the rich body of mathematical analysis to which it 
> gave rise made modern science possible, but it was the algorithm that 
> made the modern world possible.
> 	- The Advent of the Algorithm (pending), by David Berlinski
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev

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



From gstein at lyra.org  Thu Jun 29 02:36:41 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 17:36:41 -0700
Subject: [Python-Dev] RTFM: SourceForge access for Win32
Message-ID: <20000628173641.I29590@lyra.org>

All right guys... all this banter about setting up CVS access for Win32
users has been quite silly. Did anybody even stop to look at the docs?

http://sfdocs.sourceforge.net/sfdocs/

In particular:

http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=19
http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=20
http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=46

There is also a new tool available (released today);

http://sfsetup.sourceforge.net/


Cheers,
-g

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



From gstein at lyra.org  Thu Jun 29 03:01:40 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 28 Jun 2000 18:01:40 -0700
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEBGGHAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 08:07:20PM -0400
References: <20000628124606.K29590@lyra.org> <LNBBLJKPBEHFEDALKOLCAEBGGHAA.tim_one@email.msn.com>
Message-ID: <20000628180140.M29590@lyra.org>

On Wed, Jun 28, 2000 at 08:07:20PM -0400, Tim Peters wrote:
> [Greg Stein]
> > ...
> > I'd throw Tools into the same thing [as Demos]. As a separate distro,
> > you can have a faster release cycle. ... you could release Idle
> > updates easily and distinctly from the Python core.
> 
> Note that Guido gave his blessing for a "wide open" policy on IDLE (== its
> own project in SourceForge, and anyone can be a developer).  If that's a
> success (& I predict it will be, provided someone actually bothers to set up
> the SF project!), I'd like to see it spread to Tools and Demos too.

Are you suggesting that IDLE be separate from a Tools/Demo package, or that
the whole bunch be shoved out into the wild?

Hmm... I guess that I don't much have an opinion one way or the other, but
was mostly looking for clarification.

Cheers,
-g

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



From jeremy at beopen.com  Thu Jun 29 04:08:51 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 28 Jun 2000 22:08:51 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
Message-ID: <14682.44979.673881.83798@bitdiddle.concentric.net>

Setup.in contains the following comment:

# (Note: the expat build process doesn't yet build a libexpat.a; you can
# do this manually while we try convince the author to add it.)

I've got expat, and I've built it, but I don't have any idea how to
build libexpat.a.  It may be possible to do it manually, but it would
help a lot if the comments could say how to build it or contain a link
to instructions on how to build it.

Jeremy



From gward at python.net  Thu Jun 29 04:37:08 2000
From: gward at python.net (Greg Ward)
Date: Wed, 28 Jun 2000 22:37:08 -0400
Subject: [Python-Dev] Just spotted on SourceForge main page
Message-ID: <20000628223707.A1168@beelzebub>

Maybe this is what all you Windows folks are looking for.

  SFSetup v1 released 
  mhearn - 06/28/00 11:00   -   SourceForge Setup for Win32 

  SFSetup is a program to automatically setup SSH and WinCVS for
  SourceForge projects under the Windows 32 platform. It's now available
  for download so if you have not yet set up SSH and WinCVS and want it
  done for you, you can use this program. Go to sfsetup.sourceforge.net
  to find out how to use it. It's open source and written in Delphi -
  the code is in CVS and any improvements are welcome! Thanks -mike
                
-- 
Greg Ward - Linux nerd                                  gward at python.net
http://starship.python.net/~gward/
I love ROCK 'N ROLL!  I memorized the all WORDS to "WIPE-OUT" in 1965!!



From fdrake at beopen.com  Thu Jun 29 05:26:55 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 28 Jun 2000 23:26:55 -0400 (EDT)
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <200006282310.SAA05850@cj20424-a.reston1.va.home.com>
References: <200006282112.OAA03095@slayer.i.sourceforge.net>
	<20000628144800.T29590@lyra.org>
	<200006282310.SAA05850@cj20424-a.reston1.va.home.com>
Message-ID: <14682.49663.208158.88794@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > That depends.  It is documented as an integer -- which may be vague
 > enough to encompass longs, but that's weasel-wording. ;-)

  The 1.6 documentation will make it clear that this may be a long
integer, but I don't think we need to promise on which platforms this
will be the case.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From paul at prescod.net  Thu Jun 29 06:21:41 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 28 Jun 2000 21:21:41 -0700
Subject: [Python-Dev] how do I build pyexpat?
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
Message-ID: <395ACED5.83764D45@prescod.net>

I don't know where you got your expat or how new it is, but with the one
I got from the xml-sig, I can type

"make libexpat.a"

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From tim_one at email.msn.com  Thu Jun 29 06:55:22 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 00:55:22 -0400
Subject: [Python-Dev] PyString_GET_SIZE()
In-Reply-To: <20000628172919.G29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEBPGHAA.tim_one@email.msn.com>

[Greg Stein]
> ...
> How about removing Py_PROTO() usage, and changing function
> definitions from K&R arg declaration to ANSI declarations? That
> kind of work is pretty simple, straight-forward, and if somebody
> has free time to plod through the work... so much the better.

I think it's too late in the cycle to suggest work for others to do and get
any payback from that.  Unless you're the one with the free time -- in which
case full speed ahead and God bless!  I previously volunteered to take the
Py_PROTO crap on, as I use an editor with a symbol database that gets
confused by that stuff, but I'm sure not going to start that this week.

> ...
> Hmm. Is there a good place to start listing these todo items?

Not that I know of.  "Group whiteboards" and shared journals etc are darned
useful, though.

> One that we can truly use for communicating this info? In Apache, we
> have a file named STATUS that everybody uses for dropping ideas, patch
> references, critical bugs, etc. As that file gets changed, we see it
> in the -checkins alias, so everybody is aware of the suggested
> changes/problems/available patches/etc.  It also holds people's votes
> on particular changes.
>
> Can we institute something similar? Possibly Misc/STATUS? Should I post
> Apache's STATUS file as an example?

Yes, sure, no:  just check one in!  If Guido hates it, we can remove it
later.  In the meantime, I bet we'll find great ways to use it.  In the
spirit of Unix, maybe it should be called Misc/gwtbd <wink>.

let-a-thousand-idiosyncracies-bloom-ly y'rs  - tim





From tim_one at email.msn.com  Thu Jun 29 06:55:24 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 00:55:24 -0400
Subject: [Python-Dev] RTFM: SourceForge access for Win32
In-Reply-To: <20000628173641.I29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEBPGHAA.tim_one@email.msn.com>

> All right guys... all this banter about setting up CVS access for Win32
> users has been quite silly.

It's been a valuable object lesson, Greg:  I showed everyone the value of
sitting on their ass until someone who knows what they're doing can't stand
it anymore <0.8 wink>.

> Did anybody even stop to look at the docs?

Didn't seem so to me.  I personally never found any docs, despite looking
for them.

> http://sfdocs.sourceforge.net/sfdocs/

Great!  Thank you.

> ...
> There is also a new tool available (released today);
>
> http://sfsetup.sourceforge.net/





From tim_one at email.msn.com  Thu Jun 29 07:08:27 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 01:08:27 -0400
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: <20000628180140.M29590@lyra.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCOECAGHAA.tim_one@email.msn.com>

[Greg Stein]
> Are you suggesting that IDLE be separate from a Tools/Demo
> package, or that the whole bunch be shoved out into the wild?

There's already an IDLE distribution distinct from Python's:

    http://www.python.org/idle/

Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not
clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack
of time).

> Hmm... I guess that I don't much have an opinion one way or the other, but
> was mostly looking for clarification.

I don't have a specific plan in mind either -- just "me too"ing on the idea
that it would do no harm and possibly do real good to let these peripheral
(to the core) things live on their own schedules.  I don't see any harm in
including "the latest" snapshot of them with the core distribution,
though -- it's handy for newcomers to get these things without needing to
search for them.  I know I learned a lot about Python at the start from
browsing these directories.





From skip at mojam.com  Thu Jun 29 07:27:02 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 00:27:02 -0500 (CDT)
Subject: [Python-Dev] Another Python-based company makes good...
Message-ID: <14682.56870.790737.261865@beluga.mojam.com>

Saw this on InfoBeat today:

    ** Yahoo to buy EGroups

    Yahoo said it would buy e-mail service provider EGroups
    (www.egroups.com) for $437.5 million in stock to enhance the
    Internet giant's communications services. Yahoo (YHOO) said it
    would issue 3.43 million shares of stock for all of EGroups
    shares, options, and warrants. The purchase will be accounted for
    as a pooling of interests and is expected to close in the third
    quarter. Yahoo said it would report a one-time charge during the
    third quarter for expenses to cover the takeover.

Looks like Scott Hassan can safely drop out of grad school now (if he hasn't
already)... ;-)

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From skip at mojam.com  Thu Jun 29 07:39:09 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 00:39:09 -0500 (CDT)
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <395A31B7.911D9BC2@prescod.net>
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>
	<395A31B7.911D9BC2@prescod.net>
Message-ID: <14682.57597.600123.167311@beluga.mojam.com>

    Paul> http://gisle.aas.no/perl/illguts/

The author of all those pretty diagrams is going to be really pissed when
they rename all the data structures in Perl 6... :-/

Skip



From tim_one at email.msn.com  Thu Jun 29 08:47:41 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 02:47:41 -0400
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
In-Reply-To: <200006281541.KAA02041@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKECGGHAA.tim_one@email.msn.com>

[Guido]
> OK, I've disabled the SF bugs manager.  There were two bugs submitted
> so far.  I've assigned one to you (about os.listdir on Windows) and
> one to MAL (about -U vs. exec/eval).  You two can take care of
> entering these into JB.  You can still access the bugs database via
> this URL:
>
> https://sourceforge.net/bugs/?group_id=5470

I moved "my" bug to Jitterbug, and moved Marc-Andre's too to save him the
bother.  Marked them "Closed" and "Duplicate" on SourceForge, so that if we
reenable bug management there someday they won't confuse us.





From moshez at math.huji.ac.il  Thu Jun 29 09:12:17 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Thu, 29 Jun 2000 10:12:17 +0300 (IDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <200006282213.PAA13365@slayer.i.sourceforge.net>
Message-ID: <Pine.GSO.4.10.10006290943150.15938-100000@sundial>

On Wed, 28 Jun 2000, Fred L. Drake wrote:

> + * Update the filecmp documentation (Moshe?).

I'm waiting for Gordon to check-in his directory comparisons to filecmp.
Gordon?
--
Moshe Zadka <moshez at math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com




From effbot at telia.com  Thu Jun 29 10:19:42 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 10:19:42 +0200
Subject: [Python-Dev] id() on Win64
References: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>
Message-ID: <00d501bfe1a2$c93f8cc0$f2a6b5d4@hagrid>

tim wrote:
> [Greg Stein]
> > Regardless: yes, it can certainly break some code. IMO, if any code out
> > there makes any kinds of assumptions about id(), then they deserve to be
> > broken :-)
> 
> [Trent Mick]
> > Amen.
> 
> Guys, it's almost never that simple, and developers are the last ones to
> think of the reasonable cases that may break.

especially since it's documented to be an integer:

    id (object) 
    Return the `identity' of an object. This is an integer which is
    guaranteed to be unique and constant for this object during
    its lifetime.

(section 2.1.4 says that "integer" is the same thing as a "plain
integer", and that "long integer" is something different).

</F>




From gstein at lyra.org  Thu Jun 29 11:15:08 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 02:15:08 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.4,2.5
In-Reply-To: <200006290857.BAA11219@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 01:57:57AM -0700
References: <200006290857.BAA11219@slayer.i.sourceforge.net>
Message-ID: <20000629021508.P29590@lyra.org>

Euh... can we get a bit more information in that checkin message. "towards
1.6b1" says zippo about what is changing or why.

Cheers,
-g

On Thu, Jun 29, 2000 at 01:57:57AM -0700, Fredrik Lundh wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv11206
> 
> Modified Files:
> 	_sre.c 
> Log Message:
> towards 1.6b1
> 
> Index: _sre.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/_sre.c,v
> retrieving revision 2.4
> retrieving revision 2.5
> diff -C2 -r2.4 -r2.5
> *** _sre.c	2000/06/01 17:34:20	2.4
> --- _sre.c	2000/06/29 08:57:54	2.5
> ***************
> *** 4,20 ****
>    * $Id$
>    *
> !  * simple regular expression matching engine
>    *
>    * partial history:
> !  * 99-10-24 fl	created (based on the template matcher)
>    * 99-11-13 fl	added categories, branching, and more (0.2)
>    * 99-11-16 fl	some tweaks to compile on non-Windows platforms
>    * 99-12-18 fl	non-literals, generic maximizing repeat (0.3)
> !  * 99-02-28 fl	tons of changes (not all to the better ;-) (0.4)
> [...1589 lines suppressed...]
>   
>   void
> ! #if defined(WIN32)
>   __declspec(dllexport)
>   #endif
> ***************
> *** 1708,1713 ****
>           Cursor_Type.ob_type = &PyType_Type;
>   
> ! 	Py_InitModule("_sre", _functions);
>   }
>   
> ! #endif
> --- 1846,1851 ----
>           Cursor_Type.ob_type = &PyType_Type;
>   
> ! 	Py_InitModule("_" MODULE, _functions);
>   }
>   
> ! #endif /* !defined(SRE_RECURSIVE) */
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From effbot at telia.com  Thu Jun 29 11:29:11 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 11:29:11 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.4,2.5
References: <200006290857.BAA11219@slayer.i.sourceforge.net> <20000629021508.P29590@lyra.org>
Message-ID: <005601bfe1ac$7e014460$f2a6b5d4@hagrid>

greg wrote:

> Euh... can we get a bit more information in that checkin message. "towards
> 1.6b1" says zippo about what is changing or why.

just bringing the repository in sync with the current development
snapshot -- I promise to provide more info when the checkins are
more focused...

just gotta reach "1.6b1 quality" first...

</F>




From bckfnn at worldonline.dk  Thu Jun 29 11:42:03 2000
From: bckfnn at worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 09:42:03 GMT
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCKEBBGHAA.tim_one@email.msn.com>
Message-ID: <395b1528.5978476@smtp.worldonline.dk>

[Tim Peters]

>id() has to return a unique value.

This property of id() does not hold in JPython. When used with hotspot,
id() is not unique.

regards,
finn



From Vladimir.Marangozov at inrialpes.fr  Thu Jun 29 12:05:12 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Thu, 29 Jun 2000 12:05:12 +0200 (CEST)
Subject: [Python-Dev] id() on Win64
In-Reply-To: <395b1528.5978476@smtp.worldonline.dk> from "Finn Bock" at Jun 29, 2000 09:42:03 AM
Message-ID: <200006291005.MAA20940@python.inrialpes.fr>

Finn Bock wrote:
> 
> [Tim Peters]
> 
> >id() has to return a unique value.
> 
> This property of id() does not hold in JPython. When used with hotspot,
> id() is not unique.

Is it?
Not unique or not persistent during the object's lifetime?

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From effbot at telia.com  Thu Jun 29 12:07:42 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 12:07:42 +0200
Subject: [Python-Dev] build problems under MSVC 5.0
Message-ID: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid>

Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier
Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv'
Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier
Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type'
Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier

in MSVC 5.0, _beginthread returns an "unsigned long" (this is also
how it's documented in MSDN).

I suggest changing the declaration in thread_nt.h to:

#if _MSC_VER >= 1200
 INT_PTR rv;
#else
 unsigned long rv;
#endif

on the other hand, the same docs claim that it returns -1 on errors.
doesn't exactly look like an unsigned long to me, but that's another
story...

</F>




From effbot at telia.com  Thu Jun 29 12:21:22 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 12:21:22 +0200
Subject: [Python-Dev] arraymodule still broken?
Message-ID: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid>

just checked everything out and rebuilt, the exceptions
problem sure disappeared, but I still get this error:

>>> import array
>>> array.array("H", [60000])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: signed short integer is greater than maximum

second opinion, anyone?

</F>




From bckfnn at worldonline.dk  Thu Jun 29 12:43:55 2000
From: bckfnn at worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 10:43:55 GMT
Subject: [Python-Dev] id() on Win64
In-Reply-To: <200006291005.MAA20940@python.inrialpes.fr>
References: <200006291005.MAA20940@python.inrialpes.fr>
Message-ID: <395b26e6.10520397@smtp.worldonline.dk>

[Finn Bock]

> This property of id() does not hold in JPython. When used with hotspot,
> id() is not unique.

[Vladimir Marangozov}

>Is it?
>Not unique or not persistent during the object's lifetime?

Not unique. Two different objects can return the same value from
System.identityHashCode().

The HTML java docs have this to say about hashCodes:

"""
  As much as is reasonably practical, the hashCode method defined by class
  Object does return distinct integers for distinct objects. (This is
  typically implemented by converting the internal address of the object
  into an integer, but this implementation technique is not required by the
  JavaTM programming language.)
"""

Its just one of those small difference that we have to live with. In
pratical term I have seen it cause problems in pickle.py and
copy.deepcopy()

regards,
finn



From gmcm at hypernet.com  Thu Jun 29 14:22:12 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 29 Jun 2000 08:22:12 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <Pine.GSO.4.10.10006290943150.15938-100000@sundial>
References: <200006282213.PAA13365@slayer.i.sourceforge.net>
Message-ID: <1249841091-43777448@hypernet.com>

Moshe wrote:

> On Wed, 28 Jun 2000, Fred L. Drake wrote:
> 
> > + * Update the filecmp documentation (Moshe?).
> 
> I'm waiting for Gordon to check-in his directory comparisons to
> filecmp. Gordon? 

Looking at CVS, my stuff was there in filecmp revision 1.2 
(+299 -38) and wiped out by 1.3 (+38 -299) which was done 
the following day.

- Gordon



From akuchlin at cnri.reston.va.us  Thu Jun 29 14:25:19 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Thu, 29 Jun 2000 08:25:19 -0400
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <395ACED5.83764D45@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 09:21:41PM -0700
References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net>
Message-ID: <20000629082519.A13839@newcnri.cnri.reston.va.us>

On Wed, Jun 28, 2000 at 09:21:41PM -0700, Paul Prescod wrote:
>I don't know where you got your expat or how new it is, but with the one
>I got from the xml-sig, I can type
>"make libexpat.a"

That's a patch I made to the Makefile and submitted to James Clark.
For Modules/Setup.in, I can change it to explicitly list the 8 files
from Expat that need to be linked to.  The problem is that one of the
files will vary:

# Use one of the next two lines; unixfilemap is better if it works.
FILEMAP_OBJ=xmlwf/unixfilemap.o
#FILEMAP_OBJ=xmlwf/readfilemap.o

--amk



From gward at mems-exchange.org  Thu Jun 29 14:26:47 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 08:26:47 -0400
Subject: [Python-Dev] OT: A Day in the Life of p5p
In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200
References: <LNBBLJKPBEHFEDALKOLCGEADGHAA.tim_one@email.msn.com> <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>
Message-ID: <20000629082647.A27322@ludwig.cnri.reston.va.us>

On 28 June 2000, Fredrik Lundh said:
> it would be very nice if the file object could do something similar
> internally (only in text mode, perhaps).  maybe in 1.7?

Oddly enough, I've been idly contemplating writing an extension type
(hypothetically called "superfile") that makes most of Perl's
file-handling semantics, and maybe some of the speedup, available in
Python.  At one level, it would be a rewrite of my 'text_file'
module/TextFile class in C.

But this is all speculation, mainly predicated on the theory that I
*really* should be eating my own dogfood and distributing some Python
extension, instead of just telling other people how to do it.  ;-)

        Greg



From gward at mems-exchange.org  Thu Jun 29 14:33:39 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 08:33:39 -0400
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <14682.15020.589514.702145@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Jun 28, 2000 at 01:49:32PM -0400
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net>
Message-ID: <20000629083339.B27322@ludwig.cnri.reston.va.us>

On 28 June 2000, Jeremy Hylton said:
>   PP> import cyclicgc
> 
>   PP> should turn on the -with-cycle-gc flag.
> 
> The -with-cycle-gc flag is an option to configure when you build
> Python.  It can't be turned on or off at runtime.

No, no, *obviously* Paul meant that "import cyclicgc" should configure
and compile a new Python interpreter with "--with-cycle-gc" and 'exec()'
it for you.  What else would it mean?

;-)

        Greg

(PS. if this were Perl, you could say

   use cyclegc;

to turn it on, and then elsewhere in your code

   no cyclegc;

to turn it off.  Maybe Python needs an "unimport" command?)

(Kidding!)



From gward at mems-exchange.org  Thu Jun 29 14:39:08 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 08:39:08 -0400
Subject: [Python-Dev] ucnhash module
In-Reply-To: <395A7E65.2271C723@lemburg.com>; from mal@lemburg.com on Thu, Jun 29, 2000 at 12:38:29AM +0200
References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com>
Message-ID: <20000629083908.D27322@ludwig.cnri.reston.va.us>

On 29 June 2000, M.-A. Lemburg said:
> The ucnhash module is loaded on demand to avoid memory bloat.
> In practice the difference is not really noticeable since 
> loading a shared module or swapping in a few pages of static
> C data result in pretty much the same overall memory usage.
> 
> If no-one complains, I'll fix the test suite though to make
> the tests of the named Unicode characters optional.

How 'bout a separate "test_ucn" to test this feature?

...of course, this is yet another case of language syntax features
becoming optional and selectable at compile-time, which I still think is
a bad idea.  Hmmm.

        Greg



From guido at beopen.com  Thu Jun 29 15:39:59 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 08:39:59 -0500
Subject: [Python-Dev] add Demo/imputil/importers.py ?
In-Reply-To: Your message of "Thu, 29 Jun 2000 01:08:27 -0400."
             <LNBBLJKPBEHFEDALKOLCOECAGHAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCOECAGHAA.tim_one@email.msn.com> 
Message-ID: <200006291339.IAA09887@cj20424-a.reston1.va.home.com>

> There's already an IDLE distribution distinct from Python's:
> 
>     http://www.python.org/idle/
> 
> Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not
> clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack
> of time).

Yes.

> > Hmm... I guess that I don't much have an opinion one way or the other, but
> > was mostly looking for clarification.
> 
> I don't have a specific plan in mind either -- just "me too"ing on the idea
> that it would do no harm and possibly do real good to let these peripheral
> (to the core) things live on their own schedules.  I don't see any harm in
> including "the latest" snapshot of them with the core distribution,
> though -- it's handy for newcomers to get these things without needing to
> search for them.  I know I learned a lot about Python at the start from
> browsing these directories.

Additionally, it's great for Python on Windows to come with a working
GUI.  Pythonwin may be more like Windows, but it's much more fragile
than (recent versions of) IDLE in my experience.

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



From guido at beopen.com  Thu Jun 29 15:49:32 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 08:49:32 -0500
Subject: [Python-Dev] PyString_GET_SIZE()
In-Reply-To: Your message of "Wed, 28 Jun 2000 17:29:20 MST."
             <20000628172919.G29590@lyra.org> 
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com>  
            <20000628172919.G29590@lyra.org> 
Message-ID: <200006291349.IAA09962@cj20424-a.reston1.va.home.com>

> Hmm. Is there a good place to start listing these todo items? One that we
> can truly use for communicating this info? In Apache, we have a file named
> STATUS that everybody uses for dropping ideas, patch references, critical
> bugs, etc. As that file gets changed, we see it in the -checkins alias, so
> everybody is aware of the suggested changes/problems/available patches/etc.
> It also holds people's votes on particular changes.
> 
> Can we institute something similar? Possibly Misc/STATUS? Should I post
> Apache's STATUS file as an example?

Possibly, but I'm somewhat skeptical.  I used to have a large TODO
file -- still have it -- but it's so full of long-term ideas that
never happened that I rarely look in it any more.  I never got into
the discipline of using it for my day-to-day priorities -- it was more
of a place to write down long-term ideas so I could forget about
them.  I'll append it.  I appreciate a copy of Apache's STATUS file.

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

NEW TODO LIST FOR 1.6
=====================

IDLE: set window class?
socket/ssl version mystery

UNIFIED TODO LIST
=================


From effbot at telia.com  Thu Jun 29 14:58:13 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 14:58:13 +0200
Subject: [Python-Dev] PyString_GET_SIZE()
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com>             <20000628172919.G29590@lyra.org>  <200006291349.IAA09962@cj20424-a.reston1.va.home.com>
Message-ID: <006201bfe1c9$b928d400$f2a6b5d4@hagrid>

guido wrote:

> > Hmm. Is there a good place to start listing these todo items? One that we
> > can truly use for communicating this info? In Apache, we have a file named
> > STATUS that everybody uses for dropping ideas, patch references, critical
> > bugs, etc. As that file gets changed, we see it in the -checkins alias, so
> > everybody is aware of the suggested changes/problems/available patches/etc.
> > It also holds people's votes on particular changes.
> > 
> > Can we institute something similar? Possibly Misc/STATUS? Should I post
> > Apache's STATUS file as an example?
> 
> Possibly, but I'm somewhat skeptical.  I used to have a large TODO
> file -- still have it -- but it's so full of long-term ideas that
> never happened that I rarely look in it any more.

instead of a file, I suggest taking a look at ?!ng's Roundup
(once 1.6 final is out, of course).

</F>




From guido at beopen.com  Thu Jun 29 15:58:00 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 08:58:00 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: Your message of "Thu, 29 Jun 2000 08:22:12 -0400."
             <1249841091-43777448@hypernet.com> 
References: <200006282213.PAA13365@slayer.i.sourceforge.net>  
            <1249841091-43777448@hypernet.com> 
Message-ID: <200006291358.IAA10045@cj20424-a.reston1.va.home.com>

> Moshe wrote:
> 
> > On Wed, 28 Jun 2000, Fred L. Drake wrote:
> > 
> > > + * Update the filecmp documentation (Moshe?).
> > 
> > I'm waiting for Gordon to check-in his directory comparisons to
> > filecmp. Gordon? 
> 
> Looking at CVS, my stuff was there in filecmp revision 1.2 
> (+299 -38) and wiped out by 1.3 (+38 -299) which was done 
> the following day.

Argh!  An inappropriate side effect of Ping's cleanup -- thanks for
catching this.  Apparently Ping didn't do a CVS update before
generating his diffs.

I can restore version 1.2 easily, but I'm not sure what to do with
/F's changes (1.3 -> 1.4).  Gordon, can you look at this and suggest
what to do?

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



From mal at lemburg.com  Thu Jun 29 15:04:24 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 15:04:24 +0200
Subject: [Python-Dev] ucnhash module
References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com> <20000629083908.D27322@ludwig.cnri.reston.va.us>
Message-ID: <395B4958.C9909145@lemburg.com>

Greg Ward wrote:
> 
> On 29 June 2000, M.-A. Lemburg said:
> > The ucnhash module is loaded on demand to avoid memory bloat.
> > In practice the difference is not really noticeable since
> > loading a shared module or swapping in a few pages of static
> > C data result in pretty much the same overall memory usage.
> >
> > If no-one complains, I'll fix the test suite though to make
> > the tests of the named Unicode characters optional.
> 
> How 'bout a separate "test_ucn" to test this feature?

Good idea.
 
> ...of course, this is yet another case of language syntax features
> becoming optional and selectable at compile-time, which I still think is
> a bad idea.  Hmmm.

It's not selectable at run-time: either you have compiled the
module or not. It is enabled per default.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From Vladimir.Marangozov at inrialpes.fr  Thu Jun 29 15:31:21 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Thu, 29 Jun 2000 15:31:21 +0200 (CEST)
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 28, 2000 03:59:46 PM
Message-ID: <200006291331.PAA21571@python.inrialpes.fr>

Guido van Rossum wrote:
> 
> I wonder if we should turn this option *on* during beta testing?

Why not, as long as --without-gc does not suffer from bugs hidden by
--with-gc.

> 
> That way we gather a lot more experience with its use!  Maybe nobody
> complains and we can leave it on in the final release...

This is risky. We don't have enough experience with this implementation.
All we know is that things get slower and consume more memory. Without
a clear picture of the impact of this GC implementation, it's probably
a bad idea to enable (i.e. impose) it by default.  

The "optional experimental feature" label is good and IMO it complies
with anybody's expectations. Interested people will jump in and will
eventually contribute with improvements, those who don't care won't
and will live happily without it (at least until the day the feature
and its implementation reach their expected maturity).

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From gmcm at hypernet.com  Thu Jun 29 15:27:01 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 29 Jun 2000 09:27:01 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com>
References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400."             <1249841091-43777448@hypernet.com> 
Message-ID: <1249837203-44011365@hypernet.com>

[Gordon] 
> > Looking at CVS, my stuff was there in filecmp revision 1.2
> > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the
> > following day.
[Guido]
> Argh!  An inappropriate side effect of Ping's cleanup -- thanks
> for catching this.  Apparently Ping didn't do a CVS update before
> generating his diffs.
> 
> I can restore version 1.2 easily, but I'm not sure what to do
> with /F's changes (1.3 -> 1.4).  Gordon, can you look at this and
> suggest what to do?

If you have the eff-bot's diff, it should apply to 1.2 (my changes 
are all below there - basically I added a rewritten dircmp). I 
think a CVS merge would do the right thing, too.

- Gordon



From mal at lemburg.com  Thu Jun 29 15:33:36 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 15:33:36 +0200
Subject: [Python-Dev] CVS locks on SF
Message-ID: <395B5030.C0F08E82@lemburg.com>

I'm getting loads of lock messages during CVS checkins recently.
Is this due to overload ? (I wonder why anoncvs access causes
locking at all -- there is no write access so why should there
be file locking ?):

[06:31:40] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test
cvs server: [06:32:10] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test
cvs server: [06:32:41] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test
cvs server: [06:33:11] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Thu Jun 29 15:52:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 09:52:40 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <20000629082519.A13839@newcnri.cnri.reston.va.us>
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
	<395ACED5.83764D45@prescod.net>
	<20000629082519.A13839@newcnri.cnri.reston.va.us>
Message-ID: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com>

Andrew Kuchling writes:
 > That's a patch I made to the Makefile and submitted to James Clark.
 > For Modules/Setup.in, I can change it to explicitly list the 8 files
 > from Expat that need to be linked to.  The problem is that one of the

  It's not in the stable version I picked up last night; I'll dig up
the experimental version today.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From paul at prescod.net  Thu Jun 29 15:52:21 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 29 Jun 2000 06:52:21 -0700
Subject: [Python-Dev] Text about cycle GC
References: <200006291331.PAA21571@python.inrialpes.fr>
Message-ID: <395B5495.CF274583@prescod.net>

Vladimir Marangozov wrote:
> 
>...
>
> This is risky. We don't have enough experience with this implementation.
> All we know is that things get slower and consume more memory. Without
> a clear picture of the impact of this GC implementation, it's probably
> a bad idea to enable (i.e. impose) it by default.

Won't we have a clear picture by the end of the beta period?

> The "optional experimental feature" label is good and IMO it complies
> with anybody's expectations. Interested people will jump in and will
> eventually contribute with improvements, those who don't care won't
> and will live happily without it (at least until the day the feature
> and its implementation reach their expected maturity).

A million Window users will live unhappily without it because they don't
know how to recompile to get it!

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski



From billtut at microsoft.com  Thu Jun 29 15:54:21 2000
From: billtut at microsoft.com (Bill Tutt)
Date: Thu, 29 Jun 2000 06:54:21 -0700
Subject: [Python-Dev] re: ucnhash
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50>

Re: ucnhash and where the stuff gets tested

Doesn't matter to me where the test goes.

WRT how big it is, thats why its dynamically loaded at run time.
If you don't compile it at all, then the \N{...} syntax just won't owrk.

Re: static vs. staticforward
I can actually do a patch for that, and regen ucnhash.c for you.

Re: "" vs. <>
Whats wrong with what I'm currently doing?

All of the .h files I'm including are on the include file path. "" usage
just means stick "." before everything else in your include path.
None of the files need that. :) If there's a diffferent policy in the Python
source 'bout that that I'm not aware of, then I can fix that issue too.

Bill



From guido at beopen.com  Thu Jun 29 17:03:36 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 10:03:36 -0500
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: Your message of "Thu, 29 Jun 2000 15:33:36 +0200."
             <395B5030.C0F08E82@lemburg.com> 
References: <395B5030.C0F08E82@lemburg.com> 
Message-ID: <200006291503.KAA10324@cj20424-a.reston1.va.home.com>

> I'm getting loads of lock messages during CVS checkins recently.
> Is this due to overload ? (I wonder why anoncvs access causes
> locking at all -- there is no write access so why should there
> be file locking ?):

I haven't seen this myself.  Could be you were just unlucky.  Could be
someone was doing a full checkout over a slow connection.

I think the anon checkouts still use (read) locks because they need to
get a consistent version.

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



From gstein at lyra.org  Thu Jun 29 16:10:51 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 07:10:51 -0700
Subject: [Python-Dev] STATUS files (was: PyString_GET_SIZE())
In-Reply-To: <200006291349.IAA09962@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 08:49:32AM -0500
References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> <200006291349.IAA09962@cj20424-a.reston1.va.home.com>
Message-ID: <20000629071051.T29590@lyra.org>

On Thu, Jun 29, 2000 at 08:49:32AM -0500, Guido van Rossum wrote:
> > Hmm. Is there a good place to start listing these todo items? One that we
> > can truly use for communicating this info? In Apache, we have a file named
> > STATUS that everybody uses for dropping ideas, patch references, critical
> > bugs, etc. As that file gets changed, we see it in the -checkins alias, so
> > everybody is aware of the suggested changes/problems/available patches/etc.
> > It also holds people's votes on particular changes.
> > 
> > Can we institute something similar? Possibly Misc/STATUS? Should I post
> > Apache's STATUS file as an example?
> 
> Possibly, but I'm somewhat skeptical.  I used to have a large TODO
> file -- still have it -- but it's so full of long-term ideas that
> never happened that I rarely look in it any more.  I never got into
> the discipline of using it for my day-to-day priorities -- it was more
> of a place to write down long-term ideas so I could forget about
> them.  I'll append it.  I appreciate a copy of Apache's STATUS file.

Attached below...

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

Apache 2.0 STATUS:
Last modified at [$Date: 2000/06/28 11:41:14 $]

Release:

    2.0a5   : ???
    2.0a4   : released June 7, 2000
    2.0a3   : released April 28, 2000
    2.0a2   : released March 31, 2000
    2.0a1   : released March 10, 2000

RELEASE SHOWSTOPPERS:
    * Win32: Get mod_auth_digest working under win32
      - APR_HAS_RANDOM should be defined on windows and there is a 
      lib/apr/misc/win32/rand.c which is basically a copy of what
      mod_auth_digest used to use.

    * Re-work configuration for top level Apache.  Work should start with
      trying to clean the autoconf stuff.  If and only if this proves
      impossible to do (very unlikely), autoconf should be removed and we
      will roll our own config implementation.

    * suEXEC doesn't work
        Status: Manoj has posted an patch to fix this.
        <19991103003605.A20612 at samosa.mindspring.com>

    * Win32: Enable the Windows MPM to honor max_requests_per_child
        Status: Bill will fix this.

    * Win32: Get Apache working on Windows 95/98. The following work
	(at least) needs to be done:
	- winnt MPM: Fix 95/98 code paths in the winnt MPM. There is some NT
	specific code that is still not in NT only code paths
	- IOL binds to APR sendfile, implemented with TransmitFile, which 
        is not available on 95/98.

    * Win32: Test access logging with multiple threads. Will the 
	native file I/O calls serialize automagically like the 
	CRT calls or do we need to add region locking each time 
	we access the logs?
	Status: 

    * Win32: Complete the revamp the service environment and relocation
        into the WinNT MPM.  Changes ServerRoot service registry 
        parameter into ConfigArgs for multiple service startup parameters.
        Problems to fix in the revamp: -k shutdown/restart are broken, 
        signals are not being acknowledged.  Close window and shutdown 
        also seem out of sorts.
        OtherBill is working on this

    * Win32: fix build/run time environment to remove ApacheCore.dll 
        linkage from ab.exe and htdigest.exe.
    
    * We need a thread-safe resolver, at least on Unix.
        Status: The best known candidate would be something from
	BIND v9.
        Status: Greg asks, "why? doesn't gethostbyname_r() handle this?"

    * Modify mod_cgi and mod_cgid to deal with directories.  This allows
      a lot of directives to be removed from the core.

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
    * OS/2: Get loadable modules working again. Requires shared core support
      which doesn't appear to be catered for in the current build system.

    * OS/2: Make mod_status work for spmt_os2 MPM.

    * Build scripts do not recognise AIX 4.2.1 pthreads, so the
      pthread MPMs will not build.

    * Win32: Reuse accept socket after transmitfile/close
	This is not a bug, but would be nice to get this feature in 
	before ship.

    * Win32: Enable the winnt MPM to use the new scoreboard API

    * Win32: Implement ap_shm_ functions in APR.

    * Win32: Win9x console window still won't play nice with the
        close window, logoff and shutdown scenarios.

    * Win32: Add a simple hold console open patch (wait for close or
        the ESC key, with a nice message) if the server died a bad 
        death (non-zero exit code) in console mode.

    * Platforms that do not support fork (primarily Win32 and AS/400)
      Consider introducing HAVE_FORK feature macro. Architect start-up code
      that avoids initializing all the modules in the parent process on
      platforms that do not support fork.

    * Clean the code.  There are a lot of places we used APR but didn't 
      remove the hacks that were required for the cross-platform code in
      1.3.  We need to make the code look like APR was supposed to be there. 

    * Go throught the 1.3 Bug DB and research the bugs marked "suspended".
      People were told these would be considered for inclusion in Apache 2.0,
      it would be nice to actually do so.

    * Win32: Migrate the MPM over to use APR thread/process calls. This
      would eliminate some code in the Win32 branch that essentially
      duplicates what is in APR.

      Bill says we need a new procattr, APR_CREATE_SUSPENDED (or
      something similar) to direct ap_create_process to create the
      process suspended. We also need a call to wake up the suspended 
      process This may not be able to be implemented everywhere though.

        Status: 

    * Move I/O layering into APR.

    * There are still a number of places in the code where we are
      loosing error status (i.e. throwing away the error returned by a
      system call and replacing it with a generic error code)

    * Win32: Implement reliable piped logs on Windows
        Status: 
          
    * Use APR to get rid of more platform dependancies.
        Status: Ryan Bloom <rbb at covalenet.net> is working on this.

    * The connection status table is not very efficient. Also, very few stats
      are exported to the connection status table (easy to fix), and mod_status
      is ugly.

    * Mass vhosting version of suEXEC.

    * Replace tables with a proper opaque ADT that has pluggable
      implementations (including something like the existing data type,
      plus hash tables for speed, with options for more later).
	Status: fanf is working on this.

    * configuration option to use *DBM
      Status: Greg +1 (volunteers)

    * add SDBM into src/lib/sdbm/ as a default/fallback DBM implementation.
      SDBM is used by Perl, mod_dav, mod_sssl, others for basic DBM support.
      Status: Greg +1 (volunteers)

    * Integrate mod_dav.
        Message-id: <20000625173247.M29590 at lyra.org>
        Status: in process.
        - APR does not provide a couple needed things: chmod()
          and ap_finfo_t.st_dev.
	- expat-lite needs to be brought up to parity with the 1.3
	  vsn and inserted into the config/build process
	- SDBM needs to go into the config/build process
	- fix up include dirs to pick up expat-lite, sdbm, dav/main
	- APR-ization to the dav/fs/ stuff
	- case_preserved_filename stuff

    * ap_core_translate() and its use by mod_mmap_static are a bit wonky.
      The function should probably be exposed as a utility function (such
      as ap_translate_url2fs() or ap_validate_fs_url() or something).
      Another approach would be a new hook phase after "translate" which
      would allow mod_mmap_static to munge what the translation has
      decided to do.
        Status: Greg +1 (volunteers), Ryan +1

    * Go through ap_config.h and namespace-protect the symbols (e.g. USE_*).
      Some symbols can/should move to mpm_common.h where possible.

    * Explore use of a post-config hook for the code in http_main.c which
      calls ap_fixup_virutal_hosts(), ap_fini_vhost_config(), and
      ap_sort_hooks()  [to reduce the logic in main()]

    * read the config tree just once, and process N times (as necessary)

    * add a version number to ap_initialize() as an extra failsafe against
      (APR) library version skew.
      MsgID: <Pine.LNX.4.10.10005231712380.31927-100000 at nebula.lyra.org>
      Status: Greg +1 (volunteers), Jeff +1, Ryan +1, Tony -0(?)

    * mod_info to use the configuration tree

    * add output filtering. there are a couple variants for this.
      - The "link-based" variant is ready to go:
        MsgID: <20000627044436.N29590 at lyra.org>   (patch)
	MsgID: <20000627053302.O29590 at lyra.org>   (demo usage)
	MsgID: <Pine.LNX.4.21.0006270731240.4006-100000 at koj.rkbloom.net>
                             (problems with the patch)
        Status: Greg +1, Ryan -1
        

Other bugs that need fixing:

    * MaxRequestsPerChild measures connections, not requests.
        Until someone has a better way, we'll probably just rename it
        "MaxConnectionsPerChild".
    
    * Regex containers don't work in an intutive way
        Status: No one has come up with an efficient way to fix this
        behavior. Dean has suggested getting rid of regex containers
        completely.

    * SIGSEGV on Linux (glibc 2.1.2) isn't caught properly by a
      sigwaiting thread. We need to work around this, perhaps unless
      there is hope soon for a fixed glibc.

    * The mod_cgid daemon process isn't always cleaned up when httpd
      gets SIGTERM.  Jeff thinks it may be as simple as registering
      the daemon process for cleanup with the proper pool, but he hasn't
      looked at it in enough detail.

    * The MM library is built as static and shared library. This should
      be set up to build only the required version.

Other features that need writing:

    * Finish infrastructure in core for async MPMs
        Status: post 2.0

    * TODO in source -- just do an egrep on "TODO" and see what's there

Documentation that needs writing:
    * Mod_status docs are needed.

    * The concept of MPMs, especially if we ship more than one MPM for a
      given platform

    * New directives in the various MPMs and appropriate links from
	obsolete directives in core.html to the MPM documentation.

    * Revise manual/stopping.html and the last part of
	manual/misc/perf-tuning.html to take account of the MPMs.

    * API documentation
        Status: Ben Laurie has written some hooks documentation
        (apache-2.0/htdocs/hooks.html)

    * Changes since 1.3.9 can be more easily seen in the commitlog file
         dev.apache.org:/home/cvs/CVSROOT/commitlogs/apache-2.0
      which includes some of Roy's comments when the changes were
      committed in rough change-sets by purpose.  Note that the commitlog
      does not show the contents of new files until later.

    * mod_dav documentation (once integrated)

Available Patches:

   * Mike Abbott's <mja at trudge.engr.sgi.com> patches to improve
     performance
       Status: These were written for 1.3, and are awaiting a port to
       2.0
 
   * Jim Winstead's <jimw at trainedmonkey.com> patch to add CookieDomain and 
     other small mod_usertrack features

Open issues:

   * What do we do about mod_proxy?

   * Which MPMs will be included with Apache 2.0?

   * Is conf/highperformance.conf-dist obsolete?  It looks obsolete.




From fredrik at pythonware.com  Thu Jun 29 16:11:26 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 16:11:26 +0200
Subject: [Python-Dev] Text about cycle GC
References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net>             <20000628122725.A13473@acs.ucalgary.ca>  <200006282059.PAA04852@cj20424-a.reston1.va.home.com>
Message-ID: <016a01bfe1d3$ea2474b0$0900a8c0@SPIFF>

guido wrote:
> I wonder if we should turn this option *on* during beta testing?

+1 from me.

> That way we gather a lot more experience with its use!  Maybe nobody
> complains and we can leave it on in the final release...

I won't mind (unless it breaks my code, of course).

</F>




From mal at lemburg.com  Thu Jun 29 16:10:28 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 16:10:28 +0200
Subject: [Python-Dev] re: ucnhash
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50>
Message-ID: <395B58D4.E52CBBD6@lemburg.com>

Bill Tutt wrote:
> 
> Re: ucnhash and where the stuff gets tested
> 
> Doesn't matter to me where the test goes.

I'm currently trying to check these changes in... doesn't work
though due to some obscure CVS locks.
 
> WRT how big it is, thats why its dynamically loaded at run time.
> If you don't compile it at all, then the \N{...} syntax just won't owrk.
> 
> Re: static vs. staticforward
> I can actually do a patch for that, and regen ucnhash.c for you.

Someone (Fred ?) already patches those places for you. He didn't
send patches for the perfect hash tool though.
 
> Re: "" vs. <>
> Whats wrong with what I'm currently doing?

<> uses a differnt header file lookup path... normally doesn't
hurt, but...
 
> All of the .h files I'm including are on the include file path. "" usage
> just means stick "." before everything else in your include path.
> None of the files need that. :) If there's a diffferent policy in the Python
> source 'bout that that I'm not aware of, then I can fix that issue too.

... you already know that ;-)

Again, these are already fixed :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at beopen.com  Thu Jun 29 17:15:09 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 10:15:09 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: Your message of "Thu, 29 Jun 2000 09:27:01 -0400."
             <1249837203-44011365@hypernet.com> 
References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com>  
            <1249837203-44011365@hypernet.com> 
Message-ID: <200006291515.KAA10374@cj20424-a.reston1.va.home.com>

> [Gordon] 
> > > Looking at CVS, my stuff was there in filecmp revision 1.2
> > > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the
> > > following day.
> [Guido]
> > Argh!  An inappropriate side effect of Ping's cleanup -- thanks
> > for catching this.  Apparently Ping didn't do a CVS update before
> > generating his diffs.
> > 
> > I can restore version 1.2 easily, but I'm not sure what to do
> > with /F's changes (1.3 -> 1.4).  Gordon, can you look at this and
> > suggest what to do?

[Gordon]
> If you have the eff-bot's diff, it should apply to 1.2 (my changes 
> are all below there - basically I added a rewritten dircmp). I 
> think a CVS merge would do the right thing, too.

There was a change in indent style, so effbot's diff didn't apply
cleanly -- but your suggestion made me realize that it was easy to
re-apply manually.

It's all fixed now.  Thanks all!

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



From mal at lemburg.com  Thu Jun 29 16:15:23 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 29 Jun 2000 16:15:23 +0200
Subject: [Python-Dev] CVS locks on SF
References: <395B5030.C0F08E82@lemburg.com> <200006291503.KAA10324@cj20424-a.reston1.va.home.com>
Message-ID: <395B59FB.1CD472AE@lemburg.com>

Guido van Rossum wrote:
> 
> > I'm getting loads of lock messages during CVS checkins recently.
> > Is this due to overload ? (I wonder why anoncvs access causes
> > locking at all -- there is no write access so why should there
> > be file locking ?):
> 
> I haven't seen this myself.  Could be you were just unlucky.  Could be
> someone was doing a full checkout over a slow connection.
> 
> I think the anon checkouts still use (read) locks because they need to
> get a consistent version.

Looks like someone is using a 9.6kBaud mobile phone connection ;-)
The problem still persists and I've been trying for about
half an hour now.

I'll try again later today...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at beopen.com  Thu Jun 29 17:21:47 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 10:21:47 -0500
Subject: [Python-Dev] Text about cycle GC
In-Reply-To: Your message of "Thu, 29 Jun 2000 06:52:21 MST."
             <395B5495.CF274583@prescod.net> 
References: <200006291331.PAA21571@python.inrialpes.fr>  
            <395B5495.CF274583@prescod.net> 
Message-ID: <200006291521.KAA10440@cj20424-a.reston1.va.home.com>

> Won't we have a clear picture by the end of the beta period?

Not clear.  Unfortunately, few people who run important apps will
download a beta and try it.  But they *will* download a new release
labeled "final" and install it without making sure it works for their
app.  This has been my experience throughout Python's life.  I've
become pretty conservative about staying backwards compatible as a
result...

> > The "optional experimental feature" label is good and IMO it complies
> > with anybody's expectations. Interested people will jump in and will
> > eventually contribute with improvements, those who don't care won't
> > and will live happily without it (at least until the day the feature
> > and its implementation reach their expected maturity).
> 
> A million Window users will live unhappily without it because they don't
> know how to recompile to get it!

This can be solved the way we solve everything for Windows users: give
them two distributions to choose from -- or maybe one distribution
with a checkbox to choose which version to use.

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



From skip at mojam.com  Thu Jun 29 15:38:20 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 08:38:20 -0500 (CDT)
Subject: [Python-Dev] Sourceforge Interface Concerns
In-Reply-To: <PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
References: <20000628025304.BB64A1CE0D@dinsdale.python.org>
	<PGECLPOBGNBNKHNAGIJHEEPDCCAA.andy@robanal.demon.co.uk>
Message-ID: <14683.20812.615266.196934@beluga.mojam.com>

    Andy> How many people here have actually created accounts for themselves
    Andy> on SourceForge and tried to do stuff when logged in - raise bugs
    Andy> and so on?  Did it work for you?

I've submitted a few patches with no problems.  My usual connections are a
corporate T1-ish connection or cable modem access from home, however.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From jeremy at beopen.com  Thu Jun 29 16:45:27 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 29 Jun 2000 10:45:27 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com>
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
	<395ACED5.83764D45@prescod.net>
	<20000629082519.A13839@newcnri.cnri.reston.va.us>
	<14683.21672.414396.364125@cj42289-a.reston1.va.home.com>
Message-ID: <14683.24839.650558.23732@bitdiddle.concentric.net>

>>>>> "FLD" == Fred L Drake, <fdrake at beopen.com> writes:

  FLD> Andrew Kuchling writes:
  >> That's a patch I made to the Makefile and submitted to James
  >> Clark.  For Modules/Setup.in, I can change it to explicitly list
  >> the 8 files from Expat that need to be linked to.  The problem is
  >> that one of the

  FLD>   It's not in the stable version I picked up last night; I'll
  FLD> dig up the experimental version today.

I downloaded version 1.1 from the expat home page.  The URL for the
download is ftp://ftp.jclark.com/pub/xml/expat.zip.  This version
hasn't changed in the last two weeks. 

The instructions Fred include worked almost just right.  I checked in
the corrected ar command and it looks good.

Jeremy



From fdrake at beopen.com  Thu Jun 29 16:46:48 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 10:46:48 -0400 (EDT)
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <200006291503.KAA10324@cj20424-a.reston1.va.home.com>
References: <395B5030.C0F08E82@lemburg.com>
	<200006291503.KAA10324@cj20424-a.reston1.va.home.com>
Message-ID: <14683.24920.264911.840500@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > I think the anon checkouts still use (read) locks because they need to
 > get a consistent version.

  Yes; you need a directory lock to avoid files getting modified or
deleted underneath you while checking out/updating.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Thu Jun 29 16:48:38 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 10:48:38 -0400 (EDT)
Subject: [Python-Dev] re: ucnhash
In-Reply-To: <395B58D4.E52CBBD6@lemburg.com>
References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50>
	<395B58D4.E52CBBD6@lemburg.com>
Message-ID: <14683.25030.205960.13328@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Someone (Fred ?) already patches those places for you. He didn't
 > send patches for the perfect hash tool though.

  Not this Fred...


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Thu Jun 29 16:52:28 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 10:52:28 -0400 (EDT)
Subject: [Python-Dev] how do I build pyexpat?
In-Reply-To: <14683.24839.650558.23732@bitdiddle.concentric.net>
References: <14682.44979.673881.83798@bitdiddle.concentric.net>
	<395ACED5.83764D45@prescod.net>
	<20000629082519.A13839@newcnri.cnri.reston.va.us>
	<14683.21672.414396.364125@cj42289-a.reston1.va.home.com>
	<14683.24839.650558.23732@bitdiddle.concentric.net>
Message-ID: <14683.25260.182929.808330@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > The instructions Fred include worked almost just right.  I checked in
 > the corrected ar command and it looks good.

  That's what I get for typing in the dark on a dark keyboard.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Thu Jun 29 18:23:54 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 12:23:54 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <395b1528.5978476@smtp.worldonline.dk>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>

[posted & mailed]

[Tim]
> id() has to return a unique value.

[Finn Bock]
> This property of id() does not hold in JPython. When used with hotspot,
> id() is not unique.

So it's possible there for one of these be true:

    id(x) == id(y) and x is not y
    id(x) != id(x)

?  Then that's a bug in JPython or hotspot.  Know which?  Filed a bug
report?

In CPython, we just use the address of an object's header, and as CPython
never moves an object's header in memory, the good stuff follows trivially.
Don't know what JPython tries to do, but it's bound to be harder there (as
Java can move memory around).





From bckfnn at worldonline.dk  Thu Jun 29 18:43:09 2000
From: bckfnn at worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 16:43:09 GMT
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>
Message-ID: <395b79a7.31704869@smtp.worldonline.dk>

[Tim]

>So it's possible there for one of these be true:
>
>    id(x) == id(y) and x is not y
>    id(x) != id(x)
>
>?

Yes, the first.


d = {}
cnt = 0

for i in xrange(100000):
    s = "test" + `i`
    j = id(s)
    if d.has_key(j):
        cnt = cnt + 1
    d[j] = s

print cnt, "failures"

Will print 500+ failures when run by JPython & JDK1.3 on win2k.

>Then that's a bug in JPython or hotspot.  Know which?

JPython.

> Filed a bug report?

Years ago <wink>:
  http://www.python.org/jpython-bugs/incoming?id=118

>In CPython, we just use the address of an object's header, and as CPython
>never moves an object's header in memory, the good stuff follows trivially.
>Don't know what JPython tries to do, but it's bound to be harder there (as
>Java can move memory around).

That is also my guess. I cannot see what we can do about it, except inform
users that not all python platform behave exactly the same. Which is why I
brought it up.

regards,
finn



From trentm at activestate.com  Thu Jun 29 18:42:56 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 09:42:56 -0700
Subject: [Python-Dev] arraymodule still broken?
In-Reply-To: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid>
References: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid>
Message-ID: <20000629094256.A21926@activestate.com>

On Thu, Jun 29, 2000 at 12:21:22PM +0200, Fredrik Lundh wrote:
> just checked everything out and rebuilt, the exceptions
> problem sure disappeared, but I still get this error:
> 
> >>> import array
> >>> array.array("H", [60000])
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> OverflowError: signed short integer is greater than maximum
> 
> second opinion, anyone?
> 

I think this is because we are in the middling state where all of my patches
have not gotten in yet. I say this because this is what I get with my version
that has all of my patches applied:

Python 1.6a2 (#1, Jun 29 2000, 09:28:15)  [GCC egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> import array
>>> array.array("H", [60000])
array('H', [60000])
>>>


Specifically, I haven't looked for the issue. Is it alright if I look at this
this weekend?


Trent


-- 
Trent Mick
trentm at activestate.com



From trentm at activestate.com  Thu Jun 29 18:53:43 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 09:53:43 -0700
Subject: [Python-Dev] build problems under MSVC 5.0
In-Reply-To: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid>
References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid>
Message-ID: <20000629095343.B21926@activestate.com>

On Thu, Jun 29, 2000 at 12:07:42PM +0200, Fredrik Lundh wrote:
> Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier
> Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv'
> Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier
> Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type'
> Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier
> 
This is a result of one of my patches. I was using MSVC 6.0, where INT_PTR is
defined as you would expect. I did not realize that it was new to that
version of the headers.

BTW, INT_PTR, UINT_PTR, etc are the standard defines that I saw Microsoft
suggesting in their Win64 docs. I don't like those names, because they are
not portable. I should have used the (ANSI?) equivalents: intptr_t,
uintptr_t. In fact, I *did* use those in some of my patches where the code
portability was required (as obviously it is not in thread_*nt*.h).


> in MSVC 5.0, _beginthread returns an "unsigned long" (this is also
> how it's documented in MSDN).

Yup. And in the Win64 headers _beginthread returns uintptr_t, which makes me
wonder why I picked INT_PTR.


> 
> I suggest changing the declaration in thread_nt.h to:
> 
> #if _MSC_VER >= 1200
>  INT_PTR rv;
> #else
>  unsigned long rv;
> #endif
> 

As I said above, I acknowledge that I should not have used INT_PTR.
Win32: unsigned long _beginthread()
Win64: uintptr_t _beginthread()

I think (am I wrong?) to generalize that the intention for both Win32 and
Win64 is to have _beginthread return an unsigned pointer-sized integer: hence
uintptr_t.

This would eliminate the #ifdef but would require a typedef for uintptr_t on
Win32. This can be done in PC/config.h (I already did this for intptr_t,
because I needed *that* elsewhere.) Does this also need to be generalized to
typedef uintptr_t whereever it is not defined, i.e. in the autoconf files.

I can look at this this weekend, if that is soon enough.



> on the other hand, the same docs claim that it returns -1 on errors.
> doesn't exactly look like an unsigned long to me, but that's another
> story...
> 

Yes, strange.



Trent

-- 
Trent Mick
trentm at activestate.com



From effbot at telia.com  Thu Jun 29 19:07:02 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 19:07:02 +0200
Subject: [Python-Dev] build problems under MSVC 5.0
References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> <20000629095343.B21926@activestate.com>
Message-ID: <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid>

trent wrote:
> I think (am I wrong?) to generalize that the intention for both Win32 and
> Win64 is to have _beginthread return an unsigned pointer-sized integer: hence
> uintptr_t.
> 
> This would eliminate the #ifdef but would require a typedef for uintptr_t on
> Win32. This can be done in PC/config.h (I already did this for intptr_t,
> because I needed *that* elsewhere.) Does this also need to be generalized to
> typedef uintptr_t whereever it is not defined, i.e. in the autoconf files.
> 
> I can look at this this weekend, if that is soon enough.

I suggest checking in the #ifdef as a stopgap measure, if you
promise to come up with the right thing (whatever that is) in
time for 1.6 final.

Should I go ahead and check it in?

</F>




From tim_one at email.msn.com  Thu Jun 29 19:15:08 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 13:15:08 -0400
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <395B5030.C0F08E82@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com>

[MAL]
> I'm getting loads of lock messages during CVS checkins recently.
> Is this due to overload ? (I wonder why anoncvs access causes
> locking at all -- there is no write access so why should there
> be file locking ?):

IIRC, CVS maintains the illusion of being a multi-user system by using
per-*directory* locks.  That means it gives you the warm fuzzy feeling that
you're being protected against (e.g.) getting an inconsistent snapshot while
someone else is committing, but in fact you're not protected at all
(inter-directory).  It locks per-directory to ensure the integrity of its
own data files, but users are subject to the luck of the draw.

Note that Perl is maintained under (the commercial, alas) Perforce, which is
one of the few SCMs to take multi-developer multi-directory issues
seriously.

So the good news is that when you see a CVS lock gripe, that means CVS is
protecting itself from corruption.  The bad news is that if we used a system
that protected *us* against inconsistencies too, we'd probably see lock
gripes even more often.





From gmcm at hypernet.com  Thu Jun 29 19:19:51 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 29 Jun 2000 13:19:51 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEDAGHAA.tim_one@email.msn.com>
References: <395b1528.5978476@smtp.worldonline.dk>
Message-ID: <1249823239-44851587@hypernet.com>

[Finn Bock]
> > This property of id() does not hold in JPython. When used with
> > hotspot, id() is not unique.
[Tim] 
> So it's possible there for one of these be true:
> 
>     id(x) == id(y) and x is not y
>     id(x) != id(x)
> 
> ?  Then that's a bug in JPython or hotspot.  Know which?  Filed a
> bug report?

Oh, you silly boy. There are (by definition) no bugs in hotspot.

it's-only-'cause-Guido's-a-weenie-that-Python-has-'em-ly y'rs

- Gordon



From tim_one at email.msn.com  Thu Jun 29 19:44:45 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 13:44:45 -0400
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <395b79a7.31704869@smtp.worldonline.dk>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>

[Finn Bock, says id() is buggy under JPython]

[Tim]
>> Filed a bug report?

[Finn]
> Years ago <wink>:
>   http://www.python.org/jpython-bugs/incoming?id=118

>> In CPython, we just use the address of an object's header, and as CPython
>> never moves an object's header in memory, the good stuff follows
>> trivially.  Don't know what JPython tries to do, but it's bound to be
>> harder there (as Java can move memory around).

> That is also my guess. I cannot see what we can do about it, except
> inform users that not all python platform behave exactly the same. Which
> is why I brought it up.

Well, neither Java's hashCode nor identityHashCode are correct
implementations of Python's id(), so JPython's id() is simply wrong.  I
don't know anything about the internals of JPython.  If there's a "choke
point" for allocating Python objects, the quickest way out may be to add a
write-once "id" field to each Python object under JPython, and simply fill
it with an integer that's (safely) incremented by 1 on each allocation.

Python doesn't guarantee you'll get the *same* id(x) across implementations,
or even across runs under a single implementation, so the implementations of
id() in CPython and JPython can do entirely different things.  They have to
meet the promises in the Python docs, though, and JPython's currently
doesn't.






From effbot at telia.com  Thu Jun 29 19:51:32 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 19:51:32 +0200
Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org>
Message-ID: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>

greg wrote:
> I think you are being paranoid :-)
> 
> Consider that this same issue applies to all 5900 projects and 38000
> developers at SourceForge. VA Linux has a brand identity entirely built on
> the trust and support of the Linux (and Open Source) communities. If they
> blow away that trust, they are simply screwed.

on the other hand, lots of people thought that dejanews
would store usenet postings forever...

http://salon.com/tech/log/2000/06/20/deja/index.html

</F>




From pingster at ilm.com  Thu Jun 29 19:47:13 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 10:47:13 -0700 (PDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.SGI.3.96.1000629104223.621134m-100000@happy>

On Thu, 29 Jun 2000, Guido van Rossum wrote:
> 
> Argh!  An inappropriate side effect of Ping's cleanup -- thanks for
> catching this.  Apparently Ping didn't do a CVS update before
> generating his diffs.

My apologies!  I'm pretty sure i did an update, but i must have
left too long a gap during which 1.2 got checked in.  You'd think
somehow a version-control system would have noticed the inconsistency
between ancestor versions...

Anyway, very sorry for the trouble.  Glad it appears to be cleared
up now.


-- ?!ng




From effbot at telia.com  Thu Jun 29 19:56:02 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 19:56:02 +0200
Subject: [Python-Dev] id() on Win64
References: <20000628160743.A16262@acs.ucalgary.ca>
Message-ID: <027101bfe1f3$4d478ae0$f2a6b5d4@hagrid>

neil wrote:
> [Greg Stein]
> >Strictly speaking: the Long only occurs on Win64 platforms.
> >
> >I would guess that it is also possible on say, an Alpha running
> >Linux.  Presuming that has 64-bit pointers(?).
> 
> I think the Alpha is okay. The problem is strange type models
> were int is 32 bits and pointers are 64.  AFAIK, the Alpha uses
> 64 bits for both.

is this true for linux alpha too?

it's definitely true for tru64; we've been using python
extensively on that platform since 1995:
http://www.smhi.se/weather/satelitbilder/satellitbilder.htm
(in swedish, but I suppose you all can figure out what
it is anyway ;-)

</F>




From gward at mems-exchange.org  Thu Jun 29 19:55:25 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 29 Jun 2000 13:55:25 -0400
Subject: [Python-Dev] Test results of linuxaudiodev.c
Message-ID: <20000629135525.A5221@ludwig.cnri.reston.va.us>

Hi --

here are results from testing linuxaudiodev from the latest CVS Python
1.6.  This is on a Dell Dimension with on-board audio hardware: the
Yamaha YMF724 chipset.  I'm using the ALSA 0.5.8a driver (the latest as
of a week or two ago, and the only one that supports the YMF724).

Bottom line: the test sound plays, but it sounds horrible when played by 
linuxaudiodev.  If I do this:

  $ play Lib/test/audiotest.au

then Cardinal Fang comes through loud and clear.  ("play" is a shell
script wrapper for "sox", writing to /dev/dsp.)  But if I do this:

  $ ./python Lib/test/regrtest.py test_linuxaudiodev

he's still audible (and at the same volume), but very scratchy.  Sounds
kind of like a very over-driven amp, or like a cheap car radio that
somebody attacked with a knife.

[...some time passes...]

OK, I just tried it on another machine, also a Dell but with a different
sound chip: the Crystal CS4232.  I'm pretty sure this one is using the
OSS drivers included with the kernel, which is probably the second most
important difference after the chipset itself.  Bottom line: it also
sounds horrible.

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From bwarsaw at beopen.com  Thu Jun 29 19:57:27 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 13:57:27 -0400 (EDT)
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
References: <395b79a7.31704869@smtp.worldonline.dk>
	<LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>
Message-ID: <14683.36359.864478.495915@anthem.concentric.net>

>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:

    TP> Well, neither Java's hashCode nor identityHashCode are correct
    TP> implementations of Python's id(), so JPython's id() is simply
    TP> wrong.  I don't know anything about the internals of JPython.
    TP> If there's a "choke point" for allocating Python objects, the
    TP> quickest way out may be to add a write-once "id" field to each
    TP> Python object under JPython, and simply fill it with an
    TP> integer that's (safely) incremented by 1 on each allocation.

    TP> Python doesn't guarantee you'll get the *same* id(x) across
    TP> implementations, or even across runs under a single
    TP> implementation, so the implementations of id() in CPython and
    TP> JPython can do entirely different things.  They have to meet
    TP> the promises in the Python docs, though, and JPython's
    TP> currently doesn't.

I can't generate patches right now, but what you need to change is in
__builtin__.java, the id() function.  It should probably call
object.id() which would fill in the monotonically incrementing id as
Tim suggestions.

One question is what to do about Java proxies.  Currently built-in
id() returns the identityHashCode() of the proxy object, which is just
an Object.  I'm not sure sticking the id in the wrapper is the right
thing or not.

-Barry



From effbot at telia.com  Thu Jun 29 20:18:26 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 20:18:26 +0200
Subject: [Python-Dev] Re: sourceforge data (was: Let's use the SourceForge Patch Manager)
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> <20000629110557.W29590@lyra.org>
Message-ID: <02d901bfe1f6$720ca920$f2a6b5d4@hagrid>

greg wrote:
> > on the other hand, lots of people thought that dejanews
> > would store usenet postings forever...
> 
> Different problem space. They weren't holding people's data.

well, they dropped a few thousand eff-bot postings ;-)

> Worrying about it is a useless exercise, IMO.

well, I'm not worried.  but in the internet universe, strange
things happen all the time...

(checked out http://www.fuckedcompany.com/ lately?)

...

btw, has anyone checked what's in:
http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz 

(with ping times somewhere around one second, it's too
large for me to check out...)

</F>




From effbot at telia.com  Thu Jun 29 20:05:34 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 29 Jun 2000 20:05:34 +0200
Subject: [Python-Dev] OT: A Day in the Life of p5p
References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <20000628113505.C15643@ludwig.cnri.reston.va.us>
Message-ID: <02cd01bfe1f4$a271cca0$f2a6b5d4@hagrid>

greg wrote:


> On 28 June 2000, Fredrik Lundh said:
> > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt
> > 
> > unfortunately, his "What is it with those Python fucks anyway" talk
> > isn't posted... ;-)
> 
> But the "Conclusion" of his "Lies We Tell" talk:
> 
>    Perl sucks. Use Python.
> 
> Presumably tongue-in-cheek, but you never know...

note that all lies he mentioned earlier in that talk
was quoted; this one wasn't.  in other words, it's
a fact.  but we already know that, don't we ;-)

</F>




From bwarsaw at beopen.com  Thu Jun 29 20:56:52 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 14:56:52 -0400 (EDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
References: <20000629135525.A5221@ludwig.cnri.reston.va.us>
Message-ID: <14683.39924.477408.233069@anthem.concentric.net>

>>>>> "GW" == Greg Ward <gward at mems-exchange.org> writes:

    GW> then Cardinal Fang comes through loud and clear.  ("play" is a
    GW> shell script wrapper for "sox", writing to /dev/dsp.)  But if
    GW> I do this:

    GW>   $ ./python Lib/test/regrtest.py test_linuxaudiodev

    GW> he's still audible (and at the same volume), but very
    GW> scratchy.  Sounds kind of like a very over-driven amp, or like
    GW> a cheap car radio that somebody attacked with a knife.

I don't even get that.  play works fine for me too, but on this Dell
Optiplex GX110 with unknown sound chip set, test_linuxaudiodev gives
me nothing.

-Barry



From gstein at lyra.org  Thu Jun 29 20:05:57 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 11:05:57 -0700
Subject: [Python-Dev] sourceforge data (was: Let's use the SourceForge Patch Manager)
In-Reply-To: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>; from effbot@telia.com on Thu, Jun 29, 2000 at 07:51:32PM +0200
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com> <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>
Message-ID: <20000629110557.W29590@lyra.org>

On Thu, Jun 29, 2000 at 07:51:32PM +0200, Fredrik Lundh wrote:
> greg wrote:
> > I think you are being paranoid :-)
> > 
> > Consider that this same issue applies to all 5900 projects and 38000
> > developers at SourceForge. VA Linux has a brand identity entirely built on
> > the trust and support of the Linux (and Open Source) communities. If they
> > blow away that trust, they are simply screwed.
> 
> on the other hand, lots of people thought that dejanews
> would store usenet postings forever...

Different problem space. They weren't holding people's data.

If SourceForge were ever to close, then I have 100% faith that they would
make sure to provide a way for everybody to get their data off the machines.

Worrying about it is a useless exercise, IMO.

Cheers,
-g

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



From guido at beopen.com  Thu Jun 29 21:05:11 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 29 Jun 2000 14:05:11 -0500
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: Your message of "Thu, 29 Jun 2000 13:15:08 -0400."
             <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com> 
Message-ID: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>

> [MAL]
> > I'm getting loads of lock messages during CVS checkins recently.
> > Is this due to overload ? (I wonder why anoncvs access causes
> > locking at all -- there is no write access so why should there
> > be file locking ?):
> 
> IIRC, CVS maintains the illusion of being a multi-user system by using
> per-*directory* locks.  That means it gives you the warm fuzzy feeling that
> you're being protected against (e.g.) getting an inconsistent snapshot while
> someone else is committing, but in fact you're not protected at all
> (inter-directory).  It locks per-directory to ensure the integrity of its
> own data files, but users are subject to the luck of the draw.

Yes, that's how it works...

> Note that Perl is maintained under (the commercial, alas) Perforce, which is
> one of the few SCMs to take multi-developer multi-directory issues
> seriously.

We tried Perforce at CNRI.  It's really neat, but somehow it was
lacking some stuff we were used to and we never converted.

Note that Perforce is free for open source projects -- at least at the
time it was.  (CNRI paid a license fee, but that was just an
expression of CNRI's reluctance against free software. :-)

There's also bitkeeper.  It stayed in beta so long that we gave up
(and they have a weird license) -- but it's out of beta since May 4:
see http://www.bitkeeper.com/.  But there's no immediate download!
You must sign up and they send you instructions in the mail...

> So the good news is that when you see a CVS lock gripe, that means CVS is
> protecting itself from corruption.  The bad news is that if we used a system
> that protected *us* against inconsistencies too, we'd probably see lock
> gripes even more often.

Well, the implementation could save the previous consistent version
and give you that while an update was under way...  There are other
ways to protect against inconsistencies.  But I'm not sure that you
always *want* this -- as a system grows, it's better to be able to
deal with inconsistencies than to try to avoid them (and have the
world blow up in your face when the avoidance fails).

Anyway, I submitted a service request to have the lock in the Lib/test
lock removed.  (Apparently some process didn't clear up its lock.
That's rare, but sometimes it happens.)  It's been fixed now, so
checkins in the Lib/test directory should move forward again.

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



From bckfnn at worldonline.dk  Thu Jun 29 21:15:45 2000
From: bckfnn at worldonline.dk (Finn Bock)
Date: Thu, 29 Jun 2000 19:15:45 GMT
Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCGEEBGHAA.tim_one@email.msn.com>
Message-ID: <395b9f71.41379240@smtp.worldonline.dk>

[Tim]

>Well, neither Java's hashCode nor identityHashCode are correct
>implementations of Python's id(), so JPython's id() is simply wrong. 

I agree.

>I don't know anything about the internals of JPython.  If there's a "choke  
>point" for allocating Python objects, 

The constructor of PyObject should do nicely.

>the quickest way out may be to add a
>write-once "id" field to each Python object under JPython, and simply fill
>it with an integer that's (safely) incremented by 1 on each allocation.

Properly have to be a java long to avoid overflowing.

>Python doesn't guarantee you'll get the *same* id(x) across implementations,
>or even across runs under a single implementation, so the implementations of
>id() in CPython and JPython can do entirely different things.  They have to
>meet the promises in the Python docs, though, and JPython's currently
>doesn't.

I haven't considered it to be so important. It is possible to fix the std
modules so it doesn't cause problems (as is done in cPickle.java). 

[Barry]

>One question is what to do about Java proxies.  Currently built-in
>id() returns the identityHashCode() of the proxy object, which is just
>an Object.  I'm not sure sticking the id in the wrapper is the right
>thing or not.

It properly isn't. New wrappers can be created for the same object. F.ex
when a java object is passed from python into java code and returned back
into python, two wrappers will exists for the same java object. Since these
two wrappers represent the same object they should (as it does now) return
the same id() value.

regards,
finn



From bwarsaw at beopen.com  Thu Jun 29 21:23:48 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 15:23:48 -0400 (EDT)
Subject: [Python-Dev] Re: sourceforge data (was: Let's use the SourceForge Patch Manager)
References: <LNBBLJKPBEHFEDALKOLCEENKGGAA.tim_one@email.msn.com>
	<395A32FD.D3C58B23@prescod.net>
	<20000628173424.H29590@lyra.org>
	<025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>
	<20000629110557.W29590@lyra.org>
	<02d901bfe1f6$720ca920$f2a6b5d4@hagrid>
Message-ID: <14683.41540.530581.459708@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <effbot at telia.com> writes:

    FL> btw, has anyone checked what's in:
    FL> http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz 

I suck down nightly copies of that file and the corresponding Mailman
tarball.  I looked at them when I first set up my script, but haven't
checked them lately.

-Barry



From nascheme at enme.ucalgary.ca  Thu Jun 29 22:02:02 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 29 Jun 2000 14:02:02 -0600
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com> <200006291905.OAA17265@cj20424-a.reston1.va.home.com>
Message-ID: <20000629140201.A20446@acs.ucalgary.ca>

I recently made the conversion from CVS to PRCS.  I like PRCS
much better.  It is easier to use, implemented indepentant of
rcs, faster, more flexible and has versioned project meta-data.
Branching and merging is much simpiler than CVS.  Operations on
project versions are atomic.  Renaming and moving files is easy.
It is well documented.

Unfortunately version 1 does not support distributed
repositories.  Josh has informed my that version to is coming
(hopefully this year) and will support distributed repositories.

For Python I don't think that a multi-user version control system
is strictly necessary anyhow.  The PRCS repository could be made
available via rsync and a process could be setup for checking
patches into the central repository.  It should actually be more
efficient than the current CVS setup.

I just looked at the webpage and the beta for 2.0 is out:

    http://www.xcf.berkeley.edu/~jmacd/prcs.html

If PythonLabs is interested in using PRCS I will even volunteer
to make sure those Windows weenies have a good port. :)

  Neil




From jeremy at beopen.com  Thu Jun 29 22:40:14 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 29 Jun 2000 16:40:14 -0400 (EDT)
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <20000629140201.A20446@acs.ucalgary.ca>
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com>
	<200006291905.OAA17265@cj20424-a.reston1.va.home.com>
	<20000629140201.A20446@acs.ucalgary.ca>
Message-ID: <14683.46126.19856.447975@bitdiddle.concentric.net>

I was just looking at Josh's work last week, and thought it looks
quite interesting.  Despite my interest, I don't expect we would use
it for Python unless SourceForge adopted it.  We moved the Python CVS
tree to SourceForge to avoid maintaing a large installation of
software development/management tools.

Jeremy



From klm at digicool.com  Thu Jun 29 22:53:21 2000
From: klm at digicool.com (Ken Manheimer)
Date: Thu, 29 Jun 2000 16:53:21 -0400 (EDT)
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEBPGHAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>

On Thu, 29 Jun 2000, Tim Peters wrote:

> > ...
> > Hmm. Is there a good place to start listing these todo items?
> 
> Not that I know of.  "Group whiteboards" and shared journals etc are darned
> useful, though.

Wiki = Group whiteboard

Zope could do a lot of this stuff well.  As is, ZWiki offers some
organizational features.  I've held off on pushing them because they're
still baking - things like change notifications, discretion about change
privileges, versions (with differences, based on your ndiff.py), etc are
coming soonish.  (Exactly how soonish is hard to say, the way time and
more direct business obligations are - but this stuff actually is
important to us, we're using them a lot for collaboration, and need for
the dynamics to scale...)

I also have the feeling that our tracker would be good for patch
management - except, i don't really know what the requirements are, there,
and once again, tracker only gives notifications via email, it doesn't
take input that way.

Anyway, to see leads on both zwikis and tracker, see:

  http://www.zope.org/Members/klm/TrackerWiki

Oh, and it would be easy to set up a wiki for python dev on zope.org
somewhere - i could put it in my account, or we could situate one more
centrally, in a storage that's never packed, so the version history is
maintained.  Or any of you could get a zope.org membership and set some
up, yerselves.  Or set up a zope somewhere - it'd be !cool! if sourceforge
were willing...

Ken
klm at zope.org




From klm at digicool.com  Thu Jun 29 23:25:55 2000
From: klm at digicool.com (Ken Manheimer)
Date: Thu, 29 Jun 2000 17:25:55 -0400 (EDT)
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>
Message-ID: <Pine.LNX.4.21.0006291723370.4495-100000@korak.digicool.com>

On Thu, 29 Jun 2000, Ken Manheimer wrote:

> Wiki = Group whiteboard
> [...]
> Oh, and it would be easy to set up a wiki for python dev on zope.org
> somewhere - i could put it in my account, or we could situate one more

http://www.zope.org/Members/klm/PythonDev/TodoLists

There's nothing else of substance there, but anyone who's a member at
zope.org can edit and add pages...

Ken




From guido at python.org  Fri Jun 30 01:25:09 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 29 Jun 2000 18:25:09 -0500
Subject: [Python-Dev] New PythonLabs site revealed!
Message-ID: <200006292325.SAA19744@cj20424-a.reston1.va.home.com>

Today, without much fanfare, we opened the new PythonLabs website.
The design is by BeOpen's creative Director, Jun Simmons.  Thanks to
Jeremy Hylton, who did most of the actual HTML editing to get our
contents in place.

The new beta will be released via this site.

And since you python-dev folks will find this out through my checkins
anyway, let this be an advance warning that it will be called Python
2.0.  Here's my explanation for the version bump (soon to be checked
in to README):

"""
While Pythoneers have grown fond of Python's exceedingly slow version
incrementing, that same quality makes parts of the rest of the world
think Python is barely out of its first alpha test.  Especially
enterprise customers are often fearful of anything that's version 1.x!
The new version number also clearly marks Python's departure from
CNRI.

Previously, the version number 2.0 was associated with a mythical and
elusive incompatible future release.  That release (still ways off,
and not as incompatible as people fear!) is now referred to as Python
3000.
"""

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



From mwh21 at cam.ac.uk  Fri Jun 30 00:53:39 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 29 Jun 2000 23:53:39 +0100
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: Greg Ward's message of "Thu, 29 Jun 2000 13:55:25 -0400"
References: <20000629135525.A5221@ludwig.cnri.reston.va.us>
Message-ID: <m33dlw85fw.fsf@atrus.jesus.cam.ac.uk>

Greg Ward <gward at mems-exchange.org> writes:

> Hi --
> 
> here are results from testing linuxaudiodev from the latest CVS Python
> 1.6.  This is on a Dell Dimension with on-board audio hardware: the
> Yamaha YMF724 chipset.  I'm using the ALSA 0.5.8a driver (the latest as
> of a week or two ago, and the only one that supports the YMF724).
> 
> Bottom line: the test sound plays, but it sounds horrible when played by 
> linuxaudiodev.  If I do this:
> 
>   $ play Lib/test/audiotest.au
> 
> then Cardinal Fang comes through loud and clear.  ("play" is a shell
> script wrapper for "sox", writing to /dev/dsp.)  But if I do this:
> 
>   $ ./python Lib/test/regrtest.py test_linuxaudiodev
> 
> he's still audible (and at the same volume), but very scratchy.  Sounds
> kind of like a very over-driven amp, or like a cheap car radio that
> somebody attacked with a knife.
> 
> [...some time passes...]
> 
> OK, I just tried it on another machine, also a Dell but with a different
> sound chip: the Crystal CS4232.  I'm pretty sure this one is using the
> OSS drivers included with the kernel, which is probably the second most
> important difference after the chipset itself.  Bottom line: it also
> sounds horrible.

Just tried that here; ouch.  I have a Dell Dimension XPS D233 (which
has an on-board Yamaha chipset - the OPL2, I believe).  I use the
sound driver that comes with the redhat built kernel (which is the OSS
one I think).

$ play audiotest.au

sounds fine,

$  ../../../build/python regrtest.py test_linuxaudiodev.py \
test_linuxaudiodev

sounds horrible; it sounds like it's being rammed through at far too
high a volume, but playing with the PCM or volume sliders in gmix has
no appreciable effect on the quality.  This suggests somewhat that the
problem lies in linuxaudiodev.c, doesn't it?

Is this stuff, like, documented anywhere?  I can't find any helpful
manpages...

I presume this module must work better than this for some people?

Cheers,
M.





From guido at python.org  Fri Jun 30 02:20:15 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 29 Jun 2000 19:20:15 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: Your message of "Thu, 29 Jun 2000 16:05:01 MST."
             <200006292305.QAA11929@slayer.i.sourceforge.net> 
References: <200006292305.QAA11929@slayer.i.sourceforge.net> 
Message-ID: <200006300020.TAA21877@cj20424-a.reston1.va.home.com>

> On second thought, first try for _winreg, and then winreg.  Only if both
> fail do we try for win32api/win32con.  If *those* both fail, then we don't
> have registry access.  Phew!

Is this smart?  Doesn't the new winreg have a very different I/F than
the old one?

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



From pingster at ilm.com  Fri Jun 30 01:24:28 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 16:24:28 -0700 (PDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: <m33dlw85fw.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <Pine.SGI.3.96.1000629162303.621134p-100000@happy>

On 29 Jun 2000, Michael Hudson wrote:
> $ play audiotest.au
> 
> sounds fine,
> 
> $  ../../../build/python regrtest.py test_linuxaudiodev.py \
> test_linuxaudiodev
> 
> sounds horrible; it sounds like it's being rammed through at far too
> high a volume

Sounds like u-law to me.  linuxaudiodev.c selects /dev/dsp by
default, which accepts raw data, not .au format.

Try setting the environment variable AUDIODEV to /dev/audio
before running the test script.  Does that work any better?


-- ?!ng




From fdrake at beopen.com  Fri Jun 30 01:29:42 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 19:29:42 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: <200006300020.TAA21877@cj20424-a.reston1.va.home.com>
References: <200006292305.QAA11929@slayer.i.sourceforge.net>
	<200006300020.TAA21877@cj20424-a.reston1.va.home.com>
Message-ID: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>

Greg Ward wrote in a checkin message:
 > On second thought, first try for _winreg, and then winreg.  Only if both
 > fail do we try for win32api/win32con.  If *those* both fail, then we don't
 > have registry access.  Phew!

Guido van Rossum writes on python-dev:
 > Is this smart?  Doesn't the new winreg have a very different I/F than
 > the old one?

  No, this is bad.  It *will* break with winreg; if _winreg isn't
available, it should use the win32api/win32con/whatever stuff; it's a
Python 1.5.2 interpreter at that point.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From skip at mojam.com  Fri Jun 30 00:22:18 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 17:22:18 -0500 (CDT)
Subject: [Python-Dev] Mysterious SF message...
Message-ID: <14683.52250.789900.357275@beluga.mojam.com>

I just submitted a patch for lib/libatexit.tex.  In the response page it
displayed a list of patches, then the following cryptic message:

    Patch Uploaded Successfully Added Patch Could Not Send Patch Update

Any idea what that means?

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From tim_one at email.msn.com  Fri Jun 30 01:32:42 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 29 Jun 2000 19:32:42 -0400
Subject: [Python-Dev] Controversial patch (cmath)
Message-ID: <LNBBLJKPBEHFEDALKOLCAEFBGHAA.tim_one@email.msn.com>

I just voted to accept a patch that's broken.  If you want to argue it, be
my guest, but I'm out of it now <wink>.

Here's the patch:

https://sourceforge.net/patch/?func=detailpatch&patch_id=100651&group_id=547
0

Here's my comment (also available on that page):

Accepted (but reluctantly; see below), and assigned back to Guido for
checkin.

cmathmodule is not production quality, and this patch isn't either, but its
asinh and acosh are better than what's there now.

The author avoided some of the numerical foolishness in the original, but
didn't avoid all of it.  For example, it's harder to get asinh to do
something ridiculous now than it was before, but still possible:

>>> cmath.acosh(1e200)
(461.210165779+0j)
>>> cmath.asinh(1e200)
(1.#INF+0j)
>>>

asinh should have returned something approximately equal to what acosh
returned.

That may not be the patch's problem, though!  I suspect that's due to one of
the module's other functions that's too naive about the limits of floating
point.  In any case, it is much easier to provoke the *current* cmath
functions into cases like this one.

Another possible problem has to do with principal values.  My reference
books are in storage, so about the best I can do right now is compare what
this code does to Macsyma (which I have on my laptop).  The acosh in this
patch often returns the negative of what Macysma computes.  For example,

>>> cmath.acosh(-1-1j)
(1.06127506191-2.23703575929j)
>>>

Macsyma returns the negation of that.  On the other hand, the *original*
acosh doesn't agree with Macsyma on some signs where this acosh does.  So
call this one a wash.

I may have mentioned this before <wink>:  robust math libraries are
extremely difficult to get right.  It would take several months to write a
production-quality cmath module from scratch, which is several months more
than were devoted to Python's current cmath <wink>.  I vote we check this in
anyway (since it *is*, overall, an improvement), and look into borrowing
some other language's complex math library later (note in particular that
C9X adds complex numbers and these functions on them, so if we sit on our
asses long enough, we can inherit libc's!).





From mwh21 at cam.ac.uk  Fri Jun 30 01:33:37 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 30 Jun 2000 00:33:37 +0100
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:24:28 -0700 (PDT)"
References: <Pine.SGI.3.96.1000629162303.621134p-100000@happy>
Message-ID: <m3ya3o6p0u.fsf@atrus.jesus.cam.ac.uk>

Ka-Ping Yee <pingster at ilm.com> writes:

> On 29 Jun 2000, Michael Hudson wrote:
> > $ play audiotest.au
> > 
> > sounds fine,
> > 
> > $  ../../../build/python regrtest.py test_linuxaudiodev.py \
> > test_linuxaudiodev
> > 
> > sounds horrible; it sounds like it's being rammed through at far too
> > high a volume
> 
> Sounds like u-law to me.  linuxaudiodev.c selects /dev/dsp by
> default, which accepts raw data, not .au format.
> 
> Try setting the environment variable AUDIODEV to /dev/audio
> before running the test script.  Does that work any better?

That's the ticket.  "play" and the test now sound identical, modulo
some pops & cracks at the start and end of the test.  I presume what
follows is thus a good idea?

Index: test_linuxaudiodev.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_linuxaudiodev.py,v
retrieving revision 1.1
diff -u -r1.1 test_linuxaudiodev.py
--- test_linuxaudiodev.py       2000/06/10 04:22:57     1.1
+++ test_linuxaudiodev.py       2000/06/29 23:32:55
@@ -17,4 +17,6 @@
 def test():
     play_sound_file(findfile('audiotest.au'))
 
+os.environ["AUDIODEV"] = "/dev/audio"
+
 test()

Cheers,
M.




From Vladimir.Marangozov at inrialpes.fr  Fri Jun 30 01:38:19 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 01:38:19 +0200 (CEST)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <200006292325.SAA19744@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 29, 2000 06:25:09 PM
Message-ID: <200006292338.BAA07798@python.inrialpes.fr>

Guido van Rossum wrote:
> 
> Today, without much fanfare, we opened the new PythonLabs website.
> The design is by BeOpen's creative Director, Jun Simmons.  Thanks to
> Jeremy Hylton, who did most of the actual HTML editing to get our
> contents in place.
> 
> The new beta will be released via this site.
> 
> And since you python-dev folks will find this out through my checkins
> anyway, let this be an advance warning that it will be called Python
> 2.0.  Here's my explanation for the version bump (soon to be checked
> in to README):

Guido van Rossum just won't stop surprising us! :-) Witness the three
shocking news that arrived in one day: (1) very strict self-discipline
about "long-term" TODO's full of short-term and less than medium-term
topics that were very logically left behind, (2) major version number
revision one day before the official beta-cycle, (3) a new PythonLabs
corporate-style Web site with a flashing color palette & tutti quanti.
I am really (positively) amazed! :-)

spanish-inquisition-is-all-we-deserve-<wink>-ly y'rs

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From fdrake at beopen.com  Fri Jun 30 01:39:48 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 19:39:48 -0400 (EDT)
Subject: [Python-Dev] documentation patch guidelines
Message-ID: <14683.56900.433607.125111@cj42289-a.reston1.va.home.com>

  I've updated the patch guidelines for documentation to match other
patches, and added a patch category for documentation.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From pingster at ilm.com  Fri Jun 30 01:46:32 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 16:46:32 -0700 (PDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: <Pine.SGI.3.96.1000629162303.621134p-100000@happy>
Message-ID: <Pine.SGI.3.96.1000629163112.621134r-100000@happy>

On Thu, 29 Jun 2000, Ka-Ping Yee wrote:
> Try setting the environment variable AUDIODEV to /dev/audio
> before running the test script.  Does that work any better?

Even if that works, i realize that's not the way the interface
was intended to be used.  To play an AU file, the routine should
look something like this (not tested, as i don't have a working
Linux box)...

def play_au_file(path):

    fp = open(path, "r")

    # Read the .au file header.
    header = fp.read(24)
    hdrsize, length, encoding, rate, channels = \
        struct.unpack(">xxxxiiiii", header)
    fp.read(hdrsize - 24)
    
    data = fp.read()
    fp.close()

    # Set the data format according to the code in the .au header.
    if encoding == 1:
        size, fmt = 8, linuxaudiodev.AFMT_MU_LAW
    elif encoding == 2:
        size, fmt = 8, linuxaudiodev.AFMT_S8
    elif encoding == 3:
        size, fmt = 16, linuxaudiodev.AFMT_S16_BE
    else:
        raise "audio format not supported"
        
    dsp = linuxaudiodev.open("w")
    dsp.setparameters(rate, size, channels, fmt)
    dsp.write(data)
    dsp.close()


-- ?!ng

Explicit hoc totum;            This completes the whole;
Pro Christo da mihi potum.     For Christ's sake give me a drink.
    -- from the colophon of a 12th-century copyist




From nascheme at enme.ucalgary.ca  Fri Jun 30 02:00:37 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Thu, 29 Jun 2000 18:00:37 -0600
Subject: [Python-Dev] Mysterious SF message...
In-Reply-To: <14683.52250.789900.357275@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 05:22:18PM -0500
References: <14683.52250.789900.357275@beluga.mojam.com>
Message-ID: <20000629180037.A22566@acs.ucalgary.ca>

On Thu, Jun 29, 2000 at 05:22:18PM -0500, Skip Montanaro wrote:
> 
> I just submitted a patch for lib/libatexit.tex.  In the response page it
> displayed a list of patches, then the following cryptic message:
> 
>     Patch Uploaded Successfully Added Patch Could Not Send Patch Update
> 
> Any idea what that means?

SourceForge sucks?  Seriously though, I think it means:

  Patch Uploaded Successfully, Added Patch, Could Not Send Patch Update
  
For some reason it couldn't email out the patch update URL.


  Neil



From mwh21 at cam.ac.uk  Fri Jun 30 02:06:04 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 30 Jun 2000 01:06:04 +0100
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:46:32 -0700 (PDT)"
References: <Pine.SGI.3.96.1000629163112.621134r-100000@happy>
Message-ID: <m3u2ec6nir.fsf@atrus.jesus.cam.ac.uk>

Ka-Ping Yee <pingster at ilm.com> writes:

> On Thu, 29 Jun 2000, Ka-Ping Yee wrote:
> > Try setting the environment variable AUDIODEV to /dev/audio
> > before running the test script.  Does that work any better?
> 
> Even if that works, i realize that's not the way the interface
> was intended to be used.  To play an AU file, the routine should
> look something like this (not tested, as i don't have a working
> Linux box)...
[snip]

Yup, that works fine.  Don't understand the details - and as I have my
graduation ceremony tomorrow I'm going to go to bed and leave learning
them until some other occasion!

Cheers,
M.

PS: my Lib/test/test_linuxaudiodev.py is now this:

from test_support import verbose, findfile, TestFailed
import linuxaudiodev
import os,struct

def play_au_file(path):

    fp = open(path, "r")

    # Read the .au file header.
    header = fp.read(24)
    hdrsize, length, encoding, rate, channels = \
        struct.unpack(">xxxxiiiii", header)
    fp.read(hdrsize - 24)
    
    data = fp.read()
    fp.close()

    # Set the data format according to the code in the .au header.
    if encoding == 1:
        size, fmt = 8, linuxaudiodev.AFMT_MU_LAW
    elif encoding == 2:
        size, fmt = 8, linuxaudiodev.AFMT_S8
    elif encoding == 3:
        size, fmt = 16, linuxaudiodev.AFMT_S16_BE
    else:
        raise "audio format not supported"
        
    dsp = linuxaudiodev.open("w")
    dsp.setparameters(rate, size, channels, fmt)
    dsp.write(data)
    dsp.close()


def test():
    play_au_file(findfile('audiotest.au'))

test()

... which is an improvement on what's there now.




From pingster at ilm.com  Fri Jun 30 02:44:35 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Thu, 29 Jun 2000 17:44:35 -0700 (PDT)
Subject: [Python-Dev] Test results of linuxaudiodev.c
In-Reply-To: <m3u2ec6nir.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <Pine.SGI.3.96.1000629173646.621134u-100000@happy>

On 30 Jun 2000, Michael Hudson wrote:
> Yup, that works fine.  Don't understand the details - and as I have my
> graduation ceremony tomorrow I'm going to go to bed and leave learning
> them until some other occasion!

Cool.

Okay, i just discovered sunau.py.  Here's my real shot at
test_linuxaudiodev.py.  Can you give this a try?


---- test_linuxaudiodev.py ----
from test_support import verbose, findfile, TestFailed
import linuxaudiodev
import os, sunau

formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW,
           ("NONE", 1): linuxaudiodev.AFMT_S8,
           ("NONE", 2): linuxaudiodev.AFMT_S16_BE}

def play_au_file(path):
    au = sunau.open(path, "r")
    data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE)
    au.close()

    spec = (au.getcomptype(), au.getsampwidth())
    if not has_key(formats, spec):
        raise "audio format not supported by linuxaudiodev"
        
    dsp = linuxaudiodev.open("w")
    dsp.setparameters(au.getframerate(), au.getsampwidth() * 8,
                      au.getnchannels(), formats[spec])
    dsp.write(data)
    dsp.close()

def test():
    play_au_file(findfile('audiotest.au'))

test()
---- test_linuxaudiodev.py ----



-- ?!ng




From gstein at lyra.org  Fri Jun 30 03:03:11 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 29 Jun 2000 18:03:11 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8
In-Reply-To: <200006291238.FAA01061@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 05:38:48AM -0700
References: <200006291238.FAA01061@slayer.i.sourceforge.net>
Message-ID: <20000629180311.I29590@lyra.org>

Fredrik,

Something you are doing is forcing CVS to issue a new revision for some of
those files, even when you are not changing them. These "false" revisions
are probably not a good thing.

Could you review your checkin process to see what is up? I would guess that
you have the "-f" option in your commit line.

Cheers,
-g

On Thu, Jun 29, 2000 at 05:38:48AM -0700, Fredrik Lundh wrote:
> Update of /cvsroot/python/python/dist/src/Lib
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv899/Lib
> 
> Modified Files:
> 	sre.py sre_compile.py sre_constants.py sre_parse.py 
> Log Message:
> 
> 
> - make sure group names are valid identifiers
>   (closes the "SRE: symbolic reference" bug)
> 
> Index: sre.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre.py,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -C2 -r1.9 -r1.10
> 
> Index: sre_compile.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre_compile.py,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -C2 -r1.7 -r1.8
> 
> Index: sre_constants.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre_constants.py,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -C2 -r1.7 -r1.8
> 
> Index: sre_parse.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/sre_parse.py,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -C2 -r1.7 -r1.8
> *** sre_parse.py	2000/06/29 11:34:27	1.7
> --- sre_parse.py	2000/06/29 12:38:45	1.8
> ***************
> *** 169,172 ****
> --- 169,190 ----
>   	return this
>   
> + def isident(char):
> +     return "a" <= char <= "z" or "A" <= char <= "Z" or char == "_"
> + 
> + def isdigit(char):
> +     return "0" <= char <= "9"
> + 
> + def isname(name):
> +     # check that group name is a valid string
> +     # FIXME: <fl> this code is really lame.  should use a regular
> +     # expression instead, but I seem to have certain bootstrapping
> +     # problems here ;-)
> +     if not isident(name[0]):
> + 	return 0
> +     for char in name:
> + 	if not isident(char) and not isdigit(char):
> + 	    return 0
> +     return 1
> + 
>   def _group(escape, state):
>       # check if the escape string represents a valid group
> ***************
> *** 419,425 ****
>   			    if char == ">":
>   				break
> - 			    # FIXME: check for valid character
>   			    name = name + char
>   			group = 1
>   		    elif source.match("="):
>   			# named backreference
> --- 437,444 ----
>   			    if char == ">":
>   				break
>   			    name = name + char
>   			group = 1
> + 			if not isname(name):
> + 			    raise error, "illegal character in group name"
>   		    elif source.match("="):
>   			# named backreference
> ***************
> *** 523,540 ****
>   			char = s.get()
>   			if char is None:
> ! 			    raise error, "unterminated index"
>   			if char == ">":
>   			    break
> - 			# FIXME: check for valid character
>   			name = name + char
>   		if not name:
> ! 		    raise error, "bad index"
>   		try:
>   		    index = int(name)
>   		except ValueError:
>   		    try:
>   			index = pattern.groupindex[name]
>   		    except KeyError:
> ! 			raise IndexError, "unknown index"
>   		a((MARK, index))
>   	    elif len(this) > 1 and this[1] in DIGITS:
> --- 542,560 ----
>   			char = s.get()
>   			if char is None:
> ! 			    raise error, "unterminated group name"
>   			if char == ">":
>   			    break
>   			name = name + char
>   		if not name:
> ! 		    raise error, "bad group name"
>   		try:
>   		    index = int(name)
>   		except ValueError:
> + 		    if not isname(name):
> + 			raise error, "illegal character in group name"
>   		    try:
>   			index = pattern.groupindex[name]
>   		    except KeyError:
> ! 			raise IndexError, "unknown group name"
>   		a((MARK, index))
>   	    elif len(this) > 1 and this[1] in DIGITS:
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://www.python.org/mailman/listinfo/python-checkins

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



From akuchlin at cnri.reston.va.us  Fri Jun 30 03:29:41 2000
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Thu, 29 Jun 2000 21:29:41 -0400
Subject: [Python-Dev] Removing modules
Message-ID: <20000629212941.A21563@newcnri.cnri.reston.va.us>

For the "deleted modules" section of the 2.0 article, I drew up a list
of modules that might be outdated, mostly the SGI-specific ones.  Are
those modules still useful, and do the libraries they were written for
still exist?

For your cogitation, here's the list: sgimodule.c, glmodule.c (and
hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c,
almodule.c, clmodule.c,  knee.py.

Also, can someone explain why importing a third party extension built
for Python 1.5.x is supposed to result in an immediate crash on
Windows?  I'd like to explain why this happens...

--amk





From guido at python.org  Fri Jun 30 05:13:13 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 29 Jun 2000 22:13:13 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8
In-Reply-To: Your message of "Thu, 29 Jun 2000 18:03:11 MST."
             <20000629180311.I29590@lyra.org> 
References: <200006291238.FAA01061@slayer.i.sourceforge.net>  
            <20000629180311.I29590@lyra.org> 
Message-ID: <200006300313.WAA22134@cj20424-a.reston1.va.home.com>

> Fredrik,
> 
> Something you are doing is forcing CVS to issue a new revision for some of
> those files, even when you are not changing them. These "false" revisions
> are probably not a good thing.
> 
> Could you review your checkin process to see what is up? I would guess that
> you have the "-f" option in your commit line.
> 
> Cheers,
> -g

Greg, we already know why this is.  It's the $ID$.

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



From mhammond at skippinet.com.au  Fri Jun 30 04:49:06 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 12:49:06 +1000
Subject: [Python-Dev] Removing modules
In-Reply-To: <20000629212941.A21563@newcnri.cnri.reston.va.us>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEPMCOAA.mhammond@skippinet.com.au>

> Also, can someone explain why importing a third party extension built
> for Python 1.5.x is supposed to result in an immediate crash on
> Windows?  I'd like to explain why this happens...

The 1.5 module is linked against Python15.dll.  When Python.exe (linked
against Python16.dll) starts up, it initializes the Python data structures
in Python16.dll.  When Python then imports foo.pyd (linked against
Python15.dll), it immediately tries to call the functions in that DLL (such
as getting the thread state).  As Python has not been initialized in that
DLL, we immediately die.

Ironically, if Python1x.dll was simply named "Python.dll", there is a
_reasonable_ chance it would work fine.  The cost of doing this tho, is
that you can not have Python 1.5 and Python 1.6 "side by side" on the same
machine.

There are a few possibilities for magic tricks we could pull, but to be
honest Im not too inclined to bother with them myself...  They would also
require a commitment to a fully backwards compatible C API, which I dont
think we can afford to commit to!

Mark.




From gward at python.net  Fri Jun 30 05:30:03 2000
From: gward at python.net (Greg Ward)
Date: Thu, 29 Jun 2000 23:30:03 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
Message-ID: <20000629233003.A1766@beelzebub>

Curses!

I just noticed that sys.platform in 1.6a2 (and the latest CVS from this
morning) returns "linux2" on my PC, not "linux-i386".  As I recall this
decision is made in the configure script.  Does anyone know why it
changed?  This is not the end of the world, but the OS name alone is not
really enough on a multi-architecture OS...

...back to calling os.uname() myself, I guess.  ;-(

        Greg
-- 
Greg Ward - programmer-at-big                           gward at python.net
http://starship.python.net/~gward/
God made machine language; all the rest is the work of man.



From fdrake at beopen.com  Fri Jun 30 05:33:45 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 29 Jun 2000 23:33:45 -0400 (EDT)
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <20000629233003.A1766@beelzebub>
References: <20000629233003.A1766@beelzebub>
Message-ID: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>

Greg Ward writes:
 > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this
 > morning) returns "linux2" on my PC, not "linux-i386".  As I recall this

  I didn't know it ever returned linux-i386; perhaps you're thinking
of Marc-Andre's platform module?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From trentm at activestate.com  Fri Jun 30 05:34:17 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 20:34:17 -0700
Subject: [Python-Dev] Controversial patch (cmath)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEFBGHAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCAEFBGHAA.tim_one@email.msn.com>
Message-ID: <20000629203417.B23077@activestate.com>

[Tim discusses god awful math details]
Would you want to foward this to python-list to see if any lurking
mathematicians might be spurred to action?

Trent

-- 
Trent Mick
trentm at activestate.com



From gward at python.net  Fri Jun 30 05:53:34 2000
From: gward at python.net (Greg Ward)
Date: Thu, 29 Jun 2000 23:53:34 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 11:33:45PM -0400
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
Message-ID: <20000629235334.B1294@beelzebub>

On 29 June 2000, Fred L. Drake, Jr. said:
>   I didn't know it ever returned linux-i386; perhaps you're thinking
> of Marc-Andre's platform module?

D'ohh!  That appears to be an artifact of Red Hat's build -- I was using
/usr/bin/python (theirs), not /usr/local/bin/python (mine).

  $ /usr/bin/python
  Python 1.5.2 (#1, Feb  1 2000, 16:32:16)  [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> sys.platform
  'linux-i386'

Sorry for getting alarmist.  Guess I never should have started using
sys.platform in the first place (or just not worry about getting the CPU
in there too).

        Greg
-- 
Greg Ward - geek                                        gward at python.net
http://starship.python.net/~gward/
Support bacteria -- it's the only culture some people have!



From skip at mojam.com  Fri Jun 30 04:57:47 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 21:57:47 -0500 (CDT)
Subject: [Python-Dev] available to look at bugs and patches...
Message-ID: <14684.3243.480545.880199@beluga.mojam.com>

Barry added me as a developer yesterday.  Those people assigning bugs and
patches can use me as a resource...

Skip



From gward at python.net  Fri Jun 30 06:26:20 2000
From: gward at python.net (Greg Ward)
Date: Fri, 30 Jun 2000 00:26:20 -0400
Subject: [Python-Dev] ANNOUNCE: Distutils 0.9
Message-ID: <20000630002620.A2329@beelzebub>

                     Python Distribution Utilities
                              release 0.9
                             June 29, 2000

The Python Distribution Utilities, or Distutils for short, are a
collection of modules that aid in the development, distribution, and
installation of Python modules.  (It is intended that ultimately the
Distutils will grow up into a system for distributing and installing
whole Python applications, but for now their scope is limited to module
distributions.)

The Distutils are a standard part of Python 2.0; if you are running 2.0
(or one of the 1.6 alpha releases that preceded it), you don't need to
install the Distutils separately.  This release is primarily so that you
can add the Distutils to a Python 1.5.2 installation -- you will then be
able to install modules that require the Distutils, or use the Distutils
to distribute your own modules.

More information is available at the Distutils web page:

    http://www.python.org/sigs/distutils-sig/

and in the README.txt included in the Distutils source distribution.

You can download the Distutils from

    http://www.python.org/sigs/distutils-sig/download.html

Trivial patches can be sent to me (Greg Ward) at gward at python.net.
Larger patches should be discussed on the Distutils mailing list:
distutils-sig at python.org.



From tim_one at email.msn.com  Fri Jun 30 07:05:32 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 01:05:32 -0400
Subject: [Python-Dev] Controversial patch (cmath)
In-Reply-To: <20000629203417.B23077@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEFLGHAA.tim_one@email.msn.com>

[Trent Mick]

> [Tim discusses god awful math details]
> Would you want to foward this to python-list to see if any lurking
> mathematicians might be spurred to action?

God, please no!  This requires a numerical analyst, not a mathematician.
Voting by talented amateurs is only going to make things worse <0.5 wink>.
I was an NA in a previous life, and know what needs to be done to resolve
all this.  But that takes way more time than we have before 2.0b1.  The
patch in question makes life better for the world's only known user of cmath
<ahem>.

may-as-well-ask-c.l.py-to-discuss-python's-version-number<wink>-ly
    y'rs  - tim





From jeremy at beopen.com  Fri Jun 30 07:08:30 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 01:08:30 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include objimpl.h,2.16,2.17
In-Reply-To: <200006300502.WAA03256@slayer.i.sourceforge.net>
References: <200006300502.WAA03256@slayer.i.sourceforge.net>
Message-ID: <14684.11086.47325.776691@bitdiddle.concentric.net>

These patches should catch up with Neil's latest submissions, but may
not have the very latest changes suggested by Neil and Vladimir.  I
will double-check with them in the morning.  I will also change
configure.in to enable GC by default for the beta test phase, unless
there is strong objection.

Jeremy



From skip at mojam.com  Fri Jun 30 06:00:29 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 29 Jun 2000 23:00:29 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1
In-Reply-To: <200006300502.WAA03286@slayer.i.sourceforge.net>
References: <200006300502.WAA03286@slayer.i.sourceforge.net>
Message-ID: <14684.7005.661874.713000@beluga.mojam.com>

    Jeremy> Log Message:
    Jeremy> final patches from Neil Schemenauer for garbage collection

    Jeremy> --- NEW FILE ---
    Jeremy> test_gc
    Jeremy> list 0x831a754
    Jeremy> dict 0x831a754
    ...
    Jeremy> dict 0x831a9bc
    Jeremy> func 0x831d9e4

I can all but guarantee you this test will always fail.  Printing absolute
machine addresses (via calls to id() in this case) in test cases should be
verboten.

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From trentm at activestate.com  Fri Jun 30 08:05:50 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 23:05:50 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7
In-Reply-To: <200006300502.WAA03275@slayer.i.sourceforge.net>
References: <200006300502.WAA03275@slayer.i.sourceforge.net>
Message-ID: <20000629230550.A24811@activestate.com>

On Thu, Jun 29, 2000 at 10:02:55PM -0700, Jeremy Hylton wrote:
> Update of /cvsroot/python/python/dist/src/PCbuild
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv3220/PCbuild
> 
> Modified Files:
> 	python16.dsp 
> Log Message:
> final patches from Neil Schemenauer for garbage collection
> 
> 
> Index: python16.dsp
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/PCbuild/python16.dsp,v
> retrieving revision 1.6
> retrieving revision 1.7
> diff -C2 -r1.6 -r1.7
> *** python16.dsp	2000/06/06 23:29:09	1.6
> --- python16.dsp	2000/06/30 05:02:53	1.7
> ***************
> *** 660,663 ****
> --- 660,677 ----
>   # End Source File
>   # Begin Source File
> + SOURCE=..\Modules\gcmodule.c
> + 
> + !IF  "$(CFG)" == "python16 - Win32 Release"
> + 
> + !ELSEIF  "$(CFG)" == "python16 - Win32 Debug"
> + 
> + !ELSEIF  "$(CFG)" == "python16 - Win32 Alpha Debug"
> + 
> + !ELSEIF  "$(CFG)" == "python16 - Win32 Alpha Release"
> + 
> + !ENDIF 
> + 
> + # End Source File
> + # Begin Source File
>   
>   SOURCE=..\Python\getargs.c
> 

Pardon me if I am wrong (I have not actually checked the repository) but is
this correct now that the version number is 2.0?

Trent


-- 
Trent Mick
trentm at activestate.com



From trentm at activestate.com  Fri Jun 30 08:27:33 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 23:27:33 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <200006300608.XAA13124@slayer.i.sourceforge.net>
References: <200006300608.XAA13124@slayer.i.sourceforge.net>
Message-ID: <20000629232733.D24811@activestate.com>

Cool

On Thu, Jun 29, 2000 at 11:08:38PM -0700, Skip Montanaro wrote:
> 
> --- NEW FILE ---
> 			 Writing Python Test Cases
> 			 -------------------------
> 			       Skip Montanaro
> 
> 
> To run the entire test suite, make the "test" target at the top level:
> 
>     cd ...
>     make test

This is a UN*Xism, on Windows and UN*X:
cd ...\Lib\test
python regrtest.py



A sample walk through to create a test might make it more approachable for
people. As well, it would be helpful to mention
test_support.{verbose|TESTFN|...}.  But I have no right to bitch about good
work.


Trent



-- 
Trent Mick
trentm at activestate.com



From tim_one at email.msn.com  Fri Jun 30 08:39:15 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 02:39:15 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <20000629232733.D24811@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com>

[Trent Mick]
> ...
> But I have no right to bitch about good work.

How do you figure that?  We do it to you enough <wink>.

BTW, I'd just like to say what a delight it is to work with *all* of you
folks!  I wanted to say that before I can be accused of pimping for my
employer -- so far, BeOpen hasn't paid me a dime, so you know my opinion
hasn't yet been bought.

well-maybe-on-credit<wink>-ly y'rs  - tim





From tim_one at email.msn.com  Fri Jun 30 08:39:12 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 02:39:12 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7
In-Reply-To: <20000629230550.A24811@activestate.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEFPGHAA.tim_one@email.msn.com>

[Trent Mick, on Guido's late-night (for him <wink>) checkin of
 python16.dsp]

> Pardon me if I am wrong (I have not actually checked the
> repository) but is this correct now that the version number is 2.0?

No, it is not, and the Windows build is slightly damaged now.  I've already
yelled at Guido about this, but I suspect he's asleep.  I'm sure it will get
sorted out in the morning.





From trentm at activestate.com  Fri Jun 30 08:52:47 2000
From: trentm at activestate.com (Trent Mick)
Date: Thu, 29 Jun 2000 23:52:47 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com>
References: <20000629232733.D24811@activestate.com> <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com>
Message-ID: <20000629235247.A25090@activestate.com>

On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote:
> BTW, I'd just like to say what a delight it is to work with *all* of you
> folks!

I feel a group hug coming on in the morning. Or maybe I am just moved by the
beer that I had for dinner. :) Likewise, Tim. As my first foray into
community development I find this, Python dev, a refreshing pleasure.

Trent

-- 
Trent Mick
trentm at activestate.com



From tim_one at email.msn.com  Fri Jun 30 09:41:28 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 03:41:28 -0400
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEGBGHAA.tim_one@email.msn.com>

[Tim]
> ... "Group whiteboards" and shared journals etc are darned
> useful, though.

[Ken Manheimer]
> Wiki = Group whiteboard

Ya, I kind of picked that up from your last passionate advertisement for
this stuff <wink>.  Not knocking it!  Never tried it.  Believe it or not, I
spend as little time on the web as possible.  After I've gotten into a place
to live here, and this current release crunch is behind us, I'm definitely
going to check out your leads.

For the past several years my development group worked thru Lotus Notes,
which I didn't much care for at the time, but I'm increasingly realizing
just how essential group-modifiable shared persistent documents were to our
productivity.  Notes is the purest example of a whole being greater than the
sum of its parts I've ever seen (lousy mail system, lousy database, lousy
change manager, lousy bug tracker, lousy workflow manager, worse than lousy
native scripting ... but they all sucked in ways that were downright
synergistic <0.9 wink>).

> ...
> Anyway, to see leads on both zwikis and tracker, see:
>
>   http://www.zope.org/Members/klm/TrackerWiki

can-beopen-zwiki-2.0-be-far-behind<wink>?-ly y'rs  - tim





From pingster at ilm.com  Fri Jun 30 10:21:08 2000
From: pingster at ilm.com (Ka-Ping Yee)
Date: Fri, 30 Jun 2000 01:21:08 -0700 (PDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <200006292338.BAA07798@python.inrialpes.fr>
Message-ID: <Pine.SGI.3.96.1000630010709.621134O-100000@happy>

Guido van Rossum wrote:
> let this be an advance warning that it will be called Python 2.0.

On Fri, 30 Jun 2000, Vladimir Marangozov wrote:
> Guido van Rossum just won't stop surprising us! :-)

Will many be spooked by the jump in version number into fearing
incompatibility with older scripts...?

I wonder if we'll end up trying to persuade the user community that
the changes are small ("no, don't worry, your scripts will still
work") and yet big ("honest, it really deserves to be called 2.0,
it's not just a ploy") at the same time.

Perl 5 was basically incompatible with Perl 4.  Some things run,
but a lot don't.  (Actually many microversions of Perl 5 were
mutually incompatible with each other, but i'll ignore that. :) )

I've thought of the jump to Python3k (lowercase "k", please) much
like the Perl-4-to-Perl-5 jump: simple stuff is still okay but a lot
of guts have changed.  If i hadn't been "on the inside" watching
development activity, i might expect something of similar magnitude
upon hearing of going from Python 1.x to 2.0.

I guess we can point at Unicode and SRE as big things.


-- ?!ng




From effbot at telia.com  Fri Jun 30 10:33:10 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 10:33:10 +0200
Subject: [Python-Dev] SRE status report
Message-ID: <005001bfe26d$d3dc3540$f2a6b5d4@hagrid>

just checked in a test script for sre.  the test_sre file is a
copy of test_re, with some minor changes:

-- disabled one test (caused by bug #8; see below)

-- added T (template mode, experimental, unsupported)
   and U (unicode locale) flags to the flag test

-- removed keyword arguments in pattern test loop:

    result = obj.search(s, pos=result.start(0), endpos=result.end(0)+1)

was changed to:

    result = obj.search(s, result.start(0), result.end(0)+1)

as far as I can tell, the docs don't mention anything about keyword
arguments...

-- added unicode pattern / target string / locale tests to
   the pattern test loop.

however, the current version SRE doesn't fully pass the test.
here's an annotated version of Lib/test/output/test_sre:

1) test_support -- test failed re module pickle
2) test_support -- test failed re module cPickle

under SRE, patterns are C objects, not class instances.
to allow pickling, I need to modify copy_reg (either by
modifing the file itself, or by updating the registry when
SRE is first imported).  see patch #100650 for more info,

3) === Syntax error: ('(?P<foo_123>a)(?P=foo_123)', 'aa', 0, 'g1', 'a')

this is a bug in the SRE parser.  should be easy to fix.

4) === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A')

this is a bug in the engine (nested repetitions). needs
further research.

5) === Failed incorrectly ('(a+)+\\1', 'aa', 0, 'found+"-"+g1', 'aa-a')

this is a bug in the engine or in the parser.  needs further
research.

6) === grouping error ('([^/]*/)*sub1/', 'd:msgs/tdir/sub1/trial/away.cpp', 0, 'found+"-"+g1', 'd:msgs/tdir/sub1/-tdir/') 'd:msgs/tdir/sub1/-trial/' should be 'd:msgs/tdir/sub1/-tdir/'

same as #5.

7) === Syntax error: ('(?P<id>aa)(?P=id)', 'aaaa', 0, 'found+"-"+id', 'aaaa-aa')

same as #3.

8) === grouping error ('([abc])*bcd', 'abcd', 0, 'found+"-"+g1', 'abcd-a') 'abcd-c' should be 'abcd-a'

this is a bug in the engine.  should be easy to fix, I think.
in fact, I could have sworn that I'd fixed it already.

9) === grouping error ('(?i)([abc])*bcd', 'ABCD', 0, 'found+"-"+g1', 'ABCD-A') 'ABCD-C' should be 'ABCD-A'

same as #8

10) === Syntax error: ('a(?!b).', 'abad', 0, 'found', 'ad')

this is bug in the parser.  should be easy to fix.

11) === Syntax error: ('a(?=d).', 'abad', 0, 'found', 'ad')

same as (or at least related to) #10

12) === Syntax error: ('a(?=c|d).', 'abad', 0, 'found', 'ad')

same as #11

13) === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A')

same as #4 (literally!).

...

fwiw, *all* RE-based code I've played with seem to
work.  ymmv.  let me know asap if it does.

</F>




From mhammond at skippinet.com.au  Fri Jun 30 10:41:44 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 18:41:44 +1000
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <Pine.SGI.3.96.1000630010709.621134O-100000@happy>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>

> Will many be spooked by the jump in version number into fearing
> incompatibility with older scripts...?
>
> I wonder if we'll end up trying to persuade the user community that
> the changes are small ("no, don't worry, your scripts will still
> work") and yet big ("honest, it really deserves to be called 2.0,
> it's not just a ploy") at the same time.

I see your concerns, but I think the trick is to be honest, just as Guido
was.  We simply say it was bumped to V2 for the reasons of percieved
maturity, and a clear break from CNRI Python.

Both seem reasonable.  I believe many people will simply wait for some form
of consensus on the newsgroup, regardless of the version number.

Personally, Im a little - umm - lets just say that I can see the irony in
the fact that I recently changed a few bits of code that were dependent on
a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x
family.  I figured there was no point trying to predict the packaging
details of the 2.x family, seeing it as still some time off.  Nothing like
foresight :-)

And-"foresight"-isnt-an-excuse-for-Tim-to-get-back-on-the-topic-of-his-geni
tals-<wink>-ly,

Mark.




From effbot at telia.com  Fri Jun 30 10:55:01 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 10:55:01 +0200
Subject: [Python-Dev] New PythonLabs site revealed!
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>
Message-ID: <005801bfe270$e140d440$f2a6b5d4@hagrid>

mark wrote:
> Personally, Im a little - umm - lets just say that I can see the irony in
> the fact that I recently changed a few bits of code that were dependent on
> a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x
> family.

heh.  you're not the only one...

btw, now that we're bumping to 2.0, maybe we can break
socket.connect and friends once again?  if somebody com-
plains, just tell them "it's a major release, dammit" ;-)

</F>




From gstein at lyra.org  Fri Jun 30 10:59:56 2000
From: gstein at lyra.org (Greg Stein)
Date: Fri, 30 Jun 2000 01:59:56 -0700
Subject: [Python-Dev] CVS locks on SF
In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500
References: <LNBBLJKPBEHFEDALKOLCIEDNGHAA.tim_one@email.msn.com> <200006291905.OAA17265@cj20424-a.reston1.va.home.com>
Message-ID: <20000630015956.S29590@lyra.org>

On Thu, Jun 29, 2000 at 02:05:11PM -0500, Guido van Rossum wrote:
>...
> > Note that Perl is maintained under (the commercial, alas) Perforce, which is
> > one of the few SCMs to take multi-developer multi-directory issues
> > seriously.
> 
> We tried Perforce at CNRI.  It's really neat, but somehow it was
> lacking some stuff we were used to and we never converted.
> 
> Note that Perforce is free for open source projects -- at least at the
> time it was.  (CNRI paid a license fee, but that was just an
> expression of CNRI's reluctance against free software. :-)
> 
> There's also bitkeeper.  It stayed in beta so long that we gave up
> (and they have a weird license) -- but it's out of beta since May 4:
> see http://www.bitkeeper.com/.  But there's no immediate download!
> You must sign up and they send you instructions in the mail...

And coming down the pipe (end of the year) is Subversion:

    http://subversion.tigris.org/

Cheers,
-g

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



From mhammond at skippinet.com.au  Fri Jun 30 11:23:53 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 19:23:53 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6
In-Reply-To: <200006300904.CAA04151@slayer.i.sourceforge.net>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEBACPAA.mhammond@skippinet.com.au>

> Making a tiny change to figure out what I'm going to screw up
> by trying to use CVS under Windows at all ...

Congratulations :-)

Mark.




From mhammond at skippinet.com.au  Fri Jun 30 11:25:39 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Jun 2000 19:25:39 +1000
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBGEBACPAA.mhammond@skippinet.com.au>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEBACPAA.mhammond@skippinet.com.au>

> To: python-dev at python.org

Damn damn damn - did it again.  Sorry.

[I wishing mailing-lists would agree on how they handle reply-to :-]

Mark.



From mal at lemburg.com  Fri Jun 30 11:27:57 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 11:27:57 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
Message-ID: <395C681D.C3211F6@lemburg.com>

"Fred L. Drake, Jr." wrote:
> 
> Greg Ward writes:
>  > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this
>  > morning) returns "linux2" on my PC, not "linux-i386".  As I recall this
> 
>   I didn't know it ever returned linux-i386; perhaps you're thinking
> of Marc-Andre's platform module?

Python has returned 'linux2' on my machine ever since I moved
to a 2.x kernel -- why should it return 'linux-i386' (without
any indication of version) ?

As Fred mentioned, you should probably use platform.py to
access the information you have in mind. It supports loads
of different architectures and has pretty much all the
information you need for distutils warpped in nice APIs.

Why not simply include it in distutils ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Fri Jun 30 12:04:00 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 12:04:00 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2
References: <200006300953.CAA14782@slayer.i.sourceforge.net>
Message-ID: <00b001bfe27a$845f7880$f2a6b5d4@hagrid>

MAL wrote:
>     out.write(header)
>     out = open(cFileName, "w")
> !   out.write("#include "%s"\n" % headerFileName)
>     out.write(code)
>     perfHash.generate_graph(out)

umm.  I suppose you meant:

> !   out.write('#include "%s"\n' % headerFileName)

or possibly:

> !   out.write("#include \"%s\"\n" % headerFileName)

</F>




From mal at lemburg.com  Fri Jun 30 12:15:23 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 12:15:23 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: 
 python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2
References: <200006300953.CAA14782@slayer.i.sourceforge.net> <00b001bfe27a$845f7880$f2a6b5d4@hagrid>
Message-ID: <395C733B.4E2AFFA3@lemburg.com>

Fredrik Lundh wrote:
> 
> MAL wrote:
> >     out.write(header)
> >     out = open(cFileName, "w")
> > !   out.write("#include "%s"\n" % headerFileName)
> >     out.write(code)
> >     perfHash.generate_graph(out)
> 
> umm.  I suppose you meant:
> 
> > !   out.write('#include "%s"\n' % headerFileName)
> 
> or possibly:
> 
> > !   out.write("#include \"%s\"\n" % headerFileName)

Oops, you're right.

Thanks.
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Fri Jun 30 15:20:23 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:20:23 -0400 (EDT)
Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE())
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMEGBGHAA.tim_one@email.msn.com>
References: <Pine.LNX.4.21.0006291640180.4495-100000@korak.digicool.com>
	<LNBBLJKPBEHFEDALKOLCMEGBGHAA.tim_one@email.msn.com>
Message-ID: <14684.40599.135974.497497@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > productivity.  Notes is the purest example of a whole being greater than the
 > sum of its parts I've ever seen (lousy mail system, lousy database, lousy
 > change manager, lousy bug tracker, lousy workflow manager, worse than lousy
 > native scripting ... but they all sucked in ways that were downright
 > synergistic <0.9 wink>).

  I had to use Notes before working at CNRI, and wouldn't have
described all those sucky components as "synergistic".  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Fri Jun 30 15:26:15 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:26:15 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <Pine.SGI.3.96.1000630010709.621134O-100000@happy>
References: <200006292338.BAA07798@python.inrialpes.fr>
	<Pine.SGI.3.96.1000630010709.621134O-100000@happy>
Message-ID: <14684.40951.644965.274278@cj42289-a.reston1.va.home.com>

Ka-Ping Yee writes:
 > Will many be spooked by the jump in version number into fearing
 > incompatibility with older scripts...?
 > 
 > I wonder if we'll end up trying to persuade the user community that
 > the changes are small ("no, don't worry, your scripts will still
 > work") and yet big ("honest, it really deserves to be called 2.0,
 > it's not just a ploy") at the same time.

Ping,
  Haven't we heard our users complain about the conservative version
numbering a lot?  Pushing to 2.0 allows us to make the next release
2.1, which neither the "never 1.x!" crowd nor the "never x.0!" will
worry about.  Sounds like a good move to me!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Fri Jun 30 15:28:15 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:28:15 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <005801bfe270$e140d440$f2a6b5d4@hagrid>
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>
	<005801bfe270$e140d440$f2a6b5d4@hagrid>
Message-ID: <14684.41071.958061.743836@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > btw, now that we're bumping to 2.0, maybe we can break
 > socket.connect and friends once again?  if somebody com-
 > plains, just tell them "it's a major release, dammit" ;-)

  If by "break" you mean "tightly conform to the documentation", I'm
all for it!  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Fri Jun 30 15:32:24 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 09:32:24 -0400 (EDT)
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <395C681D.C3211F6@lemburg.com>
References: <20000629233003.A1766@beelzebub>
	<14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
	<395C681D.C3211F6@lemburg.com>
Message-ID: <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>

Regarding platform.py:

M.-A. Lemburg writes:
 > Why not simply include it in distutils ?

  Why not include it in the standard library?
  Guido?  I'll document it if Marc-Andre is willing to provide the
module and the regression test.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Fri Jun 30 15:40:36 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 15:40:36 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub>
		<14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
		<395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>
Message-ID: <395CA354.16AC5B7E@lemburg.com>

"Fred L. Drake, Jr." wrote:
> 
> Regarding platform.py:
> 
> M.-A. Lemburg writes:
>  > Why not simply include it in distutils ?
> 
>   Why not include it in the standard library?
>   Guido?  I'll document it if Marc-Andre is willing to provide the
> module and the regression test.

No objection from here.

I've attached my most recent copy to this mail. I'm not sure
how to write the regr. test though since output is dependent
on the platform running the functions... perhaps I'll just
add something like the audio thingie: "This string ought
to identify the platform you are currently running... if not,
then something is wrong ;-)".

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bwarsaw at beopen.com  Fri Jun 30 15:42:19 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 09:42:19 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules gcmodule.c,NONE,2.1 Setup.thread.in,2.2,2.3 cPickle.c,2.43,2.44 newmodule.c,2.20,2.21
References: <200006300502.WAA03262@slayer.i.sourceforge.net>
Message-ID: <14684.41915.59835.325026@anthem.concentric.net>

So, Setup.thread.in isn't used just for threads anymore.  Perhaps it
should be renamed?  At the very least, a comment should be added to
the top that this file is for configure enabled modules.

-Barry

Index: Setup.thread.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/Setup.thread.in,v
retrieving revision 2.2
retrieving revision 2.3
diff -C2 -r2.2 -r2.3
*** Setup.thread.in	2000/06/29 16:08:28	2.2
--- Setup.thread.in	2000/06/30 05:02:53	2.3
***************
*** 11,12 ****
--- 11,15 ----
  
  @USE_THREAD_MODULE at thread threadmodule.c
+ 
+ # Garbage collection enabled with --with-cycle-gc
+ @USE_GC_MODULE at gc gcmodule.c



From mal at lemburg.com  Fri Jun 30 15:42:06 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 15:42:06 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub>
			<14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
			<395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com>
Message-ID: <395CA3AE.8A5800F1@lemburg.com>

Ooops, forgot the attachement...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: platform.py
Type: text/python
Size: 36884 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20000630/2c97c250/attachment-0001.bin>

From guido at python.org  Fri Jun 30 16:47:29 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 09:47:29 -0500
Subject: [Python-Dev] Removing modules
In-Reply-To: Your message of "Thu, 29 Jun 2000 21:29:41 -0400."
             <20000629212941.A21563@newcnri.cnri.reston.va.us> 
References: <20000629212941.A21563@newcnri.cnri.reston.va.us> 
Message-ID: <200006301447.JAA30671@cj20424-a.reston1.va.home.com>

> For the "deleted modules" section of the 2.0 article, I drew up a list
> of modules that might be outdated, mostly the SGI-specific ones.  Are
> those modules still useful, and do the libraries they were written for
> still exist?

Doubtful.  I've asked Sjoerd and Jack, who were most involved in using
these.

> For your cogitation, here's the list: sgimodule.c, glmodule.c (and
> hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c,
> almodule.c, clmodule.c,  knee.py.

I'd like to keep knee.py -- it's a nice piece of *documentation* of
the package import.

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



From guido at python.org  Fri Jun 30 16:55:08 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 09:55:08 -0500
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: Your message of "Fri, 30 Jun 2000 15:40:36 +0200."
             <395CA354.16AC5B7E@lemburg.com> 
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>  
            <395CA354.16AC5B7E@lemburg.com> 
Message-ID: <200006301455.JAA30721@cj20424-a.reston1.va.home.com>

> > Regarding platform.py:
> > 
> > M.-A. Lemburg writes:
> >  > Why not simply include it in distutils ?
> > 
> >   Why not include it in the standard library?
> >   Guido?  I'll document it if Marc-Andre is willing to provide the
> > module and the regression test.
> 
> No objection from here.
> 
> I've attached my most recent copy to this mail. I'm not sure
> how to write the regr. test though since output is dependent
> on the platform running the functions... perhaps I'll just
> add something like the audio thingie: "This string ought
> to identify the platform you are currently running... if not,
> then something is wrong ;-)".

You didn't include it!

But I vote -1 on this one anyway -- it's too much code and almost by
its very nature not something that belongs in a "standard" library.
Plus, I don't want to be responsible for maintaining it.  Sorry,

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



From bwarsaw at beopen.com  Fri Jun 30 15:57:47 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 09:57:47 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au>
	<005801bfe270$e140d440$f2a6b5d4@hagrid>
Message-ID: <14684.42843.472230.609828@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <effbot at telia.com> writes:

    FL> btw, now that we're bumping to 2.0, maybe we can break
    FL> socket.connect and friends once again?  if somebody com-
    FL> plains, just tell them "it's a major release, dammit" ;-)

That's a good point.  A bump in major rev number is an /opportunity/
to break things, like a bone that hasn't healed right, so that they
can be fixed correctly.  We'll lose that for 2.0, mostly likely
because of the tight release schedule.  There's always 3.0 though,
which will mesh nicely with the mythical Py3k.

-Barry



From effbot at telia.com  Fri Jun 30 16:08:13 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 16:08:13 +0200
Subject: [Python-Dev] New PythonLabs site revealed!
References: <ECEPKNMJLHAPFFJHDOJBIEANCPAA.mhammond@skippinet.com.au><005801bfe270$e140d440$f2a6b5d4@hagrid> <14684.42843.472230.609828@anthem.concentric.net>
Message-ID: <016e01bfe29c$a2e8bb00$f2a6b5d4@hagrid>

barry wrote:
> >>>>> "FL" == Fredrik Lundh <effbot at telia.com> writes:
> 
>     FL> btw, now that we're bumping to 2.0, maybe we can break
>     FL> socket.connect and friends once again?  if somebody com-
>     FL> plains, just tell them "it's a major release, dammit" ;-)
> 
> That's a good point.  A bump in major rev number is an /opportunity/
> to break things, like a bone that hasn't healed right, so that they
> can be fixed correctly.  We'll lose that for 2.0, mostly likely
> because of the tight release schedule.

yeah, but I'm sure Guido has the patches somewhere (after
all, the 1.6 release notes still mention this change).  if not,
the mad patcher volunteers to fix (or rather, break) this.

Guido?

</F>




From bwarsaw at beopen.com  Fri Jun 30 16:07:47 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 10:07:47 -0400 (EDT)
Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6
References: <ECEPKNMJLHAPFFJHDOJBGEBACPAA.mhammond@skippinet.com.au>
	<ECEPKNMJLHAPFFJHDOJBMEBACPAA.mhammond@skippinet.com.au>
Message-ID: <14684.43443.919858.897738@anthem.concentric.net>

>>>>> "MH" == Mark Hammond <mhammond at skippinet.com.au> writes:

    MH> [I wishing mailing-lists would agree on how they handle
    MH> reply-to :-]

It's fundamentally broken, but the problem is in the mail readers
(MUA).  There's no header (that I'm aware of) that portably tells an
MUA - "Hey, for a group follow up, don't go to the original list, go
to THIS one instead, but for an individual followup (i.e. reply) still
address that to the original author."

This is one reason why munging reply-to is evil.  But in this case
we've agreed that following up to python-dev is more important than
preserving the ability to reply to the author.

-Barry



From mal at lemburg.com  Fri Jun 30 16:11:54 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 16:11:54 +0200
Subject: [Python-Dev] Hey! who changed sys.platform?!
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com>  
	            <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com>
Message-ID: <395CAAAA.5975A617@lemburg.com>

Guido van Rossum wrote:
> 
> > > Regarding platform.py:
> > >
> > > M.-A. Lemburg writes:
> > >  > Why not simply include it in distutils ?
> > >
> > >   Why not include it in the standard library?
> > >   Guido?  I'll document it if Marc-Andre is willing to provide the
> > > module and the regression test.
> >
> > No objection from here.
> >
> > I've attached my most recent copy to this mail. I'm not sure
> > how to write the regr. test though since output is dependent
> > on the platform running the functions... perhaps I'll just
> > add something like the audio thingie: "This string ought
> > to identify the platform you are currently running... if not,
> > then something is wrong ;-)".
> 
> You didn't include it!

I posted a reply to fix this ;-)
 
> But I vote -1 on this one anyway -- it's too much code and almost by
> its very nature not something that belongs in a "standard" library.
> Plus, I don't want to be responsible for maintaining it.  Sorry,

You don't have to maintain it... I will anyway since it's part
of mxCGIPython.

Anyway, perhaps Greg Ward can find some use for it in
distutils.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From effbot at telia.com  Fri Jun 30 16:18:13 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 16:18:13 +0200
Subject: [Python-Dev] SRE incompatibility
Message-ID: <018401bfe29e$07f26720$f2a6b5d4@hagrid>

my latest changes fixed a couple of things, but broke
one of the old RE tests, namely:

    re.match('\\x00ffffffffffffff', '\377') != None

or in other words, long hexadecimal escapes are cast
down to 8-bit characters in RE.

in SRE (after the latest change), they're cast down to
the size of the engine's internal word size (currently 16
bits).

is the old behaviour worth keeping?  I'd rather not make
the engine dependent on string types; it shouldn't really
matter if you're using unicode patterns on 8-bit target
strings, or vice versa.

</F>




From gward at mems-exchange.org  Fri Jun 30 16:13:40 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Fri, 30 Jun 2000 10:13:40 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 07:29:42PM -0400
References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>
Message-ID: <20000630101340.A16350@ludwig.cnri.reston.va.us>

On 29 June 2000, Fred L. Drake, Jr. said:
> 
> Greg Ward wrote in a checkin message:
>  > On second thought, first try for _winreg, and then winreg.  Only if both
>  > fail do we try for win32api/win32con.  If *those* both fail, then we don't
>  > have registry access.  Phew!
> 
> Guido van Rossum writes on python-dev:
>  > Is this smart?  Doesn't the new winreg have a very different I/F than
>  > the old one?
> 
>   No, this is bad.  It *will* break with winreg; if _winreg isn't
> available, it should use the win32api/win32con/whatever stuff; it's a
> Python 1.5.2 interpreter at that point.

What if it's a 1.6a1 or 1.6a2 interpreter?  Presumably people will try
Distutils 0.9 with them.  Should I remove that feature now that 0.9 is
out, but before Python 2.0b1?

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From esr at thyrsus.com  Fri Jun 30 16:27:07 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 30 Jun 2000 10:27:07 -0400
Subject: [Python-Dev] Removing modules
In-Reply-To: <200006301447.JAA30671@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 09:47:29AM -0500
References: <20000629212941.A21563@newcnri.cnri.reston.va.us> <200006301447.JAA30671@cj20424-a.reston1.va.home.com>
Message-ID: <20000630102707.A27830@thyrsus.com>

Guido van Rossum <guido at python.org>:
> > For the "deleted modules" section of the 2.0 article, I drew up a list
> > of modules that might be outdated, mostly the SGI-specific ones.  Are
> > those modules still useful, and do the libraries they were written for
> > still exist?
> 
> Doubtful.  I've asked Sjoerd and Jack, who were most involved in using
> these.
> 
> > For your cogitation, here's the list: sgimodule.c, glmodule.c (and
> > hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c,
> > almodule.c, clmodule.c,  knee.py.
> 
> I'd like to keep knee.py -- it's a nice piece of *documentation* of
> the package import.

+1 on giving the SGI-specific modules the heave-ho.  

Their presence has always struck me as a sort of vermiform appendix in
a core library otherwise clearly aimed at being as platform-independent
as rdeasonably possible (e.g. given the Unix-vs.Windows differences).
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Power concedes nothing without a demand. It never did, and it never will.
Find out just what people will submit to, and you have found out the exact
amount of injustice and wrong which will be imposed upon them; and these will
continue until they are resisted with either words or blows, or with both.
The limits of tyrants are prescribed by the endurance of those whom they
oppress.
	-- Frederick Douglass, August 4, 1857



From gward at mems-exchange.org  Fri Jun 30 16:22:42 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Fri, 30 Jun 2000 10:22:42 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <395CAAAA.5975A617@lemburg.com>; from mal@lemburg.com on Fri, Jun 30, 2000 at 04:11:54PM +0200
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com>
Message-ID: <20000630102242.B16350@ludwig.cnri.reston.va.us>

On 30 June 2000, M.-A. Lemburg said:
> > But I vote -1 on this one anyway -- it's too much code and almost by
> > its very nature not something that belongs in a "standard" library.
> > Plus, I don't want to be responsible for maintaining it.  Sorry,
> 
> You don't have to maintain it... I will anyway since it's part
> of mxCGIPython.
> 
> Anyway, perhaps Greg Ward can find some use for it in
> distutils.

I looked at platform.py once briefly, and my impression was similar to
Guido's: too big!  All I want(ed) is "osname-cpu" -- linux-i386,
solaris-sparc, whatever.  osversion is optional.

But, consider that that the Distutils might want to know if it should
generate RPMs or Debian packages... then the stuff about grokking which
Linux distribution it's running on is relevant.  Argh!

Anyways, I'm already taking static about too much code in the Distutils,
and I partly agree.  (I agree there's a *lot* of code, I know there are
bits that can be refactored and reduced, but I'm not sure it's too
much.)  So I'll stick with sys.platform for now -- it's good enough.

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From sjoerd at oratrix.nl  Fri Jun 30 16:21:53 2000
From: sjoerd at oratrix.nl (Sjoerd Mullender)
Date: Fri, 30 Jun 2000 16:21:53 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32
In-Reply-To: Your message of Fri, 30 Jun 2000 03:29:59 -0700.
             <200006301029.DAA25494@slayer.i.sourceforge.net> 
References: <200006301029.DAA25494@slayer.i.sourceforge.net> 
Message-ID: <20000630142154.968F831047C@bireme.oratrix.nl>

Why was the change that occurred in revision 2.31 reverted?  Accident?

The change log said:
Jack Jansen: Use include "" instead of <>; and staticforward declarations

On Fri, Jun 30 2000 "M.-A. Lemburg" wrote:

> Update of /cvsroot/python/python/dist/src/Objects
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv25442/Objects
> 
> Modified Files:
> 	unicodeobject.c 
> Log Message:
> Marc-Andre Lemburg <mal at lemburg.com>:
> New buffer overflow checks for formatting strings.
> 
> By Trent Mick.
> 
> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.31
> retrieving revision 2.32
> diff -C2 -r2.31 -r2.32
> *** unicodeobject.c	2000/06/29 00:06:39	2.31
> --- unicodeobject.c	2000/06/30 10:29:57	2.32
> ***************
> *** 67,71 ****
>   #include "mymath.h"
>   #include "unicodeobject.h"
> ! #include "ucnhash.h"
>   
>   #if defined(HAVE_LIMITS_H)
> --- 67,71 ----
>   #include "mymath.h"
>   #include "unicodeobject.h"
> ! #include <ucnhash.h>
>   
>   #if defined(HAVE_LIMITS_H)
> ***************
> *** 1245,1249 ****
>   ucnFallthrough:
>               /* fall through on purpose */
> !         default:
>               *p++ = '\\';
>               *p++ = (unsigned char)s[-1];
> --- 1245,1249 ----
>   ucnFallthrough:
>               /* fall through on purpose */
> ! 		default:
>               *p++ = '\\';
>               *p++ = (unsigned char)s[-1];
> ***************
> *** 1252,1256 ****
>       }
>       if (_PyUnicode_Resize(v, (int)(p - buf)))
> ! 	goto onError;
>       return (PyObject *)v;
>       
> --- 1252,1256 ----
>       }
>       if (_PyUnicode_Resize(v, (int)(p - buf)))
> ! 		goto onError;
>       return (PyObject *)v;
>       
> ***************
> *** 4374,4377 ****
> --- 4374,4378 ----
>   static int
>   formatfloat(Py_UNICODE *buf,
> + 	    size_t buflen,
>   	    int flags,
>   	    int prec,
> ***************
> *** 4379,4382 ****
> --- 4380,4385 ----
>   	    PyObject *v)
>   {
> +     /* fmt = '%#.' + `prec` + `type`
> +        worst case length = 3 + 10 (len of INT_MAX) + 1 = 14 (use 20)*/
>       char fmt[20];
>       double x;
> ***************
> *** 4387,4395 ****
>       if (prec < 0)
>   	prec = 6;
> -     if (prec > 50)
> - 	prec = 50; /* Arbitrary limitation */
>       if (type == 'f' && (fabs(x) / 1e25) >= 1e25)
>   	type = 'g';
>       sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type);
>       return usprintf(buf, fmt, x);
>   }
> --- 4390,4408 ----
>       if (prec < 0)
>   	prec = 6;
>       if (type == 'f' && (fabs(x) / 1e25) >= 1e25)
>   	type = 'g';
>       sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type);
> +     /* worst case length calc to ensure no buffer overrun:
> +          fmt = %#.<prec>g
> +          buf = '-' + [0-9]*prec + '.' + 'e+' + (longest exp
> +             for any double rep.)
> +          len = 1 + prec + 1 + 2 + 5 = 9 + prec
> +        If prec=0 the effective precision is 1 (the leading digit is
> +        always given), therefore increase by one to 10+prec. */
> +     if (buflen <= (size_t)10 + (size_t)prec) {
> + 	PyErr_SetString(PyExc_OverflowError,
> + 	    "formatted float is too long (precision too long?)");
> + 	return -1;
> +     }
>       return usprintf(buf, fmt, x);
>   }
> ***************
> *** 4397,4400 ****
> --- 4410,4414 ----
>   static int
>   formatint(Py_UNICODE *buf,
> + 	  size_t buflen,
>   	  int flags,
>   	  int prec,
> ***************
> *** 4402,4405 ****
> --- 4416,4421 ----
>   	  PyObject *v)
>   {
> +     /* fmt = '%#.' + `prec` + 'l' + `type`
> +        worst case length = 3 + 10 (len of INT_MAX) + 1 + 1 = 15 (use 20)*/
>       char fmt[20];
>       long x;
> ***************
> *** 4410,4413 ****
> --- 4426,4436 ----
>       if (prec < 0)
>   	prec = 1;
> +     /* buf = '+'/'-'/'0'/'0x' + '[0-9]'*max(prec,len(x in octal))
> +        worst case buf = '0x' + [0-9]*prec, where prec >= 11 */
> +     if (buflen <= 13 || buflen <= (size_t)2+(size_t)prec) {
> +         PyErr_SetString(PyExc_OverflowError,
> +             "formatted integer is too long (precision too long?)");
> +         return -1;
> +     }
>       sprintf(fmt, "%%%s.%dl%c", (flags & F_ALT) ? "#" : "", prec, type);
>       return usprintf(buf, fmt, x);
> ***************
> *** 4416,4421 ****
>   static int
>   formatchar(Py_UNICODE *buf,
> ! 	   PyObject *v)
>   {
>       if (PyUnicode_Check(v)) {
>   	if (PyUnicode_GET_SIZE(v) != 1)
> --- 4439,4446 ----
>   static int
>   formatchar(Py_UNICODE *buf,
> !            size_t buflen,
> !            PyObject *v)
>   {
> +     /* presume that the buffer is at least 2 characters long */
>       if (PyUnicode_Check(v)) {
>   	if (PyUnicode_GET_SIZE(v) != 1)
> ***************
> *** 4447,4450 ****
> --- 4472,4485 ----
>   }
>   
> + /* fmt%(v1,v2,...) is roughly equivalent to sprintf(fmt, v1, v2, ...)
> + 
> +    FORMATBUFLEN is the length of the buffer in which the floats, ints, &
> +    chars are formatted. XXX This is a magic number. Each formatting
> +    routine does bounds checking to ensure no overflow, but a better
> +    solution may be to malloc a buffer of appropriate size for each
> +    format. For now, the current solution is sufficient.
> + */
> + #define FORMATBUFLEN (size_t)120
> + 
>   PyObject *PyUnicode_Format(PyObject *format,
>   			   PyObject *args)
> ***************
> *** 4506,4513 ****
>   	    PyObject *v = NULL;
>   	    PyObject *temp = NULL;
> ! 	    Py_UNICODE *buf;
>   	    Py_UNICODE sign;
>   	    int len;
> ! 	    Py_UNICODE tmpbuf[120]; /* For format{float,int,char}() */
>   
>   	    fmt++;
> --- 4541,4548 ----
>   	    PyObject *v = NULL;
>   	    PyObject *temp = NULL;
> ! 	    Py_UNICODE *pbuf;
>   	    Py_UNICODE sign;
>   	    int len;
> ! 	    Py_UNICODE formatbuf[FORMATBUFLEN]; /* For format{float,int,char}() */
>   
>   	    fmt++;
> ***************
> *** 4659,4664 ****
>   
>   	    case '%':
> ! 		buf = tmpbuf;
> ! 		buf[0] = '%';
>   		len = 1;
>   		break;
> --- 4694,4700 ----
>   
>   	    case '%':
> ! 		pbuf = formatbuf;
> ! 		/* presume that buffer length is at least 1 */
> ! 		pbuf[0] = '%';
>   		len = 1;
>   		break;
> ***************
> *** 4696,4700 ****
>   			goto onError;
>   		}
> ! 		buf = PyUnicode_AS_UNICODE(temp);
>   		len = PyUnicode_GET_SIZE(temp);
>   		if (prec >= 0 && len > prec)
> --- 4732,4736 ----
>   			goto onError;
>   		}
> ! 		pbuf = PyUnicode_AS_UNICODE(temp);
>   		len = PyUnicode_GET_SIZE(temp);
>   		if (prec >= 0 && len > prec)
> ***************
> *** 4710,4715 ****
>   		if (c == 'i')
>   		    c = 'd';
> ! 		buf = tmpbuf;
> ! 		len = formatint(buf, flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> --- 4746,4752 ----
>   		if (c == 'i')
>   		    c = 'd';
> ! 		pbuf = formatbuf;
> ! 		len = formatint(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE),
> ! 			flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> ***************
> *** 4719,4725 ****
>   		    if ((flags&F_ALT) &&
>   			(c == 'x' || c == 'X') &&
> ! 			buf[0] == '0' && buf[1] == c) {
> ! 			*res++ = *buf++;
> ! 			*res++ = *buf++;
>   			rescnt -= 2;
>   			len -= 2;
> --- 4756,4762 ----
>   		    if ((flags&F_ALT) &&
>   			(c == 'x' || c == 'X') &&
> ! 			pbuf[0] == '0' && pbuf[1] == c) {
> ! 			*res++ = *pbuf++;
> ! 			*res++ = *pbuf++;
>   			rescnt -= 2;
>   			len -= 2;
> ***************
> *** 4736,4741 ****
>   	    case 'g':
>   	    case 'G':
> ! 		buf = tmpbuf;
> ! 		len = formatfloat(buf, flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> --- 4773,4779 ----
>   	    case 'g':
>   	    case 'G':
> ! 		pbuf = formatbuf;
> ! 		len = formatfloat(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE),
> ! 			flags, prec, c, v);
>   		if (len < 0)
>   		    goto onError;
> ***************
> *** 4746,4751 ****
>   
>   	    case 'c':
> ! 		buf = tmpbuf;
> ! 		len = formatchar(buf, v);
>   		if (len < 0)
>   		    goto onError;
> --- 4784,4789 ----
>   
>   	    case 'c':
> ! 		pbuf = formatbuf;
> ! 		len = formatchar(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), v);
>   		if (len < 0)
>   		    goto onError;
> ***************
> *** 4759,4764 ****
>   	    }
>   	    if (sign) {
> ! 		if (*buf == '-' || *buf == '+') {
> ! 		    sign = *buf++;
>   		    len--;
>   		}
> --- 4797,4802 ----
>   	    }
>   	    if (sign) {
> ! 		if (*pbuf == '-' || *pbuf == '+') {
> ! 		    sign = *pbuf++;
  		    len--;
>   		}
> ***************
> *** 4796,4800 ****
>   	    if (sign && fill == ' ')
>   		*res++ = sign;
> ! 	    memcpy(res, buf, len * sizeof(Py_UNICODE));
>   	    res += len;
>   	    rescnt -= len;
> --- 4834,4838 ----
>   	    if (sign && fill == ' ')
>   		*res++ = sign;
> ! 	    memcpy(res, pbuf, len * sizeof(Py_UNICODE));
>   	    res += len;
>   	    rescnt -= len;
> 
> 

-- Sjoerd Mullender <sjoerd.mullender at oratrix.com>



From akuchlin at mems-exchange.org  Fri Jun 30 16:29:00 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 30 Jun 2000 10:29:00 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jun 30, 2000 at 04:18:13PM +0200
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid>
Message-ID: <20000630102900.A19597@kronos.cnri.reston.va.us>

On Fri, Jun 30, 2000 at 04:18:13PM +0200, Fredrik Lundh wrote:
>    re.match('\\x00ffffffffffffff', '\377') != None
>or in other words, long hexadecimal escapes are cast
>down to 8-bit characters in RE.

This is for compatibility with Python string literals:

kronos Python-1.6>./python
>>> '\x00fffffff'
'\377'
>>> u'\x00fffffff'
u'\uFFFF'

(Where do these semantics come from, BTW?  C's \x seems to take any
number of hex digits but then reports an error if the character is
greater than 256, too large to fit into a byte.)

Note that the \u escape for Unicode characters uses exactly 4 digits,
no more, no less.  It would certainly be simpler and clearer to only
support a fixed number of digits with \x, since I find the casting
down behaviour is magical and not obvious.  But I don't know if we
want to make that change now.  (Guido now realizes the downside to
numbering it 2.0, as everyone hurries to suggest their favorite
backward-incompatible change.)

That doesn't help with regexes, of course, since a pattern might be
written as a regular string but be intended to match Unicode.  Maybe
the simplest rule is the best; always take 4 digits, even if it winds
up being incompatible with the \x in string literals.

--amk



From fdrake at beopen.com  Fri Jun 30 16:33:47 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 10:33:47 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
In-Reply-To: <20000630101340.A16350@ludwig.cnri.reston.va.us>
References: <200006292305.QAA11929@slayer.i.sourceforge.net>
	<200006300020.TAA21877@cj20424-a.reston1.va.home.com>
	<14683.56294.836295.923883@cj42289-a.reston1.va.home.com>
	<20000630101340.A16350@ludwig.cnri.reston.va.us>
Message-ID: <14684.45003.193701.382599@cj42289-a.reston1.va.home.com>

Greg Ward writes:
 > What if it's a 1.6a1 or 1.6a2 interpreter?  Presumably people will try
 > Distutils 0.9 with them.  Should I remove that feature now that 0.9 is
 > out, but before Python 2.0b1?

  You're placing too much value on code labelled "alpha". ;)  There
are two interesting versions -- 1.5.2 (since you scrapped support for
versions before that), and 2.0.  And the CVS version is the closest
approximation to 2.0 that anyone has.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Fri Jun 30 16:38:51 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 10:38:51 -0400 (EDT)
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <20000630102242.B16350@ludwig.cnri.reston.va.us>
References: <20000629233003.A1766@beelzebub>
	<14684.5401.518766.362678@cj42289-a.reston1.va.home.com>
	<395C681D.C3211F6@lemburg.com>
	<14684.41320.38954.833643@cj42289-a.reston1.va.home.com>
	<395CA354.16AC5B7E@lemburg.com>
	<200006301455.JAA30721@cj20424-a.reston1.va.home.com>
	<395CAAAA.5975A617@lemburg.com>
	<20000630102242.B16350@ludwig.cnri.reston.va.us>
Message-ID: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>

Greg Ward writes:
 > But, consider that that the Distutils might want to know if it should
 > generate RPMs or Debian packages... then the stuff about grokking which
 > Linux distribution it's running on is relevant.  Argh!

  Why would you need to figure this out?  Are you selecting a
platform-specific packaging system automatically?  In that case, I'd
search for the presence of the tools rather than asking what sort of
distribution you're running on -- several distros use RPM, a few use
.deb packages, etc.  When the user specifies one on the command line,
just use the one they name and be done with it.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Fri Jun 30 16:53:31 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 16:53:31 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects
 unicodeobject.c,2.31,2.32
References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl>
Message-ID: <395CB46B.34053D3E@lemburg.com>

> Why was the change that occurred in revision 2.31 reverted?  Accident?
> 
> The change log said:
> Jack Jansen: Use include "" instead of <>; and staticforward declarations

Accident... I'll revert that change.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Fri Jun 30 18:07:16 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 11:07:16 -0500
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: Your message of "Fri, 30 Jun 2000 16:18:13 +0200."
             <018401bfe29e$07f26720$f2a6b5d4@hagrid> 
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> 
Message-ID: <200006301607.LAA10829@cj20424-a.reston1.va.home.com>

> my latest changes fixed a couple of things, but broke
> one of the old RE tests, namely:
> 
>     re.match('\\x00ffffffffffffff', '\377') != None
> 
> or in other words, long hexadecimal escapes are cast
> down to 8-bit characters in RE.
> 
> in SRE (after the latest change), they're cast down to
> the size of the engine's internal word size (currently 16
> bits).
> 
> is the old behaviour worth keeping?  I'd rather not make
> the engine dependent on string types; it shouldn't really
> matter if you're using unicode patterns on 8-bit target
> strings, or vice versa.

To someone familiar with '\x00ffffffffffffff' == '\377', the failure
is surprising.  What Would Larry Do?  (I.e. is this in Perl?)

Maybe make it dependent on the type of the searched string ('\377')
rather than on the type of the pattern?

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



From skip at mojam.com  Fri Jun 30 15:54:49 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 30 Jun 2000 08:54:49 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
In-Reply-To: <20000629232733.D24811@activestate.com>
References: <200006300608.XAA13124@slayer.i.sourceforge.net>
	<20000629232733.D24811@activestate.com>
Message-ID: <14684.42665.221905.911205@beluga.mojam.com>

    Trent> Cool

Thanks.

    >> To run the entire test suite, make the "test" target at the top level:
    >> 
    >> cd ...
    >> make test

    Trent> This is a UN*Xism, on Windows and UN*X:
    Trent> cd ...\Lib\test
    Trent> python regrtest.py

Thanks, I'll check into it.  I'm a Unix weenie so am (blissfully) unaware of 
how Windows weenies do these things... ;-)

    Trent> A sample walk through to create a test might make it more
    Trent> approachable for people. As well, it would be helpful to mention
    Trent> test_support.{verbose|TESTFN|...}.  But I have no right to bitch
    Trent> about good work.

I'll check into that as well.  The README file was created in about 30
minutes and was a good excuse to test my checkin capabilities on something
that wouldn't break anything. ;-)

Skip



From mhammond at skippinet.com.au  Fri Jun 30 17:48:43 2000
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 1 Jul 2000 01:48:43 +1000
Subject: [Python-Dev] Checked in new PC\config.h
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEBPCPAA.mhammond@skippinet.com.au>

Hi all,
	I noticed that PC\config.h still had a reference to "Python16.lib".  I
simply checked in a new version without submitting a patch or following any
other process.  I hope this was appropriate.

Mark.




From akuchlin at mems-exchange.org  Fri Jun 30 18:03:48 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 30 Jun 2000 12:03:48 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <200006301607.LAA10829@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 11:07:16AM -0500
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com>
Message-ID: <20000630120348.C19597@kronos.cnri.reston.va.us>

On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote:
>To someone familiar with '\x00ffffffffffffff' == '\377', the failure
>is surprising.  What Would Larry Do?  (I.e. is this in Perl?)

It uses two digits: "\x00ffff" is the string "<binary 0>ffff".

>Maybe make it dependent on the type of the searched string ('\377')
>rather than on the type of the pattern?

Won't work; you could just be compiling a pattern to make a regex
object, and have no idea what you're matching against.

--amk



From jeremy at beopen.com  Fri Jun 30 18:10:09 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 12:10:09 -0400 (EDT)
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid>
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid>
Message-ID: <14684.50785.245652.345591@bitdiddle.concentric.net>

I don't know if this is related, exactly, but there is some kind of
problem with the current test.

When I run make test, I see:

test test_sre crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation

tabnanny thinks test_sre.py is fine, so I'm not sure what the problem
is.

Jeremy



From tim_one at email.msn.com  Fri Jun 30 18:18:03 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 12:18:03 -0400
Subject: [Python-Dev] Checked in new PC\config.h
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEBPCPAA.mhammond@skippinet.com.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEHDGHAA.tim_one@email.msn.com>

[Mark Hammond]
> 	I noticed that PC\config.h still had a reference to
> "Python16.lib".  I simply checked in a new version without
> submitting a patch or following any other process.  I hope
> this was appropriate.

IMO, if you're an expert in an area and need to make a change in that area
that indeed needs to be made and isn't going to screw anybody (and because
you're an expert in that area, you're not wrong in your judgment of that
<wink>), just do it!  We'll see the diffs come by later.  Guido, Barry,
Jeremy, & Fred have been working that way a long time now.  If they didn't
want us to work that way too, they shouldn't have given us the ability to
commit.

empowering-the-masses-ly y'rs  - tim





From guido at python.org  Fri Jun 30 19:18:10 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 12:18:10 -0500
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: Your message of "Fri, 30 Jun 2000 12:03:48 -0400."
             <20000630120348.C19597@kronos.cnri.reston.va.us> 
References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com>  
            <20000630120348.C19597@kronos.cnri.reston.va.us> 
Message-ID: <200006301718.MAA12448@cj20424-a.reston1.va.home.com>

> On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote:
> >To someone familiar with '\x00ffffffffffffff' == '\377', the failure
> >is surprising.  What Would Larry Do?  (I.e. is this in Perl?)
> 
> It uses two digits: "\x00ffff" is the string "<binary 0>ffff".
> 
> >Maybe make it dependent on the type of the searched string ('\377')
> >rather than on the type of the pattern?
> 
> Won't work; you could just be compiling a pattern to make a regex
> object, and have no idea what you're matching against.

OK.  Let's change our spec.

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



From guido at python.org  Fri Jun 30 19:26:51 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 12:26:51 -0500
Subject: [Python-Dev] Checked in new PC\config.h
In-Reply-To: Your message of "Fri, 30 Jun 2000 12:18:03 -0400."
             <LNBBLJKPBEHFEDALKOLCMEHDGHAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCMEHDGHAA.tim_one@email.msn.com> 
Message-ID: <200006301726.MAA12560@cj20424-a.reston1.va.home.com>

> IMO, if you're an expert in an area and need to make a change in that area
> that indeed needs to be made and isn't going to screw anybody (and because
> you're an expert in that area, you're not wrong in your judgment of that
> <wink>), just do it!  We'll see the diffs come by later.  Guido, Barry,
> Jeremy, & Fred have been working that way a long time now.  If they didn't
> want us to work that way too, they shouldn't have given us the ability to
> commit.

Exactly!

So far it's working like a charm!

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



From tim_one at email.msn.com  Fri Jun 30 18:38:21 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 12:38:21 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <20000630102900.A19597@kronos.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEHFGHAA.tim_one@email.msn.com>

[Andrew Kuchling]
> ...
> This is for compatibility with Python string literals:
>
> kronos Python-1.6>./python
> >>> '\x00fffffff'
> '\377'
> >>> u'\x00fffffff'
> u'\uFFFF'
>
> (Where do these semantics come from, BTW?  C's \x seems to take any
> number of hex digits but then reports an error if the character is
> greater than 256, too large to fit into a byte.)

The behavior of \x in C is mostly implementation-defined.  The committee
knew that C had to do *something* to support "large characters" down the
road, but in those early days they had no clear idea exactly what.  So,
rather than do something sensible <0.5 wink>, they invented a perfectly
general mechanism without portable semantics.  "C itself" isn't complaining
if the character "is greater than 256", it's the specific implementation of
C you're using that's complaining.  A different implementation is free to (&
probably will!) do something different.

Guido adopted the most commonly implemented semantics (ignore all but the
last byte) in Python, apparently under the delusion that this would be a
Good Thing <wink>.  Marc-Andre followed suit by generalizing this madness to
Unicode.

> Note that the \u escape for Unicode characters uses exactly 4 digits,
> no more, no less.

I pushed for that obnoxiously.  Glad you appreciate it <wink>.  Java does
the same.

> It would certainly be simpler and clearer to only support a fixed
> number of digits with \x, since I find the casting down behaviour is
> magical and not obvious.

Yes, it's basically nuts.

> But I don't know if we want to make that change now.

No from me, because it may break stuff.  Wait for Python 2.0 <ahem>.

> (Guido now realizes the downside to numbering it 2.0, as everyone
> hurries to suggest their favorite backward-incompatible change.)

Guido always realized that, I believe.  It's a "least of evils" kind of
thing, mixed with a celebration, not a pure win.

> That doesn't help with regexes, of course, since a pattern might be
> written as a regular string but be intended to match Unicode.  Maybe
> the simplest rule is the best; always take 4 digits, even if it winds
> up being incompatible with the \x in string literals.

I vote for backward compatibility for now, and not only because that will
irritate /F the most.





From bwarsaw at beopen.com  Fri Jun 30 18:51:15 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 12:51:15 -0400 (EDT)
Subject: [Python-Dev] --with-cycle-gc switch
Message-ID: <14684.53251.309942.13110@anthem.concentric.net>

I don't like --with-cycle-gc as the configure switch, and
unfortunately configure is explicitly designed not to complain about
bogus switches.  I just typed --without-gc and was momentarily
surprised that the module was still enabled.

I propose to change the switch to --with(out)-gc and to not recognize
--with(out)-cycle-gc.  The switch hasn't been there long enough to
support both.

-Barry



From jeremy at beopen.com  Fri Jun 30 19:02:42 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 13:02:42 -0400 (EDT)
Subject: [Python-Dev] --with-cycle-gc switch
In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net>
References: <14684.53251.309942.13110@anthem.concentric.net>
Message-ID: <14684.53938.307841.921051@bitdiddle.concentric.net>

The problem with the name --without-gc is that it suggests a build
without any garbage collection.  The new patch only handles one
special case of garbage collection.  The name --without-cycle-gc is a
little unwieldy, but clearer.

Jeremy



From Vladimir.Marangozov at inrialpes.fr  Fri Jun 30 19:11:50 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 19:11:50 +0200 (CEST)
Subject: [Python-Dev] --with-cycle-gc switch
In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 12:51:15 PM
Message-ID: <200006301711.TAA21382@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> I propose to change the switch to --with(out)-gc and to not recognize
> --with(out)-cycle-gc.  The switch hasn't been there long enough to
> support both.

-0

for the reason summarized by Jeremy

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From effbot at telia.com  Fri Jun 30 19:33:55 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 19:33:55 +0200
Subject: [Python-Dev] SRE: a minor glitch in re.py
References: <200006301625.JAA32503@slayer.i.sourceforge.net>
Message-ID: <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid>

from the new re.py:

> ! # change this to "pre" if your regexps stopped working.  don't
> ! # forget to send a bug report to <some suitable address>

is bugs-py at python.org suitable?

or should we refer people to 
http://www.python.org/search/search_bugs.html

or should they pester me directly? (i.e. effbot at telia.com)

</F>





From guido at python.org  Fri Jun 30 20:33:46 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 13:33:46 -0500
Subject: [Python-Dev] SRE: a minor glitch in re.py
In-Reply-To: Your message of "Fri, 30 Jun 2000 19:33:55 +0200."
             <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> 
References: <200006301625.JAA32503@slayer.i.sourceforge.net>  
            <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> 
Message-ID: <200006301833.NAA18667@cj20424-a.reston1.va.home.com>

> from the new re.py:
> 
> > ! # change this to "pre" if your regexps stopped working.  don't
> > ! # forget to send a bug report to <some suitable address>
> 
> is bugs-py at python.org suitable?
> 
> or should we refer people to 
> http://www.python.org/search/search_bugs.html
> 
> or should they pester me directly? (i.e. effbot at telia.com)

Probably.  You decide and check it in!

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



From bwarsaw at beopen.com  Fri Jun 30 19:39:12 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 13:39:12 -0400 (EDT)
Subject: [Python-Dev] --with-cycle-gc switch
References: <14684.53251.309942.13110@anthem.concentric.net>
	<200006301711.TAA21382@python.inrialpes.fr>
Message-ID: <14684.56128.700037.255534@anthem.concentric.net>

>>>>> "VM" == Vladimir Marangozov <Vladimir.Marangozov at inrialpes.fr> writes:

    VM> -0

    VM> for the reason summarized by Jeremy

Okay, I'll leave it alone.



From Vladimir.Marangozov at inrialpes.fr  Fri Jun 30 19:52:15 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 19:52:15 +0200 (CEST)
Subject: [Python-Dev] Oops on AIX
Message-ID: <200006301752.TAA22474@python.inrialpes.fr>

After the CVS commit storm that occurred during the last 3 days,
I wanted to validate the current build on AIX. And I am stalled.

I am not sure, but it seems like the errors I get relate with the
latest 64-bit support patches, and I don't dare to suggest corrections
in this area, so I welcome any help...


        xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c
"methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed.

        xlc_r  -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c
"./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined.
"./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h.
make: 1254-004 The error code from the last command is 1.

Thanks.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From effbot at telia.com  Fri Jun 30 19:53:45 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 19:53:45 +0200
Subject: [Python-Dev] SRE incompatibility
References: <LNBBLJKPBEHFEDALKOLCAEHFGHAA.tim_one@email.msn.com>
Message-ID: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid>

tim wrote:
> > That doesn't help with regexes, of course, since a pattern might be
> > written as a regular string but be intended to match Unicode.  Maybe
> > the simplest rule is the best; always take 4 digits, even if it winds
> > up being incompatible with the \x in string literals.
> 
> I vote for backward compatibility for now, and not only because that will
> irritate /F the most.

backward compatibility with what?  8-bit string literals or unicode
string literals?

the problem here is that the pattern is compiled once (from either
8-bit or unicode strings), and can then be used on either 8-bit or
unicode targets.  to be fully backwards compatible, this means that
the compiler should use 8 bits, no matter what string type you're
using.

another solution would be to use the type of the pattern string to
choose between 8 and 16 bits.  I almost implemented that, before
I realized that it broke the following rather nice property:

    sre.compile("some pattern") == sre.compile(u"some pattern")

(well, the pattern type doesn't implement __cmp__, but you get the
idea).  the current implementation guarantees "==", but I'm planning
to change that to "is" (!).

anyway, I suspect it's too late to change this in 2.0b1.  if enough
people complain about this, we can always label it a "critical bug",
and do something about it in b2.

</F>




From bwarsaw at beopen.com  Fri Jun 30 20:04:06 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 14:04:06 -0400 (EDT)
Subject: [Python-Dev] Odd behavior with `make test'
Message-ID: <14684.57622.9807.868551@anthem.concentric.net>

make test is behaving strangely.  The first time I ran it I got

test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation

which I believe Jeremy has seen with test_sre.  tabnanny says
everything's fine, and running the module manually (and individually
w/ regrtest) shows no problems with the test.

Similarly, I got a different crash in test_sre.  It says:

test test_sre failed -- sre.search

and I also get

test test_re failed -- re.search

I'm also getting bizare stuff like

test test_strftime crashed -- exceptions.AttributeError : match
test test_tokenize crashed -- exceptions.AttributeError : compile
test test_xmllib crashed -- exceptions.AttributeError : compile

This is all with a CVS updated Python 2.0b1.

Now if I run "./python Lib/test/test_mmap.py" manually, this succeeds,
and now either the failures go away or are transmorgrified into
something more reasonable:

mmap, strftime, tokenize, sre, and xmllib all pass.

test_re still fails, but this time with

test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou"

Blowing away the Lib/test/*.pyc's doesn't seem to re-trigger the
problem once it's fixed, but doing a `make distclean' and `make test'
gets me back to the initial situation.

Weird!
-Barry



From effbot at telia.com  Fri Jun 30 20:12:11 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:12:11 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1
References: <20000629232733.D24811@activestate.com> <LNBBLJKPBEHFEDALKOLCAEGAGHAA.tim_one@email.msn.com> <20000629235247.A25090@activestate.com>
Message-ID: <037e01bfe2be$b814d5a0$f2a6b5d4@hagrid>

trent wrote:
> On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote:
> > BTW, I'd just like to say what a delight it is to work with *all* of you
> > folks!
> 
> I feel a group hug coming on in the morning. Or maybe I am just moved by the
> beer that I had for dinner. :)

beer for dinner?  what an excellent idea.  didn't I have
some strong lager somewhere?

ah, yes...

hey, maybe I should rewrite the SRE core again, to get
rid of those last glitches...




From effbot at telia.com  Fri Jun 30 20:15:37 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:15:37 +0200
Subject: [Python-Dev] Odd behavior with `make test'
References: <14684.57622.9807.868551@anthem.concentric.net>
Message-ID: <038601bfe2bf$31c52da0$f2a6b5d4@hagrid>

> test_re still fails, but this time with
> 
> test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou"

note that test_re should fail; someone (me?) needs to
regenerate the output file.

the rest looks a bit scary, to say the least.  does someone (sre?)
overwrite something? does anyone have purify (dmalloc, fences,
whatever) within reach?

</F>




From Vladimir.Marangozov at inrialpes.fr  Fri Jun 30 20:22:03 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 20:22:03 +0200 (CEST)
Subject: [Python-Dev] Odd behavior with `make test'
In-Reply-To: <14684.57622.9807.868551@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 02:04:06 PM
Message-ID: <200006301822.UAA22606@python.inrialpes.fr>

Barry A. Warsaw wrote:
> 
> make test is behaving strangely.  The first time I ran it I got

On which platform? Linux seems to do fine with most of this.
On AIX (after some hacking related to my previous msg "Oops on AIX",
I managed to compile everything but I'll dump an error log on Trent :-)

> 
> test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation

same here

> test test_sre failed -- sre.search
> ...
> test test_re failed -- re.search
> ...
> test test_strftime crashed -- exceptions.AttributeError : match
> test test_tokenize crashed -- exceptions.AttributeError : compile
> test test_xmllib crashed -- exceptions.AttributeError : compile

same here. I believe Guido & al. are aware as per the checkin msg,
saying that  /F promises to fix this.

But on AIX I get in addition to the above failures:

test test_array failed -- array('b') overflowed assigning -128L


-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From tim_one at email.msn.com  Fri Jun 30 20:20:46 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 14:20:46 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEHLGHAA.tim_one@email.msn.com>

[Tim]
> I vote for backward compatibility for now, and not only because
> that will irritate /F the most.

[/F]
> backward compatibility with what?

1.5.2.

> 8-bit string literals

At least, because they were in 1.5.2.

> or unicode string literals?

I'm sorry \x escapes are even allowed in those -- \x notation is a gimmick
for making strings hold arbitrary binary data, which we're trying to get
away from.  To the extent that they make any sense at all in Unicode
strings, \u should be used instead.

> the problem here is that the pattern is compiled once (from either
> 8-bit or unicode strings), and can then be used on either 8-bit or
> unicode targets.  to be fully backwards compatible, this means that
> the compiler should use 8 bits, no matter what string type you're
> using.

Unicode strings weren't in 1.5.2, so there can't possibly be a backwards
compatibility issue with them -- at least not in the sense I'm using the
phrase here.

> another solution would be to use the type of the pattern string to
> choose between 8 and 16 bits.  I almost implemented that, before
> I realized that it broke the following rather nice property:
>
>     sre.compile("some pattern") == sre.compile(u"some pattern")
>
> (well, the pattern type doesn't implement __cmp__, but you get the
> idea).  the current implementation guarantees "==", but I'm planning
> to change that to "is" (!).

Do you mean that, e.g.,

    sre.compile("\u0045") == sre.compile(u"\u0045")

too?  If so, that doesn't make any sense to me (interpreting \u in 8-bit
strings is even more confused than interpreting \x in Unicode strings).  But
if you didn't mean to include this case, then the equality doesn't actually
hold now, so there's nothing to preserve <wink>.

> anyway, I suspect it's too late to change this in 2.0b1.  if enough
> people complain about this, we can always label it a "critical bug",
> and do something about it in b2.

I think the real problem here was MAL's generalization of \x to 2-byte stuff
in Unicode strings.  If Unicode strings *have* to support \x, then

    \x0123456789abcdef

in Unicode strings should act like

    \u00ef

in Unicode strings, and SRE should play along with that too.  \x was broken
to begin with; better to wipe it out than try to generalize it.

OTOH, I didn't get much sleep last night <0.8 wink>.





From effbot at telia.com  Fri Jun 30 20:29:54 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:29:54 +0200
Subject: [Python-Dev] Odd behavior with `make test'
References: <200006301822.UAA22606@python.inrialpes.fr>
Message-ID: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid>

> > test test_sre failed -- sre.search
> > ...
> > test test_re failed -- re.search
> > ...
> > test test_strftime crashed -- exceptions.AttributeError : match
> > test test_tokenize crashed -- exceptions.AttributeError : compile
> > test test_xmllib crashed -- exceptions.AttributeError : compile
> 
> same here. I believe Guido & al. are aware as per the checkin msg,
> saying that  /F promises to fix this.

I have no idea what causes this.

however, I just noticed that evil tabs had snucked their way into
sre_parse and sre_compile.  new, properly untabified versions are
on their way to the repository.

maybe the interpreter messes up badly once -tt has reported an
error?  try removing -tt from the TESTPYTHON line in the makefile,
and see what happens.

</F>




From gward at mems-exchange.org  Fri Jun 30 20:26:51 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Fri, 30 Jun 2000 14:26:51 -0400
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jun 30, 2000 at 10:38:51AM -0400
References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> <20000630102242.B16350@ludwig.cnri.reston.va.us> <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>
Message-ID: <20000630142650.B16028@ludwig.cnri.reston.va.us>

On 30 June 2000, Fred L. Drake, Jr. said:
>   Why would you need to figure this out?  Are you selecting a
> platform-specific packaging system automatically?  In that case, I'd
> search for the presence of the tools rather than asking what sort of
> distribution you're running on -- several distros use RPM, a few use
> .deb packages, etc.  When the user specifies one on the command line,
> just use the one they name and be done with it.

Currently it's up to the user to decide which kind of built distribution
they want, with stupid defaults: dumb tarball for Unix, dumb ZIP file
for Windows.  If you want an RPM or a Windows installer, you have to say 
so explicitly.  This is not a big deal, but it might be nice to detect
automatically if we can build (say) RPMs and do so.

This is not a high-priority feature, though.  I'll accept a patch if
someone out there is interested enough to implement it.

        Greg



From effbot at telia.com  Fri Jun 30 20:37:16 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 20:37:16 +0200
Subject: [Python-Dev] SRE incompatibility
References: <LNBBLJKPBEHFEDALKOLCEEHLGHAA.tim_one@email.msn.com>
Message-ID: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid>

tim wrote:
> > to be fully backwards compatible, this means that the compiler
> > should use 8 bits, no matter what string type you're using.
...
> I think the real problem here was MAL's generalization of \x to 2-byte stuff
> in Unicode strings.  If Unicode strings *have* to support \x, then
> 
>     \x0123456789abcdef
> 
> in Unicode strings should act like
> 
>     \u00ef
> 
> in Unicode strings, and SRE should play along with that too.  \x was broken
> to begin with; better to wipe it out than try to generalize it.

I think this means that we agree -- \x is a wart that can only
be used to embed *binary bytes* in a string.

</F>




From Vladimir.Marangozov at inrialpes.fr  Fri Jun 30 20:37:35 2000
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Fri, 30 Jun 2000 20:37:35 +0200 (CEST)
Subject: [Python-Dev] Odd behavior with `make test'
In-Reply-To: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 30, 2000 08:29:54 PM
Message-ID: <200006301837.UAA22688@python.inrialpes.fr>

Fredrik Lundh wrote:
> 
> maybe the interpreter messes up badly once -tt has reported an
> error?  try removing -tt from the TESTPYTHON line in the makefile,
> and see what happens.

Matches Barry's report exactly.
To which I'll add the array('b') failure which is not due to an
optimization of arraymodule.c. Will investigate this tonight.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From DavidA at ActiveState.com  Fri Jun 30 20:43:14 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 30 Jun 2000 11:43:14 -0700
Subject: [Python-Dev] Hey! who changed sys.platform?!
In-Reply-To: <200006301455.JAA30721@cj20424-a.reston1.va.home.com>
Message-ID: <PLEJJNOHDIGGLDPOGPJJEEGJCLAA.DavidA@ActiveState.com>

> But I vote -1 on this one anyway -- it's too much code and almost by
> its very nature not something that belongs in a "standard" library.
> Plus, I don't want to be responsible for maintaining it.  Sorry,
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Not that I hope to override the heavy -1, but I don't agree with the second
point.  It embodies a huge amount of knowledge that is needed to write
portable code.  As such, IMO, it _does_ belong in the standard library.  How
is it different in its nature from sys.platform, which is only a much weaker
version of the same concept?

--david




From skip at mojam.com  Fri Jun 30 19:35:20 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 30 Jun 2000 12:35:20 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5
In-Reply-To: <200006301841.LAA20523@slayer.i.sourceforge.net>
References: <200006301841.LAA20523@slayer.i.sourceforge.net>
Message-ID: <14684.55896.890339.982232@beluga.mojam.com>

    Fred> The new copyright / license.
    ...
    Fred> ! ...  IN NO EVENT SHALL THE REGENTS OR
    Fred> ! CONTRIBUTORS BE LIABLE FOR ...

Who are the "regents" and the "contributors"?  Should those terms be
defined somewhere?

not-a-lawyer-and-never-wanted-to-be-ly y'rs,

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From nascheme at enme.ucalgary.ca  Fri Jun 30 20:53:06 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 12:53:06 -0600
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1
In-Reply-To: <14684.7005.661874.713000@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 11:00:29PM -0500
References: <200006300502.WAA03286@slayer.i.sourceforge.net> <14684.7005.661874.713000@beluga.mojam.com>
Message-ID: <20000630125306.B32568@acs.ucalgary.ca>

On Thu, Jun 29, 2000 at 11:00:29PM -0500, Skip Montanaro wrote:
> I can all but guarantee you this test will always fail.  Printing absolute
> machine addresses (via calls to id() in this case) in test cases should be
> verboten.

This test script should be better.  It doesn't generate any
output (the stuff the old script printed was pretty useless
anyhow).

  Neil
-------------- next part --------------
import gc
from test_support import *

def test_list():
    l = []
    l.append(l)
    gc.collect()
    del l
    assert gc.collect() == 1

def test_dict():
    d = {}
    d[1] = d
    gc.collect()
    del d
    assert gc.collect() == 1

def test_tuple():
    l = []
    t = (l,)
    l.append(t)
    gc.collect()
    del t
    del l
    assert gc.collect() == 2

def test_class():
    class A:
        pass
    A.a = A
    gc.collect()
    del A
    assert gc.collect() > 0

def test_instance():
    class A:
        pass
    a = A()
    a.a = a
    gc.collect()
    del a
    assert gc.collect() > 0

def test_method():
    class A:
        def __init__(self):
            self.init = self.__init__
    a = A()
    gc.collect()
    del a
    assert gc.collect() > 0

def test_finalizer():
    class A:
        def __del__(self): pass
    class B:
        pass
    a = A()
    a.a = a
    id_a = id(a)
    b = B()
    b.b = b
    gc.collect()
    del a
    del b
    assert gc.collect() > 0
    for obj in gc.garbage:
        if id(obj) == id_a:
            return
    raise TestFailed

def test_function():
    d = {}
    exec("def f(): pass\n") in d
    gc.collect()
    del d
    assert gc.collect() > 0


def test_all():
    threshold = gc.get_threshold()
    gc.set_threshold(0) # disable automatic collection
    gc.collect()
    test_list()
    test_dict()
    test_tuple()
    test_class()
    test_instance()
    test_method()
    test_finalizer()
    test_function()
    apply(gc.set_threshold, threshold)

test_all()

From tim_one at email.msn.com  Fri Jun 30 20:51:59 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 14:51:59 -0400
Subject: [Python-Dev] SRE incompatibility
In-Reply-To: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEHOGHAA.tim_one@email.msn.com>

[/F]
> I think this means that we agree -- \x is a wart that can only
> be used to embed *binary bytes* in a string.

We certainly agree about that part!  I thought my

> I'm sorry \x escapes are even allowed in [u-strings] -- \x notation
> is a gimmick for making strings hold arbitrary binary data, which
> we're trying to get away from.  To the extent that they make any
> sense at all in Unicode strings, \u should be used instead.

was pretty explicit <wink>.

What we may still disagree on is how SRE should deal with the \x mess.  I'm
in favor of making \x mean "just the last byte" in plain and Unicode
strings -- do the least harm with this (mis)feature.  Making \x mean
anything other than that for plain strings, regardless of context, is not
backward compatible (with 1.5.2).  And since Unicode strings haven't been
released yet, it's not too late to change what they do with \x.

That would make SRE's job clear here, yes?  And in a way that allows the
now-failing test to pass again?





From skip at mojam.com  Fri Jun 30 19:43:21 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 30 Jun 2000 12:43:21 -0500 (CDT)
Subject: [Python-Dev] "make test" vs. "-tt"
Message-ID: <14684.56377.293211.329273@beluga.mojam.com>

Per Fredrik's suggestion, I changed "-tt" to simply "-t".  I've not yet done
a "cvs update" to grab the tab-corrected versions of whatever files were
causing the indigestion.  I'm down to a single test failure (test_re) now
when running "make test" before .py[co] files have been created.

I noticed a couple warnings when test_mmap was running though:

    ./Lib/sre_compile.py: inconsistent tab/space usage
    ./Lib/sre_parse.py: inconsistent tab/space usage

Could it be that when "-tt" detects a problem it causes a broken .py[co]
file to be generated?

-- 
Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings.  I listen to the man with the rings."



From DavidA at ActiveState.com  Fri Jun 30 20:58:20 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 30 Jun 2000 11:58:20 -0700
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <14684.42843.472230.609828@anthem.concentric.net>
Message-ID: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>

> That's a good point.  A bump in major rev number is an /opportunity/
> to break things, like a bone that hasn't healed right, so that they
> can be fixed correctly.  We'll lose that for 2.0, mostly likely
> because of the tight release schedule.

Yes, I find that frustrating.  The story for months (years?) has been that
we don't break things because it's a 'dot-release', and so we've shelved
improvements left and right.  Now we don't have time to do those things even
when it _is_ a major release.

Some advance notice would have been nice.

--david




From fdrake at beopen.com  Fri Jun 30 21:05:42 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 15:05:42 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
References: <14684.42843.472230.609828@anthem.concentric.net>
	<PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
Message-ID: <14684.61318.668529.402341@cj42289-a.reston1.va.home.com>

David Ascher writes:
 > Yes, I find that frustrating.  The story for months (years?) has been that
 > we don't break things because it's a 'dot-release', and so we've shelved
 > improvements left and right.  Now we don't have time to do those things even
 > when it _is_ a major release.
 > 
 > Some advance notice would have been nice.

  I agree, but this was news to at least some of us even Wednesday.
The upside is that major releases are more likely to happen now that
the precedent has been set.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Fri Jun 30 21:06:04 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 30 Jun 2000 15:06:04 -0400
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIBGHAA.tim_one@email.msn.com>

[David Ascher, wishing he had had the opportunity to break things with 2.0]
> ...
> Some advance notice would have been nice.

David, it would have been nice for us too <0.3 wink>.

we're-not-keeping-secrets-we're-just-another-thrashing-startup-ly y'rs
    - tim





From nascheme at enme.ucalgary.ca  Fri Jun 30 21:50:52 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 13:50:52 -0600
Subject: [Python-Dev] Windows build issues
Message-ID: <20000630135052.A405@acs.ucalgary.ca>

A couple of things:

PCbuild/readme.txt

    Should be updated for the new release.

PC/config.h 

    VC++ 5.0 will not compile python20 unless "#include
    <basetsd.h>" is commented out.  Trent?

    WITH_CYCLE_GC should be uncommented if we want to have GC
    enabled in the beta.

PCbuild/python20.dsp

    Line endings seem to be incorrect.  Someone probably edited
    the file on a Unix machine and munched things up.  VC++ 5.0
    likes DOS line endings otherwise it refuses to load the
    project.

Also, I get a few warnings when compiling.  One is about an /IZ
(I think) option being ignored.  There are a few other warnings
as well which I didn't write down.

  Neil



From effbot at telia.com  Fri Jun 30 21:53:05 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 21:53:05 +0200
Subject: [Python-Dev] SRE incompatibility
References: <LNBBLJKPBEHFEDALKOLCKEHOGHAA.tim_one@email.msn.com>
Message-ID: <03f501bfe2cc$cf5dcce0$f2a6b5d4@hagrid>

tim wrote:
> That would make SRE's job clear here, yes?  And in a way that allows the
> now-failing test to pass again?

sure.  quoting from python-checkins:

RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_sre,v
...
  test_sre
- === Failed incorrectly ('\\x00ffffffffffffff', '\377', 0, 'found', '\377')
  === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A')
...

still messes up on nested repetitions, but that's entirely
different problem...

</F>




From fdrake at beopen.com  Fri Jun 30 22:23:35 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 30 Jun 2000 16:23:35 -0400 (EDT)
Subject: [Python-Dev] 2.0b1 documentation online
Message-ID: <14685.455.115147.446238@cj42289-a.reston1.va.home.com>

  See it at:

  http://www.python.org/doc/devel/


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Fri Jun 30 23:23:09 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 16:23:09 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5
In-Reply-To: Your message of "Fri, 30 Jun 2000 12:35:20 EST."
             <14684.55896.890339.982232@beluga.mojam.com> 
References: <200006301841.LAA20523@slayer.i.sourceforge.net>  
            <14684.55896.890339.982232@beluga.mojam.com> 
Message-ID: <200006302123.QAA20537@cj20424-a.reston1.va.home.com>

>     Fred> The new copyright / license.
>     ...
>     Fred> ! ...  IN NO EVENT SHALL THE REGENTS OR
>     Fred> ! CONTRIBUTORS BE LIABLE FOR ...
> 
> Who are the "regents" and the "contributors"?  Should those terms be
> defined somewhere?

Oops.  I thought I caught all the regents and replaced them with a
more politically correct term.  Seems one got away.  Fixed now.

> not-a-lawyer-and-never-wanted-to-be-ly y'rs,

Ditto,

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



From guido at python.org  Fri Jun 30 23:26:21 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 16:26:21 -0500
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: Your message of "Fri, 30 Jun 2000 11:58:20 MST."
             <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com> 
References: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com> 
Message-ID: <200006302126.QAA20621@cj20424-a.reston1.va.home.com>

> > That's a good point.  A bump in major rev number is an /opportunity/
> > to break things, like a bone that hasn't healed right, so that they
> > can be fixed correctly.  We'll lose that for 2.0, mostly likely
> > because of the tight release schedule.

[David Ascher]
> Yes, I find that frustrating.  The story for months (years?) has been that
> we don't break things because it's a 'dot-release', and so we've shelved
> improvements left and right.  Now we don't have time to do those things even
> when it _is_ a major release.

You have no idea how frustration it is for me!  But sometimes the
marketing people force us engineers to act quickly.  Just be glad I'm
not following the release schedule that they had *wanted* me to
use... :-)

> Some advance notice would have been nice.

Same here. :-)

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



From nascheme at enme.ucalgary.ca  Fri Jun 30 22:31:48 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 14:31:48 -0600
Subject: [Python-Dev] Idle breakage
Message-ID: <20000630143148.A9725@acs.ucalgary.ca>

Caused by _sre perhaps?

$ python Tools/idle/idle.py
Traceback (most recent call last):
  File "Tools/idle/idle.py", line 8, in ?
    IdleConf.load(idle_dir)
  File "Tools/idle/IdleConf.py", line 109, in load
    idleconf.read((os.path.join(dir, "config.txt"), genplatfile, platfile,
  File "/usr/local/lib/python2.0/ConfigParser.py", line 207, in read
    self.__read(fp, filename)
  File "/usr/local/lib/python2.0/ConfigParser.py", line 382, in __read
    raise e
ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt
        [line 21]: 'width= 80\012'
        [line 22]: 'height= 24\012'
        [line 26]: 'normal-foreground= black\012'
        [line 27]: 'normal-background= white\012'
        [line 29]: 'keyword-foreground= #ff7700\012'
        [line 30]: 'comment-foreground= #dd0000\012'
        [line 31]: 'string-foreground= #00aa00\012'
        [line 32]: 'definition-foreground= #0000ff\012'
        [line 33]: 'hilite-foreground= #000068\012'
        [line 34]: 'hilite-background= #006868\012'
        [line 35]: 'break-foreground= #ff7777\012'
        [line 36]: 'hit-foreground= #ffffff\012'
        [line 37]: 'hit-background= #000000\012'
        [line 38]: 'stdout-foreground= blue\012'
        [line 39]: 'stderr-foreground= red\012'
        [line 40]: 'console-foreground= #770000\012'
        [line 41]: 'error-background= #ff7777\012'
        [line 42]: 'cursor-background= black\012'
        [line 59]: 'enable= 0\012'
        [line 60]: 'style= expression\012'
        [line 61]: 'flash-delay= 500\012'
        [line 62]: 'bell= 1\012'
        [line 63]: 'hilite-foreground= black\012'
        [line 64]: 'hilite-background= #43cd80\012'



From jeremy at beopen.com  Fri Jun 30 22:33:01 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 16:33:01 -0400 (EDT)
Subject: [Python-Dev] New PythonLabs site revealed!
In-Reply-To: <200006302126.QAA20621@cj20424-a.reston1.va.home.com>
References: <PLEJJNOHDIGGLDPOGPJJGEGKCLAA.DavidA@ActiveState.com>
	<200006302126.QAA20621@cj20424-a.reston1.va.home.com>
Message-ID: <14685.1021.870885.796187@bitdiddle.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

  >> That's a good point.  A bump in major rev number is an
  >> /opportunity/ to break things, like a bone that hasn't healed
  >> right, so that they can be fixed correctly.  We'll lose that
  >> for 2.0, mostly likely because of the tight release schedule.

  GvR> [David Ascher]
  >> Yes, I find that frustrating.  The story for months (years?) has
  >> been that we don't break things because it's a 'dot-release', and
  >> so we've shelved improvements left and right.  Now we don't have
  >> time to do those things even when it _is_ a major release.

  GvR> You have no idea how frustration it is for me!  But sometimes
  GvR> the marketing people force us engineers to act quickly.  Just
  GvR> be glad I'm not following the release schedule that they had
  GvR> *wanted* me to use... :-)

Perhaps I am too easy-going, but I consider the 2.0 release a
'dot-release' masquerading as a major revision.  It might be a little
silly, but it seems even sillier to preserve a naming scheme that
makes users think that the technology is immature.

Jeremy



From guido at python.org  Fri Jun 30 23:33:52 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Jun 2000 16:33:52 -0500
Subject: [Python-Dev] Windows build issues
In-Reply-To: Your message of "Fri, 30 Jun 2000 13:50:52 CST."
             <20000630135052.A405@acs.ucalgary.ca> 
References: <20000630135052.A405@acs.ucalgary.ca> 
Message-ID: <200006302133.QAA20696@cj20424-a.reston1.va.home.com>

> A couple of things:
> 
> PCbuild/readme.txt
> 
>     Should be updated for the new release.

Tim will do this.

> PC/config.h 
> 
>     VC++ 5.0 will not compile python20 unless "#include
>     <basetsd.h>" is commented out.  Trent?

I'll leave this to Trent -- I don't know how to check for VC 5.0
vs. 6.0.

>     WITH_CYCLE_GC should be uncommented if we want to have GC
>     enabled in the beta.

Done.

> PCbuild/python20.dsp
> 
>     Line endings seem to be incorrect.  Someone probably edited
>     the file on a Unix machine and munched things up.  VC++ 5.0
>     likes DOS line endings otherwise it refuses to load the
>     project.

There was one missing CR.  Fixed now.

> Also, I get a few warnings when compiling.  One is about an /IZ
> (I think) option being ignored.  There are a few other warnings
> as well which I didn't write down.

Probably 6.0 flags that 5.0 doesn't have.  What can we do?

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



From nascheme at enme.ucalgary.ca  Fri Jun 30 22:40:21 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 14:40:21 -0600
Subject: [Python-Dev] Idle breakage
In-Reply-To: <20000630143148.A9725@acs.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Fri, Jun 30, 2000 at 02:31:48PM -0600
References: <20000630143148.A9725@acs.ucalgary.ca>
Message-ID: <20000630144021.A9847@acs.ucalgary.ca>

Changing to pre fixes the problem.

  Neil



From mwh21 at cam.ac.uk  Fri Jun 30 22:50:37 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 30 Jun 2000 21:50:37 +0100
Subject: [Python-Dev] Re: Test results of linuxaudiodev.c
In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 17:44:35 -0700 (PDT)"
References: <Pine.SGI.3.96.1000629173646.621134u-100000@happy>
Message-ID: <m3r99e7v1e.fsf@atrus.jesus.cam.ac.uk>

To python-dev: Sorry for the hiatus.

To python-list: does someone who knows about audio and can run linux
want to play with this (Ping and I fall into just one of these
categories each!).

Ka-Ping Yee <pingster at ilm.com> writes:

> On 30 Jun 2000, Michael Hudson wrote:
> > Yup, that works fine.  Don't understand the details - and as I have my
> > graduation ceremony tomorrow I'm going to go to bed and leave learning
> > them until some other occasion!
> 
> Cool.
> 
> Okay, i just discovered sunau.py.  Here's my real shot at
> test_linuxaudiodev.py.  Can you give this a try?
> 
> 
> ---- test_linuxaudiodev.py ----
> from test_support import verbose, findfile, TestFailed
> import linuxaudiodev
> import os, sunau
> 
> formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW,
>            ("NONE", 1): linuxaudiodev.AFMT_S8,
>            ("NONE", 2): linuxaudiodev.AFMT_S16_BE}
> 
> def play_au_file(path):
>     au = sunau.open(path, "r")
>     data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE)
>     au.close()
> 
>     spec = (au.getcomptype(), au.getsampwidth())
>     if not has_key(formats, spec):
             ^^^^^^^
Oops?

>         raise "audio format not supported by linuxaudiodev"

Maybe you mean:

        raise TestFailed, "audio format not supported by linuxaudiodev"

?  I thought string exceptions were deprecated...
         
>     dsp = linuxaudiodev.open("w")
>     dsp.setparameters(au.getframerate(), au.getsampwidth() * 8,
>                       au.getnchannels(), formats[spec])
>     dsp.write(data)
>     dsp.close()
> 
> def test():
>     play_au_file(findfile('audiotest.au'))
> 
> test()

This doesn't work.  I don't really understand why.

For audiotest.au, |spec| is ("ULAW",2), which I don't think is right;
file(1) says 

audiotest.au: Sun/NeXT audio data: 8-bit ISDN u-law, mono, 8000 Hz

So I think this could be a bug in sunau.

The other data (au.getframerate(), au.getnchannels()) agrees with
file(1).

Anybody have a better idea?

Cheers,
Michael Hudson, BA (as of today! woohoo!)




From jeremy at beopen.com  Fri Jun 30 22:57:44 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 30 Jun 2000 16:57:44 -0400 (EDT)
Subject: [Python-Dev] last minute GC questions
Message-ID: <14685.2504.722378.79294@bitdiddle.concentric.net>

I've got two last minute questions.

Does it look to you like I checked in all of the changes that you and
Vladimir discussed?

Might we change the strategy for deciding when to collect?

There are two parts of the strategy that could probably change.  The
first is what kind of allocation events we count to determine when to
collect.  

Right now, the gc is counting the net effect of allocations and
deallocations.  This isn't effective for at least a couple of cases.
If we allocate N objects and don't deallocate anything, then no
garbage is going to be created.  If we have many objects currently
allocated and then dealloc N objects without allocating any, we could
create collectible garbage, but the collector won't run because there
haven't been any allocations.

It seems to me that counting deallocations only would be more
effective.  It is only the deallocations that cause a live object to
become garbage.

The other part of the strategy that might be changed is the collection
frequency.  Right now, the threshold is 100 net allocations &
dealloactions.  On the compiler benchmark, this leads to some 2600
collections, which seems like a lot.  (I have no idea why it seems
like a lot, but it does.)

I experimented with a policy that runs the collected every N
deallocations (not counting deallocations the occur during a
collection).  I set N == 1000 and got 1600 collections on the compiler
benchmark.  

There is only a small speedup (just a few percent), so maybe this
change doesn't have a big effect.  I don't recall much about the
cost/complexity of various GC approaches.

Jeremy



From nascheme at enme.ucalgary.ca  Fri Jun 30 23:12:06 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 15:12:06 -0600
Subject: [Python-Dev] Re: last minute GC questions
In-Reply-To: <14685.2504.722378.79294@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jun 30, 2000 at 04:57:44PM -0400
References: <14685.2504.722378.79294@bitdiddle.concentric.net>
Message-ID: <20000630151206.A10333@acs.ucalgary.ca>

On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote:
> I've got two last minute questions.
> 
> Does it look to you like I checked in all of the changes that you and
> Vladimir discussed?

Nope.

  Neil


Index: 0.13/Include/objimpl.h
*** 0.13/Include/objimpl.h Fri, 30 Jun 2000 13:05:40 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644)
--- 0.13(w)/Include/objimpl.h Fri, 30 Jun 2000 15:09:51 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644)
***************
*** 204,209 ****
--- 204,211 ----
  	(PyVarObject *) PyObject_MALLOC( _PyObject_VAR_SIZE((typeobj),(n)) ),\
  	(typeobj), (n)) )
  
+ #define PyObject_DEL(op) PyObject_FREE(op)
+ 
  /* This example code implements an object constructor with a custom
     allocator, where PyObject_New is inlined, and shows the important
     distinction between two steps (at least):
***************
*** 242,248 ****
     PyObject_{New, VarNew, Del} to manage the memory.  Set the type flag
     Py_TPFLAGS_GC and define the type method tp_recurse.  You should also
     add the method tp_clear if your object is mutable.  Include
!    PyGC_INFO_SIZE in the calculation of tp_basicsize.  Call
     PyObject_GC_Init after the pointers followed by tp_recurse become
     valid (usually just before returning the object from the allocation
     method.  Call PyObject_GC_Fini before those pointers become invalid
--- 244,250 ----
     PyObject_{New, VarNew, Del} to manage the memory.  Set the type flag
     Py_TPFLAGS_GC and define the type method tp_recurse.  You should also
     add the method tp_clear if your object is mutable.  Include
!    PyGC_HEAD_SIZE in the calculation of tp_basicsize.  Call
     PyObject_GC_Init after the pointers followed by tp_recurse become
     valid (usually just before returning the object from the allocation
     method.  Call PyObject_GC_Fini before those pointers become invalid
***************
*** 255,261 ****
  #define PyObject_GC_Fini(op)
  #define PyObject_AS_GC(op) (op)
  #define PyObject_FROM_GC(op) (op)
- #define PyObject_DEL(op) PyObject_FREE(op)
   
  #else
  
--- 257,262 ----
***************
*** 289,295 ****
  /* Get the object given the PyGC_Head */
  #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1))
  
! #define PyObject_DEL(op) PyObject_FREE( PyObject_IS_GC(op) ? \
  					(ANY *)PyObject_AS_GC(op) : \
  					(ANY *)(op) )
  
--- 290,297 ----
  /* Get the object given the PyGC_Head */
  #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1))
  
! #undef PyObject_DEL
! #define PyObject_DEL(op) PyObject_FREE( (op && PyObject_IS_GC(op)) ? \
  					(ANY *)PyObject_AS_GC(op) : \
  					(ANY *)(op) )
  
Index: 0.13/Objects/object.c
*** 0.13/Objects/object.c Fri, 30 Jun 2000 13:05:40 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644)
--- 0.13(w)/Objects/object.c Fri, 30 Jun 2000 15:05:26 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644)
***************
*** 192,205 ****
  	PyObject *op;
  {
  #ifdef WITH_CYCLE_GC
! 	if (PyType_IS_GC(op->ob_type)) {
! 		PyGC_Head *g = PyObject_AS_GC(op);
! 		PyObject_FREE(g);
! 	} else
! #endif
! 	{
! 		PyObject_FREE(op);
  	}
  }
  
  #ifndef WITH_CYCLE_GC
--- 192,202 ----
  	PyObject *op;
  {
  #ifdef WITH_CYCLE_GC
! 	if (op && PyType_IS_GC(op->ob_type)) {
! 		op = (PyObject *) PyObject_AS_GC(op);
  	}
+ #endif
+ 	PyObject_FREE(op);
  }
  
  #ifndef WITH_CYCLE_GC



From effbot at telia.com  Fri Jun 30 23:20:20 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 23:20:20 +0200
Subject: [Python-Dev] Windows build issues
References: <20000630135052.A405@acs.ucalgary.ca>  <200006302133.QAA20696@cj20424-a.reston1.va.home.com>
Message-ID: <044b01bfe2d9$01dcee60$f2a6b5d4@hagrid>

guido wrote:

> > PC/config.h 
> > 
> >     VC++ 5.0 will not compile python20 unless "#include
> >     <basetsd.h>" is commented out.  Trent?
> 
> I'll leave this to Trent -- I don't know how to check for VC 5.0
> vs. 6.0.

#if _MSC_VER >= 1200
    VC 6.0
#else
    VC 5.0 or earlier    
#endif

(we added a similar workaround to Python/thread_nt.c)

> > Also, I get a few warnings when compiling.  One is about an /IZ
> > (I think) option being ignored.  There are a few other warnings
> > as well which I didn't write down.
> 
> Probably 6.0 flags that 5.0 doesn't have.  What can we do?

ignore it, for now.  I remember seeing a few type warnings, but
nothing critical.  there's plenty of time to sort that out on the
way to 2.0 final.

</F>




From effbot at telia.com  Fri Jun 30 23:24:06 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 23:24:06 +0200
Subject: [Python-Dev] Idle breakage
References: <20000630143148.A9725@acs.ucalgary.ca>
Message-ID: <046a01bfe2d9$88302360$f2a6b5d4@hagrid>

neil wrote:


> Caused by _sre perhaps?
> 
> ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt
>         [line 21]: 'width= 80\012'

probably; I'll dig into this.

when's the 2.0 deadline?

</F>




From nascheme at enme.ucalgary.ca  Fri Jun 30 23:30:08 2000
From: nascheme at enme.ucalgary.ca (Neil Schemenauer)
Date: Fri, 30 Jun 2000 15:30:08 -0600
Subject: [Python-Dev] Fwd: Re: last minute GC questions
Message-ID: <20000630153008.C10333@acs.ucalgary.ca>

Oops, should have cc python-dev.

----- Forwarded message from Neil Schemenauer <nascheme at enme.ucalgary.ca> -----

Date: Fri, 30 Jun 2000 15:27:48 -0600
From: Neil Schemenauer <nascheme at enme.ucalgary.ca>
Subject: Re: last minute GC questions
To: Jeremy Hylton <jeremy at beopen.com>
X-Url: http://www.enme.ucalgary.ca/~nascheme/

On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote:
> Might we change the strategy for deciding when to collect?

We might. :)

> It seems to me that counting deallocations only would be more
> effective.  It is only the deallocations that cause a live object to
> become garbage.

You can easily run out of memory with that strategy though:

    N = 10000
    while 1:
        l = []
        for i in xrange(N):
            l.append([])
        l[0] = l

You only get a couple of deallocations while a large amount of
garbage is created.  Think of large cyclic structures like graphs
being created and then becoming garbage due to one deallocation.
By counting the net new objects we guarantee that this doesn't
happen.

> The other part of the strategy that might be changed is the collection
> frequency.  Right now, the threshold is 100 net allocations &
> dealloactions.  On the compiler benchmark, this leads to some 2600
> collections, which seems like a lot.  (I have no idea why it seems
> like a lot, but it does.)

Try setting the threshold to zero.  The major part of the GC
overhead does not seem to be running the collector.  OTOH, the
frequency could probably be decreased without the risk of running
out of memory.  No Python applications currently exist that
create that amount of garbage anyhow.

  Neil

----- End forwarded message -----



From effbot at telia.com  Fri Jun 30 23:39:26 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Fri, 30 Jun 2000 23:39:26 +0200
Subject: [Python-Dev] Idle breakage
References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid>
Message-ID: <049601bfe2db$acea1380$f2a6b5d4@hagrid>

I wrote:

> > Caused by _sre perhaps?
> > 
> > ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt
> >         [line 21]: 'width= 80\012'
> 
> probably; I'll dig into this.

confirmed.  SRE implements $ exactly as described in
the library reference, RE doesn't ;-)

patch coming within 30 minutes.

</F>




From bwarsaw at beopen.com  Fri Jun 30 23:57:19 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 17:57:19 -0400 (EDT)
Subject: [Python-Dev] Odd behavior with `make test'
References: <14684.57622.9807.868551@anthem.concentric.net>
	<038601bfe2bf$31c52da0$f2a6b5d4@hagrid>
Message-ID: <14685.6079.779817.674190@anthem.concentric.net>

>>>>> "FL" == Fredrik Lundh <effbot at telia.com> writes:

    FL> the rest looks a bit scary, to say the least.  does someone
    FL> (sre?)  overwrite something? does anyone have purify (dmalloc,
    FL> fences, whatever) within reach?

I will very soon.  I found a Solaris box on which I could load up an
eval copy of Purify.  Will report back soon.

-Barry