From amauryfa at gmail.com  Fri Aug  1 01:04:50 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Fri, 1 Aug 2008 01:04:50 +0200
Subject: [Python-3000] MemoryError oddities
In-Reply-To: <g62ke1$45m$1@ger.gmane.org>
References: <g62ke1$45m$1@ger.gmane.org>
Message-ID: <e27efe130807311604k7684a357pf15fb79954e93b5@mail.gmail.com>

2008/7/21 Georg Brandl <g.brandl at gmx.net>:
>>>> b"a"*sys.maxsize
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> MemoryError
> [41297 refs]
>>>> b"a"*sys.maxsize
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "<stdin>", line 1, in <module>
> MemoryError
> [41317 refs]
>>>> b"a"*sys.maxsize
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "<stdin>", line 1, in <module>
>  File "<stdin>", line 1, in <module>
> MemoryError
> [41337 refs]
>
> This probably has to do with the fact that this MemoryError is a prebuilt
> instance.

I corrected this with r65341.
But this prebuilt MemoryError has another nasty consequence:
when PyErr_NoMemory is raised, the traceback is attached to the
prebuilt object,
and all local variables of the failing procedure are still referenced
and will not be freed.

This seems to defeat the purpose of the prebuilt MemoryError...

-- 
Amaury Forgeot d'Arc

From solipsis at pitrou.net  Fri Aug  1 01:40:58 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 31 Jul 2008 23:40:58 +0000 (UTC)
Subject: [Python-3000] MemoryError oddities
References: <g62ke1$45m$1@ger.gmane.org>
	<e27efe130807311604k7684a357pf15fb79954e93b5@mail.gmail.com>
Message-ID: <loom.20080731T233707-907@post.gmane.org>

Amaury Forgeot d'Arc <amauryfa <at> gmail.com> writes:
> 
> I corrected this with r65341.
> But this prebuilt MemoryError has another nasty consequence:
> when PyErr_NoMemory is raised, the traceback is attached to the
> prebuilt object,
> and all local variables of the failing procedure are still referenced
> and will not be freed.

I suppose this prebuilt MemoryError isn't very multithreading-friendly either...
How about using a preallocated freelist scheme instead?




From musiccomposition at gmail.com  Fri Aug  1 01:48:32 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 31 Jul 2008 18:48:32 -0500
Subject: [Python-3000] is it easier to multithread ?
In-Reply-To: <e7f3ad37-e1de-4723-8cda-4704dd3f3108@l33g2000pri.googlegroups.com>
References: <e7f3ad37-e1de-4723-8cda-4704dd3f3108@l33g2000pri.googlegroups.com>
Message-ID: <1afaf6160807311648k55f0e8cta8706694472f9514@mail.gmail.com>

On Thu, Jul 31, 2008 at 10:18 AM, binaryjesus <coolman.guron at gmail.com> wrote:
> Is these any improvement in multi-threaded performance in the py3k
> scheduler over py2?

No. However, 2.6 and 3.0 have gained the multiprocessing module to do
concurrency over multiply processes.

> >From what i know py2 runs only 1 (one) pythn thread at a time (refer 1
> below).  Another thing that i would like to see being included in
> python is auto-mutex like the java implementation. That would make my
> life much easier !!
>
> Binaryjesus-
>
> refer1 : http://softwareramblings.com/2008/07/multi-thread-scaling-issues-with-python-and-ruby.html
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From josiah.carlson at gmail.com  Fri Aug  1 02:16:55 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Thu, 31 Jul 2008 17:16:55 -0700
Subject: [Python-3000] is it easier to multithread ?
In-Reply-To: <e7f3ad37-e1de-4723-8cda-4704dd3f3108@l33g2000pri.googlegroups.com>
References: <e7f3ad37-e1de-4723-8cda-4704dd3f3108@l33g2000pri.googlegroups.com>
Message-ID: <e6511dbf0807311716n28da6eb9h6b85e3ec0a651298@mail.gmail.com>

On Thu, Jul 31, 2008 at 8:18 AM, binaryjesus <coolman.guron at gmail.com> wrote:
> Is these any improvement in multi-threaded performance in the py3k
> scheduler over py2?
> >From what i know py2 runs only 1 (one) pythn thread at a time (refer 1
> below).  Another thing that i would like to see being included in
> python is auto-mutex like the java implementation. That would make my
> life much easier !!

Things have not changed with regards to Python's threading
implementation in py3k.

If you want auto-locking with function calls, there isn't a keyword
that you can just pass, but there are these magical things called
decorators that allow the easy creation of synchronized decorators...

import threading

_lock = threading.RLock()
def synchronized(fcn):
    def call(*args, **kwargs):
        with _lock:
            return fcn(*args, **kwargs)
    return call


Used like:

class foo:
    @synchronized
    def method(self, ...):
        #because of the synchronized decorator, this method is now
protected by a lock

 - Josiah

From abpillai at gmail.com  Fri Aug  1 15:57:38 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Fri, 1 Aug 2008 19:27:38 +0530
Subject: [Python-3000] Providing compress/uncompress functions in gzip
Message-ID: <8548c5f30808010657l5d6dc57dw8698d83103d2d399@mail.gmail.com>

Python has great in-built support for all sorts of text compression
including bzip, gzip, tarfile and other general purpose modules like
zlib etc.

Of these, I have a gripe with gzip - it does not provide a simple
way of compressing/uncompressing a string like the other modules
to (namely bzip, zlib) at the module level.

It is relatively easy to perform gzip de-compression using the
GzipFile class and StringIO objects, but compression is not
that straight-forward.

It would be great for the gzip module to have "compress"
and "uncompress" functions at the module level without having
to go through GzipFile every-time.

If it is not too late in the dev-cycle, please consider this.

Thanks

-- 
-Anand

From phd at phd.pp.ru  Fri Aug  1 16:02:25 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Fri, 1 Aug 2008 18:02:25 +0400
Subject: [Python-3000] Providing compress/uncompress functions in gzip
In-Reply-To: <8548c5f30808010657l5d6dc57dw8698d83103d2d399@mail.gmail.com>
References: <8548c5f30808010657l5d6dc57dw8698d83103d2d399@mail.gmail.com>
Message-ID: <20080801140225.GB2177@phd.pp.ru>

On Fri, Aug 01, 2008 at 07:27:38PM +0530, Anand Balachandran Pillai wrote:
> Of these, I have a gripe with gzip - it does not provide a simple
> way of compressing/uncompressing a string

   It does. It is zlib.compress() and zlib.decompress().

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From abpillai at gmail.com  Fri Aug  1 16:07:09 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Fri, 1 Aug 2008 19:37:09 +0530
Subject: [Python-3000] Providing compress/uncompress functions in gzip
In-Reply-To: <20080801140225.GB2177@phd.pp.ru>
References: <8548c5f30808010657l5d6dc57dw8698d83103d2d399@mail.gmail.com>
	<20080801140225.GB2177@phd.pp.ru>
Message-ID: <8548c5f30808010707w28df88b6w5d8befbe07708a61@mail.gmail.com>

On Fri, Aug 1, 2008 at 7:32 PM, Oleg Broytmann <phd at phd.pp.ru> wrote:
> On Fri, Aug 01, 2008 at 07:27:38PM +0530, Anand Balachandran Pillai wrote:
>> Of these, I have a gripe with gzip - it does not provide a simple
>> way of compressing/uncompressing a string
>
>   It does. It is zlib.compress() and zlib.decompress().

Yes, I know gzip uses zlib for performing compression. But
zlib.compress does not return a string which can be de-compressed
using gzip directly, because the gzip headers are missing.

>>> import gzip
>>> import zlib
>>> s='This is a line of text'
>>> sc=zlib.compress(s)
>>> g=gzip.GzipFile(fileobj=cStringIO.StringIO(sc))
>>> print g.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/gzip.py", line 218, in read
    self._read(readsize)
  File "/usr/lib/python2.4/gzip.py", line 261, in _read
    self._read_gzip_header()
  File "/usr/lib/python2.4/gzip.py", line 162, in _read_gzip_header
    raise IOError, 'Not a gzipped file'
IOError: Not a gzipped file

I think being able to send gzip compressed strings directly would be useful
for applications which require to send gzip data over the wire without
having to write to files and read-back.

>
> Oleg.
> --
>     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
>           Programmers don't die, they just GOSUB without RETURN.
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/abpillai%40gmail.com
>



-- 
-Anand

From solipsis at pitrou.net  Fri Aug  1 17:30:24 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 1 Aug 2008 15:30:24 +0000 (UTC)
Subject: [Python-3000] Providing compress/uncompress functions in gzip
References: <8548c5f30808010657l5d6dc57dw8698d83103d2d399@mail.gmail.com>
	<20080801140225.GB2177@phd.pp.ru>
	<8548c5f30808010707w28df88b6w5d8befbe07708a61@mail.gmail.com>
Message-ID: <loom.20080801T152935-560@post.gmane.org>

Anand Balachandran Pillai <abpillai <at> gmail.com> writes:
> 
> I think being able to send gzip compressed strings directly would be useful
> for applications which require to send gzip data over the wire without
> having to write to files and read-back.

I also think gzip.compress() and gzip.decompress() would be an useful addition.

Regards

Antoine.



From musiccomposition at gmail.com  Fri Aug  1 17:32:26 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 1 Aug 2008 10:32:26 -0500
Subject: [Python-3000] Providing compress/uncompress functions in gzip
In-Reply-To: <8548c5f30808010657l5d6dc57dw8698d83103d2d399@mail.gmail.com>
References: <8548c5f30808010657l5d6dc57dw8698d83103d2d399@mail.gmail.com>
Message-ID: <1afaf6160808010832i66e873c0pac9b30d29615a9e4@mail.gmail.com>

On Fri, Aug 1, 2008 at 8:57 AM, Anand Balachandran Pillai
<abpillai at gmail.com> wrote:
> Python has great in-built support for all sorts of text compression
> including bzip, gzip, tarfile and other general purpose modules like
> zlib etc.
>
> Of these, I have a gripe with gzip - it does not provide a simple
> way of compressing/uncompressing a string like the other modules
> to (namely bzip, zlib) at the module level.
>
> It is relatively easy to perform gzip de-compression using the
> GzipFile class and StringIO objects, but compression is not
> that straight-forward.
>
> It would be great for the gzip module to have "compress"
> and "uncompress" functions at the module level without having
> to go through GzipFile every-time.
>
> If it is not too late in the dev-cycle, please consider this.

Please file a feature request ticket on the tracker: http://bugs.python.org.
>
> Thanks
>
> --
> -Anand
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From abpillai at gmail.com  Fri Aug  1 19:59:08 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Fri, 1 Aug 2008 23:29:08 +0530
Subject: [Python-3000] Providing compress/uncompress functions in gzip
In-Reply-To: <1afaf6160808010832i66e873c0pac9b30d29615a9e4@mail.gmail.com>
References: <8548c5f30808010657l5d6dc57dw8698d83103d2d399@mail.gmail.com>
	<1afaf6160808010832i66e873c0pac9b30d29615a9e4@mail.gmail.com>
Message-ID: <8548c5f30808011059s6175f6acxe23df6ddc13242dd@mail.gmail.com>

Hi Benjamin,

  Filed http://bugs.python.org/issue3488.

Btw I have a fix ready for this, but I am not in the developer list and
do not have permissions for checkins.

Thanks

--Anand

On Fri, Aug 1, 2008 at 9:02 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> On Fri, Aug 1, 2008 at 8:57 AM, Anand Balachandran Pillai
> <abpillai at gmail.com> wrote:
>> Python has great in-built support for all sorts of text compression
>> including bzip, gzip, tarfile and other general purpose modules like
>> zlib etc.
>>
>> Of these, I have a gripe with gzip - it does not provide a simple
>> way of compressing/uncompressing a string like the other modules
>> to (namely bzip, zlib) at the module level.
>>
>> It is relatively easy to perform gzip de-compression using the
>> GzipFile class and StringIO objects, but compression is not
>> that straight-forward.
>>
>> It would be great for the gzip module to have "compress"
>> and "uncompress" functions at the module level without having
>> to go through GzipFile every-time.
>>
>> If it is not too late in the dev-cycle, please consider this.
>
> Please file a feature request ticket on the tracker: http://bugs.python.org.
>>
>> Thanks
>>
>> --
>> -Anand
>> _______________________________________________
>> Python-3000 mailing list
>> Python-3000 at python.org
>> http://mail.python.org/mailman/listinfo/python-3000
>> Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>>
>
>
>
> --
> Cheers,
> Benjamin Peterson
> "There's no place like 127.0.0.1."
>



-- 
-Anand

From musiccomposition at gmail.com  Fri Aug  1 20:04:35 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 1 Aug 2008 13:04:35 -0500
Subject: [Python-3000] Providing compress/uncompress functions in gzip
In-Reply-To: <8548c5f30808011059s6175f6acxe23df6ddc13242dd@mail.gmail.com>
References: <8548c5f30808010657l5d6dc57dw8698d83103d2d399@mail.gmail.com>
	<1afaf6160808010832i66e873c0pac9b30d29615a9e4@mail.gmail.com>
	<8548c5f30808011059s6175f6acxe23df6ddc13242dd@mail.gmail.com>
Message-ID: <1afaf6160808011104x47b69dd8nec048d5892d87c26@mail.gmail.com>

On Fri, Aug 1, 2008 at 12:59 PM, Anand Balachandran Pillai
<abpillai at gmail.com> wrote:
> Hi Benjamin,
>
>  Filed http://bugs.python.org/issue3488.
>
> Btw I have a fix ready for this, but I am not in the developer list and
> do not have permissions for checkins.

Great! Post the patch to the issue and we'll review it.

>
> Thanks


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From abpillai at gmail.com  Fri Aug  1 23:24:47 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Sat, 2 Aug 2008 02:54:47 +0530
Subject: [Python-3000] Providing compress/uncompress functions in gzip
In-Reply-To: <1afaf6160808011104x47b69dd8nec048d5892d87c26@mail.gmail.com>
References: <8548c5f30808010657l5d6dc57dw8698d83103d2d399@mail.gmail.com>
	<1afaf6160808010832i66e873c0pac9b30d29615a9e4@mail.gmail.com>
	<8548c5f30808011059s6175f6acxe23df6ddc13242dd@mail.gmail.com>
	<1afaf6160808011104x47b69dd8nec048d5892d87c26@mail.gmail.com>
Message-ID: <8548c5f30808011424q7613f35ai4950d8a3368c9497@mail.gmail.com>

Sample file containing code (not a patch) posted to
the bug. If the code is fine, I will make a patch.

Thanks

--Anand

On Fri, Aug 1, 2008 at 11:34 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> On Fri, Aug 1, 2008 at 12:59 PM, Anand Balachandran Pillai
> <abpillai at gmail.com> wrote:
>> Hi Benjamin,
>>
>>  Filed http://bugs.python.org/issue3488.
>>
>> Btw I have a fix ready for this, but I am not in the developer list and
>> do not have permissions for checkins.
>
> Great! Post the patch to the issue and we'll review it.
>
>>
>> Thanks
>
>
> --
> Cheers,
> Benjamin Peterson
> "There's no place like 127.0.0.1."
>



-- 
-Anand

From abpillai at gmail.com  Fri Aug  1 23:29:19 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Sat, 2 Aug 2008 02:59:19 +0530
Subject: [Python-3000] Zlib compress/decompress returning bytearray
Message-ID: <8548c5f30808011429i3f829f3buc67120107222cab4@mail.gmail.com>

Try this in Python 3.0 trunk.

>>> import zlib
>>> s='This is a string'
>>> sc=zlib.compress(s)
>>> sc
bytearray(b'x\x9c\x0b\xc9\xc8,V\x00\xa2D\x85\xe2\x92\xa2\xcc\xbct\x00/\xc2\x05\xcd')
>>> zlib.decompress(sc)
bytearray(b'This is a string')
>>>

This is wrong behavior as compress functions should return byte
,not a bytearray. Same for decompress.

Saw this while trying to write a patch for #3382.
Shall I file an issue ?

Thanks

-- 
-Anand

From musiccomposition at gmail.com  Fri Aug  1 23:38:29 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 1 Aug 2008 16:38:29 -0500
Subject: [Python-3000] Zlib compress/decompress returning bytearray
In-Reply-To: <8548c5f30808011429i3f829f3buc67120107222cab4@mail.gmail.com>
References: <8548c5f30808011429i3f829f3buc67120107222cab4@mail.gmail.com>
Message-ID: <1afaf6160808011438v12d8e869l38d0a449d82b0fd6@mail.gmail.com>

On Fri, Aug 1, 2008 at 4:29 PM, Anand Balachandran Pillai
<abpillai at gmail.com> wrote:
> Try this in Python 3.0 trunk.
>
>>>> import zlib
>>>> s='This is a string'
>>>> sc=zlib.compress(s)
>>>> sc
> bytearray(b'x\x9c\x0b\xc9\xc8,V\x00\xa2D\x85\xe2\x92\xa2\xcc\xbct\x00/\xc2\x05\xcd')
>>>> zlib.decompress(sc)
> bytearray(b'This is a string')
>>>>
>
> This is wrong behavior as compress functions should return byte
> ,not a bytearray. Same for decompress.
>
> Saw this while trying to write a patch for #3382.
> Shall I file an issue ?

Yes, please do.

>
> Thanks
>
> --
> -Anand
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From g.brandl at gmx.net  Sat Aug  2 01:24:00 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 02 Aug 2008 01:24:00 +0200
Subject: [Python-3000] Zlib compress/decompress returning bytearray
In-Reply-To: <8548c5f30808011429i3f829f3buc67120107222cab4@mail.gmail.com>
References: <8548c5f30808011429i3f829f3buc67120107222cab4@mail.gmail.com>
Message-ID: <g705nv$va7$1@ger.gmane.org>

Anand Balachandran Pillai schrieb:
> Try this in Python 3.0 trunk.
> 
>>>> import zlib
>>>> s='This is a string'
>>>> sc=zlib.compress(s)
>>>> sc
> bytearray(b'x\x9c\x0b\xc9\xc8,V\x00\xa2D\x85\xe2\x92\xa2\xcc\xbct\x00/\xc2\x05\xcd')
>>>> zlib.decompress(sc)
> bytearray(b'This is a string')
>>>>
> 
> This is wrong behavior as compress functions should return byte
> ,not a bytearray. Same for decompress.
> 
> Saw this while trying to write a patch for #3382.
> Shall I file an issue ?

I also wonder why compress() takes a Unicode string.

Georg


From abpillai at gmail.com  Sat Aug  2 15:35:25 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Sat, 2 Aug 2008 19:05:25 +0530
Subject: [Python-3000] Zlib compress/decompress returning bytearray
In-Reply-To: <g705nv$va7$1@ger.gmane.org>
References: <8548c5f30808011429i3f829f3buc67120107222cab4@mail.gmail.com>
	<g705nv$va7$1@ger.gmane.org>
Message-ID: <8548c5f30808020635g6eaaa07djc16332c648973fe9@mail.gmail.com>

The top-level compress function in bzip2 module also now
only accepts a byte string not a text string.

Python 3.0b2+ (py3k:65401, Aug  2 2008, 18:57:08)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import bz2
>>> s='This is a line of text'
>>> bz2.compress(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument 1 must be bytes or read-only buffer, not str
>>> bz2.compress(s.encode('ascii'))
b'BZh91AY&SY\xfc\xbb\x84\xfd\x00\x00\x02\x93\x80@\x00\x04\x00#e\x8c@
\x001\x00\xd0\x01\x13\xd2=F\x9eB\x8d\xf0\xb2\xa5\xd3(0"\xe5`\xbb\x92)\xc2\x84\x87\xe5\xdc\'\xe8'
>>>

In Python 2.x, text strings work, but in Python 2.x, we did not have
the distinction between binary strings and text strings anyway.

Since this is the way bz2 behaves, I have submitted my patch
for adding compress/uncompress functions in gzip module
also to follow the same behavior.

--Anand

On Sat, Aug 2, 2008 at 4:54 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> Anand Balachandran Pillai schrieb:
>>
>> Try this in Python 3.0 trunk.
>>
>>>>> import zlib
>>>>> s='This is a string'
>>>>> sc=zlib.compress(s)
>>>>> sc
>>
>>
>> bytearray(b'x\x9c\x0b\xc9\xc8,V\x00\xa2D\x85\xe2\x92\xa2\xcc\xbct\x00/\xc2\x05\xcd')
>>>>>
>>>>> zlib.decompress(sc)
>>
>> bytearray(b'This is a string')
>>>>>
>>
>> This is wrong behavior as compress functions should return byte
>> ,not a bytearray. Same for decompress.
>>
>> Saw this while trying to write a patch for #3382.
>> Shall I file an issue ?
>
> I also wonder why compress() takes a Unicode string.
>
> Georg
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/abpillai%40gmail.com
>



-- 
-Anand

From abpillai at gmail.com  Sun Aug  3 21:50:05 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Mon, 4 Aug 2008 01:20:05 +0530
Subject: [Python-3000] Zlib compress/decompress returning bytearray
In-Reply-To: <1afaf6160808011438v12d8e869l38d0a449d82b0fd6@mail.gmail.com>
References: <8548c5f30808011429i3f829f3buc67120107222cab4@mail.gmail.com>
	<1afaf6160808011438v12d8e869l38d0a449d82b0fd6@mail.gmail.com>
Message-ID: <8548c5f30808031250l38ff59ecs1f364846c52eb98f@mail.gmail.com>

Hi,

  I have uploaded a patch for this which can be applied to
zlibmodule.c (issue #3492).
I have verified it works.

Thanks

--Anand

On Sat, Aug 2, 2008 at 3:08 AM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> On Fri, Aug 1, 2008 at 4:29 PM, Anand Balachandran Pillai
> <abpillai at gmail.com> wrote:
>> Try this in Python 3.0 trunk.
>>
>>>>> import zlib
>>>>> s='This is a string'
>>>>> sc=zlib.compress(s)
>>>>> sc
>> bytearray(b'x\x9c\x0b\xc9\xc8,V\x00\xa2D\x85\xe2\x92\xa2\xcc\xbct\x00/\xc2\x05\xcd')
>>>>> zlib.decompress(sc)
>> bytearray(b'This is a string')
>>>>>
>>
>> This is wrong behavior as compress functions should return byte
>> ,not a bytearray. Same for decompress.
>>
>> Saw this while trying to write a patch for #3382.
>> Shall I file an issue ?
>
> Yes, please do.
>
>>
>> Thanks
>>
>> --
>> -Anand
>> _______________________________________________
>> Python-3000 mailing list
>> Python-3000 at python.org
>> http://mail.python.org/mailman/listinfo/python-3000
>> Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>>
>
>
>
> --
> Cheers,
> Benjamin Peterson
> "There's no place like 127.0.0.1."
>



-- 
-Anand

From facundobatista at gmail.com  Tue Aug  5 15:01:56 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Tue, 5 Aug 2008 10:01:56 -0300
Subject: [Python-3000] [OT] Commit number
Message-ID: <e04bdf310808050601y5f389571h8898dd55e649f177@mail.gmail.com>

Congratulations to Andrew Kuchling for doing the commit # 2**16

Lover-of-round-numbers--ly yours,

-- 
. Facundo

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

From mal at egenix.com  Thu Aug  7 00:40:17 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 07 Aug 2008 00:40:17 +0200
Subject: [Python-3000] Last minute C API fixes
In-Reply-To: <484FE1E9.2080904@egenix.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<484FE1E9.2080904@egenix.com>
Message-ID: <489A2851.8020306@egenix.com>

On 2008-06-11 16:32, M.-A. Lemburg wrote:
> There are two things I'd like to get in to 3.0:
> 
>  * .transform()/.untransform() methods (this is mostly done, just need
>    to add the methods to PyUnicode, PyBytes and PyByteArray)
> 
>  * cleanup of the PyUnicode_AsString() and PyUnicode_AsStringAndSize()
>    C APIs (these APIs don't fit into the naming scheme used in the
>    Unicode API and have a few other issues as well, see issue 2799;
>    at the very least they should be made interpreter internal, ie.
>    rename them to _PyUnicode_AsString() and _PyUnicode_AsStringAndSize()
>    to prevent their use in extensions)

As it turned out, I haven't had time to look into these things.

The .transform()/.untransform() can wait until 3.1. The codecs module
allows doing same-type conversion, so that can be used as work-around.

Regarding the C API, I would really not like extensions to start using
these APIs since they expose internals that should be exposed in this
direct way (PyUnicode_AsString()) and/or behave differently than the
corresponding PyString API (PyUnicode_AsStringAndSize()).

Since I don't have time to work on the C API, I'd like to do a
simple name change to make them private to the interpreter.

Is it too late for that ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 07 2008)
 >>> 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,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From guido at python.org  Thu Aug  7 01:41:59 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 6 Aug 2008 16:41:59 -0700
Subject: [Python-3000] Last minute C API fixes
In-Reply-To: <489A2851.8020306@egenix.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<484FE1E9.2080904@egenix.com> <489A2851.8020306@egenix.com>
Message-ID: <ca471dc20808061641q501ba8a2kc334529eb6f3bc6f@mail.gmail.com>

On Wed, Aug 6, 2008 at 3:40 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-06-11 16:32, M.-A. Lemburg wrote:
>>
>> There are two things I'd like to get in to 3.0:
>>
>>  * .transform()/.untransform() methods (this is mostly done, just need
>>   to add the methods to PyUnicode, PyBytes and PyByteArray)
>>
>>  * cleanup of the PyUnicode_AsString() and PyUnicode_AsStringAndSize()
>>   C APIs (these APIs don't fit into the naming scheme used in the
>>   Unicode API and have a few other issues as well, see issue 2799;
>>   at the very least they should be made interpreter internal, ie.
>>   rename them to _PyUnicode_AsString() and _PyUnicode_AsStringAndSize()
>>   to prevent their use in extensions)
>
> As it turned out, I haven't had time to look into these things.
>
> The .transform()/.untransform() can wait until 3.1. The codecs module
> allows doing same-type conversion, so that can be used as work-around.

Fine (obviously).

> Regarding the C API, I would really not like extensions to start using
> these APIs since they expose internals that should be exposed in this
> direct way (PyUnicode_AsString()) and/or behave differently than the
> corresponding PyString API (PyUnicode_AsStringAndSize()).
>
> Since I don't have time to work on the C API, I'd like to do a
> simple name change to make them private to the interpreter.
>
> Is it too late for that ?

That kind of depends on how far other 3rd party projects are in
porting their extensions to Py3k, and how much they've bought into
these APIs. I recall that mechanically translating these APIs to
something else can easily introduce memory leaks.

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

From mal at egenix.com  Thu Aug  7 11:09:46 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 07 Aug 2008 11:09:46 +0200
Subject: [Python-3000] Last minute C API fixes
In-Reply-To: <ca471dc20808061641q501ba8a2kc334529eb6f3bc6f@mail.gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>
	<489A2851.8020306@egenix.com>
	<ca471dc20808061641q501ba8a2kc334529eb6f3bc6f@mail.gmail.com>
Message-ID: <489ABBDA.30700@egenix.com>

On 2008-08-07 01:41, Guido van Rossum wrote:
> On Wed, Aug 6, 2008 at 3:40 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> On 2008-06-11 16:32, M.-A. Lemburg wrote:
>>> There are two things I'd like to get in to 3.0:
>>>
>>>  * .transform()/.untransform() methods (this is mostly done, just need
>>>   to add the methods to PyUnicode, PyBytes and PyByteArray)
>>>
>>>  * cleanup of the PyUnicode_AsString() and PyUnicode_AsStringAndSize()
>>>   C APIs (these APIs don't fit into the naming scheme used in the
>>>   Unicode API and have a few other issues as well, see issue 2799;
>>>   at the very least they should be made interpreter internal, ie.
>>>   rename them to _PyUnicode_AsString() and _PyUnicode_AsStringAndSize()
>>>   to prevent their use in extensions)
>> As it turned out, I haven't had time to look into these things.
>>
>> The .transform()/.untransform() can wait until 3.1. The codecs module
>> allows doing same-type conversion, so that can be used as work-around.
> 
> Fine (obviously).
> 
>> Regarding the C API, I would really not like extensions to start using
>> these APIs since they expose internals that should be exposed in this
>> direct way (PyUnicode_AsString()) and/or behave differently than the
>> corresponding PyString API (PyUnicode_AsStringAndSize()).
>>
>> Since I don't have time to work on the C API, I'd like to do a
>> simple name change to make them private to the interpreter.
>>
>> Is it too late for that ?
> 
> That kind of depends on how far other 3rd party projects are in
> porting their extensions to Py3k, and how much they've bought into
> these APIs. I recall that mechanically translating these APIs to
> something else can easily introduce memory leaks.

True, but isn't it better to go through that pain for a few extensions
now and then have a proper C API to use in 3.1 ? Otherwise, we end
up having to support those APIs for the whole lifetime
of the 3.x branch.

Note that those two APIs are not documented, so their use is not
yet officially allowed.

BTW: The correct way to get at an UTF-8 encoded version of a PyUnicode
object is to use PyUnicode_AsUTF8String() or the "s#" parser marker.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 07 2008)
 >>> 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,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From barry at python.org  Thu Aug  7 14:18:51 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 7 Aug 2008 08:18:51 -0400
Subject: [Python-3000] Last minute C API fixes
In-Reply-To: <489ABBDA.30700@egenix.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>
	<489A2851.8020306@egenix.com>
	<ca471dc20808061641q501ba8a2kc334529eb6f3bc6f@mail.gmail.com>
	<489ABBDA.30700@egenix.com>
Message-ID: <C5D74A92-3DDF-4384-9877-E5977FBF3F1A@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 7, 2008, at 5:09 AM, M.-A. Lemburg wrote:

>>> Is it too late for that ?
>> That kind of depends on how far other 3rd party projects are in
>> porting their extensions to Py3k, and how much they've bought into
>> these APIs. I recall that mechanically translating these APIs to
>> something else can easily introduce memory leaks.
>
> True, but isn't it better to go through that pain for a few extensions
> now and then have a proper C API to use in 3.1 ? Otherwise, we end
> up having to support those APIs for the whole lifetime
> of the 3.x branch.
>
> Note that those two APIs are not documented, so their use is not
> yet officially allowed.

I'd prefer not introducing such instability this late in the beta  
processes, but I agree that fixing it now will be better in the long  
term.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSJroK3EjvBPtnXfVAQKeBwP/UlfTlCS3RgW5vuyaMjKbhQkL0d3nwOGr
NqYfLX6a0XRaroJzb9hPClzwyrkllQs6bLFoaFegTbi200+2Z3fG4z7vc1ywNBsu
rBIsyyQIN6kH7bqHqgqj0hDHgCNuobLz8m9R+Wodkafz4Jo49tDm60raUeHrKOvZ
TRIIUH5ZzVw=
=Q69C
-----END PGP SIGNATURE-----

From janssen at parc.com  Thu Aug  7 18:10:56 2008
From: janssen at parc.com (Bill Janssen)
Date: Thu, 7 Aug 2008 09:10:56 PDT
Subject: [Python-3000] state of Py3K trunk?
Message-ID: <08Aug7.091106pdt."58698"@synergy1.parc.xerox.com>

I'm trying to run the regression suite on a checkout of the Py3K trunk
my OS X 10.5 machine, and getting nowhere fast.  First off,
test_audioop segfaults.  After disabling that, I've been hanging in
test_bz2 for half an hour.

Should we be able to test the current codebase?

Bill

From guido at python.org  Thu Aug  7 18:40:04 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 7 Aug 2008 09:40:04 -0700
Subject: [Python-3000] Last minute C API fixes
In-Reply-To: <C5D74A92-3DDF-4384-9877-E5977FBF3F1A@python.org>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<484FE1E9.2080904@egenix.com> <489A2851.8020306@egenix.com>
	<ca471dc20808061641q501ba8a2kc334529eb6f3bc6f@mail.gmail.com>
	<489ABBDA.30700@egenix.com>
	<C5D74A92-3DDF-4384-9877-E5977FBF3F1A@python.org>
Message-ID: <ca471dc20808070940s9b6546epf7602cec627c6cee@mail.gmail.com>

On Thu, Aug 7, 2008 at 5:18 AM, Barry Warsaw <barry at python.org> wrote:
> On Aug 7, 2008, at 5:09 AM, M.-A. Lemburg wrote:
>
>>>> Is it too late for that ?
>>>
>>> That kind of depends on how far other 3rd party projects are in
>>> porting their extensions to Py3k, and how much they've bought into
>>> these APIs. I recall that mechanically translating these APIs to
>>> something else can easily introduce memory leaks.
>>
>> True, but isn't it better to go through that pain for a few extensions
>> now and then have a proper C API to use in 3.1 ? Otherwise, we end
>> up having to support those APIs for the whole lifetime
>> of the 3.x branch.
>>
>> Note that those two APIs are not documented, so their use is not
>> yet officially allowed.
>
> I'd prefer not introducing such instability this late in the beta processes,
> but I agree that fixing it now will be better in the long term.

I see this as a sufficient endorsement. Marc-Andre, can you do this?

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

From mal at egenix.com  Thu Aug  7 19:03:29 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 07 Aug 2008 19:03:29 +0200
Subject: [Python-3000] Last minute C API fixes
In-Reply-To: <ca471dc20808070940s9b6546epf7602cec627c6cee@mail.gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>
	<489A2851.8020306@egenix.com>	<ca471dc20808061641q501ba8a2kc334529eb6f3bc6f@mail.gmail.com>	<489ABBDA.30700@egenix.com>	<C5D74A92-3DDF-4384-9877-E5977FBF3F1A@python.org>
	<ca471dc20808070940s9b6546epf7602cec627c6cee@mail.gmail.com>
Message-ID: <489B2AE1.1000202@egenix.com>

On 2008-08-07 18:40, Guido van Rossum wrote:
> On Thu, Aug 7, 2008 at 5:18 AM, Barry Warsaw <barry at python.org> wrote:
>> On Aug 7, 2008, at 5:09 AM, M.-A. Lemburg wrote:
>>
>>>>> Is it too late for that ?
>>>> That kind of depends on how far other 3rd party projects are in
>>>> porting their extensions to Py3k, and how much they've bought into
>>>> these APIs. I recall that mechanically translating these APIs to
>>>> something else can easily introduce memory leaks.
>>> True, but isn't it better to go through that pain for a few extensions
>>> now and then have a proper C API to use in 3.1 ? Otherwise, we end
>>> up having to support those APIs for the whole lifetime
>>> of the 3.x branch.
>>>
>>> Note that those two APIs are not documented, so their use is not
>>> yet officially allowed.
>> I'd prefer not introducing such instability this late in the beta processes,
>> but I agree that fixing it now will be better in the long term.
> 
> I see this as a sufficient endorsement. Marc-Andre, can you do this?

Yes. I'll just apply a renaming of two APIs (and all their uses
in the interpreter code) to a _Py internal name.

We can then hash out a better interface to the internal UTF-8
representation for 3.1.

Extension that use the current unofficial APIs could then also
apply that renaming if the developers don't have time to update
the code and then use the new APIs when 3.1 ships.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 07 2008)
 >>> 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,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From guido at python.org  Thu Aug  7 19:04:38 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 7 Aug 2008 10:04:38 -0700
Subject: [Python-3000] state of Py3K trunk?
In-Reply-To: <-3306327851934792399@unknownmsgid>
References: <-3306327851934792399@unknownmsgid>
Message-ID: <ca471dc20808071004p72bb307fweae42b8f974ee1eb@mail.gmail.com>

On Thu, Aug 7, 2008 at 9:10 AM, Bill Janssen <janssen at parc.com> wrote:
> I'm trying to run the regression suite on a checkout of the Py3K trunk

DO you mean the trunk (which is 2.6), or the py3k branch?

> my OS X 10.5 machine, and getting nowhere fast.

PPC or x86? For segfaults it might matter (byte order).

> First off,
> test_audioop segfaults.  After disabling that, I've been hanging in
> test_bz2 for half an hour.
>
> Should we be able to test the current codebase?

Yes. On my x86 OS X 10.5 machine, test_audioop and test_bz2 both pass
in the p3yk branch. I'll get my PPC 10.4 machine unfrozen and test
there too.

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

From guido at python.org  Thu Aug  7 19:09:36 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 7 Aug 2008 10:09:36 -0700
Subject: [Python-3000] Last minute C API fixes
In-Reply-To: <489B2AE1.1000202@egenix.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<484FE1E9.2080904@egenix.com> <489A2851.8020306@egenix.com>
	<ca471dc20808061641q501ba8a2kc334529eb6f3bc6f@mail.gmail.com>
	<489ABBDA.30700@egenix.com>
	<C5D74A92-3DDF-4384-9877-E5977FBF3F1A@python.org>
	<ca471dc20808070940s9b6546epf7602cec627c6cee@mail.gmail.com>
	<489B2AE1.1000202@egenix.com>
Message-ID: <ca471dc20808071009j9a4b8ffle2e518f7ca948247@mail.gmail.com>

Sounds like a plan. Make sure it is prominently mentioned in Misc/NEWS.

On Thu, Aug 7, 2008 at 10:03 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-08-07 18:40, Guido van Rossum wrote:
>>
>> On Thu, Aug 7, 2008 at 5:18 AM, Barry Warsaw <barry at python.org> wrote:
>>>
>>> On Aug 7, 2008, at 5:09 AM, M.-A. Lemburg wrote:
>>>
>>>>>> Is it too late for that ?
>>>>>
>>>>> That kind of depends on how far other 3rd party projects are in
>>>>> porting their extensions to Py3k, and how much they've bought into
>>>>> these APIs. I recall that mechanically translating these APIs to
>>>>> something else can easily introduce memory leaks.
>>>>
>>>> True, but isn't it better to go through that pain for a few extensions
>>>> now and then have a proper C API to use in 3.1 ? Otherwise, we end
>>>> up having to support those APIs for the whole lifetime
>>>> of the 3.x branch.
>>>>
>>>> Note that those two APIs are not documented, so their use is not
>>>> yet officially allowed.
>>>
>>> I'd prefer not introducing such instability this late in the beta
>>> processes,
>>> but I agree that fixing it now will be better in the long term.
>>
>> I see this as a sufficient endorsement. Marc-Andre, can you do this?
>
> Yes. I'll just apply a renaming of two APIs (and all their uses
> in the interpreter code) to a _Py internal name.
>
> We can then hash out a better interface to the internal UTF-8
> representation for 3.1.
>
> Extension that use the current unofficial APIs could then also
> apply that renaming if the developers don't have time to update
> the code and then use the new APIs when 3.1 ships.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Aug 07 2008)
>>>> 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,MacOSX for free ! ::::
>
>
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>           Registered at Amtsgericht Duesseldorf: HRB 46611
>



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

From barry at python.org  Thu Aug  7 19:25:34 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 7 Aug 2008 13:25:34 -0400
Subject: [Python-3000] state of Py3K trunk?
In-Reply-To: <ca471dc20808071004p72bb307fweae42b8f974ee1eb@mail.gmail.com>
References: <-3306327851934792399@unknownmsgid>
	<ca471dc20808071004p72bb307fweae42b8f974ee1eb@mail.gmail.com>
Message-ID: <2658942F-92A6-43FE-847A-150F3BFB086C@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 7, 2008, at 1:04 PM, Guido van Rossum wrote:

> On Thu, Aug 7, 2008 at 9:10 AM, Bill Janssen <janssen at parc.com> wrote:
>> I'm trying to run the regression suite on a checkout of the Py3K  
>> trunk
>
> DO you mean the trunk (which is 2.6), or the py3k branch?
>
>> my OS X 10.5 machine, and getting nowhere fast.
>
> PPC or x86? For segfaults it might matter (byte order).
>
>> First off,
>> test_audioop segfaults.  After disabling that, I've been hanging in
>> test_bz2 for half an hour.
>>
>> Should we be able to test the current codebase?
>
> Yes. On my x86 OS X 10.5 machine, test_audioop and test_bz2 both pass
> in the p3yk branch. I'll get my PPC 10.4 machine unfrozen and test
> there too.

All py3k tests pass on my PPC 10.5 machine.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSJswDnEjvBPtnXfVAQKcYgP/eZazBXLVVT28TRkOwrTSWbGSDRzowKzJ
zQv243E0pByFH/zHQnPNm6yDuKNBrnvmwhiFvNR4FJNSQJwtUIgwzVCz/Sh7Yg9H
DWHH8YGhxF/9d8/Ev85eePAAFe+i6oZBIygwATn48LixXRmzUR75vjtqJdXkE9uF
5wnrQy59W5Y=
=+/85
-----END PGP SIGNATURE-----

From guido at python.org  Thu Aug  7 20:07:46 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 7 Aug 2008 11:07:46 -0700
Subject: [Python-3000] state of Py3K trunk?
In-Reply-To: <ca471dc20808071004p72bb307fweae42b8f974ee1eb@mail.gmail.com>
References: <-3306327851934792399@unknownmsgid>
	<ca471dc20808071004p72bb307fweae42b8f974ee1eb@mail.gmail.com>
Message-ID: <ca471dc20808071107p4f7f8a78wcb77d80516e50c24@mail.gmail.com>

On Thu, Aug 7, 2008 at 10:04 AM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Aug 7, 2008 at 9:10 AM, Bill Janssen <janssen at parc.com> wrote:
>> I'm trying to run the regression suite on a checkout of the Py3K trunk
>
> DO you mean the trunk (which is 2.6), or the py3k branch?
>
>> my OS X 10.5 machine, and getting nowhere fast.
>
> PPC or x86? For segfaults it might matter (byte order).
>
>> First off,
>> test_audioop segfaults.  After disabling that, I've been hanging in
>> test_bz2 for half an hour.
>>
>> Should we be able to test the current codebase?
>
> Yes. On my x86 OS X 10.5 machine, test_audioop and test_bz2 both pass
> in the p3yk branch.

Ditto in the trunk.

> I'll get my PPC 10.4 machine unfrozen and test there too.

Both tests pass there, both in the trunk and in the py3k branch.

Are you using a debug or a non-debug build?

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

From janssen at parc.com  Thu Aug  7 20:24:38 2008
From: janssen at parc.com (Bill Janssen)
Date: Thu, 7 Aug 2008 11:24:38 PDT
Subject: [Python-3000] state of Py3K trunk?
In-Reply-To: <ca471dc20808071107p4f7f8a78wcb77d80516e50c24@mail.gmail.com> 
References: <-3306327851934792399@unknownmsgid>
	<ca471dc20808071004p72bb307fweae42b8f974ee1eb@mail.gmail.com>
	<ca471dc20808071107p4f7f8a78wcb77d80516e50c24@mail.gmail.com>
Message-ID: <08Aug7.112443pdt."58698"@synergy1.parc.xerox.com>

> Both tests pass there, both in the trunk and in the py3k branch.
> 
> Are you using a debug or a non-debug build?

Debug.

Bill

From janssen at parc.com  Thu Aug  7 20:24:16 2008
From: janssen at parc.com (Bill Janssen)
Date: Thu, 7 Aug 2008 11:24:16 PDT
Subject: [Python-3000] state of Py3K trunk?
In-Reply-To: <ca471dc20808071004p72bb307fweae42b8f974ee1eb@mail.gmail.com> 
References: <-3306327851934792399@unknownmsgid>
	<ca471dc20808071004p72bb307fweae42b8f974ee1eb@mail.gmail.com>
Message-ID: <08Aug7.112422pdt."58698"@synergy1.parc.xerox.com>

> On Thu, Aug 7, 2008 at 9:10 AM, Bill Janssen <janssen at parc.com> wrote:
> > I'm trying to run the regression suite on a checkout of the Py3K trunk
> 
> DO you mean the trunk (which is 2.6), or the py3k branch?

the py3k branch

> > my OS X 10.5 machine, and getting nowhere fast.
> 
> PPC or x86? For segfaults it might matter (byte order).

x86, Mac Pro, latest OS updates.

> > First off,
> > test_audioop segfaults.  After disabling that, I've been hanging in
> > test_bz2 for half an hour.
> >
> > Should we be able to test the current codebase?
> 
> Yes. On my x86 OS X 10.5 machine, test_audioop and test_bz2 both pass
> in the p3yk branch.

OK, thanks.  Must be some setup bug on my side.

Bill


From guido at python.org  Thu Aug  7 20:27:55 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 7 Aug 2008 11:27:55 -0700
Subject: [Python-3000] state of Py3K trunk?
In-Reply-To: <4273683588225453179@unknownmsgid>
References: <-3306327851934792399@unknownmsgid>
	<ca471dc20808071004p72bb307fweae42b8f974ee1eb@mail.gmail.com>
	<ca471dc20808071107p4f7f8a78wcb77d80516e50c24@mail.gmail.com>
	<4273683588225453179@unknownmsgid>
Message-ID: <ca471dc20808071127y16dc3d38h6e04e515b52ce9d8@mail.gmail.com>

On Thu, Aug 7, 2008 at 11:24 AM, Bill Janssen <janssen at parc.com> wrote:
>> Both tests pass there, both in the trunk and in the py3k branch.
>>
>> Are you using a debug or a non-debug build?
>
> Debug.

Sometimes debug builds have additional problems, but these tests pass
for me in a debug build of the p3yk branch as well.

I recommend "make distclean" and then ./configure --with-pydebug; make.

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

From janssen at parc.com  Thu Aug  7 20:40:31 2008
From: janssen at parc.com (Bill Janssen)
Date: Thu, 7 Aug 2008 11:40:31 PDT
Subject: [Python-3000] state of Py3K trunk?
In-Reply-To: <ca471dc20808071127y16dc3d38h6e04e515b52ce9d8@mail.gmail.com> 
References: <-3306327851934792399@unknownmsgid>
	<ca471dc20808071004p72bb307fweae42b8f974ee1eb@mail.gmail.com>
	<ca471dc20808071107p4f7f8a78wcb77d80516e50c24@mail.gmail.com>
	<4273683588225453179@unknownmsgid>
	<ca471dc20808071127y16dc3d38h6e04e515b52ce9d8@mail.gmail.com>
Message-ID: <08Aug7.114038pdt."58698"@synergy1.parc.xerox.com>

> I recommend "make distclean" and then ./configure --with-pydebug; make.

Yes, that's what I tried, and it seems to be rolling along now.  I
must have had some stale bits there.  Thanks!

Bill

From mal at egenix.com  Thu Aug  7 20:57:20 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 07 Aug 2008 20:57:20 +0200
Subject: [Python-3000] Last minute C API fixes
In-Reply-To: <ca471dc20808071009j9a4b8ffle2e518f7ca948247@mail.gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>
	<489A2851.8020306@egenix.com>	<ca471dc20808061641q501ba8a2kc334529eb6f3bc6f@mail.gmail.com>	<489ABBDA.30700@egenix.com>	<C5D74A92-3DDF-4384-9877-E5977FBF3F1A@python.org>	<ca471dc20808070940s9b6546epf7602cec627c6cee@mail.gmail.com>	<489B2AE1.1000202@egenix.com>
	<ca471dc20808071009j9a4b8ffle2e518f7ca948247@mail.gmail.com>
Message-ID: <489B4590.1030407@egenix.com>

On 2008-08-07 19:09, Guido van Rossum wrote:
> Sounds like a plan. Make sure it is prominently mentioned in Misc/NEWS.

Committed as r65582.

All tests pass except test_socket, but that appears to be related
to some quirk on my machine:

    File "Lib/test/test_socket.py", line 365, in testGetServBy
     eq(socket.getservbyport(port2), service)
socket.error: port/proto not found

Note that the macro PyObject_REPR() still potentially exposes the
_PyUnicode_AsString() API to 3rd party code. We should probably
change that macro to a function in Python 3.1.

> On Thu, Aug 7, 2008 at 10:03 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> On 2008-08-07 18:40, Guido van Rossum wrote:
>>> On Thu, Aug 7, 2008 at 5:18 AM, Barry Warsaw <barry at python.org> wrote:
>>>> On Aug 7, 2008, at 5:09 AM, M.-A. Lemburg wrote:
>>>>
>>>>>>> Is it too late for that ?
>>>>>> That kind of depends on how far other 3rd party projects are in
>>>>>> porting their extensions to Py3k, and how much they've bought into
>>>>>> these APIs. I recall that mechanically translating these APIs to
>>>>>> something else can easily introduce memory leaks.
>>>>> True, but isn't it better to go through that pain for a few extensions
>>>>> now and then have a proper C API to use in 3.1 ? Otherwise, we end
>>>>> up having to support those APIs for the whole lifetime
>>>>> of the 3.x branch.
>>>>>
>>>>> Note that those two APIs are not documented, so their use is not
>>>>> yet officially allowed.
>>>> I'd prefer not introducing such instability this late in the beta
>>>> processes,
>>>> but I agree that fixing it now will be better in the long term.
>>> I see this as a sufficient endorsement. Marc-Andre, can you do this?
>> Yes. I'll just apply a renaming of two APIs (and all their uses
>> in the interpreter code) to a _Py internal name.
>>
>> We can then hash out a better interface to the internal UTF-8
>> representation for 3.1.
>>
>> Extension that use the current unofficial APIs could then also
>> apply that renaming if the developers don't have time to update
>> the code and then use the new APIs when 3.1 ships.
>>
>> --
>> Marc-Andre Lemburg
>> eGenix.com
>>
>> Professional Python Services directly from the Source  (#1, Aug 07 2008)
>>>>> 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,MacOSX for free ! ::::
>>
>>
>>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>>    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>           Registered at Amtsgericht Duesseldorf: HRB 46611
>>
> 
> 
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 07 2008)
 >>> 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,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From guido at python.org  Thu Aug  7 21:00:04 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 7 Aug 2008 12:00:04 -0700
Subject: [Python-3000] Last minute C API fixes
In-Reply-To: <489B4590.1030407@egenix.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<484FE1E9.2080904@egenix.com> <489A2851.8020306@egenix.com>
	<ca471dc20808061641q501ba8a2kc334529eb6f3bc6f@mail.gmail.com>
	<489ABBDA.30700@egenix.com>
	<C5D74A92-3DDF-4384-9877-E5977FBF3F1A@python.org>
	<ca471dc20808070940s9b6546epf7602cec627c6cee@mail.gmail.com>
	<489B2AE1.1000202@egenix.com>
	<ca471dc20808071009j9a4b8ffle2e518f7ca948247@mail.gmail.com>
	<489B4590.1030407@egenix.com>
Message-ID: <ca471dc20808071200y2161680dm72f6db743ba9e05b@mail.gmail.com>

On Thu, Aug 7, 2008 at 11:57 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-08-07 19:09, Guido van Rossum wrote:
>>
>> Sounds like a plan. Make sure it is prominently mentioned in Misc/NEWS.
>
> Committed as r65582.

Thanks!

> All tests pass except test_socket, but that appears to be related
> to some quirk on my machine:
>
>   File "Lib/test/test_socket.py", line 365, in testGetServBy
>    eq(socket.getservbyport(port2), service)
> socket.error: port/proto not found

I saw this fail earlier today, but now I can't repro it. What OS+hardware?

> Note that the macro PyObject_REPR() still potentially exposes the
> _PyUnicode_AsString() API to 3rd party code. We should probably
> change that macro to a function in Python 3.1.
>
>> On Thu, Aug 7, 2008 at 10:03 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>
>>> On 2008-08-07 18:40, Guido van Rossum wrote:
>>>>
>>>> On Thu, Aug 7, 2008 at 5:18 AM, Barry Warsaw <barry at python.org> wrote:
>>>>>
>>>>> On Aug 7, 2008, at 5:09 AM, M.-A. Lemburg wrote:
>>>>>
>>>>>>>> Is it too late for that ?
>>>>>>>
>>>>>>> That kind of depends on how far other 3rd party projects are in
>>>>>>> porting their extensions to Py3k, and how much they've bought into
>>>>>>> these APIs. I recall that mechanically translating these APIs to
>>>>>>> something else can easily introduce memory leaks.
>>>>>>
>>>>>> True, but isn't it better to go through that pain for a few extensions
>>>>>> now and then have a proper C API to use in 3.1 ? Otherwise, we end
>>>>>> up having to support those APIs for the whole lifetime
>>>>>> of the 3.x branch.
>>>>>>
>>>>>> Note that those two APIs are not documented, so their use is not
>>>>>> yet officially allowed.
>>>>>
>>>>> I'd prefer not introducing such instability this late in the beta
>>>>> processes,
>>>>> but I agree that fixing it now will be better in the long term.
>>>>
>>>> I see this as a sufficient endorsement. Marc-Andre, can you do this?
>>>
>>> Yes. I'll just apply a renaming of two APIs (and all their uses
>>> in the interpreter code) to a _Py internal name.
>>>
>>> We can then hash out a better interface to the internal UTF-8
>>> representation for 3.1.
>>>
>>> Extension that use the current unofficial APIs could then also
>>> apply that renaming if the developers don't have time to update
>>> the code and then use the new APIs when 3.1 ships.
>>>
>>> --
>>> Marc-Andre Lemburg
>>> eGenix.com
>>>
>>> Professional Python Services directly from the Source  (#1, Aug 07 2008)
>>>>>>
>>>>>> 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,MacOSX for free ! ::::
>>>
>>>
>>>  eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>>>   D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>>          Registered at Amtsgericht Duesseldorf: HRB 46611
>>>
>>
>>
>>
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Aug 07 2008)
>>>> 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,MacOSX for free ! ::::
>
>
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>           Registered at Amtsgericht Duesseldorf: HRB 46611
>



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

From mal at egenix.com  Thu Aug  7 21:01:08 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 07 Aug 2008 21:01:08 +0200
Subject: [Python-3000] Last minute C API fixes
In-Reply-To: <ca471dc20808071200y2161680dm72f6db743ba9e05b@mail.gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>
	<489A2851.8020306@egenix.com>	<ca471dc20808061641q501ba8a2kc334529eb6f3bc6f@mail.gmail.com>	<489ABBDA.30700@egenix.com>	<C5D74A92-3DDF-4384-9877-E5977FBF3F1A@python.org>	<ca471dc20808070940s9b6546epf7602cec627c6cee@mail.gmail.com>	<489B2AE1.1000202@egenix.com>	<ca471dc20808071009j9a4b8ffle2e518f7ca948247@mail.gmail.com>	<489B4590.1030407@egenix.com>
	<ca471dc20808071200y2161680dm72f6db743ba9e05b@mail.gmail.com>
Message-ID: <489B4674.5050200@egenix.com>

On 2008-08-07 21:00, Guido van Rossum wrote:
> On Thu, Aug 7, 2008 at 11:57 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> On 2008-08-07 19:09, Guido van Rossum wrote:
>>> Sounds like a plan. Make sure it is prominently mentioned in Misc/NEWS.
>> Committed as r65582.
> 
> Thanks!
> 
>> All tests pass except test_socket, but that appears to be related
>> to some quirk on my machine:
>>
>>   File "Lib/test/test_socket.py", line 365, in testGetServBy
>>    eq(socket.getservbyport(port2), service)
>> socket.error: port/proto not found
> 
> I saw this fail earlier today, but now I can't repro it. What OS+hardware?

x64 machine running openSUSE 10.3.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 07 2008)
 >>> 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,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From mal at egenix.com  Thu Aug  7 21:18:53 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 07 Aug 2008 21:18:53 +0200
Subject: [Python-3000] Last minute C API fixes
In-Reply-To: <489B4674.5050200@egenix.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>	<489A2851.8020306@egenix.com>	<ca471dc20808061641q501ba8a2kc334529eb6f3bc6f@mail.gmail.com>	<489ABBDA.30700@egenix.com>	<C5D74A92-3DDF-4384-9877-E5977FBF3F1A@python.org>	<ca471dc20808070940s9b6546epf7602cec627c6cee@mail.gmail.com>	<489B2AE1.1000202@egenix.com>	<ca471dc20808071009j9a4b8ffle2e518f7ca948247@mail.gmail.com>	<489B4590.1030407@egenix.com>	<ca471dc20808071200y2161680dm72f6db743ba9e05b@mail.gmail.com>
	<489B4674.5050200@egenix.com>
Message-ID: <489B4A9D.6080903@egenix.com>

On 2008-08-07 21:01, M.-A. Lemburg wrote:
> On 2008-08-07 21:00, Guido van Rossum wrote:
>> On Thu, Aug 7, 2008 at 11:57 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>> On 2008-08-07 19:09, Guido van Rossum wrote:
>>>> Sounds like a plan. Make sure it is prominently mentioned in Misc/NEWS.
>>> Committed as r65582.
>>
>> Thanks!
>>
>>> All tests pass except test_socket, but that appears to be related
>>> to some quirk on my machine:
>>>
>>>   File "Lib/test/test_socket.py", line 365, in testGetServBy
>>>    eq(socket.getservbyport(port2), service)
>>> socket.error: port/proto not found
>>
>> I saw this fail earlier today, but now I can't repro it. What 
>> OS+hardware?
> 
> x64 machine running openSUSE 10.3.

Here's a manual run:

 >>> import socket
 >>> socket.getservbyport(13)
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
socket.error: port/proto not found

Looking at an strace, the socket C call is trying to access nscd.

Switching off nscd results in this:

 >>> import socket
 >>> socket.getservbyport(13)
'daytime'

So it's really not related to Python in any way.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 07 2008)
 >>> 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,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From stefan_ml at behnel.de  Thu Aug  7 22:48:51 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 07 Aug 2008 22:48:51 +0200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <4851D404.90308@canterbury.ac.nz>
References: <484E001A.5000002@v.loewis.de>
	<g2qe71$mq$1@ger.gmane.org>	<g2qf42$3fu$1@ger.gmane.org>
	<g2qk10$glg$1@ger.gmane.org>	<4851B593.6030308@v.loewis.de>
	<4851D404.90308@canterbury.ac.nz>
Message-ID: <g7fn3i$am4$1@ger.gmane.org>

Greg Ewing wrote:
> Martin v. L?wis wrote:
> 
>>   However, _sre relied on the module already being in
>>   sys.modules, as it runs Python code in the init function that already
>>   imports the module being initialized.
> 
> This issue also potentially affects all Pyrex and Cython
> generated modules, which must be free to execute arbitrary
> Python code during initialisation, including imports.

As I understand this, the problem only relates to importing the module being
initialised, which a module won't do for itself. But I can well imagine the
case that a third module that gets imported during the init phase happens to
import the initialising module, i.e. a transitive re-import.

Martin, talking about correctness, I would also expect the import code to
prevent an infinite import loop here (or whatever the problem for _sre was).

Stefan


From stefan_ml at behnel.de  Sun Aug 10 15:18:22 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 10 Aug 2008 15:18:22 +0200
Subject: [Python-3000] xml.etree.ElementTree and PEP 8
Message-ID: <g7mpqu$i6v$1@ger.gmane.org>

Hi,

I wonder why the ElementTree modules in Py3k's xml.etree still do not follow
PEP8 naming (ok, besides the obvious explanation that no-one renamed them so
far). Was there a decision that they should keep their name despite the
general push towards a uniformly named standard library? Or would it be ok to
rename them for the next beta?

Given the fact that most packages that depend on ET already use more than one
try-except import for these modules anyway (and likely a separate module that
cares for the right import), I don't see the situation becoming any worse by
making them PEP8 compliant.

Stefan


From musiccomposition at gmail.com  Sun Aug 10 17:03:32 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 10 Aug 2008 09:03:32 -0600
Subject: [Python-3000] xml.etree.ElementTree and PEP 8
In-Reply-To: <g7mpqu$i6v$1@ger.gmane.org>
References: <g7mpqu$i6v$1@ger.gmane.org>
Message-ID: <1afaf6160808100803j214c61a7je20de9feeb20c432@mail.gmail.com>

On Sun, Aug 10, 2008 at 7:18 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
> I wonder why the ElementTree modules in Py3k's xml.etree still do not follow
> PEP8 naming (ok, besides the obvious explanation that no-one renamed them so
> far). Was there a decision that they should keep their name despite the
> general push towards a uniformly named standard library? Or would it be ok to
> rename them for the next beta?

The stdlib APIs are never going to be completely PEP 8 compliant, and
that's ok; internal consistency (in the library) is most important.
I'm very -1 this late in the release cycle.

>
> Given the fact that most packages that depend on ET already use more than one
> try-except import for these modules anyway (and likely a separate module that
> cares for the right import), I don't see the situation becoming any worse by
> making them PEP8 compliant.
>
> Stefan
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From martin at v.loewis.de  Sun Aug 10 17:16:55 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Aug 2008 17:16:55 +0200
Subject: [Python-3000] xml.etree.ElementTree and PEP 8
In-Reply-To: <g7mpqu$i6v$1@ger.gmane.org>
References: <g7mpqu$i6v$1@ger.gmane.org>
Message-ID: <489F0667.2080900@v.loewis.de>

> I wonder why the ElementTree modules in Py3k's xml.etree still do not follow
> PEP8 naming (ok, besides the obvious explanation that no-one renamed them so
> far). Was there a decision that they should keep their name despite the
> general push towards a uniformly named standard library?

There was no such push (some people where pushing, but they were
fortunately stopped).

> Or would it be ok to rename them for the next beta?

Definitely not. The policy is to not gratuitously break things.

> Given the fact that most packages that depend on ET already use more than one
> try-except import for these modules anyway (and likely a separate module that
> cares for the right import), I don't see the situation becoming any worse by
> making them PEP8 compliant.

So what specific changes would you have in mind? How would existing code
have to be changed to accommodate these changes?

Regards,
Martin

From stefan_ml at behnel.de  Sun Aug 10 18:32:23 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 10 Aug 2008 18:32:23 +0200
Subject: [Python-3000] xml.etree.ElementTree and PEP 8
In-Reply-To: <489F0667.2080900@v.loewis.de>
References: <g7mpqu$i6v$1@ger.gmane.org> <489F0667.2080900@v.loewis.de>
Message-ID: <g7n56n$fol$1@ger.gmane.org>

Martin v. L?wis wrote:
>> Given the fact that most packages that depend on ET already use more than one
>> try-except import for these modules anyway (and likely a separate module that
>> cares for the right import), I don't see the situation becoming any worse by
>> making them PEP8 compliant.
> 
> So what specific changes would you have in mind? How would existing code
> have to be changed to accommodate these changes?

I was thinking of the existing import cascade below:

http://code.activestate.com/recipes/475126/

There's hardly a way to make *that* worse.

>From looking at the archives, it seems that the original idea to call the
package "xml.etree" came from Fredrik himself - a bad choice, even at the
time, but that's how it is now.

So the obvious suggestion is that in Py3, the modules should be called
"xml.etree.elementtree", "xml.etree.celementtree", etc., and code that imports
them would add yet another try-import-except. I think the rest of the modules
(function names, class names, etc.) is pretty much PEP8 compliant already,
given the freedom that it currently permits. The only thing that really
strikes currently is the identical naming of modules and classes.

Stefan


From brett at python.org  Sun Aug 10 20:23:56 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 10 Aug 2008 11:23:56 -0700
Subject: [Python-3000] xml.etree.ElementTree and PEP 8
In-Reply-To: <g7n56n$fol$1@ger.gmane.org>
References: <g7mpqu$i6v$1@ger.gmane.org> <489F0667.2080900@v.loewis.de>
	<g7n56n$fol$1@ger.gmane.org>
Message-ID: <bbaeab100808101123j1ff904a3hfa4e96fe14aef3be@mail.gmail.com>

On Sun, Aug 10, 2008 at 9:32 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Martin v. L?wis wrote:
>>> Given the fact that most packages that depend on ET already use more than one
>>> try-except import for these modules anyway (and likely a separate module that
>>> cares for the right import), I don't see the situation becoming any worse by
>>> making them PEP8 compliant.
>>
>> So what specific changes would you have in mind? How would existing code
>> have to be changed to accommodate these changes?
>
> I was thinking of the existing import cascade below:
>
> http://code.activestate.com/recipes/475126/
>
> There's hardly a way to make *that* worse.
>
> >From looking at the archives, it seems that the original idea to call the
> package "xml.etree" came from Fredrik himself - a bad choice, even at the
> time, but that's how it is now.
>
> So the obvious suggestion is that in Py3, the modules should be called
> "xml.etree.elementtree", "xml.etree.celementtree", etc., and code that imports
> them would add yet another try-import-except. I think the rest of the modules
> (function names, class names, etc.) is pretty much PEP8 compliant already,
> given the freedom that it currently permits. The only thing that really
> strikes currently is the identical naming of modules and classes.
>

Actually, if this rename ever happened the C version would be hidden
behind ElementTree as an implementation detail.

And one of the reasons this didn't happen was that ElementTree is a
third-party module, so it was a question of whether to break from that
or not. As Martin said, some people (including me) would like to see
this change, but there were other battles to be fought for renames.

-Brett

From barry at python.org  Mon Aug 11 14:27:14 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 11 Aug 2008 08:27:14 -0400
Subject: [Python-3000] [Python-Dev] next beta
In-Reply-To: <loom.20080811T095014-204@post.gmane.org>
References: <4838EA2D.7060402@jcea.es>
	<319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com>
	<488150A5.8050804@jcea.es>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
Message-ID: <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 11, 2008, at 5:51 AM, Antoine Pitrou wrote:

> Barry Warsaw <barry <at> python.org> writes:
>>
>> I agree.  Our last beta is scheduled for this wednesday
>
> Are you sure?
> According to http://mail.python.org/pipermail/python-3000/2008-July/014269.html 
> ,
> it's scheduled for August 23rd.

Ah darn, that's a typo in the PEP.  I definitely meant August 13, as  
the Google calendar shows.

Do we think we can be ready for beta3 this Wednesday?  If not, I'd  
rather stick to a weekday release and do it on Wednesday August 20th.   
Let me know what you think.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKAwI3EjvBPtnXfVAQLumgQAqq6Vmk9qMQQRQkapppNPkypj8IuJiRAN
MSCHi9iEj0RP4XpOuXF6oLAOJPajsabnC13J8Zu/tPqnrKR6gwTm/PG/6CDDi5tv
JqNQJwBWyXOT56TtDxXNaIy2HIS2Klu6uqNUXoUrGdLuBskWeNBWlj87GKs0ozhq
EfgXVbdl0+Y=
=ZZd7
-----END PGP SIGNATURE-----

From barry at python.org  Tue Aug 12 01:02:15 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 11 Aug 2008 19:02:15 -0400
Subject: [Python-3000] [Python-Dev] next beta
In-Reply-To: <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
References: <4838EA2D.7060402@jcea.es>
	<319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com>
	<488150A5.8050804@jcea.es>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
Message-ID: <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 11, 2008, at 8:27 AM, Barry Warsaw wrote:

> Ah darn, that's a typo in the PEP.  I definitely meant August 13, as  
> the Google calendar shows.
>
> Do we think we can be ready for beta3 this Wednesday?  If not, I'd  
> rather stick to a weekday release and do it on Wednesday August  
> 20th.  Let me know what you think.

It sounds like Wednesday August 13th will not be feasible, so we'll do  
beta 3 on Wednesday August 20th.  I've updated both the PEP and the  
Google Calendar.

Thanks,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKDE+XEjvBPtnXfVAQIATwQApbwwrof862rrH8YU0QP3gVENMU4TRpZx
9jdnJk+OZJpFo74XitnrWDsprY1r/lJdGaLnebfg9DztbjHVgCWvkRNXI7qIbRpf
QfSeMusrhVwDNITBhJ/0j+A1phWUQG6CU0dez+iKvCJUcohgDlFmlIsw8tCkgDYG
On7b7ZKlHd8=
=kLcU
-----END PGP SIGNATURE-----

From mg at daimi.au.dk  Wed Aug 13 10:38:08 2008
From: mg at daimi.au.dk (Martin Geisler)
Date: Wed, 13 Aug 2008 10:38:08 +0200
Subject: [Python-3000] translation support feature,
	via extended % operators
References: <331bbefa-7745-4447-8251-3527c0c3afb2@79g2000hsk.googlegroups.com>
	<bd849054-81ad-400c-b733-32a56802c095@z6g2000pre.googlegroups.com>
	<48A29ADE.9040707@g.nevcal.com>
Message-ID: <g82hc9p71jj.fsf@celano.unix.zurich.ibm.com>

Glenn Linderman <v+python at g.nevcal.com> writes:

> In this message I'll discuss a scheme for handling complex
> translations with multiple numeric parameters.

Have you had a look at the ngettext function?

  http://docs.python.org/dev/library/gettext.html#gettext.ngettext

I think it does most of what you propose, including letting the
translators write the little code snippets that will determine if it
should be '1 file' or 'n files'.

The gettext manual has more to say here:

  http://www.gnu.org/software/gettext/manual/gettext.html#Plural-forms

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080813/3c54d945/attachment.pgp>

From jcea at jcea.es  Wed Aug 13 19:14:21 2008
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 13 Aug 2008 19:14:21 +0200
Subject: [Python-3000] pybsddb 4.7.3pre1: Compatibility with Python 3.0
Message-ID: <48A3166D.8080703@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all.

Sorry for spamming several mailing list.

After many hours of hard work, I'm proud to present a preview of pybsddb
4.7.3, able to compile and work under Python 2.3, 2.4, 2.5, 2.6b2 and 3.0b2.

You can try it out downloading it directly from my repository:

~     svn co -r 597 svn://svn.argo.es/jcea/pybsddb/trunk \
~       pybsddb-4.7.3pre1

Please, DO NOT download any other revision, since I can make changes
anytime, breaking things.

To exercise the testsuite (currently, 304 tests, if you are running the
more recent Berkeley DB release (4.7.25)), do:

~     python2.3 test.py -bv
~     python2.4 test.py -bv
~     python2.5 test.py -bv
~     python2.6 test.py -bv
~     python3.0 test.py -bv

This will compile the code and run the testsuite for each supported
python release. Of course you need to have Berkeley DB installed, better
if you have 4.6 (fully patched, the original release was very buggy) or
the last 4.7.25 release (rock solid).

You can install the code using the usual "python setup.py install".

BEWARE, nevertheless; this code is not ready for production use,
especially under Python 3.0. But, please, test your code with this
preview. Test it as hard as you can.

Current code has several ugly hacks (like some abuse of "hasattr" to
avoid selected automatic 2to3 conversion), but it works and it will be
improved in the future.

Please, report any issue, incompatibility or improvement you can see.

I plan to release pybsddb 4.7.3 in mid-september, ready to be delivered
bundled in Python 2.6/3.0 (to be released early in october).

I'll be on summer holidays, 100% offline, until early september. I will
read your comments as soon as possible. Thanks for your time!.

Homepage:
http://www.jcea.es/programacion/pybsddb.htm
http://www.jcea.es/programacion/pybsddb.htm#bsddb-4.7.3
http://www.jcea.es/programacion/pybsddb_doc/preview/

CHANGES SINCE 4.7.2:
"""
~  * "private" is a keyword in C++.  (Duncan Grisby)
~  * setup.py should install "bsddb.h".  (Duncan Grisby)
~  * "DB_remove" memory corruption & crash.  (Duncan Grisby)
~  * Under Python 3.0, you can't use string keys/values, but
~    bytes ones. Print the right error message.
~  * "DB.has_key()" allowed transactions as a positional parameter.
~    We allow, now, transactions as a keyword parameter also, as
~    documented.
~  * Correct "DB.associate()" parameter order in the documentation.
~  * "DB.append()" recognizes "txn" both as a positional and a
~    keyword parameter.
~  * Small fix in "dbshelve" for compatibility with Python 3.0.
~  * A lot of changes in "dbtables" for compatibility with Python 3.0.
~  * Huge work making the testsuite compatible with Python 3.0.
~  * In some cases the C module returned Unicode strings under
~    Python 3.0. It should return "bytes", ALWAYS. Solved.
"""


NOTES ABOUT PYTHON 3.0:
The most visible change in Python 3.0, related to this library, is that
Python 2.x strings are replaced by unicode strings and "bytes" objects.
Under Python 3.0, pybsddb always consumes and produces "bytes" objects.
Unicode strings are rejected.

To easy testsuite porting, I've defined some minimal proxy/adapter
objects to facade unicode strings from/to "bytes". So, current testsuite
works for every supported python release, with the minimal conditional
code. These adapter objects ARE NOT INTENTED to be used in production.
If you are developing for Python 3.0, just use the right approach: use
the native "bytes" objects.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSKMWY5lgi5GaxT1NAQL64gP/flHcMi3PIMuy2iiMZftYZ9GLVFLztxxD
FZBivMJj/n3+B6tQ4PK9FZwYvelE4lgTPuC/Lv94SJi8xW3CxtLyjoUcj7Pobf3t
8cV6jXdcczQbYa8/4+kptQyHhr/lNnQD9vZ7Do1+D8Zdoz/vUM6yXKoKQnAiDcfQ
0qmlY+15SgA=
=RNRk
-----END PGP SIGNATURE-----

From jcea at jcea.es  Thu Aug 14 06:33:05 2008
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 14 Aug 2008 06:33:05 +0200
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <488F6BA1.1020806@v.loewis.de>
References: <488F29FE.6090800@jcea.es> <488F6BA1.1020806@v.loewis.de>
Message-ID: <48A3B581.2080204@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin v. L?wis wrote:
|> So, I'm thinking seriously in accepting *ONLY* "bytes" in the bsddb API
|> (when working under Python 3.0), and do the proxy thing *ONLY* in the
|> testsuite, to be able to reuse it.
|>
|> What do you think?.
|
| I think you should write the test suite in terms of bytes.

The problem is that pybsddb must work in python 2.3, 2.4, 2.5, 2.6 and 3.0.

My final approach was to write some proxy/adapter objects to manage the
unicode<->bytes conversion, so being able to share testsuite and
basecode between all pybsddb supported platforms.

Not the nicest thing to do, but the the bulk of code is unchanged and
fully shared in any supported python version. The adapter code is big,
but isolated.

Some code would be simplest if pybsddb classes allowed subclassing. This
is in my "todo" list.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSKO1e5lgi5GaxT1NAQIR1QP+IRAATC3K/BNYzSjxj+hn9oKqhpG+IJcv
Jl05MPHd1+/GMpD/Fzug8dZ0POG202DXoyD6a5R2lJlkPT/5R+8G170FQMXaO2EV
Df6juuWjMlg4CRUvSmX62uHWPGs70YtD6j+M26sQaMqUQckUNiIdKnjKYgaQa0tI
rbNWCF0wr7g=
=PL4N
-----END PGP SIGNATURE-----

From jcea at jcea.es  Thu Aug 14 07:05:52 2008
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 14 Aug 2008 07:05:52 +0200
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <A39B71EC-1816-4C70-B2A5-BECF3882B051@gmail.com>
References: <488F29FE.6090800@jcea.es>
	<A39B71EC-1816-4C70-B2A5-BECF3882B051@gmail.com>
Message-ID: <48A3BD30.20901@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Klaas wrote:
| You may find this thread to be relevant:
|
| http://mail.python.org/pipermail/python-3000/2007-August/009197.html

Very relevant, indeed.

I will think about the "callback" option to convert both keys and values
(in both directions). This would be very nice if pybsddb classes could
be subclassed, inplementing in the subclass the appropiate conversion
methods.

But this is not going to be ready for 2.6/3.0.

Performance would be an issue, though. Although any code demanding the
callback conversion functions would do the conversion directly, so
paying for this work in a way or another.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSKO9IZlgi5GaxT1NAQJ6aQQAoHKpyoRV28IAbD7v2UJZe/53Dz2t3krf
on9ojRTH1e/VhpOdNusLuvp5CurrWCtZqcvLViOKP/qIpLs8Q2M0lw5y35q15FIh
s8UpW+qmW+w5zaU8iQDrr8jjw9jFtHlkoDw5XD2hA/vRh4AIOHiXFN5Nta6GZtGd
LC3XvyYAQu0=
=ph+v
-----END PGP SIGNATURE-----

From jcea at jcea.es  Thu Aug 14 07:10:00 2008
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 14 Aug 2008 07:10:00 +0200
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <489072DB.7050201@egenix.com>
References: <488F29FE.6090800@jcea.es>	<20080730022402.01A4B5CCC95@longblack.object-craft.com.au>	<488FF604.507@v.loewis.de>	<20080730051726.BA11E5CCC96@longblack.object-craft.com.au>
	<489072DB.7050201@egenix.com>
Message-ID: <48A3BE28.8000507@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

M.-A. Lemburg wrote:
| Since bsddb is about storing arbitrary data, I think just accepting
| bytes for both keys and values is more intuitive.

Agreed. This is the approach I've done in current code.

| The question of encoding is application and database specific, so
| not something you'd want to put into a low-level interface.

Agreed.

| BTW: If you make the database object subclassable, an application
| could easily implement whatever strategy is needed on top of the
| bytes-only interface.

Current pybsddb code don't allow subclassing or adding new attibutes to
a given instance. I will (probably) work on this for a future pybsddb
version. Pointers to references to do this kind of magic welcomed :-)

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSKO+KJlgi5GaxT1NAQL+dgP+PRVTPmAhvsK+qkUqb32K8/tsMwb+HKV2
lR5Tn6w0bLRLARvVAfcNKtXfkJZo/IAqJFUrAE8JlNZlnMWyL3+A67oj0Aghi2ft
K82ysrMNh/wd+QkBg1kavrJOrbrBeswupBsDAIjrRvbKhIDbOzCkAbzz7P6eG97d
Qxck/l+wu6A=
=ceBz
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Thu Aug 14 11:51:13 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 14 Aug 2008 11:51:13 +0200
Subject: [Python-3000] translation support feature,
	via extended % operators
In-Reply-To: <48A29ADE.9040707@g.nevcal.com>
References: <331bbefa-7745-4447-8251-3527c0c3afb2@79g2000hsk.googlegroups.com>	<bd849054-81ad-400c-b733-32a56802c095@z6g2000pre.googlegroups.com>
	<48A29ADE.9040707@g.nevcal.com>
Message-ID: <48A40011.3020102@v.loewis.de>

> In this message I'll discuss a scheme for handling complex
> translations with multiple numeric parameters.

Please take a look at the plural support in gettext. I think it
should allow you to achieve the proper string substitution already
today.

Regards,
Martin

From martin at v.loewis.de  Thu Aug 14 12:22:32 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 14 Aug 2008 12:22:32 +0200
Subject: [Python-3000] translation support feature,
	via extended % operators
In-Reply-To: <48A344B9.8070302@g.nevcal.com>
References: <331bbefa-7745-4447-8251-3527c0c3afb2@79g2000hsk.googlegroups.com>	<bd849054-81ad-400c-b733-32a56802c095@z6g2000pre.googlegroups.com>	<48A29ADE.9040707@g.nevcal.com>	<g82hc9p71jj.fsf@celano.unix.zurich.ibm.com>
	<48A344B9.8070302@g.nevcal.com>
Message-ID: <48A40768.2000908@v.loewis.de>

> With some languages
> requiring restructuring of the phraseology, what seems to be the first
> fragment and the second fragment may no longer be ordered in the same
> manner in a target language.

That is theoretical, right? For a specific message, and a specific set
of languages, I'm fairly optimistic that you can split the message so
that you can translate the fragments individually, and then paste them
together again so that it still "works" in all languages.

> Hence the code that pastes the English
> fragments back together may be wrong for a target language.

Perhaps. However, if you change the pasting, you should be able to find
a solution that works for all languages.

> Further,
> multiple target languages could have conflicting reorderings, such that
> it is nearly impossible to write a single piece of code to paste the
> fragments back together.

Example?

Also, what makes you believe that your approach will solve this problem?

IIUC, it should be fairly straight-forward to map your syntax to
gettext. It seems that you propose to have multiple placeholders
in a skeleton sentence, each placeholder potentially substituting
different depending on the value of a parameter.

I think this can be mapped fairly easily onto gettext: make one message
for each of your placeholders, and another message for the skeleton.
IOW, they both have the same expressiveness.

As another note: I don't think your ord() function can work. In some
languages, the ordinal words depend on the gender of the noun. E.g.
Russian:

"the first man"   - "?????? ???????" / "?????? ???????"
"the first woman" - "?????? ???????"

Here, "??" indicates male, "??". Things get further complicated
by case, e.g. German (likewise for Russian)

"the first man" - "der erste Mann"
"for the first man" - "f?r den ersten Mann"

Regards,
Martin

From stephen at xemacs.org  Thu Aug 14 17:50:32 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 15 Aug 2008 00:50:32 +0900
Subject: [Python-3000] translation support feature,
	via extended % operators
In-Reply-To: <48A40768.2000908@v.loewis.de>
References: <331bbefa-7745-4447-8251-3527c0c3afb2@79g2000hsk.googlegroups.com>
	<bd849054-81ad-400c-b733-32a56802c095@z6g2000pre.googlegroups.com>
	<48A29ADE.9040707@g.nevcal.com>
	<g82hc9p71jj.fsf@celano.unix.zurich.ibm.com>
	<48A344B9.8070302@g.nevcal.com> <48A40768.2000908@v.loewis.de>
Message-ID: <87vdy3h9yv.fsf@uwakimon.sk.tsukuba.ac.jp>

"Martin v. L?wis" writes:

 > > With some languages
 > > requiring restructuring of the phraseology, what seems to be the first
 > > fragment and the second fragment may no longer be ordered in the same
 > > manner in a target language.
 > 
 > That is theoretical, right? For a specific message, and a specific set
 > of languages, I'm fairly optimistic that you can split the message so
 > that you can translate the fragments individually, and then paste them
 > together again so that it still "works" in all languages.

As far as I know, translators rarely complain about this kind of
issue.  I've never seen it on debian-i18n, for example.  I would think
Japanese would be one of the worst for reordering, but I haven't
heard of it from Japanese translators I know.

In any case trying to design an improved facility in the absence of
concrete examples that we need to handle, but currently don't, will
not work well.  Translation is a field where the devil is indeed in
the details.

From mal at egenix.com  Thu Aug 14 21:50:59 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 14 Aug 2008 21:50:59 +0200
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <48A3BE28.8000507@jcea.es>
References: <488F29FE.6090800@jcea.es>	<20080730022402.01A4B5CCC95@longblack.object-craft.com.au>	<488FF604.507@v.loewis.de>	<20080730051726.BA11E5CCC96@longblack.object-craft.com.au>	<489072DB.7050201@egenix.com>
	<48A3BE28.8000507@jcea.es>
Message-ID: <48A48CA3.6090902@egenix.com>

On 2008-08-14 07:10, Jesus Cea wrote:
> M.-A. Lemburg wrote:
> | BTW: If you make the database object subclassable, an application
> | could easily implement whatever strategy is needed on top of the
> | bytes-only interface.
> 
> Current pybsddb code don't allow subclassing or adding new attibutes to
> a given instance. I will (probably) work on this for a future pybsddb
> version. Pointers to references to do this kind of magic welcomed :-)

I can't give you a cookbook reference for converting existing
C extensions to subclassable ones, but if you look at e.g.
the code one of the more recently added builtin objects, you
should be able to extract the required details.

It's mostly about getting the constructors right and replacing
the attribute lookup code with getters/setters.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 14 2008)
>>> 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,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From solipsis at pitrou.net  Thu Aug 14 23:49:56 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 14 Aug 2008 21:49:56 +0000 (UTC)
Subject: [Python-3000] python -S
Message-ID: <loom.20080814T214251-841@post.gmane.org>

Hello,

I have a problem with "python -S". When python is launched from its build dir,
the extension build dir is not added to sys.path, and thus importing some
modules fails:

$ ./python -S -c "import threading"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/antoine/py3k/pristine/Lib/threading.py", line 6, in <module>
    from time import time as _time, sleep as _sleep
ImportError: No module named time

The problem is that "python -S" is tested by test_cmdline, and it fails if I try
to import the threading module in io.py, as io.py is needed to initialize the
standard streams. 

Any thoughts?

Antoine.



From lists at cheimes.de  Thu Aug 14 23:25:58 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 14 Aug 2008 23:25:58 +0200
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <48A3BE28.8000507@jcea.es>
References: <488F29FE.6090800@jcea.es>	<20080730022402.01A4B5CCC95@longblack.object-craft.com.au>	<488FF604.507@v.loewis.de>	<20080730051726.BA11E5CCC96@longblack.object-craft.com.au>	<489072DB.7050201@egenix.com>
	<48A3BE28.8000507@jcea.es>
Message-ID: <48A4A2E6.6080106@cheimes.de>

Jesus Cea wrote:
> Current pybsddb code don't allow subclassing or adding new attibutes to
> a given instance. I will (probably) work on this for a future pybsddb
> version. Pointers to references to do this kind of magic welcomed :-)

For making it subclass-able you have to add Py_TPFLAGS_BASETYPE to the 
type flags. In order to make new attributes possible you either need to 
mess around with tp_dict or tp_dictoffset. Grepping for 
_PyObject_GetDictPtr should give you some hints.

Christian

From martin at v.loewis.de  Fri Aug 15 00:13:47 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 15 Aug 2008 00:13:47 +0200
Subject: [Python-3000] python -S
In-Reply-To: <loom.20080814T214251-841@post.gmane.org>
References: <loom.20080814T214251-841@post.gmane.org>
Message-ID: <48A4AE1B.1000601@v.loewis.de>

> Any thoughts?

That is http://bugs.python.org/issue586680, right?

As a work-around, test_cmd_line should set PYTHONPATH to include
the build directory (i.e. what addbuilddir has added).

Regards,
Martin

From solipsis at pitrou.net  Fri Aug 15 01:18:54 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 14 Aug 2008 23:18:54 +0000 (UTC)
Subject: [Python-3000] python -S
References: <loom.20080814T214251-841@post.gmane.org>
Message-ID: <loom.20080814T231300-971@post.gmane.org>


Well, it looks like I underestimated the consequences of making io.py depend on
the threading module. Is it ok if I add itertools, operator, _collections and
time to the list of statically compiled modules? They are needed by threading,
and thus necessary for running setup.py on a blank checkout.


Antoine.



From lists at cheimes.de  Fri Aug 15 01:40:32 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 15 Aug 2008 01:40:32 +0200
Subject: [Python-3000] python -S
In-Reply-To: <loom.20080814T231300-971@post.gmane.org>
References: <loom.20080814T214251-841@post.gmane.org>
	<loom.20080814T231300-971@post.gmane.org>
Message-ID: <g82fpg$uc$1@ger.gmane.org>

Antoine Pitrou wrote:
> Well, it looks like I underestimated the consequences of making io.py depend on
> the threading module. Is it ok if I add itertools, operator, _collections and
> time to the list of statically compiled modules? They are needed by threading,
> and thus necessary for running setup.py on a blank checkout.

Couldn't you use "from _thread import allocate_lock as Lock" instead? I 
know, I know, never use a private module directly. But the io module is 
crucial to the interpreter startup. Do we really want to load four 
additional C modules and one Python module at *every* startup?

Christian


From solipsis at pitrou.net  Fri Aug 15 02:08:59 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 15 Aug 2008 00:08:59 +0000 (UTC)
Subject: [Python-3000] python -S
References: <loom.20080814T214251-841@post.gmane.org>
	<loom.20080814T231300-971@post.gmane.org>
	<g82fpg$uc$1@ger.gmane.org>
Message-ID: <loom.20080815T000700-657@post.gmane.org>

Christian Heimes <lists <at> cheimes.de> writes:
> 
> Couldn't you use "from _thread import allocate_lock as Lock" instead?

I feel stupid for not thinking of such an obvious solution.
(by the way, is _thread always available?)



From lists at cheimes.de  Fri Aug 15 02:32:24 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 15 Aug 2008 02:32:24 +0200
Subject: [Python-3000] python -S
In-Reply-To: <loom.20080815T000700-657@post.gmane.org>
References: <loom.20080814T214251-841@post.gmane.org>	<loom.20080814T231300-971@post.gmane.org>	<g82fpg$uc$1@ger.gmane.org>
	<loom.20080815T000700-657@post.gmane.org>
Message-ID: <g82iqp$7r7$1@ger.gmane.org>

Antoine Pitrou wrote:
> I feel stupid for not thinking of such an obvious solution.
> (by the way, is _thread always available?)

_thread is a builtin module. It's available on every platform that 
supports threading (which should be all platforms we support). If you 
want to be extra carefully then use _dummy_thread as a fallback.

try:
     from _thread import allocate_lock as Lock
except ImportError:
     from _dummy_thread import allocate_lock as Lock

By the way I did some testing. We could save the load of the re and 
couple of sre_* modules by rewriting a tiny bit of linecache. The 
linecache module is using re to find the "# coding: spec" of a Python 
source file when the load fails to return the source of a file. It'd 
reduce the amount of loaded modules by 5.

Remove "import types" from warnings.py and you'll get one for free.

Christian


From brett at python.org  Fri Aug 15 05:47:58 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 14 Aug 2008 20:47:58 -0700
Subject: [Python-3000] python -S
In-Reply-To: <g82iqp$7r7$1@ger.gmane.org>
References: <loom.20080814T214251-841@post.gmane.org>
	<loom.20080814T231300-971@post.gmane.org> <g82fpg$uc$1@ger.gmane.org>
	<loom.20080815T000700-657@post.gmane.org> <g82iqp$7r7$1@ger.gmane.org>
Message-ID: <bbaeab100808142047g5d75eb1dt31b8e37395e3fd38@mail.gmail.com>

On Thu, Aug 14, 2008 at 5:32 PM, Christian Heimes <lists at cheimes.de> wrote:
> Antoine Pitrou wrote:
>>
>> I feel stupid for not thinking of such an obvious solution.
>> (by the way, is _thread always available?)
>
> _thread is a builtin module. It's available on every platform that supports
> threading (which should be all platforms we support). If you want to be
> extra carefully then use _dummy_thread as a fallback.
>
> try:
>    from _thread import allocate_lock as Lock
> except ImportError:
>    from _dummy_thread import allocate_lock as Lock
>
> By the way I did some testing. We could save the load of the re and couple
> of sre_* modules by rewriting a tiny bit of linecache. The linecache module
> is using re to find the "# coding: spec" of a Python source file when the
> load fails to return the source of a file. It'd reduce the amount of loaded
> modules by 5.
>

Speaking with my importlib hat on, I need a function that can easily
return the encoding of a file, so I have another legit use-case for
the functionality where exposing it through some built-in fashion
would be REALLY appreciated (I have one hacked together as
imp.source_open() in my bootstrapping work, but I still don't think it
is a very good solution).

> Remove "import types" from warnings.py and you'll get one for free.

Who is loading 'warnings'? If it something minor and very
startup-specific, perhaps using _warnings instead is a possibility.

-Brett

From solipsis at pitrou.net  Fri Aug 15 00:35:47 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 15 Aug 2008 00:35:47 +0200
Subject: [Python-3000] python -S
In-Reply-To: <48A4AE1B.1000601@v.loewis.de>
References: <loom.20080814T214251-841@post.gmane.org>
	<48A4AE1B.1000601@v.loewis.de>
Message-ID: <1218753347.5572.31.camel@fsol>

Le vendredi 15 ao?t 2008 ? 00:13 +0200, "Martin v. L?wis" a ?crit :
> > Any thoughts?
> 
> That is http://bugs.python.org/issue586680, right?
> 
> As a work-around, test_cmd_line should set PYTHONPATH to include
> the build directory (i.e. what addbuilddir has added).

Thanks a lot for the suggestion. Works perfectly.

Regards

Antoine.



From lists at cheimes.de  Fri Aug 15 10:09:05 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 15 Aug 2008 10:09:05 +0200
Subject: [Python-3000] python -S
In-Reply-To: <bbaeab100808142047g5d75eb1dt31b8e37395e3fd38@mail.gmail.com>
References: <loom.20080814T214251-841@post.gmane.org>	
	<loom.20080814T231300-971@post.gmane.org>
	<g82fpg$uc$1@ger.gmane.org>	
	<loom.20080815T000700-657@post.gmane.org>
	<g82iqp$7r7$1@ger.gmane.org>
	<bbaeab100808142047g5d75eb1dt31b8e37395e3fd38@mail.gmail.com>
Message-ID: <48A539A1.2000701@cheimes.de>

Brett Cannon wrote:
> Speaking with my importlib hat on, I need a function that can easily
> return the encoding of a file, so I have another legit use-case for
> the functionality where exposing it through some built-in fashion
> would be REALLY appreciated (I have one hacked together as
> imp.source_open() in my bootstrapping work, but I still don't think it
> is a very good solution).

I've send you a patch.

> Who is loading 'warnings'? If it something minor and very
> startup-specific, perhaps using _warnings instead is a possibility.

It's always loaded by Python/pythonrun.c

Christian

From ncoghlan at gmail.com  Fri Aug 15 11:51:57 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 15 Aug 2008 19:51:57 +1000
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <48A4A2E6.6080106@cheimes.de>
References: <488F29FE.6090800@jcea.es>	<20080730022402.01A4B5CCC95@longblack.object-craft.com.au>	<488FF604.507@v.loewis.de>	<20080730051726.BA11E5CCC96@longblack.object-craft.com.au>	<489072DB.7050201@egenix.com>	<48A3BE28.8000507@jcea.es>
	<48A4A2E6.6080106@cheimes.de>
Message-ID: <48A551BD.4070409@gmail.com>

Christian Heimes wrote:
> Jesus Cea wrote:
>> Current pybsddb code don't allow subclassing or adding new attibutes to
>> a given instance. I will (probably) work on this for a future pybsddb
>> version. Pointers to references to do this kind of magic welcomed :-)
> 
> For making it subclass-able you have to add Py_TPFLAGS_BASETYPE to the
> type flags. In order to make new attributes possible you either need to
> mess around with tp_dict or tp_dictoffset. Grepping for
> _PyObject_GetDictPtr should give you some hints.

There's no real reason to do the latter though - none of the builtin
Python types permit it since once you make the class subclassable, it's
fairly easy for people to add the facility for themselves (as a standard
Python class, the subclass gets a __dict__ attribute automatically).

Cheers,
Nick.

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

From hyeshik at gmail.com  Fri Aug 15 15:41:53 2008
From: hyeshik at gmail.com (Hye-Shik Chang)
Date: Fri, 15 Aug 2008 22:41:53 +0900
Subject: [Python-3000] Workaround for py3k build problem on CJK MacOS X?
Message-ID: <4f0b69dc0808150641n69f53e1br228f1faaef9ad62c@mail.gmail.com>

Currently, Python 3.0 fails to build in MacOS X with CJK locales
due to lack of codec support for preferred encodings, such as
MacJapanese or MacKorean, provided by locale.getpreferredencoding().
We have a patch that implements the codecs that resolves the problem
in issue #1276, but it's too late to put the new code into the
upcoming release. So, I propose few alternative temporary workarounds
that can be incorporated in 3.0.

1) Add temporary encoding aliases.

All Macintosh CJK encodings have their base legacy encoding that
is supported by Python already. They are virtually identical to the
legacy encodings except few Apple extension codepoints which are
rarely used. Just adding aliases will immediately resolve the problem
while it's little bit incorrect.


2) Force to use non-CJK encoding in build process.

The preferred encoding comes from an environment variable,
__CF_USER_TEXT_ENCODING. We can easily change the encoding to U.S.
English by setting the env variable in Makefile. But this still
means locale.getpreferredencoding() returns non-support encoding
on installed runtime on MacOS X with CJK locales.  The problem has
been mentioned several times by users of applications that refers
the preferred encoding, such as Django.


3) Add Mac script to legacy encoding mapping in _locale.

There's a function, mac_getscript(), that converts Macintosh encoding
name to Python codec encoding in _localemodule.c. We shall add
temporary mappings from Macintosh's to their legacy base encoding.
This is also not quite correct like 1), but there'll be no problem
in practical use.


4) Add FAQ entry in the documentation.

Alternative to the code changes, we can just add a FAQ entry about the
problem on MacOS X with CJK locales in the documentation.


What do you think?



Hye-Shik

From mal at egenix.com  Fri Aug 15 19:00:07 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 15 Aug 2008 19:00:07 +0200
Subject: [Python-3000] Workaround for py3k build problem on CJK MacOS X?
In-Reply-To: <4f0b69dc0808150641n69f53e1br228f1faaef9ad62c@mail.gmail.com>
References: <4f0b69dc0808150641n69f53e1br228f1faaef9ad62c@mail.gmail.com>
Message-ID: <48A5B617.7090905@egenix.com>

On 2008-08-15 15:41, Hye-Shik Chang wrote:
> Currently, Python 3.0 fails to build in MacOS X with CJK locales
> due to lack of codec support for preferred encodings, such as
> MacJapanese or MacKorean, provided by locale.getpreferredencoding().
> We have a patch that implements the codecs that resolves the problem
> in issue #1276, but it's too late to put the new code into the
> upcoming release. So, I propose few alternative temporary workarounds
> that can be incorporated in 3.0.
> 
> 1) Add temporary encoding aliases.
> 
> All Macintosh CJK encodings have their base legacy encoding that
> is supported by Python already. They are virtually identical to the
> legacy encodings except few Apple extension codepoints which are
> rarely used. Just adding aliases will immediately resolve the problem
> while it's little bit incorrect.

I think this is the best solution for 3.0. In 3.1 we should then
ship proper codecs for the various Asian Mac encodings.

> 4) Add FAQ entry in the documentation.
> 
> Alternative to the code changes, we can just add a FAQ entry about the
> problem on MacOS X with CJK locales in the documentation.

We should add a note about the slightly wrong codec usage in 3.0 to
the FAQ and probably also to the NEWS file.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 15 2008)
 >>> 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,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From brett at python.org  Fri Aug 15 19:50:10 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 15 Aug 2008 10:50:10 -0700
Subject: [Python-3000] python -S
In-Reply-To: <48A539A1.2000701@cheimes.de>
References: <loom.20080814T214251-841@post.gmane.org>
	<loom.20080814T231300-971@post.gmane.org> <g82fpg$uc$1@ger.gmane.org>
	<loom.20080815T000700-657@post.gmane.org> <g82iqp$7r7$1@ger.gmane.org>
	<bbaeab100808142047g5d75eb1dt31b8e37395e3fd38@mail.gmail.com>
	<48A539A1.2000701@cheimes.de>
Message-ID: <bbaeab100808151050m160d8c67ka65fbb2f0fe43165@mail.gmail.com>

On Fri, Aug 15, 2008 at 1:09 AM, Christian Heimes <lists at cheimes.de> wrote:
> Brett Cannon wrote:
>>
>> Speaking with my importlib hat on, I need a function that can easily
>> return the encoding of a file, so I have another legit use-case for
>> the functionality where exposing it through some built-in fashion
>> would be REALLY appreciated (I have one hacked together as
>> imp.source_open() in my bootstrapping work, but I still don't think it
>> is a very good solution).
>
> I've send you a patch.
>
>> Who is loading 'warnings'? If it something minor and very
>> startup-specific, perhaps using _warnings instead is a possibility.
>
> It's always loaded by Python/pythonrun.c
>

Really? Without really digging into the code too much I see that if
warnings were set on the command-line it's loaded, otherwise it's
skipped.

-Brett

From lists at cheimes.de  Fri Aug 15 20:53:17 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 15 Aug 2008 20:53:17 +0200
Subject: [Python-3000] python -S
In-Reply-To: <bbaeab100808151050m160d8c67ka65fbb2f0fe43165@mail.gmail.com>
References: <loom.20080814T214251-841@post.gmane.org>	<loom.20080814T231300-971@post.gmane.org>
	<g82fpg$uc$1@ger.gmane.org>	<loom.20080815T000700-657@post.gmane.org>
	<g82iqp$7r7$1@ger.gmane.org>	<bbaeab100808142047g5d75eb1dt31b8e37395e3fd38@mail.gmail.com>	<48A539A1.2000701@cheimes.de>
	<bbaeab100808151050m160d8c67ka65fbb2f0fe43165@mail.gmail.com>
Message-ID: <48A5D09D.6020102@cheimes.de>

Brett Cannon wrote:
> Really? Without really digging into the code too much I see that if
> warnings were set on the command-line it's loaded, otherwise it's
> skipped.

You are right. It's not loaded by pythonrun.c. The io module is 
importing warnings w/o using it. I fixed it in r65694

./python -S -c "import sys; print(list(sorted(sys.modules)), 
len(sys.modules))"

Before:
['__main__', '_abcoll', '_codecs', '_fileio', '_sre', '_thread', 
'_warnings', '_weakref', '_weakrefset', 'abc', 'builtins', 'codecs', 
'copyreg', 'encodings', 'encodings.aliases', 'encodings.latin_1', 
'encodings.utf_8', 'errno', 'genericpath', 'io', 'linecache', 'os', 
'os.path', 'posix', 'posixpath', 're', 'signal', 'sre_compile', 
'sre_constants', 'sre_parse', 'stat', 'sys', 'types', 'warnings', 
'zipimport'] 35

After:
['__main__', '_abcoll', '_codecs', '_fileio', '_thread', '_weakref', 
'_weakrefset', 'abc', 'builtins', 'codecs', 'copyreg', 'encodings', 
'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno', 
'genericpath', 'io', 'os', 'os.path', 'posix', 'posixpath', 'signal', 
'stat', 'sys', 'zipimport'] 26

I'm able to remove copyreg as well. It's imported to register some 
pickle/unpickle hooks. The code can be moved into the copyreg module safely.

Christian


From martin at v.loewis.de  Fri Aug 15 21:25:30 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 15 Aug 2008 21:25:30 +0200
Subject: [Python-3000] Workaround for py3k build problem on CJK MacOS X?
In-Reply-To: <4f0b69dc0808150641n69f53e1br228f1faaef9ad62c@mail.gmail.com>
References: <4f0b69dc0808150641n69f53e1br228f1faaef9ad62c@mail.gmail.com>
Message-ID: <48A5D82A.7050501@v.loewis.de>

> What do you think?

I see another alternative: invoke the Apple converters (assuming they
exist). Then, these encodings would only be available on OS X, but
that might be just sufficient.

Now, I'm not a CFString expert, but I would hope that the conversion
would only be a few lines of C code which can be reviewed quickly.

If that code cannot be contributed, I then prefer your option 3:
make mac_getscript return the slightly incorrect codec names. It's
better than returning "ascii" (which I think it should do, anyway,
as a fallback).

Regards,
Martin

From hyeshik at gmail.com  Sat Aug 16 14:48:58 2008
From: hyeshik at gmail.com (Hye-Shik Chang)
Date: Sat, 16 Aug 2008 21:48:58 +0900
Subject: [Python-3000] Workaround for py3k build problem on CJK MacOS X?
In-Reply-To: <48A5D82A.7050501@v.loewis.de>
References: <4f0b69dc0808150641n69f53e1br228f1faaef9ad62c@mail.gmail.com>
	<48A5D82A.7050501@v.loewis.de>
Message-ID: <4f0b69dc0808160548w4cdbfbe3tb81942927418d71a@mail.gmail.com>

On Sat, Aug 16, 2008 at 4:25 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> What do you think?
>
> I see another alternative: invoke the Apple converters (assuming they
> exist). Then, these encodings would only be available on OS X, but
> that might be just sufficient.
>
> Now, I'm not a CFString expert, but I would hope that the conversion
> would only be a few lines of C code which can be reviewed quickly.

I like the idea.  Here's a preliminary patch implements the codec:
http://people.freebsd.org/~perky/py3k-maccodec.diff (no tests or
documentations yet)

There're two build problems to be resolved in the patch. First,
that makes libpython depends on CoreFoundation framework, we need
to put "-framework CoreFoundation" somewhere around LIBS.  The next
is slightly tough.  I added new aliasmbcs() function in `site`
module to register a user encoding alias to mac codec like mbcs
codec does.  The function needs `locale` module which imports
`_locale` and `_functools`.  But they are not available yet on the
starting point of build process.  I think we'd better force
locale in build process on MacOS for the problem.

Like MBCS codec, the Mac codec implementation in the patch doesn't
support non-strict error modes and codec error callbacks. And it
has another problem in stateful encoders related to multiple candidates with
multiple unicode letters -> single Mac codepoint mappings like:

 U+2222        <-> 0xA768, and also
 U+2222 U+F87F <-> 0xA498

The problem can't be resolved when we're using CF string interface
only.  The codec would be appropriate just for secondary use when
the main codec isn't available.


Hye-Shik

From facundobatista at gmail.com  Sat Aug 16 16:04:24 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Sat, 16 Aug 2008 11:04:24 -0300
Subject: [Python-3000] parse_qs and parse_qsl functions
Message-ID: <e04bdf310808160704g36140bfbod0b68d38e91b9ed1@mail.gmail.com>

Hi!

The issue 600362 has two patches (one for 2.6 and the other for 3.0)
that are ready to commit (with a small change in the docs). This
patches relocates the parse_qs and parse_qsl functions into the
urlparse module (urllib.parse in 3k), bringing them from the cgi one.

For backward compatibility, those functions are also accessible from
the cgi module, but in the documentation says that the function was
moved, and you should use it from the urlparse one.

So, we don't have *any* change in the behaviour towards the final user.

Two questions:

- It's ok to do this now or we should wait for 3.1/2.7?

- Should we add a deprecation warning in the cgi module for this functions?

I propose to commit this now, but leave a deprecation warning for the
next release.

Thanks!!

-- 
. Facundo

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

From martin at v.loewis.de  Sat Aug 16 17:30:52 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 16 Aug 2008 17:30:52 +0200
Subject: [Python-3000] Workaround for py3k build problem on CJK MacOS X?
In-Reply-To: <4f0b69dc0808160548w4cdbfbe3tb81942927418d71a@mail.gmail.com>
References: <4f0b69dc0808150641n69f53e1br228f1faaef9ad62c@mail.gmail.com>	
	<48A5D82A.7050501@v.loewis.de>
	<4f0b69dc0808160548w4cdbfbe3tb81942927418d71a@mail.gmail.com>
Message-ID: <48A6F2AC.4000401@v.loewis.de>

> I like the idea.  Here's a preliminary patch implements the codec:
> http://people.freebsd.org/~perky/py3k-maccodec.diff (no tests or
> documentations yet)

It's not exactly what I had in mind (although it might be sufficient,
anyway): I thought not of a single codec, but many. They can be
called x-mac-%d, and be implemented with a lookup routine:

def lookup(name):
    if not name.startswith("x_mac_"): return None
    try:
        name = int(name[6:], 10)
    except ValueError:
        return name
    def encode(*args, **kw):
        return codecs.mac_encode(name, *args, **kw)
    def decode(*args, **kw):
        return codecs.mac_decode(name, *args, **kw)
    reader,writer likewise
    return encode,decode,reader,writer

That way, you always have a precise encoding name (this %d name
would be the Apple enumerator value, of course).

This assumes that OSX has always all the Apple codecs installed,
of course. Even if not, it may not be a problem if mac_encode
raises a proper exception if conversion fails.

> There're two build problems to be resolved in the patch. First,
> that makes libpython depends on CoreFoundation framework, we need
> to put "-framework CoreFoundation" somewhere around LIBS.

If that is a problem, we could move that codec into a separate module,
right?

> The next
> is slightly tough.  I added new aliasmbcs() function in `site`
> module to register a user encoding alias to mac codec like mbcs
> codec does.  The function needs `locale` module which imports
> `_locale` and `_functools`.  But they are not available yet on the
> starting point of build process.  I think we'd better force
> locale in build process on MacOS for the problem.

If you follow my approach, you wouldn't need such an alias.

> The problem can't be resolved when we're using CF string interface
> only.  The codec would be appropriate just for secondary use when
> the main codec isn't available.

I think these restrictions are fine.

Regards,
Martin

P.S. I don't think you need to make so many global functions.
This code could live completely in _codecsmodule.c, right?
Even if not, use _Py functions if you can - you don't need
to make those support different Py_UNICODE sizes.

From brett at python.org  Sat Aug 16 21:52:04 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 16 Aug 2008 12:52:04 -0700
Subject: [Python-3000] [Python-Dev] parse_qs and parse_qsl functions
In-Reply-To: <e04bdf310808160704g36140bfbod0b68d38e91b9ed1@mail.gmail.com>
References: <e04bdf310808160704g36140bfbod0b68d38e91b9ed1@mail.gmail.com>
Message-ID: <bbaeab100808161252l3ed4b26fjee08b4bbc1f8f5ce@mail.gmail.com>

On Sat, Aug 16, 2008 at 7:04 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> Hi!
>
> The issue 600362 has two patches (one for 2.6 and the other for 3.0)
> that are ready to commit (with a small change in the docs). This
> patches relocates the parse_qs and parse_qsl functions into the
> urlparse module (urllib.parse in 3k), bringing them from the cgi one.
>
> For backward compatibility, those functions are also accessible from
> the cgi module, but in the documentation says that the function was
> moved, and you should use it from the urlparse one.
>
> So, we don't have *any* change in the behaviour towards the final user.
>
> Two questions:
>
> - It's ok to do this now or we should wait for 3.1/2.7?
>
> - Should we add a deprecation warning in the cgi module for this functions?
>
> I propose to commit this now, but leave a deprecation warning for the
> next release.
>

Obviously Barry's call, but I think it's fine to do what you are proposing.

-Brett

From mal at egenix.com  Sun Aug 17 17:24:51 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 17 Aug 2008 17:24:51 +0200
Subject: [Python-3000] Workaround for py3k build problem on CJK MacOS X?
In-Reply-To: <48A6F2AC.4000401@v.loewis.de>
References: <4f0b69dc0808150641n69f53e1br228f1faaef9ad62c@mail.gmail.com>		<48A5D82A.7050501@v.loewis.de>	<4f0b69dc0808160548w4cdbfbe3tb81942927418d71a@mail.gmail.com>
	<48A6F2AC.4000401@v.loewis.de>
Message-ID: <48A842C3.8090803@egenix.com>

I'm -1 on taking this approach this late in the release process.

You are adding a completely new codec, which hasn't received enough
testing. Furthermore, the concept of relying on OS defined codecs is
not in line with our concept of shipping codecs that work on all
platforms, not just the OS where they happen to be available via
some system libraries (and then completely outside of our control).

For 3.0, please just add aliases to the existing codecs and a
note that this is just a work-around to be able to build Python
on Mac OS X.

For 3.1, we'll then have to add proper codecs for the missing
encodings, hopefully reusing the existing CJK mapping tables.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 17 2008)
 >>> 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,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

On 2008-08-16 17:30, Martin v. L?wis wrote:
>> I like the idea.  Here's a preliminary patch implements the codec:
>> http://people.freebsd.org/~perky/py3k-maccodec.diff (no tests or
>> documentations yet)
> 
> It's not exactly what I had in mind (although it might be sufficient,
> anyway): I thought not of a single codec, but many. They can be
> called x-mac-%d, and be implemented with a lookup routine:
> 
> def lookup(name):
>     if not name.startswith("x_mac_"): return None
>     try:
>         name = int(name[6:], 10)
>     except ValueError:
>         return name
>     def encode(*args, **kw):
>         return codecs.mac_encode(name, *args, **kw)
>     def decode(*args, **kw):
>         return codecs.mac_decode(name, *args, **kw)
>     reader,writer likewise
>     return encode,decode,reader,writer
> 
> That way, you always have a precise encoding name (this %d name
> would be the Apple enumerator value, of course).
> 
> This assumes that OSX has always all the Apple codecs installed,
> of course. Even if not, it may not be a problem if mac_encode
> raises a proper exception if conversion fails.
> 
>> There're two build problems to be resolved in the patch. First,
>> that makes libpython depends on CoreFoundation framework, we need
>> to put "-framework CoreFoundation" somewhere around LIBS.
> 
> If that is a problem, we could move that codec into a separate module,
> right?
> 
>> The next
>> is slightly tough.  I added new aliasmbcs() function in `site`
>> module to register a user encoding alias to mac codec like mbcs
>> codec does.  The function needs `locale` module which imports
>> `_locale` and `_functools`.  But they are not available yet on the
>> starting point of build process.  I think we'd better force
>> locale in build process on MacOS for the problem.
> 
> If you follow my approach, you wouldn't need such an alias.
> 
>> The problem can't be resolved when we're using CF string interface
>> only.  The codec would be appropriate just for secondary use when
>> the main codec isn't available.
> 
> I think these restrictions are fine.
> 
> Regards,
> Martin
> 
> P.S. I don't think you need to make so many global functions.
> This code could live completely in _codecsmodule.c, right?
> Even if not, use _Py functions if you can - you don't need
> to make those support different Py_UNICODE sizes.
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/mal%40egenix.com


From edreamleo at gmail.com  Sun Aug 17 19:40:39 2008
From: edreamleo at gmail.com (Edward K. Ream)
Date: Sun, 17 Aug 2008 12:40:39 -0500
Subject: [Python-3000] What is the state of xml.sax, tkinter, pmw?
Message-ID: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>

For Python 3.0b2 on Windows I don't see any test_xml_sax.py file in
Python30\Lib\test for b2. Do unit tests exist?

While trying to bring up Leo, I found what looks like a bug that will cause
any byte stream to loop when calling xml.sax.parser.parse.  My quick fix was
to change:

    while buffer != "":

to:

    while buffer != "" and buffer != b"":

at line 123 of xmlreader.py

Here is the entire function:

def parse(self, source):
        from . import saxutils
        source = saxutils.prepare_input_source(source)

        self.prepareParser(source)
        file = source.getByteStream()
        buffer = file.read(self._bufsize)
        ### while buffer != "":
        while buffer != "" and buffer != b"": ### EKR
            self.feed(buffer)
            buffer = file.read(self._bufsize)
        self.close()

For reference, here is the code in Leo that was hanging::

        parser = xml.sax.make_parser()
        parser.setFeature(xml.sax.handler.feature_external_ges,1)
            # Include external general entities, esp. xml-stylesheet lines.
        handler = saxContentHandler(c,inputFileName,silent,inClipboard)
        parser.setContentHandler(handler)
        ### theFile must be a byte stream?
        ### hangs in a loop in xmlreader.py near line 124.
        ### I hacked the code to fix it.
        parser.parse(theFile) # expat does not support parseString

In this case theFile is simply the result of open(filename,'r') Iirc,
attempting to speed up the parsing using various io.streams slowed things
down dramatically.  Anyway, the code above works in Python 2.5.

Python26 -3 reports no errors in Leo, although several errors are reported
in tkinter and Pmw 1.3.

I'm concerned about missing unit tests for the sax module. The new io module
has the potential to break lots of code in subtle ways, as shown above.

I can't tell you more about sax until I sidestep Pmw and tkinter libs that
aren't importing...Hopefully I'll get a curses gui working soon for Leo :-)

I'm highly motivated to get tkinter, Pmw and sax working...Let me know if I
can help.  Is anyone else working on these libs?

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo at gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080817/ae1b580e/attachment.htm>

From brett at python.org  Sun Aug 17 21:09:18 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 17 Aug 2008 12:09:18 -0700
Subject: [Python-3000] What is the state of xml.sax, tkinter, pmw?
In-Reply-To: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>
References: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>
Message-ID: <bbaeab100808171209q7b29fff0pa585c02e0c95053a@mail.gmail.com>

On Sun, Aug 17, 2008 at 10:40 AM, Edward K. Ream <edreamleo at gmail.com> wrote:
> For Python 3.0b2 on Windows I don't see any test_xml_sax.py file in
> Python30\Lib\test for b2. Do unit tests exist?
>

Wrong name; it's test_sax.

> While trying to bring up Leo, I found what looks like a bug that will cause
> any byte stream to loop when calling xml.sax.parser.parse.  My quick fix was
> to change:
>
>     while buffer != "":
>
> to:
>
>     while buffer != "" and buffer != b"":
>
> at line 123 of xmlreader.py
>
> Here is the entire function:
>
> def parse(self, source):
>         from . import saxutils
>         source = saxutils.prepare_input_source(source)
>
>         self.prepareParser(source)
>         file = source.getByteStream()
>         buffer = file.read(self._bufsize)
>         ### while buffer != "":
>         while buffer != "" and buffer != b"": ### EKR
>             self.feed(buffer)
>             buffer = file.read(self._bufsize)
>         self.close()
>
> For reference, here is the code in Leo that was hanging::
>
>         parser = xml.sax.make_parser()
>         parser.setFeature(xml.sax.handler.feature_external_ges,1)
>             # Include external general entities, esp. xml-stylesheet lines.
>         handler = saxContentHandler(c,inputFileName,silent,inClipboard)
>         parser.setContentHandler(handler)
>         ### theFile must be a byte stream?
>         ### hangs in a loop in xmlreader.py near line 124.
>         ### I hacked the code to fix it.
>         parser.parse(theFile) # expat does not support parseString
>
> In this case theFile is simply the result of open(filename,'r') Iirc,
> attempting to speed up the parsing using various io.streams slowed things
> down dramatically.  Anyway, the code above works in Python 2.5.
>

Can you report this as a bug on the tracker, Edward? Otherwise this is
just going to get lost.

> Python26 -3 reports no errors in Leo, although several errors are reported
> in tkinter and Pmw 1.3.
>

I have been working on silencing warnings in the stdlib. Hopefully I
got the ones you found for tkinter. Otherwise you will find out in b3
and you can file a bug. =)

-Brett

From gregor.lingl at aon.at  Mon Aug 18 10:15:45 2008
From: gregor.lingl at aon.at (Gregor Lingl)
Date: Mon, 18 Aug 2008 10:15:45 +0200
Subject: [Python-3000] turtle.Screen- how to implement best a Singleton
Message-ID: <48A92FB1.7010201@aon.at>

Hi,

this posting - concerning the new turtle module - goes to the Python-Dev 
and Python-3000 lists and to a couple of 'power users' of turtle 
graphics, hoping to recieve feedback from the developer's point of view 
as well as from the user's point of view.

Currently the implementations of the turtle.Screen class for Python 2.6 
and Python 3.0 differ by a 'tiny' detail with an important difference in 
behaviour. So clearly this has to be resolved  before the final 
release.(The origin of this difference is, that when I ported turtle.py 
to Python 3.0 I discovered (and 'fixed') what I now consider to be a bug 
in the 2.6 version.) I'd like to ask you kindly for your advice to 
achieve an optimal solution.

The posting consists of three parts:
1. Exposition of design goals
2. Problem with the implementation 
3. How to solve it?

Preliminary remark:  I've had some discussions on this topic before but 
I still do not see a clear solution. Moreover I'm well aware of the fact 
that using the Singleton pattern is controversial. So ...

1. Exposition of design goals
... why use the Singleton design pattern? The turtle module contains a 
TurtleScreen class, which implements methods to control the drawing area 
the turtle is (turtles are) drawing on. It's constructor needs a Tkinter 
Canvas as argument. In order to avoid the need for users to tinker 
around with Tkinter stuff there is the Screen(TurtleScreen) class, 
designed to be used by beginners(students, kids,...), particularly in 
interactive sessions.

A (THE (!)) Screen object is essentially a window containing a scrolled 
canvas, the TurtleScreen. So it's a ressource which should exist only 
once. It can be constructed in several ways:
- implicitely by calling an arbitrary function derived from a 
Turtle-method, such as forward(100) or by constructing a Turtle such as 
bob = Turtle()
- implicitely by calling an arbitrary function derived from a Screen 
method, such as bgcolor("red")
- explicitely by calling it's constructor such as s = Screen()
Anyway this construction should only happen if a Screen object doesn't 
exist yet.
Now for the pending question: What should happen, when s = Screen() is 
called explicitely and there exists already 'the' Screen object.
(i) Clearly s should get a reference to the existing Screen object, but ...
(ii) (a)... should s be reinitialized (this is the case now in Python 
2.6), or
     (b)... should s be left untouched (this is the case now in Python 3.0)

I, for my part, prefer the latter solution (b). Example: a student, 
having (interactively) produced some design using some turtle t = 
Turtle() decides spontaneously to change backgroundcolor. s = Screen(); 
s.bgcolor("pink") should do this for her - instead of deleting her 
design and moreover her turtle. To reinitialize the screen she still can 
use s.clear().

Of course, there are workarounds to achieve the same effect also with 
solution (a), for instance by assigning s = Screen() *before* drawing 
anything or by assigning s = t.getscreen(). But imho (which derives 
itself from my experience as a teacher) solution (b) supports better the 
oop-view as well as experimenting spontaneously in interactive sessions.

2. Problem with the implementation
The task is to derive a Singleton class from a Nonsingleton class 
(Screen from TurtleScreen). The current implementations of the Screen 
'Singleton' both use the Borg idiom.  Just for *explaining* the 
difference between the two versions of class Screen here concisely,  
I'll use a 'standard' Singleton pattern (roughly equivalent to the Borg 
idiom):

class Spam(object):
    def __init__(self, s):
        self.s = s

class SingleSpam(Spam):
    _inst = None
    def __new__(cls, *args, **kwargs):       
        if cls != type(cls._inst):
            cls._inst = Spam.__new__(cls, *args, **kwargs)
        return cls._inst
    def __init__(self, s):
        if vars(self): return    ######  should this be here???
        Spam.__init__(self, s)

Shortly, this means that SingleSpam.__init__() acts like an empty method 
whenever a (the!) SingleSpam object already exists. 3.0 version of 
Screen acts like this. By contrast 2.6 version of Screen acts as if the 
butlast line were not there and thus reinitializes the Screen object.

3. How to solve it?

Main question: which *behaviour* of the Screen class should be 
preferred.  If  3.0, is it feasible and correct not to call the 
constructor of the parent class if the object already exists?

Additional question: Do you consider the Borg idiom a good solution for 
this task or should the standard singleton pattern as shown above be 
preferred. Or would you suggest a solution/an approach different from both?

Thanks for your patience, and - in advance - for your assistance

Regard,
Gregor


 


From gregor.lingl at aon.at  Mon Aug 18 14:14:33 2008
From: gregor.lingl at aon.at (Gregor Lingl)
Date: Mon, 18 Aug 2008 14:14:33 +0200
Subject: [Python-3000] turtle.Screen- how to implement best a Singleton
In-Reply-To: <48A95CC6.9090706@canterburyschool.org>
References: <48A92FB1.7010201@aon.at> <48A95CC6.9090706@canterburyschool.org>
Message-ID: <48A967A9.3040102@aon.at>

Thanks for the feedback,
Gregor

Vern Ceder schrieb:
> Gregor,
>
> I don't feel authoritative on the correctness/appropriateness of the 
> implementation, but I do agree completely that behavior b, or what you 
> have in the 3.0 version, is vastly preferable.
>
> Cheers,
> Vern
>
> Gregor Lingl wrote:
>> Hi,
>>
>> this posting - concerning the new turtle module - goes to the 
>> Python-Dev and Python-3000 lists and to a couple of 'power users' of 
>> turtle graphics, hoping to recieve feedback from the developer's 
>> point of view as well as from the user's point of view.
>>
>> Currently the implementations of the turtle.Screen class for Python 
>> 2.6 and Python 3.0 differ by a 'tiny' detail with an important 
>> difference in behaviour. So clearly this has to be resolved  before 
>> the final release.(The origin of this difference is, that when I 
>> ported turtle.py to Python 3.0 I discovered (and 'fixed') what I now 
>> consider to be a bug in the 2.6 version.) I'd like to ask you kindly 
>> for your advice to achieve an optimal solution.
>>
>> The posting consists of three parts:
>> 1. Exposition of design goals
>> 2. Problem with the implementation 3. How to solve it?
>>
>> Preliminary remark:  I've had some discussions on this topic before 
>> but I still do not see a clear solution. Moreover I'm well aware of 
>> the fact that using the Singleton pattern is controversial. So ...
>>
>> 1. Exposition of design goals
>> ... why use the Singleton design pattern? The turtle module contains 
>> a TurtleScreen class, which implements methods to control the drawing 
>> area the turtle is (turtles are) drawing on. It's constructor needs a 
>> Tkinter Canvas as argument. In order to avoid the need for users to 
>> tinker around with Tkinter stuff there is the Screen(TurtleScreen) 
>> class, designed to be used by beginners(students, kids,...), 
>> particularly in interactive sessions.
>>
>> A (THE (!)) Screen object is essentially a window containing a 
>> scrolled canvas, the TurtleScreen. So it's a ressource which should 
>> exist only once. It can be constructed in several ways:
>> - implicitely by calling an arbitrary function derived from a 
>> Turtle-method, such as forward(100) or by constructing a Turtle such 
>> as bob = Turtle()
>> - implicitely by calling an arbitrary function derived from a Screen 
>> method, such as bgcolor("red")
>> - explicitely by calling it's constructor such as s = Screen()
>> Anyway this construction should only happen if a Screen object 
>> doesn't exist yet.
>> Now for the pending question: What should happen, when s = Screen() 
>> is called explicitely and there exists already 'the' Screen object.
>> (i) Clearly s should get a reference to the existing Screen object, 
>> but ...
>> (ii) (a)... should s be reinitialized (this is the case now in Python 
>> 2.6), or
>>     (b)... should s be left untouched (this is the case now in Python 
>> 3.0)
>>
>> I, for my part, prefer the latter solution (b). Example: a student, 
>> having (interactively) produced some design using some turtle t = 
>> Turtle() decides spontaneously to change backgroundcolor. s = 
>> Screen(); s.bgcolor("pink") should do this for her - instead of 
>> deleting her design and moreover her turtle. To reinitialize the 
>> screen she still can use s.clear().
>>
>> Of course, there are workarounds to achieve the same effect also with 
>> solution (a), for instance by assigning s = Screen() *before* drawing 
>> anything or by assigning s = t.getscreen(). But imho (which derives 
>> itself from my experience as a teacher) solution (b) supports better 
>> the oop-view as well as experimenting spontaneously in interactive 
>> sessions.
>>
>> 2. Problem with the implementation
>> The task is to derive a Singleton class from a Nonsingleton class 
>> (Screen from TurtleScreen). The current implementations of the Screen 
>> 'Singleton' both use the Borg idiom.  Just for *explaining* the 
>> difference between the two versions of class Screen here concisely,  
>> I'll use a 'standard' Singleton pattern (roughly equivalent to the 
>> Borg idiom):
>>
>> class Spam(object):
>>    def __init__(self, s):
>>        self.s = s
>>
>> class SingleSpam(Spam):
>>    _inst = None
>>    def __new__(cls, *args, **kwargs):              if cls != 
>> type(cls._inst):
>>            cls._inst = Spam.__new__(cls, *args, **kwargs)
>>        return cls._inst
>>    def __init__(self, s):
>>        if vars(self): return    ######  should this be here???
>>        Spam.__init__(self, s)
>>
>> Shortly, this means that SingleSpam.__init__() acts like an empty 
>> method whenever a (the!) SingleSpam object already exists. 3.0 
>> version of Screen acts like this. By contrast 2.6 version of Screen 
>> acts as if the butlast line were not there and thus reinitializes the 
>> Screen object.
>>
>> 3. How to solve it?
>>
>> Main question: which *behaviour* of the Screen class should be 
>> preferred.  If  3.0, is it feasible and correct not to call the 
>> constructor of the parent class if the object already exists?
>>
>> Additional question: Do you consider the Borg idiom a good solution 
>> for this task or should the standard singleton pattern as shown above 
>> be preferred. Or would you suggest a solution/an approach different 
>> from both?
>>
>> Thanks for your patience, and - in advance - for your assistance
>>
>> Regard,
>> Gregor
>>
>>
>>
>>
>


From solipsis at pitrou.net  Mon Aug 18 18:33:00 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 18 Aug 2008 16:33:00 +0000 (UTC)
Subject: [Python-3000] XML as bytes or unicode?
References: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>
	<bbaeab100808171209q7b29fff0pa585c02e0c95053a@mail.gmail.com>
Message-ID: <loom.20080818T162617-305@post.gmane.org>


I took a look at test_sax and it seems sax.parser expects all (XML) input as
unicode rather than bytes. Apparently ElementTree does the same. Is there any
rationale for this decision?

cheers

Antoine.



From musiccomposition at gmail.com  Mon Aug 18 18:35:53 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Mon, 18 Aug 2008 11:35:53 -0500
Subject: [Python-3000] XML as bytes or unicode?
In-Reply-To: <loom.20080818T162617-305@post.gmane.org>
References: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>
	<bbaeab100808171209q7b29fff0pa585c02e0c95053a@mail.gmail.com>
	<loom.20080818T162617-305@post.gmane.org>
Message-ID: <1afaf6160808180935k3470efc0n65c318b87d54a99@mail.gmail.com>

On Mon, Aug 18, 2008 at 11:33 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> I took a look at test_sax and it seems sax.parser expects all (XML) input as
> unicode rather than bytes. Apparently ElementTree does the same. Is there any
> rationale for this decision?

Well, unless the parser decodes explicitly, I believe this should be true.
>
> cheers
>
> Antoine.
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From solipsis at pitrou.net  Mon Aug 18 18:54:08 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 18 Aug 2008 16:54:08 +0000 (UTC)
Subject: [Python-3000] XML as bytes or unicode?
References: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>
	<bbaeab100808171209q7b29fff0pa585c02e0c95053a@mail.gmail.com>
	<loom.20080818T162617-305@post.gmane.org>
	<1afaf6160808180935k3470efc0n65c318b87d54a99@mail.gmail.com>
Message-ID: <loom.20080818T164216-491@post.gmane.org>

Benjamin Peterson <musiccomposition <at> gmail.com> writes:
> 
> Well, unless the parser decodes explicitly, I believe this should be true.

XML documents have an encoding declaration... the parser's should be able to
handle it, no?

Actually, I've just checked and ElementTree does support bytes input, including
with non-ASCII chars. It's just that there are no tests for it.



From brett at python.org  Mon Aug 18 19:29:25 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 18 Aug 2008 10:29:25 -0700
Subject: [Python-3000] XML as bytes or unicode?
In-Reply-To: <loom.20080818T164216-491@post.gmane.org>
References: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>
	<bbaeab100808171209q7b29fff0pa585c02e0c95053a@mail.gmail.com>
	<loom.20080818T162617-305@post.gmane.org>
	<1afaf6160808180935k3470efc0n65c318b87d54a99@mail.gmail.com>
	<loom.20080818T164216-491@post.gmane.org>
Message-ID: <bbaeab100808181029w1eb1051fp9aecf0c6e239a818@mail.gmail.com>

On Mon, Aug 18, 2008 at 9:54 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Benjamin Peterson <musiccomposition <at> gmail.com> writes:
>>
>> Well, unless the parser decodes explicitly, I believe this should be true.
>
> XML documents have an encoding declaration... the parser's should be able to
> handle it, no?
>

Well, does the parser handle it or should the code that got the XML in
the first place handle it? Depends on who should take responsibility.
Apparently whomever wrote the parsers originally thought it was not
the parser's job. =)

If someone wanted to you could possibly dispatch on bytes to some code
that tried to determine the encoding and do the proper decode before
proceeding.

-Brett

From stefan_ml at behnel.de  Mon Aug 18 20:47:26 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 18 Aug 2008 20:47:26 +0200
Subject: [Python-3000] XML as bytes or unicode?
In-Reply-To: <loom.20080818T162617-305@post.gmane.org>
References: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>	<bbaeab100808171209q7b29fff0pa585c02e0c95053a@mail.gmail.com>
	<loom.20080818T162617-305@post.gmane.org>
Message-ID: <g8cg3u$l2p$1@ger.gmane.org>

Antoine Pitrou wrote:
> I took a look at test_sax and it seems sax.parser expects all (XML) input as
> unicode rather than bytes. Apparently ElementTree does the same. Is there any
> rationale for this decision?

There can't be. Serialised XML is about bytes, not characters.

Taking lxml as a reference, there is only one case in which it allows a
unicode string as parser input, and that is when it contains no encoding
declaration at all. The rational is that the XML specification allows external
transport protocols to provide this information instead, which in the case of
a unicode string is the platform specific encoding that Python uses.
Therefore, I would not mind having support for unicode strings in the stdlib's
XML support as long as you get an encoding error for this:

    parser.feed("<?xml version='1.0' encoding='utf-8'?><root/>") # Py3

I doubt that that's currently the case, though...

I also saw in the test that the XMLGenerator can serialise into a StringIO. At
least serialising to a byte encoding should fail when the target is a
StringIO, right?

Stefan


From tjreedy at udel.edu  Mon Aug 18 23:48:21 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 18 Aug 2008 17:48:21 -0400
Subject: [Python-3000] turtle.Screen- how to implement best a Singleton
In-Reply-To: <48A92FB1.7010201@aon.at>
References: <48A92FB1.7010201@aon.at>
Message-ID: <g8cqn3$qsn$1@ger.gmane.org>


> I, for my part, prefer the latter solution (b). Example: a student, 
> having (interactively) produced some design using some turtle t = 
> Turtle() decides spontaneously to change backgroundcolor. s = Screen(); 
> s.bgcolor("pink") should do this for her -

My perhaps naive view is that students should be given name S bound to 
the single Screen object and not have direct access to the Screen class 
object to ever call it.  S.bgcolor should be all that they need to do.


From barry at python.org  Tue Aug 19 04:57:33 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 18 Aug 2008 22:57:33 -0400
Subject: [Python-3000] [Python-Dev] parse_qs and parse_qsl functions
In-Reply-To: <bbaeab100808161252l3ed4b26fjee08b4bbc1f8f5ce@mail.gmail.com>
References: <e04bdf310808160704g36140bfbod0b68d38e91b9ed1@mail.gmail.com>
	<bbaeab100808161252l3ed4b26fjee08b4bbc1f8f5ce@mail.gmail.com>
Message-ID: <20080818225733.0457f242@resist.wooz.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 16, 2008, at 12:52 PM, Brett Cannon wrote:

>On Sat, Aug 16, 2008 at 7:04 AM, Facundo Batista
><facundobatista at gmail.com> wrote:
>> Hi!
>>
>> The issue 600362 has two patches (one for 2.6 and the other for 3.0)
>> that are ready to commit (with a small change in the docs). This
>> patches relocates the parse_qs and parse_qsl functions into the
>> urlparse module (urllib.parse in 3k), bringing them from the cgi one.
>>
>> For backward compatibility, those functions are also accessible from
>> the cgi module, but in the documentation says that the function was
>> moved, and you should use it from the urlparse one.
>>
>> So, we don't have *any* change in the behaviour towards the final user.
>>
>> Two questions:
>>
>> - It's ok to do this now or we should wait for 3.1/2.7?
>>
>> - Should we add a deprecation warning in the cgi module for this functions?
>>
>> I propose to commit this now, but leave a deprecation warning for the
>> next release.
>>
>
>Obviously Barry's call, but I think it's fine to do what you are proposing.

I think it's fine to commit this.  I would put a DeprecationWarning in 3.0 and
a PendingDeprecationWarning in 2.6 (updated to a DW in 2.7).

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIqja42YZpQepbvXERAp7oAJ9t6h/MtzAQQDDS3J65p7Zwpf+JzgCeO24r
kCmcTtPIeo/M0hiqmtee0/o=
=FVuq
-----END PGP SIGNATURE-----

From barry at python.org  Tue Aug 19 05:29:50 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 18 Aug 2008 23:29:50 -0400
Subject: [Python-3000] Beta 3 planned for this Wednesday
Message-ID: <20080818232950.5f234f31@resist.wooz.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello everyone,

I am going to try to release the last planned beta of 2.6 and 3.0 this
Wednesday.  Looking at the stable buildbots and showstopper bugs indicates
some work to do between now and then.  Here are the showstoppers, along with
my recommendations.

1878    class attribute cache failure (regression)
- - Medium priority
- - Guido, there are some design choices that need your decision.  I'd like to
  fix this for beta 3 if it's going to be fixed at all, because I suspect the
  changes will be too disruptive once we reach release candidates.

2394    [Py3k] Finish the memoryview object implementation
- - High priority
- - This one is serious enough to hold up the release.  I really do not think we
  should be finishing this implementation in the rc phase.

1179    [CVE-2007-4965] Integer overflow in imageop module
- - High priority
- - This will block final release and I think it needs to be fixed for this beta.

3131    2to3 can't find fixes_dir
- - Medium priority
- - I'm willing to defer this to the release candidates, but it will definitely
  block the release candidates.

3402    test_nis is hanging on Solaris
- - Medium priority
- - I suggest disabling this test and adding a note to the release notes.  If
  nobody comes forward to fix it for the final release, tough.

3352    Deficiencies in multiprocessing/threading API
- - Medium priority
- - This one is getting some love, so I'm confident this will get fixed before
  beta 3.

As for the buildbots, they're not looking so good.  It looks like the trunk
has various failures in multiprocessing (hopefully fixed soon) and bsddb3.
Also some crashes in test_anydbm.  Hmm.

3.0 is looking better but there's a weird error in test_sys and
test_threading.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIqj4v2YZpQepbvXERAolaAJ4uydGlv5wP2/SrZt4HzROkWfQUeACcDyoJ
7DZW8MgxYKQMedhj7wJywDo=
=oJk1
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Tue Aug 19 10:45:30 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 19 Aug 2008 08:45:30 +0000 (UTC)
Subject: [Python-3000] Beta 3 planned for this Wednesday
References: <20080818232950.5f234f31@resist.wooz.org>
Message-ID: <loom.20080819T084350-583@post.gmane.org>


Barry, could you please take a look at http://bugs.python.org/issue2834 ?
It's not marked as release blocker but if it doesn't integrate beta3 it will
probably not make it at all into 3.0 (unless you are fine with such a change
before an rc).

Thanks

Antoine.



From solipsis at pitrou.net  Tue Aug 19 14:44:19 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 19 Aug 2008 12:44:19 +0000 (UTC)
Subject: [Python-3000] Slight cleanup of the PyMemoryView API
Message-ID: <loom.20080819T124254-514@post.gmane.org>


Hi,

Would anybody object to the slight cleanup of the C PyMemoryView API that I
proposed in http://bugs.python.org/issue3560 ?
It's better to do this now before any third party extension starts relying on it.

Regards

Antoine.




From barry at python.org  Tue Aug 19 14:58:48 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 19 Aug 2008 08:58:48 -0400
Subject: [Python-3000] Beta 3 planned for this Wednesday
In-Reply-To: <loom.20080819T084350-583@post.gmane.org>
References: <20080818232950.5f234f31@resist.wooz.org>
	<loom.20080819T084350-583@post.gmane.org>
Message-ID: <A134FE7A-5A79-4383-9127-694A1D0E3CB3@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 19, 2008, at 4:45 AM, Antoine Pitrou wrote:

> Barry, could you please take a look at http://bugs.python.org/issue2834 
>  ?
> It's not marked as release blocker but if it doesn't integrate beta3  
> it will
> probably not make it at all into 3.0 (unless you are fine with such  
> a change
> before an rc).

Antoine,

I don't have time to review the specific patch, but based on the  
description, I'm +1 on adding this before beta 3.  See my additional  
comments in the tracker issue.

Thanks,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKrDiHEjvBPtnXfVAQL5CAP/RUo8RN9T9BZ73WQme0hqGY4Qlzztlugp
vxJrfOB5OaFhhMFpOjhpjl4yqgZmBVCfIQpNlWVWOBrwQtM8e+Fqy7Lvwvgep4s+
J4MZz9YC7N1VFFBJceGEpTxIDs9psn00UG2wrMmXvv9B0WUn74+S6LYa4/NiW/wS
TL3yP22aAX4=
=9vSo
-----END PGP SIGNATURE-----

From barry at python.org  Tue Aug 19 15:01:12 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 19 Aug 2008 09:01:12 -0400
Subject: [Python-3000] Hanging out on freenode IRC #python-dev
Message-ID: <3AD66C78-C365-48FB-94DB-4462E5AC9A0C@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I will be hanging out as much as possible over the next two days on  
the #python-dev channel on freenode IRC.  If you have any last minute  
decisions you need, that will be the most immediate way to get in  
touch with me.

Modulo work commitments, I'm generally available from about 7am to  
about 7pm US Eastern (UTC -0400) time.

Cheers,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKrEGHEjvBPtnXfVAQKCZAP+JyldH4bq1MO/0s5cJYDIM1hKNuXTm488
Ys/scWaPb7zBGi5/+Wdbwmle82EAsl3SDH6yDzjzhvgHOkOdsvaCP2bbVaXzDQ2r
gOWs9jNBug/1HuGlaD3UPLehZ0I8Hy192XZz0o9z6jXmh7+ffbbDdyUW8x3D4IKX
+pu/DsL8EkY=
=+MNA
-----END PGP SIGNATURE-----

From musiccomposition at gmail.com  Tue Aug 19 15:02:40 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 19 Aug 2008 08:02:40 -0500
Subject: [Python-3000] Beta 3 planned for this Wednesday
In-Reply-To: <20080818232950.5f234f31@resist.wooz.org>
References: <20080818232950.5f234f31@resist.wooz.org>
Message-ID: <1afaf6160808190602u8c00856oe08d76a198a6c382@mail.gmail.com>

On Mon, Aug 18, 2008 at 10:29 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello everyone,
>
> I am going to try to release the last planned beta of 2.6 and 3.0 this
> Wednesday.  Looking at the stable buildbots and showstopper bugs indicates
> some work to do between now and then.  Here are the showstoppers, along with
> my recommendations.
>
> 1878    class attribute cache failure (regression)
> - - Medium priority
> - - Guido, there are some design choices that need your decision.  I'd like to
>  fix this for beta 3 if it's going to be fixed at all, because I suspect the
>  changes will be too disruptive once we reach release candidates.
>
> 2394    [Py3k] Finish the memoryview object implementation
> - - High priority
> - - This one is serious enough to hold up the release.  I really do not think we
>  should be finishing this implementation in the rc phase.

How finished is finished? I see Antoine has implemented a little more of it.

>
> 1179    [CVE-2007-4965] Integer overflow in imageop module
> - - High priority
> - - This will block final release and I think it needs to be fixed for this beta.

I've never used imageop, but I'll see if I can review the patch.

>
> 3131    2to3 can't find fixes_dir
> - - Medium priority
> - - I'm willing to defer this to the release candidates, but it will definitely
>  block the release candidates.

This is pretty simple. There are patches that can be applied, but I
think 2to3 requires a little refactoring. I suppose that can be done
after the beta, though.

>
> 3402    test_nis is hanging on Solaris
> - - Medium priority
> - - I suggest disabling this test and adding a note to the release notes.  If
>  nobody comes forward to fix it for the final release, tough.
>
> 3352    Deficiencies in multiprocessing/threading API
> - - Medium priority
> - - This one is getting some love, so I'm confident this will get fixed before
>  beta 3.

Jesse said he could have it done today.
>
> As for the buildbots, they're not looking so good.  It looks like the trunk
> has various failures in multiprocessing (hopefully fixed soon) and bsddb3.
> Also some crashes in test_anydbm.  Hmm.
>
> 3.0 is looking better but there's a weird error in test_sys and
> test_threading.
>
> - -Barry
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIqj4v2YZpQepbvXERAolaAJ4uydGlv5wP2/SrZt4HzROkWfQUeACcDyoJ
> 7DZW8MgxYKQMedhj7wJywDo=
> =oJk1
> -----END PGP SIGNATURE-----
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From barry at python.org  Tue Aug 19 16:16:52 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 19 Aug 2008 10:16:52 -0400
Subject: [Python-3000] Beta 3 planned for this Wednesday
In-Reply-To: <1afaf6160808190602u8c00856oe08d76a198a6c382@mail.gmail.com>
References: <20080818232950.5f234f31@resist.wooz.org>
	<1afaf6160808190602u8c00856oe08d76a198a6c382@mail.gmail.com>
Message-ID: <E07C53F9-AB37-40F3-8507-F737CFDAC817@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 19, 2008, at 9:02 AM, Benjamin Peterson wrote:

> On Mon, Aug 18, 2008 at 10:29 PM, Barry Warsaw <barry at python.org>  
> wrote:
>>
>> 1878    class attribute cache failure (regression)
>> - - Medium priority
>> - - Guido, there are some design choices that need your decision.   
>> I'd like to
>> fix this for beta 3 if it's going to be fixed at all, because I  
>> suspect the
>> changes will be too disruptive once we reach release candidates.
>>
>> 2394    [Py3k] Finish the memoryview object implementation
>> - - High priority
>> - - This one is serious enough to hold up the release.  I really do  
>> not think we
>> should be finishing this implementation in the rc phase.
>
> How finished is finished? I see Antoine has implemented a little  
> more of it.

The API needs to be completed.  If there are bugs, that's fine but we  
need to stabilize the API by the release candidate.  I just followed  
up on the issues and it looks like Antoine has a good handle on this.

>> 1179    [CVE-2007-4965] Integer overflow in imageop module
>> - - High priority
>> - - This will block final release and I think it needs to be fixed  
>> for this beta.
>
> I've never used imageop, but I'll see if I can review the patch.

Great, thanks!

>> 3131    2to3 can't find fixes_dir
>> - - Medium priority
>> - - I'm willing to defer this to the release candidates, but it  
>> will definitely
>> block the release candidates.
>
> This is pretty simple. There are patches that can be applied, but I
> think 2to3 requires a little refactoring. I suppose that can be done
> after the beta, though.

Yep, but it should be done before rc1.

>> 3402    test_nis is hanging on Solaris
>> - - Medium priority
>> - - I suggest disabling this test and adding a note to the release  
>> notes.  If
>> nobody comes forward to fix it for the final release, tough.
>>
>> 3352    Deficiencies in multiprocessing/threading API
>> - - Medium priority
>> - - This one is getting some love, so I'm confident this will get  
>> fixed before
>> beta 3.
>
> Jesse said he could have it done today.

Excellent.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKrV1nEjvBPtnXfVAQLtXgP9HiHfxtbCPojQ1r6oMeou+7iWcedoBROL
BhtEEDxp74X8Bnnu8IfONMvQRL3I9wrktm6AztCKN8o9ZEAY5IlcFD4ICKM8f6My
kU5P6/ffJL7DgMyZSHh2w8p9lafNeH8tH1twy1hRWmh+jq8hkp1pgipYBCVqzSzp
iO3fKdhIGXk=
=IpIE
-----END PGP SIGNATURE-----

From guido at python.org  Tue Aug 19 22:19:37 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 19 Aug 2008 13:19:37 -0700
Subject: [Python-3000] Beta 3 planned for this Wednesday
In-Reply-To: <20080818232950.5f234f31@resist.wooz.org>
References: <20080818232950.5f234f31@resist.wooz.org>
Message-ID: <ca471dc20808191319g2959d506vbb29cb4761bd974d@mail.gmail.com>

On Mon, Aug 18, 2008 at 8:29 PM, Barry Warsaw <barry at python.org> wrote:
> 1878    class attribute cache failure (regression)
> - - Medium priority
> - - Guido, there are some design choices that need your decision.  I'd like to
>  fix this for beta 3 if it's going to be fixed at all, because I suspect the
>  changes will be too disruptive once we reach release candidates.

Resolved, see r65874.

> 2394    [Py3k] Finish the memoryview object implementation
> - - High priority
> - - This one is serious enough to hold up the release.  I really do not think we
>  should be finishing this implementation in the rc phase.

Can someone review Antoine's patch at http://codereview.appspot.com/3004 ?
It's above my head.

> 1179    [CVE-2007-4965] Integer overflow in imageop module
> - - High priority
> - - This will block final release and I think it needs to be fixed for this beta.

I'll look into this. Didn't we have a patch?

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

From guido at python.org  Tue Aug 19 23:03:11 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 19 Aug 2008 14:03:11 -0700
Subject: [Python-3000] Beta 3 planned for this Wednesday
In-Reply-To: <ca471dc20808191319g2959d506vbb29cb4761bd974d@mail.gmail.com>
References: <20080818232950.5f234f31@resist.wooz.org>
	<ca471dc20808191319g2959d506vbb29cb4761bd974d@mail.gmail.com>
Message-ID: <ca471dc20808191403m128d76b4t14f4c2d29cfcf9dd@mail.gmail.com>

On Tue, Aug 19, 2008 at 1:19 PM, Guido van Rossum <guido at python.org> wrote:
>> 1179    [CVE-2007-4965] Integer overflow in imageop module
>> - - High priority
>> - - This will block final release and I think it needs to be fixed for this beta.

Submitted the patch to 2.5 and 2.6.

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

From jnoller at gmail.com  Tue Aug 19 23:06:49 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Tue, 19 Aug 2008 17:06:49 -0400
Subject: [Python-3000] Beta 3 planned for this Wednesday
In-Reply-To: <20080818232950.5f234f31@resist.wooz.org>
References: <20080818232950.5f234f31@resist.wooz.org>
Message-ID: <4222a8490808191406r3f002916o7e9f02ea200988c@mail.gmail.com>

> 3352    Deficiencies in multiprocessing/threading API
> - - Medium priority
> - - This one is getting some love, so I'm confident this will get fixed before
>  beta 3.
>

This is complete on 2.6 as of r65864

From solipsis at pitrou.net  Wed Aug 20 00:23:50 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 19 Aug 2008 22:23:50 +0000 (UTC)
Subject: [Python-3000] Beta 3 planned for this Wednesday
References: <20080818232950.5f234f31@resist.wooz.org>
	<ca471dc20808191319g2959d506vbb29cb4761bd974d@mail.gmail.com>
Message-ID: <loom.20080819T221808-130@post.gmane.org>


Hi,

Guido van Rossum <guido <at> python.org> writes:
> > 2394    [Py3k] Finish the memoryview object implementation
> > - - High priority
> > - - This one is serious enough to hold up the release.  I really do not
think we
> >  should be finishing this implementation in the rc phase.
> 
> Can someone review Antoine's patch at http://codereview.appspot.com/3004 ?
> It's above my head.

Benjamin reviewed it and after a few fixes, it went in in r65886.
The implementation is finished for contiguous one-dimensional byte buffers. For
other types of buffers some things will be either not implemented, or perhaps
defective (since there isn't anything to test with).

Regards

Antoine.



From janssen at parc.com  Wed Aug 20 02:57:30 2008
From: janssen at parc.com (Bill Janssen)
Date: Tue, 19 Aug 2008 17:57:30 PDT
Subject: [Python-3000] move parse_header from cgi to email.header?
Message-ID: <08Aug19.175734pdt."58698"@synergy1.parc.xerox.com>

There's a function in the cgi module called "parse_header", which
takes a MIME-style email header and returns the "main" value along
with a dictionary of the parameters in the header.  I had to look for
a while before I found it; first I thought it should be in httplib,
then when it wasn't there I figured it would be in the email package,
along with the rest of the MIME support.  I was surprised to finally
find it in cgi.  Perhaps it should be moved to email.header,
email.parser, or email.util?  (With, of course, appropriate imports
and eventually deprecations in the cgi module, which already imports
email.parser.)

And what about parse_multipart?

http://bugs.python.org/issue3609

Bill

From hyeshik at gmail.com  Wed Aug 20 08:15:27 2008
From: hyeshik at gmail.com (Hye-Shik Chang)
Date: Wed, 20 Aug 2008 15:15:27 +0900
Subject: [Python-3000] Workaround for py3k build problem on CJK MacOS X?
In-Reply-To: <48A842C3.8090803@egenix.com>
References: <4f0b69dc0808150641n69f53e1br228f1faaef9ad62c@mail.gmail.com>
	<48A5D82A.7050501@v.loewis.de>
	<4f0b69dc0808160548w4cdbfbe3tb81942927418d71a@mail.gmail.com>
	<48A6F2AC.4000401@v.loewis.de> <48A842C3.8090803@egenix.com>
Message-ID: <4f0b69dc0808192315i5cf20b2bg63d2052beed9cde7@mail.gmail.com>

On Mon, Aug 18, 2008 at 12:24 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> I'm -1 on taking this approach this late in the release process.
>
> You are adding a completely new codec, which hasn't received enough
> testing. Furthermore, the concept of relying on OS defined codecs is
> not in line with our concept of shipping codecs that work on all
> platforms, not just the OS where they happen to be available via
> some system libraries (and then completely outside of our control).
>
> For 3.0, please just add aliases to the existing codecs and a
> note that this is just a work-around to be able to build Python
> on Mac OS X.

I see.  I've uploaded a patch for option 1 in issue #1276.

> For 3.1, we'll then have to add proper codecs for the missing
> encodings, hopefully reusing the existing CJK mapping tables.

I already have a patch that is implemented just as you describe. :)


Hye-Shik

From abpillai at gmail.com  Wed Aug 20 09:20:00 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Wed, 20 Aug 2008 12:50:00 +0530
Subject: [Python-3000] Fwd: Beta 3 planned for this Wednesday (OT: Beta 3
	planned for this Wednesday)
Message-ID: <8548c5f30808200020i3a48c512hb9bf5fbbc149dfbf@mail.gmail.com>

Hi,

    I think the patches for issue 3492 should also be merged in for this beta.
It affects the behaviour of zlib module. I have submitted patches for
zlibmodule.c
and test_zlib.py a few weeks back and they are ready to be merged anytime.

I am forwarding a message where I discussed this with Antoine, who is
CCed on the bug.

Thanks

--Anand

---------- Forwarded message ----------
From: Antoine Pitrou <solipsis at pitrou.net>
Date: Wed, Aug 20, 2008 at 12:26 PM
Subject: Re: [Python-3000] Beta 3 planned for this Wednesday
To: Anand Balachandran Pillai <abpillai at gmail.com>



Hello Anand,

>       If that is the case is http://bugs.python.org/issue3492 important ? It is
> not marked as critical or blocker or anything, but I find it strange
> that zlib in
> Python 3.0 will return bytearrays, if we don't merge the patches.

Agreed, however I can't do it myself today. You should post your message
to the list or on the bug tracker if you want someone to apply the patch
before the beta.

Regards

Antoine.





-- 
-Anand

From mal at egenix.com  Wed Aug 20 09:56:48 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 20 Aug 2008 09:56:48 +0200
Subject: [Python-3000] Workaround for py3k build problem on CJK MacOS X?
In-Reply-To: <4f0b69dc0808192315i5cf20b2bg63d2052beed9cde7@mail.gmail.com>
References: <4f0b69dc0808150641n69f53e1br228f1faaef9ad62c@mail.gmail.com>	<48A5D82A.7050501@v.loewis.de>	<4f0b69dc0808160548w4cdbfbe3tb81942927418d71a@mail.gmail.com>	<48A6F2AC.4000401@v.loewis.de>
	<48A842C3.8090803@egenix.com>
	<4f0b69dc0808192315i5cf20b2bg63d2052beed9cde7@mail.gmail.com>
Message-ID: <48ABCE40.6020502@egenix.com>

On 2008-08-20 08:15, Hye-Shik Chang wrote:
> On Mon, Aug 18, 2008 at 12:24 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> I'm -1 on taking this approach this late in the release process.
>>
>> You are adding a completely new codec, which hasn't received enough
>> testing. Furthermore, the concept of relying on OS defined codecs is
>> not in line with our concept of shipping codecs that work on all
>> platforms, not just the OS where they happen to be available via
>> some system libraries (and then completely outside of our control).
>>
>> For 3.0, please just add aliases to the existing codecs and a
>> note that this is just a work-around to be able to build Python
>> on Mac OS X.
> 
> I see.  I've uploaded a patch for option 1 in issue #1276.

Great ! Thanks.

>> For 3.1, we'll then have to add proper codecs for the missing
>> encodings, hopefully reusing the existing CJK mapping tables.
> 
> I already have a patch that is implemented just as you describe. :)

Perfect :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 20 2008)
 >>> 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,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From ncoghlan at gmail.com  Wed Aug 20 11:13:28 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 20 Aug 2008 19:13:28 +1000
Subject: [Python-3000] Beta 3 planned for this Wednesday
In-Reply-To: <loom.20080819T221808-130@post.gmane.org>
References: <20080818232950.5f234f31@resist.wooz.org>	<ca471dc20808191319g2959d506vbb29cb4761bd974d@mail.gmail.com>
	<loom.20080819T221808-130@post.gmane.org>
Message-ID: <48ABE038.7020206@gmail.com>

Antoine Pitrou wrote:
> Hi,
> 
> Guido van Rossum <guido <at> python.org> writes:
>>> 2394    [Py3k] Finish the memoryview object implementation
>>> - - High priority
>>> - - This one is serious enough to hold up the release.  I really do not
> think we
>>>  should be finishing this implementation in the rc phase.
>> Can someone review Antoine's patch at http://codereview.appspot.com/3004 ?
>> It's above my head.
> 
> Benjamin reviewed it and after a few fixes, it went in in r65886.
> The implementation is finished for contiguous one-dimensional byte buffers. For
> other types of buffers some things will be either not implemented, or perhaps
> defective (since there isn't anything to test with).

We'll probably need some help from the NumPy folks for that - once beta
3 is out, hopefully they can take it for a spin and let us know if they
find any unexpected problems when attempting to use memoryview with
multi-dimensional arrays.

At some stage, we should probably put a simple type in the C API testing
module that we can use to test some of the extra indexing and buffer
interface features that aren't exercised within the standard library.

Cheers,
Nick.

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

From solipsis at pitrou.net  Wed Aug 20 11:21:37 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 20 Aug 2008 11:21:37 +0200 (CEST)
Subject: [Python-3000] Beta 3 planned for this Wednesday
In-Reply-To: <48ABE038.7020206@gmail.com>
References: <20080818232950.5f234f31@resist.wooz.org>
	<ca471dc20808191319g2959d506vbb29cb4761bd974d@mail.gmail.com>
	<loom.20080819T221808-130@post.gmane.org>
	<48ABE038.7020206@gmail.com>
Message-ID: <2bf7eb58fadc5fa91a14b936b8ed838b.squirrel@webmail.nerim.net>


Hello Nick,

> At some stage, we should probably put a simple type in the C API testing
> module that we can use to test some of the extra indexing and buffer
> interface features that aren't exercised within the standard library.

Yes, I think that's what we should do. The only problem is that our
testing types must themselves conform to the intended behaviour - do you
think you have sufficient understanding of the spec to be able to do that?

Regards

Antoine.



From edreamleo at gmail.com  Wed Aug 20 18:19:54 2008
From: edreamleo at gmail.com (Edward K. Ream)
Date: Wed, 20 Aug 2008 11:19:54 -0500
Subject: [Python-3000] 2to3 docs? Py2.6 -3 warnings
Message-ID: <ffb592890808200919s772d57abpdc70715657b68ee8@mail.gmail.com>

Am I missing something in front of my nose? Where are the docs for
2to3?  I've tried, and failed, several times to run this script.

Also, python2.6 -3 did not seem to warn about xrange.

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo at gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

From brett at python.org  Wed Aug 20 19:16:23 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Aug 2008 10:16:23 -0700
Subject: [Python-3000] 2to3 docs? Py2.6 -3 warnings
In-Reply-To: <ffb592890808200919s772d57abpdc70715657b68ee8@mail.gmail.com>
References: <ffb592890808200919s772d57abpdc70715657b68ee8@mail.gmail.com>
Message-ID: <bbaeab100808201016v24104f44kecc694ffcd213c7c@mail.gmail.com>

On Wed, Aug 20, 2008 at 9:19 AM, Edward K. Ream <edreamleo at gmail.com> wrote:
> Am I missing something in front of my nose? Where are the docs for
> 2to3?  I've tried, and failed, several times to run this script.
>
> Also, python2.6 -3 did not seem to warn about xrange.
>

Warnings with the -3 flag only occur for things that 2to3 cannot fix.
Changing xrange() to range() in Py3K is easily done by 2to3, so no
explicit warning is raised.

-Brett

From levi at gis.net  Wed Aug 20 21:45:24 2008
From: levi at gis.net (Levi)
Date: Wed, 20 Aug 2008 15:45:24 -0400
Subject: [Python-3000] PEPs 3106 and 3119
Message-ID: <48AC7454.1020909@gis.net>

Recently I've taken some interest in PEP 3106 (revamping dick.keys, 
etc.) and wrote a rough draft of an experimental implementation in 
Python. Along the way I noticed a few things that I think need some 
discussion. A lot of them have to do with the interaction with PEP 3119 
(Abstract Base Classes).

While 3119 clearly incorporates most of the ideas in 3106, the reverese 
isn't the case (which I suppose makes sense, as 3106 is older.) However, 
there are some inconsistancies I've noticed.

In particular, 3119 specifies that Mapping.values() should return a 
Sized, Iterable, Container, but Guido's code in 3106 suggests that 
equality (and possibly other operations) should be defined as well. In 
this particular case, I thing there really ought to be a more clearly 
defined collection interface for the result of Mapping.values, 
especially if operations beyond those of Sized, Iterable, and Container 
are to be supported.

Another thing I noticed is that 3106 assumes that set, frozenset, and 
the various dictionary view objecs are the only sets like objects 
dictionary views will need to interact with, while 3119 implies that 
they really ought to play nice with any Set. To that end I implimented a 
base Set class that defines the set operations in terms of only __len__, 
__iter__, and __contains__. The keys and items classes inherit this 
behavior, so they can interact with anything supporting the Set interface.

However, there is one major wrinkle with this solution. The builtin set 
and frozenset types don't play nice with others. In particular, __eq__ 
and other such operations don't return NotImplemented when they ought 
to. Therefore, even though my view objects have suitably generic methods 
that could be used instead, they won't get called (in some cases) 
because set returns improper results. This leads  to some strange 
behavior, such as this:

 >>> d = dict(one=1, two=2, three=3)
 >>> s = set(('one', 'two', 'three'))
 >>> d.keys() == s
True
 >>> s == d.keys()
False

Now, I understand that set doesn't return NotImplemented to avoid having 
it's __cmp__ method called, but what I don't get is why it has a __cmp__ 
method at all. I thought the entire point of set and co. using the rich 
comparison operators is that Sets only define a partial ordering and so 
shouldn't define __cmp__, which implies a total ordering. So why define 
a __cmp__ method that only raises an error at the expense of breaking 
the rich comparison operators?

While a dict's keys view is guaranteed to only have hashable elements 
and can return a set (or frozenset) from it's set operations (union et 
al), the items view cannot. The solution (or at least the semantics 
thereof) supplied by Guido in PEP 3106 is to construct a new dict and 
return it's item view. What I did instead was to create a (poor, list 
based) Set type object to return instead. I think that the final 
implementaion should do something like this, however, the returned type 
should be implemented as effeciently as is reasonable and be a new 
standard builtin type. What said type should be called and how to 
implement it in a performant manner, I'm not so sure about. Any suggestions?

Additionally, while dict's keys are Hashable, another Mapping type's 
keys may not be, so such a Set type would also be useful in that case.

While implementing my (psudo) PEP 3119 Set base class, I noticed 
something strange. The specification states that issuperset and issubset 
aren't included, because they're basically just synonyms for __ge__ and 
__le__. However, no mention of union and the other named operations is 
made, which are basically in the same boat, is made. The asymetry seems 
a little odd to me.

The actually semantic differnce between the implicit methods and the 
explicit ones is that the explicit ones will coerce any (suitable) 
Iterable into the required Set type, while the implicit ones will not. 
Whether such operations should be required is up for debate, but I find 
it odd that some of the named operations (is...set)  are removed while 
the others (union etc.) are not. What is the reasoning for this?

Finally, you can check out my implementation at 
"http://gis.net/~levi/code/py3k/". It's not the most presentable code at 
the moment, and no doubt has all sorts of missing fuctionality, poor 
performance, and insufficent test coverage, but it's something at least. 
It provides an implimentation of most of PEP 3106 and a tiny subset of 
3119 and a small (unittest based) test suit. Unfortunatly it's 
undocumented, but it should be pretty easy to follow. I'll be working on 
improving it sometime soon. In the meantime any suggestions, critques, 
or comments will be greatly appreciated.

Thanks in Advance,
       Levi Aho


From barry at python.org  Thu Aug 21 00:45:06 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 20 Aug 2008 18:45:06 -0400
Subject: [Python-3000] Releasing beta 3's tonight
Message-ID: <4FEA536F-45BC-4EA2-8806-71B721A45350@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pending a resolution of bug 3611 (which has an attached patch that  
we're testing now), I plan on releasing 2.6 and 3.0 beta 3 tonight.

Please do not make any commits to the trees unless you ask me first,  
until further notice.  I am on #python-dev if you need an immediate  
decision.

Thanks.
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKyecnEjvBPtnXfVAQJ4DgQAg7hNzp76nUT8/dA4C2xTqwL+mmtXeu2s
MLbez1xVk3IoU3J/GRRcposaUQKoPToophndj1yk57v/g/AtrXIAjFRXkqH7giU5
eD7WltOt3Ch/f6ZBkT9eHttq9uaQB35kKcCPNUSL81C24xn8z7JS08KG+6bgx1hE
g0tYCMAj7Wk=
=tomA
-----END PGP SIGNATURE-----

From greg.ewing at canterbury.ac.nz  Thu Aug 21 02:48:59 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 21 Aug 2008 12:48:59 +1200
Subject: [Python-3000] PEPs 3106 and 3119
In-Reply-To: <48AC7454.1020909@gis.net>
References: <48AC7454.1020909@gis.net>
Message-ID: <48ACBB7B.30806@canterbury.ac.nz>

Levi wrote:
> Recently I've taken some interest in PEP 3106 (revamping dick.keys,
                                                            ^^^^^^^^^

Is this a feature related to some kind of chastity belt for men? :-)

-- 
Greg

From lists at cheimes.de  Thu Aug 21 03:05:54 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 21 Aug 2008 03:05:54 +0200
Subject: [Python-3000] PEPs 3106 and 3119
In-Reply-To: <48ACBB7B.30806@canterbury.ac.nz>
References: <48AC7454.1020909@gis.net> <48ACBB7B.30806@canterbury.ac.nz>
Message-ID: <g8if1h$kia$1@ger.gmane.org>

Greg Ewing wrote:
> Levi wrote:
>> Recently I've taken some interest in PEP 3106 (revamping dick.keys,
>                                                            ^^^^^^^^^
> 
> Is this a feature related to some kind of chastity belt for men? :-)

Maybe it's a brand new, special feature when a dict contains 37 keys in 
a row. *scnr*

Christian


From levi at gis.net  Thu Aug 21 04:23:42 2008
From: levi at gis.net (Levi)
Date: Wed, 20 Aug 2008 22:23:42 -0400
Subject: [Python-3000] PEPs 3106 and 3119
In-Reply-To: <48ACBB7B.30806@canterbury.ac.nz>
References: <48AC7454.1020909@gis.net> <48ACBB7B.30806@canterbury.ac.nz>
Message-ID: <48ACD1AE.3060307@gis.net>

Greg Ewing wrote:

> Levi wrote:
>
>> Recently I've taken some interest in PEP 3106 (revamping dick.keys,
>
> ^^^^^^^^^
>
> Is this a feature related to some kind of chastity belt for men? :-)
>
I didn't notice that until I recived the message from the list. Truely 
an embarrasssing typo to say the least.

From barry at python.org  Thu Aug 21 05:17:15 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 20 Aug 2008 23:17:15 -0400
Subject: [Python-3000] RELEASED Python 2.6b3 and 3.0b3
Message-ID: <20080820231715.57fde07f@resist.wooz.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On behalf of the Python development team and the Python community, I am happy
to announce the third and last planned beta releases of Python 2.6 and Python
3.0.

Please note that these are beta releases, and as such are not suitable for
production environments.  We continue to strive for a high degree of quality,
and these releases are intended to freeze the feature set for Python 2.6 and
3.0.

As these are the last planned beta releases, we strongly urge you to download
these releases and test them against your code.  Once we reach release
candidates (currently planned for 03-Sep-2008), only highly critical bugs will
be fixed before the final release.

If you find things broken or incorrect, please submit bug reports at

     http://bugs.python.org

For more information and downloadable distributions, see the Python  
2.6 website:

     http://www.python.org/download/releases/2.6/

and the Python 3.0 web site:

     http://www.python.org/download/releases/3.0/

See PEP 361 for release schedule details:

     http://www.python.org/dev/peps/pep-0361/

Enjoy,
- -Barry

Barry Warsaw
barry at python.org
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIrN472YZpQepbvXERAl4fAJ9QxHhSn/jYdA3lCYvgfXRhBVV2pgCfdNUx
3NTlSrsSULxXhoMqiNmUMSg=
=Z4+y
-----END PGP SIGNATURE-----

From greg at krypto.org  Thu Aug 21 07:14:34 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Wed, 20 Aug 2008 22:14:34 -0700
Subject: [Python-3000] io deadlock, use of RLock, issues 3618 & 3001 thoughts
Message-ID: <52dc1c820808202214r55e0e3fbo948d0d452798b521@mail.gmail.com>

http://bugs.python.org/issue3618 is a release blocker due to deadlock
in the io library.

and the related C RLock implementation in
http://bugs.python.org/issue3001 at this point in the release process.
 Its obviously missed beta3 which is why I suggested in 3001 that it
was too late.  That was before I knew about 3618.  IMHO for py3k there
is a compelling reason to go ahead with it the C RLock implementation
for use with io.

thoughts?

-gps

PS I'd also love to see a fast RLock in 2.6 but realize the cutoff has
already passed..

From solipsis at pitrou.net  Thu Aug 21 12:09:44 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 21 Aug 2008 10:09:44 +0000 (UTC)
Subject: [Python-3000] io deadlock, use of RLock,
	issues 3618 & 3001 thoughts
References: <52dc1c820808202214r55e0e3fbo948d0d452798b521@mail.gmail.com>
Message-ID: <loom.20080821T100633-841@post.gmane.org>

Gregory P. Smith <greg <at> krypto.org> writes:
> 
> http://bugs.python.org/issue3618 is a release blocker due to deadlock
> in the io library.
> 
> and the related C RLock implementation in
[etc.]


By the way, please note using an RLock will just solve the deadlock bug. It
won't make the behaviour of write() and friends absolutely correct if called
recursively, rather than lose or duplicate chunks of bytes. Those functions are
not meant to be reentrant at all.

Which means, perhaps another way of solving the bug would be to ensure tracing
is disabled when entering those functions. Are there cases of reentrancy apart
from tracing? signals and other asynchronous stuff perhaps?

Regards

Antoine.



From ncoghlan at gmail.com  Thu Aug 21 12:19:46 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 21 Aug 2008 20:19:46 +1000
Subject: [Python-3000] PEPs 3106 and 3119
In-Reply-To: <48AC7454.1020909@gis.net>
References: <48AC7454.1020909@gis.net>
Message-ID: <48AD4142.1060805@gmail.com>

Levi wrote:
> Now, I understand that set doesn't return NotImplemented to avoid having
> it's __cmp__ method called, but what I don't get is why it has a __cmp__
> method at all. I thought the entire point of set and co. using the rich
> comparison operators is that Sets only define a partial ordering and so
> shouldn't define __cmp__, which implies a total ordering. So why define
> a __cmp__ method that only raises an error at the expense of breaking
> the rich comparison operators?

set() and frozenset() do this to prevent falling back to the default
ordering employed in Python 2.x:

>>> obj1 = type('T1', (), {})
>>> obj2 = type('T2', (), {})
>>> obj1 < obj2
True
>>> obj1 > obj2
False

It should be possible to make them play more nicely with others in 3.x
where that undesirable fallback behaviour is gone though.

Cheers,
Nick.

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

From musiccomposition at gmail.com  Thu Aug 21 15:30:22 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 21 Aug 2008 08:30:22 -0500
Subject: [Python-3000] issue 3187 and decoding filenames
Message-ID: <1afaf6160808210630s58e9798an6e3662b60cadf9d3@mail.gmail.com>

Issue 3187 is a case where os.listdir tries to decode filenames with
the default file system encoding, but failing that, simply returns the
unencoded bytestring. This was obviously ok in 2.x, but not so good in
py3k where bytes are cleanly separated from unicode.

Any comments on the issue are welcome.

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From victor.stinner at haypocalc.com  Thu Aug 21 17:01:38 2008
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 21 Aug 2008 17:01:38 +0200
Subject: [Python-3000] issue 3187 and decoding filenames
In-Reply-To: <1afaf6160808210630s58e9798an6e3662b60cadf9d3@mail.gmail.com>
References: <1afaf6160808210630s58e9798an6e3662b60cadf9d3@mail.gmail.com>
Message-ID: <200808211701.39047.victor.stinner@haypocalc.com>

Le Thursday 21 August 2008 15:30:22 Benjamin Peterson, vous avez ?crit?:
> Issue 3187 is a case where os.listdir tries to decode filenames with
> the default file system encoding, but failing that, simply returns the
> unencoded bytestring. This was obviously ok in 2.x, but not so good in
> py3k where bytes are cleanly separated from unicode.

I'm trying to write a workaround in Python, but I'm unable to write my own 
class which is compatible with "buffer interface"... What is this interface?

It works with bytes, but I don't want to inherit bytes (nor str).

  class MyBuffer(bytes):
     def __new__(self, data):
        obj = bytes.__new__(self, data)
        obj.myattribute = 42
        return obj


-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/

From guido at python.org  Thu Aug 21 18:18:26 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 21 Aug 2008 09:18:26 -0700
Subject: [Python-3000] PEPs 3106 and 3119
In-Reply-To: <48AD4142.1060805@gmail.com>
References: <48AC7454.1020909@gis.net> <48AD4142.1060805@gmail.com>
Message-ID: <ca471dc20808210918n155404dag4e0a5223ba4ace67@mail.gmail.com>

2008/8/21 Nick Coghlan <ncoghlan at gmail.com>:
> Levi wrote:
>> Now, I understand that set doesn't return NotImplemented to avoid having
>> it's __cmp__ method called, but what I don't get is why it has a __cmp__
>> method at all. I thought the entire point of set and co. using the rich
>> comparison operators is that Sets only define a partial ordering and so
>> shouldn't define __cmp__, which implies a total ordering. So why define
>> a __cmp__ method that only raises an error at the expense of breaking
>> the rich comparison operators?
>
> set() and frozenset() do this to prevent falling back to the default
> ordering employed in Python 2.x:
>
>>>> obj1 = type('T1', (), {})
>>>> obj2 = type('T2', (), {})
>>>> obj1 < obj2
> True
>>>> obj1 > obj2
> False
>
> It should be possible to make them play more nicely with others in 3.x
> where that undesirable fallback behaviour is gone though.

I thought in 3.0 they already behave cooperatively? set_richcompare()
returns NotImplemented (where in 2.x it raises TypeError.)

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

From brett at python.org  Thu Aug 21 20:41:20 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 11:41:20 -0700
Subject: [Python-3000] Still get rid of the stat module?
Message-ID: <bbaeab100808211141y28524133y2763b0607a2ad824@mail.gmail.com>

PEP 3108 has the stat module slated for removal, but some snags have
been hit and it makes me wonder if it is still worth it. The issue
tracking all of this is http://bugs.python.org/issue2874 .

First, it turns out a bunch of constants from the module are used all
over the place. Those constants would either have to be relocated or
the module stays and just the functions get deprecated.

But that raises a second issue: a namedtuple is used for what
os.stat() returns, making adding methods a pain. Georg did a
proof-of-concept, but obviously it is cheating a little to make it all
work.

So my question is whether it is still worth trying to remove the
module, or just leave it be.

-Brett

From dirkjan at ochtman.nl  Thu Aug 21 21:54:30 2008
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Thu, 21 Aug 2008 21:54:30 +0200
Subject: [Python-3000] Still get rid of the stat module?
In-Reply-To: <bbaeab100808211141y28524133y2763b0607a2ad824@mail.gmail.com>
References: <bbaeab100808211141y28524133y2763b0607a2ad824@mail.gmail.com>
Message-ID: <g8kh60$epc$1@ger.gmane.org>

Brett Cannon wrote:
> So my question is whether it is still worth trying to remove the
> module, or just leave it be.

Seeing this is the only chance in the coming 15 years to fix this, I'd 
say fix it... Having it around is pretty ugly, when the "real" stat() is 
actually in os.

Cheers,

Dirkjan


From guido at python.org  Thu Aug 21 22:22:56 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 21 Aug 2008 13:22:56 -0700
Subject: [Python-3000] Still get rid of the stat module?
In-Reply-To: <g8kh60$epc$1@ger.gmane.org>
References: <bbaeab100808211141y28524133y2763b0607a2ad824@mail.gmail.com>
	<g8kh60$epc$1@ger.gmane.org>
Message-ID: <ca471dc20808211322v696ec61el72beabcd1d3811c7@mail.gmail.com>

On Thu, Aug 21, 2008 at 12:54 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> Brett Cannon wrote:
>>
>> So my question is whether it is still worth trying to remove the
>> module, or just leave it be.
>
> Seeing this is the only chance in the coming 15 years to fix this, I'd say
> fix it... Having it around is pretty ugly, when the "real" stat() is
> actually in os.

Why? We could just deprecate it and rip it out in 3.1 or 3.2.

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

From ncoghlan at gmail.com  Fri Aug 22 00:35:44 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 22 Aug 2008 08:35:44 +1000
Subject: [Python-3000] PEPs 3106 and 3119
In-Reply-To: <ca471dc20808210918n155404dag4e0a5223ba4ace67@mail.gmail.com>
References: <48AC7454.1020909@gis.net> <48AD4142.1060805@gmail.com>
	<ca471dc20808210918n155404dag4e0a5223ba4ace67@mail.gmail.com>
Message-ID: <48ADEDC0.1000005@gmail.com>

Guido van Rossum wrote:
> 2008/8/21 Nick Coghlan <ncoghlan at gmail.com>:
>> Levi wrote:
>>> Now, I understand that set doesn't return NotImplemented to avoid having
>>> it's __cmp__ method called, but what I don't get is why it has a __cmp__
>>> method at all. I thought the entire point of set and co. using the rich
>>> comparison operators is that Sets only define a partial ordering and so
>>> shouldn't define __cmp__, which implies a total ordering. So why define
>>> a __cmp__ method that only raises an error at the expense of breaking
>>> the rich comparison operators?
>> set() and frozenset() do this to prevent falling back to the default
>> ordering employed in Python 2.x:
>>
>>>>> obj1 = type('T1', (), {})
>>>>> obj2 = type('T2', (), {})
>>>>> obj1 < obj2
>> True
>>>>> obj1 > obj2
>> False
>>
>> It should be possible to make them play more nicely with others in 3.x
>> where that undesirable fallback behaviour is gone though.
> 
> I thought in 3.0 they already behave cooperatively? set_richcompare()
> returns NotImplemented (where in 2.x it raises TypeError.)

Other than look to see if __cmp__ was still in dir(set) (which it is), I
didn't actually check if this had been corrected already... perhaps Levi
should retry his experiment with the latest 3.0 beta instead of 2.6?

Cheers,
Nick.

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

From dirkjan at ochtman.nl  Thu Aug 21 22:32:10 2008
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Thu, 21 Aug 2008 22:32:10 +0200
Subject: [Python-3000] Still get rid of the stat module?
In-Reply-To: <ca471dc20808211322v696ec61el72beabcd1d3811c7@mail.gmail.com>
References: <bbaeab100808211141y28524133y2763b0607a2ad824@mail.gmail.com>	
	<g8kh60$epc$1@ger.gmane.org>
	<ca471dc20808211322v696ec61el72beabcd1d3811c7@mail.gmail.com>
Message-ID: <48ADD0CA.6000907@ochtman.nl>

Guido van Rossum wrote:
> Why? We could just deprecate it and rip it out in 3.1 or 3.2.

In that case, not doing it for 3.0 seems just fine.

Cheers,

Dirkjan

From edreamleo at gmail.com  Sat Aug 23 15:29:09 2008
From: edreamleo at gmail.com (Edward K. Ream)
Date: Sat, 23 Aug 2008 08:29:09 -0500
Subject: [Python-3000] Several days later: no windows installers for b3
Message-ID: <ffb592890808230629n6b1ae6e3g5552d927501c086a@mail.gmail.com>

No b3 installers for windows at http://www.python.org/download/releases/3.0/

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo at gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

From brett at python.org  Sat Aug 23 22:09:48 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 23 Aug 2008 13:09:48 -0700
Subject: [Python-3000] Several days later: no windows installers for b3
In-Reply-To: <ffb592890808230629n6b1ae6e3g5552d927501c086a@mail.gmail.com>
References: <ffb592890808230629n6b1ae6e3g5552d927501c086a@mail.gmail.com>
Message-ID: <bbaeab100808231309j66ad371l3d99324e94a153e5@mail.gmail.com>

On Sat, Aug 23, 2008 at 6:29 AM, Edward K. Ream <edreamleo at gmail.com> wrote:
> No b3 installers for windows at http://www.python.org/download/releases/3.0/
>

We know. Martin, who usually does the Windows installer, is on vacation.

-Brett


> Edward
> --------------------------------------------------------------------
> Edward K. Ream email: edreamleo at gmail.com
> Leo: http://webpages.charter.net/edreamleo/front.html
> --------------------------------------------------------------------
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/brett%40python.org
>

From abdallah.elguindy at gmail.com  Sat Aug 23 23:03:37 2008
From: abdallah.elguindy at gmail.com (Abdallah El Guindy)
Date: Sun, 24 Aug 2008 00:03:37 +0300
Subject: [Python-3000] Minor addition to Python interactive shell...
Message-ID: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>

Hey all

I know that the feature I am about to suggest may be minor and may have a
very low priority considering other issues to be discussed, however I'll
suggest it anyways..

Being a very frequent user of the interactive shell, I find it annoying when
I try to use a function or a class that resides in another module that I
haven't imported... So why not let the interactive shell say a message about
the appropriate module to be imported for this class/function.. The idea is
similar to bash on Ubuntu, if you don't have the necessary package it lets
you know by suggesting the package name to be installed.

Let me know what you think.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080824/2579f1e1/attachment.htm>

From musiccomposition at gmail.com  Sat Aug 23 23:06:28 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 23 Aug 2008 16:06:28 -0500
Subject: [Python-3000] Minor addition to Python interactive shell...
In-Reply-To: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
References: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
Message-ID: <1afaf6160808231406q2dc07f41la4ef42327f4cbcc@mail.gmail.com>

On Sat, Aug 23, 2008 at 4:03 PM, Abdallah El Guindy
<abdallah.elguindy at gmail.com> wrote:
> Hey all
>
> I know that the feature I am about to suggest may be minor and may have a
> very low priority considering other issues to be discussed, however I'll
> suggest it anyways..
>
> Being a very frequent user of the interactive shell, I find it annoying when
> I try to use a function or a class that resides in another module that I
> haven't imported... So why not let the interactive shell say a message about
> the appropriate module to be imported for this class/function.. The idea is
> similar to bash on Ubuntu, if you don't have the necessary package it lets
> you know by suggesting the package name to be installed.

How would that be implemented? At the least, every module and package
on sys.path would have to be scanned.
>
> Let me know what you think.
>
> Thank you.
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From abdallah.elguindy at gmail.com  Sat Aug 23 23:10:02 2008
From: abdallah.elguindy at gmail.com (Abdallah El Guindy)
Date: Sun, 24 Aug 2008 00:10:02 +0300
Subject: [Python-3000] Minor addition to Python interactive shell...
In-Reply-To: <1afaf6160808231406q2dc07f41la4ef42327f4cbcc@mail.gmail.com>
References: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
	<1afaf6160808231406q2dc07f41la4ef42327f4cbcc@mail.gmail.com>
Message-ID: <112f66890808231410p78dcd54cm9a5280361d9dcc63@mail.gmail.com>

I believe there must be a way... Maybe by creating an index file for each
module. I'm not sure, but I think the number of packages on apt-get is much
more than the number of python built-in modules (obviously I don't know
their number), yet it is doable with the case of apt-get.

On Sun, Aug 24, 2008 at 12:06 AM, Benjamin Peterson <
musiccomposition at gmail.com> wrote:

> On Sat, Aug 23, 2008 at 4:03 PM, Abdallah El Guindy
> <abdallah.elguindy at gmail.com> wrote:
> > Hey all
> >
> > I know that the feature I am about to suggest may be minor and may have a
> > very low priority considering other issues to be discussed, however I'll
> > suggest it anyways..
> >
> > Being a very frequent user of the interactive shell, I find it annoying
> when
> > I try to use a function or a class that resides in another module that I
> > haven't imported... So why not let the interactive shell say a message
> about
> > the appropriate module to be imported for this class/function.. The idea
> is
> > similar to bash on Ubuntu, if you don't have the necessary package it
> lets
> > you know by suggesting the package name to be installed.
>
> How would that be implemented? At the least, every module and package
> on sys.path would have to be scanned.
> >
> > Let me know what you think.
> >
> > Thank you.
> >
> > _______________________________________________
> > Python-3000 mailing list
> > Python-3000 at python.org
> > http://mail.python.org/mailman/listinfo/python-3000
> > Unsubscribe:
> >
> http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
> >
> >
>
>
>
> --
> Cheers,
> Benjamin Peterson
> "There's no place like 127.0.0.1."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080824/1920ddb0/attachment.htm>

From brett at python.org  Sat Aug 23 23:26:40 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 23 Aug 2008 14:26:40 -0700
Subject: [Python-3000] Minor addition to Python interactive shell...
In-Reply-To: <112f66890808231410p78dcd54cm9a5280361d9dcc63@mail.gmail.com>
References: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
	<1afaf6160808231406q2dc07f41la4ef42327f4cbcc@mail.gmail.com>
	<112f66890808231410p78dcd54cm9a5280361d9dcc63@mail.gmail.com>
Message-ID: <bbaeab100808231426u9871e77w795d789d2622d0ee@mail.gmail.com>

On Sat, Aug 23, 2008 at 2:10 PM, Abdallah El Guindy
<abdallah.elguindy at gmail.com> wrote:
> I believe there must be a way... Maybe by creating an index file for each
> module. I'm not sure, but I think the number of packages on apt-get is much
> more than the number of python built-in modules (obviously I don't know
> their number), yet it is doable with the case of apt-get.
>

I think Ruby has a similar tool; someone once showed me how in Ruby
you can just start to type the function or class name and it lists all
possible matches, and then when you make a choice it shows the docs. I
am sure it was done based on an index. And doctools probably already
has this index information somewhere (isn't it used for pydoc?).

But I don't care enough to code up a solution. =)

-Brett

> On Sun, Aug 24, 2008 at 12:06 AM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
>>
>> On Sat, Aug 23, 2008 at 4:03 PM, Abdallah El Guindy
>> <abdallah.elguindy at gmail.com> wrote:
>> > Hey all
>> >
>> > I know that the feature I am about to suggest may be minor and may have
>> > a
>> > very low priority considering other issues to be discussed, however I'll
>> > suggest it anyways..
>> >
>> > Being a very frequent user of the interactive shell, I find it annoying
>> > when
>> > I try to use a function or a class that resides in another module that I
>> > haven't imported... So why not let the interactive shell say a message
>> > about
>> > the appropriate module to be imported for this class/function.. The idea
>> > is
>> > similar to bash on Ubuntu, if you don't have the necessary package it
>> > lets
>> > you know by suggesting the package name to be installed.
>>
>> How would that be implemented? At the least, every module and package
>> on sys.path would have to be scanned.
>> >
>> > Let me know what you think.
>> >
>> > Thank you.
>> >
>> > _______________________________________________
>> > Python-3000 mailing list
>> > Python-3000 at python.org
>> > http://mail.python.org/mailman/listinfo/python-3000
>> > Unsubscribe:
>> >
>> > http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>> >
>> >
>>
>>
>>
>> --
>> Cheers,
>> Benjamin Peterson
>> "There's no place like 127.0.0.1."
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/brett%40python.org
>
>

From aleaxit at gmail.com  Sat Aug 23 23:35:35 2008
From: aleaxit at gmail.com (Alex Martelli)
Date: Sat, 23 Aug 2008 14:35:35 -0700
Subject: [Python-3000] Minor addition to Python interactive shell...
In-Reply-To: <112f66890808231410p78dcd54cm9a5280361d9dcc63@mail.gmail.com>
References: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
	<1afaf6160808231406q2dc07f41la4ef42327f4cbcc@mail.gmail.com>
	<112f66890808231410p78dcd54cm9a5280361d9dcc63@mail.gmail.com>
Message-ID: <e8a0972d0808231435i4a07cbe0l69139f91f59052b0@mail.gmail.com>

On Sat, Aug 23, 2008 at 2:10 PM, Abdallah El Guindy
<abdallah.elguindy at gmail.com> wrote:
> I believe there must be a way... Maybe by creating an index file for each
> module. I'm not sure, but I think the number of packages on apt-get is much
> more than the number of python built-in modules (obviously I don't know
> their number), yet it is doable with the case of apt-get.

Adding a package to the repositories searched by apt-get is a much
higher-ceremony operation than copying a file into some sys.path
directory or changing sys.path, so that indexing makes sense for
apt-get but not for Python's imports -- I can imagine the poor Python
interpreter churning away all the time updating the index all the
time.  And even then, the Python index WOULD still potentially miss
some entries, because a Python module is vastly more dynamic than the
totally-static repositories used by apt-get, where each package is
mandated to very explicitly state what it requires, and what it
provides.

If you want to try your hand at this kind of extension, I recommend
you do it as a pypi package -- since all you want is peculiar messages
in response to some NameError or ImportError exceptions, you can hang
your functionality neatly into sys.excepthook -- there is absolutely
nothing to be gained by having the functionality inside the core
rather than in a third-party package.  Moreover, I would recommend
targeting the extension (solely or primarily) at "rich" environments
such as IDLE or ipython (http://ipython.scipy.org/moin/), whose users
already expect and obviously appreciate getting especially rich
interactive functionality even if it comes at the potential cost of
some overhead -- users of the Python built-in interactive interpreter
are more likely to be after lean-and-mean functionality instead.

If and when your extension "takes the Python world by storm", you will
have strong practical arguments to recommend its inclusion in some
future version of Python -- its popularity will have proven that there
is strong demand for that functionality, after all.  Until such
support does exist, it's hard to argue for including in the Python
core offering something that can be done just as well as a 3rd party
package, has no proven demand, AND presents potentially delicate
tradeoffs in terms of implementation (is the user going to be asked to
explicitly reindex each time they alter sys.path, or is the overhead
of the reindexing going to be implicit in ANY alteration at all?  etc,
etc).


Alex

From abdallah.elguindy at gmail.com  Sat Aug 23 23:45:57 2008
From: abdallah.elguindy at gmail.com (Abdallah El Guindy)
Date: Sun, 24 Aug 2008 00:45:57 +0300
Subject: [Python-3000] Minor addition to Python interactive shell...
In-Reply-To: <e8a0972d0808231435i4a07cbe0l69139f91f59052b0@mail.gmail.com>
References: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
	<1afaf6160808231406q2dc07f41la4ef42327f4cbcc@mail.gmail.com>
	<112f66890808231410p78dcd54cm9a5280361d9dcc63@mail.gmail.com>
	<e8a0972d0808231435i4a07cbe0l69139f91f59052b0@mail.gmail.com>
Message-ID: <112f66890808231445q5f594cdeqe9f535df135601df@mail.gmail.com>

Adding a package to the repositories searched by apt-get is a much
> higher-ceremony operation than copying a file into some sys.path
> directory or changing sys.path, so that indexing makes sense for
> apt-get but not for Python's imports -- I can imagine the poor Python
> interpreter churning away all the time updating the index all the
> time.
>
You are definitely right about that, I totally missed this when first
thinking about it...

there is absolutely
> nothing to be gained by having the functionality inside the core
> rather than in a third-party package.
>
I guess you are right once again.

If and when your extension "takes the Python world by storm"


I guess this is never gonna happen (that's why I probably tagged the feature
minor).

I did not realized at the beginning that it has as much technical
complications.. Thanks for pointing that out, I'm convinced that perhaps it
is not a good idea after all.

Thanks.

On Sun, Aug 24, 2008 at 12:35 AM, Alex Martelli <aleaxit at gmail.com> wrote:

> On Sat, Aug 23, 2008 at 2:10 PM, Abdallah El Guindy
> <abdallah.elguindy at gmail.com> wrote:
> > I believe there must be a way... Maybe by creating an index file for each
> > module. I'm not sure, but I think the number of packages on apt-get is
> much
> > more than the number of python built-in modules (obviously I don't know
> > their number), yet it is doable with the case of apt-get.
>
> Adding a package to the repositories searched by apt-get is a much
> higher-ceremony operation than copying a file into some sys.path
> directory or changing sys.path, so that indexing makes sense for
> apt-get but not for Python's imports -- I can imagine the poor Python
> interpreter churning away all the time updating the index all the
> time.  And even then, the Python index WOULD still potentially miss
> some entries, because a Python module is vastly more dynamic than the
> totally-static repositories used by apt-get, where each package is
> mandated to very explicitly state what it requires, and what it
> provides.
>
> If you want to try your hand at this kind of extension, I recommend
> you do it as a pypi package -- since all you want is peculiar messages
> in response to some NameError or ImportError exceptions, you can hang
> your functionality neatly into sys.excepthook -- there is absolutely
> nothing to be gained by having the functionality inside the core
> rather than in a third-party package.  Moreover, I would recommend
> targeting the extension (solely or primarily) at "rich" environments
> such as IDLE or ipython (http://ipython.scipy.org/moin/), whose users
> already expect and obviously appreciate getting especially rich
> interactive functionality even if it comes at the potential cost of
> some overhead -- users of the Python built-in interactive interpreter
> are more likely to be after lean-and-mean functionality instead.
>
> If and when your extension "takes the Python world by storm", you will
> have strong practical arguments to recommend its inclusion in some
> future version of Python -- its popularity will have proven that there
> is strong demand for that functionality, after all.  Until such
> support does exist, it's hard to argue for including in the Python
> core offering something that can be done just as well as a 3rd party
> package, has no proven demand, AND presents potentially delicate
> tradeoffs in terms of implementation (is the user going to be asked to
> explicitly reindex each time they alter sys.path, or is the overhead
> of the reindexing going to be implicit in ANY alteration at all?  etc,
> etc).
>
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080824/0075ecf7/attachment.htm>

From aleaxit at gmail.com  Sat Aug 23 23:55:18 2008
From: aleaxit at gmail.com (Alex Martelli)
Date: Sat, 23 Aug 2008 14:55:18 -0700
Subject: [Python-3000] Minor addition to Python interactive shell...
In-Reply-To: <112f66890808231445q5f594cdeqe9f535df135601df@mail.gmail.com>
References: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
	<1afaf6160808231406q2dc07f41la4ef42327f4cbcc@mail.gmail.com>
	<112f66890808231410p78dcd54cm9a5280361d9dcc63@mail.gmail.com>
	<e8a0972d0808231435i4a07cbe0l69139f91f59052b0@mail.gmail.com>
	<112f66890808231445q5f594cdeqe9f535df135601df@mail.gmail.com>
Message-ID: <e8a0972d0808231455n6fd45f82nb3b1f6363e696eb3@mail.gmail.com>

You're welcome!  I wasn't trying to discourage you -- I was trying to
prompt you to do it the best way, as a third party open source project
(perhaps a contributed one to iPython, etc).  Brett suggests that the
index might be already around somewhere (maybe just for the standard
library, but that would be a start) so if you could locate it then the
needed excepthook might not be too hard to write, etc, etc.  However,
it's definitely up to you!

Alex

On Sat, Aug 23, 2008 at 2:45 PM, Abdallah El Guindy
<abdallah.elguindy at gmail.com> wrote:
>> Adding a package to the repositories searched by apt-get is a much
>> higher-ceremony operation than copying a file into some sys.path
>> directory or changing sys.path, so that indexing makes sense for
>> apt-get but not for Python's imports -- I can imagine the poor Python
>> interpreter churning away all the time updating the index all the
>> time.
>
> You are definitely right about that, I totally missed this when first
> thinking about it...
>
>> there is absolutely
>> nothing to be gained by having the functionality inside the core
>> rather than in a third-party package.
>
> I guess you are right once again.
>
>> If and when your extension "takes the Python world by storm"
>
> I guess this is never gonna happen (that's why I probably tagged the feature
> minor).
>
> I did not realized at the beginning that it has as much technical
> complications.. Thanks for pointing that out, I'm convinced that perhaps it
> is not a good idea after all.
>
> Thanks.
>
> On Sun, Aug 24, 2008 at 12:35 AM, Alex Martelli <aleaxit at gmail.com> wrote:
>>
>> On Sat, Aug 23, 2008 at 2:10 PM, Abdallah El Guindy
>> <abdallah.elguindy at gmail.com> wrote:
>> > I believe there must be a way... Maybe by creating an index file for
>> > each
>> > module. I'm not sure, but I think the number of packages on apt-get is
>> > much
>> > more than the number of python built-in modules (obviously I don't know
>> > their number), yet it is doable with the case of apt-get.
>>
>> Adding a package to the repositories searched by apt-get is a much
>> higher-ceremony operation than copying a file into some sys.path
>> directory or changing sys.path, so that indexing makes sense for
>> apt-get but not for Python's imports -- I can imagine the poor Python
>> interpreter churning away all the time updating the index all the
>> time.  And even then, the Python index WOULD still potentially miss
>> some entries, because a Python module is vastly more dynamic than the
>> totally-static repositories used by apt-get, where each package is
>> mandated to very explicitly state what it requires, and what it
>> provides.
>>
>> If you want to try your hand at this kind of extension, I recommend
>> you do it as a pypi package -- since all you want is peculiar messages
>> in response to some NameError or ImportError exceptions, you can hang
>> your functionality neatly into sys.excepthook -- there is absolutely
>> nothing to be gained by having the functionality inside the core
>> rather than in a third-party package.  Moreover, I would recommend
>> targeting the extension (solely or primarily) at "rich" environments
>> such as IDLE or ipython (http://ipython.scipy.org/moin/), whose users
>> already expect and obviously appreciate getting especially rich
>> interactive functionality even if it comes at the potential cost of
>> some overhead -- users of the Python built-in interactive interpreter
>> are more likely to be after lean-and-mean functionality instead.
>>
>> If and when your extension "takes the Python world by storm", you will
>> have strong practical arguments to recommend its inclusion in some
>> future version of Python -- its popularity will have proven that there
>> is strong demand for that functionality, after all.  Until such
>> support does exist, it's hard to argue for including in the Python
>> core offering something that can be done just as well as a 3rd party
>> package, has no proven demand, AND presents potentially delicate
>> tradeoffs in terms of implementation (is the user going to be asked to
>> explicitly reindex each time they alter sys.path, or is the overhead
>> of the reindexing going to be implicit in ANY alteration at all?  etc,
>> etc).
>>
>>
>> Alex
>
>

From abdallah.elguindy at gmail.com  Sun Aug 24 00:06:47 2008
From: abdallah.elguindy at gmail.com (Abdallah El Guindy)
Date: Sun, 24 Aug 2008 01:06:47 +0300
Subject: [Python-3000] Minor addition to Python interactive shell...
In-Reply-To: <e8a0972d0808231455n6fd45f82nb3b1f6363e696eb3@mail.gmail.com>
References: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
	<1afaf6160808231406q2dc07f41la4ef42327f4cbcc@mail.gmail.com>
	<112f66890808231410p78dcd54cm9a5280361d9dcc63@mail.gmail.com>
	<e8a0972d0808231435i4a07cbe0l69139f91f59052b0@mail.gmail.com>
	<112f66890808231445q5f594cdeqe9f535df135601df@mail.gmail.com>
	<e8a0972d0808231455n6fd45f82nb3b1f6363e696eb3@mail.gmail.com>
Message-ID: <112f66890808231506r33358effn42fa13cf592c3642@mail.gmail.com>

Of course I'm not discouraged =), rather convinced.. The feature's correct
place is outside of the core as you suggested! As for getting the index from
the docs, it is probably a good idea to look for that... Once I get some
free time, I'll give it some more thought..

Thanks again!

On Sun, Aug 24, 2008 at 12:55 AM, Alex Martelli <aleaxit at gmail.com> wrote:

> You're welcome!  I wasn't trying to discourage you -- I was trying to
> prompt you to do it the best way, as a third party open source project
> (perhaps a contributed one to iPython, etc).  Brett suggests that the
> index might be already around somewhere (maybe just for the standard
> library, but that would be a start) so if you could locate it then the
> needed excepthook might not be too hard to write, etc, etc.  However,
> it's definitely up to you!
>
> Alex
>
> On Sat, Aug 23, 2008 at 2:45 PM, Abdallah El Guindy
> <abdallah.elguindy at gmail.com> wrote:
> >> Adding a package to the repositories searched by apt-get is a much
> >> higher-ceremony operation than copying a file into some sys.path
> >> directory or changing sys.path, so that indexing makes sense for
> >> apt-get but not for Python's imports -- I can imagine the poor Python
> >> interpreter churning away all the time updating the index all the
> >> time.
> >
> > You are definitely right about that, I totally missed this when first
> > thinking about it...
> >
> >> there is absolutely
> >> nothing to be gained by having the functionality inside the core
> >> rather than in a third-party package.
> >
> > I guess you are right once again.
> >
> >> If and when your extension "takes the Python world by storm"
> >
> > I guess this is never gonna happen (that's why I probably tagged the
> feature
> > minor).
> >
> > I did not realized at the beginning that it has as much technical
> > complications.. Thanks for pointing that out, I'm convinced that perhaps
> it
> > is not a good idea after all.
> >
> > Thanks.
> >
> > On Sun, Aug 24, 2008 at 12:35 AM, Alex Martelli <aleaxit at gmail.com>
> wrote:
> >>
> >> On Sat, Aug 23, 2008 at 2:10 PM, Abdallah El Guindy
> >> <abdallah.elguindy at gmail.com> wrote:
> >> > I believe there must be a way... Maybe by creating an index file for
> >> > each
> >> > module. I'm not sure, but I think the number of packages on apt-get is
> >> > much
> >> > more than the number of python built-in modules (obviously I don't
> know
> >> > their number), yet it is doable with the case of apt-get.
> >>
> >> Adding a package to the repositories searched by apt-get is a much
> >> higher-ceremony operation than copying a file into some sys.path
> >> directory or changing sys.path, so that indexing makes sense for
> >> apt-get but not for Python's imports -- I can imagine the poor Python
> >> interpreter churning away all the time updating the index all the
> >> time.  And even then, the Python index WOULD still potentially miss
> >> some entries, because a Python module is vastly more dynamic than the
> >> totally-static repositories used by apt-get, where each package is
> >> mandated to very explicitly state what it requires, and what it
> >> provides.
> >>
> >> If you want to try your hand at this kind of extension, I recommend
> >> you do it as a pypi package -- since all you want is peculiar messages
> >> in response to some NameError or ImportError exceptions, you can hang
> >> your functionality neatly into sys.excepthook -- there is absolutely
> >> nothing to be gained by having the functionality inside the core
> >> rather than in a third-party package.  Moreover, I would recommend
> >> targeting the extension (solely or primarily) at "rich" environments
> >> such as IDLE or ipython (http://ipython.scipy.org/moin/), whose users
> >> already expect and obviously appreciate getting especially rich
> >> interactive functionality even if it comes at the potential cost of
> >> some overhead -- users of the Python built-in interactive interpreter
> >> are more likely to be after lean-and-mean functionality instead.
> >>
> >> If and when your extension "takes the Python world by storm", you will
> >> have strong practical arguments to recommend its inclusion in some
> >> future version of Python -- its popularity will have proven that there
> >> is strong demand for that functionality, after all.  Until such
> >> support does exist, it's hard to argue for including in the Python
> >> core offering something that can be done just as well as a 3rd party
> >> package, has no proven demand, AND presents potentially delicate
> >> tradeoffs in terms of implementation (is the user going to be asked to
> >> explicitly reindex each time they alter sys.path, or is the overhead
> >> of the reindexing going to be implicit in ANY alteration at all?  etc,
> >> etc).
> >>
> >>
> >> Alex
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080824/336ef3ae/attachment-0001.htm>

From wescpy at gmail.com  Sun Aug 24 23:27:56 2008
From: wescpy at gmail.com (wesley chun)
Date: Sun, 24 Aug 2008 14:27:56 -0700
Subject: [Python-3000] Several days later: no windows installers for b3
In-Reply-To: <bbaeab100808231309j66ad371l3d99324e94a153e5@mail.gmail.com>
References: <ffb592890808230629n6b1ae6e3g5552d927501c086a@mail.gmail.com>
	<bbaeab100808231309j66ad371l3d99324e94a153e5@mail.gmail.com>
Message-ID: <78b3a9580808241427r4ae5ccege87fc644405b67f2@mail.gmail.com>

>> No b3 installers for windows at http://www.python.org/download/releases/3.0/
> We know. Martin, who usually does the Windows installer, is on vacation.

once they're ready and the page updated, also change the 1st sentence
under "Download" to reflect beta (and future release candidate) status
as it still says, "This is an alpha release...."

-- wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python Programming", (c)2007,2001 PHPTR http://corepython.com
"Python Web Development with Django", (c)2008 AW http://withdjango.com

wesley.j.chun :: wescpy-at-gmail.com
python training and technical consulting
cyberweb.consulting : silicon valley, ca
http://cyberwebconsulting.com

From nnorwitz at gmail.com  Mon Aug 25 03:15:06 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 24 Aug 2008 18:15:06 -0700
Subject: [Python-3000] what version of bsddb to use/accept for 2.6/3.0
Message-ID: <ee2a432c0808241815n57de2264o2c958327968673da@mail.gmail.com>

Many buildbots are running bsddb 4.7, particularly the debian/ubuntu
ones (4.7.25 which seems to be the latest).  Some of them are
crashing, others are not.  The max version we support in both 2.6 and
3.0 is 4.7.  Should we allow this version or should we use a lower
maximum that is more likely to work (ie, not crash)?

It looks like the WIndows buildbots use 4.4.20.  Unfortunately, the
Windows bots aren't in great shape either.

Additionally, there are reference leaks in both 2.6 and 3.0:
  test_bsddb3 leaked [80, 80] references, sum=160 (2.6)
  test_bsddb3 leaked [63, 63] references, sum=126 (3.0)

It would be nice to get as many of these things fixed up before
release.  Jesus, Greg, Trent, can you make some time over the next
week to stabilize bsddb support?

Thanks,
n
PS.  To change the max version of bsddb supported in Unix, modify
max_db_ver in setup.py.

From martin at v.loewis.de  Mon Aug 25 07:37:41 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 25 Aug 2008 07:37:41 +0200
Subject: [Python-3000] XML as bytes or unicode?
In-Reply-To: <bbaeab100808181029w1eb1051fp9aecf0c6e239a818@mail.gmail.com>
References: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>	<bbaeab100808171209q7b29fff0pa585c02e0c95053a@mail.gmail.com>	<loom.20080818T162617-305@post.gmane.org>	<1afaf6160808180935k3470efc0n65c318b87d54a99@mail.gmail.com>	<loom.20080818T164216-491@post.gmane.org>
	<bbaeab100808181029w1eb1051fp9aecf0c6e239a818@mail.gmail.com>
Message-ID: <48B24525.3080808@v.loewis.de>

> Well, does the parser handle it or should the code that got the XML in
> the first place handle it?

The parser handles encodings in XML; XML parsing is "bytes in, pieces of
Unicode out".

> Apparently whomever wrote the parsers originally thought it was not
> the parser's job. =)

Why do you think so? In Python, the XML parsers have always supported
encoding declarations.

Parsing Unicode XML strings isn't quite that meaningful.

> If someone wanted to you could possibly dispatch on bytes to some code
> that tried to determine the encoding and do the proper decode before
> proceeding.

That's the parser's job (and one that expat does correctly).

Regards,
Martin

From martin at v.loewis.de  Mon Aug 25 08:29:31 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 25 Aug 2008 08:29:31 +0200
Subject: [Python-3000] Several days later: no windows installers for b3
In-Reply-To: <bbaeab100808231309j66ad371l3d99324e94a153e5@mail.gmail.com>
References: <ffb592890808230629n6b1ae6e3g5552d927501c086a@mail.gmail.com>
	<bbaeab100808231309j66ad371l3d99324e94a153e5@mail.gmail.com>
Message-ID: <48B2514B.30303@v.loewis.de>

Brett Cannon wrote:
> On Sat, Aug 23, 2008 at 6:29 AM, Edward K. Ream <edreamleo at gmail.com> wrote:
>> No b3 installers for windows at http://www.python.org/download/releases/3.0/
>>
> 
> We know. Martin, who usually does the Windows installer, is on vacation.

And I will be for two more weeks - so unless somebody else produces
them, there won't be any Windows binaries until September 8.

Regards,
Martin

From pacqa100 at yahoo.com.au  Mon Aug 25 12:29:55 2008
From: pacqa100 at yahoo.com.au (PL)
Date: Mon, 25 Aug 2008 20:29:55 +1000
Subject: [Python-3000] Windows Installer - default install directory
Message-ID: <48B289A3.1090502@yahoo.com.au>

Hi
I'm new to the list. Sorry if this has been discussed before, but I 
didn't notice it.
Is it possible for the Windows installer to install to some other 
directory than the root (i.e., somewhere else apart from C:\Python25 as 
2.5 does).
It goes against some Windows conventions to put it there.
Java has finally got it going to a default install at C:\Program 
Files\Java\jre1.5.0_04
My recommendation would be the Program Files directory.
There may be issues with the space in the directory name, though.
Peter

---------------------
Peter Lovett
web: www.pythontraining.com.au
---------------------

From barry at python.org  Mon Aug 25 13:14:06 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 25 Aug 2008 07:14:06 -0400
Subject: [Python-3000] Still get rid of the stat module?
In-Reply-To: <ca471dc20808211322v696ec61el72beabcd1d3811c7@mail.gmail.com>
References: <bbaeab100808211141y28524133y2763b0607a2ad824@mail.gmail.com>
	<g8kh60$epc$1@ger.gmane.org>
	<ca471dc20808211322v696ec61el72beabcd1d3811c7@mail.gmail.com>
Message-ID: <45E19A7E-010B-400C-A8CF-520A96F406A1@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 21, 2008, at 4:22 PM, Guido van Rossum wrote:

> On Thu, Aug 21, 2008 at 12:54 PM, Dirkjan Ochtman  
> <dirkjan at ochtman.nl> wrote:
>> Brett Cannon wrote:
>>>
>>> So my question is whether it is still worth trying to remove the
>>> module, or just leave it be.
>>
>> Seeing this is the only chance in the coming 15 years to fix this,  
>> I'd say
>> fix it... Having it around is pretty ugly, when the "real" stat() is
>> actually in os.
>
> Why? We could just deprecate it and rip it out in 3.1 or 3.2.

+1
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSLKT/nEjvBPtnXfVAQJOAwQAjTCgd+oI/BZCvRvKv25NroJuUo6iJPS3
eDv1rhmcMcIfTnQM5s2ZfATNWPVySHutiMy3Yr/kRmFZ8kcNwwJqwybc6KpTkGD2
waFYXsNvUb01MlHwcKCnZjYgYrXmFIvWJV+n6TqqjA0GpsswE8pZosA8Da5wpIqT
pLRD7phA+E8=
=YuAe
-----END PGP SIGNATURE-----

From doko at ubuntu.com  Mon Aug 25 03:21:02 2008
From: doko at ubuntu.com (Matthias Klose)
Date: Mon, 25 Aug 2008 03:21:02 +0200
Subject: [Python-3000] what version of bsddb to use/accept for 2.6/3.0
In-Reply-To: <ee2a432c0808241815n57de2264o2c958327968673da@mail.gmail.com>
References: <ee2a432c0808241815n57de2264o2c958327968673da@mail.gmail.com>
Message-ID: <48B208FE.8050600@ubuntu.com>

[CCing Clint]

4.7.25 generally looks fine, except for sparc (afaics); I asked the Debian bsddb
maintainer to have a look at the sparc problems. At least on sparc, there's no
difference between 4.6 and 4.7. I usually try to run the buildbots with the
recent software in the distribution, as this is what users will see with the
next release.

  Matthias

PS: currently travelling, won't be able to answer in time.

Neal Norwitz schrieb:
> Many buildbots are running bsddb 4.7, particularly the debian/ubuntu
> ones (4.7.25 which seems to be the latest).  Some of them are
> crashing, others are not.  The max version we support in both 2.6 and
> 3.0 is 4.7.  Should we allow this version or should we use a lower
> maximum that is more likely to work (ie, not crash)?
> 
> It looks like the WIndows buildbots use 4.4.20.  Unfortunately, the
> Windows bots aren't in great shape either.
> 
> Additionally, there are reference leaks in both 2.6 and 3.0:
>   test_bsddb3 leaked [80, 80] references, sum=160 (2.6)
>   test_bsddb3 leaked [63, 63] references, sum=126 (3.0)
> 
> It would be nice to get as many of these things fixed up before
> release.  Jesus, Greg, Trent, can you make some time over the next
> week to stabilize bsddb support?
> 
> Thanks,
> n
> PS.  To change the max version of bsddb supported in Unix, modify
> max_db_ver in setup.py.


From tjreedy at udel.edu  Mon Aug 25 17:30:44 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 25 Aug 2008 11:30:44 -0400
Subject: [Python-3000] Windows Installer - default install directory
In-Reply-To: <48B289A3.1090502@yahoo.com.au>
References: <48B289A3.1090502@yahoo.com.au>
Message-ID: <g8uj71$3st$1@ger.gmane.org>



PL wrote:
> Hi
> I'm new to the list. Sorry if this has been discussed before, but I 
> didn't notice it.
> Is it possible for the Windows installer to install to some other 
> directory than the root (i.e., somewhere else apart from C:\Python25 as 
> 2.5 does).

That is the default.  You are free to put in /program files, as I have 
done without apparent problems.


From guido at python.org  Mon Aug 25 18:23:30 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 25 Aug 2008 09:23:30 -0700
Subject: [Python-3000] XML as bytes or unicode?
In-Reply-To: <48B24525.3080808@v.loewis.de>
References: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>
	<bbaeab100808171209q7b29fff0pa585c02e0c95053a@mail.gmail.com>
	<loom.20080818T162617-305@post.gmane.org>
	<1afaf6160808180935k3470efc0n65c318b87d54a99@mail.gmail.com>
	<loom.20080818T164216-491@post.gmane.org>
	<bbaeab100808181029w1eb1051fp9aecf0c6e239a818@mail.gmail.com>
	<48B24525.3080808@v.loewis.de>
Message-ID: <ca471dc20808250923h39fd06bei16c71508e391610f@mail.gmail.com>

2008/8/24 "Martin v. L?wis" <martin at v.loewis.de>:
> Parsing Unicode XML strings isn't quite that meaningful.

Maybe not according to the XML standard, but I can see lots of
practical situations where the encoding is always known and applied by
some other layer, i.e. the I/O library or a database wrapper. Forcing
XML to be interpreted as binary isn't always the best idea. E.g.
consider storing XML in a SVN repository. Or consider storing XML
fragments in Python string literals.

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

From rrr at ronadam.com  Tue Aug 26 21:48:17 2008
From: rrr at ronadam.com (Ron Adam)
Date: Tue, 26 Aug 2008 14:48:17 -0500
Subject: [Python-3000] Minor addition to Python interactive shell...
In-Reply-To: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
References: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
Message-ID: <48B45E01.3060508@ronadam.com>



Abdallah El Guindy wrote:
> Hey all
> 
> I know that the feature I am about to suggest may be minor and may have 
> a very low priority considering other issues to be discussed, however 
> I'll suggest it anyways..
> 
> Being a very frequent user of the interactive shell, I find it annoying 
> when I try to use a function or a class that resides in another module 
> that I haven't imported... So why not let the interactive shell say a 
> message about the appropriate module to be imported for this 
> class/function.. The idea is similar to bash on Ubuntu, if you don't 
> have the necessary package it lets you know by suggesting the package 
> name to be installed.
> 
> Let me know what you think.

I think the best way to add this is to add it to the help function, which 
is the console interface to pydoc.  Something like help(find="name") could 
find all instances of name in all available modules.

Ron



From rrr at ronadam.com  Tue Aug 26 21:48:17 2008
From: rrr at ronadam.com (Ron Adam)
Date: Tue, 26 Aug 2008 14:48:17 -0500
Subject: [Python-3000] Minor addition to Python interactive shell...
In-Reply-To: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
References: <112f66890808231403wb641dacsb0d49846e6477130@mail.gmail.com>
Message-ID: <48B45E01.3060508@ronadam.com>



Abdallah El Guindy wrote:
> Hey all
> 
> I know that the feature I am about to suggest may be minor and may have 
> a very low priority considering other issues to be discussed, however 
> I'll suggest it anyways..
> 
> Being a very frequent user of the interactive shell, I find it annoying 
> when I try to use a function or a class that resides in another module 
> that I haven't imported... So why not let the interactive shell say a 
> message about the appropriate module to be imported for this 
> class/function.. The idea is similar to bash on Ubuntu, if you don't 
> have the necessary package it lets you know by suggesting the package 
> name to be installed.
> 
> Let me know what you think.

I think the best way to add this is to add it to the help function, which 
is the console interface to pydoc.  Something like help(find="name") could 
find all instances of name in all available modules.

Ron



From samuel.j.bishop at gmail.com  Wed Aug 27 05:21:53 2008
From: samuel.j.bishop at gmail.com (Sam Bishop)
Date: Tue, 26 Aug 2008 21:21:53 -0600
Subject: [Python-3000] default argument surprises
Message-ID: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>

Hi, all.

I know that Python 3.0 is quite a ways along, but I'd like to make two
small suggestions with regards to how the language works.  (I would
have spoken up earlier, except that I'm very new to Python.)

I've talked to a few of my co-workers who are also new to Python, and
we've all been surprised at the way code like this behaves:

:def process(L=[]):
:    # 'x' always needs processed...
:    L += ['x']
:    print L
:
:process()  # prints "['x']"
:process()  # prints "['x', 'x']"!

We've been able to figure out what's happening, but it seems counter-intuitive.

If Python were changed so that default-argument, rvalue objects were
recreated each time a function is invoked, I think that it would be
intuitive (and efficient) if the object were only created when
necessary.  Here's (approximately) another code snippet I've seen
recently:

:def determine_default():
:    print "Why is this code executing?"
:    return 1
:
:def fun(arg=determine_default()):
:    pass
:
:fun("value")

Thanks,
Sam

From cvrebert at gmail.com  Wed Aug 27 05:31:13 2008
From: cvrebert at gmail.com (Chris Rebert)
Date: Tue, 26 Aug 2008 20:31:13 -0700
Subject: [Python-3000] default argument surprises
In-Reply-To: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
Message-ID: <47c890dc0808262031w239e62fetc74d4c1e1be25873@mail.gmail.com>

You might then be interested in the following related discussions from
last year wherein I proposed something extremely similar:

[Python-ideas] proto-PEP: Fixing Non-constant Default Arguments
http://mail.python.org/pipermail/python-ideas/2007-January/000121.html

[Python-3000] pre-PEP: Default Argument Expressions
http://mail.python.org/pipermail/python-3000/2007-February/005712.html

The proposal was rejected by the BDFL (for being too magical) before
it had become a full-fledged PEP.

- Chris


On Tue, Aug 26, 2008 at 8:21 PM, Sam Bishop <samuel.j.bishop at gmail.com> wrote:
> Hi, all.
>
> I know that Python 3.0 is quite a ways along, but I'd like to make two
> small suggestions with regards to how the language works.  (I would
> have spoken up earlier, except that I'm very new to Python.)
>
> I've talked to a few of my co-workers who are also new to Python, and
> we've all been surprised at the way code like this behaves:
>
> :def process(L=[]):
> :    # 'x' always needs processed...
> :    L += ['x']
> :    print L
> :
> :process()  # prints "['x']"
> :process()  # prints "['x', 'x']"!
>
> We've been able to figure out what's happening, but it seems counter-intuitive.
>
> If Python were changed so that default-argument, rvalue objects were
> recreated each time a function is invoked, I think that it would be
> intuitive (and efficient) if the object were only created when
> necessary.  Here's (approximately) another code snippet I've seen
> recently:
>
> :def determine_default():
> :    print "Why is this code executing?"
> :    return 1
> :
> :def fun(arg=determine_default()):
> :    pass
> :
> :fun("value")
>
> Thanks,
> Sam
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/cvrebert%40gmail.com
>

From bruce at leapyear.org  Wed Aug 27 06:10:16 2008
From: bruce at leapyear.org (Bruce Leban)
Date: Tue, 26 Aug 2008 21:10:16 -0700
Subject: [Python-3000] default argument surprises
In-Reply-To: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
Message-ID: <cf5b87740808262110v469e8d78td495551def09c2b2@mail.gmail.com>

There are two issues** here:

(1) def foo(L=[]):
the [] is a single list, not a new list created every time the function is
called.

(2) def foo(L=list()):
the list() is evaluated once when the function is declared.

I think (1) is easy to explain; I find (2) confusing. (**Yes, I realize that
these can be considered the same issue, but I'm speaking here as a person
writing python programs, not designing the language.) On the other hand,
consider this code:

    bar = 1
    def foo(arg=bar):
      print(arg)
    bar = 2
    foo()

I would be very surprised if foo() printed 2 rather than 1. The difference
to my (programmer's) mind is that in this case bar looks like a simple value
and list() looks like a function call. So it's not quite that simple. At
least the way it works now is completely consistent and the code:

    def foo(arg=None):
      arg = bar if arg is None else arg
      arg2 = list() if arg is None else arg

is unambiguous if clumsy.

Now thinking as a language designer, C# has a ?? operator where A??B is
shorthand for (B if A is None else A) except you only have to write A once
and A is only evaluated once. A Pythonesque version of this would be just
"else":

   def foo(arg=None, arg2=None):
      arg = arg else bar
      arg2 = arg2 else list()

And I think that metaphor is easy to read. Chains of else operators can be
useful:

   x = f() else g() else h() else 0

--- Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080826/d80b85b9/attachment.htm>

From shiblon at gmail.com  Wed Aug 27 06:14:59 2008
From: shiblon at gmail.com (Chris Monson)
Date: Tue, 26 Aug 2008 21:14:59 -0700
Subject: [Python-3000] default argument surprises
In-Reply-To: <cf5b87740808262110v469e8d78td495551def09c2b2@mail.gmail.com>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
	<cf5b87740808262110v469e8d78td495551def09c2b2@mail.gmail.com>
Message-ID: <da3f900e0808262114q687d60deje1f1880f28c72570@mail.gmail.com>

On Tue, Aug 26, 2008 at 9:10 PM, Bruce Leban <bruce at leapyear.org> wrote:

> There are two issues** here:
>
> (1) def foo(L=[]):
> the [] is a single list, not a new list created every time the function is
> called.
>
> (2) def foo(L=list()):
> the list() is evaluated once when the function is declared.
>
> I think (1) is easy to explain; I find (2) confusing. (**Yes, I realize
> that these can be considered the same issue, but I'm speaking here as a
> person writing python programs, not designing the language.) On the other
> hand, consider this code:
>
>     bar = 1
>     def foo(arg=bar):
>       print(arg)
>     bar = 2
>     foo()
>
> I would be very surprised if foo() printed 2 rather than 1. The difference
> to my (programmer's) mind is that in this case bar looks like a simple value
> and list() looks like a function call. So it's not quite that simple. At
> least the way it works now is completely consistent and the code:
>
>     def foo(arg=None):
>       arg = bar if arg is None else arg
>       arg2 = list() if arg is None else arg
>
> is unambiguous if clumsy.
>
> Now thinking as a language designer, C# has a ?? operator where A??B is
> shorthand for (B if A is None else A) except you only have to write A once
> and A is only evaluated once. A Pythonesque version of this would be just
> "else":
>
>    def foo(arg=None, arg2=None):
>       arg = arg else bar
>       arg2 = arg2 else list()
>
> And I think that metaphor is easy to read. Chains of else operators can be
> useful:
>
>    x = f() else g() else h() else 0
>

Not a bad idea.  Looks like the time machine is at work again:

x = f() or g() or h() or 0

:-)

- C


>
>
> --- Bruce
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/shiblon%40gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080826/44dd31ef/attachment.htm>

From foom at fuhm.net  Wed Aug 27 06:23:59 2008
From: foom at fuhm.net (James Y Knight)
Date: Wed, 27 Aug 2008 00:23:59 -0400
Subject: [Python-3000] default argument surprises
In-Reply-To: <da3f900e0808262114q687d60deje1f1880f28c72570@mail.gmail.com>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
	<cf5b87740808262110v469e8d78td495551def09c2b2@mail.gmail.com>
	<da3f900e0808262114q687d60deje1f1880f28c72570@mail.gmail.com>
Message-ID: <A87BFBDC-35AB-4141-876A-843B5669ED6D@fuhm.net>

On Aug 27, 2008, at 12:14 AM, Chris Monson wrote:
> Now thinking as a language designer, C# has a ?? operator where A??B  
> is shorthand for (B if A is None else A) except you only have to  
> write A once and A is only evaluated once. A Pythonesque version of  
> this would be just "else":
>
>    def foo(arg=None, arg2=None):
>       arg = arg else bar
>       arg2 = arg2 else list()
>
> And I think that metaphor is easy to read. Chains of else operators  
> can be useful:
>
>    x = f() else g() else h() else 0
>
> Not a bad idea.  Looks like the time machine is at work again:
>
> x = f() or g() or h() or 0

Well...no. "else" here is significantly different from "or": it only  
tests for None, not falseness.

 >>> A = 0
 >>> B = 1

 >>> B if A is None else A # suggested equivalence for "A else B"
0
 >>> A or B
1

Although, maybe you just meant that "else" and "or" have such similar  
behavior, and their names do not obviously distinguish their behavior.  
And, thus, people would find them confusing, so "else" should not be  
added to the language. That I could agree with.

James

From cvrebert at gmail.com  Wed Aug 27 07:39:00 2008
From: cvrebert at gmail.com (Chris Rebert)
Date: Tue, 26 Aug 2008 22:39:00 -0700
Subject: [Python-3000] default argument surprises
In-Reply-To: <47c890dc0808262031w239e62fetc74d4c1e1be25873@mail.gmail.com>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
	<47c890dc0808262031w239e62fetc74d4c1e1be25873@mail.gmail.com>
Message-ID: <47c890dc0808262239k202e79a4q364b98be387ea5b0@mail.gmail.com>

On Tue, Aug 26, 2008 at 8:31 PM, Chris Rebert <cvrebert at gmail.com> wrote:
> You might then be interested in the following related discussions from
> last year wherein I proposed something extremely similar:
>
> [Python-ideas] proto-PEP: Fixing Non-constant Default Arguments
> http://mail.python.org/pipermail/python-ideas/2007-January/000121.html
>
> [Python-3000] pre-PEP: Default Argument Expressions
> http://mail.python.org/pipermail/python-3000/2007-February/005712.html

I apologize, this second link should have been to
http://mail.python.org/pipermail/python-3000/2007-February/005704.html
- Chris

>
> The proposal was rejected by the BDFL (for being too magical) before
> it had become a full-fledged PEP.
>
> - Chris
>
>
> On Tue, Aug 26, 2008 at 8:21 PM, Sam Bishop <samuel.j.bishop at gmail.com> wrote:
>> Hi, all.
>>
>> I know that Python 3.0 is quite a ways along, but I'd like to make two
>> small suggestions with regards to how the language works.  (I would
>> have spoken up earlier, except that I'm very new to Python.)
>>
>> I've talked to a few of my co-workers who are also new to Python, and
>> we've all been surprised at the way code like this behaves:
>>
>> :def process(L=[]):
>> :    # 'x' always needs processed...
>> :    L += ['x']
>> :    print L
>> :
>> :process()  # prints "['x']"
>> :process()  # prints "['x', 'x']"!
>>
>> We've been able to figure out what's happening, but it seems counter-intuitive.
>>
>> If Python were changed so that default-argument, rvalue objects were
>> recreated each time a function is invoked, I think that it would be
>> intuitive (and efficient) if the object were only created when
>> necessary.  Here's (approximately) another code snippet I've seen
>> recently:
>>
>> :def determine_default():
>> :    print "Why is this code executing?"
>> :    return 1
>> :
>> :def fun(arg=determine_default()):
>> :    pass
>> :
>> :fun("value")
>>
>> Thanks,
>> Sam
>> _______________________________________________
>> Python-3000 mailing list
>> Python-3000 at python.org
>> http://mail.python.org/mailman/listinfo/python-3000
>> Unsubscribe: http://mail.python.org/mailman/options/python-3000/cvrebert%40gmail.com
>>
>

From eastor1 at swarthmore.edu  Wed Aug 27 07:15:48 2008
From: eastor1 at swarthmore.edu (Eric Astor)
Date: Wed, 27 Aug 2008 01:15:48 -0400
Subject: [Python-3000] else Versus or (Was: Re: default argument surprises)
In-Reply-To: <da3f900e0808262114q687d60deje1f1880f28c72570@mail.gmail.com>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>	<cf5b87740808262110v469e8d78td495551def09c2b2@mail.gmail.com>
	<da3f900e0808262114q687d60deje1f1880f28c72570@mail.gmail.com>
Message-ID: <48B4E304.7090706@swarthmore.edu>

Chris Monson wrote:
>     Now thinking as a language designer, C# has a ?? operator where A??B
>     is shorthand for (B if A is None else A) except you only have to
>     write A once and A is only evaluated once. A Pythonesque version of
>     this would be just "else":
> 
>        def foo(arg=None, arg2=None):
>           arg = arg else bar
>           arg2 = arg2 else list()
>          
>     And I think that metaphor is easy to read. Chains of else operators
>     can be useful:
> 
>        x = f() else g() else h() else 0
> 
> 
> Not a bad idea.  Looks like the time machine is at work again:
> 
> x = f() or g() or h() or 0

True, but 'else' can be a more specific operator, so that

>>> arg = arg else bar

is equivalent to:

>>> if arg is None: arg = bar,

where

>>> arg = arg or bar

is instead equivalent to:

>>> if not arg: arg = b

This has the advantage of being more linguistically clear and/or
unambiguous. No nasty surprises when someone calls foo(0, []); using or,
you'd get default argument treatment when you might need the values as
specified. This is basically the reasoning used for introducing

>>> arg = b if a else c

where we had a hack before that failed in certain corner cases

>>> arg = a and b or c

It's a little more nuanced here, I admit, but it doesn't seem like it
would kill anything too badly. If we weren't freezing, it'd be something
to toss around and explore - as it stands, maybe this should get filed
as an idea for the future.

- Eric Astor

From bruce at leapyear.org  Wed Aug 27 08:47:00 2008
From: bruce at leapyear.org (Bruce Leban)
Date: Tue, 26 Aug 2008 23:47:00 -0700
Subject: [Python-3000] default argument surprises
In-Reply-To: <A87BFBDC-35AB-4141-876A-843B5669ED6D@fuhm.net>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
	<cf5b87740808262110v469e8d78td495551def09c2b2@mail.gmail.com>
	<da3f900e0808262114q687d60deje1f1880f28c72570@mail.gmail.com>
	<A87BFBDC-35AB-4141-876A-843B5669ED6D@fuhm.net>
Message-ID: <cf5b87740808262347g93f4dcfx266028532b9f571@mail.gmail.com>

On Tue, Aug 26, 2008 at 9:23 PM, James Y Knight <foom at fuhm.net> wrote:

> On Aug 27, 2008, at 12:14 AM, Chris Monson wrote:
>
>>
>> And I think that metaphor is easy to read. Chains of else operators can be
>> useful:
>>
>>   x = f() else g() else h() else 0
>>
>> Not a bad idea.  Looks like the time machine is at work again:
>>
>> x = f() or g() or h() or 0
>>
>
> Well...no. "else" here is significantly different from "or": it only tests
> for None, not falseness.
>
> Correct.

>
> Although, maybe you just meant that "else" and "or" have such similar
> behavior, and their names do not obviously distinguish their behavior. And,
> thus, people would find them confusing, so "else" should not be added to the
> language. That I could agree with.
>
> Unfortunately, I agree that it's confusing because else implies a boolean
value. It doesn't mean that some other analog for the ?? operator wouldn't
be useful. Alternatively, an analog for just the ??= operator would
explicitly address this case:

    arg floob value
is
    arg = value if arg is None else arg

although I'm sure there's a better word than floob. The downside of floob is
that it only addresses this case so not a very convincing argument.

--- Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080826/e7a1e5f6/attachment.htm>

From samuel.j.bishop at gmail.com  Wed Aug 27 18:29:53 2008
From: samuel.j.bishop at gmail.com (Sam Bishop)
Date: Wed, 27 Aug 2008 10:29:53 -0600
Subject: [Python-3000] default argument surprises
In-Reply-To: <47c890dc0808262239k202e79a4q364b98be387ea5b0@mail.gmail.com>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
	<47c890dc0808262031w239e62fetc74d4c1e1be25873@mail.gmail.com>
	<47c890dc0808262239k202e79a4q364b98be387ea5b0@mail.gmail.com>
Message-ID: <3cadf8630808270929l33d451edwd1497a8cb1b1bde0@mail.gmail.com>

On Tue, Aug 26, 2008 at 8:31 PM, Chris Rebert <cvrebert at gmail.com> wrote:
> You might then be interested in the following related discussions from
> last year wherein I proposed something extremely similar:
>
> [Python-ideas] proto-PEP: Fixing Non-constant Default Arguments
> http://mail.python.org/pipermail/python-ideas/2007-January/000121.html
>
> [Python-3000] pre-PEP: Default Argument Expressions
> http://mail.python.org/pipermail/python-3000/2007-February/005712.html

Hmm...  That's too bad.  I like your PEP.  :)

I disagree with Guido's comment about this being related to class
variables, from a newbie's point of view anyway.  Classes introduce a
namespace and functions introduce a scope.  What surprises me is that
functions seem to introduce two scopes: one for variables declared as
formal parameters and one for variables assigned to within the
function.

Don't get me wrong.  I realize that I'm a newbie, but I expect that's
a unique perspective for those subscribed to this list.  And I do know
what "BDFL" stands for.  :)

Thanks,
Sam

From stefan_ml at behnel.de  Wed Aug 27 19:30:06 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 27 Aug 2008 19:30:06 +0200
Subject: [Python-3000] XML as bytes or unicode?
In-Reply-To: <ca471dc20808250923h39fd06bei16c71508e391610f@mail.gmail.com>
References: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>	<bbaeab100808171209q7b29fff0pa585c02e0c95053a@mail.gmail.com>	<loom.20080818T162617-305@post.gmane.org>	<1afaf6160808180935k3470efc0n65c318b87d54a99@mail.gmail.com>	<loom.20080818T164216-491@post.gmane.org>	<bbaeab100808181029w1eb1051fp9aecf0c6e239a818@mail.gmail.com>	<48B24525.3080808@v.loewis.de>
	<ca471dc20808250923h39fd06bei16c71508e391610f@mail.gmail.com>
Message-ID: <g942uu$2mb$1@ger.gmane.org>

Guido van Rossum wrote:
> 2008/8/24 "Martin v. L?wis" <martin at v.loewis.de>:
>> Parsing Unicode XML strings isn't quite that meaningful.
> 
> Maybe not according to the XML standard, but I can see lots of
> practical situations where the encoding is always known and applied by
> some other layer, i.e. the I/O library or a database wrapper. Forcing
> XML to be interpreted as binary isn't always the best idea. E.g.
> consider storing XML in a SVN repository. Or consider storing XML
> fragments in Python string literals.

lxml handles XML data in unicode strings nicely. The reasoning is that the XML
spec says in 4.3.3:

"""
In the absence of information provided by an external transport protocol (e.g.
HTTP or MIME), it is a fatal error for an entity including an encoding
declaration to be presented to the XML processor in an encoding other than
that named in the declaration [...]
"""

On a given platform, the internal encoding of a Python unicode string is well
defined, which means it is as good as an encoding provided by a transport
protocol. So this works as long as the XML content of the unicode string does
not specify a wrong encoding itself (in which case the parser must reject it).

Another reason why lxml handles this is that it also has great support for
HTML. In the HTML world, unicode data is a lot easier to handle than the
average byte encoded page that doesn't provide any encoding information at all.

Stefan


From brett at python.org  Wed Aug 27 20:01:26 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 27 Aug 2008 11:01:26 -0700
Subject: [Python-3000] default argument surprises
In-Reply-To: <3cadf8630808270929l33d451edwd1497a8cb1b1bde0@mail.gmail.com>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
	<47c890dc0808262031w239e62fetc74d4c1e1be25873@mail.gmail.com>
	<47c890dc0808262239k202e79a4q364b98be387ea5b0@mail.gmail.com>
	<3cadf8630808270929l33d451edwd1497a8cb1b1bde0@mail.gmail.com>
Message-ID: <bbaeab100808271101i59e7a92ai6cea3a92b53df60f@mail.gmail.com>

On Wed, Aug 27, 2008 at 9:29 AM, Sam Bishop <samuel.j.bishop at gmail.com> wrote:
> On Tue, Aug 26, 2008 at 8:31 PM, Chris Rebert <cvrebert at gmail.com> wrote:
>> You might then be interested in the following related discussions from
>> last year wherein I proposed something extremely similar:
>>
>> [Python-ideas] proto-PEP: Fixing Non-constant Default Arguments
>> http://mail.python.org/pipermail/python-ideas/2007-January/000121.html
>>
>> [Python-3000] pre-PEP: Default Argument Expressions
>> http://mail.python.org/pipermail/python-3000/2007-February/005712.html
>
> Hmm...  That's too bad.  I like your PEP.  :)
>
> I disagree with Guido's comment about this being related to class
> variables, from a newbie's point of view anyway.  Classes introduce a
> namespace and functions introduce a scope.  What surprises me is that
> functions seem to introduce two scopes: one for variables declared as
> formal parameters and one for variables assigned to within the
> function.
>

But the point is that this is a newbie POV that is based on a
misunderstanding. It's going to be nearly impossible to remove all
possible gotchas from the language based on what a proto-typical
newbie might get tripped up on when it is based on a misunderstanding.
If you don't view everything but function/method bodies as executed
code, then you have a misconception about how Python works.

Perhaps this can be better explained in the tutorial or language
reference. But because something is not being communicated well by the
documentation does not mean it needs to be changed.

-Brett

From cvrebert at gmail.com  Wed Aug 27 20:25:07 2008
From: cvrebert at gmail.com (Chris Rebert)
Date: Wed, 27 Aug 2008 11:25:07 -0700
Subject: [Python-3000] default argument surprises
In-Reply-To: <bbaeab100808271101i59e7a92ai6cea3a92b53df60f@mail.gmail.com>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
	<47c890dc0808262031w239e62fetc74d4c1e1be25873@mail.gmail.com>
	<47c890dc0808262239k202e79a4q364b98be387ea5b0@mail.gmail.com>
	<3cadf8630808270929l33d451edwd1497a8cb1b1bde0@mail.gmail.com>
	<bbaeab100808271101i59e7a92ai6cea3a92b53df60f@mail.gmail.com>
Message-ID: <47c890dc0808271125u1ae7f9abu5727cf267fc3e56@mail.gmail.com>

On Wed, Aug 27, 2008 at 11:01 AM, Brett Cannon <brett at python.org> wrote:
> On Wed, Aug 27, 2008 at 9:29 AM, Sam Bishop <samuel.j.bishop at gmail.com> wrote:
>> On Tue, Aug 26, 2008 at 8:31 PM, Chris Rebert <cvrebert at gmail.com> wrote:
>>> You might then be interested in the following related discussions from
>>> last year wherein I proposed something extremely similar:
>>>
>>> [Python-ideas] proto-PEP: Fixing Non-constant Default Arguments
>>> http://mail.python.org/pipermail/python-ideas/2007-January/000121.html
>>>
>>> [Python-3000] pre-PEP: Default Argument Expressions
>>> http://mail.python.org/pipermail/python-3000/2007-February/005712.html
>>
>> Hmm...  That's too bad.  I like your PEP.  :)
>>
>> I disagree with Guido's comment about this being related to class
>> variables, from a newbie's point of view anyway.  Classes introduce a
>> namespace and functions introduce a scope.  What surprises me is that
>> functions seem to introduce two scopes: one for variables declared as
>> formal parameters and one for variables assigned to within the
>> function.
>>
>
> But the point is that this is a newbie POV that is based on a
> misunderstanding. It's going to be nearly impossible to remove all
> possible gotchas from the language based on what a proto-typical
> newbie might get tripped up on when it is based on a misunderstanding.
> If you don't view everything but function/method bodies as executed
> code, then you have a misconception about how Python works.
>
> Perhaps this can be better explained in the tutorial or language
> reference. But because something is not being communicated well by the
> documentation does not mean it needs to be changed.
>
> -Brett
>

Normally I'd agree, but in this case there seems to be no significant
advantage to the current behavior over the hypothetical behavior
beyond simply inertia and a slight possible performance advantage.
While the hypothetical behavior would obviate the extremely common
"x=None): if x is None: x = foo" idiom AND prevent the sorts of
confusion that the OP experienced, the current behavior is mostly only
advantageous when using function arguments as caches, except that
there are much better and clearer ways to do these caches!

But anyway, Python 3.0 is already basically closed to further language
modifications, so this discussion is more or less moot. :)

- Chris
========
Follow the path of the Iguana...
Rebertia: http://rebertia.com
Blog: http://blog.rebertia.com

From ncoghlan at gmail.com  Wed Aug 27 23:27:07 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 28 Aug 2008 07:27:07 +1000
Subject: [Python-3000] default argument surprises
In-Reply-To: <47c890dc0808271125u1ae7f9abu5727cf267fc3e56@mail.gmail.com>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>	<47c890dc0808262031w239e62fetc74d4c1e1be25873@mail.gmail.com>	<47c890dc0808262239k202e79a4q364b98be387ea5b0@mail.gmail.com>	<3cadf8630808270929l33d451edwd1497a8cb1b1bde0@mail.gmail.com>	<bbaeab100808271101i59e7a92ai6cea3a92b53df60f@mail.gmail.com>
	<47c890dc0808271125u1ae7f9abu5727cf267fc3e56@mail.gmail.com>
Message-ID: <48B5C6AB.9030407@gmail.com>

Chris Rebert wrote:
> On Wed, Aug 27, 2008 at 11:01 AM, Brett Cannon <brett at python.org> wrote:
>> On Wed, Aug 27, 2008 at 9:29 AM, Sam Bishop <samuel.j.bishop at gmail.com> wrote:
>>> On Tue, Aug 26, 2008 at 8:31 PM, Chris Rebert <cvrebert at gmail.com> wrote:
>>>> You might then be interested in the following related discussions from
>>>> last year wherein I proposed something extremely similar:
>>>>
>>>> [Python-ideas] proto-PEP: Fixing Non-constant Default Arguments
>>>> http://mail.python.org/pipermail/python-ideas/2007-January/000121.html
>>>>
>>>> [Python-3000] pre-PEP: Default Argument Expressions
>>>> http://mail.python.org/pipermail/python-3000/2007-February/005712.html
>>> Hmm...  That's too bad.  I like your PEP.  :)
>>>
>>> I disagree with Guido's comment about this being related to class
>>> variables, from a newbie's point of view anyway.  Classes introduce a
>>> namespace and functions introduce a scope.  What surprises me is that
>>> functions seem to introduce two scopes: one for variables declared as
>>> formal parameters and one for variables assigned to within the
>>> function.
>>>
>> But the point is that this is a newbie POV that is based on a
>> misunderstanding. It's going to be nearly impossible to remove all
>> possible gotchas from the language based on what a proto-typical
>> newbie might get tripped up on when it is based on a misunderstanding.
>> If you don't view everything but function/method bodies as executed
>> code, then you have a misconception about how Python works.
>>
>> Perhaps this can be better explained in the tutorial or language
>> reference. But because something is not being communicated well by the
>> documentation does not mean it needs to be changed.
>>
>> -Brett
>>
> 
> Normally I'd agree, but in this case there seems to be no significant
> advantage to the current behavior over the hypothetical behavior
> beyond simply inertia and a slight possible performance advantage.
> While the hypothetical behavior would obviate the extremely common
> "x=None): if x is None: x = foo" idiom AND prevent the sorts of
> confusion that the OP experienced, the current behavior is mostly only
> advantageous when using function arguments as caches, except that
> there are much better and clearer ways to do these caches!

Late binding default arguments would do some fairly bad things to nested
functions such as preventing the use of class attributes when defining
method default arguments, and having the default value reflect the last
bound value of a function local, instead of the value bound at the time
when the nested function is defined. It would also result in closures
being created in many cases where they aren't currently needed (i.e.
when the only reference to variables in the containing scope is via
default argument values).

The speed impact of late binding is also non-trivial, since the cost of
the default argument evaluation would then be incurred every time the
function is called, instead of just once when the function is defined.

Given that both approaches (binding at definition execution time and
binding afresh at each call) have their "gotchas", and the latter offers
no compelling advantages over the former and comes with some major
disadvantages (such as breaking every piece of Python code that relies
on the current behaviour and slowing down calls to all functions with
default arguments), I'd say our reasons for leaving it the way it is are
a bit stronger than is suggested by the "inertia and a slight possible
performance advantage" phrasing. Backwards compatibility and speed
matter, and neither should be thrown away just because novices find
something a little confusing before they understand how it works.

Cheers,
Nick.

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

From greg.ewing at canterbury.ac.nz  Thu Aug 28 02:47:26 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 28 Aug 2008 12:47:26 +1200
Subject: [Python-3000] XML as bytes or unicode?
In-Reply-To: <g942uu$2mb$1@ger.gmane.org>
References: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>
	<bbaeab100808171209q7b29fff0pa585c02e0c95053a@mail.gmail.com>
	<loom.20080818T162617-305@post.gmane.org>
	<1afaf6160808180935k3470efc0n65c318b87d54a99@mail.gmail.com>
	<loom.20080818T164216-491@post.gmane.org>
	<bbaeab100808181029w1eb1051fp9aecf0c6e239a818@mail.gmail.com>
	<48B24525.3080808@v.loewis.de>
	<ca471dc20808250923h39fd06bei16c71508e391610f@mail.gmail.com>
	<g942uu$2mb$1@ger.gmane.org>
Message-ID: <48B5F59E.8060104@canterbury.ac.nz>

Stefan Behnel wrote:

> In the absence of information provided by an external transport protocol (e.g.
> HTTP or MIME), it is a fatal error for an entity including an encoding
> declaration to be presented to the XML processor in an encoding other than
> that named in the declaration [...]

But if the XML has already been decoded and turned into
a Python unicode string, there *is* external information
about the encoding -- we know it's encoded however Python
represents unicode internally. So this clause doesn't
apply.

-- 
Greg

From aleaxit at gmail.com  Thu Aug 28 04:01:06 2008
From: aleaxit at gmail.com (Alex Martelli)
Date: Wed, 27 Aug 2008 19:01:06 -0700
Subject: [Python-3000] default argument surprises
In-Reply-To: <48B5C6AB.9030407@gmail.com>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
	<47c890dc0808262031w239e62fetc74d4c1e1be25873@mail.gmail.com>
	<47c890dc0808262239k202e79a4q364b98be387ea5b0@mail.gmail.com>
	<3cadf8630808270929l33d451edwd1497a8cb1b1bde0@mail.gmail.com>
	<bbaeab100808271101i59e7a92ai6cea3a92b53df60f@mail.gmail.com>
	<47c890dc0808271125u1ae7f9abu5727cf267fc3e56@mail.gmail.com>
	<48B5C6AB.9030407@gmail.com>
Message-ID: <e8a0972d0808271901x63921a51w73de102ab14964bb@mail.gmail.com>

On Wed, Aug 27, 2008 at 2:27 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
   ...
> Late binding default arguments would do some fairly bad things to nested
> functions such as preventing the use of class attributes when defining

They'd also be SERIOUSLY problematic wrt a VERY common issue -- one
that I had an excellent and Python-experienced colleague ask me about
just the other day as we were waiting for a meeting room to actually
get free for a meeting we were both at -- rephrasing and summarizing,
his problem was like:

for text, command in zip(labels, commands):
  makebutton(text, lambda evt: command)

and the LAST command was being bound to all buttons (of course).  With
current semantics I was able to give him the solution instantly (while
others were still streaming out of the conference room;-):

for text, command in zip(labels, commands):
  makebutton(text, lambda evt, command=command: command)

If default args were late-bound, I'd have to offer exclusively the
more-complex "closure" approach:

def makecommand(command):
    def doit(evt): return command()
    return doit
for text, command in zip(labels, commands):
  makebutton(text, makecommand(command))

which -- while I personally prefer it -- is _definitely_
heavier-weight.  This issue does happen A LOT: I even saw it
highlighted in a popular text on Javascript (so, it's not even a
Python-only one;-).


Alex

From mwm at mired.org  Wed Aug 27 18:11:42 2008
From: mwm at mired.org (Mike Meyer)
Date: Wed, 27 Aug 2008 12:11:42 -0400
Subject: [Python-3000] else Versus or (Was: Re: default argument
 surprises)
In-Reply-To: <48B4E304.7090706@swarthmore.edu>
References: <3cadf8630808262021w720ca61dn7cd10ac1027bfa9c@mail.gmail.com>
	<cf5b87740808262110v469e8d78td495551def09c2b2@mail.gmail.com>
	<da3f900e0808262114q687d60deje1f1880f28c72570@mail.gmail.com>
	<48B4E304.7090706@swarthmore.edu>
Message-ID: <20080827121142.42eb8cbd@mbook.mired.org>

On Wed, 27 Aug 2008 01:15:48 -0400 Eric Astor <eastor1 at swarthmore.edu> wrote:
> True, but 'else' can be a more specific operator, so that
> >>> arg = arg else bar
> is equivalent to:
> >>> if arg is None: arg = bar,

Yes, but only because you used arg twice. Dealing with the general
case clarifies things a little:

>>> arg = bar else foo
which is equivalent to
>>> arg = bar if bar is not None else foo

whereas your original will skip the assignment to arg if bar were not
None. Your proposed semantics have the "else" keyword change the
behavior of the assignment statement, which I suspect is unintended.

> where
> >>> arg = arg or bar
> is instead equivalent to:
> >>> if not arg: arg = b

Again, you've hidden part of the semantics by using arg twice. I
believe you want:

>>> arg = bar or foo
which is equivalent to
>>> arg = bar if bar else foo

In short, this change would only be useful in cases where a variable
has a default value of None, and you want to change that default value
to something other than None if it's not None. Which pretty much
limits it to dealing with arguments (otherwise we don't have a default
value) whose default value is a mutable object (otherwise we just use
the value we really want as the default) you're going to change
(otherwise, we just use the value we really want as the default) that
can evaluate to false under some conditions (otherwise, we could use
the "or" variant).

That seems to be a thin use case for a change that will generally only
affect a single line of code.

       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

From 4vinoth at gmail.com  Fri Aug 29 09:39:28 2008
From: 4vinoth at gmail.com (vin vin)
Date: Fri, 29 Aug 2008 13:09:28 +0530
Subject: [Python-3000] Nettri! The Open Source Python Web Application
	Platform
Message-ID: <6176a14d0808290039xdc7ebf8tec619224696c46b0@mail.gmail.com>

 Nettri! The Open Source Python Web Application Platform

*Welcome to Nettri*

HI Friends

I am (*Vinoth*) very Glad to announce you the Development of *Nettri* an *Open
Source Project for Python Web Application Platform*. Currently I am only the
Developer. Sure I'll not wait for others to join, But I would like to give
you all the Great Solution for Free and like to see *Nettri* as the Best
Solution for Python Guys.

*First Release?*

Soon. Once the Python 3 is on the playground. Because I have started *Nettri
* in Python 3.

*Like to Contribute?*

You are welcome to Join *Nettri* as a Contributor. Please contact me

*Seeing Drupal?*

:) Currently I am using Drupal to build this simple site, as I am Drupal
Developer :), But we can convert this site to *Nettri* once *Nettri* is
Released.

*Advice me!*
* I don't have much experience in Open Source Projects. Your Advice is
Greatly welcome.mainly regarding license, etc.*

*Donations?*
First I would like to have your great experience on Nettri by first release.
Then, Yes, we should build our own community for Netttri. :)

Hope You got a Good news Today.

Cheers.
*Vinoth*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080829/3d2e449f/attachment.htm>

From 4vinoth at gmail.com  Fri Aug 29 09:40:46 2008
From: 4vinoth at gmail.com (vin vin)
Date: Fri, 29 Aug 2008 13:10:46 +0530
Subject: [Python-3000] Nettri! The Open Source Python Web Application
	Platform
In-Reply-To: <6176a14d0808290039xdc7ebf8tec619224696c46b0@mail.gmail.com>
References: <6176a14d0808290039xdc7ebf8tec619224696c46b0@mail.gmail.com>
Message-ID: <6176a14d0808290040u54a641aar7244300ad7774d8e@mail.gmail.com>

Ah,,

Forgot to tell..

*nettri.org *

will be the official website of Nettri.

On Fri, Aug 29, 2008 at 1:09 PM, vin vin <4vinoth at gmail.com> wrote:

> Nettri! The Open Source Python Web Application Platform
>
> *Welcome to Nettri*
>
> HI Friends
>
> I am (*Vinoth*) very Glad to announce you the Development of *Nettri* an *Open
> Source Project for Python Web Application Platform*. Currently I am only
> the Developer. Sure I'll not wait for others to join, But I would like to
> give you all the Great Solution for Free and like to see *Nettri* as the
> Best Solution for Python Guys.
>
> *First Release?*
>
> Soon. Once the Python 3 is on the playground. Because I have started *
> Nettri* in Python 3.
>
> *Like to Contribute?*
>
> You are welcome to Join *Nettri* as a Contributor. Please contact me
>
> *Seeing Drupal?*
>
> :) Currently I am using Drupal to build this simple site, as I am Drupal
> Developer :), But we can convert this site to *Nettri* once *Nettri* is
> Released.
>
> *Advice me!*
> * I don't have much experience in Open Source Projects. Your Advice is
> Greatly welcome.mainly regarding license, etc.*
>
> *Donations?*
> First I would like to have your great experience on Nettri by first
> release. Then, Yes, we should build our own community for Netttri. :)
>
> Hope You got a Good news Today.
>
> Cheers.
> *Vinoth*
>



-- 
vin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080829/5f2f020c/attachment.htm>

From orsenthil at gmail.com  Fri Aug 29 11:23:43 2008
From: orsenthil at gmail.com (O.R.Senthil Kumaran)
Date: Fri, 29 Aug 2008 14:53:43 +0530
Subject: [Python-3000] Nettri! The Open Source Python Web
	Application	Platform
Message-ID: <20080829092343.GA5741@gmail.com>

Hello Vinoth,

Your broadcast was no better than a SPAM. This list is for discussing Python 3K
efforts.

python-announce list is better place when you have the finished product.
python-list would be the place where you can seek guidance.

Let us stop the thread here.

Thanks,
Senthil

* scriptor vin vin, explico 

> Ah,,
> 
> Forgot to tell..
> 
> *nettri.org *
> 
> will be the official website of Nettri.
> 
> On Fri, Aug 29, 2008 at 1:09 PM, vin vin <4vinoth at gmail.com> wrote:
> 
> > Nettri! The Open Source Python Web Application Platform
> >
> > *Welcome to Nettri*
> >
> > HI Friends
> >
> > I am (*Vinoth*) very Glad to announce you the Development of *Nettri* an *Open
> > Source Project for Python Web Application Platform*. Currently I am only
> > the Developer. Sure I'll not wait for others to join, But I would like to
> > give you all the Great Solution for Free and like to see *Nettri* as the
> > Best Solution for Python Guys.
> >
> > *First Release?*
> >
> > Soon. Once the Python 3 is on the playground. Because I have started *
> > Nettri* in Python 3.
> >
> > *Like to Contribute?*
> >
> > You are welcome to Join *Nettri* as a Contributor. Please contact me
> >
> > *Seeing Drupal?*
> >
> > :) Currently I am using Drupal to build this simple site, as I am Drupal
> > Developer :), But we can convert this site to *Nettri* once *Nettri* is
> > Released.
> >
> > *Advice me!*
> > * I don't have much experience in Open Source Projects. Your Advice is
> > Greatly welcome.mainly regarding license, etc.*
> >
> > *Donations?*
> > First I would like to have your great experience on Nettri by first
> > release. Then, Yes, we should build our own community for Netttri. :)
> >
> > Hope You got a Good news Today.
> >
> > Cheers.
> > *Vinoth*
> >
> 
> 
> 
> -- 
> vin

> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/orsenthil%40gmail.com


-- 
O.R.Senthil Kumaran
http://uthcode.sarovar.org

From stefan_ml at behnel.de  Fri Aug 29 11:37:47 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 29 Aug 2008 11:37:47 +0200
Subject: [Python-3000] XML as bytes or unicode?
In-Reply-To: <48B5F59E.8060104@canterbury.ac.nz>
References: <ffb592890808171040g5db8f25flb9a1222f40364760@mail.gmail.com>	<bbaeab100808171209q7b29fff0pa585c02e0c95053a@mail.gmail.com>	<loom.20080818T162617-305@post.gmane.org>	<1afaf6160808180935k3470efc0n65c318b87d54a99@mail.gmail.com>	<loom.20080818T164216-491@post.gmane.org>	<bbaeab100808181029w1eb1051fp9aecf0c6e239a818@mail.gmail.com>	<48B24525.3080808@v.loewis.de>	<ca471dc20808250923h39fd06bei16c71508e391610f@mail.gmail.com>	<g942uu$2mb$1@ger.gmane.org>
	<48B5F59E.8060104@canterbury.ac.nz>
Message-ID: <g98g1b$d80$1@ger.gmane.org>

Greg Ewing wrote:
> Stefan Behnel wrote:
> 
>> In the absence of information provided by an external transport
>> protocol (e.g.
>> HTTP or MIME), it is a fatal error for an entity including an encoding
>> declaration to be presented to the XML processor in an encoding other
>> than
>> that named in the declaration [...]
> 
> But if the XML has already been decoded and turned into
> a Python unicode string, there *is* external information
> about the encoding -- we know it's encoded however Python
> represents unicode internally. So this clause doesn't
> apply.

Correct. That's exactly what I was indicating.

Stefan


From python-3000-list at trentnelson.com  Fri Aug 29 13:30:08 2008
From: python-3000-list at trentnelson.com (Trent Nelson)
Date: Fri, 29 Aug 2008 11:30:08 +0000
Subject: [Python-3000] what version of bsddb to use/accept for 2.6/3.0
In-Reply-To: <ee2a432c0808241815n57de2264o2c958327968673da@mail.gmail.com>
References: <ee2a432c0808241815n57de2264o2c958327968673da@mail.gmail.com>
Message-ID: <20080829113008.GA29787@wind.teleri.net>

On Sun, Aug 24, 2008 at 06:15:06PM -0700, Neal Norwitz wrote:
> It looks like the WIndows buildbots use 4.4.20.  Unfortunately, the
> Windows bots aren't in great shape either.
    
    It won't be that hard to bump 3.0 on Windows to use 4.7 (assuming
    that the 3.0 bsddb codebase has Jesus's new code).  I'll be able
    to take a look at this early next week.

        Trent.

From pyry.pakkanen at gmail.com  Fri Aug 29 15:23:33 2008
From: pyry.pakkanen at gmail.com (Pyry Pakkanen)
Date: Fri, 29 Aug 2008 16:23:33 +0300
Subject: [Python-3000] bytearray incompatible with bytes
Message-ID: <4be695f60808290623l3db1b0f0ve3cf542553c96811@mail.gmail.com>

Hello list! First post.

I ran in to this problem with ossaudiodev module when trying to copy
the input audio to output:

import ossaudiodev
dev = ossaudiodev.open("rw")
dev.setparameters(ossaudiodev.AFMT_S16_NE,2,44100)
for i in range(1000): #Copy audio from input to output for a few seconds
    dev.write(dev.read(1024))

It runs fine in 2.5 but in 3.0b3 it gives the following exception:
Traceback (most recent call last):
  File "myscripts/ossthrough.py", line 5, in <module>
    dev.write(dev.read(1024))
TypeError: write() argument 1 must be bytes or read-only buffer, not bytearray

This looks like a bug. I thought bytearray is a read-only buffer.

Looking at the ossaudiodev.c source it seems that
PyArg_ParseTuple(args, "y#:write", &cp, &size) doesn't accept
bytearrays.

-Pyry Pakkanen

From 4vinoth at gmail.com  Fri Aug 29 15:25:44 2008
From: 4vinoth at gmail.com (vin vin)
Date: Fri, 29 Aug 2008 18:55:44 +0530
Subject: [Python-3000] Nettri! The Open Source Python Web Application
	Platform
In-Reply-To: <20080829092343.GA5741@gmail.com>
References: <20080829092343.GA5741@gmail.com>
Message-ID: <6176a14d0808290625w461bef3dke3b2224e38f557f@mail.gmail.com>

Thank you Senthil for your Advice.

First let me complete the solution. :)

sorry for overtaking
-- 
Vinoth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080829/1f46eeea/attachment.htm>

From aahz at pythoncraft.com  Fri Aug 29 15:40:01 2008
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 29 Aug 2008 06:40:01 -0700
Subject: [Python-3000] bytearray incompatible with bytes
In-Reply-To: <4be695f60808290623l3db1b0f0ve3cf542553c96811@mail.gmail.com>
References: <4be695f60808290623l3db1b0f0ve3cf542553c96811@mail.gmail.com>
Message-ID: <20080829134001.GA911@panix.com>

On Fri, Aug 29, 2008, Pyry Pakkanen wrote:
> 
> It runs fine in 2.5 but in 3.0b3 it gives the following exception:
> Traceback (most recent call last):
>   File "myscripts/ossthrough.py", line 5, in <module>
>     dev.write(dev.read(1024))
> TypeError: write() argument 1 must be bytes or read-only buffer, not bytearray
> 
> This looks like a bug. I thought bytearray is a read-only buffer.
> 
> Looking at the ossaudiodev.c source it seems that
> PyArg_ParseTuple(args, "y#:write", &cp, &size) doesn't accept
> bytearrays.

Please file a report on bugs.python.org -- that's the only way we have to
track things.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!

From guido at python.org  Fri Aug 29 18:20:16 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 29 Aug 2008 09:20:16 -0700
Subject: [Python-3000] bytearray incompatible with bytes
In-Reply-To: <4be695f60808290623l3db1b0f0ve3cf542553c96811@mail.gmail.com>
References: <4be695f60808290623l3db1b0f0ve3cf542553c96811@mail.gmail.com>
Message-ID: <ca471dc20808290920g4fc7b138gd406ee4819096d5f@mail.gmail.com>

2008/8/29 Pyry Pakkanen <pyry.pakkanen at gmail.com>:
> Hello list! First post.

Welcome!

> I ran in to this problem with ossaudiodev module when trying to copy
> the input audio to output:
>
> import ossaudiodev
> dev = ossaudiodev.open("rw")
> dev.setparameters(ossaudiodev.AFMT_S16_NE,2,44100)
> for i in range(1000): #Copy audio from input to output for a few seconds
>    dev.write(dev.read(1024))
>
> It runs fine in 2.5 but in 3.0b3 it gives the following exception:
> Traceback (most recent call last):
>  File "myscripts/ossthrough.py", line 5, in <module>
>    dev.write(dev.read(1024))
> TypeError: write() argument 1 must be bytes or read-only buffer, not bytearray
>
> This looks like a bug. I thought bytearray is a read-only buffer.
>
> Looking at the ossaudiodev.c source it seems that
> PyArg_ParseTuple(args, "y#:write", &cp, &size) doesn't accept
> bytearrays.

There are two separate bugs here: it's true that dev.write() should
accept a bytearray instance, but dev.read() should have returned
bytes.

And yes, Aahz is right, please take a minute to register with
bugs.python.org and file a bug.

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

From hagenf at coli.uni-saarland.de  Sat Aug 30 17:07:40 2008
From: hagenf at coli.uni-saarland.de (=?UTF-8?Q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 30 Aug 2008 16:07:40 +0100
Subject: [Python-3000] Should len() clip to sys.maxsize or raise
	OverflowError?
Message-ID: <33965e610808300807t3dc7eb1es44a29afd2afcd56f@mail.gmail.com>

While __len__() is allowed to return a value of any size, issues 2723
and 3729 need a decision on what len() should do if the value doesn't
fit in a Py_ssize_t.

In a previous thread
(http://mail.python.org/pipermail/python-3000/2008-May/013387.html)
Guido wanted len() to "lie" and return sys.maxsize in this case, but
several people have voiced strong discomfort with that. Any comments
or pronouncements?

From leif.walsh at gmail.com  Sat Aug 30 23:17:22 2008
From: leif.walsh at gmail.com (Leif Walsh)
Date: Sat, 30 Aug 2008 17:17:22 -0400
Subject: [Python-3000] Should len() clip to sys.maxsize or raise
	OverflowError?
In-Reply-To: <33965e610808300807t3dc7eb1es44a29afd2afcd56f@mail.gmail.com>
References: <33965e610808300807t3dc7eb1es44a29afd2afcd56f@mail.gmail.com>
Message-ID: <cc7430500808301417o53447639m9c3c3746466dde1d@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Aug 30, 2008 at 11:07 AM, Hagen F?rstenau  wrote:
> While __len__() is allowed to return a value of any size, issues 2723
> and 3729 need a decision on what len() should do if the value doesn't
> fit in a Py_ssize_t.
>
> In a previous thread
> (http://mail.python.org/pipermail/python-3000/2008-May/013387.html)
> Guido wanted len() to "lie" and return sys.maxsize in this case, but
> several people have voiced strong discomfort with that. Any comments
> or pronouncements?

I didn't read the whole thread, but I did like the idea of using
returning sys.maxsize for __length_hint__, and not __length__.

That said, knowingly returning an incorrect value for __len__ sounds
awful.  I'd much prefer the OverflowError (which would let me catch it
and use sys.maxsize if I wanted, anyway), and would make the point
that many things in the Java world (for example, fallacious functions
being called 'practical') are good examples of Evil.

- --
Cheers,
Leif


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAki5uOIACgkQfBqXGvVwnEluKQCfWWC0R6kXH8z/GqmW5/hORLjK
mBAAni4OdgPhnlGxvBLtZmtt/L2d6SbA
=AEeb
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Sun Aug 31 14:56:15 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 31 Aug 2008 12:56:15 +0000 (UTC)
Subject: [Python-3000] 3.0: smaller than 2.6
Message-ID: <loom.20080831T121537-844@post.gmane.org>


Hi,

Just a bunch of simple statistics between the current py3k branch and the trunk.
Compilation was done with all default values (bare "./configure") on a Linux
machine with gcc, in non-debug mode.

The fact that 3.0 is measurably smaller than 2.6 (for various meanings of the
"size" metric) is not a surprise in itself, but still interesting to verify and
quantify.

Compilation time ("time make")
------------------------------

* 2.6:
153.68user 9.06system 2:52.91elapsed 94%CPU
* 3.0:
141.31user 7.99system 2:41.93elapsed 92%CPU

Object code size ("size python")
--------------------------------

The 3.0 executable has ~70KB less object code (for a total of ~1MB object code).

* 2.6:
   text	   data	    bss	    dec	    hex	filename
1177856	 170508	  37428	1385792	 152540	python
* 3.0:
   text	   data	    bss	    dec	    hex	filename
1103421	 164000	  93584	1361005	 14c46d	python

Executable size ("strip python && ls -sk python")
-------------------------------------------------

Here is the size of the executable in kilobytes. Dependent libraries ("ldd
python") are the same for both.

* 2.6:
1328 python*
* 3.0:
1252 python*

Runtime size of the interpreter
-------------------------------

I launch the interactive interpreter and then launch a pystone run (by typing
"from test import pystone; pystone.main()" at the prompt). Launching pystone is
just an easy way of "doing something" from the command-line, to ensure that the
necessary basic stuff is loaded and initialized. At the end of the pystone run,
I run "ps aux" and note the memory consumption values.

It is not obvious to interpret these numbers, and more meaningful workloads
would probably show 3.0 taking more memory than 2.6, due to strings being
unicode by default.

* 2.6 ("./python -E"):
VSZ=6292, RSS=4328
* 3.0 ("./python -E"):
VSZ=6876, RSS=4132

* 2.6 ("./python -E -OO"):
VSZ=6240, RSS=4252
* 3.0 ("./python -E -OO"):
VSZ=6712, RSS=3948

(the numbers are collected after a second run, so there is no bytecode
compilation phase)

Number of code lines ("make distclean && sloccount .")
------------------------------------------------------

3.0 is smaller by 25% (a massive 180000 lines of code have been removed, 70000
of which in the Mac directory which has become almost empty).

* 2.6:

SLOC	Directory	SLOC-by-Language (Sorted)
294958  Lib             python=294883,sh=75
204473  Modules         ansic=190682,asm=9565,sh=3927,python=299
91268   Mac             ansic=77313,python=13090,objc=756,sh=109
56952   Objects         ansic=56952
36698   Python          ansic=36698
29763   Tools           python=29660,ansic=67,sh=36
18351   Demo            python=17987,ansic=360,sh=4
8927    PC              ansic=8320,python=607
5935    Include         ansic=5935
5782    Parser          ansic=3926,python=1856
3802    Misc            lisp=2933,python=595,sh=175,ansic=99
2729    Doc             python=1947,ansic=782
2071    RISCOS          ansic=2071
1408    top_dir         python=1239,sh=169
351     PCbuild         python=281,ansic=70
0       Grammar         (none)


Totals grouped by language (dominant language first):
ansic:       383275 (50.20%)
python:      362444 (47.47%)
asm:           9565 (1.25%)
sh:            4495 (0.59%)
lisp:          2933 (0.38%)
objc:           756 (0.10%)

* 3.0:

SLOC	Directory	SLOC-by-Language (Sorted)
241350  Lib             python=241305,sh=45
179281  Modules         ansic=165789,asm=9565,sh=3927
50523   Objects         ansic=50523
36196   Python          ansic=36196
26791   Tools           python=26688,ansic=67,sh=36
18269   Demo            python=17905,ansic=360,sh=4
8923    PC              ansic=8316,python=607
5747    Parser          ansic=3881,python=1866
5623    Include         ansic=5623
3517    Misc            lisp=2948,python=293,sh=177,ansic=99
2728    Doc             python=1946,ansic=782
2368    Mac             python=1495,objc=756,sh=109,ansic=8
1351    top_dir         python=1112,sh=239
351     PCbuild         python=281,ansic=70
0       Grammar         (none)


Totals grouped by language (dominant language first):
python:      293498 (50.34%)
ansic:       271714 (46.60%)
asm:           9565 (1.64%)
sh:            4537 (0.78%)
lisp:          2948 (0.51%)
objc:           756 (0.13%)



From jcea at jcea.es  Sun Aug 31 16:43:34 2008
From: jcea at jcea.es (Jesus Cea)
Date: Sun, 31 Aug 2008 16:43:34 +0200
Subject: [Python-3000] Email update
Message-ID: <48BAAE16.9010200@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm getting some private email about python issues in "jcea at argo.es".
This email address works for now, but it is "deprecated". My current
email is "jcea at jcea.es". Please, update your addressbooks, and any
list/contact info out there.

I already updated my mailman subscriptions months ago. My old email can
vanish without warning.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSLquCZlgi5GaxT1NAQKQRwP/fI7xR3O87aPRSunGIibVqLEAwiSczc8N
diWZ2QxSmr2GnL7tDWXU9B/ROxuFL3Rhti21T/BfLDDPn5pi9YmwVkKji4Jt+v1L
UROgaJ5nnv1CBiLvKPDSkIoHoFKa4Gx1hIWihEy6Oed8mA8qKP+rm0tX0NfWJaRo
ofEja3FooDs=
=wYIM
-----END PGP SIGNATURE-----

From jcea at jcea.es  Sun Aug 31 16:46:45 2008
From: jcea at jcea.es (Jesus Cea)
Date: Sun, 31 Aug 2008 16:46:45 +0200
Subject: [Python-3000] bsddb landing in py3k branch
Message-ID: <48BAAED5.9070302@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm still basically offline, working via a 9600 bps connection. I will
be "fully functional" late this week, back in Madrid. Too late for rc1,
I think.

I just committed bsddb 4.7.3pre2 to py3k. I need somebody that updates
"Lib/test/test_bsddb3.py" to make it equivalent to Python 2.6 one. The
code is short, maybe a simple "2to3" operation would be enough. I can't
do it because my online connection is marginal and I can't test
python3000 code at this moment. Please, confirm.

Important details:

* bsddb Python 3000 svn work is "lost". In particular, the "buffer"
code. This issue was already discussed here. My point is that bsddb is
big and complex, and I need to keep a single/unified Python 2.x/3.x
codebase to be able to cope with it. I will study your buffer efforts
eventually, nevertheless.

* All python code in bsddb in written in Python 2.x style. Python 3 code
is generated via "2to3". Please, do not update Python3 code directly.
The canonical version IS the 2.x code!.

* You will see conditional code and some ugliness . This will be
improved in the future. Just remember that this code MUST work in Python
2.3, 2.4, 2.5, 2.6 and 3.0. The very same code (via "2to3").

* The bytes/unicode dicotomy in Python 3.0 will be improved in future
releases of bsddb, in a compatible way (so, new code will be more
elegant, and old code will work without changes). I have already plans
for bsddb 4.7.4 and 4.7.5. Python3.0 cutoff is too close to improve this
just now. Be patient. In any case, current code is fully functional;
just beware with Unicode/Bytes mixes.

* Precompiled binaries distributed via Python.org SHOULD use Berkeley DB
4.7 (current version: 4.7.25). I guess we should update some buildbots,
also... (I already test the code privately against all Berkeley DB
versions 4.0-4.7).

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSLqu1Jlgi5GaxT1NAQJxGAP/QlZ39BE1kWAXDXECXvkLlBAVOQfdF5nk
fno+sA+rUSPES19CBxWhvEqoLzT8NS9JKuIU/treKfbcMv8BmPkqqsu2GLI8FXD4
uPCKcABOFHmszkT4+/VFjJVPq+GQXNkw8Gf6SlIgTeQ+exIwxUaGg85aMzfkylfD
XY1mJu2L2R0=
=aK7S
-----END PGP SIGNATURE-----