From jim.jewett at eds.com  Tue Jun  1 00:10:22 2004
From: jim.jewett at eds.com (Jewett, Jim J)
Date: Tue Jun  1 00:11:07 2004
Subject: [Python-Dev] RE: Python-Dev Digest, Vol 10, Issue 52
Message-ID: <B8CDFB11BB44D411B8E600508BDF076C1E96D4FB@usahm010.exmi01.exch.eds.com>

"Martin v. L?wis" <martin@v.loewis.de>:

> It is not surprising the patches haven't seen any
> comments: We get way more patches than we can handle
> these days. If you want to help, please review patches
> of other people, and recommend adaption or rejection.

I doubt I'm the only one who assumed that anything but
a change suggestion would be counterproductive; that it
would just be adding a "me too" that slowed down the 
person who could actually check the patch in.

If reviews from anyone are welcome, it wouldn't hurt 
to mention that a few more places.  Ideally, it would
be in the:

(1)  boilerplate that you see when looking at a patch
(2)  boilerplate at the top of a list of patches
<URL: http://sourceforge.net/tracker/?group_id=5470&atid=305470 >
(3)  developer documentation.  (I can sort of find it in 
<URL: http://www.python.org/dev/dev_intro.html#helping-out >, 
but didn't see it until I was already looking specifically 
for information on patch reviews.)
(4)  pre-announce for a new alpha release.

-jJ


From pje at telecommunity.com  Tue Jun  1 00:27:08 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue Jun  1 00:25:50 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <200406010317.i513Hvv22066@guido.python.org>
References: <Your message of "Mon, 31 May 2004 20:37:09 EDT."
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>

At 08:17 PM 5/31/04 -0700, Guido van Rossum wrote:
> > If soft-switching is portable (i.e. pure C, no assembly), and is
> > exposed as a library module (so that Jython et al can avoid
> > supporting it), then perhaps a PEP for adding that functionality to
> > mainstream Python would be meaningful.
>
>Anything that can be supported by a pure extension module is fair game
>IMO.  But it was my understanding that Stackless requires changes to
>the VM.

I did mean *exposed* as a library module, not implemented as one.  I am 
aware of the VM change.


>   And I definitely don't want people to get into a habit of
>writing code that relies on deep recursion that is only supported by
>Stackless, only to find that it doesn't work in Jython etc.

 From the docs of sys.setrecursionlimit():

"""The highest possible limit is platform-dependent. A user may need to set 
the limit higher when she has a program that requires deep recursion and a 
platform that supports a higher limit. This should be done with care, 
because a too-high limit can lead to a crash."""

Seems to me that the platform-specific nature of this is already established.


> > If that gets in, then the other 5% can always sneak in later via
> > feature creep.  ;) Or, more importantly (if I understand correctly),
> > it could be separately distributed as an add-on for platforms that
> > can support it.
>
>Hey, that's what Stackless already does.  Why is that approach
>suddenly not good enough any more?

I didn't say that.  I was just suggesting that if people had specific 
features of Stackless that they wanted to see in CPython, that it would be 
best for them to write a PEP specifically addressing the desired 
feature(s), rather than asking "why isn't CPython stackless?"


From guido at python.org  Tue Jun  1 00:31:41 2004
From: guido at python.org (Guido van Rossum)
Date: Tue Jun  1 00:31:49 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: Your message of "Tue, 01 Jun 2004 00:27:08 EDT."
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com> 
References: <Your message of "Mon, 31 May 2004 20:37:09 EDT."
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com> 
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com> 
Message-ID: <200406010431.i514Vfs22302@guido.python.org>

> >Anything that can be supported by a pure extension module is fair
> >game IMO.  But it was my understanding that Stackless requires
> >changes to the VM.
> 
> I did mean *exposed* as a library module, not implemented as one.  I
> am aware of the VM change.

Well, if it's going to be a commonly required feature, it better be
implementable in Jython etc. too.

> >   And I definitely don't want people to get into a habit of
> >writing code that relies on deep recursion that is only supported by
> >Stackless, only to find that it doesn't work in Jython etc.
> 
>  From the docs of sys.setrecursionlimit():
> 
> """The highest possible limit is platform-dependent. A user may need
> to set the limit higher when she has a program that requires deep
> recursion and a platform that supports a higher limit. This should
> be done with care, because a too-high limit can lead to a crash."""
> 
> Seems to me that the platform-specific nature of this is already
> established.

But in practice the current limit is pretty similar across platforms.
If some platforms support virtually infinite and others stick to the
common 1000 or so, that is definitely not sticking to the intent of
the law, even if it is to the letter.

> > > If that gets in, then the other 5% can always sneak in later via
> > > feature creep.  ;) Or, more importantly (if I understand correctly),
> > > it could be separately distributed as an add-on for platforms that
> > > can support it.
> >
> >Hey, that's what Stackless already does.  Why is that approach
> >suddenly not good enough any more?
> 
> I didn't say that.  I was just suggesting that if people had
> specific features of Stackless that they wanted to see in CPython,
> that it would be best for them to write a PEP specifically
> addressing the desired feature(s), rather than asking "why isn't
> CPython stackless?"

I think the bar should be raised pretty high for Stackless, given the
various objections that have been raised against it (x86-only code, no
Jython support, arbitrary exceptions, murky semantics, to name a few).

Together, the answer as to "why" should be pretty clean by now.

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

From martin at v.loewis.de  Tue Jun  1 00:34:02 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue Jun  1 00:34:10 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <40BBC924.6000803@stackless.com>
References: <20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de> <40BBC924.6000803@stackless.com>
Message-ID: <40BC073A.2030708@v.loewis.de>

Christian Tismer wrote:
>>> I'm believe that map and filter are non-recursive
> 
> 
> They have been. They can be, again, but why.

I'm not saying they should be non-recursive; I was just claiming
that they weren't, and that they would trigger "hard" switching.

> I don't know the C++ exception mechanism. It it walks the whole stack
> once before taking an action, then this is a problem.
> If it does proper unwinding of C frames, I could probably play the
> game and restore things just in time.

I'm unsure also; this is part of the Visual C++ runtime (or perhaps
even of the system's "structured EH"). In my coroutine library, the
application would crash even if there was an exception handler that
could have been found without walking the entire stack.

> Anyway, I don't really get the point.
> 95% of Stackless is doing soft-switched stackless calls.

My point is that Stackless 3.0 is probably not acceptable for
integration into C Python because of the processor-specific
assembler fragments.

> The discussion, as often before, tries to find out why it is *not*
> possible to include Stackless, instead of finding out the useful
> parts which could be supported with relatively small impact.
> This is why Stackless exists, and will continue to exist.

That's because people always ask the question "Can it be included?"
They never ask "If I were to contribute this and that part, would
it be accepted?".

Actually, this thread *started* with the question "Why isn't Python
stackless?" to which the correct answer is "Because nobody has
contributed patches." Only then people get excited and think that
Stackless 3.0 would be part of Python 2.5.

Regards,
Martin


From martin at v.loewis.de  Tue Jun  1 00:55:23 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue Jun  1 00:55:28 2004
Subject: [Python-Dev] doctest improvements
In-Reply-To: <20040531235745.GA29629@dave@alana.ucc.usyd.edu.au>
References: <40BB7414.9030304@gradient.cis.upenn.edu>
	<40BB82F8.4070906@v.loewis.de>
	<20040531235745.GA29629@dave@alana.ucc.usyd.edu.au>
Message-ID: <40BC0C3B.5050607@v.loewis.de>

Dave Harrison wrote:
> I'm interested in getting involved in python dev, how do you go about
> reviewing patches etc ?

Pick a patch that interests you, and that hasn't seen any comments
(if you run out of those, consider patches that have comments and
appear to have fizzled out). For these patches:
- check whether they are formally complete, i.e. whether they
   include test cases and documentation.
- check whether they actually work. Apply them, and run the
   test suite. At some point, run the entire Python test suite,
   to see whether they break anything else.
- if they are bug fixes, check whether they actually fix the
   bug they claim to fix (if they claim to fix bugs but don't
   actually state which bug they fix, make the submitter explain
   the problem first)
- if they add new features, determine:
   a) whether the feature could have negative effects on existing
      code, and
   b) whether the feature is desirable in your POV
- review the actual code:
   a) check whether it follows the style guide
   b) if it is C code, check for common mistakes, e.g. refcounting
      bugs
   c) check whether tricky aspects are properly commented
   d) check whether there are any border cases that would need
      consideration
When you have done your analysis, put your report as a comment
into the patch. This could be one of three outcomes:
a) the patch is acceptable
b) the patch should be rejected
c) the patch is acceptable in principle, and needs more work,
    or is just incomplete (so it needs more work but hasn't been
    fully reviewed)

For cases a) and b), if you have a list of five or so patches,
post them to python-dev, asking for somebody to commit the
a)-cases, and close the b)-cases as rejected.

For case c), see whether the author is willing to follow up.
If not, ping the author again after two months or so. If the
author is still not responsive, consider completing the patch
for yourself. If you find that the patch is not important
enough, consider rejection (I often do that, assuming that
somebody will do the work eventually if the feature is really
desired).

> I'm sure this question has been asked a million times before, but is
> there a list of things that need to be done ?

It's not that often asked as I'd like to, so I'm happy to answer it
every time it comes up. However, people have also added text to
the web pages summarizing these principles, at

http://www.python.org/dev/dev_intro.html

in the section "Helping out".

Regards,
Martin


From martin at v.loewis.de  Tue Jun  1 00:57:42 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue Jun  1 00:57:49 2004
Subject: [Python-Dev] doctest improvements
In-Reply-To: <40BBC9A2.9080002@gradient.cis.upenn.edu>
References: <40BB7414.9030304@gradient.cis.upenn.edu>
	<40BB82F8.4070906@v.loewis.de>
	<40BBC9A2.9080002@gradient.cis.upenn.edu>
Message-ID: <40BC0CC6.9040102@v.loewis.de>

Edward Loper wrote:
> I thought that it would be more efficient to get feedback on whether the 
> patch is a good idea before writing the docs & tests.  But I guess that 
> that's now how things are done w/ Python development.  I'll go ahead and 
> add test cases & docs, and update the patches.

It's more efficient for the patch submitter, but less efficient for the
reviewer, because the reviewer needs to spend more time understanding
the patch in detail. Therefore, patches that are formally complete get
better attention; patches where the author couldn't find the time to
write documentation might never get reviewed.

Regards,
Martin


From martin at v.loewis.de  Tue Jun  1 01:11:00 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue Jun  1 01:11:04 2004
Subject: [Python-Dev] anonymous cvs checkout
In-Reply-To: <40BBD304.9000904@gradient.cis.upenn.edu>
References: <40BBD304.9000904@gradient.cis.upenn.edu>
Message-ID: <40BC0FE4.7080808@v.loewis.de>

Edward Loper wrote:
> I'm having trouble checking out an anonymous copy of the Python CVS 
> repository.  I tried the instructions from both the developer FAQ and 
> the SF CVS page; and tried checking it out from debian, win2k, and OS X. 
>  In all cases, I get an error that looks something like this:
> 
>     cvs server: cannot read file in mydbm_load_file: Input/output error
>     cvs checkout: in directory .:
>     cvs [checkout aborted]: *PANIC* administration files missing
> 
> A google search for "mydbm_load_file" didn't turn up anything useful. 
> Anyone have an idea what's going wrong?  Thanks!

It appears SF broke anonymous CVS. This has already been reported, e.g.
as

http://sourceforge.net/tracker/index.php?func=detail&aid=963875&group_id=1&atid=200001

Regards,
Martin


From martin at v.loewis.de  Tue Jun  1 01:20:11 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue Jun  1 01:20:16 2004
Subject: [Python-Dev] RE: Python-Dev Digest, Vol 10, Issue 52
In-Reply-To: <B8CDFB11BB44D411B8E600508BDF076C1E96D4FB@usahm010.exmi01.exch.eds.com>
References: <B8CDFB11BB44D411B8E600508BDF076C1E96D4FB@usahm010.exmi01.exch.eds.com>
Message-ID: <40BC120B.1030700@v.loewis.de>

Jewett, Jim J wrote:
> I doubt I'm the only one who assumed that anything but
> a change suggestion would be counterproductive; that it
> would just be adding a "me too" that slowed down the 
> person who could actually check the patch in.

Indeed, adding just "me too" would not be helpful. Instead,
one should add a message: I made such and such tests, they
all passed, I could not find any flaws in the code, and
recommend approval. This would actually help the reviewer.

> If reviews from anyone are welcome, it wouldn't hurt 
> to mention that a few more places.  Ideally, it would
> be in the:

I'd rather prefer potential reviewers actually ask
how they could help, or atleast read

http://www.python.org/dev/dev_intro.html

> (3)  developer documentation.  (I can sort of find it in 
> <URL: http://www.python.org/dev/dev_intro.html#helping-out >, 
> but didn't see it until I was already looking specifically 
> for information on patch reviews.)

But is it asked too much to read a text "Intro to development"?

My experience is that very few people actually get active
and review patches, even after they learn that they can on
python-dev.

Anyway, if you want to see boilerplate text, propose specific
wording, and I'll add that.

Regards,
Martin


From kbk at shore.net  Tue Jun  1 01:34:20 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Tue Jun  1 01:34:24 2004
Subject: [Python-Dev] Weekly Python Bug/Patch Summary
Message-ID: <200406010534.i515YKiZ023952@hydra.localdomain>


Patch / Bug Summary
___________________

Patches :  280 open ( +5) /  2391 closed (+11) /  2671 total (+16)
Bugs    :  775 open (+22) /  4058 closed (+11) /  4833 total (+33)
RFE     :  137 open ( +4) /   127 closed ( +1) /   264 total ( +5)

New / Reopened Patches
______________________

use PyOS_ReadlineFunctionPointer in non-interractive input   (2004-05-18)
       http://python.org/sf/955928  opened by  Gregory Lielens 

imaplib.IMAP4_SSL: changed quadratic read() code to linear  (2004-05-18)
CLOSED http://python.org/sf/956394  opened by  Carl Howells 

Allow compilation of C/C++ Python extensions without MSVC  (2004-05-19)
       http://python.org/sf/957033  opened by  Connelly 

Improved hash for tuples  (2004-05-20)
       http://python.org/sf/957122  opened by  Yitz Gale 

Patch for feature request 491033  (2004-05-19)
       http://python.org/sf/957240  opened by  Josiah Carlson 

Generator Objects  (2004-05-20)
       http://python.org/sf/957398  opened by  James William Pye 

Fix for bugs relating to ntpath.expanduser()  (2004-05-20)
       http://python.org/sf/957650  opened by  Josiah Carlson 

Arrange 64bits detection for ReliantUnix  (2004-05-24)
       http://python.org/sf/959534  opened by  Jean-frederic Clere 

sdist versus SVN  (2004-05-24)
CLOSED http://python.org/sf/959726  opened by  Tim Peters 

unblock signals in threads  (2004-05-25)
       http://python.org/sf/960406  opened by  Andrew Langmead 

Make IDLE's paragraph reformatting width configurable  (2004-05-27)
       http://python.org/sf/961387  opened by  Raymond Hettinger 

New Misc/RPM/python-2.3.spec file  (2004-05-27)
CLOSED http://python.org/sf/961465  opened by  Sean Reifschneider 

locale.getdefaultlocale fails with empty env. variable  (2004-05-28)
       http://python.org/sf/962487  opened by  Matthias Klose 

East Asian Width support for Unicode  (2004-05-29)
       http://python.org/sf/962502  opened by  Hye-Shik Chang 

New module cookielib  (2004-05-31)
CLOSED http://python.org/sf/963318  opened by  John J Lee 

New module cookielib  (2004-05-31)
       http://python.org/sf/963318  reopened by  jjlee

Unicode email address helper  (2004-06-01)
       http://python.org/sf/963906  opened by  Stuart Bishop 

Patches Closed
______________

ConfigParser.read() should return list of files read  (2003-01-30)
       http://python.org/sf/677651  closed by  fdrake

imaplib.IMAP4_SSL: changed quadratic read() code to linear  (2004-05-19)
       http://python.org/sf/956394  closed by  pierslauder

generator expression implementation  (2004-01-07)
       http://python.org/sf/872326  closed by  rhettinger

sdist versus SVN  (2004-05-24)
       http://python.org/sf/959726  closed by  tim_one

synchronous signals blocked in pthreads  (2004-05-06)
       http://python.org/sf/949332  closed by  mwh

Linux signals during threads  (2004-05-05)
       http://python.org/sf/948614  closed by  langmead

New Misc/RPM/python-2.3.spec file  (2004-05-27)
       http://python.org/sf/961465  closed by  loewis

Remove ROT_FOUR  (2004-04-04)
       http://python.org/sf/929502  closed by  bcannon

New module cookielib  (2004-05-31)
       http://python.org/sf/963318  closed by  loewis

New module cookielib  (2004-05-31)
       http://python.org/sf/963318  closed by  loewis

doctest: suggest the use of rawstrings for backslashes  (2004-04-10)
       http://python.org/sf/932930  closed by  loewis

doctest: add an option to end examples w/ dedent  (2004-04-10)
       http://python.org/sf/932933  closed by  tim_one

New / Reopened Bugs
___________________

Nested generator terminates prematurely  (2004-05-18)
CLOSED http://python.org/sf/955772  opened by  Yitz Gale 

PyDateTime_Check macro unusable  (2004-05-18)
CLOSED http://python.org/sf/955985  opened by  Jon Willeke 

csv.writer refuses a variable parameter  (2004-05-18)
CLOSED http://python.org/sf/956246  opened by  Xavier BASSERY 

Potential data corruption bug in save_pers in pickle module.  (2004-05-18)
       http://python.org/sf/956303  opened by  Allan Crooks 

Simplifiy coding in cmd.py  (2004-05-18)
       http://python.org/sf/956408  opened by  Raymond Hettinger 

RFE: Extend smtplib.py with support for LMTP  (2004-05-19)
       http://python.org/sf/957003  opened by  Leif Hedstrom 

C/C++ extensions w/ Python + Mingw (Windows)  (2004-05-20)
       http://python.org/sf/957198  opened by  Connelly 

bdist_rpm fails on redhat9, fc1, fc2  (2004-05-20)
       http://python.org/sf/957381  opened by  Jeff Epler 

os.lseek() doesn't work  (2004-05-20)
CLOSED http://python.org/sf/957485  opened by  michal cernoevic 

SocketServer module documentation misleading  (2004-05-20)
       http://python.org/sf/957505  opened by  Jon Giddy 

logging functionality non-intuitive, levels confusing  (2004-05-21)
       http://python.org/sf/958180  opened by  Jason R. Coombs 

PythonIDE crashes on very large scripts folder  (2004-05-24)
       http://python.org/sf/959291  opened by  Jack Jansen 

Implicit close() should check for errors  (2004-05-24)
       http://python.org/sf/959379  opened by  Peter Åstrand 

Can't build Python on POSIX w/o $HOME  (2004-05-24)
       http://python.org/sf/959576  opened by  Barry A. Warsaw 

"require <feature>" configure option  (2004-05-25)
       http://python.org/sf/960325  opened by  Hallvard B Furuseth 

Poor documentation of new-style classes  (2004-05-25)
       http://python.org/sf/960340  opened by  Hallvard B Furuseth 

grammar for "class" inheritance production slightly wrong  (2004-05-25)
       http://python.org/sf/960448  opened by  Jim Jewett 

botched html for index subheadings  (2004-05-26)
       http://python.org/sf/960860  opened by  Jim Jewett 

codecs.lookup can raise exceptions other than LookupError  (2004-05-26)
CLOSED http://python.org/sf/960874  opened by  John Ehresman 

test_zlib is too slow  (2004-05-26)
       http://python.org/sf/960995  opened by  Michael Hudson 

Text.edit_modified() fails  (2004-05-27)
       http://python.org/sf/961805  opened by  Eric P. 

Python 2.3.4 on Linux: test test_grp failed  (2004-05-28)
       http://python.org/sf/962226  opened by  Michael Ströder 

Konqueror can't render docs because of malformed HTML  (2004-05-28)
       http://python.org/sf/962442  opened by  Klaus-J Wolf 

PyModule_AddIntConstant documented to take an int, not a lon  (2004-05-28)
       http://python.org/sf/962471  opened by  Matthias Klose 

misspelling -- warngin -> warning  (2004-05-29)
CLOSED http://python.org/sf/962602  opened by  Evil Mr Henry 

Typo in Lib/test/test_sax.py can confuse  (2004-05-29)
       http://python.org/sf/962631  opened by  Bryan Blackburn 

macfs and macostools tests fail on UFS  (2004-05-29)
       http://python.org/sf/962633  opened by  Bryan Blackburn 

when both maintainer and author provided, author discarded  (2004-05-29)
       http://python.org/sf/962772  opened by  John Belmonte 

2.3.4 can not be installed over 2.3.3  (2004-05-29)
       http://python.org/sf/962918  opened by  Jarek Zgoda 

Multiple Metaclass inheritance limitation  (2004-05-30)
       http://python.org/sf/963246  opened by  Greg Chapman 

Acroread aborts printing PDF documentation  (2004-05-30)
       http://python.org/sf/963321  opened by  Howard B. Golden 

packman upgrade issue  (2004-05-31)
       http://python.org/sf/963494  opened by  Ronald Oussoren 

Distutils should be able to produce Debian packages (.deb)  (2004-05-31)
       http://python.org/sf/963825  opened by  Kaleissin 

There ought to be a way to uninstall  (2004-05-31)
       http://python.org/sf/963845  opened by  Kaleissin 

Bad error mesage when subclassing a module  (2004-06-01)
       http://python.org/sf/963956  opened by  Edward C. Jones 

Bugs Closed
___________

Support for non-string data in ConfigParser unclear/buggy  (2003-09-22)
       http://python.org/sf/810843  closed by  fdrake

ConfigParser.getint failure on 2.3.3  (2003-12-21)
       http://python.org/sf/864063  closed by  zgoda

Config parser don't raise DuplicateSectionError when reading  (2003-10-26)
       http://python.org/sf/830449  closed by  fdrake

Nested generator terminates prematurely  (2004-05-18)
       http://python.org/sf/955772  closed by  rhettinger

PyDateTime_Check macro unusable  (2004-05-18)
       http://python.org/sf/955985  closed by  willeke

csv.writer refuses a variable parameter  (2004-05-18)
       http://python.org/sf/956246  closed by  balthus

Generator expression used in doc example  (2004-05-10)
       http://python.org/sf/951270  closed by  rhettinger

stringprep.py:  sets.Set() --> set()   (2004-05-06)
       http://python.org/sf/949329  closed by  arigo

os.lseek() doesn't work  (2004-05-20)
       http://python.org/sf/957485  closed by  loewis

codecs.lookup can raise exceptions other than LookupError  (2004-05-26)
       http://python.org/sf/960874  closed by  lemburg

Don't define _SGAPI on IRIX  (2003-04-27)
       http://python.org/sf/728330  closed by  mwh

1==float('nan')  (2004-02-17)
       http://python.org/sf/899109  closed by  mwh

misspelling -- warngin -> warning  (2004-05-29)
       http://python.org/sf/962602  closed by  doerwalter

New / Reopened RFE
__________________

Implement BundleBuilder GUI as plugin component  (2004-05-20)
       http://python.org/sf/957652  opened by  has 

old/new class documentation  (2004-05-25)
       http://python.org/sf/960454  opened by  Jim Jewett 

Add an updating load function in pickle  (2004-05-26)
       http://python.org/sf/960821  opened by  Nicolas Fleury 

overall index to distributed documentation  (2004-05-26)
       http://python.org/sf/960845  opened by  Jim Jewett 

RFE Closed
__________

int object need more informative error message  (2004-02-29)
       http://python.org/sf/906746  closed by  nascheme


From michel at dialnetwork.com  Tue Jun  1 02:59:49 2004
From: michel at dialnetwork.com (Michel Pelletier)
Date: Tue Jun  1 04:57:13 2004
Subject: [Python-Dev] PEP 330 Python bytecode verification
Message-ID: <200406010159.49433.michel@dialnetwork.com>


I have written up a rough draft PEP on bytecode verification:

http://www.python.org/peps/pep-0330.html

I also have a sketch implementation written in Python that I have uploaded:

http://www.daca.net:8080/verify.tgz

This implementation does not really work yet, and there are only a couple of 
unit tests, mostly because I am not a bytecode expert, but I think the 
framework is pretty close to being usable and I'm getting a better grasp on 
the issue.  It is based on the algorithm posted by Phillip Eby, and feedback 
on it would be great.

-Michel

From cm at leetspeak.org  Tue Jun  1 07:03:36 2004
From: cm at leetspeak.org (Michael Walter)
Date: Tue Jun  1 06:57:52 2004
Subject: [Python-Dev] PEP 330 Python bytecode verification
In-Reply-To: <200406010159.49433.michel@dialnetwork.com>
References: <200406010159.49433.michel@dialnetwork.com>
Message-ID: <40BC6288.7080106@leetspeak.org>

Hello Michel,

Michel Pelletier wrote:
> I have written up a rough draft PEP on bytecode verification:
> 
> http://www.python.org/peps/pep-0330.html
just allow me a quick remark:
   (len(co_code) < sizeof(unsigned char) - 1)
==
   (len(co_code) < 0)
which might not be what you want. I suppose you are aiming for an 
expression involving UCHAR_MAX.

Thanks,
Michael

> I also have a sketch implementation written in Python that I have uploaded:
> 
> http://www.daca.net:8080/verify.tgz
> 
> This implementation does not really work yet, and there are only a couple of 
> unit tests, mostly because I am not a bytecode expert, but I think the 
> framework is pretty close to being usable and I'm getting a better grasp on 
> the issue.  It is based on the algorithm posted by Phillip Eby, and feedback 
> on it would be great.
> 
> -Michel
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/cm%40leetspeak.org
> 


From tismer at stackless.com  Tue Jun  1 08:02:27 2004
From: tismer at stackless.com (Christian Tismer)
Date: Tue Jun  1 08:00:59 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <40BC073A.2030708@v.loewis.de>
References: <20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de> <40BBC924.6000803@stackless.com>
	<40BC073A.2030708@v.loewis.de>
Message-ID: <40BC7053.8040306@stackless.com>

Martin v. L?wis wrote:

> My point is that Stackless 3.0 is probably not acceptable for
> integration into C Python because of the processor-specific
> assembler fragments.

Ok, that can be dropped and put into an extension.

>> The discussion, as often before, tries to find out why it is *not*
>> possible to include Stackless, instead of finding out the useful
>> parts which could be supported with relatively small impact.
>> This is why Stackless exists, and will continue to exist.
> 
> 
> That's because people always ask the question "Can it be included?"
> They never ask "If I were to contribute this and that part, would
> it be accepted?".
> 
> Actually, this thread *started* with the question "Why isn't Python
> stackless?" to which the correct answer is "Because nobody has
> contributed patches." Only then people get excited and think that
> Stackless 3.0 would be part of Python 2.5.

I didn't understand the question this way, although it was probably
meant so. For me it was more like "why doesn't it aim for Stackless'
features". Although I'm trying to make Stackless as clean and
compatible as possible, I'm not trying to have my current version
ready for inclusion. Development is more influenced by user requests.

I think, the heart of the thing is to decide whether Python wants
to go the way to make as much as possible calls non-recursive.
This is a lot of work, and I did one possible implementation,
which minimized changes to the rest of the system.
If we try to modify Python to be stackless, we would probably
got more rigorous ways and change more of the design. I can't
do that alone. I doubt that anybody would be able to create
such a re-design alone, while keeping up with Python development,
that does quite much in the opposite direction.
This must become a goal of the core developer group.

all the best - chris
-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Tue Jun  1 08:19:38 2004
From: tismer at stackless.com (Christian Tismer)
Date: Tue Jun  1 08:18:03 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <200406010431.i514Vfs22302@guido.python.org>
References: <Your message of "Mon, 31 May 2004 20:37:09
	EDT."	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<40BBA2B8.7000907@v.loewis.de>	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
Message-ID: <40BC745A.7070700@stackless.com>

Guido van Rossum wrote:

>>>Anything that can be supported by a pure extension module is fair
>>>game IMO.  But it was my understanding that Stackless requires
>>>changes to the VM.

As Armin has shown, it is possible to do the hard switching approach
as a pure extension module.
But that's the opposite of what I want. I want a supportive core
without the need to fiddle with C stacks.
That needs VM changes. Cheating and supplying a different VM
as an extension module is probably no option? :-)

>>>Hey, that's what Stackless already does.  Why is that approach
>>>suddenly not good enough any more?

Philip:

>>I didn't say that.  I was just suggesting that if people had
>>specific features of Stackless that they wanted to see in CPython,
>>that it would be best for them to write a PEP specifically
>>addressing the desired feature(s), rather than asking "why isn't
>>CPython stackless?"

Guido:

> I think the bar should be raised pretty high for Stackless, given the
> various objections that have been raised against it (x86-only code, no
> Jython support, arbitrary exceptions, murky semantics, to name a few).

Huh? There is support for 8 or more platforms, and I'm not addressing
the assembly parts.
It is most probably possible to implement soft-switchign in Jython.
No idea what you mean by arbitrary exceptions (I never had that)
or what's wrong with semantics. On the latter: Well, this is a pure
interface issue. I don't say that everybody must love tasklets,
there are other approaches and interfaces possible.
But they all rely on the non-recursive interpreter core, and that's
the point, IMHO.

> Together, the answer as to "why" should be pretty clean by now.

If you understand the question like "why is current Stackless
not included", that's true. I understood it more like the more
advanced question "why does Python still block itself from
lightweight threading by keping state on the C stack".

ciao - chris
-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Tue Jun  1 08:44:58 2004
From: tismer at stackless.com (Christian Tismer)
Date: Tue Jun  1 08:43:22 2004
Subject: [Python-Dev] Why aren't more things weak referencable
In-Reply-To: <200406010315.i513F8E22050@guido.python.org>
References: <000001c4461b$1fa22d80$e841fea9@oemcomputer>
	<200405302204.i4UM4hb19989@guido.python.org>
	<40BBC48E.6030405@stackless.com>
	<200406010315.i513F8E22050@guido.python.org>
Message-ID: <40BC7A4A.2040204@stackless.com>

Guido van Rossum wrote:

>>Same here. I would not vote to make strings or tuples or any other
>>tiny type weak-reffed in the first place.
>>Instead I would add the possible support to derived types, via
>>the __slot__ mechanism for instance.
>>There is a little coding necessary to make the generic code
>>handle the case of var-sized objects, but this is doable
>>and not very complicated.
>>
>>This may be really needed or not. if we can create the rule
>>"every derived type *can* have weak-refs", this is simpler
>>to memorize than "well, most can, some cannot".
> 
> 
> With some (considerable?) effort, slots on var-sized objects can
> certainly be supported -- the same approach as used for __dict__
> should work.  I expect it might slow down the normal case a bit,
> unless you define a new descriptor type just for this.

Yes, I didn't recognize the tricky implementation until you
said this. _PyObject_GetDictPtr looks at the end of the
object if type->tp_dictoffset is < 0.
This would become more complicated in the presence of weakref
and other slots. Well, fairly, they would simply all store
their offset from the end of the object.

A not so costly approach could be to change slots a little:
The slot offset is now computed on the beginning of the
object's structure. There could be either a type flag that
says "you must add an offset", or a new type slot which is either
a function that computes and additional offset, or NULL.
It would probably even suffice to check if varsize is nonzero
and then do a little computation to bump the offset.

cheers - chris
-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From guido at python.org  Tue Jun  1 09:26:31 2004
From: guido at python.org (Guido van Rossum)
Date: Tue Jun  1 09:26:36 2004
Subject: [Python-Dev] PEP 330 Python bytecode verification
In-Reply-To: Your message of "Tue, 01 Jun 2004 01:59:49 CDT."
	<200406010159.49433.michel@dialnetwork.com> 
References: <200406010159.49433.michel@dialnetwork.com> 
Message-ID: <200406011326.i51DQVf23041@guido.python.org>

> I have written up a rough draft PEP on bytecode verification:
> 
> http://www.python.org/peps/pep-0330.html
> 
> I also have a sketch implementation written in Python that I have uploaded:
> 
> http://www.daca.net:8080/verify.tgz
> 
> This implementation does not really work yet, and there are only a
> couple of unit tests, mostly because I am not a bytecode expert, but
> I think the framework is pretty close to being usable and I'm
> getting a better grasp on the issue.  It is based on the algorithm
> posted by Phillip Eby, and feedback on it would be great.

Shouldn't at least the MAKE_CLOSURE opcode be changed before we move
forward with this?

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

From mlist at asesoft.ro  Tue Jun  1 09:21:41 2004
From: mlist at asesoft.ro (MailingList)
Date: Tue Jun  1 09:29:12 2004
Subject: [Python-Dev] (no subject)
Message-ID: <003b01c447db$606a5dd0$7560a8c0@asesoft.intl>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20040601/92176305/attachment.html
From guido at python.org  Tue Jun  1 09:34:20 2004
From: guido at python.org (Guido van Rossum)
Date: Tue Jun  1 09:34:25 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: Your message of "Tue, 01 Jun 2004 14:19:38 +0200."
	<40BC745A.7070700@stackless.com> 
References: <Your message of "Mon, 31 May 2004 20:37:09 EDT."
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org> 
	<40BC745A.7070700@stackless.com> 
Message-ID: <200406011334.i51DYKF23071@guido.python.org>

> That needs VM changes. Cheating and supplying a different VM
> as an extension module is probably no option? :-)

Not unless you can write it in Java or C# as well.  C-only hacks are
not welcome.

> > I think the bar should be raised pretty high for Stackless, given
> > the various objections that have been raised against it (x86-only
> > code, no Jython support, arbitrary exceptions, murky semantics, to
> > name a few).
> 
> Huh? There is support for 8 or more platforms, and I'm not addressing
> the assembly parts.

OK, that's good news.

> It is most probably possible to implement soft-switchign in Jython.

That's a rather vague statement; I'd like to hear from Samuele about
that.

> No idea what you mean by arbitrary exceptions (I never had that)

I meant exceptions to the general rules.  Like, you can't depend on
tasklet switching when you use one of these extensions, or one of
these built-ins, or ...

> or what's wrong with semantics.

Last time we (PythonLabs) looked at this, there were many murky rules
that were difficult to explain except by looking at the accidents of
the implementation.  I take it you have removed all that?

> On the latter: Well, this is a pure interface issue. I don't say
> that everybody must love tasklets, there are other approaches and
> interfaces possible.  But they all rely on the non-recursive
> interpreter core, and that's the point, IMHO.

Is it really just tasklets that the users want?  Then maybe we should
focus on adding tasklets to Jython too, so as to understand the
requirements and limitations of the approach better outside the
context of a C implementation.  (Jython must remain 100% pure Java.)

> > Together, the answer as to "why" should be pretty clean by now.
> 
> If you understand the question like "why is current Stackless
> not included", that's true.

That started the thread, yes.

> I understood it more like the more advanced question "why does
> Python still block itself from lightweight threading by keping state
> on the C stack".

IMO mostly because Python wants to be friendly to extensions written
in C or C++, including those that frequently call back into Python.

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

From amk at amk.ca  Tue Jun  1 10:32:43 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Tue Jun  1 10:33:09 2004
Subject: [Python-Dev] Python bug day?
Message-ID: <20040601143243.GB18424@rogue.amk.ca>

For the impending 2.4alpha1 release, a coordinated effort to reduce
the bug backlog would be good.  Several other projects (Zope, GNOME,
Mozilla) have "bug days" in which people meet on IRC and go through
the bug database, closing irrelevant or incorrect reports, writing
small test cases for vague reports, etc.  

Holding a Python bug day seems worth a try.  I've written up a Wiki
page, http://www.python.org/cgi-bin/moinmoin/PythonBugDay, to begin
planning a bug day and to figure out what tools (if any) are required.
Please comment, particularly if you've participated in bug days for
Zope or other projects.  Do we need transcripts of the IRC channel?
Should we use #python or a new channel?  

If the details can get sorted out in time, perhaps we can have a bug
day as soon as this weekend.  Is a weekend day better than a weekday
for people who are interested in participating?

--amk

From tjreedy at udel.edu  Tue Jun  1 10:52:48 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue Jun  1 10:53:03 2004
Subject: [Python-Dev] Re: doctest improvements
References: <200406010203.i5123EaN026869@gradient.cis.upenn.edu>
	<40BBF4C4.2090204@gradient.cis.upenn.edu>
Message-ID: <c9i584$b8e$1@sea.gmane.org>


"Edward Loper" <edloper@gradient.cis.upenn.edu> wrote in message
news:40BBF4C4.2090204@gradient.cis.upenn.edu...
> Tim Peters wrote:
> > That's more what I had in mind, but if the marker is changed to
something
> > wordy instead of "a magic character", I don't think the dedent trick is
of
> > much value anymore:
> >
> >      r"""
> >      A different marker:
> >
> >              >>> print 'a\n\nb'
> >              a
> >              <blank line>
> >              b
> >      """
> >
> > Then when the expected output is (exactly) "<blank line>", doctest
would
> > accept "<blank line>", or a line with nothing other than whitespace, as
a
> > match.  I can't get upset by that bit of ambiguity.
>
> I had ruled this out because I assumed that any change I made had to
> maintain backward compatibility.  But if this (minor) incompatibility is
> acceptable, then let me know and I'll write up a patch to implement it.

To me as a potential user, '<blank line>' is the uniquely obvious marker
for a blank line.  The ambiguity is fine; having it uniquely not match
itself and therefore needing a special case escape mechanism would be
worse.  I think the explanation "<blank line> matches a blank line as well
as itself" might be sufficient.

Terry J. Reedy




From jiwon at softwise.co.kr  Tue Jun  1 11:48:40 2004
From: jiwon at softwise.co.kr (Jiwon Seo)
Date: Tue Jun  1 11:42:33 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <20040601143243.GB18424@rogue.amk.ca>
References: <20040601143243.GB18424@rogue.amk.ca>
Message-ID: <40BCA558.8020301@softwise.co.kr>

Sounds great to me.
One question, though. What need to be done, when several issues are 
dicussed at the same time making it hard to participate in the 
dicussion? Make a branch-channel? Or it just doesn't happen? How did 
Zope people solve it?

Regards, jiwon.

A.M. Kuchling wrote:

>For the impending 2.4alpha1 release, a coordinated effort to reduce
>the bug backlog would be good.  Several other projects (Zope, GNOME,
>Mozilla) have "bug days" in which people meet on IRC and go through
>the bug database, closing irrelevant or incorrect reports, writing
>small test cases for vague reports, etc.  
>
>Holding a Python bug day seems worth a try.  I've written up a Wiki
>page, http://www.python.org/cgi-bin/moinmoin/PythonBugDay, to begin
>planning a bug day and to figure out what tools (if any) are required.
>Please comment, particularly if you've participated in bug days for
>Zope or other projects.  Do we need transcripts of the IRC channel?
>Should we use #python or a new channel?  
>
>If the details can get sorted out in time, perhaps we can have a bug
>day as soon as this weekend.  Is a weekend day better than a weekday
>for people who are interested in participating?
>
>--amk
>
>_______________________________________________
>Python-Dev mailing list
>Python-Dev@python.org
>http://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe: http://mail.python.org/mailman/options/python-dev/jiwon%40softwise.co.kr
>
>
>  
>


From tim.one at comcast.net  Tue Jun  1 11:55:08 2004
From: tim.one at comcast.net (Tim Peters)
Date: Tue Jun  1 11:55:27 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <20040601143243.GB18424@rogue.amk.ca>
Message-ID: <mailman.280.1086105327.6944.python-dev@python.org>

[A.M. Kuchling]
> For the impending 2.4alpha1 release, a coordinated effort to reduce the
> bug backlog would be good.  Several other projects (Zope, GNOME, Mozilla)
> have "bug days" in which people meet on IRC and go through the bug
> database, closing irrelevant or incorrect reports, writing small test
> cases for vague reports, etc.
>
> Holding a Python bug day seems worth a try.  I've written up a Wiki page,
> http://www.python.org/cgi-bin/moinmoin/PythonBugDay, to begin planning a
> bug day and to figure out what tools (if any) are required. Please
> comment, particularly if you've participated in bug days for Zope or
> other projects.

A bug day is an excellent idea.  In the Zope world, it's the only way any
bugs get fixed <wink>.

> Do we need transcripts of the IRC channel?

When a bug gets closed or rejected, and the OP protests, it can be useful to
paste snippets of the IRC session wherein the issue was discussed.  Most
people save their own transcripts for this purpose.  Don't see a need for
"an official" transcript.

> Should we use #python or a new channel?

No opinion.

> If the details can get sorted out in time, perhaps we can have a bug day
> as soon as this weekend.  Is a weekend day better than a weekday for
> people who are interested in participating?

A weekday would be impossible for at least me and Fred.



From lists at andreas-jung.com  Tue Jun  1 12:05:15 2004
From: lists at andreas-jung.com (Andreas Jung)
Date: Tue Jun  1 12:05:22 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <20040601155748.76983200029@service-web.de>
References: <20040601155748.76983200029@service-web.de>
Message-ID: <ADD048BB6550E53B1DC93098@[192.168.0.100]>



--On Dienstag, 1. Juni 2004 11:55 Uhr -0400 Tim Peters 
<tim.one@comcast.net> wrote:

> [A.M. Kuchling]
>> For the impending 2.4alpha1 release, a coordinated effort to reduce the
>> bug backlog would be good.  Several other projects (Zope, GNOME, Mozilla)
>> have "bug days" in which people meet on IRC and go through the bug
>> database, closing irrelevant or incorrect reports, writing small test
>> cases for vague reports, etc.
>>
>> Holding a Python bug day seems worth a try.  I've written up a Wiki page,
>> http://www.python.org/cgi-bin/moinmoin/PythonBugDay, to begin planning a
>> bug day and to figure out what tools (if any) are required. Please
>> comment, particularly if you've participated in bug days for Zope or
>> other projects.
>
> A bug day is an excellent idea.  In the Zope world, it's the only way any
> bugs get fixed <wink>.

That's really not true :-) There is always a looser standing up to early in 
the morning
fixing some bugs.

Andreas




From pje at telecommunity.com  Tue Jun  1 12:21:00 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue Jun  1 12:19:12 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <200406011334.i51DYKF23071@guido.python.org>
References: <Your message of "Tue,
	01 Jun 2004 14:19:38 +0200." <40BC745A.7070700@stackless.com>
	<Your message of "Mon, 31 May 2004 20:37:09 EDT."
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
Message-ID: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>

At 06:34 AM 6/1/04 -0700, Guido van Rossum wrote:
> > It is most probably possible to implement soft-switchign in Jython.
>
>That's a rather vague statement; I'd like to hear from Samuele about
>that.

Me too.  The only thing I've heard of in Java that does lightweight 
co-operative task switching, is actually implemented using a Java VM 
written in Java.  Sort of like PyPy, only I guess you'd call it 
JavaJava.  :)  I don't remember the name of it right off, just that it was 
a commercial product that claimed they had a patent pending.


> > No idea what you mean by arbitrary exceptions (I never had that)
>
>I meant exceptions to the general rules.  Like, you can't depend on
>tasklet switching when you use one of these extensions, or one of
>these built-ins, or ...

Perhaps it would be better if it were defined in terms of where it *does* 
work, rather than where it doesn't.  For example, one can write 
co-operative multitasking code in CPython now using generators...  but it 
only works if you have "generators all the way down".  That is, any code in 
a task that calls a generator must itself be a generator.  That's a pretty 
comprehensible rule, albeit draconian to follow.  Adding soft-switching 
would change the rule to be, "you can switch as long as you haven't been 
called from C code."  That is, you haven't been called from *any* built-in 
or extension module.

Speaking as someone who's written some significant event-driven 
co-operative multitasking code using generators, I would say that going 
from "generators all the way down" to "Python all the way down" would be a 
huge improvement in flexibility.


> > On the latter: Well, this is a pure interface issue. I don't say
> > that everybody must love tasklets, there are other approaches and
> > interfaces possible.  But they all rely on the non-recursive
> > interpreter core, and that's the point, IMHO.
>
>Is it really just tasklets that the users want?

I am not currently a Stackless user, but if I were to try it, tasklets 
would be my primary interest.  I don't actually think that the higher 
recursion limit is a "feature", for two reasons: 1) Python loops run a lot 
faster than function calls, and 2) every time I've ever gotten an error 
from excessive recursion, it was because I'd accidentally created an 
infinite recursion.  So, to me, lifting the default recursion limit in 
standard Python would be a really *bad* idea.

The other feature besides tasklets that I find potentially interesting is 
thread pickling.  I'm intrigued by the possibility of using them to create 
"long-running tasks".  That is, workflow using Python scripts to define the 
loops, branches, etc. of the workflow.   But to make a really practical 
workflow system based on this, one would have to have a way of dealing with 
changes to the code that the running workflows were based on, so I don't 
know if that whole idea is really worth pursuing.  I would probably be 
better off basing such an animal on PyPy, because performance for the code 
in a long-running process workflow is a non-issue.

Anyway, I don't know about "the users" in general, but for me at least 
tasklets are where it's at.  :)  And I only care about explicit yielding, 
not thread-like concurrency.  (IOW, I don't want Stackless doing the 
scheduling, I'd want to be able to write my own scheduler, in pure Python.)


> > I understood it more like the more advanced question "why does
> > Python still block itself from lightweight threading by keping state
> > on the C stack".
>
>IMO mostly because Python wants to be friendly to extensions written
>in C or C++, including those that frequently call back into Python.

That would only disable task-switching within the called Python code, not 
from the code that called the extension.  And that, only if the 
hard-switching module wasn't available.


From amk at amk.ca  Tue Jun  1 12:20:51 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Tue Jun  1 12:21:06 2004
Subject: [Python-Dev] Python bug day?
References: <20040601143243.GB18424@rogue.amk.ca>
Message-ID: <20040601162051.GB19012@rogue.amk.ca>

On Tue, Jun 01, 2004 at 11:55:08AM -0400, Tim Peters wrote:
> A weekday would be impossible for at least me and Fred.

OK.  Something I had planned for this weekend is not going to happen,
so I'm free this weekend.  Is there anyone who wants to participate
who can't make Saturday?

None of the bug day documents I've found describe how participants
indicate which bugs they're working on.  Do people say "I'm working on
bug #9" in the IRC channel, or do they record their current bug in a
Wiki page or tool? Or is duplication of effort not a problem in
practice?

--amk

From nbastin at opnet.com  Tue Jun  1 12:29:09 2004
From: nbastin at opnet.com (Nick Bastin)
Date: Tue Jun  1 12:29:21 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <20040601143243.GB18424@rogue.amk.ca>
References: <20040601143243.GB18424@rogue.amk.ca>
Message-ID: <CF48AF58-B3E8-11D8-8EAA-000D932927FE@opnet.com>


On Jun 1, 2004, at 10:32 AM, A.M. Kuchling wrote:

> For the impending 2.4alpha1 release, a coordinated effort to reduce
> the bug backlog would be good.  Several other projects (Zope, GNOME,
> Mozilla) have "bug days" in which people meet on IRC and go through
> the bug database, closing irrelevant or incorrect reports, writing
> small test cases for vague reports, etc.
>
> Holding a Python bug day seems worth a try.  I've written up a Wiki
> page, http://www.python.org/cgi-bin/moinmoin/PythonBugDay, to begin
> planning a bug day and to figure out what tools (if any) are required.
> Please comment, particularly if you've participated in bug days for
> Zope or other projects.  Do we need transcripts of the IRC channel?
> Should we use #python or a new channel?
>
> If the details can get sorted out in time, perhaps we can have a bug
> day as soon as this weekend.  Is a weekend day better than a weekday
> for people who are interested in participating?

This sounds like a great idea.  Weekends would definitely be best.  
Maybe for ultimate flexibility it becomes a 'Bug fix weekend', and 
people can pop in and out as necessary.  If you can divine it from 
throwing the bones or something, we should try to pick a weekend when 
SF CVS is working.  Oh, wait...

--
Nick


From tjreedy at udel.edu  Tue Jun  1 12:40:42 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue Jun  1 12:40:59 2004
Subject: [Python-Dev] Re: Stackless Python
References: <Your message of "Mon, 31 May 2004 20:37:09
	EDT."<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com><40BBA2B8.7000907@v.loewis.de><20040530133843.51528.qmail@web50709.mail.yahoo.com><40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org><40BB7E63.9090304@v.loewis.de><A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com><40BB8882.60503@v.loewis.de><5611D758-B33E-11D8-9388-000A95686CD8@redivi.com><40BB9C17.20500@v.loewis.de><F8297E54-B346-11D8-9388-000A95686CD8@redivi.com><40BBA2B8.7000907@v.loewis.de><5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<200406010317.i513Hvv22066@guido.python.org>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
Message-ID: <c9ibie$uk4$1@sea.gmane.org>


"Phillip J. Eby" <pje@telecommunity.com> wrote in message
news:5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com...
>  I was just suggesting that if people had specific
> features of Stackless that they wanted to see in CPython, that it would
be
> best for them to write a PEP specifically addressing the desired
> feature(s), rather than asking "why isn't CPython stackless?"

I agree that a PEP would be more useful than the repeated question.

One criterion for adding a new module is a constituency of users.  One
thing that would help the Stackless in Python cause is more evidence that
it is useful in practice as well as in theory and expectation.  Even today,
the only thing I can find on the site is
"
Stackless has impressive applications, like:
  a.. Eve, an online massive multiplayer game by CCP Games
  b.. ? by Iron Port
"
Eve was listed two years ago and ? does not say much.  I went to the Eve
site, downloaded several videos, and from what was presented, was impressed
negatively, so it is not obviously to me an advertisement for Stackless. So
other examples, less costly to try out, might be more persuasive.

 Terry J. Reedy




From tim.one at comcast.net  Tue Jun  1 12:55:53 2004
From: tim.one at comcast.net (Tim Peters)
Date: Tue Jun  1 12:56:00 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <20040601162051.GB19012@rogue.amk.ca>
Message-ID: <mailman.284.1086108960.6944.python-dev@python.org>

[A.M. Kuchling]
> ...
> None of the bug day documents I've found describe how participants
> indicate which bugs they're working on.  Do people say "I'm working on
> bug #9" in the IRC channel, or do they record their current bug in a Wiki
> page or tool? Or is duplication of effort not a problem in practice?

Announce your intent on IRC.  It's helpful if someone volunteers to keep a
list of item numbers and the people working on them.  They have to pay
attention to IRC.  That person responds when someone says "I'm going to work
on 12345" -- "great", or "Bob has that one, please coordinate with him".  A
Wiki page may or may not be usable for this (depends on whether it drops
changes on the floor in case of overlapping edits); a Wiki page would
certainly work for this if a single person is in charge of keeping it up to
date.



From nbastin at opnet.com  Tue Jun  1 13:04:31 2004
From: nbastin at opnet.com (Nick Bastin)
Date: Tue Jun  1 13:04:44 2004
Subject: [Python-Dev] anonymous cvs checkout
In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F1304677EE1@its-xchg4.massey.ac.nz>
References: <1ED4ECF91CDED24C8D012BCF2B034F1304677EE1@its-xchg4.massey.ac.nz>
Message-ID: <BFAD45BA-B3ED-11D8-8EAA-000D932927FE@opnet.com>


On May 31, 2004, at 9:55 PM, Tony Meyer wrote:

> [Opps.  Forgot to include the list in my reply.  And those that read
> spambayes-dev will have seen this already.  Good grief.]
>
> [Edward Loper]
>> I'm having trouble checking out an anonymous copy of the Python CVS
>> repository.
>
> FWIW, neither a fresh checkout nor an update works here
> (WinXP), either, although (at least some) other sourceforge
> projects do.  ViewCVS doesn't work, either (shows an empty
> page), so it's certainly not just you.
>
> <http://cvs.sourceforge.net/viewcvs.py/python/>
>
> The SF site status does mention that there's maintenance scheduled (for
> tomorrow) - maybe that's relevant?  Does developer access still work?

It probably works with about the same frequency as anonymous access - I 
think the problem is with the SF boxen and connection in general, and 
not with any type of user in specific.  I'm getting about 450ms RTT to 
cvs.sf.net, with about 45% packet loss.  I was able to do a complete 
update of my 2.4 tree earlier in the day, but it had failed 4 or 5 
times before that, so it's just hit or miss, I think.

--
Nick


From chrism at plope.com  Tue Jun  1 13:37:09 2004
From: chrism at plope.com (Chris McDonough)
Date: Tue Jun  1 13:37:16 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <20040601143243.GB18424@rogue.amk.ca>
References: <20040601143243.GB18424@rogue.amk.ca>
Message-ID: <1086111429.2726.11.camel@localhost.localdomain>

On Tue, 2004-06-01 at 10:32, A.M. Kuchling wrote:
> Holding a Python bug day seems worth a try.  I've written up a Wiki
> page, http://www.python.org/cgi-bin/moinmoin/PythonBugDay, to begin
> planning a bug day and to figure out what tools (if any) are required.
> Please comment, particularly if you've participated in bug days for
> Zope or other projects.  Do we need transcripts of the IRC channel?
> Should we use #python or a new channel?  

FWIW, I would probably use a dedicated channel for bug day traffic (in
the zope world, we use #zope-dev for bug days as opposed to #zope). 
This prevents crosstalk between people trying to fix bugs and people
trying to get help on specific language usage.

For Zope bug days, we set the channel topic to a "bugfix list" where we
try to keep track of all the "resolved" bugs.  When someone starts
working on a particular issue, they announce it to the IRC channel ("I'm
going to work on 5416") and and "accept" the issue in the Zope
collector.    When someone fixes a bug, they add its issue number to the
IRC channel topic and close the bug in the collector.  The purpose of
the resolved-bugs-list in the topic is really to just get a sense of how
many bugs were fixed at the end of the day (we can't get that info out
of the Zope collector).

Bug days have been really useful in the Zope world.  Besides providing a
conduit to wrap up loose ends, it's also a great excuse for people who
are currently just users to become developers as they get a sense of
ownership over a bit of the code, especially when they are able to
submit a patch and have it evaluated and maybe committed in real time.

- C



From bac at OCF.Berkeley.EDU  Tue Jun  1 13:50:38 2004
From: bac at OCF.Berkeley.EDU (Brett C.)
Date: Tue Jun  1 13:50:52 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <20040601162051.GB19012@rogue.amk.ca>
References: <20040601143243.GB18424@rogue.amk.ca>
	<20040601162051.GB19012@rogue.amk.ca>
Message-ID: <40BCC1EE.7050700@ocf.berkeley.edu>

A.M. Kuchling wrote:

> On Tue, Jun 01, 2004 at 11:55:08AM -0400, Tim Peters wrote:
> 
>>A weekday would be impossible for at least me and Fred.
> 
> 
> OK.  Something I had planned for this weekend is not going to happen,
> so I'm free this weekend.  Is there anyone who wants to participate
> who can't make Saturday?
> 

Well, I am going to be out of town visiting my father this weekend (on 
top of finishing my final project for graphics; damn OpenGL and 
lighting).  And the following weekend I am going to be visiting friends 
out of town before I start working full-time.  After that I am available.

Perhaps we should hold another one of these for the beta?  That way any 
bugs or patches that require more feedback and testing from this bug day 
for the alpha can get it at another bug day.

As for telling who is working on a bug or patch, perhaps someone could 
write up an IRC bot?  Then people can just say ``<tracker #>: working`` 
and such, allowing people to query by asking ``<tracker #>: status`` and 
have it say who is currently working on it.  But I have no clue how 
feasible that is since I don't know how IRC works under the covers 
(heck, I barely know how to log on).

-Brett

From michel at dialnetwork.com  Tue Jun  1 12:51:10 2004
From: michel at dialnetwork.com (Michel Pelletier)
Date: Tue Jun  1 14:57:14 2004
Subject: [Python-Dev] PEP 330 Python bytecode verification
In-Reply-To: <200406011326.i51DQVf23041@guido.python.org>
References: <200406010159.49433.michel@dialnetwork.com>
	<200406011326.i51DQVf23041@guido.python.org>
Message-ID: <200406011151.10774.michel@dialnetwork.com>

On Tuesday 01 June 2004 08:26, Guido van Rossum wrote:

> Shouldn't at least the MAKE_CLOSURE opcode be changed before we move
> forward with this?

Certainly, currently the verify code doesn't handle it and only verifies 
really simple code.  I need to look at the MAKE_CLOSURE problem and put a 
section on it in the PEP, but I haven't gotten that far.

I released the PEP and code now to see if anyone else had any comments at this 
point.

-Michel

From greg at electricrain.com  Tue Jun  1 15:02:59 2004
From: greg at electricrain.com (Gregory P. Smith)
Date: Tue Jun  1 15:03:07 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <40BCC1EE.7050700@ocf.berkeley.edu>
References: <20040601143243.GB18424@rogue.amk.ca>
	<20040601162051.GB19012@rogue.amk.ca>
	<40BCC1EE.7050700@ocf.berkeley.edu>
Message-ID: <20040601190259.GA16828@zot.electricrain.com>

> As for telling who is working on a bug or patch, perhaps someone could 
> write up an IRC bot?  Then people can just say ``<tracker #>: working`` 
> and such, allowing people to query by asking ``<tracker #>: status`` and 
> have it say who is currently working on it.  But I have no clue how 
> feasible that is since I don't know how IRC works under the covers 
> (heck, I barely know how to log on).

I'd use one of the many irc bots already written in python as a basis
for such a thing, chump for example:

  http://usefulinc.com/chump/

Other nice ideas are to have the bot monitor the bug database (directly,
via bug emails or by screen scraping) and announce bug status changes
to the channel as well as being able to give the bot simple commands to
have it update bug status or assignment in the sf bug tracker.

anyways, enough with the bugbot brainstorm; i'd be impressed if someone
implemented a bugbot at all before the first bug day. ;)

-g

From amk at amk.ca  Tue Jun  1 15:29:10 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Tue Jun  1 15:29:20 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <20040601190259.GA16828@zot.electricrain.com>
References: <20040601143243.GB18424@rogue.amk.ca>
	<20040601162051.GB19012@rogue.amk.ca>
	<40BCC1EE.7050700@ocf.berkeley.edu>
	<20040601190259.GA16828@zot.electricrain.com>
Message-ID: <20040601192910.GA564@rogue.amk.ca>

On Tue, Jun 01, 2004 at 12:02:59PM -0700, Gregory P. Smith wrote
> anyways, enough with the bugbot brainstorm; i'd be impressed if someone
> implemented a bugbot at all before the first bug day. ;)

I could certainly set up a stock chumpbot before the bug day.  We
could then use it to record fixed bugs, and details about the fix.

--amk


From amk at amk.ca  Tue Jun  1 15:33:11 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Tue Jun  1 15:33:15 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <40BCC1EE.7050700@ocf.berkeley.edu>
References: <20040601143243.GB18424@rogue.amk.ca>
	<20040601162051.GB19012@rogue.amk.ca>
	<40BCC1EE.7050700@ocf.berkeley.edu>
Message-ID: <20040601193311.GB564@rogue.amk.ca>

On Tue, Jun 01, 2004 at 10:50:38AM -0700, Brett C. wrote:
> Perhaps we should hold another one of these for the beta?  That way any 
> bugs or patches that require more feedback and testing from this bug day 
> for the alpha can get it at another bug day.

If the first one is successful, we could have one every month until
2.4final.

--amk

From nas at arctrix.com  Tue Jun  1 15:53:54 2004
From: nas at arctrix.com (Neil Schemenauer)
Date: Tue Jun  1 15:53:59 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <20040601192910.GA564@rogue.amk.ca>
References: <20040601143243.GB18424@rogue.amk.ca>
	<20040601162051.GB19012@rogue.amk.ca>
	<40BCC1EE.7050700@ocf.berkeley.edu>
	<20040601190259.GA16828@zot.electricrain.com>
	<20040601192910.GA564@rogue.amk.ca>
Message-ID: <20040601195354.GA21677@mems-exchange.org>

On Tue, Jun 01, 2004 at 03:29:10PM -0400, A.M. Kuchling wrote:
> I could certainly set up a stock chumpbot before the bug day.  We
> could then use it to record fixed bugs, and details about the fix.

While the bot idea sounds cool, I would think a wiki page would be a
better interface.  OTOH, I'm not a regular user of IRC or of wikis,
so what do I know. :-)

  Neil

From tismer at stackless.com  Tue Jun  1 18:18:40 2004
From: tismer at stackless.com (Christian Tismer)
Date: Tue Jun  1 18:17:06 2004
Subject: [Python-Dev] Re: Stackless Python
In-Reply-To: <c9ibie$uk4$1@sea.gmane.org>
References: <Your message of "Mon, 31 May 2004
	20:37:09	EDT."<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com><40BBA2B8.7000907@v.loewis.de><20040530133843.51528.qmail@web50709.mail.yahoo.com><40BAE605.5040800@v.loewis.de>	<40BB6C9B.4040701@ieee.org><40BB7E63.9090304@v.loewis.de><A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com><40BB8882.60503@v.loewis.de><5611D758-B33E-11D8-9388-000A95686CD8@redivi.com><40BB9C17.20500@v.loewis.de><F8297E54-B346-11D8-9388-000A95686CD8@redivi.com><40BBA2B8.7000907@v.loewis.de><5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<200406010317.i513Hvv22066@guido.python.org>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<c9ibie$uk4$1@sea.gmane.org>
Message-ID: <40BD00C0.6010606@stackless.com>

Terry Reedy wrote:

> One criterion for adding a new module is a constituency of users.  One
> thing that would help the Stackless in Python cause is more evidence that
> it is useful in practice as well as in theory and expectation.  Even today,
> the only thing I can find on the site is
> "
> Stackless has impressive applications, like:
>   a.. Eve, an online massive multiplayer game by CCP Games
>   b.. ? by Iron Port
> "
> Eve was listed two years ago and ? does not say much.  I went to the Eve
> site, downloaded several videos, and from what was presented, was impressed
> negatively, so it is not obviously to me an advertisement for Stackless. So
> other examples, less costly to try out, might be more persuasive.

Why did you do that?
Would you download and try Zope, in order to judge about Python?
Would you say C is a bad language, because you (perhaps) don't like
Perl?
Last time I disliked a movie, I really thought celluloid is a bad idea.

These examples are shown to prove that Stackless has industrial
strength, nothing else. I'm no real fan of each application,
and I don't expect enthusiasm except from my kids, perhaps.

But I don't need kids as Stackless users.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Tue Jun  1 18:31:16 2004
From: tismer at stackless.com (Christian Tismer)
Date: Tue Jun  1 18:29:38 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
References: <Your message of "Tue, 01 Jun 2004 14:19:38 +0200."
	<40BC745A.7070700@stackless.com>	<Your message of "Mon,
	31 May 2004 20:37:09
	EDT."	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<40BBA2B8.7000907@v.loewis.de>	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
Message-ID: <40BD03B4.8010607@stackless.com>

Phillip J. Eby wrote:

> At 06:34 AM 6/1/04 -0700, Guido van Rossum wrote:
> 
>> > It is most probably possible to implement soft-switchign in Jython.
>>
>> That's a rather vague statement; I'd like to hear from Samuele about
>> that.

I believe it is doable, and I'll ask him. If java can use
something like function pointers, it is possible. If you have
to have compiled calls all the time, well, I did not invent Java,
and I don't want to know who was it. (Actually I do :)

Me:

>> > No idea what you mean by arbitrary exceptions (I never had that)
>>
>> I meant exceptions to the general rules.  Like, you can't depend on
>> tasklet switching when you use one of these extensions, or one of
>> these built-ins, or ...

This is out of date stuff, related to 2.0 where everything was
hard-switched. Soft-switching has none of these problems.
Hard switching between tasklets doesn't have this, too, provided
that you don't leave a context without a consistent exception state.
I do this consistently with Python: never leaving a Python exception
around across a switch, everything is packed up. If a user tells me
about a problem in the context of C++ exceptions, I will build
the necessary framework to make this consistent. it just didn't happen,
yet.
But in the general case, there is nothing like this. If you switch
between tasklets, this is like switching between threads. If your
code tries to access stack memory from a different thread while
running your thread, your code is flawed, not Stackless.

...

Philip:

> Anyway, I don't know about "the users" in general, but for me at least 
> tasklets are where it's at.  :)  And I only care about explicit 
> yielding, not thread-like concurrency.  (IOW, I don't want Stackless 
> doing the scheduling, I'd want to be able to write my own scheduler, in 
> pure Python.)

You can have it both, some like auto-scheduling, most dislike it
(as I do). This is all configurable at runtime, and by default,
nothing is scheduled unless you explicitly ask for it.

>> > I understood it more like the more advanced question "why does
>> > Python still block itself from lightweight threading by keping state
>> > on the C stack".
>>
>> IMO mostly because Python wants to be friendly to extensions written
>> in C or C++, including those that frequently call back into Python.
> 
> That would only disable task-switching within the called Python code, 
> not from the code that called the extension.  And that, only if the 
> hard-switching module wasn't available.

Exactly. A tasklet can always tell whether it is on top-level, or
if there is some C code sitting on its stack. If you know that this C
code can stand a stack switch, you can switch. If not, you shouldn't
do it. This is just a little more power, to be used with care.
In Stackless 1.0, and in Python still, you simply can't do it.

But this is all irrelevant for a possible inclusion of parts of
Stackless: These would for sure avoid all hardware issues and
just do the innocent "avoid the stack" thing, raising an exception
if a switch on a C stack bound context is attempted.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From aahz at pythoncraft.com  Tue Jun  1 22:18:13 2004
From: aahz at pythoncraft.com (Aahz)
Date: Tue Jun  1 22:18:16 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <DE1CF2B4FEC4A342BF62B6B2B334601E56215B@opus.amorhq.net>
References: <DE1CF2B4FEC4A342BF62B6B2B334601E56215B@opus.amorhq.net>
Message-ID: <20040602021813.GA21957@panix.com>

On Mon, May 31, 2004, Robert Brewer wrote:
>
> Quite similar to my current "pet peeve":
> 
> >>> None > 3
> False
> >>> None > 'hoopy'
> False
> >>> None > True
> False
> >>> None > datetime.date(2004, 5, 31)
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> TypeError: can't compare datetime.date to NoneType
> 
> ...writing an O-R mapper, this particular hobgoblin bites me rather often ;)

Time for you to bite the bullet.  Guido has all-but-decreed that the
future of comparisons is that TypeError will be raised for all operators
other than == and <> for types that have no appropriate relationship
system.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha

From fumanchu at amor.org  Tue Jun  1 22:42:17 2004
From: fumanchu at amor.org (Robert Brewer)
Date: Tue Jun  1 22:45:46 2004
Subject: [Python-Dev] RE: Comparing heterogeneous types
Message-ID: <DE1CF2B4FEC4A342BF62B6B2B334601E56217B@opus.amorhq.net>

Aahz wrote:
> On Mon, May 31, 2004, Robert Brewer wrote:
> >
> > Quite similar to my current "pet peeve":
> > 
> > >>> None > 3
> > False
> > >>> None > 'hoopy'
> > False
> > >>> None > True
> > False
> > >>> None > datetime.date(2004, 5, 31)
> > Traceback (most recent call last):
> >   File "<interactive input>", line 1, in ?
> > TypeError: can't compare datetime.date to NoneType
> > 
> > ...writing an O-R mapper, this particular hobgoblin bites 
> me rather often ;)
> 
> Time for you to bite the bullet.  Guido has all-but-decreed that the
> future of comparisons is that TypeError will be raised for 
> all operators
> other than == and <> for types that have no appropriate relationship
> system.

...which is fine. I'll end up either disallowing None as a legal value,
or making a NO_VALUE singleton for which I can customize comparisons.
Either is a better design choice IMO; I just haven't been forced into
the choice yet. ;)


Robert Brewer
MIS
Amor Ministries
fumanchu@amor.org

From skip at pobox.com  Tue Jun  1 13:10:59 2004
From: skip at pobox.com (Skip Montanaro)
Date: Tue Jun  1 23:31:08 2004
Subject: [Python-Dev] Re: Stackless Python
References: <Your message of
Message-ID: <loom.20040601T190938-767@post.gmane.org>

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

> Sort of like PyPy, only I guess you'd call it JavaJava.  :)

You meant JaJa, right? <wink>

Skip



From pje at telecommunity.com  Wed Jun  2 01:14:53 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed Jun  2 01:13:06 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <40BD03B4.8010607@stackless.com>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<Your message of "Tue,
	01 Jun 2004 14:19:38 +0200." <40BC745A.7070700@stackless.com>
	<Your message of "Mon, 31 May 2004 20:37:09
	EDT."	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>

At 12:31 AM 6/2/04 +0200, Christian Tismer wrote:
>Phillip J. Eby wrote:
>
>>At 06:34 AM 6/1/04 -0700, Guido van Rossum wrote:
>>
>>> > It is most probably possible to implement soft-switchign in Jython.
>>>
>>>That's a rather vague statement; I'd like to hear from Samuele about
>>>that.
>
>I believe it is doable, and I'll ask him. If java can use
>something like function pointers, it is possible.

There are various things that correspond to function pointers.  Sort 
of.  You'll need to be a bit more specific than that.


>  If you have
>to have compiled calls all the time, well, I did not invent Java,
>and I don't want to know who was it. (Actually I do :)

Keep in mind that Jython *compiles* Python code to Java bytecodes.  It is 
*not* a Python interpreter written in Java.  I suspect this will severely 
limit the applicable approaches.

Googling "Java co-operative multitasking" and "Java asynchronous methods" 
turns up plenty of hits on people who are trying to figure out how to do 
them, but not much about any successes.  :)  Indeed, the only thing I've 
ever run into that does it, is that commercial system I mentioned, which 
does it by writing a Java VM in Java, so they can control its execution.  I 
don't think that idea will go over very well with the Jython team.  :)


From bob at redivi.com  Wed Jun  2 01:37:59 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Jun  2 01:38:10 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com> <Your
	message of "Tue,
	01 Jun 2004 14:19:38 +0200." <40BC745A.7070700@stackless.com> <Your
	message of "Mon, 31 May 2004 20:37:09
	EDT."	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
Message-ID: <0272635E-B457-11D8-9821-000A95686CD8@redivi.com>


On Jun 2, 2004, at 1:14 AM, Phillip J. Eby wrote:

> At 12:31 AM 6/2/04 +0200, Christian Tismer wrote:
>>  If you have
>> to have compiled calls all the time, well, I did not invent Java,
>> and I don't want to know who was it. (Actually I do :)
>
> Keep in mind that Jython *compiles* Python code to Java bytecodes.  It 
> is *not* a Python interpreter written in Java.  I suspect this will 
> severely limit the applicable approaches.
>
> Googling "Java co-operative multitasking" and "Java asynchronous 
> methods" turns up plenty of hits on people who are trying to figure 
> out how to do them, but not much about any successes.  :)  Indeed, the 
> only thing I've ever run into that does it, is that commercial system 
> I mentioned, which does it by writing a Java VM in Java, so they can 
> control its execution.  I don't think that idea will go over very well 
> with the Jython team.  :)

Well the tasklet/channel model of Stackless is a single threaded 
version of CSP, which has at least one Java implementation:
http://wotug.kent.ac.uk/parallel/languages/java/jcsp/

If you add a bunch of extra mutexes, then it could act just like 
Stackless (no actual concurrency).

That, of course, doesn't cover every single function that the Stackless 
API currently exposes, but tasklets/channels are the raison d'etre.  
You don't really need the other functions (or at least, I haven't 
needed them).

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040602/b7b8f3e6/smime.bin
From martin at v.loewis.de  Wed Jun  2 01:58:53 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed Jun  2 01:59:01 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<40BC745A.7070700@stackless.com> <Your	message of "Mon, 31 May 2004
	20:37:09	EDT."	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<40BBA2B8.7000907@v.loewis.de>	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
Message-ID: <40BD6C9D.90003@v.loewis.de>

Bob Ippolito wrote:
> Well the tasklet/channel model of Stackless is a single threaded version 
> of CSP, which has at least one Java implementation:
> http://wotug.kent.ac.uk/parallel/languages/java/jcsp/

However, JCSP uses java.lang.Threads to implement concurrency. So they
are completely unlike Stackless' tasklets in their implementation
strategy.

> That, of course, doesn't cover every single function that the Stackless 
> API currently exposes, but tasklets/channels are the raison d'etre.

That sounds strange. I would have expected that the reason for Stackless
Python is to have no stack, not to have tasklets.

If you only wanted tasklets, you could implement them on top of threads,
without any need for extensions.

Regards,
Martin


From bob at redivi.com  Wed Jun  2 03:35:39 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Jun  2 03:35:51 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <40BD6C9D.90003@v.loewis.de>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<40BC745A.7070700@stackless.com> <Your	message of "Mon, 31 May 2004
	20:37:09	EDT."	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<40BBA2B8.7000907@v.loewis.de>	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
Message-ID: <7224D932-B467-11D8-9821-000A95686CD8@redivi.com>


On Jun 2, 2004, at 1:58 AM, Martin v. L?wis wrote:

> Bob Ippolito wrote:
>> Well the tasklet/channel model of Stackless is a single threaded 
>> version of CSP, which has at least one Java implementation:
>> http://wotug.kent.ac.uk/parallel/languages/java/jcsp/
>
> However, JCSP uses java.lang.Threads to implement concurrency. So they
> are completely unlike Stackless' tasklets in their implementation
> strategy.

So what, if the API is the same?

>> That, of course, doesn't cover every single function that the 
>> Stackless API currently exposes, but tasklets/channels are the raison 
>> d'etre.
>
> That sounds strange. I would have expected that the reason for 
> Stackless
> Python is to have no stack, not to have tasklets.
>
> If you only wanted tasklets, you could implement them on top of 
> threads,
> without any need for extensions.

You're kidding, right?

Using the stack or not is an implementation detail, what matters is 
having more control over the flow of your programs in a reasonably 
efficient manner.  It just so happens that the recursive evaluation in 
CPython uses the stack in such a way that makes these kind of 
constructs impossible, so it needed to be changed for Stackless.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040602/79fde72a/smime.bin
From mwh at python.net  Wed Jun  2 05:26:04 2004
From: mwh at python.net (Michael Hudson)
Date: Wed Jun  2 05:26:14 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <40BCC1EE.7050700@ocf.berkeley.edu> (Brett C.'s message of
	"Tue, 01 Jun 2004 10:50:38 -0700")
References: <20040601143243.GB18424@rogue.amk.ca>
	<20040601162051.GB19012@rogue.amk.ca>
	<40BCC1EE.7050700@ocf.berkeley.edu>
Message-ID: <2maczmz4yb.fsf@starship.python.net>

"Brett C." <bac@OCF.Berkeley.EDU> writes:

> As for telling who is working on a bug or patch, perhaps someone could
> write up an IRC bot?  Then people can just say ``<tracker #>:
> working`` and such, allowing people to query by asking ``<tracker #>:
> status`` and have it say who is currently working on it.  But I have
> no clue how feasible that is since I don't know how IRC works under
> the covers (heck, I barely know how to log on).

Pah, I went from being in that state to having an IRC bot written
using Twisted in about an hour and a half (and I didn't know a lot
about Twisted beforehand either).  It's not hard.

Cheers,
mwh

-- 
6. Symmetry is a complexity-reducing concept (co-routines include
   subroutines); seek it everywhere.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

From mwh at python.net  Wed Jun  2 05:29:34 2004
From: mwh at python.net (Michael Hudson)
Date: Wed Jun  2 05:29:43 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <20040601162051.GB19012@rogue.amk.ca> (A. M. Kuchling's message
	of "Tue, 1 Jun 2004 12:20:51 -0400")
References: <20040601143243.GB18424@rogue.amk.ca>
	<20040601162051.GB19012@rogue.amk.ca>
Message-ID: <2m65aaz4sh.fsf@starship.python.net>

"A.M. Kuchling" <amk@amk.ca> writes:

> On Tue, Jun 01, 2004 at 11:55:08AM -0400, Tim Peters wrote:
>> A weekday would be impossible for at least me and Fred.
>
> OK.  Something I had planned for this weekend is not going to happen,
> so I'm free this weekend.  Is there anyone who wants to participate
> who can't make Saturday?

I'll be at or around EuroPython this saturday, pypy-sprinting, but can
probably keep a head in any IRC channel (and we don't want to do this
in #python, let's use #python-dev or go to #python-bug-day or
something).

Cheers,
mwh

-- 
  The only problem with Microsoft is they just have no taste.
              -- Steve Jobs, (From _Triumph of the Nerds_ PBS special)
                                and quoted by Aahz on comp.lang.python

From mwh at python.net  Wed Jun  2 05:46:31 2004
From: mwh at python.net (Michael Hudson)
Date: Wed Jun  2 05:46:46 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <40BD6C9D.90003@v.loewis.de> (
	=?iso-8859-1?q?Martin_v._L=F6wis's_message_of?= "Wed,
	02 Jun 2004 07:58:53 +0200")
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com> <Your
	message of "Mon, 31 May 2004 20:37:09 EDT."
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
Message-ID: <2m1xkyz408.fsf@starship.python.net>

"Martin v. L?wis" <martin@v.loewis.de> writes:

> Bob Ippolito wrote:
>> Well the tasklet/channel model of Stackless is a single threaded
>> version of CSP, which has at least one Java implementation:
>> http://wotug.kent.ac.uk/parallel/languages/java/jcsp/
>
> However, JCSP uses java.lang.Threads to implement concurrency. So they
> are completely unlike Stackless' tasklets in their implementation
> strategy.
>
>> That, of course, doesn't cover every single function that the
>> Stackless API currently exposes, but tasklets/channels are the
>> raison d'etre.
>
> That sounds strange. I would have expected that the reason for Stackless
> Python is to have no stack, not to have tasklets.

*BZZZZZZZZZZT*!

:-)

Cheers,
mwh

-- 
  First of all, email me your AOL password as a security measure. You
  may find that won't be able to connect to the 'net for a while. This
  is normal. The next thing to do is turn your computer upside down
  and shake it to reboot it.                     -- Darren Tucker, asr

From jeremy at alum.mit.edu  Wed Jun  2 07:54:10 2004
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed Jun  2 07:54:16 2004
Subject: [Python-Dev] pre-announce: Python 2.4a1 is about a month away
In-Reply-To: <40BB5196.7070207@interlink.com.au>
References: <40BB5196.7070207@interlink.com.au>
Message-ID: <1086177250.26555.15.camel@slothrop.corp.google.com>

On Mon, 2004-05-31 at 11:39, Anthony Baxter wrote:
>      This is a pre-announcement that the first alpha of Python 2.4
>      is about a month away. The purpose of this notice is to give
>      people a heads up - if you have a bug that you want to see
>      fixed for 2.4, start looking at it now.

I just wanted to note for the record that the ast-branch did not get
merged by the beginning of May and won't be included in Python 2.4.  (At
PyCon, we agreed to finish it by then or hold off.)

The ast-branch is actually in quite good shape, but I didn't have time
to finish it before starting my new job.  It handles every major source
construct correctly; there are a few corner cases (in exec for example)
that are off and there are a number of error handling / memory
management issues to sort out.

It's far enough along that development is fairly comfortable on the
branch.  setup.py compiles and executes correctly as do almost all of
the regression tests.

I think the most likely next step is to merge the head to the branch so
that it keeps up with the evolution of the language.  Merging changes
from the head will identify changes that the compiler is expected to
handle.  I don't know when that will happen -- perhaps early fall if
it's left to me.

Jeremy



From amk at amk.ca  Wed Jun  2 09:56:50 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Wed Jun  2 09:57:01 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <CF48AF58-B3E8-11D8-8EAA-000D932927FE@opnet.com>
References: <20040601143243.GB18424@rogue.amk.ca>
	<CF48AF58-B3E8-11D8-8EAA-000D932927FE@opnet.com>
Message-ID: <20040602135650.GA3911@rogue.amk.ca>

On Tue, Jun 01, 2004 at 12:29:09PM -0400, Nick Bastin wrote:
> people can pop in and out as necessary.  If you can divine it from 
> throwing the bones or something, we should try to pick a weekend when 
> SF CVS is working.  Oh, wait...

We can always point people at the daily tarballs of the CVS HEAD.

I'd like to get an announcement written and posted today.  No one has
objected to Saturday, so that's the date I'll use.  

--amk

From guido at python.org  Wed Jun  2 10:06:29 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun  2 10:06:35 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: Your message of "Wed, 02 Jun 2004 03:35:39 EDT."
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com> 
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<40BC745A.7070700@stackless.com> <Your message of "Mon,
	31 May 2004 20:37:09 EDT."
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de> 
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com> 
Message-ID: <200406021406.i52E6TW24969@guido.python.org>

[Bob Ippolito]
> Using the stack or not is an implementation detail, what matters is
> having more control over the flow of your programs in a reasonably
> efficient manner.  It just so happens that the recursive evaluation
> in CPython uses the stack in such a way that makes these kind of
> constructs impossible, so it needed to be changed for Stackless.

Sorry Bob, you've reached my limit for repeating the same point over
and over without making progress.  You don't seem to be getting the
real point of the responses you're getting, which are that Stackless
is *not* a minor change to Python, and that it severely restricts the
ways in which Python can interact with other systems, be they hardware
platforms, software frameworks, or 3rd party extensions.

Please step off your soapbox, listen, and understand how and why
Stackless gets in the way of Python's range of applicability.

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

From theller at python.net  Wed Jun  2 11:06:15 2004
From: theller at python.net (Thomas Heller)
Date: Wed Jun  2 11:06:29 2004
Subject: [Python-Dev] functions decorators in 2.4?
Message-ID: <y8n6uhi0.fsf@python.net>

PEP 318 is marked as Python 2.4.  Will functions decorators make it in
2.4a1?  Is there anything I can do to make it happen?

Thomas


From guido at python.org  Wed Jun  2 11:19:24 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun  2 11:19:31 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
Message-ID: <200406021519.i52FJP025688@guido.python.org>

Anthony's updates to PEP 320 (the 2.4 release schedule) reminded me
that I still haven't decided on the decorator syntax.  I still hate
the most popular proposal (def foo(args) [decorators]: body) and my
own proposal is unpopular.  I just saw the Java metadata syntax again
and want to think about being inspired by that instead of by the C#
syntax.  On the plus side, Java's @name(kwargs) syntax allows us to
put decorators in front methods and classes without ambiguous syntax;
on the minus side, using up a potential operator character for one
specific purpose should not be done lightly.  But I don't want to get
too deep into this discussion -- I just want to suggest that we put
this off and get 2.4 on the road without any decorator syntax at all.
What do people think of that?

Posts proposing syntax alternatives will be deleted unread.

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

From pje at telecommunity.com  Wed Jun  2 11:32:24 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed Jun  2 11:30:28 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <200406021519.i52FJP025688@guido.python.org>
Message-ID: <5.1.1.6.0.20040602112947.01e83020@mail.telecommunity.com>

At 08:19 AM 6/2/04 -0700, Guido van Rossum wrote:
>Anthony's updates to PEP 320 (the 2.4 release schedule) reminded me
>that I still haven't decided on the decorator syntax.  I still hate
>the most popular proposal (def foo(args) [decorators]: body) and my
>own proposal is unpopular.

I'd rather have your syntax than no syntax for 2.4.



From tjreedy at udel.edu  Wed Jun  2 11:30:38 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed Jun  2 11:30:52 2004
Subject: [Python-Dev] Re: Re: Stackless Python
References: <Your message of "Mon, 31 May
	200420:37:09	EDT."<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com><40BBA2B8.7000907@v.loewis.de><20040530133843.51528.qmail@web50709.mail.yahoo.com><40BAE605.5040800@v.loewis.de>	<40BB6C9B.4040701@ieee.org><40BB7E63.9090304@v.loewis.de><A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com><40BB8882.60503@v.loewis.de><5611D758-B33E-11D8-9388-000A95686CD8@redivi.com><40BB9C17.20500@v.loewis.de><F8297E54-B346-11D8-9388-000A95686CD8@redivi.com><40BBA2B8.7000907@v.loewis.de><5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<200406010317.i513Hvv22066@guido.python.org>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com><c9ibie$uk4$1@sea.gmane.org>
	<40BD00C0.6010606@stackless.com>
Message-ID: <c9krr2$ru$1@sea.gmane.org>


"Christian Tismer" <tismer@stackless.com> wrote in message
news:40BD00C0.6010606@stackless.com...
> Terry Reedy wrote:
>
> > One criterion for adding a new module is a constituency of users.  One
> > thing that would help the Stackless in Python cause is more evidence
that
> > it is useful in practice as well as in theory and expectation.  Even
today,
> > the only thing I can find on the site is
> > "
> > Stackless has impressive applications, like:
> >   a.. Eve, an online massive multiplayer game by CCP Games
> >   b.. ? by Iron Port
> > "
> > Eve was listed two years ago and ? does not say much.  I went to the
Eve
> > site, downloaded several videos, and from what was presented, was
impressed
> > negatively, so it is not obviously to me an advertisement for
Stackless. So
> > other examples, less costly to try out, might be more persuasive.
>
> Why did you do that?

Do what?  Accept the invitation to follow the posted link to the new
Stackless site to learn more about Stackless today?  Click on the Wiki link
and read?  Click on the included link to the one and only listed example
application?

Among other things, I looked to see if there were currently a free trial
period for Eve, as there sometines is for online games.  If I were to try
it, and it ran smoothly for some time without lags and crashes (which I
have experience of), then that would suggest that the tools (including
Stackless) and use thereof were adequate to the task.  If not, that
something (though not necessarily Stackless) would be shown lacking.

> Would you download and try Zope, in order to judge about Python?

Given that you seem to be trying to ridicule sensible behavior, it is
ironic that you should pick that particular example.  In fact, several
years ago, Zope (perhaps by its earlier name) was touted as Python's
'killer application'.  At least a few people said something like 'To see
Python in action, go visit the Python/Zope powered Zope site.'  Which I
(and others) did.  And it appears that others went further and downloaded
Zope to try on their own systems.  A year or two ago, the Zope site listed
Plone as an example of Zope in action.  I followed the link to its site and
signed up for one of the free demo accounts.

> Would you say C is a bad language, because you (perhaps) don't like
> Perl?

The issue is performance, not liking.  In any case, the proof of C was
Unix, 30 years ago.  I switched from Fortran to C in 80/81, long before
Perl existed.  However, if Perl were the only available example application
for C, then yes, trying it out would one sensible way to evaluate C.

> Last time I disliked a movie, I really thought celluloid is a bad idea.

If there were a celluloid movie development site that listed exacly one
celluloid movie and either its price to watch were too much for me and the
free stills unimpressive,  or its *technical* performance crummy, then I
would consider its technical virtue unproven.  But that is not the case.

> These examples

To me, there is only one example.  I don't count '?'.  But perhaps you know
something you can't post.

> are shown to prove that Stackless has industrial strength, nothing else.

Your biased-by-parenthood assertion is not proof to most people.  The mere
existence of Eve is not proof.  A positive evaluation of its technical
performance would be evidence.  To paraphrase my original second sentence:
if you want me to see that Stackless has industrial strength, show me more
evidence.

Terry J. Reedy





From ark-mlist at att.net  Wed Jun  2 11:32:50 2004
From: ark-mlist at att.net (Andrew Koenig)
Date: Wed Jun  2 11:32:51 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <20040602021813.GA21957@panix.com>
Message-ID: <005c01c448b6$df405700$6602a8c0@arkdesktop>

> Time for you to bite the bullet.  Guido has all-but-decreed that the
> future of comparisons is that TypeError will be raised for all operators
> other than == and <> for types that have no appropriate relationship
> system.

When that happens, I hope that comparisons between long and float will
either raise TypeError or behave as if they are done in infinite precision.
Right now, the long gets converted to float, which may lose precision; as a
result, it is possible to have values such that a==b, b==c, and a!=c.


From bob at redivi.com  Wed Jun  2 11:39:14 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Jun  2 11:39:27 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <200406021519.i52FJP025688@guido.python.org>
References: <200406021519.i52FJP025688@guido.python.org>
Message-ID: <003BC6E2-B4AB-11D8-9821-000A95686CD8@redivi.com>


On Jun 2, 2004, at 11:19 AM, Guido van Rossum wrote:

> Anthony's updates to PEP 320 (the 2.4 release schedule) reminded me
> that I still haven't decided on the decorator syntax.  I still hate
> the most popular proposal (def foo(args) [decorators]: body) and my
> own proposal is unpopular.  I just saw the Java metadata syntax again
> and want to think about being inspired by that instead of by the C#
> syntax.  On the plus side, Java's @name(kwargs) syntax allows us to
> put decorators in front methods and classes without ambiguous syntax;
> on the minus side, using up a potential operator character for one
> specific purpose should not be done lightly.  But I don't want to get
> too deep into this discussion -- I just want to suggest that we put
> this off and get 2.4 on the road without any decorator syntax at all.
> What do people think of that?
>
> Posts proposing syntax alternatives will be deleted unread.

I would love to have method decorators in Python 2.4.  I don't even 
care which syntax it has at this point.  I'll donate more money to the 
PSF, or write the implementation myself, if that's what it takes.

I write a lot of PyObjC code, which often requires method wrapping so 
that it can bridge with existing Objective C code properly.  It pains 
me every time I have to write foo = bar(foo), for arbitrarily long foo 
(and they do get arbitrarily long).  It would make a lot of Mac OS X 
developers very happy, especially myself, if there was an alternative.

It would probably be quite practical for ctypes developers as well.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040602/28aa6f33/smime.bin
From aahz at pythoncraft.com  Wed Jun  2 11:56:56 2004
From: aahz at pythoncraft.com (Aahz)
Date: Wed Jun  2 11:57:00 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <200406021519.i52FJP025688@guido.python.org>
References: <200406021519.i52FJP025688@guido.python.org>
Message-ID: <20040602155656.GA801@panix.com>

On Wed, Jun 02, 2004, Guido van Rossum wrote:
>
> I just want to suggest that we put this off and get 2.4 on the road
> without any decorator syntax at all.  What do people think of that?

The arguments in favor of doing *something* now are moderately
compelling, but I dislike getting locked in to a specific syntax or
semantic until we've tested it in the field.  I just had an idea to make
sure that people understand that this is an experimental feature:

Raise a DeprecationWarning anytime someone uses decorators (doesn't
matter which syntax we pick).  This would be in addition to requiring a
``from future import decorators`` directive.

With both of those, I'm +0 on going ahead; without, I'm -1 (i.e. +1 for
delaying).
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha

From pje at telecommunity.com  Wed Jun  2 12:02:18 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed Jun  2 12:00:27 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <200406021406.i52E6TW24969@guido.python.org>
References: <Your message of "Wed, 02 Jun 2004 03:35:39 EDT."
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<40BC745A.7070700@stackless.com> <Your message of "Mon,
	31 May 2004 20:37:09 EDT."
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
Message-ID: <5.1.1.6.0.20040602113243.01e861e0@mail.telecommunity.com>

At 07:06 AM 6/2/04 -0700, Guido van Rossum wrote:
>Stackless is *not* a minor change to Python, and that it severely 
>restricts the
>ways in which Python can interact with other systems, be they hardware
>platforms, software frameworks, or 3rd party extensions.

It's definitely not a minor change, but I think that the severe 
restrictions comment may perhaps be inaccurate.  My understanding at this 
point from Bob and Christian is that for tasklets (which are apparently 
what most people want from Stackless), the code is portable, pure C, and 
has no effect on code that doesn't use tasklets, except in performance.

However, rather than continue discussion on this point, it would probably 
be better if the people who actually understand the Stackless 
implementation were to write a tasklets PEP addressing what *specifically* 
would be the *minimum* changes to the CPython interpreter to support 
co-operative multitasking.

By specifically, I mean listing what core functions/objects will be 
changed, and how those changes will impact other code.  Do any 
interfaces/APIs change?  Is there anything that people writing new core 
code or extensions have to be aware of?  And so on.  A full statement of 
impact, in other words.  At that point, a pronouncement could be made on 
the basis of those specifics, and if the answer is no, then the PEP would 
provide a convenient place to point people to in the future, thus avoiding 
further reiterations of this discussion.  And, in the meanwhile, it gives 
you and Martin a way to tell the other folks to "PEP up or shut up".  :)


From pje at telecommunity.com  Wed Jun  2 12:07:31 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed Jun  2 12:05:41 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <20040602155656.GA801@panix.com>
References: <200406021519.i52FJP025688@guido.python.org>
	<200406021519.i52FJP025688@guido.python.org>
Message-ID: <5.1.1.6.0.20040602120500.030126f0@mail.telecommunity.com>

At 11:56 AM 6/2/04 -0400, Aahz wrote:
>On Wed, Jun 02, 2004, Guido van Rossum wrote:
> >
> > I just want to suggest that we put this off and get 2.4 on the road
> > without any decorator syntax at all.  What do people think of that?
>
>The arguments in favor of doing *something* now are moderately
>compelling, but I dislike getting locked in to a specific syntax or
>semantic until we've tested it in the field.  I just had an idea to make
>sure that people understand that this is an experimental feature:
>
>Raise a DeprecationWarning anytime someone uses decorators (doesn't
>matter which syntax we pick).  This would be in addition to requiring a
>``from future import decorators`` directive.
>
>With both of those, I'm +0 on going ahead; without, I'm -1 (i.e. +1 for
>delaying).

Given that alpha APIs are subject to change anyway, I'm not sure I see the 
point of this, unless you expect us to still be uncertain when 2.4 reaches 
beta and want to add the warning at that point.


From python at rcn.com  Wed Jun  2 00:07:18 2004
From: python at rcn.com (Raymond Hettinger)
Date: Wed Jun  2 12:07:50 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <200406021519.i52FJP025688@guido.python.org>
Message-ID: <004e01c44857$18d23340$e841fea9@oemcomputer>

[GvR]
> I just want to suggest that we put
> this off and get 2.4 on the road without any decorator syntax at all.
> What do people think of that?

+1


Raymond


From guido at python.org  Wed Jun  2 12:20:29 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun  2 12:20:43 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: Your message of "Wed, 02 Jun 2004 11:32:50 EDT."
	<005c01c448b6$df405700$6602a8c0@arkdesktop> 
References: <005c01c448b6$df405700$6602a8c0@arkdesktop> 
Message-ID: <200406021620.i52GKTn25880@guido.python.org>

> When that happens, I hope that comparisons between long and float
> will either raise TypeError or behave as if they are done in
> infinite precision.  Right now, the long gets converted to float,
> which may lose precision; as a result, it is possible to have values
> such that a==b, b==c, and a!=c.

I agree that doing them as if usin infinite precision is best, but I
adamantly oppose the idea that they should not be comparable at all.
To the contrary, we should do our best to ensure that int/long are
properly and cleanly embedded in floats.  That's why I introduced the
change to int/long division after all.

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

From guido at python.org  Wed Jun  2 12:23:29 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun  2 12:23:36 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: Your message of "Wed, 02 Jun 2004 12:02:18 EDT."
	<5.1.1.6.0.20040602113243.01e861e0@mail.telecommunity.com> 
References: <Your message of "Wed, 02 Jun 2004 03:35:39 EDT."
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<40BC745A.7070700@stackless.com> <Your message of "Mon,
	31 May 2004 20:37:09 EDT."
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com> 
	<5.1.1.6.0.20040602113243.01e861e0@mail.telecommunity.com> 
Message-ID: <200406021623.i52GNTO25910@guido.python.org>

> At 07:06 AM 6/2/04 -0700, Guido van Rossum wrote:
> >Stackless is *not* a minor change to Python, and that it severely
> >restricts the ways in which Python can interact with other systems,
> >be they hardware platforms, software frameworks, or 3rd party
> >extensions.

[Phillip]
> It's definitely not a minor change, but I think that the severe 
> restrictions comment may perhaps be inaccurate.  My understanding at this 
> point from Bob and Christian is that for tasklets (which are apparently 
> what most people want from Stackless), the code is portable, pure C, and 
> has no effect on code that doesn't use tasklets, except in performance.
> 
> However, rather than continue discussion on this point, it would probably 
> be better if the people who actually understand the Stackless 
> implementation were to write a tasklets PEP addressing what *specifically* 
> would be the *minimum* changes to the CPython interpreter to support 
> co-operative multitasking.
> 
> By specifically, I mean listing what core functions/objects will be 
> changed, and how those changes will impact other code.  Do any 
> interfaces/APIs change?  Is there anything that people writing new core 
> code or extensions have to be aware of?  And so on.  A full statement of 
> impact, in other words.  At that point, a pronouncement could be made on 
> the basis of those specifics, and if the answer is no, then the PEP would 
> provide a convenient place to point people to in the future, thus avoiding 
> further reiterations of this discussion.  And, in the meanwhile, it gives 
> you and Martin a way to tell the other folks to "PEP up or shut up".  :)

Right.  That PEP better explain how one writes C code that calls into
Python without involving the C stack as well!

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


From guido at python.org  Wed Jun  2 12:24:27 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun  2 12:24:36 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: Your message of "Wed, 02 Jun 2004 11:39:14 EDT."
	<003BC6E2-B4AB-11D8-9821-000A95686CD8@redivi.com> 
References: <200406021519.i52FJP025688@guido.python.org>  
	<003BC6E2-B4AB-11D8-9821-000A95686CD8@redivi.com> 
Message-ID: <200406021624.i52GORA25925@guido.python.org>

> I would love to have method decorators in Python 2.4.  I don't even 
> care which syntax it has at this point.  I'll donate more money to the 
> PSF, or write the implementation myself, if that's what it takes.
> 
> I write a lot of PyObjC code, which often requires method wrapping so 
> that it can bridge with existing Objective C code properly.  It pains 
> me every time I have to write foo = bar(foo), for arbitrarily long foo 
> (and they do get arbitrarily long).  It would make a lot of Mac OS X 
> developers very happy, especially myself, if there was an alternative.

Do you need it for classes too, or only for methods?

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

From bob at redivi.com  Wed Jun  2 12:28:04 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Jun  2 12:28:14 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <200406021624.i52GORA25925@guido.python.org>
References: <200406021519.i52FJP025688@guido.python.org>
	<003BC6E2-B4AB-11D8-9821-000A95686CD8@redivi.com>
	<200406021624.i52GORA25925@guido.python.org>
Message-ID: <D2FB6CAC-B4B1-11D8-9821-000A95686CD8@redivi.com>

On Jun 2, 2004, at 12:24 PM, Guido van Rossum wrote:

>> I would love to have method decorators in Python 2.4.  I don't even
>> care which syntax it has at this point.  I'll donate more money to the
>> PSF, or write the implementation myself, if that's what it takes.
>>
>> I write a lot of PyObjC code, which often requires method wrapping so
>> that it can bridge with existing Objective C code properly.  It pains
>> me every time I have to write foo = bar(foo), for arbitrarily long foo
>> (and they do get arbitrarily long).  It would make a lot of Mac OS X
>> developers very happy, especially myself, if there was an alternative.
>
> Do you need it for classes too, or only for methods?

Just methods.

-bob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040602/3e5257d5/smime.bin
From ark-mlist at att.net  Wed Jun  2 12:57:49 2004
From: ark-mlist at att.net (Andrew Koenig)
Date: Wed Jun  2 12:57:48 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <200406021620.i52GKTn25880@guido.python.org>
Message-ID: <007101c448c2$bcb43b00$6602a8c0@arkdesktop>

> I agree that doing them as if usin infinite precision is best, but I
> adamantly oppose the idea that they should not be comparable at all.

As do I.

> To the contrary, we should do our best to ensure that int/long are
> properly and cleanly embedded in floats.  That's why I introduced the
> change to int/long division after all.

Agreed.

Unfortunately, long/float comparison doesn't work quite correctly right now:

>>> n = 1
>>> for i in range(2000): n += n
>>> n == 0.0
OverflowError: long int too large to convert to float

One strategy for solving the problem is to observe that for every
floating-point implementation, there is a number N with the property that if
x >= N, converting x from float to long preserves information, and if x <=
N, converting x from long to float preserves information.  Therefore,
instead of unconditionally converting to float, the conversion's direction
should be based on the value of one of the comparands.

Of course, such comparisons can be made faster by doing a rough range check
first, and doing the actual conversion only if the number of bits in the
long is commensurate with the exponent of the float.


From theller at python.net  Wed Jun  2 12:59:59 2004
From: theller at python.net (Thomas Heller)
Date: Wed Jun  2 13:00:13 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <D2FB6CAC-B4B1-11D8-9821-000A95686CD8@redivi.com> (Bob
	Ippolito's message of "Wed, 2 Jun 2004 12:28:04 -0400")
References: <200406021519.i52FJP025688@guido.python.org>
	<003BC6E2-B4AB-11D8-9821-000A95686CD8@redivi.com>
	<200406021624.i52GORA25925@guido.python.org>
	<D2FB6CAC-B4B1-11D8-9821-000A95686CD8@redivi.com>
Message-ID: <smddvqsw.fsf@python.net>

Bob Ippolito <bob@redivi.com> writes:

> On Jun 2, 2004, at 12:24 PM, Guido van Rossum wrote:
>
>>> I would love to have method decorators in Python 2.4.  I don't even
>>> care which syntax it has at this point.  I'll donate more money to the
>>> PSF, or write the implementation myself, if that's what it takes.
>>>
>>> I write a lot of PyObjC code, which often requires method wrapping so
>>> that it can bridge with existing Objective C code properly.  It pains
>>> me every time I have to write foo = bar(foo), for arbitrarily long foo
>>> (and they do get arbitrarily long).  It would make a lot of Mac OS X
>>> developers very happy, especially myself, if there was an alternative.
>>
>> Do you need it for classes too, or only for methods?
>
> Just methods.

Same for me (if you replace PyObjC with ctypes).

Thomas


From skip at pobox.com  Wed Jun  2 13:01:39 2004
From: skip at pobox.com (Skip Montanaro)
Date: Wed Jun  2 13:01:48 2004
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Include
	unicodeobject.h, 2.42, 2.43
In-Reply-To: <E1BVYvt-0000BF-Vd@sc8-pr-cvs1.sourceforge.net>
References: <E1BVYvt-0000BF-Vd@sc8-pr-cvs1.sourceforge.net>
Message-ID: <16574.2035.935166.39542@montanaro.dyndns.org>


    perky> - SF #962502: Add two more methods for unicode type; width() and
    perky> iswide() for east asian width manipulation.

Should strings grow these methods as well for symmetry?

Skip

From guido at python.org  Wed Jun  2 13:08:46 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun  2 13:08:59 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: Your message of "Wed, 02 Jun 2004 12:57:49 EDT."
	<007101c448c2$bcb43b00$6602a8c0@arkdesktop> 
References: <007101c448c2$bcb43b00$6602a8c0@arkdesktop> 
Message-ID: <200406021708.i52H8kP26104@guido.python.org>

> Unfortunately, long/float comparison doesn't work quite correctly right now:
> 
> >>> n = 1
> >>> for i in range(2000): n += n
> >>> n == 0.0
> OverflowError: long int too large to convert to float
> 
> One strategy for solving the problem is to observe that for every
> floating-point implementation, there is a number N with the property that if
> x >= N, converting x from float to long preserves information, and if x <=
> N, converting x from long to float preserves information.  Therefore,
> instead of unconditionally converting to float, the conversion's direction
> should be based on the value of one of the comparands.
> 
> Of course, such comparisons can be made faster by doing a rough range check
> first, and doing the actual conversion only if the number of bits in the
> long is commensurate with the exponent of the float.

Do you think you can come up with a patch, or at least a description
of an algorithm that someone without a wizard level understanding of
the issues could implement?

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

From martin at v.loewis.de  Wed Jun  2 13:20:55 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed Jun  2 13:20:59 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<40BBA2B8.7000907@v.loewis.de>	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
Message-ID: <40BE0C77.2080204@v.loewis.de>

Bob Ippolito wrote:
>> However, JCSP uses java.lang.Threads to implement concurrency. So they
>> are completely unlike Stackless' tasklets in their implementation
>> strategy.
> 
> 
> So what, if the API is the same?

If you don't have a problem with that, I don't either.

> Using the stack or not is an implementation detail, what matters is 
> having more control over the flow of your programs in a reasonably 
> efficient manner.  It just so happens that the recursive evaluation in 
> CPython uses the stack in such a way that makes these kind of constructs 
> impossible, so it needed to be changed for Stackless.

That is simply not true. It is possible and straight-forward to
implement Stackless' tasklets and channels on top of the standard
Python, with no need to change the interpreter proper.

Regards,
Martin


From perky at i18n.org  Wed Jun  2 13:22:50 2004
From: perky at i18n.org (Hye-Shik Chang)
Date: Wed Jun  2 13:23:15 2004
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Include
	unicodeobject.h, 2.42, 2.43
In-Reply-To: <16574.2035.935166.39542@montanaro.dyndns.org>
References: <E1BVYvt-0000BF-Vd@sc8-pr-cvs1.sourceforge.net>
	<16574.2035.935166.39542@montanaro.dyndns.org>
Message-ID: <20040602172250.GA61016@i18n.org>

On Wed, Jun 02, 2004 at 12:01:39PM -0500, Skip Montanaro wrote:
> 
>     perky> - SF #962502: Add two more methods for unicode type; width() and
>     perky> iswide() for east asian width manipulation.
> 
> Should strings grow these methods as well for symmetry?
> 

I think there'll be two possible behaviors for strings:

1) regard all characters as non-wide.
2) decode the string to unicode with the system default encoding
   and call its methods.

1) is simple and cheap and can work for non-unicode builds. And it
even work nicely for the most east asian encodings, too. (the only
encodings that len() and screen width are different are euc-jp,
euc-tw and gb18030. But they aren't so major encoding in real life.)

2) is somewhat expensive and will not work in many of CJK environments
because major portion of them don't aware of sys.setdefaultencoding()
and how to play with it.  But this would be more flawless and it
works all encodings that have its unicode codec in Python including
iso-2022 instances.

I didn't make my mind between these two yet.  What do you think?


Hye-Shik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040603/c3d7c41e/attachment.bin
From perky at i18n.org  Wed Jun  2 13:31:49 2004
From: perky at i18n.org (Hye-Shik Chang)
Date: Wed Jun  2 13:31:57 2004
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Include
	unicodeobject.h, 2.42, 2.43
In-Reply-To: <20040602172250.GA61016@i18n.org>
References: <E1BVYvt-0000BF-Vd@sc8-pr-cvs1.sourceforge.net>
	<16574.2035.935166.39542@montanaro.dyndns.org>
	<20040602172250.GA61016@i18n.org>
Message-ID: <20040602173148.GA61543@i18n.org>

On Thu, Jun 03, 2004 at 02:22:50AM +0900, Hye-Shik Chang wrote:
> On Wed, Jun 02, 2004 at 12:01:39PM -0500, Skip Montanaro wrote:
> > 
> >     perky> - SF #962502: Add two more methods for unicode type; width() and
> >     perky> iswide() for east asian width manipulation.
> > 
> > Should strings grow these methods as well for symmetry?
> > 
> 
> I think there'll be two possible behaviors for strings:
> 
> 1) regard all characters as non-wide.
> 2) decode the string to unicode with the system default encoding
>    and call its methods.

Or,

3) leave them available on unicode type only.  Because the east
   asian width is a concept just from Unicode.  POSIX supports width
   manipulation (wcswidth, wcwidth) for wide characters only.

> 
> 1) is simple and cheap and can work for non-unicode builds. And it
> even work nicely for the most east asian encodings, too. (the only
> encodings that len() and screen width are different are euc-jp,
> euc-tw and gb18030. But they aren't so major encoding in real life.)
> 
> 2) is somewhat expensive and will not work in many of CJK environments
> because major portion of them don't aware of sys.setdefaultencoding()
> and how to play with it.  But this would be more flawless and it
> works all encodings that have its unicode codec in Python including
> iso-2022 instances.
> 
> I didn't make my mind between these two yet.  What do you think?
> 
> 
> Hye-Shik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040603/9b9722b8/attachment.bin
From tismer at stackless.com  Wed Jun  2 13:35:05 2004
From: tismer at stackless.com (Christian Tismer)
Date: Wed Jun  2 13:33:34 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <40BE0C77.2080204@v.loewis.de>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<40BE0C77.2080204@v.loewis.de>
Message-ID: <40BE0FC9.1060907@stackless.com>

Martin v. L?wis wrote:
> Bob Ippolito wrote:
> 
>>> However, JCSP uses java.lang.Threads to implement concurrency. So they
>>> are completely unlike Stackless' tasklets in their implementation
>>> strategy.
>>
>>
>>
>> So what, if the API is the same?
> 
> 
> If you don't have a problem with that, I don't either.
> 
>> Using the stack or not is an implementation detail, what matters is 
>> having more control over the flow of your programs in a reasonably 
>> efficient manner.  It just so happens that the recursive evaluation in 
>> CPython uses the stack in such a way that makes these kind of 
>> constructs impossible, so it needed to be changed for Stackless.
> 
> 
> That is simply not true. It is possible and straight-forward to
> implement Stackless' tasklets and channels on top of the standard
> Python, with no need to change the interpreter proper.

This is true, we have written demo implementations of tasklets
with pure Python and threads on the last sprint.

The difference is that nobody would use these for production code,
when tasklets are used frequently, because real threads are at
least an order of magnitude slower than tasklet switching.
This high speed of context switch is what makes certain kinds of
algorithms even useful. You will do things with tasklets which
you never would seriously do with threads, because a context switch
is as cheap as a builtin function call.

This makes the big difference.

The compatibility issue (same API etc.) just guarantees that
such code would run on regular Python and Jython as well.
It would be very slow, no doubt, but it would just work.

Still, tasklets make sense in the first place if they are fast.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From bob at redivi.com  Wed Jun  2 13:38:48 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Jun  2 13:39:00 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <40BE0C77.2080204@v.loewis.de>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<40BBA2B8.7000907@v.loewis.de>	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<40BE0C77.2080204@v.loewis.de>
Message-ID: <B49CCCEE-B4BB-11D8-9821-000A95686CD8@redivi.com>


On Jun 2, 2004, at 1:20 PM, Martin v. L?wis wrote:

> Bob Ippolito wrote:
>>> However, JCSP uses java.lang.Threads to implement concurrency. So 
>>> they
>>> are completely unlike Stackless' tasklets in their implementation
>>> strategy.
>> So what, if the API is the same?
>
> If you don't have a problem with that, I don't either.
>
>> Using the stack or not is an implementation detail, what matters is 
>> having more control over the flow of your programs in a reasonably 
>> efficient manner.  It just so happens that the recursive evaluation 
>> in CPython uses the stack in such a way that makes these kind of 
>> constructs impossible, so it needed to be changed for Stackless.
>
> That is simply not true. It is possible and straight-forward to
> implement Stackless' tasklets and channels on top of the standard
> Python, with no need to change the interpreter proper.

In my quick attempt to do CSP on top of CPython threads I learned that:
- It's not as easy as it sounds to get deterministic behavior out of 
threads, and debugging threaded python apps is no fun.
- When it does work, the performance sucks compared to Stackless.

Perhaps someone with more Python threading experience can prove me 
wrong?

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040602/12dfb585/smime.bin
From skip at pobox.com  Wed Jun  2 13:41:44 2004
From: skip at pobox.com (Skip Montanaro)
Date: Wed Jun  2 13:41:57 2004
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Include
	unicodeobject.h, 2.42, 2.43
In-Reply-To: <20040602172250.GA61016@i18n.org>
References: <E1BVYvt-0000BF-Vd@sc8-pr-cvs1.sourceforge.net>
	<16574.2035.935166.39542@montanaro.dyndns.org>
	<20040602172250.GA61016@i18n.org>
Message-ID: <16574.4440.603341.143057@montanaro.dyndns.org>


    perky> - SF #962502: Add two more methods for unicode type; width() and
    perky> iswide() for east asian width manipulation.

    Skip> Should strings grow these methods as well for symmetry?

    Hye-Shik> I think there'll be two possible behaviors for strings:

    Hye-Shik> 1) regard all characters as non-wide.
    Hye-Shik> 2) decode the string to unicode with the system default encoding
    Hye-Shik>    and call its methods.

    ...

    Hye-Shik> I didn't make my mind between these two yet.  What do you think?

#1 sounds like the most reasonable to me.  You can't rely on strings coming
into your program with proper encoding information, and they might come from
an environment different than sys.defaultencoding (think WWW), so #2 seems
like it would create as many problems as it solves.  All I'm interested in
is avoiding needless occurrences of these constructs in code:

    if isinstance(s, unicode):
        width = s.width()
    else:
        ...

or

    try:
        width = s.width()
    except AttributeError:
        ...

Skip

From tismer at stackless.com  Wed Jun  2 13:44:44 2004
From: tismer at stackless.com (Christian Tismer)
Date: Wed Jun  2 13:43:09 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <B49CCCEE-B4BB-11D8-9821-000A95686CD8@redivi.com>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<40BE0C77.2080204@v.loewis.de>
	<B49CCCEE-B4BB-11D8-9821-000A95686CD8@redivi.com>
Message-ID: <40BE120C.9030004@stackless.com>

Bob Ippolito wrote:

...

> In my quick attempt to do CSP on top of CPython threads I learned that:
> - It's not as easy as it sounds to get deterministic behavior out of 
> threads, and debugging threaded python apps is no fun.
> - When it does work, the performance sucks compared to Stackless.
> 
> Perhaps someone with more Python threading experience can prove me wrong?

I have spent almost three weeks to implement thread-aware
channels for Stackless in C, and I can tell you it was hard.
They are almost exactly 10 times slower than Stackless
channels, and it was not trivial, but once for all time. :-)

I think you are right! -- chris

-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From guido at python.org  Wed Jun  2 13:50:54 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun  2 14:02:05 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: Your message of "Wed, 02 Jun 2004 13:38:48 EDT."
	<B49CCCEE-B4BB-11D8-9821-000A95686CD8@redivi.com> 
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<40BE0C77.2080204@v.loewis.de> 
	<B49CCCEE-B4BB-11D8-9821-000A95686CD8@redivi.com> 
Message-ID: <200406021750.i52HosE26215@guido.python.org>

> > Bob Ippolito wrote:
> >>> However, JCSP uses java.lang.Threads to implement
> >>> concurrency. So they are completely unlike Stackless' tasklets
> >>> in their implementation strategy.
> >> So what, if the API is the same?

> In my quick attempt to do CSP on top of CPython threads I learned that:
> - It's not as easy as it sounds to get deterministic behavior out of
>   threads, and debugging threaded python apps is no fun.
> - When it does work, the performance sucks compared to Stackless.

The same is probably true for JCSP.  I don't want a feature that can
only be implemented efficiently by using assembler or some other
platform-specific hack (and most uses of longjmp() fall in that
category, despite its status as an ISO standard library function!).
Especially if the proponents keep using efficiency as the most
important property of the feature.

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

From amk at amk.ca  Wed Jun  2 13:56:39 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Wed Jun  2 14:02:51 2004
Subject: [Python-Dev] Removing pcre module
Message-ID: <20040602175639.GA5094@rogue.amk.ca>

I've removed the pcre module, unused since Python 1.6, from CVS HEAD.
Should I try to edit the various build files in PC/ and PCbuild/ to
remove it, or should that be left to the Windows-based developers
(Tim, Thomas Heller, Martin)?

--amk


From pje at telecommunity.com  Wed Jun  2 14:04:43 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed Jun  2 14:03:03 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <200406021623.i52GNTO25910@guido.python.org>
References: <Your message of "Wed, 02 Jun 2004 12:02:18 EDT."
	<5.1.1.6.0.20040602113243.01e861e0@mail.telecommunity.com>
	<Your message of "Wed, 02 Jun 2004 03:35:39 EDT."
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<40BC745A.7070700@stackless.com> <Your message of "Mon,
	31 May 2004 20:37:09 EDT."
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040602113243.01e861e0@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20040602134615.031fc820@mail.telecommunity.com>

At 09:23 AM 6/2/04 -0700, Guido van Rossum wrote:

>Right.  That PEP better explain how one writes C code that calls into
>Python without involving the C stack as well!

I believe the outstanding proposal is that attempting a task switch from 
within Python code that was called by an extension will fail with an exception.

But, if you mean, "how do you write a new piece of C that calls the 
interpreter, such that it can allow task switching to take place from the 
invoked interpreter?", then that's a different question, which should 
definitely be answered in the PEP.

The problem I see is that *any* operation on a Python object potentially 
involves C calling Python, which seems to mean that the changes to the core 
interpreter would have to be quite widespread.  But maybe the PEP authors 
have a more clever way to deal with that than anything I've thought of.


From martin at v.loewis.de  Wed Jun  2 14:03:08 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed Jun  2 14:03:17 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <B49CCCEE-B4BB-11D8-9821-000A95686CD8@redivi.com>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>	<40BD6C9D.90003@v.loewis.de>	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>	<40BE0C77.2080204@v.loewis.de>
	<B49CCCEE-B4BB-11D8-9821-000A95686CD8@redivi.com>
Message-ID: <40BE165C.1040907@v.loewis.de>

Bob Ippolito wrote:
> In my quick attempt to do CSP on top of CPython threads I learned that:
> - It's not as easy as it sounds to get deterministic behavior out of 
> threads, and debugging threaded python apps is no fun.

You could have looked at JCSP for guidance.

> - When it does work, the performance sucks compared to Stackless.

So the performance of JCSP sucks as well? Then tasklets aren't
implementable in an acceptable way in Java?

Regards,
Martin


From martin at v.loewis.de  Wed Jun  2 14:11:15 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed Jun  2 14:11:26 2004
Subject: [Python-Dev] Re: [Python-checkins]
	python/dist/src/Include	unicodeobject.h, 2.42, 2.43
In-Reply-To: <16574.4440.603341.143057@montanaro.dyndns.org>
References: <E1BVYvt-0000BF-Vd@sc8-pr-cvs1.sourceforge.net>	<16574.2035.935166.39542@montanaro.dyndns.org>	<20040602172250.GA61016@i18n.org>
	<16574.4440.603341.143057@montanaro.dyndns.org>
Message-ID: <40BE1843.4060007@v.loewis.de>

Skip Montanaro wrote:
>     Hye-Shik> 1) regard all characters as non-wide.
>     Hye-Shik> 2) decode the string to unicode with the system default encoding
>     Hye-Shik>    and call its methods.
> 
>     ...
> 
>     Hye-Shik> I didn't make my mind between these two yet.  What do you think?
> 
> #1 sounds like the most reasonable to me.  

That violates the rule

In the face of ambiguity, refuse the temptation to guess.

For a byte string, for "character width" to be a meaningful concept, the
byte string must use a multi-byte encoding. The, .iswide would not be
implementable because it doesn't apply to a single byte, but a sequence
of bytes. .width is unimplementable because you need to know the
encoding.

So I propose that the methods aren't added to string objects.

 > You can't rely on strings coming
> into your program with proper encoding information, and they might come from
> an environment different than sys.defaultencoding (think WWW), so #2 seems
> like it would create as many problems as it solves.  All I'm interested in
> is avoiding needless occurrences of these constructs in code:
> 
>     if isinstance(s, unicode):
>         width = s.width()
>     else:
>         ...

If you have code that cares about character width, you need to convert
all incoming strings to Unicode. Then, you can just write

   width = s.width()

If you find you are writing code like the one above, you have found a
bug in your code.

Regards,
Martin


From martin at v.loewis.de  Wed Jun  2 14:13:24 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed Jun  2 14:13:35 2004
Subject: [Python-Dev] Removing pcre module
In-Reply-To: <20040602175639.GA5094@rogue.amk.ca>
References: <20040602175639.GA5094@rogue.amk.ca>
Message-ID: <40BE18C4.7020108@v.loewis.de>

A.M. Kuchling wrote:
> I've removed the pcre module, unused since Python 1.6, from CVS HEAD.
> Should I try to edit the various build files in PC/ and PCbuild/ to
> remove it, or should that be left to the Windows-based developers
> (Tim, Thomas Heller, Martin)?

If you easily can, please do. If you don't, I'll try to do that
tomorrow (unless somebody beats me).

Regards,
Martin


From pje at telecommunity.com  Wed Jun  2 14:17:20 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed Jun  2 14:15:26 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <200406021750.i52HosE26215@guido.python.org>
References: <Your message of "Wed, 02 Jun 2004 13:38:48 EDT."
	<B49CCCEE-B4BB-11D8-9821-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<40BE0C77.2080204@v.loewis.de>
	<B49CCCEE-B4BB-11D8-9821-000A95686CD8@redivi.com>
Message-ID: <5.1.1.6.0.20040602140524.02908cd0@mail.telecommunity.com>

At 10:50 AM 6/2/04 -0700, Guido van Rossum wrote:
> > > Bob Ippolito wrote:
> > >>> However, JCSP uses java.lang.Threads to implement
> > >>> concurrency. So they are completely unlike Stackless' tasklets
> > >>> in their implementation strategy.
> > >> So what, if the API is the same?
>
> > In my quick attempt to do CSP on top of CPython threads I learned that:
> > - It's not as easy as it sounds to get deterministic behavior out of
> >   threads, and debugging threaded python apps is no fun.
> > - When it does work, the performance sucks compared to Stackless.
>
>The same is probably true for JCSP.  I don't want a feature that can
>only be implemented efficiently by using assembler or some other
>platform-specific hack (and most uses of longjmp() fall in that
>category, despite its status as an ISO standard library function!).
>Especially if the proponents keep using efficiency as the most
>important property of the feature.

I personally think that deterministic task-switching is more relevant than 
raw speed.  Being able to create hundreds or even thousands of lightweight 
tasks is also very useful.

Right now I can do both of these using generators in CPython 2.2 or better, 
so the only things (IMO) that Stackless is offering to add are:

1. dropping the need to write tasks solely in the form of "generators all 
the way down"

2. a simpler syntax: yields are expressed as calls, rather than as a 
'yield' statement followed by various magical idioms.

I currently have code that doesn't hesitate to spawn generator-based 
tasklets for simple condition monitoring tasks, and I have no idea in 
practice how many of these tasklets might be running in my code, but I'm 
pretty sure it's more than I'd want to have threads running for.  However, 
if threads only had to be used when yielding code was called from 
non-yielding code, or vice versa, I'd probably be okay with it.  Such 
boundaries aren't all that common in my experience to date using 
generator-based tasklets.


From tim.one at comcast.net  Wed Jun  2 14:16:03 2004
From: tim.one at comcast.net (Tim Peters)
Date: Wed Jun  2 14:16:23 2004
Subject: [Python-Dev] Removing pcre module
In-Reply-To: <20040602175639.GA5094@rogue.amk.ca>
Message-ID: <mailman.304.1086200183.6944.python-dev@python.org>

[A.M. Kuchling]
> I've removed the pcre module, unused since Python 1.6, from CVS HEAD.

Yay!  We hardly knew ye, pcre.

> Should I try to edit the various build files in PC/ and PCbuild/ to
> remove it, or should that be left to the Windows-based developers (Tim,
> Thomas Heller, Martin)?

Leave it to the Windows geeks.  The build files are generated by MS IDEs,
and it's easiest, safest, and fastest for us to click the IDE's "delete this
file" button.  It will update the build files accordingly then.



From gmcm at hypernet.com  Wed Jun  2 14:22:41 2004
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed Jun  2 14:18:04 2004
Subject: [Python-Dev] Re: Re: Stackless Python
In-Reply-To: <1125930309-82661563@hypernet.com>
References: <1125930309-82661563@hypernet.com>
Message-ID: <200406021422.42480.gmcm@hypernet.com>

Terry Reedy wrote:

[trying Stackless]
> Among other things, I looked to see if there were currently a free trial
> period for Eve, as there sometines is for online games.  If I were to try
> it, and it ran smoothly for some time without lags and crashes (which I
> have experience of), then that would suggest that the tools (including
> Stackless) and use thereof were adequate to the task.  If not, that
> something (though not necessarily Stackless) would be shown lacking.

Let me pop my head up for a second.

You won't see Stackless do anything (from a user's perspective) that can't be 
done without Stackless[1]. Stackless (like generators) just makes some things 
much easier.

Basically, any state machine(s) with complex internal state (and relatively 
simple events) will be much more straightforward to write in Stackless. Put 
another way (if you don't think in terms of "state machines"), if you've got 
callbacks onSomething(...) where a lot of the code is concerned with where 
you are in a complex interchange, it will be much easier in Stackless.

I can't speak to the new Stackless, but in 2000 I did a proprietary, 
commercial app for Avid that used Stackless (and lots of C extensions). It 
went through Avid's QA, so it would not have been released if it crashed.
The Mac OS8/9 port was difficult, but not because of Stackless.

-- Gordon

[1] Though perhaps you can do more / quicker, because of more efficient memory 
usage than an implementation using threads.

From theller at python.net  Wed Jun  2 14:19:24 2004
From: theller at python.net (Thomas Heller)
Date: Wed Jun  2 14:19:37 2004
Subject: [Python-Dev] Removing pcre module
In-Reply-To: <20040602175639.GA5094@rogue.amk.ca> (A. M. Kuchling's message
	of "Wed, 2 Jun 2004 13:56:39 -0400")
References: <20040602175639.GA5094@rogue.amk.ca>
Message-ID: <65a9vn4j.fsf@python.net>

"A.M. Kuchling" <amk@amk.ca> writes:

> I've removed the pcre module, unused since Python 1.6, from CVS HEAD.
> Should I try to edit the various build files in PC/ and PCbuild/ to
> remove it, or should that be left to the Windows-based developers
> (Tim, Thomas Heller, Martin)?

We'll do it.  (If the others don't agree, I have to do it alone).

Thomas


From mchermside at ingdirect.com  Wed Jun  2 14:21:48 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Wed Jun  2 14:21:54 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550A45@ingdexj1.ingdirect.com>

Guido writes:
> I still hate
> the most popular proposal (def foo(args) [decorators]: body) and my
> own proposal is unpopular.

Just one voice here, but I was initially opposed to your proposal,
and favored the above-mentioned popular proposal. But as I played
around with your proposed syntax, it grew on me, and I'm now a 
supporter your approach.

> I just want to suggest that we put
> this off and get 2.4 on the road without any decorator syntax at all.
> What do people think of that?

It's fine with me if we put it off. Obviously others have already
posted saying that they'd rather have the feature (at least FUNCTION
decorators... other decorators seem to be less in demand), regardless 
of the syntax. As for me, I'd rather prefer to get the syntax "right"
even if it means delaying another release... but that's because I
don't have a project that is in desperate need of decorators.

I like the *idea* of releasing one syntax and reserving the right
to change syntax later (via warnings or something). But I don't 
believe it is possible in the real world.

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From martin at v.loewis.de  Wed Jun  2 14:28:01 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed Jun  2 14:28:10 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <40BE0FC9.1060907@stackless.com>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<40BE0C77.2080204@v.loewis.de> <40BE0FC9.1060907@stackless.com>
Message-ID: <40BE1C31.2090302@v.loewis.de>

Christian Tismer wrote:
> This is true, we have written demo implementations of tasklets
> with pure Python and threads on the last sprint.

Where can I find that implementation?

Regards,
Martin


From tismer at stackless.com  Wed Jun  2 14:32:11 2004
From: tismer at stackless.com (Christian Tismer)
Date: Wed Jun  2 14:30:35 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <200406021623.i52GNTO25910@guido.python.org>
References: <Your message of "Wed, 02 Jun 2004 03:35:39
	EDT."	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>	<40BD6C9D.90003@v.loewis.de>	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040602113243.01e861e0@mail.telecommunity.com>
	<200406021623.i52GNTO25910@guido.python.org>
Message-ID: <40BE1D2B.1050904@stackless.com>

Guido van Rossum wrote:

...

[cooperative multitasking]

> Right.  That PEP better explain how one writes C code that calls into
> Python without involving the C stack as well!

Quick reply to give you an idea:

A tail recursive call is rather trivial, so here the non-trivial
side of the coin:

Conventional style:

PyObject *
some_c_code(some_args)
{
	PyObject *ret, ret2;

	/* do preparation things */
	/* call into Python */

	ret = PyEval_CallObject(some_args);

	/* do post-processing */
	ret2 = some_other_processing(ret);
	return ret2;
}

Stackless style (simplified and sketched, only):

PyObject *
some_c_code(some_args)
{
	PyObject *ret, ret2;

	/* do preparation things */
	
	create_miniframe(some_c_code_post);
	/* put parameters in miniframe */

	/* deferred call into Python */

	ret = PyEval_CallObject_defer(some_args);
	return <special value>
}

PyObject *
some_c_code_post(miniframe)
{
	/* reload variables from miniframe */
	/* drop miniframe */
	/* do post-processing */
	ret2 = some_other_processing(ret);
	return ret2;
}

So the idea is to avoid recursions by creating frame-like
tiny structures, which are then executed by a toplevel loop
which does nothing than call the next frame.
The <special value> (not specified here) passes through the
currently involved C code as a dummy which unwinds the stack
until the toplevel loop is reached. There this value is
captured and unpacked, and execution continues.

Well, this was rough and incomplete. A PEP would be nice
and also quite much work. The protocol sketched above
is a lot of work to do if you want to do it throughout all of
Python, and I didn't do it in most cases, but did the simple
tail-recursive things (which don't need that extra tinyframe)
everywhere where possible.
If adopting a similar technique for parts of Python is not
feasible, then the PEP would be a waste of time. There is
no other principal way to do it in plain C, IMHO.

cheers - chris
-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Wed Jun  2 14:36:48 2004
From: tismer at stackless.com (Christian Tismer)
Date: Wed Jun  2 14:35:22 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <40BE1C31.2090302@v.loewis.de>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<40BE0C77.2080204@v.loewis.de> <40BE0FC9.1060907@stackless.com>
	<40BE1C31.2090302@v.loewis.de>
Message-ID: <40BE1E40.2090107@stackless.com>

Martin v. L?wis wrote:

> Christian Tismer wrote:
> 
>> This is true, we have written demo implementations of tasklets
>> with pure Python and threads on the last sprint.
> 
> 
> Where can I find that implementation?

If you checked out current cvs, it is in the Stackless folder

Stackless/demo/stephan/stacklessness

I'm not sure how complete or correct it is, I think he was
planning to do some more on it.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From bac at OCF.Berkeley.EDU  Wed Jun  2 14:45:35 2004
From: bac at OCF.Berkeley.EDU (Brett C.)
Date: Wed Jun  2 14:45:52 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <200406021519.i52FJP025688@guido.python.org>
References: <200406021519.i52FJP025688@guido.python.org>
Message-ID: <40BE204F.8070606@ocf.berkeley.edu>

Guido van Rossum wrote:
[snip]

> I just want to suggest that we put
> this off and get 2.4 on the road without any decorator syntax at all.
> What do people think of that?
> 

+1 from me.

While I completely understand Bob and Thomas wanting this for PyObjC and 
ctypes, respectively, I don't want to rush this.  And I don't think this 
is going to suffer from being pushed off indefinitely since enough 
people want this feature.  If you need more time to consider how Java 
handles it, then take it.  You are BDFL for a reason; your gut feeling 
tends be right in the end.

But if you decide not to wait and put in 2.4, I'm +1 on your syntax; as 
I said before, your gut tends to be right.

-Brett

From skip at pobox.com  Wed Jun  2 15:00:55 2004
From: skip at pobox.com (Skip Montanaro)
Date: Wed Jun  2 15:01:05 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <200406021750.i52HosE26215@guido.python.org>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<40BE0C77.2080204@v.loewis.de>
	<B49CCCEE-B4BB-11D8-9821-000A95686CD8@redivi.com>
	<200406021750.i52HosE26215@guido.python.org>
Message-ID: <16574.9191.826913.569485@montanaro.dyndns.org>


    Guido> Especially if the proponents keep using efficiency as the most
    Guido> important property of the feature.

True, but there's efficiency and there's efficiency.  I would agree if we
were just speeding up a slow algorithm.  Following this thread with just one
eye though it seems like the people advocating tasklets are suggesting they
are efficient enough to allow algorithms which simply aren't feasible using
threads (far too expensive) or are intractable for other reasons (like
generators all the way down).

Skip


From guido at python.org  Wed Jun  2 15:10:47 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun  2 15:11:17 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: Your message of "Wed, 02 Jun 2004 14:04:43 EDT."
	<5.1.1.6.0.20040602134615.031fc820@mail.telecommunity.com> 
References: <Your message of "Wed, 02 Jun 2004 12:02:18 EDT."
	<5.1.1.6.0.20040602113243.01e861e0@mail.telecommunity.com>
	<Your message of "Wed, 02 Jun 2004 03:35:39 EDT."
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<40BC745A.7070700@stackless.com> <Your message of "Mon,
	31 May 2004 20:37:09 EDT."
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D8-9821-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040602113243.01e861e0@mail.telecommunity.com> 
	<5.1.1.6.0.20040602134615.031fc820@mail.telecommunity.com> 
Message-ID: <200406021910.i52JAlV26387@guido.python.org>

> >Right.  That PEP better explain how one writes C code that calls into
> >Python without involving the C stack as well!
> 
> I believe the outstanding proposal is that attempting a task switch
> from within Python code that was called by an extension will fail
> with an exception.

But how do you define "called by an exception"?  There are lots
built-in data types that call back into Python, e.g. comparisons and
hash for dict keys, list.sort, sets, etc...

Last time we looked there were so many exceptions of this type that
enumerating them all was hopeless.  That's a problem for a PEP.

> But, if you mean, "how do you write a new piece of C that calls the
> interpreter, such that it can allow task switching to take place
> from the invoked interpreter?", then that's a different question,
> which should definitely be answered in the PEP.

That's what I meant, yes.

> The problem I see is that *any* operation on a Python object
> potentially involves C calling Python, which seems to mean that the
> changes to the core interpreter would have to be quite widespread.
> But maybe the PEP authors have a more clever way to deal with that
> than anything I've thought of.

My way of dealing with this is to keep Stackless out of the core.
Everybody happy.

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

From theller at python.net  Wed Jun  2 15:43:07 2004
From: theller at python.net (Thomas Heller)
Date: Wed Jun  2 15:43:24 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <40BE204F.8070606@ocf.berkeley.edu> (Brett C.'s message of
	"Wed, 02 Jun 2004 11:45:35 -0700")
References: <200406021519.i52FJP025688@guido.python.org>
	<40BE204F.8070606@ocf.berkeley.edu>
Message-ID: <fz9du4ok.fsf@python.net>

"Brett C." <bac@OCF.Berkeley.EDU> writes:

> Guido van Rossum wrote:
> [snip]
>
>> I just want to suggest that we put
>> this off and get 2.4 on the road without any decorator syntax at all.
>> What do people think of that?
>>
>
> +1 from me.
>
> While I completely understand Bob and Thomas wanting this for PyObjC
> and ctypes, respectively, I don't want to rush this.  And I don't
> think this is going to suffer from being pushed off indefinitely since
> enough people want this feature.  If you need more time to consider
> how Java handles it, then take it.  You are BDFL for a reason; your
> gut feeling tends be right in the end.
>
> But if you decide not to wait and put in 2.4, I'm +1 on your syntax;
> as I said before, your gut tends to be right.

Guido's syntax has the advantage that it's possible to experiment with
this more easily (for those who want it) since it's possible to write
backwards compatible code (no syntax errors, but different semantics).
This may, however, also be a disadvantage.  Probably all this has been
said before, but for me it's now a point in favor of Guido's patch.

I agree with Brett that Guido is usually right, so I'm curious about his
decision.

Thomas


From guido at python.org  Wed Jun  2 15:48:08 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun  2 15:51:19 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: Your message of "Wed, 02 Jun 2004 21:43:07 +0200."
	<fz9du4ok.fsf@python.net> 
References: <200406021519.i52FJP025688@guido.python.org>
	<40BE204F.8070606@ocf.berkeley.edu> <fz9du4ok.fsf@python.net> 
Message-ID: <200406021948.i52Jm8v26530@guido.python.org>

> I agree with Brett that Guido is usually right, so I'm curious about his
> decision.

I plan to talk it through with people at EuroPython next week.

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

From FBatista at uniFON.com.ar  Wed Jun  2 15:52:32 2004
From: FBatista at uniFON.com.ar (Batista, Facundo)
Date: Wed Jun  2 15:55:32 2004
Subject: [Python-Dev] Python bug day?
Message-ID: <A128D751272CD411BC9200508BC2194D033839D2@escpl.tcp.com.ar>

[A.M. Kuchling]

#- I'd like to get an announcement written and posted today.  No one has
#- objected to Saturday, so that's the date I'll use.  

This Saturday? 

I liked to don't put this on #python. #python-bugday seems a good name.

.	Facundo

From jepler at unpythonic.net  Wed Jun  2 16:12:30 2004
From: jepler at unpythonic.net (Jeff Epler)
Date: Wed Jun  2 16:12:35 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <200406021708.i52H8kP26104@guido.python.org>
References: <007101c448c2$bcb43b00$6602a8c0@arkdesktop>
	<200406021708.i52H8kP26104@guido.python.org>
Message-ID: <20040602201230.GF19278@unpythonic.net>

Can't you do it like so:
    def cmp_long_vs_float(l, f):
        try:
            lf = float(l)
        except OverflowError:
            if special_float_value(f): # NaN, Inf
                return cmp(0.0, f)
            return cmp(l, 0L)
        else:
            return cmp(lf, f)
The try/else control flow seems to be what Python does today.
If the OverflowError is triggered, then the magnitude of l is bigger
than any finite float so you might just as well compare it against 0L.
Infinite floats are handled by the "if special_float_value(f):" branch, or
just ignored if you prefer.. (but having 2L**2000 compare greater than
+INF would bring complaints)

If it turns out to be more efficient, the implementation could LBYL to
see whether l can convert to float without overflow.

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040602/b42ac11e/attachment.bin
From mchermside at ingdirect.com  Wed Jun  2 17:18:44 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Wed Jun  2 17:18:48 2004
Subject: [Python-Dev] Comparing heterogeneous types
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550A47@ingdexj1.ingdirect.com>

Jeff Epler writes:
> Can't you do it like so:
>     def cmp_long_vs_float(l, f):
>         try:
>             lf = float(l)
>         except OverflowError:
>             if special_float_value(f): # NaN, Inf
>                 return cmp(0.0, f)
>             return cmp(l, 0L)
>         else:
>             return cmp(lf, f)

I don't think so. There are three "problems" with comparing
floats to longs. The float might have a fraction part (not be an
integer), in which case we really need pay attention to it (perhaps
by comparing floats). The long might be larger than the largest
float, in which case we really need to pay attention to THAT
(perhaps by comparing longs). Your code handles these. But there's
another situation too... the long could be less than MAX_FLOAT,
but still not be precisely representably as a float. In a case
like this, we really need to convert both to longs and compare
(or something equivalent) and your code fails to do this.

What Andrew Koenig was suggesting (and I hope I'm understanding
it properly, since I'd never realized this fact before I read
his post) is that for any (sane) implementation of float, there
is a crossover value. Below that value, the precision is larger
than the exponent and there might be a fractional part. Above
that value, the precision is smaller than the exponent, and so
floats above that value must all be integers... and some integers
above that value will not be representable as floats. Andrew's
suggestion is to (losslessly) convert both to floats and compare
if the float is below that value, and (losslessly) convert both
to longs and compare if the float is above that value.

The only bit that seems tricky to me is determining the crossover
value in pure C. How do we do that?

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From tjreedy at udel.edu  Wed Jun  2 18:24:43 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed Jun  2 18:24:54 2004
Subject: [Python-Dev] Re: Re: Stackless Python
References: <1125930309-82661563@hypernet.com>
	<200406021422.42480.gmcm@hypernet.com>
Message-ID: <c9lk3f$84i$1@sea.gmane.org>


"Gordon McMillan" <gmcm@hypernet.com> wrote in message
news:200406021422.42480.gmcm@hypernet.com...
> Let me pop my head up for a second.

Welcome ;-)

> You won't see Stackless do anything (from a user's perspective) that
can't be
> done without Stackless[1].
> [1] Though perhaps you can do more / quicker, because of more efficient
> memory usage than an implementation using threads.

Except that for real-time game simulations, running smoothly without
freeze-ups (and crashes) *is* experientially different, for the gamer-user,
from being frozen in the middle of deadly battle, which is typically when
freeze-ups occur.

> Stackless (like generators) just makes some things much easier.
> Basically, any state machine(s) with complex internal state (and
relatively
> simple events) will be much more straightforward to write in Stackless.

Enought more so to lead to less bugs and/or more features (if the same time
is allotted)?

> I can't speak to the new Stackless, but in 2000 I did a proprietary,
> commercial app for Avid that used Stackless (and lots of C extensions).
It
> went through Avid's QA, so it would not have been released if it crashed.

OK, another success story, even if somewhat old.

Terry J. Reedy




From jepler at unpythonic.net  Wed Jun  2 18:32:45 2004
From: jepler at unpythonic.net (Jeff Epler)
Date: Wed Jun  2 18:32:56 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <0CFFADBB825C6249A26FDF11C1772AE1550A47@ingdexj1.ingdirect.com>
References: <0CFFADBB825C6249A26FDF11C1772AE1550A47@ingdexj1.ingdirect.com>
Message-ID: <20040602223245.GA2392@unpythonic.net>

Oh -- there are some floats f for which
    float(long(f))
raises an OverflowError in float()?

My code assumed that wouldn't happen, that all longs that caused
OverflowError() in conversion to float were bigger than all finite
floats.  Surely this is just as much a problem as the overflow on
comparison.

You can tell if a float f is well above Andrew's crossover value (but
still well below the largest finite value, in sane FP formats) when
    f + 1 == f
though I guess this wouldn't actually work in all rounding modes and for
all signs of f...

Just hard-code the value 53 (as in 2**53).  But write it as 42 +
sizeof(double) + sizeof(int) - 1 and put a cryptic comment next to it.
I suggest
    /* on 36-bit platforms, this may be wrog */

It's clear that I should think this through some more before making any
more suggestions.

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040602/e8ec0be5/attachment-0001.bin
From jeremy at alum.mit.edu  Wed Jun  2 20:10:03 2004
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed Jun  2 20:10:05 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <40BE204F.8070606@ocf.berkeley.edu>
Message-ID: <mailman.313.1086221405.6944.python-dev@python.org>

Brett Cannon wrote:
> > I just want to suggest that we put
> > this off and get 2.4 on the road without any decorator syntax at all.
> > What do people think of that?
> >
> 
> +1 from me.
>
> While I completely understand Bob and Thomas wanting this for PyObjC and 
> ctypes, respectively, I don't want to rush this.  And I don't think this 
> is going to suffer from being pushed off indefinitely since enough 
> people want this feature.  If you need more time to consider how Java 
> handles it, then take it.  You are BDFL for a reason; your gut feeling 
> tends be right in the end.

I'd like it well enough for my own code, although I don't feel the need as
keenly as others working on PyObjC or the like.  Yet I'm more concerned that
we get the right answer than that we get an answer now.

> But if you decide not to wait and put in 2.4, I'm +1 on your syntax; as 
> I said before, your gut tends to be right.

I'm generally found of the C#-style syntax, but I grant that its problems in
interactive mode are awkward.  Thus, it feels a bit like the least bad
solution rather than a good solution.

Jeremy



From tim.one at comcast.net  Wed Jun  2 20:36:47 2004
From: tim.one at comcast.net (Tim Peters)
Date: Wed Jun  2 20:37:02 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <20040602223245.GA2392@unpythonic.net>
Message-ID: <mailman.316.1086223022.6944.python-dev@python.org>

[Jeff Epler]
> Oh -- there are some floats f for which
>     float(long(f))
> raises an OverflowError in float()?

No, at least not unless the machine has very strange arithmetic.  For an
IEEE box,

>>> from math import ldexp
>>> b = 2**53 - 1       # string of 53 1-bits
>>> ldexp(b, 1024-53)   # largest finite IEEE double
1.7976931348623157e+308
>>> long(_)             # as a long
179769313486231570814527423731704356798070567525844996598917476803157
260780028538760589558632766878171540458953514382464234321326889464182
768467546703537516986049910576551282076245490090389328944075868508455
133942304583236903222948165808559332123348274797826204144723168738177
180919299881250404026184124858368L
>>> float(_)            # and back to float
1.7976931348623157e+308
>>>

Similarly for its negation, and those are the worst cases.



From jepler at unpythonic.net  Wed Jun  2 20:40:51 2004
From: jepler at unpythonic.net (Jeff Epler)
Date: Wed Jun  2 20:41:04 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <200406030037.i530bFY28691@bald.unpythonic.net>
References: <20040602223245.GA2392@unpythonic.net>
	<200406030037.i530bFY28691@bald.unpythonic.net>
Message-ID: <20040603004051.GA3210@unpythonic.net>

On Wed, Jun 02, 2004 at 08:36:47PM -0400, Tim Peters wrote:
> [Jeff Epler]
> > Oh -- there are some floats f for which
> >     float(long(f))
> > raises an OverflowError in float()?
> 
> No, at least not unless the machine has very strange arithmetic.  For an
> IEEE box,
[...]

Thanks.  I re-read the message I was replying to, and now I see the
problem with the code I proposed.  I just didn't get it the first time.

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040602/a7c20cfb/attachment.bin
From gward at python.net  Wed Jun  2 22:15:09 2004
From: gward at python.net (Greg Ward)
Date: Wed Jun  2 22:15:15 2004
Subject: [Python-Dev] Reminder: optparse.py is auto-generated
Message-ID: <20040603021509.GA2941@cthulhu.gerg.ca>

I just noticed SF bug #850964, which Fred kindly fixed (back in
April)... except he did it by modifying optparse.py, which is a no-no.
As it says in the comment at the top:

# Python developers: please do not make changes to this file, since
# it is automatically generated from the Optik source code.

Luckily, I've already fixed this bug in the Optik CVS, very similarly to
Fred's fix.  So the fact that optparse.py will be clobbered sooner or
later doesn't really matter in this case.  But it might have!

        Greg
-- 
Greg Ward <gward@python.net>                         http://www.gerg.ca/
Sure, I'm paranoid... but am I paranoid ENOUGH?

From t-meyer at ihug.co.nz  Wed Jun  2 22:31:50 2004
From: t-meyer at ihug.co.nz (Tony Meyer)
Date: Wed Jun  2 22:35:08 2004
Subject: [Python-Dev] 
	RE: [Python-checkins] python/dist/src/Misc NEWS, 1.983, 1.984
In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F1306967347@its-xchg4.massey.ac.nz>
Message-ID: <1ED4ECF91CDED24C8D012BCF2B034F13064C0269@its-xchg4.massey.ac.nz>

> Fix grammar hopefully. :)
[...]
> ! - Unicode type got two new methods; iswide() and width(). They
> !   manipulate east asian width information as of Unicode TR11.
[...]
> ! - Unicode type got two new methods now; iswide() and width(). They
> !   manipulate east asian width information from Unicode TR11.

Not that I think that having grammatically perfect NEWS is at all important,
but this isn't grammatically correct.

Something like "The Unicode type received two new methods: iswide() and
width().  These manipulate East Asian width information, as outlined in
Unicode TR11" is probably what you're after.

=Tony Meyer


From t-meyer at ihug.co.nz  Wed Jun  2 22:42:29 2004
From: t-meyer at ihug.co.nz (Tony Meyer)
Date: Wed Jun  2 22:44:54 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F1306967317@its-xchg4.massey.ac.nz>
Message-ID: <1ED4ECF91CDED24C8D012BCF2B034F13064C026A@its-xchg4.massey.ac.nz>

> We can always point people at the daily tarballs of the CVS HEAD.

Are these generated by SourceForge?  If so, note that the same problem
affecting viewcvs and anonymous cvs is also affecting the tarballs as well.

<http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1>

I doubt this is much of an issue, though - most of the bugs would be
independent enough to be able be worked on from slightly old cvs, wouldn't
they?  Maybe SourceForge's "timely resolution" will come through before
Saturday, anyway.

=Tony Meyer


From t-meyer at ihug.co.nz  Thu Jun  3 00:19:48 2004
From: t-meyer at ihug.co.nz (Tony Meyer)
Date: Thu Jun  3 00:21:11 2004
Subject: [Python-Dev] 
	RE: [Python-checkins] python/dist/src/Misc NEWS, 1.984, 1.985
In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F1306967443@its-xchg4.massey.ac.nz>
Message-ID: <1ED4ECF91CDED24C8D012BCF2B034F13064C026C@its-xchg4.massey.ac.nz>

> One more attempt to fix the grammar.
> ! - Unicode objects received two new methods now; iswide() 
> and width(). They
> !   query east asian width information according to Unicode TR11.

One more attempt to fix the fix <wink>.

1. "east asian" should be "East Asian".
2. The semi-colon after "now" should be a colon.
3. The "now" after "methods" should be removed.

Given the content changes, I'd now suggest:

"Unicode objects received two new methods: iswide() and width().  These
query East Asian width information, as specified in Unicode TR11."

(To me (and this might be a NZ thing or something) "according to" doesn't
convey the quite same meaning as "as specified in", or "as described by", or
words to that effect; hence the other change.  It's not as important).

=Tony Meyer


From anthony at interlink.com.au  Thu Jun  3 05:15:53 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Thu Jun  3 05:16:42 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <200406021519.i52FJP025688@guido.python.org>
References: <200406021519.i52FJP025688@guido.python.org>
Message-ID: <40BEEC49.1070708@interlink.com.au>

Guido van Rossum wrote:
> Anthony's updates to PEP 320 (the 2.4 release schedule) reminded me
> that I still haven't decided on the decorator syntax.  

You beat me to the email - I was going to send out a message asking
about this.

Personally, I'm +1 on _something_ going in. None of the options
presented are absolutely right, but no-one's found a better way
to spell it. Since it's going to be a part of the language that's
not used heavily, I don't think this matters too much.

(By "absolutely right" I mean you can look at it and say "yes,
that's definitely the way to do it").

And hey, we have the alpha cycle to get it right.

Anthony


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


From ajm at flonidan.dk  Thu Jun  3 05:35:29 2004
From: ajm at flonidan.dk (Anders J. Munch)
Date: Thu Jun  3 05:35:44 2004
Subject: SV: [Python-Dev] Comparing heterogeneous types
Message-ID: <6D9E824FA10BD411BE95000629EE2EC3C6DDF7@FLONIDAN-MAIL>

Chermside, Michael wrote:
> 
> The only bit that seems tricky to me is determining the crossover
> value in pure C. How do we do that?

I think that's as simple as pow(FLT_RADIX, DBL_MAX_DIG).

So the comparison would go something like:

def cmp_floatvlong_positive(afloat, along):
    assert afloat >=0 and along >= 0
    if along < FLT_RADIX**DBL_MANT_DIG:
        # the long is representable as float
        return cmp(afloat, float(along))
    elif afloat >= FLT_RADIX**DBL_MANT_DIG:
        # the float is representable as integer
        return cmp(long(afloat), along)
    else:
        # At this point we know: afloat < FLT_RADIX**DBL_MANT_DIG <= along
        return -1

def cmp_floatvlong(afloat, along):
    ures = cmp_floatvlong_positive(abs(afloat), abs(along))
    if (afloat >= 0) != (along >= 0):
        return -ures
    else:
        return ures

Assuming FLT_RADIX is a power of 2, comparing the long to the
crossover value can be implemented by counting bits of magnitude,
replacing
    if along < FLT_RADIX**DBL_MANT_DIG:
with
    if trunc(lg(along)) < lg(FLT_RADIX)*DBL_MANT_DIG:
The crossover value as a float can be (pre-)computed the
straightforward way: pow(FLT_RADIX, DBL_MAX_DIG) will always be exact
representable.

- Anders

From gisle at ActiveState.com  Thu Jun  3 05:38:03 2004
From: gisle at ActiveState.com (Gisle Aas)
Date: Thu Jun  3 05:39:11 2004
Subject: [Python-Dev] Contribution Licensing Agreement?
In-Reply-To: <40B6DE94.5030801@v.loewis.de>
References: <Pine.LNX.4.58.0405272353290.933@alice>
	<40B6DE94.5030801@v.loewis.de>
Message-ID: <lrn03lvv5w.fsf@caliper.activestate.com>

"Martin v. L?wis" <martin@v.loewis.de> writes:

> John J Lee wrote:
> > I remember from a year or so ago that the various PSF licensing agreements
> > were not finalised, but Guido said contributors should still sign them in
> > their draft form.  Have things moved on at all since then?  I recall that
> > Guido said legal ditherings had been going on for a year or so even back
> > then.  cookielib is a derived work of libwww-perl, so I guess I need to
> > get Gisle Aas (libwww-perl's author) to sign something if it is to be part
> > of 2.4, right?
> 
> Most likely, no. Things are still proceeding at a very low pace, and the
> papers that have originally been drafted are likely obsolete.
> 
> At the moment, an acknowledgement of the author that he agrees to
> distribution of the code together with Python, and under the Python
> licensing conditions, is ok.

Hi, there.  I have no problem with letting cookielib be distibuted
under the Python license.

Regards,
Gisle Aas


From walter at livinglogic.de  Thu Jun  3 06:26:43 2004
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu Jun  3 06:26:54 2004
Subject: [Python-Dev] 	RE: [Python-checkins] python/dist/src/Misc NEWS,
	1.983, 1.984
In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F13064C0269@its-xchg4.massey.ac.nz>
References: <1ED4ECF91CDED24C8D012BCF2B034F13064C0269@its-xchg4.massey.ac.nz>
Message-ID: <40BEFCE3.20406@livinglogic.de>

Tony Meyer wrote:

> [...]
> 
>>! - Unicode type got two new methods now; iswide() and width(). They
>>!   manipulate east asian width information from Unicode TR11.

Should these methods be added to UserString too?

Bye,
    Walter D?rwald



From perky at i18n.org  Thu Jun  3 07:17:01 2004
From: perky at i18n.org (Hye-Shik Chang)
Date: Thu Jun  3 07:17:11 2004
Subject: [Python-Dev] 	RE: [Python-checkins] python/dist/src/Misc NEWS,
	1.983, 1.984
In-Reply-To: <40BEFCE3.20406@livinglogic.de>
References: <1ED4ECF91CDED24C8D012BCF2B034F13064C0269@its-xchg4.massey.ac.nz>
	<40BEFCE3.20406@livinglogic.de>
Message-ID: <20040603111701.GA76378@i18n.org>

On Thu, Jun 03, 2004 at 12:26:43PM +0200, Walter D?rwald wrote:
> Tony Meyer wrote:
> 
> >[...]
> >
> >>! - Unicode type got two new methods now; iswide() and width(). They
> >>!   manipulate east asian width information from Unicode TR11.
> 
> Should these methods be added to UserString too?
> 

iswide() and width() are for unicode objects only.  Please see
Martin's reply on addition of the methods to string objects:
http://mail.python.org/pipermail/python-dev/2004-June/045153.html

Hye-Shik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040603/175efe8f/attachment-0001.bin
From skip at pobox.com  Thu Jun  3 07:45:24 2004
From: skip at pobox.com (Skip Montanaro)
Date: Thu Jun  3 07:45:55 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <40BEEC49.1070708@interlink.com.au>
References: <200406021519.i52FJP025688@guido.python.org>
	<40BEEC49.1070708@interlink.com.au>
Message-ID: <16575.3924.80349.163359@montanaro.dyndns.org>


    Anthony> (By "absolutely right" I mean you can look at it and say "yes,
    Anthony> that's definitely the way to do it").

    Anthony> And hey, we have the alpha cycle to get it right.

This may seem silly, but would it be possible to support both grammars
during the alpha cycle so people get a chance to try it out (especially
those people most likely to use the feature) and weed one out for the beta?
I take it the grammar changes would be only a small source of bugs, and in
any case, dumping one after the alpha should reduce the bug count.

Skip

From pf_moore at yahoo.co.uk  Thu Jun  3 08:23:57 2004
From: pf_moore at yahoo.co.uk (Paul Moore)
Date: Thu Jun  3 08:23:58 2004
Subject: [Python-Dev] Re: Stackless Python
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de> <7224D932-B467-11D
	<40BE0FC9.1060907@stackless.com>
Message-ID: <ekowomn6.fsf@yahoo.co.uk>

Christian Tismer <tismer@stackless.com> writes:

> This is true, we have written demo implementations of tasklets
> with pure Python and threads on the last sprint.
>
> The difference is that nobody would use these for production code,

I don't know if this is true. In a production environment where there
is an existing Python installation, but no Stackless installation, and
where performance is not a killer issue, tasklets *may* be useful for
their organisational benefits.

I say *may* because I don't know much about tasklets. A pure Python
implementation may help my understanding.

Is the demo downloadable from anywhere?

Paul.
-- 
This signature intentionally left blank


From tismer at stackless.com  Thu Jun  3 08:54:36 2004
From: tismer at stackless.com (Christian Tismer)
Date: Thu Jun  3 08:52:56 2004
Subject: [Python-Dev] Re: Stackless Python
In-Reply-To: <ekowomn6.fsf@yahoo.co.uk>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<40BBA2B8.7000907@v.loewis.de>	<20040530133843.51528.qmail@web50709.mail.yahoo.com>	<40BAE605.5040800@v.loewis.de>
	<40BB6C9B.4040701@ieee.org>	<40BB7E63.9090304@v.loewis.de>	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>	<40BB8882.60503@v.loewis.de>	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>	<40BB9C17.20500@v.loewis.de>	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>	<40BBA2B8.7000907@v.loewis.de>	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>	<200406010431.i514Vfs22302@guido.python.org>	<40BC745A.7070700@stackless.com>	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D	<40BE0FC9.1060907@stackless.com>
	<ekowomn6.fsf@yahoo.co.uk>
Message-ID: <40BF1F8C.5020906@stackless.com>

Paul Moore wrote:
> Christian Tismer <tismer@stackless.com> writes:
> 
> 
>>This is true, we have written demo implementations of tasklets
>>with pure Python and threads on the last sprint.
>>
>>The difference is that nobody would use these for production code,
> 
> 
> I don't know if this is true. In a production environment where there
> is an existing Python installation, but no Stackless installation, and
> where performance is not a killer issue, tasklets *may* be useful for
> their organisational benefits.
> 
> I say *may* because I don't know much about tasklets. A pure Python
> implementation may help my understanding.
> 
> Is the demo downloadable from anywhere?

Yes, in current cvs under Stackless/demo/stephan

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From walter at livinglogic.de  Thu Jun  3 09:18:47 2004
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu Jun  3 09:18:55 2004
Subject: [Python-Dev] 	RE: [Python-checkins] python/dist/src/Misc NEWS,
	1.983, 1.984
In-Reply-To: <20040603111701.GA76378@i18n.org>
References: <1ED4ECF91CDED24C8D012BCF2B034F13064C0269@its-xchg4.massey.ac.nz>
	<40BEFCE3.20406@livinglogic.de> <20040603111701.GA76378@i18n.org>
Message-ID: <40BF2537.1020908@livinglogic.de>

Hye-Shik Chang wrote:

> On Thu, Jun 03, 2004 at 12:26:43PM +0200, Walter D?rwald wrote:
> 
>>Tony Meyer wrote:
>>
>>>[...]
>>>
>>>>! - Unicode type got two new methods now; iswide() and width(). They
>>>>!   manipulate east asian width information from Unicode TR11.
>>
>>Should these methods be added to UserString too?
> 
> 
> iswide() and width() are for unicode objects only.  Please see
> Martin's reply on addition of the methods to string objects:
> http://mail.python.org/pipermail/python-dev/2004-June/045153.html

Yes, but UserString.UserString can be used to wrap both str and
unicode objects.

Bye,
    Walter D?rwald



From john at neggie.net  Thu Jun  3 09:24:17 2004
From: john at neggie.net (John Belmonte)
Date: Thu Jun  3 09:24:34 2004
Subject: [Python-Dev] [development doc updates]
In-Reply-To: <20040603061548.6A9D718EAC0@grendel.fdrake.net>
References: <20040603061548.6A9D718EAC0@grendel.fdrake.net>
Message-ID: <40BF2681.5080902@neggie.net>

Fred L. Drake wrote:
> The development version of the documentation has been updated:
> 
>     http://www.python.org/dev/doc/devel/

In <http://www.python.org/dev/doc/devel/whatsnew/node6.html>,
"Added an newcode opcode" should probably be "Added a new opcode".

-John

-- 
http://giftfile.org/  ::  giftfile project

From fdrake at acm.org  Thu Jun  3 09:31:51 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu Jun  3 09:32:01 2004
Subject: [Python-Dev] [development doc updates]
In-Reply-To: <40BF2681.5080902@neggie.net>
References: <20040603061548.6A9D718EAC0@grendel.fdrake.net>
	<40BF2681.5080902@neggie.net>
Message-ID: <200406030931.51253.fdrake@acm.org>

On Thursday 03 June 2004 09:24 am, John Belmonte wrote:
 > In <http://www.python.org/dev/doc/devel/whatsnew/node6.html>,
 > "Added an newcode opcode" should probably be "Added a new opcode".

Fixed in CVS; thanks!


  -Fred

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


From perky at i18n.org  Thu Jun  3 09:53:15 2004
From: perky at i18n.org (Hye-Shik Chang)
Date: Thu Jun  3 09:53:20 2004
Subject: [Python-Dev] 	RE: [Python-checkins] python/dist/src/Misc NEWS,
	1.983, 1.984
In-Reply-To: <40BF2537.1020908@livinglogic.de>
References: <1ED4ECF91CDED24C8D012BCF2B034F13064C0269@its-xchg4.massey.ac.nz>
	<40BEFCE3.20406@livinglogic.de> <20040603111701.GA76378@i18n.org>
	<40BF2537.1020908@livinglogic.de>
Message-ID: <20040603135315.GA78807@i18n.org>

On Thu, Jun 03, 2004 at 03:18:47PM +0200, Walter D?rwald wrote:
> Hye-Shik Chang wrote:
> 
> >On Thu, Jun 03, 2004 at 12:26:43PM +0200, Walter D?rwald wrote:
> >
> >>Tony Meyer wrote:
> >>
> >>>[...]
> >>>
> >>>>! - Unicode type got two new methods now; iswide() and width(). They
> >>>>!   manipulate east asian width information from Unicode TR11.
> >>
> >>Should these methods be added to UserString too?
> >
> >
> >iswide() and width() are for unicode objects only.  Please see
> >Martin's reply on addition of the methods to string objects:
> >http://mail.python.org/pipermail/python-dev/2004-June/045153.html
> 
> Yes, but UserString.UserString can be used to wrap both str and
> unicode objects.
> 

Aah. Sorry. I've overlooked extensive use of UserString. :)

Could you review my patch?:
http://people.freebsd.org/~perky/userstring-width.diff

Hye-Shik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040603/a8cffba0/attachment.bin
From guido at python.org  Thu Jun  3 10:11:38 2004
From: guido at python.org (Guido van Rossum)
Date: Thu Jun  3 10:23:38 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: Your message of "Thu, 03 Jun 2004 06:45:24 CDT."
	<16575.3924.80349.163359@montanaro.dyndns.org> 
References: <200406021519.i52FJP025688@guido.python.org>
	<40BEEC49.1070708@interlink.com.au> 
	<16575.3924.80349.163359@montanaro.dyndns.org> 
Message-ID: <200406031411.i53EBc028092@guido.python.org>

> This may seem silly, but would it be possible to support both
> grammars during the alpha cycle so people get a chance to try it out
> (especially those people most likely to use the feature) and weed
> one out for the beta?  I take it the grammar changes would be only a
> small source of bugs, and in any case, dumping one after the alpha
> should reduce the bug count.

Hm, I can only see downsides to this.  Producing the unified patch
would be painful, as the code has to deal with both sources of
decorators (and what if both are present???).  Users would be confused
about which syntax to use.  Users would be discouraged even more than
with one alternative to use the feature except for pure experiments,
because they won't know until the beta cycle which syntax will
survive.  Ripping out one version would be problematic (due to the
merging of patches).

As I said before, I'll try to discuss this extensively with users at
EuroPython.

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

From amk at amk.ca  Thu Jun  3 10:58:00 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Thu Jun  3 10:58:11 2004
Subject: [Python-Dev] Python bug day?
In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F13064C026A@its-xchg4.massey.ac.nz>
References: <1ED4ECF91CDED24C8D012BCF2B034F1306967317@its-xchg4.massey.ac.nz>
	<1ED4ECF91CDED24C8D012BCF2B034F13064C026A@its-xchg4.massey.ac.nz>
Message-ID: <20040603145800.GB14367@rogue.amk.ca>

On Thu, Jun 03, 2004 at 02:42:29PM +1200, Tony Meyer wrote:
> Are these generated by SourceForge?  If so, note that the same problem
> affecting viewcvs and anonymous cvs is also affecting the tarballs as well.

No, the page links to the CVS snapshots provided by the Perl
developers: http://cvs.perl.org/snapshots/python/python/ .  Checking
the tree, it's slightly out of date; the newest files in the tree
dated 06/03 only show changes up to 05/29, but that's close enough.

If worst comes to worst, I could always make a tarball Saturday
morning and drop it on python.org.  (If the bug tracker goes down on
Saturday, we're screwed, though.)

SourceForge-related: in the past running our own SF setup has been
suggested, but the general opinion (my own included) has been that the
administrative burden would be too much effort.

Recently I chatted with Rich Kilmer, whose company specializes in
setting up the GForge software for organizational use.  They run
http://www.semwebcentral.org/ for DARPA and a large internal site for
Xerox, for example, and also donate the effort for a GForge for
Ruby-based projects (www.rubyforge.org).  He said the day-to-day task
of running RubyForge only takes up a few hours a week, a surprisingly
low figure.  Setting up GForge for the first time is still pretty
complicated, but he offered to donate some engineer time to help;
they've gotten pretty good at it.  I believe they also sell
preconfigured machines that will run a GForge setup; if we deemed it
worthwhile to run our own, the PSF could purchase such a machine.

--amk

From walter at livinglogic.de  Thu Jun  3 11:03:21 2004
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu Jun  3 11:03:30 2004
Subject: [Python-Dev] 	RE: [Python-checkins] python/dist/src/Misc NEWS,
	1.983, 1.984
In-Reply-To: <20040603135315.GA78807@i18n.org>
References: <1ED4ECF91CDED24C8D012BCF2B034F13064C0269@its-xchg4.massey.ac.nz>
	<40BEFCE3.20406@livinglogic.de> <20040603111701.GA76378@i18n.org>
	<40BF2537.1020908@livinglogic.de> <20040603135315.GA78807@i18n.org>
Message-ID: <40BF3DB9.50006@livinglogic.de>

Hye-Shik Chang wrote:

> On Thu, Jun 03, 2004 at 03:18:47PM +0200, Walter D?rwald wrote:
> 
>> [...]
>>Yes, but UserString.UserString can be used to wrap both str and
>>unicode objects.
> 
> Aah. Sorry. I've overlooked extensive use of UserString. :)
> 
> Could you review my patch?:
> http://people.freebsd.org/~perky/userstring-width.diff

I don't think it's necessary to define iswide() and width()
only when self.data is a unicode object (in fact, self.data
might change from str to unicode during the lifetime of the
UserString object). Simply define

     # the following methods are defined for unicode objects only:
     def iswide(self): return self.data.iswide()
     def width(self): return self.data.width()

When a str object is wrapped, an AttributeError will be raised
anyway, it shouldn't be a problem that this error is not raised
by UserString itself. You could add comments to the method like
this:

     def iswide(self): return self.data.iswide() # unicode only
     def width(self): return self.data.width() # unicode only

that will show up in a stacktrace and give a hint to the user.

It's good that the tests are in string_tests.py now, but you
should reuse this test class in test_unicode.py too.

Bye,
    Walter D?rwald



From ark-mlist at att.net  Thu Jun  3 11:16:42 2004
From: ark-mlist at att.net (Andrew Koenig)
Date: Thu Jun  3 11:16:40 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <200406021708.i52H8kP26104@guido.python.org>
Message-ID: <001e01c4497d$c6ee4460$6602a8c0@arkdesktop>

> Do you think you can come up with a patch, or at least a description
> of an algorithm that someone without a wizard level understanding of
> the issues could implement?

The following code is lightly but not exhaustively tested, but I do think it
gives a good idea of the algorithm.  In particular, note that
compare(fmagic, lmagic+1) is -1 even though (fmagic==lmagic+1) yields True.


lmagic = 1
fmagic = 1.0
while fmagic + 1.0 != fmagic:
    fmagic += fmagic
    lmagic += lmagic
assert fmagic + 1.0 == fmagic
assert fmagic - 1.0 != fmagic

# fmagic and lmagic are the float and long representations of the
# smallest power of 2 for which the floating-point LSB is strictly
# greater than 1.  Accordingly, adding 1 to this magic value doesn't
# change it, but subtracting 1 does (because it is a power of 2, so
# the subtraction makes the representation one bit shorter).

# Because of the properties of fmagic and lmagic, converting an
# integer that is < lmagic to floating-point will lose no information,
# and converting a floating-point number that is >= fmagic to long
# will also lose no information.

def sign(x):
    if x > 0:
        return 1
    if x < 0:
        return -1
    return 0

def simple_compare(x, y):               # arguments both float or neither
    if x < y:
        return -1
    if x > y:
        return 1
    return 0

def compare(x, y):
    # We handle only integers and floats
    if type(x) not in [int, long, float]:
        raise TypeError, "left argument to compare not integer or float"
    if type(y) not in [int, long, float]:
        raise TypeError, "right argument to compare not integer or float"

    # If the arguments are the same type (counting int and long as
    # the same), there's nothing special to do
    if (type(x) == float) == (type(y) == float):
        return simple_compare(x, y)

    # Perhaps the signs will make the comparison unnecessary
    signx = sign(x)
    signy = sign(y)
    if signx != signy or signx == 0:
        return simple_compare(signx, signy)

    # Now we know that both arguments are nonzero and have the same
    # sign.  We'll use signx to remember the original sign and make
    # the arguments both positive for convenience.
    if signx < 0:
        x = -x
        y = -y

    # We have reduced the problem to one where the arguments are both
    # positive and exactly one of them is float--but we don't know
    # which one.  For convenience, we'll make x float by swapping x
    # and y if necessary, adjusting signx as appropriate.
    if type(y) == float:
        x, y = y, x
        signx = -signx

    assert type(x) == float
    assert type(y) in [int, long]
    assert x > 0 and y > 0

    # If x and y are on different sides of the magic barrier, we're
    # done.
    if x >= fmagic and y < lmagic:
        return signx
    if x < fmagic and y >= lmagic:
        return -signx

    # Now we know that x and y are on the same side of the barrier.
    # Depending on which side, we will convert x to long or y to
    # float, then compare.
    if x >= fmagic:
        x = long(x)
    else:
        y = float(y)
    return signx * simple_compare(x, y)


From pje at telecommunity.com  Thu Jun  3 11:22:01 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu Jun  3 11:20:25 2004
Subject: [Python-Dev] Re: Stackless Python
In-Reply-To: <ekowomn6.fsf@yahoo.co.uk>
References: <5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<40BBA2B8.7000907@v.loewis.de>
	<20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
	<F8297E54-B346-11D8-9388-000A95686CD8@redivi.com>
	<40BBA2B8.7000907@v.loewis.de>
	<5.1.1.6.0.20040531202832.037b7ec0@mail.telecommunity.com>
	<5.1.1.6.0.20040601001051.01f00ca0@mail.telecommunity.com>
	<200406010431.i514Vfs22302@guido.python.org>
	<40BC745A.7070700@stackless.com>
	<5.1.1.6.0.20040601115717.020e4760@mail.telecommunity.com>
	<5.1.1.6.0.20040602010111.0291f7d0@mail.telecommunity.com>
	<0272635E-B457-11D8-9821-000A95686CD8@redivi.com>
	<40BD6C9D.90003@v.loewis.de>
	<7224D932-B467-11D <40BE0FC9.1060907@stackless.com>
Message-ID: <5.1.1.6.0.20040603111655.02983840@mail.telecommunity.com>

At 01:23 PM 6/3/04 +0100, Paul Moore wrote:
>Christian Tismer <tismer@stackless.com> writes:
>
> > This is true, we have written demo implementations of tasklets
> > with pure Python and threads on the last sprint.
> >
> > The difference is that nobody would use these for production code,
>
>I don't know if this is true. In a production environment where there
>is an existing Python installation, but no Stackless installation, and
>where performance is not a killer issue, tasklets *may* be useful for
>their organisational benefits.
>
>I say *may* because I don't know much about tasklets. A pure Python
>implementation may help my understanding.
>
>Is the demo downloadable from anywhere?

Also keep in mind that tasklet-like operations can be done using 
state-machine callbacks (e.g. Twisted), or using nested generators (e.g. 
'peak.events').  Callbacks have the problem of "twisting" what would 
otherwise be linear code, and if you're using generators, you have to use 
"generators all the way down" to code that does task switching.  IOW, you 
can't have a non-generator call a generator and have that generator be able 
to task-switch.

The net result of either approach is that you can't use any existing code 
(outside of those frameworks, of course) as part of your tasks.


From barry at python.org  Thu Jun  3 09:33:54 2004
From: barry at python.org (Barry Warsaw)
Date: Thu Jun  3 11:50:35 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <200406031411.i53EBc028092@guido.python.org>
References: <200406021519.i52FJP025688@guido.python.org>
	<40BEEC49.1070708@interlink.com.au>
	<16575.3924.80349.163359@montanaro.dyndns.org>
	<200406031411.i53EBc028092@guido.python.org>
Message-ID: <1086269634.7269.27.camel@localhost>

On Thu, 2004-06-03 at 10:11, Guido van Rossum wrote:

> As I said before, I'll try to discuss this extensively with users at
> EuroPython.

Please do!  Personally, your syntax is not my preference, but I'd rather
have the feature in 2.4, so I'm willing to trust your intuition.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040603/0569481c/attachment.bin
From noamr at myrealbox.com  Thu Jun  3 18:07:48 2004
From: noamr at myrealbox.com (Noam Raphael)
Date: Thu Jun  3 23:50:55 2004
Subject: [Python-Dev] An ability to specify start and length of slices
Message-ID: <40BFA134.10404@myrealbox.com>

Hello,

Many times I find myself asking for a slice of a specific length, rather 
than a slice with a specific end. I suggest to add the syntax 
object[start:>length] (or object[start:>length:jump]), beside the 
existing syntax.


Two examples:

1. Say I have a list with the number of panda bears hunted in each 
month, starting from 1900. Now I want to know how many panda bears were 
hunted in year y. Currently, I have to write something like this:
sum(huntedPandas[(y-1900)*12:(y-1900)*12+12])
If my suggestion is accepted, I would be able to write:
sum(huntedPandas[(y-1900)*12:>12])

2. Many data files contain fields of fixed length. Just an example: say 
I want to get the color of the first pixel of a 24-bit color BMP file. 
Say I have a function which gets a 4-byte string and converts it into a 
32-bit integer. The four bytes, from byte no. 10, are the size of the 
header, in bytes. Right now, if I don't want to use temporary variables, 
I have to write:
picture[s2i(picture[10:14]):s2i(picture[10:14])+4]
I think this is nicer (and quicker):
picture[s2i(picture[10:>4]):>4]

(I mean to show that when working with data files, it's common to have 
slices of specific length, and that the proposed syntax makes things 
clear and simple. I took BMP just as an example - I know about PIL.)


Other solutions (from comp.lang.python responses):

1. Of course, the longer form may be used, and a temporary variable may 
be used to avoid repeated function calls.
2. The idiom object[start:][:length] may be used. However, it may be 
very inefficient, if the list is long. Another advantage of the proposed 
syntax is that it can be used in multi-dimensional slices (for example, 
ar[:,x:>3,:])
3. The programmer may define the function lambda object, start, length: 
object[start:start+length]. This does make expressions quite short, but 
it isn't very readable IMHO, and doesn't deal with multi-dimensional slices.


Objections (also from comp.lang.python):

1. There should be only one way to do something in Python.
2. Some don't like how it looks.
3. l[a:b] yields an empty list when a>b, and l[a:>b] doesn't.


My responses:

1. Changes should be taken seriously, and the language must be kept 
simple and easy to read, but it doesn't mean that there should be only 
one way to do something. Just an example: you could write l[:,:,:,3], 
but the ellipsis token lets you write l[...,3].
2. I can't really argue with that, besides saying that it looks fine to 
me; The symbol '>' generally means "move to the right". I think that 
l[12345:>10] can easily be read as "start from 12345, and move 10 steps 
to the right. Take all the items you passed over."
3. l[a:>b] doesn't look like l[a:b] and it means something altogether 
different. Besides, l[a:b:-1] doesn't yield an empty list when a > b.


Some technical details:

My proposal only affects the conversion from Python code into byte-code. 
This is why it is easy to implement and has no side effects, as far as I 
can see.
I changed the definition of "subscript" in the Grammar file from:
subscript: '.' '.' '.' | test | [test] ':' [test] [sliceop]
into:
subscript: '.' '.' '.' | test | ([test] ':' [test] | test ':>' test) 
[sliceop]
and added the ':>' token to tokenize.c and token.h.
I then extended compile.c to handle the new syntax.

The byte code produced is basically simple: Calculate start, calculate 
length, and add start to length to get the usual start, end. It gets a 
bit complicated because you want range(10)[3:>-5], for example, to yield 
an empty list, and using the method described, it will be equivalent to 
range(10)[3:-2], that is, to [3,4,5,6,7]. So the byte-code my 
implementation produces checks to see if the resulting end is negative 
and start is positive, and if so, puts -sys.maxint, instead of 
start+length, as end. -sys.maxint is used instead of the more obvious 
choice, 0, so that range(10)[3:>-5:-1] will yield [3,2,1,0] and not [3,2,1].
This can be optimized, because I expect that usually length will be an 
integer given explicitly in the Python code, in which case no testing 
has to be done in the byte-code.

Attached are the 4 diffs. I'm sorry, they are against the Python-2.3.3 
release (the sourceforge CVS doesn't work for me currently), but I 
expect them to work fine with the CVS head.


To summerize, this is a small addition, with no side-effects or 
backward-compatibility issues, which will help me and others.

Well, what do you think? I would like to hear your comments.


Best wishes,
Noam Raphael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Grammar.diff
Type: text/x-patch
Size: 808 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040604/cf70e9a5/Grammar.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compile.c.diff
Type: text/x-patch
Size: 2278 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040604/cf70e9a5/compile.c.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: token.h.diff
Type: text/x-patch
Size: 767 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040604/cf70e9a5/token.h.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tokenizer.c.diff
Type: text/x-patch
Size: 550 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040604/cf70e9a5/tokenizer.c.bin
From guido at python.org  Fri Jun  4 00:21:49 2004
From: guido at python.org (Guido van Rossum)
Date: Fri Jun  4 00:21:21 2004
Subject: [Python-Dev] An ability to specify start and length of slices
In-Reply-To: Your message of "Fri, 04 Jun 2004 01:07:48 +0300."
	<40BFA134.10404@myrealbox.com> 
References: <40BFA134.10404@myrealbox.com> 
Message-ID: <200406040421.i544Ln302375@guido.python.org>

> Many times I find myself asking for a slice of a specific length, rather 
> than a slice with a specific end. I suggest to add the syntax 
> object[start:>length] (or object[start:>length:jump]), beside the 
> existing syntax.

Feel free to continue to argue for this, but I'm -1, and that usually
kills a proposal dead.  I doubt that you'll be able to get enough
influential people on python-dev to rally for your proposal; but I'm
sure they will explain to you why your syntax is unpythonic and the
feature is so minor as to be unneeded.

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

From tdelaney at avaya.com  Fri Jun  4 01:38:18 2004
From: tdelaney at avaya.com (Delaney, Timothy C (Timothy))
Date: Fri Jun  4 01:38:27 2004
Subject: [Python-Dev] An ability to specify start and length of slices
Message-ID: <338366A6D2E2CA4C9DAEAE652E12A1DE018F0376@au3010avexu1.global.avaya.com>

Guido van Rossum wrote:

>> Many times I find myself asking for a slice of a specific length,
>> rather than a slice with a specific end. I suggest to add the syntax
>> object[start:>length] (or object[start:>length:jump]), beside the
>> existing syntax.
> 
> Feel free to continue to argue for this, but I'm -1, and that usually
> kills a proposal dead.  I doubt that you'll be able to get enough
> influential people on python-dev to rally for your proposal; but I'm
> sure they will explain to you why your syntax is unpythonic and the
> feature is so minor as to be unneeded.

It already was explained when this came up on c.l.py ...

Tim Delaney

From theller at python.net  Fri Jun  4 05:59:46 2004
From: theller at python.net (Thomas Heller)
Date: Fri Jun  4 06:00:36 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <16575.3924.80349.163359@montanaro.dyndns.org> (Skip
	Montanaro's message of "Thu, 3 Jun 2004 06:45:24 -0500")
References: <200406021519.i52FJP025688@guido.python.org>
	<40BEEC49.1070708@interlink.com.au>
	<16575.3924.80349.163359@montanaro.dyndns.org>
Message-ID: <ekovlk31.fsf@python.net>

Couldn't Guido's syntax be implemented as a combination of an import
hook together with a byte code hack, without direct support in the core?

Code like this

  [decorator1, decorator2]
  def func(args):
      pass

seems to be compiled into these byte codes
             ....
           6 BUILD_LIST               
           9 POP_TOP             
          10 LOAD_CONST               0 (<code object test at 0091FD20, ...)
          13 MAKE_FUNCTION            0
          16 STORE_NAME               2 (test)

It seems BUILD_LIST / POP_TOP / LOAD_CONST / MAKE_FUNCTION is the
sequence which should trigger the magic.

Thomas


From tismer at stackless.com  Fri Jun  4 06:29:36 2004
From: tismer at stackless.com (Christian Tismer)
Date: Fri Jun  4 06:29:03 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <ekovlk31.fsf@python.net>
References: <200406021519.i52FJP025688@guido.python.org>	<40BEEC49.1070708@interlink.com.au>	<16575.3924.80349.163359@montanaro.dyndns.org>
	<ekovlk31.fsf@python.net>
Message-ID: <40C04F10.8010607@stackless.com>

Thomas Heller wrote:
> Couldn't Guido's syntax be implemented as a combination of an import
> hook together with a byte code hack, without direct support in the core?

I think I proposed that long time ago, and it was dissed
as a hack.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From jhylton at gmail.com  Fri Jun  4 08:38:21 2004
From: jhylton at gmail.com (Jeremy Hylton)
Date: Fri Jun  4 08:46:48 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <ekovlk31.fsf@python.net>
References: <200406021519.i52FJP025688@guido.python.org>
	<40BEEC49.1070708@interlink.com.au>
	<16575.3924.80349.163359@montanaro.dyndns.org>
	<ekovlk31.fsf@python.net>
Message-ID: <e8bf7a5304060405387fc317f0@mail.gmail.com>

On Fri, 04 Jun 2004 11:59:46 +0200, Thomas Heller <theller@python.net> wrote:
> 
> Couldn't Guido's syntax be implemented as a combination of an import
> hook together with a byte code hack, without direct support in the core?
> 
> Code like this
> 
>   [decorator1, decorator2]
>   def func(args):
>       pass

How about this?

[decorator1, decorator2]
if 0:
    print "Obscure corner case?"
def func(args):
    pass
 
> seems to be compiled into these byte codes
>              ....
>            6 BUILD_LIST
>            9 POP_TOP
>           10 LOAD_CONST               0 (<code object test at 0091FD20, ...)
>           13 MAKE_FUNCTION            0
>           16 STORE_NAME               2 (test)
> 
> It seems BUILD_LIST / POP_TOP / LOAD_CONST / MAKE_FUNCTION is the
> sequence which should trigger the magic.

I don't recall Guido's patch.  Did he modify the grammar or can it all
be done inside the compiler?  Not that it's practical for 2.4, but I
think it wouldn't be hard to post-process the existing AST to
recognize decorators written like this.

You'd like for adjacent statements of the form:
    Expr(List())
    FunctionDef()
and replace them with a single
    FunctionDef()

Or do we need to catch Expr(ListComp()) too?  PEP 318 doesn't mention
semantics anywhere, so it doesn't say what is allowed inside the
square brackets.

Jeremy

From ncoghlan at iinet.net.au  Fri Jun  4 09:53:39 2004
From: ncoghlan at iinet.net.au (Nick Coghlan)
Date: Fri Jun  4 09:54:01 2004
Subject: [Python-Dev] An ability to specify start and length of slices
In-Reply-To: <40BFA134.10404@myrealbox.com>
References: <40BFA134.10404@myrealbox.com>
Message-ID: <40C07EE3.7030006@iinet.net.au>

Noam Raphael wrote:

> Two examples:

Both examples you give are far more self-explanatory if you use 
temporary variables to create self-documenting code rather than trying 
to squeeze everything in to one line. Particularly since using magic 
numbers in your code is generally evil, anyway.

(The X's in the code examples are just so they don't look like quoted 
sections to Thunderbird and other mail clients)

> 1. Say I have a list with the number of panda bears hunted in each 
> month, starting from 1900. Now I want to know how many panda bears were 
> hunted in year y. Currently, I have to write something like this:
> sum(huntedPandas[(y-1900)*12:(y-1900)*12+12])
> If my suggestion is accepted, I would be able to write:
> sum(huntedPandas[(y-1900)*12:>12])

X >>> y_jan = (y-1900)*12
X >>> sum(huntedPandas[y_jan:y_jan+12])

> 2. Many data files contain fields of fixed length. Just an example: say 
> I want to get the color of the first pixel of a 24-bit color BMP file. 
> Say I have a function which gets a 4-byte string and converts it into a 
> 32-bit integer. The four bytes, from byte no. 10, are the size of the 
> header, in bytes. Right now, if I don't want to use temporary variables, 
> I have to write:
> picture[s2i(picture[10:14]):s2i(picture[10:14])+4]
> I think this is nicer (and quicker):
> picture[s2i(picture[10:>4]):>4]

X >>> header_size = s2i(picture[10:14])
X >>> first_pixel = picture[header_size:header_size+4]

I don't see any reason to change Python to encourage the writing of code 
which is significantly more cryptic as it tries to cram too much onto 
one line.

The only reason I can see for not wanting to use temporary variables is 
if you're using some part of the language that demands an expression 
(e.g. a lambda or a generator expression). But if you're talking about 
embedding this sort of thing inside an *additional* level of expression, 
it's just going to get even *more* unreadable, and it may be time to 
bite the bullet and write a helper function to get the info you want.

If you want extremely concise, but entirely unreadable code, there's 
another language beginning with P that you can use ;)

(you may want to think about submitting a patch that just adds a method 
to lists: list.length_slice(slice_start, slice_length). You'd probably 
need a better name than the one I just used, though)

Regards,
Nick.

-- 
Nick Coghlan               |     Brisbane, Australia
Email: ncoghlan@email.com  | Mobile: +61 409 573 268

From guido at python.org  Fri Jun  4 10:17:27 2004
From: guido at python.org (Guido van Rossum)
Date: Fri Jun  4 10:17:33 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: Your message of "Fri, 04 Jun 2004 08:38:21 EDT."
	<e8bf7a5304060405387fc317f0@mail.gmail.com> 
References: <200406021519.i52FJP025688@guido.python.org>
	<40BEEC49.1070708@interlink.com.au>
	<16575.3924.80349.163359@montanaro.dyndns.org>
	<ekovlk31.fsf@python.net> 
	<e8bf7a5304060405387fc317f0@mail.gmail.com> 
Message-ID: <200406041417.i54EHRH03295@guido.python.org>

> I don't recall Guido's patch.  Did he modify the grammar or can it
> all be done inside the compiler?

The parser generator is too weak to allow a grammar change to work, so
I did it in the compiler.

> Not that it's practical for 2.4, but I
> think it wouldn't be hard to post-process the existing AST to
> recognize decorators written like this.
> 
> You'd like for adjacent statements of the form:
>     Expr(List())
>     FunctionDef()
> and replace them with a single
>     FunctionDef()
> 
> Or do we need to catch Expr(ListComp()) too?  PEP 318 doesn't mention
> semantics anywhere, so it doesn't say what is allowed inside the
> square brackets.

My patch excludes list comprehensions, because I need to know the
number of elements of the list for the code I generate.  The PEP
should be disambiguated to disallow list comps.

(I see no merit to the import hook + bytecode hack approach.)

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

From skip at pobox.com  Fri Jun  4 10:22:22 2004
From: skip at pobox.com (Skip Montanaro)
Date: Fri Jun  4 10:22:47 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <e8bf7a5304060405387fc317f0@mail.gmail.com>
References: <200406021519.i52FJP025688@guido.python.org>
	<40BEEC49.1070708@interlink.com.au>
	<16575.3924.80349.163359@montanaro.dyndns.org>
	<ekovlk31.fsf@python.net>
	<e8bf7a5304060405387fc317f0@mail.gmail.com>
Message-ID: <16576.34206.857000.425530@montanaro.dyndns.org>

    Jeremy> Not that it's practical for 2.4, but I think it wouldn't be hard
    Jeremy> to post-process the existing AST to recognize decorators written
    Jeremy> like this.

    Jeremy> You'd like for adjacent statements of the form:
    Jeremy>     Expr(List())
    Jeremy>     FunctionDef()
    Jeremy> and replace them with a single
    Jeremy>     FunctionDef()

Yes, but only if it appears at the top level of a module.

    Jeremy> Or do we need to catch Expr(ListComp()) too?  PEP 318 doesn't
    Jeremy> mention semantics anywhere, so it doesn't say what is allowed
    Jeremy> inside the square brackets.

I think you probably have to look at Michael Hudson's patch for semantics at
the moment.  The original PEP 318 was purely about syntax.  I made some
changes and Jim Jewett sent me some more changes which I still have sitting
in my mailbox.  I'll see if I can dig them out over the weekend and merge
them in.

Skip

From guido at python.org  Fri Jun  4 10:51:50 2004
From: guido at python.org (Guido van Rossum)
Date: Fri Jun  4 10:51:57 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: Your message of "Fri, 04 Jun 2004 09:22:22 CDT."
	<16576.34206.857000.425530@montanaro.dyndns.org> 
References: <200406021519.i52FJP025688@guido.python.org>
	<40BEEC49.1070708@interlink.com.au>
	<16575.3924.80349.163359@montanaro.dyndns.org>
	<ekovlk31.fsf@python.net>
	<e8bf7a5304060405387fc317f0@mail.gmail.com> 
	<16576.34206.857000.425530@montanaro.dyndns.org> 
Message-ID: <200406041451.i54Epol03419@guido.python.org>

>     Jeremy> You'd like for adjacent statements of the form:
>     Jeremy>     Expr(List())
>     Jeremy>     FunctionDef()
>     Jeremy> and replace them with a single
>     Jeremy>     FunctionDef()
> 
> Yes, but only if it appears at the top level of a module.

Why?  Can't I nest decorated functions inside other functions?  And a
class isn't at the top of a module either.

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

From pf_moore at yahoo.co.uk  Fri Jun  4 11:40:03 2004
From: pf_moore at yahoo.co.uk (Paul Moore)
Date: Fri Jun  4 11:40:01 2004
Subject: [Python-Dev] Re: Dropping decorator syntax for 2.4?
References: <200406021519.i52FJP025688@guido.python.org>
	<40BEEC49.1070708@interlink.com.au>
	<16575.3924.80349.163359@montanaro.dyndns.org>
	<ekovlk31.fsf@python.net>
	<e8bf7a5304060405387fc317f0@mail.gmail.com>
	<200406041417.i54EHRH03295@guido.python.org>
Message-ID: <zn7js564.fsf@yahoo.co.uk>

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

> (I see no merit to the import hook + bytecode hack approach.)

Is the merit not that it can be implemented as a module, with no core
changes, hence allowing experimentation with the syntax?

Paul.
-- 
This signature intentionally left blank


From FBatista at uniFON.com.ar  Fri Jun  4 12:08:26 2004
From: FBatista at uniFON.com.ar (Batista, Facundo)
Date: Fri Jun  4 12:11:49 2004
Subject: [Python-Dev] Decimal issues - Conclusion
Message-ID: <A128D751272CD411BC9200508BC2194D033839E5@escpl.tcp.com.ar>

People:

Sorry for the delay, but between the moment that the discussion in
python-dev settled down and now, my car got stolen, my grandmother
got into the hospital (brain accident), and I was designed as
Deployment Manager of the new SMS Center that bought the company I
work for.

Anyway, all the following is the discussion itself post-crunched.
The first three items are the result of the subjects for which the
discussion was initiated.  The other items are subjects that arose
alone.

A lot of new functionalities were asked for inclusion into the PEP,
but we're trying to keep it pure at this stage.  From Tim Peters:

    Piles of "convenience features" should wait until people actually
    use this in real life, so can judge what's truly clumsy based on
    experience instead of speculation.

Unless there're strong feelings against any point, my plan is to
include the results in the PEP 327 and send it again to Tim for a
re-review.  The only tricky part is that I propose something new at
the end of the first point. 

Thanks you all for the time and knowledge that invested in this.
Even the points that didn't got through to this resume added a lot of
value.

.	Facundo



Exponent maximum
----------------

The original post asked if to keep the maximum exponent value::

    DEFAULT_MAX_EXPONENT = 999999999
    DEFAULT_MIN_EXPONENT = -999999999
    ABSOLUTE_MAX_EXP = 999999999
    ABSOLUTE_MIN_EXP = -999999999

The general consenss is to keep the artificial limits only if there
are important reasons to do that.  Tim Peters gives us three:

    ...eliminating bounds on exponents effectively means overflow
    (and underflow) can never happen.  But overflow *is* a valuable
    safety net in real life fp use, like a canary in a coal mine,
    giving danger signs early when a program goes insane.

    Virtually all implementations of 854 use (and as IBM's standard
    even suggests) "forbidden" exponent values to encode non-finite
    numbers (infinities and NaNs).  A bounded exponent can do this at
    virtually no extra storage cost.  If the exponent is unbounded,
    then additional bits have to be used instead.  This cost remains
    hidden until more time- and space- efficient implementations are
    attempted.

    Big as it is, the IBM standard is a tiny start at supplying a
    complete numeric facility.  Having no bound on exponent size will
    enormously complicate the implementations of, e.g., decimal sin()
    and cos() (there's then no a priori limit on how many digits of
    pi effectively need to be known in order to perform argument
    reduction).

Edward Loper give us an example of when the limits are to be crossed:
probabilities.

Said that, Robert Brewer and Andrew Lentvorski want the limits to be
easily modifiable by the users.  Actually, this is quite posible::

    >>> d1 = Decimal("1e999999999")     # in the exponent limit
    >>> d1
    Decimal( (0, (1,), 999999999L) )
    >>> d1 * 10                         # exceed the limit, got infinity
    Decimal( (0, (0,), 'F') )
    >>> getcontext().Emax = 1000000000  # increase the limit
    >>> d1 * 10                         # does not exceed any more
    Decimal( (0, (1, 0), 999999999L) )  
    >>> d1 * 100                        # exceed again
    Decimal( (0, (0,), 'F') )

However, note that sometimes absolute maximum and minimum are
actually used, and they can not be changed.  Actually, I want to
change this:

    As long as all the good effects of a maximum can be achieved with
    modifiable maximum and minimum, I propose to not have absolute
    ones (in the Spec this is optional).


Hash behaviour
--------------

This point was about the behaviour of hash() on Decimals.

Community agrees that if the values are the same, also the hashes of
those values.  So, while Decimal(25) == 25 is True, hash(Decimal(25))
should be equal to hash(25). 

The detail is that you can NOT compare Decimal to floats or strings,
so we should not worry about them to give the same hashes.

In short::

    hash(n) == hash(Decimal(n))   # Only if n is int, long, or Decimal


New operations
--------------

There were three operations that I missed to put in the PEP:

- ``to-scientific-string``: Converts a number to a string using
  scientific notation if an exponent is needed.

- ``to-engineering-string``: Converts a number to a string using
  engineering notation if an exponent is needed.

- ``to-number``: Converts a string to a number.

The discussion originated the community wish to change the behaviour
of repr() and str().  Ka-Ping Yee proposes that repr() have the same
behaviour that str() and Tim Peters proposes to str() behave like the
to-scientific-string operation specified in the Spec.

This is posible, because (from Aahz): "The string form already
contains all the necessary information to reconstruct a Decimal
object".

And also complies with the Spec; Tim Peters:

    There's no requirement to have a method *named* "to_sci_string",
    the only requirement is that *some* way to spell to-sci-string's
    functionality be supplied.  The meaning of to-sci-string is
    precisely specified by the standard, and is a good choice for
    both str(Decimal) and repr(Decimal).

Tim also proposes a method as_tuple() to return the internal triple
tuple, the way repr() behaved until now.

So, in short:

- str() and repr() will behave as the to-scientific-string operation.
  Because of that we won't put a specific method for it.

- ``to_eng_string`` will be the name of the method for the
  to-engineering-string operation.

- As long as we can pass a string to create a Decimal using the
  context, we won't put a specific method for the to-number operation.

- We'll put a new method to return the internal triple tuple: as_tuple()


Create with other Context
-------------------------

This item arose from two sources in parallel.  Ka-Ping Yee proposes
to pass the context as argument at construct time (he wants the
context he passes to be used only in creation time: "It would not be
persistent").  Tony Meyer asks from_string to honor the context if
receives a parameter "honour_context" in True (I don't like it,
because the doc specify to honor the context and I don't want the
method to comply with the specification regarding the value of an
argument)

Tim Peters gives us a reason to have a creation that uses context:

    In general number-crunching, literals may be given to high
    precision, but that precision isn't free and *usually* isn't
    needed

Casey Duncan wants to use another method, not a bool arg:

    I find boolean arguments a general anti-pattern, especially given
    we have class methods. Why not use an alternate constructor like
    Decimal.rounded_to_context("3.14159265").

In the process of deciding the syntax of that, Tim came up with a
better idea: he proposes not to have a method in Decimal to create
with a different context, but having instead a method in Context to
create a Decimal instance.  Basically, instead of::

    D.using_context(number, context)

it will be::

    context.create_decimal(number)

>From Tim:

    While all operations in the spec except for the two to-string
    operations use context, no operations in the spec support an
    optional local context.  That the Decimal() constructor ignores
    context by default is an extension to the spec.  We must supply a
    context-honoring from-string operation to meet the spec.  I
    recommend against any concept of "local context" in any operation
    -- it complicates the model and isn't necessary.  

So, we decided to use a context method to create a Decimal that will
use (only to be created) that context in particular (fur further
operations it'll use the context of the thread).  But, a method with
what name?

I proposed the name create_decimal().  Tim Peters proposes three
methods to create from diverse sources::

    context.from_string(a_string)
    context.from_int(an_int_or_long)
    context.from_float(a_float)

Michael Chermside says to use the same method without caring about
the data type: "The name just fits my brain. The fact that it uses
the context is obvious from the fact that it's Context method".  I
think that it's ok because a newbie will not be using the creation
method from Context (the separate method in Decimal to construct from
float is just to prevent newbies from binary floating point issues).

So, in short, if you want to create a Decimal instance using a
particular context (that will be used just in creation time and not
further), you'll have to use a method of that context::

    mycontext.create_decimal(n)  # being n any datatype accepted in
                                 #   Decimal(n) plus float.

Example::

    >>> # create a standard decimal instance
    >>> Decimal("11.2233445566778899")  
    Decimal( (0, (1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8, 9, 9),
-16) )
    >>>
    >>> # create a decimal instance using the thread context
    >>> thread_context = getcontext()
    >>> thread_context.prec
    9
    >>> thread_contex.create_decimal("11.2233445566778899")
    Decimal( (0, (1, 1, 2, 2, 3, 3, 4, 4, 6), -7L) )
    >>>
    >>> # create a decimal instance using other context
    >>> other_context = thread_context.copy()
    >>> other_context.prec = 4
    >>> other_context.create_decimal("11.2233445566778899")
    Decimal( (0, (1, 1, 2, 2), -2L) )


New method in Context
---------------------

Paul Moore wants a copy method in Context, so I'll put copy() and
__copy__ methods in Context (but not in Decimal: it's immutable, it's
not needed).


Extracting a method from Decimal
--------------------------------

Tim Peters doesn't want round() because it's not in the Spec and you
can achieve the same result with quantize()::

    >>> d = Decimal("12345.6789")
    >>> dimes = Decimal('0.1')
    >>> print d.quantize(dimes)
    12345.7
    >>> print d.quantize(Decimal('1e1'))
    1.235E+4
    >>>

So, as long the PEP is for implementing the Spec, I'll drop round().

From skip at pobox.com  Fri Jun  4 12:37:42 2004
From: skip at pobox.com (Skip Montanaro)
Date: Fri Jun  4 12:38:03 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <200406041451.i54Epol03419@guido.python.org>
References: <200406021519.i52FJP025688@guido.python.org>
	<40BEEC49.1070708@interlink.com.au>
	<16575.3924.80349.163359@montanaro.dyndns.org>
	<ekovlk31.fsf@python.net>
	<e8bf7a5304060405387fc317f0@mail.gmail.com>
	<16576.34206.857000.425530@montanaro.dyndns.org>
	<200406041451.i54Epol03419@guido.python.org>
Message-ID: <16576.42326.238134.67982@montanaro.dyndns.org>

    >> Yes, but only if it appears at the top level of a module.

    Guido> Why?  Can't I nest decorated functions inside other functions?
    Guido> And a class isn't at the top of a module either.

I thought you stated that as a desired/implemented restriction of your
syntax when you first proposed it.

Skip


From theller at python.net  Fri Jun  4 09:06:09 2004
From: theller at python.net (Thomas Heller)
Date: Fri Jun  4 13:11:06 2004
Subject: [Python-Dev] Re: Dropping decorator syntax for 2.4?
References: <200406021519.i52FJP025688@guido.python.org>
	<40BEEC49.1070708@interlink.com.au>
	<16575.3924.80349.163359@montanaro.dyndns.org>
	<ekovlk31.fsf@python.net>
	<e8bf7a5304060405387fc317f0@mail.gmail.com>
Message-ID: <r7svjwvy.fsf@python.net>

Jeremy Hylton <jhylton@gmail.com> writes:

> On Fri, 04 Jun 2004 11:59:46 +0200, Thomas Heller <theller@python.net> wrote:
>> 
>> Couldn't Guido's syntax be implemented as a combination of an import
>> hook together with a byte code hack, without direct support in the core?
>> 
>> Code like this
>> 
>>   [decorator1, decorator2]
>>   def func(args):
>>       pass
>
> How about this?
>
> [decorator1, decorator2]
> if 0:
>     print "Obscure corner case?"
> def func(args):
>     pass
>  
>> seems to be compiled into these byte codes
>>              ....
>>            6 BUILD_LIST
>>            9 POP_TOP
>>           10 LOAD_CONST               0 (<code object test at 0091FD20, ...)
>>           13 MAKE_FUNCTION            0
>>           16 STORE_NAME               2 (test)
>> 
>> It seems BUILD_LIST / POP_TOP / LOAD_CONST / MAKE_FUNCTION is the
>> sequence which should trigger the magic.
>
> I don't recall Guido's patch.  Did he modify the grammar or can it all
> be done inside the compiler?  Not that it's practical for 2.4, but I
> think it wouldn't be hard to post-process the existing AST to
> recognize decorators written like this.

He does it inside the compiler.  The patch is here:
http://python.org/sf/926860

> You'd like for adjacent statements of the form:
>     Expr(List())
>     FunctionDef()
> and replace them with a single
>     FunctionDef()
>
> Or do we need to catch Expr(ListComp()) too?  PEP 318 doesn't mention
> semantics anywhere, so it doesn't say what is allowed inside the
> square brackets.

IIUC, inside the square brackets only a list of simple expressions is
allowed.

Two more remarks:

1. Guido's patch contains one flaw, as I see it: it doesn't work for top
level functions. That is probably good for interactive use, but bad for
modules.  I don't know if this was intended or not.

2. Implementing my proposal above doesn't seem trivial.  Default
arguments to functions can contain arbitrarily complex expressions, so
at least a simple pattern matching on byte codes does not work.

3. My interest in this is because it would be nice to get a
backwards compatible way to use this in Python 2.3.

Thomas


From tim.one at comcast.net  Fri Jun  4 15:10:25 2004
From: tim.one at comcast.net (Tim Peters)
Date: Fri Jun  4 15:10:34 2004
Subject: [Python-Dev] An ability to specify start and length of slices
In-Reply-To: <40BFA134.10404@myrealbox.com>
Message-ID: <mailman.344.1086376234.6944.python-dev@python.org>

[Noam Raphael]
> Many times I find myself asking for a slice of a specific length, rather
> than a slice with a specific end. I suggest to add the syntax
> object[start:>length] (or object[start:>length:jump]), beside the
> existing syntax.

It would be convenient at times, and I've got nothing against that.  It
isn't *necessary*, and if it were to be added the syntax should change.

Python's sequence slicing is so similar to that in the earlier Icon language
that for years I thought Guido borrowed it from Icon (but years later he
told me that's not so).  Icon has 1-based indexing (Python's is 0-based),
but apart from that they're the same.

In Icon, the notations are, e.g.,

    S[5:8]  # S[5], S[6], and S[7]
and
    S[5+:3] # also S[5], S[6], and S[7]

"+:" suggests addition in a way ":>" does not, so I think it's a better
notation.  Putting the '+' before the colon is also reminiscent of, e.g.

    i += j

conceptually expanding to

    i = i+j

Then

    i +: j

conceptually expanding to

    i : i+j

is the same syntactic pattern.  I should note that Icon had the good sense
to stop there too <wink>.



From jepler at unpythonic.net  Fri Jun  4 15:52:36 2004
From: jepler at unpythonic.net (Jeff Epler)
Date: Fri Jun  4 15:52:42 2004
Subject: [Python-Dev] An ability to specify start and length of slices
In-Reply-To: <40BFA134.10404@myrealbox.com>
References: <40BFA134.10404@myrealbox.com>
Message-ID: <20040604195236.GO19278@unpythonic.net>

Some questions:

At the top, you mention the syntax
    object[start:>length:jump]
  but you never explain what that does.  Is it equivalent to
    object[start:start+length*jump:jump] # give length items
  or
    object[start:start+length:jump] # give length/jump items
  ?

What about negative strides?

Is there a way to ask for the length items just before stop, for
instance
    object[>length:start:jump]
?

About Tim's suggestion:

Pretending for a moment that it could fly, can we make sure this works
with dicts, and also create +, for tuples and lists?

I'd like
    { 1 +: 3 }
to create the dict {1:4}, and for
    1, 3 +, 5
to create the tuple (1, 3, 8)

One last comment -- While you'll have a hard sell with this new syntax
idea, having an implementation for it makes you stand above all the
other people peddling their bad syntax change on the mailing lists.

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040604/868f4225/attachment.bin
From tim.one at comcast.net  Fri Jun  4 16:02:59 2004
From: tim.one at comcast.net (Tim Peters)
Date: Fri Jun  4 16:03:09 2004
Subject: [Python-Dev] An ability to specify start and length of slices
In-Reply-To: <20040604195236.GO19278@unpythonic.net>
Message-ID: <mailman.345.1086379389.6944.python-dev@python.org>

[Jeff Epler]
...
> Pretending for a moment that it could fly, can we make sure this works
> with dicts, and also create +, for tuples and lists?
>
> I'd like
>     { 1 +: 3 }
> to create the dict {1:4}, and for
>     1, 3 +, 5
> to create the tuple (1, 3, 8)

As I said last time,

     I should note that Icon had the good sense to stop there too ...

> One last comment -- While you'll have a hard sell with this new syntax
> idea, having an implementation for it makes you stand above all the other
> people peddling their bad syntax change on the mailing lists.

+1.  Noam did his homework!  I hope he doesn't give up just because Guido
wishes he had never been born <wink>.



From tjreedy at udel.edu  Fri Jun  4 17:51:41 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri Jun  4 17:51:55 2004
Subject: [Python-Dev] 'Buggy' feature requests
Message-ID: <c9qqti$1i6$1@sea.gmane.org>

Some items in the bug list are feature requests that better belong in the
RFE list, in spite of the unremovable Bugs list Feature Request group.
Seeking more authoritative guidance than my own feelings, and hoping to get
something I could direct feature-missing-is-a-bug posters to,  I opened
item 964703.
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=964703&group_id=5470

In responding (and closing) Tim Peters nicely fulfilled both goals. Perhaps
other bug reviewers might find this item a handy reference when trying to
prune the bug list, and perhaps closing requests as not-a-bug.

Terry J. Reedy




From paul at prescod.net  Fri Jun  4 22:36:11 2004
From: paul at prescod.net (Paul Prescod)
Date: Fri Jun  4 22:36:18 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <200406021519.i52FJP025688@guido.python.org>
References: <200406021519.i52FJP025688@guido.python.org>
Message-ID: <40C1319B.4050809@prescod.net>

Guido van Rossum wrote:
> Anthony's updates to PEP 320 (the 2.4 release schedule) reminded me
> that I still haven't decided on the decorator syntax.  I still hate
> the most popular proposal (def foo(args) [decorators]: body) and my
> own proposal is unpopular.  I just saw the Java metadata syntax again
> and want to think about being inspired by that instead of by the C#
> syntax.  On the plus side, Java's @name(kwargs) syntax allows us to
> put decorators in front methods and classes without ambiguous syntax;
> on the minus side, using up a potential operator character for one
> specific purpose should not be done lightly.  But I don't want to get
> too deep into this discussion -- I just want to suggest that we put
> this off and get 2.4 on the road without any decorator syntax at all.
> What do people think of that?

How about:

from __experimental__ import decorator_syntax

  Paul Prescod


From kbk at shore.net  Sat Jun  5 02:52:51 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sat Jun  5 02:52:57 2004
Subject: [Python-Dev] Weekly Python Bug/Patch Summary
Message-ID: <200406050652.i556qp7W018936@hydra.localdomain>


Patch / Bug Summary
___________________

Patches :  274 open ( -6) /  2401 closed (+10) /  2675 total ( +4)
Bugs    :  762 open (-13) /  4094 closed (+36) /  4856 total (+23)
RFE     :  138 open ( +1) /   128 closed ( +1) /   266 total ( +2)

New / Reopened Patches
______________________

Fix for #777597 - socketmodule.c connection handling incorec  (2004-06-02)
       http://python.org/sf/965036  opened by  Troels Walsted Hansen 

improve markupbase.py error reporting  (2004-06-02)
       http://python.org/sf/965175  opened by  No Spam 

improve markupbase.py error reporting  (2004-06-02)
CLOSED http://python.org/sf/965192  opened by  No Spam 

Cleanup generator/eval_frame exposure  (2004-06-04)
       http://python.org/sf/966493  opened by  James William Pye 

Patches Closed
______________

Improved hash for tuples  (2004-05-19)
       http://python.org/sf/957122  closed by  rhettinger

East Asian Width support for Unicode  (2004-05-29)
       http://python.org/sf/962502  closed by  perky

Public Generator Object/Type  (2004-05-20)
       http://python.org/sf/957398  closed by  loewis

Fix os.stat handling of UNC roots  (2004-05-14)
       http://python.org/sf/954115  closed by  loewis

Use .dylib for shared objects on MacOS X  (2002-11-21)
       http://python.org/sf/641685  closed by  jackjansen

Patch for feature request 491033  (2004-05-20)
       http://python.org/sf/957240  closed by  loewis

Improvements to Bluetooth support  (2004-04-04)
       http://python.org/sf/929192  closed by  loewis

improve markupbase.py error reporting  (2004-06-02)
       http://python.org/sf/965192  closed by  nnorwitz

Make IDLE's paragraph reformatting width configurable  (2004-05-27)
       http://python.org/sf/961387  closed by  rhettinger

Patch to setup.py to run on x86_64 Linux  (2004-03-30)
       http://python.org/sf/926209  closed by  loewis

New / Reopened Bugs
___________________

random.choice([]) should return more intelligible exception  (2004-06-01)
       http://python.org/sf/964230  opened by  Michael Hoffman 

Cannot encode 5 digit unicode.  (2004-06-01)
CLOSED http://python.org/sf/964284  opened by  Bugs Fly 

email package uses \n to rebuild content of a message  (2004-06-01)
       http://python.org/sf/964433  opened by  Marco Bizzarri 

idle help is modal  (2004-06-01)
       http://python.org/sf/964437  opened by  Matthias Klose 

Boolean operations section includes lambda_form grammar rule  (2004-06-01)
CLOSED http://python.org/sf/964525  opened by  Stefanus Du Toit 

2.3.4 Language Reference Typo, Section 2.3.2  (2004-06-02)
CLOSED http://python.org/sf/964592  opened by  Chris Wood 

RFE versus Bug group Feature Request  (2004-06-01)
CLOSED http://python.org/sf/964703  opened by  Terry J. Reedy 

Cookie module does not parse date  (2004-06-02)
       http://python.org/sf/964861  opened by  Manlio Perillo 

pickle protocol 2 is incompatible(?) with Cookie module  (2004-06-02)
       http://python.org/sf/964868  opened by  Manlio Perillo 

sys.getfilesystemencoding()  (2004-06-02)
       http://python.org/sf/964870  opened by  Manlio Perillo 

mapping a 0 length file  (2004-06-02)
       http://python.org/sf/964876  opened by  Manlio Perillo 

Unicode String formatting does not correctly handle objects  (2004-06-02)
       http://python.org/sf/964929  opened by  Giles Antonio Radford 

Ctrl-C causes odd behaviour  (2004-06-02)
       http://python.org/sf/964949  opened by  Michael Bax 

datetime.isoformat() contaiins 'T0'  (2004-06-02)
CLOSED http://python.org/sf/965032  opened by  Doug Fort 

document docs.python.org in PEP-101  (2004-06-03)
       http://python.org/sf/965065  opened by  Anthony Baxter 

importing dynamic modules via embedded python  (2004-06-02)
       http://python.org/sf/965206  opened by  Anne Wilson 

textwrap does not handle single quotes with hyphens properly  (2004-06-02)
CLOSED http://python.org/sf/965425  opened by  Greg Ward 

isinstance fails to recognize instance  (2004-06-03)
CLOSED http://python.org/sf/965562  opened by  Ib Jørgensen 

Build Python 2.3.3 or 4 on RedHat Enterprise fails  (2004-06-03)
CLOSED http://python.org/sf/965991  opened by  Russell Owen 

realpath description misleading  (2004-06-04)
       http://python.org/sf/966256  opened by  GaryD 

Typo in whatsnew24/genexprs  (2004-06-04)
CLOSED http://python.org/sf/966375  opened by  Kristian Ovaska 

Typo in whatsnew24/genexprs  (2004-06-04)
CLOSED http://python.org/sf/966387  opened by  Kristian Ovaska 

import x.y inside of module x.y  (2004-06-04)
       http://python.org/sf/966431  opened by  Armin Rigo 

float_subtype_new() bug  (2004-06-04)
       http://python.org/sf/966618  opened by  Armin Rigo 

execfile, type, __module__, who knows ;)  (2004-06-05)
       http://python.org/sf/966623  opened by  Anthony Baxter 

Documentation for Descriptors in the main docs  (2004-06-05)
       http://python.org/sf/966625  opened by  Raide 

LaTeX not required  (2004-05-05)
       http://python.org/sf/948517  reopened by  aahz

Bugs Closed
___________

Weakness in tuple hash  (2004-04-27)
       http://python.org/sf/942952  closed by  rhettinger

Distutils should be able to produce Debian packages (.deb)  (2004-05-31)
       http://python.org/sf/963825  closed by  akuchling

Typo in Lib/test/test_sax.py can confuse  (2004-05-29)
       http://python.org/sf/962631  closed by  akuchling

Cannot encode 5 digit unicode.  (2004-06-01)
       http://python.org/sf/964284  closed by  mozbugbox

Boolean operations section includes lambda_form grammar rule  (2004-06-01)
       http://python.org/sf/964525  closed by  loewis

2.3.4 Language Reference Typo, Section 2.3.2  (2004-06-01)
       http://python.org/sf/964592  closed by  loewis

RFE versus Bug group Feature Request  (2004-06-01)
       http://python.org/sf/964703  closed by  tim_one

isdir behavior getting odder on UNC path  (2002-02-06)
       http://python.org/sf/513572  closed by  loewis

socket timeouts produce wrong errors in win32  (2003-03-24)
       http://python.org/sf/708927  closed by  glchapman

IPV6 not correctly ifdef'd in socketmodule.c  (2004-03-27)
       http://python.org/sf/924294  closed by  loewis

PyModule_AddIntConstant documented to take an int, not a lon  (2004-05-28)
       http://python.org/sf/962471  closed by  loewis

grammar for "class" inheritance production slightly wrong  (2004-05-26)
       http://python.org/sf/960448  closed by  loewis

datetime.isoformat() contaiins 'T0'  (2004-06-02)
       http://python.org/sf/965032  closed by  anthonybaxter

Incorrect __name__ assignment  (2004-03-26)
       http://python.org/sf/923576  closed by  jackjansen

textwrap does not handle single quotes with hyphens properly  (2004-06-02)
       http://python.org/sf/965425  closed by  gward

isinstance fails to recognize instance  (2004-06-03)
       http://python.org/sf/965562  closed by  doerwalter

locale dependency of string methods undocumented  (2004-04-15)
       http://python.org/sf/935749  closed by  loewis

type of Py_UNICODE depends on ./configure options  (2004-01-22)
       http://python.org/sf/881861  closed by  loewis

Python 2.4: Warn about omitted mutable_flag.  (2003-03-03)
       http://python.org/sf/696535  closed by  loewis

pimp needs to do download itself  (2003-04-10)
       http://python.org/sf/719300  closed by  jackjansen

MacOS9: installer should test CarbonLib version  (2003-08-04)
       http://python.org/sf/783095  closed by  jackjansen

PythonIDE crashes on very large scripts folder  (2004-05-24)
       http://python.org/sf/959291  closed by  jackjansen

AskFolder (EasyDialogs) does not work?  (2004-03-09)
       http://python.org/sf/912758  closed by  jackjansen

-fconstant-cfstrings required for Xcode 1.2  (2004-05-08)
       http://python.org/sf/950482  closed by  jackjansen

Unable to overwrite file with findertools.move  (2004-03-09)
       http://python.org/sf/912747  closed by  jackjansen

PythonLauncher-run scripts have funny $CWD  (2004-03-10)
       http://python.org/sf/913581  closed by  jackjansen

#!/usr/bin/python can find wrong python  (2004-04-10)
       http://python.org/sf/932977  closed by  jackjansen

Python 2.3.3 won't build on MacOSX 10.2  (2003-12-23)
       http://python.org/sf/864985  closed by  jackjansen

InfoPlist.strings files are UTF-16.  (2003-07-04)
       http://python.org/sf/765888  closed by  jackjansen

bundlebuilder standalone app doesn't fully quit  (2004-02-02)
       http://python.org/sf/889200  closed by  jackjansen

I would like an easy way to get to file creation date  (2004-01-16)
       http://python.org/sf/878581  closed by  jackjansen

PythonIDE on osx can't run script with commandline python  (2003-12-19)
       http://python.org/sf/862941  closed by  jackjansen

PythonIDE does not save for PythonLauncher  (2003-12-15)
       http://python.org/sf/860242  closed by  jackjansen

Typo in whatsnew24/genexprs  (2004-06-04)
       http://python.org/sf/966375  closed by  perky

Typo in whatsnew24/genexprs  (2004-06-04)
       http://python.org/sf/966387  closed by  perky

C/C++ extensions w/ Python + Mingw (Windows)  (2004-05-20)
       http://python.org/sf/957198  closed by  theller

Build Python 2.3.3 or 4 on RedHat Enterprise fails  (2004-06-04)
       http://python.org/sf/965991  closed by  anthonybaxter

Bad error mesage when subclassing a module  (2004-05-31)
       http://python.org/sf/963956  closed by  rhettinger

RFE Closed
__________

asyncore - api doesn't provide doneevent  (2001-12-10)
       http://python.org/sf/491033  closed by  loewis


From ncoghlan at iinet.net.au  Sat Jun  5 05:12:18 2004
From: ncoghlan at iinet.net.au (Nick Coghlan)
Date: Sat Jun  5 05:12:27 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <40C1319B.4050809@prescod.net>
References: <200406021519.i52FJP025688@guido.python.org>
	<40C1319B.4050809@prescod.net>
Message-ID: <40C18E72.6080306@iinet.net.au>

Paul Prescod wrote:
> How about:
> 
> from __experimental__ import decorator_syntax

Downloading and installing an alpha build means you're working with 
something experimental by definition. Marking something as 
'extra-experimental' isn't really necessary.

Until we hit the beta, the syntax isn't set in stone.

Regards,
Nick.

-- 
Nick Coghlan               |     Brisbane, Australia
Email: ncoghlan@email.com  | Mobile: +61 409 573 268

From duncan.booth at suttoncourtenay.org.uk  Sat Jun  5 08:18:18 2004
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Sat Jun  5 10:04:39 2004
Subject: [Python-Dev] An ability to specify start and length of slices
References: <40BFA134.10404@myrealbox.com>
Message-ID: <n2m-g.Xns94FF8042A3000duncanrcpcouk@127.0.0.1>

Noam Raphael <noamr@myrealbox.com> wrote in 
news:40BFA134.10404@myrealbox.com:

> Many times I find myself asking for a slice of a specific length, rather 
> than a slice with a specific end. I suggest to add the syntax 
> object[start:>length] (or object[start:>length:jump]), beside the 
> existing syntax.

Can I suggest that rather than adding obscure punctuation, we could just 
have a keyword parameter 'length' to the slice type. So your examples above 
become:

 object[slice(start, length=length)]
and
 object[slice(start, length=length, step=jump)]

I think it is much more in the spirit of Python to write such things out 
explicitly.

> 
> 
> Two examples:
> 
> 1. Say I have a list with the number of panda bears hunted in each 
> month, starting from 1900. Now I want to know how many panda bears were 
> hunted in year y. Currently, I have to write something like this:
> sum(huntedPandas[(y-1900)*12:(y-1900)*12+12])
> If my suggestion is accepted, I would be able to write:
> sum(huntedPandas[(y-1900)*12:>12])

sum(huntedPandas[slice(y-1900)*12, length=12)]

> 
> 2. Many data files contain fields of fixed length. Just an example: say 
> I want to get the color of the first pixel of a 24-bit color BMP file. 
> Say I have a function which gets a 4-byte string and converts it into a 
> 32-bit integer. The four bytes, from byte no. 10, are the size of the 
> header, in bytes. Right now, if I don't want to use temporary variables, 
> I have to write:
> picture[s2i(picture[10:14]):s2i(picture[10:14])+4]
> I think this is nicer (and quicker):
> picture[s2i(picture[10:>4]):>4]
> 

picture[slice(s2i(picture[slice(10, length=4)]), length=4)

although you still need to split that up with some temporary variables to 
make the code self explanatory.

BTW, in Python 2.3.x slice silently ignores any keyword parameters it is 
given, so the above code will actually run right now, it just won't give 
the expected result!

From aahz at pythoncraft.com  Sat Jun  5 10:23:56 2004
From: aahz at pythoncraft.com (Aahz)
Date: Sat Jun  5 10:24:00 2004
Subject: [Python-Dev] An ability to specify start and length of slices
In-Reply-To: <n2m-g.Xns94FF8042A3000duncanrcpcouk@127.0.0.1>
References: <40BFA134.10404@myrealbox.com>
	<n2m-g.Xns94FF8042A3000duncanrcpcouk@127.0.0.1>
Message-ID: <20040605142356.GA18650@panix.com>

Please take this discussion to c.l.py -- Guido has already voted a
strong NO and it's not going anywhere useful for Python's development.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha

From amk at amk.ca  Sat Jun  5 11:13:40 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Sat Jun  5 11:13:48 2004
Subject: [Python-Dev] Allowing uploads in bug tracker
Message-ID: <20040605151340.GA657@rogue.amk.ca>

Is there some setting in the SF bug tracker that prevents people from
attaching files to bug reports?  Several people in #python-dev who
aren't Python developers can't attach patches, but I'm not having any
problems.

--amk


From pf_moore at yahoo.co.uk  Sat Jun  5 11:22:42 2004
From: pf_moore at yahoo.co.uk (Paul Moore)
Date: Sat Jun  5 11:30:46 2004
Subject: [Python-Dev] Re: Allowing uploads in bug tracker
References: <20040605151340.GA657@rogue.amk.ca>
Message-ID: <llj2av25.fsf@yahoo.co.uk>

"A.M. Kuchling" <amk@amk.ca> writes:

> Is there some setting in the SF bug tracker that prevents people from
> attaching files to bug reports?  Several people in #python-dev who
> aren't Python developers can't attach patches, but I'm not having any
> problems.

IIRC, you can't upload files except to a bug you opened yourself.
Possibly you can if you're a project admin, I'm not sure about that.

Paul
-- 
This signature intentionally left blank


From paul at prescod.net  Sat Jun  5 11:39:36 2004
From: paul at prescod.net (Paul Prescod)
Date: Sat Jun  5 11:39:44 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
In-Reply-To: <40C18E72.6080306@iinet.net.au>
References: <200406021519.i52FJP025688@guido.python.org>	<40C1319B.4050809@prescod.net>
	<40C18E72.6080306@iinet.net.au>
Message-ID: <40C1E938.1060808@prescod.net>

Nick Coghlan wrote:

> Paul Prescod wrote:
> 
>> How about:
>>
>> from __experimental__ import decorator_syntax
> 
> 
> Downloading and installing an alpha build means you're working with 
> something experimental by definition. Marking something as 
> 'extra-experimental' isn't really necessary.
> 
> Until we hit the beta, the syntax isn't set in stone.

But maybe we won't have a decision by beta or even by release. I'm 
proposing that the release could have an experimental feature.

  Paul Prescod



From tim.one at comcast.net  Sat Jun  5 11:49:16 2004
From: tim.one at comcast.net (Tim Peters)
Date: Sat Jun  5 11:49:33 2004
Subject: [Python-Dev] Allowing uploads in bug tracker
In-Reply-To: <20040605151340.GA657@rogue.amk.ca>
Message-ID: <mailman.349.1086450573.6944.python-dev@python.org>

[A.M. Kuchling]
> Is there some setting in the SF bug tracker that prevents people from
> attaching files to bug reports?  Several people in #python-dev who aren't
> Python developers can't attach patches, but I'm not having any problems.

You're a bug tracker admin in the Python project, so you can do anything in
the bug tracker (including changing its settings).  I don't know exactly
which permission is needed to attach files to bugs you didn't submit, but
strongly suspect it's this "bug tracker admin" permission.  If so, that can
be given only to people, one at a time, who are already developers on the
project (it's a setting in each individual's project Developer Permissions
page).

To test this theory, I've changed your (Andrew's) role in the bug tracker
from "Tech & Admin" to just "Tech".  Now please try attaching a file to a
bug you didn't submit, and let me know whether you were able to.  (I can't
test the theory on myself, because I'm a Project Admin, and I inherit the
Admin role on all project trackers because of that.)  Don't forget that the
"I'm uploading a file" checkbox has to be marked (even if you are an Admin).



From amk at amk.ca  Sat Jun  5 12:16:14 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Sat Jun  5 12:16:20 2004
Subject: [Python-Dev] Allowing uploads in bug tracker
References: <20040605151340.GA657@rogue.amk.ca>
Message-ID: <20040605161614.GA8040@rogue.amk.ca>

On Sat, Jun 05, 2004 at 11:49:16AM -0400, Tim Peters wrote:
> To test this theory, I've changed your (Andrew's) role in the bug tracker
> from "Tech & Admin" to just "Tech".  Now please try attaching a file to a
> bug you didn't submit, and let me know whether you were able to.  (I can't

Your theory is correct; the 'attach a file' checkbox is now gone.
Wow, tying admin privs and attach-a-file privs is kind of irritating;
people should be able to add patches without necessarily getting the
ability to close bugs.

--amk

From tim.one at comcast.net  Sat Jun  5 12:29:53 2004
From: tim.one at comcast.net (Tim Peters)
Date: Sat Jun  5 12:29:58 2004
Subject: [Python-Dev] Allowing uploads in bug tracker
In-Reply-To: <20040605161614.GA8040@rogue.amk.ca>
Message-ID: <mailman.351.1086452998.6944.python-dev@python.org>

[Tim]
>> To test this theory, I've changed your (Andrew's) role in the bug
>> tracker from "Tech & Admin" to just "Tech".  Now please try attaching a
>> file to a bug you didn't submit, and let me know whether you were able
>> to.

[A.M. Kuchling]
> Your theory is correct; the 'attach a file' checkbox is now gone. Wow,
> tying admin privs and attach-a-file privs is kind of irritating; people
> should be able to add patches without necessarily getting the ability to
> close bugs.

I agree, but nothing we can do about it.  The Zope Collectors (trackers)
have a similar policy, BTW (only the OP or a site manager can attach files
to a collector issue).  There must be a sysadminy kind of fear underlying
this, but don't know what it is.

In any case, I restored your "Tech & Admin" status on the Python bug
tracker, so you can resume distributing warez disguised as patches.

For the duration, people who want to attach files will need to get a Python
developer to attach them (all Python developers I added to the project have
the "Tech & Admin" role on all Python trackers; developers added by other
project admins may not; if you're a Python developer and cannot attach a
file to a tracker item, let me know and I'll boost your permissions).



From michel at dialnetwork.com  Sat Jun  5 11:03:52 2004
From: michel at dialnetwork.com (Michel Pelletier)
Date: Sat Jun  5 13:12:37 2004
Subject: [Python-Dev] Dropping decorator syntax for 2.4?
Message-ID: <200406051003.52509.michel@dialnetwork.com>

> > I agree with Brett that Guido is usually right, so I'm curious about his
> > decision.
>
> I plan to talk it through with people at EuroPython next week.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

I know there's a 2.4 crunch, but if the decision is put off a month longer, 
you can also get face time with a lot of people at OSCON and Vanpyz on this 
issue.

Sorry about the delay, I get digests.

-Michel

From troels at thule.no  Sat Jun  5 13:19:14 2004
From: troels at thule.no (Troels Walsted Hansen)
Date: Sat Jun  5 13:19:24 2004
Subject: [Python-Dev] Allowing uploads in bug tracker
In-Reply-To: <200406051630.i55GUOkL009498@odin.thule.no>
References: <200406051630.i55GUOkL009498@odin.thule.no>
Message-ID: <40C20092.2040008@thule.no>

Tim Peters wrote:

>For the duration, people who want to attach files will need to get a Python
>developer to attach them (all Python developers I added to the project have
>the "Tech & Admin" role on all Python trackers; developers added by other
>project admins may not; if you're a Python developer and cannot attach a
>file to a tracker item, let me know and I'll boost your permissions).
>  
>

I ran into this problem with bug item <http://python.org/sf/777597> My 
solution was to create a new patch item <http://python.org/sf/965036> 
and reference the bug item in the comments. Of course, my solution would 
have been less appropriate if the file I needed to attach had been 
something other than a patch...

Troels


From skip at pobox.com  Sat Jun  5 21:07:32 2004
From: skip at pobox.com (Skip Montanaro)
Date: Sat Jun  5 21:07:40 2004
Subject: [Python-Dev] fopenRF() - defunct MacOS 9 thing?
Message-ID: <16578.28244.616928.748612@montanaro.dyndns.org>


I was messing around in fileobject.c today and came across this:

    #ifdef HAVE_FOPENRF
            if (*mode == '*') {
                    FILE *fopenRF();
                    f->f_fp = fopenRF(name, mode+1);
            }
            else
    #endif

Googling for fopenRF() indicated it is a way to open resource forks on Macs
(all the Google hits were Python-related).  Is that something that should
have been deleted with the demise of MacOS 9 support?

Skip

From kbk at shore.net  Sat Jun  5 21:56:46 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sat Jun  5 21:56:51 2004
Subject: [Python-Dev] python23-maint Branch
Message-ID: <87vfi58n4x.fsf@hydra.localdomain>


Is the branch open for 2.3.5 commit?

-- 
KBK

From tim.one at comcast.net  Sat Jun  5 23:56:32 2004
From: tim.one at comcast.net (Tim Peters)
Date: Sat Jun  5 23:56:39 2004
Subject: [Python-Dev] Free Icon books
In-Reply-To: <40C25DED.8040205@myrealbox.com>
Message-ID: <mailman.354.1086494199.6944.python-dev@python.org>

Speaking of Icon, the 3 major books published on it are available for free
downloading in PDF format now:

    http://www.cs.arizona.edu/icon/books.htm

I especially recommend the "Design & Implementation" book, which is out of
print.  There are few good books about the implementations of very high
level languages, and this book is excellent.  It no longer matches the
current implementation of Icon in several respects, but who cares <wink>.
Two (also free) separate technical reports try to explain how the current
implementation differs:

    http://www.cs.arizona.edu/icon/docs/ipd112.htm
    http://www.cs.arizona.edu/icon/docs/ipd239.htm




From kbk at shore.net  Sun Jun  6 00:32:18 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sun Jun  6 00:32:22 2004
Subject: [Python-Dev] Free Icon books
In-Reply-To: <E1BWosq-0001Uk-IA@mx2.primushost.com> (Tim Peters's message of
	"Sat, 5 Jun 2004 23:56:32 -0400")
References: <E1BWosq-0001Uk-IA@mx2.primushost.com>
Message-ID: <87oenx8fxp.fsf@hydra.localdomain>

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

> I especially recommend the "Design & Implementation" book, which is
> out of print.  There are few good books about the implementations of
> very high level languages, and this book is excellent.  It no longer
> matches the current implementation of Icon in several respects, but
> who cares <wink>.

Cool, thanks.

Ah, the good old days: "Since the initial work was done on a PDP-11/70,
with a user address space of only 128K bytes (combined instruction and
data spaces), the size of the implementation was of significant
concern."

-- 
KBK

From tim.one at comcast.net  Sun Jun  6 01:17:32 2004
From: tim.one at comcast.net (Tim Peters)
Date: Sun Jun  6 01:17:43 2004
Subject: [Python-Dev] An ability to specify start and length of slices
In-Reply-To: <40C25DED.8040205@myrealbox.com>
Message-ID: <mailman.355.1086499063.6944.python-dev@python.org>

[Noam Raphael]
> Ok, why not? Long live +: ! So what do people think of the improved,
> rational syntax? Perhaps someone who have used Icon can share his/her
> experience with us?

My recollection was that it was handy more than just a few times, but
reviewing some Icon code reminded me of why that was so (see below).

In addition to +:, Icon slices also support -:.  This relates to another
difference in Icon slicing:  S[i:j] means the same thing as S[j:i] in Icon.
In Python, for fixed S, i and j, at least one of those forms is an empty
slice.

In the Icon program library distributed with Icon 9.4, there are about 200K
lines of Icon source in about 1200 files.  139 lines match the regexp

    [-+]\s*:(?!=)

(since Icon uses := for assignment, the negative lookahead on "=" is needed
to weed out the Icon augmented assignments +:=, -:=, ++:= and --:=)

So it's not used a lot by Icon experts (< 1 per 1000 lines).  What staring
at this reminded me of (and which I had forgotten) is that the most *common*
use of +: in Icon is slices of the form

    S[1+:n]

to get the leftmost n elements.  Python spells this

    S[:n]

but specifying a starting index isn't optional in Icon.  The handful of uses
of -: outside the test suite are all of the form

    S[0:-n]

which Python spells

    S[-n:]

(get the rightmost n elements).

Several dozen "non-trivial" uses of +: remain, but it's hard to get excited
about them; e.g.,

    line[x+:2] := "["

is marginally easier than

    line[x:x+2] := "["

but Python doesn't support assigning to string slices anyway.

    "abcde"[2+:2]

was an elaborate way to spell

    "bc"

This is a good use:

   every push(layout,show(deck[(0 to 3) * handsize + 1 +: handsize]))

The closest Python is

   layout = [show(deck[i*handsize:(i+1)*handsize]) for i in range(4)]

and

   layout = [show(deck[i*handsize +: handsize]) for i in range(4)]

would indeed be clearer.

That's not enough (IMO) to be worth the pain of changing the language,
though.  Note that if you have a lot of fixed-field strings to parse, the
struct module already supplies a nice way to spell that; e.g., to pick apart
8-character HH:MM:SS strings,

>>> def hms(s):
...     import struct
...     return struct.unpack('2sx2sx2s', s)
...
>>> hms('01:12:45')
('01', '12', '45')
>>>

That's better (clearer, easier, faster) than coding a bunch of fiddly
indexing too.



From anthony at interlink.com.au  Sun Jun  6 03:49:35 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Sun Jun  6 03:49:59 2004
Subject: [Python-Dev] python23-maint Branch
In-Reply-To: <87vfi58n4x.fsf@hydra.localdomain>
References: <87vfi58n4x.fsf@hydra.localdomain>
Message-ID: <40C2CC8F.5030503@interlink.com.au>

Kurt B. Kaiser wrote:
> Is the branch open for 2.3.5 commit?


Yes.

From amk at amk.ca  Sun Jun  6 08:31:25 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Sun Jun  6 08:31:34 2004
Subject: [Python-Dev] Bug day outcome
Message-ID: <20040606123124.GA14035@rogue.amk.ca>

The bug day yesterday was a success, despite ending four hours early
when SourceForge CVS stopped working and didn't come back.  (So, are
we thinking of running our own CVS/SVN/whatever server?)

About eight people showed up; attendance was probably reduced because
some people are at the EuroPython sprints working on other things.
That's still enough people to get a significant amount of work done.

The last bug summary said there were 762 open bugs.  30 bugs (= 4%)
were closed during the bug day, and
http://www.python.org/moin/PythonBugDayStatus lists 14 more bugs that
need to be reviewed by a core developer and possibly committed.

IMHO the bug day was a success, and we should have a few more of them
before 2.4final.  Notes for the next one:

* Perhaps the next one could be on the second weekend in July (the
  10th/11th).  Or should we try to have it before the first alpha is
  released?

* This one was originally supposed to be 12 hours long, but that's
  really too long for the organizer to keep focus :). 
  The next one should be just eight hours.

* The inability for random third-party developers to attach patches to
  bugs was an annoyance, not a serious problem; I attached a few files
  for developers who weren't able to do it themselves.  Still, I hope
  the PSF pushes forward on the Roundup work.

--amk

From skip at pobox.com  Sun Jun  6 09:27:56 2004
From: skip at pobox.com (Skip Montanaro)
Date: Sun Jun  6 09:27:43 2004
Subject: [Python-Dev] various test failures - test_site, test_tempfile,
	test_bsddb/anydbm
Message-ID: <16579.7132.999269.435446@montanaro.dyndns.org>


I was making some simple changes to fileobject.c yesterday (checking file()
mode strings for validity) and started having test failures.  After lots of
head scratching and changes to my code I concluded it couldn't be my code
and finally just ripped out the changes and ran with a fresh CVS checkout.
Sure enough, I got the same problem.  On Mac OS X I get this output (debug
build):

    ...
    test_sys
    test_tarfile
    test_tcl
    test_tempfile
    *** malloc[24360]: error for object 0x680b408: Pointer being reallocated was not allocated
    [5939 refs]
    test test_tempfile failed -- Traceback (most recent call last):
      File "/Users/skip/tmp/python/dist/src/Lib/test/test_tempfile.py", line 155, in test_wanted_dirs
	os.environ[envname] = os.path.abspath(envname)
      File "/Users/skip/tmp/python/dist/src/Lib/os.py", line 445, in __setitem__
	putenv(key, item)
    OSError: (0, 'Error')

    test_textwrap
    test_thread
    test_threaded_import
    test_threadedtempfile
    test_threading
    test_time
    make: *** [test] Bus error

This stuff passes with no complaint on Linux (Mandrake 8.1-ish) but I'm
having other problems there.  Tests involving bsddb fail (I'm building with
Berkeley DB 3.3 - is that too old now?) with something like this:

    test_anydbm
    U??S??c???
    make: *** [quicktest] Segmentation fault

On both Mac OS X and Linux (Mandrake 8.1-ish) test_site fails with:

    test test_site failed -- Traceback (most recent call last):
      File "/home/skip/tmp/python/dist/src/Lib/test/test_site.py", line 150, in test_sitepackages
	self.fail("'site-packages' directory missing'")
    AssertionError: 'site-packages' directory missing'

This seems like a problem with the test itself.  It should be okay to run
the tests in the build directory without a site-packages directory.

I'm doing a little further investigation into the malloc problem on Mac OS X
using the debug stuff available in its malloc(3) implementation.

Skip
 

From mwh at python.net  Sun Jun  6 09:55:42 2004
From: mwh at python.net (Michael Hudson)
Date: Sun Jun  6 09:55:48 2004
Subject: [Python-Dev] various test failures - test_site, test_tempfile,
	test_bsddb/anydbm
In-Reply-To: <16579.7132.999269.435446@montanaro.dyndns.org> (Skip
	Montanaro's message of "Sun, 6 Jun 2004 08:27:56 -0500")
References: <16579.7132.999269.435446@montanaro.dyndns.org>
Message-ID: <2m8yf0yen5.fsf@starship.python.net>

Skip Montanaro <skip@pobox.com> writes:

> Tests involving bsddb fail (I'm building with Berkeley DB 3.3 - is
> that too old now?) with something like this:

Is the bsddd from fink?  I must admit, I've given up on that ...

Cheers,
mwh

-- 
  ARTHUR:  Yes.  It was on display in the bottom of a locked filing
           cabinet stuck in a disused lavatory with a sign on the door
           saying "Beware of the Leopard".
                    -- The Hitch-Hikers Guide to the Galaxy, Episode 1

From perky at i18n.org  Sun Jun  6 10:40:35 2004
From: perky at i18n.org (Hye-Shik Chang)
Date: Sun Jun  6 10:40:43 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <20040606123124.GA14035@rogue.amk.ca>
References: <20040606123124.GA14035@rogue.amk.ca>
Message-ID: <20040606144035.GA48003@i18n.org>

On Sun, Jun 06, 2004 at 08:31:25AM -0400, A.M. Kuchling wrote:
> The bug day yesterday was a success,

Congratulations! :)

> despite ending four hours early
> when SourceForge CVS stopped working and didn't come back.  (So, are
> we thinking of running our own CVS/SVN/whatever server?)

I'm all for this.  It'll be great if we have our own CVS or SVN
repository and bug trackers under our control.

Hye-Shik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040606/74cc2925/attachment.bin
From skip at pobox.com  Sun Jun  6 11:08:50 2004
From: skip at pobox.com (Skip Montanaro)
Date: Sun Jun  6 11:08:44 2004
Subject: [Python-Dev] various test failures - test_site, test_tempfile,
	test_bsddb/anydbm
In-Reply-To: <2m8yf0yen5.fsf@starship.python.net>
References: <16579.7132.999269.435446@montanaro.dyndns.org>
	<2m8yf0yen5.fsf@starship.python.net>
Message-ID: <16579.13186.751965.648492@montanaro.dyndns.org>



    >> Tests involving bsddb fail (I'm building with Berkeley DB 3.3 - is
    >> that too old now?) with something like this:

    Michael> Is the bsddd from fink?  I must admit, I've given up on that
    Michael> ...

No, the bsddb failures occur on the Mandrake system.  I'm using 4.2.52 via
fink on Mac OS X (bsddb stuff works fine there).  I probably should have
posted two separate notes.

Skip

From skip at pobox.com  Sun Jun  6 12:42:43 2004
From: skip at pobox.com (Skip Montanaro)
Date: Sun Jun  6 12:42:24 2004
Subject: [Python-Dev] Re: various test failures - test_site, test_tempfile,
	test_bsddb/anydbm
Message-ID: <16579.18819.175407.224238@montanaro.dyndns.org>

Regarding this message I'm seeing:

    *** malloc[24360]: error for object 0x680b408: Pointer being reallocated was not allocated

a breakpoint in malloc_printf (handy that) yields this stack trace info near
the call:

    Starting program: /Users/skip/tmp/python/dist/src/python.exe Lib/test/regrtest.py -f ~/tmp/tests
    test_sundry
    test_tcl
    test_tempfile
    
    Breakpoint 1, 0x90070ddc in malloc_printf ()
    (gdb) bt 10
    #0  0x90070ddc in malloc_printf ()
    #1  0x9000de5c in szone_realloc ()
    #2  0x9000dd70 in malloc_zone_realloc ()
    #3  0x9000dce8 in realloc ()
    #4  0x90010c24 in setenv ()
    #5  0x90010a74 in putenv ()
    #6  0x0012d280 in posix_putenv (self=0x0, args=0x130e038) at Modules/posixmodule.c:5685
    #7  0x000d9b84 in PyCFunction_Call (func=0x41c878, arg=0x130e038, kw=0x0) at Objects/methodobject.c:73
    #8  0x000ccc1c in call_function (pp_stack=0xbfff9480, oparg=2) at Python/ceval.c:3377
    #9  0x000c6dec in eval_frame (f=0xb41738) at Python/ceval.c:1990
    (More stack frames follow...)
    (gdb) f 6
    #6  0x0012d280 in posix_putenv (self=0x0, args=0x130e038) at Modules/posixmodule.c:5685
    (gdb) p new
    $2 = 0x1078644 "TMPDIR=/Users/skip/tmp/python/dist/src/TMPDIR"
    (gdb) pystack
    /Users/skip/tmp/python/dist/src/Lib/os.py (444): __setitem__
    /Users/skip/tmp/python/dist/src/Lib/test/test_tempfile.py (146): test_wanted_dirs
    /Users/skip/tmp/python/dist/src/Lib/unittest.py (245): run
    /Users/skip/tmp/python/dist/src/Lib/unittest.py (419): __call__
    /Users/skip/tmp/python/dist/src/Lib/unittest.py (419): __call__
    /Users/skip/tmp/python/dist/src/Lib/test/test_support.py (249): run
    /Users/skip/tmp/python/dist/src/Lib/test/test_support.py (255): run_suite
    /Users/skip/tmp/python/dist/src/Lib/test/test_support.py (278): run_unittest
    /Users/skip/tmp/python/dist/src/Lib/test/test_tempfile.py (662): test_main
    Lib/test/regrtest.py (396): runtest
    Lib/test/regrtest.py (124): main
    Lib/test/regrtest.py (77): ?

It seems that the string posix_putenv() is passing to putenv() is properly
allocated.  Setting a breakpoint in setenv() I see only three calls to it,
two from the readline initialization during test_sundry (it looks like to
set LINES and COLS - I have no source for that stuff) and one in
test_tempfile to set TMPDIR (the one causing the malloc warning).  If I
comment out the rlcompleter import in test_sundry the warning disappears and
the failing test in test_tempfile succeeds.  I'm getting libreadline
(version 4.2.0) from fink.

I'm not sure what else I can do to debug this problem.  Should I bother
(readline can be problematic)?  Any thoughts?

Skip

From tim.one at comcast.net  Sun Jun  6 13:22:44 2004
From: tim.one at comcast.net (Tim Peters)
Date: Sun Jun  6 13:22:52 2004
Subject: [Python-Dev] Re: various test failures - test_site, test_tempfile,
	test_bsddb/anydbm
In-Reply-To: <16579.18819.175407.224238@montanaro.dyndns.org>
Message-ID: <mailman.357.1086542572.6944.python-dev@python.org>

[Skip Montanaro]
> Regarding this message I'm seeing:
>
>     *** malloc[24360]: error for object 0x680b408: Pointer being
reallocated was not allocated
>
> a breakpoint in malloc_printf (handy that) yields this stack trace info
> near the call:
>
>     Starting program: /Users/skip/tmp/python/dist/src/python.exe
Lib/test/regrtest.py -f ~/tmp/tests
>     test_sundry
>     test_tcl
>     test_tempfile
>
>     Breakpoint 1, 0x90070ddc in malloc_printf ()
>     (gdb) bt 10
>     #0  0x90070ddc in malloc_printf ()
>     #1  0x9000de5c in szone_realloc ()
>     #2  0x9000dd70 in malloc_zone_realloc ()
>     #3  0x9000dce8 in realloc ()
>     #4  0x90010c24 in setenv ()
>     #5  0x90010a74 in putenv ()
>     #6  0x0012d280 in posix_putenv (self=0x0, args=0x130e038) at
Modules/posixmodule.c:5685

...

> It seems that the string posix_putenv() is passing to putenv() is
> properly allocated.

It is, but "new" is embedded inside a Python string object:

	new = PyString_AS_STRING(newstr);

A realloc(new) call would be insane (new isn't an address returned by
malloc; newstr is the address that was returned by malloc).

You need to look at this platform's implementation of putenv().  If it truly
tries to realloc() the string passed to it, it's insane.

But if it's not trying to realloc(new), then new is a red herring, and the
platform has gotten its pointers into the environment structure screwed up.
That could be due to a wild store anywhere (platform, Python, whatever).



From martin at v.loewis.de  Sun Jun  6 13:25:35 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun Jun  6 13:25:38 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <20040606123124.GA14035@rogue.amk.ca>
References: <20040606123124.GA14035@rogue.amk.ca>
Message-ID: <40C3538F.6020202@v.loewis.de>

A.M. Kuchling wrote:
> The bug day yesterday was a success, despite ending four hours early
> when SourceForge CVS stopped working and didn't come back.  (So, are
> we thinking of running our own CVS/SVN/whatever server?)

I discourage moving away from SF. Our "own" server will have just
as much problems as SourceForge; operating such an infrastructure
should not be taken lightly.

Regards,
Martin


From martin at v.loewis.de  Sun Jun  6 13:28:05 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun Jun  6 13:28:08 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <20040606123124.GA14035@rogue.amk.ca>
References: <20040606123124.GA14035@rogue.amk.ca>
Message-ID: <40C35425.90502@v.loewis.de>

A.M. Kuchling wrote:
> * The inability for random third-party developers to attach patches to
>   bugs was an annoyance, not a serious problem; I attached a few files
>   for developers who weren't able to do it themselves.  Still, I hope
>   the PSF pushes forward on the Roundup work.

Didn't notice this when responding to your message first. Same story
here: We need a volunteer that commits to maintaining the
infrastructure, or ideally two of them. Money (for hardware or network
connectivity) would not be a problem - the PSF is ready to pay such
bills.

Regards,
Martin


From nbastin at opnet.com  Sun Jun  6 13:31:36 2004
From: nbastin at opnet.com (Nick Bastin)
Date: Sun Jun  6 13:31:56 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <40C3538F.6020202@v.loewis.de>
References: <20040606123124.GA14035@rogue.amk.ca>
	<40C3538F.6020202@v.loewis.de>
Message-ID: <5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>


On Jun 6, 2004, at 1:25 PM, Martin v. L?wis wrote:

> A.M. Kuchling wrote:
>> The bug day yesterday was a success, despite ending four hours early
>> when SourceForge CVS stopped working and didn't come back.  (So, are
>> we thinking of running our own CVS/SVN/whatever server?)
>
> I discourage moving away from SF. Our "own" server will have just
> as much problems as SourceForge; operating such an infrastructure
> should not be taken lightly.

I'm not so sure of that.  Obviously, many of the problems with SF have 
to do with the number of projects that they're hosting.  One would hope 
that the load would be a lot less just supporting Python developers.  
Does anybody have any stats on how many CVS checkouts are done on a 
daily basis?  We could rough up some numbers on how much bandwidth we'd 
need to support that.

--
Nick

From neal at metaslash.com  Sun Jun  6 16:52:45 2004
From: neal at metaslash.com (Neal Norwitz)
Date: Sun Jun  6 16:52:50 2004
Subject: [Python-Dev] valgrind report
Message-ID: <20040606205245.GA938@epoch.metaslash.com>

I checked in several changes to support valgrind better.  Mostly it
was documentation changes (additions).  The changes should be minimal
enough to be considered for backporting to 2.3.5.  Although I did not
mark all the checkins as such.  At the end of this mail are the
remaining issues that valgrind reports.

There were very few problems reported.  Valgrind was run on gentoo,
dual amd athlon box with 1GB.

I checked in a fix to Modules/binascii.c.  Someone familiar with
the module should review this change.  It fixed an uninitialized
memory read.  It would be nice to improve the comment.

I fixed a memory leak in Modules/posixmodule.c when callin utime().
The code is a bit complex, so it would be good to review this
change carefully as well.

Neal
--

These are from most important to fix to least important.

I submitted a patch to fix a bunch of possible memory leaks.
the patch fixes at least one memory leak not reported here.
The fixes are in the same location as these leaks.

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

BSD DB memory leaks:
--------------------

 4 bytes in 1 blocks are definitely lost in loss record 7 of 663
    at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
    by 0x3C928265: make_key_dbt (_bsddb.c:400)
    by 0x3C92DE4F: DBC_set_range (_bsddb.c:2911)

 8 bytes in 2 blocks are definitely lost in loss record 29 of 663
    at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
    by 0x3C928265: make_key_dbt (_bsddb.c:400)
    by 0x3C929088: DB_get (_bsddb.c:1349)


I'm not sure which test caused these leaks.  I will try narrow
these two down.  I suspect one may be test_import.py.

Import/compile related memory leaks:
------------------------------------

128 bytes in 1 blocks are definitely lost in loss record 221 of 799
   at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
   by 0x807CDB7: new_arena (obmalloc.c:500)
   by 0x807CAF2: PyObject_Malloc (obmalloc.c:699)
   by 0x807D5A7: PyString_FromStringAndSize (stringobject.c:73)
   by 0x80D6D43: r_object (marshal.c:500)
   by 0x80D63D5: r_object (marshal.c:621)
   by 0x80D5E01: r_object (marshal.c:546)
   by 0x80D6380: r_object (marshal.c:616)
   by 0x80D7683: PyMarshal_ReadLastObjectFromFile (marshal.c:665)
   by 0x80D0CAA: load_source_module (import.c:690)
   by 0x80CEA8D: load_module (import.c:1616)
   by 0x80CF977: import_submodule (import.c:2210)
   by 0x80CF4A2: load_next (import.c:2030)
   by 0x80D14D8: import_module_ex (import.c:1865)
   by 0x80D054B: PyImport_ImportModuleEx (import.c:1906)

256 bytes in 1 blocks are definitely lost in loss record 252 of 799
   at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
   by 0x807CDB7: new_arena (obmalloc.c:500)
   by 0x807CAF2: PyObject_Malloc (obmalloc.c:699)
   by 0x80F8914: PyNode_AddChild (node.c:95)
   by 0x80F8BE1: PyParser_AddToken (parser.c:112)
   by 0x8055AF2: parsetok (parsetok.c:166)
   by 0x80DBFAD: Py_CompileStringFlags (pythonrun.c:1375)
   by 0x80A2AAC: builtin_compile (bltinmodule.c:391)
   by 0x81019F9: PyCFunction_Call (methodobject.c:108)
   by 0x80AA71D: call_function (ceval.c:3377)
   by 0x80AE5FF: eval_frame (ceval.c:1990)
   by 0x80A93AD: PyEval_EvalCodeEx (ceval.c:2543)
   by 0x80AA898: fast_function (ceval.c:3468)
   by 0x80AA3F3: call_function (ceval.c:3397)
   by 0x80AE5FF: eval_frame (ceval.c:1990)

The thread leaks may occur at most once in a program.  I'm not sure.

Thread memory leaks:
--------------------

 16 bytes in 1 blocks are definitely lost in loss record 63 of 663
    at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
    by 0x80DF227: PyThread_allocate_lock (thread_pthread.h:262)
    by 0x80ABC43: PyEval_InitThreads (ceval.c:162)
    by 0x80E287F: thread_PyThread_start_new_thread (threadmodule.c:243)

 64 bytes in 4 blocks are definitely lost in loss record 132 of 663
    at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
    by 0x80E2843: thread_PyThread_start_new_thread (threadmodule.c:233)

Initialization memory leaks:
----------------------------

 64 bytes in 1 blocks are definitely lost in loss record 139 of 663
    at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
    by 0x807CE32: new_arena (obmalloc.c:452)
    by 0x807CAF2: PyObject_Malloc (obmalloc.c:699)
    by 0x80E1566: _PyObject_GC_Malloc (gcmodule.c:1183)
    by 0x80E166C: _PyObject_GC_NewVar (gcmodule.c:1214)
    by 0x8084A71: PyTuple_New (tupleobject.c:68)
    by 0x8087B2F: PyType_Ready (typeobject.c:3161)
    by 0x8087B39: PyType_Ready (typeobject.c:3147)
    by 0x807BE01: _Py_ReadyTypes (object.c:1802)
    by 0x80D9B93: Py_Initialize (pythonrun.c:167)
    by 0x805510A: Py_Main (main.c:376)
    by 0x8054DAA: main (python.c:23)

I don't know if we can fix any of these.  They may all be within
non-Python libraries.

DL memory leaks:
----------------

 17 bytes in 1 blocks are definitely lost in loss record 90 of 663
    at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
    by 0x3C0060D9: _dl_map_object (in /lib/ld-2.3.2.so)
    by 0x3C25E0AA: (within /lib/libc-2.3.2.so)
    by 0x3C00B247: _dl_catch_error (in /lib/ld-2.3.2.so)
    by 0x3C25E6C8: _dl_open (in /lib/libc-2.3.2.so)
    by 0x3C06DCF7: (within /lib/libdl-2.3.2.so)
    by 0x3C00B247: _dl_catch_error (in /lib/ld-2.3.2.so)
    by 0x3C06D485: (within /lib/libdl-2.3.2.so)
    by 0x3C06DD4B: dlopen (in /lib/libdl-2.3.2.so)
    by 0x3F9DD3E2: dl_open (dlmodule.c:184)

Readline memory leaks:
----------------------

 40 bytes in 2 blocks are definitely lost in loss record 116 of 663
    at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
    by 0x3CB85EF1: xmalloc (in /lib/libreadline.so.4.3)

Reading password/group memory leaks:
------------------------------------

36 bytes in 1 blocks are definitely lost in loss record 162 of 799
   at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
   by 0x3C23EBC2: (within /lib/libc-2.3.2.so)
   by 0x3C23E4F2: __nss_database_lookup (in /lib/libc-2.3.2.so)
   by 0x3FA3533D: ???
   by 0x3FA355B0: ???
   by 0x3C23F5FD: (within /lib/libc-2.3.2.so)
   by 0x3C200131: setgrent (in /lib/libc-2.3.2.so)
   by 0x3CA32E17: grp_getgrall (grpmodule.c:123)

36 bytes in 1 blocks are definitely lost in loss record 163 of 799
   at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
   by 0x3C23EBC2: (within /lib/libc-2.3.2.so)
   by 0x3C23E4F2: __nss_database_lookup (in /lib/libc-2.3.2.so)
   by 0x3FA362FD: ???
   by 0x3FA3780C: ???
   by 0x3C201597: getpwnam_r (in /lib/libc-2.3.2.so)
   by 0x3C20103D: getpwnam (in /lib/libc-2.3.2.so)
   by 0x3CB48D80: pwd_getpwnam (pwdmodule.c:130)


From skip at pobox.com  Sun Jun  6 17:36:27 2004
From: skip at pobox.com (Skip Montanaro)
Date: Sun Jun  6 17:36:03 2004
Subject: [Python-Dev] Re: various test failures - test_site, test_tempfile,
	test_bsddb/anydbm
In-Reply-To: <20040606172315.45CB5C9211@majesty.pobox.com>
References: <16579.18819.175407.224238@montanaro.dyndns.org>
	<20040606172315.45CB5C9211@majesty.pobox.com>
Message-ID: <16579.36443.601908.28618@montanaro.dyndns.org>


    >> It seems that the string posix_putenv() is passing to putenv() is
    >> properly allocated.

    Tim> It is, but "new" is embedded inside a Python string object:

    Tim>        new = PyString_AS_STRING(newstr);

    Tim> A realloc(new) call would be insane (new isn't an address returned
    Tim> by malloc; newstr is the address that was returned by malloc).

Agreed.  I grabbed the Darwin libc source from Apple which corresponds to
the version of Mac OS X I'm running.  The only realloc() call in
stdlib/setenv.c is to realloc the entire environment.  The environment
pointer is a funny beast.  It starts out not in malloc'd storage but has to
be malloc'd if it needs to be resized:

        static int alloced;                     /* if allocated space before */
        ...
        char ***environp = _NSGetEnviron();

        ...
                register int cnt;
                register char **p;

                for (p = *environp, cnt = 0; *p; ++p, ++cnt);
                if (alloced) {                  /* just increase size */
                        *environp = (char **)realloc((char *)*environp,
                            (size_t)(sizeof(char *) * (cnt + 2)));
                        if (!*environp)
                                return (-1);
                }
                else {                          /* get new space */
                        alloced = 1;            /* copy old entries into it */
                        p = malloc((size_t)(sizeof(char *) * (cnt + 2)));

I stepped through the raw machine code in gdb.  The alloced variable gets
set properly (0 the first time through, then the space is malloc'd and
alloced is set to 1).  On the third call to setenv() the malloc_printf call
is triggered.

    Tim> But if it's not trying to realloc(new), then new is a red herring,
    Tim> and the platform has gotten its pointers into the environment
    Tim> structure screwed up.  That could be due to a wild store anywhere
    Tim> (platform, Python, whatever).

*sigh* That seems to be the case.  I haven't the energy to pick over machine
code to find out where "anywhere" is...

Skip

From martin at v.loewis.de  Sun Jun  6 17:47:28 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun Jun  6 17:47:34 2004
Subject: [Python-Dev] Allowing uploads in bug tracker
In-Reply-To: <20040605161614.GA8040@rogue.amk.ca>
References: <20040605151340.GA657@rogue.amk.ca>
	<20040605161614.GA8040@rogue.amk.ca>
Message-ID: <40C390F0.1010607@v.loewis.de>

A.M. Kuchling wrote:
>>To test this theory, I've changed your (Andrew's) role in the bug tracker
>>from "Tech & Admin" to just "Tech".  Now please try attaching a file to a
>>bug you didn't submit, and let me know whether you were able to.  (I can't
> 
> 
> Your theory is correct; the 'attach a file' checkbox is now gone.
> Wow, tying admin privs and attach-a-file privs is kind of irritating;
> people should be able to add patches without necessarily getting the
> ability to close bugs.

I disagree: people should never attach patches to bug reports (even
if they can). Instead, they should create an item in the patches
tracker and indicate that this patches fixes a bug in the subject
(which is what many people have been doing all the time). They should
leave a comment in the bug report indicating that there is a patch
for it.

That way, it is much easier to see what the bugs with patches are.

Regards,
Martin


From martin at v.loewis.de  Sun Jun  6 17:54:37 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun Jun  6 17:54:41 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>
References: <20040606123124.GA14035@rogue.amk.ca>	<40C3538F.6020202@v.loewis.de>
	<5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>
Message-ID: <40C3929D.5030609@v.loewis.de>

Nick Bastin wrote:
> I'm not so sure of that.  Obviously, many of the problems with SF have 
> to do with the number of projects that they're hosting.  One would hope 
> that the load would be a lot less just supporting Python developers.  
> Does anybody have any stats on how many CVS checkouts are done on a 
> daily basis?  We could rough up some numbers on how much bandwidth we'd 
> need to support that.

I don't think even SF has such numbers. However, bandwidth is not a
problem - the PSF is willing to reimburse anybody hosting the Python CVS
for bandwidth (although donations are certainly welcome).

The issue is providing timely service: what if the system runs out of
memory, gets cracked by a hacker, a new committer needs to be added,
the sendmail installation gets stuck because some commit messages cannot
be delivered to some recipient, and so on.

Such a system needs permanent hand-holding. Certainly, the number of
projects that SF hosts do cause delays in timely responses. OTOH,
they also have many more full-time people for hand-holding than we
will ever get.

Regards,
Martin


From nas at arctrix.com  Sun Jun  6 19:01:24 2004
From: nas at arctrix.com (Neil Schemenauer)
Date: Sun Jun  6 19:01:33 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <40C3929D.5030609@v.loewis.de>
References: <20040606123124.GA14035@rogue.amk.ca>
	<40C3538F.6020202@v.loewis.de>
	<5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>
	<40C3929D.5030609@v.loewis.de>
Message-ID: <20040606230124.GA11886@mems-exchange.org>

On Sun, Jun 06, 2004 at 11:54:37PM +0200, "Martin v. L?wis" wrote:
> I don't think even SF has such numbers. However, bandwidth is not a
> problem - the PSF is willing to reimburse anybody hosting the Python CVS
> for bandwidth (although donations are certainly welcome).

Really?  What would be a reasonable monthy fee?  I ask because the
bandwidth required for hosting both a checkin and an a anonymous
repository may be quite a lot.  A full checkout seems to be about
100 MB.  The hosting plan I'm looking at now offers 50 GiB/month for
$40.

> The issue is providing timely service: what if the system runs out of
> memory, gets cracked by a hacker, a new committer needs to be added,
> the sendmail installation gets stuck because some commit messages cannot
> be delivered to some recipient, and so on.
> 
> Such a system needs permanent hand-holding. Certainly, the number of
> projects that SF hosts do cause delays in timely responses. OTOH,
> they also have many more full-time people for hand-holding than we
> will ever get.

If the PSF pays the hosting fees, I am willing manage a Subversion
repository for Python.  If we can get one ore two people to offer
backup support when I'm not available then I think we could offer
better service than SF.

If we would want to host the tracker as well, I would need more
help.  I'm not experienced in supporting Roundup, etc.  I suspect
they may require more hand-holding.

  Neil

From bob at redivi.com  Sun Jun  6 19:18:49 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sun Jun  6 19:18:56 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <20040606230124.GA11886@mems-exchange.org>
References: <20040606123124.GA14035@rogue.amk.ca>
	<40C3538F.6020202@v.loewis.de>
	<5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>
	<40C3929D.5030609@v.loewis.de>
	<20040606230124.GA11886@mems-exchange.org>
Message-ID: <DE44FEDE-B80F-11D8-86FB-000A95686CD8@redivi.com>


On Jun 6, 2004, at 7:01 PM, Neil Schemenauer wrote:

> On Sun, Jun 06, 2004 at 11:54:37PM +0200, "Martin v. L?wis" wrote:
>> I don't think even SF has such numbers. However, bandwidth is not a
>> problem - the PSF is willing to reimburse anybody hosting the Python 
>> CVS
>> for bandwidth (although donations are certainly welcome).
>
> Really?  What would be a reasonable monthy fee?  I ask because the
> bandwidth required for hosting both a checkin and an a anonymous
> repository may be quite a lot.  A full checkout seems to be about
> 100 MB.  The hosting plan I'm looking at now offers 50 GiB/month for
> $40.

Surely there must be an ISP out there that is Python friendly and would 
offer a significant discount.. and is that with or without considering 
the typical compression (-z3 is normal, I guess)?

>> The issue is providing timely service: what if the system runs out of
>> memory, gets cracked by a hacker, a new committer needs to be added,
>> the sendmail installation gets stuck because some commit messages 
>> cannot
>> be delivered to some recipient, and so on.
>>
>> Such a system needs permanent hand-holding. Certainly, the number of
>> projects that SF hosts do cause delays in timely responses. OTOH,
>> they also have many more full-time people for hand-holding than we
>> will ever get.
>
> If the PSF pays the hosting fees, I am willing manage a Subversion
> repository for Python.  If we can get one ore two people to offer
> backup support when I'm not available then I think we could offer
> better service than SF.

I am definitely 100% for Subversion.  Update and diff are much faster, 
and you can view the repository or do an export with wget if you have 
to (assuming Subversion+Apache).  Also the efficiency of copying/moving 
things around makes life easier, especially for Mac stuff because there 
tends to be a lot more directories.  We have just recently moved PyObjC 
from Sourceforge CVS to a Subversion server and the grass is definitely 
greener.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040606/af423a66/smime.bin
From barry at python.org  Sun Jun  6 19:42:35 2004
From: barry at python.org (Barry Warsaw)
Date: Sun Jun  6 19:42:44 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <DE44FEDE-B80F-11D8-86FB-000A95686CD8@redivi.com>
References: <20040606123124.GA14035@rogue.amk.ca>
	<40C3538F.6020202@v.loewis.de>
	<5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>
	<40C3929D.5030609@v.loewis.de>
	<20040606230124.GA11886@mems-exchange.org>
	<DE44FEDE-B80F-11D8-86FB-000A95686CD8@redivi.com>
Message-ID: <1086565354.21649.534.camel@anthem.wooz.org>

On Sun, 2004-06-06 at 19:18, Bob Ippolito wrote:

> Surely there must be an ISP out there that is Python friendly and would 
> offer a significant discount.. and is that with or without considering 
> the typical compression (-z3 is normal, I guess)?

Maybe someone like, oh, XS4ALL? <wink>.

Last time I talked to Thomas, re moving mail.python.org, he seemed to be
totally unconcerned about bandwidth.

> I am definitely 100% for Subversion.  Update and diff are much faster, 
> and you can view the repository or do an export with wget if you have 
> to (assuming Subversion+Apache).  Also the efficiency of copying/moving 
> things around makes life easier, especially for Mac stuff because there 
> tends to be a lot more directories.  We have just recently moved PyObjC 
> from Sourceforge CVS to a Subversion server and the grass is definitely 
> greener.

+1 on Subversion too, but I still say the biggest problem is finding the
cycles to set up and maintain the infrastructure.  It was an
overwhelming task when we did it ourselves with a fraction of the user
and developer community, and I was glad when we moved to SF.  If the
Gforge installation Andrew was talking about can really be set up and
babysat with as little effort as claimed, I think that's worth looking
into.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040606/9086cb0c/attachment.bin
From t-meyer at ihug.co.nz  Sun Jun  6 19:52:58 2004
From: t-meyer at ihug.co.nz (Tony Meyer)
Date: Sun Jun  6 19:54:51 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F1306967C67@its-xchg4.massey.ac.nz>
Message-ID: <1ED4ECF91CDED24C8D012BCF2B034F1304677F0E@its-xchg4.massey.ac.nz>

> The bug day yesterday was a success
[...]

Out of curiosity, did you end up announcing it anywhere?  Where does this
sort of thing get announced?

=Tony Meyer


From tim.one at comcast.net  Sun Jun  6 20:20:07 2004
From: tim.one at comcast.net (Tim Peters)
Date: Sun Jun  6 20:20:13 2004
Subject: [Python-Dev] valgrind report
In-Reply-To: <20040606205245.GA938@epoch.metaslash.com>
Message-ID: <mailman.360.1086567613.6944.python-dev@python.org>

[Neal Norwitz]

...

> Import/compile related memory leaks:
> ------------------------------------

These aren't actually related to anything <wink>.  The code starting at

>    by 0x807CDB7: new_arena (obmalloc.c:500)

is this:

		p = (uptr *)malloc(newmax * sizeof(*arenas));
		if (p == NULL)
			goto error;
		memcpy(p, arenas, narenas * sizeof(*arenas));
		arenas = p;	/* old arenas deliberately leaked */

Note the comment on the last line!  The reason for this is explained in
horrid detail in a comment block a few lines above this.  pymalloc maintains
a vector of pointers to arena base addresses, and when this vector itself
needs to grow, the memory it used to occupy is allowed to leak.  In the
absence of introducing expensive thread locks, we can't know whether some
other thread may still be referencing the old version of this vector (it's
OK if it does), so we can't free() it.  Any valgrind complaint with

>    by 0x807CDB7: new_arena (obmalloc.c:500)

in the listing is due to this deliberate leak, and the code lower in the
listing is irrelevant.  It just had the bad luck to call pymalloc exactly
when available space in all currently allocated arenas is in use, *and*
there's no space left in pymalloc's exponentially-overallocated vector of
arena base addresses to hold one more arena base address.

...

> Initialization memory leaks: ----------------------------
>
>  64 bytes in 1 blocks are definitely lost in loss record 139 of 663
>     at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
>     by 0x807CE32: new_arena (obmalloc.c:452)
>     by 0x807CAF2: PyObject_Malloc (obmalloc.c:699)
>     by 0x80E1566: _PyObject_GC_Malloc (gcmodule.c:1183)
>     by 0x80E166C: _PyObject_GC_NewVar (gcmodule.c:1214)
>     by 0x8084A71: PyTuple_New (tupleobject.c:68)
>     by 0x8087B2F: PyType_Ready (typeobject.c:3161)
>     by 0x8087B39: PyType_Ready (typeobject.c:3147)
>     by 0x807BE01: _Py_ReadyTypes (object.c:1802)
>     by 0x80D9B93: Py_Initialize (pythonrun.c:167)
>     by 0x805510A: Py_Main (main.c:376)
>     by 0x8054DAA: main (python.c:23)

That's really the same thing:  this is the *first* time the vector of arena
base addresses got allocated.  That memory is eventually allowed to leak by
the C code reproduced above.

This isn't worth any convolution "to fix".  Each pointer we save in the
vector of arena base addresses controls 256KB of memory, so it's an
insignificant space overhead.  The vector doubles in size whenever growth is
necessary, so the total amount of leaked space is approximately equal to the
current size of the vector.



From anthony at interlink.com.au  Sun Jun  6 20:37:47 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Sun Jun  6 20:38:07 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <1086565354.21649.534.camel@anthem.wooz.org>
References: <20040606123124.GA14035@rogue.amk.ca>	<40C3538F.6020202@v.loewis.de>	<5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>	<40C3929D.5030609@v.loewis.de>	<20040606230124.GA11886@mems-exchange.org>	<DE44FEDE-B80F-11D8-86FB-000A95686CD8@redivi.com>
	<1086565354.21649.534.camel@anthem.wooz.org>
Message-ID: <40C3B8DB.4020809@interlink.com.au>

Barry Warsaw wrote:
> +1 on Subversion too, but I still say the biggest problem is finding the
> cycles to set up and maintain the infrastructure.  It was an
> overwhelming task when we did it ourselves with a fraction of the user
> and developer community, and I was glad when we moved to SF.  If the
> Gforge installation Andrew was talking about can really be set up and
> babysat with as little effort as claimed, I think that's worth looking
> into.

The main problem with GForge is that it's bugtracker is just like SF's.
Which is to say, it's awful.

Back at PyCon, at the PSF board meeting, I thought the decision was
made that once the PSF Grants committee was up and going, there'd be
a grant cut to get Roundup finished? What's happened with this?

Anthony

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

From tim.one at comcast.net  Sun Jun  6 20:39:31 2004
From: tim.one at comcast.net (Tim Peters)
Date: Sun Jun  6 20:39:46 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F1304677F0E@its-xchg4.massey.ac.nz>
Message-ID: <mailman.362.1086568786.6944.python-dev@python.org>

[Andrew Kuchling]
>> The bug day yesterday was a success
> [...]

[Tony Meyer]
> Out of curiosity, did you end up announcing it anywhere?  Where does this
> sort of thing get announced?

I think the next one needs to be better publicized.  This one was discussed
on Python-Dev, but it wasn't clear to me that it was actually going to
happen.  I didn't realize it was happening until I saw email on python-dev
Saturday, asking questions about SourceForge that suggested it might be
happening.  In any case, Python-Dev is the natural place to announce it.

I noticed just now that

    A Python Bug Day will be held on Saturday, June 5; see the Wiki for
    information.

is a prominent announcement on the python.org home page, but I don't look at
that often.  Subscribing to that Wiki page

    http://www.python.org/cgi-bin/moinmoin/PythonBugDay

may or may not be a good way to learn about the next one (depends on whether
it's reused).



From anthony at interlink.com.au  Sun Jun  6 20:41:17 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Sun Jun  6 20:41:37 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <40C3929D.5030609@v.loewis.de>
References: <20040606123124.GA14035@rogue.amk.ca>	<40C3538F.6020202@v.loewis.de>	<5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>
	<40C3929D.5030609@v.loewis.de>
Message-ID: <40C3B9AD.7080304@interlink.com.au>

We have the equipment (xs4all has donated 3 machines) and
we've been assured on multiple occasions that we can't even
make a dint in their bandwidth, so that's not a problem.

The question is simply whether we'd be better running our
own CVS (or SVN) server. The major reason to do this is that
the SF anon CVS is awful. Truly awful. This impacts people
who'd like to contribute, but can't get current CVS. A while
ago, I suggested taking the tarball of the CVS root and
putting it somewhere, then setting up 'anoncvs.python.org'
and pointing it at this. Is this still a good idea? If so,
I can look at it.

As far as moving CVS/SVN, if it happens before 2.4(final)
I will be very cranky <wink>


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

From t-meyer at ihug.co.nz  Sun Jun  6 20:50:55 2004
From: t-meyer at ihug.co.nz (Tony Meyer)
Date: Sun Jun  6 20:53:59 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F1306967D01@its-xchg4.massey.ac.nz>
Message-ID: <1ED4ECF91CDED24C8D012BCF2B034F1304677F10@its-xchg4.massey.ac.nz>

[Tim Peters]
> I noticed just now that
> 
>     A Python Bug Day will be held on Saturday, June 5; see 
>     the Wiki for information.
> 
> is a prominent announcement on the python.org home page, but 
> I don't look at that often.

Ah, I see that now, thanks :)  I did look at python.org before posting, but
didn't pay much attention to the main page, and looked carefully at /dev
instead :)

In any case, I would have been asleep (1am to 10am here) or too sleepy to
contribute my meagre skills anyway :)

=Tony Meyer


From tim.one at comcast.net  Sun Jun  6 21:04:39 2004
From: tim.one at comcast.net (Tim Peters)
Date: Sun Jun  6 21:04:46 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <40C3B9AD.7080304@interlink.com.au>
Message-ID: <mailman.364.1086570286.6944.python-dev@python.org>

[Anthony Baxter]
> We have the equipment (xs4all has donated 3 machines) and we've been
> assured on multiple occasions that we can't even make a dint in their
> bandwidth, so that's not a problem.
>
> The question is simply whether we'd be better running our own CVS (or
> SVN) server.

Note that xs4all will not allow running pserver (anonymous) CVS.  This is
for the same reason pserver access is disabled at zope.org now too:  the
history of "security bugs" associated with pserver CVS is dismal.

> The major reason to do this is that the SF anon CVS is awful.  Truly
> awful.

It's a hell of a lot more useful than Zope's anon CVS now <0.5 wink>.

> This impacts people who'd like to contribute, but can't get current
> CVS. A while ago, I suggested taking the tarball of the CVS root and
> putting it somewhere, then setting up 'anoncvs.python.org' and pointing
> it at this. Is this still a good idea? If so, I can look at it.

I'm not sure what this suggestion is.  Daily tarballs of HEAD, and the 22
and 23 branches, are already available here:

    http://www.python.org/dev/

> As far as moving CVS/SVN, if it happens before 2.4(final) I will be very
> cranky <wink>

Good call!  Zope's conversion to SVN has been quite bumpy, and there still
isn't a released version of ViewCVS that works with SVN.  The "download a
tarball" feature of in-development ViewCVS-with-SVN was disabled (at Zope)
when Jim discovered it sucked up 400MB of RAM to generate a 3MB Zope3
tarball.  The Berkeley database often wants an admin to run recovery on it,
and etc:  Martin is correct that the major barrier here is sufficient
volunteers to do support and maintenance.  Source control systems, and
trackers, require endless care and feeding.



From martin at v.loewis.de  Mon Jun  7 01:26:50 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun  7 01:27:03 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <40C3B9AD.7080304@interlink.com.au>
References: <20040606123124.GA14035@rogue.amk.ca>	<40C3538F.6020202@v.loewis.de>	<5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>
	<40C3929D.5030609@v.loewis.de> <40C3B9AD.7080304@interlink.com.au>
Message-ID: <40C3FC9A.6070803@v.loewis.de>

Anthony Baxter wrote:
> The question is simply whether we'd be better running our
> own CVS (or SVN) server. The major reason to do this is that
> the SF anon CVS is awful. Truly awful. This impacts people
> who'd like to contribute, but can't get current CVS. A while
> ago, I suggested taking the tarball of the CVS root and
> putting it somewhere, then setting up 'anoncvs.python.org'
> and pointing it at this. Is this still a good idea?

It can't hurt, so if it is not too much effort, go ahead.

Unfortunately, the nightly tarballs aren't reliably produced,
either - they weren't present for the last week. So a procedure
that downloads the nightly tarball and unpacks it would have
failed most recently (my own procedure managed to overwrite
the older tarballs in the process).

However, such a procedure shares some of the problems of
anon CVS on SF: it is always behind the life CVS.

In addition, providing another place for anon CVS doesn't
solve the problems that some committers have with SF.

Regards,
Martin



From amk at amk.ca  Mon Jun  7 07:17:15 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Mon Jun  7 07:17:28 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <1086565354.21649.534.camel@anthem.wooz.org>
References: <20040606123124.GA14035@rogue.amk.ca>
	<40C3538F.6020202@v.loewis.de>
	<5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>
	<40C3929D.5030609@v.loewis.de>
	<20040606230124.GA11886@mems-exchange.org>
	<DE44FEDE-B80F-11D8-86FB-000A95686CD8@redivi.com>
	<1086565354.21649.534.camel@anthem.wooz.org>
Message-ID: <20040607111715.GA17574@rogue.amk.ca>

On Sun, Jun 06, 2004 at 07:42:35PM -0400, Barry Warsaw wrote:
> and developer community, and I was glad when we moved to SF.  If the
> Gforge installation Andrew was talking about can really be set up and
> babysat with as little effort as claimed, I think that's worth looking
> into.

Careful -- setting it up is emphatically not simple, and in fact Rich
Kilmer said that the installation process is really complex.  They
were simply willing to help with it.  Running a GForge setup and
running just a CVS/SVN server probably aren't in the same class of
complexity.

--amk


From amk at amk.ca  Mon Jun  7 07:30:09 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Mon Jun  7 07:30:20 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F1304677F0E@its-xchg4.massey.ac.nz>
References: <1ED4ECF91CDED24C8D012BCF2B034F1306967C67@its-xchg4.massey.ac.nz>
	<1ED4ECF91CDED24C8D012BCF2B034F1304677F0E@its-xchg4.massey.ac.nz>
Message-ID: <20040607113009.GB17574@rogue.amk.ca>

On Mon, Jun 07, 2004 at 11:52:58AM +1200, Tony Meyer wrote:
> Out of curiosity, did you end up announcing it anywhere?  Where does this
> sort of thing get announced?

Python-URL and Daily Python-URL both carried it.  I sent an
announcement to c.l.py.a, but that annoucement doesn't seem to have
been approved; hopefully whoever moderates the list will notice the
date and discard it.

--amk


From aahz at pythoncraft.com  Mon Jun  7 10:09:56 2004
From: aahz at pythoncraft.com (Aahz)
Date: Mon Jun  7 10:10:00 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <20040607113009.GB17574@rogue.amk.ca>
References: <1ED4ECF91CDED24C8D012BCF2B034F1306967C67@its-xchg4.massey.ac.nz>
	<1ED4ECF91CDED24C8D012BCF2B034F1304677F0E@its-xchg4.massey.ac.nz>
	<20040607113009.GB17574@rogue.amk.ca>
Message-ID: <20040607140955.GA13280@panix.com>

On Mon, Jun 07, 2004, A.M. Kuchling wrote:
> On Mon, Jun 07, 2004 at 11:52:58AM +1200, Tony Meyer wrote:
>>
>> Out of curiosity, did you end up announcing it anywhere?  Where does this
>> sort of thing get announced?
> 
> Python-URL and Daily Python-URL both carried it.  I sent an
> announcement to c.l.py.a, but that annoucement doesn't seem to have
> been approved; hopefully whoever moderates the list will notice the
> date and discard it.

It was either discarded accidentally or never made it to the queue; I
certainly didn't see it.  I've had problems in the past with netnews
posts to c.l.py.a failing, so now I always send e-mail to
python-announce@python.org
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha

From theller at python.net  Mon Jun  7 10:11:07 2004
From: theller at python.net (Thomas Heller)
Date: Mon Jun  7 10:11:15 2004
Subject: [Python-Dev] Python/import.c
Message-ID: <ekor5uh0.fsf@python.net>

In the context of http://www.python.org/sf/845802 I'm looking at the
code in Python/import.c, function load_package().

The latter part of the function is this code, which tries to import the
__init__.py file, after building the module object in 'm', and
initializing it's __file__ and __path__ attributes:

        fdp = find_module(name, "__init__", path, buf, sizeof(buf), &fp, NULL);
        if (fdp == NULL) {
                if (PyErr_ExceptionMatches(PyExc_ImportError)) {
                        PyErr_Clear();
                }
                else
                        m = NULL;
                goto cleanup;
        }
        m = load_module(name, fp, buf, fdp->type, NULL);
        if (fp != NULL)
                fclose(fp);
  cleanup:
        Py_XDECREF(path);
        Py_XDECREF(file);
        return m;
}


I do not understand why the function doesn't fail when find_module
returns NULL because of an PyExc_ImportError.  For the above mentioned
bug, when __init__.py is a directory instead of a file, find_module
returns NULL.

Thomas


From amk at amk.ca  Mon Jun  7 10:53:57 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Mon Jun  7 10:54:08 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <20040607140955.GA13280@panix.com>
References: <1ED4ECF91CDED24C8D012BCF2B034F1306967C67@its-xchg4.massey.ac.nz>
	<1ED4ECF91CDED24C8D012BCF2B034F1304677F0E@its-xchg4.massey.ac.nz>
	<20040607113009.GB17574@rogue.amk.ca>
	<20040607140955.GA13280@panix.com>
Message-ID: <20040607145357.GB18282@rogue.amk.ca>

On Mon, Jun 07, 2004 at 10:09:56AM -0400, Aahz wrote:
> It was either discarded accidentally or never made it to the queue; I
> certainly didn't see it.  I've had problems in the past with netnews
> posts to c.l.py.a failing, ...

Aha! I posted via slrn, so that's probably what's happened.  That's
heartening; if it had been publicized properly, there would have been
even more participants.

Question for Anthony: PEP 320 says "alpha 1 -- second week of July
2004".  Does this mean July 4-10 (first full week of July, but the
second week) or July 11-17 (second full week of July)?  

I was thinking of July 10th as the next bug day, making for one per
month, but if alpha1 is being released around that time, that date
won't work.  If alpha1 is released around the 17th, are you OK with
having a bug day a week earlier, with the resulting spike of changes?
If not, then maybe June 26th will be a good choice.

--amk

From sh at defuze.org  Mon Jun  7 09:32:18 2004
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Mon Jun  7 11:30:54 2004
Subject: [Python-Dev] Empty keyword
Message-ID: <ca1qme$5b9$1@sea.gmane.org>

Hi all,

It miht sound stupid or useless, or maybe someone has already mentioned 
it but sometimes I wish Python could provdie an "Empty" keyword like The 
"None" one.

It would be usefull to validdate the emptyness of any scalar or sequence 
in an uniform way instead of using things such as :

if len(mylist) == 0:

which I really dislike.

It makes in my head but it might be stupid.

Thanks for your feedback.
- Sylvain


From FBatista at uniFON.com.ar  Mon Jun  7 11:44:14 2004
From: FBatista at uniFON.com.ar (Batista, Facundo)
Date: Mon Jun  7 11:47:32 2004
Subject: [Python-Dev] Empty keyword
Message-ID: <A128D751272CD411BC9200508BC2194D033839EF@escpl.tcp.com.ar>

[Sylvain Hellegouarch]

#- It would be usefull to validdate the emptyness of any scalar 
#- or sequence 
#- in an uniform way instead of using things such as :
#- 
#- if len(mylist) == 0:

Taking in consideration that I'll also like such keyword, making a new
keyword for a functionality that already exists like an idiom is not very
likely to happen.

Anyway, if you really want to push this, I recommend you to search in the
archives why others keywords have been rejected in the past, and if this new
one passes all the tests, make a PEP.

.	Facundo





. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
ADVERTENCIA  

La informaci?n contenida en este mensaje y cualquier archivo anexo al mismo,
son para uso exclusivo del destinatario y pueden contener informaci?n
confidencial o propietaria, cuya divulgaci?n es sancionada por la ley. 

Si Ud. No es uno de los destinatarios consignados o la persona responsable
de hacer llegar este mensaje a los destinatarios consignados, no est?
autorizado a divulgar, copiar, distribuir o retener informaci?n (o parte de
ella) contenida en este mensaje. Por favor notif?quenos respondiendo al
remitente, borre el mensaje original y borre las copias (impresas o grabadas
en cualquier medio magn?tico) que pueda haber realizado del mismo. 

Todas las opiniones contenidas en este mail son propias del autor del
mensaje y no necesariamente coinciden con las de Telef?nica Comunicaciones
Personales S.A. o alguna empresa asociada. 

Los mensajes electr?nicos pueden ser alterados, motivo por el cual
Telef?nica Comunicaciones Personales S.A. no aceptar? ninguna obligaci?n
cualquiera sea el resultante de este mensaje. 

Muchas Gracias.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20040607/c503ef9e/attachment.html
From sh at defuze.org  Mon Jun  7 11:57:42 2004
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Mon Jun  7 11:56:35 2004
Subject: [Python-Dev] Re: Empty keyword
In-Reply-To: <A128D751272CD411BC9200508BC2194D033839EF@escpl.tcp.com.ar>
References: <A128D751272CD411BC9200508BC2194D033839EF@escpl.tcp.com.ar>
Message-ID: <ca2378$vlt$1@sea.gmane.org>

Hi Facundo,

Thanks for the tip. I don't really give a chance to it to reach Python 
release state or whatsoever, but I just wanted to point that IMO it 
would meke sense.

It would follow the rules of the None keyword which gives a clean, 
reusable, multiplateform and safe wayt to check the null-validity of any 
types.

And I was a bit estonished yesterday that Python didn't follow the same 
principle for the emptyness of a value.

Anyhow, I don't think it is worth a PEP as if it was that critical it 
would already be in Python :)

Cheers anyway
- Sylvain

Batista, Facundo wrote:
> [Sylvain Hellegouarch]
> 
> #- It would be usefull to validdate the emptyness of any scalar
> #- or sequence
> #- in an uniform way instead of using things such as :
> #-
> #- if len(mylist) == 0:
> 
> Taking in consideration that I'll also like such keyword, making a new 
> keyword for a functionality that already exists like an idiom is not 
> very likely to happen.
> 
> Anyway, if you really want to push this, I recommend you to search in 
> the archives why others keywords have been rejected in the past, and if 
> this new one passes all the tests, make a PEP.
> 
> .       Facundo
> 
> 
> 
> 
> 
> *. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
> . . . . . . . . . . . . . . . . . . .*
> 
> *_ADVERTENCIA _ *
> 
> *La informaci?n contenida en este mensaje y cualquier archivo anexo al 
> mismo, son para uso exclusivo del destinatario y pueden contener 
> informaci?n confidencial o propietaria, cuya divulgaci?n es sancionada 
> por la ley. *
> 
> *Si Ud. No es uno de los destinatarios consignados o la persona 
> responsable de hacer llegar este mensaje a los destinatarios 
> consignados, no est? autorizado a divulgar, copiar, distribuir o retener 
> informaci?n (o parte de ella) contenida en este mensaje. Por favor 
> notif?quenos respondiendo al remitente, borre el mensaje original y 
> borre las copias (impresas o grabadas en cualquier medio magn?tico) que 
> pueda haber realizado del mismo. *
> 
> *Todas las opiniones contenidas en este mail son propias del autor del 
> mensaje y no necesariamente coinciden con las de Telef?nica 
> Comunicaciones Personales S.A. o alguna empresa asociada. *
> 
> *Los mensajes electr?nicos pueden ser alterados, motivo por el cual 
> Telef?nica Comunicaciones Personales S.A. no aceptar? ninguna obligaci?n 
> cualquiera sea el resultante de este mensaje. *
> 
> *Muchas Gracias.*
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org


From fumanchu at amor.org  Mon Jun  7 12:12:46 2004
From: fumanchu at amor.org (Robert Brewer)
Date: Mon Jun  7 12:16:22 2004
Subject: [Python-Dev] Empty keyword
Message-ID: <DE1CF2B4FEC4A342BF62B6B2B334601E5621BA@opus.amorhq.net>

Sylvain Hellegouarch wrote:
> It miht sound stupid or useless, or maybe someone has already 
> mentioned 
> it but sometimes I wish Python could provdie an "Empty" 
> keyword like The 
> "None" one.
> 
> It would be usefull to validdate the emptyness of any scalar 
> or sequence 
> in an uniform way instead of using things such as :
> 
> if len(mylist) == 0:
> 
> which I really dislike.

Have you read the bit about empty lists and such when testing truth
values?
http://docs.python.org/lib/truth.html

>>> x = []
>>> if x:
... 	print True
... else:
... 	print False
... 	
False
>>> x = [0]
>>> if x:
... 	print True
... else:
... 	print False
... 	
True


Robert Brewer
MIS
Amor Ministries
fumanchu@amor.org

From aahz at pythoncraft.com  Mon Jun  7 12:40:29 2004
From: aahz at pythoncraft.com (Aahz)
Date: Mon Jun  7 12:40:35 2004
Subject: [Python-Dev] Empty keyword
In-Reply-To: <DE1CF2B4FEC4A342BF62B6B2B334601E5621BA@opus.amorhq.net>
References: <DE1CF2B4FEC4A342BF62B6B2B334601E5621BA@opus.amorhq.net>
Message-ID: <20040607164029.GA23877@panix.com>

Please, let's not clutter python-dev with this discussion.  c.l.py is a
better place.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha

From jiwon at softwise.co.kr  Mon Jun  7 13:21:45 2004
From: jiwon at softwise.co.kr (Jiwon Seo)
Date: Mon Jun  7 13:15:19 2004
Subject: [Python-Dev] Python/import.c
In-Reply-To: <ekor5uh0.fsf@python.net>
References: <ekor5uh0.fsf@python.net>
Message-ID: <40C4A429.8090304@softwise.co.kr>

It looks like it's because even if the package failed to be loaded, it 
should be added to its parent module dict, IMHO.
The comment in the import.c::add_submodule describes the behavior. I 
don't know how it could be useful, but I think it's the way import behaves.

...
static int
add_submodule(PyObject *mod, PyObject *submod, char *fullname, char 
*subname,
          PyObject *modules)
{
    if (mod == Py_None)
        return 1;
    /* Irrespective of the success of this load, make a
       reference to it in the parent package module.  A copy gets
       saved in the modules dictionary under the full name, so get a
       reference from there, if need be.  (The exception is when the
       load failed with a SyntaxError -- then there's no trace in
       sys.modules.  In that case, of course, do nothing extra.) */
...


Jiwon

From casey at zope.com  Mon Jun  7 14:10:24 2004
From: casey at zope.com (Casey Duncan)
Date: Mon Jun  7 14:09:17 2004
Subject: [Python-Dev] Re: Empty keyword
References: <ca1qme$5b9$1@sea.gmane.org>
Message-ID: <20040607141024.1fff1191.casey@zope.com>

On Mon, 07 Jun 2004 14:32:18 +0100
Sylvain Hellegouarch <sh@defuze.org> wrote:

> Hi all,
> 
> It miht sound stupid or useless, or maybe someone has already
> mentioned it but sometimes I wish Python could provdie an "Empty"
> keyword like The "None" one.
> 
> It would be usefull to validdate the emptyness of any scalar or
> sequence in an uniform way instead of using things such as :
> 
> if len(mylist) == 0:

You would not write it this way anyhow. In Python you can test a
sequence directly as in:

if mylist:

or

if not mylist:

Empty sequences (and mappings) are false and non-empty sequences are
true.

See also: http://docs.python.org/ref/Booleans.html#Booleans

-Casey


From fdrake at acm.org  Mon Jun  7 14:21:54 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Jun  7 14:22:49 2004
Subject: [Python-Dev] Python/import.c
In-Reply-To: <40C4A429.8090304@softwise.co.kr>
References: <ekor5uh0.fsf@python.net> <40C4A429.8090304@softwise.co.kr>
Message-ID: <200406071421.54752.fdrake@acm.org>

On Monday 07 June 2004 01:21 pm, Jiwon Seo wrote:
 > It looks like it's because even if the package failed to be loaded, it
 > should be added to its parent module dict, IMHO.
 > The comment in the import.c::add_submodule describes the behavior. I
 > don't know how it could be useful, but I think it's the way import
 > behaves.

This is to support caching; if some module in the "foo" package imports the 
"bar" module, and there isn't a "foo.bar" module, sys.modules grows a 
"foo.bar": None entry so that further attempts to import sys within the "foo" 
package don't have to do as much work to know that there isn't one, and can 
fall back to a top-level "bar" module (which can still fail if there isn't 
one).


  -Fred

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


From sh at defuze.org  Mon Jun  7 17:33:49 2004
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Mon Jun  7 17:33:11 2004
Subject: [Python-Dev] Re: Empty keyword
In-Reply-To: <20040607164029.GA23877@panix.com>
References: <DE1CF2B4FEC4A342BF62B6B2B334601E5621BA@opus.amorhq.net>
	<20040607164029.GA23877@panix.com>
Message-ID: <ca2mue$6p6$1@sea.gmane.org>

Hi,

  Sorry about that.
Anyhow, I must say that I didn't see any clear statement about what 
should go here or there, I naively thought it would be the best place.

Would you let me know then how I should keep going with this talk 
without loosing it ?

Thanks
- Sylvain

Aahz wrote:
> Please, let's not clutter python-dev with this discussion.  c.l.py is a
> better place.


From sh at defuze.org  Mon Jun  7 17:36:28 2004
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Mon Jun  7 17:40:53 2004
Subject: [Python-Dev] Re: Empty keyword
In-Reply-To: <20040607141024.1fff1191.casey@zope.com>
References: <ca1qme$5b9$1@sea.gmane.org>
	<20040607141024.1fff1191.casey@zope.com>
Message-ID: <ca2n3d$6p6$2@sea.gmane.org>

It still doesn't make sense to me as I don't see why the fact a list is 
empty means that it can be stated as false.

Intuitively it doesn't sound correct to me as there is no logical link 
between the truth of an object and the fact that it can be empty.

What I mean, is that usually I find Python to be really logical and 
clear, but there I think it is misleading.

You're gonna say "nah you're stupid, it is easy"... certainly when you 
are used to it, it sounds ok but it doesn't IMO.

Cheers :)
- Sylvain

Casey Duncan wrote:
> On Mon, 07 Jun 2004 14:32:18 +0100
> Sylvain Hellegouarch <sh@defuze.org> wrote:
> 
> 
>>Hi all,
>>
>>It miht sound stupid or useless, or maybe someone has already
>>mentioned it but sometimes I wish Python could provdie an "Empty"
>>keyword like The "None" one.
>>
>>It would be usefull to validdate the emptyness of any scalar or
>>sequence in an uniform way instead of using things such as :
>>
>>if len(mylist) == 0:
> 
> 
> You would not write it this way anyhow. In Python you can test a
> sequence directly as in:
> 
> if mylist:
> 
> or
> 
> if not mylist:
> 
> Empty sequences (and mappings) are false and non-empty sequences are
> true.
> 
> See also: http://docs.python.org/ref/Booleans.html#Booleans
> 
> -Casey
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
> 


From aahz at pythoncraft.com  Mon Jun  7 18:40:41 2004
From: aahz at pythoncraft.com (Aahz)
Date: Mon Jun  7 18:40:45 2004
Subject: [Python-Dev] Re: Empty keyword
In-Reply-To: <ca2mue$6p6$1@sea.gmane.org>
References: <DE1CF2B4FEC4A342BF62B6B2B334601E5621BA@opus.amorhq.net>
	<20040607164029.GA23877@panix.com> <ca2mue$6p6$1@sea.gmane.org>
Message-ID: <20040607224040.GA23066@panix.com>

On Mon, Jun 07, 2004, Sylvain Hellegouarch wrote:
> Aahz wrote:
>>
>>Please, let's not clutter python-dev with this discussion.  c.l.py is a
>>better place.
> 
>  Sorry about that.
> Anyhow, I must say that I didn't see any clear statement about what 
> should go here or there, I naively thought it would be the best place.
> 
> Would you let me know then how I should keep going with this talk 
> without loosing it ?

comp.lang.python
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha

From martin at v.loewis.de  Mon Jun  7 18:45:28 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun  7 18:45:34 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <20040606230124.GA11886@mems-exchange.org>
References: <20040606123124.GA14035@rogue.amk.ca>	<40C3538F.6020202@v.loewis.de>	<5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>	<40C3929D.5030609@v.loewis.de>
	<20040606230124.GA11886@mems-exchange.org>
Message-ID: <40C4F008.2050109@v.loewis.de>

Neil Schemenauer wrote:
>>I don't think even SF has such numbers. However, bandwidth is not a
>>problem - the PSF is willing to reimburse anybody hosting the Python CVS
>>for bandwidth (although donations are certainly welcome).
> 
> 
> Really?  What would be a reasonable monthy fee?  

I don't actually know.

> I ask because the
> bandwidth required for hosting both a checkin and an a anonymous
> repository may be quite a lot.  A full checkout seems to be about
> 100 MB.  The hosting plan I'm looking at now offers 50 GiB/month for
> $40.

If we can't find somebody who sponsors that bandwidth, the PSF would
have no problems paying $500 a year.

> If the PSF pays the hosting fees, I am willing manage a Subversion
> repository for Python.  If we can get one ore two people to offer
> backup support when I'm not available then I think we could offer
> better service than SF.
> 
> If we would want to host the tracker as well, I would need more
> help.  I'm not experienced in supporting Roundup, etc.  I suspect
> they may require more hand-holding.

I think version management could reasonably be separate from
the issue tracking.

Regards,
Martin


From martin at v.loewis.de  Mon Jun  7 18:47:05 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun  7 18:47:10 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <40C3B8DB.4020809@interlink.com.au>
References: <20040606123124.GA14035@rogue.amk.ca>	<40C3538F.6020202@v.loewis.de>	<5C912848-B7DF-11D8-9CEF-000D932927FE@opnet.com>	<40C3929D.5030609@v.loewis.de>	<20040606230124.GA11886@mems-exchange.org>	<DE44FEDE-B80F-11D8-86FB-000A95686CD8@redivi.com>	<1086565354.21649.534.camel@anthem.wooz.org>
	<40C3B8DB.4020809@interlink.com.au>
Message-ID: <40C4F069.1090506@v.loewis.de>

Anthony Baxter wrote:
> Back at PyCon, at the PSF board meeting, I thought the decision was
> made that once the PSF Grants committee was up and going, there'd be
> a grant cut to get Roundup finished? What's happened with this?

I hope we are close to issuing a call for proposals. Then, we will
need people to actually apply.

Regards,
Martin


From anthony at interlink.com.au  Tue Jun  8 00:00:27 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Tue Jun  8 00:00:48 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <20040607145357.GB18282@rogue.amk.ca>
References: <1ED4ECF91CDED24C8D012BCF2B034F1306967C67@its-xchg4.massey.ac.nz>	<1ED4ECF91CDED24C8D012BCF2B034F1304677F0E@its-xchg4.massey.ac.nz>	<20040607113009.GB17574@rogue.amk.ca>	<20040607140955.GA13280@panix.com>
	<20040607145357.GB18282@rogue.amk.ca>
Message-ID: <40C539DB.5060904@interlink.com.au>

A.M. Kuchling wrote:
> On Mon, Jun 07, 2004 at 10:09:56AM -0400, Aahz wrote:
> 
>>It was either discarded accidentally or never made it to the queue; I
>>certainly didn't see it.  I've had problems in the past with netnews
>>posts to c.l.py.a failing, ...
> 
> 
> Aha! I posted via slrn, so that's probably what's happened.  That's
> heartening; if it had been publicized properly, there would have been
> even more participants.
> 
> Question for Anthony: PEP 320 says "alpha 1 -- second week of July
> 2004".  Does this mean July 4-10 (first full week of July, but the
> second week) or July 11-17 (second full week of July)?  
> 
> I was thinking of July 10th as the next bug day, making for one per
> month, but if alpha1 is being released around that time, that date
> won't work.  If alpha1 is released around the 17th, are you OK with
> having a bug day a week earlier, with the resulting spike of changes?
> If not, then maybe June 26th will be a good choice.


I was aiming at 7-8 July for alpha1. I see no problem with having
the bug day a couple of days after the first alpha.




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

From theller at python.net  Tue Jun  8 06:32:40 2004
From: theller at python.net (Thomas Heller)
Date: Tue Jun  8 06:32:50 2004
Subject: [Python-Dev] Python/import.c
In-Reply-To: <200406071421.54752.fdrake@acm.org> (Fred L. Drake, Jr.'s
	message of "Mon, 7 Jun 2004 14:21:54 -0400")
References: <ekor5uh0.fsf@python.net> <40C4A429.8090304@softwise.co.kr>
	<200406071421.54752.fdrake@acm.org>
Message-ID: <1xkq731z.fsf@python.net>

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

> On Monday 07 June 2004 01:21 pm, Jiwon Seo wrote:
>  > It looks like it's because even if the package failed to be loaded, it
>  > should be added to its parent module dict, IMHO.
>  > The comment in the import.c::add_submodule describes the behavior. I
>  > don't know how it could be useful, but I think it's the way import
>  > behaves.
>
> This is to support caching; if some module in the "foo" package imports the 
> "bar" module, and there isn't a "foo.bar" module, sys.modules grows a 
> "foo.bar": None entry so that further attempts to import sys within the "foo" 
> package don't have to do as much work to know that there isn't one, and can 
> fall back to a top-level "bar" module (which can still fail if there isn't 
> one).

I knew this already ;-), but it doesn't apply to my question.  The code
I quoted was commited in import.c rev 2.82 (6 years, 9 months ago), but
adding dummy entries to sys.modules was added in rev 2.85.

Here's the code again, with the refcount bug fixed (which I already
applied in CVS):
Thomas Heller <theller@python.net> writes:

> In the context of http://www.python.org/sf/845802 I'm looking at the
> code in Python/import.c, function load_package().
>
> The latter part of the function is this code, which tries to import the
> __init__.py file, after building the module object in 'm', and
> initializing it's __file__ and __path__ attributes:
>
>         fdp = find_module(name, "__init__", path, buf, sizeof(buf), &fp, NULL);
>         if (fdp == NULL) {
>                 if (PyErr_ExceptionMatches(PyExc_ImportError)) {
>                         PyErr_Clear();
                          Py_INCREF(m);
>                 }
>                 else
>                         m = NULL;
>                 goto cleanup;
>         }
>         m = load_module(name, fp, buf, fdp->type, NULL);
>         if (fp != NULL)
>                 fclose(fp);
>   cleanup:
>         Py_XDECREF(path);
>         Py_XDECREF(file);
>         return m;
> }
>
>
> I do not understand why the function doesn't fail when find_module
> returns NULL because of an PyExc_ImportError.  For the above mentioned
> bug, when __init__.py is a directory instead of a file, find_module
> returns NULL.

As far as I can tell, the code in the 'if (fdp == NULL)' part is never
executed by the whole test suite, and I believe the refcount bug would
have been found much earlier otherwise.  This code *is* executed (and
the bug was triggered, at least in a debug build) when you try to import
a package where '__init__.py' is a directory instead of a file.

I believe the code should read:

>         fdp = find_module(name, "__init__", path, buf, sizeof(buf), &fp, NULL);
>         if (fdp == NULL) {
>                 m = NULL;
>                 goto cleanup;
>         }
>         m = load_module(name, fp, buf, fdp->type, NULL);
>         if (fp != NULL)
>                 fclose(fp);
>   cleanup:
>         Py_XDECREF(path);
>         Py_XDECREF(file);
>         return m;
> }

I'll upload a patch.

Thomas


From theller at python.net  Tue Jun  8 06:36:07 2004
From: theller at python.net (Thomas Heller)
Date: Tue Jun  8 06:36:25 2004
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules
 posixmodule.c, 2.318, 2.319
In-Reply-To: <E1BX4RS-0004MV-Nc@sc8-pr-cvs1.sourceforge.net>
	(nnorwitz@users.sourceforge.net's
	message of "Sun, 06 Jun 2004 13:40:30 -0700")
References: <E1BX4RS-0004MV-Nc@sc8-pr-cvs1.sourceforge.net>
Message-ID: <wu2i5obs.fsf@python.net>

nnorwitz@users.sourceforge.net writes:

> Update of /cvsroot/python/python/dist/src/Modules
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16270/Modules
>
> Modified Files:
> 	posixmodule.c 
> Log Message:
> Plug a few memory leaks in utime().  path is allocated from within 
> PyArg_ParseTuple() since the format is "et"  This change should
> be reviewed carefully.

I believe 'path' must be set to NULL at the start of the posix_utime
function - I had a crash in a debug build on windows when running
lib\test\test_unicode_file.py.

Thomas

Index: posixmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v
retrieving revision 2.319
diff -c -r2.319 posixmodule.c
*** posixmodule.c	6 Jun 2004 20:40:27 -0000	2.319
--- posixmodule.c	8 Jun 2004 10:35:03 -0000
***************
*** 1994,2000 ****
  static PyObject *
  posix_utime(PyObject *self, PyObject *args)
  {
! 	char *path;
  	long atime, mtime, ausec, musec;
  	int res;
  	PyObject* arg;
--- 1994,2000 ----
  static PyObject *
  posix_utime(PyObject *self, PyObject *args)
  {
! 	char *path = NULL;
  	long atime, mtime, ausec, musec;
  	int res;
  	PyObject* arg;


From amk at amk.ca  Tue Jun  8 08:12:56 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Tue Jun  8 08:13:10 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <40C539DB.5060904@interlink.com.au>
References: <1ED4ECF91CDED24C8D012BCF2B034F1306967C67@its-xchg4.massey.ac.nz>
	<1ED4ECF91CDED24C8D012BCF2B034F1304677F0E@its-xchg4.massey.ac.nz>
	<20040607113009.GB17574@rogue.amk.ca>
	<20040607140955.GA13280@panix.com>
	<20040607145357.GB18282@rogue.amk.ca>
	<40C539DB.5060904@interlink.com.au>
Message-ID: <20040608121256.GA22268@rogue.amk.ca>

On Tue, Jun 08, 2004 at 02:00:27PM +1000, Anthony Baxter wrote:
> I was aiming at 7-8 July for alpha1. I see no problem with having
> the bug day a couple of days after the first alpha.

OK.  If alpha1 slips a few days, we'd probably run the bug day without
actually checking in any changes, which will be a bit of a pain but
not a problem.  July 10th it is!

--amk

From tjreedy at udel.edu  Tue Jun  8 09:23:50 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue Jun  8 09:24:06 2004
Subject: [Python-Dev] Re: Empty keyword
References: <ca1qme$5b9$1@sea.gmane.org>
Message-ID: <ca4elg$9o1$1@sea.gmane.org>

> It miht sound stupid or useless, or maybe someone has already mentioned
> it but sometimes I wish Python could provdie an "Empty" keyword like The
> "None" one.

None is not a keyword.  When it is, it will be more like a 'keyname'
(unrebindable name).

> if len(mylist) == 0:

as someone else said, 'if not mylist:'

>Anyhow, I must say that I didn't see any clear statement about what
>should go here or there, I naively thought it would be the best place.

My opinion: until you understand Python as it is and are contributing to
its future development and have watched the development list for at least a
couple of months (as I did), I think it better to stick to
comp.lang.python.  After seven years with Python, I still restrain my
posting here ;-)  In any case, some of the main developers also read c.l.p
and will mention here things that need to be.

Terry J. Reedy




From Jack.Jansen at cwi.nl  Tue Jun  8 09:38:26 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Tue Jun  8 09:38:26 2004
Subject: [Python-Dev] fopenRF() - defunct MacOS 9 thing?
In-Reply-To: <16578.28244.616928.748612@montanaro.dyndns.org>
References: <16578.28244.616928.748612@montanaro.dyndns.org>
Message-ID: <1ED26A41-B951-11D8-9123-000D934FF6B4@cwi.nl>


On 6 Jun 2004, at 03:07, Skip Montanaro wrote:

>
> I was messing around in fileobject.c today and came across this:
>
>     #ifdef HAVE_FOPENRF
>             if (*mode == '*') {
>                     FILE *fopenRF();
>                     f->f_fp = fopenRF(name, mode+1);
>             }
>             else
>     #endif
>
> Googling for fopenRF() indicated it is a way to open resource forks on 
> Macs
> (all the Google hits were Python-related).  Is that something that 
> should
> have been deleted with the demise of MacOS 9 support?

Yes, rip this out. While resource forks still exist on OSX the 
fopenRF() call is specific to the Metrowerks C library which is no 
longer supported.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman


From skip at pobox.com  Tue Jun  8 11:16:21 2004
From: skip at pobox.com (Skip Montanaro)
Date: Tue Jun  8 11:16:33 2004
Subject: [Python-Dev] fopenRF() - defunct MacOS 9 thing?
In-Reply-To: <1ED26A41-B951-11D8-9123-000D934FF6B4@cwi.nl>
References: <16578.28244.616928.748612@montanaro.dyndns.org>
	<1ED26A41-B951-11D8-9123-000D934FF6B4@cwi.nl>
Message-ID: <16581.55365.926478.161618@montanaro.dyndns.org>

    >> #ifdef HAVE_FOPENRF
    ...
    >> #endif
    >> 

    Jack> Yes, rip this out.

Thanks.  I'll get to this in a bit.

Skip

From fdrake at acm.org  Tue Jun  8 11:27:38 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue Jun  8 11:27:46 2004
Subject: [Python-Dev] Re: Python CVS docs - libposixpath.tex is wrong file!
In-Reply-To: <Pine.LNX.4.60.0406071653260.1573@bender.tc.fluke.com>
References: <Pine.LNX.4.60.0406071653260.1573@bender.tc.fluke.com>
Message-ID: <200406081127.38656.fdrake@acm.org>

On Monday 07 June 2004 08:00 pm, Mat Martineau wrote:
 > It looks like something went awry with sf.net CVS - somehow
 > libposixpath.tex (and all of its revision history) got swapped out
 > with a file from the "moodle" project.  I've verified on separate
 > machines and clean CVS checkouts.  The file CVS has been handing out
 > since this morning (at least) is attached - definitely not a LaTeX
 > file!
 >
 > Thought you'd want to know.

Mat just alerted me to this screwed-up file in the Python CVS.  Doing a "cvs 
log" on Doc/lib/libposixpath.tex shows an error in the repository:

cvs [log aborted]: unexpected '\x0' reading revision number in RCS file 
/cvsroot/python/python/dist/src/Doc/lib/libposixpath.tex,v

The most recent version of the file I can find on my disks (that isn't 
corrupt) is dated 16 April 2004.  I've started looking through the snapshots 
at http://cvs.perl.org/snapshots/python/python/ for a more recent good copy, 
but I'd really like a good copy of the ,v from the repository itself.

Does anyone have a recent copy of that?


  -Fred

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


From fdrake at acm.org  Tue Jun  8 11:57:04 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue Jun  8 12:02:18 2004
Subject: [Python-Dev] Re: Python CVS docs - libposixpath.tex is wrong file!
In-Reply-To: <200406081127.38656.fdrake@acm.org>
References: <Pine.LNX.4.60.0406071653260.1573@bender.tc.fluke.com>
	<200406081127.38656.fdrake@acm.org>
Message-ID: <200406081157.04430.fdrake@acm.org>

I've filed a support request with SF for this matter:

http://sourceforge.net/tracker/index.php?func=detail&aid=968983&group_id=1&atid=200001

I'd still like to know if anyone has been keeping backups of what repository 
tarballs have been available from SF.

I think it's time for us to deal with getting CVS hosted somewhere.  As I 
understand it, we can host SSH-accessible CVS at XS4ALL; we'll need someone 
to host an anonymous pserver elsewhere.  I'll guess that no committers are 
using authenticated pserver access (I don't know if SF supports that at all, 
but I doubt it).


  -Fred

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


From fdrake at acm.org  Tue Jun  8 12:06:03 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue Jun  8 12:06:12 2004
Subject: [Python-Dev] Re: Python CVS docs - libposixpath.tex is wrong file!
In-Reply-To: <200406081127.38656.fdrake@acm.org>
References: <Pine.LNX.4.60.0406071653260.1573@bender.tc.fluke.com>
	<200406081127.38656.fdrake@acm.org>
Message-ID: <200406081206.03882.fdrake@acm.org>

On Tuesday 08 June 2004 11:27 am, I wrote:
 > Does anyone have a recent copy of that?

Ok, the copy from:

   http://cvs.perl.org/snapshots/python/python/python_2004-06-08_070002.tar.gz

appears to be the most recent good copy.  That gives us a usable LaTeX file at 
least.


  -Fred

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


From theller at python.net  Tue Jun  8 12:30:29 2004
From: theller at python.net (Thomas Heller)
Date: Tue Jun  8 12:30:37 2004
Subject: [Python-Dev] Re: Python CVS docs - libposixpath.tex is wrong file!
In-Reply-To: <200406081157.04430.fdrake@acm.org> (Fred L. Drake, Jr.'s
	message of "Tue, 8 Jun 2004 11:57:04 -0400")
References: <Pine.LNX.4.60.0406071653260.1573@bender.tc.fluke.com>
	<200406081127.38656.fdrake@acm.org>
	<200406081157.04430.fdrake@acm.org>
Message-ID: <ekoq57x6.fsf@python.net>

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

> I've filed a support request with SF for this matter:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=968983&group_id=1&atid=200001
>

They seem to have disabled developer CVS, see
http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1#1086711437

> I'd still like to know if anyone has been keeping backups of what repository 
> tarballs have been available from SF.

Not me, unfortunately, at least not for the Python project.  And I don't have the
libposixfile.tex you need - sorry.

>
> I think it's time for us to deal with getting CVS hosted somewhere.  As I 
> understand it, we can host SSH-accessible CVS at XS4ALL; we'll need someone 
> to host an anonymous pserver elsewhere.  I'll guess that no committers are 
> using authenticated pserver access (I don't know if SF supports that at all, 
> but I doubt it).

As I understand it they don't support it.

Thomas


From martin at v.loewis.de  Tue Jun  8 13:43:43 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue Jun  8 13:44:01 2004
Subject: [Python-Dev] Re: Python CVS docs - libposixpath.tex is wrong file!
In-Reply-To: <200406081127.38656.fdrake@acm.org>
References: <Pine.LNX.4.60.0406071653260.1573@bender.tc.fluke.com>
	<200406081127.38656.fdrake@acm.org>
Message-ID: <40C5FACF.3070901@v.loewis.de>

Fred L. Drake, Jr. wrote:
> The most recent version of the file I can find on my disks (that isn't 
> corrupt) is dated 16 April 2004.  I've started looking through the snapshots 
> at http://cvs.perl.org/snapshots/python/python/ for a more recent good copy, 
> but I'd really like a good copy of the ,v from the repository itself.
> 
> Does anyone have a recent copy of that?

On

creosote.python.org:/usr/local/archives/python-cvsroot.tar.bz2.<version>

a lot of snapshots of the CVS repository are stored. I haven't looked
through them, but I would expect that one of them has the most recent
uncorrupted repository file; atleast .160 has the file apparently
still intact, and goes up to libposixpath.py,v rev 1.38/1.36.12.1.

If you cannot extract the necessary information out of these files,
please let me know.

The current snapshot has a file libposixpath.py,v which is completely
unrelated, which looks like SF had a disk corruption.

Regards,
Martin


From fdrake at acm.org  Tue Jun  8 13:47:08 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue Jun  8 13:47:19 2004
Subject: [Python-Dev] Re: Python CVS docs - libposixpath.tex is wrong file!
In-Reply-To: <40C5FACF.3070901@v.loewis.de>
References: <Pine.LNX.4.60.0406071653260.1573@bender.tc.fluke.com>
	<200406081127.38656.fdrake@acm.org> <40C5FACF.3070901@v.loewis.de>
Message-ID: <200406081347.08532.fdrake@acm.org>

On Tuesday 08 June 2004 01:43 pm, Martin v. L?wis wrote:
 > On
 >
 > creosote.python.org:/usr/local/archives/python-cvsroot.tar.bz2.<version>
 >
 > a lot of snapshots of the CVS repository are stored. I haven't looked
 > through them, but I would expect that one of them has the most recent
 > uncorrupted repository file; atleast .160 has the file apparently
 > still intact, and goes up to libposixpath.py,v rev 1.38/1.36.12.1.

I'll dig through these; thanks!

 > The current snapshot has a file libposixpath.py,v which is completely
 > unrelated, which looks like SF had a disk corruption.

Ouch.


  -Fred

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


From bac at OCF.Berkeley.EDU  Tue Jun  8 14:28:06 2004
From: bac at OCF.Berkeley.EDU (Brett)
Date: Tue Jun  8 14:30:18 2004
Subject: [Python-Dev] various test failures - test_site, test_tempfile,
	test_bsddb/anydbm
In-Reply-To: <16579.7132.999269.435446@montanaro.dyndns.org>
References: <16579.7132.999269.435446@montanaro.dyndns.org>
Message-ID: <40C60536.5040007@ocf.berkeley.edu>

Skip Montanaro wrote:
[snip]
> On both Mac OS X and Linux (Mandrake 8.1-ish) test_site fails with:
> 
>     test test_site failed -- Traceback (most recent call last):
>       File "/home/skip/tmp/python/dist/src/Lib/test/test_site.py", line 150, in test_sitepackages
> 	self.fail("'site-packages' directory missing'")
>     AssertionError: 'site-packages' directory missing'
> 
> This seems like a problem with the test itself.  It should be okay to run
> the tests in the build directory without a site-packages directory.
> 

This is my fault.  The test has been removed since it passed only if you 
had installed Python previously (didn't depend on the location of the 
executable).  Probably should add it back in at some point, but only 
after some detection can be done to see if an installation has occurred 
to make the test conditional.

-Brett

P.S.: Sorry for the delayed response; on vacation visiting my father.

From troels at thule.no  Tue Jun  8 14:30:59 2004
From: troels at thule.no (Troels Walsted Hansen)
Date: Tue Jun  8 14:31:03 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <20040608121256.GA22268@rogue.amk.ca>
References: <1ED4ECF91CDED24C8D012BCF2B034F1306967C67@its-xchg4.massey.ac.nz>	<1ED4ECF91CDED24C8D012BCF2B034F1304677F0E@its-xchg4.massey.ac.nz>	<20040607113009.GB17574@rogue.amk.ca>	<20040607140955.GA13280@panix.com>	<20040607145357.GB18282@rogue.amk.ca>	<40C539DB.5060904@interlink.com.au>
	<20040608121256.GA22268@rogue.amk.ca>
Message-ID: <40C605E3.6070405@thule.no>

A.M. Kuchling wrote:

>OK.  If alpha1 slips a few days, we'd probably run the bug day without
>actually checking in any changes, which will be a bit of a pain but
>not a problem.  July 10th it is!
>  
>

Unfortunately I missed the last bug day, and the next one seems to be 
some time off... Perhaps I can convince a Python developer with Windows 
and socket experience to take a look at bug http://python.org/sf/777597 
and the associated patch http://python.org/sf/965036 ?

The bug is in the new timeout code and causes excessive delay in 
connect() when a connection refused error should have been raised 
immediately.

Troels


From skip at pobox.com  Tue Jun  8 15:18:21 2004
From: skip at pobox.com (Skip Montanaro)
Date: Tue Jun  8 15:18:27 2004
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Python
 pystrtod.c, NONE, 2.1 compile.c, 2.302, 2.303 marshal.c, 1.76, 1.77
In-Reply-To: <E1BXliT-0006vi-EF@sc8-pr-cvs1.sourceforge.net>
References: <E1BXliT-0006vi-EF@sc8-pr-cvs1.sourceforge.net>
Message-ID: <16582.4349.596912.141484@montanaro.dyndns.org>


    Martin> Modified Files:
    Martin>     compile.c marshal.c 
    Martin> Added Files:
    Martin>     pystrtod.c 
    Martin> Log Message:
    Martin> Patch #774665: Make Python LC_NUMERIC agnostic.
    ...

Are we sure the SF CVS problem has been resolved?  If not, maybe it would be
best to hold off on checkins for now.

Skip

From fdrake at acm.org  Tue Jun  8 15:25:05 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue Jun  8 15:25:16 2004
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Python
	pystrtod.c, NONE, 2.1 compile.c, 2.302, 2.303 marshal.c, 1.76, 1.77
In-Reply-To: <16582.4349.596912.141484@montanaro.dyndns.org>
References: <E1BXliT-0006vi-EF@sc8-pr-cvs1.sourceforge.net>
	<16582.4349.596912.141484@montanaro.dyndns.org>
Message-ID: <200406081525.06019.fdrake@acm.org>

On Tuesday 08 June 2004 03:18 pm, Skip Montanaro wrote:
 > Are we sure the SF CVS problem has been resolved?  If not, maybe it would
 > be best to hold off on checkins for now.

There's no reason to think it's resolved.  The only response to my support 
request so far is this:

------------------------------------------------------------------------------
Date: 2004-06-08 13:57
Sender: burleySourceForge.net Site Admin
Logged In: YES 
user_id=597273

Greetings,

We are and have been looking into this issue since shortly
after seeing this report. I don't have further information
to provide at this time but will as soon as I do.

Thank you,

David Burley
Second Level Support Technician, SourceForge.net
burley@sourceforge.net
------------------------------------------------------------------------------


  -Fred

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


From martin at v.loewis.de  Tue Jun  8 16:49:01 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue Jun  8 16:49:08 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <40C605E3.6070405@thule.no>
References: <1ED4ECF91CDED24C8D012BCF2B034F1306967C67@its-xchg4.massey.ac.nz>	<1ED4ECF91CDED24C8D012BCF2B034F1304677F0E@its-xchg4.massey.ac.nz>	<20040607113009.GB17574@rogue.amk.ca>	<20040607140955.GA13280@panix.com>	<20040607145357.GB18282@rogue.amk.ca>	<40C539DB.5060904@interlink.com.au>	<20040608121256.GA22268@rogue.amk.ca>
	<40C605E3.6070405@thule.no>
Message-ID: <40C6263D.6020100@v.loewis.de>

Troels Walsted Hansen wrote:
> Unfortunately I missed the last bug day, and the next one seems to be 
> some time off... Perhaps I can convince a Python developer with Windows 
> and socket experience to take a look at bug http://python.org/sf/777597 
> and the associated patch http://python.org/sf/965036 ?

I've briefly looked at it, and noticed that the patch should not be
applied. So I suggest you complete the patch, and submit one that
should be applied. You should submit that as a new patch, and close
the one that should not be applied.

Regards,
Martin


From martin at v.loewis.de  Tue Jun  8 16:51:00 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue Jun  8 16:51:07 2004
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Python
	pystrtod.c, NONE, 2.1 compile.c, 2.302, 2.303 marshal.c, 1.76, 1.77
In-Reply-To: <16582.4349.596912.141484@montanaro.dyndns.org>
References: <E1BXliT-0006vi-EF@sc8-pr-cvs1.sourceforge.net>
	<16582.4349.596912.141484@montanaro.dyndns.org>
Message-ID: <40C626B4.5040602@v.loewis.de>

Skip Montanaro wrote:
> Are we sure the SF CVS problem has been resolved?  If not, maybe it would be
> best to hold off on checkins for now.

Are we sure that we are notified when the problems (whatever they are)
get resolved? We may wait forever - or we may risk to duplicate work
if it turns out that an old repository gets restored.

Regards,
Martin


From troels at thule.no  Tue Jun  8 17:06:20 2004
From: troels at thule.no (Troels Walsted Hansen)
Date: Tue Jun  8 17:06:21 2004
Subject: [Python-Dev] Bug day outcome
In-Reply-To: <40C6263D.6020100@v.loewis.de>
References: <1ED4ECF91CDED24C8D012BCF2B034F1306967C67@its-xchg4.massey.ac.nz>	<1ED4ECF91CDED24C8D012BCF2B034F1304677F0E@its-xchg4.massey.ac.nz>	<20040607113009.GB17574@rogue.amk.ca>	<20040607140955.GA13280@panix.com>	<20040607145357.GB18282@rogue.amk.ca>	<40C539DB.5060904@interlink.com.au>	<20040608121256.GA22268@rogue.amk.ca>
	<40C605E3.6070405@thule.no> <40C6263D.6020100@v.loewis.de>
Message-ID: <40C62A4C.1000906@thule.no>

Martin v. L?wis wrote:

> Troels Walsted Hansen wrote:
>
>> Unfortunately I missed the last bug day, and the next one seems to be 
>> some time off... Perhaps I can convince a Python developer with 
>> Windows and socket experience to take a look at bug 
>> http://python.org/sf/777597 and the associated patch 
>> http://python.org/sf/965036 ?
>
> I've briefly looked at it, and noticed that the patch should not be
> applied. So I suggest you complete the patch, and submit one that
> should be applied. You should submit that as a new patch, and close
> the one that should not be applied.


The patch tracker item contains both a regression test and an updated 
patch now. I attached both some time ago, I wasn't aware that it was 
preferable to open a new patch tracking item.

Thanks for checking it out.

Troels


From python at rcn.com  Tue Jun  8 05:17:48 2004
From: python at rcn.com (Raymond Hettinger)
Date: Tue Jun  8 17:18:10 2004
Subject: [Python-Dev] Re: [Python-checkins]
	python/dist/src/Pythonpystrtod.c, NONE, 2.1 compile.c, 2.302,
	2.303 marshal.c, 1.76, 1.77
In-Reply-To: <40C626B4.5040602@v.loewis.de>
Message-ID: <000401c44d39$77c09180$e841fea9@oemcomputer>

[Skip]
> > Are we sure the SF CVS problem has been resolved?  If not, maybe it
> would be
> > best to hold off on checkins for now.

[Martin]
> Are we sure that we are notified when the problems (whatever they are)
> get resolved? We may wait forever - or we may risk to duplicate work
> if it turns out that an old repository gets restored.

Right now, the checkin, checkout, update process is working fine.

IMO, we should continue as if it were a one-time problem.

Holding-off on checkins at this point may keep some work from getting
done at all (I suspect that the several recent contributions were all
done on borrowed time).  IOW, I would rather run the risk of having to
re-apply than to risk that contributions temporarily stop.


Raymond


From tim.one at comcast.net  Tue Jun  8 17:32:24 2004
From: tim.one at comcast.net (Tim Peters)
Date: Tue Jun  8 17:32:33 2004
Subject: [Python-Dev] Re:
	[Python-checkins]python/dist/src/Pythonpystrtod.c, NONE,
	2.1 compile.c, 2.302, 2.303 marshal.c, 1.76, 1.77
In-Reply-To: <000401c44d39$77c09180$e841fea9@oemcomputer>
Message-ID: <mailman.379.1086730353.6944.python-dev@python.org>

[Raymond Hettinger]
> Right now, the checkin, checkout, update process is working fine.
>
> IMO, we should continue as if it were a one-time problem.

+1.  SW doesn't work, and HW is unreliable.  If you wait for a guarantee
that nothing will go wrong, you'll end up being my age in a just a few dozen
short decades, but without the rollicking good memories that make me such an
agreeable old fart <wink>.



From duncf at ihug.co.nz  Tue Jun  8 22:48:46 2004
From: duncf at ihug.co.nz (duncf@ihug.co.nz)
Date: Tue Jun  8 19:41:42 2004
Subject: [Python-Dev] software
In-Reply-To: <AGB32EBC6AGE77BJ@python.org>
References: <AGB32EBC6AGE77BJ@python.org>
Message-ID: <6EG8IC2I5HEJBE9K@ihug.co.nz>

Microsoft Windows XP Professional 2002 
Retail price: $270.99 Our low Price: $50.00 You Save: $220.00  
 
Adobe Photoshop 7.0  
Retail price: $609.99 Our low Price: $60.00 You Save: $550.00  
 
Microsoft Office XP Professional 2002  
Retail price: $579.99 Our low Price: $60.00 You Save: $510.00  
 
Adobe Illustrator 10
Retail price: $270.99 Our low Price: $60.00 You Save: $210.00  
 
Corel Draw Graphics Suite 11
Retail price: $270.99 Our low Price: $60.00 You Save: $210.00  

Delphi 7
Retail price: $404.99 Our low Price: $60.00 You Save: $335.00  
 

And more!!!


Why so cheap?

All the software is OEM- Meaning that you don't get the box and the
manual with your software. All you will receive is the actual
software and your unique registration code. 

All the software is in the English language for PC. Our offers
are unbeatable and we always update our prices to make sure we
provide you with the best possible offers. Hurry up and place
your order, because our supplies are limited.


Our site is  http://LENFGB.biz/OE017/?affiliate_id=233763&campaign_id=601

uns * ub - scribe http://NANNEH.biz/diamondtron.php?affiliate_id=233763&campaign_id=601


yptqncbv tmirb mttmtfw uxbfb tbnqqco twhw ziqtwb 
lxnu fbdkxxt zcjte zkvbbdyt ayqq qmtdkhy 
pibchzj hbv aful bvmfuwf rmxib p mmyke 


From listuser at br.logorrhea.com  Tue Jun  8 20:10:04 2004
From: listuser at br.logorrhea.com (listuser)
Date: Tue Jun  8 20:42:22 2004
Subject: [Python-Dev] creating factory methods in C extension modules.
Message-ID: <200406081610.04528.listuser@br.logorrhea.com>

I'm creating an C extension module that returns one of my C-defined python 
classes from a factory function. is it correct to simple have the factory 
function allocate and init the object by calling the functions I defined and 
set as tp_new and tp_init in the PyTypeObject? If not am I supposed to use 
PyObject_New and PyObject_Init or something?

Cherrs,
-P

From python at rcn.com  Tue Jun  8 09:04:59 2004
From: python at rcn.com (Raymond Hettinger)
Date: Tue Jun  8 21:05:22 2004
Subject: [Python-Dev] creating factory methods in C extension modules.
In-Reply-To: <200406081610.04528.listuser@br.logorrhea.com>
Message-ID: <000201c44d59$3710ea20$ab32c797@oemcomputer>

> I'm creating an C extension module that returns one of my C-defined
python
> classes from a factory function. is it correct to simple have the
factory
> function allocate and init the object by calling the functions I
defined
> and
> set as tp_new and tp_init in the PyTypeObject? If not am I supposed to
use
> PyObject_New and PyObject_Init or something?

These kind of questions should be directed to comp.lang.python.

FWIW, good examples can be found in Objects/listobject.c.  The code for
list_slice is effectively a factory function that returns a new list.
It calls PyList_New() which calls PyObject_GC_New() to create the new
object.


Raymond


From neal at metaslash.com  Tue Jun  8 21:48:41 2004
From: neal at metaslash.com (Neal Norwitz)
Date: Tue Jun  8 21:48:49 2004
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules
	posixmodule.c, 2.318, 2.319
In-Reply-To: <wu2i5obs.fsf@python.net>
References: <E1BX4RS-0004MV-Nc@sc8-pr-cvs1.sourceforge.net>
	<wu2i5obs.fsf@python.net>
Message-ID: <20040609014841.GE955@epoch.metaslash.com>

On Tue, Jun 08, 2004 at 12:36:07PM +0200, Thomas Heller wrote:
> nnorwitz@users.sourceforge.net writes:
> 
> > Update of /cvsroot/python/python/dist/src/Modules
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16270/Modules
> >
> > Modified Files:
> > 	posixmodule.c 
> > Log Message:
> > Plug a few memory leaks in utime().  path is allocated from within 
> > PyArg_ParseTuple() since the format is "et"  This change should
> > be reviewed carefully.
> 
> I believe 'path' must be set to NULL at the start of the posix_utime
> function - I had a crash in a debug build on windows when running
> lib\test\test_unicode_file.py.

Yes, you are correct.  I checked in a fix.  path should not be used if
have_unicode_filename is set.  So I removed an unnecessary free too.

Let me know if you have any more problems.

Neal


From dmgass at hotmail.com  Wed Jun  9 09:40:36 2004
From: dmgass at hotmail.com (Dan Gass)
Date: Wed Jun  9 09:40:41 2004
Subject: [Python-Dev] Side by Side Differencing Patch
Message-ID: <BAY18-F62fh6BYVKBLE00074f54@hotmail.com>

Tim,

A while back I submitted a Python patch (#914575) for the difflib.py module 
and the diff.py utility script to add support for generating side by side 
differences. It was intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

1) Is this worthwhile functionality where it would be worth including it and 
supporting it in Python?
2) What can I do to help evolve it, prove its worth and get this patch on 
the road for inclusion in Python?

The patch was designed to not interfere or duplicate existing code (it uses 
the output of the ndiff iterator) and I believe is very maintainable code.  
I initially wrote it for showing log differences in HTML test reports 
(personal project) but have also found it useful at work for supplementing 
Doxygen documentation with source differences and also a utility script 
which generates an HTML report of all the source differences between two 
builds.  In addition I've set up CVS to use it so that I have frequent 
exposure to the results of my algorithms to make sure I never see quirks.

Thanks,
Dan Gass

_________________________________________________________________
Getting married? Find great tips, tools and the latest trends at MSN Life 
Events. http://lifeevents.msn.com/category.aspx?cid=married


From fdrake at acm.org  Wed Jun  9 12:26:25 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed Jun  9 12:26:35 2004
Subject: [Python-Dev] Re: Python CVS docs - libposixpath.tex is wrong file!
In-Reply-To: <40C5FACF.3070901@v.loewis.de>
References: <Pine.LNX.4.60.0406071653260.1573@bender.tc.fluke.com>
	<200406081127.38656.fdrake@acm.org> <40C5FACF.3070901@v.loewis.de>
Message-ID: <200406091226.25461.fdrake@acm.org>

On Tuesday 08 June 2004 01:43 pm, Martin v. L?wis wrote:
 > If you cannot extract the necessary information out of these files,
 > please let me know.

I was able to get a good ,v file from

creosote.python.org:/usr/local/archives/python-cvsroot.tar.bz2.168

I've not checked any of the other files in archive 169 for problems; that's 
likely worth doing.  Archive 168 was retrieved from SF on June 5; the next 
archive (169) was retrieved 24 hours later and contains at least one wrong ,v 
file.


  -Fred

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


From nidoizo at yahoo.com  Wed Jun  9 13:58:55 2004
From: nidoizo at yahoo.com (Nicolas Fleury)
Date: Wed Jun  9 14:10:47 2004
Subject: [Python-Dev] Re: Dropping decorator syntax for 2.4?
In-Reply-To: <40C1319B.4050809@prescod.net>
References: <200406021519.i52FJP025688@guido.python.org>
	<40C1319B.4050809@prescod.net>
Message-ID: <ca7j4u$fml$1@sea.gmane.org>

Paul Prescod wrote:
> How about:
> 
> from __experimental__ import decorator_syntax
> 
>  Paul Prescod

It sounds like a great idea to me.  Making the difference between what 
*will* be in future releases and what *might* be in future releases.
Just my 2 cents.
Regards,
Nicolas


From python at rcn.com  Wed Jun  9 03:06:32 2004
From: python at rcn.com (Raymond Hettinger)
Date: Wed Jun  9 15:06:58 2004
Subject: [Python-Dev] Re: Dropping decorator syntax for 2.4?
In-Reply-To: <ca7j4u$fml$1@sea.gmane.org>
Message-ID: <000701c44df0$4c01e960$ab16c797@oemcomputer>

> Paul Prescod wrote:
> > How about:
> >
> > from __experimental__ import decorator_syntax

[Nicolas]
> It sounds like a great idea to me.  Making the difference between what
> *will* be in future releases and what *might* be in future releases.

-1

To mark a new feature as experimental is essentially deprecating it
before it ever gets started.  It is a strong discouragement from writing
any programs that use the feature.  Even so, some people will use it and
there will be pressure to keep it even if the syntax turns out to be a
loser.

worst-of-both-worlds-ly yours,


Raymond


From theller at python.net  Wed Jun  9 15:22:36 2004
From: theller at python.net (Thomas Heller)
Date: Wed Jun  9 15:22:46 2004
Subject: [Python-Dev] undocumented api functions
Message-ID: <y8mwtu2r.fsf@python.net>

Every so often, when writing C extensions, or embedding Python, I
encounter api functions which seem to be useful, but they are
undocumented.  I brought the Doc/tools/undoc_symbols.py script up to
date - this uses ctags to find function declarations, macro definitions
and typedefs, then looks through the .tex files whether they are
mentioned or not.

Currently, for CVS head, it finds 239 undocumented function prototypes.
Probably most of them should better stay undocumented and unused by
extension writers, but several are really useful like these random picks:
  PySys_SetPath PyGILState_* PyOS_snprintf

First I thought I write docs for some of them myself and submit patches
or check them in directly, but maybe a more organized way would be
better.  So, as an experiment, I set up a wiki page for that.

<http://starship.python.net/crew/theller/moin.cgi/Documenting_25CorePythonApiFunctions>

Maybe the page should be moved to the python.org wiki, but I'd like to
hear any comments before.

Thanks,

Thomas


From nidoizo at yahoo.com  Wed Jun  9 15:39:42 2004
From: nidoizo at yahoo.com (Nicolas Fleury)
Date: Wed Jun  9 15:39:49 2004
Subject: [Python-Dev] Re: Dropping decorator syntax for 2.4?
In-Reply-To: <000701c44df0$4c01e960$ab16c797@oemcomputer>
References: <ca7j4u$fml$1@sea.gmane.org>
	<000701c44df0$4c01e960$ab16c797@oemcomputer>
Message-ID: <ca7p1u$3j0$1@sea.gmane.org>

Raymond Hettinger wrote:
> -1
> 
> To mark a new feature as experimental is essentially deprecating it
> before it ever gets started.  It is a strong discouragement from writing
> any programs that use the feature.  Even so, some people will use it and
> there will be pressure to keep it even if the syntax turns out to be a
> loser.

I agree with you.  However, there's a difference between a deprecated 
feature and an experimental one.  You might not have any easy workaround 
for an experimental feature, which you usually have for a deprecated 
one.  Maybe some developers prefer to have a "deprecated-experimental" 
way to do something than no way at all and afford the cost of changing 
everything in a next release.  This __experimental__ would also only 
make sense for features that *will* be present in future but might be in 
a different form.  That way, there's no strong discouragement from 
writing any program using that feature, but rather a strong warning that 
is might (and even should) change in a next release.

It is true that not a lot features would fall in that category and I'm 
not advocating that decorators is.

Regards,
Nicolas


From skip at pobox.com  Wed Jun  9 16:27:07 2004
From: skip at pobox.com (Skip Montanaro)
Date: Wed Jun  9 16:27:25 2004
Subject: [Python-Dev] undocumented api functions
In-Reply-To: <y8mwtu2r.fsf@python.net>
References: <y8mwtu2r.fsf@python.net>
Message-ID: <16583.29339.755256.207843@montanaro.dyndns.org>


    Thomas> First I thought I write docs for some of them myself and submit
    Thomas> patches or check them in directly, but maybe a more organized
    Thomas> way would be better.  So, as an experiment, I set up a wiki page
    Thomas> for that.

    Thomas> <http://starship.python.net/crew/theller/moin.cgi/Documenting_25CorePythonApiFunctions>

    Thomas> Maybe the page should be moved to the python.org wiki, but I'd
    Thomas> like to hear any comments before.

This worked pretty well for the tutorial glossary.  I started up a wiki
page, gathered a bunch of contributions then filtered the submissions into
what is in the current glossary.  (I must admit that Raymond Hettinger was a
major contributor.  I actually did very little.)

Skip

From nbastin at opnet.com  Wed Jun  9 17:09:59 2004
From: nbastin at opnet.com (Nick Bastin)
Date: Wed Jun  9 17:10:17 2004
Subject: [Python-Dev] Int/long future warning (again)
Message-ID: <5DF130BC-BA59-11D8-B385-000D932927FE@opnet.com>

Not to dredge up a thread from 1.5 years ago, but I guess I will.. :-)

Did anyone actually implement a __future__ import or SOMETHING to 
disable the annoying "FutureWarning: hex/oct constants > sys.maxint 
will return positive values in Python 2.4 and up".  There was some 
discussion that there should be a way to suppress this message before 
2.3 went out the door, but I don't see any indications on the mailing 
list (or in the code) that there's any way to suppress the message.

--
Nick


From bob at redivi.com  Wed Jun  9 17:19:19 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Jun  9 17:19:25 2004
Subject: [Python-Dev] Int/long future warning (again)
In-Reply-To: <5DF130BC-BA59-11D8-B385-000D932927FE@opnet.com>
References: <5DF130BC-BA59-11D8-B385-000D932927FE@opnet.com>
Message-ID: <ABD1D1C2-BA5A-11D8-A247-000A95686CD8@redivi.com>


On Jun 9, 2004, at 5:09 PM, Nick Bastin wrote:

> Not to dredge up a thread from 1.5 years ago, but I guess I will.. :-)
>
> Did anyone actually implement a __future__ import or SOMETHING to 
> disable the annoying "FutureWarning: hex/oct constants > sys.maxint 
> will return positive values in Python 2.4 and up".  There was some 
> discussion that there should be a way to suppress this message before 
> 2.3 went out the door, but I don't see any indications on the mailing 
> list (or in the code) that there's any way to suppress the message.

 >>> import warnings
 >>> warnings.filterwarnings('ignore', category=FutureWarning)
 >>> 0xffffffff
-1

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040609/8c19770c/smime.bin
From tjreedy at udel.edu  Wed Jun  9 17:58:07 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed Jun  9 17:58:17 2004
Subject: [Python-Dev] Re: undocumented api functions
References: <y8mwtu2r.fsf@python.net>
Message-ID: <ca815i$kb7$1@sea.gmane.org>


"Thomas Heller" <theller@python.net> wrote in message
news:y8mwtu2r.fsf@python.net...
> Every so often, when writing C extensions, or embedding Python, I
> encounter api functions which seem to be useful, but they are
> undocumented.  I brought the Doc/tools/undoc_symbols.py script up to
> date - this uses ctags to find function declarations, macro definitions
> and typedefs, then looks through the .tex files whether they are
> mentioned or not.
>
> Currently, for CVS head, it finds 239 undocumented function prototypes.
> Probably most of them should better stay undocumented and unused by
> extension writers,

Perhaps these could be tagged, if they are not now, in a way, such as /*
NOT API */, that both readers and your script could recognize.

TJR




From listuser at br.logorrhea.com  Wed Jun  9 18:01:23 2004
From: listuser at br.logorrhea.com (Patrick Stinson)
Date: Wed Jun  9 18:06:54 2004
Subject: [Python-Dev] creating factory methods in C extension modules.
In-Reply-To: <000201c44d59$3710ea20$ab32c797@oemcomputer>
References: <000201c44d59$3710ea20$ab32c797@oemcomputer>
Message-ID: <200406091401.23515.listuser@br.logorrhea.com>

excellent, that will help.

On Tuesday 08 June 2004 05:04 am, Raymond Hettinger wrote:
> > I'm creating an C extension module that returns one of my C-defined
>
> python
>
> > classes from a factory function. is it correct to simple have the
>
> factory
>
> > function allocate and init the object by calling the functions I
>
> defined
>
> > and
> > set as tp_new and tp_init in the PyTypeObject? If not am I supposed to
>
> use
>
> > PyObject_New and PyObject_Init or something?
>
> These kind of questions should be directed to comp.lang.python.
>
> FWIW, good examples can be found in Objects/listobject.c.  The code for
> list_slice is effectively a factory function that returns a new list.
> It calls PyList_New() which calls PyObject_GC_New() to create the new
> object.
>
>
> Raymond

From oliver.schoenborn at utoronto.ca  Wed Jun  9 21:25:25 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Wed Jun  9 21:25:36 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
Message-ID: <042201c44e89$cee72f40$0202a8c0@olidesk>

This is a module I made to test a concept of finalization *not* based on
__del__. I'm curious to find out if the techniques look like they could be
implemented directly in the Python interpreter to lessen the burden on the
user, which is why I post this here.

Summary:
- Seems like can't rely on __del__ being called (standard says no guarantee)
- Means a coder of a class for which instances need some sort of
finalization (e.g. file objects need close()) must document textually the
need for finalization
- User of class must remember to use try/finally blocks and position them
judiciously since several objects may require "finalization"; this is easy
to forget if there are multiple (normal or exceptional) exit points.

The technique is based on inheritance: a class that needs finalization is
derived from scope.NeedsFinalization. This class adds info to a special
function, called scope.ScopeGuardian, that wraps a try/finally around the
function that you are interested in making "finalization safe" (ie the
function in which you would normally have to worry about manually putting a
try/finally). This seems to work well and has the advantage that:

- Coder of class makes explicit by base class that finalizaiton is
important, no need to remember to document
- User of class knows just by looking at class def, can't overlook  a
sentence saying "call this-that when done with object"
- Some error checking can be done to decrease likelyhood of user forgetting
the try/finallies (which are no longer needed) or of wanting finalization
before ref count goes to 0.

The info added to the function, seems to me, could be done at the
interpreter implementation level, e.g. by adding a new field to function
objects (f_name, etc), such as f_scopedobjs, so it would be almost trivial
to use even for beginners. There are a couple of limitations in the current
implementation that are easy to fix (e.g. make it work for recursive
functions, nested scope guarding, and methods), don't know yet about thread
safety.

Anyways, from having looked at the archives, doesn't seem like this
technique has been used, and would't require addition of a new keyword (only
a new class, .e.g as opposed to pep310 approach).

Thanks for any feedback,

Oliver

-------------- next part --------------
"""
This module provides a class, NeedsFinalization, that you derive from
to indicate that instances of it need finalization upon local
(function) scope. This module also provides a ScopeGuarded() function,
that takes as argument a function and returns a scope-guarded
function.

To use this module in a function that instantiates objects that must
be finalized on exit of function, derive the class of those objects
from NeedsFinalization. Don't forget to call
NeedsFinalization.__init__ in the constructors and to define
_finalize(self) for each class. Then, in the module where your
function is defined, do yourFn = ScopeGuarded(yourFn). This rebinds
your function to be scope-guarded. Now when you call yourFn(), a
special function actually gets called that makes sure all instances of
NeedsFinalization in your original yourFn get deleted. Note that some
runtime error checking is done for you: if you forget to call
NeedsFinalization.__init__(self), or you forget to wrap func but
func contains instances of NeedsFinalization, or if you 

Ex::

    class MyClass(NeedsFinalization):
        def __init__(self):
            NeedsFinalization.__init__(self)

        def _finalize(self):
            # do finalization stuff

    def yourFunc(name, greeting):
        obj1 = MyClass() # needs finalization
        obj2 = 'asdf'    # doesn't need it
        # do stuff with name, greeting, obj1 and obj2
        return (0,3)

    yourFunc = ScopeGuarded(yourFunc)
    yourFunc(1,'hello')


This module demonstrates that scope exit for local scopes can have
the equivalent of automatic, guaranteed finalizers, using techniques
that could most likely be implemented inside Python interpreter.
This would bypass the need for re-assigned function names and avoid
the two extra levels of indirection needed in the current
implementation. This would require a built-in class
NeedsFinalization but ScopeGuarded would become hidden from user:
instead, every NeedsFinalization can add itself to a special
built-in field of function objects, and the function would go over
that list upon return and do the finally clause.
  
Notes:

- Current implementation doesn't work for recursive functions, or
  multiple levels of scope guarding, or multiple threads: this could
  probably work if a stack of lists is used for func.f_scopedObjs
  instead of a plain list. However, this module is merely a
  demonstration of the concept for study.

- Probably doesn't work for diamond inheritence diagrams: the
  _finalize() method of root of diamond will get called twice. How
  should this situation be trapped? Perhaps instead of asking user to
  call base class _finalize(), the user would call
  self.finalize_bases(), and that function, implemented in
  NeedsFinalization, would make sure things only get called once (if
  possible).

- Could it be made to work for unbound methods? Docs of inspect module
  seem to say no.
  
- There may be other issues to be resolved, other than the two
  above (recursion etc).
  
:Author:     Oliver Schoenborn
:Since:      Jun 9, 2004
:Version:    $Id$
:Copyright:  \(c) 2004 Oliver
:License:    Same as for Python

"""

import inspect, sys

def ScopeGuarded(func):
    """Return func wrapped such that if you call func(...) you
    get the _finalize() method of all instances that derive
    from NeedsFinalization, instantiate in func, to be called
    upon return, normal or via exception. """
    return lambda *args, **kwargs: ScopeGuardian(func, *args, **kwargs)
    
class NeedsFinalization:
    def __init__(self):
        """Find ScopeGuardian function that called function
        that instantiated us."""
        self.__finalized = False
        
        stack = inspect.stack()
        try:
            lframe = stack[0][0]
            while (lframe is not None) and (lframe.f_code.co_name != 'ScopeGuardian'):
                lframe = lframe.f_back
                
        finally:
            del stack

        if lframe is None:
            msg = '%s: Forgot to scope-guard your function???' % repr(self)
            raise RuntimeError, msg

        # ok, we're ready
        fname = lframe.f_code.co_name
        guardedFunc = lframe.f_locals['func']
        
        print '%s: instantiated by scope-guarded %s' % (repr(self), guardedFunc)
        guardedFunc.f_scopedObjs.append(self)
        
    def finalizeMaster(self):
        """Derived classes MUST define a self._finalize() method,
        where they do their finalization for scope exit."""
        print '%s: Finalize() being called' % repr(self)
        assert sys.getrefcount(self) == 5
        self._finalize()
        self.__finalized = True

    def __del__(self):
        """This just does some error checking, probably want to remove
        in production in case derived objects involved in cycles."""
        try:
            problem = not self.__finalized
        except AttributeError:
            print '%s: NeedsFinalization.__init__ not called for %s' % (repr(self), self.__class__)
            raise RuntimeError, msg

        if not problem:
            print '%s: Finalized properly' % repr(self)
        else:
            # this is being called because exception was thrown
            pass
            
def ScopeGuardian(func, *args, **kwargs):
    """Make func finalize its locals that said neede finalization.
    This is done by wrapping func function in a try/finally block.
    When the finally clause is executed, all instances of classes
    derived from NeedsFinalization, and instantiated in func, will be
    in a special attribute func.f_scopedObjs. We go over that list and
    call finalizeMaster() for each item in list."""
    try:
        func.f_scopedObjs = []
        func(*args, **kwargs)
        print 'Scoped variables created during call to %s: %s\n\n' \
              % (func, func.f_scopedObjs)
        
    finally:
        if func.f_scopedObjs != []:
            for obj in func.f_scopedObjs:
                obj.finalizeMaster()
            func.f_scopedObjs = []


def test():
    
    class TestFree:
        def _finalize():
            raise RuntimeError, 'finalize() not supposed to be called'

    class TestDanger(NeedsFinalization):
        def __init__(self):
            NeedsFinalization.__init__(self)
        
        def _finalize(self):
            """Override this. If you class inherits from a
            class derived from NeedsFinalization, make sure to
            call parent.finalize()."""
            pass
    
    class TestDangerNoInit(NeedsFinalization):
        def _finalize(self):
            pass

    def func1():
        ok = TestFree()
        danger = TestDanger()

    # test when forget to use ScopeGuardian
    try:
        hello = func1()
        assert False, 'Expected exception not thrown!'
    except RuntimeError, msg:
        print 'Expected exception caught: ', msg
        
    func1 = ScopeGuarded(func1)
    func1()

    def func2(objType):
        dontKnow = objType()

    func2 = ScopeGuarded(func2)
    #try:
    func2(TestDangerNoInit)
    func2(TestDanger)
        #assert False, 'Expected exception not thrown!'
    #except RuntimeError, msg:
        #print 'Expected exception caught: ', msg
        

if __name__ == '__main__':
    test()
    
From tim.one at comcast.net  Wed Jun  9 23:43:24 2004
From: tim.one at comcast.net (Tim Peters)
Date: Wed Jun  9 23:43:34 2004
Subject: [Python-Dev] Side by Side Differencing Patch
In-Reply-To: <BAY18-F62fh6BYVKBLE00074f54@hotmail.com>
Message-ID: <mailman.386.1086839014.6944.python-dev@python.org>

[Dan Gass]
> A while back I submitted a Python patch (#914575) for the difflib.py
> module and the diff.py utility script to add support for generating side
> by side differences. It was intended to be used for generating HTML pages
> but is generic where it can be used for other types of markup.

I wondered why you addressed this to me, and then I saw that someone
assigned your patch to me.  Sucks, doesn't it <0.5 wink>?  I'm sorry it sat
there ignored.  Sad fact is we have way more bug and patch reports than we
have volunteers to review them, and in the little time I can still make for
that I tend to focus on bug or bug+patch reports rather than new features.

That said, I downloaded the zip file attached to your patch just now, and
was delighted by the examples of its output you included.  I'd definitely
use this!  OTOH, I'm not an HTML Guy, and unassigned myself -- I'm not the
best person to review it.  I'm +1 on the concept, FWIW.

> 1) Is this worthwhile functionality where it would be worth including it
>    and supporting it in Python?

Yes, I think so.  The closest alternative I know of is the HTML-ized
diff'ing included in ViewCVS, which I believe also builds on difflib
functions.  I like your output better, both because of the embedded "next
difference" links and because of the intraline difference marking.

> 2) What can I do to help evolve it, prove its worth and get this patch on
>    the road for inclusion in Python?

I hope this exchange was enough to attract sufficient interest from another
potential reviewer.  If it isn't, add your comments to 10 other patches, and
Martin will feel honor-bound to do something for you <0.9 wink>.

> The patch was designed to not interfere or duplicate existing code (it
> uses the output of the ndiff iterator) and I believe is very maintainable
> code.  I initially wrote it for showing log differences in HTML test
> reports (personal project) but have also found it useful at work for
> supplementing Doxygen documentation with source differences and also a
> utility script which generates an HTML report of all the source
> differences between two builds.  In addition I've set up CVS to use it so
> that I have frequent exposure to the results of my algorithms to make
> sure I never see quirks.

Without a detailed review, I agree it looks like very high-quality work.

For purposes of getting the patch reviewed, it would help most if you:

a) Generated an ordinary context-diff patch against current CVS Python.

and

b) Added a documentation patch.  It doesn't need to be LaTeX -- if you
   write new docs in plain text, the reviewers here are usually happy
   to add the sometimes-mysterious markup needed to play well with
   the Python doc-generation tools.



From martin at v.loewis.de  Thu Jun 10 01:22:57 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu Jun 10 01:23:01 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
In-Reply-To: <042201c44e89$cee72f40$0202a8c0@olidesk>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>
Message-ID: <40C7F031.20900@v.loewis.de>

Oliver Schoenborn wrote:
> This is a module I made to test a concept of finalization *not* based on
> __del__. I'm curious to find out if the techniques look like they could be
> implemented directly in the Python interpreter to lessen the burden on the
> user, which is why I post this here.

Yes, it could be implemented directly on the user. However, I notice
that the algorithm you implement has nothing to do with finalization.

Typically, the term finalization is associated with objects whose
life is about to end, i.e. objects which should cease to exist.

Python does provide finalization, and in a reliable way: the finalizer
is called before the object goes away, guaranteed.

What you want is a function that is called when the object goes of of
some scope. This is something completely different, as the object may
life long and prosper even after it goes out of scope. You have an
assertion

     assert sys.getrefcount(self) == 5

It is very easy to trigger that assertion, so I'm uncertain what
the intended meaning of that assertion is.

In summary: to avoid confusion, you should not use the term
"finalization" when talking about the mechanisms you have implemented
in the module.

Regards,
Martin


From sh at defuze.org  Thu Jun 10 08:43:49 2004
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Thu Jun 10 08:42:14 2004
Subject: [Python-Dev] Re: Empty keyword
In-Reply-To: <ca4elg$9o1$1@sea.gmane.org>
References: <ca1qme$5b9$1@sea.gmane.org> <ca4elg$9o1$1@sea.gmane.org>
Message-ID: <ca9kut$3el$1@sea.gmane.org>

Yeap.

I didn't see the difference. Of course, I will be more careful in the 
future.

I must say though that if was not clear to me, it might not be clear for 
some other people. It might sound obvious of course... but hey errare 
humanum est :)

Bye
- Sylvain

Terry Reedy wrote:
>>It miht sound stupid or useless, or maybe someone has already mentioned
>>it but sometimes I wish Python could provdie an "Empty" keyword like The
>>"None" one.
> 
> 
> None is not a keyword.  When it is, it will be more like a 'keyname'
> (unrebindable name).
> 
> 
>>if len(mylist) == 0:
> 
> 
> as someone else said, 'if not mylist:'
> 
> 
>>Anyhow, I must say that I didn't see any clear statement about what
>>should go here or there, I naively thought it would be the best place.
> 
> 
> My opinion: until you understand Python as it is and are contributing to
> its future development and have watched the development list for at least a
> couple of months (as I did), I think it better to stick to
> comp.lang.python.  After seven years with Python, I still restrain my
> posting here ;-)  In any case, some of the main developers also read c.l.p
> and will mention here things that need to be.
> 
> Terry J. Reedy
> 
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
> 


From oliver.schoenborn at utoronto.ca  Thu Jun 10 08:47:47 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Thu Jun 10 08:48:00 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>
	<40C7F031.20900@v.loewis.de>
Message-ID: <047001c44ee9$23c8b880$0202a8c0@olidesk>


----- Original Message ----- 
From: "Martin v. L?wis" <martin@v.loewis.de>


> Oliver Schoenborn wrote:
> > This is a module I made to test a concept of finalization *not* based on
> > __del__. I'm curious to find out if the techniques look like they could
be
> > implemented directly in the Python interpreter to lessen the burden on
the
> > user, which is why I post this here.
>
> Yes, it could be implemented directly on the user. However, I notice
> that the algorithm you implement has nothing to do with finalization.
> ...
> In summary: to avoid confusion, you should not use the term
> "finalization" when talking about the mechanisms you have implemented
> in the module.

Granted, it's not finalization in the technical sense but it is in the
logical sense: when the function returns, the try/finally calls a method
which must assume that the object will no longer be used after that (i.e. no
other references will be keeping the object alive past the function).

> Python does provide finalization, and in a reliable way: the finalizer
> is called before the object goes away, guaranteed.

The python docs are a bit confusing to me in this regard, so allow me to
quote a few section:

  From Python 2.3 docs:

      "An implementation is allowed to postpone garbage collection
      or omit it altogether -- it is a matter of implementation
      quality how garbage collection is implemented, as long as no
      objects are collected that are still reachable. (Implementation
      note: the current implementation uses a reference-counting
      scheme with (optional) delayed detection of cyclically linked
      garbage, which collects most objects as soon as they become
      unreachable, but is not guaranteed to collect garbage containing
      circular references. ...)"

>From Python 2.3 docs, section 3.1 of Library Ref:

    "Some objects contain references to external resources such
    as open files or windows. It is understood that these resources
    are freed when the object is garbage collected, but since garbage
collection is
    not guaranteed to happen, such objects also provide an explicit
    way to release the external resource, usually a close() method.
    Programs are strongly recommended to explicitly close such
    objects. The 'try...finally' statement provides a convenient way
    to do this."

>From section 3.3.1:

      __del__( self)

Called when the instance is about to be destroyed. .... It is not
guaranteed that __del__() methods are called for objects that
still exist when the interpreter exits.  ...x.__del__() ... is only
called when x's reference count reaches zero.

And finally, from 1.10 of "Extending and Embedding...":

"While Python uses the traditional reference counting implementation, it
also offers a cycle detector that works to detect reference cycles. This
allows applications to not worry about creating direct or indirect circular
references"

This seems to indicate that there are several situations to keep in mind:

1) __del__ is called automatically when reference count goes to zero; this
is independent of the presence of gc; however, standard doesn't garantee
that __del__ gets called for objects still alive when interpreter exits, so
for critical pieces of code (like releasing mutex locks), this could be
dangerous; plus the object is kept alive in the case of an exception, so
can't rely on its __del__ being called if exception is not caught.

2) the (optional) garbage collector handles the cases where reference count
never goes to zero due to cyclical refs involving at least one class with a
__del__ defined; however it is implementation-defined whether this exists
and if it does, when it does its job; so classes that have a __del__ are
unlikely to get freed by the gc if they are involved in a cyclical ref.

So it seems that having a __del__ is ok *most* of the time, and that if you
find a mem leak, verify if you have cyclical refs, and modify algorithm to
break cycle because gc won't be able to call __del__; however if an
exception gets thrown, you can't rely on __del__ getting called. Since
exceptions are so common, I have to conclude that you can never rely on
__del__ to free resources. Where am I wrong in this reasoning?

> What you want is a function that is called when the object goes of of
> some scope. This is something completely different, as the object may
> life long and prosper even after it goes out of scope.

> You have an assertion
>
>      assert sys.getrefcount(self) == 5
>
> It is very easy to trigger that assertion, so I'm uncertain what
> the intended meaning of that assertion is.

Was useful only during testing and has since been removed.

Thanks for the feedback!

Oliver


From dmgass at hotmail.com  Thu Jun 10 12:20:28 2004
From: dmgass at hotmail.com (Dan Gass)
Date: Thu Jun 10 12:20:36 2004
Subject: [Python-Dev] Side by Side Differencing Patch
Message-ID: <BAY18-F102AMqri5Gle0002d2d3@hotmail.com>

Tim,

>That said, I downloaded the zip file attached to your patch just now, and
>was delighted by the examples of its output you included.  I'd definitely
>use this!  OTOH, I'm not an HTML Guy, and unassigned myself -- I'm not the
>best person to review it.  I'm +1 on the concept, FWIW.
>
> > 1) Is this worthwhile functionality where it would be worth including it
> >    and supporting it in Python?
>
>Yes, I think so.  The closest alternative I know of is the HTML-ized
>diff'ing included in ViewCVS, which I believe also builds on difflib
>functions.  I like your output better, both because of the embedded "next
>difference" links and because of the intraline difference marking.

<clippedText/>

>For purposes of getting the patch reviewed, it would help most if you:
>
>a) Generated an ordinary context-diff patch against current CVS Python.
>
>and
>
>b) Added a documentation patch.  It doesn't need to be LaTeX -- if you
>    write new docs in plain text, the reviewers here are usually happy
>    to add the sometimes-mysterious markup needed to play well with
>    the Python doc-generation tools.

Based on your positive response I'll go ahead and regenerate the patch with 
the current CVS Python code and redo the differences.  This will allow me to 
address the issues discussed in the sourceforge patch (correctly handling 
files with no differences and improving the interface for dropping anchors) 
as well as a couple other really minor issues not documented anywhere.

I'd appreciate feedback from other interested parties before I go nuts on 
writing good user documentation for the Python manuals.  I hope there is an 
HTML guru interested in this as they may have better ideas for the HTML 
look, feel and functionality that may impact the interfaces I provide.  Who 
worked on ViewCVS?

Thanks for your positive feedback!
Dan Gass

_________________________________________________________________
Getting married? Find great tips, tools and the latest trends at MSN Life 
Events. http://lifeevents.msn.com/category.aspx?cid=married


From martin at v.loewis.de  Thu Jun 10 16:08:54 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu Jun 10 16:09:00 2004
Subject: [Python-Dev] Re: Empty keyword
In-Reply-To: <ca9kut$3el$1@sea.gmane.org>
References: <ca1qme$5b9$1@sea.gmane.org> <ca4elg$9o1$1@sea.gmane.org>
	<ca9kut$3el$1@sea.gmane.org>
Message-ID: <40C8BFD6.60605@v.loewis.de>

Sylvain Hellegouarch wrote:
> I didn't see the difference. Of course, I will be more careful in the 
> future.
> 
> I must say though that if was not clear to me, it might not be clear for 
> some other people. It might sound obvious of course...

It might not be obvious for Python users, and there is nothing wrong
with that.

However, it should be obvious (or atleast well-known) for people posting
to python-dev. Posters are expected to be familiar with the Python
interpreter internals, and will often verify claims in the source
before posting.

Regards,
Martin


From martin at v.loewis.de  Thu Jun 10 16:14:25 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu Jun 10 16:14:32 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
In-Reply-To: <047001c44ee9$23c8b880$0202a8c0@olidesk>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>
	<047001c44ee9$23c8b880$0202a8c0@olidesk>
Message-ID: <40C8C121.40809@v.loewis.de>

Oliver Schoenborn wrote:
>>Python does provide finalization, and in a reliable way: the finalizer
>>is called before the object goes away, guaranteed.
> 
> 
> The python docs are a bit confusing to me in this regard, so allow me to
> quote a few section:
> 
>   From Python 2.3 docs:
> 
>       "An implementation is allowed to postpone garbage collection
>       or omit it altogether -- it is a matter of implementation
>       quality how garbage collection is implemented, as long as no
>       objects are collected that are still reachable.

This is precisely what I said: the object is finalized before it
goes away. If it does not go away, it might not get finalized.

> So it seems that having a __del__ is ok *most* of the time, and that if you
> find a mem leak, verify if you have cyclical refs, and modify algorithm to
> break cycle because gc won't be able to call __del__; however if an
> exception gets thrown, you can't rely on __del__ getting called. Since
> exceptions are so common, I have to conclude that you can never rely on
> __del__ to free resources. Where am I wrong in this reasoning?

Yes, you are wrong. The Python language specification does not make
guarantees. However, specific implementations do make specific
guarantees beyond what the language specification guarantees.

Your proposed mechanism cannot be added to the Python language
specification because there might be Python implementations for
which the mechanism is difficult to implement.

Regards,
Martin


From oliver.schoenborn at utoronto.ca  Thu Jun 10 17:07:22 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Thu Jun 10 17:08:03 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>
	<047001c44ee9$23c8b880$0202a8c0@olidesk>
	<40C8C121.40809@v.loewis.de>
Message-ID: <00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>


From: "Martin v. L?wis" <martin@v.loewis.de>
> Oliver Schoenborn wrote:
> > So it seems that having a __del__ is ok *most* of the time, and that if
you
> > find a mem leak, verify if you have cyclical refs, and modify algorithm
to
> > break cycle because gc won't be able to call __del__; however if an
> > exception gets thrown, you can't rely on __del__ getting called. Since
> > exceptions are so common, I have to conclude that you can never rely on
> > __del__ to free resources. Where am I wrong in this reasoning?
>
> Yes, you are wrong. The Python language specification does not make
> guarantees. However, specific implementations do make specific
> guarantees beyond what the language specification guarantees.

Which means nothing because if I code in Python, code portability is a major
concern. Any aspects of the language that are not in the specification must
be avoided, so if specs don't guarantee s/m, no one in their right mind
would use that s/t.

> Your proposed mechanism cannot be added to the Python language
> specification because there might be Python implementations for
> which the mechanism is difficult to implement.

I can accept that only if there is something inherent to the technique which
exploits a non-specified aspect of the language. I can't think of any. Could
you be more specific about what aspect is not portable?

If it is portable, then since it works as-is in Python, it could be put into
the specs. At the very least, Python interpreter implementers who can't
implement right into the interpreter could provide it as a module, like it
is now (and as it would be anyways, so that the front end never changes, a
bit like weakref).

Oliver


From martin at v.loewis.de  Thu Jun 10 18:40:23 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu Jun 10 18:40:30 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
In-Reply-To: <00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>	<40C8C121.40809@v.loewis.de>
	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>
Message-ID: <40C8E357.8030107@v.loewis.de>

Oliver Schoenborn wrote:
> I can accept that only if there is something inherent to the technique which
> exploits a non-specified aspect of the language. I can't think of any. Could
> you be more specific about what aspect is not portable?

The idea that you can execute code at the end of a function to invoke
teardown operations, even in the presence of exceptions. That cannot be
done for Jython, AFAIK. Jython generates Java byte code from Python
source code, so there is no Python virtual machine anywhere.

> If it is portable, then since it works as-is in Python, it could be put into
> the specs. 

It doesn't work in Python. I believe your implementation also fails in
Jython (but didn't test).

Regards,
Martin


From dave at nullcube.com  Thu Jun 10 19:35:55 2004
From: dave at nullcube.com (Dave Harrison)
Date: Thu Jun 10 19:37:35 2004
Subject: [Python-Dev] python-dev archive searching ?
Message-ID: <20040610233555.GA15938@dave@alana.ucc.usyd.edu.au>

Hi all,

I've spent a bit of time looking for a way to search the python-dev
archives for topics, but I'm not having much success (unless I want to
trawl the archives by hand, month by month).

Is there something I'm missing here ?

cheers
Dave

From oliver.schoenborn at utoronto.ca  Thu Jun 10 19:40:49 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Thu Jun 10 19:41:00 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>	<40C8C121.40809@v.loewis.de>
	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>
	<40C8E357.8030107@v.loewis.de>
Message-ID: <04a701c44f44$5c02e300$0202a8c0@olidesk>

Martin,

From: "Martin v. L?wis" <martin@v.loewis.de>
> Oliver Schoenborn wrote:
> > I can accept that only if there is something inherent to the technique
which
> > exploits a non-specified aspect of the language. I can't think of any.
Could
> > you be more specific about what aspect is not portable?
>
> The idea that you can execute code at the end of a function to invoke
> teardown operations, even in the presence of exceptions. That cannot be
> done for Jython, AFAIK. Jython generates Java byte code from Python
> source code, so there is no Python virtual machine anywhere.

That's assuming that what you say below is true. The technique, shown in
scope.py attached to the first post to python-dev, is simple (and consists
in rebinding a function to a wrapper that puts a try/finally around the
original function, with some special behind-the-scenes stuff for what to
execute in the finally block). Scope.py works here, so I don't understand
your statement that the technique doesn't work in Python.

> > If it is portable, then since it works as-is in Python, it could be put
into
> > the specs.
>
> It doesn't work in Python. I believe your implementation also fails in
> Jython (but didn't test).

Unless we're talking cross-purpose here, scope.py shows it works at least in
Python downloaded from python.org. Again, could you please be more specific,
pointing to which part of the code is allegedly flawed or not portable?

Oliver


From oliver.schoenborn at utoronto.ca  Thu Jun 10 19:40:50 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Thu Jun 10 19:41:06 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>	<40C8C121.40809@v.loewis.de>
	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>
	<40C8E357.8030107@v.loewis.de>
Message-ID: <04a801c44f44$5e53b0d0$0202a8c0@olidesk>

Martin,

From: "Martin v. L?wis" <martin@v.loewis.de>
> Oliver Schoenborn wrote:
> > I can accept that only if there is something inherent to the technique
which
> > exploits a non-specified aspect of the language. I can't think of any.
Could
> > you be more specific about what aspect is not portable?
>
> The idea that you can execute code at the end of a function to invoke
> teardown operations, even in the presence of exceptions. That cannot be
> done for Jython, AFAIK. Jython generates Java byte code from Python
> source code, so there is no Python virtual machine anywhere.

That's assuming that what you say below is true. The technique, shown in
scope.py attached to the first post to python-dev, is simple (and consists
in rebinding a function to a wrapper that puts a try/finally around the
original function, with some special behind-the-scenes stuff for what to
execute in the finally block). Scope.py works here, so I don't understand
your statement that the technique doesn't work in Python.

> > If it is portable, then since it works as-is in Python, it could be put
into
> > the specs.
>
> It doesn't work in Python. I believe your implementation also fails in
> Jython (but didn't test).

Unless we're talking cross-purpose here, scope.py shows it works at least in
Python downloaded from python.org. Again, could you please be more specific,
pointing to which part of the code is allegedly flawed or not portable?

Oliver


From oliver.schoenborn at utoronto.ca  Thu Jun 10 19:46:38 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Thu Jun 10 19:46:50 2004
Subject: [Python-Dev] python-dev archive searching ?
References: <20040610233555.GA15938@dave@alana.ucc.usyd.edu.au>
Message-ID: <04c401c44f45$2c3c3ee0$0202a8c0@olidesk>

Dave, I did it the brute force way and created a python script that
downloads all the files using urllib2. From a unix shell you can then
trivially do your searches (after doing a massive gunzip and cat them all to
one file). I would have liked to find a tool that takes an archive file and
shows it in a threaded display. Oh well... Hopefully someone shows a more
convenient way to do the search. I can send you the script if you wish,
pretty basic though.
Oliver

----- Original Message ----- 
From: "Dave Harrison" <dave@nullcube.com>
To: <python-dev@python.org>
Sent: Thursday, June 10, 2004 7:35 PM
Subject: [Python-Dev] python-dev archive searching ?


> Hi all,
>
> I've spent a bit of time looking for a way to search the python-dev
> archives for topics, but I'm not having much success (unless I want to
> trawl the archives by hand, month by month).
>
> Is there something I'm missing here ?
>
> cheers
> Dave
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/oliver.schoenborn%40utoronto.ca
>


From tim.one at comcast.net  Thu Jun 10 19:49:54 2004
From: tim.one at comcast.net (Tim Peters)
Date: Thu Jun 10 19:50:08 2004
Subject: [Python-Dev] python-dev archive searching ?
In-Reply-To: <20040610233555.GA15938@dave@alana.ucc.usyd.edu.au>
Message-ID: <mailman.427.1086911408.6944.python-dev@python.org>

[Dave Harrison]
> I've spent a bit of time looking for a way to search the python-dev
> archives for topics, but I'm not having much success (unless I want to
> trawl the archives by hand, month by month).
>
> Is there something I'm missing here ?

Ain't easy.  Best trick I know is to add

    site:mail.python.org python-dev

to an ordinary Google search.



From greg at cosc.canterbury.ac.nz  Thu Jun 10 22:43:00 2004
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu Jun 10 22:43:26 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
In-Reply-To: <047001c44ee9$23c8b880$0202a8c0@olidesk>
Message-ID: <200406110243.i5B2h06T000355@cosc353.cosc.canterbury.ac.nz>

> Granted, it's not finalization in the technical sense but it is in
> the logical sense: when the function returns, the try/finally calls
> a method which must assume that the object will no longer be used
> after that

Maybe it should be called finally-ization. :-)

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

From tinuviel at sparcs.kaist.ac.kr  Thu Jun 10 23:31:03 2004
From: tinuviel at sparcs.kaist.ac.kr (Seo Sanghyeon)
Date: Thu Jun 10 23:41:08 2004
Subject: [Python-Dev] Re: python-dev archive searching ?
References: <38780.8878477246$1086910720@news.gmane.org>
Message-ID: <loom.20040611T052947-484@post.gmane.org>

Dave Harrison <dave <at> nullcube.com> writes:

> Hi all,
> 
> I've spent a bit of time looking for a way to search the python-dev
> archives for topics, but I'm not having much success (unless I want to
> trawl the archives by hand, month by month).
> 
> Is there something I'm missing here ?

Try http://search.gmane.org/ in group gmane.comp.python.devel.
It works very well.


From martin at v.loewis.de  Fri Jun 11 00:56:23 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri Jun 11 00:56:31 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
In-Reply-To: <04a701c44f44$5c02e300$0202a8c0@olidesk>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>	<40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de>
	<04a701c44f44$5c02e300$0202a8c0@olidesk>
Message-ID: <40C93B77.4060504@v.loewis.de>

Oliver Schoenborn wrote:
>>It doesn't work in Python. I believe your implementation also fails in
>>Jython (but didn't test).
> 
> 
> Unless we're talking cross-purpose here, scope.py shows it works at least in
> Python downloaded from python.org. Again, could you please be more specific,
> pointing to which part of the code is allegedly flawed or not portable?

Try running it with Jython 2.1, available from www.jython.org. I get the
error

    ImportError: no module named inspect

Regards,
Martin



From stephen at xemacs.org  Fri Jun 11 05:55:34 2004
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri Jun 11 05:55:49 2004
Subject: [Python-Dev] Re: Python CVS docs - libposixpath.tex is wrong file!
In-Reply-To: <200406081157.04430.fdrake@acm.org> (Fred L. Drake, Jr.'s
	message of "Tue, 8 Jun 2004 11:57:04 -0400")
References: <Pine.LNX.4.60.0406071653260.1573@bender.tc.fluke.com>
	<200406081127.38656.fdrake@acm.org>
	<200406081157.04430.fdrake@acm.org>
Message-ID: <877jue771l.fsf@tleepslib.sk.tsukuba.ac.jp>

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

    Fred> I think it's time for us to deal with getting CVS hosted
    Fred> somewhere.  As I understand it, we can host SSH-accessible
    Fred> CVS at XS4ALL; we'll need someone to host an anonymous
    Fred> pserver elsewhere.

FWIW, XEmacs has been very happy with SunSITE.dk, for about 3 years
now.  They have excellent bandwidth, and except for acts of God (two
lightning strikes that took the server down for a day each), we have
been most likely to find out about problems when SunSITE staff
apologizes for problems we didn't have.  They do not host all comers
like SF or savannah, so they can plan to stay within their resources.

Assuming they are willing to host Python at all, they would be happy
to set up a CVS mirror that only does anonymous pserver.  They offer
web resources, etc., but I don't know whether they would host a
SF-style tracker or Roundup.

If you like I would be willing to ask them, or you could directly
contact staff@sunsite.dk and tell them that stephen@xemacs.org sent
you.  I can't predict what their response would be, it would depend on
their current resource contraints and what Python would need.

Cheers

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From kiko at async.com.br  Fri Jun 11 12:29:02 2004
From: kiko at async.com.br (Christian Robottom Reis)
Date: Fri Jun 11 12:29:25 2004
Subject: [Python-Dev] LC_NUMERIC proto-PEP
In-Reply-To: <1085071967.1037.7.camel@spectrum.inescn.pt>
References: <40ABFA56.9050805@iinet.net.au>
	<1085071967.1037.7.camel@spectrum.inescn.pt>
Message-ID: <20040611162902.GA1894@async.com.br>


Hello there,

    Now that the LC_NUMERIC patch has gone in (and we're set to live
with it for the forseeable future) would it make sense to update the PEP
and have it added to the PEP list? It would at least count as
"complete" documentation for the change in the upcoming What's New
document.

How do people feel about this?

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331

From gjc at inescporto.pt  Fri Jun 11 13:58:07 2004
From: gjc at inescporto.pt (Gustavo J. A. M. Carneiro)
Date: Fri Jun 11 13:58:42 2004
Subject: [Python-Dev] tp_(get|set)attro? inheritance bug?
Message-ID: <1086976687.11716.52.camel@spectrum.inescn.pt>

  Documentation says, regarding tp_getattr:
?
This field is inherited by subtypes together with tp_getattro: a subtype
inherits both tp_getattr and tp_getattro from its base type when the
subtype's tp_getattr and tp_getattro are both NULL.
?

  Implementation disagrees, at least in cvs head, but the effect of the
bug (non-inheritance of tp_getattr) happens in 2.3.3.  Follow with me:

In function type_new (typeobject.c) line 1927:
	/* Special case some slots */
	if (type->tp_dictoffset != 0 || nslots > 0) {
		if (base->tp_getattr == NULL && base->tp_getattro == NULL)
			type->tp_getattro = PyObject_GenericGetAttr;
		if (base->tp_setattr == NULL && base->tp_setattro == NULL)
			type->tp_setattro = PyObject_GenericSetAttr;
	}
...later in the same function... line 

	/* Initialize the rest */
	if (PyType_Ready(type) < 0) {
		Py_DECREF(type);
		return NULL;
	}

Inside PyType_Ready(), line 3208:
	for (i = 1; i < n; i++) {
		PyObject *b = PyTuple_GET_ITEM(bases, i);
		if (PyType_Check(b))
			inherit_slots(type, (PyTypeObject *)b);
	}

Inside inherit_slots, line (3056):
	if (type->tp_getattr == NULL && type->tp_getattro == NULL) {
		type->tp_getattr = base->tp_getattr;
		type->tp_getattro = base->tp_getattro;
	}
	if (type->tp_setattr == NULL && type->tp_setattro == NULL) {
		type->tp_setattr = base->tp_setattr;
		type->tp_setattro = base->tp_setattro;
	}

  So, if you have followed through, you'll notice that type_new first
sets tp_getattro = GenericGetAttr, in case 'base' has neither tp_getattr
nor tp_getattro.
  So, you are thinking that there is no problem.  If base has
tp_getattr, that code path won't be execute.  The problem is with
multiple inheritance.  In type_new, 'base' is determined by calling
best_base().  But the selected base may not have tp_getattr, while
another might have.  In this case, setting tp_getattro based on
information from the wrong base precludes the slot from being inherited
from the right base.  This is happening in pygtk, unfortunately.

  One possible solution would be to move the first code block to after
the PyType_Ready() call.

-- 
Gustavo Jo?o Alves Marques Carneiro
<gjc@inescporto.pt> <gustavo@users.sourceforge.net>
The universe is always one step beyond logic.


From mike at skew.org  Fri Jun 11 18:01:56 2004
From: mike at skew.org (Mike Brown)
Date: Fri Jun 11 18:01:55 2004
Subject: [Python-Dev] mimetypes and _winreg
Message-ID: <200406112201.i5BM1uMR007733@chilled.skew.org>

I thought it would be nice to try to improve the mimetypes module by having 
it, on Windows, query the Registry to get the mapping of filename extensions 
to media types, since the mimetypes code currently just blindly checks 
posix-specific paths for httpd-style mapping files. However, it seems that the 
way to get mappings from the Windows registry is excessively slow in Python.

I'm told that the reason has to do with the limited subset of APIs that are 
exposed in the _winreg module. I think it is that EnumKey(key, index) is 
querying for the entire list of subkeys for the given key every time you call 
it. Or something. Whatever the situation is, the code I tried below is way 
slower than I think it ought to be.

Does anyone have any suggestions (besides "write it in C")? Could _winreg 
possibly be improved to provide an iterator or better interface to get the 
subkeys? (or certain ones? There are a lot of keys under HKEY_CLASSES_ROOT, 
and I only need the ones that start with a period). Should I file this as a
feature request?

Thanks

-Mike


from _winreg import HKEY_CLASSES_ROOT, OpenKey, EnumKey, QueryValueEx

i = 0
typemap = {}
try:
    while 1:
        subkeyname = EnumKey(HKEY_CLASSES_ROOT, i)
        try:
            subkey = OpenKey(HKEY_CLASSES_ROOT, subkeyname)
            if subkeyname[:1] == '.':
                data = QueryValueEx(subkey, 'Content Type')[0]
                print subkeyname, '=', data
                typemap[subkeyname] = data   # data will be unicode
        except EnvironmentError, WindowsError:
            pass
        i += 1
except WindowsError:
    pass


From theller at python.net  Fri Jun 11 18:20:55 2004
From: theller at python.net (Thomas Heller)
Date: Fri Jun 11 18:21:06 2004
Subject: [Python-Dev] mimetypes and _winreg
In-Reply-To: <200406112201.i5BM1uMR007733@chilled.skew.org> (Mike Brown's
	message of "Fri, 11 Jun 2004 16:01:56 -0600 (MDT)")
References: <200406112201.i5BM1uMR007733@chilled.skew.org>
Message-ID: <8yetlos8.fsf@python.net>

Mike Brown <mike@skew.org> writes:

> I thought it would be nice to try to improve the mimetypes module by having 
> it, on Windows, query the Registry to get the mapping of filename extensions 
> to media types, since the mimetypes code currently just blindly checks 
> posix-specific paths for httpd-style mapping files. However, it seems that the 
> way to get mappings from the Windows registry is excessively slow in Python.
>
> I'm told that the reason has to do with the limited subset of APIs that are 
> exposed in the _winreg module. I think it is that EnumKey(key, index) is 
> querying for the entire list of subkeys for the given key every time you call 
> it. Or something. Whatever the situation is, the code I tried below is way 
> slower than I think it ought to be.
>
> Does anyone have any suggestions (besides "write it in C")? Could _winreg 
> possibly be improved to provide an iterator or better interface to get the 
> subkeys? (or certain ones? There are a lot of keys under HKEY_CLASSES_ROOT, 
> and I only need the ones that start with a period).

See this post I made some time ago:
<http://mail.python.org/pipermail/python-dev/2004-January/042198.html>

> Should I file this as a feature request?

If you still think it should be changed in the core, you should work on
a patch.

Thomas


From martin at v.loewis.de  Fri Jun 11 19:33:49 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri Jun 11 19:34:17 2004
Subject: [Python-Dev] LC_NUMERIC proto-PEP
In-Reply-To: <20040611162902.GA1894@async.com.br>
References: <40ABFA56.9050805@iinet.net.au>
	<1085071967.1037.7.camel@spectrum.inescn.pt>
	<20040611162902.GA1894@async.com.br>
Message-ID: <40CA415D.7090502@v.loewis.de>

Christian Robottom Reis wrote:
> Hello there,
> 
>     Now that the LC_NUMERIC patch has gone in (and we're set to live
> with it for the forseeable future) would it make sense to update the PEP
> and have it added to the PEP list? It would at least count as
> "complete" documentation for the change in the upcoming What's New
> document.
> 
> How do people feel about this?

I don't like documentation inside PEPs. Documentation should live
inside the documentation.

Regards,
Martin


From kiko at async.com.br  Fri Jun 11 19:37:01 2004
From: kiko at async.com.br (Christian Robottom Reis)
Date: Fri Jun 11 19:37:12 2004
Subject: [Python-Dev] LC_NUMERIC proto-PEP
In-Reply-To: <40CA415D.7090502@v.loewis.de>
References: <40ABFA56.9050805@iinet.net.au>
	<1085071967.1037.7.camel@spectrum.inescn.pt>
	<20040611162902.GA1894@async.com.br> <40CA415D.7090502@v.loewis.de>
Message-ID: <20040611233701.GC17248@async.com.br>

On Sat, Jun 12, 2004 at 01:33:49AM +0200, "Martin v. L?wis" wrote:
> Christian Robottom Reis wrote:
> >Hello there,
> >
> >    Now that the LC_NUMERIC patch has gone in (and we're set to live
> >with it for the forseeable future) would it make sense to update the PEP
> >and have it added to the PEP list? It would at least count as
> >"complete" documentation for the change in the upcoming What's New
> >document.
> >
> >How do people feel about this?
> 
> I don't like documentation inside PEPs. Documentation should live
> inside the documentation.

Well, maybe I should have used the word "change rationale" instead of
documentation. In any case, the document describes the original problem
statement, potential solutions, and the process through which a solution
was devised. 

Is the general opinion it's not worth being published?

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331

From martin at v.loewis.de  Fri Jun 11 19:37:20 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri Jun 11 19:38:14 2004
Subject: [Python-Dev] Re: Python CVS docs - libposixpath.tex is wrong file!
In-Reply-To: <877jue771l.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <Pine.LNX.4.60.0406071653260.1573@bender.tc.fluke.com>	<200406081127.38656.fdrake@acm.org>	<200406081157.04430.fdrake@acm.org>
	<877jue771l.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <40CA4230.2070409@v.loewis.de>

Stephen J. Turnbull wrote:
> Assuming they are willing to host Python at all, they would be happy
> to set up a CVS mirror that only does anonymous pserver.  They offer
> web resources, etc., but I don't know whether they would host a
> SF-style tracker or Roundup.

I've tried to talk them into hosting the Python CVS. I found them
to be quite unresponsive, not helping me with the process of
transitioning the Python CVS to sunsite.dk. So I have given up.

> If you like I would be willing to ask them

Please do. Maybe you have more luck than myself.

Regards,
Martin




From martin at v.loewis.de  Fri Jun 11 19:44:15 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri Jun 11 19:44:22 2004
Subject: [Python-Dev] LC_NUMERIC proto-PEP
In-Reply-To: <20040611233701.GC17248@async.com.br>
References: <40ABFA56.9050805@iinet.net.au>
	<1085071967.1037.7.camel@spectrum.inescn.pt>
	<20040611162902.GA1894@async.com.br> <40CA415D.7090502@v.loewis.de>
	<20040611233701.GC17248@async.com.br>
Message-ID: <40CA43CF.7080001@v.loewis.de>

Christian Robottom Reis wrote:
> Well, maybe I should have used the word "change rationale" instead of
> documentation. In any case, the document describes the original problem
> statement, potential solutions, and the process through which a solution
> was devised. 
> 
> Is the general opinion it's not worth being published?

In general, such information is not useful. For those interested,
Misc/NEWS keeps track of all changes, but nobody will read through
all of them. People are more interested in how the version of Python
behaves that they use, and that should be documented.

Regards,
Martin


From dave at boost-consulting.com  Sat Jun 12 08:18:20 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat Jun 12 08:18:39 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function) scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>
	<40C7F031.20900@v.loewis.de>
	<047001c44ee9$23c8b880$0202a8c0@olidesk> <40C8C121.40809@v.loewis.de>
	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>
	<40C8E357.8030107@v.loewis.de>
Message-ID: <uacz9ufzn.fsf@boost-consulting.com>

"Martin v. L?wis" <martin@v.loewis.de> writes:

> Oliver Schoenborn wrote:
>> I can accept that only if there is something inherent to the technique which
>> exploits a non-specified aspect of the language. I can't think of any. Could
>> you be more specific about what aspect is not portable?
>
> The idea that you can execute code at the end of a function to invoke
> teardown operations, even in the presence of exceptions. That cannot be
> done for Jython, AFAIK. Jython generates Java byte code from Python
> source code, so there is no Python virtual machine anywhere.

I'm sure I missed something important along the way here, but the fact
that you can generate Java bytecode for Python's "finally" in Jython,
it seems to me, _proves_ that you can also generate code to that will
be executed at the end of a function even in the presence of
exceptions.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From martin at v.loewis.de  Sat Jun 12 08:36:48 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat Jun 12 08:36:54 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)
	scopes
In-Reply-To: <uacz9ufzn.fsf@boost-consulting.com>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>
	<40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de>
	<uacz9ufzn.fsf@boost-consulting.com>
Message-ID: <40CAF8E0.1030909@v.loewis.de>

David Abrahams wrote:
> I'm sure I missed something important along the way here, but the fact
> that you can generate Java bytecode for Python's "finally" in Jython,
> it seems to me, _proves_ that you can also generate code to that will
> be executed at the end of a function even in the presence of
> exceptions.

Certainly. However, I'm uncertain whether you find out, in this finally
block, what objects require this finally-ization. Part of this 
uncertainty comes from my failure to understand how the proposed
mechanism works in the first place - ie. what is the precise set of
objects that should be finally-ized. If any algorithm for such a
mechanism would need to find out what objects have been created while
the function was running, and invoke finally-ization on those, that
may not be possible to implement: you can't get hold of all objects
that have been created in Java, AFAIK (1). If it involves looking at
all local variables, it might be implementable, but might cause a
significant slowdown even if the feature is not used.

Regards,
Martin

(1) that is currently not possible in Python, either, but
it might be possible to change the interpreter to record the list
of young objects in the thread state.


From qrczak at knm.org.pl  Sat Jun 12 10:59:05 2004
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Sat Jun 12 10:59:15 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)
	scopes
In-Reply-To: <40CAF8E0.1030909@v.loewis.de>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>
	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>
	<40C8C121.40809@v.loewis.de>
	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>
	<40C8E357.8030107@v.loewis.de> <uacz9ufzn.fsf@boost-consulting.com>
	<40CAF8E0.1030909@v.loewis.de>
Message-ID: <1087052345.2032.156.camel@qrnik>

W li?cie z sob, 12-06-2004, godz. 14:36 +0200, "Martin v. L?wis"
napisa?:

> If it involves looking at
> all local variables, it might be implementable, but might cause a
> significant slowdown even if the feature is not used.

Not just inefficient but wrong: not all such objects should be
finalized. They can have references stored elsewhere.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From tjreedy at udel.edu  Sat Jun 12 14:02:59 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat Jun 12 14:03:09 2004
Subject: [Python-Dev] Re: Re: Object finalization for local (ie
	function)scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk><40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de><uacz9ufzn.fsf@boost-consulting.com>
	<40CAF8E0.1030909@v.loewis.de>
Message-ID: <cafggm$kk$1@sea.gmane.org>


"Martin v. Löwis" <martin@v.loewis.de> wrote in message
news:40CAF8E0.1030909@v.loewis.de...
> Certainly. However, I'm uncertain whether you find out, in this finally
> block, what objects require this finally-ization.

I brought up the same point on the parallel thread in c.l.p and got no
response.  As I remember, one way to create dangling pointers in C is for a
function to pass out of its scope a pointer to a local about to be freed.
I presume the same is true in C++.  To me, a main purpose of ref counting
is to know what *not* to release at function exit.

People who want more agressive cleanup on function exit could perhaps
develop a version of Python that calls a cyclic-junk finalizer *after*
locals are decrefed, as part of the execution of explicit or implicit
'return'.  The cyclic-junk finalizer could either be cyclic gc improved to
work with __del__ methods or a separate process that used the current cycle
detection apparatus to find candidates for processing.

Since most people neither need nor want the extra return overhead, this
should be a third-party add-on, a compilation option, or possibly a
built-in decoration like staticmethod.

My naive guess is that this would take a least a person-month.  I leave it
to *RAII-in-Python advocates to investigate further.

Terry J. Reedy

*Resource Aquisition Is Initialization,  in C++ -- because of auto
destruction of locals.




From martin at v.loewis.de  Sat Jun 12 14:51:05 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat Jun 12 14:51:14 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)
	scopes
In-Reply-To: <1087052345.2032.156.camel@qrnik>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>	<40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de>
	<uacz9ufzn.fsf@boost-consulting.com>	<40CAF8E0.1030909@v.loewis.de>
	<1087052345.2032.156.camel@qrnik>
Message-ID: <40CB5099.4010005@v.loewis.de>

Marcin 'Qrczak' Kowalczyk wrote:
>>If it involves looking at
>>all local variables, it might be implementable, but might cause a
>>significant slowdown even if the feature is not used.
> 
> 
> Not just inefficient but wrong: not all such objects should be
> finalized. They can have references stored elsewhere.

I understand that is the whole purpose of the requested feature:
to invoke a method on the object when a function completes,
regardless of whether there are still references to the object.

I cannot, in good faith, call this finalization.

Regards,
Martin


From garth at garthy.com  Sat Jun 12 15:16:20 2004
From: garth at garthy.com (Garth)
Date: Sat Jun 12 15:16:34 2004
Subject: [Python-Dev] mimetypes and _winreg
In-Reply-To: <8yetlos8.fsf@python.net>
References: <200406112201.i5BM1uMR007733@chilled.skew.org>
	<8yetlos8.fsf@python.net>
Message-ID: <40CB5684.2090609@garthy.com>

Thomas Heller wrote:

>Mike Brown <mike@skew.org> writes:
>
>  
>
>>I thought it would be nice to try to improve the mimetypes module by having 
>>it, on Windows, query the Registry to get the mapping of filename extensions 
>>to media types, since the mimetypes code currently just blindly checks 
>>posix-specific paths for httpd-style mapping files. However, it seems that the 
>>way to get mappings from the Windows registry is excessively slow in Python.
>>
>>I'm told that the reason has to do with the limited subset of APIs that are 
>>exposed in the _winreg module. I think it is that EnumKey(key, index) is 
>>querying for the entire list of subkeys for the given key every time you call 
>>it. Or something. Whatever the situation is, the code I tried below is way 
>>slower than I think it ought to be.
>>
>>Does anyone have any suggestions (besides "write it in C")? Could _winreg 
>>possibly be improved to provide an iterator or better interface to get the 
>>subkeys? (or certain ones? There are a lot of keys under HKEY_CLASSES_ROOT, 
>>and I only need the ones that start with a period).
>>    
>>
>
>See this post I made some time ago:
><http://mail.python.org/pipermail/python-dev/2004-January/042198.html>
>
>  
>
>>Should I file this as a feature request?
>>    
>>
>
>If you still think it should be changed in the core, you should work on
>a patch.
>
>Thomas
>
>  
>
I could file a patch if no one else is looking at it. The solution would 
be to use

RegEnumKeyEx and remove RegQueryInfoKey. This loses compatability with win16 which 
I guess is ok.

Garth


From raymond.hettinger at verizon.net  Sat Jun 12 04:38:56 2004
From: raymond.hettinger at verizon.net (Raymond Hettinger)
Date: Sat Jun 12 16:39:21 2004
Subject: [Python-Dev] heapq API
Message-ID: <002001c45058$b381f840$dab7958d@oemcomputer>

Please give feedback on two proposed new functions heappushpop(heap,
item)  and heapiter(heap).  Both are intended to make the API more
closely fit the way heaps are actually used and to take maximum
advantage of the implementation.
 
The first is equivalent to:
 
def heappushpop(heap, item):
    "Pushes the item onto the heap and then pops the smallest value"
    if not heap or item < heap[0]:
        return item
    return heapreplace(heap, item)
 
def heapiter(heap):
    "Return a destructive iterator over the heap's elements,
smallest-to-largest"
    try:
        while 1:
            yield heappop(heap)
    except IndexError:
        pass
 
 
 
Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20040612/75c74107/attachment.html
From oliver.schoenborn at utoronto.ca  Sat Jun 12 20:00:35 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Sat Jun 12 20:00:51 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk><40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de><uacz9ufzn.fsf@boost-consulting.com>
	<40CAF8E0.1030909@v.loewis.de>
Message-ID: <00be01c450d9$73e5c5a0$0202a8c0@olidesk>


From: "Martin v. L?wis" <martin@v.loewis.de>
> David Abrahams wrote:
> > I'm sure I missed something important along the way here, but the fact
> > that you can generate Java bytecode for Python's "finally" in Jython,
> > it seems to me, _proves_ that you can also generate code to that will
> > be executed at the end of a function even in the presence of
> > exceptions.
>
> Certainly. However, I'm uncertain whether you find out, in this finally
> block, what objects require this finally-ization. Part of this
> uncertainty comes from my failure to understand how the proposed
> mechanism works in the first place - ie. what is the precise set of
> objects that should be finally-ized.

Those objects that have "registered" themselves to the "cleaner" require
finally-ization. Hence, if no objects registered themselves, there is only
the overhead of an empty finally. The implementation details can worry about
how registration takes place, and who does the cleanup. In scope.py,
"registration" is handled by derivation from class NeedsFinalization -- 
which I can eventually rename so please let's not get stuck on terminology
at this stage. The cleaner is a function called ScopeGuardian.

> If any algorithm for such a
> mechanism would need to find out what objects have been created while
> the function was running, and invoke finally-ization on those, that
> may not be possible to implement: you can't get hold of all objects
> that have been created in Java, AFAIK (1).

The technique, as state above, does NOT require that.

> If it involves looking at
> all local variables, it might be implementable, but might cause a
> significant slowdown even if the feature is not used.

The technique, as state above, does NOT require that either.

Oliver




From oliver.schoenborn at utoronto.ca  Sat Jun 12 20:27:49 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Sat Jun 12 20:28:08 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>	<40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de>
	<04a701c44f44$5c02e300$0202a8c0@olidesk>
	<40C93B77.4060504@v.loewis.de>
Message-ID: <018d01c450dd$4448c230$0202a8c0@olidesk>

This never got sent, sorry, may help...

From: "Martin v. L?wis" <martin@v.loewis.de>
> Oliver Schoenborn wrote:
> >>It doesn't work in Python. I believe your implementation also fails in
> >>Jython (but didn't test).
> >
> >
> > Unless we're talking cross-purpose here, scope.py shows it works at
least in
> > Python downloaded from python.org. Again, could you please be more
specific,
> > pointing to which part of the code is allegedly flawed or not portable?
>
> Try running it with Jython 2.1, available from www.jython.org. I get the
> error
>
>     ImportError: no module named inspect

I checked on the jython site, the cvs repository, and the inspect module is
only partially implemented as a wrapper around the Python inspect module.
This problem you are having seems related to implementation, not technique.
The technique itself can be summarized as follows:

- Create a function that wraps a try/finally around the function of interest
- Make class whose instances need "cleanup" automatically tell the function
in which they were created (the "function of interest" above) that they
should be cleaned up upon function exit. This requires three things:
    - A new class in which that functionality can be encapsulated so the
user doesn't have to replicate it every time; just need to derive from it
    - Someone (the new class, or the wrapper) to create new function
attribute
    - When an object is instantiated, add ref to self to the new, special
function attribute, like Python allows. This itself requires:
        - Find function in which self was instantiated so that the function
attribute can be accessed

The inspect module is used in the very last task. The new function attribute
is only used as a convenient place to store information which is closely
tied to the function. But there are other possibilities. E.g. instead of
creating a function attribute, the ScopeGuardian could use a global stack of
list of objects. An instance of NeedsFinalization would use the top list of
the stack to add a reference to istelf there.

It looks like Jython has some parts of python lib implemented natively, some
borrowed, and some not implemented, based on need and manpower, so the fact
that the inspect module is not available hardly qualifies the technique as
"not working". If Jython doesn't use stack, and implementing in terms of
global var not feasible, *and* there is no other implementation possible in
Jython, then yeah, I agree, scope.py is not portable to Jython. However that
doesn't mean that the technique can't be implemented different in Python
interpreter and Jython interpreter.

Cheers,
Oliver


From martin at v.loewis.de  Sun Jun 13 04:02:13 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun Jun 13 04:02:21 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)scopes
In-Reply-To: <00be01c450d9$73e5c5a0$0202a8c0@olidesk>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk><40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de><uacz9ufzn.fsf@boost-consulting.com>	<40CAF8E0.1030909@v.loewis.de>
	<00be01c450d9$73e5c5a0$0202a8c0@olidesk>
Message-ID: <40CC0A05.8080504@v.loewis.de>

Oliver Schoenborn wrote:
> Those objects that have "registered" themselves to the "cleaner" require
> finally-ization. Hence, if no objects registered themselves, there is only
> the overhead of an empty finally. The implementation details can worry about
> how registration takes place, and who does the cleanup. In scope.py,
> "registration" is handled by derivation from class NeedsFinalization -- 
> which I can eventually rename so please let's not get stuck on terminology
> at this stage. The cleaner is a function called ScopeGuardian.

I'm still uncertain, though, as to what objects precisely should get
the cleanup calls: *All* objects that have registered with the cleaner,
or only some of them?

If all objects: what if nested function calls each have to-clean 
objects, and only the inner function returns? Why is it then useful
to also clean objects that where created in an outer function?

If only some objects: which ones?

Regards,
Martin


From martin at v.loewis.de  Sun Jun 13 04:10:12 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun Jun 13 04:10:20 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
In-Reply-To: <018d01c450dd$4448c230$0202a8c0@olidesk>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>	<40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de>	<04a701c44f44$5c02e300$0202a8c0@olidesk>	<40C93B77.4060504@v.loewis.de>
	<018d01c450dd$4448c230$0202a8c0@olidesk>
Message-ID: <40CC0BE4.9000609@v.loewis.de>

Oliver Schoenborn wrote:
> I checked on the jython site, the cvs repository, and the inspect module is
> only partially implemented as a wrapper around the Python inspect module.
> This problem you are having seems related to implementation, not technique.

Hmm. My claim was that your "portable" implementation is not, in fact,
portable. It might be possible to create a portable implementation that
works on different versions of CPython, as well as on versions of
Jython, but I haven't seen one.

> The technique itself can be summarized as follows:
> 
> - Create a function that wraps a try/finally around the function of interest
> - Make class whose instances need "cleanup" automatically tell the function
> in which they were created (the "function of interest" above) that they
> should be cleaned up upon function exit. This requires three things:

I claim that this might not be possible to do across different
implementations of Python. It relies on the ability to look at the local
variables of a caller of a function, and the Python language does not
guarantee support for such a mechanism.

> The inspect module is used in the very last task. The new function attribute
> is only used as a convenient place to store information which is closely
> tied to the function. But there are other possibilities. E.g. instead of
> creating a function attribute, the ScopeGuardian could use a global stack of
> list of objects. An instance of NeedsFinalization would use the top list of
> the stack to add a reference to istelf there.

In that implementation, how would you know how many objects to cleanup?

> It looks like Jython has some parts of python lib implemented natively, some
> borrowed, and some not implemented, based on need and manpower, so the fact
> that the inspect module is not available hardly qualifies the technique as
> "not working". If Jython doesn't use stack, and implementing in terms of
> global var not feasible, *and* there is no other implementation possible in
> Jython, then yeah, I agree, scope.py is not portable to Jython. However that
> doesn't mean that the technique can't be implemented different in Python
> interpreter and Jython interpreter.

Yes, but I have no reason to believe you an implementation is possible
until I have seen an implementation.

It might be that an implementation of the feature would be very
expensive even if not used, in which case the feature also would not
be acceptable for inclusion in Python.

However, this is probably the time to ask for a PEP that properly
describes the API and the semantics of the feature.

As to your original question: Can this be implemented in the C
interpreter directly? The answer is: yes, probably, depending
on what precisely the feature is.

Regards,
Martin


From oliver.schoenborn at utoronto.ca  Sun Jun 13 14:49:08 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Sun Jun 13 14:49:28 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>	<40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de>	<04a701c44f44$5c02e300$0202a8c0@olidesk>	<40C93B77.4060504@v.loewis.de>
	<018d01c450dd$4448c230$0202a8c0@olidesk>
	<40CC0BE4.9000609@v.loewis.de>
Message-ID: <026501c45177$1e571c80$0202a8c0@olidesk>

> > The technique itself can be summarized as follows:
> >
> > - Create a function that wraps a try/finally around the function of
interest
> > - Make class whose instances need "cleanup" automatically tell the
function
> > in which they were created (the "function of interest" above) that they
> > should be cleaned up upon function exit. This requires three things:
>
> I claim that this might not be possible to do across different
> implementations of Python. It relies on the ability to look at the local
> variables of a caller of a function, and the Python language does not
> guarantee support for such a mechanism.

Actually it doesn't. The file I showed in my first post to python-dev used
the stack, plus the knowledge of what name was given to a local variable,
but it didn't need to "look at the local variables"; it looked at one
variable, of known name. I have a second implementation, below, that
requires neither stack, nor local, and is faster.

> > tied to the function. But there are other possibilities. E.g. instead of
> > creating a function attribute, the ScopeGuardian could use a global
stack of
> > list of objects. An instance of NeedsFinalization would use the top list
of
> > the stack to add a reference to istelf there.
>
> In that implementation, how would you know how many objects to cleanup?

See my reply to your last post where you ask same question. However, as to
this new implementation, I paste it in at the end of the post.

> Yes, but I have no reason to believe you an implementation is possible
> until I have seen an implementation.

> It might be that an implementation of the feature would be very
> expensive even if not used, in which case the feature also would not
> be acceptable for inclusion in Python.

I'm doing some timing tests, I should have them tonight with a bit of luck.

> However, this is probably the time to ask for a PEP that properly
> describes the API and the semantics of the feature.

In time... I'd like a couple more opinions if possible. I'm surprised there
hasn't been more given how fundamental the problem of RAII is in Python.

Oliver

----------- New implementation for scope.py --------------
# Note: comments and tests are in module, but not reproduced here for space

import sys

def ScopeGuarded(func):
    return lambda *args, **kwargs: ScopeGuardian(func, *args, **kwargs)

_funcStack = []

class NeedsFinalization:
    def __init__(self):
        print '\n%s: being created' % repr(self)
        self.__finalized = False
        try: _funcStack[-1].append(self)
        except IndexError:
            raise RuntimeError, "Forgot to scope-guard function? "

    def finalizeMaster(self):
        print '%s: Finalize() being called' % repr(self)
        self._finalize()
        self.__finalized = True

    def __del__(self):
        try:
            problem = not self.__finalized
        except AttributeError:
            msg = '%s: NeedsFinalization.__init__ not called for %s' \
                  % (repr(self), self.__class__)
            raise RuntimeError, msg

        if not problem:
            print '%s: Finalized properly' % repr(self)
        else:
            print "Forgot to scope-guard function"

def ScopeGuardian(func, *args, **kwargs):
    try:
        scopedObjs = []
        _funcStack.append(scopedObjs)

        func(*args, **kwargs)
        print 'Scoped variables created during call to %s: %s' \
              % (func, scopedObjs)

    finally:
        _funcStack.pop()
        scopedObjs.reverse() # destroy in reverse order from creation
        for obj in scopedObjs:
            obj.finalizeMaster()


def testBasic():
    def func1():
        ok = TestFree()
        danger = TestDanger()

    # test when forget to use ScopeGuardian
    try:
        hello = func1()
        assert False, 'Expected exception not thrown!'
    except RuntimeError, msg:
        print 'Expected exception caught: ', msg

    func1 = ScopeGuarded(func1)
    func1()

    def func2(objType):
        dontKnow = objType()

    func2 = ScopeGuarded(func2)
    print "An RuntimeError exception will happen but be ignored: "
    func2(TestDangerNoInit)
    func2(TestDanger)

def testRecursive():
    def recurse(n):
        print 'Recurse(%s)' % n
        danger = TestDanger()
        ok = TestFree()
        if n>0:
            recurse(n-1)
        else:
            print 'recurse: Raising exception'
            raise RuntimeError, "pretend exception thrown during recursion"

    print '\nTesting that recursive does not work'
    recurse = ScopeGuarded(recurse)
    try:
        recurse(3)
        assert False, 'Expected exception not thrown!'
    except RuntimeError, msg:
        print 'Expected exception caught: ', msg

if __name__ == '__main__':

    class TestFree:
        def _finalize():
            raise RuntimeError, 'finalize() not supposed to be called'

    class TestDanger(NeedsFinalization):
        def __init__(self):
            NeedsFinalization.__init__(self)

        def _finalize(self):
            """Override this. If you class inherits from a
            class derived from NeedsFinalization, make sure to
            call parent.finalize()."""
            pass

    class TestDangerNoInit(NeedsFinalization):
        def __init__(self):
            pass
        def _finalize(self):
            pass

    testBasic()
    testRecursive()


From oliver.schoenborn at utoronto.ca  Sun Jun 13 14:54:49 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Sun Jun 13 14:55:03 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk><40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de><uacz9ufzn.fsf@boost-consulting.com>	<40CAF8E0.1030909@v.loewis.de>
	<00be01c450d9$73e5c5a0$0202a8c0@olidesk>
	<40CC0A05.8080504@v.loewis.de>
Message-ID: <026f01c45177$e71be6a0$0202a8c0@olidesk>

From: "Martin v. L?wis" <martin@v.loewis.de>
> Oliver Schoenborn wrote:
> > Those objects that have "registered" themselves to the "cleaner" require
> > finally-ization.
>
> I'm still uncertain, though, as to what objects precisely should get
> the cleanup calls: *All* objects that have registered with the cleaner,
> or only some of them?

I don't see why it wouldn't be all objects. You'll have to show me an
example for when that might be the case. Each object that has registered is
saying, "I need cleanup at exit of scope, because I should be the only one
left". If you don't clean it up you are not upholding your side of the
contract.

> If all objects: what if nested function calls each have to-clean
> objects, and only the inner function returns? Why is it then useful
> to also clean objects that where created in an outer function?

You'll have to show me some code before I can answer this.

Thanks,
Oliver


From oliver.schoenborn at utoronto.ca  Sun Jun 13 16:21:32 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Sun Jun 13 16:21:49 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>	<40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de><uacz9ufzn.fsf@boost-consulting.com>	<40CAF8E0.1030909@v.loewis.de><1087052345.2032.156.camel@qrnik>
	<40CB5099.4010005@v.loewis.de>
Message-ID: <028c01c45184$0676fa10$0202a8c0@olidesk>

From: "Martin v. L?wis" <martin@v.loewis.de>
> Marcin 'Qrczak' Kowalczyk wrote:
> >>If it involves looking at
> >>all local variables, it might be implementable, but might cause a
> >>significant slowdown even if the feature is not used.
> >
> >
> > Not just inefficient but wrong: not all such objects should be
> > finalized. They can have references stored elsewhere.
>
> I understand that is the whole purpose of the requested feature:
> to invoke a method on the object when a function completes,
> regardless of whether there are still references to the object.

Actually, what I am bringing forward does not address that case. The
implicit assumption is that the coder is sure that zero references to the
object will be left upon return from function. This is usually the case when
opening files, acquiring locks etc: if the coder wants proper cleanup, they
*have* to assume there are no references left. E.g.,

def func():
    ff = file('foo.txt', 'w')
    # do calls to various other functions
    ff.close()

The implicit assumption is that the close() is safe to do, i.e. that none of
the functions called between the open and the close stored references. If
there are refs stored and try to write, exception will occur, in section of
program totally unrelated to func(), certainly not expected behavior by the
coder.

I think it is safe to say that in cases where deterministic "finalization"
is desired, the coder doesn't want the object to be shared, and makes the
assumption that refs aren't being stored without their knowledge. If they
are, even current idioms, like the simplistic example above, are flawed.

Oliver


From oliver.schoenborn at utoronto.ca  Sun Jun 13 16:33:13 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Sun Jun 13 16:33:28 2004
Subject: [Python-Dev] Timing results for scope.py (was Re: Object
	finalization for local (ie function) scopes)
Message-ID: <02c501c45185$a681ef50$0202a8c0@olidesk>

I created two functions: one empty and one that opens a file and writes a
line and closes it. I ran once without scope-guard, and once with for each.

Short unscoped (us):   17.485010669
Short and scoped (us): 72.8106022384
Long unscoped (ms):    19.7690964161
Long and scoped (ms):  20.380344323

Here is the code with the tests:

import sys

def ScopeGuarded(func):
    return lambda *args, **kwargs: ScopeGuardian(func, *args, **kwargs)

_funcStack = []

def ScopeGuardian(func, *args, **kwargs):
    try:
        scopedObjs = []
        _funcStack.append(scopedObjs)
        func(*args, **kwargs)

    finally:
        _funcStack.pop()
        if scopedObjs != []:
            scopedObjs.reverse() # destroy in reverse order from creation
            for obj in scopedObjs:
                obj.finalizeMaster()


def testTimingShort(scoped=False):
    def fastFun():
        pass

    if scoped:
        fastFun = ScopeGuarded(fastFun)
    fastFun()


def testTimingLong(scoped=False):
    def slowFun():
        ff = file('asdfaf','w')
        ff.write('asdfaf')
        ff.close()

    if scoped:
        slowFun = ScopeGuarded(slowFun)
    slowFun()


def testTiming():
    from timeit import Timer
    tts =  Timer('testTimingShort()',     'from __main__ import
testTimingShort')
    ttss = Timer('testTimingShort(True)', 'from __main__ import
testTimingShort')
    ttl =  Timer('testTimingLong()',      'from __main__ import
testTimingLong')
    ttls = Timer('testTimingLong(True)',  'from __main__ import
testTimingLong')

    tms  = tts.timeit(10000)*100
    print "Short unscoped (us):  ", tms
    tmss = ttss.timeit(10000)*100
    print "Short and scoped (us):", tmss
    tml  = ttl.timeit(100)*10
    print "Long unscoped (ms):   ", tml
    tmls = ttls.timeit(100)*10
    print "Long and scoped (ms): ", tmls

    print "For long, scoped takes %s%% longer than unscoped" %
((tmls/tml-1)*100)


if __name__ == '__main__':
    testTiming()



From guido at python.org  Sun Jun 13 18:56:23 2004
From: guido at python.org (Guido van Rossum)
Date: Sun Jun 13 18:56:29 2004
Subject: [Python-Dev] VC 7.1 maintenance?
Message-ID: <200406132256.i5DMuNG28840@guido.python.org>

Is anybody maintaining the project files for Visual Studio 7.1?  In
recent checkins a new file was added (pystrtod.c) that isn't included
in the project file yet.  I hesitate to make the checkin myself
because I honestly don't understand which files are affected...

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

From doko at cs.tu-berlin.de  Sun Jun 13 20:26:15 2004
From: doko at cs.tu-berlin.de (Matthias Klose)
Date: Sun Jun 13 20:26:23 2004
Subject: [Python-Dev] Bug day outcome
Message-ID: <16588.61607.248947.902744@gargle.gargle.HOWL>

Barry Warsaw writes:
> +1 on Subversion too, but I still say the biggest problem is finding the
> cycles to set up and maintain the infrastructure.  It was an
> overwhelming task when we did it ourselves with a fraction of the user
> and developer community, and I was glad when we moved to SF.  If the
> Gforge installation Andrew was talking about can really be set up and
> babysat with as little effort as claimed, I think that's worth looking
> into.

you may want to check alioth.debian.org for a gforge setup supporting
either cvs, subversion or arch.

From tim.one at comcast.net  Sun Jun 13 21:19:01 2004
From: tim.one at comcast.net (Tim Peters)
Date: Sun Jun 13 21:19:13 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406132256.i5DMuNG28840@guido.python.org>
Message-ID: <mailman.464.1087175953.6944.python-dev@python.org>

[Guido]
> Is anybody maintaining the project files for Visual Studio 7.1?

Martin, Thomas and I all fiddle it when we notice it needs something.  I
view Martin as being the primary owner.

> In recent checkins a new file was added (pystrtod.c) that isn't
> included in the project file yet.

Fixed now.  I was running on Win98SE when that first got checked in, so
fiddled the VC6 project files (in PC/VC6).  Didn't have VC7.1 on that box.

> I hesitate to make the checkin myself because I honestly don't
> understand which files are affected...

Just "the usual":  used the GUI to add the new file to the pythoncore
project.

test_anydbm fails, I think because of some problem with Sleepycat bsddb
and/or our wrappers.

test_tcl doesn't get off the ground because it can't find tk84.dll.

All other "-u network,largefile" tests passed on WinXP, in both release and
debug builds (although I haven't downloaded the codec test files, so those
tests get skipped).

test_asynchat fails if you run it a *second* time, from .pyc/.pyo file
instead of from scratch.  This is a known problem with marshal not knowing
how to deal with a float infinity (don't ask).

test_zlib is much faster than it used to be <wink>.



From tim.one at comcast.net  Sun Jun 13 22:54:36 2004
From: tim.one at comcast.net (Tim Peters)
Date: Sun Jun 13 22:54:49 2004
Subject: [Python-Dev] Side by Side Differencing Patch
In-Reply-To: <BAY18-F102AMqri5Gle0002d2d3@hotmail.com>
Message-ID: <mailman.465.1087181689.6944.python-dev@python.org>

[Dan Gass]
> ...
> Who worked on ViewCVS?

I believe it was started by Greg Stein.  It's a project on SF too:

    http://viewcvs.sourceforge.net/

Browsing the repository, I'm not sure they actually use difflib, although
there's a fiddled copy of an old version of the code in the project.



From dan.gass at gmail.com  Sun Jun 13 22:58:10 2004
From: dan.gass at gmail.com (Dan Gass)
Date: Sun Jun 13 22:58:14 2004
Subject: [Python-Dev] HTML side by side diff patch 914575
Message-ID: <bc15ba2804061319582aa99ed1@mail.gmail.com>

Jim,

I appreciate your feedback, based on it I'm currently tinkering with
the HTML to figure out a better way.  Would you (and RH?) be
interested in reviewing it when I'm done to see if you can think of
any improvements?  After I'm done mocking up some HTML I'll implement
it and go ahead and resubmit the patch.

I think I figured out how to use tables to do what you want but still
have the look I want.  I'm also going to switch to utilize the viewCVS
color scheme.  Please note that some of your "next" alignment problems
may be caused by the text size setting.  I've seen certain text size
settings in Microsoft Internet Explorer that don't work as well.  I
typically select the smallest text size and never have problems.  I'm
hoping to make this a non-issue with what I'm going to propose.

Thanks,
Dan Gass

From bac at OCF.Berkeley.EDU  Sun Jun 13 23:55:16 2004
From: bac at OCF.Berkeley.EDU (Brett)
Date: Sun Jun 13 23:55:25 2004
Subject: [Python-Dev] python-dev Summary for 2004-05-01 through 2004-05-31
	[draft]
Message-ID: <A55FEE38-BDB6-11D8-AF94-0003931A4158@ocf.berkeley.edu>

Thanks to a change in the IMAP server used for my email I have switched 
to Apple Mail to do this summary.  May have missed some threads, but if 
I did miss anything I will get to them in the next summary.

I probably won't get to sending out this summary until the latter half 
of next week, so no huge rush on corrections.

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

Summary Announcements
=====================
The Spring quarter is now finished for me, so hopefully over the summer 
I can pull off a semi-monthly summaries again (work permitting).

2.3.4 was released during the coverage time of this summary.  Everyone 
should upgrade if possible to this bugfix release.

2.4a should be ready by mid-July.

The email server I use (not under my control) decided to change their 
IMAP server.  Unfortunately it is not playing nicely with Thunderbird 
or the mbox format, so I am being forced to use Apple Mail in order to 
delete emails.  Since I am not used to Mail's threading I may have 
missed some threads.  If I did, sorry about that and they will be 
covered in the next summary.

Summaries
=========
-----------------------------
Generator expressions are in!
-----------------------------
Generator expressions have been checked in.  They are currently using 
late bindings (see the `last summary`_ for an explanation of what that 
means).  If using late binding semantics doesn't work for you, do 
express your opinion since it can be changed before the beta is 
released.

Contributing threads:
   - `PEP 289 - Generator Expressions 
<http://mail.python.org/pipermail/python-dev/2004-May/044684.html>`__
   - `PEP 289 - Generator Expressions - Let's Move For ward 
<http://mail.python.org/pipermail/python-dev/2004-May/044643.html>`__

------------------------------------------
Following the docs, not the implementation
------------------------------------------
What happens if you rely on an implementation when the documentation 
explicitly states the semantics in another way?  Well, "you will pay 
for your sin in a special kind of hell set aside for people who take 
the implementation as the spec" according to Guido.  Some things in 
CPython go against the spec for performance reasons, but there is 
nothing stopping from it being changed at another point to more closely 
follow the spec.

Contributing threads:
   - `Passing compile(...,'exec') code to 'eval' 
<http://mail.python.org/pipermail/python-dev/2004-May/044683.html>`__

---------------------------------------------
What you need to get a module into the stdlib
---------------------------------------------
In order to prevent the stdlib from getting bloated with unneeded 
modules, new ones need to have seen use "in the field", as Guido put 
it.

Contributing threads:
   - `New Subscriber 
<http://mail.python.org/pipermail/python-dev/2004-May/044709.html>`__

---------------------
2.3.4 is out the door
---------------------
Python 2.3.4 has been released.  Being a bugfix there are no new 
features.  It is recommended that everyone upgrade to this version.

Contributing threads:
   - `Python 2.3.4 schedule 
<http://mail.python.org/pipermail/python-dev/2004-May/044661.html>`__
   - `release23-maint tree closed for 2.3.4rc1 
<http://mail.python.org/pipermail/python-dev/2004-May/044771.html>`__
   - `Python 2.3.4, release candidate 1 - BUG FIX 
<http://mail.python.org/pipermail/python-dev/2004-May/044854.html>`__
   - `python 2.3.4 delayed for a week 
<http://mail.python.org/pipermail/python-dev/2004-May/044921.html>`__
   - `2.3.4 release this thursday 
<http://mail.python.org/pipermail/python-dev/2004-May/044954.html>`__
   - `ELEASED Python 2.3.4 (final) 
<http://mail.python.org/pipermail/python-dev/2004-May/044984.html>`__

-----------------------
IPv6 for Windows in 2.4
-----------------------
For those of you wanting IPv6 support on Windows in the binary build, 
you will get in 2.4 .  The reason it isn't in 2.3.x is that the branch 
is compiled with VC 6 which can only compile in IPv6 support with a 
separate SDK.  VC 7, on the other hand, does not have this issue.

Contributing threads:
   - `IPv6 support in Win binary again 
<http://mail.python.org/pipermail/python-dev/2004-May/044779.html>`__

-----------------------
cookielib in the stdlib
-----------------------
A module named cookielib was added to the stdlib to allow transparent 
handling of cookies for modules such as urllib2.

Contributing threads:
   - `cookielib module in 2.4? 
<http://mail.python.org/pipermail/python-dev/2004-May/044785.html>`__
   - `cookielib 
<http://mail.python.org/pipermail/python-dev/2004-May/045015.html>`__

------------------------
cmp doesn't call __cmp__
------------------------
It was pointed out that calling ``cmp(x,x)``` does not call 
``x.__cmp__(x)`` but instead uses PyObject_RichCompareBool().  The 
issue with this is that PyObject_RichCompareBool() has a short-circuit 
for when the object being compared is the same, thus skipping a 
possible call to x.__cmp__ and saving some time.

This can be an issue, though, if you want something other than True or 
False to be returned.  Basically what came out of this thread was that 
C functions can short-circuit comparisons so be careful if you want to 
make sure that __cmp__ is called; use '==' and the other comparison 
operators instead.

Contributing threads:
   - `cmp(x,x) 
<http://mail.python.org/pipermail/python-dev/2004-May/044885.html>`__

----------------------------------
Posssible improvements to import.c
----------------------------------
Tim Peters asked if anyone knew the working details of import.c; no one 
spoke up.  The question was brought up because Tim would like to see 
failed imports not lead to mangled modules being in sys.modules and 
thus being considered properly imported.  The suggestion of also 
handling circular imports came up as well.

Contributing threads:
   - `import.c 
<http://mail.python.org/pipermail/python-dev/2004-May/044998.html>`__


From guido at python.org  Sun Jun 13 23:57:52 2004
From: guido at python.org (Guido van Rossum)
Date: Sun Jun 13 23:57:59 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: Your message of "Sun, 13 Jun 2004 21:19:01 EDT."
	<200406140120.i5E1KDs28969@guido.python.org> 
References: <200406140120.i5E1KDs28969@guido.python.org> 
Message-ID: <200406140357.i5E3vqC29145@guido.python.org>

> [Guido]
> > Is anybody maintaining the project files for Visual Studio 7.1?

[Tim]
> Martin, Thomas and I all fiddle it when we notice it needs
> something.  I view Martin as being the primary owner.
> 
> > In recent checkins a new file was added (pystrtod.c) that isn't
> > included in the project file yet.
> 
> Fixed now.  I was running on Win98SE when that first got checked in,
> so fiddled the VC6 project files (in PC/VC6).  Didn't have VC7.1 on
> that box.

Thanks!

> > I hesitate to make the checkin myself because I honestly don't
> > understand which files are affected...
> 
> Just "the usual": used the GUI to add the new file to the pythoncore
> project.

Something I did to the project in response to some insistent messages
at startup seems to have touched every single .proj file, which is one
reason why I was hesitant to check those changes in.

> test_anydbm fails, I think because of some problem with Sleepycat
> bsddb and/or our wrappers.
> 
> test_tcl doesn't get off the ground because it can't find tk84.dll.

Known problem, goes away when you install it.

> All other "-u network,largefile" tests passed on WinXP, in both
> release and debug builds (although I haven't downloaded the codec
> test files, so those tests get skipped).
> 
> test_asynchat fails if you run it a *second* time, from .pyc/.pyo
> file instead of from scratch.  This is a known problem with marshal
> not knowing how to deal with a float infinity (don't ask).

So is someone going to fix it?

> test_zlib is much faster than it used to be <wink>.

There are a few other tests that are very slow, I believe test_thread
is one.

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

From martin at v.loewis.de  Mon Jun 14 00:18:18 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 14 00:18:23 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)scopes
In-Reply-To: <026f01c45177$e71be6a0$0202a8c0@olidesk>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk><40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de><uacz9ufzn.fsf@boost-consulting.com>	<40CAF8E0.1030909@v.loewis.de>	<00be01c450d9$73e5c5a0$0202a8c0@olidesk>	<40CC0A05.8080504@v.loewis.de>
	<026f01c45177$e71be6a0$0202a8c0@olidesk>
Message-ID: <40CD270A.8000208@v.loewis.de>

Oliver Schoenborn wrote:
>>I'm still uncertain, though, as to what objects precisely should get
>>the cleanup calls: *All* objects that have registered with the cleaner,
>>or only some of them?
> 
> 
> I don't see why it wouldn't be all objects. You'll have to show me an
> example for when that might be the case. Each object that has registered is
> saying, "I need cleanup at exit of scope, because I should be the only one
> left". If you don't clean it up you are not upholding your side of the
> contract.

Consider this example, where X is a class that needs finally-ization,
and f and g are functions that participate in the protocol:

def f():
   a = X()
   g()
   a.do_something()

def g():
   b = X()

Now, when f starts, an X instance is registered with the cleaner,
and this is assigned to the local variable a. Then g is invoked.
This creates another X instance that is also registered with the
cleaner. Then g returns, and all objects registered with the
cleaner are finally-ized. At the moment, there are two objects
registered with the cleaner, so they are both finally-ized.

Then, g returns, and f tries to use the objects stored in a.
However, that object already has been finally-ized, so the object
is no longer functional.

I doubt this is the intended semantics, but I don't know what
the intended semantics is instead.

Regards,
Martin


From martin at v.loewis.de  Mon Jun 14 00:23:21 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 14 00:23:26 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)scopes
In-Reply-To: <028c01c45184$0676fa10$0202a8c0@olidesk>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk>	<40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de><uacz9ufzn.fsf@boost-consulting.com>	<40CAF8E0.1030909@v.loewis.de><1087052345.2032.156.camel@qrnik>	<40CB5099.4010005@v.loewis.de>
	<028c01c45184$0676fa10$0202a8c0@olidesk>
Message-ID: <40CD2839.60704@v.loewis.de>

Oliver Schoenborn wrote:
> Actually, what I am bringing forward does not address that case. The
> implicit assumption is that the coder is sure that zero references to the
> object will be left upon return from function. 

Hmm. Assumptions are irrelevant for language semantics specification, 
unless they can be proven correct. It is very easy to come up with
examples where the assumption is not met. I'd like to know what the
semantics of your proposed mechanism is before I can understand in what
cases it is useful.

In the particular case of Python, there is *no* guarantee that there
are zero references to an object when the function returns, as the
object may be referred-to in a traceback.

> I think it is safe to say that in cases where deterministic "finalization"
> is desired, the coder doesn't want the object to be shared, and makes the
> assumption that refs aren't being stored without their knowledge. If they
> are, even current idioms, like the simplistic example above, are flawed.

Your idiom is flawed, as you need to consider the case of exceptions.
The Python idiom really reads this way:

def func():
     ff = file('foo.txt', 'w')
     try:
       # do calls to various other functions
     finally:
       ff.close()

Regards,
Martin


From martin at v.loewis.de  Mon Jun 14 00:26:41 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 14 00:26:47 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406140357.i5E3vqC29145@guido.python.org>
References: <200406140120.i5E1KDs28969@guido.python.org>
	<200406140357.i5E3vqC29145@guido.python.org>
Message-ID: <40CD2901.1030008@v.loewis.de>

Guido van Rossum wrote:
>>test_asynchat fails if you run it a *second* time, from .pyc/.pyo
>>file instead of from scratch.  This is a known problem with marshal
>>not knowing how to deal with a float infinity (don't ask).
> 
> 
> So is someone going to fix it?

Yes. I'll back-out #957240.

Regards,
Martin


From python at rcn.com  Sun Jun 13 12:29:05 2004
From: python at rcn.com (Raymond Hettinger)
Date: Mon Jun 14 00:29:59 2004
Subject: [Python-Dev] HTML side by side diff patch 914575
In-Reply-To: <bc15ba2804061319582aa99ed1@mail.gmail.com>
Message-ID: <003201c45163$8bad0240$7e32c797@oemcomputer>

> I appreciate your feedback, based on it I'm currently tinkering with
> the HTML to figure out a better way.  Would you (and RH?) be
> interested in reviewing it when I'm done to see if you can think of
> any improvements?  

Yes.

If you can, get it in soon to avoid getting to close to the alpha
release date.



> I think I figured out how to use tables to do what you want but still
> have the look I want.  I'm also going to switch to utilize the viewCVS
> color scheme.  Please note that some of your "next" alignment problems
> may be caused by the text size setting.  I've seen certain text size
> settings in Microsoft Internet Explorer that don't work as well.  I
> typically select the smallest text size and never have problems.  I'm
> hoping to make this a non-issue with what I'm going to propose.

Please segregate all of this stuff in a single section devoted to
configuration and make it easy to change without affecting the rest of
the implementation logic.


Raymond



From python at rcn.com  Sun Jun 13 13:02:46 2004
From: python at rcn.com (Raymond Hettinger)
Date: Mon Jun 14 01:03:42 2004
Subject: [Python-Dev] RE: [Python-checkins] python/dist/src/Lib asyncore.py,
	1.51, 1.52
In-Reply-To: <E1BZjYT-0000jo-2z@sc8-pr-cvs1.sourceforge.net>
Message-ID: <003b01c45168$4002f200$7e32c797@oemcomputer>

> ! def loop(timeout=30.0, use_poll=False, map=None, count=1e309):

Would sys.maxint have sufficed?


Raymond


From Paul.Moore at atosorigin.com  Mon Jun 14 05:17:58 2004
From: Paul.Moore at atosorigin.com (Moore, Paul)
Date: Mon Jun 14 05:18:05 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
Message-ID: <16E1010E4581B049ABC51D4975CEDB8803060EE1@UKDCX001.uk.int.atosorigin.com>

From: Oliver Schoenborn
>> However, this is probably the time to ask for a PEP that properly
>> describes the API and the semantics of the feature.

> In time... I'd like a couple more opinions if possible. I'm
> surprised there hasn't been more given how fundamental the problem
> of RAII is in Python.

It's not at all clear that there *is* a "problem of RAII" in Python.
Regardless, you may want to look at PEP 310, and the (extensive)
threads on python-dev which it spawned, for an alternative view of
the issue.

>From my perspective, the RAII idiom is a very nice approach in C++,
but it's not at all clear if it can be made to translate cleanly into
Python, for fundamental semantic reasons (C++ deallocates on scope
exit, regardless of outstanding references, which creates the issue of
dangling reference, but makes RAII possible).

The things I like about RAII:

1. Resource management is concentrated in one place, the creation of
   the object. (OK, the object's class definition needs to contain the
   acquisition and release code, but that's normal encapsulation, IMO).
2. First-in, last-out ordering is enforced by the scope rules of the
   language.
3. Timing issues over windows where interrupts can result in acquired
   resources not being released, or partially-acquired resources being
   released, are avoided by the language's semantics of initialisation.

PEP 310 addresses points (1) and (3) - although (3) is only alluded to
in the "Implementation notes" section, and isn't clearly stated as a
required feature of the construct in the main PEP body.

Point (2) is the one that often causes code to look most "messy". Nested
try/finally (or PEP 310 with) blocks can obscure code structure. Consider

    lock.acquire()
    try:
        f = open(...)
        try:
            something_else.reserve()
            try:
                # The real code goes here!
            finally:
                something_else.release()
        finally:
            f.close()
    finally:
        lock.release()

However, the general consensus seems to be (a) that such code needs
refactoring into separate functions, each of which only acquires a single
resource, and (b) that if you *really* need to acquire 3 resources like
this, you can write a user-defined class which encapsulates this need
as a "combined" resource:

    class StuffINeed:
        "Missing code to handle failures during __enter__ or __exit__"
        def __init__(self, lock, something_else):
            self.lock = lock
            self.something_else = something_else
            self.f = None
        def __enter__(self):
            "PEP 310 method"
            self.lock.acquire()
            self.f = open(...)
            self.something_else.reserve()
        def __exit__(self):
            "PEP 310 method"
            self.something_else.release()
            self.f.close()
            self.lock.release()

[Because of the "Missing code..." comment, a generalised version of such
a class may be a useful addition to the standard library in combination
with PEP 310]

Sorry - that went on longer than anticipated. To summarise, I think you
should consider whether PEP 310 is what you need (it's probably mode
Pythonic than overloading __del__ the way C++ does), and if so, put your
energy into assisting the progress of that PEP.

Paul.


__________________________________________________________________________
This e-mail and the documents attached are confidential and intended 
solely for the addressee; it may also be privileged. If you receive this 
e-mail in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group 
liability cannot be triggered for the message content. Although the 
sender endeavours to maintain a computer virus-free network, the sender 
does not warrant that this transmission is virus-free and will not be 
liable for any damages resulting from any virus transmitted.
__________________________________________________________________________

From mwh at python.net  Mon Jun 14 06:40:01 2004
From: mwh at python.net (Michael Hudson)
Date: Mon Jun 14 06:40:09 2004
Subject: [Python-Dev] RE: [Python-checkins] python/dist/src/Lib
	asyncore.py, 1.51, 1.52
In-Reply-To: <003b01c45168$4002f200$7e32c797@oemcomputer> (Raymond
	Hettinger's message of "Sun, 13 Jun 2004 13:02:46 -0400")
References: <003b01c45168$4002f200$7e32c797@oemcomputer>
Message-ID: <2m659ubeym.fsf@starship.python.net>

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

>> ! def loop(timeout=30.0, use_poll=False, map=None, count=1e309):
>
> Would sys.maxint have sufficed?

Possibly :-) Josiah said he had a patch that didn't use floating point
infinities, but I don't think he's offered it up yet.

Cheers,
mwh

-- 
  I'm okay with intellegent buildings, I'm okay with non-sentient
  buildings. I have serious reservations about stupid buildings.
     -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year)

From guido at python.org  Mon Jun 14 10:15:38 2004
From: guido at python.org (Guido van Rossum)
Date: Mon Jun 14 10:15:46 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: Your message of "Mon, 14 Jun 2004 06:26:41 +0200."
	<40CD2901.1030008@v.loewis.de> 
References: <200406140120.i5E1KDs28969@guido.python.org>
	<200406140357.i5E3vqC29145@guido.python.org> 
	<40CD2901.1030008@v.loewis.de> 
Message-ID: <200406141415.i5EEFcm30116@guido.python.org>

[Tim]
> >>test_asynchat fails if you run it a *second* time, from .pyc/.pyo
> >>file instead of from scratch.  This is a known problem with marshal
> >>not knowing how to deal with a float infinity (don't ask).

[Guido]
> > So is someone going to fix it?

[Martin]
> Yes. I'll back-out #957240.

Surely there was a less drastic way to fix that?  sys.maxint is plenty
for an "infinite" timeout...

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

From guido at python.org  Mon Jun 14 10:31:06 2004
From: guido at python.org (Guido van Rossum)
Date: Mon Jun 14 10:32:33 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: Your message of "Sun, 13 Jun 2004 20:57:52 PDT."
Message-ID: <200406141431.i5EEV6f30289@guido.python.org>

Another question about the VS7.1 project files: these are XML text,
but they seem to be checked in as binary, therefore CVS won't even
attempt merges.  Is there a reason they can't be marked as text?
Surely the old VC 6.0 reason for this is no longer valid now it's XML?

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

From theller at python.net  Mon Jun 14 10:57:44 2004
From: theller at python.net (Thomas Heller)
Date: Mon Jun 14 10:58:44 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406141431.i5EEV6f30289@guido.python.org> (Guido van
	Rossum's message of "Mon, 14 Jun 2004 07:31:06 -0700")
References: <200406141431.i5EEV6f30289@guido.python.org>
Message-ID: <u0xe89w7.fsf@python.net>

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

> Another question about the VS7.1 project files: these are XML text,
> but they seem to be checked in as binary, therefore CVS won't even
> attempt merges.  Is there a reason they can't be marked as text?
> Surely the old VC 6.0 reason for this is no longer valid now it's XML?

Yes it is: MSVC only accepts them if they have \r\n line separators.

Thomas


From noamr at myrealbox.com  Sat Jun 12 20:44:24 2004
From: noamr at myrealbox.com (Noam Raphael)
Date: Mon Jun 14 11:00:36 2004
Subject: [Python-Dev] An ability to specify start and length of slices
Message-ID: <40CBA368.2000107@myrealbox.com>

Ok, I quit...

Thank you for your serious consideration of my proposal and for your 
suggestions!
I think that, according to Duncan Booth's suggestion, I will write, for 
my own use, a function which gets start and length and returns a slice.
Even though it wasn't accepted, making the patch and participating in 
the discussion was quite fun. And don't worry, I will continue to use 
Python - it's still the best computer language I know...

Thanks again,
Noam

From noamr at myrealbox.com  Sat Jun 12 20:48:11 2004
From: noamr at myrealbox.com (Noam Raphael)
Date: Mon Jun 14 11:00:42 2004
Subject: [Python-Dev] pydoc improvements
Message-ID: <40CBA44B.7020807@myrealbox.com>

Hello,

I've made a few improvements to the pydoc module. I've tried to deliver 
them to Ka-Ping Yee, but it seems that the e-mail wasn't transferred, so 
here I present them to python-dev, including Ping. I hope they will be 
reviewed and, if found to be appropriate, accepted.

Pretty-Printed Source Code
==========================
   Many times, in order to understand exactly what a function does, I'm 
interested in its source code. This is especially true for Python, 
because of its readability. So I made pydoc produce, along with the HTML 
documentation of a module, a highlighted source code of the module, 
interlinked with its documentation.
   I added to the HTMLDoc class a new method, sourcemodule (you may think
of a better name). It gets a filename and a few more parameters, and
returns the pretty-printed source code, in HTML format. Class and method
definitions are links to the description of them in the generated
module documentation. I also made class and function definitions in the
module documentation link to their definition in the source code.
   I've changed the second link on the right-top of a module
documentation to point to the HTML source instead of the original file,
because I think usually people are interested in seeing the code in
their browser, not in downloading it. In case they are interesting in
downloading it, I added a link called "download <filename>" to the HTML 
source, so people can click it and hopefully get the pure source code.
   The file name of the HTML source code is "<module name>-source.html".
It is now generated automatically along with the "<module name>.html",
and is served by the HTTP server.

Public and Private
==================
   Public attributes are defined by the current pydoc version as 
attributes whose name doesn't start with an underscore, or, for module 
attributes where __all__ is defined, attributes which appear in __all__.
   Currently pydoc doesn't show private objects at all. This is usually
what people want, but sometimes, when they are interested in what the 
module really does (for example when they want to define a subclass), 
they may want to view the documentation for private objects too. So I 
added a link to the module documentation header, which alternates 
between "Show Private" and "Hide Private", and shows or hides private 
attributes - both module attributes and class methods. To accomplish 
this, I defined two alternative style sheets: one which shows private 
attributes and one which doesn't. The "Show/Hide Private" link uses 
javascript to switch between these two styles. (The style can also be 
selected by a menu in the Mozilla browser.) I used a cookie to save the 
user's prefered style - if I hadn't, the style would've returned to the 
default every time a new documentation page is opened. The produces HTML 
is standard-compliant, to my knowledge, and works with both Mozilla and 
IE. The style-switching link doesn't work in konqueror, so one using it 
won't be able to see private attributes - not too bad.
   Many modules contain objects imported from other modules. Usually
these are for the module's own use, and the module's user isn't 
interested in them. These are not even private - I don't think anyone 
will want to see their documentation. In the current version of pydoc, 
these are filtered by calling inspect.getmodule. This raises two 
problems: the first is that inspect.getmodule can't deduce the module of 
built-in objects, so the module documentation may be filled with such 
"garbage" (it actually happened to me, before I've used my version of 
pydoc). The second problem is that sometimes a module wants attributes 
of other modules to be considered as its own attributes too (for 
example, the tokenize module exports the constants of the token module). 
My solution is this: attributes which are not public attributes of a
module, and are public attributes of another imported module, are never
displayed. They are probably the result of an internal "from module 
import something" statement.
   The patch attached is against version 1.91, because I implemented 
using __all__ in a bit different way than version 1.92.

More flexible HTML documentation of a complete directory
========================================================
   Here's my actual situation: There's a package maintainance system, 
where you first create files in your home directory and then use the 
system to install them in a common place. For example, if a package is 
called foo, and includes the modules ya.py and chsia.py, the modules 
will be named /home/noam/foo/lib/python/{ya,chsia}.py. I want to 
automatically document them, so that the HTML files will sit in 
/home/noam/foo/doc. After installing the package, the python modules 
will be copied to /usr/local/lib/python/, and the documentation will be 
copied to /usr/local/doc/foo.
   I want to be able to type one command to generate all the
documentation, but I don't want to waste time if I only need the 
documentation re-generated for one module. So I made "pydoc -w <dir>" 
produce documentation only if the target file was modified before the 
module was. (pydoc -w <filename> still write the documentation even if 
it seems up to date.)
   It is perfectly legitimate to write a HTML documentation for a module
by your own. So I made pydoc never overwrite HTML files which weren't
created by pydoc. To accomplish this, I added the tag <meta
name="generator" content="pydoc"> to the head of all HTML files produced
by pydoc. A warning is printed if a module was modified after a manually 
created documentation was modified.
   I wanted to be able to run "pydoc -w" from any directory, not just
from /home/noam/foo/doc, so I added an option "-o <dir>", to specify the
output directory. (If it isn't specified, the current directory is used.)
   I wanted the documentation to refer to the installed file 
(/usr/local/lib/python/foo.py), not to the file in my home directory. So 
I added an option "-d <destdir>", to specify the directory in which the 
files will reside after being installed.
   To summarise, the command which I should now run to produce the
documentation is
pydoc -w -o doc/ -d /usr/local/ lib/python/
(running it from /home/noam/foo).
   The -d and -o options are already available in compileall.py, for 
exactly the same reasons, I think.
   None of this should cause backward compatibility issues.

Module loading
==============
   Currently, safeimport(), used by writedocs(), gets only a module name
and imports it using __import__(). This means that when you document a
complete directory, you can only produce HTML documentation for modules
which are already installed, and that a documentation for the wrong 
version of a module may be produced. I changed safeimport() to get an 
optional list of directories in which to look for the module/package, in 
which case it uses imp.find_module and imp.load_module instead of 
__import__. This means that when producing documentation for a complete 
directory, the actual files in the directory are used, not installed 
modules of the same name.

Misc.
=====
   I changed the docmodule methods, to use cStringIO.StringIO.write 
instead of s = s + something.
   in do_GET, forceload was set to True for some reason. It caused
problems when documenting modules which pydoc itself uses, and I don't
see why should modules be forced to load, so I changed it to False.
   The link to a file was "file:"+path. I changed it to "file://"+path,
because my browser (Mozilla) treated the path as a relative path.

Attached is a diff against version 1.91 of pydoc.py (see the section on 
public and private).
I will be glad if after your review, at least some of these changes will 
be accepted.

Have a happy day,
Noam Raphael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pydoc.py.diff
Type: text/x-patch
Size: 58687 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040613/8e42d480/pydoc.py-0001.bin
From tim.one at comcast.net  Mon Jun 14 11:02:11 2004
From: tim.one at comcast.net (Tim Peters)
Date: Mon Jun 14 11:02:21 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406141431.i5EEV6f30289@guido.python.org>
Message-ID: <mailman.469.1087225341.6944.python-dev@python.org>

[Guido]
> Another question about the VS7.1 project files: these are XML text, but
> they seem to be checked in as binary,

So they do.

> therefore CVS won't even attempt merges.

Can't say I care.  The checkin msg showed a teensy context diff, and I
couldn't measure the time difference between CVS applying a patch or
replacing the file.

> Is there a reason they can't be marked as text? Surely the old
> VC 6.0 reason for this is no longer valid now it's XML?

Don't know, haven't tried.  See above for "don't care" <wink>.  If you
determine it still works with plain \n line ends, OK by me if you change
'em.



From oliver.schoenborn at utoronto.ca  Mon Jun 14 11:08:10 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Mon Jun 14 11:09:51 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)scopes
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk><40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de><uacz9ufzn.fsf@boost-consulting.com>	<40CAF8E0.1030909@v.loewis.de>	<00be01c450d9$73e5c5a0$0202a8c0@olidesk>	<40CC0A05.8080504@v.loewis.de>
	<026f01c45177$e71be6a0$0202a8c0@olidesk>
	<40CD270A.8000208@v.loewis.de>
Message-ID: <004701c45221$6840c490$2c08f684@u66schoenborno>


From: "Martin v. L?wis" <martin@v.loewis.de>
> Consider this example, where X is a class that needs finally-ization,
> and f and g are functions that participate in the protocol:
>
> def f():
>    a = X()
>    g()
>    a.do_something()
>
> def g():
>    b = X()
>
> Now, when f starts, an X instance is registered with the cleaner,
> and this is assigned to the local variable a. Then g is invoked.
> This creates another X instance that is also registered with the
> cleaner. Then g returns, and all objects registered with the
> cleaner are finally-ized.
> At the moment, there are two objects
> registered with the cleaner, so they are both finally-ized.


Oh no, absolutely not! The objects are finaly-izated only for the frame
where created. This is ensured because the cleaner uses a stack (unrelated
to the frame stack), one item in the stack per function call. You will see
this clearly if you look at the latest detscope.py. b is cleaned up upon
return from g, and a will be cleaned up only upon return from f.

Oliver


From jcarlson at uci.edu  Mon Jun 14 11:36:57 2004
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon Jun 14 11:42:31 2004
Subject: [Python-Dev] RE: [Python-checkins] python/dist/src/Lib
	asyncore.py, 1.51, 1.52
In-Reply-To: <003b01c45168$4002f200$7e32c797@oemcomputer>
References: <E1BZjYT-0000jo-2z@sc8-pr-cvs1.sourceforge.net>
	<003b01c45168$4002f200$7e32c797@oemcomputer>
Message-ID: <20040614082717.9291.JCARLSON@uci.edu>

> > ! def loop(timeout=30.0, use_poll=False, map=None, count=1e309):
> 
> Would sys.maxint have sufficed?

No.  On 32 bit machines that would only result in 2**31 - 1 passes
through the loop, not quite a practical infinity.  On 64 bit machines,
2^63 - 1 would be a practical infinity.

The latest patch uses None instead, which doesn't fail when asyncore.py
exists.  The use of FP infinity was a cute hack, but only worthwhile if
you can rely on FP infinity being marshalled and unmarshalled correctly.
I didn't know there was an issue with such things, but should have
tested it on my end before posting it.  I have tested None, and at least
with Python 2.3, it works fine.

 - Josiah


From jim.jewett at eds.com  Mon Jun 14 11:43:53 2004
From: jim.jewett at eds.com (Jewett, Jim J)
Date: Mon Jun 14 11:45:10 2004
Subject: [Python-Dev] Object finalization for local (ie function) scop es
Message-ID: <B8CDFB11BB44D411B8E600508BDF076C1E96D51F@usahm010.exmi01.exch.eds.com>

I suspect people are talking about slightly different things.
I'll try to make my understanding very explicit, so that 
people can jump on the parts they disagree with.

(1)  Python does not guarantee that it will clean up for you.

If an object has a __del__ method, then this method will be
run when the object is finalized -- but python might decide
to never finalize the object.  For example, if there are
two objects in a cycle, and both have a __del__ method, then
python may decide to make them immortal, so that it doesn't
have to decide which __del__ to run first.

(2)  It is fairly common to have a resource which should be
closed/released when you are done.  (Example:  a file).  

Normally, the garbage collector will do this for you -- it 
might even do so in all your tests, but not in production.

If you want to *ensure* that your files are flushed and
closed, you have to do it yourself, because python might 
choose not to collect them, even though it could.

This is bug-prone.  

	(a)  It is easy to forget (and the problem may not
	show up in tests, because the garbage collection will 
	*usually* work).

	(b)  Calling a finalizer (such as close) explicitly 
	means you can call it before all references are truly
	gone.

(3)  The closest thing there is to a safe idiom today is to
emulate lisp's with-open-* macros using try/finally.

	try:
		f = open("filename")
	# if you do catch exceptions, then finally will have to
	# be replaced with a bare except and a reraise, plus an 
	# else clause
	finally:
		f.close()

(4)  Proponents would like a way of saying "objects like this
should *always* get their finalizer called".  In return, they're 
willing to say "this is a temporary object that will not be 
returned from the local scope."  If you replaced

	f()

with

	f()
	gc()

then any such objects created in f should have their __del__
methods run now.  Even if they do appear in cycles.  Even if
they are referenced by an uncollectable object, such as an old
extension class.

(5)  As proposed, it would be the user's responsibilibity to 
ensure that running __del__ was safe.  In return, python would
guarantee to actually do it, even if garbage collection is
turned off.

-jJ

From jcarlson at uci.edu  Mon Jun 14 11:41:16 2004
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon Jun 14 11:46:28 2004
Subject: [Python-Dev] RE: [Python-checkins] python/dist/src/Lib
	asyncore.py, 1.51, 1.52
In-Reply-To: <2m659ubeym.fsf@starship.python.net>
References: <003b01c45168$4002f200$7e32c797@oemcomputer>
	<2m659ubeym.fsf@starship.python.net>
Message-ID: <20040614083923.9294.JCARLSON@uci.edu>

> Possibly :-) Josiah said he had a patch that didn't use floating point
> infinities, but I don't think he's offered it up yet.

It was uploaded Saturday morning at 9:56AM (according to SF).  I've
deleted the other patch so that only the good one exists, and also
posted a comment to SF saying that it actually works (I tested it this
time, sorry about that last one).

 - Josiah


From jcarlson at uci.edu  Mon Jun 14 11:43:03 2004
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon Jun 14 11:48:29 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406141415.i5EEFcm30116@guido.python.org>
References: <40CD2901.1030008@v.loewis.de>
	<200406141415.i5EEFcm30116@guido.python.org>
Message-ID: <20040614084142.9297.JCARLSON@uci.edu>

[Guido]
> Surely there was a less drastic way to fix that?  sys.maxint is plenty
> for an "infinite" timeout...

It's not a timeout.  It's a parameter for "maximum number of times to
call the polling function".

 - Josiah


From skip at pobox.com  Mon Jun 14 11:57:04 2004
From: skip at pobox.com (Skip Montanaro)
Date: Mon Jun 14 11:57:12 2004
Subject: [Python-Dev] pydoc improvements
In-Reply-To: <40CBA44B.7020807@myrealbox.com>
References: <40CBA44B.7020807@myrealbox.com>
Message-ID: <16589.51921.92275.916894@montanaro.dyndns.org>


    Noam> I've made a few improvements to the pydoc module. I've tried to
    Noam> deliver them to Ka-Ping Yee, but it seems that the e-mail wasn't
    Noam> transferred, so here I present them to python-dev, including
    Noam> Ping. I hope they will be reviewed and, if found to be
    Noam> appropriate, accepted.

Noam,

Can you submit this as a patch on SourceForge?  That way it won't get lost.

Skip

From oliver.schoenborn at utoronto.ca  Mon Jun 14 12:03:41 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Mon Jun 14 12:04:45 2004
Subject: [Python-Dev] Object finalization for local (ie function) scopes
References: <16E1010E4581B049ABC51D4975CEDB8803060EE1@UKDCX001.uk.int.atosorigin.com>
Message-ID: <007d01c45229$2934cf00$2c08f684@u66schoenborno>

From: "Moore, Paul" <Paul.Moore@atosorigin.com>
> From: Oliver Schoenborn
> > surprised there hasn't been more given how fundamental the problem
> > of RAII is in Python.
>
> It's not at all clear that there *is* a "problem of RAII" in Python.
> Regardless, you may want to look at PEP 310, and the (extensive)
> threads on python-dev which it spawned, for an alternative view of
> the issue.

Already have. As mentioned in a discussion off list, I quite like 310.
However, I also troweled the python-dev archives and didn't seen any
discussion of anything related to the try/finally wrapping that I mentioned,
and since the implementation could likely be cleaner and more performant if
implemented in the interpreter directly, and would not require change to the
language itself, I mentioned it here. But that's the only reason for coming
to python-dev.

> To summarise, I think you
> should consider whether PEP 310 is what you need

310 is a good, fairly clean compromise.

> (it's probably mode
> Pythonic than overloading __del__ the way C++ does)

I agree, that's certainly *not* what I would advocate. But since you bring
it up, is there any reason why a new method like, say, __deterministic__,
couldn't be added, and any class that has it means that interpreter calls
that method upon scope exit if exception has been thrown *or* object
unreachable?

Oliver


From guido at python.org  Mon Jun 14 12:32:22 2004
From: guido at python.org (Guido van Rossum)
Date: Mon Jun 14 12:32:30 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: Your message of "Mon, 14 Jun 2004 16:57:44 +0200."
	<u0xe89w7.fsf@python.net> 
References: <200406141431.i5EEV6f30289@guido.python.org>  
	<u0xe89w7.fsf@python.net> 
Message-ID: <200406141632.i5EGWMH30576@guido.python.org>

> > Another question about the VS7.1 project files: these are XML text,
> > but they seem to be checked in as binary, therefore CVS won't even
> > attempt merges.  Is there a reason they can't be marked as text?
> > Surely the old VC 6.0 reason for this is no longer valid now it's XML?
> 
> Yes it is: MSVC only accepts them if they have \r\n line separators.

Are you sure?  I just tried changing the line endings of a few .vcproj
files to \n only, and MSVC (7.1) worked just fine.  The story about it
only accepting \r\n was true with VC 6.0, but I don't believe it for 7.1.

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

From fdrake at acm.org  Mon Jun 14 12:53:59 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Jun 14 12:54:17 2004
Subject: [Python-Dev] LC_NUMERIC proto-PEP
In-Reply-To: <20040611233701.GC17248@async.com.br>
References: <40ABFA56.9050805@iinet.net.au> <40CA415D.7090502@v.loewis.de>
	<20040611233701.GC17248@async.com.br>
Message-ID: <200406141253.59677.fdrake@acm.org>

On Sat, Jun 12, 2004 at 01:33:49AM +0200, "Martin v. L?wis" wrote:
 > I don't like documentation inside PEPs. Documentation should live
 > inside the documentation.

On Friday 11 June 2004 07:37 pm, Christian Robottom Reis wrote:
 > Well, maybe I should have used the word "change rationale" instead of
 > documentation. In any case, the document describes the original problem
 > statement, potential solutions, and the process through which a solution
 > was devised.

This is exactly the historical record PEPs were intended to provide; I think 
the PEP should be complete with respect to the rationale.

The documentation should certainly describe the final behavior, but that 
shouldn't preclude a finished PEP.


  -Fred

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


From guido at python.org  Mon Jun 14 12:34:12 2004
From: guido at python.org (Guido van Rossum)
Date: Mon Jun 14 13:25:59 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: Your message of "Mon, 14 Jun 2004 11:02:11 EDT."
	<200406141515.i5EFFas30357@guido.python.org> 
References: <200406141515.i5EFFas30357@guido.python.org> 
Message-ID: <200406141634.i5EGYCE30597@guido.python.org>

> > therefore CVS won't even attempt merges.
> 
> Can't say I care.  The checkin msg showed a teensy context diff, and I
> couldn't measure the time difference between CVS applying a patch or
> replacing the file.

I agree, but I didn't mean that.  I meant when there are local changes
and changes in the CVS repository, for text files CVS attempts to
merge those changes, but for binaries it simply moves the local file
aside and checks out a fresh copy.

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

From nas at arctrix.com  Mon Jun 14 13:41:40 2004
From: nas at arctrix.com (Neil Schemenauer)
Date: Mon Jun 14 13:41:50 2004
Subject: [Python-Dev] pydoc improvements
In-Reply-To: <16589.51921.92275.916894@montanaro.dyndns.org>
References: <40CBA44B.7020807@myrealbox.com>
	<16589.51921.92275.916894@montanaro.dyndns.org>
Message-ID: <20040614174139.GA5258@mems-exchange.org>

On Mon, Jun 14, 2004 at 10:57:04AM -0500, Skip Montanaro wrote:
> 
>     Noam> I've made a few improvements to the pydoc module.
> 
> Can you submit this as a patch on SourceForge?  That way it won't get lost.

Better yet would be to split it into small, logically separate
patches.  That makes your changes easier to review and increases the
likelihood of them being applied.

  Neil

From theller at python.net  Mon Jun 14 15:24:23 2004
From: theller at python.net (Thomas Heller)
Date: Mon Jun 14 15:24:29 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406141632.i5EGWMH30576@guido.python.org> (Guido van
	Rossum's message of "Mon, 14 Jun 2004 09:32:22 -0700")
References: <200406141431.i5EEV6f30289@guido.python.org>
	<u0xe89w7.fsf@python.net> <200406141632.i5EGWMH30576@guido.python.org>
Message-ID: <d642osd4.fsf@python.net>

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

>> > Another question about the VS7.1 project files: these are XML text,
>> > but they seem to be checked in as binary, therefore CVS won't even
>> > attempt merges.  Is there a reason they can't be marked as text?
>> > Surely the old VC 6.0 reason for this is no longer valid now it's XML?
>> 
>> Yes it is: MSVC only accepts them if they have \r\n line separators.
>
> Are you sure?  I just tried changing the line endings of a few .vcproj
> files to \n only, and MSVC (7.1) worked just fine.  The story about it
> only accepting \r\n was true with VC 6.0, but I don't believe it for 7.1.

Sorry, you are right.  Maybe it was still the case in 7.0?

Thomas


From martin at v.loewis.de  Mon Jun 14 17:02:42 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 14 17:02:52 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406141415.i5EEFcm30116@guido.python.org>
References: <200406140120.i5E1KDs28969@guido.python.org>
	<200406140357.i5E3vqC29145@guido.python.org>
	<40CD2901.1030008@v.loewis.de>
	<200406141415.i5EEFcm30116@guido.python.org>
Message-ID: <40CE1272.1000407@v.loewis.de>

Guido van Rossum wrote:
> Surely there was a less drastic way to fix that?  sys.maxint is plenty
> for an "infinite" timeout...

Perhaps. However, I let the submitter of the original patch try again.

Regards,
Martin


From pf_moore at yahoo.co.uk  Mon Jun 14 18:15:12 2004
From: pf_moore at yahoo.co.uk (Paul Moore)
Date: Mon Jun 14 18:15:01 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function) scopes
References: <16E1010E4581B049ABC51D4975CEDB8803060EE1@UKDCX001.uk.int.atosorigin.com>
	<007d01c45229$2934cf00$2c08f684@u66schoenborno>
Message-ID: <acz5vlan.fsf@yahoo.co.uk>

"Oliver Schoenborn" <oliver.schoenborn@utoronto.ca> writes:

> As mentioned in a discussion off list, I quite like 310. However, I
> also troweled the python-dev archives and didn't seen any discussion
> of anything related to the try/finally wrapping that I mentioned,

PEP 310 basically *is* about try/finally wrapping. Just not at
function level.

> and since the implementation could likely be cleaner and more
> performant if implemented in the interpreter directly, and would not
> require change to the language itself, I mentioned it here. But
> that's the only reason for coming to python-dev.

[...]

>> To summarise, I think you
>> should consider whether PEP 310 is what you need
>
> 310 is a good, fairly clean compromise.

Can you enumerate precisely how your proposal differs from PEP 310?
While I've not been following the technicalities of your discussions,
I get the impression that the main points are:

1. Delimits the scope of the construct by variable scope rather than
   introducing a new keyword.
2. Different "magic" method names.
3. Derives the objects to call the "release" method on, based on some
   sort of local variable scan (I don't follow this too well, so I
   apologise if I've described it badly).

Clearly, (2) is trivial. For (1), you save a keyword at the cost of
overloading 2 different behaviours on the variable scoping mechanism.
I'm not at all sure I can comment on (3), but my instinct says that it
is too magical - a direct violation of "explicit is better than
implicit".

In summary, I see PEP 310 as a cleaner, more explicit, less magical
variation of your proposal. (Of course, I would!)

>> (it's probably mode
>> Pythonic than overloading __del__ the way C++ does)
>
> I agree, that's certainly *not* what I would advocate. But since you bring
> it up, is there any reason why a new method like, say, __deterministic__,
> couldn't be added, and any class that has it means that interpreter calls
> that method upon scope exit if exception has been thrown *or* object
> unreachable?

Your semantics are very muddy here. I prefer something clear and
explicit - PEP 310's with construct calls the __exit__ method
*always*. No exceptions. The semantics are clear, and the behaviour is
simple. It's up to the user to write code that conforms to that
contract, but as the contract is so simple, that should be easy.

One of the problems with __del__ is that the semantics of when it is
called are complex and subtle. It seems to me that your proposal is
going to have the same problem. [Remember, that "object unreachable"
is a fairly subtle concept - you need to watch for exception frames
which still contain references to the function and its locals, etc,
etc.]

If you could take your proposal, and tease out the reasons why you
feel that PEP 310 does not satisfy the need you have, which your
proposal does, and list those reasons in a way that could be added to
PEP 310 (possibly as limitations, possibly as open questions, or
possibly even as proposed extensions) then that would be great.

Paul.
-- 
This signature intentionally left blank


From martin at v.loewis.de  Mon Jun 14 23:38:26 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 14 23:38:30 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406141431.i5EEV6f30289@guido.python.org>
References: <200406141431.i5EEV6f30289@guido.python.org>
Message-ID: <40CE6F32.5000603@v.loewis.de>

Guido van Rossum wrote:
> Another question about the VS7.1 project files: these are XML text,
> but they seem to be checked in as binary, therefore CVS won't even
> attempt merges.  Is there a reason they can't be marked as text?
> Surely the old VC 6.0 reason for this is no longer valid now it's XML?

I believe this is true for the project files. I'm not so sure about
the solution file: it is not XML.

Regards,
Martin


From martin at v.loewis.de  Mon Jun 14 23:50:18 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 14 23:50:24 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)scopes
In-Reply-To: <004701c45221$6840c490$2c08f684@u66schoenborno>
References: <042201c44e89$cee72f40$0202a8c0@olidesk>	<40C7F031.20900@v.loewis.de>	<047001c44ee9$23c8b880$0202a8c0@olidesk><40C8C121.40809@v.loewis.de>	<00c901c44f2e$ec9145d0$2c08f684@u66schoenborno>	<40C8E357.8030107@v.loewis.de><uacz9ufzn.fsf@boost-consulting.com>	<40CAF8E0.1030909@v.loewis.de>	<00be01c450d9$73e5c5a0$0202a8c0@olidesk>	<40CC0A05.8080504@v.loewis.de>	<026f01c45177$e71be6a0$0202a8c0@olidesk>	<40CD270A.8000208@v.loewis.de>
	<004701c45221$6840c490$2c08f684@u66schoenborno>
Message-ID: <40CE71FA.3000703@v.loewis.de>

Oliver Schoenborn wrote:
> Oh no, absolutely not! The objects are finaly-izated only for the frame
> where created. This is ensured because the cleaner uses a stack (unrelated
> to the frame stack), one item in the stack per function call. You will see
> this clearly if you look at the latest detscope.py. b is cleaned up upon
> return from g, and a will be cleaned up only upon return from f.

While I understand your implementation, I'm uncertain how much of it you
consider normative, and how much is implementation detail. For example,
is the order in which the finally-izers are called significant or not?

Or, coming back to my original question: It appears that *not* all
objects registered with the cleaner are destroyed when the function
returns. This brings me back to my original question: As not all
objects are finally-ized at the end of the function, then *which*
objects precisely are finally-ized?

Let me try guess an answer: At the end of a scope-guarded function,
all need-finally-ization objects are finally-ized that have been
created since the function was invoked, and which haven't yet been
finally-ized.

Taking threads into account, this definition is probably not what you
want: likely, you want to see only those objects finally-ized, that
have been created in the context of the thread in which the function
was invoked.

Is that correct? In particular, what happens with need-finally-ization 
objects which whose constructor call does not directly appear in a
scope-guarded function?

Regards,
Martin


From guido at python.org  Mon Jun 14 23:59:46 2004
From: guido at python.org (Guido van Rossum)
Date: Tue Jun 15 00:10:06 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: Your message of "Tue, 15 Jun 2004 05:38:26 +0200."
	<40CE6F32.5000603@v.loewis.de> 
References: <200406141431.i5EEV6f30289@guido.python.org>  
	<40CE6F32.5000603@v.loewis.de> 
Message-ID: <200406150359.i5F3xlf31581@guido.python.org>

> Guido van Rossum wrote:
> > Another question about the VS7.1 project files: these are XML text,
> > but they seem to be checked in as binary, therefore CVS won't even
> > attempt merges.  Is there a reason they can't be marked as text?
> > Surely the old VC 6.0 reason for this is no longer valid now it's XML?
> 
[Martin]
> I believe this is true for the project files. I'm not so sure about
> the solution file: it is not XML.

That's okay, the solution file doesn't change as much.

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

From raymond.hettinger at verizon.net  Tue Jun 15 04:27:52 2004
From: raymond.hettinger at verizon.net (Raymond Hettinger)
Date: Tue Jun 15 16:28:28 2004
Subject: [Python-Dev] Candidate Itertools
Message-ID: <000a01c452b2$a6f13b20$bfaf2c81@oemcomputer>

Feedback is requested for two prospective itertools:

def count_elements(iterable):
    b = {}
    for elem in iterable:
        b[elem] = b.get(elem, 0) + 1
    return ((cnt, elem) for elem, cnt in b.iteritems())


def pairswap(iterable):
    return ((b,a) for a,b in iterable)



The first is designed to provide item counts for min(), max(), sorted(),
nlargest(), and nsmallest().  It accepts any iterable including
generator expressions:

>>> from heapq import nlargest
>>> words = (word  for line in open('mystory.txt')  for word in
line.split())
>>> nlargest(count_elements(words), 3)
[(200, 'super'), (129, 'hero'), (103, 'villain')]



The second handles reordering of fields in tuples of length two.  It
works well with dict(), enumerate(),  dict.iteritems(),
itertools.starmap() and anything else that accepts or returns a series
of pairs:

>>> list(pairswap(_))
[('super', 200), ('hero', 129), ('villain', 103)]

>>> inversemap = dict(pairswap(forwardmap.iteritems()))

>>> maptoposition = dict(pairswap(enumerate(mysequence)))



Raymond


P.S.  If you have naming suggestions other than pairswap() and
count_elements(), I'm all ears.


From oliver.schoenborn at utoronto.ca  Tue Jun 15 07:14:38 2004
From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn)
Date: Tue Jun 15 17:29:10 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)
	scopes
References: <16E1010E4581B049ABC51D4975CEDB8803060EE1@UKDCX001.uk.int.atosorigin.com><007d01c45229$2934cf00$2c08f684@u66schoenborno>
	<acz5vlan.fsf@yahoo.co.uk>
Message-ID: <035301c452c9$f28baa40$0202a8c0@olidesk>

From: "Paul Moore" <pf_moore@yahoo.co.uk>
> "Oliver Schoenborn" <oliver.schoenborn@utoronto.ca> writes:
>
> Can you enumerate precisely how your proposal differs from PEP 310?
> [...]
> In summary, I see PEP 310 as a cleaner, more explicit, less magical
> variation of your proposal. (Of course, I would!)

In my original post, I didn't have 310 in mind, in the sense that,
naturally, an extension built right into the language (what 310 proposes) is
going to be better than one that "wraps" and "rebinds", so I wasn't
proposing something "better". Actually, my original post just asked if my
technique could be implemented in the interpreter directly. Nothing more.

So how about forgetting about it and focus on the good summary in Jim's
post. Scope.py was just an exploration of alternatives on my part and I
don't think it is worth pursuing on python-dev.

> If you could take your proposal, and tease out the reasons why you
> feel that PEP 310 does not satisfy the need you have, which your
> proposal does, and list those reasons in a way that could be added to
> PEP 310 (possibly as limitations, possibly as open questions, or
> possibly even as proposed extensions) then that would be great.

My only problem with PEP 310 is that the solution it proposes doesn't
address the problem that the user of a class still needs to be the one to
take care of ordering cleanup. So I would have prefered something that the
coder of a class uses to tell the interpreter "any instance of this object
needs deterministic cleanup", so the user can just be carefree when using
that class.

This problem is summarized well in Jim's last post, and if there is interest
I think that's what I'd like to focus on, and forget about my original post
(of course, I don't mind continuing the discussion about the implementation
of scope.py offlist).

Oliver


From guido at python.org  Tue Jun 15 17:40:26 2004
From: guido at python.org (Guido van Rossum)
Date: Tue Jun 15 17:40:45 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)
	scopes
In-Reply-To: Your message of "Tue, 15 Jun 2004 07:14:38 EDT."
	<035301c452c9$f28baa40$0202a8c0@olidesk> 
References: <16E1010E4581B049ABC51D4975CEDB8803060EE1@UKDCX001.uk.int.atosorigin.com><007d01c45229$2934cf00$2c08f684@u66schoenborno>
	<acz5vlan.fsf@yahoo.co.uk> 
	<035301c452c9$f28baa40$0202a8c0@olidesk> 
Message-ID: <200406152140.i5FLeQh00962@guido.python.org>

> My only problem with PEP 310 is that the solution it proposes doesn't
> address the problem that the user of a class still needs to be the one to
> take care of ordering cleanup. So I would have prefered something that the
> coder of a class uses to tell the interpreter "any instance of this object
> needs deterministic cleanup", so the user can just be carefree when using
> that class.

This is a fallacy, because the user still has to order the cleanup by
using the correct decorator.  We can't afford to decorate *every*
function with this mechanism (method calls are already too expensive).

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

From bob at redivi.com  Tue Jun 15 17:44:06 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Jun 15 17:44:15 2004
Subject: [Python-Dev] Candidate Itertools
In-Reply-To: <000a01c452b2$a6f13b20$bfaf2c81@oemcomputer>
References: <000a01c452b2$a6f13b20$bfaf2c81@oemcomputer>
Message-ID: <20770E32-BF15-11D8-ACAE-000A95686CD8@redivi.com>


On Jun 15, 2004, at 4:27 AM, Raymond Hettinger wrote:

> Feedback is requested for two prospective itertools:
>
> def count_elements(iterable):
>     b = {}
>     for elem in iterable:
>         b[elem] = b.get(elem, 0) + 1
>     return ((cnt, elem) for elem, cnt in b.iteritems())
>
>
> def pairswap(iterable):
>     return ((b,a) for a,b in iterable)

pairswap would be extremely convenient, but I'm not sure about 
count_elements.  Why not just return the dict?  Or create a bucket 
type?  Why return (cnt, elem) instead of (elem, cnt) if you have 
pairswap?

-bob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040615/7273208e/smime.bin
From jim.jewett at eds.com  Tue Jun 15 16:26:11 2004
From: jim.jewett at eds.com (Jewett, Jim J)
Date: Tue Jun 15 17:54:12 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function) scop es
Message-ID: <B8CDFB11BB44D411B8E600508BDF076C1E96D56E@usahm010.exmi01.exch.eds.com>

Paul Moore:

> Can you enumerate precisely how your proposal differs from PEP 310?
> ...
> 3. Derives the objects to call the "release" method on, based on some
>    sort of local variable scan (I don't follow this too well, so I
>    apologise if I've described it badly).

My (perhaps faulty) understanding is that it depended only 
on the class of the object.

PEP 310 says to call the __enter__ and __exit__ methods if an
object is wrapped by a "with:" clause.  

The scope-guard proposal says to call those methods anytime
they exist.  

Neither works well with the rare case when you do want the
object to outlive its initial scope.

I see a best-of-both-worlds by treating __exit__ as a
mini-__del__.  __exit__ would typically be called sooner,
and it would always be called, even if this meant breaking
cycles in an arbitrary order.

Unfortunately, one reason __del__ cycles aren't broken this
way is that people don't always follow the guidance for what
should be done in a __del__ function.  The meaning of __exit__ 
would be "okay, we'll run the cleanup like we should, but now 
messups are your own fault!".  If that wasn't OK the first
time (__del__), I'm not sure it will be OK the second.

-jJ

From eppstein at ics.uci.edu  Tue Jun 15 17:54:39 2004
From: eppstein at ics.uci.edu (David Eppstein)
Date: Tue Jun 15 17:54:53 2004
Subject: [Python-Dev] Re: Candidate Itertools
References: <000a01c452b2$a6f13b20$bfaf2c81@oemcomputer>
Message-ID: <eppstein-F90B31.14543915062004@sea.gmane.org>

In article <000a01c452b2$a6f13b20$bfaf2c81@oemcomputer>,
 "Raymond Hettinger" <raymond.hettinger@verizon.net> wrote:

> Feedback is requested for two prospective itertools:
> 
> def count_elements(iterable):
>     b = {}
>     for elem in iterable:
>         b[elem] = b.get(elem, 0) + 1
>     return ((cnt, elem) for elem, cnt in b.iteritems())
> 
> 
> def pairswap(iterable):
>     return ((b,a) for a,b in iterable)

I'd probably use count_elements, but as Bob I. already said, I'd prefer 
the dict to the transposed pairs of its items.  I'm not so sure why 
pairswap would be better than the generator expression it replaces, 
though.

-- 
David Eppstein                      http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science


From aahz at pythoncraft.com  Tue Jun 15 18:23:03 2004
From: aahz at pythoncraft.com (Aahz)
Date: Tue Jun 15 18:23:07 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)
	scopes
In-Reply-To: <200406152140.i5FLeQh00962@guido.python.org>
References: <acz5vlan.fsf@yahoo.co.uk> <035301c452c9$f28baa40$0202a8c0@olidesk>
	<200406152140.i5FLeQh00962@guido.python.org>
Message-ID: <20040615222303.GA23309@panix.com>

On Tue, Jun 15, 2004, Guido van Rossum wrote:
>Oliver:
>>
>> My only problem with PEP 310 is that the solution it proposes doesn't
>> address the problem that the user of a class still needs to be the one to
>> take care of ordering cleanup. So I would have prefered something that the
>> coder of a class uses to tell the interpreter "any instance of this object
>> needs deterministic cleanup", so the user can just be carefree when using
>> that class.
> 
> This is a fallacy, because the user still has to order the cleanup by
> using the correct decorator.  We can't afford to decorate *every*
> function with this mechanism (method calls are already too expensive).

My impression is that if integrated into the interpreter core, this
wouldn't be particularly expensive.  Fundamentally, it would look
something like this:

    class C(RAII):
        def __init__(self):
            RAII.register(self)

    def foo():
        x = C()

then somewhere in the guts of the function calling mechanism, just
before the scope unwinding, we'd have:

    for o in registered_objects:
        o.__finalize__()

This is IMO an attractive nuisance, but I don't think it imposes much
burden in execution speed.  I do see the attraction as being similar to
that of metaclasses and decorators: power provided to the end-developer
with few demands for understanding.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha

From Martin.vonLoewis at hpi.uni-potsdam.de  Tue Jun 15 14:26:53 2004
From: Martin.vonLoewis at hpi.uni-potsdam.de (=?iso-8859-1?Q?L=F6wis_Martin_von_?=)
Date: Tue Jun 15 21:15:07 2004
Subject: [Python-Dev] Changing PCBuild/*.vcproj to text mode
Message-ID: <5AC0F51A926CD442BC08D55DA7DAB1D499B8D1@3mxma1r.hpi.uni-potsdam.de>

I changed all *.vcproj files to text mode, removing the 
CRLFs in the repository. In your sandboxes, you will still see
the -kb flag, because it is a sticky tag. You need to perform
cvs up -A on the PCBuild directory to remove the sticky tag 
from your sandbox. This causes a text check-out, which, when you
are using CVSNT, will put in CRLFs into the files.

Kind regards,
Martin

From aweil at mail.ru  Tue Jun 15 21:52:50 2004
From: aweil at mail.ru (alejandro david weil)
Date: Tue Jun 15 21:49:36 2004
Subject: [Python-Dev] what about DECREF() implemented in python?
Message-ID: <200406152252.50786.aweil@mail.ru>

Did some version of python had DECREF() implemented in python?

Or, at least, some callback / overload posibility from python, like,
ob_type->tp_dealloc ?

I think that with this, someone could implement, in python, the
object-finalizators when an object goes out of scope..

Has sense that I make some stats to see if it's time expensive?

See ya,
david
-- 
+ There is no dark side of the moon really. Matter of fact it's all dark.


From ehuss at ironport.com  Tue Jun 15 22:35:26 2004
From: ehuss at ironport.com (Eric Huss)
Date: Tue Jun 15 22:27:23 2004
Subject: [Python-Dev] Object free lists
Message-ID: <Pine.BSF.4.58.0406151935080.99200@wintermute.sponsor.net>

Is there a plan to switch the basic objects (int, float, method, etc.) to
use pymalloc instead of the block allocation technique they currently use?

The reason I ask is because the free_list in these objects is unbounded.
It becomes a problem in a server environment if activity spikes cause
different types of objects to start eating memory and never give it up.

The only problem I see with using pymalloc is that the objects won't be
stored in memory in such a compact way.  I would imagine there would be no
performance difference.

Of course some optimizations (such as small_ints) would stay.

I would be willing to submit a patch with the change if there is interest.

-Eric

From tim.one at comcast.net  Tue Jun 15 22:52:10 2004
From: tim.one at comcast.net (Tim Peters)
Date: Tue Jun 15 22:52:16 2004
Subject: [Python-Dev] Object free lists
In-Reply-To: <Pine.BSF.4.58.0406151935080.99200@wintermute.sponsor.net>
Message-ID: <mailman.15.1087354336.21517.python-dev@python.org>

[Eric Huss]
> Is there a plan to switch the basic objects (int, float, method, etc.) to
> use pymalloc instead of the block allocation technique they currently
> use?

No.  pymalloc is slower than a simple dedicated free list.

> The reason I ask is because the free_list in these objects is unbounded.

Also immortal (once memory has been allocated for an int (float, etc), it
can never go away, or be used for anything else, for the life of the
process).

> It becomes a problem in a server environment if activity spikes cause
> different types of objects to start eating memory and never give it up.

Yup.

> The only problem I see with using pymalloc is that the objects won't be
> stored in memory in such a compact way.

The difference can be large, because pymalloc aligns to 8-byte boundaries.
So, e.g., on most boxes today a Python int object consumes 12 bytes, but
would consume 16 if allocated with pymalloc.  That's a 33% boost, and that
can be significant for apps hanging on to lots of ints.

OTOH, on most boxes there would be no real size difference for float
objects.

> I would imagine there would be no performance difference.

Sorry, there is -- and it's in the wrong direction <wink>.

> Of course some optimizations (such as small_ints) would stay.
>
> I would be willing to submit a patch with the change if there is
> interest.

I think you'd have better luck with a patch that bounded the sizes of these
free lists.  That's not hard to do; e.g., look at the simple bounded free
list in frameobject.c.  I wouldn't like a small limit on ints or floats, but
letting any subsystem suck up unbounded resource forever does cause
problems.



From bob at redivi.com  Tue Jun 15 22:58:43 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Jun 15 22:58:50 2004
Subject: [Python-Dev] Object free lists
In-Reply-To: <E1BaQNU-0005Cr-Cu@redivi.com>
References: <E1BaQNU-0005Cr-Cu@redivi.com>
Message-ID: <1439C639-BF41-11D8-ACAE-000A95686CD8@redivi.com>


On Jun 15, 2004, at 10:52 PM, Tim Peters wrote:

> [Eric Huss]
>> The only problem I see with using pymalloc is that the objects won't 
>> be
>> stored in memory in such a compact way.
>
> The difference can be large, because pymalloc aligns to 8-byte 
> boundaries.
> So, e.g., on most boxes today a Python int object consumes 12 bytes, 
> but
> would consume 16 if allocated with pymalloc.  That's a 33% boost, and 
> that
> can be significant for apps hanging on to lots of ints.
>
> OTOH, on most boxes there would be no real size difference for float
> objects.

The implementation of malloc in OS X always returns pointers aligned to 
16-byte boundaries, so that the buffers can be reasonably used by 
AltiVec instructions.  Would there be a difference in this case? :)

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040615/5a82b77f/smime.bin
From barry at python.org  Tue Jun 15 23:05:08 2004
From: barry at python.org (Barry Warsaw)
Date: Tue Jun 15 23:05:09 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
Message-ID: <1087355108.12187.3.camel@localhost>

PEP 292 is slated for inclusion in Python 2.4, according to PEP 320.  At
Pycon I checked in my code for this into the sandbox, which I've since
updated, adding unit tests.  I believe it's ready for inclusion in dist
CVS, but I want to get some feedback first.

My new stuff provides two classes, dstring() as described in PEP 292 and
astring() as hinted at in the PEP.  It also provides two dictionary
subclasses called safedict() and nsdict() which are not required, but
work nicely with dstring() and astring() -- safedict re-expands keys
instead of throwing exceptions, and nsdict does namespace lookup and
attribute path expansion.

Brett and I (I forget who else was there for this) talked about where to
situate the PEP 292 support.  The interesting idea came up to turn the
string module into a package, providing backward support for the
existing string module API, then exporting my PEP 292 modules into this
namespace.  This would make the 'import string' useful again since it
would be a place to collect future string related functionality without
having to claim some dumb name like 'stringlib'.  I believe we can still
someday deprecate the old string module functions, retaining the useful
constants, as well as new string-y features.

This is actually not hard to do, and I have this working (and passing
the existing unit tests) in a local checkout.  You simply create the
Lib/string directory, copy or move Lib/string.py to Lib/string/string.py
and do a bit of import-* in Lib/string/__init__.py.  The unit tests all
passed with no changes necessary.  I'd drop my pep292.py file and
safedict.py file into Lib/string and import the useful names out of
there, exposing them in the string namespace.

Is this a good idea?  I dunno, but it seems better to me than adding two
more top-level modules with largely contrived names; nothing better
jumps out to me.  I also really want to include safedict.py if we're
including pep292.py because they're quite useful and complimentary, IMO,
and I can't think of a better place to put those classes either.

I'm open to suggestions.  I have not yet written docs for these new
classes, but will do so once we agree on where they're getting added. 
The code and test cases are in python/nondist/sandbox/string.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040615/76d3fb41/attachment.bin
From ehuss at ironport.com  Tue Jun 15 23:26:41 2004
From: ehuss at ironport.com (Eric Huss)
Date: Tue Jun 15 23:18:38 2004
Subject: [Python-Dev] Object free lists
In-Reply-To: <367dap$be1c@rs-c601.ironport.com>
References: <367dap$be1c@rs-c601.ironport.com>
Message-ID: <Pine.BSF.4.58.0406152017300.99200@wintermute.sponsor.net>

> I think you'd have better luck with a patch that bounded the sizes of these
> free lists.  That's not hard to do; e.g., look at the simple bounded free
> list in frameobject.c.  I wouldn't like a small limit on ints or floats, but
> letting any subsystem suck up unbounded resource forever does cause
> problems.

Unfortunately the limit code would be much more complex than in
frameobject because frameobject does not allocate in blocks.

So, we would have to somehow determine if an int block is completely free
before freeing it.  Some different methods:

1) Scan each block and count the number of free integers.  If the block
contains only free integers, then free it.  This would essentially be the
code in PyInt_Fini().

We actually have code that calls PyInt_Fini when we are doing leak
detection.

2) Alternate to #1, it could avoid scanning entire blocks if it detected a
used int, and instead manually dissect the free_list iff the entire block
is free instead of rebuilding free_list from scratch like PyInt_Fini()
does.

3) Add a counter of the number of free ints in PyIntBlock.  Free the block
with this number equals the maximum number of ints in a block.

The problem with #1 is that it is slow, and one would need to determine
how often to call it.  #2 has the same problem.

#3 is a little nicer, at the cost of maintaining the counter (which should
be negligible).

Thoughts?

-Eric

From tim.one at comcast.net  Tue Jun 15 23:21:45 2004
From: tim.one at comcast.net (Tim Peters)
Date: Tue Jun 15 23:21:53 2004
Subject: [Python-Dev] Object free lists
In-Reply-To: <1439C639-BF41-11D8-ACAE-000A95686CD8@redivi.com>
Message-ID: <mailman.18.1087356113.21517.python-dev@python.org>

[Bob Ippolito]
> The implementation of malloc in OS X always returns pointers aligned to
> 16-byte boundaries, so that the buffers can be reasonably used by AltiVec
> instructions.  Would there be a difference in this case? :)

The int object free list is carved out of larger contiguous blocks, 12 bytes
(on most boxes) at a time -- see the code for details:

struct _intblock {
	struct _intblock *next;
	PyIntObject objects[N_INTOBJECTS];
};

If we had hidden malloc overhead bytes per object, pymalloc would probably
be more space-efficient than the platform malloc.  If the OS X C compiler
says sizeof(PyIntObject) == 16 (which it may or may not do, independent of
what malloc() likes best), then int objects will indeed consume 16 bytes
apiece despite Python's attempt to be more space-efficient than that.



From aweil at mail.ru  Tue Jun 15 23:32:25 2004
From: aweil at mail.ru (alejandro david weil)
Date: Tue Jun 15 23:29:16 2004
Subject: [Python-Dev] what about DECREF() implemented in python?
In-Reply-To: <200406152252.50786.aweil@mail.ru>
References: <200406152252.50786.aweil@mail.ru>
Message-ID: <200406160032.25503.aweil@mail.ru>

Ah.. It seems to be very dificult to be implemented. 
(I've got a neverending loop :-) )
Sorry.. forget it. 

On Tue June 15 2004 22:52, alejandro david weil wrote:
> Did some version of python had DECREF() implemented in python?
>
> Or, at least, some callback / overload posibility from python, like,
> ob_type->tp_dealloc ?
>
> I think that with this, someone could implement, in python, the
> object-finalizators when an object goes out of scope..
>
> Has sense that I make some stats to see if it's time expensive?
>
> See ya,
> david

-- 
+ There is no dark side of the moon really. Matter of fact it's all dark.


From tim.one at comcast.net  Tue Jun 15 23:30:57 2004
From: tim.one at comcast.net (Tim Peters)
Date: Tue Jun 15 23:31:04 2004
Subject: [Python-Dev] Object free lists
In-Reply-To: <Pine.BSF.4.58.0406152017300.99200@wintermute.sponsor.net>
Message-ID: <mailman.19.1087356664.21517.python-dev@python.org>

[Eric Huss]
> Unfortunately the limit code would be much more complex than in
> frameobject because frameobject does not allocate in blocks.

Ugh -- yup.

> So, we would have to somehow determine if an int block is completely free
> before freeing it.  Some different methods:
>
> 1) Scan each block and count the number of free integers.  If the block
> contains only free integers, then free it.  This would essentially be the
> code in PyInt_Fini().
>
> We actually have code that calls PyInt_Fini when we are doing leak
> detection.
>
> 2) Alternate to #1, it could avoid scanning entire blocks if it detected
> a used int, and instead manually dissect the free_list iff the entire
> block is free instead of rebuilding free_list from scratch like
> PyInt_Fini() does.
>
> 3) Add a counter of the number of free ints in PyIntBlock.  Free the
> block with this number equals the maximum number of ints in a block.
>
> The problem with #1 is that it is slow, and one would need to determine
> how often to call it.  #2 has the same problem.
>
> #3 is a little nicer, at the cost of maintaining the counter (which
> should be negligible).

At which point we're getting close to reinventing pymalloc, except not
enough so:  since the list of int blocks is singly-linked, it's not
efficient to remove an arbitrary one.

I can't make more time tonight, so I look forward to reading the solution in
the morning <wink>.



From martin at v.loewis.de  Wed Jun 16 01:22:23 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed Jun 16 01:22:28 2004
Subject: [Python-Dev] Object free lists
In-Reply-To: <Pine.BSF.4.58.0406152017300.99200@wintermute.sponsor.net>
References: <367dap$be1c@rs-c601.ironport.com>
	<Pine.BSF.4.58.0406152017300.99200@wintermute.sponsor.net>
Message-ID: <40CFD90F.7000506@v.loewis.de>

Eric Huss wrote:
> #3 is a little nicer, at the cost of maintaining the counter (which should
> be negligible).
> 
> Thoughts?

I don't know if that has been considered, yet: in int_dealloc, you don't 
know what block an int belongs to. Therefore, changing the counter will
be difficult.

Regards,
Martin


From python at rcn.com  Tue Jun 15 15:07:40 2004
From: python at rcn.com (Raymond Hettinger)
Date: Wed Jun 16 03:08:11 2004
Subject: [Python-Dev] Re: Candidate Itertools
In-Reply-To: <eppstein-F90B31.14543915062004@sea.gmane.org>
Message-ID: <000201c4530c$07c3c540$bfaf2c81@oemcomputer>

[David Eppstein]
> I'd probably use count_elements, but as Bob I. already said, I'd
prefer
> the dict to the transposed pairs of its items.

An alternate dictionary constructor would provide that flexibility:

  def countkeys(cls, iterable):
      b = cls()
      for elem in iterable:
          [elem] = b.get(elem, 0) + 1
      return b

However, the added flexibility makes the use case more complicated:


  >>> from heapq import nlargest
  >>> words = (word  for line in myfile  for word in line.split())
  >>> nlargest(3, pairwise(dict.countkeys(words).iteritems()))
  [(200, 'super'), (129, 'hero'), (103, 'villain')]

That last line is much more involved than writing:

  >>> nlargest(3, count_elements(words))

I find the latter to be more readable and to be a more obvious tool for
working with nlargest(), nsmallest(), sorted(), min(), and max().  Also,
it does less work under the hood because it doesn't have to build two
different tuples for each entry.

OTOH, if you actually want to end-up with a dictionary, it is somewhat
wasteful to build one, throw it away, and then rebuild it from the
itemlist:

  >>> dict(count_elements(words))



Raymond


From dooms at info.ucl.ac.be  Wed Jun 16 04:26:42 2004
From: dooms at info.ucl.ac.be (=?ISO-8859-1?Q?Gr=E9goire_Dooms?=)
Date: Wed Jun 16 04:27:39 2004
Subject: [Python-Dev] Re: Candidate Itertools
In-Reply-To: <000201c4530c$07c3c540$bfaf2c81@oemcomputer>
References: <000201c4530c$07c3c540$bfaf2c81@oemcomputer>
Message-ID: <40D00442.4020507@info.ucl.ac.be>

Raymond Hettinger wrote:

<snip ...>

>
>OTOH, if you actually want to end-up with a dictionary, it is somewhat
>wasteful to build one, throw it away, and then rebuild it from the
>itemlist:
>
>  >>> dict(count_elements(words))
>
>  
>
IMO, the dictionary would be more useful as :
    >>>  dict(pairswap(count_elements(words)))
And yes, it would be wasteful to produce it in this way.

--
Gr?goire Dooms


From python at rcn.com  Tue Jun 15 17:10:17 2004
From: python at rcn.com (Raymond Hettinger)
Date: Wed Jun 16 05:11:46 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <1087355108.12187.3.camel@localhost>
Message-ID: <000f01c4531d$28ce9240$bfaf2c81@oemcomputer>

> PEP 292 is slated for inclusion in Python 2.4,

For completeness, perhaps update the PEP to specify what will happen
with $ strings that do not fall under $$, $indentifier, or
${identifier}.  For instance, what should happen with:

   "A dangling $"
   "A $!invalid_identifier"
   "A $identfier&followed_by_nonwhitespace_punctuation"



> My new stuff provides two classes, dstring() as described in PEP 292
and
> astring() as hinted at in the PEP.  It also provides two dictionary
> subclasses called safedict() and nsdict() which are not required, but
> work nicely with dstring() and astring() -- safedict re-expands keys
> instead of throwing exceptions, and nsdict does namespace lookup and
> attribute path expansion.

The names dstring(), astring(), safedict(), and nsdict() could likely be
improved to be more suggestive of what they do.   



> Brett and I (I forget who else was there for this) talked about where
to
> situate the PEP 292 support.  The interesting idea came up to turn the
> string module into a package, providing backward support for the
> existing string module API, then exporting my PEP 292 modules into
this
> namespace.  This would make the 'import string' useful again since it
> would be a place to collect future string related functionality
without
> having to claim some dumb name like 'stringlib'.  I believe we can
still
> someday deprecate the old string module functions, retaining the
useful
> constants, as well as new string-y features.

-1

The inclusion of string.py breathes life into something that needs to
disappear.  One of the reasons for deprecating these functions is to
reduce the number of things you need to learn and remember.
Interspersing a handful of new functions and classes is contrary to that
goal.  It becomes hard to introduce simplified substitutions without
talking about all the other string functions that you're better off not
knowing about.

A separate module is preferable.  Also, I don't see any benefit into
rolling a package with safedict and nsdict in a separate module from
dstring and astring.



> I also really want to include safedict.py if we're
> including pep292.py because they're quite useful and complimentary,
IMO,
> and I can't think of a better place to put those classes either.

Can safedict.safedict() be made more general so that it has value
outside of string substitutions.  Ideally, the default format would be
customizable and would include an option to leave the entry unchanged.
Right now, the implementation is specific to string substitution
formats.  It is not even useful with normal % formatting.



> I'm open to suggestions.  I have not yet written docs for these new
> classes, but will do so once we agree on where they're getting added.
> The code and test cases are in python/nondist/sandbox/string.

Given the simplicity of the PEP, the sandbox implementation is
surprisingly intricate.  Is it possible to simplify it with a function
based rather than class based approach? 

I can imagine alternatives which encapsulate the whole idea in something
similar to this:

import re

nondotted =
re.compile(r'(\${2})|\$([_a-z][_a-z0-9]*)|\$({[_a-z][_a-z0-9]*})',
re.IGNORECASE)

dotted=
re.compile(r'(\${2})|\$([_a-z][_.a-z0-9]*)|\$({[_a-z][_.a-z0-9]*})',
re.IGNORECASE)

def _convert(m):
    'Convert $ formats to % formats'
    escaped, straight, bracketed = m.groups()
    if escaped is not None:
        return '$'
    if straight is not None:
        return '%(' + straight + ')s'
    return '%(' + bracketed[1:-1] + ')s'

def subst(fmtstr, mapping, fmtcode=nondotted, _cache={}):
    if fmtstr not in _cache:
        _cache[fmtstr] = _fmtcode.sub(_convert, fmtstr)
    return _cache[fmtstr] % mapping

>>> fmtstr = '$who owes me $$${what}.'
>>> mapping = dict(who='Guido', what='money'))
>>> print subst(fmtstr, mapping)
Guido owes me $money.
    
  

Raymond


From perky at i18n.org  Wed Jun 16 05:17:18 2004
From: perky at i18n.org (Hye-Shik Chang)
Date: Wed Jun 16 05:17:30 2004
Subject: [Python-Dev] Planned updates for cjkcodecs before 2.4a1
Message-ID: <20040616091718.GA81120@i18n.org>

I have planned few things to update in cjkcodecs before 2.4 alpha1
is out.  If you have any opionions or objections, please tell me.

1. Update JIS X 0213 to its first amendment (a.k.a JIS X 0213:2004)
   This will introduce three new encodings; euc-jis-2004, shift_jis-2004
   and iso-2022-jp-2004.  It's not so different from their each
   preceding encodings but we may need to keep both of versions due
   to incompatibilities and encoding name change.  (This won't bloat
   code size a lot. I expect it around 3~5K.)

2. Merge two or three simliar C codecs into one.  We have one C
   codec for every each python codecs currently.  I have got an
   idea to merge them into several similar groups and many common
   part of .so binaries will be saved:

     _codecs_jacodecs_1.so: euc-jp, shift-jis, iso-2022-jp,
                            iso-2022-jp-1, iso-2022-jp-ext
     _codecs_jacodecs_2.so: euc-jisx0213, shift-jisx0213, iso-2022-jp-3,
			    euc-jis-2004, shift-jis-2004,
			    iso-2022-jp-2004
     _codecs_jacodecs_3.so: iso-2022-jp-2
     _codecs_kocodecs_1.so: euc-kr, johab, iso-2022-kr
     _codecs_kocodecs_2.so: cp949
     _codecs_zhcodecs_1.so: gb2312, gbk, gb18030, hz
     _codecs_zhcodecs_2.so: big5, cp950

3. Split some mapping keeper modules to few group-based modules. This
   will save memory and spaces for who need only legacy codecs like
   "euc-kr only".

     _codecs_mapdata_ko_KR ->
         _codecs_komapdata_1.so: KS X 1001
         _codecs_komapdata_2.so: cp949

     _codecs_mapdata_ja_JP ->
         _codecs_jamapdata_1.so: JIS X 0208, JIS X 0212
         _codecs_jamapdata_2.so: JIS X 0213:2000 and :2004

     _codecs_mapdata_zh_CN ->
         _codecs_zhmapdata_1.so: gb2312, gbk, gb18030

     _codecs_mapdata_zh_TW ->
         _codecs_zhmapdata_2.so: big5, cp950


If these sound acceptable for python-dev people, they will be
implemented as CJKCodecs 1.1 first and imported into python later
(before 2.4a1).


Hye-Shik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040616/b576eb76/attachment.bin
From mal at egenix.com  Wed Jun 16 05:33:59 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jun 16 05:34:10 2004
Subject: [Python-Dev] Re: [I18n-sig] Planned updates for cjkcodecs before
	2.4a1
In-Reply-To: <20040616091718.GA81120@i18n.org>
References: <20040616091718.GA81120@i18n.org>
Message-ID: <40D01407.7040309@egenix.com>

Hye-Shik Chang wrote:
> I have planned few things to update in cjkcodecs before 2.4 alpha1
> is out.  If you have any opionions or objections, please tell me.
> 
> 1. Update JIS X 0213 to its first amendment (a.k.a JIS X 0213:2004)
>    This will introduce three new encodings; euc-jis-2004, shift_jis-2004
>    and iso-2022-jp-2004.  It's not so different from their each
>    preceding encodings but we may need to keep both of versions due
>    to incompatibilities and encoding name change.  (This won't bloat
>    code size a lot. I expect it around 3~5K.)

+1

> 2. Merge two or three simliar C codecs into one.  We have one C
>    codec for every each python codecs currently.  I have got an
>    idea to merge them into several similar groups and many common
>    part of .so binaries will be saved:
> 
>      _codecs_jacodecs_1.so: euc-jp, shift-jis, iso-2022-jp,
>                             iso-2022-jp-1, iso-2022-jp-ext
>      _codecs_jacodecs_2.so: euc-jisx0213, shift-jisx0213, iso-2022-jp-3,
> 			    euc-jis-2004, shift-jis-2004,
> 			    iso-2022-jp-2004
>      _codecs_jacodecs_3.so: iso-2022-jp-2
>      _codecs_kocodecs_1.so: euc-kr, johab, iso-2022-kr
>      _codecs_kocodecs_2.so: cp949
>      _codecs_zhcodecs_1.so: gb2312, gbk, gb18030, hz
>      _codecs_zhcodecs_2.so: big5, cp950


+1, but why not put all Japanese codecs into one module and
dito for the Korean and Chinese ones ?

Note that todays OS linkers will only mmap those pieces
of code into the process memory that are actually needed
by the application, so even though the size of the modules
increases, the application process memory foot-print is
likely not to increase.

> 3. Split some mapping keeper modules to few group-based modules. This
>    will save memory and spaces for who need only legacy codecs like
>    "euc-kr only".
> 
>      _codecs_mapdata_ko_KR ->
>          _codecs_komapdata_1.so: KS X 1001
>          _codecs_komapdata_2.so: cp949
> 
>      _codecs_mapdata_ja_JP ->
>          _codecs_jamapdata_1.so: JIS X 0208, JIS X 0212
>          _codecs_jamapdata_2.so: JIS X 0213:2000 and :2004
> 
>      _codecs_mapdata_zh_CN ->
>          _codecs_zhmapdata_1.so: gb2312, gbk, gb18030
> 
>      _codecs_mapdata_zh_TW ->
>          _codecs_zhmapdata_2.so: big5, cp950
> 

-1

See above: this is static C data, so splitting these won't
really buy the user anything.

If you don't believe this, compare the resident size of
Python with and without unicodedata loaded. The difference
on my machine is a measily 30kB, not the 250kB of the complete
module.

> If these sound acceptable for python-dev people, they will be
> implemented as CJKCodecs 1.1 first and imported into python later
> (before 2.4a1).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 16 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From mal at egenix.com  Wed Jun 16 05:55:00 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jun 16 06:00:56 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
Message-ID: <40D018F4.8080503@egenix.com>

As you may know, the method u"abc".encode(encoding) currently
guarantees that the return value will always be an 8-bit string
value.

Now that more and more codecs become available and the scope
of those codecs goes far beyond only encoding from Unicode to
strings and back, I am tempted to open up that restriction,
thereby opening up u.encode() for applications that wish to
use other codecs that return e.g. Unicode objects as well.

There are several applications for this, such as character
escaping, remapping characters (much like you would use
string.translate() on 8-bit strings), compression, etc. etc.

Note that codecs are not restricted in what they can return
for their .encode() or .decode() method, so any object
type is acceptable, including subclasses of str or
unicode, buffers, mmapped files, etc.

The needed code change is a one-liner.

What do you think ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 16 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From perky at i18n.org  Wed Jun 16 07:35:18 2004
From: perky at i18n.org (Hye-Shik Chang)
Date: Wed Jun 16 08:35:39 2004
Subject: [Python-Dev] Re: [I18n-sig] Planned updates for cjkcodecs before
	2.4a1
In-Reply-To: <20040616111651.GA82901@i18n.org>
References: <20040616091718.GA81120@i18n.org> <40D01407.7040309@egenix.com>
	<20040616111651.GA82901@i18n.org>
Message-ID: <20040616113518.GA83739@i18n.org>

On Wed, Jun 16, 2004 at 08:16:52PM +0900, Hye-Shik Chang wrote:
> On Wed, Jun 16, 2004 at 11:33:59AM +0200, M.-A. Lemburg wrote:
> > Hye-Shik Chang wrote:
> [snip]
> > >2. Merge two or three simliar C codecs into one.  We have one C
> > >   codec for every each python codecs currently.  I have got an
> > >   idea to merge them into several similar groups and many common
> > >   part of .so binaries will be saved:
> > 
> > +1, but why not put all Japanese codecs into one module and
> > dito for the Korean and Chinese ones ?
> > 
> > Note that todays OS linkers will only mmap those pieces
> > of code into the process memory that are actually needed
> > by the application, so even though the size of the modules
> > increases, the application process memory foot-print is
> > likely not to increase.
> 
> Okay. But how about embedded, freezed environments or statically
> compiled into python by uncommenting from Modules/Setup?  If somebody
> need to support only legacy Japanese encodings, he will want to
> include a legacy mapping(70K) but will not want JIS X 0213(85K) and
> KS X 1001, GB2312 mappings(200K, for iso-2022-jp-2).  And he may
> want to save spaces by just erasing files.  In fact, I don't know
> how real Japanese developers use but just guessed it. :)
> 

Aah.  While I'm taking shower, I found that a problem on iso-2022-jp-2
can be resolved by make codecs to load mapping tables on demand.
(they're loading mappings in init function currently.)  I agree in
incorporating all CJK codecs to each per-language codec collection
modules.  Thanks for the comments!

Hye-Shik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040616/7d4bf748/attachment.bin
From tim.one at comcast.net  Wed Jun 16 16:46:36 2004
From: tim.one at comcast.net (Tim Peters)
Date: Wed Jun 16 17:12:18 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <40D0AEAE.5000606@egenix.com>
Message-ID: <mailman.29.1087420338.21517.python-dev@python.org>

[M.-A. Lemburg]
> Are we going to have a VC7.1 binary of Python 2.4 for Windows ?

That's indeed my understanding of The Plan today.  More, we will not have a
VC6 binary for Python 2.4.  That may be controversial, but nobody has
volunteered to produce an installer for a VC6 version.

> (Just asking whether it's time to finally open the VC7 shrink-
>   wrap box ;-)

Yup.  IIRC, it took about 3GB of disk space to do a full install (including
copying all the docs to disk).  After it's installed, you won't recognize
it, and will feel completely lost.  This is a learning experience <wink>.



From mwh at python.net  Thu Jun 17 05:15:39 2004
From: mwh at python.net (Michael Hudson)
Date: Thu Jun 17 05:15:45 2004
Subject: [Python-Dev] Candidate Itertools
In-Reply-To: <000a01c452b2$a6f13b20$bfaf2c81@oemcomputer> (Raymond
	Hettinger's message of "Tue, 15 Jun 2004 04:27:52 -0400")
References: <000a01c452b2$a6f13b20$bfaf2c81@oemcomputer>
Message-ID: <2moeni8s04.fsf@starship.python.net>

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

> Feedback is requested for two prospective itertools:
>
> def count_elements(iterable):
>     b = {}
>     for elem in iterable:
>         b[elem] = b.get(elem, 0) + 1
>     return ((cnt, elem) for elem, cnt in b.iteritems())

Mmm, possibly.  I've written this farily often.  As other said, I
think I'd prefer the dict.

> def pairswap(iterable):
>     return ((b,a) for a,b in iterable)

What's the point?  It's so short as a genxp...

Cheers,
mwh

-- 
  "Also, does the simple algorithm you used in Cyclops have a name?"
  "Not officially, but it answers to "hey, dumb-ass!"
                       -- Neil Schemenauer and Tim Peters, 23 Feb 2001

From DavidA at ActiveState.com  Thu Jun 17 00:00:22 2004
From: DavidA at ActiveState.com (David Ascher)
Date: Thu Jun 17 05:45:43 2004
Subject: [Python-Dev] python-dev archive searching ?
In-Reply-To: <20040610233555.GA15938@dave@alana.ucc.usyd.edu.au>
References: <20040610233555.GA15938@dave@alana.ucc.usyd.edu.au>
Message-ID: <40D11756.40001@ActiveState.com>

Dave Harrison wrote:

> Hi all,
> 
> I've spent a bit of time looking for a way to search the python-dev
> archives for topics, but I'm not having much success (unless I want to
> trawl the archives by hand, month by month).
> 
> Is there something I'm missing here ?

Feel free to poke around the ASPN Mail archives:

http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/python-dev

(ASPN had some performance problems earlier this month, but with a brand 
spanking new box, we should be out of those woods).

--david

From barry at python.org  Wed Jun 16 14:51:01 2004
From: barry at python.org (Barry Warsaw)
Date: Thu Jun 17 06:56:21 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <40D018F4.8080503@egenix.com>
References: <40D018F4.8080503@egenix.com>
Message-ID: <1087411861.7146.2.camel@localhost>

On Wed, 2004-06-16 at 05:55, M.-A. Lemburg wrote:

> Now that more and more codecs become available and the scope
> of those codecs goes far beyond only encoding from Unicode to
> strings and back, I am tempted to open up that restriction,
> thereby opening up u.encode() for applications that wish to
> use other codecs that return e.g. Unicode objects as well.

+1

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040616/54f978f6/attachment.bin
From mike at skew.org  Wed Jun 16 17:15:27 2004
From: mike at skew.org (Mike Brown)
Date: Thu Jun 17 07:11:22 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <40D018F4.8080503@egenix.com> "from M.-A. Lemburg at Jun 16, 2004
	11:55:00 am"
Message-ID: <200406162115.i5GLFRrb050850@chilled.skew.org>

M.-A. Lemburg wrote:
> Now that more and more codecs become available and the scope
> of those codecs goes far beyond only encoding from Unicode to
> strings and back, I am tempted to open up that restriction,
> thereby opening up u.encode() for applications that wish to
> use other codecs that return e.g. Unicode objects as well.
> [...]
> Note that codecs are not restricted in what they can return
> for their .encode() or .decode() method, so any object
> type is acceptable, including subclasses of str or
> unicode, buffers, mmapped files, etc.

+1. I find it surprising that the restriction exists. I would have thought 
u.encode('foo') would pretty transparently wrap the foo codec's .encode().

This is also a good reminder that type checking of the result of codec or
unicode .encode() calls is prudent, anytime.

From mal at egenix.com  Wed Jun 16 16:33:50 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jun 17 07:26:02 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <20040614011919.35A0D2EFF0@mail.egenix.com>
References: <20040614011919.35A0D2EFF0@mail.egenix.com>
Message-ID: <40D0AEAE.5000606@egenix.com>

Tim Peters wrote:
> [Guido]
> 
>>Is anybody maintaining the project files for Visual Studio 7.1?
> 
> Martin, Thomas and I all fiddle it when we notice it needs something.  I
> view Martin as being the primary owner.

Are we going to have a VC7.1 binary of Python 2.4 for Windows ?

(Just asking whether it's time to finally open the VC7 shrink-
  wrap box ;-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 16 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From Scott.Daniels at Acm.Org  Wed Jun 16 13:22:31 2004
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Thu Jun 17 07:53:49 2004
Subject: [Python-Dev] Re: heapq API
In-Reply-To: <002001c45058$b381f840$dab7958d@oemcomputer>
References: <002001c45058$b381f840$dab7958d@oemcomputer>
Message-ID: <capviv$lqq$1@sea.gmane.org>

Raymond Hettinger wrote:
> def heappushpop(heap, item):
>     ?Pushes the item onto the heap and then pops the smallest value?
> 
>     if not heap or item < heap[0]:
>         return item
>     return heapreplace(heap, item)
Better is:
      if heap and heap[0] < item:
          return heapreplace(heap, item)
      return item
-- Don't touch the heap unless necessary.

-- 
-- Scott David Daniels
Scott.Daniels@Acm.Org


From perky at i18n.org  Wed Jun 16 07:16:52 2004
From: perky at i18n.org (Hye-Shik Chang)
Date: Thu Jun 17 08:03:03 2004
Subject: [Python-Dev] Re: [I18n-sig] Planned updates for cjkcodecs before
	2.4a1
In-Reply-To: <40D01407.7040309@egenix.com>
References: <20040616091718.GA81120@i18n.org> <40D01407.7040309@egenix.com>
Message-ID: <20040616111651.GA82901@i18n.org>

On Wed, Jun 16, 2004 at 11:33:59AM +0200, M.-A. Lemburg wrote:
> Hye-Shik Chang wrote:
[snip]
> >2. Merge two or three simliar C codecs into one.  We have one C
> >   codec for every each python codecs currently.  I have got an
> >   idea to merge them into several similar groups and many common
> >   part of .so binaries will be saved:
> >
> >     _codecs_jacodecs_1.so: euc-jp, shift-jis, iso-2022-jp,
> >                            iso-2022-jp-1, iso-2022-jp-ext
> >     _codecs_jacodecs_2.so: euc-jisx0213, shift-jisx0213, iso-2022-jp-3,
> >			    euc-jis-2004, shift-jis-2004,
> >			    iso-2022-jp-2004
> >     _codecs_jacodecs_3.so: iso-2022-jp-2
> >     _codecs_kocodecs_1.so: euc-kr, johab, iso-2022-kr
> >     _codecs_kocodecs_2.so: cp949
> >     _codecs_zhcodecs_1.so: gb2312, gbk, gb18030, hz
> >     _codecs_zhcodecs_2.so: big5, cp950
> 
> 
> +1, but why not put all Japanese codecs into one module and
> dito for the Korean and Chinese ones ?
> 
> Note that todays OS linkers will only mmap those pieces
> of code into the process memory that are actually needed
> by the application, so even though the size of the modules
> increases, the application process memory foot-print is
> likely not to increase.

Okay. But how about embedded, freezed environments or statically
compiled into python by uncommenting from Modules/Setup?  If somebody
need to support only legacy Japanese encodings, he will want to
include a legacy mapping(70K) but will not want JIS X 0213(85K) and
KS X 1001, GB2312 mappings(200K, for iso-2022-jp-2).  And he may
want to save spaces by just erasing files.  In fact, I don't know
how real Japanese developers use but just guessed it. :)

[snip]
> 
> If you don't believe this, compare the resident size of
> Python with and without unicodedata loaded. The difference
> on my machine is a measily 30kB, not the 250kB of the complete
> module.

I do believe this.  This is also why I wrote cjkcodecs in not pure
Python but C extensions.


Hye-Shik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040616/66a5d767/attachment.bin
From python at rcn.com  Wed Jun 16 08:26:34 2004
From: python at rcn.com (Raymond Hettinger)
Date: Thu Jun 17 08:18:45 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <1087414523.7150.45.camel@localhost>
Message-ID: <003301c4539d$29dc70a0$bfaf2c81@oemcomputer>

> > For completeness, perhaps update the PEP to specify what will happen
> > with $ strings that do not fall under $$, $indentifier, or
> > ${identifier}.
> 
> Good point, I've pushed out an update.

One other thought, please reconsider the key lookup for ${identifier}.
I think retaining the braces in the key is a mistake.  The purpose of
the braces was to allow trailing characters without intervening
whitespace.  Extending it to have special meaning for SafeDicts was
probably not the way to go.

As a result, the example in the PEP doesn't work anymore:

>>> mapping = dict(name='Guido', country='the Netherlands')
>>> s = dstring('${name} was born in ${country}')
>>> print s % mapping

Traceback (most recent call last):
  File "C:\nondist\sandbox\string\pep292.py", line 124, in -toplevel-
    print s % mapping
  File "C:\nondist\sandbox\string\pep292.py", line 108, in __mod__
    return self._modstr % other
KeyError: '{name}'


Raymond


P.S.  The PEP example is also missing the rightmost single quotation
mark.


From mchermside at ingdirect.com  Thu Jun 17 07:52:44 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Thu Jun 17 08:24:09 2004
Subject: [Python-Dev] Candidate Itertools
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550A7E@ingdexj1.ingdirect.com>

[Michael Chermside]
> Is the behavior of count_elements() exactly the same as
> the given python equivalent when one (or more) of the
> elements in the iterable is not hashable?

[Raymond Hettinger]
> That was the original idea; however, we could easily keep a separate
> list of identity comparisons for unhashables

If you do indeed handle unhashables, then I think this interface
seems useful, although I'd order it (elem, cnt) so that when
everything IS hashable a dict can be built via
    dict(*count_elements(iterable))
If you do NOT handle unhashables, then I'd agree with Bob that
we should just return the dict itself -- that's the most natural
data structure for expressing a bunch of counts available in
Python. And I think the function is worth including.

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From jcarlson at uci.edu  Thu Jun 17 08:29:56 2004
From: jcarlson at uci.edu (Josiah Carlson)
Date: Thu Jun 17 08:35:50 2004
Subject: [Python-Dev] Re: heapq API
In-Reply-To: <capviv$lqq$1@sea.gmane.org>
References: <002001c45058$b381f840$dab7958d@oemcomputer>
	<capviv$lqq$1@sea.gmane.org>
Message-ID: <20040617052830.70F5.JCARLSON@uci.edu>

> Raymond Hettinger wrote:
> > def heappushpop(heap, item):
> >     ?Pushes the item onto the heap and then pops the smallest value?
> > 
> >     if not heap or item < heap[0]:
> >         return item
> >     return heapreplace(heap, item)

Scott David Daniels wrote:
> Better is:
>       if heap and heap[0] < item:
>           return heapreplace(heap, item)
>       return item

The or method short-circuits too.
>>> heap = []
>>> not heap or 7 < heap[0]
1
>>> 

 - Josiah


From ncoghlan at email.com  Wed Jun 16 13:42:03 2004
From: ncoghlan at email.com (Nick Coghlan)
Date: Thu Jun 17 09:06:10 2004
Subject: [Python-Dev] PEP 310 - A standard way to wrap objects?
Message-ID: <1087407723.40d0866b22307@mail.iinet.net.au>

After the recent discussion of resource acquisition, I went back and read PEP 
310 again myself.

Something that I wondered was whether it would be possible to include in the 
PEP a generic wrapper function that could be used inline in the 'with' 
statement.

That is, instead of resource control via lots of throwaway subclasses like this:

  class Resource_Foo(Foo):
    __exit__ = foo_done

  with myFoo = Resource_Foo(args):
    # Do stuff

We would have:

  with myFoo = resource(Foo(args), Foo.foo_done):
    # Do stuff

or

  with myFile = resource(file("bar.txt"), file.close):
    # Do stuff

or
  my_bar = Bar()
  with resource(my_bar, my_bar.start, my_bar.stop):
    # Do stuff

Having a recommended way to wrap objects which don't support the 'with' 
protocol natively would seem to be better than having everyone invent there own 
methodology.

Possible definition for the 'resource' function (this mechanism for adding the 
relevant methods has been tested in Python 2.2):

  def resource(obj, get_resource=None, free_resource):
    # Set up the enter method (if there is one)
    if get_resource:
      enter_obj = getattr(enter_meth, "im_self", None)
      if not enter_obj:
        # It's a function or unbound method
        obj.__enter__ = lambda: get_resource(obj)
      elif enter_obj is obj:
        # It's a bound method of our object
        obj.__enter__ = get_resource
      else:
        raise ValueError("Resource and bound enter method do not match")

    # Set up the exit method
    if not getattr(free_resource, "im_self", None):
      # It's a function or unbound method
      obj.__exit__ = lambda: free_resource(obj)
    elif free_resource.im_self is obj:
      # It's a bound method of our object
      obj.__exit__ = free_resource
    else:
      raise ValueError("Resource and bound exit method do not match")

    # Return the object so that we can use the assignment
    # form of the 'with' statement
    return obj

Regards,
Nick.

-- 
Nick Coghlan
Brisbane, Australia

From mchermside at ingdirect.com  Wed Jun 16 14:25:04 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Thu Jun 17 09:54:24 2004
Subject: [Python-Dev] Candidate Itertools
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550A77@ingdexj1.ingdirect.com>

Raymond Hettinger writes:
> Feedback is requested for two prospective itertools:
> 
> def count_elements(iterable):
>     b = {}
>     for elem in iterable:
>         b[elem] = b.get(elem, 0) + 1
>     return ((cnt, elem) for elem, cnt in b.iteritems())

Is the behavior of count_elements() exactly the same as
the given python equivalent when one (or more) of the
elements in the iterable is not hashable?

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From python at rcn.com  Wed Jun 16 06:49:24 2004
From: python at rcn.com (Raymond Hettinger)
Date: Thu Jun 17 10:01:49 2004
Subject: [Python-Dev] Candidate Itertools
In-Reply-To: <0CFFADBB825C6249A26FDF11C1772AE1550A77@ingdexj1.ingdirect.com>
Message-ID: <002201c4538f$96bcc980$bfaf2c81@oemcomputer>

> > def count_elements(iterable):
> >     b = {}
> >     for elem in iterable:
> >         b[elem] = b.get(elem, 0) + 1
> >     return ((cnt, elem) for elem, cnt in b.iteritems())

[Michael Chermside]
> Is the behavior of count_elements() exactly the same as
> the given python equivalent when one (or more) of the
> elements in the iterable is not hashable?

That was the original idea; however, we could easily keep a separate
list of identity comparisons for unhashables:

b = {}
keys = []
counts = []
for elem in iterable:
    try:
        b[elem] = b.get(elem, 0) + 1
    except TypeError:
        i = keys.find(elem)
        if i == -1:
            keys.append(elem)
            counts.append(1)
        else:
            counts[i] += 1
return zip(counts, keys) + tuple(pairwise(b.iteritems()))



Raymond Hettinger


From guido at python.org  Thu Jun 17 11:43:15 2004
From: guido at python.org (Guido van Rossum)
Date: Thu Jun 17 11:43:28 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: Your message of "Wed, 16 Jun 2004 15:15:27 MDT."
	<200406162115.i5GLFRrb050850@chilled.skew.org> 
References: <200406162115.i5GLFRrb050850@chilled.skew.org> 
Message-ID: <200406171543.i5HFhFY04716@guido.python.org>

> M.-A. Lemburg wrote:
> > Now that more and more codecs become available and the scope
> > of those codecs goes far beyond only encoding from Unicode to
> > strings and back, I am tempted to open up that restriction,
> > thereby opening up u.encode() for applications that wish to
> > use other codecs that return e.g. Unicode objects as well.
> > [...]
> > Note that codecs are not restricted in what they can return
> > for their .encode() or .decode() method, so any object
> > type is acceptable, including subclasses of str or
> > unicode, buffers, mmapped files, etc.
> 
> +1. I find it surprising that the restriction exists. I would have
> thought u.encode('foo') would pretty transparently wrap the foo
> codec's .encode().
> 
> This is also a good reminder that type checking of the result of
> codec or unicode .encode() calls is prudent, anytime.

May I make one tiny objection?  I don't know if it's enough to stop
this (I value it at -0.5 at most), but this will make reasoning about
types harder.  Given that approaches like StarKiller and IronPython
are likely the best way to get near-C speed for Python, I'd like the
standard library at least to make life eacy for their approach.

The issue is that currently the type inferencer can know that the
return type of u.encode(s) is 'unicode', assuming u's type is
'unicode'.  But with the proposed change, the return type will depend
on the *value* of s, and I don't know how easy it is for the type
inferencers to handle that case -- likely, a type inferencer will have
to give up and say it returns 'object'.

(I've never liked functions whose return type depends on the value of
an argument -- I guess my intuition has always anticipated type
inferencing. :-)

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

From FBatista at uniFON.com.ar  Wed Jun 16 14:35:42 2004
From: FBatista at uniFON.com.ar (Batista, Facundo)
Date: Thu Jun 17 13:00:19 2004
Subject: [Python-Dev] PEP 327 (Decimal data type) updated and status
Message-ID: <A128D751272CD411BC9200508BC2194D03383A3C@escpl.tcp.com.ar>

There's a new version of the PEP at

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

This one includes a lot of fixes, the results of the last discussion in
python-dev, and a new section: Documentation, which includes all the methods
and attributes available (with examples!).

Enjoy it!  Any feedback is welcomed.

This PEP was send to a re-review to Tim Peters.  In parallel, I continued to
work on the code.

When Tim approves the PEP, I'll make the code and test cases comply with it.
I'll let you know when I finish.

Thank you!

.	Facundo


From listuser at br.logorrhea.com  Wed Jun 16 17:13:34 2004
From: listuser at br.logorrhea.com (Patrick Stinson)
Date: Thu Jun 17 13:23:58 2004
Subject: [Python-Dev] (no subject)
Message-ID: <200406161313.34568.listuser@br.logorrhea.com>

if you had a hex string like 
'0x7c'
how would you convert it to an int?

int(0x7c) works, but not int('0x7c')

From arigo at tunes.org  Thu Jun 17 14:03:25 2004
From: arigo at tunes.org (Armin Rigo)
Date: Thu Jun 17 14:21:44 2004
Subject: [Python-Dev] heapq API
In-Reply-To: <002001c45058$b381f840$dab7958d@oemcomputer>
References: <002001c45058$b381f840$dab7958d@oemcomputer>
Message-ID: <20040617180325.GA20108@vicky.ecs.soton.ac.uk>

Hello Raymond,

On Sat, Jun 12, 2004 at 04:38:56AM -0400, Raymond Hettinger wrote:
> def heapiter(heap):
>     "Return a destructive iterator over the heap's elements,
> smallest-to-largest"

Is there a reason why the heap cannot simply be made iterable?
The suggested heapiter() is destructive, but e.g. sys.stdin is also
destructively iterable, so that would not be unprecedented.
Alternatively, would a non-destructive algorithm be significantly slower or
bad for some other reason?


Armin

From tjreedy at udel.edu  Wed Jun 16 22:06:25 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu Jun 17 15:54:50 2004
Subject: [Python-Dev] Re: VC 7.1 maintenance?
References: <40D0AEAE.5000606@egenix.com> <E1BakeY-00026a-00@deer.gmane.org>
Message-ID: <caqub4$pol$1@sea.gmane.org>


"Tim Peters" <tim.one@comcast.net> wrote in message
news:E1BakeY-00026a-00@deer.gmane.org...
> [M.-A. Lemburg]
> > Are we going to have a VC7.1 binary of Python 2.4 for Windows ?
>
> That's indeed my understanding of The Plan today.  More, we will not have
a
> VC6 binary for Python 2.4.  That may be controversial, but nobody has
> volunteered to produce an installer for a VC6 version.

Just today, I got the announcement of this:
http://www.joelonsoftware.com/articles/APIWar.html
which has a link to this
http://msdn.microsoft.com/visualc/vctoolkit2003/
which describes the free download for Microsoft Visual C++ Toolkit 2003 .

Is VC2003 a fancier name for VC7.1? or at least binary compatible?
Will this allow people to compile extensions without $$ to MS?

Terry J. Reedy




From tjreedy at udel.edu  Thu Jun 17 15:57:26 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu Jun 17 15:57:40 2004
Subject: [Python-Dev] Re: (no subject)
References: <200406161313.34568.listuser@br.logorrhea.com>
Message-ID: <cast39$o07$1@sea.gmane.org>


"Patrick Stinson" <listuser@br.logorrhea.com> wrote in message
news:200406161313.34568.listuser@br.logorrhea.com...
> if you had a hex string like
> '0x7c'
> how would you convert it to an int?
>
> int(0x7c) works, but not int('0x7c')

Usage questions like this belong on comp.lang.python or the corresponding
mailing list, not on the development list.  In addition, you should give a
subject heading, something like 'Int from hex string'.  '(no subject)'
makes your posting look like possible spam, and it invites people who pick
and choose threads to skip on to the next.

Terry J. Reedy




From judson at mcs.anl.gov  Thu Jun 17 16:03:46 2004
From: judson at mcs.anl.gov (Ivan R. Judson)
Date: Thu Jun 17 16:04:00 2004
Subject: [Python-Dev] Re: VC 7.1 maintenance?
In-Reply-To: <caqub4$pol$1@sea.gmane.org>
Message-ID: <200406172003.i5HK3t872750@mcs.anl.gov>


> Just today, I got the announcement of this:
> http://www.joelonsoftware.com/articles/APIWar.html
> which has a link to this
> http://msdn.microsoft.com/visualc/vctoolkit2003/
> which describes the free download for Microsoft Visual C++ 
> Toolkit 2003 .
> 
> Is VC2003 a fancier name for VC7.1? or at least binary compatible?
> Will this allow people to compile extensions without $$ to MS?

The free download is the compiler and linker and basic tools to build apps.
The part that costs money is the Visual Studio Development Environment (the
IDE and higher level tools), however I can find the concrete details if you
want them.

--Ivan


From mzarate at uoguelph.ca  Thu Jun 17 15:56:57 2004
From: mzarate at uoguelph.ca (Martin Zarate)
Date: Thu Jun 17 18:17:28 2004
Subject: [Python-Dev] functions decorators in 2.4?
Message-ID: <1087502217.40d1f78964f3a@webmail.uoguelph.ca>

Why not use the underused "as" keyword for decorators?

That is,

def foo(bar, baz) as StaticMethod:

It would be very handy for classes, as I've worked with custom class 
structures (such as an overcomplicated interface-based structure that I was 
experimenting with) that it would be useful for.

Are there plans to extend this to fully custom blocks and statements like in 
Ruby?  Or will it only be for modified def and class statements?

From bac at OCF.Berkeley.EDU  Thu Jun 17 18:50:31 2004
From: bac at OCF.Berkeley.EDU (Brett)
Date: Thu Jun 17 18:52:30 2004
Subject: [Python-Dev] python-dev Summary for 2004-06-01 through 2004-06-15
	[draft]
Message-ID: <BC929538-C0B0-11D8-AE40-0003931A4158@ocf.berkeley.edu>

I plan on sending this summary out this weekend, so please get any  
edits in by then.

And don't get too used this level of turn-around; I just haven't  
started work yet and I am not in the mood to start coding my thesis.   
=)

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

Summary Announcements
=====================
Wow, two summaries written in a single week.  Hell has not frozen over,  
don't worry; work has just not started yet.  =)

Summaries
=========
--------------------------------
New PEP on bytecode verification
--------------------------------
As it stands now, unless you are running a debug build of Python, there  
are no checks that the bytecode being executed by the interpreter is  
valid.  It is not terribly difficult to crash the interpreter with  
blatently invalid bytecode.

In an attempt to resolve this, `PEP 330`_ has been written in hopes of  
coming up with a Python module in the stdlib that can have bytecode  
passed to it and attempt to perform some basic verification on it.

.. _PEP 330: http://python.org/peps/pep-0300.html

Contributing threads:
   - `PEP 330 Python bytecode verification  
<http://mail.python.org/pipermail/python-dev/2004-June/045082.html>`__

--------------------
2.4a1 coming up soon
--------------------
Python 2.4a1 should be coming out early July.  If you have some bugs or  
patches you want to see in 2.4 then reads Anthony's announcement email  
for general guidelines on how to go about this.

Jeremy Hylton pointed out that since the AST branch did not make it in  
before this announcement it would not be included in 2.4 (thus  
guaranteeing a sprint topic for PyCON 2005).  Generator expressions  
*are* in this alpha with late bindings; if early binding would work  
better in your code after trying late binding then speak up since the  
semantics can change.

Contributing threads:
   - `pre-announce: Python 2.4a1 is about a month away  
<http://mail.python.org/pipermail/python-dev/2004-May/045028.html>`__

--------------------------------------------------
The shaky courtship of 2.4 and function decorators
--------------------------------------------------
With 2.4a1 ominously approaching on the horizon, Guido asked what  
people thought of holding off on including function decorators for 2.5.  
  Some people said to put it in and if that meant using Guido's, then so  
be it.  Others said to wait and let Guido have more time since he  
wanted to consider Java 1.5's syntax.

Guido said he would ask at EuroPython_ for more opinions.

.. EuroPython: http://www.europython.org/

Contributing threads:
   - `functions decorators in 2.4?  
<http://mail.python.org/pipermail/python-dev/2004-June/045124.html>`__
   - `Dropping decorator syntax for 2.4?  
<http://mail.python.org/pipermail/python-dev/2004-June/045125.html>`__

-----------------------------------------------------------
Why Stackless is not about to be incorporated into the core
-----------------------------------------------------------
Someone asked why Stackless_ is still not part of the Python core.   
After a bunch of talking, Guido spelled out a couple of reasons.  One  
was a lack of a clear spec; if it is not obvious how it will behave it  
can't go in.  Another was whether it could reasonably work on Jython;  
Python the language needs to be portable enough to be coded in C or  
Java.  A third point was not wanting to rely on platform hacks in order  
for something to work; Stackless doesn't use the C stack and that can  
complicate things (and Guido put longjmp() from ISO C in this category  
so don't ever think of using it in a patch).

In other words Stackless is not going to be integrated into the core at  
this time.

.. _Stackless: http://www.stackless.com/

Contributing threads:
   - `Stackless Python  
<http://mail.python.org/pipermail/python-dev/2004-June/045074.html>`__
   - `Re: Stackless Python  
<http://mail.python.org/pipermail/python-dev/2004-June/045098.html>`__

------------------------------------------------------
Remember, some stdlib modules are maintained elsewhere
------------------------------------------------------
Greg Ward reminded python-dev that optparse is maintained as Optik_ and  
as a separate project.  Some other modules are also maintained like  
this, so it is something to keep an eye out for if you are writing  
patches or reporting a bug.

.. _Optik: http://optik.sf.net/

Contributing threads:
   - `Reminder: optparse.py is auto-generated  
<http://mail.python.org/pipermail/python-dev/2004-June/045176.html>`__

--------------
Python Bug Day
--------------
The First Python Bug Day took place on June 5th, led by AM Kuchling.   
The end results are listed at  
http://www.python.org/moin/PythonBugDayStatus and look very good.

Since SF troubles cropped up during the day (both frustration with  
people not being able to add files to bugs and patches created by other  
people and SF CVS going down), discussion of getting off of SF came up  
(this was also mentioned in several other minor threads).  The desire  
to host off-site were brought up, but the issue of having enough  
volunteers to handle the load of managing a CVS or Subbversion  
repository was brought up.  Also moving over to Roundup or GForge on a  
server under out control was also brought up.  Nothing looks like it is  
going to happen any time soon, though (at least not until 2.4 is out  
the door).

The next Bug Day has been tentatively scheduled for July 10.

Contributing threads:
   - `Python bug day?  
<http://mail.python.org/pipermail/python-dev/2004-June/045090.html>`__
   - `Bug day outcome  
<http://mail.python.org/pipermail/python-dev/2004-June/045235.html>`__

----------------------------------------------------------
What it takes to have something to support weak references
----------------------------------------------------------
(should have been in last summary)
Why don't strings and such support weak references?  Turns out that  
variable-sized objects (i.e., tp_itemsize specified) cannot support  
them without direct support hard-coded in the struct.  Since it would  
require more space and extra code for deallocation to add support for  
things such as strings and tuples, it is not going to be added to them,  
especially since they are immutable already.

Contributing threads:
   - `Why aren't more things weak referencable  
<http://mail.python.org/pipermail/python-dev/2004-May/045006.html>`__

-------------------------
Heterogeneous comparisons
-------------------------
The list was reminded that in the future at some point, comparisons  
between heterogeneous types will raise TypeError sans '==' and '!='.   
This brought up the discussion of comparing floats to longs.  Guido  
said he is going to make sure that they can still be compared without  
issue (part of the reason true division was introduced).  People talked  
about the best way to go about it, but it was mostly just talk since  
this is not about to go into the core.

Contributing threads:
   - `Comparing heterogeneous types  
<http://mail.python.org/pipermail/python-dev/2004-June/045111.html>`__

-----------------------
Finalizing Decimal type
-----------------------
Facundo Batista posted an email summing up the last nagging features  
for the Decimal type and `PEP 327`_.  He said he would send another  
draft to Tim Peters for a quick look and then post basically the final  
PEP (doesn't look like that has happened, though

.. _PEP 327: http://python.org/peps/pep-0327.html

Contributing threads:
   - `Decimal issues - Conclusion  
<http://mail.python.org/pipermail/python-dev/2004-June/045209.html>`__

---------------
Free Icon books
---------------
Tim Peters posted links to links to PDFs of three significant books on  
Icon_ (see the email for the links).

Why would Python programmers care about the Icon programming language?   
Well, Python got the idea of generators from Icon.  Plus it never hurts  
to know more languages, if anything just for new ideas for Python or to  
be able to emphatically state Python is better.  =)

.. _Icon: http://www.cs.arizona.edu/icon/

Contributing threads:
   - `Free Icon books  
<http://mail.python.org/pipermail/python-dev/2004-June/045231.html>`__

----------------------------------------
Documenting undocumented C API functions
----------------------------------------
Thomas Heller updated Doc/tools/undoc_symbols.py (which finds out what  
C API code is undocumented) and ran it.  The list of undocumented C  
code is listed at  
http://starship.python.net/crew/theller/moin.cgi/ 
Documenting_25CorePythonApiFunctions .  If you would like to help with  
documenting, helping with documenting what is listed at the wiki would  
be great.

Contributing threads:
   - `undocumented api functions  
<http://mail.python.org/pipermail/python-dev/2004-June/045308.html>`__

---------------------------------------------
Tool for side-by-side diffs outputted in HTML
---------------------------------------------
http://www.python.org/sf/914575 has a patch that adds the necessary  
code and a tool script for side-by-side diffs using difflib that output  
in a nice HTML format.  While the code has not been accepted yet, I  
personally know how useful this functionality can be so I thought I  
would just let people know about the code.

And if you find this code helpful, then doing a code review and adding  
a comment on the patch would be helpful in getting the code accepted.

Contributing threads:
   - `Side by Side Differencing Patch  
<http://mail.python.org/pipermail/python-dev/2004-June/045304.html>`__
   - `HTML side by side diff patch 914575  
<http://mail.python.org/pipermail/python-dev/2004-June/045361.html>`__

-----------------------------------
Removing CLRFs in PCbuild directory
-----------------------------------
Martin v. Lowis fixed the vcproj files in the PCbuild directory to have  
the proper line endings.  Problem is that you must run ``cvs update  
-A`` on your PCbuild directory to add the -kb tag on the files since it  
is a sticky tag.

Contributing threads:
   - `Changing PCBuild/*.vcproj to text mode  
<http://mail.python.org/pipermail/python-dev/2004-June/045401.html>`__

--------------------------------------------------------
Bounding free list creation for ints and such ain't easy
--------------------------------------------------------
Bounding the size of the memory used by ints and other built-ins that  
have a custom allocator was brought up.  The suggestion of moving them  
to pymalloc was suggested, but it was pointed out it would make it  
slower and waste more space on some platforms.  And the ideas on how to  
deal with this all seemed difficult.  No code was committed in the end.

Contributing threads:
   - `Object free lists  
<http://mail.python.org/pipermail/python-dev/2004-June/045403.html>`__

-------------------------------------
How to search the python-dev archives
-------------------------------------
One idea is to use gmane.org to do your searches since they index the  
mailing list.  The one that I (and apparently Tim Peters) use is to do  
a Google search with ``site:mail.python.org python-dev`` at the  
beginning.  I actually search the python-dev archives using the same  
technique; ``site:www.python.org "python-dev Summary"``.

Contributing threads:
   - `python-dev archive searching ?  
<http://mail.python.org/pipermail/python-dev/2004-June/045325.html>`__


From dan.gass at gmail.com  Fri Jun 18 02:31:16 2004
From: dan.gass at gmail.com (Dan Gass)
Date: Fri Jun 18 03:10:28 2004
Subject: [Python-Dev] HTML side by side diff patch 914575
In-Reply-To: <003201c45163$8bad0240$7e32c797@oemcomputer>
References: <003201c45163$8bad0240$7e32c797@oemcomputer>
Message-ID: <bc15ba280406172331235ddc8a@mail.gmail.com>

Raymond,

I'm attaching two samples of the latest side by side differencing HTML
output from/of the difflib.py patch.  If you get the chance, look at
the samples at let me know what you think of how they look/function. 
The samples themselves show the patched code.  I'm hoping some HTML
experts see this and can offer some tips on improving it (I would be
tickled if someone could tell me how to force the browser to select
text from a single column -- right now a selection over multiple lines
gets text from all the columns).

The HTML output is alot less sensitive to browser quirks and I think
looks better than what I previously had (I took some color schemes
from viewCVS).  I have simplified the user interface ALOT without
sacrificing flexibility which will also make writing the required
documentation more manageable.

I looked at the output on IE, Mozilla, and Konquerer.  Konquerer gave
some extra grid lines between all the rows which was annoying but the
other two looked great.

> If you can, get it in soon to avoid getting to close to the alpha
> release date.

I will try to get something to you soon.  I mainly have comment and
coding convention cleanup to do.  Barring no major changes, no later
than the end of June.

> Please segregate all of this stuff in a single section devoted to
> configuration and make it easy to change without affecting the rest of
> the implementation logic.

Hopefully the reorganization using a new style class for HTML
differencing addresses this.  If not I will need to talk to you a bit
more to see what you have in mind.

Regards,
Dan Gass
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samples.zip
Type: application/x-zip-compressed
Size: 14453 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040618/53daf165/samples.bin
From Scott.Daniels at Acm.Org  Fri Jun 18 03:13:15 2004
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Fri Jun 18 03:16:35 2004
Subject: [Python-Dev] Re: heapq API
In-Reply-To: <E1Bazji-0007Ab-49@sodium.pdx.net>
References: <E1Bazji-0007Ab-49@sodium.pdx.net>
Message-ID: <40D2960B.4060807@Acm.Org>

 > Josiah Carlson wrote:
 > Scott David Daniels wrote:
 >> Raymond Hettinger wrote:
 >>>    if not heap or item < heap[0]:
 >>>         return item
 >>>     return heapreplace(heap, item)
 >> Better is:
 >>       if heap and heap[0] < item:
 >>           return heapreplace(heap, item)
 >>       return item
 > The or method short-circuits too....

Sorry, I was (inadvertently) being cryptic:

I was avoiding the heapreplace call if item == heap[0].
Since "<" is the native ordering comparison, I reordered
the comparison to continue using "<".

While I was rearranging I dropped the "not" which was
probably a useless micro-optimization, but I usually
avoid not for clarity for myself these days.  I wouldn't
presume to correct just to fiddle out the not.

For the list, I'd probably have done better simply to write:
 > ...
 > Better is:
 >    if not heap or item <= heap[0]:
 >         return item
 >    return heapreplace(heap, item)
 > because you want to avoid calling heapreplace if possible.

-- 
-Scott David Daniels
Scott.Daniels@Acm.Org

From ark-mlist at att.net  Fri Jun 18 11:30:45 2004
From: ark-mlist at att.net (Andrew Koenig)
Date: Fri Jun 18 11:31:45 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <0CFFADBB825C6249A26FDF11C1772AE1550A9B@ingdexj1.ingdirect.com>
Message-ID: <003601c45549$399cfde0$6602a8c0@arkdesktop>

Michael Chermside cites Armin Rigo:

> Armin Rigo writes:
> > Is it really what we want?  It seems to me that the precision
> > of a float gives roughly the magnitude of "uncertainty" of the
> > value that it represents.  If a float is large enough, then the
> > same float can represent several long integer values.  It should
> > then probably be considered equal to any of these integers,
> > instead of just equal to the one arbitrarily returned by
> > casting it to long.

> I think that what you describe is NOT the behavior that we
> want, and I'll try to give an explanation of why. But please
> bear with me... I'm still a beginner at understanding some
> of the theory behind numerical computing, so I may make some
> mistakes. Hopefully those who understand it better will
> correct me.

I'm not going to correct you--rather, I'd like to amplify what you're saying
by noting that you don't even need to resort to numerical computing to make
the argument.

There's a much simpler line of reasoning:  Sort and other related algorithms
can be made to work reliably only if they have recourse to a total order
relation over the elements being sorted.  A total order relation is one for
which exactly one of x<y, x==y, y<x holds for any x and y, and for which <,
==, and > are transitive, == is reflexive and symmetric, and < and > are
irreflexive and antisymmetric.  In other words, x==y if and only if y==x,
x==y and y==z implies x==z, x<y and y<z implies x<z, and x>y and y>z implies
x>z.

If a float is considered equal to more than one integer, then these
requirements fail, because if x is such a float, there are two integers m
and n such that x==m, x==n, and m!=n.  In other words, equality is not
transitive.  You can't sort numbers reliably under such circumstances.

> There are (at least) two different mental models we can use to
> deal with this limitation of finite precision. One (which you
> are espousing above) is to treat each limited-precision
> number as if it had an inherent uncertainty, and it represented
> all those numbers which are closer to that representable
> number than any other. The other mental model is to suppose
> that each limited-precision number represents just one
> specific value and that the other values simply cannot be
> represented.

Yes.  And as I understand it, that is the school of thought that
computational numerical analysts are more likely to adopt these days.  Such
thinking, for example, gives rise to the requirement in IEEE floating-point
that the primitive operations (+, -, /, *, and square root) must give
results that are exactly equal to the infinite-precision results after
rounding.



From jhylton at gmail.com  Thu Jun 17 21:59:42 2004
From: jhylton at gmail.com (Jeremy Hylton)
Date: Fri Jun 18 13:59:52 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <200406171543.i5HFhFY04716@guido.python.org>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>
	<200406171543.i5HFhFY04716@guido.python.org>
Message-ID: <e8bf7a53040617185929301051@mail.gmail.com>

On Thu, 17 Jun 2004 08:43:15 -0700, Guido van Rossum <guido@python.org> wrote:
> 
> The issue is that currently the type inferencer can know that the
> return type of u.encode(s) is 'unicode', assuming u's type is
> 'unicode'.  But with the proposed change, the return type will depend
> on the *value* of s, and I don't know how easy it is for the type
> inferencers to handle that case -- likely, a type inferencer will have
> to give up and say it returns 'object'.

Who cares about the type inference <0.2 wink>.  It's harder for the
reader of the program to understand if encode() returns a different
type.  Would there be some common property that all encode() return
values would share?  Can't think of one myself.

Jeremy

From fdrake at acm.org  Fri Jun 18 14:17:01 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri Jun 18 15:28:26 2004
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Doc/dist
	dist.tex, 1.77, 1.78
In-Reply-To: <E1BbND5-0000q6-4Z@sc8-pr-cvs1.sourceforge.net>
References: <E1BbND5-0000q6-4Z@sc8-pr-cvs1.sourceforge.net>
Message-ID: <200406181417.01724.fdrake@acm.org>

On Friday 18 June 2004 01:31 pm, theller@users.sourceforge.net wrote:
 > Modified Files:
 > 	dist.tex
 > Log Message:
 > Fix an obvious typo (It *is* a typo, or not?)

Indeed it is!  Thanks.


  -Fred

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


From bac at OCF.Berkeley.EDU  Thu Jun 17 17:37:38 2004
From: bac at OCF.Berkeley.EDU (Brett)
Date: Sun Jun 20 23:24:27 2004
Subject: [Python-Dev] tp_(get|set)attro? inheritance bug?
In-Reply-To: <1086976687.11716.52.camel@spectrum.inescn.pt>
References: <1086976687.11716.52.camel@spectrum.inescn.pt>
Message-ID: <8DBDC610-C0A6-11D8-AE40-0003931A4158@ocf.berkeley.edu>

Did an SF bug report ever get filed for this?

On Jun 11, 2004, at 10:58, Gustavo J. A. M. Carneiro wrote:

>   Documentation says, regarding tp_getattr:
> ?
> This field is inherited by subtypes together with tp_getattro: a 
> subtype
> inherits both tp_getattr and tp_getattro from its base type when the
> subtype's tp_getattr and tp_getattro are both NULL.
> ?
>
>   Implementation disagrees, at least in cvs head, but the effect of the
> bug (non-inheritance of tp_getattr) happens in 2.3.3.  Follow with me:
>
> In function type_new (typeobject.c) line 1927:
> 	/* Special case some slots */
> 	if (type->tp_dictoffset != 0 || nslots > 0) {
> 		if (base->tp_getattr == NULL && base->tp_getattro == NULL)
> 			type->tp_getattro = PyObject_GenericGetAttr;
> 		if (base->tp_setattr == NULL && base->tp_setattro == NULL)
> 			type->tp_setattro = PyObject_GenericSetAttr;
> 	}
> ...later in the same function... line
>
> 	/* Initialize the rest */
> 	if (PyType_Ready(type) < 0) {
> 		Py_DECREF(type);
> 		return NULL;
> 	}
>
> Inside PyType_Ready(), line 3208:
> 	for (i = 1; i < n; i++) {
> 		PyObject *b = PyTuple_GET_ITEM(bases, i);
> 		if (PyType_Check(b))
> 			inherit_slots(type, (PyTypeObject *)b);
> 	}
>
> Inside inherit_slots, line (3056):
> 	if (type->tp_getattr == NULL && type->tp_getattro == NULL) {
> 		type->tp_getattr = base->tp_getattr;
> 		type->tp_getattro = base->tp_getattro;
> 	}
> 	if (type->tp_setattr == NULL && type->tp_setattro == NULL) {
> 		type->tp_setattr = base->tp_setattr;
> 		type->tp_setattro = base->tp_setattro;
> 	}
>
>   So, if you have followed through, you'll notice that type_new first
> sets tp_getattro = GenericGetAttr, in case 'base' has neither 
> tp_getattr
> nor tp_getattro.
>   So, you are thinking that there is no problem.  If base has
> tp_getattr, that code path won't be execute.  The problem is with
> multiple inheritance.  In type_new, 'base' is determined by calling
> best_base().  But the selected base may not have tp_getattr, while
> another might have.  In this case, setting tp_getattro based on
> information from the wrong base precludes the slot from being inherited
> from the right base.  This is happening in pygtk, unfortunately.
>
>   One possible solution would be to move the first code block to after
> the PyType_Ready() call.
>
> -- 
> Gustavo Jo?o Alves Marques Carneiro
> <gjc@inescporto.pt> <gustavo@users.sourceforge.net>
> The universe is always one step beyond logic.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/brett%40python.org


From Paul.Moore at atosorigin.com  Fri Jun 18 04:13:43 2004
From: Paul.Moore at atosorigin.com (Moore, Paul)
Date: Sun Jun 20 23:27:52 2004
Subject: [Python-Dev] Re: VC 7.1 maintenance?
Message-ID: <16E1010E4581B049ABC51D4975CEDB88052CB1E1@UKDCX001.uk.int.atosorigin.com>

From: Ivan R. Judson
>> Is VC2003 a fancier name for VC7.1? or at least binary compatible?
>> Will this allow people to compile extensions without $$ to MS?

> The free download is the compiler and linker and basic tools to build apps.
> The part that costs money is the Visual Studio Development Environment (the
> IDE and higher level tools), however I can find the concrete details if you
> want them.

The problem for Python development is that the free download VC doesn't
support linking to the DLL verstion of the CRT (msvcr71). This means that
there will still be CRT incompatibilities if extensions are built with this
compiler :-(

Mingw is another option, as the latest version of mingw allows building DLLs
which link to msvcr71, but it's pretty bleeding-edge, and I haven't been able
to do much work yet on proving the relevant distutils support is there, as I
don't have an up-to-date Python binary build. I'm planning on doing some
testing when 2.4a1 comes out...

Paul.


__________________________________________________________________________
This e-mail and the documents attached are confidential and intended 
solely for the addressee; it may also be privileged. If you receive this 
e-mail in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group 
liability cannot be triggered for the message content. Although the 
sender endeavours to maintain a computer virus-free network, the sender 
does not warrant that this transmission is virus-free and will not be 
liable for any damages resulting from any virus transmitted.
__________________________________________________________________________

From gmccaughan at synaptics-uk.com  Fri Jun 18 09:03:52 2004
From: gmccaughan at synaptics-uk.com (Gareth McCaughan)
Date: Sun Jun 20 23:28:31 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <200406171543.i5HFhFY04716@guido.python.org>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>
	<200406171543.i5HFhFY04716@guido.python.org>
Message-ID: <200406181403.53023.gmccaughan@synaptics-uk.com>

On Thursday 2004-06-17 16:43, Guido van Rossum wrote:

[MAL proposed that restrictions on the "encode" method should
be lifted...]

> May I make one tiny objection?  I don't know if it's enough to stop
> this (I value it at -0.5 at most), but this will make reasoning about
> types harder.  Given that approaches like StarKiller and IronPython
> are likely the best way to get near-C speed for Python, I'd like the
> standard library at least to make life easy for their approach.
> 
> The issue is that currently the type inferencer can know that the
> return type of u.encode(s) is 'unicode', assuming u's type is
> 'unicode'.

Um, you don't mean that. u"foo".encode() == "foo", of type str.

>             But with the proposed change, the return type will depend
> on the *value* of s, and I don't know how easy it is for the type
> inferencers to handle that case -- likely, a type inferencer will have
> to give up and say it returns 'object'.

When looking for near-C speed, type inferencing is most important
for a relatively small set of particularly efficiently manipulable
types: most notably, smallish integers. Being able to prove that
something is a Unicode object just isn't all that useful for
efficiency, because most of the things you can do to Unicode
objects aren't all that cheap relative to the cost of finding out
what they are. Likewise, though perhaps a bit less so, for being
able to prove that something is a string.

At least, so it seems to me. Maybe I'm wrong. I suppose the
extract-one-character operation might be used quite a bit,
and that could be cheap. But I can't help feeling that
occasions where (1) the compiler can prove that something
is a string because it comes from calling an "encode" method,
(2) it can't prove that any other way, (3) this makes an
appreciable difference to the speed of the code, and (4)
there isn't any less-rigorous (Psyco-like, say) way for
the type to be discovered and efficient code used, are
likely to be pretty rare, and in particular rare enough
that supplying some sort of optional type declaration
won't be unacceptable to users. (I bet that any version
of Python that achieves near-C speed by doing extensive
type inference will have optional type declarations.)

The above paragraph, of course, presupposes that we keep
the restriction on the return value of u.encode(s), and
start enforcing it so that the compiler can take advantage.

> (I've never liked functions whose return type depends on the value of
> an argument -- I guess my intuition has always anticipated type
> inferencing. :-)

def f(x): return x+x

has that property, even if you pretend that "+" only works
on numbers.

-- 
g


From kbk at shore.net  Thu Jun 17 19:41:36 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sun Jun 20 23:28:48 2004
Subject: [Python-Dev] Weekly Python Bug/Patch Summary (2nd try)
Message-ID: <871xkdvjkf.fsf@hydra.localdomain>


[The first posting of this report has not appeared on python-dev though
it was accepted by the mail server 20 hrs ago]

Jun 16 23:48:24 hydra sm-mta[21306]: i5H3m2l6025771: to=<python-dev@python.org>, d
elay=00:00:22, xdelay=00:00:22, mailer=esmtp, pri=30371, relay=mail.python.org. [1
2.155.117.29], dsn=2.0.0, stat=Sent (OK id=1Bansp-0001jb-Kg)


Patch / Bug Summary
___________________

Patches :  276 open ( +2) /  2415 closed (+14) /  2691 total (+16)
Bugs    :  741 open (-21) /  4156 closed (+62) /  4897 total (+41)
RFE     :  140 open ( +2) /   129 closed ( +1) /   269 total ( +3)

New / Reopened Patches
______________________

Fix to minor spelling error in exception in int_subtype_new  (2004-06-05)
CLOSED http://python.org/sf/967057  opened by  Aaron Brady 

fix bsddb memory leaks  (2004-06-06)
       http://python.org/sf/967763  opened by  Neal Norwitz 

Add fileinput.islastline()  (2004-06-07)
       http://python.org/sf/968063  opened by  Relm Arrowny 

Py_HUGE_VAL HUGE_VAL HUGE undefined  (2004-06-08)
       http://python.org/sf/968728  opened by  Michael Schloh von Bennewitz 

hotshot incorrectly computes elapsed time  (2004-06-08)
CLOSED http://python.org/sf/969180  opened by  Jason Beardsley 

heapq.nlargest  (2004-06-09)
CLOSED http://python.org/sf/969791  opened by  Raymond Hettinger 

str(a_tuple) == str(tuple(map(str,a_tuple)))  (2004-06-09)
CLOSED http://python.org/sf/969805  opened by  Gr?goire Dooms 

cookielib doc minor corrections and clarifications  (2004-06-09)
       http://python.org/sf/969900  opened by  John J Lee 

cookielib.py   (2004-06-09)
       http://python.org/sf/969907  opened by  John J Lee 

Generate a working spec even with wrong version of software   (2004-06-10)
       http://python.org/sf/970015  opened by  Scherer Michael 

Use a better BuildRoot tag  (2004-06-10)
       http://python.org/sf/970019  opened by  Scherer Michael 

Fix for #876637 - Random stack corruption from socketmodule  (2004-06-10)
       http://python.org/sf/970288  opened by  Troels Walsted Hansen 

Patch for feature request 491033  (2004-05-20)
       http://python.org/sf/957240  reopened by  mwh

make test_signal less annoying  (2004-06-11)
CLOSED http://python.org/sf/971323  opened by  Michael Hudson 

urllib2 handler algorithm docs  (2004-06-13)
       http://python.org/sf/972310  opened by  John J Lee 

urllib2 handler naming convention collision  (2004-06-14)
       http://python.org/sf/972322  opened by  John J Lee 

urllib2 FTPHandler bugs  (2004-06-14)
       http://python.org/sf/972332  opened by  John J Lee 

fix build of docs in info format  (2004-06-15)
       http://python.org/sf/972991  opened by  Matthias Klose 

Fix for compilation with runtime_library_dirs  (2004-06-15)
       http://python.org/sf/973204  opened by  Antti Honkela 

Patches Closed
______________

deprecate or fix buffer object  (2003-10-28)
       http://python.org/sf/832058  closed by  nascheme

cygwinccompiler should set C++ compiler  (2004-02-02)
       http://python.org/sf/888839  closed by  perky

Rewrite of site.py  (2004-03-23)
       http://python.org/sf/921793  closed by  bcannon

Fix to minor spelling error in exception in int_subtype_new  (2004-06-05)
       http://python.org/sf/967057  closed by  akuchling

CodeContext - an extension to show you where you are  (2004-04-16)
       http://python.org/sf/936169  closed by  kbk

Tk Dialog Upon Subprocess Socket Error  (2003-07-26)
       http://python.org/sf/778323  closed by  kbk

_socket fails to build with latest SGI compiler  (2004-01-27)
       http://python.org/sf/885905  closed by  nnorwitz

cycle profiler for VM opcodes  (2002-01-30)
       http://python.org/sf/510695  closed by  loewis

making Python LC_NUMERIC agnostic  (2003-07-20)
       http://python.org/sf/774665  closed by  loewis

hotshot incorrectly computes elapsed time  (2004-06-08)
       http://python.org/sf/969180  closed by  nnorwitz

str(a_tuple) == '(%s)'%', '.join(map(str,a_tuple))  (2004-06-09)
       http://python.org/sf/969805  closed by  dooms

Add nlargest() and nsmallest() to heapq.  (2004-06-09)
       http://python.org/sf/969791  closed by  rhettinger

make test_signal less annoying  (2004-06-11)
       http://python.org/sf/971323  closed by  mwh

cmath.log optional base argument, fixes #823209  (2003-10-18)
       http://python.org/sf/826074  closed by  rhettinger

Crash in binascii_a2b_uu on corrupt data  (2003-01-09)
       http://python.org/sf/665458  closed by  nnorwitz

Added Proxyauth command to imaplib  (2002-11-14)
       http://python.org/sf/638673  closed by  nnorwitz

New / Reopened Bugs
___________________

cgitb.scanvars fails  (2004-06-05)
CLOSED http://python.org/sf/966992  opened by  Robin Becker 

file("foo", "wU") is silently accepted  (2004-06-05)
       http://python.org/sf/967182  opened by  Skip Montanaro 

PythonWin fails reporting "Can not locate pywintypes23.dll   (2004-06-05)
CLOSED http://python.org/sf/967207  opened by  puffingbilly 

Cmd in thread segfaults after Ctrl-C  (2004-06-05)
       http://python.org/sf/967334  opened by  Kevin M. Turner 

PyInt_FromString failed with certain hex/oct  (2004-06-06)
CLOSED http://python.org/sf/967657  opened by  Qian Wenjie 

csv module cannot handle embedded \r  (2004-06-07)
       http://python.org/sf/967934  opened by  Gregory Bond 

file.encoding doesn't apply to file.write  (2004-06-07)
       http://python.org/sf/967986  opened by  Matthew Mueller 

Python Logging filename & file number   (2004-06-07)
       http://python.org/sf/968245  opened by  Ryan 

error flattening complex smime signed message  (2004-06-07)
       http://python.org/sf/968430  opened by  Ludovico Magnocavallo 

CJK codecs list incomplete  (2004-06-08)
       http://python.org/sf/969415  opened by  Mike Brown 

CJK codecs list incomplete  (2004-06-09)
       http://python.org/sf/969415  reopened by  perky

Python hangs up on I/O operations on the latest FreeBSD 4.10  (2004-06-09)
       http://python.org/sf/969492  opened by  _Iww_ 

BSD restartable signals not correctly disabled  (2004-06-09)
       http://python.org/sf/969574  opened by  Luke Mewburn 

BASECFLAGS are not passed to module build line  (2004-06-09)
       http://python.org/sf/969718  opened by  Jason Beardsley 

function and method objects confounded in Tutorial  (2004-06-09)
       http://python.org/sf/969757  opened by  Mark Jackson 

pydoc ignores module's __all__ attributes  (2004-06-09)
CLOSED http://python.org/sf/969938  opened by  Skip Montanaro 

lfcntl.lockf() signature uses len, doc refers to length  (2004-06-10)
CLOSED http://python.org/sf/970042  opened by  Clinton Roy 

2.3.4 fails build on solaris 10 - complexobject.c  (2004-06-10)
       http://python.org/sf/970334  opened by  JD Bronson 

Generators produce wrong exception  (2004-06-10)
CLOSED http://python.org/sf/970459  opened by  Anders Lehmann 

PyObject_GenericGetAttr is undocumented  (2004-06-10)
       http://python.org/sf/970783  opened by  Eric Huss 

Pyton 2.3.4 Make Test Fails on Mac OS X  (2004-06-10)
       http://python.org/sf/970799  opened by  D.  Evan Kiefer 

Comparisons of unicode and strings shouldn  (2004-06-11)
CLOSED http://python.org/sf/971101  opened by  Christian Theune 

Comparisons of unicode and strings raises UnicodeErrors  (2004-06-11)
CLOSED http://python.org/sf/971106  opened by  Christian Theune 

bizarro test_asynchat failure  (2004-06-11)
CLOSED http://python.org/sf/971200  opened by  Michael Hudson 

another threads+readline+signals nasty  (2004-06-12)
       http://python.org/sf/971213  opened by  Anthony Baxter 

test_timeout failure on trunk  (2004-06-12)
       http://python.org/sf/971238  opened by  Anthony Baxter 

test_signal sucks  (2004-06-11)
       http://python.org/sf/971330  opened by  Michael Hudson 

thread.name crashes interpreter  (2004-06-11)
CLOSED http://python.org/sf/971395  opened by  Jonathan Ellis 

Wrong indentation of example code in tutorial  (2004-06-12)
CLOSED http://python.org/sf/971747  opened by  Gr?goire Dooms 

An apparent bug in help  (2004-06-12)
       http://python.org/sf/971872  opened by  Colin J. Williams 

Generator mangles returned lists.  (2004-06-13)
CLOSED http://python.org/sf/971962  opened by  Ed Watkeys 

urllib2 raises exception with non-200 success codes.  (2004-06-13)
       http://python.org/sf/971965  opened by  Ed Watkeys 

local variables problem  (2004-06-14)
CLOSED http://python.org/sf/972467  opened by  Toon Verstraelen 

Python 2.3.4, Solaris 7, socketmodule.c does not compile  (2004-06-14)
       http://python.org/sf/972724  opened by  Bruce D. Ray 

attached script causes python segfault  (2004-06-15)
CLOSED http://python.org/sf/972917  opened by  Faheem Mitha 

bsddb in Python 2.3 incompatible with SourceNav output  (2004-06-15)
       http://python.org/sf/973054  opened by  gdy 

inspect.getframeinfo bug if 'context' is to big   (2004-06-15)
CLOSED http://python.org/sf/973092  opened by  Hans Georg Krauthaeuser 

empty raise after handled exception  (2004-06-15)
       http://python.org/sf/973103  opened by  Niki Spahiev 

sys.stdout problems with pythonw.exe  (2004-06-15)
       http://python.org/sf/973507  opened by  Manlio Perillo 

Doc error on super(cls,self)  (2004-06-15)
       http://python.org/sf/973579  opened by  David MacQuigg 

Bugs Closed
___________

cgitb.scanvars fails  (2004-06-05)
       http://python.org/sf/966992  closed by  akuchling

random.choice([]) should return more intelligible exception  (2004-06-01)
       http://python.org/sf/964230  closed by  rhettinger

2.3 inspect.getframeinfo wrong tb line numbers  (2004-05-15)
       http://python.org/sf/954364  closed by  akuchling

xmlrpclib chokes on Unicode keys  (2003-11-13)
       http://python.org/sf/841757  closed by  akuchling

HTMLParser ParseError in start tag  (2004-03-23)
       http://python.org/sf/921657  closed by  akuchling

cgi module documentation could mention getlist  (2004-05-13)
       http://python.org/sf/953177  closed by  akuchling

many os.path functions bahave inconsistently  (2004-04-04)
       http://python.org/sf/929316  closed by  akuchling

pty.spawn() leaks file descriptors  (2004-02-16)
       http://python.org/sf/897935  closed by  akuchling

PyNumber_InPlaceDivide()'s description  (2004-04-17)
       http://python.org/sf/936837  closed by  akuchling

Py_FilesystemDefaultEncoding leaks  (2004-04-17)
       http://python.org/sf/936915  closed by  akuchling

popen2 returns (out, in) not (in, out)  (2004-03-18)
       http://python.org/sf/918710  closed by  akuchling

PythonWin fails reporting "Can not locate pywintypes23.dll   (2004-06-05)
       http://python.org/sf/967207  closed by  theller

distutils - compiling C++ ext in cyg or mingw w/ std Python  (2004-01-15)
       http://python.org/sf/877165  closed by  perky

distutils - compiling C++ ext in cyg or mingw w/ std Python  (2004-01-15)
       http://python.org/sf/877165  closed by  perky

SSL bug in socketmodule.c using threads  (2003-07-20)
       http://python.org/sf/774798  closed by  akuchling

cgi module should handle large post attack  (2003-06-22)
       http://python.org/sf/758665  closed by  akuchling

CGIHTTPServer doesn't quote arguments correctly on Windows.  (2003-03-03)
       http://python.org/sf/696846  closed by  akuchling

test_zlib is too slow  (2004-05-26)
       http://python.org/sf/960995  closed by  nascheme

pickle protocol 2 is incompatible(?) with Cookie module  (2004-06-02)
       http://python.org/sf/964868  closed by  akuchling

realpath description misleading  (2004-06-03)
       http://python.org/sf/966256  closed by  akuchling

Multiple Metaclass inheritance limitation  (2004-05-30)
       http://python.org/sf/963246  closed by  pje

Cookie module does not parse date  (2004-06-02)
       http://python.org/sf/964861  closed by  akuchling

socket-module SSL is broken  (2002-01-26)
       http://python.org/sf/508944  closed by  akuchling

mapping a 0 length file  (2004-06-02)
       http://python.org/sf/964876  closed by  tim_one

bug? in PyImport_ImportModule under AIX  (2002-03-12)
       http://python.org/sf/528990  closed by  akuchling

Build fails in _curses module  (2002-04-24)
       http://python.org/sf/548109  closed by  akuchling

os.mkdir() handles SETGID inconsistently  (2002-04-05)
       http://python.org/sf/539942  closed by  akuchling

Interpreter won't always exit with daemonic thread  (2001-12-17)
       http://python.org/sf/494203  closed by  akuchling

build problems on DEC Unix 4.0f  (2002-05-30)
       http://python.org/sf/562585  closed by  akuchling

canvas.create_box() crashes Tk thread  (2002-10-22)
       http://python.org/sf/626936  closed by  akuchling

tarfile fails on MacOS9  (2003-02-20)
       http://python.org/sf/690341  closed by  akuchling

macfs and macostools tests fail on UFS  (2004-05-29)
       http://python.org/sf/962633  closed by  mondragon

segfault in subclassing datetime.date & pickling  (2004-05-12)
       http://python.org/sf/952807  closed by  tim_one

Error in obmalloc.  (2004-01-21)
       http://python.org/sf/881641  closed by  nnorwitz

binascii.a2b_base64 with non base64 data  (2002-12-19)
       http://python.org/sf/656392  closed by  nnorwitz

PyInt_FromString failed with certain hex/oct  (2004-06-07)
       http://python.org/sf/967657  closed by  anthonybaxter

getsockopt/setsockopt with SO_RCVTIMEO are inconsistent  (2003-03-11)
       http://python.org/sf/701936  closed by  nnorwitz

add a stronger PRNG  (2004-03-15)
       http://python.org/sf/917055  closed by  rhettinger

distutils/mingw32 links to dbg libs  (2001-08-22)
       http://python.org/sf/454086  closed by  akuchling

Python crashes when __init__.py is a directory.  (2003-11-20)
       http://python.org/sf/845802  closed by  theller

PyBuffer_New() memory not aligned  (2001-10-18)
       http://python.org/sf/472568  closed by  nascheme

Tix not included in windows distribution  (2001-10-25)
       http://python.org/sf/474836  closed by  loewis

CJK codecs list incomplete  (2004-06-09)
       http://python.org/sf/969415  closed by  perky

pydoc ignores module's __all__ attributes  (2004-06-09)
       http://python.org/sf/969938  closed by  montanaro

Generators produce wrong exception  (2004-06-10)
       http://python.org/sf/970459  closed by  anders_lehmann

Comparisons of unicode and strings shouldn  (2004-06-11)
       http://python.org/sf/971101  closed by  ctheune

Comparisons of unicode and strings raises UnicodeErrors  (2004-06-11)
       http://python.org/sf/971106  closed by  lemburg

execfile -> type() created objects w/ no  __module__ error  (2004-06-05)
       http://python.org/sf/966623  closed by  anthonybaxter

asyncore sillies  (2004-06-11)
       http://python.org/sf/971200  closed by  mwh

thread.name crashes interpreter  (2004-06-11)
       http://python.org/sf/971395  closed by  tim_one

test_unicode_file fails on Win98SE  (2004-03-28)
       http://python.org/sf/924703  closed by  loewis

Wrong indentation of example code in tutorial  (2004-06-12)
       http://python.org/sf/971747  closed by  rhettinger

Generator mangles returned lists.  (2004-06-12)
       http://python.org/sf/971962  closed by  rhettinger

fcntl.lockf() signature uses len, doc refers to length  (2004-06-09)
       http://python.org/sf/970042  closed by  nnorwitz

Assignment to __builtins__.__debug__ doesn't do anything.  (2003-12-18)
       http://python.org/sf/862600  closed by  rhettinger

cmath.log doesn't have the same interface as math.log.  (2003-10-13)
       http://python.org/sf/823209  closed by  rhettinger

local variables problem  (2004-06-14)
       http://python.org/sf/972467  closed by  tim_one

attached script causes python segfault  (2004-06-15)
       http://python.org/sf/972917  closed by  perky

inspect.getframeinfo bug if 'context' is to big   (2004-06-15)
       http://python.org/sf/973092  closed by  rhettinger

sys.getfilesystemencoding()  (2004-06-02)
       http://python.org/sf/964870  closed by  loewis

Listbox itemconfigure leaks memory  (2003-08-02)
       http://python.org/sf/781883  closed by  nnorwitz

PyObject_Free unallocated memory read warning  (2003-08-04)
       http://python.org/sf/782689  closed by  nnorwitz

New / Reopened RFE
__________________

pty.spawn() enhancements  (2004-06-05)
       http://python.org/sf/967161  opened by  A.M. Kuchling 

Better SSL support in socket module  (2004-06-05)
       http://python.org/sf/967275  opened by  A.M. Kuchling 

RFE Closed
__________

os.nullfilename  (2004-04-15)
       http://python.org/sf/935915  closed by  loewis




From qrczak at knm.org.pl  Fri Jun 18 08:31:26 2004
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Sun Jun 20 23:30:57 2004
Subject: [Python-Dev] python-dev Summary for 2004-06-01 through
	2004-06-15 [draft]
In-Reply-To: <BC929538-C0B0-11D8-AE40-0003931A4158@ocf.berkeley.edu>
References: <BC929538-C0B0-11D8-AE40-0003931A4158@ocf.berkeley.edu>
Message-ID: <1087561885.10860.112.camel@qrnik>

W li?cie z czw, 17-06-2004, godz. 15:50 -0700, Brett napisa?:

> .. _PEP 330: http://python.org/peps/pep-0300.html

330, not 300 in the URL.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From fdrake at acm.org  Thu Jun 17 13:26:46 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sun Jun 20 23:31:04 2004
Subject: [Python-Dev] Downloadable HTML from the trunk
Message-ID: <200406171326.46254.fdrake@acm.org>

I've changed the script I use to update the online version of the development 
docmentation so that when that's updated, a copy of the tarball is kept 
available for download.

Both the online and downloadable forms of the development documentation are 
at:

    http://www.python.org/dev/doc/


  -Fred

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


From arigo at tunes.org  Thu Jun 17 14:48:01 2004
From: arigo at tunes.org (Armin Rigo)
Date: Sun Jun 20 23:35:45 2004
Subject: [Python-Dev] Stackless Python
In-Reply-To: <40BB9C17.20500@v.loewis.de>
References: <20040530133843.51528.qmail@web50709.mail.yahoo.com>
	<40BAE605.5040800@v.loewis.de> <40BB6C9B.4040701@ieee.org>
	<40BB7E63.9090304@v.loewis.de>
	<A30D1ADC-B335-11D8-9388-000A95686CD8@redivi.com>
	<40BB8882.60503@v.loewis.de>
	<5611D758-B33E-11D8-9388-000A95686CD8@redivi.com>
	<40BB9C17.20500@v.loewis.de>
Message-ID: <20040617184801.GD20108@vicky.ecs.soton.ac.uk>

Hello,

On Mon, May 31, 2004 at 10:56:55PM +0200, "Martin v. L?wis" wrote:
> >Alternatively, Armin believes that Stackless "hard switching" can 
> >actually be implemented in mostly-platform-neutral C (either by 
> >setjmp/longjmp or alloca hacks, I forget which)
> 
> It is setjmp/longjmp. I have implemented a coroutine library on
> top of setjmp/longjmp myself, so I am well aware of the implications.

Actually, it was alloca(), and would be a real C hack that would probably fail
on some platforms, depending on the phase of the moon.  The idea was that
alloca() can be abused to change the stack pointer almost freely.


Not-easy-to-shake-off-a-C-hacking-reputation'ly yours,

Armin

From kbk at shore.net  Wed Jun 16 23:48:01 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sun Jun 20 23:37:18 2004
Subject: [Python-Dev] Weekly Python Bug/Patch Summary
Message-ID: <200406170348.i5H3m1dd030505@hydra.localdomain>


Patch / Bug Summary
___________________

Patches :  276 open ( +2) /  2415 closed (+14) /  2691 total (+16)
Bugs    :  741 open (-21) /  4156 closed (+62) /  4897 total (+41)
RFE     :  140 open ( +2) /   129 closed ( +1) /   269 total ( +3)

New / Reopened Patches
______________________

Fix to minor spelling error in exception in int_subtype_new  (2004-06-05)
CLOSED http://python.org/sf/967057  opened by  Aaron Brady 

fix bsddb memory leaks  (2004-06-06)
       http://python.org/sf/967763  opened by  Neal Norwitz 

Add fileinput.islastline()  (2004-06-07)
       http://python.org/sf/968063  opened by  Relm Arrowny 

Py_HUGE_VAL HUGE_VAL HUGE undefined  (2004-06-08)
       http://python.org/sf/968728  opened by  Michael Schloh von Bennewitz 

hotshot incorrectly computes elapsed time  (2004-06-08)
CLOSED http://python.org/sf/969180  opened by  Jason Beardsley 

heapq.nlargest  (2004-06-09)
CLOSED http://python.org/sf/969791  opened by  Raymond Hettinger 

str(a_tuple) == str(tuple(map(str,a_tuple)))  (2004-06-09)
CLOSED http://python.org/sf/969805  opened by  Grégoire Dooms 

cookielib doc minor corrections and clarifications  (2004-06-09)
       http://python.org/sf/969900  opened by  John J Lee 

cookielib.py   (2004-06-09)
       http://python.org/sf/969907  opened by  John J Lee 

Generate a working spec even with wrong version of software   (2004-06-10)
       http://python.org/sf/970015  opened by  Scherer Michael 

Use a better BuildRoot tag  (2004-06-10)
       http://python.org/sf/970019  opened by  Scherer Michael 

Fix for #876637 - Random stack corruption from socketmodule  (2004-06-10)
       http://python.org/sf/970288  opened by  Troels Walsted Hansen 

Patch for feature request 491033  (2004-05-20)
       http://python.org/sf/957240  reopened by  mwh

make test_signal less annoying  (2004-06-11)
CLOSED http://python.org/sf/971323  opened by  Michael Hudson 

urllib2 handler algorithm docs  (2004-06-13)
       http://python.org/sf/972310  opened by  John J Lee 

urllib2 handler naming convention collision  (2004-06-14)
       http://python.org/sf/972322  opened by  John J Lee 

urllib2 FTPHandler bugs  (2004-06-14)
       http://python.org/sf/972332  opened by  John J Lee 

fix build of docs in info format  (2004-06-15)
       http://python.org/sf/972991  opened by  Matthias Klose 

Fix for compilation with runtime_library_dirs  (2004-06-15)
       http://python.org/sf/973204  opened by  Antti Honkela 

Patches Closed
______________

deprecate or fix buffer object  (2003-10-28)
       http://python.org/sf/832058  closed by  nascheme

cygwinccompiler should set C++ compiler  (2004-02-02)
       http://python.org/sf/888839  closed by  perky

Rewrite of site.py  (2004-03-23)
       http://python.org/sf/921793  closed by  bcannon

Fix to minor spelling error in exception in int_subtype_new  (2004-06-05)
       http://python.org/sf/967057  closed by  akuchling

CodeContext - an extension to show you where you are  (2004-04-16)
       http://python.org/sf/936169  closed by  kbk

Tk Dialog Upon Subprocess Socket Error  (2003-07-26)
       http://python.org/sf/778323  closed by  kbk

_socket fails to build with latest SGI compiler  (2004-01-27)
       http://python.org/sf/885905  closed by  nnorwitz

cycle profiler for VM opcodes  (2002-01-30)
       http://python.org/sf/510695  closed by  loewis

making Python LC_NUMERIC agnostic  (2003-07-20)
       http://python.org/sf/774665  closed by  loewis

hotshot incorrectly computes elapsed time  (2004-06-08)
       http://python.org/sf/969180  closed by  nnorwitz

str(a_tuple) == '(%s)'%', '.join(map(str,a_tuple))  (2004-06-09)
       http://python.org/sf/969805  closed by  dooms

Add nlargest() and nsmallest() to heapq.  (2004-06-09)
       http://python.org/sf/969791  closed by  rhettinger

make test_signal less annoying  (2004-06-11)
       http://python.org/sf/971323  closed by  mwh

cmath.log optional base argument, fixes #823209  (2003-10-18)
       http://python.org/sf/826074  closed by  rhettinger

Crash in binascii_a2b_uu on corrupt data  (2003-01-09)
       http://python.org/sf/665458  closed by  nnorwitz

Added Proxyauth command to imaplib  (2002-11-14)
       http://python.org/sf/638673  closed by  nnorwitz

New / Reopened Bugs
___________________

cgitb.scanvars fails  (2004-06-05)
CLOSED http://python.org/sf/966992  opened by  Robin Becker 

file("foo", "wU") is silently accepted  (2004-06-05)
       http://python.org/sf/967182  opened by  Skip Montanaro 

PythonWin fails reporting "Can not locate pywintypes23.dll   (2004-06-05)
CLOSED http://python.org/sf/967207  opened by  puffingbilly 

Cmd in thread segfaults after Ctrl-C  (2004-06-05)
       http://python.org/sf/967334  opened by  Kevin M. Turner 

PyInt_FromString failed with certain hex/oct  (2004-06-06)
CLOSED http://python.org/sf/967657  opened by  Qian Wenjie 

csv module cannot handle embedded \r  (2004-06-07)
       http://python.org/sf/967934  opened by  Gregory Bond 

file.encoding doesn't apply to file.write  (2004-06-07)
       http://python.org/sf/967986  opened by  Matthew Mueller 

Python Logging filename & file number   (2004-06-07)
       http://python.org/sf/968245  opened by  Ryan 

error flattening complex smime signed message  (2004-06-07)
       http://python.org/sf/968430  opened by  Ludovico Magnocavallo 

CJK codecs list incomplete  (2004-06-08)
       http://python.org/sf/969415  opened by  Mike Brown 

CJK codecs list incomplete  (2004-06-09)
       http://python.org/sf/969415  reopened by  perky

Python hangs up on I/O operations on the latest FreeBSD 4.10  (2004-06-09)
       http://python.org/sf/969492  opened by  _Iww_ 

BSD restartable signals not correctly disabled  (2004-06-09)
       http://python.org/sf/969574  opened by  Luke Mewburn 

BASECFLAGS are not passed to module build line  (2004-06-09)
       http://python.org/sf/969718  opened by  Jason Beardsley 

function and method objects confounded in Tutorial  (2004-06-09)
       http://python.org/sf/969757  opened by  Mark Jackson 

pydoc ignores module's __all__ attributes  (2004-06-09)
CLOSED http://python.org/sf/969938  opened by  Skip Montanaro 

lfcntl.lockf() signature uses len, doc refers to length  (2004-06-10)
CLOSED http://python.org/sf/970042  opened by  Clinton Roy 

2.3.4 fails build on solaris 10 - complexobject.c  (2004-06-10)
       http://python.org/sf/970334  opened by  JD Bronson 

Generators produce wrong exception  (2004-06-10)
CLOSED http://python.org/sf/970459  opened by  Anders Lehmann 

PyObject_GenericGetAttr is undocumented  (2004-06-10)
       http://python.org/sf/970783  opened by  Eric Huss 

Pyton 2.3.4 Make Test Fails on Mac OS X  (2004-06-10)
       http://python.org/sf/970799  opened by  D.  Evan Kiefer 

Comparisons of unicode and strings shouldn  (2004-06-11)
CLOSED http://python.org/sf/971101  opened by  Christian Theune 

Comparisons of unicode and strings raises UnicodeErrors  (2004-06-11)
CLOSED http://python.org/sf/971106  opened by  Christian Theune 

bizarro test_asynchat failure  (2004-06-11)
CLOSED http://python.org/sf/971200  opened by  Michael Hudson 

another threads+readline+signals nasty  (2004-06-12)
       http://python.org/sf/971213  opened by  Anthony Baxter 

test_timeout failure on trunk  (2004-06-12)
       http://python.org/sf/971238  opened by  Anthony Baxter 

test_signal sucks  (2004-06-11)
       http://python.org/sf/971330  opened by  Michael Hudson 

thread.name crashes interpreter  (2004-06-11)
CLOSED http://python.org/sf/971395  opened by  Jonathan Ellis 

Wrong indentation of example code in tutorial  (2004-06-12)
CLOSED http://python.org/sf/971747  opened by  Grégoire Dooms 

An apparent bug in help  (2004-06-12)
       http://python.org/sf/971872  opened by  Colin J. Williams 

Generator mangles returned lists.  (2004-06-13)
CLOSED http://python.org/sf/971962  opened by  Ed Watkeys 

urllib2 raises exception with non-200 success codes.  (2004-06-13)
       http://python.org/sf/971965  opened by  Ed Watkeys 

local variables problem  (2004-06-14)
CLOSED http://python.org/sf/972467  opened by  Toon Verstraelen 

Python 2.3.4, Solaris 7, socketmodule.c does not compile  (2004-06-14)
       http://python.org/sf/972724  opened by  Bruce D. Ray 

attached script causes python segfault  (2004-06-15)
CLOSED http://python.org/sf/972917  opened by  Faheem Mitha 

bsddb in Python 2.3 incompatible with SourceNav output  (2004-06-15)
       http://python.org/sf/973054  opened by  gdy 

inspect.getframeinfo bug if 'context' is to big   (2004-06-15)
CLOSED http://python.org/sf/973092  opened by  Hans Georg Krauthaeuser 

empty raise after handled exception  (2004-06-15)
       http://python.org/sf/973103  opened by  Niki Spahiev 

sys.stdout problems with pythonw.exe  (2004-06-15)
       http://python.org/sf/973507  opened by  Manlio Perillo 

Doc error on super(cls,self)  (2004-06-15)
       http://python.org/sf/973579  opened by  David MacQuigg 

Bugs Closed
___________

cgitb.scanvars fails  (2004-06-05)
       http://python.org/sf/966992  closed by  akuchling

random.choice([]) should return more intelligible exception  (2004-06-01)
       http://python.org/sf/964230  closed by  rhettinger

2.3 inspect.getframeinfo wrong tb line numbers  (2004-05-15)
       http://python.org/sf/954364  closed by  akuchling

xmlrpclib chokes on Unicode keys  (2003-11-13)
       http://python.org/sf/841757  closed by  akuchling

HTMLParser ParseError in start tag  (2004-03-23)
       http://python.org/sf/921657  closed by  akuchling

cgi module documentation could mention getlist  (2004-05-13)
       http://python.org/sf/953177  closed by  akuchling

many os.path functions bahave inconsistently  (2004-04-04)
       http://python.org/sf/929316  closed by  akuchling

pty.spawn() leaks file descriptors  (2004-02-16)
       http://python.org/sf/897935  closed by  akuchling

PyNumber_InPlaceDivide()'s description  (2004-04-17)
       http://python.org/sf/936837  closed by  akuchling

Py_FilesystemDefaultEncoding leaks  (2004-04-17)
       http://python.org/sf/936915  closed by  akuchling

popen2 returns (out, in) not (in, out)  (2004-03-18)
       http://python.org/sf/918710  closed by  akuchling

PythonWin fails reporting "Can not locate pywintypes23.dll   (2004-06-05)
       http://python.org/sf/967207  closed by  theller

distutils - compiling C++ ext in cyg or mingw w/ std Python  (2004-01-15)
       http://python.org/sf/877165  closed by  perky

distutils - compiling C++ ext in cyg or mingw w/ std Python  (2004-01-15)
       http://python.org/sf/877165  closed by  perky

SSL bug in socketmodule.c using threads  (2003-07-20)
       http://python.org/sf/774798  closed by  akuchling

cgi module should handle large post attack  (2003-06-22)
       http://python.org/sf/758665  closed by  akuchling

CGIHTTPServer doesn't quote arguments correctly on Windows.  (2003-03-03)
       http://python.org/sf/696846  closed by  akuchling

test_zlib is too slow  (2004-05-26)
       http://python.org/sf/960995  closed by  nascheme

pickle protocol 2 is incompatible(?) with Cookie module  (2004-06-02)
       http://python.org/sf/964868  closed by  akuchling

realpath description misleading  (2004-06-03)
       http://python.org/sf/966256  closed by  akuchling

Multiple Metaclass inheritance limitation  (2004-05-30)
       http://python.org/sf/963246  closed by  pje

Cookie module does not parse date  (2004-06-02)
       http://python.org/sf/964861  closed by  akuchling

socket-module SSL is broken  (2002-01-26)
       http://python.org/sf/508944  closed by  akuchling

mapping a 0 length file  (2004-06-02)
       http://python.org/sf/964876  closed by  tim_one

bug? in PyImport_ImportModule under AIX  (2002-03-12)
       http://python.org/sf/528990  closed by  akuchling

Build fails in _curses module  (2002-04-24)
       http://python.org/sf/548109  closed by  akuchling

os.mkdir() handles SETGID inconsistently  (2002-04-05)
       http://python.org/sf/539942  closed by  akuchling

Interpreter won't always exit with daemonic thread  (2001-12-17)
       http://python.org/sf/494203  closed by  akuchling

build problems on DEC Unix 4.0f  (2002-05-30)
       http://python.org/sf/562585  closed by  akuchling

canvas.create_box() crashes Tk thread  (2002-10-22)
       http://python.org/sf/626936  closed by  akuchling

tarfile fails on MacOS9  (2003-02-20)
       http://python.org/sf/690341  closed by  akuchling

macfs and macostools tests fail on UFS  (2004-05-29)
       http://python.org/sf/962633  closed by  mondragon

segfault in subclassing datetime.date & pickling  (2004-05-12)
       http://python.org/sf/952807  closed by  tim_one

Error in obmalloc.  (2004-01-21)
       http://python.org/sf/881641  closed by  nnorwitz

binascii.a2b_base64 with non base64 data  (2002-12-19)
       http://python.org/sf/656392  closed by  nnorwitz

PyInt_FromString failed with certain hex/oct  (2004-06-07)
       http://python.org/sf/967657  closed by  anthonybaxter

getsockopt/setsockopt with SO_RCVTIMEO are inconsistent  (2003-03-11)
       http://python.org/sf/701936  closed by  nnorwitz

add a stronger PRNG  (2004-03-15)
       http://python.org/sf/917055  closed by  rhettinger

distutils/mingw32 links to dbg libs  (2001-08-22)
       http://python.org/sf/454086  closed by  akuchling

Python crashes when __init__.py is a directory.  (2003-11-20)
       http://python.org/sf/845802  closed by  theller

PyBuffer_New() memory not aligned  (2001-10-18)
       http://python.org/sf/472568  closed by  nascheme

Tix not included in windows distribution  (2001-10-25)
       http://python.org/sf/474836  closed by  loewis

CJK codecs list incomplete  (2004-06-09)
       http://python.org/sf/969415  closed by  perky

pydoc ignores module's __all__ attributes  (2004-06-09)
       http://python.org/sf/969938  closed by  montanaro

Generators produce wrong exception  (2004-06-10)
       http://python.org/sf/970459  closed by  anders_lehmann

Comparisons of unicode and strings shouldn  (2004-06-11)
       http://python.org/sf/971101  closed by  ctheune

Comparisons of unicode and strings raises UnicodeErrors  (2004-06-11)
       http://python.org/sf/971106  closed by  lemburg

execfile -> type() created objects w/ no  __module__ error  (2004-06-05)
       http://python.org/sf/966623  closed by  anthonybaxter

asyncore sillies  (2004-06-11)
       http://python.org/sf/971200  closed by  mwh

thread.name crashes interpreter  (2004-06-11)
       http://python.org/sf/971395  closed by  tim_one

test_unicode_file fails on Win98SE  (2004-03-28)
       http://python.org/sf/924703  closed by  loewis

Wrong indentation of example code in tutorial  (2004-06-12)
       http://python.org/sf/971747  closed by  rhettinger

Generator mangles returned lists.  (2004-06-12)
       http://python.org/sf/971962  closed by  rhettinger

fcntl.lockf() signature uses len, doc refers to length  (2004-06-09)
       http://python.org/sf/970042  closed by  nnorwitz

Assignment to __builtins__.__debug__ doesn't do anything.  (2003-12-18)
       http://python.org/sf/862600  closed by  rhettinger

cmath.log doesn't have the same interface as math.log.  (2003-10-13)
       http://python.org/sf/823209  closed by  rhettinger

local variables problem  (2004-06-14)
       http://python.org/sf/972467  closed by  tim_one

attached script causes python segfault  (2004-06-15)
       http://python.org/sf/972917  closed by  perky

inspect.getframeinfo bug if 'context' is to big   (2004-06-15)
       http://python.org/sf/973092  closed by  rhettinger

sys.getfilesystemencoding()  (2004-06-02)
       http://python.org/sf/964870  closed by  loewis

Listbox itemconfigure leaks memory  (2003-08-02)
       http://python.org/sf/781883  closed by  nnorwitz

PyObject_Free unallocated memory read warning  (2003-08-04)
       http://python.org/sf/782689  closed by  nnorwitz

New / Reopened RFE
__________________

pty.spawn() enhancements  (2004-06-05)
       http://python.org/sf/967161  opened by  A.M. Kuchling 

Better SSL support in socket module  (2004-06-05)
       http://python.org/sf/967275  opened by  A.M. Kuchling 

RFE Closed
__________

os.nullfilename  (2004-04-15)
       http://python.org/sf/935915  closed by  loewis


From mal at egenix.com  Wed Jun 16 07:56:06 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jun 20 23:42:32 2004
Subject: [Python-Dev] Re: [I18n-sig] Planned updates for cjkcodecs before
	2.4a1
In-Reply-To: <20040616111651.GA82901@i18n.org>
References: <20040616091718.GA81120@i18n.org> <40D01407.7040309@egenix.com>
	<20040616111651.GA82901@i18n.org>
Message-ID: <40D03556.5080403@egenix.com>

Hye-Shik Chang wrote:
> On Wed, Jun 16, 2004 at 11:33:59AM +0200, M.-A. Lemburg wrote:
> 
>>Hye-Shik Chang wrote:
> 
> [snip]
> 
>>>2. Merge two or three simliar C codecs into one.  We have one C
>>>  codec for every each python codecs currently.  I have got an
>>>  idea to merge them into several similar groups and many common
>>>  part of .so binaries will be saved:
>>>
>>>    _codecs_jacodecs_1.so: euc-jp, shift-jis, iso-2022-jp,
>>>                           iso-2022-jp-1, iso-2022-jp-ext
>>>    _codecs_jacodecs_2.so: euc-jisx0213, shift-jisx0213, iso-2022-jp-3,
>>>			    euc-jis-2004, shift-jis-2004,
>>>			    iso-2022-jp-2004
>>>    _codecs_jacodecs_3.so: iso-2022-jp-2
>>>    _codecs_kocodecs_1.so: euc-kr, johab, iso-2022-kr
>>>    _codecs_kocodecs_2.so: cp949
>>>    _codecs_zhcodecs_1.so: gb2312, gbk, gb18030, hz
>>>    _codecs_zhcodecs_2.so: big5, cp950
>>
>>
>>+1, but why not put all Japanese codecs into one module and
>>dito for the Korean and Chinese ones ?
>>
>>Note that todays OS linkers will only mmap those pieces
>>of code into the process memory that are actually needed
>>by the application, so even though the size of the modules
>>increases, the application process memory foot-print is
>>likely not to increase.
> 
> 
> Okay. But how about embedded, freezed environments or statically
> compiled into python by uncommenting from Modules/Setup?  

Same thing: the OS will only load those parts that are actually
needed into memory. The only downside with having e.g. all
modules statically linked into the python binary is the file
size. OTOH, using static linking improves performance.

> If somebody
> need to support only legacy Japanese encodings, he will want to
> include a legacy mapping(70K) but will not want JIS X 0213(85K) and
> KS X 1001, GB2312 mappings(200K, for iso-2022-jp-2).  And he may
> want to save spaces by just erasing files.  In fact, I don't know
> how real Japanese developers use but just guessed it. :)

Is this a common enough use case to warrant the added
complexity of having to find the right _[123] mapping for
the codec in question ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 16 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From Scott.Daniels at Acm.Org  Wed Jun 16 09:01:40 2004
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Sun Jun 20 23:43:10 2004
Subject: [Python-Dev] Possible addition to itertools
Message-ID: <capg9p$7ms$1@sea.gmane.org>

One feature that I'd find nice in itertools is access to "universal
newlines" behavior.  This would make it much easier to extend zipfile
and other compression-related code to provide pseudo-files that iterate
properly.

To try out a simple Python equivalent, look at:
     http://members.dsl-only.net/~daniels/ilines.html

If people think such code would be useful in itertools, I'd be happy to
add it as a patch.  If not, I'll provide it as a Cookbook recipe or
some such.

-- 
-- Scott David Daniels
Scott.Daniels@Acm.Org


From kiko at async.com.br  Fri Jun 18 18:12:54 2004
From: kiko at async.com.br (Christian Robottom Reis)
Date: Sun Jun 20 23:46:47 2004
Subject: [Python-Dev] tp_(get|set)attro? inheritance bug?
In-Reply-To: <8DBDC610-C0A6-11D8-AE40-0003931A4158@ocf.berkeley.edu>
References: <1086976687.11716.52.camel@spectrum.inescn.pt>
	<8DBDC610-C0A6-11D8-AE40-0003931A4158@ocf.berkeley.edu>
Message-ID: <20040618221254.GE5275@async.com.br>

On Thu, Jun 17, 2004 at 02:37:38PM -0700, Brett wrote:
> Did an SF bug report ever get filed for this?

Yes. Gustavo endured the bugtracker and it was filed today as bug 975646: 

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

Let us know if any further info is necessary, or if we're barking up the
wrong tree. Thanks.

> On Jun 11, 2004, at 10:58, Gustavo J. A. M. Carneiro wrote:
> 
> >  Documentation says, regarding tp_getattr:
> >?
> >This field is inherited by subtypes together with tp_getattro: a 
> >subtype
> >inherits both tp_getattr and tp_getattro from its base type when the
> >subtype's tp_getattr and tp_getattro are both NULL.
> >?
> >
> >  Implementation disagrees, at least in cvs head, but the effect of the
> >bug (non-inheritance of tp_getattr) happens in 2.3.3.  Follow with me:
[snip]

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331

From mal at egenix.com  Wed Jun 16 16:52:56 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jun 20 23:52:50 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <20040616204643.C83042FA0A@mail.egenix.com>
References: <20040616204643.C83042FA0A@mail.egenix.com>
Message-ID: <40D0B328.9020704@egenix.com>

Tim Peters wrote:
> [M.-A. Lemburg]
> 
>>Are we going to have a VC7.1 binary of Python 2.4 for Windows ?
> 
> 
> That's indeed my understanding of The Plan today.  More, we will not have a
> VC6 binary for Python 2.4.  That may be controversial, but nobody has
> volunteered to produce an installer for a VC6 version.

Perhaps ActiveState can fill this gap ?!

>>(Just asking whether it's time to finally open the VC7 shrink-
>>  wrap box ;-)
> 
> Yup.  IIRC, it took about 3GB of disk space to do a full install (including
> copying all the docs to disk).  After it's installed, you won't recognize
> it, and will feel completely lost.  This is a learning experience <wink>.

Hmm, looks like we'll have to get yet another box contributing
to the global heating then... this Wintel alliance sure works
well ;-)

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 16 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From mal at egenix.com  Fri Jun 18 04:19:43 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jun 20 23:55:02 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <e8bf7a53040617185929301051@mail.gmail.com>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>	<200406171543.i5HFhFY04716@guido.python.org>
	<e8bf7a53040617185929301051@mail.gmail.com>
Message-ID: <40D2A59F.3030802@egenix.com>

Jeremy Hylton wrote:
> On Thu, 17 Jun 2004 08:43:15 -0700, Guido van Rossum <guido@python.org> wrote:
> 
>>The issue is that currently the type inferencer can know that the
>>return type of u.encode(s) is 'unicode', assuming u's type is
>>'unicode'.  But with the proposed change, the return type will depend
>>on the *value* of s, and I don't know how easy it is for the type
>>inferencers to handle that case -- likely, a type inferencer will have
>>to give up and say it returns 'object'.
> 
> 
> Who cares about the type inference <0.2 wink>.  It's harder for the
> reader of the program to understand if encode() returns a different
> type.  Would there be some common property that all encode() return
> values would share?  Can't think of one myself.

In my reply to Guido's post I mentioned that it would be reasonable
to limit the number of types to 2 (basically types.StringTypes and
subclasses).

We could then add two new helpers codecs.encode() and .decode()
to do more general codec work without this type restriction.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 18 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From mchermside at ingdirect.com  Fri Jun 18 11:08:33 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Sun Jun 20 23:56:08 2004
Subject: [Python-Dev] Comparing heterogeneous types
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550A9B@ingdexj1.ingdirect.com>

Armin Rigo writes:
> Is it really what we want?  It seems to me that the precision 
> of a float gives
> roughly the magnitude of "uncertainty" of the value that it 
> represents.  If a
> float is large enough, then the same float can represent 
> several long integer
> values.  It should then probably be considered equal to any 
> of these integers,
> instead of just equal to the one arbitrarily returned by 
> casting it to long.

I think that what you describe is NOT the behavior that we
want, and I'll try to give an explanation of why. But please
bear with me... I'm still a beginner at understanding some
of the theory behind numerical computing, so I may make some
mistakes. Hopefully those who understand it better will
correct me.

It's a fact that only certain numbers can be represented exactly
when using numbers of finite precision. For instance, floating
point numbers where the exponent is larger than the number of
digits of precision can represent certain integers but not
others. The same situation arises in the use of floating (or
fixed) point decimals -- only certain fractions can be expressed
exactly.

There are (at least) two different mental models we can use to
deal with this limitation of finite precision. One (which you
are espousing above) is to treat each limited-precision
number as if it had an inherent uncertainty, and it represented
all those numbers which are closer to that representable
number than any other. The other mental model is to suppose
that each limited-precision number represents just one
specific value and that the other values simply cannot be
represented.

I always understand things better when I have concrete examples,
so let me use numbers in base 10 with a precision of 3 to
illustrate these two viewpoints. With a precision of 3 we can
write out the values 2.34x10^4 for the number 23,400 and 
2.35x10^4 for the number 23,500. But 23,401, 23,402, and all the
others in between can't be represented. So by the "Error bar"
mental model, we think of "2.34x10^4" as shorthand for "some
number from 23,350 to 23,450". By the "Exact values" mental
model we think of "2.34x10^4" as meaning "The exact value
23,340".

Now that we know there are two different mental models, we
have to wonder whether one is inherently better than the
other (and whether it makes any difference). I maintain that
it DOES make a difference, and that the "Exact values" mental
model is BETTER than the "Error bar" model. The reason why it
is better doesn't come into play until you start performing
operations on the numbers, so let's examine that.

Suppose that you are adding two numbers under the "Exact
values" mental model. Adding 1.23x10^4 and 3.55x10^4 is quite
easy... the exact sum of 12,300 and 35,500 is 47,800 or
4.78x10^4. But if we add 1.23x10^4 and 8.55x10^2, then the
"real" sum is 12,300 + 855 = 13,155. That CAN'T be represented
in the "exact values" mental model, so we have to ROUND IT
OFF and store "1.32x10^4" instead. In general, the values are
quite clear in the "Exact values" model, but OPERATIONS may
require rounding to express the result.

Proponents of the "Error bar" mental model are now thinking
"yes, well our model trades complexity of VALUES for
simplicity in OPERATIONS". But unfortunately that's just not
true. Again, let us try to add 1.23x10^4 and 3.55x10^4. What
that REALLY means (in the "Error bar" mental model) is that
we are adding SOME number in the range 12,250..12,350 to SOME
number in the range 35,450..35,550. The result must be some
number in the range 47,700..47,900. That is LIKELY to belong
to the range 47,750..47,850 (ie 4.78x10^4), but it MIGHT also
come out to something in the 4.77x10^4 range or the 4.79x10^4
range. We intent to return a result of 1.78x10^4, so operations
in the "Error bar" mental model aren't simple, but contain
some sort of "rounding off" as well, only the exact rules for
how THIS "rounding off" works are a bit more confusing -- I'm
not sure I could express them very well.

(Side Note: You might think to fix this problem by saying that
instead of perfect ranges, the numbers represent probability
curves centered around the given number. By using gaussian
curves, you might even be able to make addition "simple" (at
the cost of a very complex idea of "values"). But whatever
distribution worked for addition would NOT work for
multiplication or other operations, so this trick is doomed
to failure.)

So it turns out that WHATEVER you do, operations on finite-
precision numbers are going to require some sort of a "rounding
off" step to keep the results within the domain. That being
said, the "Exact values" mental model is superior. Not only
does it allow a very simple interpretation of the "values",
but it *also* allows the definition of "rounding off" to be
part of the definition of the operations and not be linked to
the values themselves. (For instance, I prefer a simple
"round-to-nearest" rule, but someone else may have a different
rule and that only affects how they perform operations.) It
is for this reason that (I think) most serious specifications
for the behavior of finite-precision numbers prefer to use
the "Exact value" mental model.

(Another side note: You will notice that the argument here
is strikingly similar to the behavior of PEP 327's Decimal
type. That's because I learned just about everything I'm saying
here from following the discussions (and doing the recommended
reading) about Facundo's work there.)

Okay, in my long-winded fashion, I may have shown that the
"Exact values" mental model is superior to the "Error bars"
model. But does it really make any difference to anyone other
than writers of numerical arithmetic specifications? It does,
and one of the best examples is the one that started this
conversation... comparing instances of different numerical
types. I maintain that when comparing a long with a float
where the exponent is larger than the precision, that the
float should be treated as if it were EXACTLY EQUAL TO 
<coefficient>*2^<exponent>, instead of trying to treat it as
some sort of a range. Similarly, if we implemented a Rational
type, I would suggest that instances of float (or of Facundo's
Decimal) where <exponent> is LESS than the digits of
<coefficient> should be treated as if they were EXACTLY EQUAL
TO the corresponding fraction-over-a-power-of-two.

All right, those who ACTUALLY understand this stuff (rather
than having learned it from this newsgroup) can go ahead and
correct me now.

Once-a-teacher,-always-trying-to-give-a-lecture-lly yours,

-- Michael Chermside



This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From martin at v.loewis.de  Thu Jun 17 16:17:11 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun Jun 20 23:56:34 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <40D0AEAE.5000606@egenix.com>
References: <20040614011919.35A0D2EFF0@mail.egenix.com>
	<40D0AEAE.5000606@egenix.com>
Message-ID: <40D1FC47.4010508@v.loewis.de>

M.-A. Lemburg wrote:
> Are we going to have a VC7.1 binary of Python 2.4 for Windows ?
> 
> (Just asking whether it's time to finally open the VC7 shrink-
>  wrap box ;-)

Yes. I think it hasn't been decided whether Thomas will produce
that, or yours truly.

Regards,
Martin



From pje at telecommunity.com  Fri Jun 18 14:28:16 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon Jun 21 00:03:01 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <e8bf7a53040617185929301051@mail.gmail.com>
References: <200406171543.i5HFhFY04716@guido.python.org>
	<200406162115.i5GLFRrb050850@chilled.skew.org>
	<200406171543.i5HFhFY04716@guido.python.org>
Message-ID: <5.1.1.6.0.20040618142016.024e89d0@mail.telecommunity.com>

At 09:59 PM 6/17/04 -0400, Jeremy Hylton wrote:
>On Thu, 17 Jun 2004 08:43:15 -0700, Guido van Rossum <guido@python.org> wrote:
> >
> > The issue is that currently the type inferencer can know that the
> > return type of u.encode(s) is 'unicode', assuming u's type is
> > 'unicode'.  But with the proposed change, the return type will depend
> > on the *value* of s, and I don't know how easy it is for the type
> > inferencers to handle that case -- likely, a type inferencer will have
> > to give up and say it returns 'object'.
>
>Who cares about the type inference <0.2 wink>.  It's harder for the
>reader of the program to understand if encode() returns a different
>type.  Would there be some common property that all encode() return
>values would share?  Can't think of one myself.

Indeed.  What does this proposal offer that writing 'somefunc(u)' in place 
of 'u.encode("somecodec")' doesn't?  Unicode streams aren't going to work 
with this, right?  And anything else that already uses '.encode()' is going 
to expect a string.

In the former case, you know you have to look at 'somefunc' to know what's 
returned, but in the latter, you are encouraged to think that it's a 
string, and tempted to worry about the details of the actual encoding 
later, even if you don't recognize the codec name.

Anyway, it seems to me that things returned from u.encode() should either 
be strings or "stringlike".  Maybe implementing the read character buffer 
interface should suffice?  But I don't think this should be opened up to 
any old objects without some kind of defined invariant that they should 
satisfy.


From arigo at tunes.org  Thu Jun 17 14:38:06 2004
From: arigo at tunes.org (Armin Rigo)
Date: Mon Jun 21 00:04:18 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <0CFFADBB825C6249A26FDF11C1772AE1550A47@ingdexj1.ingdirect.com>
References: <0CFFADBB825C6249A26FDF11C1772AE1550A47@ingdexj1.ingdirect.com>
Message-ID: <20040617183806.GC20108@vicky.ecs.soton.ac.uk>

Hello Michael,

On Wed, Jun 02, 2004 at 05:18:44PM -0400, Chermside, Michael wrote:
> the long could be less than MAX_FLOAT,
> but still not be precisely representably as a float. In a case
> like this, we really need to convert both to longs and compare
> (or something equivalent) and your code fails to do this.

Is it really what we want?  It seems to me that the precision of a float gives
roughly the magnitude of "uncertainty" of the value that it represents.  If a
float is large enough, then the same float can represent several long integer
values.  It should then probably be considered equal to any of these integers,
instead of just equal to the one arbitrarily returned by casting it to long.

>>> L = 2**60
>>> float(L)
1.152921504606847e+18
>>> float(L) == float(L+1)
True

In this situation I would expect this float(L) value to be equal to both L and
L+1.  (But equality between floats is messy anyway.)


A bientot,

Armin.

From daniels at db-x.com  Thu Jun 17 20:28:38 2004
From: daniels at db-x.com (Scott David Daniels)
Date: Mon Jun 21 00:05:04 2004
Subject: [Python-Dev] Re: heapq API
In-Reply-To: <20040617052830.70F5.JCARLSON@uci.edu>
References: <002001c45058$b381f840$dab7958d@oemcomputer>	<capviv$lqq$1@sea.gmane.org>
	<20040617052830.70F5.JCARLSON@uci.edu>
Message-ID: <catcvn$mlt$1@sea.gmane.org>

Josiah Carlson wrote:
> Scott David Daniels wrote:
>>Better is:
>>      if heap and heap[0] < item:
>>          return heapreplace(heap, item)
>>      return item
> 
> The or method short-circuits too.
> 
>>>>heap = []
>>>>not heap or 7 < heap[0]

Ah, but the point was to avoid the heapreplace
call on equal values, not to get the shortcircuiting.
Since < is the primitive-of-choice, I reversed the test.

-Scott David Daniels
Scott.Daniels@Acm.Org


From walter at livinglogic.de  Fri Jun 18 11:55:41 2004
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Mon Jun 21 00:07:06 2004
Subject: [Python-Dev] HTML side by side diff patch 914575
In-Reply-To: <bc15ba280406172331235ddc8a@mail.gmail.com>
References: <003201c45163$8bad0240$7e32c797@oemcomputer>
	<bc15ba280406172331235ddc8a@mail.gmail.com>
Message-ID: <40D3107D.6020103@livinglogic.de>

Dan Gass wrote:

> Raymond,
> 
> I'm attaching two samples of the latest side by side differencing HTML
> output from/of the difflib.py patch.  If you get the chance, look at
> the samples at let me know what you think of how they look/function.

The file is a strange mix of HTML and XHTML. It contains <br> and
<td nowrap> (i.e. HTML) and <a name="_chg_to_0"/> without any end tag
(i.e. real XML). I'd prefer a patch that generates valid XML, which
is backwards compatible (i.e. <br /> and <a name="_chg_to_0"></a>).
All attributes should be quoted.

The file uses a mix of name and id attributes (but not everywhere).

All style information should be moved to an external file. The URL
of this external file should be a parameter for the generation process.

Padding line numbers with 0s is confusing IMHO.

The additional <span class=sub>...</span> is unneccessary as the
class could be put into the <td>.

What about encoding issues? The HTML file doesn't contain any encoding
declaration, so it will default to latin-1 regardless of the encoding
of the original files. Unfortunately this is rather difficult to fix.

Bye,
    Walter D?rwald

From barry at python.org  Wed Jun 16 15:35:23 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Jun 21 00:10:20 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <000f01c4531d$28ce9240$bfaf2c81@oemcomputer>
References: <000f01c4531d$28ce9240$bfaf2c81@oemcomputer>
Message-ID: <1087414523.7150.45.camel@localhost>

On Tue, 2004-06-15 at 17:10, Raymond Hettinger wrote:

> For completeness, perhaps update the PEP to specify what will happen
> with $ strings that do not fall under $$, $indentifier, or
> ${identifier}.

Good point, I've pushed out an update.

> The names dstring(), astring(), safedict(), and nsdict() could likely be
> improved to be more suggestive of what they do.

The 'd' is a mnemonic for 'dollar strings'.  Similarly 'a' is for
'attribute path'.  'safedict' is meant to imply that it will not throw
KeyError exceptions, and 'nsdict' indicates that namespace lookups are
used.  I'm certainly open to alternative suggestions, although sorry
Tim, I'll reject 'hamstring' outright.

> > Brett and I (I forget who else was there for this) talked about where
> to
> > situate the PEP 292 support.  The interesting idea came up to turn the
> > string module into a package

> -1

:(

> The inclusion of string.py breathes life into something that needs to
> disappear.  One of the reasons for deprecating these functions is to
> reduce the number of things you need to learn and remember.
> Interspersing a handful of new functions and classes is contrary to that
> goal.  It becomes hard to introduce simplified substitutions without
> talking about all the other string functions that you're better off not
> knowing about.
> 
> A separate module is preferable.  Also, I don't see any benefit into
> rolling a package with safedict and nsdict in a separate module from
> dstring and astring.

Here's the point: we know that some of the names in the current string
module will always be useful.  I'd hate to see us have to come up with
some contrived new module for things like string.letters to live in
(e.g. 'stringlib' would suck).  'string' seems like such a useful name
to keep as a place to collect future useful string-related constants,
utilities, and functionality, of which PEP 292 support is perhaps just
the first example.

I'd be perfectly happy splitting string.py into two parts after moving
it into Lib/string.  One would be named 'deprecated.py' and that would
contain all the someday-to-be-deleted functions.  The other might be
called 'constants.py' for lack of a better name, and would contain
things we know we want to keep, like letters, hexdigits, etc. 
string/__init__.py can hide all that and it would be a simple matter
once we ever decide to actually remove the deprecated functions <wink>
to do it in two steps (strawman: remove the 'from deprecated import *'
from Lib/string/__init__.py but leave the module around for diehards,
then eventually remove the module).

I don't think documentation is a problem.  I'd propose (and would even
write) splitting the current string module so that the deprecated
functions are described in a subsection that doesn't appear on the main
module page.  That way, the documentation just describes the constants
we want to keep and the new PEP 292 support (perhaps in another new
subsection).

> Can safedict.safedict() be made more general so that it has value
> outside of string substitutions.  

It's such a trivial matter to subclass from dict and write your own
__getitem__() that I doubt it's worth it.

> Given the simplicity of the PEP, the sandbox implementation is
> surprisingly intricate.  Is it possible to simplify it with a function
> based rather than class based approach? 

Take away all the comments, and it's really a fairly simple
implementation.  I really want to use traditional % syntax to perform
the substitutions since that's the Pythonically natural way to spell
string interpolation.  The only complication in the implementation is
the cache of the converted-to-%s string in the subclass, but this is
critical.  In an i18n application you need the original string for
catalog lookup, and the transformed string is only useful for the mod
operation.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040616/2f132fa6/attachment.bin
From ilya at bluefir.net  Sat Jun 19 00:38:22 2004
From: ilya at bluefir.net (Ilya Sandler)
Date: Mon Jun 21 00:11:08 2004
Subject: [Python-Dev] could someone review pdb patch 896011?
In-Reply-To: <20040610233555.GA15938@dave@alana.ucc.usyd.edu.au>
References: <20040610233555.GA15938@dave@alana.ucc.usyd.edu.au>
Message-ID: <Pine.LNX.4.58.0406182117180.2771@bagira>


Would it be possible for someone to review patch 896011?
(it has been sitting in CVS without any feedback for about 4 months now)

The patch fixes a few minor bugs in pdb and implements a couple small (but
I think  useful features--like auto-restart, auto post-mortem modes)

The patch also fixes 2/3 of a bug#751124,

There are a couple more pdb bugs which I think I could fix, but I'd like
to  wait until I know the fate of the earlier patch.

Many thanks,

Ilya

-------------------------------------------------------------
Guido van Rossum guido at python.org
Fri Feb 6 00:04:28 EST 2004

> I was wondering whether I should submit a formal patch for the
> following pdb enhancements:
>
> 1) right now if you do "pdb script"
> pdb will stop with a confusing
> > <string>(1)?()
>
> and you need to execute "s" before you get to the actual source being
> debugged, this seems somewhat unexpected and inconvenient
>
> A better way would be to go straight to the 1st line of user's code

If you can fix that, it would be great.  Just make sure that the fix
doesn't break anything else.

> 2) right now when the script exits, the debugger exits too, taking with
it
> all the debugging settings (like breakpoints) this seems very
inconvenient
>
> Basically the cost of a too early exit is high (as you lose your
> breakpoints) while the cost of not exiting debugger at all is minimal
(you
> just need to press Ctrl-D to exit when you need it)
>
> So I would think that pdb should not exit on script's exit.
> (and, say, gdb does not exit when program exits...)
>
> Do these suggestions make sense? Is implementing them likely to break
> anything else?

Ditto.  I don't know what it would break, but you will hve to test
this thoroughly.

From bac at OCF.Berkeley.EDU  Sat Jun 19 01:19:14 2004
From: bac at OCF.Berkeley.EDU (Brett Cannon)
Date: Mon Jun 21 00:13:28 2004
Subject: [Python-Dev] functions decorators in 2.4?
In-Reply-To: <1087502217.40d1f78964f3a@webmail.uoguelph.ca>
References: <1087502217.40d1f78964f3a@webmail.uoguelph.ca>
Message-ID: <40D3CCD2.2040006@ocf.berkeley.edu>

Martin Zarate wrote:

> Why not use the underused "as" keyword for decorators?
> 
> That is,
> 
> def foo(bar, baz) as StaticMethod:
> 
> It would be very handy for classes, as I've worked with custom class 
> structures (such as an overcomplicated interface-based structure that I was 
> experimenting with) that it would be useful for.
> 

I think Guido has said no more syntax ideas on this one.  It's either 
before the 'def', after the argument list, or like Java 1.5 .

> Are there plans to extend this to fully custom blocks and statements like in 
> Ruby?  Or will it only be for modified def and class statements?
> 

Since Python does not have blocks like Ruby this is a moot point at the 
moment.  If Python grows blocks like Ruby it can be determined then.  As 
it stands now it is only meant for functions and methods.

-Brett

From bac at OCF.Berkeley.EDU  Sat Jun 19 01:19:55 2004
From: bac at OCF.Berkeley.EDU (Brett Cannon)
Date: Mon Jun 21 00:13:36 2004
Subject: [Python-Dev] (no subject)
In-Reply-To: <200406161313.34568.listuser@br.logorrhea.com>
References: <200406161313.34568.listuser@br.logorrhea.com>
Message-ID: <40D3CCFB.5090005@ocf.berkeley.edu>

Patrick Stinson wrote:
> if you had a hex string like 
> '0x7c'
> how would you convert it to an int?
> 
> int(0x7c) works, but not int('0x7c')

This is the wrong place to ask this; try your question on comp.lang.python .

-Brett

From anthony at interlink.com.au  Wed Jun 16 12:03:54 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Mon Jun 21 00:15:39 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <000f01c4531d$28ce9240$bfaf2c81@oemcomputer>
References: <000f01c4531d$28ce9240$bfaf2c81@oemcomputer>
Message-ID: <40D06F6A.9080304@interlink.com.au>

Raymond Hettinger wrote:
>>PEP 292 is slated for inclusion in Python 2.4,
> 
> 
> For completeness, perhaps update the PEP to specify what will happen
> with $ strings that do not fall under $$, $indentifier, or
> ${identifier}.  For instance, what should happen with:
> 
>    "A dangling $"
>    "A $!invalid_identifier"
>    "A $identfier&followed_by_nonwhitespace_punctuation"

Or, to pick a more common example:

"$Id: rtp.py,v 1.40 2004/03/07 14:41:39 anthony Exp $"


From tim.one at comcast.net  Sat Jun 19 02:39:38 2004
From: tim.one at comcast.net (Tim Peters)
Date: Mon Jun 21 00:20:38 2004
Subject: [Python-Dev] (no subject)
In-Reply-To: <200406161313.34568.listuser@br.logorrhea.com>
Message-ID: <mailman.17.1087791638.451.python-dev@python.org>

[Patrick Stinson]
> if you had a hex string like '0x7c' how would you convert it to an int?
>
> int(0x7c) works, but not int('0x7c')

Please address questions about Python usage to comp.lang.python, or mail to
help@python.org.  They're off-topic on python-dev.  In this case, reading
the docs for int() will answer the question (honest <wink>).



From python at rcn.com  Wed Jun 16 06:37:38 2004
From: python at rcn.com (Raymond Hettinger)
Date: Mon Jun 21 00:22:35 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <1087414523.7150.45.camel@localhost>
Message-ID: <001f01c4538d$f1fcfec0$bfaf2c81@oemcomputer>

> > For completeness, perhaps update the PEP to specify what will happen
> > with $ strings that do not fall under $$, $indentifier, or
> > ${identifier}.
> 
> Good point, I've pushed out an update.

Thanks.


 
> > The names dstring(), astring(), safedict(), and nsdict() could
likely be
> > improved to be more suggestive of what they do.
> 
> The 'd' is a mnemonic for 'dollar strings'.  Similarly 'a' is for
> 'attribute path'.  'safedict' is meant to imply that it will not throw
> KeyError exceptions, and 'nsdict' indicates that namespace lookups are
> used.  I'm certainly open to alternative suggestions

Since this is in a string module, the "string" part of the name can be
more abbreviated and the qualifier should be less abbreviated.

dstring:    dollarstr, formatstr, dollarfmt, template, kwdonly
astring:    attrstr, attrlookup, dottedfmt, kwdattr
safedict:   defaultdict, 
nsdict:     nslookup, namespace, envdict

Cheetah has been through several versions.  Perhaps, they have worked
out some better naming conventions.



> I don't think documentation is a problem.  I'd propose (and would even
> write) splitting the current string module so that the deprecated
> functions are described in a subsection that doesn't appear on the
main
> module page.  That way, the documentation just describes the constants
> we want to keep and the new PEP 292 support (perhaps in another new
> subsection).

That's reasonable.  A string module is the natural place to locate the
simplified substitutions.  Splitting out the old functions seems like a
good way to re-use the string module without breathing life into things
that I was hoping that people would forget ever existed (otherwise, we
will never be rid of them).

Please do give consideration to putting all of this in a single module.
IMO, this is too small of an addition to warrant splitting everything in
to packages (which make it more difficult to understand and maintain as
a collective unit).



> > Can safedict.safedict() be made more general so that it has value
> > outside of string substitutions.
> 
> It's such a trivial matter to subclass from dict and write your own
> __getitem__() that I doubt it's worth it.

True enough.  Do consider having an optional argument for setting the
default string.  Ideally, the class should be useful with both $
formatted and % formatted strings (for instance, make it return the key
unchanged when the key is not found).  Also, since the implementation is
so tightly bound to $ formatting, it makes no sense to put it in a
separate module.



> > Given the simplicity of the PEP, the sandbox implementation is
> > surprisingly intricate.  Is it possible to simplify it with a
function
> > based rather than class based approach?
> 
> Take away all the comments, and it's really a fairly simple
> implementation.  I really want to use traditional % syntax to perform
> the substitutions since that's the Pythonically natural way to spell
> string interpolation. 

The overall goal of the PEP is simplification.  It takes very little
complexity before $ formatting becomes more complicated than %
formatting.

The % syntax has its share of issues (hard to find in the docs;
precedence is more appropriate for integer modulo; tuple vs single
string argument).

If you give up the % syntax, you get perfectly pythonic method calls and
an opportunity to do the whole job with only one exposed,
differentiating the approaches with various method names:

t = Template('$who owes me ${what')
t.subst_from_dict(mydict)
t.subst_from_env()
t.subst_from_attr()
t.subst(mydict, noexception=True)


Something like this would mean that you don't need several different
classes to do the job.  Also, compare the following for obviousness and
readability:

Template('$name loves $spouse').subst(mydict, noexception=True)
dstring('$name loves $spouse') % SafeDict(mydict)



>  In an i18n application you need the original string for
> catalog lookup, and the transformed string is only useful for the mod
> operation.

That settles that one.



Raymond


From martin at v.loewis.de  Thu Jun 17 01:06:10 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 21 00:23:12 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <40D018F4.8080503@egenix.com>
References: <40D018F4.8080503@egenix.com>
Message-ID: <40D126C2.5060603@v.loewis.de>

M.-A. Lemburg wrote:
> What do you think ?

-1. I find it unfortunate that there are encodings which
don't convert between Unicode and byte strings; this direction
should not be followed.

Instead, text processing utilities should be proper libraries.

Regards,
Martin



From guido at python.org  Wed Jun 16 10:59:48 2004
From: guido at python.org (Guido van Rossum)
Date: Mon Jun 21 00:23:16 2004
Subject: [Python-Dev] Re: Object finalization for local (ie function)
	scopes
In-Reply-To: Your message of "Tue, 15 Jun 2004 18:23:03 EDT."
	<20040615222303.GA23309@panix.com> 
References: <acz5vlan.fsf@yahoo.co.uk> <035301c452c9$f28baa40$0202a8c0@olidesk>
	<200406152140.i5FLeQh00962@guido.python.org> 
	<20040615222303.GA23309@panix.com> 
Message-ID: <200406161459.i5GExms02949@guido.python.org>

> > This is a fallacy, because the user still has to order the cleanup by
> > using the correct decorator.  We can't afford to decorate *every*
> > function with this mechanism (method calls are already too expensive).
> 
> My impression is that if integrated into the interpreter core, this
> wouldn't be particularly expensive.  Fundamentally, it would look
> something like this:
> 
>     class C(RAII):
>         def __init__(self):
>             RAII.register(self)
> 
>     def foo():
>         x = C()
> 
> then somewhere in the guts of the function calling mechanism, just
> before the scope unwinding, we'd have:
> 
>     for o in registered_objects:
>         o.__finalize__()
> 
> This is IMO an attractive nuisance, but I don't think it imposes much
> burden in execution speed.  I do see the attraction as being similar to
> that of metaclasses and decorators: power provided to the end-developer
> with few demands for understanding.

So you propose to add a list of registered objects to each stack
frame, and to add code to look at that list upon function return.  YOu
betcha that that is going to slow down short function calls -- if only
by a few instructions, it's still a trend in the wrong direction.

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

From ajole-1 at gci.net  Wed Jun 16 17:13:18 2004
From: ajole-1 at gci.net (Patrick)
Date: Mon Jun 21 00:26:03 2004
Subject: [Python-Dev] hx string -> int
Message-ID: <200406161313.18977.ajole-1@gci.net>

if you had a hex string like 
'0x7c'
how would you convert it to an int?

int(0x7c) works, but not int('0x7c')

From Scott.Daniels at Acm.Org  Fri Jun 18 03:25:06 2004
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Mon Jun 21 00:26:48 2004
Subject: [Python-Dev] Another possible itertools candidate
In-Reply-To: <E1Bazji-0007Ab-49@sodium.pdx.net>
References: <E1Bazji-0007Ab-49@sodium.pdx.net>
Message-ID: <40D298D2.6050308@Acm.Org>

One candidate for itertools I'd like feedback on is "ilines": a
universal newlines iterator.  The idea is to take an iterator that
produces input blocks and yield lines as universal newlines would
produce them if the reads from a binary-opened file produced the
same blocks.  This allows things like decompression to iterate in
parts rather than perform a full expansion.  It would also make
pseudo-files from zipfile a later possibility.

For the curious, I have a Python version with tests at:

     http://members.dsl-only.net/~daniels/ilines.html

If people think this is a good idea, I could turn it into an
itertools patch.

-- 
-Scott David Daniels
Scott.Daniels@Acm.Org

From mal at egenix.com  Thu Jun 17 13:44:19 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jun 21 00:28:38 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <200406171543.i5HFhFY04716@guido.python.org>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>
	<200406171543.i5HFhFY04716@guido.python.org>
Message-ID: <40D1D873.8080804@egenix.com>

Guido van Rossum wrote:
>>M.-A. Lemburg wrote:
>>
>>>Now that more and more codecs become available and the scope
>>>of those codecs goes far beyond only encoding from Unicode to
>>>strings and back, I am tempted to open up that restriction,
>>>thereby opening up u.encode() for applications that wish to
>>>use other codecs that return e.g. Unicode objects as well.
>>>[...]
>>>Note that codecs are not restricted in what they can return
>>>for their .encode() or .decode() method, so any object
>>>type is acceptable, including subclasses of str or
>>>unicode, buffers, mmapped files, etc.
>>
>>+1. I find it surprising that the restriction exists. I would have
>>thought u.encode('foo') would pretty transparently wrap the foo
>>codec's .encode().
>>
>>This is also a good reminder that type checking of the result of
>>codec or unicode .encode() calls is prudent, anytime.
> 
> May I make one tiny objection?  I don't know if it's enough to stop
> this (I value it at -0.5 at most), but this will make reasoning about
> types harder.  Given that approaches like StarKiller and IronPython
> are likely the best way to get near-C speed for Python, I'd like the
> standard library at least to make life eacy for their approach.
> 
> The issue is that currently the type inferencer can know that the
> return type of u.encode(s) is 'unicode', assuming u's type is
> 'unicode'.  But with the proposed change, the return type will depend
> on the *value* of s, and I don't know how easy it is for the type
> inferencers to handle that case -- likely, a type inferencer will have
> to give up and say it returns 'object'.

Ok, how about a compromise: .encode() and .decode() of string
and unicode objects may return string or unicode objects only
(limiting the set of types to two base types).

I think those would cover 90% of all cases. For the remaining
cases we could add codecs.encode() and codecs.decode()
which then do allow arbitrary return types.

> (I've never liked functions whose return type depends on the value of
> an argument -- I guess my intuition has always anticipated type
> inferencing. :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 17 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From aahz at pythoncraft.com  Thu Jun 17 20:23:01 2004
From: aahz at pythoncraft.com (Aahz)
Date: Mon Jun 21 00:30:10 2004
Subject: [Python-Dev] Candidate Itertools
In-Reply-To: <000a01c452b2$a6f13b20$bfaf2c81@oemcomputer>
References: <000a01c452b2$a6f13b20$bfaf2c81@oemcomputer>
Message-ID: <20040618002301.GA22833@panix.com>

On Tue, Jun 15, 2004, Raymond Hettinger wrote:
>
> Feedback is requested for two prospective itertools:
> 
> def count_elements(iterable):
>     b = {}
>     for elem in iterable:
>         b[elem] = b.get(elem, 0) + 1
>     return ((cnt, elem) for elem, cnt in b.iteritems())

+1 provided it returns either (elem, cnt) or the dict itself.

> def pairswap(iterable):
>     return ((b,a) for a,b in iterable)

-1 -- too trivial.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith, c.l.py

From paul at prescod.net  Sat Jun 19 06:38:35 2004
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun 21 00:32:35 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <1087355108.12187.3.camel@localhost>
References: <1087355108.12187.3.camel@localhost>
Message-ID: <40D417AB.30109@prescod.net>

Barry Warsaw wrote:

> PEP 292 is slated for inclusion in Python 2.4, according to PEP 320.  At
> Pycon I checked in my code for this into the sandbox, which I've since
> updated, adding unit tests.  I believe it's ready for inclusion in dist
> CVS, but I want to get some feedback first.
> 
> My new stuff provides two classes, dstring() as described in PEP 292 and
> astring() as hinted at in the PEP. 

I find these names to be arbitrary and not mnemonic or suggestive. How 
about "template" or "format" for "dstring"? I don't know what "astring" is.

  Paul Prescod



From martin at v.loewis.de  Sat Jun 19 08:04:11 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 21 00:33:24 2004
Subject: [Python-Dev] Re: [I18n-sig] Planned updates for cjkcodecs before
	2.4a1
In-Reply-To: <20040616111651.GA82901@i18n.org>
References: <20040616091718.GA81120@i18n.org> <40D01407.7040309@egenix.com>
	<20040616111651.GA82901@i18n.org>
Message-ID: <40D42BBB.8040205@v.loewis.de>

Hye-Shik Chang wrote:
> Okay. But how about embedded, freezed environments or statically
> compiled into python by uncommenting from Modules/Setup?  If somebody
> need to support only legacy Japanese encodings, he will want to
> include a legacy mapping(70K) but will not want JIS X 0213(85K) and
> KS X 1001, GB2312 mappings(200K, for iso-2022-jp-2).

People who want that have many options: the could go back to an older
version of CJKCodecs, they could use Japanese codecs, they could write
their own codecs based on libraries that are only available to the
embedded Python, they could break down your modules again.

For the average user, it does not matter much. For packaging and
maintaining, I believe it is slightly simpler to have fewer files.

So if people have an actual need for non-standard customization,
they can contribute a patch.

Regards,
Martin


From perky at i18n.org  Sat Jun 19 11:12:19 2004
From: perky at i18n.org (Hye-Shik Chang)
Date: Mon Jun 21 00:36:41 2004
Subject: [Python-Dev] Re: [I18n-sig] Planned updates for cjkcodecs before
	2.4a1
In-Reply-To: <40D42BBB.8040205@v.loewis.de>
References: <20040616091718.GA81120@i18n.org> <40D01407.7040309@egenix.com>
	<20040616111651.GA82901@i18n.org> <40D42BBB.8040205@v.loewis.de>
Message-ID: <20040619151219.GA77468@i18n.org>

On Sat, Jun 19, 2004 at 02:04:11PM +0200, "Martin v. L?wis" wrote:
> Hye-Shik Chang wrote:
> >Okay. But how about embedded, freezed environments or statically
> >compiled into python by uncommenting from Modules/Setup?  If somebody
> >need to support only legacy Japanese encodings, he will want to
> >include a legacy mapping(70K) but will not want JIS X 0213(85K) and
> >KS X 1001, GB2312 mappings(200K, for iso-2022-jp-2).
> 
> People who want that have many options: the could go back to an older
> version of CJKCodecs, they could use Japanese codecs, they could write
> their own codecs based on libraries that are only available to the
> embedded Python, they could break down your modules again.
> 
> For the average user, it does not matter much. For packaging and
> maintaining, I believe it is slightly simpler to have fewer files.
> 

Yeah.  I just finished merging varities of codecs into few per-locale
modules.
			before		after
			(codecs+maps)
_codecs_cn.so		159851		130769
_codecs_jp.so		340350		241307
_codecs_kr.so		150269		125508
_codecs_tw.so		110057 		 97567
_codecs_unicode.so	 17050		 12332
_multibytecodec.so	 24438		 24439
			802015		631922

As a result, 166KB is saved by this unification.  And, I guess that
builtin codec initialization time in Windows may be saved also.  :)

Hye-Shik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040620/411dd2a9/attachment.bin
From martin at v.loewis.de  Sat Jun 19 12:22:38 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 21 00:40:04 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <e8bf7a53040617185929301051@mail.gmail.com>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>	<200406171543.i5HFhFY04716@guido.python.org>
	<e8bf7a53040617185929301051@mail.gmail.com>
Message-ID: <40D4684E.3040309@v.loewis.de>

Jeremy Hylton wrote:
> Who cares about the type inference <0.2 wink>.  It's harder for the
> reader of the program to understand if encode() returns a different
> type.  Would there be some common property that all encode() return
> values would share?  Can't think of one myself.

No. In addition, the stream codec classes become meaningless 
(StreamReader, StreamWriter), as they are supposed to return
a concatenation of encoding results - however, there is no
guarantee that the encoding results even can be concatenated.

Regards,
Martin


From guido at python.org  Sat Jun 19 11:29:48 2004
From: guido at python.org (Guido van Rossum)
Date: Mon Jun 21 00:41:22 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: Your message of "Thu, 17 Jun 2004 19:44:19 +0200."
	<40D1D873.8080804@egenix.com> 
References: <200406162115.i5GLFRrb050850@chilled.skew.org>
	<200406171543.i5HFhFY04716@guido.python.org> 
	<40D1D873.8080804@egenix.com> 
Message-ID: <200406191529.i5JFTmx08976@guido.python.org>

> Ok, how about a compromise: .encode() and .decode() of string
> and unicode objects may return string or unicode objects only
> (limiting the set of types to two base types).

This works for me, especially since I expect type inferencers to
collapse the two types (just as they should collapse int and long).

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

From dan.gass at gmail.com  Sat Jun 19 12:15:08 2004
From: dan.gass at gmail.com (Dan Gass)
Date: Mon Jun 21 00:42:11 2004
Subject: [Python-Dev] (no subject)
In-Reply-To: <200406161313.34568.listuser@br.logorrhea.com>
References: <200406161313.34568.listuser@br.logorrhea.com>
Message-ID: <bc15ba2804061909157eb31c55@mail.gmail.com>

Patrick,

> if you had a hex string like
> '0x7c'
> how would you convert it to an int?
> 
> int(0x7c) works, but not int('0x7c')

The general python mailing list is a more appropriate place for this
question.  That being said, what you are looking for is
int('0x7c',16).  FYI int('7c',16) also works.  This can be found in
the Python manual (that came with Python) in the Python Library
Reference section 2.1 Built in functions.  You may want to scan
through the tutorial and the library reference material as they both
are good places to look to answer questions like this.

Regards,
Dan Gass

From Jack.Jansen at cwi.nl  Sat Jun 19 18:17:28 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Mon Jun 21 00:48:52 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
Message-ID: <734AA269-C23E-11D8-88DB-000D934FF6B4@cwi.nl>


On 16 Jun 2004, at 22:46, Tim Peters wrote:

> [M.-A. Lemburg]
>> Are we going to have a VC7.1 binary of Python 2.4 for Windows ?
>
> That's indeed my understanding of The Plan today.  More, we will not 
> have a
> VC6 binary for Python 2.4.  That may be controversial, but nobody has
> volunteered to produce an installer for a VC6 version.

Does this mean that the final answer to the question of whether VC7 was 
GPL-compatible was "yes"?
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman


From tim.one at comcast.net  Sat Jun 19 21:56:23 2004
From: tim.one at comcast.net (Tim Peters)
Date: Mon Jun 21 00:53:48 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <734AA269-C23E-11D8-88DB-000D934FF6B4@cwi.nl>
Message-ID: <200406200157.i5K1vBPf097445@mxzilla3.xs4all.nl>

[Jack Jansen]
> Does this mean that the final answer to the question of whether VC7 was
> GPL-compatible was "yes"?

Sorry, if there was some debate about that, I missed it.  That's not an
invitation to start another one here <wink> -- since "GPL compatible" is
determined by pronouncements from the FSF, I strongly advise asking them
directly whether a thing is GPL-compatible.



From jcarlson at uci.edu  Sun Jun 20 01:57:51 2004
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon Jun 21 00:55:37 2004
Subject: [Python-Dev] functions decorators in 2.4?
In-Reply-To: <1087502217.40d1f78964f3a@webmail.uoguelph.ca>
References: <1087502217.40d1f78964f3a@webmail.uoguelph.ca>
Message-ID: <20040619225557.7113.JCARLSON@uci.edu>


> Why not use the underused "as" keyword for decorators?
> 
> That is,
> 
> def foo(bar, baz) as StaticMethod:

The reason why not is in the archives.
Surprisingly enough, the most recent python-dev summary contains a
description of how to search the archives.

 - Josiah


From raymond.hettinger at verizon.net  Sat Jun 19 15:40:07 2004
From: raymond.hettinger at verizon.net (Raymond Hettinger)
Date: Mon Jun 21 00:57:08 2004
Subject: [Python-Dev] Wild Idea for the Year
Message-ID: <001b01c45635$3a03cec0$52af958d@oemcomputer>

What is wrong with the following code?

    def join(*iterable):
        s = ""
        for e in iterable:
            s = s + e
        return s


What if that code could run as fast as ''.join(iterable)?
How much existing code would start to perform better?
Would Python be easier to teach and write?
Would the resulting code look more natural and obvious?

Without expanding the size of the string structure, I think it is
possible to implement something equivalent to the following proposal
(which for clarity, does add two words to the structure).  Roughly, the
idea is:

Add two PyObject pointers to the structure, component0 and component1,
and initialize them to NULL.

Alter string_concat(a, b) to return a new string object with:
    ob_sval = '\0'
    ob_size = len(a) + len(b)
    component0 = a         // be sure to INCREF(a)
    component1 = b         // be sure to INCREF(b)

To the start of every string method except string_len() and
string_concat(), add a macro that expands to:

    if (self->component0 != NULL) 
        _autojoin(self);

Write an _autojoin(self) method who's goal in life is to recursively
fill-out the string from the components:

* resize self to be big enough for an ob_sized string
* treat component0 and component1 as a binary tree (with only the leaves
holding real strings) and recursively (in-order) find the leaves and
copy their string data into self->ob_sval.  DECREF each component after
traversing it.
* set self->component0 to NULL to mark self as being fully joined.

The recursion depth should not be worrisome.  In the typical case, one
side of the tree will be a leaf and will not recurse further.  It gets
more interesting if the user writes things like b=a+a or has a nested
series like c=a+b; f=d+e; g=c+f.  The recursion and reference counting
trivializes the handling of those cases.

An actual implementation striving to save the two additional structure
fields could use the ob_sstate field to indicate a deferred string (my
name for one that has not yet had ob_sval filled out).  The ob_sval
array itself would be given room to hold two object pointers for the
components and access to those pointers would be cast to (PyObject *).

If this works out, it would be an innovation.  The join([a,b]) versus
a+=b problem also exists in several other languages.  AFAICT, Python
would have been the first to solve it.

As a nice side benefit, __builtin__.sum() would no longer need to reject
the case where the inputs were strings.



Raymond Hettinger


From python at rcn.com  Sat Jun 19 16:30:30 2004
From: python at rcn.com (Raymond Hettinger)
Date: Mon Jun 21 00:58:09 2004
Subject: [Python-Dev] Candidate Itertools
In-Reply-To: <20040618002301.GA22833@panix.com>
Message-ID: <002101c4563c$43e4a160$52af958d@oemcomputer>

[Aahz]
> > Feedback is requested for two prospective itertools:
> >
> > def count_elements(iterable):
> >     b = {}
> >     for elem in iterable:
> >         b[elem] = b.get(elem, 0) + 1
> >     return ((cnt, elem) for elem, cnt in b.iteritems())
> 
> +1 provided it returns either (elem, cnt) or the dict itself.

Hmm, there seems to be 100% support for returning a dictionary and zero
support for my iterable (cnt, elem) ... to feed min(), max(), sorted(),
nlargest(), and nsmallest().

If a dictionary is returned, it no longer makes sense to put this in
itertools.  It looks like what is being requested is an alternate
dictionary constructor classmethod, dict.countkeys(iterable).

To get what I was after now takes more intermediate steps:

  nlargest((c,e) for (e,c) in dict.countkey(iterable).iteritems())

It gets the job done, but lacks the grace of:

  nlargest(count_elements(iterable))

Are you guys sure you would prefer having the dict instead of the
pairswapped iterable?



Raymond Hettinger



From martin at v.loewis.de  Sun Jun 20 12:55:24 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 21 01:07:21 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
Message-ID: <40D5C17C.2010008@v.loewis.de>

In the translation project, we now have two (partial) translation
of Python doc strings: for German, and for Turkish. I'd like to ship
the compiled message catalogs with Python 2.4, so that pydoc will
automatically display translated doc strings if they are available.

I would suggest to place the catalogs into Lib/messages/*.mo
(alternatively, if a "non-doc" message catalog for Python is foreseen,
Lib/doc/*.mo would also be reasonable).

What do you think?

Regards,
Martin


From raymond.hettinger at verizon.net  Sun Jun 20 02:01:48 2004
From: raymond.hettinger at verizon.net (Raymond Hettinger)
Date: Mon Jun 21 01:08:31 2004
Subject: [Python-Dev] NOP
Message-ID: <001b01c4568c$13710280$52af958d@oemcomputer>

Any objections to my adding a NOP instruction to support additional code
generation improvements in Python/compile.c?

One possible improvement is replacing [UNARY_NOT JUMP_IF_FALSE addr]
with [NOP JUMP_IF_TRUE addr].


Raymond


From gjc at inescporto.pt  Sun Jun 20 14:06:32 2004
From: gjc at inescporto.pt (Gustavo J. A. M. Carneiro)
Date: Mon Jun 21 01:08:40 2004
Subject: [Python-Dev] logging vs warnings?
Message-ID: <1087754792.2297.30.camel@emperor>

  Why do we have modules logging(2.3) and warnings(2.1)?  Does 'logging'
deprecate 'warnings' in any way?

  I know this question doesn't belong in this list.  I appreciate any
clarifications anyway.  Thanks in advance.

  Regards.

-- 
Gustavo J. A. M. Carneiro
<gjc@inescporto.pt> <gustavo@users.sourceforge.net>
The universe is always one step beyond logic


From martin at v.loewis.de  Sun Jun 20 12:19:19 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 21 01:10:50 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <1087355108.12187.3.camel@localhost>
References: <1087355108.12187.3.camel@localhost>
Message-ID: <40D5B907.2010602@v.loewis.de>

Barry Warsaw wrote:
> Brett and I (I forget who else was there for this) talked about where to
> situate the PEP 292 support.  The interesting idea came up to turn the
> string module into a package, providing backward support for the
> existing string module API, then exporting my PEP 292 modules into this
> namespace.  

I'm fine with providing dstring inside the string module. -1 on making
it a package. I see no advantage for having a package with three files,
some of them containing only a single class, over having it all in a
single module.

Regards,
Martin


From tino.lange at isg.de  Sun Jun 20 17:31:59 2004
From: tino.lange at isg.de (Tino Lange)
Date: Mon Jun 21 01:12:49 2004
Subject: Patch #945642, was: Re: [Python-Dev] release23-maint tree closed
	for 2.3.4rc1
In-Reply-To: <40A31D2C.5040602@interlink.com.au>
References: <40A1B731.1050504@interlink.com.au> <40A285D2.1030401@isg.de>
	<40A2FD06.8070204@interlink.com.au> <40A31697.50403@isg.de>
	<40A31D2C.5040602@interlink.com.au>
Message-ID: <40D6024F.8090500@isg.de>

Anthony Baxter wrote:

> Well, I'd recommend you chase people up who've expressed an interest in
> the patch and make sure one of them checks it in. I will try to get to
> it in a couple of weeks, but my time is (as always) somewhat limited,
> and at the moment I'm ramping up for the 2.4 release cycle.

Hi all - may I remind you of patch #945642?
It would be really nice to have it revised and checked in for 2.3.5 and 2.4.

Thank you a lot!

Tino


From python at rcn.com  Sun Jun 20 07:25:33 2004
From: python at rcn.com (Raymond Hettinger)
Date: Mon Jun 21 01:14:28 2004
Subject: [Python-Dev] NOP
Message-ID: <000201c456b9$4d27a9c0$52af958d@oemcomputer>

Any objections to my adding a NOP instruction to support additional code
generation improvements in Python/compile.c?


Raymond


From listuser at br.logorrhea.com  Sun Jun 20 20:18:24 2004
From: listuser at br.logorrhea.com (Patrick Stinson)
Date: Mon Jun 21 01:15:43 2004
Subject: [Python-Dev] thread priority
Message-ID: <200406201618.24713.listuser@br.logorrhea.com>

I am trying to create a thread that runs with real-time priority, while the 
others do not. Any way to do this from the python level.

From martin at v.loewis.de  Mon Jun 21 01:22:32 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 21 01:23:06 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
Message-ID: <40D67098.7080907@v.loewis.de>

http://python.org/sf/973103 points to two interesting bugs in Python:

First, using a re-raise after the except-block has completed will
still re-raise the last exception. Even though the language spec
is ambiguous (what is the "last expression that was active in the
current scope" (*)), I doubt this is intended.

It then also shows that the error you "normally" get for a reraise
in absence of an exception is

TypeError: exceptions must be classes, instances, or strings 
(deprecated), not NoneType

I think this is in violation of the language description, which says

"If no exception is active in the current scope, an exception is raised 
indicating this error."

"This" error probably being "no active exception", not "exception must
not be NoneType".

What do you think?

Regards,
Martin


From Paul.Moore at atosorigin.com  Mon Jun 21 04:15:48 2004
From: Paul.Moore at atosorigin.com (Moore, Paul)
Date: Mon Jun 21 04:16:28 2004
Subject: [Python-Dev] Re: VC 7.1 maintenance?
Message-ID: <16E1010E4581B049ABC51D4975CEDB88052CB1EC@UKDCX001.uk.int.atosorigin.com>

[I never saw this message on python-dev - apologies if others see it twice...]

From: Ivan R. Judson
>> Is VC2003 a fancier name for VC7.1? or at least binary compatible?
>> Will this allow people to compile extensions without $$ to MS?

> The free download is the compiler and linker and basic tools to build apps.
> The part that costs money is the Visual Studio Development Environment (the
> IDE and higher level tools), however I can find the concrete details if you
> want them.

The problem for Python development is that the free download VC doesn't
support linking to the DLL verstion of the CRT (msvcr71). This means that
there will still be CRT incompatibilities if extensions are built with this
compiler :-(

Mingw is another option, as the latest version of mingw allows building DLLs
which link to msvcr71, but it's pretty bleeding-edge, and I haven't been able
to do much work yet on proving the relevant distutils support is there, as I
don't have an up-to-date Python binary build. I'm planning on doing some
testing when 2.4a1 comes out...

Paul.


__________________________________________________________________________
This e-mail and the documents attached are confidential and intended 
solely for the addressee; it may also be privileged. If you receive this 
e-mail in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group 
liability cannot be triggered for the message content. Although the 
sender endeavours to maintain a computer virus-free network, the sender 
does not warrant that this transmission is virus-free and will not be 
liable for any damages resulting from any virus transmitted.
__________________________________________________________________________

From tismer at stackless.com  Mon Jun 21 09:53:00 2004
From: tismer at stackless.com (Christian Tismer)
Date: Mon Jun 21 09:45:50 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406141632.i5EGWMH30576@guido.python.org>
References: <200406141431.i5EEV6f30289@guido.python.org>
	<u0xe89w7.fsf@python.net>
	<200406141632.i5EGWMH30576@guido.python.org>
Message-ID: <40D6E83C.9040109@stackless.com>

Guido van Rossum wrote:
>>>Another question about the VS7.1 project files: these are XML text,
>>>but they seem to be checked in as binary, therefore CVS won't even
>>>attempt merges.  Is there a reason they can't be marked as text?
>>>Surely the old VC 6.0 reason for this is no longer valid now it's XML?
>>
>>Yes it is: MSVC only accepts them if they have \r\n line separators.
> 
> 
> Are you sure?  I just tried changing the line endings of a few .vcproj
> files to \n only, and MSVC (7.1) worked just fine.  The story about it
> only accepting \r\n was true with VC 6.0, but I don't believe it for 7.1.

By the way, I only have MSVC 7.0, and it didn't understand the
solution and project files.
By editing the version text from "7.10" to "7.0" for project
files and from "8.0" to "7.0" for .sln files, everything
worked fine for me.
No idea what has changed, but at least it works for Python.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/

From tismer at stackless.com  Mon Jun 21 10:19:50 2004
From: tismer at stackless.com (Christian Tismer)
Date: Mon Jun 21 10:15:52 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <E1BawRO-0000jw-00@centera.de>
References: <E1BawRO-0000jw-00@centera.de>
Message-ID: <40D6EE86.50904@stackless.com>

Tim Peters wrote:

> [M.-A. Lemburg]

>>(Just asking whether it's time to finally open the VC7 shrink-
>>  wrap box ;-)
> 
> 
> Yup.  IIRC, it took about 3GB of disk space to do a full install (including
> copying all the docs to disk).  After it's installed, you won't recognize
> it, and will feel completely lost.  This is a learning experience <wink>.

I had to do this, primarily to try and compile Prothon,
and after half a day of playing with the thing, I think it
is better to use than VC 6. Some keyboard shortcuts are gone,
unfortunately, but those for the debugger are still there (sigh).
One tremendous improvement in the GUI:
You can now decide which windows are docked and which not, and
the docking concept is now so universal, that I begin to like it.
Every window can split itself, becoming a container for more windows,
it can become tabbed, you can drag windows out, and on and on.
This is really much mre handy. Before, I always had trouble with
my variable inspector windows. Touching them wrong, they would
snap into a place where I didn't want them.
And, now you can have as many VC instances as you like, which is
*very* handy when testing different versions against each other.

Does anybody have experience with the newly exposed COM model
for debugging? I'd like to write an add-on that allows to
inspect PyObjects more naturally, likewise using __repr__
calls to show PyObjects while debugging the interpreter.

ciao - chris
-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/

From aahz at pythoncraft.com  Mon Jun 21 13:22:36 2004
From: aahz at pythoncraft.com (Aahz)
Date: Mon Jun 21 13:58:45 2004
Subject: [Python-Dev] Weekly Python Bug/Patch Summary (2nd try)
In-Reply-To: <871xkdvjkf.fsf@hydra.localdomain>
References: <871xkdvjkf.fsf@hydra.localdomain>
Message-ID: <20040621172236.GA16146@panix.com>

On Thu, Jun 17, 2004, Kurt B. Kaiser wrote:
>
> [The first posting of this report has not appeared on python-dev though
> it was accepted by the mail server 20 hrs ago]

...and it just now showed up in my mailbox.  mail.python.org has been
under severe load for several days, everyone please be patient.  I'll
probably poke Thomas Wouters about the status of the new machines XS4ALL
has been promising.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith, c.l.py

From mchermside at ingdirect.com  Mon Jun 21 16:15:34 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Mon Jun 21 16:15:42 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550AA7@ingdexj1.ingdirect.com>

> When looking for near-C speed, type inferencing is most important
> for a relatively small set of particularly efficiently manipulable
> types: most notably, smallish integers. Being able to prove that
> something is a Unicode object just isn't all that useful for
> efficiency, because most of the things you can do to Unicode
> objects aren't all that cheap relative to the cost of finding out
> what they are. Likewise, though perhaps a bit less so, for being
> able to prove that something is a string.

I think you may be missing an important special case here...
machines for which "unicode" is a machine-native type. Like the
JVM or .NET runtime. These machines are increasingly important,
and one of the two major implementations of Python runs on such
a machine. (I can't say "2 out of 3" because IronPython doesn't
count until it's released publicly.)

Of course, I *still* don't think that it makes all that much
difference. I agree with the folks who are saying that the
"functions generally return a known type" rule is useful not so
much because of optimization as because it helps the readability
of code. (And that's why obvious exceptions like construction
factories don't bother anybody.)

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From bac at OCF.Berkeley.EDU  Mon Jun 21 18:21:09 2004
From: bac at OCF.Berkeley.EDU (Brett C.)
Date: Mon Jun 21 18:22:20 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <200406171543.i5HFhFY04716@guido.python.org>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>
	<200406171543.i5HFhFY04716@guido.python.org>
Message-ID: <40D75F55.1040307@ocf.berkeley.edu>



Guido van Rossum wrote:

>>M.-A. Lemburg wrote:
>>
>>>Now that more and more codecs become available and the scope
>>>of those codecs goes far beyond only encoding from Unicode to
>>>strings and back, I am tempted to open up that restriction,
>>>thereby opening up u.encode() for applications that wish to
>>>use other codecs that return e.g. Unicode objects as well.
>>>[...]
>>>Note that codecs are not restricted in what they can return
>>>for their .encode() or .decode() method, so any object
>>>type is acceptable, including subclasses of str or
>>>unicode, buffers, mmapped files, etc.
>>
>>+1. I find it surprising that the restriction exists. I would have
>>thought u.encode('foo') would pretty transparently wrap the foo
>>codec's .encode().
>>
>>This is also a good reminder that type checking of the result of
>>codec or unicode .encode() calls is prudent, anytime.
> 
> 
> May I make one tiny objection?  I don't know if it's enough to stop
> this (I value it at -0.5 at most), but this will make reasoning about
> types harder.  Given that approaches like StarKiller and IronPython
> are likely the best way to get near-C speed for Python, I'd like the
> standard library at least to make life eacy for their approach.
> 
> The issue is that currently the type inferencer can know that the
> return type of u.encode(s) is 'unicode', assuming u's type is
> 'unicode'.  But with the proposed change, the return type will depend
> on the *value* of s, and I don't know how easy it is for the type
> inferencers to handle that case -- likely, a type inferencer will have
> to give up and say it returns 'object'.
> 

If you use something like the Cartesian product algorithm (what 
StarKiller uses) then for different call signatures a new inferred 
return type is done for a method.  But this pretty much only works with 
Python code since you have full access to the source to do the analysis 
again.  With Unicode stuff being done in C, you would have to just take 
the lowest common-denominator result, which would be 'object' since you 
can't reanalyze the execution path for different call signatures unless 
someone wants to take the pain of type inferring C code.  Otherwise this 
type fo case can be taken into consideration when developing a type 
inferencing framework that deals with C code, but that just seems 
painful and overly complicated.

-Brett

From raymond.hettinger at verizon.net  Mon Jun 21 12:43:45 2004
From: raymond.hettinger at verizon.net (Raymond Hettinger)
Date: Tue Jun 22 00:44:59 2004
Subject: [Python-Dev] Building strings with +=
Message-ID: <001301c457ae$ebd753e0$dcad2c81@oemcomputer>

What is wrong with the following code?

    def join(*iterable):
        s = ""
        for e in iterable:
            s = s + e
        return s


What if that code could run as fast as ''.join(iterable)?
How much existing code would start to perform better?
In particular, would XML code laden with += loops run faster?
Would Python be easier to teach and write?
Would the resulting code look more natural and obvious?

Without expanding the size of the string structure, I think it is
possible to implement something equivalent to the following proposal
(which for clarity, does add two words to the structure).  Roughly, the
idea is:

Add two PyObject pointers to the structure, component0 and component1,
and initialize them to NULL.

Alter string_concat(a, b) to return a new string object with:
    ob_sval = '\0'
    ob_size = len(a) + len(b)
    component0 = a         // be sure to INCREF(a)
    component1 = b         // be sure to INCREF(b)

To the start of every string method except string_len() and
string_concat(), add a macro that expands to:

    if (self->component0 != NULL) 
        _autojoin(self);

Write an _autojoin(self) method who's goal in life is to recursively
fill-out the string from the components:

* resize self to be big enough for an ob_sized string
* treat component0 and component1 as a binary tree (with only the leaves
holding real strings) and recursively (in-order) find the leaves and
copy their string data into self->ob_sval.  DECREF each component after
traversing it.
* set self->component0 to NULL to mark self as being fully joined.

The recursion depth should not be worrisome.  In the typical case, one
side of the tree will be a leaf and will not recurse further.  It gets
more interesting if the user writes things like b=a+a or has a nested
series like c=a+b; f=d+e; g=c+f.  The recursion and reference counting
trivializes the handling of those cases.

An actual implementation striving to save the two additional structure
fields could use the ob_sstate field to indicate a deferred string (my
name for a string that has not yet had ob_sval filled out).  The ob_sval
array itself would be given room to hold two object pointers for the
components and access to those pointers would be cast to (PyObject *).

If this works out, it would be an innovation.  The join([a,b,c,d])
versus a+b+c+d problem also exists in several other languages.  AFAICT,
Python would have been the first to solve it.

As a nice side benefit, __builtin__.sum() would no longer need to reject
the case where the inputs were strings.

There is a proof-of-concept patch for this at:

    www.python.org/sf/976162

Using UserString, the patch demonstrates a simplified implementation
that converts the O(n**2) string addition process into an O(n) process
like str.join().  Since the patch passes the test suite, it seems likely
that the above could be implemented in a way that is transparent to the
user.



Raymond Hettinger


P.S.  This is a repeat post.  I don't think the first one made it
through mailman this week.


From python at rcn.com  Mon Jun 21 12:53:47 2004
From: python at rcn.com (Raymond Hettinger)
Date: Tue Jun 22 00:54:43 2004
Subject: [Python-Dev] Possible addition to itertools
In-Reply-To: <capg9p$7ms$1@sea.gmane.org>
Message-ID: <001401c457b0$528c3f00$dcad2c81@oemcomputer>

[Scott David Daniels]
> One feature that I'd find nice in itertools is access to "universal
> newlines" behavior.  This would make it much easier to extend zipfile
> and other compression-related code to provide pseudo-files that
iterate
> properly.


My initial thoughts are:

* the functionality is useful
* it duplicates some code from fileobject.c
* ilines() is not abstracted from the problem domain like other
itertools
* it meets other criteria for inclusion in itertools:
  - iterable in, iterable out
  - does bring the whole input into memory
  - interacts well with other itertools
* unsure whether the needs to be Unicode aware

I'm interested to see whether a fan club emerges for this one.


Raymond Hettinger




From aahz at pythoncraft.com  Mon Jun 21 23:52:55 2004
From: aahz at pythoncraft.com (Aahz)
Date: Tue Jun 22 01:00:48 2004
Subject: [Python-Dev] Candidate Itertools
In-Reply-To: <002101c4563c$43e4a160$52af958d@oemcomputer>
References: <20040618002301.GA22833@panix.com>
	<002101c4563c$43e4a160$52af958d@oemcomputer>
Message-ID: <20040622035255.GB1891@panix.com>

On Sat, Jun 19, 2004, Raymond Hettinger wrote:
> [Aahz]
>>Raymond:
>>>
>>> Feedback is requested for two prospective itertools:
>>>
>>> def count_elements(iterable):
>>>     b = {}
>>>     for elem in iterable:
>>>         b[elem] = b.get(elem, 0) + 1
>>>     return ((cnt, elem) for elem, cnt in b.iteritems())
>> 
>> +1 provided it returns either (elem, cnt) or the dict itself.
> 
> Hmm, there seems to be 100% support for returning a dictionary and zero
> support for my iterable (cnt, elem) ... to feed min(), max(), sorted(),
> nlargest(), and nsmallest().

The problem is that it's useful for those operations -- and nothing
else.  It's narrow functionality, and anyone looking just at itertools
will find this confusing; it's just not the natural definition for
something named ``count_elements``, and I suspect it is not possible to
create a good name for your purpose.  Anyone who understands Python will
expect ``count_elements`` to return (elem,cnt) or a dict.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith, c.l.py

From guido at python.org  Mon Jun 21 22:37:57 2004
From: guido at python.org (Guido van Rossum)
Date: Tue Jun 22 02:58:14 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: Your message of "Fri, 18 Jun 2004 14:03:52 BST."
	<200406181403.53023.gmccaughan@synaptics-uk.com> 
References: <200406162115.i5GLFRrb050850@chilled.skew.org>
	<200406171543.i5HFhFY04716@guido.python.org> 
	<200406181403.53023.gmccaughan@synaptics-uk.com> 
Message-ID: <200406220237.i5M2bvh21816@guido.python.org>

> > The issue is that currently the type inferencer can know that the
> > return type of u.encode(s) is 'unicode', assuming u's type is
> > 'unicode'.
> 
> Um, you don't mean that. u"foo".encode() == "foo", of type str.

Yes, my mistake in haste.

> >             But with the proposed change, the return type will depend
> > on the *value* of s, and I don't know how easy it is for the type
> > inferencers to handle that case -- likely, a type inferencer will have
> > to give up and say it returns 'object'.
> 
> When looking for near-C speed, type inferencing is most important
> for a relatively small set of particularly efficiently manipulable
> types: most notably, smallish integers.

If type inferencing only worked for *smallish* ints it would be a
waste of time.  You don't want the program to run 50x faster but
compute the wrong result if some intermediate result is larger than 32
bits.

> Being able to prove that
> something is a Unicode object just isn't all that useful for
> efficiency, because most of the things you can do to Unicode
> objects aren't all that cheap relative to the cost of finding out
> what they are. Likewise, though perhaps a bit less so, for being
> able to prove that something is a string.

Hm, strings are so fundamental as arguments to other things (used as
keys etc.) that my intuition tells me that it actually would matter.

And there are quite a few fast operations on strings: len(), "iftrue",
even slicing: slices with a fixed size are O(1).

Also, the type gets propagated to other function calls, so now you
have to analyze those with nothing more than 'object' for some
argument type.

> At least, so it seems to me. Maybe I'm wrong. I suppose the
> extract-one-character operation might be used quite a bit,
> and that could be cheap. But I can't help feeling that
> occasions where (1) the compiler can prove that something
> is a string because it comes from calling an "encode" method,
> (2) it can't prove that any other way, (3) this makes an
> appreciable difference to the speed of the code, and (4)
> there isn't any less-rigorous (Psyco-like, say) way for
> the type to be discovered and efficient code used, are
> likely to be pretty rare, and in particular rare enough
> that supplying some sort of optional type declaration
> won't be unacceptable to users. (I bet that any version
> of Python that achieves near-C speed by doing extensive
> type inference will have optional type declarations.)

Don't forget all those other uses of type inferencing, e.g. for
pointing out latent bugs in programs (pychecker etc.).

> The above paragraph, of course, presupposes that we keep
> the restriction on the return value of u.encode(s), and
> start enforcing it so that the compiler can take advantage.
> 
> > (I've never liked functions whose return type depends on the value of
> > an argument -- I guess my intuition has always anticipated type
> > inferencing. :-)
> 
> def f(x): return x+x
> 
> has that property, even if you pretend that "+" only works
> on numbers.

No, the type of f depends on the *type* of x (unless x has a type
whose '+' operation has a type that depends on the value of x).

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

From tismer at stackless.com  Tue Jun 22 05:49:11 2004
From: tismer at stackless.com (Christian Tismer)
Date: Tue Jun 22 05:47:45 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406141632.i5EGWMH30576@guido.python.org>
References: <200406141431.i5EEV6f30289@guido.python.org>
	<u0xe89w7.fsf@python.net>
	<200406141632.i5EGWMH30576@guido.python.org>
Message-ID: <40D80097.5060104@stackless.com>

[for unknown reasons, this message didn't make it to the list]

Guido van Rossum wrote:
>>>Another question about the VS7.1 project files: these are XML text,
>>>but they seem to be checked in as binary, therefore CVS won't even
>>>attempt merges.  Is there a reason they can't be marked as text?
>>>Surely the old VC 6.0 reason for this is no longer valid now it's XML?
>>
>>Yes it is: MSVC only accepts them if they have \r\n line separators.
> 
> 
> Are you sure?  I just tried changing the line endings of a few .vcproj
> files to \n only, and MSVC (7.1) worked just fine.  The story about it
> only accepting \r\n was true with VC 6.0, but I don't believe it for 7.1.

By the way, I only have MSVC 7.0, and it didn't understand the
solution and project files.
By editing the version text from "7.10" to "7.0" for project
files and from "8.0" to "7.0" for .sln files, everything
worked fine for me.
No idea what has changed, but at least it works for Python.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Tue Jun 22 05:49:20 2004
From: tismer at stackless.com (Christian Tismer)
Date: Tue Jun 22 05:48:22 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <E1BawRO-0000jw-00@centera.de>
References: <E1BawRO-0000jw-00@centera.de>
Message-ID: <40D800A0.4030209@stackless.com>

[for unknown reasons, this message didn't make it to the list]

Tim Peters wrote:

> [M.-A. Lemburg]

>>(Just asking whether it's time to finally open the VC7 shrink-
>>  wrap box ;-)
> 
> 
> Yup.  IIRC, it took about 3GB of disk space to do a full install (including
> copying all the docs to disk).  After it's installed, you won't recognize
> it, and will feel completely lost.  This is a learning experience <wink>.

I had to do this, primarily to try and compile Prothon,
and after half a day of playing with the thing, I think it
is better to use than VC 6. Some keyboard shortcuts are gone,
unfortunately, but those for the debugger are still there (sigh).
One tremendous improvement in the GUI:
You can now decide which windows are docked and which not, and
the docking concept is now so universal, that I begin to like it.
Every window can split itself, becoming a container for more windows,
it can become tabbed, you can drag windows out, and on and on.
This is really much mre handy. Before, I always had trouble with
my variable inspector windows. Touching them wrong, they would
snap into a place where I didn't want them.
And, now you can have as many VC instances as you like, which is
*very* handy when testing different versions against each other.

Does anybody have experience with the newly exposed COM model
for debugging? I'd like to write an add-on that allows to
inspect PyObjects more naturally, likewise using __repr__
calls to show PyObjects while debugging the interpreter.

ciao - chris
-- 
Christian Tismer             :^)   <mailto:tismer@stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



From gmccaughan at synaptics-uk.com  Tue Jun 22 07:53:10 2004
From: gmccaughan at synaptics-uk.com (Gareth McCaughan)
Date: Tue Jun 22 07:57:02 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <200406220237.i5M2bvh21816@guido.python.org>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>
	<200406181403.53023.gmccaughan@synaptics-uk.com>
	<200406220237.i5M2bvh21816@guido.python.org>
Message-ID: <200406221253.10779.gmccaughan@synaptics-uk.com>

On Tuesday 2004-06-22 03:37, Guido van Rossum wrote:
>>>             But with the proposed change, the return type will depend
>>> on the *value* of s, and I don't know how easy it is for the type
>>> inferencers to handle that case -- likely, a type inferencer will have
>>> to give up and say it returns 'object'.
>> 
>> When looking for near-C speed, type inferencing is most important
>> for a relatively small set of particularly efficiently manipulable
>> types: most notably, smallish integers.
> 
> If type inferencing only worked for *smallish* ints it would be a
> waste of time.  You don't want the program to run 50x faster but
> compute the wrong result if some intermediate result is larger than 32
> bits.

Either I'm misunderstanding you, or that's a straw man.
I'm not saying type inference is useful if it gives the
wrong answer when non-smallish ints occur. I'm saying
it's useful if it stops providing major speedups when
non-smallish ints occur. Which is what happens in, say,
modern Lisp systems when their type inferencing can
prove that some important intermediate value is an
integer but not that it's small enough to fit in a
single word.

>> Being able to prove that
>> something is a Unicode object just isn't all that useful for
>> efficiency, because most of the things you can do to Unicode
>> objects aren't all that cheap relative to the cost of finding out
>> what they are. Likewise, though perhaps a bit less so, for being
>> able to prove that something is a string.
> 
> Hm, strings are so fundamental as arguments to other things (used as
> keys etc.) that my intuition tells me that it actually would matter.

As a Python user I am required by law to have great
respect for your intuition :-), and I would do anyway,
so you may be right here. But surely most places where
strings are used so very heavily almost always *do*
get strings, so their type-checking is just a matter
of, um, checking the type (i.e., no dynamic dispatch
is needed in the common case), so if you then need to
do something non-trivial like a dict lookup the cost
of the type check is relatively rather small.

> And there are quite a few fast operations on strings: len(), "iftrue",
> even slicing: slices with a fixed size are O(1).

Yes, though it's O(1) with a rather large constant. (Except
maybe for single-character slices.) I'll agree about len and
iftrue, though.

>> At least, so it seems to me. Maybe I'm wrong. I suppose the
>> extract-one-character operation might be used quite a bit,
>> and that could be cheap. But I can't help feeling that
>> occasions where (1) the compiler can prove that something
>> is a string because it comes from calling an "encode" method,
>> (2) it can't prove that any other way, (3) this makes an
>> appreciable difference to the speed of the code, and (4)
>> there isn't any less-rigorous (Psyco-like, say) way for
>> the type to be discovered and efficient code used, are
>> likely to be pretty rare, and in particular rare enough
>> that supplying some sort of optional type declaration
>> won't be unacceptable to users. (I bet that any version
>> of Python that achieves near-C speed by doing extensive
>> type inference will have optional type declarations.)
>
> Don't forget all those other uses of type inferencing, e.g. for
> pointing out latent bugs in programs (pychecker etc.).

Sure, and I think that's a better argument. If you'd said
"We'll probably do heavy type inferencing eventually for
speed, and it's really helpful for finding bugs too, so
it would be a shame to do anything that interferes with
it" then I'd probably just have agreed :-).

>>> (I've never liked functions whose return type depends on the value of
>>> an argument -- I guess my intuition has always anticipated type
>>> inferencing. :-)
>> 
>> def f(x): return x+x
>> 
>> has that property, even if you pretend that "+" only works
>> on numbers.
> 
> No, the type of f depends on the *type* of x (unless x has a type
> whose '+' operation has a type that depends on the value of x).

Oh, I see. I misunderstood you; sorry about that. How do
you feel about the "eval" function? :-)

Slightly more seriously and digressing a little, my "f" still
has that property if you consider Python's 'int' and 'long'
to be different types (which you certainly need to do if you're
doing type inference for the sake of speed). It is (or will be)
better for most purposes to consider them a single type with
two internal representations; I wonder whether sooner or later
it will be appropriate to take the same view of string and
unicode objects... Probably later rather than sooner, for
various reasons.

-- 
g



From bac at OCF.Berkeley.EDU  Thu Jun 17 18:43:24 2004
From: bac at OCF.Berkeley.EDU (Brett)
Date: Tue Jun 22 08:01:02 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406140357.i5E3vqC29145@guido.python.org>
References: <200406140120.i5E1KDs28969@guido.python.org>
	<200406140357.i5E3vqC29145@guido.python.org>
Message-ID: <BE22C5D2-C0AF-11D8-AE40-0003931A4158@ocf.berkeley.edu>


On Jun 13, 2004, at 20:57, Guido van Rossum wrote:
>
> [Tim]
>> test_zlib is much faster than it used to be <wink>.
>
> There are a few other tests that are very slow, I believe test_thread
> is one.
>
>
test_thread is slow because it runs two tests who each theoretically 
take 10 seconds (randomly calculated based on the number of threads 
being run for the test; ``random.random() * numtasks``).  We could 
either rewrite the test (test_dummy_thread was originally designed to 
replace it, but you didn't like the idea since test_thread had been 
around for so long and thus was stable) or lower the number of threads 
being run at a time to have it go faster.

-Brett


From kashtan at Validus.Com  Tue Jun 22 03:22:13 2004
From: kashtan at Validus.Com (David L. Kashtan)
Date: Tue Jun 22 08:04:36 2004
Subject: [Python-Dev] Windows/CE Python integration into development Python
	source tree
Message-ID: <000001c45829$a3d11ab0$050310ac@DAVIDSLAPTOP>

I am the person who has been doing the Windows/CE Python 2.3.4
port.  Happily, the changes are minimal -- but I would like to
get them into the source tree so Windows/CE can be a fully
supported Python platform.  I have a patch kit for 2.3.4 that
adds Windows/CE support.

How do I get this integrated?

I would also be VERY happy to do the work to integrate with the
head of the developement tree.

David Kashtan
Validus Medical Systems


From tjreedy at udel.edu  Fri Jun 18 18:00:32 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue Jun 22 08:07:05 2004
Subject: [Python-Dev] Re: python-dev Summary for 2004-06-01 through
	2004-06-15[draft]
References: <BC929538-C0B0-11D8-AE40-0003931A4158@ocf.berkeley.edu>
Message-ID: <cavom4$p4h$1@sea.gmane.org>

A few comments

> patches you want to see in 2.4 then reads Anthony's announcement email

'reads' => 'read'
Suggest delete 'email' since some of us read his announcement as a newgroup
post and 'announcement email' does not read very well anyway.

> *are* in this alpha with late bindings; if early binding would work
> better in your code after trying late binding then speak up since the
> semantics can change.

This strikes me as an invitation for a very biased sample of opinion.
Perhaps people who like and want late binding, after trying it, should also
speak up.

>   Some people said to put it in and if that meant using Guido's,

, => syntax,

> server under out control was also brought up.  Nothing looks like it is

out -> our

> The list was reminded that in the future at some point, comparisons
> between heterogeneous types will raise TypeError sans '==' and '!='.

sans == except for?

Terry J. Reedy





From jon at focalhost.com  Fri Jun 18 18:25:13 2004
From: jon at focalhost.com (Jon Oberheide)
Date: Tue Jun 22 08:07:18 2004
Subject: [Python-Dev] lvalue casts in pyrexc
Message-ID: <1087597513.14512.16.camel@dionysus>

Greetings,

I apologize if this has already been discussed or implemented in CVS but
I am not up to date on python development.

With the release of GCC 3.4 and the continuing development of GCC 3.5,
lvalue casts in C are being deprecated.  Fortunately GCC 3.4 only spits
out a warning for them.  Unfortunately, us crazies using 3.5 will
encounter an unfriendly error with the lvalue casts generated by pyrexc.
Any information on this issue would be appreciated...thanks!

PS: please CC me as I'm not subscribed

Regards,
Jon Oberheide
jon@focalhost.com


From aahz at pythoncraft.com  Tue Jun 22 09:14:53 2004
From: aahz at pythoncraft.com (Aahz)
Date: Tue Jun 22 09:15:57 2004
Subject: [Python-Dev] Possible addition to itertools
In-Reply-To: <capg9p$7ms$1@sea.gmane.org>
References: <capg9p$7ms$1@sea.gmane.org>
Message-ID: <20040622131453.GA11821@panix.com>

On Wed, Jun 16, 2004, Scott David Daniels wrote:
>
> One feature that I'd find nice in itertools is access to "universal
> newlines" behavior.  This would make it much easier to extend zipfile
> and other compression-related code to provide pseudo-files that iterate
> properly.

That's a great idea, but I don't think it belongs in itertools.  If/when
we create the semi-mythical text/string package, it should go there.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith, c.l.py

From anthony at interlink.com.au  Tue Jun 22 11:14:54 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Tue Jun 22 11:15:52 2004
Subject: [Python-Dev] decorators and 2.4
Message-ID: <40D84CEE.6040307@interlink.com.au>

So here's the state of play with decorators and 2.4.

Guido is undecided on the syntax - he writes "I'm seriously
considering doing it Java-style", but adds that he is totally
swamped for the next two weeks. He finishes with:
"Feel free to suggest this as a project for an adventurous
python-dev'er though."

So, who's feeling adventurous? I'm convinced that this should go
into 2.4 if possible, and I don't think there's any _technical_
risks (as far as implementation goes), the only problem is the
syntax (and yes, that's a technical problem too, but you know
what I mean).

Channelling Guido, via his EP keynote
(http://www.python.org/doc/essays/ppt/euro2004/euro2004.ppt)
I'm assuming that "Java-style" is something like:

@staticmethod
def blah(args):
     body

@funcattrs(vegetable="blah", author="GvR")
def blah2(args):
     body

It's not clear to me how you'd specify multiple decorators this
way, perhaps Guido can give more details...

So, let the floodgates open. Remember, we _can_ change this any
time up until 2.4b1, if there's a decision that the chosen form
sucks. :-)


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

From garth at garthy.com  Tue Jun 22 11:34:57 2004
From: garth at garthy.com (Garth)
Date: Tue Jun 22 11:38:54 2004
Subject: [Python-Dev] mimetypes and _winreg
In-Reply-To: <200406220344.i5M3iAv22451@guido.python.org>
References: <200406112201.i5BM1uMR007733@chilled.skew.org>
	<8yetlos8.fsf@python.net> <40CB5684.2090609@garthy.com>
	<200406220344.i5M3iAv22451@guido.python.org>
Message-ID: <40D851A1.6060106@garthy.com>

Guido van Rossum wrote:

>>I could file a patch if no one else is looking at it. The solution would 
>>be to use
>>
>>RegEnumKeyEx and remove RegQueryInfoKey. This loses compatability
>>with win16 which I guess is ok.
>>    
>>
>
>Indeed.  Would you mind filing a patch?  (If you've already done so,
>my apologies -- do you know the patch #?)
>
>--Guido van Rossum (home page: http://www.python.org/~guido/)
>
>  
>
Ok done it here. patch number 977553.
https://sourceforge.net/tracker/index.php?func=detail&aid=977553&group_id=5470&atid=305470

Some bench mark values for the script below:-

python 2.3              5531 89.7130000591
python 2.4 +patch  5531 0.0469999313354

start = time.time()
i = 0
try:
  while 1:
    _winreg.EnumKey(_winreg.HKEY_CLASSES_ROOT, i)
    i += 1
except WindowsError:
  pass
print i, time.time() - start

The max size of a key was taken from the MS Platform SDK.
I hope you don't mind the 255 byte array on the stack?
Not a recursive function so it shouldn't matter too much.

I've noticed a few things while looking at the winreg module.

* No unicode support
* This patch concept could be applied to other functions in this module 
to speed up stuff.

May sort out the rest of this but not soon as I'm off to Glastonbury 
tomorrow so if there's any problems I may not respond for a while.

Garth

From guido at python.org  Wed Jun 23 00:36:00 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun 23 00:36:16 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: Your message of "Wed, 23 Jun 2004 01:14:54 +1000."
	<40D84CEE.6040307@interlink.com.au> 
References: <40D84CEE.6040307@interlink.com.au> 
Message-ID: <200406230436.i5N4a0J24394@guido.python.org>

> Guido is undecided on the syntax - he writes "I'm seriously
> considering doing it Java-style", but adds that he is totally
> swamped for the next two weeks. He finishes with:
> "Feel free to suggest this as a project for an adventurous
> python-dev'er though."
> 
> So, who's feeling adventurous? I'm convinced that this should go
> into 2.4 if possible, and I don't think there's any _technical_
> risks (as far as implementation goes), the only problem is the
> syntax (and yes, that's a technical problem too, but you know
> what I mean).
> 
> Channelling Guido, via his EP keynote
> (http://www.python.org/doc/essays/ppt/euro2004/euro2004.ppt)
> I'm assuming that "Java-style" is something like:
> 
> @staticmethod
> def blah(args):
>      body
> 
> @funcattrs(vegetable="blah", author="GvR")
> def blah2(args):
>      body

Right on both counts.

> It's not clear to me how you'd specify multiple decorators this
> way, perhaps Guido can give more details...

Easy:

    @staticmethod
    @funcattrs(vegetable="blag", author="GvR")
    def blah2(args):
        body

I would love to see an implementation of this idea.

One advantage mentioned by Fredrik Lundh of this, and also of my other
favorite, over "decorators-after-args" is that the decorators are
easily cut-and-pasted -- it's much easier to cut whole lines than
sections of a line, and cutting a multiple-lines-spanning section is
even worse.

If people prefer my favorite (decorator-list-before-def, C# style)
over Java-style, that's fine too... :-)

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

From guido at python.org  Wed Jun 23 01:49:51 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun 23 01:50:01 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: Your message of "Fri, 18 Jun 2004 11:08:33 EDT."
	<0CFFADBB825C6249A26FDF11C1772AE1550A9B@ingdexj1.ingdirect.com> 
References: <0CFFADBB825C6249A26FDF11C1772AE1550A9B@ingdexj1.ingdirect.com> 
Message-ID: <200406230549.i5N5npU24506@guido.python.org>

> I maintain that when comparing a long with a float
> where the exponent is larger than the precision, that the
> float should be treated as if it were EXACTLY EQUAL TO 
> <coefficient>*2^<exponent>, instead of trying to treat it as
> some sort of a range. Similarly, if we implemented a Rational
> type, I would suggest that instances of float (or of Facundo's
> Decimal) where <exponent> is LESS than the digits of
> <coefficient> should be treated as if they were EXACTLY EQUAL
> TO the corresponding fraction-over-a-power-of-two.

Right.  I'm an amateur in this field too, but I've now been convinced
many times over this is what comparisons *should* do, rather than
converting the long (or int) to float and doing the comparison as
float (what they currenttly do).  Anyone feel like implementing this
for 2.4?  (Andrew Koenig posted an algorithm here a few weeks or so
ago.)

(For other operations, I still want to see e.g. long+float to return a
float rather than a long -- you *have* to do it this way for obvious
reasons when the values are relatively small, e.g. consider 1 + 0.5.)

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

From arigo at tunes.org  Wed Jun 23 06:15:33 2004
From: arigo at tunes.org (Armin Rigo)
Date: Wed Jun 23 06:20:01 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <200406230549.i5N5npU24506@guido.python.org>
References: <0CFFADBB825C6249A26FDF11C1772AE1550A9B@ingdexj1.ingdirect.com>
	<200406230549.i5N5npU24506@guido.python.org>
Message-ID: <20040623101533.GA21242@vicky.ecs.soton.ac.uk>

Hello Guido,

On Tue, Jun 22, 2004 at 10:49:51PM -0700, Guido van Rossum wrote:
> (For other operations, I still want to see e.g. long+float to return a
> float rather than a long -- you *have* to do it this way for obvious
> reasons when the values are relatively small, e.g. consider 1 + 0.5.)

Well, just for quick consideration (and probably rejection :-) :

If "a <= b" is to mean we convert a and b to either float or long depending on
their magnitude, would it make any sense at all if other operators like "a +
b" would do the same, to maximize precision?

>>> 1L + 0.5
1.5
>>> L = 100000000000000000000000L
>>> float(L)
9.9999999999999992e+22
>>> float(L+1)
9.9999999999999992e+22
>>> L + 1.0
9.9999999999999992e+22      # currently
100000000000000000000001L   # suggested


Armin

From brian at sweetapp.com  Wed Jun 23 07:13:46 2004
From: brian at sweetapp.com (Brian Quinlan)
Date: Wed Jun 23 07:10:27 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <40D0B328.9020704@egenix.com>
References: <20040616204643.C83042FA0A@mail.egenix.com>
	<40D0B328.9020704@egenix.com>
Message-ID: <40D965EA.3090906@sweetapp.com>

M.-A. Lemburg wrote:
>> That's indeed my understanding of The Plan today.  More, we will not 
>> have a VC6 binary for Python 2.4.  That may be controversial, but 
 >> nobody has volunteered to produce an installer for a VC6 version.
> 
> 
> Perhaps ActiveState can fill this gap ?!

Having two "official" binary-incompatible Python 2.4s for Windows seems 
like a bad idea to me. There will be confusion among Python users 
because of extension incompatibilities. Also, developers will have to 
produce binaries for both.

Cheers,
Brian

From mchermside at ingdirect.com  Wed Jun 23 08:37:31 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Wed Jun 23 08:37:50 2004
Subject: [Python-Dev] Comparing heterogeneous types
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550ABD@ingdexj1.ingdirect.com>

> If "a <= b" is to mean we convert a and b to either float or 
> long depending on
> their magnitude, would it make any sense at all if other 
> operators like "a +
> b" would do the same, to maximize precision?

IMHO, probably not. We are NOT suggesting that "a <= b" mean
we convert a and b to float or long depending on magnitude,
we are suggesting that is just means to compare the values...
and that if one value is float than it should be interpreted
as if it had the precise value it represents rather than
some range of values. Sure, we talked about converting things,
but that was an *implementation* detail.

I suspect that the reason Guido prefers "a + b" to always
return a float when one is a float and the other is a long
is because of his (recently noted in another thread)
preference for operations to be consistent in what type
they return. Of course, it COULD be done more accurately using
your approach. The only good reason I can come up with for
NOT doing so is to have the rule for what type results from
arithmatic operations on mixed types be a simple one.

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From bkc at murkworks.com  Wed Jun 23 10:04:29 2004
From: bkc at murkworks.com (Brad Clements)
Date: Wed Jun 23 10:03:53 2004
Subject: [Python-Dev] python-list to news gateway busted?
Message-ID: <40D955AD.26107.43192A3F@coal.murkworks.com>

Sorry to post here. I sent email to python-list-owner@python.org  two days ago but did not 
receive a response.

I read the python-list via gmane.comp.python.general.

There have been no new posts there since 6/18/2004. However if I post to this newsgroup, 
my post does appear in the python-list archive (ie, the meta confusion new.instance() 
argument 1 must be classobj, not type  ) post.

I do not know if this is a gmane specific problem (I don't have access to another news 
server)  or if its a python-list to news gateway problem.

-- 
Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
http://www.wecanstopspam.org/                   AOL-IM: BKClements


From guido at python.org  Wed Jun 23 10:57:14 2004
From: guido at python.org (Guido van Rossum)
Date: Wed Jun 23 11:03:59 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: Your message of "Wed, 23 Jun 2004 11:15:33 BST."
	<20040623101533.GA21242@vicky.ecs.soton.ac.uk> 
References: <0CFFADBB825C6249A26FDF11C1772AE1550A9B@ingdexj1.ingdirect.com>
	<200406230549.i5N5npU24506@guido.python.org> 
	<20040623101533.GA21242@vicky.ecs.soton.ac.uk> 
Message-ID: <200406231457.i5NEvEO25398@guido.python.org>

> Well, just for quick consideration (and probably rejection :-) :
> 
> If "a <= b" is to mean we convert a and b to either float or long
> depending on their magnitude, would it make any sense at all if
> other operators like "a + b" would do the same, to maximize
> precision?
> 
> >>> 1L + 0.5
> 1.5
> >>> L = 100000000000000000000000L
> >>> float(L)
> 9.9999999999999992e+22
> >>> float(L+1)
> 9.9999999999999992e+22
> >>> L + 1.0
> 9.9999999999999992e+22      # currently
> 100000000000000000000001L   # suggested

No, the return type shouldn't depend on the input values.  (This isn't
an issue for comparisons, since those always return a bool.)

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

From Scott.Daniels at Acm.Org  Wed Jun 23 13:02:49 2004
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Wed Jun 23 13:03:48 2004
Subject: [Python-Dev] Re: Comparing heterogeneous types
In-Reply-To: <0CFFADBB825C6249A26FDF11C1772AE1550A9B@ingdexj1.ingdirect.com>
References: <0CFFADBB825C6249A26FDF11C1772AE1550A9B@ingdexj1.ingdirect.com>
Message-ID: <cbcd5c$74a$1@sea.gmane.org>

Chermside, Michael wrote:
 > ... [a generally great explanation] ...
> All right, those who ACTUALLY understand this stuff (rather
> than having learned it from this newsgroup) can go ahead and
> correct me now.

You missed the killer example, subtraction:
Compare
     2.34x10^4 - 2.34x10^4
and
     2.34x10^40 - 2.34x10^40

These are obviously the same value in exact-mode, but no ranged
system should treat them identically.  Addition/subtraction is
_more_ problematic than multiplication/division in error range stuff.

You could even use
     2.35x10^4 - 2.34x10^4
but I find the zeros more dramatic.

- Scott David Daniels
Scott.Daniels@Acm.Org


From bac at OCF.Berkeley.EDU  Wed Jun 23 16:47:39 2004
From: bac at OCF.Berkeley.EDU (Brett C.)
Date: Wed Jun 23 16:47:54 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <1087414523.7150.45.camel@localhost>
References: <000f01c4531d$28ce9240$bfaf2c81@oemcomputer>
	<1087414523.7150.45.camel@localhost>
Message-ID: <40D9EC6B.3070104@ocf.berkeley.edu>



Barry Warsaw wrote:
> On Tue, 2004-06-15 at 17:10, Raymond Hettinger wrote:
> 
> 
>>For completeness, perhaps update the PEP to specify what will happen
>>with $ strings that do not fall under $$, $indentifier, or
>>${identifier}.
> 
> 
> Good point, I've pushed out an update.
> 
> 
>>The names dstring(), astring(), safedict(), and nsdict() could likely be
>>improved to be more suggestive of what they do.
> 
> 
> The 'd' is a mnemonic for 'dollar strings'.  Similarly 'a' is for
> 'attribute path'.  'safedict' is meant to imply that it will not throw
> KeyError exceptions, and 'nsdict' indicates that namespace lookups are
> used.  I'm certainly open to alternative suggestions, although sorry
> Tim, I'll reject 'hamstring' outright.
> 

Ah, that's why.  Perhaps we can denote this fact in the final docs if 
the name is kept?  I personally have no issue with it now that I know 
what they stand for.  +0.

> 
[SNIP]
> 
> 
>>The inclusion of string.py breathes life into something that needs to
>>disappear.  One of the reasons for deprecating these functions is to
>>reduce the number of things you need to learn and remember.
>>Interspersing a handful of new functions and classes is contrary to that
>>goal.  It becomes hard to introduce simplified substitutions without
>>talking about all the other string functions that you're better off not
>>knowing about.
>>
>>A separate module is preferable.  Also, I don't see any benefit into
>>rolling a package with safedict and nsdict in a separate module from
>>dstring and astring.
> 
> 
> Here's the point: we know that some of the names in the current string
> module will always be useful.  I'd hate to see us have to come up with
> some contrived new module for things like string.letters to live in
> (e.g. 'stringlib' would suck).  'string' seems like such a useful name
> to keep as a place to collect future useful string-related constants,
> utilities, and functionality, of which PEP 292 support is perhaps just
> the first example.
> 
> I'd be perfectly happy splitting string.py into two parts after moving
> it into Lib/string.  One would be named 'deprecated.py' and that would
> contain all the someday-to-be-deleted functions.  The other might be
> called 'constants.py' for lack of a better name, and would contain
> things we know we want to keep, like letters, hexdigits, etc. 
> string/__init__.py can hide all that and it would be a simple matter
> once we ever decide to actually remove the deprecated functions <wink>
> to do it in two steps (strawman: remove the 'from deprecated import *'
> from Lib/string/__init__.py but leave the module around for diehards,
> then eventually remove the module).
> 
> I don't think documentation is a problem.  I'd propose (and would even
> write) splitting the current string module so that the deprecated
> functions are described in a subsection that doesn't appear on the main
> module page.  That way, the documentation just describes the constants
> we want to keep and the new PEP 292 support (perhaps in another new
> subsection).
> 

It all sounds good to me.  Unless str is going to be renamed 'string' in 
Python 3, sticking with 'string' seems fine (but then, as Barry said, we 
discussed this at PyCON so I have supported it for a while  =).  I know 
Guido suggested 'strings', and short of 'strtools', 'string' is the only 
other reasonable name to me.  Tacking on 'lib' to every package will 
become rather tedious quickly, especially when the stdlib is reorganized 
in 3.0 .

And Barry's factoring out stuff that can stand to go away also works for 
me.  Making things we don't want people to use a little harder to reach, 
but still easily accessible in the docs seems like a good solution.

+1

-Brett

From jepler at unpythonic.net  Wed Jun 23 18:53:58 2004
From: jepler at unpythonic.net (Jeff Epler)
Date: Wed Jun 23 18:54:11 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <1087355108.12187.3.camel@localhost>
References: <1087355108.12187.3.camel@localhost>
Message-ID: <20040623225358.GA15481@unpythonic.net>

What is the motivation for "safedict"?  I can imagine two uses.  One
seems like it could lead to some kind of security problem.

The "harmless" (?) use would be in debugging, so that the program would
continue when a key was missing, but the programmer could see after the
fact what that key was.

The harmful case would be one where the string is substituted in several
stages.  Just like % substitutions, $-substitutions are not safe for
repeated expansion.

Here's an example:
    def something(user_controlled_string):
        mypassword = "drowssap"
        bar = "1/8 x 1 inch aluminum bar"
        s = dstring("${foo} is {$bar}")
        s = s % safedict({'foo': user_controlled_string})
        s = s % nsdict()
        print s

The malicious user supplies user_controlled_string:
    http://python.example.com/something?user_controlled_string=%24mypassword
and gets back
    drowssap is 1/8 x 1 inch aluminum bar

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040623/24763d81/attachment.bin
From barry at python.org  Wed Jun 23 19:22:25 2004
From: barry at python.org (Barry Warsaw)
Date: Wed Jun 23 19:22:23 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <200406191529.i5JFTmx08976@guido.python.org>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>
	<200406171543.i5HFhFY04716@guido.python.org>
	<40D1D873.8080804@egenix.com>
	<200406191529.i5JFTmx08976@guido.python.org>
Message-ID: <1088032945.9645.200.camel@localhost>

On Sat, 2004-06-19 at 11:29, Guido van Rossum wrote:

> This works for me, especially since I expect type inferencers to
> collapse the two types (just as they should collapse int and long).

And it's historical baggage anyway right?  IOW, eventually <wink> we're
just going to have a single string type, right?

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040623/61c36bea/attachment.bin
From nbastin at opnet.com  Wed Jun 23 21:46:14 2004
From: nbastin at opnet.com (Nick Bastin)
Date: Wed Jun 23 21:46:30 2004
Subject: [Python-Dev] NOP
In-Reply-To: <000201c456b9$4d27a9c0$52af958d@oemcomputer>
References: <000201c456b9$4d27a9c0$52af958d@oemcomputer>
Message-ID: <4736C3B7-C580-11D8-8BCD-000D932927FE@opnet.com>


On Jun 20, 2004, at 7:25 AM, Raymond Hettinger wrote:

> Any objections to my adding a NOP instruction to support additional 
> code
> generation improvements in Python/compile.c?

I'm all for it.

--
nick


From Scott.Daniels at Acm.Org  Wed Jun 23 22:48:56 2004
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Wed Jun 23 22:49:59 2004
Subject: [Python-Dev] Re: Another possible itertools candidate
In-Reply-To: <40D298D2.6050308@Acm.Org>
References: <E1Bazji-0007Ab-49@sodium.pdx.net> <40D298D2.6050308@Acm.Org>
Message-ID: <cbdfgd$ecn$1@sea.gmane.org>

As some of you may have guessed/noticed this is a repeat of a previous
message.  Sorry about that.  After a couple of days I decided that my
first message had gone into a junk mail filter.

To add a bit, this is now cookbook recipe #286165
	<http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286165>

Sorry for the bandwidth waste.
-Scott



From tjreedy at udel.edu  Wed Jun 23 23:36:35 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed Jun 23 23:36:46 2004
Subject: [Python-Dev] Re: logging vs warnings?
References: <1087754792.2297.30.camel@emperor>
Message-ID: <cbdi87$inm$1@sea.gmane.org>


"Gustavo J. A. M. Carneiro" <gjc@inescporto.pt> wrote in message
news:1087754792.2297.30.camel@emperor...
>   Why do we have modules logging(2.3) and warnings(2.1)?  Does 'logging'
> deprecate 'warnings' in any way?
>
>   I know this question doesn't belong in this list.

So post it on comp.lang.python or the corresponding python-list.  If you do
so, you might explain in what way you think 'warnings' might be deprecated,
or otherwise be more specific as to where you see the overlap.

Terry J. Reedy




From tjreedy at udel.edu  Wed Jun 23 23:40:25 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed Jun 23 23:50:59 2004
Subject: [Python-Dev] Re: thread priority
References: <200406201618.24713.listuser@br.logorrhea.com>
Message-ID: <cbdifd$j2e$1@sea.gmane.org>


"Patrick Stinson" <listuser@br.logorrhea.com> wrote in message
news:200406201618.24713.listuser@br.logorrhea.com...
> I am trying to create a thread that runs with real-time priority, while
the
> others do not. Any way to do this from the python level.

Ask this on comp.lang.python or the corresponding mailing-list with more
information about the Python version and especially the operating system
and possibly the hardware.

Terry J. Reedy




From guido at python.org  Thu Jun 24 00:53:57 2004
From: guido at python.org (Guido van Rossum)
Date: Thu Jun 24 00:54:07 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: Your message of "Mon, 21 Jun 2004 07:22:32 +0200."
	<40D67098.7080907@v.loewis.de> 
References: <40D67098.7080907@v.loewis.de> 
Message-ID: <200406240453.i5O4rvT26696@guido.python.org>

> http://python.org/sf/973103 points to two interesting bugs in Python:
> 
> First, using a re-raise after the except-block has completed will
> still re-raise the last exception. Even though the language spec
> is ambiguous (what is the "last expression that was active in the
> current scope" (*)), I doubt this is intended.

Actually, it *is* intended.  The exception state remains valid until
another exception is raised in the same or an outer scope.

> It then also shows that the error you "normally" get for a reraise
> in absence of an exception is
> 
> TypeError: exceptions must be classes, instances, or strings 
> (deprecated), not NoneType
> 
> I think this is in violation of the language description, which says
> 
> "If no exception is active in the current scope, an exception is raised 
> indicating this error."
> 
> "This" error probably being "no active exception", not "exception must
> not be NoneType".
> 
> What do you think?

Here I agree -- the error message is a little dumb.

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

From martin at v.loewis.de  Thu Jun 24 01:11:37 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu Jun 24 01:11:47 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <40D1D873.8080804@egenix.com>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>	<200406171543.i5HFhFY04716@guido.python.org>
	<40D1D873.8080804@egenix.com>
Message-ID: <40DA6289.8090509@v.loewis.de>

M.-A. Lemburg wrote:
> I think those would cover 90% of all cases. For the remaining
> cases we could add codecs.encode() and codecs.decode()
> which then do allow arbitrary return types.

Can you give examples for the remaining cases?

Regards,
Martin


From guido at python.org  Thu Jun 24 01:12:01 2004
From: guido at python.org (Guido van Rossum)
Date: Thu Jun 24 01:12:11 2004
Subject: [Python-Dev] Wild Idea for the Year
In-Reply-To: Your message of "Sat, 19 Jun 2004 15:40:07 EDT."
	<001b01c45635$3a03cec0$52af958d@oemcomputer> 
References: <001b01c45635$3a03cec0$52af958d@oemcomputer> 
Message-ID: <200406240512.i5O5C1A26763@guido.python.org>

> What is wrong with the following code?
> 
>     def join(*iterable):
>         s = ""
>         for e in iterable:
>             s = s + e
>         return s
> 
> 
> What if that code could run as fast as ''.join(iterable)?
> How much existing code would start to perform better?
> Would Python be easier to teach and write?
> Would the resulting code look more natural and obvious?
> 
> Without expanding the size of the string structure, I think it is
> possible to implement something equivalent to the following proposal
> (which for clarity, does add two words to the structure).  Roughly, the
> idea is:
> 
> Add two PyObject pointers to the structure, component0 and component1,
> and initialize them to NULL.
> 
> Alter string_concat(a, b) to return a new string object with:
>     ob_sval = '\0'
>     ob_size = len(a) + len(b)
>     component0 = a         // be sure to INCREF(a)
>     component1 = b         // be sure to INCREF(b)
> 
> To the start of every string method except string_len() and
> string_concat(), add a macro that expands to:
> 
>     if (self->component0 != NULL) 
>         _autojoin(self);
> 
> Write an _autojoin(self) method who's goal in life is to recursively
> fill-out the string from the components:
> 
> * resize self to be big enough for an ob_sized string
> * treat component0 and component1 as a binary tree (with only the leaves
> holding real strings) and recursively (in-order) find the leaves and
> copy their string data into self->ob_sval.  DECREF each component after
> traversing it.
> * set self->component0 to NULL to mark self as being fully joined.
> 
> The recursion depth should not be worrisome.  In the typical case, one
> side of the tree will be a leaf and will not recurse further.  It gets
> more interesting if the user writes things like b=a+a or has a nested
> series like c=a+b; f=d+e; g=c+f.  The recursion and reference counting
> trivializes the handling of those cases.
> 
> An actual implementation striving to save the two additional structure
> fields could use the ob_sstate field to indicate a deferred string (my
> name for one that has not yet had ob_sval filled out).  The ob_sval
> array itself would be given room to hold two object pointers for the
> components and access to those pointers would be cast to (PyObject *).
> 
> If this works out, it would be an innovation.  The join([a,b]) versus
> a+=b problem also exists in several other languages.  AFAICT, Python
> would have been the first to solve it.
> 
> As a nice side benefit, __builtin__.sum() would no longer need to reject
> the case where the inputs were strings.

It goes flat against one of my *original* design goals for strings,
which was to be really simple, obviously correct code that was also
very fast for the common case.  Your idea adds some extra (constant)
time to all string ops, and quite a bit of complexity.  There are lots
of places where knowledge of string internals is assumed, including
3rd party code using a few macros, all of which would have to be
fixed.

But wait, I think it won't fly at all unless you make ob_sval a
pointer to separately allocated memory.  Otherwise, how could
_autojoin() possibly "fix" the string without allocating the memory
for it?  I am sure that making string objects contain a pointer to the
actual string data instead of having it contiguously allocated with
the header will slow things down.

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


From martin at v.loewis.de  Thu Jun 24 01:15:38 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu Jun 24 01:15:43 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <734AA269-C23E-11D8-88DB-000D934FF6B4@cwi.nl>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
	<734AA269-C23E-11D8-88DB-000D934FF6B4@cwi.nl>
Message-ID: <40DA637A.2020501@v.loewis.de>

Jack Jansen wrote:
>> That's indeed my understanding of The Plan today.  More, we will not 
>> have a
>> VC6 binary for Python 2.4.  That may be controversial, but nobody has
>> volunteered to produce an installer for a VC6 version.
> 
> 
> Does this mean that the final answer to the question of whether VC7 was 
> GPL-compatible was "yes"?

I don't recall that the question has been asked before - let alone
recalling an answer to it.

If you were wondering about the question "is it possible to build
extension modules for a VC7 compiled Python without having to buy
VC7", then this question would have nothing to do with legal issues,
but much more with technical ones.

Regards,
Martin


From martin at v.loewis.de  Thu Jun 24 01:18:12 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu Jun 24 01:18:17 2004
Subject: [Python-Dev] logging vs warnings?
In-Reply-To: <1087754792.2297.30.camel@emperor>
References: <1087754792.2297.30.camel@emperor>
Message-ID: <40DA6414.7040305@v.loewis.de>

Gustavo J. A. M. Carneiro wrote:
>   Why do we have modules logging(2.3) and warnings(2.1)?  Does 'logging'
> deprecate 'warnings' in any way?

No, logging does not deprecate warnings. Logging messages, and emitting
warnings, are two completely different things.

Regards,
Martin


From python at rcn.com  Wed Jun 23 13:52:35 2004
From: python at rcn.com (Raymond Hettinger)
Date: Thu Jun 24 01:53:18 2004
Subject: [Python-Dev] Wild Idea for the Year
In-Reply-To: <200406240512.i5O5C1A26763@guido.python.org>
Message-ID: <002401c4594a$de36c5c0$9417c797@oemcomputer>

> Your idea adds some extra (constant)
> time to all string ops, and quite a bit of complexity.

It adds a single if NULL check to each op (about the same cost as
PyString_Check).

Complexity (recursive joining) is confined to a single function.
Meanwhile, the code for str.__add__() becomes simpler.  That's basically
the whole show.


> There are lots
> of places where knowledge of string internals is assumed, including
> 3rd party code using a few macros, all of which would have to be
> fixed.

Then save it for Py3.0, or not.  The idea is to make things easier for
the python programmer, beginner or pro.  With little effort on the C
side, there is an opportunity to be the first dynamic language with O(n)
behavior for serial string concatenations -- one less thing to teach,
one step towards scalability.


> But wait, I think it won't fly at all unless you make ob_sval a
> pointer to separately allocated memory.  Otherwise, how could
> _autojoin() possibly "fix" the string without allocating the memory
> for it? 

PyString_Resize().



BTW, there is a proof-of-concept demo patch with UserString at:
    www.python.org/sf/976162

Also, there is an alternative approach of having str.__add__() return a
string proxy.  This would avoid issues with 3rd party code. 

That being said, I didn't miss that you hate the idea, so I'll craft a
recipe and drop it :-(


Raymond


From greg at cosc.canterbury.ac.nz  Thu Jun 24 02:20:28 2004
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu Jun 24 02:20:44 2004
Subject: [Python-Dev] lvalue casts in pyrexc
In-Reply-To: <1087597513.14512.16.camel@dionysus>
Message-ID: <200406240620.i5O6KSAC019099@cosc353.cosc.canterbury.ac.nz>

Jon Oberheide <jon@focalhost.com>:

> Unfortunately, us crazies using 3.5 will encounter an unfriendly error
> with the lvalue casts generated by pyrexc.

I'm aware of the problem, and I plan to fix it at some point. Looks
like I may have to bump the priority up a bit if gcc is going to start
rejecting them soon, though.

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

From python at rcn.com  Wed Jun 23 14:24:50 2004
From: python at rcn.com (Raymond Hettinger)
Date: Thu Jun 24 02:25:32 2004
Subject: [Python-Dev] Re: python-dev Summary for 2004-06-01
	through2004-06-15[draft]
In-Reply-To: <cavom4$p4h$1@sea.gmane.org>
Message-ID: <003401c4594f$5f504100$9417c797@oemcomputer>

[Brett]
> > *are* in this alpha with late bindings; if early binding would work
> > better in your code after trying late binding then speak up since
the
> > semantics can change.

[Terry Reedy]
> This strikes me as an invitation for a very biased sample of opinion.
> Perhaps people who like and want late binding, after trying it, should
> also
> speak up.

Given that Guido already decided after much input on python-dev,
speaking-up now is somewhat pointless.  That is doubly true after
issuing guidance that says don't use genexps when the result isn't
consumed right away.  Following the advice makes the question moot.


Raymond


From dan.gass at gmail.com  Thu Jun 24 02:43:36 2004
From: dan.gass at gmail.com (Dan Gass)
Date: Thu Jun 24 02:43:43 2004
Subject: [Python-Dev] HTML side by side diff patch 914575
In-Reply-To: <003201c45163$8bad0240$7e32c797@oemcomputer>
References: <003201c45163$8bad0240$7e32c797@oemcomputer>
Message-ID: <bc15ba28040623234318f427b2@mail.gmail.com>

> If you can, get it in soon to avoid getting to close to the alpha
> release date.

I just submitted an updated patch to the sourceforge patch (914575). 
I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was
the latest I saw today on viewCVS.  The following enhancements were
made:

1) user interface greatly simplified for generating HTML (see diff.py
for example)
2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy)
3) HTML color scheme for differences now matches that used by viewCVS.
4) differences table now has a row for each line making the HTML less
susceptible to browser quirks.
5) took care of all issues to date enumerated on the sourceforge patch
(plus suggestions from others).

As of now the only feature I may want to add in the near future is
optional tab expansion.  This should be a fairly simple change and
shouldn't break anything.

> Please segregate all of this stuff in a single section devoted to
> configuration and make it easy to change without affecting the rest of
> the implementation logic.

I hope my reorganization of the user interface for the HTML generation
took care of this concern.  If not please let me know in more detail
what you had in mind.  If you think this has a good shot at getting
into Python I'll start writing up some user documentation for the
python manuals (it should be alot easier because of the latest
changes).  What is the next step for getting this into Python?

*** CALL FOR HELP (to Java/HTML experts) ***

It would be great if I could get some help on:

A) getting some SIMPLE JavaScript? written to be able to select and
cut text from a single column (right now text is selected from the
whole row including both "from" and "to" text and line numbers.

B) solving the line width issue.  Currently the "from" / "to" column
is as wide as the widest line.  Any ideas on wrapping or scrolling?

Thanks,
Dan Gass

From python at rcn.com  Wed Jun 23 15:44:04 2004
From: python at rcn.com (Raymond Hettinger)
Date: Thu Jun 24 03:44:44 2004
Subject: [Python-Dev] Possible addition to itertools
In-Reply-To: <40D83EF0.9020903@Acm.Org>
Message-ID: <005601c4595a$70ce1820$9417c797@oemcomputer>

> Aahz wrote:
>  > ... I don't think it belongs in itertools.  If/when we create
>  > the semi-mythical text/string package, it should go there.
> Maybe  the text line filling code can be re-cast in this form to
> beef the module size up.

With Barry about to make additions to the string module, perhaps
ilines() could go there.  Alternately, I could see it as a static method
for file objects.


Raymond


From jcarlson at uci.edu  Thu Jun 24 04:34:50 2004
From: jcarlson at uci.edu (Josiah Carlson)
Date: Thu Jun 24 04:40:19 2004
Subject: [Python-Dev] Wild Idea for the Year
In-Reply-To: <001b01c45635$3a03cec0$52af958d@oemcomputer>
References: <001b01c45635$3a03cec0$52af958d@oemcomputer>
Message-ID: <20040624012622.713F.JCARLSON@uci.edu>

> What is wrong with the following code?
> 
>     def join(*iterable):
>         s = ""
>         for e in iterable:
>             s = s + e
>         return s

[snip implementation specific description]

That would be terribly nifty, but it begs the question:
If we do this for strings (an immutable sequence type), do we do this
for tuples (another immutable sequence type)?

Likely not on the tuple side, considering Python's reliance on tuples in
virtually every (is it every?) function call, additional overhead is
additional overhead, and rarely do I see people doing tuple
concatenation.

I do like the possibility that Python can be the first language to solve
the repeated string concatenation problem.  It would also reduce the
need to tell newbies in c.l.py "don't do string concatenation, use
''.join(lst)".

 - Josiah


From mal at egenix.com  Thu Jun 24 04:42:13 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jun 24 04:42:26 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <40DA6289.8090509@v.loewis.de>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>	<200406171543.i5HFhFY04716@guido.python.org>
	<40D1D873.8080804@egenix.com> <40DA6289.8090509@v.loewis.de>
Message-ID: <40DA93E5.1090404@egenix.com>

Martin v. L?wis wrote:
> M.-A. Lemburg wrote:
> 
>> I think those would cover 90% of all cases. For the remaining
>> cases we could add codecs.encode() and codecs.decode()
>> which then do allow arbitrary return types.
> 
> Can you give examples for the remaining cases?

A codec might want to return a buffer object, a mmapped
file, a home grown object, an array, a PIL Image object,
a WAV audio file object, etc. etc.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 24 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
IL Workshop @ Net.ObjectDays 2004, Erfurt, Germany          94 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From arigo at tunes.org  Thu Jun 24 05:43:15 2004
From: arigo at tunes.org (Armin Rigo)
Date: Thu Jun 24 05:45:57 2004
Subject: [Python-Dev] Wild Idea for the Year
In-Reply-To: <001b01c45635$3a03cec0$52af958d@oemcomputer>
References: <001b01c45635$3a03cec0$52af958d@oemcomputer>
Message-ID: <20040624094315.GA926@vicky.ecs.soton.ac.uk>

Hello Raymond,

On Sat, Jun 19, 2004 at 03:40:07PM -0400, Raymond Hettinger wrote:
> * resize self to be big enough for an ob_sized string

How would you do that?  I can't see how you can resize strings in-place, and
if the strings are pre-allocated to have the correct length you only solve one
side of the problem -- the copy overhead -- and not the other one --
allocating and deallocating larger and larger blocks of memory.

Solving half the problem would already be nice.  Note however that code
everywhere expects strings to have characters in their ob_sval field,
accessing it thought the PyString_AS_STRING() macro.  You could fix that macro
too, but you would have to carefully monitor the performance impact.

> If this works out, it would be an innovation.  The join([a,b]) versus
> a+=b problem also exists in several other languages.  AFAICT, Python
> would have been the first to solve it.

*cough* Psyco *cough* implementation versus language *cough*

I don't think Python can pretend to have put a lot of research effort into its
string objects.  Someone mentioned C++'s ropes, for example.  Moreover there
are a number of papers out there about which kind of structures are best
suited in which situations, which should probably be taken into account too.  
(Psyco uses over-allocated buffers.)


Armin

From dave at boost-consulting.com  Thu Jun 24 07:36:05 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu Jun 24 07:36:34 2004
Subject: [Python-Dev] Re: Candidate Itertools
References: <000a01c452b2$a6f13b20$bfaf2c81@oemcomputer>
	<20040618002301.GA22833@panix.com>
Message-ID: <usmclyyqi.fsf@boost-consulting.com>

Aahz <aahz@pythoncraft.com> writes:

>> def pairswap(iterable):
>>     return ((b,a) for a,b in iterable)
>
> -1 -- too trivial.

Yeah, shouldn't any sequence-returning functions in itertools really
be returning an iterator adaptor?  After all, what if iterable is
reading from a file?

What we need is a lazy views library.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From mal at egenix.com  Thu Jun 24 07:52:48 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jun 24 07:52:59 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <40D126C2.5060603@v.loewis.de>
References: <40D018F4.8080503@egenix.com> <40D126C2.5060603@v.loewis.de>
Message-ID: <40DAC090.6010701@egenix.com>

Martin v. L?wis wrote:
> M.-A. Lemburg wrote:
> 
>> What do you think ?
> 
> 
> -1. I find it unfortunate that there are encodings which
> don't convert between Unicode and byte strings; this direction
> should not be followed.
> 
> Instead, text processing utilities should be proper libraries.

I don't understand... codecs are not limited to only text
processing. It's a completely independent framework from the
Unicode sub-system.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 24 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
IL Workshop @ Net.ObjectDays 2004, Erfurt, Germany          94 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From jepler at unpythonic.net  Thu Jun 24 08:12:18 2004
From: jepler at unpythonic.net (Jeff Epler)
Date: Thu Jun 24 08:12:33 2004
Subject: [Python-Dev] lvalue casts in pyrexc
In-Reply-To: <1087597513.14512.16.camel@dionysus>
References: <1087597513.14512.16.camel@dionysus>
Message-ID: <20040624121218.GA17649@unpythonic.net>

This list is not about the development of pyrex, it's about the
development of Python.

Try the pyrex mailing list:
    http://lists.copyleft.no/mailman/listinfo/pyrex

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040624/f2749307/attachment.bin
From jeremy at alum.mit.edu  Thu Jun 24 09:08:39 2004
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Thu Jun 24 09:08:47 2004
Subject: [Python-Dev] Building strings with +=
In-Reply-To: <001301c457ae$ebd753e0$dcad2c81@oemcomputer>
References: <001301c457ae$ebd753e0$dcad2c81@oemcomputer>
Message-ID: <1088082519.30609.11.camel@slothrop.corp.google.com>

On Mon, 2004-06-21 at 12:43, Raymond Hettinger wrote:
> Without expanding the size of the string structure, I think it is
> possible to implement something equivalent to the following proposal
> (which for clarity, does add two words to the structure).  Roughly, the
> idea is:

I have written many applications that store millions of strings.  I
don't know how keen I am on adding more eight more bytes of storage.  An
eight-byte string currently consumes 28 bytes of storage; the proposal
would bump it up to 36 bytes.
 
> Add two PyObject pointers to the structure, component0 and component1,
> and initialize them to NULL.
> 
> Alter string_concat(a, b) to return a new string object with:
>     ob_sval = '\0'
>     ob_size = len(a) + len(b)
>     component0 = a         // be sure to INCREF(a)
>     component1 = b         // be sure to INCREF(b)

It sounds like you're proposing a string implementation know as
"ropes."  See:
    http://www.sgi.com/tech/stl/ropeimpl.html
    http://citeseer.ist.psu.edu/boehm95ropes.html
Are did I misunderstand?

I think there's some merit to the idea.  My initial reaction is that the
data structure seems a bit complex.  Strings are nice and simple. 
Another potential problem is that a lot of code purports to understand
the internal representation of strings; that is, they use
PyString_AS_STRING.

It would be pretty easy to develop an alternative string implementation
and do some performance tests without integrating it into the core. 
That would identify the gross characteristics.  I assume most of the
strings used internally, e.g. variable and attribute names, would almost
always be simple strings and, thus, wouldn't be affected much by a
different implementation.

Jeremy



From aahz at pythoncraft.com  Thu Jun 24 10:27:41 2004
From: aahz at pythoncraft.com (Aahz)
Date: Thu Jun 24 10:27:46 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <001f01c4538d$f1fcfec0$bfaf2c81@oemcomputer>
References: <1087414523.7150.45.camel@localhost>
	<001f01c4538d$f1fcfec0$bfaf2c81@oemcomputer>
Message-ID: <20040624142741.GC27922@panix.com>

On Wed, Jun 16, 2004, Raymond Hettinger wrote:
>
> Please do give consideration to putting all of this in a single
> module.  IMO, this is too small of an addition to warrant splitting
> everything in to packages (which make it more difficult to understand
> and maintain as a collective unit).

That's true.  However, there has been a regular low-level discussion
about creating a ``text`` package; why not simply name it ``string``?
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith, c.l.py

From aahz at pythoncraft.com  Thu Jun 24 10:30:23 2004
From: aahz at pythoncraft.com (Aahz)
Date: Thu Jun 24 10:30:27 2004
Subject: [Python-Dev] lvalue casts in pyrexc
In-Reply-To: <1087597513.14512.16.camel@dionysus>
References: <1087597513.14512.16.camel@dionysus>
Message-ID: <20040624143023.GD27922@panix.com>

On Fri, Jun 18, 2004, Jon Oberheide wrote:
>
> I apologize if this has already been discussed or implemented in CVS but
> I am not up to date on python development.

Pyrex is not part of the core Python language, so python-dev is the
wrong place to bring it up.  I'm not sure where discussion should go,
though I'm sure Google will tell you.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith, c.l.py

From dave at boost-consulting.com  Thu Jun 24 10:35:31 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu Jun 24 10:35:59 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <40D84CEE.6040307@interlink.com.au>
Message-ID: <uy8mdxbv0.fsf@boost-consulting.com>

Anthony Baxter <anthony@interlink.com.au> writes:

> Channelling Guido, via his EP keynote
> (http://www.python.org/doc/essays/ppt/euro2004/euro2004.ppt)
> I'm assuming that "Java-style" is something like:
>
> @staticmethod
> def blah(args):
>      body
>
> @funcattrs(vegetable="blah", author="GvR")
> def blah2(args):
>      body
>
> It's not clear to me how you'd specify multiple decorators this
> way, perhaps Guido can give more details...
>
> So, let the floodgates open. Remember, we _can_ change this any
> time up until 2.4b1, if there's a decision that the chosen form
> sucks. :-)

I'd love to discuss this, but channelling Brett channelling Guido,

> I think Guido has said no more syntax ideas on this one.  It's
> either before the 'def', after the argument list, or like Java 1.5 .

Are you really interested in more syntax ideas, Guido?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From guido at python.org  Thu Jun 24 10:36:29 2004
From: guido at python.org (Guido van Rossum)
Date: Thu Jun 24 10:36:36 2004
Subject: [Python-Dev] Wild Idea for the Year
In-Reply-To: Your message of "Wed, 23 Jun 2004 13:52:35 EDT."
	<002401c4594a$de36c5c0$9417c797@oemcomputer> 
References: <002401c4594a$de36c5c0$9417c797@oemcomputer> 
Message-ID: <200406241436.i5OEaTA27719@guido.python.org>

> > But wait, I think it won't fly at all unless you make ob_sval a
> > pointer to separately allocated memory.  Otherwise, how could
> > _autojoin() possibly "fix" the string without allocating the memory
> > for it? 
> 
> PyString_Resize().

This moves the string in memory, and therefore only works when there
is exactly one reference to the object (the one you pass in).
Otherwise you'd have to find and patch up all references to the
object.

> BTW, there is a proof-of-concept demo patch with UserString at:
>     www.python.org/sf/976162

That's using a Python class, which doesn't have the resizing problem
because it is implemented using a reference to the actual string data.

> Also, there is an alternative approach of having str.__add__() return a
> string proxy.  This would avoid issues with 3rd party code. 
> 
> That being said, I didn't miss that you hate the idea, so I'll craft a
> recipe and drop it :-(

Hate is too strong, but I think it is unnecessary encroachment.  I
worry about Python losing its KISS principle.  Python 2.2 has been
ported to the Nokia Series 60 platform, which has something like 8-16
MB of RAM available.  I'm sure the footprint growth of Python 2.3 and
2.4 gives those developers nightmares already when they are thinking
of tracking later versions...

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

From jeremy at alum.mit.edu  Thu Jun 24 11:11:38 2004
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Thu Jun 24 11:11:47 2004
Subject: [Python-Dev] logging vs warnings?
In-Reply-To: <1087754792.2297.30.camel@emperor>
References: <1087754792.2297.30.camel@emperor>
Message-ID: <1088089898.30611.19.camel@slothrop.corp.google.com>

On Sun, 2004-06-20 at 14:06, Gustavo J. A. M. Carneiro wrote:
>   Why do we have modules logging(2.3) and warnings(2.1)?  Does 'logging'
> deprecate 'warnings' in any way?

No.

>   I know this question doesn't belong in this list.  I appreciate any
> clarifications anyway.  Thanks in advance.

If you know the question is inappropriate for this list, it is rude to
ask it anyway.

Jeremy



From jhylton at google.com  Thu Jun 24 11:15:41 2004
From: jhylton at google.com (Jeremy Hylton)
Date: Thu Jun 24 11:15:54 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <40D67098.7080907@v.loewis.de>
References: <40D67098.7080907@v.loewis.de>
Message-ID: <1088090139.30612.24.camel@slothrop.corp.google.com>

On Mon, 2004-06-21 at 01:22, "Martin v. L?wis" wrote:
> "If no exception is active in the current scope, an exception is raised 
> indicating this error."
> 
> "This" error probably being "no active exception", not "exception must
> not be NoneType".

We can determine statically whether an exception would active in the
current scope, right?  If the raise does not occur within an except
handler, then there is no active exception in the current scope.  I
think it should be a SyntaxError.

Jeremy



From ark-mlist at att.net  Thu Jun 24 11:29:11 2004
From: ark-mlist at att.net (Andrew Koenig)
Date: Thu Jun 24 11:29:11 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <200406230549.i5N5npU24506@guido.python.org>
Message-ID: <000701c459ff$ffe53340$6602a8c0@arkdesktop>


> (For other operations, I still want to see e.g. long+float to return a
> float rather than a long -- you *have* to do it this way for obvious
> reasons when the values are relatively small, e.g. consider 1 + 0.5.)

That is not unreasonable behavior.  However, I wonder if it might be
possible to do better by yielding a long in those cases where the value is
so large that the LSB of a float would be >=1.  By doing so, it might be
possible to guarantee that no precision is needlessly lost--analogously to
having the result of int addition yield a long when an int cannot contain
the result exactly.

Please understand that I am not advocating this strategy for arithmetic the
way I am for comparison, because I am not sure about its formal properties.
I'm going to think about it for a while; depending on my conclusions, I may
change my opinion later.



From ark at acm.org  Thu Jun 24 12:29:12 2004
From: ark at acm.org (Andrew Koenig)
Date: Thu Jun 24 12:44:44 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <200406241610.i5OGAq027921@guido.python.org>
Message-ID: <000b01c45a08$626f8350$6602a8c0@arkdesktop>

> Well, even if for comparisons we treat floats as if they were exact,
> for other purposes I want to keep the association of "float" with
> "inexact" and "int/long" with "exact", and I'd rather not return an
> "exact" result from an operation involvin an "inexact" operand.

Agreed.

> (The alternative, introducing exactness as a separate concept from
> representation, is better in theory but in practice just complicates
> matters needlessly.)

Also agreed.

However, I'm thinking less about exactness than I am about choosing the more
accurate of two possible representations for the result.

For example, in principle it should be possible to guarantee that x+0.0 == x
for all numeric values of x.  The unanswered question in my mind is whether
such a guarantee carries other undesirable properties along with it.

Incidentally, right now I am leaning toward the believe that such a
guarantee *does* carry other undesirable properties along with it.  For
example, consider 0L + 1e300.  It is clear that in principle, no accuracy is
lost by returning the result of this addition as a long.  It is equally
clear that in practice, it would be very slow.


From anthony at interlink.com.au  Thu Jun 24 10:43:53 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Thu Jun 24 12:49:38 2004
Subject: [Python-Dev] Windows/CE Python integration into development Python
	source tree
In-Reply-To: <000001c45829$a3d11ab0$050310ac@DAVIDSLAPTOP>
References: <000001c45829$a3d11ab0$050310ac@DAVIDSLAPTOP>
Message-ID: <40DAE8A9.1090906@interlink.com.au>

David L. Kashtan wrote:
> I am the person who has been doing the Windows/CE Python 2.3.4
> port.  Happily, the changes are minimal -- but I would like to
> get them into the source tree so Windows/CE can be a fully
> supported Python platform.  I have a patch kit for 2.3.4 that
> adds Windows/CE support.

Best first step is to post this as a patch to the SF tracker.


From guido at python.org  Thu Jun 24 12:10:52 2004
From: guido at python.org (Guido van Rossum)
Date: Thu Jun 24 13:07:08 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: Your message of "Thu, 24 Jun 2004 11:29:11 EDT."
	<000701c459ff$ffe53340$6602a8c0@arkdesktop> 
References: <000701c459ff$ffe53340$6602a8c0@arkdesktop> 
Message-ID: <200406241610.i5OGAq027921@guido.python.org>

[Resending -- I got a weird bounce about this]

> > (For other operations, I still want to see e.g. long+float to return a
> > float rather than a long -- you *have* to do it this way for obvious
> > reasons when the values are relatively small, e.g. consider 1 + 0.5.)
> 
> That is not unreasonable behavior.  However, I wonder if it might be
> possible to do better by yielding a long in those cases where the value is
> so large that the LSB of a float would be >=1.  By doing so, it might be
> possible to guarantee that no precision is needlessly lost--analogously to
> having the result of int addition yield a long when an int cannot contain
> the result exactly.
> 
> Please understand that I am not advocating this strategy for arithmetic the
> way I am for comparison, because I am not sure about its formal properties.
> I'm going to think about it for a while; depending on my conclusions, I may
> change my opinion later.

Well, even if for comparisons we treat floats as if they were exact,
for other purposes I want to keep the association of "float" with
"inexact" and "int/long" with "exact", and I'd rather not return an
"exact" result from an operation involvin an "inexact" operand.

(The alternative, introducing exactness as a separate concept from
representation, is better in theory but in practice just complicates
matters needlessly.)

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


From ark-mlist at att.net  Thu Jun 24 12:52:00 2004
From: ark-mlist at att.net (Andrew Koenig)
Date: Thu Jun 24 13:07:20 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <200406231457.i5NEvEO25398@guido.python.org>
Message-ID: <000c01c45a0b$91dfa630$6602a8c0@arkdesktop>

> No, the return type shouldn't depend on the input values.

It does already:

>>> 1000000000 + 1000000000
2000000000
>>> 2000000000 + 2000000000
4000000000L



From dave at boost-consulting.com  Thu Jun 24 13:26:20 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu Jun 24 13:26:58 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <40D84CEE.6040307@interlink.com.au>
Message-ID: <uisdgyiir.fsf@boost-consulting.com>

Anthony Baxter <anthony@interlink.com.au> writes:

> So, let the floodgates open. Remember, we _can_ change this any
> time up until 2.4b1, if there's a decision that the chosen form
> sucks. :-)

Here's thinking in a different direction altogether:

   No special syntax

   Instead, expose enough functionality in standard library functions
   that an appropriately-written pure-python "decorate" function can
   do it.


   decorate(staticmethod, my_decorator)
   def f(x):
       whatever()

   Since function definitions are executable statements, it should in
   principle be possible to arrange something that allows one to hook
   the execution of that statement.  Perhaps it's already doable with
   the debugger hook?

If you really want special syntax, this would at least be a way to
gain experience with decorators before introducing syntax changes, and
there's no reason you couldn't keep the decorate function alive
ongoingly.  It could also allow more flexible semantics (e.g. decorate
everything in the current scope with blah until I say otherwise).

You can go on introduce various syntactic abominations using the
special operator methods without actually changing the language
syntax, too.  I happen to like things like this, but I can understand
that some won't.  For example:


   decorated[staticmethod, my_decorator]
   def f(x):
       whatever()


   decorators <= staticmethod, my_decorator
   def f(x):
       whatever()


etc...

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From nbastin at opnet.com  Thu Jun 24 13:43:16 2004
From: nbastin at opnet.com (Nick Bastin)
Date: Thu Jun 24 13:43:34 2004
Subject: [Python-Dev] test_profile failing (yes, I know)
Message-ID: <F8EA5AD8-C605-11D8-A38A-000D932927FE@opnet.com>

Before anybody else sends me email.. ;-)  Yes, I know test_profile 
currently fails if you don't build with --with-c-profiling.  I'll fix 
the test as soon as I can.

--
Nick


From FBatista at uniFON.com.ar  Thu Jun 24 11:51:52 2004
From: FBatista at uniFON.com.ar (Batista, Facundo)
Date: Thu Jun 24 14:13:23 2004
Subject: [Python-Dev] Comparing heterogeneous types
Message-ID: <A128D751272CD411BC9200508BC2194D03383A94@escpl.tcp.com.ar>

#- > I maintain that when comparing a long with a float
#- > where the exponent is larger than the precision, that the
#- > float should be treated as if it were EXACTLY EQUAL TO 
#- > <coefficient>*2^<exponent>, instead of trying to treat it as
#- > some sort of a range. Similarly, if we implemented a Rational
#- > type, I would suggest that instances of float (or of Facundo's
#- > Decimal) where <exponent> is LESS than the digits of
#- > <coefficient> should be treated as if they were EXACTLY EQUAL
#- > TO the corresponding fraction-over-a-power-of-two.

Don't get to understand this. Could you send please an example of Decimal to
this case?

Thank you!

.	Facundo

From bob at redivi.com  Thu Jun 24 13:08:07 2004
From: bob at redivi.com (Bob Ippolito)
Date: Thu Jun 24 14:20:16 2004
Subject: [Python-Dev] Possible addition to itertools
In-Reply-To: <001401c457b0$528c3f00$dcad2c81@oemcomputer>
References: <001401c457b0$528c3f00$dcad2c81@oemcomputer>
Message-ID: <102398B0-C601-11D8-94F6-000A95686CD8@redivi.com>


On Jun 21, 2004, at 12:53 PM, Raymond Hettinger wrote:

> [Scott David Daniels]
>> One feature that I'd find nice in itertools is access to "universal
>> newlines" behavior.  This would make it much easier to extend zipfile
>> and other compression-related code to provide pseudo-files that
> iterate
>> properly.
>
>
> My initial thoughts are:
>
> * the functionality is useful
> * it duplicates some code from fileobject.c

Which isn't available in pure Python anywhere, and isn't extensible 
enough to do what he wants to do.

> * unsure whether the needs to be Unicode aware

Universal newlines doesn't really make sense in the context of unicode. 
  Unicode would definitely have another implementation, anyway 
(unicode.splitlines(...)).

FWIW, I've wanted to do things like this before..  but I think that the 
universal newlines support in fileobject should just be refactored so 
that you can use it without a file object (possibly with a similar API 
to this).

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040624/0033ecdc/smime.bin
From python at rcn.com  Thu Jun 24 02:49:06 2004
From: python at rcn.com (Raymond Hettinger)
Date: Thu Jun 24 14:49:59 2004
Subject: [Python-Dev] Possible addition to itertools
In-Reply-To: <102398B0-C601-11D8-94F6-000A95686CD8@redivi.com>
Message-ID: <003101c459b7$5b643e80$21ba958d@oemcomputer>



> -----Original Message-----
> > [Scott David Daniels]
> >> One feature that I'd find nice in itertools is access to "universal
> >> newlines" behavior.  This would make it much easier to extend
zipfile
> >> and other compression-related code to provide pseudo-files that
> > iterate
> >> properly.
> >

[Raymond]
> > My initial thoughts are:
> >
> > * the functionality is useful
> > * it duplicates some code from fileobject.c

[Bob]
> Which isn't available in pure Python anywhere, and isn't extensible
> enough to do what he wants to do.
> 
> > * unsure whether the needs to be Unicode aware
> 
> Universal newlines doesn't really make sense in the context of
unicode.
>   Unicode would definitely have another implementation, anyway
> (unicode.splitlines(...)).
> 
> FWIW, I've wanted to do things like this before..  but I think that
the
> universal newlines support in fileobject should just be refactored so
> that you can use it without a file object (possibly with a similar API
> to this).

I would support exposing this as a static function for the file type.
Alternately, I could see it going in the string module.


Raymond


From janssen at parc.com  Thu Jun 24 14:52:03 2004
From: janssen at parc.com (Bill Janssen)
Date: Thu Jun 24 14:52:36 2004
Subject: [Python-Dev] Re: decorators and 2.4 
In-Reply-To: Your message of "Tue, 22 Jun 2004 21:36:00 PDT."
	<200406230436.i5N4a0J24394@guido.python.org> 
Message-ID: <04Jun24.115206pdt."58612"@synergy1.parc.xerox.com>

Guido writes:
> One advantage mentioned by Fredrik Lundh of this, and also of my other
> favorite, over "decorators-after-args" is that the decorators are
> easily cut-and-pasted -- it's much easier to cut whole lines than
> sections of a line, and cutting a multiple-lines-spanning section is
> even worse.

Yeah, it makes the code marginally easier to edit, but it also makes
the code harder to read.  Used to be that "def" and "class" would
stand out in the file, being at the left edge.  Now you've got these
new lines, with, God help us, new syntax, cluttering up the left edge.
What's even worse, these decorators come before the function, so you
encounter them before you even know what function you're talking
about.  A reading nightmare.

I still prefer "def FUNCTION (ARGS) as DECORATOR[S]:", myself.

Bill

From eppstein at ics.uci.edu  Thu Jun 24 15:11:50 2004
From: eppstein at ics.uci.edu (David Eppstein)
Date: Thu Jun 24 15:12:08 2004
Subject: [Python-Dev] Re: Candidate Itertools
References: <20040618002301.GA22833@panix.com>
	<002101c4563c$43e4a160$52af958d@oemcomputer>
	<20040622035255.GB1891@panix.com>
Message-ID: <eppstein-E756A9.12115024062004@sea.gmane.org>

In article <20040622035255.GB1891@panix.com>,
 Aahz <aahz@pythoncraft.com> wrote:

> > Hmm, there seems to be 100% support for returning a dictionary and zero
> > support for my iterable (cnt, elem) ... to feed min(), max(), sorted(),
> > nlargest(), and nsmallest().
> 
> The problem is that it's useful for those operations -- and nothing
> else.  It's narrow functionality, and anyone looking just at itertools
> will find this confusing; it's just not the natural definition for
> something named ``count_elements``, and I suspect it is not possible to
> create a good name for your purpose.  Anyone who understands Python will
> expect ``count_elements`` to return (elem,cnt) or a dict.

I finally found the recent code where I'd used something like this
(for the curious: http://www.ics.uci.edu/~eppstein/numth/egypt/egypt.py)

I wrote it as a function that returns a dict (itemCounts in the above 
source) but what I actually did with the results in one place was to 
sort the (elem,cnt) pairs by elem (not by cnt) and then iterate through 
them in sorted order. In another place I used the dictionary directly 
but it amounted to the same thing.

So, either of Aahz's suggestions would have worked for me but the 
original (cnt,elem) suggestion wouldn't have been right.

-- 
David Eppstein                      http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science


From P at draigBrady.com  Thu Jun 24 15:16:25 2004
From: P at draigBrady.com (P@draigBrady.com)
Date: Thu Jun 24 16:06:49 2004
Subject: [Python-Dev] A better popen2
Message-ID: <40DB2889.60808@draigBrady.com>

I've written a couple of apps that required
running a command and grabbing the output,
and I've found the existing interfaces problematic for this.

I think the proliferation of functions and classes
in the popen2 module illustrates the problem
(popen2.{popen2,popen3,popen4,Popen3,Popen4})
Now if I want to read both stdout and stderr
seperately then it's awkward to say the least
to implement that without deadlocking using
the popen2 module. Also the multiplexing of
stdout and stderr in popen4 and commands.getoutput
is not usually what one requires IMHO.

There are external solutions like the getCommandOutput recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52296
which has problems that I've commented on there.
There are also very complex solutions like "subproc" from
Ken Manheimer and "task" from Rob Hooft

Therefore I bit the bullet and wrote my own,
with as simple an interface as I thought possible:
http://www.pixelbeat.org/libs/subProcess.py

Perhaps this could be included in commands.py for e.g.?

Any comments appreciated.

cheers,
P?draig.

p.s. sorry about the previous case of trigger finger

From P at draigBrady.com  Thu Jun 24 15:00:03 2004
From: P at draigBrady.com (P@draigBrady.com)
Date: Thu Jun 24 16:06:56 2004
Subject: [Python-Dev] popen2 problems
Message-ID: <40DB24B3.1050405@draigBrady.com>


-- 
P?draig Brady - http://www.pixelbeat.org
--- Following generated by rotagator ---

For useful non obvious keyboard bindings to various linux apps, see:
http://www.pixelbeat.org/lkdb/
--

From pje at telecommunity.com  Thu Jun 24 18:13:55 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu Jun 24 18:11:24 2004
Subject: [Python-Dev] lvalue casts in pyrexc
In-Reply-To: <1087597513.14512.16.camel@dionysus>
Message-ID: <5.1.1.6.0.20040624181215.026738f0@mail.telecommunity.com>

At 05:25 PM 6/18/04 -0500, Jon Oberheide wrote:
>Greetings,
>
>I apologize if this has already been discussed or implemented in CVS but
>I am not up to date on python development.
>
>With the release of GCC 3.4 and the continuing development of GCC 3.5,
>lvalue casts in C are being deprecated.  Fortunately GCC 3.4 only spits
>out a warning for them.  Unfortunately, us crazies using 3.5 will
>encounter an unfriendly error with the lvalue casts generated by pyrexc.
>Any information on this issue would be appreciated...thanks!

You're probably looking for the Pyrex mailing list: 
pyrex@lists.copyleft.no.  Python-Dev is for the development of Python 
itself; Pyrex is an add-on tool for Python.


From pje at telecommunity.com  Thu Jun 24 18:15:56 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu Jun 24 18:13:21 2004
Subject: [Python-Dev] NOP
In-Reply-To: <001b01c4568c$13710280$52af958d@oemcomputer>
Message-ID: <5.1.1.6.0.20040624181500.02673430@mail.telecommunity.com>

At 02:01 AM 6/20/04 -0400, Raymond Hettinger wrote:
>Any objections to my adding a NOP instruction to support additional code
>generation improvements in Python/compile.c?

Would this mean that the HAVE_ARG value would change?  I was under the 
impression that all the no-argument opcodes were used up, but it's been a 
while since I looked.


From python at rcn.com  Thu Jun 24 06:15:59 2004
From: python at rcn.com (Raymond Hettinger)
Date: Thu Jun 24 18:16:43 2004
Subject: [Python-Dev] NOP
In-Reply-To: <5.1.1.6.0.20040624181500.02673430@mail.telecommunity.com>
Message-ID: <008401c459d4$3f19a2c0$21ba958d@oemcomputer>

> Would this mean that the HAVE_ARG value would change?  I was under the
> impression that all the no-argument opcodes were used up, but it's
been a
> while since I looked.

No, there's room.


Raymond


From martin at v.loewis.de  Thu Jun 24 18:19:26 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu Jun 24 18:19:31 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <40DA93E5.1090404@egenix.com>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>	<200406171543.i5HFhFY04716@guido.python.org>
	<40D1D873.8080804@egenix.com> <40DA6289.8090509@v.loewis.de>
	<40DA93E5.1090404@egenix.com>
Message-ID: <40DB536E.3050600@v.loewis.de>

M.-A. Lemburg wrote:
>> Can you give examples for the remaining cases?
> 
> 
> A codec might want to return a buffer object, a mmapped
> file, a home grown object, an array, a PIL Image object,
> a WAV audio file object, etc. etc.

Which specific encoding would return a mmaped filed?

Regards,
Martin



From martin at v.loewis.de  Thu Jun 24 18:21:08 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu Jun 24 18:21:13 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <40DAC090.6010701@egenix.com>
References: <40D018F4.8080503@egenix.com> <40D126C2.5060603@v.loewis.de>
	<40DAC090.6010701@egenix.com>
Message-ID: <40DB53D4.50905@v.loewis.de>

M.-A. Lemburg wrote:
>> -1. I find it unfortunate that there are encodings which
>> don't convert between Unicode and byte strings; this direction
>> should not be followed.
>>
>> Instead, text processing utilities should be proper libraries.
> 
> 
> I don't understand... codecs are not limited to only text
> processing. It's a completely independent framework from the
> Unicode sub-system.

I know this is viewed, and perhaps even documented, as a
framework independent of Unicode. I think this is a mistake,
and it should have been constrained to character encodings
(i.e. conversions to and from Unicode, using character tables
or similar algorithms) right from the beginning.

Regards,
Martin




From kiko at async.com.br  Thu Jun 24 20:06:49 2004
From: kiko at async.com.br (Christian Robottom Reis)
Date: Thu Jun 24 20:07:19 2004
Subject: [Python-Dev] logging vs warnings?
In-Reply-To: <40DA6414.7040305@v.loewis.de>
References: <1087754792.2297.30.camel@emperor> <40DA6414.7040305@v.loewis.de>
Message-ID: <20040625000649.GF2291@async.com.br>

On Thu, Jun 24, 2004 at 07:18:12AM +0200, "Martin v. L?wis" wrote:
> Gustavo J. A. M. Carneiro wrote:
> >  Why do we have modules logging(2.3) and warnings(2.1)?  Does 'logging'
> >deprecate 'warnings' in any way?
> 
> No, logging does not deprecate warnings. Logging messages, and emitting
> warnings, are two completely different things.

I was going to make the same point, but let me confirm: warnings are for
code `issues', log messages are for application level `issues', right?

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331

From skip at pobox.com  Thu Jun 24 21:28:40 2004
From: skip at pobox.com (Skip Montanaro)
Date: Thu Jun 24 21:27:18 2004
Subject: [Python-Dev] Wild Idea for the Year
In-Reply-To: <20040624012622.713F.JCARLSON@uci.edu>
References: <001b01c45635$3a03cec0$52af958d@oemcomputer>
	<20040624012622.713F.JCARLSON@uci.edu>
Message-ID: <16603.32712.734573.476317@montanaro.dyndns.org>


    Josiah> That would be terribly nifty, but it begs the question:

    Josiah> If we do this for strings (an immutable sequence type), do we do
    Josiah> this for tuples (another immutable sequence type)?

No.  Concatenating tuples occurs rarely.  Concatenating strings occurs all
the time.

Skip

From bob at redivi.com  Thu Jun 24 21:47:25 2004
From: bob at redivi.com (Bob Ippolito)
Date: Thu Jun 24 21:47:31 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <20040624142741.GC27922@panix.com>
References: <1087414523.7150.45.camel@localhost>
	<001f01c4538d$f1fcfec0$bfaf2c81@oemcomputer>
	<20040624142741.GC27922@panix.com>
Message-ID: <9C03360A-C649-11D8-94F6-000A95686CD8@redivi.com>

On Jun 24, 2004, at 10:27 AM, Aahz wrote:

> On Wed, Jun 16, 2004, Raymond Hettinger wrote:
>>
>> Please do give consideration to putting all of this in a single
>> module.  IMO, this is too small of an addition to warrant splitting
>> everything in to packages (which make it more difficult to understand
>> and maintain as a collective unit).
>
> That's true.  However, there has been a regular low-level discussion
> about creating a ``text`` package; why not simply name it ``string``?

If nothing else, that would cause hell for people who would like to use 
a backport of the package for Python N, where N is less than the first 
version that had this feature but still had the string module.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040624/baade4fd/smime.bin
From pje at telecommunity.com  Thu Jun 24 23:40:27 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu Jun 24 23:38:02 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <1088090139.30612.24.camel@slothrop.corp.google.com>
References: <40D67098.7080907@v.loewis.de>
 <40D67098.7080907@v.loewis.de>
Message-ID: <5.1.1.6.0.20040624233855.03088160@mail.telecommunity.com>

At 11:15 AM 6/24/04 -0400, Jeremy Hylton wrote:
>On Mon, 2004-06-21 at 01:22, "Martin v. L?wis" wrote:
> > "If no exception is active in the current scope, an exception is raised
> > indicating this error."
> >
> > "This" error probably being "no active exception", not "exception must
> > not be NoneType".
>
>We can determine statically whether an exception would active in the
>current scope, right?  If the raise does not occur within an except
>handler, then there is no active exception in the current scope.  I
>think it should be a SyntaxError.

Wouldn't that break something like this:

     def errorHandler(value):
         if isinstance(value,SomethingInParticular):
             # do something
         else:
             raise

     try:
         # something
     except Exception,v:
         errorHandler(v)



From greg at cosc.canterbury.ac.nz  Thu Jun 24 23:52:44 2004
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu Jun 24 23:53:05 2004
Subject: [Python-Dev] decorators and 2.4
In-Reply-To: <40D84CEE.6040307@interlink.com.au>
Message-ID: <200406250352.i5P3qiau020589@cosc353.cosc.canterbury.ac.nz>

Anthony Baxter <anthony@interlink.com.au>:

> So, who's feeling adventurous? I'm convinced that this should go
> into 2.4 if possible

I'd hate for this to be rushed and end up freezing something into the
language that was later regretted. My feeling is that nobody's had
enough time to absorb the latest swerve that the discussion has taken.
We seemed to be converging on a solution everyone would be reasonably
happy with, and then Guido suddenly introduced something completely
off-the-wall. I think a pause for thought is needed.

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

From greg at cosc.canterbury.ac.nz  Thu Jun 24 23:57:27 2004
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu Jun 24 23:57:33 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <200406230436.i5N4a0J24394@guido.python.org>
Message-ID: <200406250357.i5P3vRNh020599@cosc353.cosc.canterbury.ac.nz>

Guido:

> @staticmethod
> @funcattrs(vegetable="blag", author="GvR")
> def blah2(args):
>     body
> 
> If people prefer my favorite (decorator-list-before-def, C# style)
> over Java-style, that's fine too... :-)

I don't really like either of them, but to my eyes your original one
is definitely the least worst. I find the @-signs extremely ugly.

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

From greg at cosc.canterbury.ac.nz  Fri Jun 25 00:07:52 2004
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Fri Jun 25 00:07:59 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <uisdgyiir.fsf@boost-consulting.com>
Message-ID: <200406250407.i5P47quA020612@cosc353.cosc.canterbury.ac.nz>

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

> You can go on introduce various syntactic abominations using the
> special operator methods without actually changing the language
> syntax, too.
>
> ...

  +staticmethod
  +foodstyle(sandwich)
  def eject(tomato):
    ...

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

From bob at redivi.com  Fri Jun 25 01:14:40 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Jun 25 01:14:49 2004
Subject: [Python-Dev] A better popen2
In-Reply-To: <40DB2889.60808@draigBrady.com>
References: <40DB2889.60808@draigBrady.com>
Message-ID: <8FE4B8BE-C666-11D8-94F6-000A95686CD8@redivi.com>


On Jun 24, 2004, at 3:16 PM, P@draigBrady.com wrote:

> I've written a couple of apps that required
> running a command and grabbing the output,
> and I've found the existing interfaces problematic for this.
>
> I think the proliferation of functions and classes
> in the popen2 module illustrates the problem
> (popen2.{popen2,popen3,popen4,Popen3,Popen4})
> Now if I want to read both stdout and stderr
> seperately then it's awkward to say the least
> to implement that without deadlocking using
> the popen2 module. Also the multiplexing of
> stdout and stderr in popen4 and commands.getoutput
> is not usually what one requires IMHO.
>
> There are external solutions like the getCommandOutput recipe:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52296
> which has problems that I've commented on there.
> There are also very complex solutions like "subproc" from
> Ken Manheimer and "task" from Rob Hooft
>
> Therefore I bit the bullet and wrote my own,
> with as simple an interface as I thought possible:
> http://www.pixelbeat.org/libs/subProcess.py
>
> Perhaps this could be included in commands.py for e.g.?

There's already a PEP and implementation for a new popen-ish module 
that supersedes all of them and probably covers all of your needs (I've 
already used it in several projects and it's worked great):
	http://www.python.org/peps/pep-0324.html

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040625/255aaaf9/smime.bin
From pje at telecommunity.com  Fri Jun 25 01:27:03 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri Jun 25 01:24:56 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <uisdgyiir.fsf@boost-consulting.com>
References: <40D84CEE.6040307@interlink.com.au>
Message-ID: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>

At 01:26 PM 6/24/04 -0400, David Abrahams wrote:
>Anthony Baxter <anthony@interlink.com.au> writes:
>
> > So, let the floodgates open. Remember, we _can_ change this any
> > time up until 2.4b1, if there's a decision that the chosen form
> > sucks. :-)
>
>Here's thinking in a different direction altogether:
>
>    No special syntax
>
>    Instead, expose enough functionality in standard library functions
>    that an appropriately-written pure-python "decorate" function can
>    do it.
>
>
>    decorate(staticmethod, my_decorator)
>    def f(x):
>        whatever()
>
>    Since function definitions are executable statements, it should in
>    principle be possible to arrange something that allows one to hook
>    the execution of that statement.  Perhaps it's already doable with
>    the debugger hook?

Hmmm.  You probably *could* create such a function in CPython, maybe even 
as far back as 2.1 (since all it needs is sys._getframe and the tracing 
hook), but it wouldn't be portable to Jython.

And, boy, would it be a sick and twisted piece of code.  You'd need to do 
something like keep a copy of the locals and on each "new line" event from 
the trace hook, you'd need to both call the old trace hook (so that 
debugging could still take place) and check to see if the locals had a new 
function object.  As soon as the function object appeared, you could do 
your dirty work (after first restoring the *old* value bound to that name, 
so the decorators would have access to the previous binding of the name).

About the only bit you couldn't do in pure Python would be decorating a 
function defined in a nested scope, because "fast locals" aren't accessible 
from pure Python.  But for module-level functions and methods in classes, 
this might actually work.  Heck, I'm rather tempted to try to write it and 
see if it does.  At worst, it might be a fun way to learn the ins and outs 
of sys.settrace().

[goes away for 30 minutes or so]

Hm, interesting.  After a bit of twiddling, I've got a rough draft of the 
trace mechanism.  It seems to be possible to chain tracer functions in the 
manner described, and I got it to work even with pdb running.  That is, if 
the debugger was already tracing a frame, adding co-operative trace 
functions didn't appear to disturb the debugger's operation.

However, there are certainly some "interesting" peculiarities in the trace 
function behavior.  There seems to be a bit of voodoo 
necessary.  Specifically, it seems as though one must call 'sys.settrace()' 
*and* set 'frame.f_trace' in order to change a local frame trace function, 
even though in theory just returning a new trace function from a 'line' 
event should work.

Ah well.  Here's a proof-of-concept version, that uses right-to-left 
application and simple calling for the decorators, but as you'll see, the 
bulk of the code is devoted to mechanism rather than policy.  You'll see 
that it's easy to write different policies, although the way I have the 
trace mechanism set up, later tracers execute *before* earlier 
tracers.  I'm not sure if this is the right way to go, but it seems to read 
best with this syntax.

Anyway, it works with CPython 2.2.  Caveat: do *not* use listcomps or any 
other assignment statements between your 'decorate()' invocation and the 
function definition, or the decorators will be applied to the bound-to 
variable!

Personally, I think the 'decorate()' function is probably actually not that 
useful, compared to making specialized decoration functions like, say:

    classmethod_follows()
    def foo(klass, x, y, z):
        # ...

Only with better names.  :)  Also, using this approach means you can do 
something like:

     [classmethod_follows()]

     def foo(klass, x, y, z):
         # ...

which comes awfully close to Guido's preferred syntax!

Anyway, concept code follows, and I'm quite tempted to add this to 
PyProtocols, which already has a similar function for class decoration.


# =======

import sys

def add_assignment_advisor(callback,depth=2):

     frame = sys._getframe(depth)

     oldtrace = [frame.f_trace]
     old_locals = frame.f_locals.copy()

     def tracer(frm,event,arg):

         if event=='call':
             if oldtrace[0]:
                 return oldtrace[0](frm,event,arg)
             else:
                 return None

         try:
             if frm is frame and event !='exception':
                 for k,v in frm.f_locals.items():
                     if k not in old_locals:
                         del frm.f_locals[k]
                         break
                     elif old_locals[k] is not v:
                         frm.f_locals[k] = old_locals[k]
                         break
                 else:
                     return tracer

                 callback(frm,k,v)

         finally:
             if oldtrace[0]:
                 oldtrace[0] = oldtrace[0](frm,event,arg)

         frm.f_trace = oldtrace[0]
         sys.settrace(oldtrace[0])
         return oldtrace[0]

     frame.f_trace = tracer
     sys.settrace(tracer)


def decorate(*decorators):

     if len(decorators)>1:
         decorators = list(decorators)
         decorators.reverse()

     def callback(frame,k,v):
         for d in decorators:
             v = d(v)
         frame.f_locals[k] = v

     add_assignment_advisor(callback)



decorate(classmethod)

def f(klass,x,y):
     pass

print f



From bac at OCF.Berkeley.EDU  Fri Jun 25 01:50:54 2004
From: bac at OCF.Berkeley.EDU (Brett C.)
Date: Fri Jun 25 01:51:13 2004
Subject: [Python-Dev] A better popen2
In-Reply-To: <40DB2889.60808@draigBrady.com>
References: <40DB2889.60808@draigBrady.com>
Message-ID: <40DBBD3E.1030602@ocf.berkeley.edu>

I am not Cc:ing c.l.py for fear of flooding this discussion (and also 
for having a thread from hell for me to summarize later  =).

P@draigBrady.com wrote:
> I've written a couple of apps that required
> running a command and grabbing the output,
> and I've found the existing interfaces problematic for this.
> 
> I think the proliferation of functions and classes
> in the popen2 module illustrates the problem
> (popen2.{popen2,popen3,popen4,Popen3,Popen4})
> Now if I want to read both stdout and stderr
> seperately then it's awkward to say the least
> to implement that without deadlocking using
> the popen2 module. Also the multiplexing of
> stdout and stderr in popen4 and commands.getoutput
> is not usually what one requires IMHO.
> 

How does this compare to popen5 and PEP 324 
(http://www.python.org/peps/pep-0324.html)?  If it doesn't solve your 
problem perhaps you can work with Peter Astrand and get it rolled into 
the PEP so that there is a single popen replacement in development.

-Brett

From python at rcn.com  Thu Jun 24 14:25:34 2004
From: python at rcn.com (Raymond Hettinger)
Date: Fri Jun 25 02:50:03 2004
Subject: [Python-Dev] Re: Candidate Itertools
In-Reply-To: <eppstein-E756A9.12115024062004@sea.gmane.org>
Message-ID: <00ff01c45a18$a42ddac0$21ba958d@oemcomputer>

[David Eppstein]
>In another place I used the dictionary directly
> but it amounted to the same thing.

All respondents prefer having a dictionary (elements mapped to counts)
instead of an itertool returning (cnt, elem) ...

Just to be clear before I do it, does everyone support having
dict.countkeys() as a dictionary classmethod instead of the original
proposal?


Raymond


From mal at egenix.com  Fri Jun 25 04:34:17 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jun 25 04:34:25 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <40DB53D4.50905@v.loewis.de>
References: <40D018F4.8080503@egenix.com>
	<40D126C2.5060603@v.loewis.de>	<40DAC090.6010701@egenix.com>
	<40DB53D4.50905@v.loewis.de>
Message-ID: <40DBE389.2040308@egenix.com>

Martin v. L?wis wrote:
> M.-A. Lemburg wrote:
> 
>>> -1. I find it unfortunate that there are encodings which
>>> don't convert between Unicode and byte strings; this direction
>>> should not be followed.
>>>
>>> Instead, text processing utilities should be proper libraries.
>>
>> I don't understand... codecs are not limited to only text
>> processing. It's a completely independent framework from the
>> Unicode sub-system.
> 
> I know this is viewed, and perhaps even documented, as a
> framework independent of Unicode. I think this is a mistake,
> and it should have been constrained to character encodings
> (i.e. conversions to and from Unicode, using character tables
> or similar algorithms) right from the beginning.

Ok, noted.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 25 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
IL Workshop @ Net.ObjectDays 2004, Erfurt, Germany          93 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From mal at egenix.com  Fri Jun 25 04:38:35 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jun 25 04:38:40 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <200406191529.i5JFTmx08976@guido.python.org>
References: <200406162115.i5GLFRrb050850@chilled.skew.org>	<200406171543.i5HFhFY04716@guido.python.org>
	<40D1D873.8080804@egenix.com>
	<200406191529.i5JFTmx08976@guido.python.org>
Message-ID: <40DBE48B.9080502@egenix.com>

Guido van Rossum wrote:
>>Ok, how about a compromise: .encode() and .decode() of string
>>and unicode objects may return string or unicode objects only
>>(limiting the set of types to two base types).
> 
> 
> This works for me, especially since I expect type inferencers to
> collapse the two types (just as they should collapse int and long).

Ok, I'll make the necessary changes next week.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 25 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
IL Workshop @ Net.ObjectDays 2004, Erfurt, Germany          93 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From Paul.Moore at atosorigin.com  Fri Jun 25 04:44:31 2004
From: Paul.Moore at atosorigin.com (Moore, Paul)
Date: Fri Jun 25 04:44:32 2004
Subject: [Python-Dev] A better popen2
Message-ID: <16E1010E4581B049ABC51D4975CEDB8803060EFC@UKDCX001.uk.int.atosorigin.com>

From: P@draigBrady.com
> I've written a couple of apps that required
> running a command and grabbing the output,
> and I've found the existing interfaces problematic for this.

You're not the only one who has found this. Have a look at PEP 324.

> Therefore I bit the bullet and wrote my own,
> with as simple an interface as I thought possible:
> http://www.pixelbeat.org/libs/subProcess.py

> Perhaps this could be included in commands.py for e.g.?

As it stands, this looks like it is Unix-only, which would probably
be an issue for a standard library function.

Paul.


__________________________________________________________________________
This e-mail and the documents attached are confidential and intended 
solely for the addressee; it may also be privileged. If you receive this 
e-mail in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group 
liability cannot be triggered for the message content. Although the 
sender endeavours to maintain a computer virus-free network, the sender 
does not warrant that this transmission is virus-free and will not be 
liable for any damages resulting from any virus transmitted.
__________________________________________________________________________

From aleaxit at yahoo.com  Fri Jun 25 05:20:33 2004
From: aleaxit at yahoo.com (Alex Martelli)
Date: Fri Jun 25 05:20:33 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <1088090139.30612.24.camel@slothrop.corp.google.com>
References: <40D67098.7080907@v.loewis.de>
	<1088090139.30612.24.camel@slothrop.corp.google.com>
Message-ID: <E8C8327B-C688-11D8-8348-000A95EFAE9E@yahoo.com>


On 2004 Jun 24, at 17:15, Jeremy Hylton wrote:

> On Mon, 2004-06-21 at 01:22, "Martin v. L?wis" wrote:
>> "If no exception is active in the current scope, an exception is 
>> raised
>> indicating this error."
>>
>> "This" error probably being "no active exception", not "exception must
>> not be NoneType".
>
> We can determine statically whether an exception would active in the
> current scope, right?  If the raise does not occur within an except
> handler, then there is no active exception in the current scope.  I
> think it should be a SyntaxError.

Isn't the "raise" allowed to occur in a function that may be _called 
from_ an except handler? E.g.:

 >>> def foo():
...     print "do something here"
...     raise
...
 >>> try: 1/0
... except Exception: foo()

as one might obtain from refactoring otherwise duplicated "clean up a 
few things after an exception, then propagate the exception" code into 
a function foo.  Of course, this could easily be coded otherwise (just 
a bit more verbosely: keep the raise out of foo, use "foo(); raise" 
wherever foo is now called), but before making a SyntaxError out of a 
construct that's long been quite correct and may well be present in 
good working code one would surely need at least one transition release 
where the construct produces a warning, right?

Indeed. I looked for examples in the Python standard library and it 
wasn't hard to find some (there may be others, I only did a quick rough 
search) -- compiler/pycodegen.py method visitSlice of class 
CodeGenerator has a bare raise as the very last line of code (NOT 
statically inside an except handler); idlelib/rpc.py has a really 
interesting construct in method handle_error of class RPCServer:
         try:
             raise
         except SystemExit:
             raise
         except:
             erf = sys.__stderr__
             (etc etc)
also found elsewhere in idlelib, and another simpler bare raise is also 
in handle_error in class MyMixinServer in test_socketserver.py (indeed 
such handle_error methods might seem good candidates for cases of "bare 
raise not statically within an except handler").  It appears to me that 
finding examples of use of a construct inside such "hallowed" code as 
found in the standard library further militates in favour of having to 
be very cautious before making that construct into a SyntaxError.


Alex


From pyth at devel.trillke.net  Fri Jun 25 06:00:27 2004
From: pyth at devel.trillke.net (Holger Krekel)
Date: Fri Jun 25 06:00:32 2004
Subject: [Python-Dev] Re: Candidate Itertools
In-Reply-To: <00ff01c45a18$a42ddac0$21ba958d@oemcomputer>
References: <eppstein-E756A9.12115024062004@sea.gmane.org>
	<00ff01c45a18$a42ddac0$21ba958d@oemcomputer>
Message-ID: <20040625100027.GA23296@solar.trillke>

Raymond Hettinger wrote:
> [David Eppstein]
> >In another place I used the dictionary directly
> > but it amounted to the same thing.
> 
> All respondents prefer having a dictionary (elements mapped to counts)
> instead of an itertool returning (cnt, elem) ...
> 
> Just to be clear before I do it, does everyone support having
> dict.countkeys() as a dictionary classmethod instead of the original
> proposal?

I don't see the need for this method to be so high as to warrant
it to live on the dict object.  FWIW, when i came to python i especially
enjoyed the sparcity of methods on lists and dictionaries, of which
each usage was almost immediately obvious. 

    holger

From arigo at tunes.org  Fri Jun 25 06:01:25 2004
From: arigo at tunes.org (Armin Rigo)
Date: Fri Jun 25 06:04:02 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
References: <40D84CEE.6040307@interlink.com.au>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
Message-ID: <20040625100125.GA15576@vicky.ecs.soton.ac.uk>

Hello Phillip,

On Fri, Jun 25, 2004 at 01:27:03AM -0400, Phillip J. Eby wrote:
> About the only bit you couldn't do in pure Python would be decorating a 
> function defined in a nested scope, because "fast locals" aren't accessible 
> from pure Python.

Would you believe it?  Your implementation works just fine in this case too
:-)  sysmodule.c invokes PyFrame_FastToLocals and PyFrame_LocalsToFast around
a call to a trace function, so that any change to f_locals from the trace
function are actually correctly reflected into the frame.

Excellent.  Let's put this in the standard library and close the issue ;-)

As an easy extension, decorate(attr=value, ...) could just assign attributes
to the function object.  Also, the fact that it works with other assignment
statements is a bonus in my opinion, e.g.:

class X:
    decorate(doc("Number of instances created."))
    counter = 0

    def __init__(self):
        X.counter += 1

However, it gets a bit lost if several variables are assigned to in one line.


A bientot,

Armin.

From jeremy at alum.mit.edu  Fri Jun 25 07:10:47 2004
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri Jun 25 07:10:53 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <E8C8327B-C688-11D8-8348-000A95EFAE9E@yahoo.com>
References: <40D67098.7080907@v.loewis.de>
	<1088090139.30612.24.camel@slothrop.corp.google.com>
	<E8C8327B-C688-11D8-8348-000A95EFAE9E@yahoo.com>
Message-ID: <1088161847.30612.40.camel@slothrop.corp.google.com>

On Fri, 2004-06-25 at 05:20, Alex Martelli wrote:
> On 2004 Jun 24, at 17:15, Jeremy Hylton wrote:
> 
> > On Mon, 2004-06-21 at 01:22, "Martin v. L?wis" wrote:
> >> "If no exception is active in the current scope, an exception is 
> >> raised
> >> indicating this error."
> >>
> >> "This" error probably being "no active exception", not "exception must
> >> not be NoneType".
> >
> > We can determine statically whether an exception would active in the
> > current scope, right?  If the raise does not occur within an except
> > handler, then there is no active exception in the current scope.  I
> > think it should be a SyntaxError.
> 
> Isn't the "raise" allowed to occur in a function that may be _called 
> from_ an except handler? E.g.:
> 
>  >>> def foo():
> ...     print "do something here"
> ...     raise
> ...
>  >>> try: 1/0
> ... except Exception: foo()

The definition of what it means for an exception to be "active" in a
scope needs to be clarified.  The language reference doesn't appear to
define what that means, so I took a narrow reading.  I think the code
you mention later in your post is code I wrote :-).

Jeremy



From dave at boost-consulting.com  Fri Jun 25 08:26:15 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri Jun 25 08:26:45 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	(Phillip J. Eby's message of "Fri, 25 Jun 2004 01:27:03 -0400")
References: <40D84CEE.6040307@interlink.com.au>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
Message-ID: <uu0wzvn6g.fsf@boost-consulting.com>

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

> At 01:26 PM 6/24/04 -0400, David Abrahams wrote:
>>Anthony Baxter <anthony@interlink.com.au> writes:
>>
>> > So, let the floodgates open. Remember, we _can_ change this any
>> > time up until 2.4b1, if there's a decision that the chosen form
>> > sucks. :-)
>>
>>Here's thinking in a different direction altogether:
>>
>>    No special syntax
>>
>>    Instead, expose enough functionality in standard library functions
>>    that an appropriately-written pure-python "decorate" function can
>>    do it.
>>
>>
>>    decorate(staticmethod, my_decorator)
>>    def f(x):
>>        whatever()
>>
>>    Since function definitions are executable statements, it should in
>>    principle be possible to arrange something that allows one to hook
>>    the execution of that statement.  Perhaps it's already doable with
>>    the debugger hook?
>
> Hmmm.  You probably *could* create such a function in CPython, maybe
> even as far back as 2.1 (since all it needs is sys._getframe and the
> tracing hook), but it wouldn't be portable to Jython.
>
> And, boy, would it be a sick and twisted piece of code.  

What you wrote doesn't look all *that* awful.

> You'd need to do something like keep a copy of the locals and on
> each "new line" event from the trace hook, you'd need to both call
> the old trace hook (so that debugging could still take place) and
> check to see if the locals had a new function object.  As soon as
> the function object appeared, you could do your dirty work (after
> first restoring the *old* value bound to that name, so the
> decorators would have access to the previous binding of the name).

I'm perfectly happy for this decorate function to work on the very
next name binding; I don't think it's reasonable to expect to be able
to do anything else between it and the function definition.

> About the only bit you couldn't do in pure Python would be
> decorating a function defined in a nested scope, because "fast
> locals" aren't accessible from pure Python.  

You're beyond my expertise here.

> But for module-level functions and methods in classes, this might
> actually work.  Heck, I'm rather tempted to try to write it and see
> if it does.  At worst, it might be a fun way to learn the ins and
> outs of sys.settrace().

<snip>

> Anyway, it works with CPython 2.2.  Caveat: do *not* use listcomps or
> any other assignment statements between your 'decorate()' invocation
> and the function definition, or the decorators will be applied to the
> bound-to variable!
>
> Personally, I think the 'decorate()' function is probably actually not
> that useful, compared to making specialized decoration functions like,
> say:
>
>     classmethod_follows()
>     def foo(klass, x, y, z):
>         # ...

Ick!

> Only with better names.  :)  Also, using this approach means you can
> do something like:
>
>      [classmethod_follows()]

Ick in brackets ;-> !


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From tim.one at comcast.net  Thu Jun 24 17:11:53 2004
From: tim.one at comcast.net (Tim Peters)
Date: Fri Jun 25 09:34:33 2004
Subject: [Python-Dev] Weekly Python Bug/Patch Summary (2nd try)
In-Reply-To: <20040621172236.GA16146@panix.com>
Message-ID: <mailman.93.1088170473.27574.python-dev@python.org>

[Aahz]
> ...and it just now showed up in my mailbox.  mail.python.org has been
> under severe load for several days, everyone please be patient.  I'll
> probably poke Thomas Wouters about the status of the new machines XS4ALL
> has been promising.

I don't want to leave anyone with the impression that this email disaster
has been somehow the fault of Thomas or of XS4ALL.  XS4ALL has had nothing
at all to do with python.org email so far, and, to the contrary, generously
offered to contribute new machine resources so python.org email would have
better luck.

python.org email has to be migrated to the new machine, though, and humans
are the bottleneck there (e.g., "spare time" for Barry).

Zope Corp is also in the process of moving zope.org email off the machine
python.org email has been using, and that takes time too, but has the
immediate good effect of decreasing the load on both email machines.



From tim.one at comcast.net  Thu Jun 24 20:00:21 2004
From: tim.one at comcast.net (Tim Peters)
Date: Fri Jun 25 09:34:42 2004
Subject: [Python-Dev] Wild Idea for the Year
In-Reply-To: <002401c4594a$de36c5c0$9417c797@oemcomputer>
Message-ID: <mailman.94.1088170482.27574.python-dev@python.org>

[Raymond Hettinger, on lazy string cat]
> ...
> With little effort on the C side, there is an opportunity to be the
> first dynamic language with O(n) behavior for serial string
> concatenations -- one less thing to teach, one step towards scalability.

Perl has mutable strings, and appending is done in-place.  I don't know
whether they do all the memory mgmt tricks needed to guarantee worst-case
linear behavior, but in practice stuff like this doesn't visibly slow down
as time goes on (while it slows down dramatically in Python):

$a = 'x';
while (1) {
     $a .= 'x';
     if (length($a) % 1000 == 0) {
         print length($a), "\n";
     }
}

Icon has immutable strings, but append-a-bunch-of-stuff-to-a-new-string is
*often* linear-time there too.  That's an implementation trick, relying on a
compacting garbage collector so that new allocations are done just by
incrementing the high-water mark at the end of the current free area.  In
practice it often turns out to be the case that catenating strings a & b
into a finds a and b to be the "last two" memory regions allocated, and then
the total cost of catenation is building a new (fixed-size) string
descriptor, spanning the combined regions.  So a compacting garbage
collector, the internal use of string descriptors, and *not* sticking a NUL
byte on the end of strings all conspire to make this possible.

Java uses mutable string buffers under the covers, so avoids quadratic-time
behavior too.  The compiler conspires to make that happen.

Python isn't unique in having a problem to solve here, but it's not the
first to think of it either.

>> But wait, I think it won't fly at all unless you make ob_sval a pointer
>> to separately allocated memory.  Otherwise, how could _autojoin()
>> possibly "fix" the string without allocating the memory for it?

> PyString_Resize().

There isn't such a thing.  The function you're thinking of is
_PyString_Resize(), and it's in the private API for good reason:  it's
dangerous, *because* it can need to move the string object.  Note that the
implementation aborts unless the refcount on the string object is 1.  It's
intended to be used internally, and with no possibility of Python-level code
"seeing" a string object between the time it's created and the time
_PyString_Resize() returns.

> ...
> That being said, I didn't miss that you hate the idea, so I'll craft a
> recipe and drop it :-(

Because of the prohibition against relocating visible Python objects, this
isn't so easy to worm around in Python.  "".join(strings) is just a rite of
Python passage.



From dave at boost-consulting.com  Fri Jun 25 09:36:07 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri Jun 25 09:36:34 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <uisdgyiir.fsf@boost-consulting.com>
	<200406250407.i5P47quA020612@cosc353.cosc.canterbury.ac.nz>
Message-ID: <uisdfvjy0.fsf@boost-consulting.com>

Greg Ewing <greg@cosc.canterbury.ac.nz> writes:

> David Abrahams <dave@boost-consulting.com>:
>
>> You can go on introduce various syntactic abominations using the
>> special operator methods without actually changing the language
>> syntax, too.
>>
>> ...
>
>   +staticmethod
>   +foodstyle(sandwich)
>   def eject(tomato):
>     ...

Big smile over here!

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From marktrussell at btopenworld.com  Fri Jun 25 09:37:25 2004
From: marktrussell at btopenworld.com (Mark Russell)
Date: Fri Jun 25 09:37:32 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <200406230436.i5N4a0J24394@guido.python.org>
References: <40D84CEE.6040307@interlink.com.au>
	<200406230436.i5N4a0J24394@guido.python.org>
Message-ID: <1088170645.1554.9.camel@localhost>

On Wed, 2004-06-23 at 05:36, Guido van Rossum wrote:
>     @staticmethod
>     @funcattrs(vegetable="blag", author="GvR")
>     def blah2(args):
>         body
> 
> I would love to see an implementation of this idea.

OK, here's my stab at it: python.org/sf/979728

It's fairly minimal - I guess the biggest impact change is that funcdef
is now defined in Grammar/Grammer as:

     decorator: '@' test [NEWLINE]
     decorators: decorator+
     funcdef: [decorators] 'def' NAME parameters ':' suite

As this version of funcdef has an optional element at the beginning, I
changed the funcdef child node references (in compile.c and
parsermodule.c) to use a new macro RCHILD() which takes a negative index
and treats it as relative to the end of the node's children array.  

Mark Russell



From aahz at pythoncraft.com  Fri Jun 25 10:29:57 2004
From: aahz at pythoncraft.com (Aahz)
Date: Fri Jun 25 10:30:02 2004
Subject: [Python-Dev] Comparing heterogeneous types
In-Reply-To: <000c01c45a0b$91dfa630$6602a8c0@arkdesktop>
References: <200406231457.i5NEvEO25398@guido.python.org>
	<000c01c45a0b$91dfa630$6602a8c0@arkdesktop>
Message-ID: <20040625142957.GA9339@panix.com>

On Thu, Jun 24, 2004, Andrew Koenig wrote:
>Guido:
>>
>> No, the return type shouldn't depend on the input values.
> 
> It does already:
> 
> >>> 1000000000 + 1000000000
> 2000000000
> >>> 2000000000 + 2000000000
> 4000000000L

Yes, and that's strictly a transitional wart.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith, c.l.py

From paul at prescod.net  Fri Jun 25 11:40:15 2004
From: paul at prescod.net (Paul Prescod)
Date: Fri Jun 25 11:40:28 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <04Jun24.115206pdt."58612"@synergy1.parc.xerox.com>
References: <04Jun24.115206pdt."58612"@synergy1.parc.xerox.com>
Message-ID: <40DC475F.4070202@prescod.net>

Bill Janssen wrote:

>...
> 
> Yeah, it makes the code marginally easier to edit, but it also makes
> the code harder to read.  Used to be that "def" and "class" would
> stand out in the file, being at the left edge.  Now you've got these
> new lines, with, God help us, new syntax, cluttering up the left edge.

The left edge is already cluttered.

a = 5
b = a()
def foo(xyz):
     abc = 5
c = 20

It is the indentation that alerts your eye to the function definition.

> What's even worse, these decorators come before the function, so you
> encounter them before you even know what function you're talking
> about.  A reading nightmare.

Nobody reads code one line at a time from the top down. You scan for the 
bit that interests you and then look around for its context.

  Paul Prescod



From mchermside at ingdirect.com  Fri Jun 25 12:22:54 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Fri Jun 25 12:23:03 2004
Subject: [Python-Dev] Comparing heterogeneous types
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550ADA@ingdexj1.ingdirect.com>

> #- > I maintain that when comparing a long with a float
> #- > where the exponent is larger than the precision, that the
> #- > float should be treated as if it were EXACTLY EQUAL TO 
> #- > <coefficient>*2^<exponent>, instead of trying to treat it as
> #- > some sort of a range. Similarly, if we implemented a Rational
> #- > type, I would suggest that instances of float (or of Facundo's
> #- > Decimal) where <exponent> is LESS than the digits of
> #- > <coefficient> should be treated as if they were EXACTLY EQUAL
> #- > TO the corresponding fraction-over-a-power-of-two.

Facundo writes:
> Don't get to understand this. Could you send please an 
> example of Decimal to
> this case?

Presume a Rational type:

    >>> class Rational(object):
    >>>     def __init__(self, num, denom):
    >>>         self.num = num
    >>>         self.denom = denom
    >>>     # ....

Now define the following

    >>> x = 12300
    >>> y = Decimal.Decimal((0,(1,2,3),2))
    >>> z = Rational(1230000,100)

I maintain that x == y should be true (and it is, today).
I maintain that x == z should be true (and it is, obviously).
I maintain that y == z should be true. _IF_ you think
of Decimal.Decimal((0,(1,2,3),2)) as being "any number which,
when rounded to the nearest hundred, gives 12300" (in other
words, as the range 12250..12350), then you might not agree.
But if you think of Decimal.Decimal((0,(1,2,3),2)) as
being *exactly* 12300 (but with a precision of only 3 places),
then you'd want x == z to be true.

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From eppstein at ics.uci.edu  Fri Jun 25 13:19:01 2004
From: eppstein at ics.uci.edu (David Eppstein)
Date: Fri Jun 25 13:19:08 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <200406230436.i5N4a0J24394@guido.python.org>
	<200406250357.i5P3vRNh020599@cosc353.cosc.canterbury.ac.nz>
Message-ID: <eppstein-3D743B.10190125062004@sea.gmane.org>

In article <200406250357.i5P3vRNh020599@cosc353.cosc.canterbury.ac.nz>,
 Greg Ewing <greg@cosc.canterbury.ac.nz> wrote:

> > If people prefer my favorite (decorator-list-before-def, C# style)
> > over Java-style, that's fine too... :-)
> 
> I don't really like either of them, but to my eyes your original one
> is definitely the least worst. I find the @-signs extremely ugly.

I wouldn't say they're pretty, but I like them better than the 
alternative C# list-followed-by-def-magically-becomes-decorator.
And the argument about being able to cut and paste them a line at a time 
makes sense to me too.

-- 
David Eppstein                      http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science


From jcarlson at uci.edu  Fri Jun 25 13:27:17 2004
From: jcarlson at uci.edu (Josiah Carlson)
Date: Fri Jun 25 13:32:21 2004
Subject: [Python-Dev] Re: Candidate Itertools
In-Reply-To: <20040625100027.GA23296@solar.trillke>
References: <00ff01c45a18$a42ddac0$21ba958d@oemcomputer>
	<20040625100027.GA23296@solar.trillke>
Message-ID: <20040625102308.95BD.JCARLSON@uci.edu>

> > All respondents prefer having a dictionary (elements mapped to counts)
> > instead of an itertool returning (cnt, elem) ...
> > 
> > Just to be clear before I do it, does everyone support having
> > dict.countkeys() as a dictionary classmethod instead of the original
> > proposal?
> 
> I don't see the need for this method to be so high as to warrant
> it to live on the dict object.  FWIW, when i came to python i especially
> enjoyed the sparcity of methods on lists and dictionaries, of which
> each usage was almost immediately obvious. 


Since there exists a dict.fromkeys method, there is precidence for
adding a dict.countkeys method.

 - Josiah


From pje at telecommunity.com  Fri Jun 25 16:09:19 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri Jun 25 16:06:42 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <20040625100125.GA15576@vicky.ecs.soton.ac.uk>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<40D84CEE.6040307@interlink.com.au>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>

At 11:01 AM 6/25/04 +0100, Armin Rigo wrote:
>Hello Phillip,
>
>On Fri, Jun 25, 2004 at 01:27:03AM -0400, Phillip J. Eby wrote:
> > About the only bit you couldn't do in pure Python would be decorating a
> > function defined in a nested scope, because "fast locals" aren't 
> accessible
> > from pure Python.
>
>Would you believe it?  Your implementation works just fine in this case too
>:-)  sysmodule.c invokes PyFrame_FastToLocals and PyFrame_LocalsToFast around
>a call to a trace function, so that any change to f_locals from the trace
>function are actually correctly reflected into the frame.

Wow.  You're right, it does work.  The time machine strikes again.  :)


>Excellent.  Let's put this in the standard library and close the issue ;-)

Ah, if only that *would* close the issue.  It really just opens more, I'm 
afraid.


>As an easy extension, decorate(attr=value, ...) could just assign attributes
>to the function object.  Also, the fact that it works with other assignment
>statements is a bonus in my opinion, e.g.:

See, I told you it opens more issues.

Among them:

* The location in the stdlib of 'decorate'

* The signature of 'decorate', including whether it should even be *called* 
'decorate', or something else.

* Whether to have a 'decorate' function at all, or whether it's better to 
just list specialized decorator objects/functions (I generally favor the 
latter, since 'decorate' is IMO a dead chicken that hasn't appeared in any 
widely-supported syntax proposals to date).

* Which of the numerous possible syntax variations should be used/recommended:

   +classmethod
   +attrs(spam="fidget")
   def foo(...):
       ...

   [classmethod(), attrs(spam="fidget")]
   def foo(...):
       ...

   ~classmethod
   ~attrs(spam="fidget")
   def foo(...):
       ...

   -classmethod
   -attrs(spam="fidget")
   def foo(...):
       ...

   All of these are possible, and each likely to have *some* 
proponents.  Oh, and let's not forget the question of application order of 
the decorations.  :)  I personally favor a(b(c(...))) ordering for 
decorations that are listed before the 'def', even though I favor a(), b(), 
c() ordering for decorations that come after.


Anyway, I think it's probably more realistic to say that the presence of a 
viable implementation approach that allows numerous policies and syntax 
variants to be experimented with, even in existing Python versions, means 
it's more likely that Guido will *not* allow this in the stdlib for 2.4, 
and leave it for the frameworks that need this to fight it out amongst 
themselves.

I'm not sure if this is good or bad.  Personally, I'd prefer Guido to 
"bless" one of the above syntax alternatives as the recommended way to do 
these things, along with a "blessed" order in which decorators should be 
applied.  Then, in any of my frameworks that I implement this for, I'll be 
able to be "forward compatible" with other frameworks that do the same.

By the way, I should also mention that I think with this approach, my 
strongest objection to Guido's original syntax proposal goes away: if you 
have to *call* the decorators, it makes it more obvious that something is 
happening.  When you could just list '[classmethod]', it's not obvious that 
that line *does* anything.  If you have '[classmethod()]', it's apparent 
that something is being invoked.


From pje at telecommunity.com  Fri Jun 25 16:16:46 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri Jun 25 16:14:03 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <uu0wzvn6g.fsf@boost-consulting.com>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<40D84CEE.6040307@interlink.com.au>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20040625161132.0287d2d0@mail.telecommunity.com>

At 08:26 AM 6/25/04 -0400, David Abrahams wrote:
>"Phillip J. Eby" <pje@telecommunity.com> writes:
> > You'd need to do something like keep a copy of the locals and on
> > each "new line" event from the trace hook, you'd need to both call
> > the old trace hook (so that debugging could still take place) and
> > check to see if the locals had a new function object.  As soon as
> > the function object appeared, you could do your dirty work (after
> > first restoring the *old* value bound to that name, so the
> > decorators would have access to the previous binding of the name).
>
>I'm perfectly happy for this decorate function to work on the very
>next name binding; I don't think it's reasonable to expect to be able
>to do anything else between it and the function definition.

Keep in mind that this means code like this:

decorate(foo)
decorate(bar(baz=[x*2 for x in y]))
def spam():
     pass

Will likely fail horribly, applying the 'foo' decorator to the first 
element of 'y' before trying to multiply by 2, or worse, possibly applying 
them to the "anonymous" list object that's created to hold the results of 
the list comprehension.  Or, it might sometimes *seem* to work due to 
hashing order and the vagaries of when 'line' events fire, and then fail in 
a new release of Python.  This is why I consider it somewhat of a wart in 
the current implementation, as I note below...


> > Anyway, it works with CPython 2.2.  Caveat: do *not* use listcomps or
> > any other assignment statements between your 'decorate()' invocation
> > and the function definition, or the decorators will be applied to the
> > bound-to variable!
> >
> > Personally, I think the 'decorate()' function is probably actually not
> > that useful, compared to making specialized decoration functions like,
> > say:
> >
> >     classmethod_follows()
> >     def foo(klass, x, y, z):
> >         # ...
>
>Ick!

Is it the name you dislike?  Or the idea of simply invoking decorating 
functions directly?



> > Only with better names.  :)  Also, using this approach means you can
> > do something like:
> >
> >      [classmethod_follows()]
>
>Ick in brackets ;-> !



From fdrake at acm.org  Fri Jun 25 16:18:38 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri Jun 25 16:18:59 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
Message-ID: <200406251618.38924.fdrake@acm.org>

On Friday 25 June 2004 04:09 pm, Phillip J. Eby wrote:
 > * Whether to have a 'decorate' function at all, or whether it's better to
 > just list specialized decorator objects/functions (I generally favor the
 > latter, since 'decorate' is IMO a dead chicken that hasn't appeared in any
 > widely-supported syntax proposals to date).

Ooohh... time for some fun!  Some proposals have included "as".  Since "as" 
isn't really a keyword, how about:

    from decorate import decorate as as

    as(classmethod)
    def myAlternateConstructor(...):
        # make something interesting:
        return 42

Too bad this is ugly for the simple attribute decorator:

    as(spam="fidget")
    def foo(...):
        send_fred_more_spam_please()


  -Fred

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


From zorander at gmail.com  Fri Jun 25 16:52:14 2004
From: zorander at gmail.com (Brian L.)
Date: Fri Jun 25 16:52:20 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <200406251618.38924.fdrake@acm.org>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
Message-ID: <6ee4c83804062513526ea4c4ac@mail.gmail.com>

As I see it, any decorator that appears on lines previous to a
function impairs code readability by making the function harder to
find. When editing code with the standard 4-space tab, the function
name is very conveniently lined up with the code below it, and in most
code I've seen, there's a blank line above it, like this:

def something(foo): 
    do_something()

def somethingelse(bar):
    do_something_else()

Now say we were to add decorators to this. Then visually, to find the
function, you'd be searching through a non-predetermined set of
decorators first, as opposed to searching for a solid piece of
whitespace then scrolling your eyes one line down, a fixed position
from the left edge of the editor. The function name would be embedded
in noise, making the code more confusing to edit.

This particular issue can be remedied in two ways. First off, a list
of decorators with brackets, as Phillip's solution makes possible, but
with some limitation to prevent multiple lines of them (or at least a
prescribed coding convention prohibiting it without true enforcement).
It would still take away from readability a little bit, but not in
such a bad way. The brackets actually set off the decorators nicely.
Something like:

[decorators]
def func(args):
    pass

The other solution I see is something like what Bill said which is:

def func (args) as [decorators]:

The idea of bracketing them as a list is, I think, a very good one,
and it would of course still have to be determined whether decorators
are functions, whether they should be called, etc. I kind of like the
idea of them being functions that are called on the function, and if
they need additional arguments, make them higher order functions such
that the decorator list element is called with func as its argument.

Just my 2c,

Brian


On Fri, 25 Jun 2004 16:18:38 -0400, Fred L. Drake, Jr. <fdrake@acm.org> wrote:
> 
> On Friday 25 June 2004 04:09 pm, Phillip J. Eby wrote:
>  > * Whether to have a 'decorate' function at all, or whether it's better to
>  > just list specialized decorator objects/functions (I generally favor the
>  > latter, since 'decorate' is IMO a dead chicken that hasn't appeared in any
>  > widely-supported syntax proposals to date).
> 
> Ooohh... time for some fun!  Some proposals have included "as".  Since "as"
> isn't really a keyword, how about:
> 
>     from decorate import decorate as as
> 
>     as(classmethod)
>     def myAlternateConstructor(...):
>         # make something interesting:
>         return 42
> 
> Too bad this is ugly for the simple attribute decorator:
> 
>     as(spam="fidget")
>     def foo(...):
>         send_fred_more_spam_please()
> 
>   -Fred
> 
> --
> Fred L. Drake, Jr.  <fdrake at acm.org>
> PythonLabs at Zope Corporation
> 
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/zorander%40gmail.com
> 


-- 
The years ahead pick up their dark bags.
They move closer. There's a slight rise in the silence

then nothing.

From ehuss at ironport.com  Fri Jun 25 17:37:16 2004
From: ehuss at ironport.com (Eric Huss)
Date: Fri Jun 25 17:25:34 2004
Subject: [Python-Dev] Possible memory leak in typeobject.c?
Message-ID: <Pine.BSF.4.58.0406251429540.40205@wintermute.sponsor.net>

While tearing my hair out trying to figure out why my dynamically
allocated type objects weren't getting garbage collected, I noticed that
the tp_new_wrapper object had 1 too many ref counts.

Does the following patch make sense?  Seems fairly straightforward to me.

-Eric
-------------- next part --------------
*** typeobject.c	28 May 2004 18:36:03 -0000	1.3
--- typeobject.c	25 Jun 2004 21:23:15 -0000
***************
*** 3923,3929 ****
  	func = PyCFunction_New(tp_new_methoddef, (PyObject *)type);
  	if (func == NULL)
  		return -1;
! 	return PyDict_SetItemString(type->tp_dict, "__new__", func);
  }
  
  /* Slot wrappers that call the corresponding __foo__ slot.  See comments
--- 3923,3934 ----
  	func = PyCFunction_New(tp_new_methoddef, (PyObject *)type);
  	if (func == NULL)
  		return -1;
! 	if(PyDict_SetItemString(type->tp_dict, "__new__", func)) {
! 		Py_DECREF(func);
! 		return -1;
! 	}
! 	Py_DECREF(func);
! 	return 0;
  }
  
  /* Slot wrappers that call the corresponding __foo__ slot.  See comments
From Jack.Jansen at cwi.nl  Fri Jun 25 18:07:10 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Fri Jun 25 18:07:14 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <40DA637A.2020501@v.loewis.de>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
	<734AA269-C23E-11D8-88DB-000D934FF6B4@cwi.nl>
	<40DA637A.2020501@v.loewis.de>
Message-ID: <018CFA78-C6F4-11D8-AF02-000D934FF6B4@cwi.nl>


On 24 Jun 2004, at 07:15, Martin v. L?wis wrote:

> Jack Jansen wrote:
>>> That's indeed my understanding of The Plan today.  More, we will not 
>>> have a
>>> VC6 binary for Python 2.4.  That may be controversial, but nobody has
>>> volunteered to produce an installer for a VC6 version.
>> Does this mean that the final answer to the question of whether VC7 
>> was GPL-compatible was "yes"?
>
> I don't recall that the question has been asked before - let alone
> recalling an answer to it.
>
> If you were wondering about the question "is it possible to build
> extension modules for a VC7 compiled Python without having to buy
> VC7", then this question would have nothing to do with legal issues,
> but much more with technical ones.

The question I mean is that the GPL says "You shall not link against 
commercial libraries, unless they are part of the base OS". The second 
part of that sentence could be considered true for the VC6 version of 
MSVCRT, but not for the VC7 one. Actually, Microsoft strongly suggest 
you ship msvcr71.dll (or whatever the name) with the application, and 
not put it into /System. That appears to me to be a definite no-no for 
GPL software.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman


From python at rcn.com  Fri Jun 25 06:21:20 2004
From: python at rcn.com (Raymond Hettinger)
Date: Fri Jun 25 18:22:05 2004
Subject: [Python-Dev] Possible memory leak in typeobject.c?
In-Reply-To: <Pine.BSF.4.58.0406251429540.40205@wintermute.sponsor.net>
Message-ID: <001201c45a9e$28e75b80$8f1ecb97@oemcomputer>

[Eric Huss]
> While tearing my hair out trying to figure out why my dynamically
> allocated type objects weren't getting garbage collected, I noticed
that
> the tp_new_wrapper object had 1 too many ref counts.
> 
> Does the following patch make sense?  

Yes, it does.
Applied and backported.
Thanks for the patch.
Next time, please use SourceForge.


Raymond Hettinger


From pje at telecommunity.com  Fri Jun 25 18:24:52 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri Jun 25 18:22:17 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <6ee4c83804062513526ea4c4ac@mail.gmail.com>
References: <200406251618.38924.fdrake@acm.org>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
Message-ID: <5.1.1.6.0.20040625181159.025426a0@mail.telecommunity.com>

At 04:52 PM 6/25/04 -0400, Brian L. wrote:
>This particular issue can be remedied in two ways. First off, a list
>of decorators with brackets, as Phillip's solution makes possible,

I think David Abrahams should be the one to get the credit: it was his idea 
to use the tracing machinery, while I just implemented a rough 
proof-of-concept.  I could have implemented it a year ago, had I thought of 
it before now.  So, that makes it *his* solution as far as I'm concerned, 
and thus you can blame him for any resulting consequences.  <wink>

(Similarly, the concept of using _getframe() magic and __metaclass__ 
munging to implement class decorators was originally proposed by Jim Fulton 
and Steve Alexander; I just developed a robust, co-operative, and 
general-purpose implementation of the concept for Zope and PyProtocols.)


From dave at boost-consulting.com  Fri Jun 25 18:21:43 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri Jun 25 18:22:24 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <5.1.1.6.0.20040625161132.0287d2d0@mail.telecommunity.com>
	(Phillip J. Eby's message of "Fri, 25 Jun 2004 16:16:46 -0400")
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<40D84CEE.6040307@interlink.com.au>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625161132.0287d2d0@mail.telecommunity.com>
Message-ID: <ud63ns2h4.fsf@boost-consulting.com>

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

> At 08:26 AM 6/25/04 -0400, David Abrahams wrote:
>>"Phillip J. Eby" <pje@telecommunity.com> writes:
>> > You'd need to do something like keep a copy of the locals and on
>> > each "new line" event from the trace hook, you'd need to both call
>> > the old trace hook (so that debugging could still take place) and
>> > check to see if the locals had a new function object.  As soon as
>> > the function object appeared, you could do your dirty work (after
>> > first restoring the *old* value bound to that name, so the
>> > decorators would have access to the previous binding of the name).
>>
>>I'm perfectly happy for this decorate function to work on the very
>>next name binding; I don't think it's reasonable to expect to be able
>>to do anything else between it and the function definition.
>
> Keep in mind that this means code like this:
>
> decorate(foo)
> decorate(bar(baz=[x*2 for x in y]))
> def spam():
>      pass
>
> Will likely fail horribly, applying the 'foo' decorator to the first
> element of 'y' before trying to multiply by 2, or worse, possibly

"doctor, it hurts when I do this..."

> applying them to the "anonymous" list object that's created to hold
> the results of the list comprehension.  Or, it might sometimes *seem*
> to work due to hashing order and the vagaries of when 'line' events
> fire, and then fail in a new release of Python.  This is why I
> consider it somewhat of a wart in the current implementation, as I
> note below...

That's why decorate should take a variable number of arguments:

decorate(foo, bar(baz=[x*2 for x in y]))
def spam():
     pass

>> > Anyway, it works with CPython 2.2.  Caveat: do *not* use listcomps or
>> > any other assignment statements between your 'decorate()' invocation
>> > and the function definition, or the decorators will be applied to the
>> > bound-to variable!
>> >
>> > Personally, I think the 'decorate()' function is probably actually not
>> > that useful, compared to making specialized decoration functions like,
>> > say:
>> >
>> >     classmethod_follows()
>> >     def foo(klass, x, y, z):
>> >         # ...
>>
>>Ick!
>
> Is it the name you dislike?  Or the idea of simply invoking decorating
> functions directly?

What I want is a recognizable syntax that indicates decoration.  If
it's likely to be any old function name, decorators are much less
likely to jump out at you.  In fact, that's why I really like
operator syntaxes like:

  with[foo, bar(baz=[x*2 for x in y])]
  def spam():
       pass

or something.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From Jack.Jansen at cwi.nl  Fri Jun 25 18:25:40 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Fri Jun 25 18:25:44 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <200406251618.38924.fdrake@acm.org>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
Message-ID: <9702AF10-C6F6-11D8-AF02-000D934FF6B4@cwi.nl>

We've now had so many suggestions for decorators that I don't remember 
whether the following one was suggested already (and shot down, causing 
the ill-informed maker of the suggestion to go hide under a stone for 
weeks:-), so here goes:
def:
	objc_signature('i@:if')
as methodWithInt_andFloat_(self, intarg, floatarg):
	return intarg + int(floatarg)

The use of "as" here is gratuitous, because everyone seems to use that 
as the only semi-keyword in existence.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman


From jbone at place.org  Fri Jun 25 18:53:37 2004
From: jbone at place.org (Contempt for Meatheads)
Date: Fri Jun 25 18:53:47 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <6ee4c83804062513526ea4c4ac@mail.gmail.com>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
	<6ee4c83804062513526ea4c4ac@mail.gmail.com>
Message-ID: <7E7402A8-C6FA-11D8-A9D8-000A95CFE9DE@place.org>


On Jun 25, 2004, at 3:52 PM, Brian L. wrote:

> such a bad way. The brackets actually set off the decorators nicely.
> Something like:
>
> [decorators]
> def func(args):
>     pass
>

+1

IMHO, making decorators functions is a bad idea.  Decorators are 
metadata about the function to which they refer.  Using the same syntax 
for decorators as for functions conceptually weakens this distinction 
and encourages misuse of decorators, even to the point of potentially 
encouraging (or implying) side-effects as a result of decoration.

IMHO,

jb


From fperez528 at yahoo.com  Fri Jun 25 02:58:21 2004
From: fperez528 at yahoo.com (Fernando Perez)
Date: Fri Jun 25 19:00:27 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <40D84CEE.6040307@interlink.com.au>
Message-ID: <cbgiff$pht$1@sea.gmane.org>

Anthony Baxter wrote:

> So here's the state of play with decorators and 2.4.

[snip]

> Channelling Guido, via his EP keynote
> (http://www.python.org/doc/essays/ppt/euro2004/euro2004.ppt)
> I'm assuming that "Java-style" is something like:
> 
> @staticmethod
> def blah(args):
>      body
> 
> @funcattrs(vegetable="blah", author="GvR")
> def blah2(args):
>      body

I'd like to cast a -1 vote in the form of a small plea.  It turns out that
IPython (http://ipython.scipy.org) uses @ as a special character to identify
'magic' commands which control the shell itself.  If this became valid syntax,
IPython would require not only internal rewrites but also a fair amount of
users would have to change their working habits.

I'm fully aware that the core python development won't be held back by
third-party tools which use non-standard syntax. But at least I'd like to cast
a voice, in case the argument is in the end narrowly decided between this and
other alternatives.

IPython has become a fairly popular tool, judging by a quick google search, and
the fact that it's distributed in SUSE 9.1, as well as being available for
Debian, OSX (via Fink), Gentoo and other smaller Linux distributions.  There
are also several projects (mainly in scientific computing) which use it as
their interactive environments (I designed it deliberately trying to make this
kind of use very easy). IPython is also available for Windows, and using Gary
Bishop's readline library it provides full ANSI coloring and readline editing
support.  With current (and coming) CVS, it will grow an extension (pysh) for
use as a system-shell with python syntax, a long-requested feature from many
users.

I completely understand that I can't pressure any of this decision, since I
chose an unused but by no means 'reserved' character.  But at least I'd like to
let the core team know about this particular side-effect, which will impact a
fair amount of users out there.

Regards to all,

Fernando.


From tim.peters at gmail.com  Fri Jun 25 19:03:56 2004
From: tim.peters at gmail.com (Tim Peters)
Date: Fri Jun 25 19:04:02 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <018CFA78-C6F4-11D8-AF02-000D934FF6B4@cwi.nl>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
	<734AA269-C23E-11D8-88DB-000D934FF6B4@cwi.nl>
	<40DA637A.2020501@v.loewis.de>
	<018CFA78-C6F4-11D8-AF02-000D934FF6B4@cwi.nl>
Message-ID: <1f7befae040625160329626112@mail.gmail.com>

[Jack Jansen]
> The question I mean is that the GPL says "You shall not link against
> commercial libraries, unless they are part of the base OS".
> The second part of that sentence could be considered true for the VC6 version
> of MSVCRT, but not for the VC7 one. Actually, Microsoft strongly suggest
> you ship msvcr71.dll (or whatever the name) with the application, and
> not put it into /System. That appears to me to be a definite no-no for
> GPL software.

Python isn't released under the GPL, so what specifically are you
asking about?  Whether an author of a Python 2.4 derivative work
targeting Windows can put their work under the GPL?  I expect that's
more a question of the conditions under which Microsoft licenses
msvcr71.dll.  They've had some goofy language in the past purporting
to prevent redistribution of MS redistributables in packages under
"viral" licenses.  Maybe they still do.

I expect that by "You shall not link ..." (which doesn't appear in the
GPL), you have in mind the confusing requirements of GPL Version 2
Section 3.  That exempts copiers and distributors from including full
source code for "major components ... of the operating system on which
the executable runs", *except* "unless that component itself
accompanies the executable".  Python installers have always included
the MS C runtime DLLs, so there was no relief in the GPL for VC6.

I suggest asking the FSF directly what they believe.  Regardless of
internal consistency, I expect they'll develop a rationale for saying
"sure, fine".  The questions really have nothing to do with Python.

From pje at telecommunity.com  Fri Jun 25 19:20:08 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri Jun 25 19:17:24 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <7E7402A8-C6FA-11D8-A9D8-000A95CFE9DE@place.org>
References: <6ee4c83804062513526ea4c4ac@mail.gmail.com>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
	<6ee4c83804062513526ea4c4ac@mail.gmail.com>
Message-ID: <5.1.1.6.0.20040625191156.030d37d0@mail.telecommunity.com>

At 05:53 PM 6/25/04 -0500, Contempt for Meatheads wrote:
>IMHO, making decorators functions is a bad idea.  Decorators are metadata 
>about the function to which they refer.  Using the same syntax for 
>decorators as for functions conceptually weakens this distinction and 
>encourages misuse of decorators, even to the point of potentially 
>encouraging (or implying) side-effects as a result of decoration.

Side-effects are desired by various current users of decorators, so whether 
this will "encourage" them is moot.  Further, those uses often suggest that 
"metadata" is far too narrow of a word to encompass the desired uses of 
decorators.

Last, keep in mind that there is nothing stopping people today from doing 
whatever they want with functions *anyway*, in every version of Python I've 
ever used (back to 1.4):

    def foo(...):
        ...

    do_something_with(foo)

So, again, the idea that this somehow becomes a bad thing when it goes at 
the top of the function definition  -- where it should be more visible to 
the reader that it's taking place -- seems a bit odd to me.


From dave at boost-consulting.com  Fri Jun 25 20:41:54 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri Jun 25 20:42:26 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
Message-ID: <u659fqhf1.fsf@boost-consulting.com>

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

> On Friday 25 June 2004 04:09 pm, Phillip J. Eby wrote:
>  > * Whether to have a 'decorate' function at all, or whether it's better to
>  > just list specialized decorator objects/functions (I generally favor the
>  > latter, since 'decorate' is IMO a dead chicken that hasn't appeared in any
>  > widely-supported syntax proposals to date).
>
> Ooohh... time for some fun!  Some proposals have included "as".  Since "as" 
> isn't really a keyword, how about:
>
>     from decorate import decorate as as
>
>     as(classmethod)
>     def myAlternateConstructor(...):
>         # make something interesting:
>         return 42
>
> Too bad this is ugly for the simple attribute decorator:
>
>     as(spam="fidget")
>     def foo(...):
>         send_fred_more_spam_please()
>

I don't find it so ugly... but then there's always "with" ;-)

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From dave at boost-consulting.com  Fri Jun 25 20:43:27 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri Jun 25 20:51:33 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<40D84CEE.6040307@interlink.com.au>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<20040625100125.GA15576@vicky.ecs.soton.ac.uk>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
Message-ID: <uzn6rp2s0.fsf@boost-consulting.com>

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

>    +classmethod
>    +attrs(spam="fidget")
>    def foo(...):
>        ...
>
>    [classmethod(), attrs(spam="fidget")]
>    def foo(...):
>        ...
>
>    ~classmethod
>    ~attrs(spam="fidget")
>    def foo(...):
>        ...
>
>    -classmethod
>    -attrs(spam="fidget")
>    def foo(...):
>        ...
>
>    All of these are possible, and each likely to have *some*
>    proponents.  Oh, and let's not forget the question of application
>    order of the decorations.  :)  I personally favor a(b(c(...)))
>    ordering for decorations that are listed before the 'def', even
>    though I favor a(), b(), c() ordering for decorations that come
>    after.

I don't think any of these syntaxes allow classmethod to remain what
it is, a "regular" function... not that I consider it a prerequisite
or anything.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From ehuss at ironport.com  Fri Jun 25 21:38:25 2004
From: ehuss at ironport.com (Eric Huss)
Date: Fri Jun 25 21:26:40 2004
Subject: [Python-Dev] Heap allocated type objects from C
Message-ID: <Pine.BSF.4.58.0406251829290.40205@wintermute.sponsor.net>

I've been messing around with dynamically generating type objects from C.
In particular, I made a module to generate structseq type objects.
See sourceforge bug 624827 and patch 980098.

I ran into a fair amount of difficulty in doing this.  There doesn't
appear to be a direct C API for doing this.  One possible method is
calling PyType_Type.tp_new() and then updating the returned type object as
needed, but that seemed a little dirty.

First, could someone tell me if I took the correct route for creating a
type object on the heap (based on my patch).

Second, shouldn't there be a more direct API for doing this?  Perhaps a
more generalized interface to type_new(), or maybe something completely
new??

-Eric

From jbone at deepfile.com  Fri Jun 25 17:51:46 2004
From: jbone at deepfile.com (Jeff Bone)
Date: Sat Jun 26 00:16:57 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <6ee4c83804062513526ea4c4ac@mail.gmail.com>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
	<6ee4c83804062513526ea4c4ac@mail.gmail.com>
Message-ID: <DA7203C0-C6F1-11D8-A9D8-000A95CFE9DE@deepfile.com>


On Jun 25, 2004, at 3:52 PM, Brian L. wrote:

> such a bad way. The brackets actually set off the decorators nicely.
> Something like:
>
> [decorators]
> def func(args):
>     pass
>

+1

IMHO, making decorators functions is a bad idea.  Decorators are 
metadata about the function to which they refer.  Using the same syntax 
for decorators as for functions conceptually weakens this distinction 
and encourages misuse of decorators, even to the point of potentially 
encouraging (or implying) side-effects as a result of decoration.

IMHO,

jb


From janssen at parc.com  Sat Jun 26 00:33:43 2004
From: janssen at parc.com (Bill Janssen)
Date: Sat Jun 26 00:34:06 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings 
In-Reply-To: Your message of "Thu, 24 Jun 2004 15:21:08 PDT."
	<40DB53D4.50905@v.loewis.de> 
Message-ID: <04Jun25.213349pdt."58612"@synergy1.parc.xerox.com>

While we're talking about this, Martin, what is the encoding of the
"string" returned by

      struct.pack("bbb", 0xFF, 0x00, 0x83)

And what should it be?

Bill

From janssen at parc.com  Sat Jun 26 00:40:21 2004
From: janssen at parc.com (Bill Janssen)
Date: Sat Jun 26 00:40:44 2004
Subject: [Python-Dev] Re: decorators and 2.4 
In-Reply-To: Your message of "Fri, 25 Jun 2004 08:40:15 PDT."
	<40DC475F.4070202@prescod.net> 
Message-ID: <04Jun25.214024pdt."58612"@synergy1.parc.xerox.com>

Paul Prescod writes:
> The left edge is already cluttered.
> 
> a = 5
> b = a()
> def foo(xyz):
>      abc = 5
> c = 20
> 
> It is the indentation that alerts your eye to the function definition.

Paul, most modules have global variables defined only in one place,
usually well-marked, so you don't usually get the clutter that you
cite here.  Scripts, of course, are an exception.

> Nobody reads code one line at a time from the top down. You scan for the 
> bit that interests you and then look around for its context.

It's of course the scanning that I'm talking about.  Having only "def"
and "class" at the left edge makes it remarkably easy to scan for a
function or class definition.  Putting oddly-shaped decorators there
too ruins this.

But I disagree with your statement here.  Everyone reads *unfamiliar*
code one line at a time from the top.  If you're really reading it, I
mean, rather than just looking for something in it.

Bill

From janssen at parc.com  Sat Jun 26 00:47:45 2004
From: janssen at parc.com (Bill Janssen)
Date: Sat Jun 26 00:48:08 2004
Subject: [Python-Dev] Re: decorators and 2.4 
In-Reply-To: Your message of "Fri, 25 Jun 2004 13:52:14 PDT."
	<6ee4c83804062513526ea4c4ac@mail.gmail.com> 
Message-ID: <04Jun25.214749pdt."58612"@synergy1.parc.xerox.com>

I could also see the function call version:

  from decorators import decorate
  ...
  def foo (bar):
      decorate(bletch, flappy)
      ...

where decorate is automatically applied to "foo".

Bill

From tim.peters at gmail.com  Sat Jun 26 01:02:37 2004
From: tim.peters at gmail.com (Tim Peters)
Date: Sat Jun 26 01:02:42 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <494493537191594366@unknownmsgid>
References: <494493537191594366@unknownmsgid>
Message-ID: <1f7befae0406252202d8358f1@mail.gmail.com>

[Bill Janssen]
> While we're talking about this, Martin, what is the encoding of the
> "string" returned by
>
>      struct.pack("bbb", 0xFF, 0x00, 0x83)

That raises an exception.  Did you intend "BBB" as the format string?

> And what should it be?

Whatever you explicitly say it is, when you feed the string to a
context that requires knowing the intended encoding.  It has no
intrinsic encoding -- encoding is in your head (or your app's
requirements), not in the string itself.  It's like asking which
numeric base the sequence of digits

   1111

is written in.  You can't tell by staring it at.  Maybe that was
decimal, maybe it was binary.  But no -- I actually had base 2004 in
mind <wink>.

Here are two distinct possibilities for your specific string:

>>> s = struct.pack("BBB", 0xFF, 0x00, 0x83)
>>> unicode(s, 'latin1')
u'\xff\x00\x83'
>>> unicode(s, 'cp1252')
u'\xff\x00\u0192'
>>>

Python can't guess the intent.  Neither could a highly knowledgeable
but non-telepathic human, for that matter.

From pje at telecommunity.com  Sat Jun 26 01:23:54 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat Jun 26 01:21:10 2004
Subject: [Python-Dev] Re: decorators and 2.4 
In-Reply-To: <04Jun25.214749pdt."58612"@synergy1.parc.xerox.com>
References: <Your message of "Fri, 25 Jun 2004 13:52:14 PDT."
	<6ee4c83804062513526ea4c4ac@mail.gmail.com>
Message-ID: <5.1.1.6.0.20040626012303.0287ce40@mail.telecommunity.com>

At 09:47 PM 6/25/04 -0700, Bill Janssen wrote:
>I could also see the function call version:
>
>   from decorators import decorate
>   ...
>   def foo (bar):
>       decorate(bletch, flappy)
>       ...
>
>where decorate is automatically applied to "foo".

That won't work, since by the time the function is called it's too late to 
redefine foo.


From bob at redivi.com  Sat Jun 26 03:15:59 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Jun 26 03:16:18 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <DA7203C0-C6F1-11D8-A9D8-000A95CFE9DE@deepfile.com>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
	<6ee4c83804062513526ea4c4ac@mail.gmail.com>
	<DA7203C0-C6F1-11D8-A9D8-000A95CFE9DE@deepfile.com>
Message-ID: <ACE2D138-C740-11D8-B553-000A95686CD8@redivi.com>


On Jun 25, 2004, at 5:51 PM, Jeff Bone wrote:

>
> On Jun 25, 2004, at 3:52 PM, Brian L. wrote:
>
>> such a bad way. The brackets actually set off the decorators nicely.
>> Something like:
>>
>> [decorators]
>> def func(args):
>>     pass
>>
>
> +1
>
> IMHO, making decorators functions is a bad idea.  Decorators are 
> metadata about the function to which they refer.  Using the same 
> syntax for decorators as for functions conceptually weakens this 
> distinction and encourages misuse of decorators, even to the point of 
> potentially encouraging (or implying) side-effects as a result of 
> decoration.

Uh, the WHOLE POINT we want this is to have side-effects.  If it 
doesn't make the function act in a different way, it might as well live 
in the doc string or something.

The most wanted use cases are all function transformations, not the 
setting attributes on function objects.

-bob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040626/c5dd3bb1/smime.bin
From martin at v.loewis.de  Sat Jun 26 05:59:21 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat Jun 26 05:59:27 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <018CFA78-C6F4-11D8-AF02-000D934FF6B4@cwi.nl>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
	<734AA269-C23E-11D8-88DB-000D934FF6B4@cwi.nl>
	<40DA637A.2020501@v.loewis.de>
	<018CFA78-C6F4-11D8-AF02-000D934FF6B4@cwi.nl>
Message-ID: <40DD48F9.3010304@v.loewis.de>

Jack Jansen wrote:
> The question I mean is that the GPL says "You shall not link against 
> commercial libraries, unless they are part of the base OS". The second 
> part of that sentence could be considered true for the VC6 version of 
> MSVCRT, but not for the VC7 one. Actually, Microsoft strongly suggest 
> you ship msvcr71.dll (or whatever the name) with the application, and 
> not put it into /System. That appears to me to be a definite no-no for 
> GPL software.

Ah. I don't think this has been discussed before. We will definitely
include msvcr71.dll with Python, and I don't see a violation of the
GPL by doing so (as Python is not released under the terms of the GPL).

Regards,
Martin


From martin at v.loewis.de  Sat Jun 26 06:04:20 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat Jun 26 06:04:46 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <04Jun25.213349pdt."58612"@synergy1.parc.xerox.com>
References: <04Jun25.213349pdt."58612"@synergy1.parc.xerox.com>
Message-ID: <40DD4A24.5000107@v.loewis.de>

Bill Janssen wrote:
> While we're talking about this, Martin, what is the encoding of the
> "string" returned by
> 
>       struct.pack("bbb", 0xFF, 0x00, 0x83)
> 
> And what should it be?

It's a byte string, so it doesn't have an encoding. It's MIME
type might be 'application/octet-stream'.

Regards,
Martin


From phil at riverbankcomputing.co.uk  Sat Jun 26 06:11:13 2004
From: phil at riverbankcomputing.co.uk (Phil Thompson)
Date: Sat Jun 26 06:11:29 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <40DD48F9.3010304@v.loewis.de>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
	<018CFA78-C6F4-11D8-AF02-000D934FF6B4@cwi.nl>
	<40DD48F9.3010304@v.loewis.de>
Message-ID: <200406261111.13489.phil@riverbankcomputing.co.uk>

On Saturday 26 June 2004 10:59 am, "Martin v. L?wis" wrote:
> Jack Jansen wrote:
> > The question I mean is that the GPL says "You shall not link against
> > commercial libraries, unless they are part of the base OS". The second
> > part of that sentence could be considered true for the VC6 version of
> > MSVCRT, but not for the VC7 one. Actually, Microsoft strongly suggest
> > you ship msvcr71.dll (or whatever the name) with the application, and
> > not put it into /System. That appears to me to be a definite no-no for
> > GPL software.
>
> Ah. I don't think this has been discussed before. We will definitely
> include msvcr71.dll with Python, and I don't see a violation of the
> GPL by doing so (as Python is not released under the terms of the GPL).

The potential problem would be for GPL extension modules. They could be used 
with Python VC6, but not with Python VC7. Are there are any GPLed modules 
used on Windows?

Phil

From martin at v.loewis.de  Sat Jun 26 06:33:41 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat Jun 26 06:33:46 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406261111.13489.phil@riverbankcomputing.co.uk>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
	<018CFA78-C6F4-11D8-AF02-000D934FF6B4@cwi.nl>
	<40DD48F9.3010304@v.loewis.de>
	<200406261111.13489.phil@riverbankcomputing.co.uk>
Message-ID: <40DD5105.8090402@v.loewis.de>

Phil Thompson wrote:
> The potential problem would be for GPL extension modules. They could be used 
> with Python VC6, but not with Python VC7.

Why is that?

Regards,
Martin


From martin at v.loewis.de  Sat Jun 26 06:52:32 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat Jun 26 06:52:38 2004
Subject: [Python-Dev] Heap allocated type objects from C
In-Reply-To: <Pine.BSF.4.58.0406251829290.40205@wintermute.sponsor.net>
References: <Pine.BSF.4.58.0406251829290.40205@wintermute.sponsor.net>
Message-ID: <40DD5570.9000601@v.loewis.de>

Eric Huss wrote:
> First, could someone tell me if I took the correct route for creating a
> type object on the heap (based on my patch).
> 
> Second, shouldn't there be a more direct API for doing this?  Perhaps a
> more generalized interface to type_new(), or maybe something completely
> new??

I don't understand why the patch needs to be so complicated. Why can't
you just make a global function that returns new type objects which
are struct seqs? IOW, why do you need the factory type? Type objects
are callable themselves, so they act as factories.

Regards,
Martin


From martin at v.loewis.de  Sat Jun 26 07:02:25 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat Jun 26 07:03:32 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <1088161847.30612.40.camel@slothrop.corp.google.com>
References: <40D67098.7080907@v.loewis.de>	<1088090139.30612.24.camel@slothrop.corp.google.com>	<E8C8327B-C688-11D8-8348-000A95EFAE9E@yahoo.com>
	<1088161847.30612.40.camel@slothrop.corp.google.com>
Message-ID: <40DD57C1.1030905@v.loewis.de>

Jeremy Hylton wrote:
> The definition of what it means for an exception to be "active" in a
> scope needs to be clarified.  The language reference doesn't appear to
> define what that means, so I took a narrow reading.  I think the code
> you mention later in your post is code I wrote :-).

It seems that Guido has attempted to clarify it as "an exception is 
active until the next exception is raised, or the program terminates".

However, that clarification doesn't describe the current implementation,
atleast not for interactive mode:

 >>> try:
...   1/0
... except:
...   pass
...
 >>> raise
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: exceptions must be classes, instances, or strings 
(deprecated), not NoneType

Here, the re-raise doesn't find an exception anymore, even
though non has been raised...

I would prefer if it were clarified as "An exception is active
until the exception handler completes. When control runs off
the end of the exception handler, or it completes through a
return, break, or continue, no exception is active. When a new
exception is raised (or the currently active one is re-raised),
that exception becomes active."

Regards,
Martin


From phil at riverbankcomputing.co.uk  Sat Jun 26 07:23:09 2004
From: phil at riverbankcomputing.co.uk (Phil Thompson)
Date: Sat Jun 26 07:23:23 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <40DD5105.8090402@v.loewis.de>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
	<200406261111.13489.phil@riverbankcomputing.co.uk>
	<40DD5105.8090402@v.loewis.de>
Message-ID: <200406261223.09529.phil@riverbankcomputing.co.uk>

On Saturday 26 June 2004 11:33 am, "Martin v. L?wis" wrote:
> Phil Thompson wrote:
> > The potential problem would be for GPL extension modules. They could be
> > used with Python VC6, but not with Python VC7.
>
> Why is that?

Because of Jack's original point. GPL code cannot be linked against 
proprietary libraries unless they are part of the base system. Python itself 
is Ok because it's not GPL.

Phil

From martin at v.loewis.de  Sat Jun 26 07:37:42 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat Jun 26 07:37:48 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406261223.09529.phil@riverbankcomputing.co.uk>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
	<200406261111.13489.phil@riverbankcomputing.co.uk>
	<40DD5105.8090402@v.loewis.de>
	<200406261223.09529.phil@riverbankcomputing.co.uk>
Message-ID: <40DD6006.7070905@v.loewis.de>

Phil Thompson wrote:
> Because of Jack's original point. GPL code cannot be linked against 
> proprietary libraries unless they are part of the base system. Python itself 
> is Ok because it's not GPL.

As Tim says, if you want to know for sure, ask the FSF for
clarification.

It is not true that GPL code cannot be linked against proprietary
libraries. If you have the code, you can link it against whatever
you want. The GPL does not restrict your right to link the application
against libraries.

The GPL only talks about distribution of things. If you include
MSVCR71.DLL in your binary Python module, you would need to provide
source code to MSVCR71.DLL as well. The solution is very simple:
just don't ship MSVCR71.DLL with the binary Python module. It will
work on the target system because Python has already installed
that DLL.

Regards,
Martin


From phil at riverbankcomputing.co.uk  Sat Jun 26 07:58:39 2004
From: phil at riverbankcomputing.co.uk (Phil Thompson)
Date: Sat Jun 26 07:58:57 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <40DD6006.7070905@v.loewis.de>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
	<200406261223.09529.phil@riverbankcomputing.co.uk>
	<40DD6006.7070905@v.loewis.de>
Message-ID: <200406261258.39791.phil@riverbankcomputing.co.uk>

On Saturday 26 June 2004 12:37 pm, "Martin v. L?wis" wrote:
> Phil Thompson wrote:
> > Because of Jack's original point. GPL code cannot be linked against
> > proprietary libraries unless they are part of the base system. Python
> > itself is Ok because it's not GPL.
>
> As Tim says, if you want to know for sure, ask the FSF for
> clarification.
>
> It is not true that GPL code cannot be linked against proprietary
> libraries. If you have the code, you can link it against whatever
> you want. The GPL does not restrict your right to link the application
> against libraries.
>
> The GPL only talks about distribution of things. If you include
> MSVCR71.DLL in your binary Python module, you would need to provide
> source code to MSVCR71.DLL as well. The solution is very simple:
> just don't ship MSVCR71.DLL with the binary Python module. It will
> work on the target system because Python has already installed
> that DLL.

Actually, it's simpler than that. From the GPL FAQ:

"I'm writing a Windows application with Microsoft Visual C++ (or Visual Basic) 
and I will be releasing it under the GPL.  Is dynamically linking my program 
with the Visual C++ (or Visual Basic) run-time library permitted under the 
GPL?

Yes, because that run-time library normally accompanies the compiler
or interpreter you are using."

My (incorrect) understanding was that "operating system" was meant rather than 
"compiler or interpreter".

Phil

From pje at telecommunity.com  Sat Jun 26 08:11:51 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat Jun 26 08:09:12 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <40DD57C1.1030905@v.loewis.de>
References: <1088161847.30612.40.camel@slothrop.corp.google.com>
	<40D67098.7080907@v.loewis.de>
	<1088090139.30612.24.camel@slothrop.corp.google.com>
	<E8C8327B-C688-11D8-8348-000A95EFAE9E@yahoo.com>
	<1088161847.30612.40.camel@slothrop.corp.google.com>
Message-ID: <5.1.1.6.0.20040626080929.01ebb4a0@mail.telecommunity.com>

At 01:02 PM 6/26/04 +0200, Martin v. L?wis wrote:
>It seems that Guido has attempted to clarify it as "an exception is active 
>until the next exception is raised, or the program terminates".
>
>However, that clarification doesn't describe the current implementation,
>atleast not for interactive mode:
>
> >>> try:
>..   1/0
>.. except:
>..   pass
>..
> >>> raise
>Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>TypeError: exceptions must be classes, instances, or strings (deprecated), 
>not NoneType
>
>Here, the re-raise doesn't find an exception anymore, even
>though non has been raised...

Isn't each statement/block in the interactive interpreter run in a new frame?


From martin at v.loewis.de  Sat Jun 26 08:20:15 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat Jun 26 08:21:23 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <5.1.1.6.0.20040626080929.01ebb4a0@mail.telecommunity.com>
References: <1088161847.30612.40.camel@slothrop.corp.google.com>
	<40D67098.7080907@v.loewis.de>
	<1088090139.30612.24.camel@slothrop.corp.google.com>
	<E8C8327B-C688-11D8-8348-000A95EFAE9E@yahoo.com>
	<1088161847.30612.40.camel@slothrop.corp.google.com>
	<5.1.1.6.0.20040626080929.01ebb4a0@mail.telecommunity.com>
Message-ID: <40DD69FF.3050807@v.loewis.de>

Phillip J. Eby wrote:
>> >>> try:
>> ..   1/0
>> .. except:
>> ..   pass
>> ..
>> >>> raise
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>> TypeError: exceptions must be classes, instances, or strings 
>> (deprecated), not NoneType
>>
>> Here, the re-raise doesn't find an exception anymore, even
>> though non has been raised...
> 
> 
> Isn't each statement/block in the interactive interpreter run in a new 
> frame?

Yes, but why does that matter? If the language spec says
"the exception stays until the next exception is raised", then
the interpreter doesn't conform to the language spec, and has
a bug.

Regards,
Martin


From jbone at deepfile.com  Sat Jun 26 10:23:44 2004
From: jbone at deepfile.com (Jeff Bone)
Date: Sat Jun 26 10:23:51 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <ACE2D138-C740-11D8-B553-000A95686CD8@redivi.com>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
	<6ee4c83804062513526ea4c4ac@mail.gmail.com>
	<DA7203C0-C6F1-11D8-A9D8-000A95CFE9DE@deepfile.com>
	<ACE2D138-C740-11D8-B553-000A95686CD8@redivi.com>
Message-ID: <6E63CE63-C77C-11D8-A9D8-000A95CFE9DE@deepfile.com>


> Uh, the WHOLE POINT we want this is to have side-effects.  If it 
> doesn't make the function act in a different way, it might as well 
> live in the doc string or something.

Declarative vs. imperative.  Design-time *definitional* modification of 
behavior vs. runtime.  I don't really think you want side-effects in 
the literal sense.  E.g. "classmethod" isn't a side-effect, it's a 
definitional thing.  If you really want side-effecting operations on 
functions, you've already got that given higher-order / first-class 
functions.

jb


From pje at telecommunity.com  Sat Jun 26 11:14:07 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat Jun 26 11:11:42 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <40DD69FF.3050807@v.loewis.de>
References: <5.1.1.6.0.20040626080929.01ebb4a0@mail.telecommunity.com>
	<1088161847.30612.40.camel@slothrop.corp.google.com>
	<40D67098.7080907@v.loewis.de>
	<1088090139.30612.24.camel@slothrop.corp.google.com>
	<E8C8327B-C688-11D8-8348-000A95EFAE9E@yahoo.com>
	<1088161847.30612.40.camel@slothrop.corp.google.com>
	<5.1.1.6.0.20040626080929.01ebb4a0@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20040626110054.02fbbde0@mail.telecommunity.com>

At 02:20 PM 6/26/04 +0200, Martin v. L?wis wrote:
>Phillip J. Eby wrote:
>>> >>> try:
>>>..   1/0
>>>.. except:
>>>..   pass
>>>..
>>> >>> raise
>>>Traceback (most recent call last):
>>>   File "<stdin>", line 1, in ?
>>>TypeError: exceptions must be classes, instances, or strings 
>>>(deprecated), not NoneType
>>>
>>>Here, the re-raise doesn't find an exception anymore, even
>>>though non has been raised...
>>
>>Isn't each statement/block in the interactive interpreter run in a new frame?
>
>Yes, but why does that matter? If the language spec says
>"the exception stays until the next exception is raised", then
>the interpreter doesn't conform to the language spec, and has
>a bug.

I thought the spec was that exceptions are active for the life of a frame's 
execution.  That's probably my projection of the implementation onto an 
ambiguous phrase in the spec, though.

Nonetheless, I think that the ambiguity can and should be resolved by 
defining "active in the current scope" to mean, "caught by an exception 
handler in the current frame or one of its parents".  This explanation 
should probably be added to the section on "Exceptions", and 
cross-referenced from the section on "raise".

Is there consensus such that I should make these changes to the spec?


From pje at telecommunity.com  Sat Jun 26 11:27:25 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat Jun 26 11:24:42 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <6E63CE63-C77C-11D8-A9D8-000A95CFE9DE@deepfile.com>
References: <ACE2D138-C740-11D8-B553-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
	<6ee4c83804062513526ea4c4ac@mail.gmail.com>
	<DA7203C0-C6F1-11D8-A9D8-000A95CFE9DE@deepfile.com>
	<ACE2D138-C740-11D8-B553-000A95686CD8@redivi.com>
Message-ID: <5.1.1.6.0.20040626111446.02fbfec0@mail.telecommunity.com>

At 09:23 AM 6/26/04 -0500, Jeff Bone wrote:

>>Uh, the WHOLE POINT we want this is to have side-effects.  If it doesn't 
>>make the function act in a different way, it might as well live in the 
>>doc string or something.
>
>Declarative vs. imperative.  Design-time *definitional* modification of 
>behavior vs. runtime.  I don't really think you want side-effects in the 
>literal sense.

Actually, he very well might, and a number of other people definitely 
do.  One use case repeatedly mentioned on Python-Dev has been to register 
functions or classes with frameworks, therefore definitely involving a 
literal side-effect (i.e. modification to an unrelated data structure).

(I wonder if I should submit a patch for PEP 318 to add this to the 
motivation section, because it seems a lot of people keep repeating this 
"no side-effects metadata" misconception.)


>E.g. "classmethod" isn't a side-effect, it's a definitional thing.  If you 
>really want side-effecting operations on functions, you've already got 
>that given higher-order / first-class functions.

Please read the current "Motivation" section of PEP 318.  The point isn't 
that such operations aren't possible, it's that they're not very readable 
in standard Python syntax.

In contrast, most other languages with first-class functions allow function 
definitions to be used as *expressions*, which means that they can be 
nested within a decoration expression, giving the reader a context for 
understanding the function definition.  PEP 318 seeks to remedy this 
clarity/readability issue, by providing an alternative syntax for 
expressions that will "wrap" a function definition that follows.


From pf_moore at yahoo.co.uk  Sat Jun 26 11:27:34 2004
From: pf_moore at yahoo.co.uk (Paul Moore)
Date: Sat Jun 26 11:27:27 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<40D84CEE.6040307@interlink.com.au>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<20040625100125.GA15576@vicky.ecs.soton.ac.uk>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
Message-ID: <oen6l4pl.fsf@yahoo.co.uk>

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

> * Which of the numerous possible syntax variations should be
>   used/recommended:

Just a reminder, but I believe that Guido has already pronounced to
the effect that there are only 3 contenders left:

    @staticmethod
    def foo(a,b,c):
        pass

    [staticmethod]
    def foo(a,b,c):
        pass

and

    def foo(a,b,c) [staticmethod]:
        pass

Hey - guess what? Writing them out like that, I find that my initial
preference for the 3rd one has gone. To be honest, I no longer have a
strong opinion between the three. In fact, if anything, I'd say I have
a very mild preference for Guido's option (number 2). I dislike the
ambiguity problem with it, though.

Paul
-- 
"Bother," said the Borg, "We've assimilated Pooh."


From tim.peters at gmail.com  Sat Jun 26 11:37:48 2004
From: tim.peters at gmail.com (Tim Peters)
Date: Sat Jun 26 11:37:55 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406261258.39791.phil@riverbankcomputing.co.uk>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
	<200406261223.09529.phil@riverbankcomputing.co.uk>
	<40DD6006.7070905@v.loewis.de>
	<200406261258.39791.phil@riverbankcomputing.co.uk>
Message-ID: <1f7befae0406260837506b3c1d@mail.gmail.com>

[Phil Thompson]
> Actually, it's simpler than that. From the GPL FAQ:
> 
> "I'm writing a Windows application with Microsoft Visual C++ (or Visual Basic)
> and I will be releasing it under the GPL.  Is dynamically linking my program
> with the Visual C++ (or Visual Basic) run-time library permitted under the
> GPL?
> 
> Yes, because that run-time library normally accompanies the compiler
> or interpreter you are using."
> 
> My (incorrect) understanding was that "operating system" was meant rather than
> "compiler or interpreter".

Heh.  That's what I meant by

    Regardless of internal consistency, I expect they'll develop a
rationale for saying
   "sure, fine".

I quoted the relevant part of the GPL verbatim before, and it does
indeed say specifically and only "operating system".  This is why you
have to ask the FSF directly about what they mean:  since the meaning
of the GPL has never been clarified via court rulings, in practice it
means whatever the FSF says it means, and that can't always be
predicted from what the GPL actually says.

From pje at telecommunity.com  Sat Jun 26 11:51:01 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat Jun 26 11:50:18 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <oen6l4pl.fsf@yahoo.co.uk>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<40D84CEE.6040307@interlink.com.au>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<20040625100125.GA15576@vicky.ecs.soton.ac.uk>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20040626114101.022fb860@mail.telecommunity.com>

At 04:27 PM 6/26/04 +0100, Paul Moore wrote:
>"Phillip J. Eby" <pje@telecommunity.com> writes:
>
> > * Which of the numerous possible syntax variations should be
> >   used/recommended:
>
>Just a reminder, but I believe that Guido has already pronounced to
>the effect that there are only 3 contenders left:

Those are based on changing the language's actual syntax.  The Dave 
Abrahams solution for decoration allows any currently-legal execution 
syntax to be used in today's Python versions.


>     @staticmethod
>     def foo(a,b,c):
>         pass
>
>     [staticmethod]
>     def foo(a,b,c):
>         pass
>
>and
>
>     def foo(a,b,c) [staticmethod]:
>         pass
>
>Hey - guess what? Writing them out like that, I find that my initial
>preference for the 3rd one has gone. To be honest, I no longer have a
>strong opinion between the three. In fact, if anything, I'd say I have
>a very mild preference for Guido's option (number 2). I dislike the
>ambiguity problem with it, though.

IMO, the ambiguity is resolved if some kind of visible invocation occurs, e.g.:

[declare_staticmethod()]
def foo(a,b,c):
     pass

While '[staticmethod]' by itself may appear to be a useless and ignorable 
statement, adding the () makes it clear that you have to know what the 
called function *does* before you could consider removing the statement.

When you add in the fact that this syntax can be made to work in Python 2.2 
and better, not just 2.4, it makes the syntax a big winner in my book.

I would like to reverse the application order, though: Guido's patch uses 
the same order for syntax 2 as for syntax 3, and now that I've played with 
syntax 2 "for real", I think that right-to-left application should be used 
for any syntax where the decorators come before the 'def'.


From martin at v.loewis.de  Sat Jun 26 13:20:29 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat Jun 26 13:21:37 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <5.1.1.6.0.20040626110054.02fbbde0@mail.telecommunity.com>
References: <5.1.1.6.0.20040626080929.01ebb4a0@mail.telecommunity.com>
	<1088161847.30612.40.camel@slothrop.corp.google.com>
	<40D67098.7080907@v.loewis.de>
	<1088090139.30612.24.camel@slothrop.corp.google.com>
	<E8C8327B-C688-11D8-8348-000A95EFAE9E@yahoo.com>
	<1088161847.30612.40.camel@slothrop.corp.google.com>
	<5.1.1.6.0.20040626080929.01ebb4a0@mail.telecommunity.com>
	<5.1.1.6.0.20040626110054.02fbbde0@mail.telecommunity.com>
Message-ID: <40DDB05D.6060401@v.loewis.de>

Phillip J. Eby wrote:
> Is there consensus such that I should make these changes to the spec?

Well, no - I still think it is a bug that re-raising after then end
of the exception handler but before the end of the function "works".

I'm actually surprised that the exception is cleared when the
function that has the exception handler completes. Where does that
happen? The current exception is in the thread state, not in the
frame, after all.

But then, consensus on the semantics isn't needed, as you should
be looking for BDFL pronouncement. So you might be asking "Is
there consensus that these changes reflect the BDFL pronouncement?"
to which I can't respond, as I haven't understood the BDFL
pronouncement.

Regards,
Martin



From psheer at icon.co.za  Sat Jun 26 13:45:13 2004
From: psheer at icon.co.za (Paul Sheer)
Date: Sat Jun 26 13:48:17 2004
Subject: [Python-Dev] Compiling the Python sources with a C++ compiler (aCC)
Message-ID: <20040626174513.GA4419@divinian>


(previously submitted to comp.lang.python)

I have managed to build Python 2.3.3 with the aCC HP-UX C++
compiler by making a number of one-line changes. (For reasons
beyond my control, I am forced to use this compiler and it has
no C mode at all.)

Typically to get the Python source code to compile under
aCC one has to make a number of trivial changes of the form,

     struct whatzit *p;
-    p = malloc (sizeof (struct whatzit));
+    p = (struct whatzit *) malloc (sizeof (struct whatzit));

since aCC has stricter casting rules than ANSI C and does
not automatically cast  void * .

Another change is where a forward declaration is
needed for the module type. The aCC compiler complines
about a duplicate definition. I change these from "static"
to "extern" which gives a warning, but otherwise works.
For example,

  + #define staticforward ... /* in my case 'extern' */

  - static PyTypeObject Comptype;
  + staticforward PyTypeObject Comptype;

(There is/was a staticforward macro which is not used
consistently.)

A third change are the Python module initializers
(PyMODINIT_FUNC xxx(void) {...): they need to obviously
be declared 'extern "C"' (for dl importing) which can
happen in the PyMODINIT_FUNC macro. However the macro
is not used consistently throughout the Python sources.

Finally, of course there are numerous uses of "new",
"class" and other C++ keywords. I wrote a short flex
script to search and replace through the entire sources
for instances of these.

To summarize the changes needed:

  1. explicit casting of void *
  2. consistant use of a "staticforward" type
     for PyTypeObject forward declarations.
  3. consinstant use of PyMODINIT_FUNC.
  4. use of PyMODINIT_FUNC even in prototypes
     (like config.c.in)
  5. renaming of C++ reserved words.

(There are other changes specific to the HP-UX
architecture - too numerous to mention.)

My question is: are the Python maintainers interested
in such compatibility?

Although Python will always be strict ANSI C, are such
changes not of general interest for the purposes of
consistency of the source code?

Can someone forward this email to the appropriate
developers list (or tell me which one)?

Shall I prepare a proper patch against 2.3.4?

What would the consensus be on replacements for
'new', 'class', 'template', 'operator', etc.?
Perhaps __new, zew, or new2; klass, __class, or
cla55 etc.?

Has this issue come up before? URLs?

Many thanks, best wishes

-paul

Paul Sheer . . . . . . . . . . . . . . . . .  Tel  . . +27 (0)21 6869634
Email . . . http://2038bug.com/email.gif . . . . . . . . . . . . . . . .
http://www.icon.co.za/~psheer . . . . . . . . .  http://rute.2038bug.com
L I N U X . . . . . . . . . . . . . . . . The Choice of a GNU Generation


From paul at prescod.net  Sat Jun 26 13:57:21 2004
From: paul at prescod.net (Paul Prescod)
Date: Sat Jun 26 13:57:07 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <04Jun25.214024pdt."58612"@synergy1.parc.xerox.com>
References: <04Jun25.214024pdt."58612"@synergy1.parc.xerox.com>
Message-ID: <40DDB901.5020100@prescod.net>

Bill Janssen wrote:

> It's of course the scanning that I'm talking about.  Having only "def"
> and "class" at the left edge makes it remarkably easy to scan for a
> function or class definition.  Putting oddly-shaped decorators there
> too ruins this.

I have to admit that I see this as unnecessary alarmism and I don't 
think it is supported by fact. Looking at just a few standard library 
modules you will see that it is common to put documentation (i.e. 
metadata) and globals in the left-margin. I'll demonstrate in two code 
examples and we'll see if they are really much different in terms of 
readability. In my opinion, the basic code shape (outdent, indent) is 
the same and that is what matters for readability.

     # Dispatch routine for best timer program (fastest if
     # an integer but float works too that).

     def trace_dispatch_i(self, frame, event, arg):
         timer = self.timer
         t = timer() - self.t - self.bias
         if self.dispatch[event](self, frame,t):
             self.t = timer()
         else:
             self.t = timer() - t  # put back unrecorded delta

     # Dispatch routine for macintosh (timer returns time in
     # 1/60th second)

     def trace_dispatch_mac(self, frame, event, arg):
         timer = self.timer
         t = timer()/60.0 - self.t - self.bias
         if self.dispatch[event](self, frame, t):
             self.t = timer()/60.0
         else:
             self.t = timer()/60.0 - t  # put back

Versus:


     # Dispatch routine for best timer program (fastest if
     # an integer but float works too that).

     @classmethod
     def trace_dispatch_i(self, frame, event, arg):
         timer = self.timer
         t = timer() - self.t - self.bias
         if self.dispatch[event](self, frame,t):
             self.t = timer()
         else:
             self.t = timer() - t  # put back unrecorded delta

     # Dispatch routine for macintosh (timer returns time in
     # 1/60th second)

     @something(something)
     def trace_dispatch_mac(self, frame, event, arg):
         timer = self.timer
         t = timer()/60.0 - self.t - self.bias
         if self.dispatch[event](self, frame, t):
             self.t = timer()/60.0
         else:
             self.t = timer()/60.0 - t  # put back

  Paul Prescod



From dave at boost-consulting.com  Sat Jun 26 14:43:18 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat Jun 26 14:43:53 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<40D84CEE.6040307@interlink.com.au>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<20040625100125.GA15576@vicky.ecs.soton.ac.uk>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<oen6l4pl.fsf@yahoo.co.uk>
	<5.1.1.6.0.20040626114101.022fb860@mail.telecommunity.com>
Message-ID: <uoen6kvnd.fsf@boost-consulting.com>

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

>>     @staticmethod
>>     def foo(a,b,c):
>>         pass
>>
>>     [staticmethod]
>>     def foo(a,b,c):
>>         pass
>>
>>and
>>
>>     def foo(a,b,c) [staticmethod]:
>>         pass
>>
>>Hey - guess what? Writing them out like that, I find that my initial
>>preference for the 3rd one has gone. To be honest, I no longer have a
>>strong opinion between the three. In fact, if anything, I'd say I have
>>a very mild preference for Guido's option (number 2). I dislike the
>>ambiguity problem with it, though.
>
> IMO, the ambiguity is resolved if some kind of visible invocation occurs, e.g.:
>
> [declare_staticmethod()]
> def foo(a,b,c):
>      pass
>
> While '[staticmethod]' by itself may appear to be a useless and
> ignorable statement, adding the () makes it clear that you have to
> know what the called function *does* before you could consider
> removing the statement.
>
> When you add in the fact that this syntax can be made to work in
> Python 2.2 and better, not just 2.4, it makes the syntax a big winner
> in my book.
>
> I would like to reverse the application order, though: Guido's patch
> uses the same order for syntax 2 as for syntax 3, and now that I've
> played with syntax 2 "for real", I think that right-to-left
> application should be used for any syntax where the decorators come
> before the 'def'.

Here's another syntactic idea that could be made to work without core
language changes:

  [as.staticmethod]
  def foo(a,b,c):
      pass

I think that one's pretty sweet.  It can be extended any number of
ways:

  [as.staticmethod, as.classmethod, ...]
  def foo(a,b,c):
      pass

  [as.staticmethod|classmethod| ...]
  def foo(a,b,c):
      pass


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From aahz at pythoncraft.com  Sat Jun 26 15:32:34 2004
From: aahz at pythoncraft.com (Aahz)
Date: Sat Jun 26 15:32:40 2004
Subject: [Python-Dev] Re: Candidate Itertools
In-Reply-To: <00ff01c45a18$a42ddac0$21ba958d@oemcomputer>
References: <eppstein-E756A9.12115024062004@sea.gmane.org>
	<00ff01c45a18$a42ddac0$21ba958d@oemcomputer>
Message-ID: <20040626193234.GA8970@panix.com>

On Thu, Jun 24, 2004, Raymond Hettinger wrote:
> 
> Just to be clear before I do it, does everyone support having
> dict.countkeys() as a dictionary classmethod instead of the original
> proposal?

I'm -0 on this.  I certainly don't object, but I'm not sure its use case
is common enough to warrant cluttering the dict object.  Unless someone
objects, use your best judgment.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith, c.l.py

From stephen at xemacs.org  Sat Jun 26 15:51:09 2004
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat Jun 26 15:51:34 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <1f7befae0406260837506b3c1d@mail.gmail.com> (Tim Peters's
	message of "Sat, 26 Jun 2004 11:37:48 -0400")
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>
	<200406261223.09529.phil@riverbankcomputing.co.uk>
	<40DD6006.7070905@v.loewis.de>
	<200406261258.39791.phil@riverbankcomputing.co.uk>
	<1f7befae0406260837506b3c1d@mail.gmail.com>
Message-ID: <87isdenln6.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Tim" == Tim Peters <tim.peters@gmail.com> writes:

    Tim> [Phil Thompson]

    >> Actually, it's simpler than that. From the GPL FAQ:

    >> "I'm writing a Windows application with Microsoft Visual C++
    >> (or Visual Basic) and I will be releasing it under the GPL.  Is
    >> dynamically linking my program with the Visual C++ (or Visual
    >> Basic) run-time library permitted under the GPL?

    >> Yes, because that run-time library normally accompanies the
    >> compiler or interpreter you are using."

That's weird; that kind of blanket statement simply is not compatible
with the letter of the GPL.  I wonder if Eben Moglen vets that FAQ.

They must be assuming that the run-time library is "compiler helper"
stuff, eg-but-not-limited-to code to handle long long ints and set up
the C++ exception and global constructors, etc.  So msvcrt should be
fine.  The interpretation is that this is code whose presence is
mandated in one form or another by the language definition.  Then it
could be generated at build time by the compiler, but instead it's
"pregenerated" and supplied as a library.  The GPL doesn't care
whether the translator is implemented via inline code generation or by
library calls.

In other words, if you call any functions in mscvrt directly, then
you've probably got GPL issues.  If you use proprietary language
extensions implemented as library calls, you may have GPL issues.  But
if all calls are implicit in standard C code that could just as well
be open-coded, or linked with cygwin.dll or libgcc1 and crt.o, no problem.

    >> My (incorrect) understanding was that "operating system" was
    >> meant rather than "compiler or interpreter".

Unfortunately, not all official statements by the FSF are vetted by
lawyers.  Don't conclude you were incorrect until you've gotten legal
advice from a lawyer with his lawyer hat on (either yours or the FSF's).

However, in this case I would guess that this has nothing to do with
the "operating system exception."

    Tim> Heh.  That's what I meant by

    Tim>     Regardless of internal consistency, I expect they'll
    Tim> develop a rationale for saying "sure, fine".

Heh, good luck.  Ask Peter Deutsch or the guys at TrollTech about that.

    Tim> This is why you have to ask the FSF directly about what they
    Tim> mean: since the meaning Of the GPL has never been clarified
    Tim> via court rulings, in practice it means whatever the FSF says
    Tim> it means, and that can't always be predicted from what the
    Tim> GPL actually says.

The real reason for asking the FSF, of course, is that legal advice
from the FSF is free-as-in-free-beer, while your lawyer will get a
vacation on the Riviera for answering that question, despite being far
less expert than Eben Moglen.

[Aside: It's both not as bad as you suggest, and far worse than that.
But that's not relevant today.]

Of course, the usual dysclaimer: I ANAL.

But-I'm-writing-this-to-avoid-my-real-work-ly y'rs,

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your bu

From ehuss at ironport.com  Sat Jun 26 17:09:49 2004
From: ehuss at ironport.com (Eric Huss)
Date: Sat Jun 26 16:57:42 2004
Subject: [Python-Dev] Heap allocated type objects from C
In-Reply-To: <40DD5570.9000601@v.loewis.de>
References: <Pine.BSF.4.58.0406251829290.40205@wintermute.sponsor.net>
	<40DD5570.9000601@v.loewis.de>
Message-ID: <Pine.BSF.4.58.0406261404420.2943@wintermute.sponsor.net>


On Sat, 26 Jun 2004, [ISO-8859-1] "Martin v. L=F6wis" wrote:

> Eric Huss wrote:
> > First, could someone tell me if I took the correct route for creating a
> > type object on the heap (based on my patch).
> >
> > Second, shouldn't there be a more direct API for doing this?  Perhaps a
> > more generalized interface to type_new(), or maybe something completely
> > new??
>
> I don't understand why the patch needs to be so complicated. Why can't
> you just make a global function that returns new type objects which
> are struct seqs? IOW, why do you need the factory type? Type objects
> are callable themselves, so they act as factories.

Yes, that is a better route to take.  Let me rework it to do that.

The question is, would that live in __builtins__ or in the new module as
Fred suggests?

-Eric

From jbone at place.org  Sat Jun 26 17:50:27 2004
From: jbone at place.org (Jeff Bone)
Date: Sat Jun 26 17:50:35 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <5.1.1.6.0.20040626111446.02fbfec0@mail.telecommunity.com>
References: <ACE2D138-C740-11D8-B553-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
	<6ee4c83804062513526ea4c4ac@mail.gmail.com>
	<DA7203C0-C6F1-11D8-A9D8-000A95CFE9DE@deepfile.com>
	<ACE2D138-C740-11D8-B553-000A95686CD8@redivi.com>
	<5.1.1.6.0.20040626111446.02fbfec0@mail.telecommunity.com>
Message-ID: <D62F8622-C7BA-11D8-A9D8-000A95CFE9DE@place.org>


On Jun 26, 2004, at 10:27 AM, Phillip J. Eby wrote:

> Actually, he very well might, and a number of other people definitely 
> do.  One use case repeatedly mentioned on Python-Dev has been to 
> register functions or classes with frameworks, therefore definitely 
> involving a literal side-effect (i.e. modification to an unrelated 
> data structure).

IMHO, the fact that this results in a modification to a data structure 
in framework code is an implementation detail;  conceptually it can be 
argued that this is *still not a side-effect* --- you are in essence 
*saying something about* the function or object in question, not 
expressing something algorithmic.  My fear is that we end up seeing 
stuff like this:

[SomeDecorator(someFreeVariable=Assignment)]
def foo(...):
     x = someFreeVariable
    ...

My biggest concern in all this is that we end up muddying up 
readability and clarity by trying to improve it.

> (I wonder if I should submit a patch for PEP 318 to add this to the 
> motivation section, because it seems a lot of people keep repeating 
> this "no side-effects metadata" misconception.)

I think that before we "clarify" the PEP that the intent here *is* to 
allow side-effects we should get some clarity on what a side-effect 
*is.*  Clearly there's enough lack of consensus about this;  perhaps we 
need to see more examples of how various folks would use it.

jb


From nhodgson at bigpond.net.au  Sat Jun 26 18:02:23 2004
From: nhodgson at bigpond.net.au (Neil Hodgson)
Date: Sat Jun 26 18:02:29 2004
Subject: [Python-Dev] Compiling the Python sources with a C++ compiler
	(aCC)
References: <20040626174513.GA4419@divinian>
Message-ID: <006601c45bc9$424f64b0$97488890@neil>

Paul Sheer:

> My question is: are the Python maintainers interested
> in such compatibility?
>
> Although Python will always be strict ANSI C, are such
> changes not of general interest for the purposes of
> consistency of the source code?

   I think it is unlikely that such a large patch and resulting C++
compatibility policy will be accepted.

   A benefit of compiling with C++ rather than C is link time type checking.
About 10 years ago I converted a large product from C to C++ and found a few
real bugs (that is users were seeing incorrect information) due to calls not
correctly matching function signatures. While most of these sorts of errors
are found by compile time checking against header files, there are
circumstances where different contexts of header inclusion can result in
differing definitions of functions.

   Neil


From niemeyer at conectiva.com  Sat Jun 26 22:26:24 2004
From: niemeyer at conectiva.com (Gustavo Niemeyer)
Date: Sat Jun 26 22:25:01 2004
Subject: [Python-Dev] gettext improvements
Message-ID: <20040627022624.GA5238@burma.localdomain>

I've just submitted patch #980500 to SF, which implements the
gettext improvements exactly as recently discussed. Every
review is welcome. Here is an excerpt:

In _locale module: 

- bind_textdomain_codeset() binding 

In gettext module: 

- bind_textdomain_codeset() function 
- lgettext(), lngettext(), ldgettext(), ldngettext(), 
  which return translated strings encoded in 
  preferred system encoding, if bind_textdomain_codeset()
  was not used. 
- Added equivalent functionality in install() and translate()
  functions and catalog classes. 
- Documented every change.

-- 
Gustavo Niemeyer
http://niemeyer.net

From bac at OCF.Berkeley.EDU  Sun Jun 27 01:03:53 2004
From: bac at OCF.Berkeley.EDU (Brett Cannon)
Date: Sun Jun 27 01:04:07 2004
Subject: [Python-Dev] What can we do about dealing with the Demo directory?
Message-ID: <40DE5539.9050709@ocf.berkeley.edu>

While reading through the "Extending/Embedding Python" tutorial (no 
snickering; I need to implement a type from scratch for my thesis and I 
figured I might as well read the tutorial for once), I noticed a mention 
of Demo/embed/demo.c .  Having heard the comments about how outdated the 
Demo directory was(I think the last thread was by AMK), I decided to 
poke around.

Some of it is fairly old.  The README, for instance, mentions a Contrib 
directory for stuff.  And the classes/Date.py file mentions the creation 
of a generator... using __getitem__ (took me a second to realize that I 
was not going nuts in not noticing a 'yield' statement).

Maintenance of the directory has come up before and has seems to die 
every time (which I don't blame anyone for; I myself never stepped 
forward to help).  But if it is going just site there, perhaps we should 
  consider getting rid of it?  Cool snippets of code can be grabbed from 
all over the Net (take the Cookbook, for instance), and so having it 
with the code is not as important as I am sure it was when the directory 
was created.

Or at least we could prune it down.  I can see usage from 
Demo/newmetaclasses/ since metaclasses can be hard to grasp without 
example code.  But couldn't we remove the Demo/metaclasses/ directory 
for instance?

I am partially doing this so as to see if people care enough to bother 
putting an announcement in the python-dev Summary (maybe even 
python-announce) to try to get the community as a whole to help update 
the files.  Maybe everyone on this list could adopt one module and bring 
it up to date or something.  Just seems like something should happen 
with it, and if it is just going to sit we could at least prune it.

-Brett

From martin at v.loewis.de  Sun Jun 27 03:39:28 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun Jun 27 03:39:34 2004
Subject: [Python-Dev] Compiling the Python sources with a C++ compiler
	(aCC)
In-Reply-To: <20040626174513.GA4419@divinian>
References: <20040626174513.GA4419@divinian>
Message-ID: <40DE79B0.60908@v.loewis.de>

Paul Sheer wrote:
> I have managed to build Python 2.3.3 with the aCC HP-UX C++
> compiler by making a number of one-line changes. (For reasons
> beyond my control, I am forced to use this compiler and it has
> no C mode at all.)

I believe you haven't responded to my question on c.l.p yet:
what happens if you invoke c89?

Regards,
Martin


From martin at v.loewis.de  Sun Jun 27 03:46:58 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun Jun 27 03:48:25 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <87isdenln6.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <UTC200406171801.i5HI1nYm029994@hera.cwi.nl>	<200406261223.09529.phil@riverbankcomputing.co.uk>	<40DD6006.7070905@v.loewis.de>	<200406261258.39791.phil@riverbankcomputing.co.uk>	<1f7befae0406260837506b3c1d@mail.gmail.com>
	<87isdenln6.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <40DE7B72.3020101@v.loewis.de>

Stephen J. Turnbull wrote:
> They must be assuming that the run-time library is "compiler helper"
> stuff, eg-but-not-limited-to code to handle long long ints and set up
> the C++ exception and global constructors, etc.  So msvcrt should be
> fine.  The interpretation is that this is code whose presence is
> mandated in one form or another by the language definition.

I think the reasoning is different: in order to run software, you
need an operating system. It is ok if free software doesn't ship
with its own operating system, but if users of the software already
have an operating system. Likewise, it is ok if free software doesn't
ship with the compiler to compile it - users who want to build the
software are expected to obtain a copy of the compiler.

Therefore, users can be expected to have everything that comes with
the operating system, and everything that comes with the compiler.
Therefore, it is ok to assume that people already have a copy
of msvcr71.dll if they want to use VC7.1 to build something.

Regards,
Martin


From arigo at tunes.org  Sun Jun 27 07:39:10 2004
From: arigo at tunes.org (Armin Rigo)
Date: Sun Jun 27 07:41:52 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <40DDB05D.6060401@v.loewis.de>
References: <5.1.1.6.0.20040626080929.01ebb4a0@mail.telecommunity.com>
	<1088161847.30612.40.camel@slothrop.corp.google.com>
	<40D67098.7080907@v.loewis.de>
	<1088090139.30612.24.camel@slothrop.corp.google.com>
	<E8C8327B-C688-11D8-8348-000A95EFAE9E@yahoo.com>
	<1088161847.30612.40.camel@slothrop.corp.google.com>
	<5.1.1.6.0.20040626080929.01ebb4a0@mail.telecommunity.com>
	<5.1.1.6.0.20040626110054.02fbbde0@mail.telecommunity.com>
	<40DDB05D.6060401@v.loewis.de>
Message-ID: <20040627113910.GA16330@vicky.ecs.soton.ac.uk>

Hello,

Sorry, I only replied to the SF tracker.  The language specs are vague but a
very precise explanation for the "currently active exception" is given in the
library reference for sys.get_info().  The language spec can be made precise
just by copying or pointing to that text.

In other words, if we make explicit the implicit assumption that a bare
'raise' is indeed intended equivalent to

   exc, val, tb = sys.exc_info()
   raise exc, val, tb

then the docs are already precise enough and CPython really implements that.


A bient?t,

Armin.

From noamr at myrealbox.com  Sun Jun 27 08:15:23 2004
From: noamr at myrealbox.com (Noam Raphael)
Date: Sun Jun 27 08:15:31 2004
Subject: [Python-Dev] Reference implementation of an import hook
Message-ID: <40DEBA5B.9080208@myrealbox.com>

Hello,

I've sent this question to comp.lang.python and didn't get any response.

Do you know of a reference implementation of an import hook? I mean a
class, written in Python, that imitates Python's default module loading
behaviour. I mean that I would be able to append the class to 
sys.path_hooks, and module loading won't be affected.

I want it so that it would be easy for me to modify it, or subclass it,
for my own needs, while preserving its behaviour. (My situation, if you
are interested, is that in my current setup, modules are loaded from the 
network, which takes a long time. I want to create a caching mechanism 
which will use the local hard disk.)

It seems to me that such an implementation should be added to the 
standard library or at least to the documentation, since it would help 
anyone who would like to write an import hook, and would also help 
clarify Python's import mechanism. If such an implementation doesn't 
exist, I would probably write one anyway, and I would be willing to 
share it, if people want it.

Thank you,
Noam Raphael


From arigo at tunes.org  Sun Jun 27 09:38:29 2004
From: arigo at tunes.org (Armin Rigo)
Date: Sun Jun 27 09:41:07 2004
Subject: [Python-Dev] Wild Idea for the Year
In-Reply-To: <001b01c45635$3a03cec0$52af958d@oemcomputer>
References: <001b01c45635$3a03cec0$52af958d@oemcomputer>
Message-ID: <20040627133828.GA12230@vicky.ecs.soton.ac.uk>

Hello,

On Sat, Jun 19, 2004 at 03:40:07PM -0400, Raymond Hettinger wrote:
>         s = ""
>         for e in iterable:
>             s = s + e

Hum, it may not be impossible after all.

http://www.python.org/sf/980695 -> an idea that seems to work and only
involves 3 pages of obfuscated code in new well-isolated functions of ceval.c.  
stringobject.c is unmodified.


Armin

From aahz at pythoncraft.com  Sun Jun 27 11:08:21 2004
From: aahz at pythoncraft.com (Aahz)
Date: Sun Jun 27 11:08:26 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <04Jun25.214024pdt."58612"@synergy1.parc.xerox.com>
References: <40DC475F.4070202@prescod.net>
	<04Jun25.214024pdt."58612"@synergy1.parc.xerox.com>
Message-ID: <20040627150821.GA20746@panix.com>

On Fri, Jun 25, 2004, Bill Janssen wrote:
> Paul Prescod writes:
>>
>> Nobody reads code one line at a time from the top down. You scan for the 
>> bit that interests you and then look around for its context.
> 
> But I disagree with your statement here.  Everyone reads *unfamiliar*
> code one line at a time from the top.  If you're really reading it, I
> mean, rather than just looking for something in it.

Well, I'm not "everyone", though I suppose you could argue that I'm just
looking for something.  When I look at a module, I first skim it to find
the interesting parts.  I almost always know what the module is supposed
to do, so I'm looking for the bits that support the module's primary
purpose.  

You've got a point about cluttering the code, but *all* the proposed
solutions clutter code in some way.  I agree with Paul that you're being
unnecessarily alarmist.

My ordering of preference is:

Decorator after ``def``
JavaDoc style

I'm -1 on the proposal to put decorator before ``def``.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith, c.l.py

From barry at python.org  Sun Jun 27 11:49:53 2004
From: barry at python.org (Barry Warsaw)
Date: Sun Jun 27 11:49:45 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <20040627113910.GA16330@vicky.ecs.soton.ac.uk>
References: <5.1.1.6.0.20040626080929.01ebb4a0@mail.telecommunity.com>
	<1088161847.30612.40.camel@slothrop.corp.google.com>
	<40D67098.7080907@v.loewis.de>
	<1088090139.30612.24.camel@slothrop.corp.google.com>
	<E8C8327B-C688-11D8-8348-000A95EFAE9E@yahoo.com>
	<1088161847.30612.40.camel@slothrop.corp.google.com>
	<5.1.1.6.0.20040626080929.01ebb4a0@mail.telecommunity.com>
	<5.1.1.6.0.20040626110054.02fbbde0@mail.telecommunity.com>
	<40DDB05D.6060401@v.loewis.de>
	<20040627113910.GA16330@vicky.ecs.soton.ac.uk>
Message-ID: <1088351393.7333.215.camel@localhost>

On Sun, 2004-06-27 at 07:39, Armin Rigo wrote:

> In other words, if we make explicit the implicit assumption that a bare
> 'raise' is indeed intended equivalent to
> 
>    exc, val, tb = sys.exc_info()
>    raise exc, val, tb
> 
> then the docs are already precise enough and CPython really implements that.

IIRC the discusions at the time bare raise was added, those were exactly
the intended semantics.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040627/f6744dc7/attachment.bin
From amk at amk.ca  Sun Jun 27 11:59:31 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Sun Jun 27 11:59:50 2004
Subject: [Python-Dev] What can we do about dealing with the Demo directory?
In-Reply-To: <40DE5539.9050709@ocf.berkeley.edu>
References: <40DE5539.9050709@ocf.berkeley.edu>
Message-ID: <20040627155931.GA17438@rogue.amk.ca>

On Sat, Jun 26, 2004 at 10:03:53PM -0700, Brett Cannon wrote:
> the files.  Maybe everyone on this list could adopt one module and bring 
> it up to date or something.  Just seems like something should happen 
> with it, and if it is just going to sit we could at least prune it.

Updating the demo directory might be a good project for the next bug day.

--amk

From p at 2038bug.com  Sun Jun 27 07:56:45 2004
From: p at 2038bug.com (Paul Sheer)
Date: Sun Jun 27 12:00:38 2004
Subject: [Python-Dev] Compiling the Python sources with a C++ compiler
	(aCC)
In-Reply-To: <Pine.BSF.4.58.0406261505220.12865@familjen.svensson.org>;
	from paul@svensson.org on Sat, Jun 26, 2004 at 21:08:15 +0200
References: <20040626174513.GA4419@divinian>
	<Pine.BSF.4.58.0406261505220.12865@familjen.svensson.org>
Message-ID: <20040627115645.GC4791@divinian>


> Neil Hodgson:
>    I think it is unlikely that such a large patch and resulting C++
> compatibility policy will be accepted.


> Paul Svensson:
> 
> The Pythin sorces are written in C; that they fail to compile
> when usung a compiler for a different language is a feature, not a bug.
> 

of course :-)

however, most of the changes are good coding practice in any case.

the rest are outright inconsistencies in the python source
and ought to be fixed -

for instance, the macros 'PyMODINIT_FUNC' and 'staticforward'
are *not* used with consistency

in all, the patch is merely one-liner style changes, and
nothing more. The patch is not large.

on a philosophical note, one could have said that the Python
sources were POSIX, and: "the fact that they fail to compile
when using a different OS is a feature not a bug."

yet today Python compiles on a wide range of OS's

-paul



From barry at python.org  Sun Jun 27 12:11:56 2004
From: barry at python.org (Barry Warsaw)
Date: Sun Jun 27 12:11:52 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <oen6l4pl.fsf@yahoo.co.uk>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<40D84CEE.6040307@interlink.com.au>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<20040625100125.GA15576@vicky.ecs.soton.ac.uk>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<oen6l4pl.fsf@yahoo.co.uk>
Message-ID: <1088352716.7336.241.camel@localhost>

On Sat, 2004-06-26 at 11:27, Paul Moore wrote:

> Just a reminder, but I believe that Guido has already pronounced to
> the effect that there are only 3 contenders left:

I've said before that I'm past caring which syntax is chosen.  I could
live with any of these three.  I just want the feature in 2.4 and I
trust Guido to Make The Right Decision.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040627/30d15bd1/attachment.bin
From ronaldoussoren at mac.com  Sun Jun 27 12:20:30 2004
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun Jun 27 12:20:44 2004
Subject: [Python-Dev] Compiling the Python sources with a C++
	compiler	(aCC)
In-Reply-To: <20040627115645.GC4791@divinian>
References: <20040626174513.GA4419@divinian>
	<Pine.BSF.4.58.0406261505220.12865@familjen.svensson.org>
	<20040627115645.GC4791@divinian>
Message-ID: <E85ECDE9-C855-11D8-A205-0003931CFE24@mac.com>


On 27-jun-04, at 13:56, Paul Sheer wrote:

>
>> Neil Hodgson:
>>    I think it is unlikely that such a large patch and resulting C++
>> compatibility policy will be accepted.
>
>
>> Paul Svensson:
>>
>> The Pythin sorces are written in C; that they fail to compile
>> when usung a compiler for a different language is a feature, not a 
>> bug.
>>
>
> of course :-)
>
> however, most of the changes are good coding practice in any case.
>
> the rest are outright inconsistencies in the python source
> and ought to be fixed -
>
> for instance, the macros 'PyMODINIT_FUNC' and 'staticforward'
> are *not* used with consistency

This part of your patch should be fairly uncontroversial (but: I've not 
read your patch and I'm not a Python developer).

I'd seperate your patch into two patches, one containing only this part 
of your patch and another containing the changes that are necessary to 
compile with a C++ compiler.

>
> in all, the patch is merely one-liner style changes, and
> nothing more. The patch is not large.
>
> on a philosophical note, one could have said that the Python
> sources were POSIX, and: "the fact that they fail to compile
> when using a different OS is a feature not a bug."

That might be because Python started out on a non-POSIX platform (IIRC) 
:-)

Ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173


From martin at v.loewis.de  Sun Jun 27 12:55:10 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun Jun 27 12:55:15 2004
Subject: [Python-Dev] Python startup time: String objects
In-Reply-To: <200403251958.i2PJwqk19625@guido.python.org>
References: <200403251949.i2PJnod07229@twilight.domainfactory.de>
	<200403251958.i2PJwqk19625@guido.python.org>
Message-ID: <40DEFBEE.2040707@v.loewis.de>

Guido van Rossum wrote:
>>The change is backwards-compatible in the sense that existing files can
>>be unmarshalled just fine. Problems will only arise if new marshal output
>>is unmarshalled by old versions, which could be solved with an option
>>during marshalling.
> 
> 
> Works for me.  Make sure to update py_compile.py.

I have made that change now. In the process, I have changed the magic,
and introduced a marshal version number. marshal.dumps? now expects
an optional version number, which, if ommitted, defaults to the current
version (i.e. 1); older versions need to be specified explicitly.

Regards,
Martin


From pje at telecommunity.com  Sun Jun 27 18:03:06 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun Jun 27 18:00:21 2004
Subject: [Python-Dev] Wild Idea for the Year
In-Reply-To: <20040627133828.GA12230@vicky.ecs.soton.ac.uk>
References: <001b01c45635$3a03cec0$52af958d@oemcomputer>
	<001b01c45635$3a03cec0$52af958d@oemcomputer>
Message-ID: <5.1.1.6.0.20040627175530.02873c40@mail.telecommunity.com>

At 02:38 PM 6/27/04 +0100, Armin Rigo wrote:
>Hello,
>
>On Sat, Jun 19, 2004 at 03:40:07PM -0400, Raymond Hettinger wrote:
> >         s = ""
> >         for e in iterable:
> >             s = s + e
>
>Hum, it may not be impossible after all.
>
>http://www.python.org/sf/980695 -> an idea that seems to work and only
>involves 3 pages of obfuscated code in new well-isolated functions of 
>ceval.c.
>stringobject.c is unmodified.

Looks interesting.  It appears the cost is added to cases that are likely 
to have longer execution times anyway.  (i.e. the slow_add and slow_iadd 
cases.)

I notice that string_concatenate() doesn't cover the STORE_DEREF case, 
however.  Was that intentional?

Last question: is this actually faster when 'e' is replaced by an 
expression that causes memory allocation?  That is, isn't this *still* 
going to be an O(n**2) operation if the string has to be relocated on each 
addition?


From tim.peters at gmail.com  Sun Jun 27 18:22:56 2004
From: tim.peters at gmail.com (Tim Peters)
Date: Sun Jun 27 18:23:08 2004
Subject: [Python-Dev] Wild Idea for the Year
In-Reply-To: <5.1.1.6.0.20040627175530.02873c40@mail.telecommunity.com>
References: <001b01c45635$3a03cec0$52af958d@oemcomputer>
	<001b01c45635$3a03cec0$52af958d@oemcomputer>
	<5.1.1.6.0.20040627175530.02873c40@mail.telecommunity.com>
Message-ID: <1f7befae040627152243f0a32b@mail.gmail.com>

[Phillip J. Eby, on

        s = ""
        for e in iterable:
            s = s + e

and

   http://www.python.org/sf/980695
]
...
> Last question: is this actually faster when 'e' is replaced by an
> expression that causes memory allocation?  That is, isn't this *still*
> going to be an O(n**2) operation if the string has to be relocated on each
> addition?

It can't guarantee worst-case linear time, regardless of whether e
causes memory allocation.  That's because it relies on the platform
realloc() to get more memory (after the string gets too big for
pymalloc), so its behavior depends on what the platform realloc()
does.  If the string gets "big enough", a number of realloc()
implementations will move the string "to the end" of memory, and grow
it thereafter via sbrk() calls.  If e causes memory allocation too,
it's likely to get satisfied by free blocks "before the end" of memory
(for example, from the big block released at the time the string first
got moved to the end).  But there's no consistency across platforms in
how the native realloc() behaves.

BTW, so long as the string object is small enough to be handled by
pymalloc, it guarantees *to* copy the entire string object for each 8
characters added (pymalloc can never extend in-place when an 8-byte
boundary is crossed).

From vinay_sajip at red-dove.com  Sun Jun 27 18:52:03 2004
From: vinay_sajip at red-dove.com (Vinay Sajip)
Date: Sun Jun 27 19:27:21 2004
Subject: [Python-Dev] Planned changes to logging
Message-ID: <000f01c45c99$5e644dc0$652b6992@alpha>

I'm planning to check in some changes to the logging package. I'd appreciate
comments on the following:

1. A backwards-compatible change to basicConfig(), making simple
configuration of logging easier than before. For example, to change the
level of the root logger to DEBUG:

logging.basicConfig(level=logging.DEBUG)

For example, to change the message format:

logging.basicConfig(format="%(asctime)s %(levelname)-5s %(message)s")

To log to a file in append mode (for write mode, add a filemode="w"
argument):

logging.basicConfig(filename="/logs/myapp.log")

To log to an existing stream:

s = open("/logs/myapp.log", "w")
...
logging.basicConfig(stream=s)

2. Refactoring of RotatingFileHandler into BaseRotatingHandler and
RotatingFileHandler. The reason for this is the addition of a new class,
TimedRotatingFileHandler, which rotates files based on time-dependent
criteria. (See SF patch #921318 for more details).

3. Logger.log() changed to throw a TypeError if raiseExceptions is set and
the level passed in is not an integer.

If the changes seem generally acceptable, then I'll also add a section in
the docs which describes the above basic use cases under a "Basic use of the
logging package" section which appears earlier in the logging docs than it
does currently. Except for the documentation changes, I'm planning to commit
by 3 July.

Thanks,


Vinay



From tim.peters at gmail.com  Sun Jun 27 21:13:45 2004
From: tim.peters at gmail.com (Tim Peters)
Date: Sun Jun 27 21:13:50 2004
Subject: [Python-Dev] Joy in Berkeley Windowsland
Message-ID: <1f7befae040627181348177f65@mail.gmail.com>

Sharing the joy:  after Greg's checkins today, the Berkeley tests
(test_anydbm and, with -u bsddb, test_bsddb3) all pass on WinXP.  Yay!

That means there's nothing I routinely expect to fail all the time on
Windows anymore <0.9 wink>.

From greg at cosc.canterbury.ac.nz  Sun Jun 27 22:12:11 2004
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Sun Jun 27 22:12:20 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <40DC475F.4070202@prescod.net>
Message-ID: <200406280212.i5S2CBJg025348@cosc353.cosc.canterbury.ac.nz>

> The left edge is already cluttered.
> 
> a = 5
> b = a()
> def foo(xyz):
>      abc = 5
> c = 20
> 
> It is the indentation that alerts your eye to the function definition.

But the indentation alone doesn't distinguish a def from an if or
while or any other indented thing. Most people would leave some space
before and after the function definition:

  a = 5
  b = a()

  def foo(xyz):
     abc = 5

  c = 20

Unfortunately, leaving space between the decorators and the function
would break the visual association between them.

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

From kbk at shore.net  Sun Jun 27 23:19:04 2004
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sun Jun 27 23:19:13 2004
Subject: [Python-Dev] Weekly Python Bug/Patch Summary
Message-ID: <200406280319.i5S3J4Dp010584@hydra.localdomain>


Patch / Bug Summary
___________________

Patches :  286 open (+10) /  2422 closed ( +7) /  2708 total (+17)
Bugs    :  771 open (+30) /  4168 closed (+12) /  4939 total (+42)
RFE     :  142 open ( +2) /   129 closed ( +0) /   271 total ( +2)

New / Reopened Patches
______________________

Parser/acceler.c: PyObject_MALLOC return is not checked  (2004-06-17)
       http://python.org/sf/974633  opened by  Dima Dorfman 

Signal fixes for BSD systems  (2004-06-18)
       http://python.org/sf/975056  opened by  Luke Mewburn 

compileall.py - print file name in err msg in quiet mode  (2004-06-19)
CLOSED http://python.org/sf/975885  opened by  Matthias Klose 

Deferred String Addtion:  Proof-of-concept  (2004-06-20)
       http://python.org/sf/976162  opened by  Raymond Hettinger 

Stripping script extensions with distutils  (2004-06-21)
       http://python.org/sf/976869  opened by  Fred L. Drake, Jr. 

speed up md5: allow Encode and Decode to inline  (2004-06-21)
       http://python.org/sf/977074  opened by  Matthew Mueller 

Speed up EnumKey call  (2004-06-22)
       http://python.org/sf/977553  opened by  Garth Bushell 

dev_intro - make patch review request more obvious  (2004-06-22)
CLOSED http://python.org/sf/977671  opened by  Jim Jewett 

Improve HTML documentation of a directory  (2004-06-25)
       http://python.org/sf/979658  opened by  Noam Raphael 

mplementation for PEP 318 using java-style syntax  (2004-06-25)
       http://python.org/sf/979728  opened by  Mark Russell 

compile of code with incorrect encoding yields MemoryError  (2004-06-25)
CLOSED http://python.org/sf/979737  opened by  Anthony Tuininga 

OSATerminology extension fix  (2004-06-25)
       http://python.org/sf/979784  opened by  has 

Missing INCREF in PyType_Ready  (2004-06-25)
       http://python.org/sf/980082  opened by  Eric Huss 

Module to dynamically generate structseq objects  (2004-06-25)
       http://python.org/sf/980098  opened by  Eric Huss 

difflib empty list IndexError fix (Bug #980117)  (2004-06-25)
       http://python.org/sf/980120  opened by  Rocco Moretti 

partially initialized heap allocated type objects  (2004-06-26)
       http://python.org/sf/980475  opened by  Eric Huss 

gettext improvements  (2004-06-27)
       http://python.org/sf/980500  opened by  Gustavo Niemeyer 

efficient string concatenation  (2004-06-27)
       http://python.org/sf/980695  opened by  Armin Rigo 

Patches Closed
______________

A simple 3-4% speed-up for PCs  (2004-04-28)
       http://python.org/sf/943898  closed by  arigo

configure interpreter for profiling  (2003-07-08)
       http://python.org/sf/768079  closed by  montanaro

compileall.py - print file name in err msg in quiet mode  (2004-06-19)
       http://python.org/sf/975885  closed by  loewis

add C API to datetime module  (2004-01-13)
       http://python.org/sf/876130  closed by  tim_one

dev_intro - make patch review request more obvious  (2004-06-22)
       http://python.org/sf/977671  closed by  loewis

invalid submission  (2004-06-25)
       http://python.org/sf/979737  closed by  atuining

Cleanup generator/eval_frame exposure  (2004-06-04)
       http://python.org/sf/966493  closed by  loewis

Support for interned strings in marshal  (2004-03-25)
       http://python.org/sf/923098  closed by  loewis

New / Reopened Bugs
___________________

missing word in defintion of xmldom InvalidStateErr  (2004-06-16)
CLOSED http://python.org/sf/973901  opened by  Brian Gough 

ConfigParser defaults not handled correctly  (2004-06-16)
       http://python.org/sf/974019  opened by  Charles 

Slice indexes passed to __getitem__ are wrapped  (2004-06-17)
       http://python.org/sf/974635  opened by  Connelly 

urllib2's HTTPPasswordMgr and uri's with port numbers  (2004-06-17)
       http://python.org/sf/974757  opened by  Chris Withers 

test_unicode_file fails on Win98SE  (2004-03-27)
       http://python.org/sf/924703  reopened by  tim_one

Inconsistent newline handling in email module  (2004-06-18)
       http://python.org/sf/975330  opened by  Anders Hammarquist 

Python and segfaulting extension modules  (2004-06-18)
CLOSED http://python.org/sf/975387  opened by  Folke Lemaitre 

logging module uses deprecate apply()  (2004-06-18)
CLOSED http://python.org/sf/975404  opened by  Barry Alan Scott 

HTMLParser lukewarm on bogus bare attribute chars  (2004-06-18)
       http://python.org/sf/975556  opened by  Mike Coleman 

tp_(get|set)attro? inheritance bug  (2004-06-18)
       http://python.org/sf/975646  opened by  Gustavo J. A. M. Carneiro 

shutil.copytree uses os.mkdir instead of os.mkdirs  (2004-06-18)
       http://python.org/sf/975763  opened by  Brett Cannon 

Add _PyTime_DoubletoTimet to C API  (2004-06-19)
CLOSED http://python.org/sf/975996  opened by  Brett Cannon 

Unhelpful error message when getmtime.c fails  (2004-06-21)
       http://python.org/sf/976608  opened by  Peter Maxwell 

socket timeouts problems on Solaris  (2004-06-21)
       http://python.org/sf/976613  opened by  Peter =C5strand 

PDB: unreliable breakpoints on functions  (2004-06-21)
       http://python.org/sf/976878  opened by  Dieter Maurer 

mmap needs a rfind method  (2004-06-21)
       http://python.org/sf/976880  opened by  Nicholas Riley 

Double __init__.py executing  (2004-06-22)
       http://python.org/sf/977250  opened by  Alexandre 

Solaris likes sys/loadavg.h  (2004-06-22)
       http://python.org/sf/977343  opened by  Anthony Baxter 

Cannot specify compiler for 'install' on command line  (2004-06-22)
       http://python.org/sf/977461  opened by  Anders J. Munch 

Deleted files are reinstalled  (2004-06-22)
       http://python.org/sf/977470  opened by  Anders J. Munch 

IMAP4_SSL() class incompatible with socket.timeout  (2004-06-22)
       http://python.org/sf/977680  opened by  Charles 

Python compiler encodes path to source in .pyc  (2004-06-22)
CLOSED http://python.org/sf/977934  opened by  Jonathan Polley 

"build" target doesn't check umask  (2004-06-22)
       http://python.org/sf/977937  opened by  Charles 

Spurious errors taking bool of dead proxy  (2004-06-23)
       http://python.org/sf/978308  opened by  Chris King 

Broken URLs in sha module docs  (2004-06-23)
       http://python.org/sf/978556  opened by  Troels Therkelsen 

wait_variable hangs at exit  (2004-06-23)
       http://python.org/sf/978604  opened by  Russell Owen 

configure and gmake fail in openbsd 3.5 i386  (2004-06-24)
       http://python.org/sf/978632  opened by  - 

compiler warning for _NSGetExecutablePath() in getpath.c  (2004-06-23)
CLOSED http://python.org/sf/978645  opened by  Brett Cannon 

can't compile _localemodule.c w/o --enable-toolbox-glue  (2004-06-23)
       http://python.org/sf/978662  opened by  Brett Cannon 

SSL-ed sockets don't close correct?  (2004-06-24)
       http://python.org/sf/978833  opened by  Robert Kiendl 

Remove all email from the archives  (2004-06-24)
CLOSED http://python.org/sf/978952  opened by  Encolpe DEGOUTE 

Trap OSError when calling RotatingFileHandler.doRollover  (2004-06-24)
       http://python.org/sf/979252  opened by  Richard T. Hewitt 

urllib2 digest auth totally broken  (2004-06-24)
       http://python.org/sf/979407  opened by  Aaron Swartz 

compile of code with incorrect encoding yields MemoryError  (2004-06-25)
       http://python.org/sf/979739  opened by  Anthony Tuininga 

diffutil errors when coparing 2 0 byte entries  (2004-06-25)
       http://python.org/sf/979794  opened by  Robert M. Zigweid 

On HPUX 11i universal newlines seems to cause readline(s) to  (2004-06-25)
       http://python.org/sf/979872  opened by  dmcisaac 

email.Message.Message.__getitem__ doc string wrong  (2004-06-25)
       http://python.org/sf/979924  opened by  Jp Calderone 

gethostbyname is broken on hpux 11.11  (2004-06-25)
       http://python.org/sf/979967  opened by  Ehab Teima 

email module namespace inconsistent  (2004-06-25)
CLOSED http://python.org/sf/980019  opened by  Charles 

tp_subclasses grow without bounds  (2004-06-25)
       http://python.org/sf/980092  opened by  Eric Huss 

Index error for empty lists in Difflib  (2004-06-25)
       http://python.org/sf/980117  opened by  Rocco Moretti 

Possible error during LINKCC check in Configure.in  (2004-06-25)
       http://python.org/sf/980127  opened by  Brett Cannon 

ntpath normpath  (2004-06-26)
       http://python.org/sf/980327  opened by  Keyphrene 

coercion results used dangerously  (2004-06-26)
       http://python.org/sf/980352  opened by  Armin Rigo 

int left-shift causes memory leak  (2004-06-26)
CLOSED http://python.org/sf/980419  opened by  Erik Demaine 

Possible contradiction in "extending" and PyArg_ParseTuple()  (2004-06-27)
       http://python.org/sf/980925  opened by  Brett Cannon 

smtplib.SMTP prints debug stuff to stdout  (2004-06-27)
       http://python.org/sf/980938  opened by  Skip Montanaro 

Bugs Closed
___________

missing word in defintion of xmldom InvalidStateErr  (2004-06-16)
       http://python.org/sf/973901  closed by  bcannon

bsddb in Python 2.3 incompatible with SourceNav output  (2004-06-15)
       http://python.org/sf/973054  closed by  greg

bsddb test_all.py - incorrect  (2003-12-23)
       http://python.org/sf/865120  closed by  greg

bsddb craps out sporadically  (2003-12-10)
       http://python.org/sf/857909  closed by  greg

Python and segfaulting extension modules  (2004-06-18)
       http://python.org/sf/975387  closed by  loewis

logging module uses deprecate apply()  (2004-06-18)
       http://python.org/sf/975404  closed by  bcannon

platform.system() Windows inconsistency  (2004-05-01)
       http://python.org/sf/945665  closed by  lemburg

shutil.move can destroy files   (2004-03-18)
       http://python.org/sf/919012  closed by  bcannon

pydoc.stripid doesn't strip ID  (2004-04-13)
       http://python.org/sf/934282  closed by  bcannon

wrong answers from ctime  (2004-01-09)
       http://python.org/sf/874042  closed by  bcannon

Add _PyTime_DoubletoTimet to C API  (2004-06-19)
       http://python.org/sf/975996  closed by  tim_one

Python compiler encodes path to source in .pyc  (2004-06-23)
       http://python.org/sf/977934  closed by  loewis

compiler warning for _NSGetExecutablePath() in getpath.c  (2004-06-23)
       http://python.org/sf/978645  closed by  bcannon

Remove all email from the archives  (2004-06-24)
       http://python.org/sf/978952  closed by  loewis

email module namespace inconsistent  (2004-06-25)
       http://python.org/sf/980019  closed by  bwarsaw

int left-shift causes memory leak  (2004-06-26)
       http://python.org/sf/980419  closed by  rhettinger


From greg at cosc.canterbury.ac.nz  Mon Jun 28 00:48:56 2004
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon Jun 28 00:49:11 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <40DD6006.7070905@v.loewis.de>
Message-ID: <200406280448.i5S4muBQ025541@cosc353.cosc.canterbury.ac.nz>

> If you include MSVCR71.DLL in your binary Python module, you would
> need to provide source code to MSVCR71.DLL as well.

If that's true, then it's illegal to distribute *any* GPL software
compiled with VC7 -- or with any other language implementation that
links in a non-open-source runtime library -- and has been for a long
time.  I find it hard to believe that's the intent of the GPL. There
must be a lot of software out there that does this -- is it all
breaking the law?

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

From greg at cosc.canterbury.ac.nz  Mon Jun 28 00:56:42 2004
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon Jun 28 00:56:50 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <40DDB05D.6060401@v.loewis.de>
Message-ID: <200406280456.i5S4ugEG025558@cosc353.cosc.canterbury.ac.nz>

> I'm actually surprised that the exception is cleared when the
> function that has the exception handler completes.

I think it's probably when the "except" clause of the
exception handler completes, not the function.

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

From martin at v.loewis.de  Mon Jun 28 01:01:27 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 28 01:01:34 2004
Subject: [Python-Dev] VC 7.1 maintenance?
In-Reply-To: <200406280448.i5S4muBQ025541@cosc353.cosc.canterbury.ac.nz>
References: <200406280448.i5S4muBQ025541@cosc353.cosc.canterbury.ac.nz>
Message-ID: <40DFA627.2060101@v.loewis.de>

Greg Ewing wrote:
>>If you include MSVCR71.DLL in your binary Python module, you would
>>need to provide source code to MSVCR71.DLL as well.
> 
> 
> If that's true, then it's illegal to distribute *any* GPL software
> compiled with VC7 -- or with any other language implementation that
> links in a non-open-source runtime library -- and has been for a long
> time.  I find it hard to believe that's the intent of the GPL. There
> must be a lot of software out there that does this -- is it all
> breaking the law?

As always, Tim is right: if you want to know for sure, ask the FSF
lawyer.

My interpretation is that in the strict sense of the letter these
programs violate the GPL. The entire binary distribution forms
"work based on the Program"; inclusion of msvcr71.dll is not
"mere aggregation". Then, according to clause 3, you are required
to accompany the program with a machine-readable source code
(or equivalent offers), which means "complete source
code means all the source code for all modules it contains".
The special exemption for things normally distributed with the
operating system does not apply, as msvcr71.dll is not normally
distributed with "major components (compiler, kernel, and so on)
of the operating system".

However, it appears that the FSF FAQ has taken the stance that
VC7.1 is indeed a major component of the operating system
(being the system compiler), and that therefore, the exemption
clause does apply.

Under U.S. law, it seems that only a court could interpret
this license for good. But what do I care about U.S. law.

Regards,
Martin


From martin at v.loewis.de  Mon Jun 28 01:17:08 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon Jun 28 01:17:13 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
In-Reply-To: <200406280456.i5S4ugEG025558@cosc353.cosc.canterbury.ac.nz>
References: <200406280456.i5S4ugEG025558@cosc353.cosc.canterbury.ac.nz>
Message-ID: <40DFA9D4.7040209@v.loewis.de>

Greg Ewing wrote:
>>I'm actually surprised that the exception is cleared when the
>>function that has the exception handler completes.
> 
> 
> I think it's probably when the "except" clause of the
> exception handler completes, not the function.

See for yourself:

def f():
   try:
     raise Exception, "Hello"
   except:
     pass
   raise

f()

gives

Traceback (most recent call last):
   File "c.py", line 8, in ?
     f()
   File "c.py", line 3, in f
     raise Exception, "Hello"
Exception: Hello

Regards,
Martin


From python at rcn.com  Sun Jun 27 15:08:21 2004
From: python at rcn.com (Raymond Hettinger)
Date: Mon Jun 28 03:09:24 2004
Subject: [Python-Dev] Joy in Berkeley Windowsland
In-Reply-To: <1f7befae040627181348177f65@mail.gmail.com>
Message-ID: <001e01c45c7a$1d4f0560$29b7958d@oemcomputer>

[Tim]
> That means there's nothing I routinely expect to fail all the time on
> Windows anymore <0.9 wink>.

Except for Windows itself.


Raymond


From arigo at tunes.org  Mon Jun 28 05:19:32 2004
From: arigo at tunes.org (Armin Rigo)
Date: Mon Jun 28 05:22:16 2004
Subject: [Python-Dev] Wild Idea for the Year
In-Reply-To: <5.1.1.6.0.20040627175530.02873c40@mail.telecommunity.com>
References: <001b01c45635$3a03cec0$52af958d@oemcomputer>
	<001b01c45635$3a03cec0$52af958d@oemcomputer>
	<5.1.1.6.0.20040627175530.02873c40@mail.telecommunity.com>
Message-ID: <20040628091932.GA7702@vicky.ecs.soton.ac.uk>

Hello Phillip,

On Sun, Jun 27, 2004 at 06:03:06PM -0400, Phillip J. Eby wrote:
> Looks interesting.  It appears the cost is added to cases that are likely 
> to have longer execution times anyway.  (i.e. the slow_add and slow_iadd 
> cases.)

Yes.  I didn't time it, but I expect that it a lot of applications would
see a small increase in performance just because special-casing + even between
small strings is faster than doing all this PyNumber_Add() madness.

> I notice that string_concatenate() doesn't cover the STORE_DEREF case, 
> however.  Was that intentional?

Ops, thanks.  I overlooked this one.

> Last question: is this actually faster when 'e' is replaced by an 
> expression that causes memory allocation?  That is, isn't this *still* 
> going to be an O(n**2) operation if the string has to be relocated on each 
> addition?

Apparently not, according to a few tests.  I suspect the memory allocator does
some kind of over-allocation automatically, though I'm not sure how much
Python's and Linux's allocators each contribute to this result.

However, I noticed that it doesn't work for expressions like s=s+t+u, because
it is associated as s=(s+t)+u.  s+=t+u works, though.


Armin

From mchermside at ingdirect.com  Mon Jun 28 08:11:16 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Mon Jun 28 08:11:20 2004
Subject: [Python-Dev] Re: decorators and 2.4
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>

Jeff Bone writes:
> IMHO, making decorators functions is a bad idea.  Decorators are 
> metadata about the function to which they refer.

Bob Ippolito responds:
> Uh, the WHOLE POINT we want this is to have side-effects.  If it 
> doesn't make the function act in a different way, it might as well live > in the doc string or something.
> 
> The most wanted use cases are all function transformations, not the 
> setting attributes on function objects.

And back to Jeff:
> Declarative vs. imperative.  Design-time *definitional* modification of > behavior vs. runtime.  I don't really think you want side-effects in 
> the literal sense.  E.g. "classmethod" isn't a side-effect, it's a 
> definitional thing.  If you really want side-effecting operations on 
> functions, you've already got that given higher-order / first-class 
> functions.

Just one more opinion here, but I'm with Bob on this one. Sure, many
of the uses I envision are "declarative" in the sense that they just
associate metadata with the function. But many other uses I envision
would alter the function's behavior. Yes, of COURSE it can all be
achieved by applying higher-order operations to Python's first-class
functions -- in my mind, that's what decorators ARE... a cleaner
syntax allowing easier use of higher order functions.

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From aahz at pythoncraft.com  Mon Jun 28 10:05:18 2004
From: aahz at pythoncraft.com (Aahz)
Date: Mon Jun 28 10:05:23 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <9C03360A-C649-11D8-94F6-000A95686CD8@redivi.com>
References: <1087414523.7150.45.camel@localhost>
	<001f01c4538d$f1fcfec0$bfaf2c81@oemcomputer>
	<20040624142741.GC27922@panix.com>
	<9C03360A-C649-11D8-94F6-000A95686CD8@redivi.com>
Message-ID: <20040628140518.GA16685@panix.com>

On Thu, Jun 24, 2004, Bob Ippolito wrote:
> On Jun 24, 2004, at 10:27 AM, Aahz wrote:
>>On Wed, Jun 16, 2004, Raymond Hettinger wrote:
>>>
>>>Please do give consideration to putting all of this in a single
>>>module.  IMO, this is too small of an addition to warrant splitting
>>>everything in to packages (which make it more difficult to understand
>>>and maintain as a collective unit).
>>
>>That's true.  However, there has been a regular low-level discussion
>>about creating a ``text`` package; why not simply name it ``string``?
> 
> If nothing else, that would cause hell for people who would like to use 
> a backport of the package for Python N, where N is less than the first 
> version that had this feature but still had the string module.

This actually makes it *easier* to backport; you only take the submodule
you want.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith, c.l.py

From bob at redivi.com  Mon Jun 28 10:18:28 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Jun 28 10:18:47 2004
Subject: [Python-Dev] PEP 292 for Python 2.4
In-Reply-To: <20040628140518.GA16685@panix.com>
References: <1087414523.7150.45.camel@localhost>
	<001f01c4538d$f1fcfec0$bfaf2c81@oemcomputer>
	<20040624142741.GC27922@panix.com>
	<9C03360A-C649-11D8-94F6-000A95686CD8@redivi.com>
	<20040628140518.GA16685@panix.com>
Message-ID: <06AFFA9D-C90E-11D8-BA03-000A95686CD8@redivi.com>


On Jun 28, 2004, at 7:05 AM, Aahz wrote:

> On Thu, Jun 24, 2004, Bob Ippolito wrote:
>> On Jun 24, 2004, at 10:27 AM, Aahz wrote:
>>> On Wed, Jun 16, 2004, Raymond Hettinger wrote:
>>>>
>>>> Please do give consideration to putting all of this in a single
>>>> module.  IMO, this is too small of an addition to warrant splitting
>>>> everything in to packages (which make it more difficult to 
>>>> understand
>>>> and maintain as a collective unit).
>>>
>>> That's true.  However, there has been a regular low-level discussion
>>> about creating a ``text`` package; why not simply name it ``string``?
>>
>> If nothing else, that would cause hell for people who would like to 
>> use
>> a backport of the package for Python N, where N is less than the first
>> version that had this feature but still had the string module.
>
> This actually makes it *easier* to backport; you only take the 
> submodule
> you want.

Why is calling it string instead of text easier?  You can't easily 
replace string, because site-packages comes late in sys.path.

-bob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040628/3544c284/smime.bin
From jim at zope.com  Mon Jun 28 10:50:08 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Jun 28 10:50:12 2004
Subject: [Python-Dev] Proposal: thread.get_dict
Message-ID: <40E03020.7010101@zope.com>


We often want to associate data with threads.  Python
manages a dictionary per-tread for this purpose, but there's
currently no way to get to this dictionary from Python.

I propose, for 2.4, to add a get_dict method to the thread
module that will return this dictionary.  This will be
implemented via a call to PyThreadState_GetDict.

Any objections?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From aahz at pythoncraft.com  Mon Jun 28 11:07:01 2004
From: aahz at pythoncraft.com (Aahz)
Date: Mon Jun 28 11:07:08 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <40E03020.7010101@zope.com>
References: <40E03020.7010101@zope.com>
Message-ID: <20040628150701.GA22341@panix.com>

On Mon, Jun 28, 2004, Jim Fulton wrote:
> 
> We often want to associate data with threads.  Python
> manages a dictionary per-tread for this purpose, but there's
> currently no way to get to this dictionary from Python.
> 
> I propose, for 2.4, to add a get_dict method to the thread
> module that will return this dictionary.  This will be
> implemented via a call to PyThreadState_GetDict.

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

"Typing is cheap.  Thinking is expensive."  --Roy Smith, c.l.py

From arigo at tunes.org  Mon Jun 28 12:16:19 2004
From: arigo at tunes.org (Armin Rigo)
Date: Mon Jun 28 12:18:50 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <40E03020.7010101@zope.com>
References: <40E03020.7010101@zope.com>
Message-ID: <20040628161619.GA14187@vicky.ecs.soton.ac.uk>

Hello Jim,

On Mon, Jun 28, 2004 at 10:50:08AM -0400, Jim Fulton wrote:
> I propose, for 2.4, to add a get_dict method to the thread
> module that will return this dictionary.  This will be
> implemented via a call to PyThreadState_GetDict.

I am pretty sure that some extension modules would badly crash if arbitrary
Python code would be allowed to temper with the data that they store there.  

Actually, to encourage encapsulation I'd push for another interface.  For
example there could be a constructor thread.Locals which you invoke once at a
global level; it returns an object whose attributes are then local to the
thread.  An unrelated module's call to thread.Locals returns an unrelated
object.

To polish the idea more, thread.Locals would be a class that you can also
inherit from to use the functionality in your own classes.  Something along
the lines of the C version of

class Locals(object):
  def __getattribute__(self, attr):
    d = PyThreadState_GetDict()
    attrs = d.setdefault(self, {})   # use 'self' as the key
    try:
      return attrs[attr]
    except KeyError:
      ...
  def __setattr__(self, attr, value):
    ...
  def __delattr__(self, attr):
    ...


Armin

From jim.jewett at eds.com  Mon Jun 28 12:28:04 2004
From: jim.jewett at eds.com (Jewett, Jim J)
Date: Mon Jun 28 12:29:04 2004
Subject: [Python-Dev] Re: decorators and 2.4
Message-ID: <B8CDFB11BB44D411B8E600508BDF076C22955B3A@usahm010.exmi01.exch.eds.com>

Phillip Eby:

> Is it the name you dislike?  Or the idea of simply 
> invoking decorating functions directly?

If decorate is a callable class rather than a function,
it can be subclassed for common idioms.  

The question is whether or not this is a good idea.  Any 
specific use will be more clear with a usage-specific
name, but the construct as a whole may be muddied if nothing
ties these names together.  For instance, it classmethod 
were subclassed from decorate (but used current usage when 
it got an argument), you could write

    classmethod()
    def f():
        pass

But you would also see things like

    dec1()	# No good way to chain decorators.
    def g():
        pass
    g=dec2(g)

Personally, I want decorators tied together with a word (such
as "decorate" or "using"), but I admit that list brackets + 
line-break *might* be enough.

    decorators(classmethod())
    def f(): 
        pass

    decorators(dec1(), dec2())
    def g():
        pass

vs

    [classmethod()]
    def f():
        pass

    [dec1(), dec2()]
    def g():
        pass


-jJ

From pje at telecommunity.com  Mon Jun 28 12:37:45 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon Jun 28 12:35:21 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <40E03020.7010101@zope.com>
Message-ID: <5.1.1.6.0.20040628123537.02243600@mail.telecommunity.com>

At 10:50 AM 6/28/04 -0400, Jim Fulton wrote:

>We often want to associate data with threads.  Python
>manages a dictionary per-tread for this purpose, but there's
>currently no way to get to this dictionary from Python.
>
>I propose, for 2.4, to add a get_dict method to the thread
>module that will return this dictionary.  This will be
>implemented via a call to PyThreadState_GetDict.
>
>Any objections?

What's wrong with using (e.g. setting attributes on) 
'threading.currentThread()'?  It's already implemented and available in 2.3 
(and numerous prior versions).


From pje at telecommunity.com  Mon Jun 28 12:43:54 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon Jun 28 12:41:09 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <B8CDFB11BB44D411B8E600508BDF076C22955B3A@usahm010.exmi01.e
	xch.eds.com>
Message-ID: <5.1.1.6.0.20040628124119.01f25de0@mail.telecommunity.com>

At 12:28 PM 6/28/04 -0400, Jewett, Jim J wrote:

>But you would also see things like
>
>     dec1()      # No good way to chain decorators.
>     def g():
>         pass
>     g=dec2(g)

This works with the proof-of-concept code I posted:

     [dec2(), dec1()]
     def g():
         pass

and so does this:

     dec2()
     dec1()
     def g():
         pass

So, I don't know what you mean about no good way to chain them.  The 
chaining is implemented in the tracing hook.


>Personally, I want decorators tied together with a word (such
>as "decorate" or "using"), but I admit that list brackets +
>line-break *might* be enough.

You can always do this:

     def using(*args):
         pass

<wink>


From jbone at place.org  Mon Jun 28 12:50:45 2004
From: jbone at place.org (Jeff Bone)
Date: Mon Jun 28 12:50:51 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
References: <0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
Message-ID: <4CA7798A-C923-11D8-9B14-000A95CFE9DE@place.org>


> Just one more opinion here, but I'm with Bob on this one. Sure, many
> of the uses I envision are "declarative" in the sense that they just
> associate metadata with the function. But many other uses I envision
> would alter the function's behavior.

I'm really curious what these uses might be.  Folks keep saying this 
kind of thing, but when you dig in IMHO most of these actually seem to 
be design-time things, statements *about* the intent or use of the 
function (relative to the language runtime itself, e.g. classmethod and 
so forth, or relative to a framework, such as registering a function, 
or relative to some tool, e.g. for extended documentation purposes or 
type-checking, etc.) rather than e.g. runtime modifications to its 
behavior.

I wouldn't keep pushing on this except that I'm entirely puzzled about 
what these legitimate "runtime" applications might be that aren't 
already more easily and clearly accomplished with existing mechanisms:  
arguments, lexical scope, and higher-order functions.  I'm all for 
decorations as a mechanism for declaring things *about* the function as 
above, but I'm at a loss re: rationale for "decorations" that do more 
than declaratively and immutably *decorate* the function.

Given that my distinctions between declarative and imperative uses of 
decorators and design- vs. run-time seem to have confused more than 
they've illuminated, perhaps a series of questions, scenarios, and 
thoughts might help clarify the areas of my concern.

(1)  Does a function have access to its own decorators?

I expect the answer here should be "yes."  We should be careful, 
though, that this does not introduce a mutable container for state.  
We've already got one such thing:  object instances.  We don't need 
another.

(2)  Do decorators define literal constant values at design-time or do 
they define a scope of mutable bindings?

The PEP gives this example:

	def mymethod(f) [attrs(versionadded="2.2", author="Guido van Rossum")]:
	    ...

That seems fine, but what about this:

	x = "Guido van Rossum"
	def mymethod(f) [attrs(versionadded="2.2", author=x)]:

Danger, Will Robinson!  ;-)  Even worse:

	x = "Guido van Rossum"
	def mymethod(f) [attrs(versionadded="2.2", author=x)]:
                    oldAuthor = someHandleToMyDecorators.atts.author
		someHandleToMyDecorators.atts.author = "Eric Idle"

IMHO, the RHS of an "assignment" in a decorator should only be some 
value that can be known at "compile" time, which probably means it's 
either a reference to a singly-assigned constant value or a literal.  
If you allow arbitrary variables or attributes in decorators to be 
assigned, then you limit the utility of decorators for many of their 
intended purposes such as e.g. type-checking.  Furthermore, if you can 
"assign" a decorator's attribute more than once --- particularly if the 
decorated thing (function, method, object, whatever) can access those 
bindings --- then you've simply re-invented objects with an alternate 
and idiosyncratic syntax.

(3)  Should it be possible to conditionally evaluate decorators based 
on run-time state?

The following, IMHO, is truly scary and inhibits many of the intended 
uses of decorators.  This shouldn't be legal, ever:

if foo = 3:
	[someDecoratorThatModifiesBarsRuntimeBehavior]
else:
	[someOtherDecorator]
def bar(...):
	...

If you're going to do that, just use callables, nested scopes, 
first-order functions, currying, etc.

jb


From barry at python.org  Mon Jun 28 13:19:31 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Jun 28 13:19:20 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <4CA7798A-C923-11D8-9B14-000A95CFE9DE@place.org>
References: <0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<4CA7798A-C923-11D8-9B14-000A95CFE9DE@place.org>
Message-ID: <1088443171.7466.347.camel@localhost>

On Mon, 2004-06-28 at 12:50, Jeff Bone wrote:
> > Just one more opinion here, but I'm with Bob on this one. Sure, many
> > of the uses I envision are "declarative" in the sense that they just
> > associate metadata with the function. But many other uses I envision
> > would alter the function's behavior.
> 
> I'm really curious what these uses might be.

Here's one of my use case.  

In the Mailman3 implementation of the BerkeleyDB backend storage, I need
to set up Berkeley transactions around various calls.  It's
programmatically possible to set up an explicit transaction to group
several operations together, but it's also possible to wrap a single
operation in a single transaction.  Also, the Berkeley transactions must
be wrapped in try/excepts so that if any Python level exception occurs,
the transaction can be properly aborted.

There's enough complexity in the implementation, and similarity in the
use, that I wanted to encapsulate all that in a 'txnprop' decorator.  I
currently use the 'call-after-def' wrapper idiom that's possible in
Python 2.3 today, but I want to use decorators for this, especially
because I sometimes want to combine the txnprop wrapper with other
decorators.

Here's a pointer to some of the code:

http://cvs.sourceforge.net/viewcvs.py/mailman/mailman3/src/mailman/berkeleydb/bdblist.py?rev=3.2&view=auto

The txnprop() descriptor guarantees that self.txn is bound to a
transaction inside the method call.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040628/80ff73a9/attachment.bin
From jbone at place.org  Mon Jun 28 13:27:52 2004
From: jbone at place.org (Jeff Bone)
Date: Mon Jun 28 13:28:02 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <1088443171.7466.347.camel@localhost>
References: <0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<4CA7798A-C923-11D8-9B14-000A95CFE9DE@place.org>
	<1088443171.7466.347.camel@localhost>
Message-ID: <7C37D21D-C928-11D8-9B14-000A95CFE9DE@place.org>


Okay, this is a great and meaty example, thanks Barry.  It's the first  
one that I've seen that is clearly not a purely declarative thing at  
least in the abstract.  What would the proposed decorator version of  
this look like?

On Jun 28, 2004, at 12:19 PM, Barry Warsaw wrote:

> Here's a pointer to some of the code:
>
> http://cvs.sourceforge.net/viewcvs.py/mailman/mailman3/src/mailman/ 
> berkeleydb/bdblist.py?rev=3.2&view=auto
>
> The txnprop() descriptor guarantees that self.txn is bound to a
> transaction inside the method call.
>
> -Barry
>


From dave at boost-consulting.com  Mon Jun 28 13:27:24 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon Jun 28 13:28:12 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
	<6ee4c83804062513526ea4c4ac@mail.gmail.com>
	<DA7203C0-C6F1-11D8-A9D8-000A95CFE9DE@deepfile.com>
	<ACE2D138-C740-11D8-B553-000A95686CD8@redivi.com>
	<6E63CE63-C77C-11D8-A9D8-000A95CFE9DE@deepfile.com>
Message-ID: <uzn6na8zn.fsf@boost-consulting.com>

Jeff Bone <jbone@deepfile.com> writes:

>> Uh, the WHOLE POINT we want this is to have side-effects.  If it
>> doesn't make the function act in a different way, it might as well
>> live in the doc string or something.
>
> Declarative vs. imperative.  Design-time *definitional* modification
> of behavior vs. runtime.  I don't really think you want side-effects
> in the literal sense.  E.g. "classmethod" isn't a side-effect, it's a
> definitional thing.  If you really want side-effecting operations on
> functions, you've already got that given higher-order / first-class
> functions.

I'm a big fan of declarative programs.

That said, declarativeness (especially in Python) is more a matter of
"notational flavor" than anything we can measure.  It's certainly
independent of whether there are actual side-effects.

Also, I'm suspicious of any heroic efforts to prevent language
features from being "abused".  Some of the most powerful techniques in
many languages were not envisioned by the language designers.  The
languages I like (by their nature) tend to encourage the invention of
these unforseen techniques.  Python is one of them.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From jbone at place.org  Mon Jun 28 13:44:41 2004
From: jbone at place.org (Jeff Bone)
Date: Mon Jun 28 13:44:46 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <uzn6na8zn.fsf@boost-consulting.com>
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
	<6ee4c83804062513526ea4c4ac@mail.gmail.com>
	<DA7203C0-C6F1-11D8-A9D8-000A95CFE9DE@deepfile.com>
	<ACE2D138-C740-11D8-B553-000A95686CD8@redivi.com>
	<6E63CE63-C77C-11D8-A9D8-000A95CFE9DE@deepfile.com>
	<uzn6na8zn.fsf@boost-consulting.com>
Message-ID: <D547AE1A-C92A-11D8-9B14-000A95CFE9DE@place.org>


On Jun 28, 2004, at 12:27 PM, David Abrahams wrote:

> I'm a big fan of declarative programs.

BTW, for the record --- I'm not under any illusions about Python's 
"declarativeness."  ;-)

> That said, declarativeness (especially in Python) is more a matter of
> "notational flavor" than anything we can measure.  It's certainly
> independent of whether there are actual side-effects.
>
> Also, I'm suspicious of any heroic efforts to prevent language
> features from being "abused".

Let me be specific about what I'm actually worried about, here.  
Specifically:  I've been playing a bit with some type-inferencing stuff 
and optional typing.  One desiderata for decorators, per the PEP, is to 
support applications like embedding type signatures and so forth into 
the language, attaching them to the relevant objects.  A goal could be 
to support at least partial compilation with (some, and optional) 
compile-time guarantees about type safety and behavior.  To the extent 
that decorators either (a) are evaluated conditionally based on runtime 
state, or (b) modify and are in turn modified by runtime state, 
decorators as mutable environments or with true side effects make a 
mess of that.  Perhaps you don't really want "decorators" for that --- 
perhaps you want "macros."  Subtle but IMHO important distinction.

NB, I'm no type Nazi.  But I'd really like to see (a) Python 
implemented in Python, someday --- it would make playing with all these 
sorts of languages ideas and moving the language along a LOT easier, 
and (b) Python compiling easily to (and running well on) arbitrary 
machines or virtual machines.  The more runtime / imperative / 
conditional / side-effecting behavior we allow for decorators, the more 
difficult both of those goals become.

Not trying (heroically or otherwise) to keep language features from 
being abused as much as simply ask the question "have we REALLY thought 
through the use cases, the alternatives, and their impact on the future 
of the language."

jb


From barry at python.org  Mon Jun 28 13:48:11 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Jun 28 13:48:04 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <7C37D21D-C928-11D8-9B14-000A95CFE9DE@place.org>
References: <0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<4CA7798A-C923-11D8-9B14-000A95CFE9DE@place.org>
	<1088443171.7466.347.camel@localhost>
	<7C37D21D-C928-11D8-9B14-000A95CFE9DE@place.org>
Message-ID: <1088444890.7466.351.camel@localhost>

On Mon, 2004-06-28 at 13:27, Jeff Bone wrote:
> Okay, this is a great and meaty example, thanks Barry.  It's the first  
> one that I've seen that is clearly not a purely declarative thing at  
> least in the abstract.  What would the proposed decorator version of  
> this look like?

Depends on which syntax Guido chooses <wink>.

I'd be able to remove all the "func = txnprop(_func)" trailers, and do
something like:

[txnprop]
def create_list(self, listid):
    # ...

or

def create_list(self, listid) [txnprop]:
    # ...

or

@txnprop
def create_list(self, listid):
    # ...

All of which seem much more clear than what I currently have to do.
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040628/8bf47a4b/attachment-0001.bin
From jim at zope.com  Mon Jun 28 13:52:34 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Jun 28 13:52:41 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <20040628161619.GA14187@vicky.ecs.soton.ac.uk>
References: <40E03020.7010101@zope.com>
	<20040628161619.GA14187@vicky.ecs.soton.ac.uk>
Message-ID: <40E05AE2.1080608@zope.com>

Armin Rigo wrote:
> Hello Jim,
> 
> On Mon, Jun 28, 2004 at 10:50:08AM -0400, Jim Fulton wrote:
> 
>>I propose, for 2.4, to add a get_dict method to the thread
>>module that will return this dictionary.  This will be
>>implemented via a call to PyThreadState_GetDict.
> 
> 
> I am pretty sure that some extension modules would badly crash if arbitrary
> Python code would be allowed to temper with the data that they store there.  

AFAIK, only one bit of extension code uses this data.

But, of course, applications that use this data would have to
be disciplined about picking keys to avoid conflict. This is actually
pretty easy.  In Zope 3, when a bit of code wants to place a value into a
shared namespace, it uses it's package dotted name as a prefix for
the key.  In this way, code from different packages don't accidentelly
use the same key.

> Actually, to encourage encapsulation I'd push for another interface.  For
> example there could be a constructor thread.Locals which you invoke once at a
> global level; it returns an object whose attributes are then local to the
> thread.  An unrelated module's call to thread.Locals returns an unrelated
> object.
> 
> To polish the idea more, thread.Locals would be a class that you can also
> inherit from to use the functionality in your own classes.  Something along
> the lines of the C version of
> 
> class Locals(object):
>   def __getattribute__(self, attr):
>     d = PyThreadState_GetDict()
>     attrs = d.setdefault(self, {})   # use 'self' as the key
>     try:
>       return attrs[attr]
>     except KeyError:
>       ...
>   def __setattr__(self, attr, value):
>     ...
>   def __delattr__(self, attr):
>     ...

This is a fine idea, but I think a simpler mechanism will work
just as well and avoid the extra dictionary lookup that your suggestion
introduces.  I have an application in which these lookups will be done a
lot and I want to minimize overhead.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From python at rcn.com  Mon Jun 28 01:52:36 2004
From: python at rcn.com (Raymond Hettinger)
Date: Mon Jun 28 13:53:44 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <20040628161619.GA14187@vicky.ecs.soton.ac.uk>
Message-ID: <005101c45cd4$1e2ffca0$29b7958d@oemcomputer>

> On Mon, Jun 28, 2004 at 10:50:08AM -0400, Jim Fulton wrote:
> > I propose, for 2.4, to add a get_dict method to the thread
> > module that will return this dictionary.  This will be
> > implemented via a call to PyThreadState_GetDict.

[Armin]
> I am pretty sure that some extension modules would badly crash if
> arbitrary
> Python code would be allowed to temper with the data that they store
> there.

Would it defeat the purpose to expose a read-only dictionary proxy (such
as that in descrobject.c) ?


Raymond


From jim at zope.com  Mon Jun 28 13:58:56 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Jun 28 13:59:00 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <5.1.1.6.0.20040628123537.02243600@mail.telecommunity.com>
References: <5.1.1.6.0.20040628123537.02243600@mail.telecommunity.com>
Message-ID: <40E05C60.7060306@zope.com>

Phillip J. Eby wrote:
> At 10:50 AM 6/28/04 -0400, Jim Fulton wrote:
> 
>> We often want to associate data with threads.  Python
>> manages a dictionary per-tread for this purpose, but there's
>> currently no way to get to this dictionary from Python.
>>
>> I propose, for 2.4, to add a get_dict method to the thread
>> module that will return this dictionary.  This will be
>> implemented via a call to PyThreadState_GetDict.
>>
>> Any objections?
> 
> 
> What's wrong with using (e.g. setting attributes on) 
> 'threading.currentThread()'?  It's already implemented and available in 
> 2.3 (and numerous prior versions).

But it's relatively expensive.  You have to call threading.currentThread,
Which then has to do a dict lookup.  Plus, when you get the thread, you have to
pick attribute names that won't conflict, which means that you either have ugly
attribute names or introduce an intermediate object to provide a separate
namespace, which ads more cost.

OTOH, Python has this nice per-thread dict that wants to be used for thread
data but is unexposed.

As far as 2.3 support, we'll provide something like this in Zope, but
I'd like to get it into Python so that we can stop providing it in Zope
some time in the future.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From tim.peters at gmail.com  Mon Jun 28 14:00:41 2004
From: tim.peters at gmail.com (Tim Peters)
Date: Mon Jun 28 14:00:46 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <5.1.1.6.0.20040628123537.02243600@mail.telecommunity.com>
References: <5.1.1.6.0.20040628123537.02243600@mail.telecommunity.com>
Message-ID: <1f7befae0406281100160ca5e8@mail.gmail.com>

[Phillip J. Eby]
> What's wrong with using (e.g. setting attributes on)
> 'threading.currentThread()'?  It's already implemented and available in 2.3
> (and numerous prior versions).

Jim's interest here is speed.  currentThread() is a Python-level
function call, which invokes the platform spelling for getting a
thread id, which is then used in a dict lookup to get the associated
Thread object.  The C API's PyThreadState_GetDict() has none of those
expenses:  a pointer to a thread-local dict is sitting in the current
thread state struct, available cheaply from C but currently not
available at all from Python.

If you need to access thread-local values frequently, the overhead of
the currentThread() approach can swamp the time spent doing useful
work.  Jim sees this in Zope3 machinery now.  I expect we're also
seeing it in the sandbox's Decimal.py (which needs to access
thread-local context on every operation, indirects thru yet another
layer of Python-level call to get at it).

From jim.jewett at eds.com  Mon Jun 28 14:03:23 2004
From: jim.jewett at eds.com (Jewett, Jim J)
Date: Mon Jun 28 14:04:08 2004
Subject: [Python-Dev] Re: decorators and 2.4
Message-ID: <B8CDFB11BB44D411B8E600508BDF076C22955B3B@usahm010.exmi01.exch.eds.com>

> This works with the proof-of-concept code I posted

Apparently I clipped too much.

With your proof-of-concept, one of your suggestions 
was using names like 

	classmethod_follows()

My intent was to say:

"Whatever method does become standard -- either in C, 
or through adding your code to stdlib -- I want some
way for a reader to know quickly that a function is
being decorated."

Therefore I do not want "better names" like

	classmethod()
	def foo():
		pass

because then various decorators will have nothing in 
common, except for the invisible fact that they they
share a common base class.

	decorators(classmethod())
	def foo(): 
		pass

is OK, and

	[classmethod()]
	def foo():
		pass

might be, because the "[]\n" or "decorators(...)" warn the
reader about what is happening.

-jJ



From jbone at place.org  Mon Jun 28 14:06:09 2004
From: jbone at place.org (Jeff Bone)
Date: Mon Jun 28 14:06:17 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <1088444890.7466.351.camel@localhost>
References: <0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<4CA7798A-C923-11D8-9B14-000A95CFE9DE@place.org>
	<1088443171.7466.347.camel@localhost>
	<7C37D21D-C928-11D8-9B14-000A95CFE9DE@place.org>
	<1088444890.7466.351.camel@localhost>
Message-ID: <D56CD749-C92D-11D8-9B14-000A95CFE9DE@place.org>


On Jun 28, 2004, at 12:48 PM, Barry Warsaw wrote:

> On Mon, 2004-06-28 at 13:27, Jeff Bone wrote:
>> Okay, this is a great and meaty example, thanks Barry.  It's the first
>> one that I've seen that is clearly not a purely declarative thing at
>> least in the abstract.  What would the proposed decorator version of
>> this look like?
>
> Depends on which syntax Guido chooses <wink>.

C'mon, Barry, work with me here. ;-)  I'm not as interested in the 
specific syntax as what the syntax implies about the semantics.

> I'd be able to remove all the "func = txnprop(_func)" trailers, and do
> something like:
>
> [txnprop]
> def create_list(self, listid):
>     # ...
>
> All of which seem much more clear than what I currently have to do.

Granted.  But let's look at the above.  Now, you're intimately familiar 
with the current implementation of txnprop, so you think of the above 
in terms of its literal side-effecting behavior.  But looking at it as 
a consumer of the interface --- simply as a user reading the code, or 
as some automated tool which doesn't understand and doesn't necessarily 
NEED to understand the effect of txnprop, that looks awfully 
declarative --- doesn't it?  You're in essence saying "the following is 
a transactional function."

So on closer examination it looks like this application can still be 
given purely declarative semantics from the API consumer's perspective. 
  That's not going to screw up e.g. typing --- particularly not if e.g. 
the implementation of txnprop is further decorated to indicate what 
exceptions are thrown, etc.  It doesn't so much *modify* the behavior 
of create_list from the API consumer's (human or otherwise) perspective 
as it does *declare* what it is.

jb


From dave at boost-consulting.com  Mon Jun 28 14:08:58 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon Jun 28 14:10:23 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<200406251618.38924.fdrake@acm.org>
	<6ee4c83804062513526ea4c4ac@mail.gmail.com>
	<DA7203C0-C6F1-11D8-A9D8-000A95CFE9DE@deepfile.com>
	<ACE2D138-C740-11D8-B553-000A95686CD8@redivi.com>
	<6E63CE63-C77C-11D8-A9D8-000A95CFE9DE@deepfile.com>
	<uzn6na8zn.fsf@boost-consulting.com>
	<D547AE1A-C92A-11D8-9B14-000A95CFE9DE@place.org>
Message-ID: <ud63ja72d.fsf@boost-consulting.com>

Jeff Bone <jbone@place.org> writes:

> NB, I'm no type Nazi.

NB: I am one.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From mchermside at ingdirect.com  Mon Jun 28 14:16:30 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Mon Jun 28 14:16:36 2004
Subject: [Python-Dev] Re: decorators and 2.4
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550AE2@ingdexj1.ingdirect.com>

> I'm really curious what these uses might be.  Folks keep saying this 
> kind of thing, but when you dig in IMHO most of these 
> actually seem to 
> be design-time things, statements *about* the intent or use of the 
> function (relative to the language runtime itself, e.g. 
> classmethod and 
> so forth, or relative to a framework, such as registering a function, 
> or relative to some tool, e.g. for extended documentation purposes or 
> type-checking, etc.) rather than e.g. runtime modifications to its 
> behavior.

Well, perhaps you and I mean slightly different things when we talk
about "declarative" functionality. Here are some uses, you let me
know whether they are "declarative" or not:

  1. Registering with a framework:
    [FooFramework]
    def some_func():
        body()

    FooFramework() "registers" the function with a framework by
    simply adding it to a list of known functions. This allows
    the GUI interface for FooFramework to display the function.

  2. Take actions before or after a call:
    [traceable]
    def some_func():
        body()

    traceable() replaces some_func() with a function which
    may write a log message before and after actually
    invoking the original some_func(). Whether the log
    message is actually written is controlled by a list of
    function names (compared to some_func.__name__) and
    that list may change dynamically while the program is
    executing.

  3. Enforce pre- and post- conditions:
    [precondition(lambda x,y: x<y),
     postcondition(lambda x,y,result: x<result<y)]
    def some_func(x, y):
        body()

    precondition() and postcondition() document what we
    expect to be true before and after a function is 
    invoked. Furthermore, if the constant Contract.PROD
    in the Contract module is False, then they replace
    some_func() with a wrapped version which tests the
    conditions and raises a ContractException if they
    fail.

    (Note: I don't think this is the best design for a
    design-by-contract library, just one approach which
    I think decorators SHOULD make possible.)

  4. Storing Private Data:
    class Some_Class:
        [private]
        def some_method(self, private, x):
            body(self, private, x)

    This is kind of far out, but private() replaces the
    function some_method(self,private,x) with a wrapper
    function some_method(self,x) which takes just TWO 
    arguments. Then the original some_method() is
    invoked with all three arguments, including "private"
    which is a dict that the wrapper conjures up from
    someplace well hidden. This means that the method
    some_method() can have access to the values in the
    "private" dict (and can write values into it also),
    but someone inspecting the __dict__ of the Some_Class
    instance won't be able to find (or change) "private".

There are lots of other good ideas out there (many better
than these), but I'm wondering whether you consider these
to be "declarative".

You follow with a few questions:  

> (1)  Does a function have access to its own decorators?

I wouldn't think so. They are NOT "metadata", that's just
one possible use. The function no more has access to its
decorators than it has access to its source code! If we
just needed a place to stick metadata we'd use the
function's __dict__.

> (2)  Do decorators define literal constant values at 
> design-time or do 
> they define a scope of mutable bindings?

The decorators are simply functions that get executed.

> 	x = "Guido van Rossum"
> 	def mymethod(f) [attrs(versionadded="2.2", author=x)]:

That's fine. author is set to Guido.

> 	x = "Guido van Rossum"
> 	def mymethod(f) [attrs(versionadded="2.2", author=x)]:
>                     oldAuthor = someHandleToMyDecorators.atts.author
> 		someHandleToMyDecorators.atts.author = "Eric Idle"

That's meaningless unless I know what "someHandleToMyDecorators"
means.

> IMHO, the RHS of an "assignment" in a decorator should only be some 
> value that can be known at "compile" time

I disagree. I think you and I just have different ideas about
what we'd use decorators for. (Actually, I think that perhaps
your set of intended uses is a subset of mine.)

> (3)  Should it be possible to conditionally evaluate decorators based 
> on run-time state?
> 
> The following, IMHO, is truly scary and inhibits many of the intended 
> uses of decorators.  This shouldn't be legal, ever:
> 
> if foo = 3:
> 	[someDecoratorThatModifiesBarsRuntimeBehavior]
> else:
> 	[someOtherDecorator]
> def bar(...):
> 	...

Hmm... I hadn't considered that one. I'll reserve judgment.
I wouldn't mind if it worked, but I'd certainly try never to
use it. I *WOULD* however make use of things like this:

    if foo = 3:
        standard_decoration = someDecoratorWithALongName
    else:
        standard_decoration = someOtherDecorator
    # ...
    [standard_decoration]
    def bar(...):
        ...

You write "The following, IMHO, is truly scary and inhibits many
of the intended uses of decorators". I'm not sure that intended
uses it is inhibiting. The only one I can imagine is using
decorators to create a type-aware compiler that generates type-
specific optimized code. I don't think this IS a possible use
for decorators. So... what use *would* be inhibited if 
decorators were used in this manner?

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From barry at python.org  Mon Jun 28 14:34:27 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Jun 28 14:34:18 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <D56CD749-C92D-11D8-9B14-000A95CFE9DE@place.org>
References: <0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<4CA7798A-C923-11D8-9B14-000A95CFE9DE@place.org>
	<1088443171.7466.347.camel@localhost>
	<7C37D21D-C928-11D8-9B14-000A95CFE9DE@place.org>
	<1088444890.7466.351.camel@localhost>
	<D56CD749-C92D-11D8-9B14-000A95CFE9DE@place.org>
Message-ID: <1088447667.7473.372.camel@localhost>

On Mon, 2004-06-28 at 14:06, Jeff Bone wrote:

> Granted.  But let's look at the above.  Now, you're intimately familiar 
> with the current implementation of txnprop, so you think of the above 
> in terms of its literal side-effecting behavior.  But looking at it as 
> a consumer of the interface --- simply as a user reading the code, or 
> as some automated tool which doesn't understand and doesn't necessarily 
> NEED to understand the effect of txnprop, that looks awfully 
> declarative --- doesn't it?  You're in essence saying "the following is 
> a transactional function."

Which is why early on, I favored decorator-after-def syntax, like so:

def [txnprop] create_list(self, listid):

because it read more English-like: "Define a txnprop called create_list
with arguments self and listid".  But I'm definitely not going to give
that poor deceased equine even one more whack.

> So on closer examination it looks like this application can still be 
> given purely declarative semantics from the API consumer's perspective. 
>   That's not going to screw up e.g. typing --- particularly not if e.g. 
> the implementation of txnprop is further decorated to indicate what 
> exceptions are thrown, etc.  It doesn't so much *modify* the behavior 
> of create_list from the API consumer's (human or otherwise) perspective 
> as it does *declare* what it is.

Perhaps, but I haven't followed this thread close enough to know what
point you want to make.  For me, I want the feature with semantics that
are described in the PEP, which are basically equivalent to what the
explicit wrappers can do in Python today.  I think there's fairly
widespread agreement on the semantics, and the only questions open are
which syntax Guido will chose, and what version of Python he'll want to
add this to.  Given the contenders still standing, I don't care about
the former, but I want the latter to be "Python 2.4".

that's-just-me-though-ly y'rs,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040628/f2c9148e/attachment-0001.bin
From jbone at place.org  Mon Jun 28 14:50:06 2004
From: jbone at place.org (Jeff Bone)
Date: Mon Jun 28 14:50:12 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <0CFFADBB825C6249A26FDF11C1772AE1550AE2@ingdexj1.ingdirect.com>
References: <0CFFADBB825C6249A26FDF11C1772AE1550AE2@ingdexj1.ingdirect.com>
Message-ID: <F92BE639-C933-11D8-9B14-000A95CFE9DE@place.org>


On Jun 28, 2004, at 1:16 PM, Chermside, Michael wrote:

>
>   1. Registering with a framework:
>     [FooFramework]
>     def some_func():
>         body()
>
>   2. Take actions before or after a call:
>     [traceable]
>     def some_func():
>         body()
>
>
>   3. Enforce pre- and post- conditions:
>     [precondition(lambda x,y: x<y),
>      postcondition(lambda x,y,result: x<result<y)]
>     def some_func(x, y):
>         body()
>
>
>  4. Storing Private Data:
>     class Some_Class:
>         [private]
>         def some_method(self, private, x):
>             body(self, private, x)
>

All of these have the effect of either "wrapping" the function (i.e., 
can be thought of as higher-order functions that take functions and 
return functions with the same type as the input function) or 
"bracketing" the function call (in the case of your pre- and post.  
Subtly different from the former.)  The former's trivial to deal with, 
semantically;  the latter slightly less so but tractable.

I would say that all such uses --- when the "outer" function doesn't 
impact state or type of the wrapped function, except perhaps to extend 
it (w/, e.g., exceptions, such as potentially in pre- and post-) --- 
can more of less be thought of as "declarative."

(Side note:  were Python to be extended with true anonymous functions, 
this would all be rendered moot;  the result would IMHO be both 
syntactically and semantically clearer.)

> You follow with a few questions:
>
>> (1)  Does a function have access to its own decorators?
>
> I wouldn't think so. They are NOT "metadata", that's just
> one possible use. The function no more has access to its
> decorators than it has access to its source code! If we
> just needed a place to stick metadata we'd use the
> function's __dict__.

+1.  I waffle on this.  In general I'd feel better if functions etc. 
don't have access to their own decorators at runtime, though you can 
make the general argument that introspection is a good thing.

>> (2)  Do decorators define literal constant values at
>> design-time or do
>> they define a scope of mutable bindings?
>
> The decorators are simply functions that get executed.

IMHO, that's one way to think about it.  From what I can tell from the 
discussion, the PEP, and reading between the lines, there are three 
legit uses and a few wacky ones.  The legit and common / consensus ones 
seem to be:

	(1)  Wrap a function w/o impacting its internal runtime scope
	(2)  Provide pre- and post- about a function
	(3)  Provide metadata (despite the claim above, the below is IMHO a 
metadata application.)

>> 	x = "Guido van Rossum"
>> 	def mymethod(f) [attrs(versionadded="2.2", author=x)]:
>
> That's fine. author is set to Guido.

This is bad because it might inhibit typing applications.  Consider 
this from the PEP:

	def func(arg1, arg2) [accepts(int, (int,float)),
                       returns((int,float))]:
    	 return arg1 * arg2

Should I be able to DYNAMICALLY define the type signature of the 
function at runtime?  Consider, say:

	if todayIsThursday():
		mysig = (int, (int, float))
	else:
		mysig = (str, (int, float))
	[accepts(sig)]
	def func(arg1, arg2):
		if todayIsThursday():
			return foo() # foo is (int, (int, float))
		else:
			return bar() # bar is (str, (int, float))

That's worse than useless.  :-/

>> 	x = "Guido van Rossum"
>> 	def mymethod(f) [attrs(versionadded="2.2", author=x)]:
>>                     oldAuthor = someHandleToMyDecorators.atts.author
>> 		someHandleToMyDecorators.atts.author = "Eric Idle"
>
> That's meaningless unless I know what "someHandleToMyDecorators"
> means.

Right, but that's my point.  Dangerous to give the handle in the first 
place,  even more so if you can set things up dynamically based on 
runtime state, much more so if you can mutate those bindings once 
they're set, *particularly* if you can do some from within the scope of 
the thing being decorated.

BTW, call "someHandleToMyDecorators" "self" or "__dict__" and think 
about it...

>> if foo = 3:
>> 	[someDecoratorThatModifiesBarsRuntimeBehavior]
>> else:
>> 	[someOtherDecorator]
>> def bar(...):
>> 	...
>
> Hmm... I hadn't considered that one. I'll reserve judgment.
> I wouldn't mind if it worked, but I'd certainly try never to
> use it. I *WOULD* however make use of things like this:
>
>     if foo = 3:
>         standard_decoration = someDecoratorWithALongName
>     else:
>         standard_decoration = someOtherDecorator
>     # ...
>     [standard_decoration]
>     def bar(...):
>         ...

Ugh.  Slippery slope to #ifdef / macro hell ala Pike et. al.  But even 
worse:  at least #ifdef can be evaluated statically!  :-/

> You write "The following, IMHO, is truly scary and inhibits many
> of the intended uses of decorators". I'm not sure that intended
> uses it is inhibiting. The only one I can imagine is using
> decorators to create a type-aware compiler that generates type-
> specific optimized code. I don't think this IS a possible use
> for decorators. So... what use *would* be inhibited if
> decorators were used in this manner?

Exactly that.  As for that being an anticipated use, it's at least 
implied in the PEP (see above example from the PEP) and indeed 
something I've been fiddling with a bit.

Point in all of this being:  the semantics of decorators are largely 
not defined at this point;  any such description appears to be an 
anecdotal side-effect of the implementations people are playing with 
--- there's certainly no normative description of their intended 
semantics, either in the PEP of elsewhere at this point to my 
knowledge.  IMHO, decorators are a GOOD idea;  but the syntax of 
decorators is in my opinion FAR less of a concern than should be their 
semantics.

jb


From mchermside at ingdirect.com  Mon Jun 28 15:00:32 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Mon Jun 28 15:00:36 2004
Subject: [Python-Dev] Proposal: thread.get_dict
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550AE3@ingdexj1.ingdirect.com>

Armin Rigo writes:
> I am pretty sure that some extension modules would badly 
> crash if arbitrary
> Python code would be allowed to temper with the data that 
> they store there.  

We're all consenting adults here. Tampering with the private
data of an extension module is a well-known way to crash
Python.

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From jim.jewett at eds.com  Mon Jun 28 15:02:37 2004
From: jim.jewett at eds.com (Jewett, Jim J)
Date: Mon Jun 28 15:03:06 2004
Subject: [Python-Dev] Re: decorators and 2.4
Message-ID: <B8CDFB11BB44D411B8E600508BDF076C22955B3C@usahm010.exmi01.exch.eds.com>

Jeff Bone 

> (1)  Does a function have access to its own decorators?
> I expect the answer here should be "yes."  

I don't expect it to have access to the decorators, or 
even to the results of running them -- at least, not any 
more than I expect a function to have access to its own name.  
Conceptually, 

	def funcname(args): ...

is (almost) just a nicer way to write

	funcname=lambda(args) ...

In either case, a function object is created, and then 
"decorated" by binding a name to it.  By analogy,

	[wrap1()]
	def funcname(args): ...

means (almost) the same thing as

	def funcname(args): ...
	funcname=wrap1(funcname)

Functions have no direct access to their own name,
or their decorators, or even the affects of these
decorators.  Recursion works anyhow, because it 
looks the name up in the enclosing namespace. 
[The actual lookup may be short-circuited for
efficiency.]

Decorators may add attributes, or even replace a
function object entirely with something else.  (In
Barry's example, that something else then delegates
back to the original object.)  This doesn't mean that
the function itself needs direct access to those 
attributes (that name), let alone to the decorators 
that created them. 

> (2)  Do decorators define literal constant values 
> at design-time or do they define a scope of mutable
> bindings?

Not either really.  They do post-processing on a
function (or class?) object before binding a name
to it.  This may or may not add attributes which
may or may not be constants.  It may or may not
create a new object with new scopes.

> That seems fine, but what about this:

>	x = "Guido van Rossum"
>	def mymethod(f) [attrs(versionadded="2.2", author=x)]:

attrs is evaluated before the body of mymethod.  Part of that 
evaluation is to properly bind its own author parameter.
This resolves to a constant string, but I agree that using 
a dictionary could allow confusion -- in exactly the same way
that mutable default arguments do today.

> (3)  Should it be possible to conditionally evaluate decorators
> based on run-time state?

At first I misunderstood.  Conditional upon state when the 
function *definition* is evaluated, yes (though maybe not in
the first version).  But that is compile-time.

Conditional upon the call-time state -- no.  The decorators 
themselves may well have been garbage collected by then.  

Note that this does not forbid a decorator that *replaces* 
the original function with another callable object that 
happens to include conditional logic.  The decorator itself
would still be evaluated only once.

-jJ

From janssen at parc.com  Mon Jun 28 15:24:30 2004
From: janssen at parc.com (Bill Janssen)
Date: Mon Jun 28 15:24:54 2004
Subject: [Python-Dev] Re: decorators and 2.4 
In-Reply-To: Your message of "Fri, 25 Jun 2004 22:23:54 PDT."
	<5.1.1.6.0.20040626012303.0287ce40@mail.telecommunity.com> 
Message-ID: <04Jun28.122440pdt."58612"@synergy1.parc.xerox.com>

Yes, it would have to be a 'compile-time' macro of some sort.

Bill

> At 09:47 PM 6/25/04 -0700, Bill Janssen wrote:
> >I could also see the function call version:
> >
> >   from decorators import decorate
> >   ...
> >   def foo (bar):
> >       decorate(bletch, flappy)
> >       ...
> >
> >where decorate is automatically applied to "foo".
> 
> That won't work, since by the time the function is called it's too late to 
> redefine foo.
> 


From janssen at parc.com  Mon Jun 28 15:27:28 2004
From: janssen at parc.com (Bill Janssen)
Date: Mon Jun 28 15:28:06 2004
Subject: [Python-Dev] Re: decorators and 2.4 
In-Reply-To: Your message of "Sat, 26 Jun 2004 10:57:21 PDT."
	<40DDB901.5020100@prescod.net> 
Message-ID: <04Jun28.122735pdt."58612"@synergy1.parc.xerox.com>

Paul, I think you're proving my point.  There's an interesting paper
on www.liveink.com where they claim that one of the problems with
classically formatted text is that the lines above and below the line
that's currently being read make it harder to focus on that line.  To
me, the same seems true in your examples of the @foo decoration
syntax.

Bill

From pje at telecommunity.com  Mon Jun 28 16:11:03 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon Jun 28 16:08:21 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <4CA7798A-C923-11D8-9B14-000A95CFE9DE@place.org>
References: <0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
Message-ID: <5.1.1.6.0.20040628160522.031f70a0@mail.telecommunity.com>

At 11:50 AM 6/28/04 -0500, Jeff Bone wrote:
>I wouldn't keep pushing on this except that I'm entirely puzzled about 
>what these legitimate "runtime" applications might be that aren't already 
>more easily and clearly accomplished with existing mechanisms:
>arguments, lexical scope, and higher-order functions.

I've already said this several times, and PEP 318 says it too: PEP 318 
seeks a *syntax* that allows those "existing mechanisms" to be invoked at 
the *beginning of a function definition*.  That is 
all.  Period.  Finito.  End of story.

So, to talk about applying restrictions to what behavior is allowed for 
decorators, is to completely miss the point of PEP 318.  Please re-read PEP 
318's "Motivation" section.


From jbone at place.org  Mon Jun 28 17:29:31 2004
From: jbone at place.org (Jeff Bone)
Date: Mon Jun 28 17:29:36 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <5.1.1.6.0.20040628160522.031f70a0@mail.telecommunity.com>
References: <0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<5.1.1.6.0.20040628160522.031f70a0@mail.telecommunity.com>
Message-ID: <3E0694CA-C94A-11D8-9B14-000A95CFE9DE@place.org>


On Jun 28, 2004, at 3:11 PM, Phillip J. Eby wrote:

> So, to talk about applying restrictions to what behavior is allowed 
> for decorators, is to completely miss the point of PEP 318.  Please 
> re-read PEP 318's "Motivation" section.

Phil, with all due respect, there's no need to get peevish.  I've read 
PEP 318 several times, and I think you're missing my point *about the 
PEP.*

You'll note that I'm not disagreeing with the desirability of 
decorators nor any of the use cases in the PEP nor any given proposed 
syntax.  I'm concerned that treating this as simple syntactic sugar w/o 
a bit more precision about impact on evaluation and on scope might 
actually impair the ability to use decorators for (at least some of) 
their intended purposes.  The PEP only implies semantics (by saying 
"it's just syntactic shorthand for things like...") --- and that 
implied semantics is in fact inconsistent with at least one of the 
implied desiderata.

Note too that an explicit design goal of the PEP is:

	* not make future extensions more difficult

If you allow conditional evaluation or parameterization of decorators 
w/o some consideration about their impact on static type analysis --- 
as in the nightmare scenario I offered previously --- AND if you 
believe that adding some optional static typing and type analysis to 
Python in the future is at least possibly desirable, then it leads one 
to consider whether additional constraints  *might* be in order.  E.g. 
if evaluation of decorators proceeds "at runtime" then we can forget 
all ideas of using them for any sort of static code analysis which, if 
you noticed, *is* one of the examples from the PEP.  (That would be the 
"Examples" section, ahem. ;-)


jb

Footnote, aside, more of an anecdotal cautionary tale than anything 
else:

Today the following happens:

> >>> def bar():
> ...    x = 3
> ...    foo()
> ...
> >>> def foo():
> ...    print x
> ...
> >>> bar()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "<stdin>", line 3, in bar
>   File "<stdin>", line 2, in foo
> NameError: global name 'x' is not defined
> >>>

This is as it should be.  Decorators shouldn't have an impact on 
variables that occur free in decorated bodies.  This is an example of 
the lack of clarity in the spec;  you can argue that it's implicit that 
this kind of behavior should be preserved, but IMHO that's more a 
function of some implied understanding of the implementation than it is 
any specification of something that the language should or should not 
do.  (And such problems lead early Lisp to have effed up scoping rules 
for so long that old Lisp hands can't even agree on whether it was a 
feature or a bug. ;-)


From arigo at tunes.org  Mon Jun 28 18:08:14 2004
From: arigo at tunes.org (Armin Rigo)
Date: Mon Jun 28 18:10:45 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <0CFFADBB825C6249A26FDF11C1772AE1550AE3@ingdexj1.ingdirect.com>
References: <0CFFADBB825C6249A26FDF11C1772AE1550AE3@ingdexj1.ingdirect.com>
Message-ID: <20040628220814.GA8618@vicky.ecs.soton.ac.uk>

Hello Michael,

On Mon, Jun 28, 2004 at 03:00:32PM -0400, Chermside, Michael wrote:
> > I am pretty sure that some extension modules would badly 
> > crash if arbitrary
> > Python code would be allowed to temper with the data that 
> > they store there.  
> 
> We're all consenting adults here. Tampering with the private
> data of an extension module is a well-known way to crash
> Python.

Is it?  I am not aware of any such example in the standard library.  I am sure
that it would be considered as a bug.  The only (internal and expected) ways
to crash the Python interpreter from Python are currently to abuse new.code()
or gc.getreferents().  If an extension module allows this kind of tampering
from Python code I'd consider it poorly written.


Armin

From arigo at tunes.org  Mon Jun 28 18:29:54 2004
From: arigo at tunes.org (Armin Rigo)
Date: Mon Jun 28 18:32:24 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <40E05AE2.1080608@zope.com>
References: <40E03020.7010101@zope.com>
	<20040628161619.GA14187@vicky.ecs.soton.ac.uk>
	<40E05AE2.1080608@zope.com>
Message-ID: <20040628222954.GB8618@vicky.ecs.soton.ac.uk>

Hello Jim,

On Mon, Jun 28, 2004 at 01:52:34PM -0400, Jim Fulton wrote:
> AFAIK, only one bit of extension code uses this data.

I mean, arbitrary extension modules outside of the standard library.  We can
make sure that all extension modules within the standard library are safe
against such tampering, of course, but still we'd have to document this new
backdoor to extension writers so that they can fix their extension modules for
2.4 if they care.  This can be considered as a backwards-incompatible change
for extension writers.  I have sometimes used this dict from an extension
module and adding new checks there would also defeat the purpose, which was
also performance.

> But, of course, applications that use this data would have to
> be disciplined about picking keys to avoid conflict.

I am sure this is not a problem.  I'd advocate using fresh instances of
'object' as keys instead of strings, which is even safer.

> This is a fine idea, but I think a simpler mechanism will work
> just as well and avoid the extra dictionary lookup that your suggestion
> introduces.  I have an application in which these lookups will be done a
> lot and I want to minimize overhead.

Then it might be faster to have dedicated operations:

  thread.setlocal(key, value)
  thread.getlocal(key)

They are a single operation (instead of two in thread.getlocals()[key]) and
they are safer because you don't see the dictionary directly.  I'd be
perfectly happy if 'key' was actually restricted to be exactly of type
'object', which guarantees that nothing bad can occur with the dict, but I can
live without that if the danger is properly documented :-)


A bientot,

Armin.

From janssen at parc.com  Mon Jun 28 20:18:52 2004
From: janssen at parc.com (Bill Janssen)
Date: Mon Jun 28 20:19:29 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings 
In-Reply-To: Your message of "Fri, 25 Jun 2004 22:02:37 PDT."
	<1f7befae0406252202d8358f1@mail.gmail.com> 
Message-ID: <04Jun28.171901pdt."58612"@synergy1.parc.xerox.com>

> That raises an exception.  Did you intend "BBB" as the format string?

Yes, I meant 'struct.pack("BBB", 0xFF, 0x00, 0x83)'.

Tim, do I understand then that Unicode strings have an implicit
character encoding, but non-Unicode strings do not?

Bill

From tim.peters at gmail.com  Mon Jun 28 20:53:32 2004
From: tim.peters at gmail.com (Tim Peters)
Date: Mon Jun 28 20:53:35 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <-2244066597517672269@unknownmsgid>
References: <-2244066597517672269@unknownmsgid>
Message-ID: <1f7befae0406281753142a3b22@mail.gmail.com>

[Bill Janssen]
> Tim, do I understand then that Unicode strings have an implicit
> character encoding, but non-Unicode strings do not?

An 8-bit string is a sequence of 8-bit bytes.  If those bytes are to
"mean something", you have to supply the meaning, or use them in a
context that supplies a specific meaning for you.  This seems nearly
impossible for an American to understand, but non-Americans appear to
know it at birth (if not earlier).

A Unicode string is, at least in theory, a sequence of Unicode
characters, the latter defined in excruciating detail by the Unicode
Consortium.  There's no conventional sense in which a Unicode string
is an encoding of something other than exactly itself, but you could
certainly make one up.

From pje at telecommunity.com  Mon Jun 28 22:05:01 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon Jun 28 22:02:12 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <3E0694CA-C94A-11D8-9B14-000A95CFE9DE@place.org>
References: <5.1.1.6.0.20040628160522.031f70a0@mail.telecommunity.com>
	<0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<5.1.1.6.0.20040628160522.031f70a0@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20040628214724.030c1890@mail.telecommunity.com>

At 04:29 PM 6/28/04 -0500, Jeff Bone wrote:
>If you allow conditional evaluation or parameterization of decorators w/o 
>some consideration about their impact on static type analysis --- as in 
>the nightmare scenario I offered previously --- AND if you believe that 
>adding some optional static typing and type analysis to Python in the 
>future is at least possibly desirable, then it leads one to consider 
>whether additional constraints  *might* be in order.

No, it doesn't.  You can already make weird decorators that disassemble the 
bytecode of the function and create a new function object, for 
example.  PEP 318 does nothing to change that fact.  Thus, attempting to 
define restrictions for them is moot, as far as anybody attempting to 
create program analysis tools -- they already have to deal with this 
dynamism today, and restricting PEP 318 simply won't help.


>   E.g. if evaluation of decorators proceeds "at runtime" then we can 
> forget all ideas of

For all practical purposes, Python doesn't have any time *other* than 
runtime.  Any analysis tool that doesn't recognize this is going to have a 
hard time making sense out of Python code.  As a simple example:

     try:
         from lib1 import SomeClass
     except ImportError:
         from lib2 import SomeClass

     class MyClass(SomeClass):
         """My stuff here"""

So, what class does 'MyClass' inherit from, here?  Note that this is 
perfectly legal Python, and I've certainly written the equivalent of it 
more than once or twice.  So if this be the stuff of nightmares, please 
don't try to wake me up.  :)


>using them for any sort of static code analysis which, if you noticed, 
>*is* one of the examples from the PEP.  (That would be the "Examples" 
>section, ahem. ;-)

To which example are you referring?  Type constraints?  That's not static 
code analysis, that's code generation.  Interfaces?  That's 
registration.  Neither has anything to do with static code analysis, AFAICT.


>This is as it should be.  Decorators shouldn't have an impact on variables 
>that occur free in decorated bodies.  This is an example of the lack of 
>clarity in the spec;

If that's true, then the Python language reference is unclear because it 
doesn't say that you mustn't use higher-order functions to change the 
behavior of other functions.


From jbone at place.org  Tue Jun 29 03:04:13 2004
From: jbone at place.org (Jeff Bone)
Date: Tue Jun 29 03:04:21 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <5.1.1.6.0.20040628214724.030c1890@mail.telecommunity.com>
References: <5.1.1.6.0.20040628160522.031f70a0@mail.telecommunity.com>
	<0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<0CFFADBB825C6249A26FDF11C1772AE1550ADE@ingdexj1.ingdirect.com>
	<5.1.1.6.0.20040628160522.031f70a0@mail.telecommunity.com>
	<5.1.1.6.0.20040628214724.030c1890@mail.telecommunity.com>
Message-ID: <86E1E62A-C99A-11D8-9B14-000A95CFE9DE@place.org>


On Jun 28, 2004, at 9:05 PM, Phillip J. Eby wrote:

> At 04:29 PM 6/28/04 -0500, Jeff Bone wrote:
>> If you allow conditional evaluation or parameterization of decorators 
>> w/o some consideration about their impact on static type analysis --- 
>> as in the nightmare scenario I offered previously --- AND if you 
>> believe that adding some optional static typing and type analysis to 
>> Python in the future is at least possibly desirable, then it leads 
>> one to consider whether additional constraints  *might* be in order.
>
> No, it doesn't.

Yes, it does --- as the examples offered indicate.				
> You can already make weird decorators that disassemble the bytecode of 
> the function and create a new function object, for example.  PEP 318 
> does nothing to change that fact.

True, but irrelevant unless you happen to be strategically myopic and 
slightly programming-language illiterate.  Tell me, Phil --- what is 
your damage here?  I believe we both want the same outcome.  So why are 
you getting so aggressive (or defensive, I can't tell which) about the 
route to the particular, and shared, outcome?  As surely as I'm 
convinced about the need for and worthiness of certain considerations 
about static type-checking and the future of this language, I'm willing 
to grant that you're equally concerned about something else, even 
though I don't yet know what.  Why can't we have the discussion on that 
factual basis instead of bogus third-hand references to the 
questionable intent (though somewhat clear, but still questionable 
relative to desiderata) of a spec you didn't write?

The only legit explanation I can think of is that *you know how to 
implement the PEP as you understand it now, but fail to understand the 
longer-term implications of said interpretation of PEP / 
implementation."  Take the time to connect w/ me or others on these 
concerns;  I think you will find them not entirely out of sync.  I may 
not have posted here much over the years, but I'm sure both I and 
countless others have put in the time to get the hearing for our 
concerns w/o being swatted down w/ an inconclusive spec like and 
ignorant school-marm swatting an overly-inquisitive 2nd-grader.

> Thus, attempting to define restrictions for them is moot,

No, it's not -- as demonstrated previously.

> as far as anybody attempting to create program analysis tools -- they 
> already have to deal with this dynamism today, and restricting PEP 318 
> simply won't help.

What a completely BS response.

Yet --- true, but only if one accepts a particular and rather 
simple-minded and overly-literal interpretation of the ***GOALS*** of 
PEP 318, driven by hackers that are inclined to hack certain changes 
into THE (and that in itself is an indictment) implementation of the 
language --- changes that that are very lightly implied by the PEP into 
the interpreter, rather than considering the longer-term goals and 
objectives of both the PEP and the language.  And THAT IS MY POINT.

jb
CTO, Deepfile


From gmccaughan at synaptics-uk.com  Tue Jun 29 06:50:29 2004
From: gmccaughan at synaptics-uk.com (Gareth McCaughan)
Date: Tue Jun 29 06:51:05 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <86E1E62A-C99A-11D8-9B14-000A95CFE9DE@place.org>
References: <5.1.1.6.0.20040628160522.031f70a0@mail.telecommunity.com>
	<5.1.1.6.0.20040628214724.030c1890@mail.telecommunity.com>
	<86E1E62A-C99A-11D8-9B14-000A95CFE9DE@place.org>
Message-ID: <200406291150.29915.gmccaughan@synaptics-uk.com>

On Tuesday 2004-06-29 08:04, Jeff Bone wrote:

[Philip Eby:]
>> You can already make weird decorators that disassemble the bytecode of 
>> the function and create a new function object, for example.  PEP 318 
>> does nothing to change that fact.

[Jeff:]
> True, but irrelevant unless you happen to be strategically myopic and 
> slightly programming-language illiterate.  Tell me, Phil --- what is 
> your damage here?  I believe we both want the same outcome.  So why are 
> you getting so aggressive (or defensive, I can't tell which) about the 
> route to the particular, and shared, outcome?

Excuse me, but when you're implying that Philip is "strategically
myopic and slightly programming-language illiterate" and asking
"what is your damage?" and calling his comments "bullshit" and
likening him to "an ignorant school-marm", you are not in a great
position to take the moral high ground about being either "aggressive"
or "defensive".

>                                                As surely as I'm 
> convinced about the need for and worthiness of certain considerations 
> about static type-checking and the future of this language, I'm willing 
> to grant that you're equally concerned about something else, even 
> though I don't yet know what.  Why can't we have the discussion on that 
> factual basis instead of bogus third-hand references to the 
> questionable intent (though somewhat clear, but still questionable 
> relative to desiderata) of a spec you didn't write?

This topic has already been extensively discussed in python-dev.
It is not, in fact, questionable whether the intent of the spec
is to permit a broader range of operations on functions than you
think desirable. It is.

> The only legit explanation I can think of is that *you know how to 
> implement the PEP as you understand it now, but fail to understand the 
> longer-term implications of said interpretation of PEP / 
> implementation."

Please consider the possibility that other people may understand
your concerns but disagree with them. Being unable to read Philip's
mind, I don't know whether that's his situation, but it certainly
seems plausible to me.

                                *

Let's rewind a bit here. Unless my mail archives are broken,
your first entry into this discussion was when you declared
that "Decorators are metadata about the function to which they
refer.". Not "it would be preferable to restrict decorators to
[etc]" -- not, that is, a statement about what sort of
decoration ought to be done, or ought to be permitted,
but a statement about what decorators *are*.

Now, doubtless analytic philosophers could spend hours arguing
about what it actually means to make such a statement when
decorators aren't currently part of the language spec. But
it seems reasonable to me to take their meaning to be defined
by some combination of (1) the PEP that proposes their introduction,
(2) the discussion that preceded and followed the writing of
that PEP, and (3) the actual implementations people have produced.
And, according to all three of those, your statement about what
decorators are is, simply, not true. And as long as you're making
statements about what decorators *are* it seems entirely
appropriate for Philip, or anyone else, to point you to the
nearest thing we have to a definition of decorators in Python
when you say something that just ain't so.

Now, certainly, it's also reasonable to discuss what decorators
*should* be, and I think that's what you actually intend in this
thread.

So, your main argument is that decorations should be "declarative".
Unfortunately, it isn't clear to me quite what you mean by
"declarative"; from your response to Michael Chermside's and
Barry Warsaw's examples, it appears that you want to define
it at a rather high level of abstraction -- but at a high enough
level of abstraction (doubtless higher than you have in mind)
*anything* can be construed as "declarative" :-), and it's not
obvious to me where your boundaries are.

So, let me make a proposition that I haven't yet seen anything
to refute:

    It is good for decorators to be, in some sufficiently
    high-level sense, "declarative". However, at that level,
    the meaning of "declarative" is broad enough that any
    mechanism that enables the full range of desirable,
    "declarative" decorators will also enable the "non-declarative"
    uses that you deplore. There is no Python-level restriction
    (such as "no functions" or "nothing that looks like functions")
    agree are legitimate, and prevent (or even discourage) the
    uses of which you disapprove.

I'm willing to guess that you don't agree with that proposition.
Would you care to offer some evidence against it?

Here are a couple of more specific comments you've made:

    "Using the same syntax for decorators as for functions
    conceptually weakens this distinction and encourages
    misuse of decorators, even to the point of potentially
    encouraging (or implying) side-effects as a result of
    decoration."

It's not clear to me what you mean by "using the same
syntax for decorators as for functions", and the context
in the thread doesn't help. Could you explain in what
way the existing proposals use the same syntax for
decorators as for functions, and how you think that
should be changed?

    "To the extent that decorators either (a) are evaluated
    conditionally based on runtime state, or (b) modify and
    are in turn modified by runtime state, decorators as
    mutable environments or with true side effects make a
    mess of that."

So presumably you would like the decoration mechanism
to prevent, or at least discourage, decorators that
"modify and are in turn modified by runtime state".
But at the implementation level, *everything* in Python
is runtime state. Changing a function's docstring is a
modification of runtime state. Presumably, then, you have
some more abstract notion of what is "runtime state" and
what isn't. But I can't tell what it is. Can you explain?

-- 
g


From mchermside at ingdirect.com  Tue Jun 29 08:41:11 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Tue Jun 29 08:41:16 2004
Subject: [Python-Dev] Proposal: thread.get_dict
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550AE5@ingdexj1.ingdirect.com>

I wrote:
> > We're all consenting adults here. Tampering with the private
> > data of an extension module is a well-known way to crash
> > Python.

Armin replies:
> Is it?  I am not aware of any such example in the standard 
> library.  I am sure
> that it would be considered as a bug.  The only (internal and 
> expected) ways
> to crash the Python interpreter from Python are currently to 
> abuse new.code()
> or gc.getreferents().  If an extension module allows this 
> kind of tampering
> from Python code I'd consider it poorly written.

As I had always understood it, we go to great lengths to ensure
that Python itself and the standard library are as robust as
possible and nearly impossible to crash. However, extension
authors, by definition, are writing *extensions* and are not
under the supervision of the Python development team. It is, of
course, trivial to write an extension which will (intentionally)
crash Python, and just as easy to (unintentionally) write one 
with a flaw which allows crashes. Thus, I have always understood
that as soon as you use an extension, Python no longer offers
any guaranties.

Of course, the author of the EXTENSION may offer such a guarantee.
Depending on who it is, and how widely-used and well-tested the
extension is, you may choose to trust such a guarantee. But I've
always thought that was separate from Python's promise of "no 
crashes".

As for handling this particular issue, I agree with your suggestion:
> I'd advocate using fresh instances of
> 'object' as keys instead of strings, which is even safer.

Good advice for extension authors AND for pure-python writers
whenever they don't want their values tramped on. Of course,
one can still call keys() on the dictionary to obtain the key
if one is *trying* to break (or monkeypatch) the extension,
but that's where I think the "consenting adults" rule applies.

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From mchermside at ingdirect.com  Tue Jun 29 08:44:28 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Tue Jun 29 08:44:32 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550AE6@ingdexj1.ingdirect.com>

Tim Peters writes:
> A Unicode string is, at least in theory, a sequence of Unicode
> characters, the latter defined in excruciating detail by the Unicode
> Consortium.  There's no conventional sense in which a Unicode string
> is an encoding of something other than exactly itself, but you could
> certainly make one up.

I, for one, have always preferred to interpret a string as it's
rot-13 equivalent.

"import this; this.s" -lly yours,

Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From ajm at flonidan.dk  Tue Jun 29 08:45:54 2004
From: ajm at flonidan.dk (Anders J. Munch)
Date: Tue Jun 29 08:46:05 2004
Subject: [Python-Dev] Re-raise in absence of an "active" exception
Message-ID: <6D9E824FA10BD411BE95000629EE2EC3C6DE0E@FLONIDAN-MAIL>

"Martin v. L?wis" [mailto:martin@v.loewis.de] wrote:
> 
> I'm actually surprised that the exception is cleared when the
> function that has the exception handler completes. Where does that
> happen? The current exception is in the thread state, not in the
> frame, after all.

eval_frame calls set_exc_info and reset_exc_info to do a save/restore
to the frame object.

Effectively there's a stack of exceptions, but since it's bound to
frames interesting cases like this occur:

try:
    point_A
except:
    try:
        point_B
    except:
        pass
    raise

==> NameError: name 'point_B' is not defined

(Refugees from C++ might expect the 'point_A' exception instead.)

Method extraction brings the frame object into play for a different
result:

def b():
    try:
        point_B
    except:
        pass
try:
    point_A
except:
    b()
    raise

==> NameError: name 'point_A' is not defined

- Anders

From jbone at place.org  Tue Jun 29 08:55:34 2004
From: jbone at place.org (Jeff Bone)
Date: Tue Jun 29 08:55:43 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <200406291150.29915.gmccaughan@synaptics-uk.com>
References: <5.1.1.6.0.20040628160522.031f70a0@mail.telecommunity.com>
	<5.1.1.6.0.20040628214724.030c1890@mail.telecommunity.com>
	<86E1E62A-C99A-11D8-9B14-000A95CFE9DE@place.org>
	<200406291150.29915.gmccaughan@synaptics-uk.com>
Message-ID: <9C12EE2E-C9CB-11D8-9B14-000A95CFE9DE@place.org>


On Jun 29, 2004, at 5:50 AM, Gareth McCaughan wrote:

> Excuse me, but when you're implying that Philip is "strategically
> myopic and slightly programming-language illiterate" and asking
> "what is your damage?" and calling his comments "bullshit" and
> likening him to "an ignorant school-marm", you are not in a great
> position to take the moral high ground about being either "aggressive"
> or "defensive".

Sorry, yes, you're correct.  I apologize to Phil and the list.  It's 
just rather frustrating to get beat all to hell (and told patronizingly 
to "read" a freakin' PEP I've read, repeatedly, before even speaking 
up) for no apparent reason just for raising what IMHO are rather 
legitimate concerns.

My bad, I'll go back to lurk and if this particular feature turns out 
to be the giant hairball it appears to be I won't say anything.

:-/

jb


From mchermside at ingdirect.com  Tue Jun 29 08:55:53 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Tue Jun 29 08:55:57 2004
Subject: [Python-Dev] Re: decorators and 2.4
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550AE7@ingdexj1.ingdirect.com>

Jeff Bone writes:
> I would say that all such uses --- when the "outer" function doesn't 
> impact state or type of the wrapped function, except perhaps to extend 
> it (w/, e.g., exceptions, such as potentially in pre- and post-) --- 
> can more of less be thought of as "declarative."

Since one of my examples specifically included modifying the parameter
list of the decorated function, I'm a little puzzled by what you
mean by "doesn't impact state or type of the wrapped function". But
what IS clear to me is that your definition of "declarative" and
mine are different. Okay... I can live with that.


After careful reading of your responses to me and to Phillip, I have
concluded (rightly or wrongly) that the real core we are arguing about
here is whether or not decorators should be restricted in ways that
would help with static type analysis of Python code. But although I
happen to be a static-typing fan (a scary thing to admit in THIS
newsgroup), I do NOT believe that static typing (in general) is
possible in Python (StarKiller notwithstanding). I don't think we're
risking breaking something here that isn't already very, VERY broken.
The fact that it is ALREADY possible to achieve the same ends by
rebinding the function after declaring it proves as much.

So, unless you can give me an argument I understand OTHER than static
type analysis, I'm going to go ahead and conclude that I just
disagree with you here and that we've likely learned as much from
each other as we are likely to for the moment.

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From mchermside at ingdirect.com  Tue Jun 29 09:07:41 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Tue Jun 29 09:07:46 2004
Subject: [Python-Dev] Re: decorators and 2.4
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550AE8@ingdexj1.ingdirect.com>

> Sorry, yes, you're correct.  I apologize to Phil and the list.  It's 
> just rather frustrating to get beat all to hell (and told 
> patronizingly 
> to "read" a freakin' PEP I've read, repeatedly, before even speaking 
> up) for no apparent reason just for raising what IMHO are rather 
> legitimate concerns.
> 
> My bad, I'll go back to lurk and if this particular feature turns out 
> to be the giant hairball it appears to be I won't say anything.

Hey... don't be afraid to speak up -- it's a good idea to challenge
ideas around here. It's just that in this case most of the people
who are speaking up don't seem to be swayed by your points. But
that doesn't mean it isn't useful. For example, when Gareth said
that you were trying to "define [declarative] at a rather high level
of abstraction", I finally began to understand (I hope) what you
were trying to convey with the term. Interesting... I had always
thought of "declarative" and "imperative" as having a very clear
boundary, but in fact, they can be looked at from a "higher level".
So if nothing else, you've educated me a bit. It's just that you
haven't convinced me that restricting decorators is wise, and once
folks (on either side) descend to ad hominem attacks it's time to
drop the subject.

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From jim at zope.com  Tue Jun 29 09:44:27 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Jun 29 09:44:32 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <20040628222954.GB8618@vicky.ecs.soton.ac.uk>
References: <40E03020.7010101@zope.com>
	<20040628161619.GA14187@vicky.ecs.soton.ac.uk>
	<40E05AE2.1080608@zope.com>
	<20040628222954.GB8618@vicky.ecs.soton.ac.uk>
Message-ID: <40E1723B.7080604@zope.com>

Armin Rigo wrote:
> Hello Jim,
> 
> On Mon, Jun 28, 2004 at 01:52:34PM -0400, Jim Fulton wrote:
> 
>>AFAIK, only one bit of extension code uses this data.
> 
> 
> I mean, arbitrary extension modules outside of the standard library.  We can
> make sure that all extension modules within the standard library are safe
> against such tampering, of course, but still we'd have to document this new
> backdoor to extension writers so that they can fix their extension modules for
> 2.4 if they care.  This can be considered as a backwards-incompatible change
> for extension writers.  I have sometimes used this dict from an extension
> module and adding new checks there would also defeat the purpose, which was
> also performance.

Fair enough.  I think your concern is definately valid.

>>But, of course, applications that use this data would have to
>>be disciplined about picking keys to avoid conflict.
> 
> 
> I am sure this is not a problem.  I'd advocate using fresh instances of
> 'object' as keys instead of strings, which is even safer.

Yes

> 
>>This is a fine idea, but I think a simpler mechanism will work
>>just as well and avoid the extra dictionary lookup that your suggestion
>>introduces.  I have an application in which these lookups will be done a
>>lot and I want to minimize overhead.
> 
> 
> Then it might be faster to have dedicated operations:
> 
>   thread.setlocal(key, value)
>   thread.getlocal(key)
> 
> They are a single operation (instead of two in thread.getlocals()[key]) and
> they are safer because you don't see the dictionary directly.  I'd be
> perfectly happy if 'key' was actually restricted to be exactly of type
> 'object', which guarantees that nothing bad can occur with the dict, but I can
> live without that if the danger is properly documented :-)

I think this is definately an improvement. I like the idea of restricting the
keys to object instances. The names should have _s to be consistent with other
thread-module names.  I also think that the names should stand alone, so that they
are meaningful without accessing them through the thread module.

How about:

   get_thread_variable(key)
   set_thread_variable(key, value)

where key's class must be object?

Note that get_thread_variable will accept a second argument to specify
a default. If no default is specified and the key is not found, then
a KeyError is raised.

I have to say that I *really* like your suggestion of the thread.local
object.  I'm not sure the elegance isn't worth the extra dictionary lookup.
Actually, for most apps, the elegance is more than worth the extra dictionary
lookup.  I'm gonna do some more investigation of this to see if I can estimate
the impact of the extra lookup on what I'm doing.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org



From pje at telecommunity.com  Tue Jun 29 09:49:14 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue Jun 29 09:46:24 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <9C12EE2E-C9CB-11D8-9B14-000A95CFE9DE@place.org>
References: <200406291150.29915.gmccaughan@synaptics-uk.com>
	<5.1.1.6.0.20040628160522.031f70a0@mail.telecommunity.com>
	<5.1.1.6.0.20040628214724.030c1890@mail.telecommunity.com>
	<86E1E62A-C99A-11D8-9B14-000A95CFE9DE@place.org>
	<200406291150.29915.gmccaughan@synaptics-uk.com>
Message-ID: <5.1.1.6.0.20040629094249.030d58d0@mail.telecommunity.com>

At 07:55 AM 6/29/04 -0500, Jeff Bone wrote:
>Sorry, yes, you're correct.  I apologize to Phil and the list.  It's just 
>rather frustrating to get beat all to hell (and told patronizingly to 
>"read" a freakin' PEP I've read, repeatedly, before even speaking up) for 
>no apparent reason just for raising what IMHO are rather legitimate concerns.

I merely suggested that you review the PEP and discussions, because the 
concerns you were trying to bring up have been rehashed on Python-Dev about 
six or seven times over the lifetime of the PEP, to the best of my 
recollection.  Also if I recall correctly, Guido weighed in on at least one 
or two of those threads pointing out that there was not going to be any 
practical restriction put on decorators, even if some uses might be 
considered a bit gauche.

I'm sorry if you took my suggestion as implying anything more than 
that.  However, such was not my intention.


From amk at amk.ca  Tue Jun 29 10:24:17 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Tue Jun 29 10:24:24 2004
Subject: [Python-Dev] SHA-256 module
Message-ID: <20040629142417.GA7223@rogue.amk.ca>

Patch #935454 is a module implementing SHA-256, a variant of the
160-bit SHA algorithm supported in Python's existing sha module.
Though it's more recent than the original SHA-160, SHA-256 is just as
"standard"; both algorithms are specified by a NIST document.

The submitter comments:

	The difference is that it produces a 256 bit hash value,
	instead of a 160 bit hash value. SHA-256 thus has 128 bits of
	resistance against birthday attacks, which makes it secure in
	certain protocols where SHA-1 is questionable (e.g.  digital
	signatures; or RNGs or Key-Derivation Functions where you want
	to produce keys for 256-bit ciphers).

A quick skim over the code doesn't turn up any issues, and the patch
includes a test suite but no documentation.  I don't want to do a
detailed code review or require docs from the submitter if the module
isn't likely to be included, so do we want to add this module?

There are a bunch of other variants with different bit sizes such as
512, 384, and 224 bits.  The only one likely to matter is SHA-512, so
adding sha256 might mean that down the road we need to add a sha512
module, too, but that seems unlikely.

--amk


From fdrake at acm.org  Tue Jun 29 10:35:53 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue Jun 29 10:36:24 2004
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Doc/api
	exceptions.tex, 1.18, 1.19
In-Reply-To: <E1BfJ22-0005iu-G1@sc8-pr-cvs1.sourceforge.net>
References: <E1BfJ22-0005iu-G1@sc8-pr-cvs1.sourceforge.net>
Message-ID: <200406291035.53295.fdrake@acm.org>

On Tuesday 29 June 2004 09:52 am, akuchling@users.sourceforge.net wrote:
 > [Bug #948970] Add PyExc_* symbols to index.
 > (I ran this through texcheck, but don't have LaTeX installed on this
 > machine and therefore haven't verified that the changes are accepted by
 > LaTeX.)

Thanks; this works just fine.


  -Fred

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


From arigo at tunes.org  Tue Jun 29 11:04:34 2004
From: arigo at tunes.org (Armin Rigo)
Date: Tue Jun 29 11:07:07 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <40E1723B.7080604@zope.com>
References: <40E03020.7010101@zope.com>
	<20040628161619.GA14187@vicky.ecs.soton.ac.uk>
	<40E05AE2.1080608@zope.com>
	<20040628222954.GB8618@vicky.ecs.soton.ac.uk>
	<40E1723B.7080604@zope.com>
Message-ID: <20040629150434.GA1772@vicky.ecs.soton.ac.uk>

Hello Jim,

On Tue, Jun 29, 2004 at 09:44:27AM -0400, Jim Fulton wrote:
> I have to say that I *really* like your suggestion of the thread.local
> object.  I'm not sure the elegance isn't worth the extra dictionary lookup.

We may have the best of both world by providing a pure Python implementation
of class Local.  If you want performance then you use [gs]et_thread_local.

For convenience, we should consider setdefault_thread_local() too...


Armin

From arigo at tunes.org  Tue Jun 29 11:10:22 2004
From: arigo at tunes.org (Armin Rigo)
Date: Tue Jun 29 11:12:54 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <20040629142417.GA7223@rogue.amk.ca>
References: <20040629142417.GA7223@rogue.amk.ca>
Message-ID: <20040629151022.GB1772@vicky.ecs.soton.ac.uk>

Hello,

On Tue, Jun 29, 2004 at 10:24:17AM -0400, A.M. Kuchling wrote:
> There are a bunch of other variants with different bit sizes such as
> 512, 384, and 224 bits.  The only one likely to matter is SHA-512, so
> adding sha256 might mean that down the road we need to add a sha512
> module, too, but that seems unlikely.

We may consider whether adding, over time, a bunch of modules named shaXXX 
doesn't mean we should start thinking about a way to group all these 
algorithms into a single module.


Armin

From barry at python.org  Tue Jun 29 11:22:40 2004
From: barry at python.org (Barry Warsaw)
Date: Tue Jun 29 11:22:29 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <20040629151022.GB1772@vicky.ecs.soton.ac.uk>
References: <20040629142417.GA7223@rogue.amk.ca>
	<20040629151022.GB1772@vicky.ecs.soton.ac.uk>
Message-ID: <1088522559.7523.105.camel@localhost>

On Tue, 2004-06-29 at 11:10, Armin Rigo wrote:

> On Tue, Jun 29, 2004 at 10:24:17AM -0400, A.M. Kuchling wrote:
> > There are a bunch of other variants with different bit sizes such as
> > 512, 384, and 224 bits.  The only one likely to matter is SHA-512, so
> > adding sha256 might mean that down the road we need to add a sha512
> > module, too, but that seems unlikely.

+1

> We may consider whether adding, over time, a bunch of modules named shaXXX 
> doesn't mean we should start thinking about a way to group all these 
> algorithms into a single module.

+1

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040629/e1f8fea8/attachment.bin
From trevp at trevp.net  Tue Jun 29 11:55:08 2004
From: trevp at trevp.net (Trevor Perrin)
Date: Tue Jun 29 11:55:59 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <20040629142417.GA7223@rogue.amk.ca>
Message-ID: <5.2.0.9.0.20040629083940.029122b8@pop.sbcglobal.yahoo.com>

At 10:24 AM 6/29/2004 -0400, A.M. Kuchling wrote:
>Patch #935454 is a module implementing SHA-256, a variant of the
>160-bit SHA algorithm supported in Python's existing sha module.
[...]
>I don't want to do a
>detailed code review or require docs from the submitter if the module
>isn't likely to be included, so do we want to add this module?

Sorry about the lack of docs.  They'll be easy to copy-and-modify from the 
"sha" module, I'll try to get to that in a day or two.


>There are a bunch of other variants with different bit sizes such as
>512, 384, and 224 bits.  The only one likely to matter is SHA-512, so
>adding sha256 might mean that down the road we need to add a sha512
>module, too, but that seems unlikely.

I agree that SHA-512 is less important: it's much slower, and the security 
margin vs. SHA-256 is excessive.

However, a "hashes" package might make sense:

from hashes import md5
from hashes import sha
from hashes import sha256
...

At some future date, you could imagine a "ciphers" package with similar 
structure:

from ciphers import AES
from ciphers import DES3
...


Trevor 


From jim.jewett at eds.com  Tue Jun 29 12:27:20 2004
From: jim.jewett at eds.com (Jewett, Jim J)
Date: Tue Jun 29 12:28:06 2004
Subject: [Python-Dev] Re: decorators and 2.4
Message-ID: <B8CDFB11BB44D411B8E600508BDF076C22955BFA@usahm010.exmi01.exch.eds.com>

Jeff Bone:

> Yet --- true, but only if one accepts a particular and rather 
> simple-minded and overly-literal interpretation of the ***GOALS*** of 
> PEP 318,

That simple-minded and overly-literal interpretation may well 
be correct.

PEP 318 does not intend to change the semantics or capabilities 
of the language in any way whatsoever.

The only reason to add 318 is so that a particular idiom will be
easier to understand (and perhaps more efficient).

The other goals are really damage control.  If the idiom becomes
easy to use, it will get used more often.  Sometimes, that will
be good, as it will replace something more byzantine.

It is true that we don't want to encourage certain types of coding,
but they're already possible, and the consensus was not to ban
them now.  Discourage in a style guide, maybe, but not ban.

The arguments about syntax are because we don't want the new and
improved idiom to end up uglifying the rest of the language.  
Ideally, any change will remove more clutter than it creates, so
adding new meaning to certain magic characters ... is risky.

If we put restrictions on decorators, people may just keep using 
the current idiom -- and then we would have added the clutter for
no gain at all.

-jJ

From amk at amk.ca  Tue Jun 29 12:28:52 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Tue Jun 29 12:29:00 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <20040629151022.GB1772@vicky.ecs.soton.ac.uk>
References: <20040629142417.GA7223@rogue.amk.ca>
	<20040629151022.GB1772@vicky.ecs.soton.ac.uk>
Message-ID: <20040629162852.GA8485@rogue.amk.ca>

On Tue, Jun 29, 2004 at 04:10:22PM +0100, Armin Rigo wrote:
> We may consider whether adding, over time, a bunch of modules named shaXXX 
> doesn't mean we should start thinking about a way to group all these 
> algorithms into a single module.

It would be possible to change the signature of sha.new() to
sha.new('string', bits=256) and have all the variants in one module,
if we want SHA-256 but not a separate module.

--amk


From dave at boost-consulting.com  Tue Jun 29 12:45:30 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue Jun 29 12:45:37 2004
Subject: [Python-Dev] Re: decorators and 2.4
References: <B8CDFB11BB44D411B8E600508BDF076C22955BFA@usahm010.exmi01.exch.eds.com>
Message-ID: <uacyms47p.fsf@boost-consulting.com>

"Jewett, Jim J" <jim.jewett@eds.com> writes:

> Jeff Bone:
>
>> Yet --- true, but only if one accepts a particular and rather 
>> simple-minded and overly-literal interpretation of the ***GOALS*** of 
>> PEP 318,
>
> That simple-minded and overly-literal interpretation may well 
> be correct.
>
> PEP 318 does not intend to change the semantics or capabilities 
> of the language in any way whatsoever.

I just want to point out that Guido has been basically silent ever
since this discussion re-started and it has now degenerated into a
mostly-philosophical debate.  I suggest it might be worth waiting for
him to respond before it spirals any further away from what was asked
for :)

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From barry at python.org  Tue Jun 29 12:45:50 2004
From: barry at python.org (Barry Warsaw)
Date: Tue Jun 29 12:45:44 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <20040629162852.GA8485@rogue.amk.ca>
References: <20040629142417.GA7223@rogue.amk.ca>
	<20040629151022.GB1772@vicky.ecs.soton.ac.uk>
	<20040629162852.GA8485@rogue.amk.ca>
Message-ID: <1088527550.7521.136.camel@localhost>

On Tue, 2004-06-29 at 12:28, A.M. Kuchling wrote:
> On Tue, Jun 29, 2004 at 04:10:22PM +0100, Armin Rigo wrote:
> > We may consider whether adding, over time, a bunch of modules named shaXXX 
> > doesn't mean we should start thinking about a way to group all these 
> > algorithms into a single module.
> 
> It would be possible to change the signature of sha.new() to
> sha.new('string', bits=256) and have all the variants in one module,
> if we want SHA-256 but not a separate module.

That seems like a very nice solution to me.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040629/0b082418/attachment.bin
From barry at python.org  Tue Jun 29 12:55:07 2004
From: barry at python.org (Barry Warsaw)
Date: Tue Jun 29 12:54:57 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <uacyms47p.fsf@boost-consulting.com>
References: <B8CDFB11BB44D411B8E600508BDF076C22955BFA@usahm010.exmi01.exch.eds.com>
	<uacyms47p.fsf@boost-consulting.com>
Message-ID: <1088528107.7527.141.camel@localhost>

On Tue, 2004-06-29 at 12:45, David Abrahams wrote:

> I just want to point out that Guido has been basically silent ever
> since this discussion re-started and it has now degenerated into a
> mostly-philosophical debate.  I suggest it might be worth waiting for
> him to respond before it spirals any further away from what was asked
> for :)

I doubt he will respond.  I think Guido has decided what the semantics
will be and is just waffling over what syntax to choose.  /I'm/ waiting
for Tim to respond, because he'll get a clear image on his BCR (BDFL
Channel Receptor) a few days before Guido makes up his mind and posts
his pronouncement.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040629/af3dc48f/attachment.bin
From mwh at python.net  Tue Jun 29 13:53:46 2004
From: mwh at python.net (Michael Hudson)
Date: Tue Jun 29 13:53:49 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <20040628220814.GA8618@vicky.ecs.soton.ac.uk> (Armin Rigo's
	message of "Mon, 28 Jun 2004 23:08:14 +0100")
References: <0CFFADBB825C6249A26FDF11C1772AE1550AE3@ingdexj1.ingdirect.com>
	<20040628220814.GA8618@vicky.ecs.soton.ac.uk>
Message-ID: <2mk6xq5jyt.fsf@starship.python.net>

Armin Rigo <arigo@tunes.org> writes:

> Hello Michael,
>
> On Mon, Jun 28, 2004 at 03:00:32PM -0400, Chermside, Michael wrote:
>> > I am pretty sure that some extension modules would badly 
>> > crash if arbitrary
>> > Python code would be allowed to temper with the data that 
>> > they store there.  
>> 
>> We're all consenting adults here. Tampering with the private
>> data of an extension module is a well-known way to crash
>> Python.
>
> Is it?  I am not aware of any such example in the standard library.  I am sure
> that it would be considered as a bug.  The only (internal and expected) ways
> to crash the Python interpreter from Python are currently to abuse new.code()
> or gc.getreferents().

I know at least two more: abusing CObjects a la my post to python-dev
some months back now, and the oft-repeated "falling off the end of the
stack".

> If an extension module allows this kind of tampering from Python
> code I'd consider it poorly written.

I concur.

Cheers,
mwh

-- 
  ... but I guess there are some things that are so gross you just have
  to forget, or it'll destroy something within you.  perl is the first
  such thing I have known.              -- Erik Naggum, comp.lang.lisp

From mwh at python.net  Tue Jun 29 13:55:37 2004
From: mwh at python.net (Michael Hudson)
Date: Tue Jun 29 13:56:07 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <20040629142417.GA7223@rogue.amk.ca> (A. M. Kuchling's message
	of "Tue, 29 Jun 2004 10:24:17 -0400")
References: <20040629142417.GA7223@rogue.amk.ca>
Message-ID: <2macym5jvq.fsf@starship.python.net>

"A.M. Kuchling" <amk@amk.ca> writes:

> Patch #935454 is a module implementing SHA-256, a variant of the
> 160-bit SHA algorithm supported in Python's existing sha module.

Why a new module and not just a new function 'sha.sha256'?

Cheers,
mwh

-- 
  MAN:  How can I tell that the past isn't a fiction designed to
        account for the discrepancy between my immediate physical
        sensations and my state of mind?
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 12

From mwh at python.net  Tue Jun 29 13:59:34 2004
From: mwh at python.net (Michael Hudson)
Date: Tue Jun 29 13:59:38 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
In-Reply-To: <40D5C17C.2010008@v.loewis.de> (
	=?iso-8859-1?q?Martin_v._L=F6wis's_message_of?= "Sun,
	20 Jun 2004 18:55:24 +0200")
References: <40D5C17C.2010008@v.loewis.de>
Message-ID: <2m3c4e5jp5.fsf@starship.python.net>

"Martin v. L?wis" <martin@v.loewis.de> writes:

> In the translation project, we now have two (partial) translation
> of Python doc strings: for German, and for Turkish. I'd like to ship
> the compiled message catalogs with Python 2.4, so that pydoc will
> automatically display translated doc strings if they are available.
>
> I would suggest to place the catalogs into Lib/messages/*.mo
> (alternatively, if a "non-doc" message catalog for Python is foreseen,
> Lib/doc/*.mo would also be reasonable).
>
> What do you think?

Sounds like a good idea to me!

Cheers,
mwh

-- 
  Many of the posts you see on Usenet are actually from moths.  You
  can tell which posters they are by their attraction to the flames.
                                      -- Internet Oracularity #1279-06

From mwh at python.net  Tue Jun 29 14:03:31 2004
From: mwh at python.net (Michael Hudson)
Date: Tue Jun 29 14:03:35 2004
Subject: [Python-Dev] Compiling the Python sources with a C++ compiler
	(aCC)
In-Reply-To: <20040627115645.GC4791@divinian> (Paul Sheer's message of "Sun,
	27 Jun 2004 13:56:45 +0200")
References: <20040626174513.GA4419@divinian>
	<Pine.BSF.4.58.0406261505220.12865@familjen.svensson.org>
	<20040627115645.GC4791@divinian>
Message-ID: <2my8m644y4.fsf@starship.python.net>

Paul Sheer <p@2038bug.com> writes:

>> Neil Hodgson:
>>    I think it is unlikely that such a large patch and resulting C++
>> compatibility policy will be accepted.
>
>
>> Paul Svensson:
>> 
>> The Pythin sorces are written in C; that they fail to compile
>> when usung a compiler for a different language is a feature, not a bug.
>> 
>
> of course :-)
>
> however, most of the changes are good coding practice in any case.
>
> the rest are outright inconsistencies in the python source
> and ought to be fixed -
>
> for instance, the macros 'PyMODINIT_FUNC' and 'staticforward'
> are *not* used with consistency

Isn't staticforward a work around for broken compilers?  I'm not sure
how much brokeness in the compiler we want to live with.

Cheers,
mwh

-- 
  M-x psych[TAB][RETURN]
                                                             -- try it

From mwh at python.net  Tue Jun 29 14:05:20 2004
From: mwh at python.net (Michael Hudson)
Date: Tue Jun 29 14:05:25 2004
Subject: [Python-Dev] What can we do about dealing with the Demo directory?
In-Reply-To: <40DE5539.9050709@ocf.berkeley.edu> (Brett Cannon's message of
	"Sat, 26 Jun 2004 22:03:53 -0700")
References: <40DE5539.9050709@ocf.berkeley.edu>
Message-ID: <2mu0wu44v3.fsf@starship.python.net>

Brett Cannon <bac@OCF.Berkeley.EDU> writes:

> While reading through the "Extending/Embedding Python" tutorial (no
> snickering; I need to implement a type from scratch for my thesis and
> I figured I might as well read the tutorial for once),

Please feel free to rewrite this document: it has lots of good
material but is also a total dogs breakfast in many ways (I know, I
wrote parts of it...).

Cheers,
mwh

-- 
  Slim Shady is fed up with your shit, and he's going to kill you.
                         -- Eminem, "Public Service Announcement 2000"

From python at rcn.com  Tue Jun 29 02:25:00 2004
From: python at rcn.com (Raymond Hettinger)
Date: Tue Jun 29 14:26:05 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <1088527550.7521.136.camel@localhost>
Message-ID: <005001c45da1$cfb9e1c0$e841fea9@oemcomputer>

> > On Tue, Jun 29, 2004 at 04:10:22PM +0100, Armin Rigo wrote:
> > > We may consider whether adding, over time, a bunch of modules
named
> shaXXX
> > > doesn't mean we should start thinking about a way to group all
these
> > > algorithms into a single module.
> >
> > It would be possible to change the signature of sha.new() to
> > sha.new('string', bits=256) and have all the variants in one module,
> > if we want SHA-256 but not a separate module.
> 
> That seems like a very nice solution to me.

+1


Raymond


From barry at python.org  Tue Jun 29 14:36:14 2004
From: barry at python.org (Barry Warsaw)
Date: Tue Jun 29 14:36:07 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
In-Reply-To: <2m3c4e5jp5.fsf@starship.python.net>
References: <40D5C17C.2010008@v.loewis.de> <2m3c4e5jp5.fsf@starship.python.net>
Message-ID: <1088534174.27300.149.camel@localhost>

On Tue, 2004-06-29 at 13:59, Michael Hudson wrote:

> > I would suggest to place the catalogs into Lib/messages/*.mo
> > (alternatively, if a "non-doc" message catalog for Python is foreseen,
> > Lib/doc/*.mo would also be reasonable).
> >
> > What do you think?
> 
> Sounds like a good idea to me!

Martin, would you make Lib/messages or Lib/doc an importable package
directory?  I guess that's the point of sticking it in Lib, so that it's
easier to find via Python's import mechanism, right?

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040629/0b768bbb/attachment.bin
From barry at python.org  Tue Jun 29 14:40:21 2004
From: barry at python.org (Barry Warsaw)
Date: Tue Jun 29 14:40:47 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <005001c45da1$cfb9e1c0$e841fea9@oemcomputer>
References: <005001c45da1$cfb9e1c0$e841fea9@oemcomputer>
Message-ID: <1088534421.27300.153.camel@localhost>

On Tue, 2004-06-29 at 02:25, Raymond Hettinger wrote:
> > > On Tue, Jun 29, 2004 at 04:10:22PM +0100, Armin Rigo wrote:
> > > > We may consider whether adding, over time, a bunch of modules
> named
> > shaXXX
> > > > doesn't mean we should start thinking about a way to group all
> these
> > > > algorithms into a single module.
> > >
> > > It would be possible to change the signature of sha.new() to
> > > sha.new('string', bits=256) and have all the variants in one module,
> > > if we want SHA-256 but not a separate module.
> > 
> > That seems like a very nice solution to me.
> 
> +1

BTW, would it raise an exception (ValueError?) for bit sizes it doesn't
know about?

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040629/74651a99/attachment-0001.bin
From greg at electricrain.com  Tue Jun 29 15:04:21 2004
From: greg at electricrain.com (Gregory P. Smith)
Date: Tue Jun 29 15:04:28 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <1088534421.27300.153.camel@localhost>
References: <005001c45da1$cfb9e1c0$e841fea9@oemcomputer>
	<1088534421.27300.153.camel@localhost>
Message-ID: <20040629190421.GT11545@zot.electricrain.com>

On Tue, Jun 29, 2004 at 02:40:21PM -0400, Barry Warsaw wrote:
> On Tue, 2004-06-29 at 02:25, Raymond Hettinger wrote:
> > > > On Tue, Jun 29, 2004 at 04:10:22PM +0100, Armin Rigo wrote:
> > > > > We may consider whether adding, over time, a bunch of modules
> > named
> > > shaXXX
> > > > > doesn't mean we should start thinking about a way to group all
> > these
> > > > > algorithms into a single module.
> > > >
> > > > It would be possible to change the signature of sha.new() to
> > > > sha.new('string', bits=256) and have all the variants in one module,
> > > > if we want SHA-256 but not a separate module.
> > > 
> > > That seems like a very nice solution to me.
> > 
> > +1
> 
> BTW, would it raise an exception (ValueError?) for bit sizes it doesn't
> know about?

I'd sure hope so.  Personally i prefer to not use a bits argument as
it passing a function reference to a hash algorithm needlessly require
a lambda.  Instead do as someone else suggested and make a sha.sha256()
function:

do_thing_and_hash(things=thingList, hashmaker=lambda x: sha.new(x, bits=256))
vs
do_thing_and_hash(things=thingList, hashmaker=sha.sha256)

The only official SHAs defined are sha1, sha256, sha384 and sha512 and
are typically referred to as a single unit name of "sha1" or "sha512"
not "the SHA which is 512 bits."  using a simple function name that is
the common spoken name is nicer.

Perl uses a top level module to contain all its hash functions
(Digest::MD5, Digest::SHA1, etc).  I agree that we should do that same
(as someone else already suggested).

Realistically, lets not reinvent the wheel.  See the pycrypto module:

 http://www.amk.ca/python/code/crypto.html

MD5 and SHA1 are the most common types of hashes in use today; those
make sense to have in the base python distro.  Does sha256 or greater?

If someone needs something better than sha1 there is a good chance
that they are also dealing with symmetric encryption or public key
authentication and would need a module like pycrypto anyways.

-g


From martin at v.loewis.de  Tue Jun 29 16:07:28 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue Jun 29 16:07:34 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
In-Reply-To: <1088534174.27300.149.camel@localhost>
References: <40D5C17C.2010008@v.loewis.de> <2m3c4e5jp5.fsf@starship.python.net>
	<1088534174.27300.149.camel@localhost>
Message-ID: <40E1CC00.7070809@v.loewis.de>

Barry Warsaw wrote:
> Martin, would you make Lib/messages or Lib/doc an importable package
> directory?  I guess that's the point of sticking it in Lib, so that it's
> easier to find via Python's import mechanism, right?

Actually, no. I'd like to stick it into Lib/somewhere, so it is easy to
locate through

os.path.join(os.path.dirname(gettext.__file__), 'messages')

Even more importantly, putting it into Lib means it is simpler to have
it installed.

If you think it helps, finding it through

import messages
messages.docstrings('de')

might be an option; messages/__init__.py would then have the proper
magic.

Regards,
Martin


From trevp at trevp.net  Tue Jun 29 17:22:10 2004
From: trevp at trevp.net (Trevor Perrin)
Date: Tue Jun 29 17:22:28 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <20040629190421.GT11545@zot.electricrain.com>
References: <1088534421.27300.153.camel@localhost>
	<005001c45da1$cfb9e1c0$e841fea9@oemcomputer>
	<1088534421.27300.153.camel@localhost>
Message-ID: <5.2.0.9.0.20040629125948.0292a5a0@pop.sbcglobal.yahoo.com>

At 12:04 PM 6/29/2004 -0700, Gregory P. Smith wrote:
>[...]
>The only official SHAs defined are sha1, sha256, sha384 and sha512

Plus SHA-224, which is just SHA-256 with a different initial value and 
truncated output (similarly, SHA-384 is just SHA-512 with a different 
initial value and truncated output).

(Why so many SHAs?  Due to birthday attacks, sometimes hash algorithms have 
half the bit-security of their output length, and you might want your 
hash's security level to match your cipher's security level.  AES has a 
security level (i.e. key length) of 128, 192, or 256 bits.  3DES has a 
level of 112 bits.  SHA-1 was designed as part of a suite including the 
Skipjack 80-bit cipher).


>  and
>are typically referred to as a single unit name of "sha1" or "sha512"
>not "the SHA which is 512 bits."  using a simple function name that is
>the common spoken name is nicer.

Agreed, since SHA-1, SHA-256, and SHA-512 are different algorithms that are 
just named similarly.

That's less true of SHA-224 and SHA-384, which *are* just parameterizations 
of the other algorithms, and could be done like:

sha256.new('string', bits=224)
sha512.new('string', bits=384)


>Perl uses a top level module to contain all its hash functions
>(Digest::MD5, Digest::SHA1, etc).  I agree that we should do that same
>(as someone else already suggested).

Yeah, that also gives room to grow if other hashes become prevalent.


>Realistically, lets not reinvent the wheel.  See the pycrypto module:
>
>  http://www.amk.ca/python/code/crypto.html
>
>MD5 and SHA1 are the most common types of hashes in use today; those
>make sense to have in the base python distro.  Does sha256 or greater?

I think SHA-256 does, since SHA-1 is skimpy for a lot of uses.  They're 
aren't many SHA-256-using protocols due to inertia, but I think it's 
happening.  The others I don't see any rush for.


>If someone needs something better than sha1 there is a good chance
>that they are also dealing with symmetric encryption or public key
>authentication and would need a module like pycrypto anyways.

Good point.  Probably this and other crypto patches need to viewed in light 
of a broader "crypto strategy", whatever that may be.

My thought is that since almost all crypto protocols depend on a tiny 
number of primitives (a few ciphers, a few hashes, modular exponentiation, 
random numbers), it would be good to have these in stdlib.  Otherwise 
crypto-using apps require extensions (like pycrypto + GMP) which makes them 
hard to distribute.

It would be great to borrow code from pycrypto where possible (for example, 
pycrypto has excellent ciphers, though it doesn't have SHA-256).  But these 
things would be handiest if they came with the standard library.

Anyways, I advocated this below..  I'd be happy to write this up as a PEP 
or something, if that would be easier to consider than a scattershot set of 
patches?
http://mail.python.org/pipermail/python-dev/2004-May/044673.html


Trevor 


From barry at python.org  Tue Jun 29 17:31:19 2004
From: barry at python.org (Barry Warsaw)
Date: Tue Jun 29 17:31:09 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
In-Reply-To: <40E1CC00.7070809@v.loewis.de>
References: <40D5C17C.2010008@v.loewis.de> <2m3c4e5jp5.fsf@starship.python.net>
	<1088534174.27300.149.camel@localhost>
	<40E1CC00.7070809@v.loewis.de>
Message-ID: <1088544679.7523.222.camel@localhost>

On Tue, 2004-06-29 at 16:07, "Martin v. L?wis" wrote:

> Actually, no. I'd like to stick it into Lib/somewhere, so it is easy to
> locate through
> 
> os.path.join(os.path.dirname(gettext.__file__), 'messages')
> 
> Even more importantly, putting it into Lib means it is simpler to have
> it installed.

Good enough reason for me, although my one (minor) concern is the
consumption of that name in the top-level package namespace for
something that isn't Python code.

> If you think it helps, finding it through
> 
> import messages
> messages.docstrings('de')
> 
> might be an option; messages/__init__.py would then have the proper
> magic.

That makes me feel better about dropping it in Lib, even if the use case
is a little questionable. I'm uncomfortable about having things other
than packages or modules in that namespace.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040629/759b31e3/attachment.bin
From ncoghlan at iinet.net.au  Tue Jun 29 21:34:24 2004
From: ncoghlan at iinet.net.au (Nick Coghlan)
Date: Tue Jun 29 21:34:31 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <1088528107.7527.141.camel@localhost>
References: <B8CDFB11BB44D411B8E600508BDF076C22955BFA@usahm010.exmi01.exch.eds.com>	<uacyms47p.fsf@boost-consulting.com>
	<1088528107.7527.141.camel@localhost>
Message-ID: <40E218A0.9060609@iinet.net.au>

Barry Warsaw wrote:
> I doubt he will respond.  I think Guido has decided what the semantics
> will be and is just waffling over what syntax to choose.  /I'm/ waiting
> for Tim to respond, because he'll get a clear image on his BCR (BDFL
> Channel Receptor) a few days before Guido makes up his mind and posts
> his pronouncement.

I'm now hoping that he goes for the list-before-def approach, since 
Phillip seems to have shown that it would then be possible to:
a) get to use decorators
b) write backwards compatible code (albeit with a little magic to do so)

Cheers,
Nick.

-- 
Nick Coghlan               |     Brisbane, Australia
Email: ncoghlan@email.com  | Mobile: +61 409 573 268

From janssen at parc.com  Wed Jun 30 01:41:08 2004
From: janssen at parc.com (Bill Janssen)
Date: Wed Jun 30 01:41:33 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings 
In-Reply-To: Your message of "Tue, 29 Jun 2004 20:55:25 PDT."
	<1f7befae04062920555b9104c7@mail.gmail.com> 
Message-ID: <04Jun29.224113pdt."58612"@synergy1.parc.xerox.com>

Tim,

I'm not sure this needs to be on the list.  My major point, I guess,
is that the byte vectors we tend to call strings in Python have no
string-ness, as understood in the 21st century.  There is no character
set associated with them, which means that there is effectively no way
to look at the "next character" in a string (you don't know how long a
character is), no way to count the number of characters, etc.  The
documentation, particularly the language manual, is extremely
confusing on this point, in classifying "string" and "Unicode" objects
as the same sort of thing.  And then not documenting them clearly.

"struct.pack", for instance, doesn't really return a string -- it
returns a byte vector.

Unicode is really the only kind of *string* type that's supported,
which is problematic, as it's not integrated with the file streams
support.  For instance, how do I write a function that opens a file
containing text in some multi-byte format (which, we'll assume, I know
the name of -- perhaps from a content-type field), and reads the first
three characters of the text?  Can't.  That's because the "file"
constructor doesn't take an encoding, and "read" and "readline" don't
return Unicode objects.  I could try, by reading some bytes, then
using unicode to turn it into a string, then seeing how many
characters I read, but that's pretty imprecise.  I go round and round
the "codecs" module thinking that someone must have thought of this --
or maybe there's an optional argument to file() that make it return
real (Unicode) strings -- but no luck.

I find it hard to believe that I've dreamed up something that neither
you nor (especially) Martin have thought of till now.  But consider
this idea.

Any file that is not explicitly opened as binary (with the 'b' flag
(and, by the way, why isn't the 'b' flag the default for file opening?
It would save a lot of grief dealing with Windows.)) should be
considered a text file, and it should have an associated "encoding"
attribute (as file objects already do), which would also be a keyword
parameter to the constructor.  The default would be
sys.getdefaultencoding().  The "size" parameter to the methods "read"
and "readline" should refer to characters, not bytes, for text files.
The return values from "next", "read" and "readline" would be Unicode
objects for text files.  Similarly, the methods "write" and
"writelines" should, for text files, take Unicode objects and raise an
exception if fed a "byte vector".

I'd go further.  I'd introduce the notation

    v = b"abc"

which means that "v" has assigned to it an 8-bit "string" byte vector.
Then, after a release or two, I'd make plain old

    "foo"

mean what

    u"foo"

means today, so that string literals are by default Unicode (module
PEP 263).

Bill

From martin at v.loewis.de  Wed Jun 30 02:04:25 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed Jun 30 02:04:39 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
In-Reply-To: <1088544679.7523.222.camel@localhost>
References: <40D5C17C.2010008@v.loewis.de>	
	<2m3c4e5jp5.fsf@starship.python.net>
	<1088534174.27300.149.camel@localhost>	
	<40E1CC00.7070809@v.loewis.de>
	<1088544679.7523.222.camel@localhost>
Message-ID: <40E257E9.6070503@v.loewis.de>

Barry Warsaw wrote:
> Good enough reason for me, although my one (minor) concern is the
> consumption of that name in the top-level package namespace for
> something that isn't Python code.

Indeed. If you can propose a different location in the source
tree, and in the installed tree (for both Windows and Unix),
I could do that as well.

> That makes me feel better about dropping it in Lib, even if the use case
> is a little questionable. I'm uncomfortable about having things other
> than packages or modules in that namespace.

There are already a lot of lib- directories, which aren't package
names. If a different directory name would make you feel more
comfortable, please suggest one.

I had precisely the same concerns myself, that's why I asked.

Regards,
Martin



From janssen at parc.com  Wed Jun 30 02:09:56 2004
From: janssen at parc.com (Bill Janssen)
Date: Wed Jun 30 02:10:23 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings 
In-Reply-To: Your message of "Tue, 29 Jun 2004 22:41:08 PDT."
	<04Jun29.224113pdt."58612"@synergy1.parc.xerox.com> 
Message-ID: <04Jun29.230958pdt."58612"@synergy1.parc.xerox.com>

> means today, so that string literals are by default Unicode (module
> PEP 263).

Meant to say "modulo PEP 263".

Bill

From python at rcn.com  Tue Jun 29 14:10:17 2004
From: python at rcn.com (Raymond Hettinger)
Date: Wed Jun 30 02:11:13 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
In-Reply-To: <40D5C17C.2010008@v.loewis.de>
Message-ID: <005301c45e04$567058e0$39b22c81@oemcomputer>

[Martin v. L?wis]
> In the translation project, we now have two (partial) translation
> of Python doc strings: for German, and for Turkish. I'd like to ship
> the compiled message catalogs with Python 2.4, so that pydoc will
> automatically display translated doc strings if they are available.

I'm curious whether there were thoughts about how to keep the
translations in sync with their English counterparts.


Raymond


From martin at v.loewis.de  Wed Jun 30 02:15:43 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed Jun 30 02:15:57 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <04Jun29.224113pdt."58612"@synergy1.parc.xerox.com>
References: <04Jun29.224113pdt."58612"@synergy1.parc.xerox.com>
Message-ID: <40E25A8F.80505@v.loewis.de>

Bill Janssen wrote:

> Unicode is really the only kind of *string* type that's supported,
> which is problematic, as it's not integrated with the file streams
> support.  For instance, how do I write a function that opens a file
> containing text in some multi-byte format (which, we'll assume, I know
> the name of -- perhaps from a content-type field), and reads the first
> three characters of the text?  Can't.  

That's really not true. To process such a file, you do

f = codecs.open(filename, "r", encoding="big-5")
data = f.read()
first_three = data[:3]


> Any file that is not explicitly opened as binary (with the 'b' flag
> (and, by the way, why isn't the 'b' flag the default for file opening?

Because it isn't in C.

> I'd go further.  I'd introduce the notation
> 
>     v = b"abc"

Yes, introduction of byte string literals, and changing standard
string literals, has been proposed before. There is the -U option
for the interpreter that changes all literals to Unicode literals.
Unfortunately, a lot of code breaks under this change, so such
breakage needs to be fixed before the change can happen.

Regards,
Martin


From martin at v.loewis.de  Wed Jun 30 02:19:11 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed Jun 30 02:19:17 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
In-Reply-To: <005301c45e04$567058e0$39b22c81@oemcomputer>
References: <005301c45e04$567058e0$39b22c81@oemcomputer>
Message-ID: <40E25B5F.4020901@v.loewis.de>

Raymond Hettinger wrote:
> I'm curious whether there were thoughts about how to keep the
> translations in sync with their English counterparts.

Using standard gettext procedures. You extract all new docstrings,
and merge the old translations with the new docstrings. Some 
translations become fuzzy, and the translators have to review them.
Likewise, some docstrings will become new.

As a result, some of the translations are always outdated, and the
standard gettext procedure is to ignore them and fall back to a
different language (e.g. if you had both pt_BR and pt translations,
and pt_BR is outdated, you might fall back to the pt translation,
before falling back to en_US).

However, this is all way ahead in the future. Translating all doc
strings is very time consuming, and hasn't been completely done
for any language so far.

Regards,
Martin


From anthony at interlink.com.au  Wed Jun 30 02:44:48 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Wed Jun 30 02:45:15 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <uacyms47p.fsf@boost-consulting.com>
References: <B8CDFB11BB44D411B8E600508BDF076C22955BFA@usahm010.exmi01.exch.eds.com>
	<uacyms47p.fsf@boost-consulting.com>
Message-ID: <40E26160.5030709@interlink.com.au>

David Abrahams wrote:
> I just want to point out that Guido has been basically silent ever
> since this discussion re-started and it has now degenerated into a
> mostly-philosophical debate.  I suggest it might be worth waiting for
> him to respond before it spirals any further away from what was asked
> for :)
> 

As I said in the original email that re-opened this can of worms:

     Guido is undecided on the syntax - he writes "I'm seriously
     considering doing it Java-style", but adds that he is totally
     swamped for the next two weeks.

I don't think the philosophical arguments about decorators are
particularly useful at this point. It seems very likely that they
will be in 2.4, in a form that Guido decides is least offensive
to his aesthetic judgement.

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

From anthony at interlink.com.au  Wed Jun 30 02:48:52 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Wed Jun 30 02:49:44 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
In-Reply-To: <40E257E9.6070503@v.loewis.de>
References: <40D5C17C.2010008@v.loewis.de>		<2m3c4e5jp5.fsf@starship.python.net>	<1088534174.27300.149.camel@localhost>		<40E1CC00.7070809@v.loewis.de>	<1088544679.7523.222.camel@localhost>
	<40E257E9.6070503@v.loewis.de>
Message-ID: <40E26254.6000903@interlink.com.au>

Martin v. L?wis wrote:
> Barry Warsaw wrote:
> 
>> Good enough reason for me, although my one (minor) concern is the
>> consumption of that name in the top-level package namespace for
>> something that isn't Python code.
> 
> 
> Indeed. If you can propose a different location in the source
> tree, and in the installed tree (for both Windows and Unix),
> I could do that as well.
> 
>> That makes me feel better about dropping it in Lib, even if the use case
>> is a little questionable. I'm uncomfortable about having things other
>> than packages or modules in that namespace.
> 
> 
> There are already a lot of lib- directories, which aren't package
> names. If a different directory name would make you feel more
> comfortable, please suggest one.
> 
> I had precisely the same concerns myself, that's why I asked.

msg-catalogs? gettext-mo? Using a '-' in the name is, to me, a
pretty clear sign that the thing is not a python package that can
be imported...

Anthony

From mal at egenix.com  Wed Jun 30 04:02:01 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jun 30 04:02:07 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings
In-Reply-To: <04Jun29.224113pdt."58612"@synergy1.parc.xerox.com>
References: <04Jun29.224113pdt."58612"@synergy1.parc.xerox.com>
Message-ID: <40E27379.1060208@egenix.com>

Bill Janssen wrote:
> I'd go further.  I'd introduce the notation
> 
>     v = b"abc"
> 
> which means that "v" has assigned to it an 8-bit "string" byte vector.
> Then, after a release or two, I'd make plain old
> 
>     "foo"
> 
> mean what
> 
>     u"foo"
> 
> means today, so that string literals are by default Unicode (modulo
> PEP 263).

This would be ideal indeed and it has been dreamed up early on
in 2000 when the whole Unicode thing happened.

The option -U was added to be able to test the standard lib
against such an approach. Unfortunately, many modules don't work
under such an assumption, so we are still far from being able to
make -U the default.

Meanwhile, it's best to always use Unicode for text data
and strings for everything else.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 30 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From mwh at python.net  Wed Jun 30 04:50:16 2004
From: mwh at python.net (Michael Hudson)
Date: Wed Jun 30 04:50:20 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <1088352716.7336.241.camel@localhost> (Barry Warsaw's message
	of "Sun, 27 Jun 2004 12:11:56 -0400")
References: <5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<40D84CEE.6040307@interlink.com.au>
	<5.1.1.6.0.20040624234205.0308cd20@mail.telecommunity.com>
	<20040625100125.GA15576@vicky.ecs.soton.ac.uk>
	<5.1.1.6.0.20040625155050.02b538f0@mail.telecommunity.com>
	<oen6l4pl.fsf@yahoo.co.uk> <1088352716.7336.241.camel@localhost>
Message-ID: <2mk6xp4egn.fsf@starship.python.net>

Barry Warsaw <barry@python.org> writes:

> On Sat, 2004-06-26 at 11:27, Paul Moore wrote:
>
>> Just a reminder, but I believe that Guido has already pronounced to
>> the effect that there are only 3 contenders left:
>
> I've said before that I'm past caring which syntax is chosen.  I could
> live with any of these three.  I just want the feature in 2.4 and I
> trust Guido to Make The Right Decision.

A-fucking-men.

Cheers,
mwh
(who apologies for the crudity, but would also like an apology from
all the people who bugged him about this topic at EuroPython (apart
from Guido :-))

-- 
  Just point your web browser at http://www.python.org/search/ and
  look for "program", "doesn't", "work", or "my". Whenever you find
  someone else whose program didn't work, don't do what they
  did. Repeat as needed.    -- Tim Peters, on python-help, 16 Jun 1998

From mwh at python.net  Wed Jun 30 05:15:24 2004
From: mwh at python.net (Michael Hudson)
Date: Wed Jun 30 05:15:29 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <5.2.0.9.0.20040629125948.0292a5a0@pop.sbcglobal.yahoo.com>
	(Trevor Perrin's message of "Tue, 29 Jun 2004 14:22:10 -0700")
References: <1088534421.27300.153.camel@localhost>
	<005001c45da1$cfb9e1c0$e841fea9@oemcomputer>
	<1088534421.27300.153.camel@localhost>
	<5.2.0.9.0.20040629125948.0292a5a0@pop.sbcglobal.yahoo.com>
Message-ID: <2mfz8d4dar.fsf@starship.python.net>

Trevor Perrin <trevp@trevp.net> writes:

> I think SHA-256 does, since SHA-1 is skimpy for a lot of uses.

Nevertheless, am I right to still believe that there are no known
distinct strings which even MD5 to the same hash?

> My thought is that since almost all crypto protocols depend on a tiny
> number of primitives (a few ciphers, a few hashes, modular
> exponentiation, random numbers), it would be good to have these in
> stdlib.  Otherwise crypto-using apps require extensions (like pycrypto
> + GMP) which makes them hard to distribute.

Unfortunately, distributing crypto software is still a hideous
international mess (just because the *US* is less silly these
days...).

Cheers,
mwh

-- 
  GAG: I think this is perfectly normal behaviour for a Vogon. ...
VOGON: That is exactly what you always say.
  GAG: Well, I think that is probably perfectly normal behaviour for a
      psychiatrist. -- The Hitch-Hikers Guide to the Galaxy, Episode 9

From mwh at python.net  Wed Jun 30 05:53:30 2004
From: mwh at python.net (Michael Hudson)
Date: Wed Jun 30 05:53:33 2004
Subject: [Python-Dev] Re: decorators and 2.4
In-Reply-To: <9C12EE2E-C9CB-11D8-9B14-000A95CFE9DE@place.org> (Jeff Bone's
	message of "Tue, 29 Jun 2004 07:55:34 -0500")
References: <5.1.1.6.0.20040628160522.031f70a0@mail.telecommunity.com>
	<5.1.1.6.0.20040628214724.030c1890@mail.telecommunity.com>
	<86E1E62A-C99A-11D8-9B14-000A95CFE9DE@place.org>
	<200406291150.29915.gmccaughan@synaptics-uk.com>
	<9C12EE2E-C9CB-11D8-9B14-000A95CFE9DE@place.org>
Message-ID: <2mbrj14bj9.fsf@starship.python.net>

Jeff Bone <jbone@place.org> writes:

> On Jun 29, 2004, at 5:50 AM, Gareth McCaughan wrote:
>
>> Excuse me, but when you're implying that Philip is "strategically
>> myopic and slightly programming-language illiterate" and asking
>> "what is your damage?" and calling his comments "bullshit" and
>> likening him to "an ignorant school-marm", you are not in a great
>> position to take the moral high ground about being either "aggressive"
>> or "defensive".
>
> Sorry, yes, you're correct.  I apologize to Phil and the list.  It's
> just rather frustrating to get beat all to hell (and told
> patronizingly to "read" a freakin' PEP I've read, repeatedly, before
> even speaking up) for no apparent reason just for raising what IMHO
> are rather legitimate concerns.

It's probably easy to underestimate the level of frustration around
this issue.  There have been THOUSANDS of posts to python-dev on this
or close-by topics in the last 18 months.  People who appear to be
trying to take the discussion back to areas where there was perceived
consensus aren't going to be popular.

> My bad, I'll go back to lurk and if this particular feature turns out
> to be the giant hairball it appears to be I won't say anything.

This is why the subject is so delicate: it requires seeing into the
future, and that's hard.  If all decorators end up being used for is
classmethods then it almsot doesn't matter which of the proposed
syntaxes get used.  If they become common, then it's a bigger issue.

FWIW, I think the idea of limiting what a descriptor can be or do is
insane (as well as possibly impossible).  If the issue is that scary,
then we shouldn't add any syntax at all.

Cheers,
mwh

-- 
  Just getting something to work usually means writing reams of code
  fast, like a Stephen King novel, but making it maintainable and
  high-quality code that really expresses the ideas well, is like
  writing poetry.  Art is taking away.  -- Erik Naggum, comp.lang.lisp

From jim at zope.com  Wed Jun 30 06:16:32 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Jun 30 09:23:48 2004
Subject: [Python-Dev] Proposal: thread.get_dict
In-Reply-To: <40E1723B.7080604@zope.com>
References: <40E03020.7010101@zope.com>
	<20040628161619.GA14187@vicky.ecs.soton.ac.uk>
	<40E05AE2.1080608@zope.com>
	<20040628222954.GB8618@vicky.ecs.soton.ac.uk>
	<40E1723B.7080604@zope.com>
Message-ID: <40E29300.60802@zope.com>

Jim Fulton wrote:
> Armin Rigo wrote:
> 
...

> I have to say that I *really* like your suggestion of the thread.local
> object.  I'm not sure the elegance isn't worth the extra dictionary lookup.
> Actually, for most apps, the elegance is more than worth the extra 
> dictionary
> lookup.  I'm gonna do some more investigation of this to see if I can 
> estimate
> the impact of the extra lookup on what I'm doing.

OK, I spent some quality time with gprof yesterday.  I was able to prove to myself
that C dict lookups (e.g. PyDict_GetItem) are so fast that the extra dict lookup
isn't worth worrying about. (On my slow laptop, a lookup from a small dict took
about 80 nanoseconds.) I was being silly about the extra dict lookup cost.
Your local object is the way to go.

I'll also note that that I can use a slightly different implementation than the
one you suggested and gain back much of the (tiny) cost of the extra lookup.
It happens that lookup on non-string keys is much more expensive than lookup of
string keys.  For small dictionaries (gprof experiments show that) using an
object key is more than 40% slower than using a string key. Tim tells me that
the difference will be more stark for a larger dictionary with collisions.

With the local object, the local-object implementation can control the key used.
Rather than using itself as the key for looking up its data dictionary, it can
use a string of it's address.  This provides the safety of using an object
key, but gets the speed benefit of using a string key.

I'll send an updated proposal here later today.

Thanks for the great suggestion!

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org



From barry at python.org  Wed Jun 30 10:19:13 2004
From: barry at python.org (Barry Warsaw)
Date: Wed Jun 30 10:18:59 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
In-Reply-To: <40E26254.6000903@interlink.com.au>
References: <40D5C17C.2010008@v.loewis.de> <2m3c4e5jp5.fsf@starship.python.net>
	<1088534174.27300.149.camel@localhost>
	<40E1CC00.7070809@v.loewis.de> <1088544679.7523.222.camel@localhost>
	<40E257E9.6070503@v.loewis.de> <40E26254.6000903@interlink.com.au>
Message-ID: <1088605153.7378.84.camel@localhost>

On Wed, 2004-06-30 at 02:48, Anthony Baxter wrote:

> > There are already a lot of lib- directories, which aren't package
> > names. If a different directory name would make you feel more
> > comfortable, please suggest one.
> > 
> > I had precisely the same concerns myself, that's why I asked.
> 
> msg-catalogs? gettext-mo? Using a '-' in the name is, to me, a
> pretty clear sign that the thing is not a python package that can
> be imported...

I don't have any better ideas, and I don't really see a good use case
for making this a package, so Anthony's suggestion seems reasonable. 
gettext-catalogs or any variation thereof seems fine to me.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040630/eb28c62a/attachment.bin
From barry at python.org  Wed Jun 30 10:23:50 2004
From: barry at python.org (Barry Warsaw)
Date: Wed Jun 30 10:23:36 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
In-Reply-To: <40E25B5F.4020901@v.loewis.de>
References: <005301c45e04$567058e0$39b22c81@oemcomputer>
	<40E25B5F.4020901@v.loewis.de>
Message-ID: <1088605430.7376.88.camel@localhost>

On Wed, 2004-06-30 at 02:19, "Martin v. L?wis" wrote:

> Using standard gettext procedures

Back in the days when we were first fleshing out Zope3's i18n story,
Stephan Richter and I fleshed out a design for a web translation service
that could be used for any open source projects.  It would basically
provide a Zope interface to the catalogs, allowing for a much more
distributed process, controlled by language champions and project
leaders.  I still think it's a cool idea, but right now zope.org is way
to slow for me to dig up a URL. ;/

-Barryu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040630/bfb0a580/attachment.bin
From jim at zope.com  Wed Jun 30 10:24:26 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Jun 30 10:24:35 2004
Subject: [Python-Dev] Revised Proposal: thread.get_dict
In-Reply-To: <40E03020.7010101@zope.com>
References: <40E03020.7010101@zope.com>
Message-ID: <40E2CD1A.8080602@zope.com>

(This revised proposal is based on a suggestion from Armin
  Rigo.)

We often want to associate data with threads.  Python
manages a dictionary per-tread for this purpose, but there's
currently no way to get to this dictionary from Python.

I propose, for 2.4, to add a "local" class to the thread
module for creating thread-local objects,

Here is proposed documentation (and test:) for the class:

"""Thread-local objects

Thread-local objects support the management of thread-local data.
If you have data that you want to be local to a thread, simply create
a thread-local object and use it's attributes:

   >>> thread
   >>> mydata = thread.local()
   >>> mydata.number = 42
   >>> mydata.number
   42

You can also access the local-object's dictionary:

   >>> mydata.__dict__
   {'number': 42}
   >>> mydata.__dict__.setdefault('widgets', [])
   []
   >>> mydata.widgets
   []

What's important about thread-local objects is that their data are
local to a thread. If we access the data in a different thread:

   >>> log = []
   >>> def f():
   ...     log.append(mydata.__dict__.items())
   ...     mydata.number = 11
   ...     log.append(mydata.number)

   >>> import threading
   >>> thread = threading.Thread(target=f)
   >>> thread.start()
   >>> thread.join()
   >>> log
   [[], 11]

we get different data.  Furthermore, changes made in the other thread
don't affect data seen in this thread:

   >>> mydata.number
   42

Of course, values you get from a local object, including a __dict__
attribute, are for whatever thread was current at the time the
attribute was read.  For that reason, you generally don't want to save
these values across threads, as they apply only to the thread they
came from.

"""

Here is a demonstration Python implementation:

   from threading import currentThread

   class local(object):

     def __init__(self):
         object.__setattr__(self, '_local__key', str(id(self)))

     def __getattribute__(self, name):
         key = object.__getattribute__(self, '__dict__')['_local__key']
         d = currentThread().__dict__.get(key)
         if d is None:
             d = {}
             currentThread().__dict__[key] = d
         if name == '__dict__':
             return d
         try:
             return d[name]
         except KeyError:
             raise AttributeError, name

     def __setattr__(self, name, value):
         key = object.__getattribute__(self, '__dict__')['_local__key']
         d = currentThread().__dict__.get(key)
         if d is None:
             d = {}
             currentThread().__dict__[key] = d
         if name == '__dict__':
             raise AttributeError, "Can't assign to __dict__"
         d[name] = value

The actual implementation will be written in C using PyThreadState_GetDict.

Thoughts?  Do I need to create a PEP?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From amk at amk.ca  Wed Jun 30 11:30:01 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Wed Jun 30 11:30:24 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <2mfz8d4dar.fsf@starship.python.net>
References: <1088534421.27300.153.camel@localhost>
	<005001c45da1$cfb9e1c0$e841fea9@oemcomputer>
	<1088534421.27300.153.camel@localhost>
	<5.2.0.9.0.20040629125948.0292a5a0@pop.sbcglobal.yahoo.com>
	<2mfz8d4dar.fsf@starship.python.net>
Message-ID: <20040630153001.GA18014@rogue.amk.ca>

On Wed, Jun 30, 2004 at 10:15:24AM +0100, Michael Hudson wrote:
> Nevertheless, am I right to still believe that there are no known
> distinct strings which even MD5 to the same hash?

Correct.

One significant reason for the larger SHAs to generate 256-bit keys
for AES encryption; it's better to have a larger hash than to take a
smaller one and replicate portions of it.  But, given that we're not
going to include AES in the Python stdlib, people will have to
download a separate library anyway. This library could include SHA256,
so this application isn't a compelling reason to add SHA256 to the
stdlib.  It would be different if there were existing protocols that
need the larger hash, such as HTTP digest auth; are there any?

--amk

From ark at acm.org  Wed Jun 30 11:44:49 2004
From: ark at acm.org (Andrew Koenig)
Date: Wed Jun 30 11:44:48 2004
Subject: [Python-Dev] PEP 276 (simple iterator for ints)
Message-ID: <000c01c45eb9$2df5a310$6602a8c0@arkdesktop>

I happened to look at PEP 276 and was struck by the thought that PEP 276 is
really an implementation of the well-known set-theoretic construction of the
natural numbers that defines each natural number as the set of all smaller
ones.  In other words, it defines 0 as the empty set, 1 as the set whose
only element is 0, 2 as the set whose elements are 0 and 1, and so on.

Indeed, under PEP 276, sets.Set(42) would be a set with 42 elements that
would be exactly the canonical representation of 42.


From stuart at stuartbishop.net  Wed Jun 30 11:45:50 2004
From: stuart at stuartbishop.net (Stuart Bishop)
Date: Wed Jun 30 11:46:09 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <20040630153001.GA18014@rogue.amk.ca>
References: <1088534421.27300.153.camel@localhost>
	<005001c45da1$cfb9e1c0$e841fea9@oemcomputer>
	<1088534421.27300.153.camel@localhost>
	<5.2.0.9.0.20040629125948.0292a5a0@pop.sbcglobal.yahoo.com>
	<2mfz8d4dar.fsf@starship.python.net>
	<20040630153001.GA18014@rogue.amk.ca>
Message-ID: <90131539-CAAC-11D8-BCA6-000A95A06FC6@stuartbishop.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 30/06/2004, at 5:30 PM, A.M. Kuchling wrote:

> On Wed, Jun 30, 2004 at 10:15:24AM +0100, Michael Hudson wrote:
>> Nevertheless, am I right to still believe that there are no known
>> distinct strings which even MD5 to the same hash?
>
> Correct.
>
> One significant reason for the larger SHAs to generate 256-bit keys
> for AES encryption; it's better to have a larger hash than to take a
> smaller one and replicate portions of it.  But, given that we're not
> going to include AES in the Python stdlib, people will have to
> download a separate library anyway. This library could include SHA256,
> so this application isn't a compelling reason to add SHA256 to the
> stdlib.  It would be different if there were existing protocols that
> need the larger hash, such as HTTP digest auth; are there any?

People use sha as a one way hash for storing passwords and credit
card details. The extra bits will make the paranoid a bit happier
(and the less paranoid are still using md5).

- --  
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFA4uAvAfqZj7rGN0oRAoejAJ4wpOQx2f3+yvSFqgKPW+S3h9YmVQCggy5h
7Ydvtp/Rdj19KT/sFOtxXM8=
=/Fa4
-----END PGP SIGNATURE-----


From tim.peters at gmail.com  Wed Jun 30 12:14:36 2004
From: tim.peters at gmail.com (Tim Peters)
Date: Wed Jun 30 12:14:49 2004
Subject: [Python-Dev] Revised Proposal: thread.get_dict
In-Reply-To: <40E2CD1A.8080602@zope.com>
References: <40E03020.7010101@zope.com> <40E2CD1A.8080602@zope.com>
Message-ID: <1f7befae040630091413861170@mail.gmail.com>

[Jim Fulton]
> We often want to associate data with threads.  Python
> manages a dictionary per-tread for this purpose, but there's
> currently no way to get to this dictionary from Python.
>
> I propose, for 2.4, to add a "local" class to the thread
> module for creating thread-local objects,

It's probably better to add this to the (coded in Python) threading
module, and include the Python implementation there.  The threading
module can replace the Python implementation with something from the
(coded in C) thread module if possible.  This is so implementations
other than CPython get something usable right away (only CPython has
the C API, of course).

... the doctest ...

>   >>> thread

That was meant to be "import thread", right?

>   >>> mydata = thread.local()

...

> You can also access the local-object's dictionary:
>
>   >>> mydata.__dict__
>   {'number': 42}

I like this much better than reimplementing the dict interface one
method at a time!  Making __dict__ available is important (IMO) for
the benefit of introspection/system tools written in Python.

...

> Thoughts?

+1.

> Do I need to create a PEP?

Not unless someone starts whining about it <wink -- but it's a small feature>.

BTW, I suggest it would be better if the string key had a
unique-to-this-purpose prefix, e.g. 'threading.local.' +
str(id(self)).  I'm uncomfortable with reserving all "string keys that
look like integers" implicitly for this use.

From jim at zope.com  Wed Jun 30 12:24:13 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Jun 30 12:24:19 2004
Subject: [Python-Dev] Revised Proposal: thread.get_dict
In-Reply-To: <1f7befae040630091413861170@mail.gmail.com>
References: <40E03020.7010101@zope.com> <40E2CD1A.8080602@zope.com>
	<1f7befae040630091413861170@mail.gmail.com>
Message-ID: <40E2E92D.9030802@zope.com>

Tim Peters wrote:
> [Jim Fulton]
> 
>>We often want to associate data with threads.  Python
>>manages a dictionary per-tread for this purpose, but there's
>>currently no way to get to this dictionary from Python.
>>
>>I propose, for 2.4, to add a "local" class to the thread
>>module for creating thread-local objects,
> 
> 
> It's probably better to add this to the (coded in Python) threading
> module, and include the Python implementation there.  The threading
> module can replace the Python implementation with something from the
> (coded in C) thread module if possible.  This is so implementations
> other than CPython get something usable right away (only CPython has
> the C API, of course).

So the C implementation would be in the thread module, perhaps
under a funny name, but the official place to import it from is the
threading module?

> 
> ... the doctest ...
> 
> 
>>  >>> thread
> 
> 
> That was meant to be "import thread", right?

Oops, yup.  My *real* prototype has "import zope.thread". :)


> BTW, I suggest it would be better if the string key had a
> unique-to-this-purpose prefix, e.g. 'threading.local.' +
> str(id(self)).  I'm uncomfortable with reserving all "string keys that
> look like integers" implicitly for this use.

ok

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From dave at boost-consulting.com  Wed Jun 30 12:23:42 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed Jun 30 12:30:23 2004
Subject: [Python-Dev] Re: PEP 276 (simple iterator for ints)
References: <000c01c45eb9$2df5a310$6602a8c0@arkdesktop>
Message-ID: <uy8m5hv5d.fsf@boost-consulting.com>

"Andrew Koenig" <ark@acm.org> writes:

> I happened to look at PEP 276 and was struck by the thought that PEP 276 is
> really an implementation of the well-known set-theoretic construction of the
> natural numbers that defines each natural number as the set of all smaller
> ones.  In other words, it defines 0 as the empty set, 1 as the set whose
> only element is 0, 2 as the set whose elements are 0 and 1, and so on.
>
> Indeed, under PEP 276, sets.Set(42) would be a set with 42 elements that
> would be exactly the canonical representation of 42.

?? Simple Iterator For Ints ?? 
http://www.python.org/peps/pep-0276.html
Are you sure you mean 276?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From tjreedy at udel.edu  Wed Jun 30 12:32:50 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed Jun 30 12:32:57 2004
Subject: [Python-Dev] Re: Allowing u.encode() to return non-strings
References: <1f7befae04062920555b9104c7@mail.gmail.com>
	<04Jun29.224113pdt."58612"@synergy1.parc.xerox.com>
Message-ID: <cbupvj$71r$1@sea.gmane.org>


"Bill Janssen" <janssen@parc.com> wrote in message
news:04Jun29.224113pdt."58612"@synergy1.parc.xerox.com...
> is that the byte vectors we tend to call strings in Python have no
> string-ness, as understood in the 21st century.

Python strings are sequences of 0 to n chars from an abstract 256-char
alphabet.  This meets my understanding of the standard 20th century CS
definition of string.  Has there been a significant change in the last few
years?

>  There is no character set associated with them,

The byte set is intentionally not any *particular* natural language char
set, but a possible carrier for any of them.  Perhaps unfortunately, it
lacks a single standard glyph set or graphic representation., but I believe
Unicode also differentiates between characters (code points?) and glyphs
(which are also not standardized).  The byte set also (fortunately) lacks
the complications of letters, capitals, signs, marks, ligatures, symbols,
and so on, which complications usually make the chararacter set for a
particular language somewhat fuzzy.

> documentation, particularly the language manual, is extremely
> confusing on this point, in classifying "string" and "Unicode" objects
> as the same sort of thing.

I think it a matter a viewpoint whether one emphasizes the similarities or
differences.

> And then not documenting them clearly.

The subject of strings, Unicode, internationalization, and Python could use
a manual in itself.

> Unicode ... is not integrated with the file streams support.

Reading numbers other than bytes is also not integrated with the file type.
Adding a 'bytes' parameters to file(), or a readbytes(n) method, would be
generally helpful for anyone wanting to iterate thru a file in chunks other
than 'lines'.

Terry J. Reedy




From trevp at trevp.net  Wed Jun 30 12:33:18 2004
From: trevp at trevp.net (Trevor Perrin)
Date: Wed Jun 30 12:34:13 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <2mfz8d4dar.fsf@starship.python.net>
References: <5.2.0.9.0.20040629125948.0292a5a0@pop.sbcglobal.yahoo.com>
	<1088534421.27300.153.camel@localhost>
	<005001c45da1$cfb9e1c0$e841fea9@oemcomputer>
	<1088534421.27300.153.camel@localhost>
	<5.2.0.9.0.20040629125948.0292a5a0@pop.sbcglobal.yahoo.com>
Message-ID: <5.2.0.9.0.20040630082845.0294ecf0@pop.sbcglobal.yahoo.com>

At 10:15 AM 6/30/2004 +0100, Michael Hudson wrote:
>Trevor Perrin <trevp@trevp.net> writes:
>
> > I think SHA-256 does, since SHA-1 is skimpy for a lot of uses.
>
>Nevertheless, am I right to still believe that there are no known
>distinct strings which even MD5 to the same hash?

Yes, though there's a distributed computing project looking for a 
collision, and they expect to succeed in a couple years.
http://www.md5crk.com/


> > My thought is that since almost all crypto protocols depend on a tiny
> > number of primitives (a few ciphers, a few hashes, modular
> > exponentiation, random numbers), it would be good to have these in
> > stdlib.  Otherwise crypto-using apps require extensions (like pycrypto
> > + GMP) which makes them hard to distribute.
>
>Unfortunately, distributing crypto software is still a hideous
>international mess (just because the *US* is less silly these
>days...).

Things have been liberalizing rapidly.  I'm not sure how true that is 
anymore, though I don't have direct experience (aside from offering some 
crypto software on a website; people download it from all over the place, 
but maybe they're scofflaws, who knows).

I know US export is no problem.  According to [1], most countries have no 
laws restricting imports, with the notable exception of ex-USSR countries 
and China, which require licenses.  I've heard anecdotally the Russian 
requirements are mostly ignored [2].  I don't know about China.

More anecdotal evidence: The windows python installer includes strong 
crypto (SSL).  Has that caused problems?

Regardless, we could offer a no-crypto distribution.  It would be 
interesting to see how many people download it.  If not many, then it could 
be abandoned....


A.M. Kuchling wrote:
 > One significant reason for the larger SHAs to generate 256-bit keys
 > for AES encryption; it's better to have a larger hash than to take a
 > smaller one and replicate portions of it.  But, given that we're not
 > going to include AES in the Python stdlib, people will have to
 > download a separate library anyway. This library could include SHA256,
 > so this application isn't a compelling reason to add SHA256 to the
 > stdlib.  It would be different if there were existing protocols that
 > need the larger hash, such as HTTP digest auth; are there any?

There's protocols that can use SHA-256, like SSH, S/MIME, or PGP, but these 
all require other crypto primitives, so your point stands.  And I 
agree:  crypto primitives should probably be considered as a lump.  If 
ciphers are absolutely not going to get in, putting in other crypto stuff 
is not that helpful..


Trevor

[1] http://rechten.uvt.nl/koops/cryptolaw/cls-sum.htm
[2] 
http://www.privacy.nb.ca/cryptography/archives/cryptography/html/1997-03/0023.html 


From pje at telecommunity.com  Wed Jun 30 12:56:49 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed Jun 30 12:53:55 2004
Subject: [Python-Dev] Revised Proposal: thread.get_dict
In-Reply-To: <40E2E92D.9030802@zope.com>
References: <1f7befae040630091413861170@mail.gmail.com>
	<40E03020.7010101@zope.com> <40E2CD1A.8080602@zope.com>
	<1f7befae040630091413861170@mail.gmail.com>
Message-ID: <5.1.1.6.0.20040630125259.02d59780@mail.telecommunity.com>

At 12:24 PM 6/30/04 -0400, Jim Fulton wrote:
>Tim Peters wrote:
>>It's probably better to add this to the (coded in Python) threading
>>module, and include the Python implementation there.  The threading
>>module can replace the Python implementation with something from the
>>(coded in C) thread module if possible.  This is so implementations
>>other than CPython get something usable right away (only CPython has
>>the C API, of course).
>
>So the C implementation would be in the thread module, perhaps
>under a funny name, but the official place to import it from is the
>threading module?

I'd like to add that there should also be corresponding implementations for 
the dummy_thread and dummy_threading modules, which should be 
interface-compatible with the corresponding non-dummy modules.


From ark-mlist at att.net  Wed Jun 30 12:55:37 2004
From: ark-mlist at att.net (Andrew Koenig)
Date: Wed Jun 30 12:55:36 2004
Subject: [Python-Dev] Re: PEP 276 (simple iterator for ints)
In-Reply-To: <uy8m5hv5d.fsf@boost-consulting.com>
Message-ID: <000001c45ec3$1154cba0$6602a8c0@arkdesktop>


> ?? Simple Iterator For Ints ??
> http://www.python.org/peps/pep-0276.html
> Are you sure you mean 276?

Yes, I'm sure.  The proposal is that if n is an integer, iter(n) should
iterate over the elements of range(n).


From tim.peters at gmail.com  Wed Jun 30 13:00:24 2004
From: tim.peters at gmail.com (Tim Peters)
Date: Wed Jun 30 13:00:53 2004
Subject: [Python-Dev] Revised Proposal: thread.get_dict
In-Reply-To: <40E2E92D.9030802@zope.com>
References: <40E03020.7010101@zope.com> <40E2CD1A.8080602@zope.com>
	<1f7befae040630091413861170@mail.gmail.com>
	<40E2E92D.9030802@zope.com>
Message-ID: <1f7befae040630100060d86a79@mail.gmail.com>

[Tim]
>> It's probably better to add this to the (coded in Python) threading
>> module, and include the Python implementation there.  The threading
>> module can replace the Python implementation with something from the
>> (coded in C) thread module if possible.  This is so implementations
>> other than CPython get something usable right away (only CPython has
>> the C API, of course).

[Jim]
> So the C implementation would be in the thread module, perhaps
> under a funny name, but the official place to import it from is the
> threading module?

Exactly.  An ancient example of this approach is at the bottom of
string.py, which replaces some string.py Python functions with much
faster ones from the (coded in C) strop module, if strop exists.  A
recent example is in CVS heapq.py, which replaces Python bits with C
functions from _heapq (if available).

From martin at v.loewis.de  Wed Jun 30 13:10:39 2004
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed Jun 30 13:10:44 2004
Subject: [Python-Dev] Re: Allowing u.encode() to return non-strings
In-Reply-To: <cbupvj$71r$1@sea.gmane.org>
References: <1f7befae04062920555b9104c7@mail.gmail.com>	<04Jun29.224113pdt."58612"@synergy1.parc.xerox.com>
	<cbupvj$71r$1@sea.gmane.org>
Message-ID: <40E2F40F.80404@v.loewis.de>

Terry Reedy wrote:
> Python strings are sequences of 0 to n chars from an abstract 256-char
> alphabet.  This meets my understanding of the standard 20th century CS
> definition of string.  Has there been a significant change in the last few
> years?

Yes. Abstract 256-char alphabets have been found useless for the 
representation of natural-language text. You need concrete alphabets,
and having more than 256 characters is often important.

> The byte set is intentionally not any *particular* natural language char
> set, but a possible carrier for any of them.  Perhaps unfortunately, it
> lacks a single standard glyph set or graphic representation., but I believe
> Unicode also differentiates between characters (code points?) and glyphs
> (which are also not standardized).  

Yes. But Unicode does define concrete characters - even if it leaves
the choice of glyphs.

Regards,
Martin


From dave at boost-consulting.com  Wed Jun 30 13:27:19 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed Jun 30 13:27:30 2004
Subject: [Python-Dev] Re: PEP 276 (simple iterator for ints)
In-Reply-To: <000001c45ec3$1154cba0$6602a8c0@arkdesktop> (Andrew Koenig's
	message of "Wed, 30 Jun 2004 12:55:37 -0400")
References: <000001c45ec3$1154cba0$6602a8c0@arkdesktop>
Message-ID: <ubrj1hs7c.fsf@boost-consulting.com>

"Andrew Koenig" <ark-mlist@att.net> writes:

>> ?? Simple Iterator For Ints ??
>> http://www.python.org/peps/pep-0276.html
>> Are you sure you mean 276?
>
> Yes, I'm sure.  The proposal is that if n is an integer, iter(n) should
> iterate over the elements of range(n).

I understood that; I don't see how you connect that with sets.Set(42).
I don't see the word "set" anywhwere in that pep.

call-me-dim-ly y'rs,
Dave


From ark-mlist at att.net  Wed Jun 30 13:31:07 2004
From: ark-mlist at att.net (Andrew Koenig)
Date: Wed Jun 30 13:31:09 2004
Subject: [Python-Dev] Re: PEP 276 (simple iterator for ints)
In-Reply-To: <ubrj1hs7c.fsf@boost-consulting.com>
Message-ID: <000101c45ec8$07165230$6602a8c0@arkdesktop>

> > Yes, I'm sure.  The proposal is that if n is an integer, iter(n) should
> > iterate over the elements of range(n).
> 
> I understood that; I don't see how you connect that with sets.Set(42).
> I don't see the word "set" anywhwere in that pep.

The connection is that sets.Set will accept an iterator as its argument, so
if integers become iterators, sets.Set(42) should work.


From ncoghlan at iinet.net.au  Wed Jun 30 14:02:59 2004
From: ncoghlan at iinet.net.au (Nick Coghlan)
Date: Wed Jun 30 14:03:03 2004
Subject: [Python-Dev] Re: PEP 276 (simple iterator for ints)
In-Reply-To: <uy8m5hv5d.fsf@boost-consulting.com>
References: <000c01c45eb9$2df5a310$6602a8c0@arkdesktop>
	<uy8m5hv5d.fsf@boost-consulting.com>
Message-ID: <40E30053.5020900@iinet.net.au>

(Accidentally sent this just to David instead of py-dev. Although Andrew 
has since clarified that the Set constructor actually accepts an 
iterable directly. And in that case, his magic would probably work 
_regardless_ of how PEP-276 was implemented behind the scenes. Something 
about this aspect of the PEP doesn't sit well with me. . .)

David Abrahams wrote:
> "Andrew Koenig" <ark@acm.org> writes:
> 
> 
>>I happened to look at PEP 276 and was struck by the thought that PEP 276 is
>>really an implementation of the well-known set-theoretic construction of the
>>natural numbers that defines each natural number as the set of all smaller
>>ones.  In other words, it defines 0 as the empty set, 1 as the set whose
>>only element is 0, 2 as the set whose elements are 0 and 1, and so on.
>>
>>Indeed, under PEP 276, sets.Set(42) would be a set with 42 elements that
>>would be exactly the canonical representation of 42.
> 
> 
> ?? Simple Iterator For Ints ?? 
> http://www.python.org/peps/pep-0276.html
> Are you sure you mean 276?
> 

I think he does.

Although I think to get the set Andrew wanted with an int type sporting
an __iter__ method, you would need to write sets.Set(*42), rather than
just writing '42' on its own.

Which actually suggests strongly to me that if PEP-276 were to be
implemented, it should be done by special casing ints in for-loop
generation rather than by having ints support the iterator protocol. Far
  too much potential for cryptic usage of the latter approach!

And you could still get the set-theoretic representation using a
generator expression: sets.Set(x for x in 42)

Cheers.
Nick.

-- 
Nick Coghlan               |     Brisbane, Australia
Email: ncoghlan@email.com  | Mobile: +61 409 573 268



From arigo at tunes.org  Wed Jun 30 14:18:32 2004
From: arigo at tunes.org (Armin Rigo)
Date: Wed Jun 30 14:21:05 2004
Subject: [Python-Dev] Revised Proposal: thread.get_dict
In-Reply-To: <40E2CD1A.8080602@zope.com>
References: <40E03020.7010101@zope.com> <40E2CD1A.8080602@zope.com>
Message-ID: <20040630181832.GA28162@vicky.ecs.soton.ac.uk>

Hello Jim,

On Wed, Jun 30, 2004 at 10:24:26AM -0400, Jim Fulton wrote:
> Here is a demonstration Python implementation:
> 
>   from threading import currentThread
> 
>   class local(object):
>
>     ...

The instance should clear the entry from all the per-thread dictionaries when
it is deallocated, to prevent data from outliving it -- and also to prevent
accidental reuse of the same data by a future instance.


Descriptor fun!  I think there is a way to write this class so that "regular"
attributes like __class__ still work, and without having to special-case
__dict__.  Something along the lines of:

    def __patch(self):
        key = "thread-local-%x" % id(self)
        d = currentThread().__dict__.setdefault(key, {})
        object.__setattr__(self, '__dict__', d)

    def __getattribute__(self, name):
        self.__patch()
        return super(local, self).__getattribute__(name)

    def __setattr__(self, name, value):
        self.__patch()
        super(local, self).__setattr__(name, value)

I am unclear about how C types should do the equivalent of the 'super' call,
though.  But I'm ok with declaring that we don't care and use
PyObject_Generic[GS]etAttr().


Finally, don't forget __delattr__.


A bient?t,

Armin.

From edloper at gradient.cis.upenn.edu  Wed Jun 30 15:16:38 2004
From: edloper at gradient.cis.upenn.edu (Edward Loper)
Date: Wed Jun 30 15:15:50 2004
Subject: [Python-Dev] Re: Revised Proposal: thread.get_dict
Message-ID: <40E31196.7040807@gradient.cis.upenn.edu>

Is this also intended for use as a base class?  In particular, it seems 
like if I have a class Foo, then I can make a thread-local version with 
the following (as long as Foo doesn't rely on overriding 
__getattribute__/__setattr__).

    class LocalFoo(local, Foo): pass

Is that right?  (I can see how it works in the Python implementation, 
but don't know enough about extensions to see if that translates 
directly to the c implementation.)

Actually, does local.__init__() need a call to super(self, 
local).__init__() to make this work?

-Edward

From jim at zope.com  Wed Jun 30 15:16:37 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Jun 30 15:16:43 2004
Subject: [Python-Dev] Revised Proposal: thread.get_dict
In-Reply-To: <20040630181832.GA28162@vicky.ecs.soton.ac.uk>
References: <40E03020.7010101@zope.com> <40E2CD1A.8080602@zope.com>
	<20040630181832.GA28162@vicky.ecs.soton.ac.uk>
Message-ID: <40E31195.3@zope.com>

Armin Rigo wrote:
> Hello Jim,
> 
> On Wed, Jun 30, 2004 at 10:24:26AM -0400, Jim Fulton wrote:
> 
>>Here is a demonstration Python implementation:
>>
>>  from threading import currentThread
>>
>>  class local(object):
>>
>>    ...
> 
> 
> The instance should clear the entry from all the per-thread dictionaries when
> it is deallocated,

Ugh.  Now you want me to work hard. ;)

...

> 
> Descriptor fun!  I think there is a way to write this class so that "regular"
> attributes like __class__ still work, and without having to special-case
> __dict__.  Something along the lines of:
> 
>     def __patch(self):
>         key = "thread-local-%x" % id(self)
>         d = currentThread().__dict__.setdefault(key, {})
>         object.__setattr__(self, '__dict__', d)
> 
>     def __getattribute__(self, name):
>         self.__patch()
>         return super(local, self).__getattribute__(name)
> 
>     def __setattr__(self, name, value):
>         self.__patch()
>         super(local, self).__setattr__(name, value)
> 
> I am unclear about how C types should do the equivalent of the 'super' call,
> though.  But I'm ok with declaring that we don't care and use
> PyObject_Generic[GS]etAttr().

Note that this makes it go somewhat slower, since we now have to
search the class dictionary as well as the instance dictonary.
I don't think it's worth it to avoid special handling for __dict__
and __class__.

This approach *does* provide the benefit that you can subclass
thead.local to ad default values, methods, and descriptors, which
I think could be very useful. I'll investigate this.

The easiest way to do this in C will be to have different logic
for the base class and for subclasses.  For the base class,
I'll do what I'm doing now (adding handling for __class__).
For subclasses, I'll do what you suggest. This mans that
simple usages of the base class don't get the extra performance
hit.

> 
> Finally, don't forget __delattr__.

Yup.

Thanks.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From jim at zope.com  Wed Jun 30 15:21:38 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Jun 30 15:21:41 2004
Subject: [Python-Dev] Re: Revised Proposal: thread.get_dict
In-Reply-To: <40E31196.7040807@gradient.cis.upenn.edu>
References: <40E31196.7040807@gradient.cis.upenn.edu>
Message-ID: <40E312C2.5020603@zope.com>

Edward Loper wrote:
> Is this also intended for use as a base class? 

With Amin's latest sugestion, yes.  That is the
real win with his suggestion.

 > In particular, it seems
> like if I have a class Foo, then I can make a thread-local version with 
> the following (as long as Foo doesn't rely on overriding 
> __getattribute__/__setattr__).
> 
>    class LocalFoo(local, Foo): pass
> 
> Is that right?  (I can see how it works in the Python implementation, 
> but don't know enough about extensions to see if that translates 
> directly to the c implementation.)

Yup

> Actually, does local.__init__() need a call to super(self, 
> local).__init__() to make this work?

Init gets pretty weird for thread-local objects.  You sort of
want to run __init__ (if there is one) every time you compute a
dict for a thread.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From pedronis at bluewin.ch  Wed Jun 30 15:45:31 2004
From: pedronis at bluewin.ch (Samuele Pedroni)
Date: Wed Jun 30 15:44:39 2004
Subject: [Python-Dev] Revised Proposal: thread.get_dict
In-Reply-To: <20040630181832.GA28162@vicky.ecs.soton.ac.uk>
References: <40E2CD1A.8080602@zope.com> <40E03020.7010101@zope.com>
	<40E2CD1A.8080602@zope.com>
Message-ID: <5.2.1.1.0.20040630214302.03170848@pop.bluewin.ch>

At 19:18 30.06.2004 +0100, Armin Rigo wrote:
>Hello Jim,
>
>On Wed, Jun 30, 2004 at 10:24:26AM -0400, Jim Fulton wrote:
> > Here is a demonstration Python implementation:
> >
> >   from threading import currentThread
> >
> >   class local(object):
> >
> >     ...
>
>The instance should clear the entry from all the per-thread dictionaries when
>it is deallocated, to prevent data from outliving it -- and also to prevent
>accidental reuse of the same data by a future instance.
>
>
>Descriptor fun!  I think there is a way to write this class so that "regular"
>attributes like __class__ still work, and without having to special-case
>__dict__.  Something along the lines of:
>
>     def __patch(self):
>         key = "thread-local-%x" % id(self)
>         d = currentThread().__dict__.setdefault(key, {})
>         object.__setattr__(self, '__dict__', d)
>
>     def __getattribute__(self, name):
>         self.__patch()
>         return super(local, self).__getattribute__(name)

I'm puzzled, is this thread-safe?


From mchermside at ingdirect.com  Wed Jun 30 16:31:51 2004
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Wed Jun 30 16:31:56 2004
Subject: [Python-Dev] PEP 276 (simple iterator for ints)
Message-ID: <0CFFADBB825C6249A26FDF11C1772AE1550AF4@ingdexj1.ingdirect.com>

Andrew Koenig writes:
> I happened to look at PEP 276 and was struck by the thought 
> that PEP 276 is
> really an implementation of the well-known set-theoretic 
> construction of the
> natural numbers that defines each natural number as the set 
> of all smaller
> ones.  In other words, it defines 0 as the empty set, 1 as 
> the set whose
> only element is 0, 2 as the set whose elements are 0 and 1, and so on.

Interesting. I suppose that could be added as an extra argument
against those who claim that [0,1,2,3,4,5] is *NOT* the sequence
of integers "obviously" associated with the number 6. As for me,
even before I started using Python I had already become convinced
of that.

PEP 276 is worth a second look. In fact, it's trivial to
implement, and what it REALLY needs is a champion to bring it up
with the BDFL (and others).

Seriously, folks, replacing every one of these:

    >>> for i in range(len(myList)):
    ...     doSomethingWithIndexes(i)

with this:

    >>> for i in len(myList):
    ...     doSomethingWithIndexes(i)

is simple and elegant. And while at first glance it seems like
allowing iteration over ints would open up all kinds of subtle
bugs, I find that the PEP does a good job of arguing that it
doesn't.

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.


From jim at zope.com  Wed Jun 30 16:53:44 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Jun 30 16:53:49 2004
Subject: [Python-Dev] Version 3 Proposal: thread-local data
In-Reply-To: <40E03020.7010101@zope.com>
References: <40E03020.7010101@zope.com>
Message-ID: <40E32858.2020505@zope.com>

(Changes from previous version:

   - Changed subject line

   - Added subclassability

   - Added cleanup of thread data on destruction

)

We often want to associate data with threads.  Python
manages a dictionary per-tread for this purpose, but there's
currently no way to get to this dictionary from Python.

I propose, for 2.4, to add a "local" class to the threading
module (and dummy_threading module) for creating
thread-local objects.  I'll provide both Python and
C implementations.

Here is proposed documentation (and test:) for the class:

"""Thread-local objects

Thread-local objects support the management of thread-local data.
If you have data that you want to be local to a thread, simply create
a thread-local object and use it's attributes:

   >>> import threading
   >>> mydata = threading.local()
   >>> mydata.__class__.__name__
   'local'
   >>> mydata.number = 42
   >>> mydata.number
   42

You can also access the local-object's dictionary:

   >>> mydata.__dict__
   {'number': 42}
   >>> mydata.__dict__.setdefault('widgets', [])
   []
   >>> mydata.widgets
   []

What's important about thread-local objects is that their data are
local to a thread. If we access the data in a different thread:

   >>> log = []
   >>> def f():
   ...     log.append(mydata.__dict__.items())
   ...     mydata.number = 11
   ...     log.append(mydata.number)

   >>> import threading
   >>> thread = threading.Thread(target=f)
   >>> thread.start()
   >>> thread.join()
   >>> log
   [[], 11]

we get different data.  Furthermore, changes made in the other thread
don't affect data seen in this thread:

   >>> mydata.number
   42

Of course, values you get from a local object, including a __dict__
attribute, are for whatever thread was current at the time the
attribute was read.  For that reason, you generally don't want to save
these values across threads, as they apply only to the thread they
came from.

You can create custom local objects by subclassing the local class:

   >>> class MyLocal(threading.local):
   ...     number = 2
   ...     def __init__(self, **kw):
   ...         self.__dict__.update(kw)
   ...     def squared(self):
   ...         return self.number ** 2

This can be useful to support default values, methods and
initialization.  Note that if you define an __init__ method, it will be
called each time the local object is used in a separate thread.  This
is necessary to initialize each thread's dictionary.

Now if we create a local object:

   >>> mydata = MyLocal(color='red')

Now we have a default number:

   >>> mydata.number
   2

an initial color:

   >>> mydata.color
   'red'
   >>> del mydata.color

And a method that operates on the data:

   >>> mydata.squared()
   4

As before, we can access the data in a separate thread:

   >>> log = []
   >>> thread = threading.Thread(target=f)
   >>> thread.start()
   >>> thread.join()
   >>> log
   [[('color', 'red')], 11]

without effecting this threads data:

   >>> mydata.number
   2
   >>> mydata.color
   Traceback (most recent call last):
   ...
   AttributeError: 'MyLocal' object has no attribute 'color'

Note that subclasses can define slots, but slots are shared across
threads. Only the instance dictionary is thread local.

"""


Here is a demonstration Python implementation:

     from threading import currentThread, enumerate

     class _localbase(object):
         __slots__ = '_local__key', '_local__args'

         def __new__(cls, *args, **kw):
             self = object.__new__(cls)
             key = '_local__key', 'thread.local.' + str(id(self))
             object.__setattr__(self, '_local__key', key)
             object.__setattr__(self, '_local__args', (args, kw))

             if args or kw and (cls.__init__ is object.__init__):
                 raise TypeError("Initialization arguments are not supported")

             return self

     def _patch(self):
         key = object.__getattribute__(self, '_local__key')
         d = currentThread().__dict__.get(key)
         if d is None:
             d = {}
             currentThread().__dict__[key] = d
             object.__setattr__(self, '__dict__', d)

             # we have a new instance dict, so call out __init__ if we have
             # one
             cls = type(self)
             if cls.__init__ is not object.__init__:
                 args, kw = object.__getattribute__(self, '_local__args')
                 cls.__init__(self, *args, **kw)
         else:
             object.__setattr__(self, '__dict__', d)

     class local(_localbase):

         def __getattribute__(self, name):
             _patch(self)
             return object.__getattribute__(self, name)

         def __setattr__(self, name, value):
             _patch(self)
             return object.__setattr__(self, name, value)

         def __delattr__(self, name):
             _patch(self)
             return object.__delattr__(self, name)

         def __del__(self):
             key = object.__getattribute__(self, '_local__key')
             for thread in enumerate():
                 if key in thread.__dict__:
                     del thread.__dict__[key]

Any objections? Any more tricks up your sleeve Armin? :)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From jcarlson at uci.edu  Wed Jun 30 16:50:38 2004
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed Jun 30 16:56:47 2004
Subject: [Python-Dev] PEP 276 (simple iterator for ints)
In-Reply-To: <0CFFADBB825C6249A26FDF11C1772AE1550AF4@ingdexj1.ingdirect.com>
References: <0CFFADBB825C6249A26FDF11C1772AE1550AF4@ingdexj1.ingdirect.com>
Message-ID: <20040630134220.780A.JCARLSON@uci.edu>


> Interesting. I suppose that could be added as an extra argument
> against those who claim that [0,1,2,3,4,5] is *NOT* the sequence
> of integers "obviously" associated with the number 6. As for me,
> even before I started using Python I had already become convinced
> of that.
> 
> PEP 276 is worth a second look. In fact, it's trivial to
> implement, and what it REALLY needs is a champion to bring it up
> with the BDFL (and others).
[snip example]
> is simple and elegant. And while at first glance it seems like
> allowing iteration over ints would open up all kinds of subtle
> bugs, I find that the PEP does a good job of arguing that it
> doesn't.


While PEP 276 attempts to make easier the most common iteration over
integers (half open, 0...n-1), PEP 284 takes care of general iteration
over integers (a...b, for arbitrary integer a and b, incrementing or
decrementing as necessary).

In this case, does practicality (usable for more integer iteration
scenarios) outweigh the purity (integer fields/list indices)?

 - Josiah


From fdrake at acm.org  Wed Jun 30 17:05:30 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed Jun 30 17:05:44 2004
Subject: [Python-Dev] making weakref.ref objects subclassable
Message-ID: <200406301705.31590.fdrake@acm.org>

I'm planning to commit a patch (http://www.python.org/sf/983019) that makes 
weak references subclassable.  This includes the following changes:

- weakref.ref and weakref.ReferenceType will become aliases for each other

- weakref.ref will be a modern, new-style class with proper __new__ and 
__init__ methods

- weakref.WeakValueDictionary will have a lighter memory footprint, using a 
new weakref.ref subclass to associate the key with the value, allowing us to 
have only a single object of overhead for each dictionary entry (currently, 
there are 3 objects of overhead per entry: a weakref to the value, a weakref 
to the dictionary, and a function object used as a weakref callback; the 
weakref to the dictionary could be avoided without this change)

- a new macro, PyWeakref_CheckRefExact(), will be added

- PyWeakref_CheckRef() will check for subclasses of weakref.ref

- the cyclic garbage detector will be affected by the change to 
PyWeakref_CheckRef(); it will potentially call issubtype() for objects in the 
unreachable list that do not have finalizers (in the move_troublemakers() 
function).  This should only happen for weakref objects which are not of one 
of the "standard" three types (ref, proxy, and callable proxy).  For debug 
builds, it will also affect assertions in the clear_weakerfs() and 
release_weakrefs() functions.

The change to the  cyclic garbage detector probably carries the most risk, and 
that only because the potential for a performance penalty.  Running the Zope 
3 test suite did not show any clear change in performance, and a key 
subsystem in Zope (zope.interface) uses weakrefs extensively.


  -Fred

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


From greg at electricrain.com  Wed Jun 30 18:52:14 2004
From: greg at electricrain.com (Gregory P. Smith)
Date: Wed Jun 30 18:52:17 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <5.2.0.9.0.20040630082845.0294ecf0@pop.sbcglobal.yahoo.com>
References: <5.2.0.9.0.20040629125948.0292a5a0@pop.sbcglobal.yahoo.com>
	<1088534421.27300.153.camel@localhost>
	<005001c45da1$cfb9e1c0$e841fea9@oemcomputer>
	<1088534421.27300.153.camel@localhost>
	<5.2.0.9.0.20040629125948.0292a5a0@pop.sbcglobal.yahoo.com>
	<5.2.0.9.0.20040630082845.0294ecf0@pop.sbcglobal.yahoo.com>
Message-ID: <20040630225214.GW11545@zot.electricrain.com>

> >Unfortunately, distributing crypto software is still a hideous
> >international mess (just because the *US* is less silly these
> >days...).
> 
> Things have been liberalizing rapidly.  I'm not sure how true that is 
> anymore, though I don't have direct experience (aside from offering some 
> crypto software on a website; people download it from all over the place, 
> but maybe they're scofflaws, who knows).
> 
> I know US export is no problem.  According to [1], most countries have no 
> laws restricting imports, with the notable exception of ex-USSR countries 
> and China, which require licenses.  I've heard anecdotally the Russian 
> requirements are mostly ignored [2].  I don't know about China.
> 
> More anecdotal evidence: The windows python installer includes strong 
> crypto (SSL).  Has that caused problems?

Agreed.  Python already includes crypto and US export is nothing more
than a harmless "let US Dept of Whateveritscalledtoday know that X has
crypto in it."  the bsddb module includes encrypted database support in
it (unless the windows packager has been building the non crypto version
of the library distributed by sleepycat; i haven't checked).

The point about SSL being included is interesting.  The OpenSSL library
provides implementations of all of the important hash algorithms (and
uses them in order to implement ssl!).  Its hashing code is much better
optimized on various architectures than the python module ever will
be.  I just filed feature request 983069 to keep this on the radar.

> There's protocols that can use SHA-256, like SSH, S/MIME, or PGP, but these 
> all require other crypto primitives, so your point stands.  And I 
> agree:  crypto primitives should probably be considered as a lump.  If 
> ciphers are absolutely not going to get in, putting in other crypto stuff 
> is not that helpful..

To waffle on my earlier question of "what uses sha256 w/o also needing
crypto?"...  One reason I can see for adding sha-256 and sha-512 (and
224/384 wrappers) to standard python is that they will potentially be
used in future distributed data storage and p2p protocols for large data
set integrity checking.

-g


From greg at cosc.canterbury.ac.nz  Wed Jun 30 22:17:15 2004
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Wed Jun 30 22:17:23 2004
Subject: [Python-Dev] PEP 276 (simple iterator for ints)
In-Reply-To: <0CFFADBB825C6249A26FDF11C1772AE1550AF4@ingdexj1.ingdirect.com>
Message-ID: <200407010217.i612HFU5007069@cosc353.cosc.canterbury.ac.nz>

"Chermside, Michael" <mchermside@ingdirect.com>:

>     >>> for i in len(myList):
>     ...     doSomethingWithIndexes(i)
> 
> is simple and elegant.

IMO it would be clearer, and equally elegant, to write
this as something like

  for i in indices(myList):
    ...

which is easily accomplished with the aid of a suitable
definition for indices(). No language changes needed.

I suspect most people other than number theorists would
find the concept of a set of integers being contained
in another integer quite wierd.

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

From tim.peters at gmail.com  Wed Jun 30 22:55:06 2004
From: tim.peters at gmail.com (Tim Peters)
Date: Wed Jun 30 23:21:52 2004
Subject: [Python-Dev] SHA-256 module
In-Reply-To: <20040630225214.GW11545@zot.electricrain.com>
References: <5.2.0.9.0.20040629125948.0292a5a0@pop.sbcglobal.yahoo.com>
	<1088534421.27300.153.camel@localhost>
	<005001c45da1$cfb9e1c0$e841fea9@oemcomputer>
	<1088534421.27300.153.camel@localhost>
	<5.2.0.9.0.20040629125948.0292a5a0@pop.sbcglobal.yahoo.com>
	<5.2.0.9.0.20040630082845.0294ecf0@pop.sbcglobal.yahoo.com>
	<20040630225214.GW11545@zot.electricrain.com>
Message-ID: <1f7befae040630195552738a9d@mail.gmail.com>

[Gregory P. Smith]
> ...
>  the bsddb module includes encrypted database support in it (unless the
> windows packager has been building the non crypto version of the library
> distributed by sleepycat; i haven't checked).

The Windows installer does ship the non-crypto version of Sleepcat
Berkeley DB.  There was no debate about that, it was just the easiest
thing to do at the time.  For the same "reason", the Windows installer
doesn't ship any of the auxiliary BDB tools either ... it's the
laziest packaging of bsddb that allowed the test suite to pass. 
Improving this story.would probably require a volunteer who actually
knows something about BDB.

From janssen at parc.com  Wed Jun 30 23:21:28 2004
From: janssen at parc.com (Bill Janssen)
Date: Wed Jun 30 23:22:03 2004
Subject: [Python-Dev] Allowing u.encode() to return non-strings 
In-Reply-To: Your message of "Tue, 29 Jun 2004 23:15:43 PDT."
	<40E25A8F.80505@v.loewis.de> 
Message-ID: <04Jun30.202138pdt."58612"@synergy1.parc.xerox.com>

Tim,

Thanks for pointing this out.  I find it very hard to know that from
any of the documentation, unless of course you already know it, in
which case you don't need the documentation :-).  In particular, I'd
suggest adding some text to the documentation on codecs.open() which
points out that read and readlines and friends will in fact return
Unicode objects.

I assume, though, that the args to "read()" and friends are still
about bytes.

>> Any file that is not explicitly opened as binary (with the 'b' flag
>> (and, by the way, why isn't the 'b' flag the default for file opening?

> Because it isn't in C.

That's probably why Python doesn't have list comprehensions, either :-).

Bill



From tim.one at comcast.net  Wed Jun 30 23:46:03 2004
From: tim.one at comcast.net (Tim Peters)
Date: Wed Jun 30 23:46:20 2004
Subject: [Python-Dev] making weakref.ref objects subclassable
Message-ID: <mailman.31.1088653580.9339.python-dev@python.org>

[Fred L. Drake, Jr.]
> I'm planning to commit a patch (http://www.python.org/sf/983019) that
> makes weak references subclassable.  This includes the following changes:
> 
> ...
> - the cyclic garbage detector will be affected by the change to
> PyWeakref_CheckRef(); it will potentially call issubtype() for objects in
> the unreachable list that do not have finalizers (in the
> move_troublemakers() function).  This should only happen for weakref
> objects which are not of one of the "standard" three types (ref, proxy,
> and callable proxy).

I think the new expense is actually that PyType_IsSubtype() will get called 
once per collection on each scanned object that is unreachable, doesn't have

a finalizer, and isn't of one of the three std weakref types (not just for 
weakref objects that aren't of one of the std weakref types -- it's all 
objects that aren't of one of the std weakref types).

But that isn't scary.  An object is typically unreachable exactly once in
its lifetime (so far as gc is concerned), so it's one measly extra 
PyType_IsSubtype() call over the lifetime of each non-std-weakref container 
object without a finalizer, and that is reclaimed by virtue of ending up in
a dead cycle, or reachable only from a dead cycle.  Most container objects 
continue to get reclaimed via refcounting (the patch has no effect on that),

so are never found to be unreachable by gc, and so never incur the trivial-
anyway new call to PyType_IsSubtype().

> ...
> The change to the  cyclic garbage detector probably carries the most risk,

Well, there is no change to gcmodule.c, except for the indirect change in 
what the PyWeakref_Check() macro expands to.  The risks with weakrefs 
historically lie elsewhere (in the weakref code itself, and in typeobject.c 
-- gc had horrible problems with weakrefs when it didn't do anything special

with them, but that was really just one bug-- a massive oversight --and
we've had no additional problems with weakrefs in gc since repairing that
oversight).

> and that only because the potential for a performance penalty.  Running
> the  Zope 3 test suite did not show any clear change in performance, and
> a key subsystem in Zope (zope.interface) uses weakrefs extensively.

For reasons given above, I believe gc performance will be virtually
unchanged for almost all programs.



From python at rcn.com  Wed Jun 30 19:57:17 2004
From: python at rcn.com (Raymond Hettinger)
Date: Thu Jul  1 07:58:10 2004
Subject: [Python-Dev] Re: [Python-checkins] python/nondist/sandbox/decimal
	Decimal.py, 1.37, 1.38
In-Reply-To: <40E3F8B6.6010403@egenix.com>
Message-ID: <00a501c45efd$f9c9b820$e841fea9@oemcomputer>

> rhettinger@users.sourceforge.net wrote:
> > Update of /cvsroot/python/python/nondist/sandbox/decimal
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22541
> >
> > Modified Files:
> > 	Decimal.py
> >   #       rename Decimal.py and test_Decimal.py to lowercase decimal
> >   #       retarget the test directory to decimaltestdata
> 
> Shouldn't these steps be applied *before* adding it to the
> core lib ?

Done *during* the move to the core.
It should all be fine now.


Raymond


From stephan.richter at tufts.edu  Wed Jun 30 15:09:56 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Thu Jul  1 08:13:24 2004
Subject: [Python-Dev] Including translated doc strings in 2.4
In-Reply-To: <1088605153.7378.84.camel@localhost>
References: <40D5C17C.2010008@v.loewis.de> <40E26254.6000903@interlink.com.au>
	<1088605153.7378.84.camel@localhost>
Message-ID: <200406301509.56390.stephan.richter@tufts.edu>

On Wednesday 30 June 2004 10:19, Barry Warsaw wrote:
> > msg-catalogs? gettext-mo? Using a '-' in the name is, to me, a
> > pretty clear sign that the thing is not a python package that can
> > be imported...
>
> I don't have any better ideas, and I don't really see a good use case
> for making this a package, so Anthony's suggestion seems reasonable.
> gettext-catalogs or any variation thereof seems fine to me.

The standard directory for gettext files is "locales".

Regards,
Stephan 
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training