From rhamph at gmail.com  Sun Jun  1 00:28:15 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Sat, 31 May 2008 16:28:15 -0600
Subject: [Python-3000] sys.exc_info()
In-Reply-To: <loom.20080531T195123-123@post.gmane.org>
References: <loom.20080526T091655-961@post.gmane.org>
	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>
	<loom.20080531T012237-406@post.gmane.org>
	<aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com>
	<003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
	<aac2c7cb0805311024mb699d8euf6a896909051dfb5@mail.gmail.com>
	<loom.20080531T173224-563@post.gmane.org>
	<aac2c7cb0805311235x31ac0151p45fe58cd2e879c99@mail.gmail.com>
	<loom.20080531T195123-123@post.gmane.org>
Message-ID: <aac2c7cb0805311528l4a9f0de9y79b59e7aa1eadc61@mail.gmail.com>

On Sat, May 31, 2008 at 2:03 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Adam Olsen <rhamph <at> gmail.com> writes:
>>
>> The bytecode generation for "raise" could be changed literally be the
>> same as "except Foo as e: raise e".  Reuse our existing stack, not add
>> another one.
>
> As someone else pointed, there is a difference between the two constructs: the
> latter appends a line to the traceback while the former doesn't. I suppose in
> some contexts it can be useful (especially if the exception is re-raised several
> times because of a complex architecture, e.g. a framework).

Yeah.  If anything it seems like a positive, not a negative.


>> The commented out raise should use the outer except block (and thus be
>> lexically based), but sys.exc_info() doesn't have to be.
>
> But would you object to sys.exc_info() being lexically based as well?
> I say that because the bare "raise" statement and sys.exc_info() use the same
> attributes internally, so they will have the same semantics unless we decide
> it's better to do otherwise.

I'm trying to eliminate complexity, paring it down to the bare minimum
of supported functionality.  However, I was also confusing
sys.exc_info() with sys.last_*.  That leads to another thought..


>> > Also, "yield" cannot blindingly clear the exception state, because the frame
>> > calling the generator may except the exception state to be non-None.
>> > Consequently, we might have to keep the f_exc_* members solely for the
>> > generator case.
>>
>> Why?  Why should the frame calling the generator be inspecting the
>> exception state of the generator?  What's the use case?
>
> You misunderstood me. The f_exc_* fields will be used internally to swap between
> the inner generator's exception state and the calling frame's own exception
> state. They will have no useful meaning for outside code so I suggest they are
> not accessible from Python code anymore.

Why not move f_exc_* into the PyTryBlock struct?  We can eliminate the
per-thread exception and have sys.exc_info() search the stack for an
active except block.  No need to swap anything because the stack is
always current.

(tstate->curexc_* would be unchanged of course, as it represents the
"hot" exception, not the last caught exception.)


-- 
Adam Olsen, aka Rhamphoryncus

From timothy.c.delaney at gmail.com  Sun Jun  1 00:42:19 2008
From: timothy.c.delaney at gmail.com (Tim Delaney)
Date: Sun, 1 Jun 2008 08:42:19 +1000
Subject: [Python-3000] sys.exc_info()
References: <loom.20080526T091655-961@post.gmane.org>	<loom.20080530T094609-317@post.gmane.org>	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>	<loom.20080531T012237-406@post.gmane.org><aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com><003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
Message-ID: <B4AA5F22A030498192994F8C4D6CA856@ryoko>

Antoine Pitrou <solipsis at pitrou.net> wrote:

> sys.exc_info() will remain, it's just that the returned value will be
> (None, None, None) if we are not in an except block in any of the
> currently active frames in the thread. In the case above it would
> return the current exception (the one caught in one of the enclosing
> frames).

This reminds me of something I've thought a few times - maybe the tuple 
returned from sys.exc_info() should be a named tuple.

Tim Delaney 


From solipsis at pitrou.net  Sun Jun  1 00:52:51 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 31 May 2008 22:52:51 +0000 (UTC)
Subject: [Python-3000] =?utf-8?b?c3lzLmV4Y19pbmZvKCk=?=
References: <loom.20080526T091655-961@post.gmane.org>
	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>
	<loom.20080531T012237-406@post.gmane.org>
	<aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com>
	<003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
	<aac2c7cb0805311024mb699d8euf6a896909051dfb5@mail.gmail.com>
	<loom.20080531T173224-563@post.gmane.org>
	<aac2c7cb0805311235x31ac0151p45fe58cd2e879c99@mail.gmail.com>
	<loom.20080531T195123-123@post.gmane.org>
	<aac2c7cb0805311528l4a9f0de9y79b59e7aa1eadc61@mail.gmail.com>
Message-ID: <loom.20080531T224927-447@post.gmane.org>


Hello again,

> Why not move f_exc_* into the PyTryBlock struct?  We can eliminate the
> per-thread exception and have sys.exc_info() search the stack for an
> active except block.  No need to swap anything because the stack is
> always current.

Yes it's a possible implementation. At the expense of a performance hit for
operations which currently use tstate->exc_* (sys.exc_info() itself, bare
"raise"...).

Right now I have a patch using my original implementation proposal. I'll post it
soon.

regards

Antoine.



From tjreedy at udel.edu  Sun Jun  1 01:29:47 2008
From: tjreedy at udel.edu (tjreedy)
Date: Sat, 31 May 2008 19:29:47 -0400
Subject: [Python-3000] [Python-Dev] Finishing up PEP 3108
References: <bbaeab100805282138x5ccac2d8q100fa0e969828bb4@mail.gmail.com>	<g1ll0v$i0p$1@ger.gmane.org><bbaeab100805291032v7749ba6n1752a0ef5be9cbca@mail.gmail.com>
	<g1rr4o$956$1@ger.gmane.org>
Message-ID: <g1sn4h$il6$1@ger.gmane.org>


"Georg Brandl" <g.brandl at gmx.net> wrote in message 
news:g1rr4o$956$1 at ger.gmane.org...
> Of course, it would also be nice for ``help("if")`` to work effortlessly,
> which it currently only does if the generated HTML documentation is
> available somewhere, which it typically isn't -- on Unix most 
> distributions
> put it in a separate package (from which pydoc won't always find it
> of its own), on Windows only the CHM file is distributed and must be
> decompiled to get single HTML files.

For 3.0a5, it does not work even after decompiling (and setting the ENV var) 
as given in the instructions (which are inadequate for many users anyway).




From wescpy at gmail.com  Sun Jun  1 01:41:38 2008
From: wescpy at gmail.com (wesley chun)
Date: Sat, 31 May 2008 16:41:38 -0700
Subject: [Python-3000] PEP 3101 str.format() equivalent of '%#o/x/X'?
In-Reply-To: <ca471dc20805301237p4a30dd5du4f3ecb2771a967ca@mail.gmail.com>
References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4@mail.gmail.com>
	<483EAF95.5050503@trueblade.com>
	<3f4107910805291116w37af38e3qb2c5145539d7e23e@mail.gmail.com>
	<483F06FF.9090007@trueblade.com>
	<78b3a9580805291634t3ed65ab3x29bedc80be887f8@mail.gmail.com>
	<483F4E3A.9090403@trueblade.com>
	<ca471dc20805301209j67c3e2a5nf819297680cbf3fb@mail.gmail.com>
	<48405420.8010800@trueblade.com>
	<ca471dc20805301237p4a30dd5du4f3ecb2771a967ca@mail.gmail.com>
Message-ID: <78b3a9580805311641ob06e7faw80c9d5e41e7e64fe@mail.gmail.com>

>>> I'd be fine with adding '#' back to the formatting language for hex and oct.
>>
>> And bin, I assume?
>
> Of course.


somewhat on-topic, can i hear from some of you as far as use-cases for
oct() and hex() [plus bin()] in Python code?  i find "%x" or "%o" (and
its variants) sufficient in serving my needs.  in other words, why
oct() and hex() built-in functions instead of elsewhere like in
operator for those who desire a functional interface?

another related inquiry, if we're going to have hex(), can its
signature be expanded to include "%#X" functionality, i.e.,
hex(number, cap=False), as the default and someone who wants the "#"
can do hex(123, cap=True)? on top of that, can hex() also support "%x"
and '%X' functionality, i.e., hex(number, cap=False, leading=True), as
the default, so i can do hex(123, leading=False) for '7b'? do you see
how i'm trying to make life difficult and lead people down the path of
not having hex(), oct(), or bin()? or are those three functions
intended to obsolete "#"? :-)

writing this message made me realize that i could have just done the
following in my original post that started this whole thread:

>>> i = 45
>>> 'dec: {0}/oct: {1}/hex: {2}'.format(i, oct(i), hex(i))
'dec: 45/oct: 0o55/hex: 0x2d'

it's definitely better than the "uglier" code in that post although
this is less elegant than being able to specify the variable 'i' just
once.

cheers,
-- wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python Programming", Prentice Hall, (c)2007,2001
 http://corepython.com

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

From mhammond at skippinet.com.au  Sun Jun  1 03:08:15 2008
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 1 Jun 2008 11:08:15 +1000
Subject: [Python-3000] sys.exc_info()
In-Reply-To: <loom.20080531T131423-489@post.gmane.org>
References: <loom.20080526T091655-961@post.gmane.org>	<loom.20080530T094609-317@post.gmane.org>	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>	<loom.20080531T012237-406@post.gmane.org>	<aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com>	<003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
Message-ID: <00ab01c8c383$fb909db0$f2b1d910$@com.au>

Antoine:
> Mark Hammond <mhammond <at> skippinet.com.au> writes:
> > In both Python 2.x and 3 (a few months old build of Py3k though), the
> > traceback isn't the same.  For Python 2.0 you could write it like:
> >
> > def handle_exception():
> > ...
> >     raise sys.exc_info()[0], sys.exc_info()[1], sys.exc_info()[2]
> >
> > Its not clear how that would be spelt in py3k though (and from what I
> can
> > see, sys.exc_info() itself has an uncertain future in py3k).
> 
> sys.exc_info() will remain, it's just that the returned value will be
> (None, None, None) if we are not in an except block in any of the 
> currently active frames in the thread.

If I look at Guido's py3k status update of almost a year ago
(http://www.artima.com/weblogs/viewpost.jsp?thread=208549) it tells me:

* "sys.exc_info() becomes redundant (or may disappear)".  Even if it doesn't
actually dissappear, the implication is that the new way (with the traceback
being an attribute) will be preferred.

* "The old raise syntax variants raise E, e and raise E, e, tb are gone" -
but I can't see anything which indicates what the replacement is for the 2
cases of (a) raising with the original traceback and (b) raising the same
exception with a "new" traceback reflecting the position of the 'raise'-
I admit I didn't look *that* hard though...

Mark


From guido at python.org  Sun Jun  1 03:49:22 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 31 May 2008 18:49:22 -0700
Subject: [Python-3000] doctest portability
In-Reply-To: <g1rrtq$aoe$1@ger.gmane.org>
References: <g1rk9q$lti$1@ger.gmane.org> <g1rpv7$5mp$1@ger.gmane.org>
	<g1rrtq$aoe$1@ger.gmane.org>
Message-ID: <ca471dc20805311849h6e14e740ye238d1984e221ed9@mail.gmail.com>

2to3 lets you specify exactly which fixers to run with the -f command line flag.

I really don't like the idea of having Py3k code with doctests written
in a dialect of Py2k...

--Guido

On Sat, May 31, 2008 at 8:47 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Georg Brandl wrote:
>> Stefan Behnel schrieb:
>>> I know, I could use the lib2to3 package, but it a) is a one-way tool
>>> in the
>>> wrong direction if you have to distinguish bytes/str literals, b) lacks
>>> configurability stating exactly what changes need to be done and c)
>>> seemed
>>> harder to set up for doctests than doing the conversion by hand.
>>
>> Shouldn't the -d option handle doctests without further set-up?
>
> If you start 2to3 from the command prompt to convert the files that contain
> the doctests and copy them to a new location, then yes. But the question is:
> how do you run a Py2 doctest in Py3 without first copying your doctests or
> doctest containing sources to new files and then running the tests from there?
> You can't require people to put such a work-around into every test script in
> the world. Adding an option, fine. Copying files, adapting paths and all that,
> why?
>
> 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/guido%40python.org
>



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

From guido at python.org  Sun Jun  1 03:50:40 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 31 May 2008 18:50:40 -0700
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <aac2c7cb0805311433q58a3e17ajd17e8debba10ca28@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<fb6fbf560805261806j7b79e776i3361a655ac1d8a36@mail.gmail.com>
	<797440730805262311j6ece045apd731b4e78eacd4c5@mail.gmail.com>
	<fb6fbf560805271312g41c6b240h322c7142d1cf98be@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<aac2c7cb0805311433q58a3e17ajd17e8debba10ca28@mail.gmail.com>
Message-ID: <ca471dc20805311850x6245df31t71c762aae0b2463d@mail.gmail.com>

On Sat, May 31, 2008 at 2:33 PM, Adam Olsen <rhamph at gmail.com> wrote:
> I think the reason why strict/backslashreplace (respectively) work
> well is that you can print a unicode string to stdout, have it fail
> (encoding can't handle it), then get an exception printed to stderr
> with the string escaped.
>
> Making stderr stricter would make it unable to print the string and
> making stdout less strict would let the error pass silently (printing
> potential garbage instead).

You've got it exactly right, better than I said it.

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

From guido at python.org  Sun Jun  1 03:59:05 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 31 May 2008 18:59:05 -0700
Subject: [Python-3000] PEP 3101 str.format() equivalent of '%#o/x/X'?
In-Reply-To: <78b3a9580805311641ob06e7faw80c9d5e41e7e64fe@mail.gmail.com>
References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4@mail.gmail.com>
	<483EAF95.5050503@trueblade.com>
	<3f4107910805291116w37af38e3qb2c5145539d7e23e@mail.gmail.com>
	<483F06FF.9090007@trueblade.com>
	<78b3a9580805291634t3ed65ab3x29bedc80be887f8@mail.gmail.com>
	<483F4E3A.9090403@trueblade.com>
	<ca471dc20805301209j67c3e2a5nf819297680cbf3fb@mail.gmail.com>
	<48405420.8010800@trueblade.com>
	<ca471dc20805301237p4a30dd5du4f3ecb2771a967ca@mail.gmail.com>
	<78b3a9580805311641ob06e7faw80c9d5e41e7e64fe@mail.gmail.com>
Message-ID: <ca471dc20805311859n76ba9048td2a6ea865ef94c25@mail.gmail.com>

On Sat, May 31, 2008 at 4:41 PM, wesley chun <wescpy at gmail.com> wrote:
> somewhat on-topic, can i hear from some of you as far as use-cases for
> oct() and hex() [plus bin()] in Python code?  i find "%x" or "%o" (and
> its variants) sufficient in serving my needs.  in other words, why
> oct() and hex() built-in functions instead of elsewhere like in
> operator for those who desire a functional interface?

I use oct() and hex() all the time at the interactive prompt when I
have a funny number given in decimal and wonder if it's really a magic
bit pattern.

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

From stefan_ml at behnel.de  Sun Jun  1 08:44:35 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 01 Jun 2008 08:44:35 +0200
Subject: [Python-3000] doctest portability
In-Reply-To: <ca471dc20805311849h6e14e740ye238d1984e221ed9@mail.gmail.com>
References: <g1rk9q$lti$1@ger.gmane.org>
	<g1rpv7$5mp$1@ger.gmane.org>	<g1rrtq$aoe$1@ger.gmane.org>
	<ca471dc20805311849h6e14e740ye238d1984e221ed9@mail.gmail.com>
Message-ID: <g1tggj$41f$1@ger.gmane.org>

Guido van Rossum wrote:
> 2to3 lets you specify exactly which fixers to run with the -f command line flag.

Nice, one problem solved then. I assume that's also available in the library
version?

 object. I find that very inconvenient.BTW, last time I checked, options were
passed into lib2to3 as attributes of an  A dict or keyword arguments would
work much better.


> I really don't like the idea of having Py3k code with doctests written
> in a dialect of Py2k...

There's two types of doctests, one that is meant as user readable examples and
one where the doctest module is used for convenience. I agree that doctests
should use a consistent syntax, either Py2 or Py3, especially if they are
meant as documentation. But that's currently not easy to achieve in a portable
way. Py2 byte strings are the most obvious problem.

I don't think that every software package that supports Py3 will convert its
doctests to Py3 syntax, at least as long as there is no perfectly working 3to2
doctest converter that converts byte/unicode strings correctly. And even then,
it would have to be integrated with the doctest module.

Having to split your code base just because your tests don't run on a new
target platform is not an option IMHO. That would rather keep people from
supporting Py3.

Stefan


From ishimoto at gembook.org  Sun Jun  1 09:23:10 2008
From: ishimoto at gembook.org (Atsuo Ishimoto)
Date: Sun, 1 Jun 2008 16:23:10 +0900
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <aac2c7cb0805311433q58a3e17ajd17e8debba10ca28@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<fb6fbf560805261806j7b79e776i3361a655ac1d8a36@mail.gmail.com>
	<797440730805262311j6ece045apd731b4e78eacd4c5@mail.gmail.com>
	<fb6fbf560805271312g41c6b240h322c7142d1cf98be@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<aac2c7cb0805311433q58a3e17ajd17e8debba10ca28@mail.gmail.com>
Message-ID: <797440730806010023h3f9cf85qc03b2a68c695a3b5@mail.gmail.com>

On Sun, Jun 1, 2008 at 6:33 AM, Adam Olsen <rhamph at gmail.com> wrote:

> I think the reason why strict/backslashreplace (respectively) work
> well is that you can print a unicode string to stdout, have it fail
> (encoding can't handle it), then get an exception printed to stderr
> with the string escaped.
>
> Making stderr stricter would make it unable to print the string and
> making stdout less strict would let the error pass silently (printing
> potential garbage instead).
>

I agree these points. I know my preference was already denied by
important persons in the python developers :), so may be I'm wrong.
The release date is approaching fast. As Marc-Andre pointed out, the
default error handler for sys.stdout may be out of scope. So I'm going
to shut up and see whether community starts mumbling or not.

But if you have spare time and interested, following is my points. I
may be come back for Python 3.1 or 3.2 :).

======
How many scripts want to care about encoding error? If you ship your
scripts with 'strict' error handler, users of the script should
determine a certain encoding of output and should be responsible to
set up correct runtime environment, which are not always possible.
For example, we can not guarantee this trivial script would work on Windows:

for filename in os.listdir("."):
    print(filename)

The 'filename' can contain ASCII, Greek, Chinese or any other
characters, so no encoding other than utf-8 (the only sane encoding
for Unicode applications) may raise exceptions. In practice, the best
thing we can do is printing escaped string silently and close can of
worms:).

Raising exceptions would be desired in some case, but for such cases,
input data and environment should be examined by script, *before* the
data are printed. Printing curt UnicodeEncodingError() message may not
be what you want to your scripts.

Thus, current restriction is too defensive for most of use-cases, IMO.
As I wrote before, other languages I familiar(Java, .Net languages,
Perl) don't raise exceptions by default, but silently print converted
characters. Ditto for utilities such as 'ls'.

From phd at phd.pp.ru  Sun Jun  1 10:15:23 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Sun, 1 Jun 2008 12:15:23 +0400
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <797440730806010023h3f9cf85qc03b2a68c695a3b5@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<fb6fbf560805261806j7b79e776i3361a655ac1d8a36@mail.gmail.com>
	<797440730805262311j6ece045apd731b4e78eacd4c5@mail.gmail.com>
	<fb6fbf560805271312g41c6b240h322c7142d1cf98be@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<aac2c7cb0805311433q58a3e17ajd17e8debba10ca28@mail.gmail.com>
	<797440730806010023h3f9cf85qc03b2a68c695a3b5@mail.gmail.com>
Message-ID: <20080601081523.GA25882@phd.pp.ru>

On Sun, Jun 01, 2008 at 04:23:10PM +0900, Atsuo Ishimoto wrote:
> silently print converted
> characters. Ditto for utilities such as 'ls'.

$ ls -lF work/
total 72
drwxr-x---  7 phd phd 4096 May 27 11:14 ?????/
drwx------  9 phd phd 4096 May 30 17:30 ?????/
drwxr-xr-x  4 phd phd 4096 May 13 18:35 books/
   [truncate]

   Filesystem encoding is koi8-r, terminal encoding is UTF-8, ls doesn't
convert (because it doesn't know filesystem encoding) but simply replaces,
like in Python filename.encode(LC_CTYPE, "replace"). No error reported.

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

From ishimoto at gembook.org  Sun Jun  1 11:05:17 2008
From: ishimoto at gembook.org (Atsuo Ishimoto)
Date: Sun, 1 Jun 2008 18:05:17 +0900
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <20080601081523.GA25882@phd.pp.ru>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<797440730805262311j6ece045apd731b4e78eacd4c5@mail.gmail.com>
	<fb6fbf560805271312g41c6b240h322c7142d1cf98be@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<aac2c7cb0805311433q58a3e17ajd17e8debba10ca28@mail.gmail.com>
	<797440730806010023h3f9cf85qc03b2a68c695a3b5@mail.gmail.com>
	<20080601081523.GA25882@phd.pp.ru>
Message-ID: <797440730806010205u43d2604ajfaf7bd859d757311@mail.gmail.com>

On Sun, Jun 1, 2008 at 5:15 PM, Oleg Broytmann <phd at phd.pp.ru> wrote:
>
>   Filesystem encoding is koi8-r, terminal encoding is UTF-8, ls doesn't
> convert (because it doesn't know filesystem encoding) but simply replaces,
> like in Python filename.encode(LC_CTYPE, "replace"). No error reported.
>

Sorry for my bad wording. I wanted to say "ls doesn't reports error,
but silently prints '?'", not "ls converts filename as per terminal
encoding, without reporting conversion errors".

In my case, ls checks characters in the file name and convert invalid
characters to '?'.

[ishimoto at host test]$ export LANG=ja_JP.eucJP
[ishimoto at host test]$ ls
???
[ishimoto at host test]$ export LANG=C
[ishimoto at host test]$ ls
??????

From qrczak at knm.org.pl  Sun Jun  1 11:34:22 2008
From: qrczak at knm.org.pl (=?UTF-8?Q?Marcin_=E2=80=98Qrczak=E2=80=99_Kowalczyk?=)
Date: Sun, 1 Jun 2008 11:34:22 +0200
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <797440730806010205u43d2604ajfaf7bd859d757311@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<fb6fbf560805271312g41c6b240h322c7142d1cf98be@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<aac2c7cb0805311433q58a3e17ajd17e8debba10ca28@mail.gmail.com>
	<797440730806010023h3f9cf85qc03b2a68c695a3b5@mail.gmail.com>
	<20080601081523.GA25882@phd.pp.ru>
	<797440730806010205u43d2604ajfaf7bd859d757311@mail.gmail.com>
Message-ID: <3f4107910806010234g7dfa96ds4b6d5b35685f4906@mail.gmail.com>

2008/6/1 Atsuo Ishimoto <ishimoto at gembook.org>:

> In my case, ls checks characters in the file name and convert invalid
> characters to '?'.

GNU ls has more options for displaying filenames with weird
characters: http://www.gnu.org/software/coreutils/manual/coreutils.html#Formatting-the-file-names

-- 
Marcin Kowalczyk
qrczak at knm.org.pl
http://qrnik.knm.org.pl/~qrczak/

From oren at hishome.net  Sun Jun  1 11:42:00 2008
From: oren at hishome.net (Oren Tirosh)
Date: Sun, 1 Jun 2008 09:42:00 +0000
Subject: [Python-3000] [Python-Dev] Iterable String Redux (aka String
	ABC)
In-Reply-To: <ca471dc20805271242q63e80104mfad81d1b1014df60@mail.gmail.com>
References: <loom.20080527T192243-415@post.gmane.org>
	<ca471dc20805271242q63e80104mfad81d1b1014df60@mail.gmail.com>
Message-ID: <20080601094159.GA9825@hishome.net>

On Tue, May 27, 2008 at 12:42:48PM -0700, Guido van Rossum wrote:
> [+python-3000]
> 
> On Tue, May 27, 2008 at 12:32 PM, Armin Ronacher
> <armin.ronacher at active-4.com> wrote:
...
> > A problem comes up as soon as user defined strings (such as UserString) is
> > passed to the function.  In my opinion a good solution would be a "String"
> > ABC one could test against.
> 
> I'm not against this, but so far I've not been able to come up with a
> good set of methods to endow the String ABC with. Another problem is
> that not everybody draws the line in the same place -- how should
> instances of bytes, bytearray, array.array, memoryview (buffer in 2.6)
> be treated?
> 
> -- 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

The issue goes beyond iterability. If a user defined string such as
UserString that is not derived from one of the "true" builtin string
types is passed to a builtin function that expects a string it will be
rejected. PyArgs_ParseTuple discriminates against such user defined
types :-)

If a String ABC is implemented it could be used as a signal that the
object is not just convertable to a string (virtually all objects are)
but IS a string and its __str__ should be used during builtin function
argument parsing.

-
Oren


From stefan_ml at behnel.de  Sun Jun  1 13:51:09 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 01 Jun 2008 13:51:09 +0200
Subject: [Python-3000] doctest portability
In-Reply-To: <g1tggj$41f$1@ger.gmane.org>
References: <g1rk9q$lti$1@ger.gmane.org>	<g1rpv7$5mp$1@ger.gmane.org>	<g1rrtq$aoe$1@ger.gmane.org>	<ca471dc20805311849h6e14e740ye238d1984e221ed9@mail.gmail.com>
	<g1tggj$41f$1@ger.gmane.org>
Message-ID: <g1u2fd$ggo$1@ger.gmane.org>

Hi again,

sorry, mail editing disorder. I meant to say this:

Stefan Behnel wrote:
> BTW, last time I checked, options were passed into lib2to3 as attributes of
> an object. I find that very inconvenient. A dict or keyword arguments would
> work much better.

And just to give a hint on what I mean here:

> There's two types of doctests, one that is meant as user readable examples and
> one where the doctest module is used for convenience.

An example of the convenience part is that we use doctests as compiler tests
in Cython, for example. The idea is to compile a source file into a C
extension module using Cython and then execute the module docstring in
Python's doctest module to test the extension.

http://hg.cython.org/cython-devel/file/tip/tests/run/

For example, here is a test for unicode strings, which currently uses both the
u'' and b'' prefix and replaces one of them based on the Python version it
runs in.

http://hg.cython.org/cython-devel/file/tip/tests/run/unicodeliterals.pyx

That's simple to do. However, doctests in user documentation are much harder
to write in a portable way, as all that overhead of (e.g.) encoding byte
strings to unicode strings for normalised output comparison is very
distracting for readers, so it would be much better if you could just say
"this is a doctest in Py3 syntax" or "in Py2 syntax", and have doctest do the
rest for you at runtime.

Stefan


From ncoghlan at gmail.com  Sun Jun  1 14:46:31 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 01 Jun 2008 22:46:31 +1000
Subject: [Python-3000] doctest portability
In-Reply-To: <g1u2fd$ggo$1@ger.gmane.org>
References: <g1rk9q$lti$1@ger.gmane.org>	<g1rpv7$5mp$1@ger.gmane.org>	<g1rrtq$aoe$1@ger.gmane.org>	<ca471dc20805311849h6e14e740ye238d1984e221ed9@mail.gmail.com>	<g1tggj$41f$1@ger.gmane.org>
	<g1u2fd$ggo$1@ger.gmane.org>
Message-ID: <48429A27.8090507@gmail.com>

Stefan Behnel wrote:
> That's simple to do. However, doctests in user documentation are much harder
> to write in a portable way, as all that overhead of (e.g.) encoding byte
> strings to unicode strings for normalised output comparison is very
> distracting for readers, so it would be much better if you could just say
> "this is a doctest in Py3 syntax" or "in Py2 syntax", and have doctest do the
> rest for you at runtime.

Doctest just uses 'exec' under the covers though - the only way for it 
to run code using non-native syntax would be for it to be able to invoke 
a non-native parser and then run the resulting AST directly, or for it 
to invoke 2to3 on the docstring.

Sphinx (the tool used to build the Python docs) gets around this by 
allowing code to be included in the doc source that is used when running 
the doctests, but hidden when generating output for human consumption 
(HTML, PDF, etc)

Cheers,
Nick.

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

From stefan_ml at behnel.de  Sun Jun  1 15:18:26 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 01 Jun 2008 15:18:26 +0200
Subject: [Python-3000] doctest portability
In-Reply-To: <48429A27.8090507@gmail.com>
References: <g1rk9q$lti$1@ger.gmane.org>	<g1rpv7$5mp$1@ger.gmane.org>	<g1rrtq$aoe$1@ger.gmane.org>	<ca471dc20805311849h6e14e740ye238d1984e221ed9@mail.gmail.com>	<g1tggj$41f$1@ger.gmane.org>	<g1u2fd$ggo$1@ger.gmane.org>
	<48429A27.8090507@gmail.com>
Message-ID: <g1u7j2$u7o$1@ger.gmane.org>

Hi,

Nick Coghlan wrote:
> Doctest just uses 'exec' under the covers though - the only way for it
> to run code using non-native syntax would be for it to be able to invoke
> a non-native parser and then run the resulting AST directly, or for it
> to invoke 2to3 on the docstring.

I think it should do the latter.


> Sphinx (the tool used to build the Python docs) gets around this by
> allowing code to be included in the doc source that is used when running
> the doctests, but hidden when generating output for human consumption
> (HTML, PDF, etc)

That's what I do, too, in a couple of places, e.g. to import StringIO/BytesIO
or to make unicode() available. But having to copy syntax work-around code
into each source file that has doctests is the wrong trade-off, IMHO. This
should be an external option passed to the doctest run.

Stefan


From stefan_ml at behnel.de  Sun Jun  1 16:39:39 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 01 Jun 2008 16:39:39 +0200
Subject: [Python-3000] doctest portability
In-Reply-To: <g1rk9q$lti$1@ger.gmane.org>
References: <g1rk9q$lti$1@ger.gmane.org>
Message-ID: <g1ucbb$bcl$1@ger.gmane.org>

Stefan Behnel wrote:
> It would be
> really nice if the doctest module had a simple option that specified if the
> doctests of a test suite are in Py2 or Py3 syntax, and then just did the right
> thing under Py3 (and maybe also 2.6).

I filed a feature request on this for now.

http://bugs.python.org/issue3020

Stefan


From stefan_ml at behnel.de  Sun Jun  1 17:28:06 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 01 Jun 2008 17:28:06 +0200
Subject: [Python-3000] doctest portability
In-Reply-To: <ca471dc20805311849h6e14e740ye238d1984e221ed9@mail.gmail.com>
References: <g1rk9q$lti$1@ger.gmane.org>
	<g1rpv7$5mp$1@ger.gmane.org>	<g1rrtq$aoe$1@ger.gmane.org>
	<ca471dc20805311849h6e14e740ye238d1984e221ed9@mail.gmail.com>
Message-ID: <g1uf65$j3t$1@ger.gmane.org>

Guido van Rossum wrote:
> I really don't like the idea of having Py3k code with doctests written
> in a dialect of Py2k...

BTW, this argument might hold for code that was written for Py3, of which
there currently is close to nothing.

Stefan


From ishimoto at gembook.org  Sun Jun  1 17:32:27 2008
From: ishimoto at gembook.org (Atsuo Ishimoto)
Date: Mon, 2 Jun 2008 00:32:27 +0900
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<fb6fbf560805261806j7b79e776i3361a655ac1d8a36@mail.gmail.com>
	<797440730805262311j6ece045apd731b4e78eacd4c5@mail.gmail.com>
	<fb6fbf560805271312g41c6b240h322c7142d1cf98be@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
Message-ID: <797440730806010832t1137891fi8e47458b8dafb1b2@mail.gmail.com>

On Sun, Jun 1, 2008 at 2:30 AM, Atsuo Ishimoto <ishimoto at gembook.org> wrote:
>
> I'll update the PEP and the patch on Sunday. Thank you!

Here's new PEP,  and new patch is uploaded at http://bugs.python.org/issue2630.
(codereview.appspot.com refused to create new issue for this patch, btw.)



----------------------------------------------
PEP: 3138

Title: String representation in Python 3000
Version: $Revision$
Last-Modified: $Date$
Author: Atsuo Ishimoto <ishimoto--at--gembook.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-May-2008
Post-History:


Abstract
========

This PEP proposes a new string representation form for Python 3000. In
Python prior to Python 3000, the repr() built-in function converted
arbitrary objects to printable ASCII strings for debugging and logging.
For Python 3000, a wider range of characters, based on the Unicode
standard, should be considered 'printable'.


Motivation
==========

The current repr() converts 8-bit strings to ASCII using following
algorithm.

- Convert CR, LF, TAB and '\\' to '\\r', '\\n', '\\t', '\\\\'.

- Convert other non-printable characters(0x00-0x1f, 0x7f) and non-ASCII
  characters(>=0x80) to '\\xXX'.

- Backslash-escape quote characters (apostrophe, ') and add the quote
  character at the beginning and the end.

For Unicode strings, the following additional conversions are done.

- Convert leading surrogate pair characters without trailing character
  (0xd800-0xdbff, but not followed by 0xdc00-0xdfff) to '\\uXXXX'.

- Convert 16-bit characters(>=0x100) to '\\uXXXX'.

- Convert 21-bit characters(>=0x10000) and surrogate pair characters to
  '\\U00xxxxxx'.

This algorithm converts any string to printable ASCII, and repr() is
used as a handy and safe way to print strings for debugging or for
logging. Although all non-ASCII characters are escaped, this does not
matter when most of the string's characters are ASCII. But for other
languages, such as Japanese where most characters in a string are not
ASCII, this is very inconvenient.

We can use ``print(aJapaneseString)`` to get a readable string, but we
don't have a similar workaround for printing strings from collections
such as lists or tuples. ``print(listOfJapaneseStrings)`` uses repr() to
build the string to be printed, so the resulting strings are always
hex-escaped. Or when ``open(japaneseFilemame)`` raises an exception, the
error message is something like ``IOError: [Errno 2] No such file or
directory: '\u65e5\u672c\u8a9e'``, which isn't helpful.

Python 3000 has a lot of nice features for non-Latin users such as
non-ASCII identifiers, so it would be helpful if Python could also
progress in a similar way for printable output.

Some users might be concerned that such output will mess up their
console if they print binary data like images. But this is unlikely to
happen in practice because bytes and strings are different types in
Python 3000, so printing an image to the console won't mess it up.

This issue was once discussed by Hye-Shik Chang [1]_ , but was rejected.


Specification
=============

- Add a new function to the Python C API ``int PY_UNICODE_ISPRINTABLE
  (Py_UNICODE ch)``. This function returns 0 if repr() should escape the
  Unicode character ``ch``; otherwise it returns 1. Characters that should
  be escaped are defined in the Unicode character database as:

  * Cc (Other, Control)
  * Cf (Other, Format)
  * Cs (Other, Surrogate)
  * Co (Other, Private Use)
  * Cn (Other, Not Assigned)
  * Zl (Separator, Line), refers to LINE SEPARATOR ('\\u2028').
  * Zp (Separator, Paragraph), refers to PARAGRAPH SEPARATOR ('\\u2029').
  * Zs (Separator, Space) other than ASCII space('\\x20'). Characters in
    this category should be escaped to avoid ambiguity.

- The algorithm to build repr() strings should be changed to:

  * Convert CR, LF, TAB and '\\' to '\\r', '\\n', '\\t', '\\\\'.

  * Convert non-printable ASCII characters(0x00-0x1f, 0x7f) to '\\xXX'.

  * Convert leading surrogate pair characters without trailing character
    (0xd800-0xdbff, but not followed by 0xdc00-0xdfff) to '\\uXXXX'.

  * Convert non-printable characters(PY_UNICODE_ISPRINTABLE() returns 0)
    to 'xXX', '\\uXXXX' or '\\U00xxxxxx'.

  * Backslash-escape quote characters (apostrophe, 0x27) and add quote
    character at the beginning and the end.

- Set the Unicode error-handler for sys.stderr to 'backslashreplace' by
  default.

- Add ``'%a'`` string format operator. ``'%a'`` converts any python
  object to a string using repr() and then hex-escapes all non-ASCII
  characters. The ``'%a'`` format operator generates the same string as
  ``'%r'`` in Python 2.

- Add a new built-in function, ``ascii()``. This function converts any
  python object to a string using repr() and then hex-escapes all non-
  ASCII characters. ``ascii()`` generates the same string as ``repr()``
  in Python 2.

- Add an ``isprintable()`` method to the string type. ``str.isprintable()``
  returns False if repr() should escape any character in the string;
  otherwise returns True. The ``isprintable()`` method calls the
  `` PY_UNICODE_ISPRINTABLE()`` function internally.


Rationale
=========

The repr() in Python 3000 should be Unicode not ASCII based, just like
Python 3000 strings. Also, conversion should not be affected by the
locale setting, because the locale is not necessarily the same as the
output device's locale. For example, it is common for a daemon process
to be invoked in an ASCII setting, but writes UTF-8 to its log files.
Also, web applications might want to report the error information in
more readable form based on the HTML page's encoding.

Characters not supported by the user's console could be hex-escaped on
printing, by the Unicode encoder's error-handler. If the error-handler
of the output file is 'backslashreplace', such characters are hex-
escaped without raising UnicodeEncodeError. For example, if your default
encoding is ASCII, ``print('Hello ?')`` will prints 'Hello \\xa2'. If
your encoding is ISO-8859-1, 'Hello ?' will be printed.

Default error-handler of sys.stdout is 'strict'. Other applications
reading the output might not understand hex-escaped characters, so
unsupported characters should be trapped when writing. If you need to
escape unsupported characters, you should change error-handler
explicitly. For sys.stderr, default error-handler is set to
'backslashreplace' and printing exceptions or error messages won't
be failed.

Alternate Solutions
-------------------

To help debugging in non-Latin languages without changing repr(), other
suggestions were made.

- Supply a tool to print lists or dicts.

  Strings to be printed for debugging are not only contained by lists or
  dicts, but also in many other types of object. File objects contain a
  file name in Unicode, exception objects contain a message in Unicode,
  etc. These strings should be printed in readable form when repr()ed.
  It is unlikely to be possible to implement a tool to print all
  possible object types.

- Use sys.displayhook and sys.excepthook.

  For interactive sessions, we can write hooks to restore hex escaped
  characters to the original characters. But these hooks are called only
  when printing the result of evaluating an expression entered in an
  interactive Python session, and doesn't work for the print() function,
  for non-interactive sessions or for logging.debug("%r", ...), etc.

- Subclass sys.stdout and sys.stderr.

  It is difficult to implement a subclass to restore hex-escaped
  characters since there isn't enough information left by the time it's
  a string to undo the escaping correctly in all cases. For example, ``
  print("\\"+"u0041")`` should be printed as '\\u0041', not 'A'. But
  there is no chance to tell file objects apart.

- Make the encoding used by unicode_repr() adjustable, and make the
  existing repr() the default.

  With adjustable repr(), the result of using repr() is unpredictable
  and would make it impossible to write correct code involving repr().
  And if current repr() is the default, then the old convention remains
  intact and users may expect ASCII strings as the result of repr().
  Third party applications or libraries could be confused when a custom
  repr() function is used.


Backwards Compatibility
=======================

Changing repr() may break some existing code, especially testing code.
Five of Python's regression tests fail with this modification. If you
need repr() strings without non-ASCII character as Python 2, you can use
the following function. ::

    def repr_ascii(obj):
        return str(repr(obj).encode("ASCII", "backslashreplace"), "ASCII")

For logging or for debugging, the following code can raise
UnicodeEncodeError. ::

    log = open("logfile", "w")
    log.write(repr(data))     # UnicodeEncodeError will be raised
                              # if data contains unsupported characters.

To avoid exceptions being raised, you can explicitly specify the error-
handler. ::

    log = open("logfile", "w", errors="backslashreplace")
    log.write(repr(data))  # Unsupported characters will be escaped.


For a console that uses a Unicode-based encoding, for example, en_US.
utf8 or de_DE.utf8, the backslashescape trick doesn't work and all
printable characters are not escaped. This will cause a problem of
similarly drawing characters in Western, Greek and Cyrillic languages.
These languages use similar (but different) alphabets (descended from
the common ancestor) and contain letters that look similar but have
different character codes. For example, it is hard to distinguish Latin
'a', 'e' and 'o' from Cyrillic '?', '?' and '?'. (The visual
representation, of course, very much depends on the fonts used but
usually these letters are almost indistinguishable.) To avoid the
problem, the user can adjust the terminal encoding to get a result
suitable for their environment.


Open Issues
===========

- Is the ``ascii()`` function necessary, or is it sufficient to document
  how to do it? If necessary, should ``ascii()`` belong to the builtin
  namespace?


Rejected Proposals
==================

- Add encoding and errors arguments to the builtin print() function,
  with defaults of sys.getfilesystemencoding() and 'backslashreplace'.

  Complicated to implement, and in general, this is not seen as a good
  idea. [2]_

- Use character names to escape characters, instead of hex character
  codes. For example, ``repr('\u03b1')`` can be converted to
  ``"\N{GREEK SMALL LETTER ALPHA}"``.

  Using character names can be very verbose compared to hex-escape.
  e.g., ``repr("\ufbf9")`` is converted to ``"\N{ARABIC LIGATURE UIGHUR
  KIRGHIZ YEH WITH HAMZA ABOVE WITH ALEF MAKSURA ISOLATED FORM}"``.

- Default error-handler of sys.stdout should be 'backslashreplace'.

  Stuff written to stdout might be consumed by another program that
  might misinterpret the \ escapes. For interactive session, it is
  possible to make 'backslashreplace' error-handler to default, but may
  add confusion of the kind "it works in interactive mode but not when
  redirecting to a file".


Reference Implementation
========================

http://bugs.python.org/issue2630


References
==========

.. [1] Multibyte string on string::string_print
        (http://bugs.python.org/issue479898)

.. [2] [Python-3000] Displaying strings containing unicode escapes
        (http://mail.python.org/pipermail/python-3000/2008-April/013366.html)

Copyright
=========

This document has been placed in the public domain.

From solipsis at pitrou.net  Sun Jun  1 22:15:30 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 01 Jun 2008 22:15:30 +0200
Subject: [Python-3000] Exception re-raising woes
In-Reply-To: <ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>
References: <loom.20080526T091655-961@post.gmane.org>
	<loom.20080530T094609-317@post.gmane.org>
	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>
Message-ID: <1212351330.5862.1.camel@fsol>


Hello,

A patch is now at http://bugs.python.org/issue3021 .

Antoine.



From qgallet at gmail.com  Mon Jun  2 00:45:53 2008
From: qgallet at gmail.com (Quentin Gallet-Gilles)
Date: Mon, 2 Jun 2008 00:45:53 +0200
Subject: [Python-3000] [Python-Dev] Finishing up PEP 3108
In-Reply-To: <8b943f2b0805290839s7a1f3238g9e21407a56c34159@mail.gmail.com>
References: <bbaeab100805282138x5ccac2d8q100fa0e969828bb4@mail.gmail.com>
	<g1ll0v$i0p$1@ger.gmane.org>
	<8b943f2b0805290625w19ab1fd3l48f00f40e630c39d@mail.gmail.com>
	<483EC414.7080603@ibp.de>
	<8b943f2b0805290839s7a1f3238g9e21407a56c34159@mail.gmail.com>
Message-ID: <8b943f2b0806011545x6a11f019r3c412bc3ebc1a3ab@mail.gmail.com>

I've uploaded a patch for the aifc module (http://bugs.python.org/issue2847).
I'm still working on the testsuite.
Comments are welcome!

Quentin

On Thu, May 29, 2008 at 5:39 PM, Quentin Gallet-Gilles <qgallet at gmail.com>
wrote:

>
> On Thu, May 29, 2008 at 4:56 PM, Lars Immisch <lars at ibp.de> wrote:
>
>> <snip>
>>
>>>        Issue 2847 - the aifc module still imports the cl module in 3.0.
>>>        Problem is that the cl module is gone. =) So it seems silly to
>>> have
>>>        the imports lying about. This can probably be changed to critical.
>>>
>>>
>>>    It shouldn't be a problem to rip everything cl-related out of aifc.
>>>    The question is how useful aifc will be after that ...
>>>
>>>
>>> Has someone already used that module ? I took a look into it, but I'm a
>>> bit confused about the various compression types, case-sensitivity and
>>> compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the
>>> same encoding ? Can we use the audioop module for ALAW, just like it's
>>> already done for ULAW ?
>>>
>>
>> There is just one alaw I've ever come across (G.711), and the audioop
>> implementation could be used (audioop's alaw support is younger than the
>> aifc module, BTW)
>>
>> The capitalisation is confusing, but your document [1] says: "Apple
>> Computer's QuickTime player recognize only the Apple compression types.
>> Although "ALAW" and "ULAW" contain identical sound samples to the "alaw" and
>> "ulaw" formats and were in use long before Apple introduced the new codes,
>>  QuickTime does not recognize them."
>>
>> So this seems just a matter of naming in the AIFC, but not a matter of two
>> different alaw implementations.
>>
>> - Lars
>>
>
> Ok, I'll handle this issue. I'll be using the audioop implementation as a
> replacement of the SGI compression library. I'll also create a test suite,
> as Brett mentioned in the bug tracker the module was missing one.
>
> Quentin
>
>
>>
>> [1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080602/b5b4be23/attachment.htm>

From greg at krypto.org  Mon Jun  2 01:30:54 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 1 Jun 2008 16:30:54 -0700
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <483FBCB4.5020007@egenix.com>
References: <48397ECC.9070805@cheimes.de> <483B2D02.8040400@cheimes.de>
	<483BDE11.509@egenix.com> <483D300B.5090309@egenix.com>
	<52dc1c820805281347n75a4baax9222b75c8fa09ec5@mail.gmail.com>
	<483ECA52.6040000@egenix.com> <483ECF94.7060607@cheimes.de>
	<483EF139.8000606@egenix.com> <483F34C3.3050402@gmail.com>
	<483FBCB4.5020007@egenix.com>
Message-ID: <52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>

On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-05-30 00:57, Nick Coghlan wrote:
>>
>> M.-A. Lemburg wrote:
>>>
>>> * Why can't we have both PyString *and* PyBytes exposed in 2.x,
>>> with one redirecting to the other ?
>>
>> We do have that - the PyString_* names still work perfectly fine in 2.x.
>> They just won't be used in the Python core codebase anymore - everything in
>> the Python core will use either PyBytes_* or PyUnicode_* regardless of which
>> branch (2.x or 3.x) you're working on. I think that's a good thing for ease
>> of maintenance in the future, even if it takes people a while to get their
>> heads around it right now.
>
> Sorry, I probably wasn't clear enough:
>
> Why can't we have both PyString *and* PyBytes exposed as C
> APIs (ie. visible in code and in the linker) in 2.x, with one redirecting
> to the other ?
>
>>> * Why should the 2.x code base turn to hacks, just because 3.x wants
>>> to restructure itself ?
>>
>> With the better explanation from Greg of what the checked in approach
>> achieves (i.e. preserving exact ABI compatibility for PyString_*, while
>> allowing PyBytes_* to be used at the source code level), I don't see what
>> has been done as being any more of a hack than the possibly more common
>> "#define <oldname> <newname>" (which *would* break binary compatibility).
>>
>> The only things that I think would tidy it up further would be to:
>> - include an explanation of the approach and its effects on API and ABI
>> backward and forward compatibility within 2.x and between 2.x and 3.x in
>> stringobject.h
>> - expose the PyBytes_* functions to the linker in 2.6 as well as 3.0
>
> Which is what I was suggesting all along; sorry if I wasn't
> clear enough on that.
>
> The standard approach is that you provide #define redirects from the
> old APIs to the new ones (which are then picked up by the compiler)
> *and* add function wrappers to the same affect (to make linkers,
> dynamic load APIs such ctypes and debuggers happy).
>
>
> Example from pythonrun.h|c:
> ---------------------------
>
> /* Use macros for a bunch of old variants */
> #define PyRun_String(str, s, g, l) PyRun_StringFlags(str, s, g, l, NULL)
>
> /* Deprecated C API functions still provided for binary compatiblity */
>
> #undef PyRun_String
> PyAPI_FUNC(PyObject *)
> PyRun_String(const char *str, int s, PyObject *g, PyObject *l)
> {
>        return PyRun_StringFlags(str, s, g, l, NULL);
> }
>

Okay, how about this?  http://codereview.appspot.com/1521

Using that patch, both PyString_ and PyBytes_ APIs are available using
function stubs similar to the above.  I opted to define the stub
functions right next to the ones they were stubbing rather than
putting them all at the end of the file or in another file but they
could be moved if someone doesn't like them that way.

> I still believe that we should *not* make "easy of merging" the
> primary motivation for backporting changes in 3.x to 2.x. Software
> design should not be guided by restrictions in the tool chain,
> if not absolutely necessary.
>
> The main argument for a backport needs to be general usefulness
> to the 2.x users, IMHO... just like any other feature that
> makes it into 2.x.
>
> If merging is difficult then this needs to be addressed, but
> there are more options to that than always going back to the
> original 2.x trunk code. I've given a few suggestions on how
> this could be approached in other emails on this thread.

I am not the one doing the merging or working on merge tools so I'll
leave this up to those that are.

-gps

From ishimoto at gembook.org  Mon Jun  2 01:32:09 2008
From: ishimoto at gembook.org (Atsuo Ishimoto)
Date: Mon, 2 Jun 2008 08:32:09 +0900
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <acd65fa20806011039w6a432df8lf8da163d6e173d9b@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<fb6fbf560805261806j7b79e776i3361a655ac1d8a36@mail.gmail.com>
	<797440730805262311j6ece045apd731b4e78eacd4c5@mail.gmail.com>
	<fb6fbf560805271312g41c6b240h322c7142d1cf98be@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<797440730806010832t1137891fi8e47458b8dafb1b2@mail.gmail.com>
	<acd65fa20806011039w6a432df8lf8da163d6e173d9b@mail.gmail.com>
Message-ID: <797440730806011632o76e5dcferca8b6c4dc015a4bf@mail.gmail.com>

On Mon, Jun 2, 2008 at 2:39 AM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
> On Sun, Jun 1, 2008 at 11:32 AM, Atsuo Ishimoto <ishimoto at gembook.org> wrote:
>>
>> ----------------------------------------------
>> PEP: 3138
>>
>> Title: String representation in Python 3000
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Atsuo Ishimoto <ishimoto--at--gembook.org>
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 05-May-2008
>> Post-History:
>>
> [SNIP]
>> - Add a new function to the Python C API ``int PY_UNICODE_ISPRINTABLE
>>  (Py_UNICODE ch)``.
>
> Shouldn't the name be Py_UNICODE_ISPRINTABLE?

Oh, yes. It has correct name in the patch.

>
> I know that I am a bit late in the whole discussion, but isn't,
> whether or not a character is "printable", actually defined as a
> property of the output device (i.e., does it have the necessary glyphs
> to render the characters)?
>
> I don't have a problem with allowing more characters to be represented
> unescaped (in fact, I think this is a great idea). But, I just don't
> like using "printable" as a character property. Maybe, "readable" or
> "legible" would be more appropriate. Anyway, that's only nitpicking
> from my part.
>

I'm not comfortable with "printable", too. Is "legible" better? This
is first time for me to see this word in my life :).

>> - Add ``'%a'`` string format operator. ``'%a'`` converts any python
>>  object to a string using repr() and then hex-escapes all non-ASCII
>>  characters. The ``'%a'`` format operator generates the same string as
>>  ``'%r'`` in Python 2.
>>
>> - Add a new built-in function, ``ascii()``. This function converts any
>>  python object to a string using repr() and then hex-escapes all non-
>>  ASCII characters. ``ascii()`` generates the same string as ``repr()``
>>  in Python 2.
>>
>
> Why ascii() has to use repr()? Couldn't we simply rename the old 2.x
> repr() function to ascii()?

No. repr() simply calls obj.__repr__(), and obj.__repr() returns
non-ASCII string now. So to get ASCII string, we should convert result
of repr().

>
>> - Add an ``isprintable()`` method to the string type. ``str.isprintable()``
>>  returns False if repr() should escape any character in the string;
>>  otherwise returns True. The ``isprintable()`` method calls the
>>  `` PY_UNICODE_ISPRINTABLE()`` function internally.
>>
>
> Quick thought, what should become of string.printable? Should it be
> renamed to string.ascii_printable or removed?
>

I agree string.ascii_printable is better name, but I'm not motivated
enough to break compatibility.

> Overall, I think the PEP is good. So, +1 from me.

Thank you!

From greg.ewing at canterbury.ac.nz  Mon Jun  2 03:21:57 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 02 Jun 2008 13:21:57 +1200
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
 Python 3000
In-Reply-To: <797440730806011632o76e5dcferca8b6c4dc015a4bf@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<fb6fbf560805261806j7b79e776i3361a655ac1d8a36@mail.gmail.com>
	<797440730805262311j6ece045apd731b4e78eacd4c5@mail.gmail.com>
	<fb6fbf560805271312g41c6b240h322c7142d1cf98be@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<797440730806010832t1137891fi8e47458b8dafb1b2@mail.gmail.com>
	<acd65fa20806011039w6a432df8lf8da163d6e173d9b@mail.gmail.com>
	<797440730806011632o76e5dcferca8b6c4dc015a4bf@mail.gmail.com>
Message-ID: <48434B35.5080400@canterbury.ac.nz>

Atsuo Ishimoto wrote:

> I'm not comfortable with "printable", too. Is "legible" better? This
> is first time for me to see this word in my life :).

The term "printable" has a long history in computing of
meaning that a character code corresponds to some visual
glyph, even if the display process involved isn't literally
printing. It would be confusing to replace it with something
else now, I think.

-- 
Greg

From collinw at gmail.com  Mon Jun  2 04:47:16 2008
From: collinw at gmail.com (Collin Winter)
Date: Sun, 1 Jun 2008 19:47:16 -0700
Subject: [Python-3000] Exception re-raising woes
In-Reply-To: <loom.20080531T012237-406@post.gmane.org>
References: <loom.20080526T091655-961@post.gmane.org>
	<loom.20080530T094609-317@post.gmane.org>
	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>
	<loom.20080531T012237-406@post.gmane.org>
Message-ID: <43aa6ff70806011947o20af27fahac889ae609cdaa7@mail.gmail.com>

On Fri, May 30, 2008 at 6:33 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Guido van Rossum <guido <at> python.org> writes:
>> I would be okay as well with restricting bare raise syntactically to
>> appearing only inside an except block, to emphasize the change in
>> semantics that was started when we decided to make the optional
>> variable disappear at the end of the except block.
>>
>> This would render the following code illegal:
>>
>> def f():
>>   try: 1/0
>>   except: pass
>>   raise
>
> But you may want to use bare raise in a function called from an exception
> handler, e.g.:
>
> def handle_exception():
>    if user() == "Albert":
>        # Albert likes his exceptions uncooked
>        raise
>    else:
>        logging.exception("an exception occurred")
>
> def f():
>    try:
>        raise KeyError
>    except:
>        handle_exception()

I think it's perfectly fine to require that such code use
sys.exc_info() or have the exception information passed in. The latter
is more testable and more readable, in any case.

Collin

From collinw at gmail.com  Mon Jun  2 04:52:48 2008
From: collinw at gmail.com (Collin Winter)
Date: Sun, 1 Jun 2008 19:52:48 -0700
Subject: [Python-3000] sys.exc_info()
In-Reply-To: <00ab01c8c383$fb909db0$f2b1d910$@com.au>
References: <loom.20080526T091655-961@post.gmane.org>
	<loom.20080530T094609-317@post.gmane.org>
	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>
	<loom.20080531T012237-406@post.gmane.org>
	<aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com>
	<003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
	<00ab01c8c383$fb909db0$f2b1d910$@com.au>
Message-ID: <43aa6ff70806011952r4f3fdd49q7f5e0456689e90c7@mail.gmail.com>

On Sat, May 31, 2008 at 6:08 PM, Mark Hammond <mhammond at skippinet.com.au> wrote:
> Antoine:
>> Mark Hammond <mhammond <at> skippinet.com.au> writes:
>> > In both Python 2.x and 3 (a few months old build of Py3k though), the
>> > traceback isn't the same.  For Python 2.0 you could write it like:
>> >
>> > def handle_exception():
>> > ...
>> >     raise sys.exc_info()[0], sys.exc_info()[1], sys.exc_info()[2]
>> >
>> > Its not clear how that would be spelt in py3k though (and from what I
>> can
>> > see, sys.exc_info() itself has an uncertain future in py3k).
>>
>> sys.exc_info() will remain, it's just that the returned value will be
>> (None, None, None) if we are not in an except block in any of the
>> currently active frames in the thread.
>
> If I look at Guido's py3k status update of almost a year ago
> (http://www.artima.com/weblogs/viewpost.jsp?thread=208549) it tells me:
>
> * "sys.exc_info() becomes redundant (or may disappear)".  Even if it doesn't
> actually dissappear, the implication is that the new way (with the traceback
> being an attribute) will be preferred.
>
> * "The old raise syntax variants raise E, e and raise E, e, tb are gone" -
> but I can't see anything which indicates what the replacement is for the 2
> cases of (a) raising with the original traceback and (b) raising the same
> exception with a "new" traceback reflecting the position of the 'raise'-
> I admit I didn't look *that* hard though...

See PEP 3109: http://www.python.org/dev/peps/pep-3109/

Collin

From jimjjewett at gmail.com  Mon Jun  2 04:56:09 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Sun, 1 Jun 2008 22:56:09 -0400
Subject: [Python-3000] PEP: str(container) should call str(item),
	not repr(item)
In-Reply-To: <20080529195757.GB17896@phd.pp.ru>
References: <20080529192157.GA17896@phd.pp.ru>
	<ca471dc20805291231k56621365ud6b05c97f0659c01@mail.gmail.com>
	<20080529195757.GB17896@phd.pp.ru>
Message-ID: <fb6fbf560806011956r3d23b3ccv90d953c2c1d72e85@mail.gmail.com>

On 5/29/08, Oleg Broytmann <phd at phd.pp.ru> wrote:
> On Thu, May 29, 2008 at 12:31:17PM -0700, Guido van Rossum wrote:
>> ... I'm opposed to this change, and that I believe
>> that it would cause way too much
>> disturbance to be accepted this close to beta.

>    That's ok. A rejected PEP has its purpose, too.

Yes, but it might be better to defer instead.

"Too close to beta" is a strong argument, but doesn't apply to 3.1 or
3.2 -- by which time the unicode-keyed dicts or oddly-converted print
statements may change the importance.

-jJ

From musiccomposition at gmail.com  Mon Jun  2 04:58:13 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 1 Jun 2008 21:58:13 -0500
Subject: [Python-3000] PEP: str(container) should call str(item),
	not repr(item)
In-Reply-To: <fb6fbf560806011956r3d23b3ccv90d953c2c1d72e85@mail.gmail.com>
References: <20080529192157.GA17896@phd.pp.ru>
	<ca471dc20805291231k56621365ud6b05c97f0659c01@mail.gmail.com>
	<20080529195757.GB17896@phd.pp.ru>
	<fb6fbf560806011956r3d23b3ccv90d953c2c1d72e85@mail.gmail.com>
Message-ID: <1afaf6160806011958n4f53bdb8vd88668503730232b@mail.gmail.com>

On Sun, Jun 1, 2008 at 9:56 PM, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 5/29/08, Oleg Broytmann <phd at phd.pp.ru> wrote:
>> On Thu, May 29, 2008 at 12:31:17PM -0700, Guido van Rossum wrote:
>>> ... I'm opposed to this change, and that I believe
>>> that it would cause way too much
>>> disturbance to be accepted this close to beta.
>
>>    That's ok. A rejected PEP has its purpose, too.
>
> Yes, but it might be better to defer instead.
>
> "Too close to beta" is a strong argument, but doesn't apply to 3.1 or
> 3.2 -- by which time the unicode-keyed dicts or oddly-converted print
> statements may change the importance.

Notice how Guido said he's opposed to it, *and* it would cause too
much disturbance. I believe he has previously shunned this idea.



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

From dalcinl at gmail.com  Mon Jun  2 18:17:47 2008
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Mon, 2 Jun 2008 13:17:47 -0300
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>
References: <48397ECC.9070805@cheimes.de> <483BDE11.509@egenix.com>
	<483D300B.5090309@egenix.com>
	<52dc1c820805281347n75a4baax9222b75c8fa09ec5@mail.gmail.com>
	<483ECA52.6040000@egenix.com> <483ECF94.7060607@cheimes.de>
	<483EF139.8000606@egenix.com> <483F34C3.3050402@gmail.com>
	<483FBCB4.5020007@egenix.com>
	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>
Message-ID: <e7ba66e40806020917i7152bfe6l6cb1a7b48507d3a5@mail.gmail.com>

Are you completelly sure of adding those guys:  PyBytes_InternXXX ???


On 6/1/08, Gregory P. Smith <greg at krypto.org> wrote:
> On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>  > On 2008-05-30 00:57, Nick Coghlan wrote:
>  >>
>  >> M.-A. Lemburg wrote:
>  >>>
>  >>> * Why can't we have both PyString *and* PyBytes exposed in 2.x,
>  >>> with one redirecting to the other ?
>  >>
>  >> We do have that - the PyString_* names still work perfectly fine in 2.x.
>  >> They just won't be used in the Python core codebase anymore - everything in
>  >> the Python core will use either PyBytes_* or PyUnicode_* regardless of which
>  >> branch (2.x or 3.x) you're working on. I think that's a good thing for ease
>  >> of maintenance in the future, even if it takes people a while to get their
>  >> heads around it right now.
>  >
>  > Sorry, I probably wasn't clear enough:
>  >
>  > Why can't we have both PyString *and* PyBytes exposed as C
>  > APIs (ie. visible in code and in the linker) in 2.x, with one redirecting
>  > to the other ?
>  >
>  >>> * Why should the 2.x code base turn to hacks, just because 3.x wants
>  >>> to restructure itself ?
>  >>
>  >> With the better explanation from Greg of what the checked in approach
>  >> achieves (i.e. preserving exact ABI compatibility for PyString_*, while
>  >> allowing PyBytes_* to be used at the source code level), I don't see what
>  >> has been done as being any more of a hack than the possibly more common
>  >> "#define <oldname> <newname>" (which *would* break binary compatibility).
>  >>
>  >> The only things that I think would tidy it up further would be to:
>  >> - include an explanation of the approach and its effects on API and ABI
>  >> backward and forward compatibility within 2.x and between 2.x and 3.x in
>  >> stringobject.h
>  >> - expose the PyBytes_* functions to the linker in 2.6 as well as 3.0
>  >
>  > Which is what I was suggesting all along; sorry if I wasn't
>  > clear enough on that.
>  >
>  > The standard approach is that you provide #define redirects from the
>  > old APIs to the new ones (which are then picked up by the compiler)
>  > *and* add function wrappers to the same affect (to make linkers,
>  > dynamic load APIs such ctypes and debuggers happy).
>  >
>  >
>  > Example from pythonrun.h|c:
>  > ---------------------------
>  >
>  > /* Use macros for a bunch of old variants */
>  > #define PyRun_String(str, s, g, l) PyRun_StringFlags(str, s, g, l, NULL)
>  >
>  > /* Deprecated C API functions still provided for binary compatiblity */
>  >
>  > #undef PyRun_String
>  > PyAPI_FUNC(PyObject *)
>  > PyRun_String(const char *str, int s, PyObject *g, PyObject *l)
>  > {
>  >        return PyRun_StringFlags(str, s, g, l, NULL);
>  > }
>  >
>
>
> Okay, how about this?  http://codereview.appspot.com/1521
>
>  Using that patch, both PyString_ and PyBytes_ APIs are available using
>  function stubs similar to the above.  I opted to define the stub
>  functions right next to the ones they were stubbing rather than
>  putting them all at the end of the file or in another file but they
>  could be moved if someone doesn't like them that way.
>
>
>  > I still believe that we should *not* make "easy of merging" the
>  > primary motivation for backporting changes in 3.x to 2.x. Software
>  > design should not be guided by restrictions in the tool chain,
>  > if not absolutely necessary.
>  >
>  > The main argument for a backport needs to be general usefulness
>  > to the 2.x users, IMHO... just like any other feature that
>  > makes it into 2.x.
>  >
>  > If merging is difficult then this needs to be addressed, but
>  > there are more options to that than always going back to the
>  > original 2.x trunk code. I've given a few suggestions on how
>  > this could be approached in other emails on this thread.
>
>
> I am not the one doing the merging or working on merge tools so I'll
>  leave this up to those that are.
>
>  -gps
>  _______________________________________________
>  Python-Dev mailing list
>  Python-Dev at python.org
>  http://mail.python.org/mailman/listinfo/python-dev
>  Unsubscribe: http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com
>


-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

From mal at egenix.com  Mon Jun  2 14:33:08 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 02 Jun 2008 14:33:08 +0200
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>
References: <48397ECC.9070805@cheimes.de>
	<483B2D02.8040400@cheimes.de>	<483BDE11.509@egenix.com>
	<483D300B.5090309@egenix.com>	<52dc1c820805281347n75a4baax9222b75c8fa09ec5@mail.gmail.com>	<483ECA52.6040000@egenix.com>
	<483ECF94.7060607@cheimes.de>	<483EF139.8000606@egenix.com>
	<483F34C3.3050402@gmail.com>	<483FBCB4.5020007@egenix.com>
	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>
Message-ID: <4843E884.1060705@egenix.com>

On 2008-06-02 01:30, Gregory P. Smith wrote:
> On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Sorry, I probably wasn't clear enough:
>>
>> Why can't we have both PyString *and* PyBytes exposed as C
>> APIs (ie. visible in code and in the linker) in 2.x, with one redirecting
>> to the other ?
>>
>>>> * Why should the 2.x code base turn to hacks, just because 3.x wants
>>>> to restructure itself ?
>>> With the better explanation from Greg of what the checked in approach
>>> achieves (i.e. preserving exact ABI compatibility for PyString_*, while
>>> allowing PyBytes_* to be used at the source code level), I don't see what
>>> has been done as being any more of a hack than the possibly more common
>>> "#define <oldname> <newname>" (which *would* break binary compatibility).
>>>
>>> The only things that I think would tidy it up further would be to:
>>> - include an explanation of the approach and its effects on API and ABI
>>> backward and forward compatibility within 2.x and between 2.x and 3.x in
>>> stringobject.h
>>> - expose the PyBytes_* functions to the linker in 2.6 as well as 3.0
>> Which is what I was suggesting all along; sorry if I wasn't
>> clear enough on that.
>>
>> The standard approach is that you provide #define redirects from the
>> old APIs to the new ones (which are then picked up by the compiler)
>> *and* add function wrappers to the same affect (to make linkers,
>> dynamic load APIs such ctypes and debuggers happy).
>>
>>
>> Example from pythonrun.h|c:
>> ---------------------------
>>
>> /* Use macros for a bunch of old variants */
>> #define PyRun_String(str, s, g, l) PyRun_StringFlags(str, s, g, l, NULL)
>>
>> /* Deprecated C API functions still provided for binary compatiblity */
>>
>> #undef PyRun_String
>> PyAPI_FUNC(PyObject *)
>> PyRun_String(const char *str, int s, PyObject *g, PyObject *l)
>> {
>>        return PyRun_StringFlags(str, s, g, l, NULL);
>> }
>>
> 
> Okay, how about this?  http://codereview.appspot.com/1521
> 
> Using that patch, both PyString_ and PyBytes_ APIs are available using
> function stubs similar to the above.  I opted to define the stub
> functions right next to the ones they were stubbing rather than
> putting them all at the end of the file or in another file but they
> could be moved if someone doesn't like them that way.

Thanks. I was working on a similar patch. Looks like you beat
me to it.

The only thing I'm not sure about is having the wrappers in the
same file - this is likely to cause merge conflicts when doing
direct merging and even with an automated renaming approach,
the extra code would be easier to remove if it were e.g. at
the end of the file or even better: in a separate file.

My patch worked slightly differently: it adds wrappers PyString*
that forward calls to the PyBytes* APIs and they all live in
stringobject.c. stringobject.h then also provides aliases
so that recompiled extensions pick up the new API names.

While working on my patch I ran into an issue that I haven't
been able to resolve: the wrapper functions got optimized away
by the linker and even though they appear in the libpython2.6.a,
they don't end up in the python binary itself.

As a result, importing Python 2.5 in the resulting 2.6
binary still fails with a unresolved PyString symbol.

Please check whether that's the case for your patch as well.

>> I still believe that we should *not* make "easy of merging" the
>> primary motivation for backporting changes in 3.x to 2.x. Software
>> design should not be guided by restrictions in the tool chain,
>> if not absolutely necessary.
>>
>> The main argument for a backport needs to be general usefulness
>> to the 2.x users, IMHO... just like any other feature that
>> makes it into 2.x.
>>
>> If merging is difficult then this needs to be addressed, but
>> there are more options to that than always going back to the
>> original 2.x trunk code. I've given a few suggestions on how
>> this could be approached in other emails on this thread.
> 
> I am not the one doing the merging or working on merge tools so I'll
> leave this up to those that are.

I'm not sure whether there are any specific merge tools around -
apart from the 2to3.py script.

There also doesn't seem to be any documentation on the merge
process itself (at least nothing that Google can find in the
PEPs), so it's difficult to make any suggestions.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 02 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/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            34 days to go

:::: 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 greg at krypto.org  Tue Jun  3 00:21:18 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Mon, 2 Jun 2008 15:21:18 -0700
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <4843E884.1060705@egenix.com>
References: <48397ECC.9070805@cheimes.de> <483D300B.5090309@egenix.com>
	<52dc1c820805281347n75a4baax9222b75c8fa09ec5@mail.gmail.com>
	<483ECA52.6040000@egenix.com> <483ECF94.7060607@cheimes.de>
	<483EF139.8000606@egenix.com> <483F34C3.3050402@gmail.com>
	<483FBCB4.5020007@egenix.com>
	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>
	<4843E884.1060705@egenix.com>
Message-ID: <52dc1c820806021521g810d9f1wd282508f8452c13@mail.gmail.com>

On Mon, Jun 2, 2008 at 5:33 AM, M.-A. Lemburg <mal at egenix.com> wrote:

>
>> Okay, how about this?  http://codereview.appspot.com/1521
>>
>> Using that patch, both PyString_ and PyBytes_ APIs are available using
>> function stubs similar to the above.  I opted to define the stub
>> functions right next to the ones they were stubbing rather than
>> putting them all at the end of the file or in another file but they
>> could be moved if someone doesn't like them that way.
>>
>
> Thanks. I was working on a similar patch. Looks like you beat
> me to it.
>
> The only thing I'm not sure about is having the wrappers in the
> same file - this is likely to cause merge conflicts when doing
> direct merging and even with an automated renaming approach,
> the extra code would be easier to remove if it were e.g. at
> the end of the file or even better: in a separate file.
>
> My patch worked slightly differently: it adds wrappers PyString*
> that forward calls to the PyBytes* APIs and they all live in
> stringobject.c. stringobject.h then also provides aliases
> so that recompiled extensions pick up the new API names.
>
> While working on my patch I ran into an issue that I haven't
> been able to resolve: the wrapper functions got optimized away
> by the linker and even though they appear in the libpython2.6.a,
> they don't end up in the python binary itself.
>
> As a result, importing Python 2.5 in the resulting 2.6
> binary still fails with a unresolved PyString symbol.
>
> Please check whether that's the case for your patch as well.


I think that is going to happen no matter which approach is used (yours or
mine) unless we force some included code to call each of the stubs
(needlessly inefficient).  One way to do that is to reference them all from
a section of code called conditionally based upon an always false condition
that the compiler and linker can never predetermine is false so that it
cannot be eliminated as dead code.

Given that, should we bother?  I don't think we really need PyBytes_ to show
up in the binary ABI for 2.x even if that is how we write the calls in the
python internals code.  The arguments put forth that debugging is easier if
you can just set a breakpoint on what you read may be true but including
stub functions doesn't help this when most of the time they're compiled
under the alternate name using #defines so a breakpoint set on the stub name
will not actually trigger.

API wise we're really providing the PyBytes* names to make module author's
work of writing code that targets 2.6 and 3.x easier but isn't it reasonable
for authors to just be told that they're just #defined aliases for
PyString*.  There is no goal, nor should there be, of a module binary
compiled against 2.x loading and working in 3.x.

I expect most module authors, code generators and such will want to target
Python 2.x earlier than 2.6 as well so should we provide PyBytes_ names as a
public API in 2.6 at all?  (regardless of if we use the PyBytes names
internally for any reason)

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080602/31760a87/attachment-0001.htm>

From guido at python.org  Tue Jun  3 00:30:11 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 2 Jun 2008 15:30:11 -0700
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <48434B35.5080400@canterbury.ac.nz>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<fb6fbf560805271312g41c6b240h322c7142d1cf98be@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<797440730806010832t1137891fi8e47458b8dafb1b2@mail.gmail.com>
	<acd65fa20806011039w6a432df8lf8da163d6e173d9b@mail.gmail.com>
	<797440730806011632o76e5dcferca8b6c4dc015a4bf@mail.gmail.com>
	<48434B35.5080400@canterbury.ac.nz>
Message-ID: <ca471dc20806021530m5582205fqe0a02e9d4161e295@mail.gmail.com>

On Sun, Jun 1, 2008 at 6:21 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Atsuo Ishimoto wrote:
>
>> I'm not comfortable with "printable", too. Is "legible" better? This
>> is first time for me to see this word in my life :).
>
> The term "printable" has a long history in computing of
> meaning that a character code corresponds to some visual
> glyph, even if the display process involved isn't literally
> printing. It would be confusing to replace it with something
> else now, I think.

Agreed. I'm +1 on everything the PEP specifies. I'll accept it
tomorrow. Other developers, please review Atsuo's patch in
http://bugs.python.org/issue2630 .

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

From stephen at xemacs.org  Mon Jun  2 07:47:59 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 02 Jun 2008 14:47:59 +0900
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation
	in	Python 3000
In-Reply-To: <797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<fb6fbf560805261806j7b79e776i3361a655ac1d8a36@mail.gmail.com>
	<797440730805262311j6ece045apd731b4e78eacd4c5@mail.gmail.com>
	<fb6fbf560805271312g41c6b240h322c7142d1cf98be@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
Message-ID: <87fxrwe6b4.fsf@uwakimon.sk.tsukuba.ac.jp>

Atsuo Ishimoto writes:

 > Okay, we'll keep 'strict' as default error handler for stdout always,
 > then. I can live with it.
 > But, my $0.02, I expect this issue will be revisited after people
 > start to develop real applications with Python 3.x.

I agree, I expect it to be revisited too.  But in the meantime

 -  people who need it will have an obvious signal that they need it,
 -  it will be obvious to people who know what's going on how to fix it,
 -  and when the experience needed to decide what use cases matter and
    which ones are subject to confusion of the kind Guido mentions
    accumulates, and it gets changed, programs that previously did not
    throw an error will continue to work as they did.


From barry at python.org  Tue Jun  3 00:51:46 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 2 Jun 2008 18:51:46 -0400
Subject: [Python-3000] Postponing the first betas
Message-ID: <06BB1BB8-2C9C-4588-9B38-49DE234752E0@python.org>

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

We are going to postpone the first beta releases by one week.  We had  
some problems with mail.python.org today, which prompted a query to  
Guido from me about the postponement.  mail.python.org should now be  
back up normally now, as evidenced by the emailfloodl but in the  
meantime, Guido said:

"I'd also like to see PEP 3138 (CJK-friendly repr()) and the
pyprocessing PEP implemented by then, and perhaps some other small
stuff."

So we're going to do the first beta releases next Wednesday, June 11.   
Please take this time to stabilize all APIs and features, both in  
Python and C.  Next week, I'll do a gut check on critical and release  
blocker bugs, so please also take a look at those and try to fix what  
you can.

Cheers,
- -Barry

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

iQCVAwUBSER5gnEjvBPtnXfVAQJlBAQAgfmRwGQzwNFrwvMusIoDNVRuyIObkKO0
FeDYb26RAL1jLXt0x/7jE0fBc5FvhDzUJnnNj3sydfyKU5MCb0eB0VeBTmjHU05l
yncX6zYSoU14OUW+bkG4y7vf+aLD9zlFsj/ybMEZTQh0RMpZ+HBNhup3NJFEDTBM
97q4SIvltAg=
=NBRW
-----END PGP SIGNATURE-----

From dalcinl at gmail.com  Tue Jun  3 01:00:05 2008
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Mon, 2 Jun 2008 20:00:05 -0300
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <52dc1c820806021522u77e94406q7575a34bcaee79c1@mail.gmail.com>
References: <48397ECC.9070805@cheimes.de>
	<52dc1c820805281347n75a4baax9222b75c8fa09ec5@mail.gmail.com>
	<483ECA52.6040000@egenix.com> <483ECF94.7060607@cheimes.de>
	<483EF139.8000606@egenix.com> <483F34C3.3050402@gmail.com>
	<483FBCB4.5020007@egenix.com>
	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>
	<e7ba66e40806020917i7152bfe6l6cb1a7b48507d3a5@mail.gmail.com>
	<52dc1c820806021522u77e94406q7575a34bcaee79c1@mail.gmail.com>
Message-ID: <e7ba66e40806021600n1947075di85c5218aacad31ce@mail.gmail.com>

On 6/2/08, Gregory P. Smith <greg at krypto.org> wrote:
> I believe those APIs are already there in the existing interface.  Why does
> that concern you?

Just because PyBytes_InternXXX are not in Py3K C API. Iff the whole
point of this patch is easier merges, then I believe there is a
problem here. Please note I'm definitely +1 for your patch, but the
string interning API seems to need a bit more of care. Am I wrong?

>
>
> On Mon, Jun 2, 2008 at 9:17 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>
> > Are you completelly sure of adding those guys:  PyBytes_InternXXX ???
> >
> >
> >
> >
> >
> > On 6/1/08, Gregory P. Smith <greg at krypto.org> wrote:
> > > On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> > >  > On 2008-05-30 00:57, Nick Coghlan wrote:
> > >  >>
> > >  >> M.-A. Lemburg wrote:
> > >  >>>
> > >  >>> * Why can't we have both PyString *and* PyBytes exposed in 2.x,
> > >  >>> with one redirecting to the other ?
> > >  >>
> > >  >> We do have that - the PyString_* names still work perfectly fine in
> 2.x.
> > >  >> They just won't be used in the Python core codebase anymore -
> everything in
> > >  >> the Python core will use either PyBytes_* or PyUnicode_* regardless
> of which
> > >  >> branch (2.x or 3.x) you're working on. I think that's a good thing
> for ease
> > >  >> of maintenance in the future, even if it takes people a while to get
> their
> > >  >> heads around it right now.
> > >  >
> > >  > Sorry, I probably wasn't clear enough:
> > >  >
> > >  > Why can't we have both PyString *and* PyBytes exposed as C
> > >  > APIs (ie. visible in code and in the linker) in 2.x, with one
> redirecting
> > >  > to the other ?
> > >  >
> > >  >>> * Why should the 2.x code base turn to hacks, just because 3.x
> wants
> > >  >>> to restructure itself ?
> > >  >>
> > >  >> With the better explanation from Greg of what the checked in
> approach
> > >  >> achieves (i.e. preserving exact ABI compatibility for PyString_*,
> while
> > >  >> allowing PyBytes_* to be used at the source code level), I don't see
> what
> > >  >> has been done as being any more of a hack than the possibly more
> common
> > >  >> "#define <oldname> <newname>" (which *would* break binary
> compatibility).
> > >  >>
> > >  >> The only things that I think would tidy it up further would be to:
> > >  >> - include an explanation of the approach and its effects on API and
> ABI
> > >  >> backward and forward compatibility within 2.x and between 2.x and
> 3.x in
> > >  >> stringobject.h
> > >  >> - expose the PyBytes_* functions to the linker in 2.6 as well as 3.0
> > >  >
> > >  > Which is what I was suggesting all along; sorry if I wasn't
> > >  > clear enough on that.
> > >  >
> > >  > The standard approach is that you provide #define redirects from the
> > >  > old APIs to the new ones (which are then picked up by the compiler)
> > >  > *and* add function wrappers to the same affect (to make linkers,
> > >  > dynamic load APIs such ctypes and debuggers happy).
> > >  >
> > >  >
> > >  > Example from pythonrun.h|c:
> > >  > ---------------------------
> > >  >
> > >  > /* Use macros for a bunch of old variants */
> > >  > #define PyRun_String(str, s, g, l) PyRun_StringFlags(str, s, g, l,
> NULL)
> > >  >
> > >  > /* Deprecated C API functions still provided for binary compatiblity
> */
> > >  >
> > >  > #undef PyRun_String
> > >  > PyAPI_FUNC(PyObject *)
> > >  > PyRun_String(const char *str, int s, PyObject *g, PyObject *l)
> > >  > {
> > >  >        return PyRun_StringFlags(str, s, g, l, NULL);
> > >  > }
> > >  >
> > >
> > >
> > > Okay, how about this?
> http://codereview.appspot.com/1521
> > >
> > >  Using that patch, both PyString_ and PyBytes_ APIs are available using
> > >  function stubs similar to the above.  I opted to define the stub
> > >  functions right next to the ones they were stubbing rather than
> > >  putting them all at the end of the file or in another file but they
> > >  could be moved if someone doesn't like them that way.
> > >
> > >
> > >  > I still believe that we should *not* make "easy of merging" the
> > >  > primary motivation for backporting changes in 3.x to 2.x. Software
> > >  > design should not be guided by restrictions in the tool chain,
> > >  > if not absolutely necessary.
> > >  >
> > >  > The main argument for a backport needs to be general usefulness
> > >  > to the 2.x users, IMHO... just like any other feature that
> > >  > makes it into 2.x.
> > >  >
> > >  > If merging is difficult then this needs to be addressed, but
> > >  > there are more options to that than always going back to the
> > >  > original 2.x trunk code. I've given a few suggestions on how
> > >  > this could be approached in other emails on this thread.
> > >
> > >
> > > I am not the one doing the merging or working on merge tools so I'll
> > >  leave this up to those that are.
> > >
> > >  -gps
> > >  _______________________________________________
> > >  Python-Dev mailing list
> > >  Python-Dev at python.org
> > >  http://mail.python.org/mailman/listinfo/python-dev
> > >  Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com
> >
> >
> >
> > >
> >
> >
> > --
> > Lisandro Dalc?n
> > ---------------
> > Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
> > Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
> > Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
> > PTLC - G?emes 3450, (3000) Santa Fe, Argentina
> > Tel/Fax: +54-(0)342-451.1594
> >
>
>


-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

From guido at python.org  Tue Jun  3 01:09:18 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 2 Jun 2008 16:09:18 -0700
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <52dc1c820806021521g810d9f1wd282508f8452c13@mail.gmail.com>
References: <48397ECC.9070805@cheimes.de>
	<52dc1c820805281347n75a4baax9222b75c8fa09ec5@mail.gmail.com>
	<483ECA52.6040000@egenix.com> <483ECF94.7060607@cheimes.de>
	<483EF139.8000606@egenix.com> <483F34C3.3050402@gmail.com>
	<483FBCB4.5020007@egenix.com>
	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>
	<4843E884.1060705@egenix.com>
	<52dc1c820806021521g810d9f1wd282508f8452c13@mail.gmail.com>
Message-ID: <ca471dc20806021609v258d7e8bk66b259694dd469b5@mail.gmail.com>

I will freely admit that I haven't followed this thread in any detail,
but if it were up to me, I'd have the 2.6 internal code use PyString
(as both what the linker sees and what the human reads in the source
code) and the 3.0 code use PyBytes for the same thing. Let the merges
be damed -- most changes to 2.6 these days seem to be blocked
explicitly from being merged anyway. I'd prefer the 2.6 code base to
stay true to 2.x, and the 3.0 code base start afresh where it makes
sense. We should reindent more of the 3.0 code base to use
4-space-indents in C code too.

I would also add macros that map the PyBytes_* APIs to PyString_*, but
I would not start using these internally except in code newly written
for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString
for 8-bit strings containing text, and PyBytes for 8-bit strings
containing binary data. For 8-bit strings that could contain either
text or data, I'd use PyString, in the spirit of 2.x.

--Guido

On Mon, Jun 2, 2008 at 3:21 PM, Gregory P. Smith <greg at krypto.org> wrote:
>
>
> On Mon, Jun 2, 2008 at 5:33 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>
>>> Okay, how about this?  http://codereview.appspot.com/1521
>>>
>>> Using that patch, both PyString_ and PyBytes_ APIs are available using
>>> function stubs similar to the above.  I opted to define the stub
>>> functions right next to the ones they were stubbing rather than
>>> putting them all at the end of the file or in another file but they
>>> could be moved if someone doesn't like them that way.
>>
>> Thanks. I was working on a similar patch. Looks like you beat
>> me to it.
>>
>> The only thing I'm not sure about is having the wrappers in the
>> same file - this is likely to cause merge conflicts when doing
>> direct merging and even with an automated renaming approach,
>> the extra code would be easier to remove if it were e.g. at
>> the end of the file or even better: in a separate file.
>>
>> My patch worked slightly differently: it adds wrappers PyString*
>> that forward calls to the PyBytes* APIs and they all live in
>> stringobject.c. stringobject.h then also provides aliases
>> so that recompiled extensions pick up the new API names.
>>
>> While working on my patch I ran into an issue that I haven't
>> been able to resolve: the wrapper functions got optimized away
>> by the linker and even though they appear in the libpython2.6.a,
>> they don't end up in the python binary itself.
>>
>> As a result, importing Python 2.5 in the resulting 2.6
>> binary still fails with a unresolved PyString symbol.
>>
>> Please check whether that's the case for your patch as well.
>
> I think that is going to happen no matter which approach is used (yours or
> mine) unless we force some included code to call each of the stubs
> (needlessly inefficient).  One way to do that is to reference them all from
> a section of code called conditionally based upon an always false condition
> that the compiler and linker can never predetermine is false so that it
> cannot be eliminated as dead code.
>
> Given that, should we bother?  I don't think we really need PyBytes_ to show
> up in the binary ABI for 2.x even if that is how we write the calls in the
> python internals code.  The arguments put forth that debugging is easier if
> you can just set a breakpoint on what you read may be true but including
> stub functions doesn't help this when most of the time they're compiled
> under the alternate name using #defines so a breakpoint set on the stub name
> will not actually trigger.
>
> API wise we're really providing the PyBytes* names to make module author's
> work of writing code that targets 2.6 and 3.x easier but isn't it reasonable
> for authors to just be told that they're just #defined aliases for
> PyString*.  There is no goal, nor should there be, of a module binary
> compiled against 2.x loading and working in 3.x.
>
> I expect most module authors, code generators and such will want to target
> Python 2.x earlier than 2.6 as well so should we provide PyBytes_ names as a
> public API in 2.6 at all?  (regardless of if we use the PyBytes names
> internally for any reason)
>
> -gps
>
>
> _______________________________________________
> 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/guido%40python.org
>
>



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

From greg at krypto.org  Tue Jun  3 01:29:16 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Mon, 2 Jun 2008 16:29:16 -0700
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <ca471dc20806021609v258d7e8bk66b259694dd469b5@mail.gmail.com>
References: <48397ECC.9070805@cheimes.de> <483ECA52.6040000@egenix.com>
	<483ECF94.7060607@cheimes.de> <483EF139.8000606@egenix.com>
	<483F34C3.3050402@gmail.com> <483FBCB4.5020007@egenix.com>
	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>
	<4843E884.1060705@egenix.com>
	<52dc1c820806021521g810d9f1wd282508f8452c13@mail.gmail.com>
	<ca471dc20806021609v258d7e8bk66b259694dd469b5@mail.gmail.com>
Message-ID: <52dc1c820806021629k5491e8c0u67e8a6f5247d2368@mail.gmail.com>

On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <guido at python.org> wrote:

> I will freely admit that I haven't followed this thread in any detail,
> but if it were up to me, I'd have the 2.6 internal code use PyString

...

Should we read this as a BDFL pronouncement and make it so?

All that would mean change wise is that trunk r63675 as well as possibly
r63672 and r63677 would need to be rolled back and this whole discussion
over if such a big change should have happened would turn into a moot point.

I would also add macros that map the PyBytes_* APIs to PyString_*, but
> I would not start using these internally except in code newly written
> for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString
> for 8-bit strings containing text, and PyBytes for 8-bit strings
> containing binary data. For 8-bit strings that could contain either
> text or data, I'd use PyString, in the spirit of 2.x.
>
> --Guido
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080602/f9efc82e/attachment-0001.htm>

From ishimoto at gembook.org  Tue Jun  3 01:35:48 2008
From: ishimoto at gembook.org (Atsuo Ishimoto)
Date: Tue, 3 Jun 2008 08:35:48 +0900
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <ca471dc20806021530m5582205fqe0a02e9d4161e295@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<797440730806010832t1137891fi8e47458b8dafb1b2@mail.gmail.com>
	<acd65fa20806011039w6a432df8lf8da163d6e173d9b@mail.gmail.com>
	<797440730806011632o76e5dcferca8b6c4dc015a4bf@mail.gmail.com>
	<48434B35.5080400@canterbury.ac.nz>
	<ca471dc20806021530m5582205fqe0a02e9d4161e295@mail.gmail.com>
Message-ID: <797440730806021635u64184235w24ecc8e87094f03e@mail.gmail.com>

On Tue, Jun 3, 2008 at 7:30 AM, Guido van Rossum <guido at python.org> wrote:
> On Sun, Jun 1, 2008 at 6:21 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> Atsuo Ishimoto wrote:
>>
>>> I'm not comfortable with "printable", too. Is "legible" better? This
>>> is first time for me to see this word in my life :).
>>
>> The term "printable" has a long history in computing of
>> meaning that a character code corresponds to some visual
>> glyph, even if the display process involved isn't literally
>> printing. It would be confusing to replace it with something
>> else now, I think.
>
> Agreed. I'm +1 on everything the PEP specifies. I'll accept it
> tomorrow. Other developers, please review Atsuo's patch in
> http://bugs.python.org/issue2630 .
>


Thank you!

Mark Summerfield suggested to add "!a" conversion flag to the
str.format() method. I'll add  the conversion flag to the patch and
PEP later today.

From brett at python.org  Tue Jun  3 02:22:51 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 2 Jun 2008 17:22:51 -0700
Subject: [Python-3000] Postponing the first betas
In-Reply-To: <06BB1BB8-2C9C-4588-9B38-49DE234752E0@python.org>
References: <06BB1BB8-2C9C-4588-9B38-49DE234752E0@python.org>
Message-ID: <bbaeab100806021722x7682841du7b10501b41db935@mail.gmail.com>

On Mon, Jun 2, 2008 at 3:51 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We are going to postpone the first beta releases by one week.  We had some
> problems with mail.python.org today, which prompted a query to Guido from me
> about the postponement.  mail.python.org should now be back up normally now,
> as evidenced by the emailfloodl but in the meantime, Guido said:
>
> "I'd also like to see PEP 3138 (CJK-friendly repr()) and the
> pyprocessing PEP implemented by then, and perhaps some other small
> stuff."
>
> So we're going to do the first beta releases next Wednesday, June 11.
>  Please take this time to stabilize all APIs and features, both in Python
> and C.  Next week, I'll do a gut check on critical and release blocker bugs,
> so please also take a look at those and try to fix what you can.
>

Now is as good a time as any to mention that on Wednesday I am flying
out to help my mother move. I don't know when she is going to have her
Internet connection set up, so I might not be back online until June
16. But thanks to all the help I have been receiving on PEP 3108, I
trust the various people involved to continue to do the right thing in
my absence.

-Brett

From musiccomposition at gmail.com  Tue Jun  3 02:26:22 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Mon, 2 Jun 2008 19:26:22 -0500
Subject: [Python-3000] Postponing the first betas
In-Reply-To: <bbaeab100806021722x7682841du7b10501b41db935@mail.gmail.com>
References: <06BB1BB8-2C9C-4588-9B38-49DE234752E0@python.org>
	<bbaeab100806021722x7682841du7b10501b41db935@mail.gmail.com>
Message-ID: <1afaf6160806021726w2ed8d453p9467ee006b90aaee@mail.gmail.com>

On Mon, Jun 2, 2008 at 7:22 PM, Brett Cannon <brett at python.org> wrote:
>>
>
> Now is as good a time as any to mention that on Wednesday I am flying
> out to help my mother move. I don't know when she is going to have her
> Internet connection set up, so I might not be back online until June
> 16. But thanks to all the help I have been receiving on PEP 3108, I
> trust the various people involved to continue to do the right thing in
> my absence.

That reminds me of those Dilbert cartoons where his mother ends up
knowing much more about computers than he does. :)

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

From fdrake at acm.org  Tue Jun  3 04:56:56 2008
From: fdrake at acm.org (Fred Drake)
Date: Mon, 2 Jun 2008 22:56:56 -0400
Subject: [Python-3000] sys.exc_info()
In-Reply-To: <B4AA5F22A030498192994F8C4D6CA856@ryoko>
References: <loom.20080526T091655-961@post.gmane.org>	<loom.20080530T094609-317@post.gmane.org>	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>	<loom.20080531T012237-406@post.gmane.org><aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com><003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
	<B4AA5F22A030498192994F8C4D6CA856@ryoko>
Message-ID: <44F57FF6-1DC0-4956-942B-3ABE5B6F9F34@acm.org>

On May 31, 2008, at 6:42 PM, Tim Delaney wrote:
> This reminds me of something I've thought a few times - maybe the  
> tuple returned from sys.exc_info() should be a named tuple.

+1


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From rhamph at gmail.com  Tue Jun  3 05:16:25 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Mon, 2 Jun 2008 21:16:25 -0600
Subject: [Python-3000] sys.exc_info()
In-Reply-To: <44F57FF6-1DC0-4956-942B-3ABE5B6F9F34@acm.org>
References: <loom.20080526T091655-961@post.gmane.org>
	<loom.20080530T094609-317@post.gmane.org>
	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>
	<loom.20080531T012237-406@post.gmane.org>
	<aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com>
	<003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
	<B4AA5F22A030498192994F8C4D6CA856@ryoko>
	<44F57FF6-1DC0-4956-942B-3ABE5B6F9F34@acm.org>
Message-ID: <aac2c7cb0806022016y2eca9504gdb94ec4e9ecfccdd@mail.gmail.com>

On Mon, Jun 2, 2008 at 8:56 PM, Fred Drake <fdrake at acm.org> wrote:
> On May 31, 2008, at 6:42 PM, Tim Delaney wrote:
>>
>> This reminds me of something I've thought a few times - maybe the tuple
>> returned from sys.exc_info() should be a named tuple.
>
> +1

It should be replaced with a function that returns only the value -
type and traceback are both redundant now.  I don't think anything's
been proposed yet though.

-- 
Adam Olsen, aka Rhamphoryncus

From rasky at develer.com  Tue Jun  3 02:00:15 2008
From: rasky at develer.com (Giovanni Bajo)
Date: Tue, 3 Jun 2008 00:00:15 +0000 (UTC)
Subject: [Python-3000] -t command line option
Message-ID: <g221ie$97s$1@ger.gmane.org>

Hello,

Python 3.0 defaults to "-tt" (error on inconsistent usage of tab and 
spaces). Then: why is there still a "-t" and "-tt" command line option? 
Is just a relic that should be removed?

Thanks!
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com


From stefan_ml at behnel.de  Mon Jun  2 21:15:31 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 02 Jun 2008 21:15:31 +0200
Subject: [Python-3000] Single buffer implied in new buffer protocol?
In-Reply-To: <g1odf8$ga8$1@ger.gmane.org>
References: <g1675f$hf4$1@ger.gmane.org>
	<g1hvto$kh3$1@ger.gmane.org>	<g1lhlt$988$1@ger.gmane.org>
	<g1odf8$ga8$1@ger.gmane.org>
Message-ID: <g21grh$j4k$1@ger.gmane.org>

Travis Oliphant wrote:
> This should be clarified in the PEP.  Can you take a stab at it?

Would this work?

Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pep-3113-locking.patch
Type: text/x-patch
Size: 8527 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080602/a8a604e5/attachment-0001.bin>

From stefan_ml at behnel.de  Mon Jun  2 14:38:05 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 2 Jun 2008 12:38:05 +0000 (UTC)
Subject: [Python-3000] Single buffer implied in new buffer protocol?
References: <g1675f$hf4$1@ger.gmane.org> <g1hvto$kh3$1@ger.gmane.org>
	<g1lhlt$988$1@ger.gmane.org> <g1odf8$ga8$1@ger.gmane.org>
Message-ID: <loom.20080602T122726-345@post.gmane.org>

Travis Oliphant <oliphant.travis <at> ieee.org> writes:
> This should be clarified in the PEP.  Can you take a stab at it?

Here's a patch for what I think the locking protocol part should look like. It
changes the "passing NULL as Py_buffer" bit into a requirement to always pass a
Py_buffer structure, and distinguishes the two cases where you set LOCK and pass
either a NULL buf pointer or a valid buf pointer into getbuffer.

It also adds a new UNLOCK flag for an explicit unlock without invalidating the
Py_buffer view. The idea it that the provider can (!) decide to return different
buffers for locked and non-locked access and can switch between the two during a
call to getbuffer. That matches the existing section about copying buffers
somewhere near the end.

Stefan


Index: pep-3118.txt
===================================================================
--- pep-3118.txt	(Revision 63861)
+++ pep-3118.txt	(Arbeitskopie)
@@ -153,10 +153,8 @@
 
 This function returns ``0`` on success and ``-1`` on failure (and raises an
 error). The first variable is the "exporting" object.  The second
-argument is the address to a bufferinfo structure.  If view is ``NULL``,
-then no information is returned but a lock on the memory is still
-obtained.  In this case, the corresponding releasebuffer should also
-be called with ``NULL``.  
+argument is the address to a bufferinfo structure.  Both arguments must
+never be NULL.
 
 The third argument indicates what kind of buffer the consumer is
 prepared to deal with and therefore what kind of buffer the exporter
@@ -178,6 +176,19 @@
 structure (with defaults or NULLs if nothing else is requested). The
 PyBuffer_FillInfo function can be used for simple cases.
 
+The second function is called to release the Py_buffer view, which may
+allow the provider to clean up the buffer itself::
+
+    typedef void (*releasebufferproc)(Py_buffer *view)
+
+Any existing lock on the buffer will be released by this call.  The
+Py_buffer struct will be invalidated and can no longer be used by the
+caller.
+
+
+Access flags
+------------
+
 Some flags are useful for requesting a specific kind of memory
 segment, while others indicate to the exporter what kind of
 information the consumer can deal with.  If certain information is not
@@ -185,14 +196,6 @@
 without that information, then a ``PyErr_BufferError`` should be raised.
 
 
-``PyBUF_SIMPLE``
-
-   This is the default flag state (0). The returned buffer may or may
-   not have writable memory.  The format will be assumed to be
-   unsigned bytes .  This is a "stand-alone" flag constant.  It never
-   needs to be \|'d to the others.  The exporter will raise an error if
-   it cannot provide such a contiguous buffer of bytes.
-
 ``PyBUF_WRITABLE``
 
    The returned buffer must be writable.  If it is not writable,
@@ -221,6 +224,54 @@
    necessary (especially the exclusive write lock) as it makes the
    object unable to share its memory until the lock is released.
 
+   The ``PyBUF_LOCK`` flag is the only case where a Py_buffer struct
+   with an initialised ``buf`` field can be passed.  This enables two
+   general locking cases:
+
+   * lock a new buffer: The caller requests a lock at the same time as
+     requesting the buffer (i.e. ``buf`` is NULL), in an atomic
+     operation.
+
+   * lock an existing buffer: The caller has already received a buffer
+     view and now wants to gain a lock on the existing buffer (i.e.
+     ``buf`` is a valid buffer pointer).  Note that the provider is
+     free to change the ``buf`` pointer during this call, so the
+     previously used buffer may become invalid.
+
+   If the call succeeds, this means that the consumer now has the
+   exclusive requested rights on the buffer.  The lock can be released
+   by either calling ``releasebuffer`` on the Py_buffer, or by
+   explicitly releasing the lock in a subsequent call to ``getbuffer``
+   that sets the ``PyBUF_UNLOCK`` flag.
+
+``PyBUF_UNLOCK``
+
+   This flag requests to release the lock on an existing buffer, while
+   keeping the Py_buffer view alive.  The ``buf`` field must be
+   initialised by a previous call to ``getbuffer`` and should have
+   been locked before (if is not an error if the buffer is not
+   currently locked).  Similar to the LOCK call, the provider may
+   decide to change the ``buf`` field in this case, so the previous
+   buffer may become invalid.
+
+   The provider is free to ignore any flags except for the WRITABLE
+   flag, so the caller cannot request a new buffer layout with an
+   UNLOCK call.  If the WRITABLE flag is set, only an existing
+   exclusive write lock will be released, but an existing read lock
+   will be kept.  No new locks can be acquired with an UNLOCK call.
+
+
+Memory layout flags
+-------------------
+
+``PyBUF_SIMPLE``
+
+   This is the default flag state (0). The returned buffer may or may
+   not have writable memory.  The format will be assumed to be
+   unsigned bytes .  This is a "stand-alone" flag constant.  It never
+   needs to be \|'d to the others.  The exporter will raise an error if
+   it cannot provide such a contiguous buffer of bytes.
+
 ``PyBUF_FORMAT``
         
    The returned buffer must have true format information if this flag
@@ -256,7 +307,6 @@
    All of these flags imply PyBUF_STRIDES and guarantee that the
    strides buffer info structure will be filled in correctly. 
 
-
 ``PyBUF_INDIRECT`` (implies ``PyBUF_STRIDES``)
 
    The returned buffer must have suboffsets information (which can be
@@ -307,6 +357,10 @@
 buffer info structure correctly according to the provided flags if a
 contiguous chunk of "unsigned bytes" is all that can be exported.
 
+
+The Py_buffer struct
+--------------------
+
 The bufferinfo structure is::
 
   struct bufferinfo {
@@ -322,14 +376,15 @@
        void *internal;
   } Py_buffer;
 
-Before calling the bf_getbuffer function, the bufferinfo structure can be 
-filled with whatever.  Upon return from bf_getbuffer, the bufferinfo
-structure is filled in with relevant information about the buffer.
-This same bufferinfo structure must be passed to bf_releasebuffer (if
-available) when the consumer is done with the memory. The caller is
-responsible for keeping a reference to obj until releasebuffer is
-called (i.e. the call to bf_getbuffer does not alter the reference
-count of obj).
+Before calling the bf_getbuffer function, the bufferinfo structure can
+be filled with whatever, but the ``buf`` field must be NULL when
+requesting a new buffer.  Upon return from bf_getbuffer, the
+bufferinfo structure is filled in with relevant information about the
+buffer.  This same bufferinfo structure must be passed to
+bf_releasebuffer (if available) when the consumer is done with the
+memory. The caller is responsible for keeping a reference to obj until
+releasebuffer is called (i.e. the call to bf_getbuffer does not alter
+the reference count of obj).
 
 The members of the bufferinfo structure are:
 
@@ -344,13 +399,13 @@
 ``readonly``
     an integer variable to hold whether or not the memory is readonly.
     1 means the memory is readonly, zero means the memory is writable,
-    -1 means the memory was read "locked" when this Py_buffer
-    structure was filled-in therefore should be unlocked when this
-    Py_buffer structure is "released." A -2 means this Py_buffer
-    structure has an exclusive-write lock on the memory.  This should
-    be unlocked when the Py_buffer structure is released.  The concept
-    of locking is not supported by all objects that expose the buffer 
-    protocol. 
+    -1 means the memory was read "locked" either when this Py_buffer
+    structure was filled-in or later on with an explicit LOCK flag,
+    therefore should be unlocked when this Py_buffer structure is
+    "released".  A -2 means this Py_buffer structure has an
+    exclusive-write lock on the memory.  This should be unlocked when
+    the Py_buffer structure is released.  The concept of locking is
+    not supported by all objects that expose the buffer protocol.
 
 ``format``
     a NULL-terminated format-string (following the struct-style syntax
@@ -571,7 +626,7 @@
 ::
 
     PyObject * PyMemoryView_GetContiguous(PyObject *obj,  int buffertype, 
-                                          char fort)
+                                          char fortran)
 
 Return a memoryview object to a contiguous chunk of memory represented
 by obj. If a copy must be made (because the memory pointed to by obj
@@ -818,10 +873,10 @@
 
 The proposed locking mechanism relies entirely on the exporter object
 to not invalidate any of the memory pointed to by the buffer structure
-until a corresponding releasebuffer is called.  If it wants to be able
-to change its own shape and/or strides arrays, then it needs to create
-memory for these in the bufferinfo structure and copy information
-over.
+until a corresponding releasebuffer is called or the UNLOCK flag is
+passed to a getbuffer call.  If it wants to be able to change its own
+shape and/or strides arrays, then it needs to create memory for these
+in the bufferinfo structure and copy information over.
 
 The sharing of strided memory and suboffsets is new and can be seen as
 a modification of the multiple-segment interface.  It is motivated by



From solipsis at pitrou.net  Mon Jun  2 11:58:14 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 2 Jun 2008 09:58:14 +0000 (UTC)
Subject: [Python-3000] =?utf-8?b?c3lzLmV4Y19pbmZvKCk=?=
References: <loom.20080526T091655-961@post.gmane.org>
	<loom.20080530T094609-317@post.gmane.org>
	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>
	<loom.20080531T012237-406@post.gmane.org>
	<aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com>
	<003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
	<00ab01c8c383$fb909db0$f2b1d910$@com.au>
	<43aa6ff70806011952r4f3fdd49q7f5e0456689e90c7@mail.gmail.com>
Message-ID: <loom.20080602T095550-358@post.gmane.org>

Collin Winter <collinw <at> gmail.com> writes:
> 
> See PEP 3109: http://www.python.org/dev/peps/pep-3109/

By the way, this document mentions a "raise ... from ..." form, but it doesn't 
seem to me it has been implemented. Perhaps the document should be corrected?

Also, it doesn't mention the with_traceback() method of exception objects.

Antoine.



From guido at python.org  Tue Jun  3 05:46:31 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 2 Jun 2008 20:46:31 -0700
Subject: [Python-3000] sys.exc_info()
In-Reply-To: <aac2c7cb0806022016y2eca9504gdb94ec4e9ecfccdd@mail.gmail.com>
References: <loom.20080526T091655-961@post.gmane.org>
	<loom.20080530T094609-317@post.gmane.org>
	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>
	<loom.20080531T012237-406@post.gmane.org>
	<aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com>
	<003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
	<B4AA5F22A030498192994F8C4D6CA856@ryoko>
	<44F57FF6-1DC0-4956-942B-3ABE5B6F9F34@acm.org>
	<aac2c7cb0806022016y2eca9504gdb94ec4e9ecfccdd@mail.gmail.com>
Message-ID: <ca471dc20806022046m1cea8478n70282e40c63edb25@mail.gmail.com>

On Mon, Jun 2, 2008 at 8:16 PM, Adam Olsen <rhamph at gmail.com> wrote:
> On Mon, Jun 2, 2008 at 8:56 PM, Fred Drake <fdrake at acm.org> wrote:
>> On May 31, 2008, at 6:42 PM, Tim Delaney wrote:
>>>
>>> This reminds me of something I've thought a few times - maybe the tuple
>>> returned from sys.exc_info() should be a named tuple.
>>
>> +1
>
> It should be replaced with a function that returns only the value -
> type and traceback are both redundant now.  I don't think anything's
> been proposed yet though.

Since I expect that in a while we will be able to deprecate
sys.exc_info() and later kill it, I would rather not meddle with it
now. There is tons of code out there that does fairly obscure things
with it, and keeping that code happy is higher on my list than
cleaning up an API that's eventually doomed.

I'm similarly underwhelmed by the idea having it return a named tuple.
I personally don't have any trouble keeping three values apart, so I
don't think it adds much.

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

From guido at python.org  Tue Jun  3 05:47:38 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 2 Jun 2008 20:47:38 -0700
Subject: [Python-3000] -t command line option
In-Reply-To: <g221ie$97s$1@ger.gmane.org>
References: <g221ie$97s$1@ger.gmane.org>
Message-ID: <ca471dc20806022047x39021a67n6b568cb55fd85bf5@mail.gmail.com>

On Mon, Jun 2, 2008 at 5:00 PM, Giovanni Bajo <rasky at develer.com> wrote:
> Python 3.0 defaults to "-tt" (error on inconsistent usage of tab and
> spaces). Then: why is there still a "-t" and "-tt" command line option?
> Is just a relic that should be removed?

Probably. Though there are plenty of precedents for leaving such
inactive options in for a long time, to avoid unnecessarily breaking
hairy shell scripts.

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

From rhamph at gmail.com  Tue Jun  3 05:56:39 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Mon, 2 Jun 2008 21:56:39 -0600
Subject: [Python-3000] sys.exc_info()
In-Reply-To: <ca471dc20806022046m1cea8478n70282e40c63edb25@mail.gmail.com>
References: <loom.20080526T091655-961@post.gmane.org>
	<ca471dc20805301030q26271bfcx907250ddd3f9875a@mail.gmail.com>
	<loom.20080531T012237-406@post.gmane.org>
	<aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com>
	<003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
	<B4AA5F22A030498192994F8C4D6CA856@ryoko>
	<44F57FF6-1DC0-4956-942B-3ABE5B6F9F34@acm.org>
	<aac2c7cb0806022016y2eca9504gdb94ec4e9ecfccdd@mail.gmail.com>
	<ca471dc20806022046m1cea8478n70282e40c63edb25@mail.gmail.com>
Message-ID: <aac2c7cb0806022056n59d8e54bi87d77a982f928076@mail.gmail.com>

On Mon, Jun 2, 2008 at 9:46 PM, Guido van Rossum <guido at python.org> wrote:
> On Mon, Jun 2, 2008 at 8:16 PM, Adam Olsen <rhamph at gmail.com> wrote:
>> On Mon, Jun 2, 2008 at 8:56 PM, Fred Drake <fdrake at acm.org> wrote:
>>> On May 31, 2008, at 6:42 PM, Tim Delaney wrote:
>>>>
>>>> This reminds me of something I've thought a few times - maybe the tuple
>>>> returned from sys.exc_info() should be a named tuple.
>>>
>>> +1
>>
>> It should be replaced with a function that returns only the value -
>> type and traceback are both redundant now.  I don't think anything's
>> been proposed yet though.
>
> Since I expect that in a while we will be able to deprecate
> sys.exc_info() and later kill it, I would rather not meddle with it
> now. There is tons of code out there that does fairly obscure things
> with it, and keeping that code happy is higher on my list than
> cleaning up an API that's eventually doomed.
>
> I'm similarly underwhelmed by the idea having it return a named tuple.
> I personally don't have any trouble keeping three values apart, so I
> don't think it adds much.

So keep the old sys.exc_info() (at least for a few more releases) and
add a new function that only returns the value?  Just need to find a
name we can be happy with for a long time.. maybe
sys.exception_block()?

-- 
Adam Olsen, aka Rhamphoryncus

From guido at python.org  Tue Jun  3 05:59:02 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 2 Jun 2008 20:59:02 -0700
Subject: [Python-3000] sys.exc_info()
In-Reply-To: <aac2c7cb0806022056n59d8e54bi87d77a982f928076@mail.gmail.com>
References: <loom.20080526T091655-961@post.gmane.org>
	<loom.20080531T012237-406@post.gmane.org>
	<aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com>
	<003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
	<B4AA5F22A030498192994F8C4D6CA856@ryoko>
	<44F57FF6-1DC0-4956-942B-3ABE5B6F9F34@acm.org>
	<aac2c7cb0806022016y2eca9504gdb94ec4e9ecfccdd@mail.gmail.com>
	<ca471dc20806022046m1cea8478n70282e40c63edb25@mail.gmail.com>
	<aac2c7cb0806022056n59d8e54bi87d77a982f928076@mail.gmail.com>
Message-ID: <ca471dc20806022059x3513954bv3716d0ed1a238832@mail.gmail.com>

On Mon, Jun 2, 2008 at 8:56 PM, Adam Olsen <rhamph at gmail.com> wrote:
> On Mon, Jun 2, 2008 at 9:46 PM, Guido van Rossum <guido at python.org> wrote:
>> On Mon, Jun 2, 2008 at 8:16 PM, Adam Olsen <rhamph at gmail.com> wrote:
>>> On Mon, Jun 2, 2008 at 8:56 PM, Fred Drake <fdrake at acm.org> wrote:
>>>> On May 31, 2008, at 6:42 PM, Tim Delaney wrote:
>>>>>
>>>>> This reminds me of something I've thought a few times - maybe the tuple
>>>>> returned from sys.exc_info() should be a named tuple.
>>>>
>>>> +1
>>>
>>> It should be replaced with a function that returns only the value -
>>> type and traceback are both redundant now.  I don't think anything's
>>> been proposed yet though.
>>
>> Since I expect that in a while we will be able to deprecate
>> sys.exc_info() and later kill it, I would rather not meddle with it
>> now. There is tons of code out there that does fairly obscure things
>> with it, and keeping that code happy is higher on my list than
>> cleaning up an API that's eventually doomed.
>>
>> I'm similarly underwhelmed by the idea having it return a named tuple.
>> I personally don't have any trouble keeping three values apart, so I
>> don't think it adds much.
>
> So keep the old sys.exc_info() (at least for a few more releases) and
> add a new function that only returns the value?  Just need to find a
> name we can be happy with for a long time.. maybe
> sys.exception_block()?

Actually I think we won't  need that function once we're used to just
passing exception instances around.

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

From fdrake at acm.org  Tue Jun  3 06:05:05 2008
From: fdrake at acm.org (Fred Drake)
Date: Tue, 3 Jun 2008 00:05:05 -0400
Subject: [Python-3000] sys.exc_info()
In-Reply-To: <ca471dc20806022059x3513954bv3716d0ed1a238832@mail.gmail.com>
References: <loom.20080526T091655-961@post.gmane.org>
	<loom.20080531T012237-406@post.gmane.org>
	<aac2c7cb0805301844o50b80f6cpbcef72bcdfeceecc@mail.gmail.com>
	<003a01c8c2e9$afc2d910$0f488b30$@com.au>
	<loom.20080531T131423-489@post.gmane.org>
	<B4AA5F22A030498192994F8C4D6CA856@ryoko>
	<44F57FF6-1DC0-4956-942B-3ABE5B6F9F34@acm.org>
	<aac2c7cb0806022016y2eca9504gdb94ec4e9ecfccdd@mail.gmail.com>
	<ca471dc20806022046m1cea8478n70282e40c63edb25@mail.gmail.com>
	<aac2c7cb0806022056n59d8e54bi87d77a982f928076@mail.gmail.com>
	<ca471dc20806022059x3513954bv3716d0ed1a238832@mail.gmail.com>
Message-ID: <CB7ACA04-1B8A-484E-BA50-74A451BE5E95@acm.org>

On Jun 2, 2008, at 11:59 PM, Guido van Rossum wrote:
> Actually I think we won't need that function once we're used to just
> passing exception instances around.


Ah, so many differences that I've lost track of.  I feel so...  
py2k.  :-(


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From g.brandl at gmx.net  Tue Jun  3 11:25:45 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 03 Jun 2008 11:25:45 +0200
Subject: [Python-3000] -t command line option
In-Reply-To: <ca471dc20806022047x39021a67n6b568cb55fd85bf5@mail.gmail.com>
References: <g221ie$97s$1@ger.gmane.org>
	<ca471dc20806022047x39021a67n6b568cb55fd85bf5@mail.gmail.com>
Message-ID: <g232gf$thl$1@ger.gmane.org>

Guido van Rossum schrieb:
> On Mon, Jun 2, 2008 at 5:00 PM, Giovanni Bajo <rasky at develer.com> wrote:
>> Python 3.0 defaults to "-tt" (error on inconsistent usage of tab and
>> spaces). Then: why is there still a "-t" and "-tt" command line option?
>> Is just a relic that should be removed?
> 
> Probably. Though there are plenty of precedents for leaving such
> inactive options in for a long time, to avoid unnecessarily breaking
> hairy shell scripts.

It's even stranger: you can use -ttt to disable the errors again.

------------------------------------------------------------------------
r45381 | thomas.wouters | 2006-04-14 13:33:28 +0200 (Fr, 14 Apr 2006) | 9 lines


Make 'python -tt' the default, meaning Python won't allow mixing tabs and
spaces for indentation. Adds a '-ttt' option to turn the errors back into
warnings; I'm not yet sure whether that's desireable for Py3K.
...

Should this stay?

In any case, the usage string and the docs for -t and sys.flags must
be corrected.

Georg


From guido at python.org  Tue Jun  3 16:35:36 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 3 Jun 2008 07:35:36 -0700
Subject: [Python-3000] -t command line option
In-Reply-To: <g232gf$thl$1@ger.gmane.org>
References: <g221ie$97s$1@ger.gmane.org>
	<ca471dc20806022047x39021a67n6b568cb55fd85bf5@mail.gmail.com>
	<g232gf$thl$1@ger.gmane.org>
Message-ID: <ca471dc20806030735u74746f60o1bced5be133ffd20@mail.gmail.com>

On Tue, Jun 3, 2008 at 2:25 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> Guido van Rossum schrieb:
>>
>> On Mon, Jun 2, 2008 at 5:00 PM, Giovanni Bajo <rasky at develer.com> wrote:
>>>
>>> Python 3.0 defaults to "-tt" (error on inconsistent usage of tab and
>>> spaces). Then: why is there still a "-t" and "-tt" command line option?
>>> Is just a relic that should be removed?
>>
>> Probably. Though there are plenty of precedents for leaving such
>> inactive options in for a long time, to avoid unnecessarily breaking
>> hairy shell scripts.
>
> It's even stranger: you can use -ttt to disable the errors again.
>
> ------------------------------------------------------------------------
> r45381 | thomas.wouters | 2006-04-14 13:33:28 +0200 (Fr, 14 Apr 2006) | 9
> lines
>
>
> Make 'python -tt' the default, meaning Python won't allow mixing tabs and
> spaces for indentation. Adds a '-ttt' option to turn the errors back into
> warnings; I'm not yet sure whether that's desireable for Py3K.
> ...
>
> Should this stay?
>
> In any case, the usage string and the docs for -t and sys.flags must
> be corrected.

I think by now it can be removed.

Just last week in an App Engine code lab, I was helping someone who
had just started to use Python on a Windows box using some
Windows-only editor (not Notepad :-) who ran into trouble by mixing
tabs and spaces. His editor most unhelpfully displayed a tab as four
spaces. Had Python defaulted to -tt we would have known much quicker
that this was the case.

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

From mal at egenix.com  Tue Jun  3 19:43:45 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 03 Jun 2008 19:43:45 +0200
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <ca471dc20806021609v258d7e8bk66b259694dd469b5@mail.gmail.com>
References: <48397ECC.9070805@cheimes.de>	<52dc1c820805281347n75a4baax9222b75c8fa09ec5@mail.gmail.com>	<483ECA52.6040000@egenix.com>
	<483ECF94.7060607@cheimes.de>	<483EF139.8000606@egenix.com>
	<483F34C3.3050402@gmail.com>	<483FBCB4.5020007@egenix.com>	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>	<4843E884.1060705@egenix.com>	<52dc1c820806021521g810d9f1wd282508f8452c13@mail.gmail.com>
	<ca471dc20806021609v258d7e8bk66b259694dd469b5@mail.gmail.com>
Message-ID: <484582D1.7000309@egenix.com>

On 2008-06-03 01:09, Guido van Rossum wrote:
> I will freely admit that I haven't followed this thread in any detail,
> but if it were up to me, I'd have the 2.6 internal code use PyString
> (as both what the linker sees and what the human reads in the source
> code) and the 3.0 code use PyBytes for the same thing. Let the merges
> be damed -- most changes to 2.6 these days seem to be blocked
> explicitly from being merged anyway. I'd prefer the 2.6 code base to
> stay true to 2.x, and the 3.0 code base start afresh where it makes
> sense. We should reindent more of the 3.0 code base to use
> 4-space-indents in C code too.
> 
> I would also add macros that map the PyBytes_* APIs to PyString_*, but
> I would not start using these internally except in code newly written
> for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString
> for 8-bit strings containing text, and PyBytes for 8-bit strings
> containing binary data. For 8-bit strings that could contain either
> text or data, I'd use PyString, in the spirit of 2.x.

+1

Let's work on better merge tools that edit the trunk code base
into shape for a 3.x checkin.

Using automated tools for this
is likely going to lower the probability of bugs introduced
due to unnoticed merge conflicts and in the end is also going
to be a benefit to everyone wanting to maintain a single code
base for both targets.

Perhaps we could revive the old Tools/scripts/fixcid.py that was
used for the 1.4->1.5 renaming ?!

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 03 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/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            33 days to go

:::: 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 ishimoto at gembook.org  Tue Jun  3 19:53:56 2008
From: ishimoto at gembook.org (Atsuo Ishimoto)
Date: Wed, 4 Jun 2008 02:53:56 +0900
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <797440730806021635u64184235w24ecc8e87094f03e@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<797440730806010832t1137891fi8e47458b8dafb1b2@mail.gmail.com>
	<acd65fa20806011039w6a432df8lf8da163d6e173d9b@mail.gmail.com>
	<797440730806011632o76e5dcferca8b6c4dc015a4bf@mail.gmail.com>
	<48434B35.5080400@canterbury.ac.nz>
	<ca471dc20806021530m5582205fqe0a02e9d4161e295@mail.gmail.com>
	<797440730806021635u64184235w24ecc8e87094f03e@mail.gmail.com>
Message-ID: <797440730806031053m443e8c09g2016b464759ff1ed@mail.gmail.com>

> Mark Summerfield suggested to add "!a" conversion flag to the
> str.format() method. I'll add  the conversion flag to the patch and
> PEP later today.

I updated PEP and patch. New patch is updated to
http://bugs.python.org/issue2630.

Changes are::

- Added conversion flag to the str.format() and PyUnicode_FromFormat() C API.

- Added new C API PyObject_ASCII() which called from ascii() builtin
function for consistency.   If PyObject_ASCII() is not necessary to be
public API, I'll make it internal function.

Questions::

- The error-handler of the sys.stderr is now configurable by
PYTHONIOENCODING, but I think default error-handler of sys.stderr
should be 'backslashreplace'. PYTHONIOENCODING is fine for sys.stdout,
but sys.stderr is not necessary to have same error-handler with
sys.stdout.

- Should new C APIs/function/method/string format operaters be
back-ported to Python 2.6, without modifying repr() itself? If so, ll
prepare a patch for Python 2.6.


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

PEP: 3138

Title: String representation in Python 3000
Version: $Revision$
Last-Modified: $Date$
Author: Atsuo Ishimoto <ishimoto--at--gembook.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created:
Post-History:


Abstract
========

This PEP proposes a new string representation form for Python 3000. In
Python prior to Python 3000, the repr() built-in function converted
arbitrary objects to printable ASCII strings for debugging and logging.
For Python 3000, a wider range of characters, based on the Unicode
standard, should be considered 'printable'.


Motivation
==========

The current repr() converts 8-bit strings to ASCII using following
algorithm.

- Convert CR, LF, TAB and '\\' to '\\r', '\\n', '\\t', '\\\\'.

- Convert other non-printable characters(0x00-0x1f, 0x7f) and non-ASCII
  characters(>=0x80) to '\\xXX'.

- Backslash-escape quote characters (apostrophe, ') and add the quote
  character at the beginning and the end.

For Unicode strings, the following additional conversions are done.

- Convert leading surrogate pair characters without trailing character
  (0xd800-0xdbff, but not followed by 0xdc00-0xdfff) to '\\uXXXX'.

- Convert 16-bit characters(>=0x100) to '\\uXXXX'.

- Convert 21-bit characters(>=0x10000) and surrogate pair characters to
  '\\U00xxxxxx'.

This algorithm converts any string to printable ASCII, and repr() is
used as a handy and safe way to print strings for debugging or for
logging. Although all non-ASCII characters are escaped, this does not
matter when most of the string's characters are ASCII. But for other
languages, such as Japanese where most characters in a string are not
ASCII, this is very inconvenient.

We can use ``print(aJapaneseString)`` to get a readable string, but we
don't have a similar workaround for printing strings from collections
such as lists or tuples. ``print(listOfJapaneseStrings)`` uses repr() to
build the string to be printed, so the resulting strings are always
hex-escaped. Or when ``open(japaneseFilemame)`` raises an exception, the
error message is something like ``IOError: [Errno 2] No such file or
directory: '\u65e5\u672c\u8a9e'``, which isn't helpful.

Python 3000 has a lot of nice features for non-Latin users such as
non-ASCII identifiers, so it would be helpful if Python could also progress
in a similar way for printable output.

Some users might be concerned that such output will mess up their
console if they print binary data like images. But this is unlikely to
happen in practice because bytes and strings are different types in
Python 3000, so printing an image to the console won't mess it up.

This issue was once discussed by Hye-Shik Chang [1]_ , but was rejected.


Specification
=============

- Add a new function to the Python C API ``int PY_UNICODE_ISPRINTABLE
  (Py_UNICODE ch)``. This function returns 0 if repr() should escape the
  Unicode character ``ch``; otherwise it returns 1. Characters that should
  be escaped are defined in the Unicode character database as:

  * Cc (Other, Control)
  * Cf (Other, Format)
  * Cs (Other, Surrogate)
  * Co (Other, Private Use)
  * Cn (Other, Not Assigned)
  * Zl (Separator, Line), refers to LINE SEPARATOR ('\\u2028').
  * Zp (Separator, Paragraph), refers to PARAGRAPH SEPARATOR ('\\u2029').
  * Zs (Separator, Space) other than ASCII space('\\x20'). Characters in
    this category should be escaped to avoid ambiguity.

- The algorithm to build repr() strings should be changed to:

  * Convert CR, LF, TAB and '\\' to '\\r', '\\n', '\\t', '\\\\'.

  * Convert non-printable ASCII characters(0x00-0x1f, 0x7f) to '\\xXX'.

  * Convert leading surrogate pair characters without trailing character
    (0xd800-0xdbff, but not followed by 0xdc00-0xdfff) to '\\uXXXX'.

  * Convert non-printable characters(PY_UNICODE_ISPRINTABLE() returns 0)
    to 'xXX', '\\uXXXX' or '\\U00xxxxxx'.

  * Backslash-escape quote characters (apostrophe, 0x27) and add quote
    character at the beginning and the end.

- Set the Unicode error-handler for sys.stderr to 'backslashreplace' by
  default.

- Add a new function to the Python C API ``PyObject *PyObject_ASCII
  (PyObject *o)``. This function converts any python object to a string
  using PyObject_Repr() and then hex-escapes all non-ASCII characters. ``
  PyObject_ASCII()`` generates the same string as ``PyObject_Repr()`` in
  Python 2.

- Add a new built-in function, ``ascii()``. This function converts any
  python object to a string using repr() and then hex-escapes all non-ASCII
  characters. ``ascii()`` generates the same string as ``repr()`` in
  Python 2.

- Add ``'%a'`` string format operator. ``'%a'`` converts any python
  object to a string using repr() and then hex-escapes all non-ASCII
  characters. The ``'%a'`` format operator generates the same string as
  ``'%r'`` in Python 2. Also, add ``'!a'`` conversion flags to the
  ``string.format()`` method and add ``'%A'`` operator to the
  PyUnicode_FromFormat(). They converts any object to an ASCII string
  as ``'%a'`` string format operator.

- Add an ``isprintable()`` method to the string type. ``str.isprintable()``
  returns False if repr() should escape any character in the string;
  otherwise returns True. The ``isprintable()`` method calls the
  ``PY_UNICODE_ISPRINTABLE()`` function internally.


Rationale
=========

The repr() in Python 3000 should be Unicode not ASCII based, just like
Python 3000 strings. Also, conversion should not be affected by the
locale setting, because the locale is not necessarily the same as the
output device's locale. For example, it is common for a daemon process
to be invoked in an ASCII setting, but writes UTF-8 to its log files.
Also, web applications might want to report the error information in
more readable form based on the HTML page's encoding.

Characters not supported by the user's console could be hex-escaped on
printing, by the Unicode encoder's error-handler. If the error-handler
of the output file is 'backslashreplace', such characters are
hex-escaped without raising UnicodeEncodeError. For example, if your default
encoding is ASCII, ``print('Hello ?')`` will print 'Hello \\xa2'. If
your encoding is ISO-8859-1, 'Hello ?' will be printed.

The default error-handler for sys.stdout is 'strict'. Other applications
reading the output might not understand hex-escaped characters, so
unsupported characters should be trapped when writing. If you need to
escape unsupported characters, you should explicitly change the
error-handler. Unlike sys.stdout, sys.stderr doesn't raise
UnicodeEncodingError by default, because the default error-handler is
'backslashreplace'. So printing error messeges containing non-ASCII
characters to sys.stderr will not raise an exception. Also, information
about uncaught exceptions (exception object, traceback) are printed by
the interpreter without raising exceptions.

Alternate Solutions
-------------------

To help debugging in non-Latin languages without changing repr(), other
suggestions were made.

- Supply a tool to print lists or dicts.

  Strings to be printed for debugging are not only contained by lists or
  dicts, but also in many other types of object. File objects contain a
  file name in Unicode, exception objects contain a message in Unicode,
  etc. These strings should be printed in readable form when repr()ed.
  It is unlikely to be possible to implement a tool to print all
  possible object types.

- Use sys.displayhook and sys.excepthook.

  For interactive sessions, we can write hooks to restore hex escaped
  characters to the original characters. But these hooks are called only
  when printing the result of evaluating an expression entered in an
  interactive Python session, and doesn't work for the print() function,
  for non-interactive sessions or for logging.debug("%r", ...), etc.

- Subclass sys.stdout and sys.stderr.

  It is difficult to implement a subclass to restore hex-escaped
  characters since there isn't enough information left by the time it's
  a string to undo the escaping correctly in all cases. For example,
  ``print("\\"+"u0041")`` should be printed as '\\u0041', not 'A'. But
  there is no chance to tell file objects apart.

- Make the encoding used by unicode_repr() adjustable, and make the
  existing repr() the default.

  With adjustable repr(), the result of using repr() is unpredictable
  and would make it impossible to write correct code involving repr().
  And if current repr() is the default, then the old convention remains
  intact and users may expect ASCII strings as the result of repr().
  Third party applications or libraries could be confused when a custom
  repr() function is used.


Backwards Compatibility
=======================

Changing repr() may break some existing code, especially testing code.
Five of Python's regression tests fail with this modification. If you
need repr() strings without non-ASCII character as Python 2, you can use
the following function. ::

    def repr_ascii(obj):
        return str(repr(obj).encode("ASCII", "backslashreplace"), "ASCII")

For logging or for debugging, the following code can raise
UnicodeEncodeError. ::

    log = open("logfile", "w")
    log.write(repr(data))     # UnicodeEncodeError will be raised
                              # if data contains unsupported characters.

To avoid exceptions being raised, you can explicitly specify the error-
handler. ::

    log = open("logfile", "w", errors="backslashreplace")
    log.write(repr(data))  # Unsupported characters will be escaped.


For a console that uses a Unicode-based encoding, for example, en_US.
utf8 or de_DE.utf8, the backslashescape trick doesn't work and all
printable characters are not escaped. This will cause a problem of
similarly drawing characters in Western, Greek and Cyrillic languages.
These languages use similar (but different) alphabets (descended from a
common ancestor) and contain letters that look similar but have
different character codes. For example, it is hard to distinguish Latin
'a', 'e' and 'o' from Cyrillic '?', '?' and '?'. (The visual
representation, of course, very much depends on the fonts used but
usually these letters are almost indistinguishable.) To avoid the
problem, the user can adjust the terminal encoding to get a result
suitable for their environment.


Rejected Proposals
==================

- Add encoding and errors arguments to the builtin print() function,
  with defaults of sys.getfilesystemencoding() and 'backslashreplace'.

  Complicated to implement, and in general, this is not seen as a good
  idea. [2]_

- Use character names to escape characters, instead of hex character
  codes. For example, ``repr('\u03b1')`` can be converted to ``"\N{GREEK
  SMALL LETTER ALPHA}"``.

  Using character names can be very verbose compared to hex-escape. e.
  g., ``repr("\ufbf9")`` is converted to ``"\N{ARABIC LIGATURE UIGHUR
  KIRGHIZ YEH WITH HAMZA ABOVE WITH ALEF MAKSURA ISOLATED FORM}"``.

- Default error-handler of sys.stdout should be 'backslashreplace'.

  Stuff written to stdout might be consumed by another program that
  might misinterpret the \ escapes. For interactive session, it is
  possible to make 'backslashreplace' error-handler to default, but may
  add confusion of the kind "it works in interactive mode but not when
  redirecting to a file".



Reference Implementation
========================

http://bugs.python.org/issue2630


References
==========

.. [1] Multibyte string on string::string_print
        (http://bugs.python.org/issue479898)

.. [2] [Python-3000] Displaying strings containing unicode escapes
        (http://mail.python.org/pipermail/python-3000/2008-April/013366.html)

Copyright
=========

This document has been placed in the public domain.

From guido at python.org  Tue Jun  3 20:55:00 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 3 Jun 2008 11:55:00 -0700
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <797440730806010832t1137891fi8e47458b8dafb1b2@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<fb6fbf560805261806j7b79e776i3361a655ac1d8a36@mail.gmail.com>
	<797440730805262311j6ece045apd731b4e78eacd4c5@mail.gmail.com>
	<fb6fbf560805271312g41c6b240h322c7142d1cf98be@mail.gmail.com>
	<797440730805272137s716d6b61l57d900b95364efd6@mail.gmail.com>
	<797440730805282340n1eea6597qfcabde6e1e611a0@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<797440730806010832t1137891fi8e47458b8dafb1b2@mail.gmail.com>
Message-ID: <ca471dc20806031155q15c9d362s4f4674c4f9fe4318@mail.gmail.com>

On Sun, Jun 1, 2008 at 8:32 AM, Atsuo Ishimoto <ishimoto at gembook.org> wrote:
> Here's new PEP,  and new patch is uploaded at http://bugs.python.org/issue2630.
> (codereview.appspot.com refused to create new issue for this patch, btw.)

Thanks for the report! I had made codereview UTF-8-aware, but it
choked on Latin-1. I now use Latin-1 as a fallback. You can see for
yourself here: http://codereview.appspot.com/1465

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

From guido at python.org  Tue Jun  3 23:02:20 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 3 Jun 2008 14:02:20 -0700
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <797440730806031053m443e8c09g2016b464759ff1ed@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<ca471dc20805310932q18f1ba44r317eac65f1209258@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<797440730806010832t1137891fi8e47458b8dafb1b2@mail.gmail.com>
	<acd65fa20806011039w6a432df8lf8da163d6e173d9b@mail.gmail.com>
	<797440730806011632o76e5dcferca8b6c4dc015a4bf@mail.gmail.com>
	<48434B35.5080400@canterbury.ac.nz>
	<ca471dc20806021530m5582205fqe0a02e9d4161e295@mail.gmail.com>
	<797440730806021635u64184235w24ecc8e87094f03e@mail.gmail.com>
	<797440730806031053m443e8c09g2016b464759ff1ed@mail.gmail.com>
Message-ID: <ca471dc20806031402s51fff8caqe1c15c2c6fc8f04d@mail.gmail.com>

On Tue, Jun 3, 2008 at 10:53 AM, Atsuo Ishimoto <ishimoto at gembook.org> wrote:
> I updated PEP and patch. New patch is updated to
> http://bugs.python.org/issue2630.
>
> Changes are::
>
> - Added conversion flag to the str.format() and PyUnicode_FromFormat() C API.
>
> - Added new C API PyObject_ASCII() which called from ascii() builtin
> function for consistency.   If PyObject_ASCII() is not necessary to be
> public API, I'll make it internal function.

I've accepted the PEP, meaning implementation can now go ahead.
Hopefully it will make it into 3.0b1. Congratulations, Atsuo!

> Questions::
>
> - The error-handler of the sys.stderr is now configurable by
> PYTHONIOENCODING, but I think default error-handler of sys.stderr
> should be 'backslashreplace'. PYTHONIOENCODING is fine for sys.stdout,
> but sys.stderr is not necessary to have same error-handler with
> sys.stdout.

Correct. You can fix this in the PEP or just in the code. :-)

> - Should new C APIs/function/method/string format operaters be
> back-ported to Python 2.6, without modifying repr() itself? If so, ll
> prepare a patch for Python 2.6.

I don't think the C level features need to be backported. Backporting
the .format()  operations is probably a good idea.

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

From ishimoto at gembook.org  Wed Jun  4 03:43:19 2008
From: ishimoto at gembook.org (Atsuo Ishimoto)
Date: Wed, 4 Jun 2008 10:43:19 +0900
Subject: [Python-3000] Fwd: UPDATED: PEP 3138- String representation in
	Python 3000
In-Reply-To: <ca471dc20806031402s51fff8caqe1c15c2c6fc8f04d@mail.gmail.com>
References: <797440730805240349t2d5430fxdf77c24eb7541204@mail.gmail.com>
	<797440730805311030q1fa2763bsc439f9183abcf3b5@mail.gmail.com>
	<797440730806010832t1137891fi8e47458b8dafb1b2@mail.gmail.com>
	<acd65fa20806011039w6a432df8lf8da163d6e173d9b@mail.gmail.com>
	<797440730806011632o76e5dcferca8b6c4dc015a4bf@mail.gmail.com>
	<48434B35.5080400@canterbury.ac.nz>
	<ca471dc20806021530m5582205fqe0a02e9d4161e295@mail.gmail.com>
	<797440730806021635u64184235w24ecc8e87094f03e@mail.gmail.com>
	<797440730806031053m443e8c09g2016b464759ff1ed@mail.gmail.com>
	<ca471dc20806031402s51fff8caqe1c15c2c6fc8f04d@mail.gmail.com>
Message-ID: <797440730806031843o1ad6aa47w8b0f93749dae1d8@mail.gmail.com>

On Wed, Jun 4, 2008 at 6:02 AM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Jun 3, 2008 at 10:53 AM, Atsuo Ishimoto <ishimoto at gembook.org> wrote:
>> I updated PEP and patch. New patch is updated to
>> http://bugs.python.org/issue2630.
>>
>> Changes are::
>>
>> - Added conversion flag to the str.format() and PyUnicode_FromFormat() C API.
>>
>> - Added new C API PyObject_ASCII() which called from ascii() builtin
>> function for consistency.   If PyObject_ASCII() is not necessary to be
>> public API, I'll make it internal function.
>
> I've accepted the PEP, meaning implementation can now go ahead.
> Hopefully it will make it into 3.0b1. Congratulations, Atsuo!

Thank you very much! The repr() issue have annoyed me more than ten
years, but now it's gone at last!
 I would much appreciate everybody participated the discussion, in
spite of my crazy English. And thanks to Mark Summerfield, he helped
me by fixing my English patiently.

From greg.ewing at canterbury.ac.nz  Wed Jun  4 03:49:00 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 04 Jun 2008 13:49:00 +1200
Subject: [Python-3000] Single buffer implied in new buffer protocol?
In-Reply-To: <loom.20080602T122726-345@post.gmane.org>
References: <g1675f$hf4$1@ger.gmane.org> <g1hvto$kh3$1@ger.gmane.org>
	<g1lhlt$988$1@ger.gmane.org> <g1odf8$ga8$1@ger.gmane.org>
	<loom.20080602T122726-345@post.gmane.org>
Message-ID: <4845F48C.6030500@canterbury.ac.nz>

I don't understand all this stuff about getting unlocked
buffers and unlocking buffers while keeping them alive,
etc.

The way I thought this was supposed to work is that the
buffer is *always* locked while the client is accessing
it, the only choice being whether it's a read-only or
read-write lock.

So the usage sequence is:

1) Client calls getbuffer() and receives a buffer
    pointer. The memory referred to by the pointer
    is now locked and will not move.

2) Client accesses the memory via the returned pointer.

3) Client calls releasebuffer(). The memory is now
    unlocked and the pointer is no longer valid.

If the client wants to access the buffer again, it
must go back to step 1.

Are there use cases for which this sequence is not
adequate?

-- 
Greg


From vdedaniya at gmail.com  Tue Jun  3 08:44:29 2008
From: vdedaniya at gmail.com (vdedaniya)
Date: Mon, 2 Jun 2008 23:44:29 -0700 (PDT)
Subject: [Python-3000] Python certifications
Message-ID: <6ab54660-6b02-4231-b21d-80ac7592248d@l42g2000hsc.googlegroups.com>

Hello Experts,

I want to give Python certifications. Can you please suggest how i
should proceed?

I do not want any training on Python as I am already working on it
since last two years. I just want to know the authorized center in
INDIA where i can give the Python certifications.

Thanks in advance,
Vishal

From r.m.oudkerk at googlemail.com  Tue Jun  3 21:16:31 2008
From: r.m.oudkerk at googlemail.com (r.m.oudkerk)
Date: Tue, 3 Jun 2008 20:16:31 +0100
Subject: [Python-3000] [Python-Dev] Postponing the first betas
In-Reply-To: <06BB1BB8-2C9C-4588-9B38-49DE234752E0@python.org>
References: <06BB1BB8-2C9C-4588-9B38-49DE234752E0@python.org>
Message-ID: <ac4216f0806031216t73d8ea3n7b07eb3fb12eea71@mail.gmail.com>

On 02/06/2008, Barry Warsaw <barry at python.org> wrote:
> meantime, Guido said:
>
> "I'd also like to see PEP 3138 (CJK-friendly repr()) and the
> pyprocessing PEP implemented by then, and perhaps some other small
> stuff."

The pyprocessing unit tests crash with a fatal error when run on Linux
with a debug version of the interpreter.  This is because the GILState
stuff is not fork aware.  I submitted a patch some months  ago:

    http://bugs.python.org/issue1683

Could somebody review it please.

Cheers,

Richard.

From cvrebert at gmail.com  Wed Jun  4 08:57:52 2008
From: cvrebert at gmail.com (Chris Rebert)
Date: Tue, 3 Jun 2008 23:57:52 -0700
Subject: [Python-3000] Python certifications
In-Reply-To: <6ab54660-6b02-4231-b21d-80ac7592248d@l42g2000hsc.googlegroups.com>
References: <6ab54660-6b02-4231-b21d-80ac7592248d@l42g2000hsc.googlegroups.com>
Message-ID: <47c890dc0806032357n2d3f3508y478a625c9f72d509@mail.gmail.com>

This mailinglist is specifically about discussing Python v3.0, not
general Python interest topics. As such, you question would be better
suited to the comp.lang.python newsgroup than this list.

- Chris Rebert

On Mon, Jun 2, 2008 at 11:44 PM, vdedaniya <vdedaniya at gmail.com> wrote:
> Hello Experts,
>
> I want to give Python certifications. Can you please suggest how i
> should proceed?
>
> I do not want any training on Python as I am already working on it
> since last two years. I just want to know the authorized center in
> INDIA where i can give the Python certifications.
>
> Thanks in advance,
> Vishal
> _______________________________________________
> 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 stefan_ml at behnel.de  Wed Jun  4 09:29:27 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 4 Jun 2008 07:29:27 +0000 (UTC)
Subject: [Python-3000] Single buffer implied in new buffer protocol?
References: <g1675f$hf4$1@ger.gmane.org> <g1hvto$kh3$1@ger.gmane.org>
	<g1lhlt$988$1@ger.gmane.org> <g1odf8$ga8$1@ger.gmane.org>
	<loom.20080602T122726-345@post.gmane.org>
	<4845F48C.6030500@canterbury.ac.nz>
Message-ID: <loom.20080604T070652-580@post.gmane.org>

Hi Greg,

Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes:
> The way I thought this was supposed to work is that the
> buffer is *always* locked while the client is accessing
> it, the only choice being whether it's a read-only or
> read-write lock.

I don't think there should always be a lock in the sense that the requestor is
the only permitted accessor. Concurrent read access is common and easy to allow.
Such an "always lock" scheme would disallow long-living buffer references.


> So the usage sequence is:
> 
> 1) Client calls getbuffer() and receives a buffer
>     pointer. The memory referred to by the pointer
>     is now locked and will not move.

"not move" is just fine, but any locks should be requested explicitly using LOCK
and maybe WRITABLE.


> 2) Client accesses the memory via the returned pointer.
> 
> 3) Client calls releasebuffer(). The memory is now
>     unlocked and the pointer is no longer valid.
> 
> If the client wants to access the buffer again, it
> must go back to step 1.

or if the client wants to acquire a lock that it currently does not hold.

That's pretty much what my locking scheme is proposing, with the difference of
not caring about a possibly valid "buf" pointer being passed into getbuffer
(which I implicitly allow in my proposal anyway).

I like that scheme BTW. It works without an explicit UNLOCK and thus simplifies
my proposal at the cost of a separate Py_buffer allocation for the case of a
postponed LOCK request /after/ requesting the buffer for the first time. And the
Py_buffer allocation will most likely happen on the stack anyway, as a LOCK is
commonly held only during a function call life-time.

I'll fix up the PEP and send another patch ASAP.

Thanks for the feed-back,
Stefan



From stefan_ml at behnel.de  Wed Jun  4 10:53:29 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 4 Jun 2008 08:53:29 +0000 (UTC)
Subject: [Python-3000] Single buffer implied in new buffer protocol?
References: <g1675f$hf4$1@ger.gmane.org> <g1hvto$kh3$1@ger.gmane.org>
	<g1lhlt$988$1@ger.gmane.org> <g1odf8$ga8$1@ger.gmane.org>
	<loom.20080602T122726-345@post.gmane.org>
	<4845F48C.6030500@canterbury.ac.nz>
Message-ID: <loom.20080604T083713-841@post.gmane.org>

Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes:
> The way I thought this was supposed to work is that the
> buffer is *always* locked while the client is accessing
> it, the only choice being whether it's a read-only or
> read-write lock.

Thinking about this some more while updating the PEP:

This scheme has the advantage of always guaranteeing a consistent buffer state,
as no consumer can be granted write access while any other consumer has read
access. However, getting exclusive write access is hard, as this requires that
there are no reading consumers, including the consumer who wants to get write
access. So you'd always have to release your own read buffer before acquiring a
write buffer (which also implies that the provider must never deallocate the
buffer just because all readers have released their buffer view).

This encourages a short-read, short-write use pattern and always requires all
consumers to call releasebuffer before any write access can be granted. I don't
know if that scenario is realistic and/or efficient, but it would work and does
not even require the LOCK flag, the WRITABLE flag would be enough.

Comments?

Stefan



From greg.ewing at canterbury.ac.nz  Thu Jun  5 03:02:43 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 05 Jun 2008 13:02:43 +1200
Subject: [Python-3000] Single buffer implied in new buffer protocol?
In-Reply-To: <loom.20080604T070652-580@post.gmane.org>
References: <g1675f$hf4$1@ger.gmane.org> <g1hvto$kh3$1@ger.gmane.org>
	<g1lhlt$988$1@ger.gmane.org> <g1odf8$ga8$1@ger.gmane.org>
	<loom.20080602T122726-345@post.gmane.org>
	<4845F48C.6030500@canterbury.ac.nz>
	<loom.20080604T070652-580@post.gmane.org>
Message-ID: <48473B33.8010001@canterbury.ac.nz>

Stefan Behnel wrote:
> I don't think there should always be a lock in the sense that the requestor is
> the only permitted accessor.

No, but there's always a lock in the sense that the provider
is not allowed to move the memory while the buffer is in
use.

As for the other forms of locking, I'm still not sure whether
that's something the buffer protocol ought to be concerning
itself with. It's actually an orthogonal concept -- there's
no logical reason you couldn't hold a read or write lock on
an object *without* holding a move-lock on its buffer the
whole time.

I'm wondering whether it would be better to separate the
two kinds of lock and have a different api for dealing with
read/write locks. Conflating them seems to be making the
buffer api confusing to talk about and complicated for a
provider to implement.

For example, consider a provider whose memory never moves.
If the buffer api confines itself to move-locking, then
that provider can ignore locking altogether. But if locking
can include concepts of read/write access, it has to
maintain state for the lock and handle the logic of managing
it.

Furthermore, the read/write aspect of the lock management
logic is going to be pretty much identical for all buffer
providers, suggesting it ought to be factored out somehow
and implemented in one place.

> Concurrent read access is common and easy to allow.
> Such an "always lock" scheme would disallow long-living
 > buffer references.

But you shouldn't be keeping long-lived buffer references
in the first place.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Thu Jun  5 03:22:55 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 05 Jun 2008 13:22:55 +1200
Subject: [Python-3000] Single buffer implied in new buffer protocol?
In-Reply-To: <loom.20080604T083713-841@post.gmane.org>
References: <g1675f$hf4$1@ger.gmane.org> <g1hvto$kh3$1@ger.gmane.org>
	<g1lhlt$988$1@ger.gmane.org> <g1odf8$ga8$1@ger.gmane.org>
	<loom.20080602T122726-345@post.gmane.org>
	<4845F48C.6030500@canterbury.ac.nz>
	<loom.20080604T083713-841@post.gmane.org>
Message-ID: <48473FEF.3060503@canterbury.ac.nz>

Stefan Behnel wrote:
> So you'd always have to release your own read buffer before acquiring a
> write buffer

Yes, you really want to be able to upgrade your own lock
from a read lock to a write lock, which means the provider
has to keep track of who the lock holder is somehow.

The more I think about this, the more I feel that implementing
this form of locking is far too big a burden to place on every
buffer provider.

So I propose that it be declared outside the scope of the
buffer protocol altogether. The only form of locking known
to the buffer protocol should be move-locking, which is
implicit in every call to getbuffer. Supporting this
requires at most a simple counter, and if the provider never
moves its memory anyway, it can ignore locking completely.

> This encourages a short-read, short-write use pattern and always requires all
> consumers to call releasebuffer before any write access can be granted. I don't
> know if that scenario is realistic and/or efficient, but it would work and does
> not even require the LOCK flag, the WRITABLE flag would be enough.

It sounds like you're heading towards the same conclusion,
if I understand what you're saying correctly.

-- 
Greg

From stefan_ml at behnel.de  Thu Jun  5 09:12:06 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 05 Jun 2008 09:12:06 +0200
Subject: [Python-3000] Single buffer implied in new buffer protocol?
In-Reply-To: <48473FEF.3060503@canterbury.ac.nz>
References: <g1675f$hf4$1@ger.gmane.org>
	<g1hvto$kh3$1@ger.gmane.org>	<g1lhlt$988$1@ger.gmane.org>
	<g1odf8$ga8$1@ger.gmane.org>	<loom.20080602T122726-345@post.gmane.org>	<4845F48C.6030500@canterbury.ac.nz>	<loom.20080604T083713-841@post.gmane.org>
	<48473FEF.3060503@canterbury.ac.nz>
Message-ID: <g283k6$fg8$1@ger.gmane.org>

Greg Ewing wrote:
> Stefan Behnel wrote:
>> So you'd always have to release your own read buffer before acquiring a
>> write buffer
> 
> Yes, you really want to be able to upgrade your own lock
> from a read lock to a write lock, which means the provider
> has to keep track of who the lock holder is somehow.

That's why I was initially proposing to pass in the original Py_buffer when
requesting a lock.


> The more I think about this, the more I feel that implementing
> this form of locking is far too big a burden to place on every
> buffer provider.

I agree, especially since I expect read-only buffers to be quite common.

Locking can always be done in Python space. That may require a Python function
call and may thus be less efficient, but locking semantics can be pretty
diverse and correctness is usually more important than absolute speed here. So
I wouldn't mind leaving the locking business entirely to a separate protocol
between providers and consumers, maybe with a short note in the PEP that the
API of the provider should follow the locking API in the threading module as
far as appropriate.

One question: what does that mean for the mutable bytearray class? How would
that handle locking?

Stefan


From ncoghlan at gmail.com  Thu Jun  5 14:16:01 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 05 Jun 2008 22:16:01 +1000
Subject: [Python-3000] Single buffer implied in new buffer protocol?
In-Reply-To: <g283k6$fg8$1@ger.gmane.org>
References: <g1675f$hf4$1@ger.gmane.org>	<g1hvto$kh3$1@ger.gmane.org>	<g1lhlt$988$1@ger.gmane.org>	<g1odf8$ga8$1@ger.gmane.org>	<loom.20080602T122726-345@post.gmane.org>	<4845F48C.6030500@canterbury.ac.nz>	<loom.20080604T083713-841@post.gmane.org>	<48473FEF.3060503@canterbury.ac.nz>
	<g283k6$fg8$1@ger.gmane.org>
Message-ID: <4847D901.2010501@gmail.com>

Stefan Behnel wrote:
> One question: what does that mean for the mutable bytearray class? How would
> that handle locking?

In a single-threaded app, or one where only a single thread at a time 
can access the object providing the buffer interface, no locking is 
needed (that's the main advantage of the approach of handing over 
reference ownership by means of Queue objects). In a multi-threaded app 
where multiple threads can access it simultaneously, it needs to be 
protected by locks just like any other resource that is shared between 
multiple threads.

No need to confuse the question of memory access with the question of 
thread synchronisation.

Cheers,
Nick.

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

From stefan_ml at behnel.de  Thu Jun  5 15:35:04 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 05 Jun 2008 15:35:04 +0200
Subject: [Python-3000] Single buffer implied in new buffer protocol?
In-Reply-To: <4847D901.2010501@gmail.com>
References: <g1675f$hf4$1@ger.gmane.org>	<g1hvto$kh3$1@ger.gmane.org>	<g1lhlt$988$1@ger.gmane.org>	<g1odf8$ga8$1@ger.gmane.org>	<loom.20080602T122726-345@post.gmane.org>	<4845F48C.6030500@canterbury.ac.nz>	<loom.20080604T083713-841@post.gmane.org>	<48473FEF.3060503@canterbury.ac.nz>	<g283k6$fg8$1@ger.gmane.org>
	<4847D901.2010501@gmail.com>
Message-ID: <g28q26$st1$1@ger.gmane.org>

Nick Coghlan wrote:
> Stefan Behnel wrote:
>> One question: what does that mean for the mutable bytearray class? How
>> would that handle locking?
> 
> No need to confuse the question of memory access with the question of
> thread synchronisation.

Fair enough. Single-threaded code is extremely common in CPython after all.

So that means it's fine to remove all locking related functionality from the
new buffer protocol and leave everything to application space, right?

Here is a patch for the PEP that reflects this.

Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pep-3113-no-locking.patch
Type: text/x-patch
Size: 11631 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080605/9a105a2d/attachment.bin>

From alexandre at peadrop.com  Thu Jun  5 22:47:06 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Thu, 5 Jun 2008 16:47:06 -0400
Subject: [Python-3000] How to specify keyword-only arguments from C?
Message-ID: <acd65fa20806051347u11250050pc23c1a9628170d54@mail.gmail.com>

Hi,

Is there a way to specify keyword-only arguments using the C API. I
searched through the mailing list archive, read PEP 3102 and grep-ed
the codebase, but I found nothing looking like a C API. So I am
wondering, is this a Python-only feature?

-- Alexandre

From ncoghlan at gmail.com  Fri Jun  6 04:02:44 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 06 Jun 2008 12:02:44 +1000
Subject: [Python-3000] How to specify keyword-only arguments from C?
In-Reply-To: <acd65fa20806051347u11250050pc23c1a9628170d54@mail.gmail.com>
References: <acd65fa20806051347u11250050pc23c1a9628170d54@mail.gmail.com>
Message-ID: <48489AC4.7090007@gmail.com>

Alexandre Vassalotti wrote:
> Hi,
> 
> Is there a way to specify keyword-only arguments using the C API. I
> searched through the mailing list archive, read PEP 3102 and grep-ed
> the codebase, but I found nothing looking like a C API. So I am
> wondering, is this a Python-only feature?

The C API has had this for a long time, but only in the *args, **kwds 
form - i.e., an argument is keyword only if the C code only looks for it 
in the keywords dictionary and not the args tuple.

There's no special support for it in the arg parsing machinery that I 
know of, if that's the question you're asking.

Cheers,
Nick.

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

From guido at python.org  Fri Jun  6 04:50:18 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 5 Jun 2008 19:50:18 -0700
Subject: [Python-3000] How to specify keyword-only arguments from C?
In-Reply-To: <48489AC4.7090007@gmail.com>
References: <acd65fa20806051347u11250050pc23c1a9628170d54@mail.gmail.com>
	<48489AC4.7090007@gmail.com>
Message-ID: <ca471dc20806051950j45635ce2qf23919ffef89efe@mail.gmail.com>

On Thu, Jun 5, 2008 at 7:02 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Alexandre Vassalotti wrote:
>> Is there a way to specify keyword-only arguments using the C API. I
>> searched through the mailing list archive, read PEP 3102 and grep-ed
>> the codebase, but I found nothing looking like a C API. So I am
>> wondering, is this a Python-only feature?
>
> The C API has had this for a long time, but only in the *args, **kwds form -
> i.e., an argument is keyword only if the C code only looks for it in the
> keywords dictionary and not the args tuple.
>
> There's no special support for it in the arg parsing machinery that I know
> of, if that's the question you're asking.

I believe Alexandre is familiar with PyArg_ParseTupleAndKeywords(),
but its API doesn't let you specify keywords that have no positional
equivalent. He's after the C equivalent of

def foo(*, a, b): ...

where a and b *must* be specified as keywords by the caller. I don't
believe this is supported, due to the way
PyArg_ParseTupleAndKeywords() and friends are implemented. I don't
think it's a great loss, but if someone has the urge to implement an
API with an even longer name that supports this, I won't stop them.

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

From alexandre at peadrop.com  Fri Jun  6 05:51:59 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Thu, 5 Jun 2008 23:51:59 -0400
Subject: [Python-3000] How to specify keyword-only arguments from C?
In-Reply-To: <ca471dc20806051950j45635ce2qf23919ffef89efe@mail.gmail.com>
References: <acd65fa20806051347u11250050pc23c1a9628170d54@mail.gmail.com>
	<48489AC4.7090007@gmail.com>
	<ca471dc20806051950j45635ce2qf23919ffef89efe@mail.gmail.com>
Message-ID: <acd65fa20806052051t7ce79f9bj3af4fc064745246b@mail.gmail.com>

On Thu, Jun 5, 2008 at 10:50 PM, Guido van Rossum <guido at python.org> wrote:
> I believe Alexandre is familiar with PyArg_ParseTupleAndKeywords(),
> but its API doesn't let you specify keywords that have no positional
> equivalent. He's after the C equivalent of
>
> def foo(*, a, b): ...
>
> where a and b *must* be specified as keywords by the caller.

Yes, that is what I was looking for. As Mark pointed out, the solution
is simply to check the size of the args tuple -- i.e., no special API
is required.

-- Alexandre

From greg.ewing at canterbury.ac.nz  Fri Jun  6 05:59:51 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 06 Jun 2008 15:59:51 +1200
Subject: [Python-3000] Single buffer implied in new buffer protocol?
In-Reply-To: <g28q26$st1$1@ger.gmane.org>
References: <g1675f$hf4$1@ger.gmane.org> <g1hvto$kh3$1@ger.gmane.org>
	<g1lhlt$988$1@ger.gmane.org> <g1odf8$ga8$1@ger.gmane.org>
	<loom.20080602T122726-345@post.gmane.org>
	<4845F48C.6030500@canterbury.ac.nz>
	<loom.20080604T083713-841@post.gmane.org>
	<48473FEF.3060503@canterbury.ac.nz>
	<g283k6$fg8$1@ger.gmane.org> <4847D901.2010501@gmail.com>
	<g28q26$st1$1@ger.gmane.org>
Message-ID: <4848B637.9090303@canterbury.ac.nz>

Stefan Behnel wrote:
> So that means it's fine to remove all locking related functionality from the
> new buffer protocol and leave everything to application space, right?

Not quite all of it -- the buffer needs to be considered
as locked against moving between calls to getbuffer and
releasebuffer, and providers that can move their memory
need to keep a count of outstanding getbuffer calls.

All the locking-related flags can go, though, since
there is only one kind of lock and it's implied by the
getbuffer call itself.

-- 
Greg

From andymac at bullseye.apana.org.au  Thu Jun  5 04:32:48 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Thu, 05 Jun 2008 13:32:48 +1100
Subject: [Python-3000] wrt the beta deadline and freelist management
In-Reply-To: <06BB1BB8-2C9C-4588-9B38-49DE234752E0@python.org>
References: <06BB1BB8-2C9C-4588-9B38-49DE234752E0@python.org>
Message-ID: <48475050.9090602@bullseye.andymac.org>

There are 2 disparate approaches to clearing/compacting free lists for
basic types:
- APIs of the form Py<type>_ClearFreeList() called from gc.collect()
   [class, frame, method, tuple & unicode types];
- APIs of the form Py<type>_CompactFreeList() called from
   sys._compact_freelists()  [int & float types];

Both approaches are new for 2.6 & 3.0.

The patch at http://bugs.python.org/issue2862 is geared towards bring
the int/float free list management into line with the others.

The patch at http://bugs.python.org/issue3029 adds free list management
to the dict, list & set types.  The value of this is probably minor,
and this patch is thus not significant in its own right other than for
consistency.

However Raymond's comment to issue 3029 that the management routines
shouldn't be public APIs is IMO important (& I happen to agree).

It would be nice to reduce the 2 approaches to one.

I would rather the gc.collect() approach, as this seems to be more
obvious to many users who have gone looking for free list management in
prior versions, however my opinion isn't particularly valuable on this.

Can this be resolved for 2.6/3.0?

Regards,
Andrew.

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

From stefan_ml at behnel.de  Fri Jun  6 08:38:05 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 06 Jun 2008 08:38:05 +0200
Subject: [Python-3000] How to specify keyword-only arguments from C?
In-Reply-To: <acd65fa20806051347u11250050pc23c1a9628170d54@mail.gmail.com>
References: <acd65fa20806051347u11250050pc23c1a9628170d54@mail.gmail.com>
Message-ID: <g2am0d$iv0$1@ger.gmane.org>

Alexandre Vassalotti wrote:
> Is there a way to specify keyword-only arguments using the C API. I
> searched through the mailing list archive, read PEP 3102 and grep-ed
> the codebase, but I found nothing looking like a C API. So I am
> wondering, is this a Python-only feature?

Cython also has it.

http://cython.org/

Stefan


From stefan_ml at behnel.de  Fri Jun  6 08:39:08 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 06 Jun 2008 08:39:08 +0200
Subject: [Python-3000] Single buffer implied in new buffer protocol?
In-Reply-To: <4848B637.9090303@canterbury.ac.nz>
References: <g1675f$hf4$1@ger.gmane.org>
	<g1hvto$kh3$1@ger.gmane.org>	<g1lhlt$988$1@ger.gmane.org>
	<g1odf8$ga8$1@ger.gmane.org>	<loom.20080602T122726-345@post.gmane.org>	<4845F48C.6030500@canterbury.ac.nz>	<loom.20080604T083713-841@post.gmane.org>	<48473FEF.3060503@canterbury.ac.nz>	<g283k6$fg8$1@ger.gmane.org>
	<4847D901.2010501@gmail.com>	<g28q26$st1$1@ger.gmane.org>
	<4848B637.9090303@canterbury.ac.nz>
Message-ID: <g2am2c$iv0$2@ger.gmane.org>

Greg Ewing wrote:
> Stefan Behnel wrote:
>> So that means it's fine to remove all locking related functionality
>> from the
>> new buffer protocol and leave everything to application space, right?
> 
> Not quite all of it -- the buffer needs to be considered
> as locked against moving between calls to getbuffer and
> releasebuffer, and providers that can move their memory
> need to keep a count of outstanding getbuffer calls.
> 
> All the locking-related flags can go, though, since
> there is only one kind of lock and it's implied by the
> getbuffer call itself.

;) did you read my patch?

Stefan


From stefan_ml at behnel.de  Fri Jun  6 08:49:11 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 06 Jun 2008 08:49:11 +0200
Subject: [Python-3000] Single buffer implied in new buffer protocol?
In-Reply-To: <g28q26$st1$1@ger.gmane.org>
References: <g1675f$hf4$1@ger.gmane.org>	<g1hvto$kh3$1@ger.gmane.org>	<g1lhlt$988$1@ger.gmane.org>	<g1odf8$ga8$1@ger.gmane.org>	<loom.20080602T122726-345@post.gmane.org>	<4845F48C.6030500@canterbury.ac.nz>	<loom.20080604T083713-841@post.gmane.org>	<48473FEF.3060503@canterbury.ac.nz>	<g283k6$fg8$1@ger.gmane.org>	<4847D901.2010501@gmail.com>
	<g28q26$st1$1@ger.gmane.org>
Message-ID: <g2aml7$kb1$1@ger.gmane.org>

Stefan Behnel wrote:
> So that means it's fine to remove all locking related functionality from the
> new buffer protocol and leave everything to application space, right?
> 
> Here is a patch for the PEP that reflects this.

I filed this as bug #3046.

http://bugs.python.org/issue3046

Stefan


From abpillai at gmail.com  Fri Jun  6 09:42:02 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Fri, 6 Jun 2008 13:12:02 +0530
Subject: [Python-3000] Persistent Error
Message-ID: <8548c5f30806060042s10c25d7gb3a0d347d61b91e@mail.gmail.com>

Hi,

    I have been getting the following persistent error with Python 3.0
since an April 15 update of the subversion trunk (svn version 62349)

I am running Fedora Core 6, with kernel 2.6.22.7-57.fc6 on
an Intel i686 SMP box.  Python was compiled with gcc
version 4.1.2 (Redhat - 4.1.2-13). Python was built with
no additional ./configure flags.

[anand at localhost py3k]$ /usr/local/bin/python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/io.py", line 63, in <module>
    import warnings
  File "/usr/local/lib/python3.0/warnings.py", line 283, in <module>
    bytes_warning = sys.flags.bytes_warning
AttributeError: 'sys.flags' object has no attribute 'bytes_warning'
Aborted

I have tried everything including removing the previous library folders
(/usr/local/lib/python-3.0), checking out the trunk fresh and building it
multiple times. Still the error is persistent. Every time I update my
svn, I have to comment out lines 280-290 in warnings.py for
Python3.0 to work.

I had posted a similar mail on April 15 titled "Trunk broken ?" but
at that time thought it was a random error.
-- 
-Anand

From amauryfa at gmail.com  Fri Jun  6 10:29:10 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Fri, 6 Jun 2008 10:29:10 +0200
Subject: [Python-3000] Persistent Error
In-Reply-To: <8548c5f30806060042s10c25d7gb3a0d347d61b91e@mail.gmail.com>
References: <8548c5f30806060042s10c25d7gb3a0d347d61b91e@mail.gmail.com>
Message-ID: <e27efe130806060129n3ee93c34m527bb141b6b8dbeb@mail.gmail.com>

Hello,

Anand Balachandran Pillai wrote:
> Hi,
>
>    I have been getting the following persistent error with Python 3.0
> since an April 15 update of the subversion trunk (svn version 62349)
>
> I am running Fedora Core 6, with kernel 2.6.22.7-57.fc6 on
> an Intel i686 SMP box.  Python was compiled with gcc
> version 4.1.2 (Redhat - 4.1.2-13). Python was built with
> no additional ./configure flags.
>
> [anand at localhost py3k]$ /usr/local/bin/python
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>  File "/usr/local/lib/python3.0/io.py", line 63, in <module>
>    import warnings
>  File "/usr/local/lib/python3.0/warnings.py", line 283, in <module>
>    bytes_warning = sys.flags.bytes_warning
> AttributeError: 'sys.flags' object has no attribute 'bytes_warning'
> Aborted

It seems that there are two problems here:
- First, there is a bug in the sys.flags structure: revision 62322
added a new flag in the underlying C structure, but did not increase
the number of fields visible from python code. This should be
corrected: in sysmodules.c, the number in the flags_desc initializer
should match the number of items in flags_fields.

- Then, it seems that warnings.py could not import the C-based
"_warnings" module. Could you modify warnings.py and remove the
"except ImportError" clause to see why?

-- 
Amaury Forgeot d'Arc

From abpillai at gmail.com  Fri Jun  6 10:37:12 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Fri, 6 Jun 2008 14:07:12 +0530
Subject: [Python-3000] Persistent Error
In-Reply-To: <e27efe130806060129n3ee93c34m527bb141b6b8dbeb@mail.gmail.com>
References: <8548c5f30806060042s10c25d7gb3a0d347d61b91e@mail.gmail.com>
	<e27efe130806060129n3ee93c34m527bb141b6b8dbeb@mail.gmail.com>
Message-ID: <8548c5f30806060137s3692dcf9veb44332065559c43@mail.gmail.com>

Hi Amaury,

After commenting out the code which catches the ImportError,
this is the trace.

[anand at localhost ~]$ python3
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/io.py", line 63, in <module>
    import warnings
  File "/usr/local/lib/python3.0/warnings.py", line 268, in <module>
    from _warnings import (filters, default_action, once_registry,
ImportError: No module named _warnings
Aborted

Regards

--Anand

On Fri, Jun 6, 2008 at 1:59 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> Hello,
>
> Anand Balachandran Pillai wrote:
>> Hi,
>>
>>    I have been getting the following persistent error with Python 3.0
>> since an April 15 update of the subversion trunk (svn version 62349)
>>
>> I am running Fedora Core 6, with kernel 2.6.22.7-57.fc6 on
>> an Intel i686 SMP box.  Python was compiled with gcc
>> version 4.1.2 (Redhat - 4.1.2-13). Python was built with
>> no additional ./configure flags.
>>
>> [anand at localhost py3k]$ /usr/local/bin/python
>> Fatal Python error: Py_Initialize: can't initialize sys standard streams
>> Traceback (most recent call last):
>>  File "/usr/local/lib/python3.0/io.py", line 63, in <module>
>>    import warnings
>>  File "/usr/local/lib/python3.0/warnings.py", line 283, in <module>
>>    bytes_warning = sys.flags.bytes_warning
>> AttributeError: 'sys.flags' object has no attribute 'bytes_warning'
>> Aborted
>
> It seems that there are two problems here:
> - First, there is a bug in the sys.flags structure: revision 62322
> added a new flag in the underlying C structure, but did not increase
> the number of fields visible from python code. This should be
> corrected: in sysmodules.c, the number in the flags_desc initializer
> should match the number of items in flags_fields.
>
> - Then, it seems that warnings.py could not import the C-based
> "_warnings" module. Could you modify warnings.py and remove the
> "except ImportError" clause to see why?
>
> --
> Amaury Forgeot d'Arc
>



-- 
-Anand

From stefan_ml at behnel.de  Fri Jun  6 10:52:32 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 06 Jun 2008 10:52:32 +0200
Subject: [Python-3000] Persistent Error
In-Reply-To: <8548c5f30806060137s3692dcf9veb44332065559c43@mail.gmail.com>
References: <8548c5f30806060042s10c25d7gb3a0d347d61b91e@mail.gmail.com>	<e27efe130806060129n3ee93c34m527bb141b6b8dbeb@mail.gmail.com>
	<8548c5f30806060137s3692dcf9veb44332065559c43@mail.gmail.com>
Message-ID: <g2atsf$cek$1@ger.gmane.org>

Anand Balachandran Pillai wrote:
> After commenting out the code which catches the ImportError,
> this is the trace.
> 
> [anand at localhost ~]$ python3
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>   File "/usr/local/lib/python3.0/io.py", line 63, in <module>
>     import warnings
>   File "/usr/local/lib/python3.0/warnings.py", line 268, in <module>
>     from _warnings import (filters, default_action, once_registry,
> ImportError: No module named _warnings
> Aborted

Looks like you should rebuild your Python and check for build errors in the
_warnings module.

Stefan


From g.brandl at gmx.net  Fri Jun  6 13:02:18 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 06 Jun 2008 11:02:18 +0000
Subject: [Python-3000] Persistent Error
In-Reply-To: <e27efe130806060129n3ee93c34m527bb141b6b8dbeb@mail.gmail.com>
References: <8548c5f30806060042s10c25d7gb3a0d347d61b91e@mail.gmail.com>
	<e27efe130806060129n3ee93c34m527bb141b6b8dbeb@mail.gmail.com>
Message-ID: <g2aufa$dmr$1@ger.gmane.org>

Amaury Forgeot d'Arc schrieb:

> It seems that there are two problems here:
> - First, there is a bug in the sys.flags structure: revision 62322
> added a new flag in the underlying C structure, but did not increase
> the number of fields visible from python code. This should be
> corrected: in sysmodules.c, the number in the flags_desc initializer
> should match the number of items in flags_fields.

It is strange though since I *can* access sys.flags.bytes_warning even
though it's not available via indexing or printed in the repr.

Anyway, fixed and added a test in r63978.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From mal at egenix.com  Fri Jun  6 11:19:29 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 06 Jun 2008 11:19:29 +0200
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <52dc1c820806021629k5491e8c0u67e8a6f5247d2368@mail.gmail.com>
References: <48397ECC.9070805@cheimes.de>
	<483ECA52.6040000@egenix.com>	<483ECF94.7060607@cheimes.de>
	<483EF139.8000606@egenix.com>	<483F34C3.3050402@gmail.com>
	<483FBCB4.5020007@egenix.com>	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>	<4843E884.1060705@egenix.com>	<52dc1c820806021521g810d9f1wd282508f8452c13@mail.gmail.com>	<ca471dc20806021609v258d7e8bk66b259694dd469b5@mail.gmail.com>
	<52dc1c820806021629k5491e8c0u67e8a6f5247d2368@mail.gmail.com>
Message-ID: <48490121.5030701@egenix.com>

On 2008-06-03 01:29, Gregory P. Smith wrote:
> On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <guido at python.org> wrote:
> 
>> I will freely admit that I haven't followed this thread in any detail,
>> but if it were up to me, I'd have the 2.6 internal code use PyString
> 
> ...
> 
> Should we read this as a BDFL pronouncement and make it so?
> 
> All that would mean change wise is that trunk r63675 as well as possibly
> r63672 and r63677 would need to be rolled back and this whole discussion
> over if such a big change should have happened would turn into a moot point.

I would certainly welcome reverting the change.

All that's needed to support PyBytes API in 2.x is a set of #defines
that map the new APIs to the PyString names. That's a clean and
easily understandable solution.

Programmers interested in the code
for a PyString API can then still look up the code in stringobject.c,
e.g. to find out how a certain special case is handled or to check
the ref counting - just like they did for years.

Developer who want to start differentiating between mixed byte/text
data and bytes-only can start using PyBytes for byte data.

>> I would also add macros that map the PyBytes_* APIs to PyString_*, but
>> I would not start using these internally except in code newly written
>> for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString
>> for 8-bit strings containing text, and PyBytes for 8-bit strings
>> containing binary data. For 8-bit strings that could contain either
>> text or data, I'd use PyString, in the spirit of 2.x.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 06 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/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            30 days to go

:::: 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 abpillai at gmail.com  Fri Jun  6 11:45:04 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Fri, 6 Jun 2008 15:15:04 +0530
Subject: [Python-3000] Persistent Error
In-Reply-To: <g2atsf$cek$1@ger.gmane.org>
References: <8548c5f30806060042s10c25d7gb3a0d347d61b91e@mail.gmail.com>
	<e27efe130806060129n3ee93c34m527bb141b6b8dbeb@mail.gmail.com>
	<8548c5f30806060137s3692dcf9veb44332065559c43@mail.gmail.com>
	<g2atsf$cek$1@ger.gmane.org>
Message-ID: <8548c5f30806060245r658ffa29v44e2b4e12e277fa7@mail.gmail.com>

Hi Stefan,

   There are no build errors in the warnings module and _warnings.o is
generated.
However I looked at the make log and no _warnings.so is built by the
linker. Instead
_warnings.o is just archived into libpython3.0a.

Cannot find any error in config.log either. I tried to check how
_warnings.so was
built in previous Python versions (<=2.5) but apparently there is no
_warnings.so
in Python 2.5 and earlier, only warnings.py .

 I tried to build a _warnings.so manually and then copy it to
lib-dynload folder.
First time it failed with an Import Error.

$gcc -pthread -shared /home/anand/projects/py3k/Python/_warnings.o
-L/usr/local/lib -o build/lib.linux-i686-3.0/_warnings.so
$sudo cp build/lib.linux-i686-3.0/_warnings.so
/usr/local/lib/python3.0/lib-dynload/

[anand at localhost ~]$ python3
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/io.py", line 63, in <module>
    import warnings
  File "/usr/local/lib/python3.0/warnings.py", line 268, in <module>
    from _warnings import (filters, default_action, once_registry,
ImportError: /usr/local/lib/python3.0/lib-dynload/_warnings.so:
undefined symbol: Py_DisplaySourceLine
Aborted

I figured Py_DisplaySourceLine is present in traceback.o, so did this
(clearly a wrong
way, but just to see if it works...)

$ gcc -pthread -shared /home/anand/projects/py3k/Python/_warnings.o
/home/anand/projects/py3k/Python/traceback.o -L/usr/local/lib -o
build/lib.linux-i686-3.0/_warnings.so
$ sudo cp build/lib.linux-i686-3.0/_warnings.so
/usr/local/lib/python3.0/lib-dynload/

Now it produces this error.

[anand at localhost py3k]$ python3
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/io.py", line 63, in <module>
    import warnings
  File "/usr/local/lib/python3.0/warnings.py", line 268, in <module>
    from _warnings import (filters, default_action, once_registry,
ImportError: dynamic module does not define init function (init_warnings)
Aborted

Basically, I am stumped at this point. Any help is appreciated.

Regards

--Anand

On Fri, Jun 6, 2008 at 2:22 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Anand Balachandran Pillai wrote:
>> After commenting out the code which catches the ImportError,
>> this is the trace.
>>
>> [anand at localhost ~]$ python3
>> Fatal Python error: Py_Initialize: can't initialize sys standard streams
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python3.0/io.py", line 63, in <module>
>>     import warnings
>>   File "/usr/local/lib/python3.0/warnings.py", line 268, in <module>
>>     from _warnings import (filters, default_action, once_registry,
>> ImportError: No module named _warnings
>> Aborted
>
> Looks like you should rebuild your Python and check for build errors in the
> _warnings module.
>
> 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/abpillai%40gmail.com
>



-- 
-Anand

From amauryfa at gmail.com  Fri Jun  6 11:55:52 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Fri, 6 Jun 2008 11:55:52 +0200
Subject: [Python-3000] Persistent Error
In-Reply-To: <8548c5f30806060245r658ffa29v44e2b4e12e277fa7@mail.gmail.com>
References: <8548c5f30806060042s10c25d7gb3a0d347d61b91e@mail.gmail.com>
	<e27efe130806060129n3ee93c34m527bb141b6b8dbeb@mail.gmail.com>
	<8548c5f30806060137s3692dcf9veb44332065559c43@mail.gmail.com>
	<g2atsf$cek$1@ger.gmane.org>
	<8548c5f30806060245r658ffa29v44e2b4e12e277fa7@mail.gmail.com>
Message-ID: <e27efe130806060255j4201e93eva6bca52bab9902a1@mail.gmail.com>

Anand Balachandran Pillai wrote:
> Hi Stefan,
>
>   There are no build errors in the warnings module and _warnings.o is
> generated.
> However I looked at the make log and no _warnings.so is built by the
> linker. Instead
> _warnings.o is just archived into libpython3.0a.
...

Yes, _warnings is not designed to be a .so module.

Please have a look at Modules/config.c (which lists the built-in
modules loaded on startup),
it should contain an entry for "_warnings".
Note that this file is generated from Modules/config.c.in. Check it as well.

Maybe the config.c file was not properly re-generated?

-- 
Amaury Forgeot d'Arc

From humberto at digi.com.br  Fri Jun  6 12:02:07 2008
From: humberto at digi.com.br (Humberto Diogenes)
Date: Fri, 6 Jun 2008 07:02:07 -0300
Subject: [Python-3000] TextIOWrapper.read() "fixed"?
Message-ID: <55352E2A-D21C-4CA8-BA0D-B5752257B410@digi.com.br>


   I found this on Lib/email/parser.py, on Parser.parse():

         while True:
             data = fp.read(8192)
             if not data:
                 break
             # XXX When Guido fixes TextIOWrapper.read() to act just  
like
             # .readlines(), this...
             feedparser.feed(str(data))
             # ...gets reverted back to
             #feedparser.feed(data)
         return feedparser.close()

   Is that still necessary?

   I noticed it while trying to migrate http.client.HTTPMessage away  
from mimetools (issue 2848). I was having problems when parse()  
received bytes directly, as they were being converted to 'b"..."'  
strings.

   BTW, is TextIOWrapper+BufferedReader the right solution to read a  
string from a socket?

# In HTTPResponse:
-        self.msg = HTTPMessage(self.fp, 0)
+        parser = email.parser.HeaderParser(_class=HTTPMessage)
+        fp = io.TextIOWrapper(io.BufferedReader(self.fp), 'latin1')
+        self.msg = parser.parse(fp)


--
Humberto Di?genes
http://humberto.digi.com.br


From abpillai at gmail.com  Fri Jun  6 12:20:36 2008
From: abpillai at gmail.com (Anand Balachandran Pillai)
Date: Fri, 6 Jun 2008 15:50:36 +0530
Subject: [Python-3000] Persistent Error
In-Reply-To: <e27efe130806060255j4201e93eva6bca52bab9902a1@mail.gmail.com>
References: <8548c5f30806060042s10c25d7gb3a0d347d61b91e@mail.gmail.com>
	<e27efe130806060129n3ee93c34m527bb141b6b8dbeb@mail.gmail.com>
	<8548c5f30806060137s3692dcf9veb44332065559c43@mail.gmail.com>
	<g2atsf$cek$1@ger.gmane.org>
	<8548c5f30806060245r658ffa29v44e2b4e12e277fa7@mail.gmail.com>
	<e27efe130806060255j4201e93eva6bca52bab9902a1@mail.gmail.com>
Message-ID: <8548c5f30806060320y6255a65bu4ee55763987ef55c@mail.gmail.com>

Hi Amaury,

 This is the entry for _warnings.

   /* This lives in _warnings.c */
    {"_warnings", _PyWarnings_Init},

 Btw, you said _warnings is not designed to be a .so module. So what type of
module is _warnings ?

Thanks

--Anand

On Fri, Jun 6, 2008 at 3:25 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> Anand Balachandran Pillai wrote:
>> Hi Stefan,
>>
>>   There are no build errors in the warnings module and _warnings.o is
>> generated.
>> However I looked at the make log and no _warnings.so is built by the
>> linker. Instead
>> _warnings.o is just archived into libpython3.0a.
> ...
>
> Yes, _warnings is not designed to be a .so module.
>
> Please have a look at Modules/config.c (which lists the built-in
> modules loaded on startup),
> it should contain an entry for "_warnings".
> Note that this file is generated from Modules/config.c.in. Check it as well.
>
> Maybe the config.c file was not properly re-generated?
>
> --
> Amaury Forgeot d'Arc
>



-- 
-Anand

From amauryfa at gmail.com  Fri Jun  6 13:35:06 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Fri, 6 Jun 2008 13:35:06 +0200
Subject: [Python-3000] Persistent Error
In-Reply-To: <8548c5f30806060320y6255a65bu4ee55763987ef55c@mail.gmail.com>
References: <8548c5f30806060042s10c25d7gb3a0d347d61b91e@mail.gmail.com>
	<e27efe130806060129n3ee93c34m527bb141b6b8dbeb@mail.gmail.com>
	<8548c5f30806060137s3692dcf9veb44332065559c43@mail.gmail.com>
	<g2atsf$cek$1@ger.gmane.org>
	<8548c5f30806060245r658ffa29v44e2b4e12e277fa7@mail.gmail.com>
	<e27efe130806060255j4201e93eva6bca52bab9902a1@mail.gmail.com>
	<8548c5f30806060320y6255a65bu4ee55763987ef55c@mail.gmail.com>
Message-ID: <e27efe130806060435g54238a0cl731bf8efb459506c@mail.gmail.com>

Anand Balachandran Pillai wrote:
> Hi Amaury,
>
>  This is the entry for _warnings.
>
>   /* This lives in _warnings.c */
>    {"_warnings", _PyWarnings_Init},

Did you find this in Modules/config.c?

>  Btw, you said _warnings is not designed to be a .so module. So what type of
> module is _warnings ?

It's a built-in module.

A module is said "built-in" if its initialization function is linked
inside the main program.
When you "import _warnings", python looks inside the list defined in
config.c, and runs the _PyWarnings_Init function it found there.

An extension module resides in a .so, which name is also the name of the module.
Its initialization function must be of the form "init%s"
It's not the case for _warnings. You would have to rename
_PyWarnings_Init to init_warnings...

-- 
Amaury Forgeot d'Arc

From mal at egenix.com  Fri Jun  6 14:24:16 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 06 Jun 2008 14:24:16 +0200
Subject: [Python-3000] .transform() / .untransform()
In-Reply-To: <48242D4A.3060802@egenix.com>
References: <797440730805060655j3250ab22le3220c76e5403ea4@mail.gmail.com><482066E3.7030209@gmail.com>	<482335CE.7000309@egenix.com>	<fvvpc7$32i$1@ger.gmane.org>
	<48242D4A.3060802@egenix.com>
Message-ID: <48492C70.2050706@egenix.com>

On 2008-05-09 12:54, M.-A. Lemburg wrote:
> On 2008-05-08 22:55, Terry Reedy wrote:
>> Functions that map unicode->unicode or bytes->bytes could be called 
>> transcoders.  Each type could be given a .transcode method to go along 
>> with but contrast with .encode or .decode.
> 
> Are you suggesting to have two separate methods which then
> allow same-type-conversions ? One for encoding to the same
> type and one for decoding ?
> 
> Fine with me.
> 
> They do have to map naturally to the codec method encode and
> decode, though, so a single method won't do, unless maybe
> you add a parameter to define the direction of the coding
> process.
> 
> In summary, I'd just like to see the following happen:
> 
>  * revert the type restrictions on the PyCodec_* API
> 
>  * enforce the restrictions on the .encode() and .decode()
>    methods of PyUnicode and PyString objects (str and bytes)

FYI: The above two bullets have now been implemented as r63986.

>  * add a way to PyUnicode and PyString objects (str and bytes)
>    to allow same type encoding and decoding

This is still pending, ie. methods .transform() and .untransform()
still need to be added to bytes/bytearray/str.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 06 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/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            30 days to go

:::: 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  Fri Jun  6 20:14:07 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 6 Jun 2008 11:14:07 -0700
Subject: [Python-3000] TextIOWrapper.read() "fixed"?
In-Reply-To: <55352E2A-D21C-4CA8-BA0D-B5752257B410@digi.com.br>
References: <55352E2A-D21C-4CA8-BA0D-B5752257B410@digi.com.br>
Message-ID: <ca471dc20806061114g17b33a9ela739e49d8f4340d3@mail.gmail.com>

On Fri, Jun 6, 2008 at 3:02 AM, Humberto Diogenes <humberto at digi.com.br> wrote:
>
>  I found this on Lib/email/parser.py, on Parser.parse():
>
>        while True:
>            data = fp.read(8192)
>            if not data:
>                break
>            # XXX When Guido fixes TextIOWrapper.read() to act just like
>            # .readlines(), this...
>            feedparser.feed(str(data))
>            # ...gets reverted back to
>            #feedparser.feed(data)
>        return feedparser.close()
>
>  Is that still necessary?

I can't tell for sure what Barry meant, but this was introduced in
August 2007. Since then, a lot has changed in io.py. Why don't you try
taking it out?

>  I noticed it while trying to migrate http.client.HTTPMessage away from
> mimetools (issue 2848). I was having problems when parse() received bytes
> directly, as they were being converted to 'b"..."' strings.
>
>  BTW, is TextIOWrapper+BufferedReader the right solution to read a string
> from a socket?
>
> # In HTTPResponse:
> -        self.msg = HTTPMessage(self.fp, 0)
> +        parser = email.parser.HeaderParser(_class=HTTPMessage)
> +        fp = io.TextIOWrapper(io.BufferedReader(self.fp), 'latin1')
> +        self.msg = parser.parse(fp)

Probably. This is what the socket class's own makefile() method does.
Read all about it in socket.py.

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

From oliphant.travis at ieee.org  Fri Jun  6 22:45:10 2008
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Fri, 06 Jun 2008 15:45:10 -0500
Subject: [Python-3000] Single buffer implied in new buffer protocol?
In-Reply-To: <g2aml7$kb1$1@ger.gmane.org>
References: <g1675f$hf4$1@ger.gmane.org>	<g1hvto$kh3$1@ger.gmane.org>	<g1lhlt$988$1@ger.gmane.org>	<g1odf8$ga8$1@ger.gmane.org>	<loom.20080602T122726-345@post.gmane.org>	<4845F48C.6030500@canterbury.ac.nz>	<loom.20080604T083713-841@post.gmane.org>	<48473FEF.3060503@canterbury.ac.nz>	<g283k6$fg8$1@ger.gmane.org>	<4847D901.2010501@gmail.com>	<g28q26$st1$1@ger.gmane.org>
	<g2aml7$kb1$1@ger.gmane.org>
Message-ID: <g2c7km$uud$1@ger.gmane.org>

Stefan Behnel wrote:
> Stefan Behnel wrote:
>> So that means it's fine to remove all locking related functionality from the
>> new buffer protocol and leave everything to application space, right?
>>
>> Here is a patch for the PEP that reflects this.
> 
> I filed this as bug #3046.
> 
> http://bugs.python.org/issue3046
> 

As I mentioned on the tracker,  I support removing the locking API from 
PEP 3118.   If needed it can be added back later under a separate API 
entirely.   It is clear that it is a separate issue.

I do think it is a useful issue, however, and would like to see some 
discussion of it in the future --- especially in the context of a future 
shared memory object for Python.

-Travis





From eric+python-dev at trueblade.com  Sat Jun  7 00:53:42 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Fri, 06 Jun 2008 18:53:42 -0400
Subject: [Python-3000] PEP 3101 str.format() equivalent of '%#o/x/X'?
In-Reply-To: <483F37DF.5060507@gmail.com>
References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4@mail.gmail.com>	<483EAF95.5050503@trueblade.com>	<3f4107910805291116w37af38e3qb2c5145539d7e23e@mail.gmail.com>
	<483F06FF.9090007@trueblade.com> <483F37DF.5060507@gmail.com>
Message-ID: <4849BFF6.9060902@trueblade.com>

Nick Coghlan wrote:
> Doing the right thing for negative numbers is a good point. It also 
> means the prefix can be handled properly when dealing with aligned 
> fields. The following update to the standard format specifier in the PEP:
> 
>   [[fill]align][#][sign][0][minimumwidth][.precision][type]
> 
>   The '#' prefix option inserts the appropriate prefix characters ('0b', 
> '0o', '0x', '0X') when displaying numbers in binary, octal or 
> hexadecimal formats. The prefix is inserted into the displayed number 
> after the sign character and fill characters (if any), but before any 
> leading zeroes.

I was implementing this today, and I note that %-formatting doesn't 
specify an order among the #, sign, and 0 flags (at least not that I 
could tell by experimentation).  PEP 3101 does say that sign comes 
before 0 for str.format().  Do we want the # to come before sign?  Do we 
want an order at all?

This sort of surprised me when I was writing tests.  Even after having 
implemented it, I was expecting "-#x" to work, but it needs to be "#-x".

I don't mind there being a fixed order (in fact I prefer it for a number 
of reasons), I just want to make sure that the order specified above is 
what we want to go with.

Eric.

From humberto at digi.com.br  Sat Jun  7 05:43:12 2008
From: humberto at digi.com.br (Humberto Diogenes)
Date: Sat, 7 Jun 2008 00:43:12 -0300
Subject: [Python-3000] TextIOWrapper.read() "fixed"?
In-Reply-To: <ca471dc20806061114g17b33a9ela739e49d8f4340d3@mail.gmail.com>
References: <55352E2A-D21C-4CA8-BA0D-B5752257B410@digi.com.br>
	<ca471dc20806061114g17b33a9ela739e49d8f4340d3@mail.gmail.com>
Message-ID: <A71E7CCE-1E71-4754-B995-64F273EFD11C@digi.com.br>


On 06/06/2008, at 15:14, Guido van Rossum wrote:

> On Fri, Jun 6, 2008 at 3:02 AM, Humberto Diogenes <humberto at digi.com.br 
> > wrote:
>>
>> Is that still necessary?
>
> I can't tell for sure what Barry meant, but this was introduced in
> August 2007. Since then, a lot has changed in io.py. Why don't you try
> taking it out?

Removing it didn't affect any tests, so I think it can go away now:
http://bugs.python.org/file10537/email.parser-small_fix.patch

>> BTW, is TextIOWrapper+BufferedReader the right solution to read a  
>> string
>> from a socket?
>>
>> # In HTTPResponse:
>> -        self.msg = HTTPMessage(self.fp, 0)
>> +        parser = email.parser.HeaderParser(_class=HTTPMessage)
>> +        fp = io.TextIOWrapper(io.BufferedReader(self.fp), 'latin1')
>> +        self.msg = parser.parse(fp)
>
> Probably. This is what the socket class's own makefile() method does.
> Read all about it in socket.py.

I can't use makefile() there, so I believe I did the Right Thing?.

Thanks for the tip, Guido! socket.makefile really is a great demo. :)


--
Humberto Di?genes
http://humberto.digi.com.br


From bruce at leapyear.org  Sat Jun  7 08:48:55 2008
From: bruce at leapyear.org (Bruce Leban)
Date: Fri, 6 Jun 2008 23:48:55 -0700
Subject: [Python-3000] PEP 3101 str.format() equivalent of '%#o/x/X'?
In-Reply-To: <4849BFF6.9060902@trueblade.com>
References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4@mail.gmail.com>
	<483EAF95.5050503@trueblade.com>
	<3f4107910805291116w37af38e3qb2c5145539d7e23e@mail.gmail.com>
	<483F06FF.9090007@trueblade.com> <483F37DF.5060507@gmail.com>
	<4849BFF6.9060902@trueblade.com>
Message-ID: <cf5b87740806062348r5d0ac89al4d9f6529a4d88ad3@mail.gmail.com>

It seems somewhat illogical to require [#][sign] in that order when the
parts inserted by them go in the opposite order.

So if a specific order is required, then I think it should be reversed.

'=' padding goes in the wrong order too: perhaps -#0=20d makes more sense
than 0=-#20d. I don't find that quite as compelling and I don't think it's
worth having everything go in any order just so that one can. (Then again, I
like the printf style -#020d.)

--- Bruce

On Fri, Jun 6, 2008 at 3:53 PM, Eric Smith
<eric+python-dev at trueblade.com<eric%2Bpython-dev at trueblade.com>>
wrote:

> Nick Coghlan wrote:
>
>> Doing the right thing for negative numbers is a good point. It also means
>> the prefix can be handled properly when dealing with aligned fields. The
>> following update to the standard format specifier in the PEP:
>>
>>  [[fill]align][#][sign][0][minimumwidth][.precision][type]
>>
>>  The '#' prefix option inserts the appropriate prefix characters ('0b',
>> '0o', '0x', '0X') when displaying numbers in binary, octal or hexadecimal
>> formats. The prefix is inserted into the displayed number after the sign
>> character and fill characters (if any), but before any leading zeroes.
>>
>
> I was implementing this today, and I note that %-formatting doesn't specify
> an order among the #, sign, and 0 flags (at least not that I could tell by
> experimentation).  PEP 3101 does say that sign comes before 0 for
> str.format().  Do we want the # to come before sign?  Do we want an order at
> all?
>
> This sort of surprised me when I was writing tests.  Even after having
> implemented it, I was expecting "-#x" to work, but it needs to be "#-x".
>
> I don't mind there being a fixed order (in fact I prefer it for a number of
> reasons), I just want to make sure that the order specified above is what we
> want to go with.
>
> Eric.
>
> _______________________________________________
> 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/bruce%40leapyear.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080606/850f2135/attachment-0001.htm>

From carl at carlsensei.com  Sat Jun  7 13:14:48 2008
From: carl at carlsensei.com (Carl Johnson)
Date: Sat, 7 Jun 2008 01:14:48 -1000
Subject: [Python-3000] Minor documentation issue with pep-3119
Message-ID: <4063DC8E-BA84-4038-BFCD-AC27C86E0093@carlsensei.com>

Currently it states:

"""To solve these and similar dilemmas, the next section will propose  
a metaclass for use with ABCs that will allow us to add an ABC as a  
"virtual base class" (not the same concept as in C++) to any class,  
including to another ABC. This allows the standard library to define  
ABCs Sequence and MutableSequence and register these as virtual base  
classes for built-in types like basestring, tuple and list, so that  
for example the following conditions are all true:

<snip>

issubclass(bytes, MutableSequence)"""



Not true anymore! Someone should fix that to say Sequence instead.

Thanks,

Carl Johnson

From g.brandl at gmx.net  Sat Jun  7 16:56:49 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 07 Jun 2008 14:56:49 +0000
Subject: [Python-3000] Minor documentation issue with pep-3119
In-Reply-To: <4063DC8E-BA84-4038-BFCD-AC27C86E0093@carlsensei.com>
References: <4063DC8E-BA84-4038-BFCD-AC27C86E0093@carlsensei.com>
Message-ID: <g2e0j4$b2q$1@ger.gmane.org>

Fixed in r64010. Thanks!

Georg

Carl Johnson schrieb:
> Currently it states:
> 
> """To solve these and similar dilemmas, the next section will propose  
> a metaclass for use with ABCs that will allow us to add an ABC as a  
> "virtual base class" (not the same concept as in C++) to any class,  
> including to another ABC. This allows the standard library to define  
> ABCs Sequence and MutableSequence and register these as virtual base  
> classes for built-in types like basestring, tuple and list, so that  
> for example the following conditions are all true:
> 
> <snip>
> 
> issubclass(bytes, MutableSequence)"""
> 
> 
> 
> Not true anymore! Someone should fix that to say Sequence instead.
> 
> Thanks,
> 
> Carl Johnson


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From g.brandl at gmx.net  Sat Jun  7 17:04:59 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 07 Jun 2008 15:04:59 +0000
Subject: [Python-3000] BytesWarning for str != bytes
Message-ID: <g2e12k$clu$1@ger.gmane.org>

Hi,

python -b warns when you do "a" == b"a".  However, it doesn't warn when
you do "a" != b"a" which occurs not as frequently, but is usually also a
sign of a bug.

See the aifc.py module:

     def initfp(self, file):
         ...
         self._file = Chunk(file)
         if self._file.getname() != 'FORM':
             raise Error('file does not start with FORM id')

Where getname() returns a bytes object.  Wouldn't it make sense to have
!= issue the same warning as ==?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From greg at krypto.org  Sat Jun  7 17:28:58 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Sat, 7 Jun 2008 08:28:58 -0700
Subject: [Python-3000] [Python-Dev] wrt the beta deadline and freelist
	management
In-Reply-To: <48475050.9090602@bullseye.andymac.org>
References: <06BB1BB8-2C9C-4588-9B38-49DE234752E0@python.org>
	<48475050.9090602@bullseye.andymac.org>
Message-ID: <52dc1c820806070828x26e85a0bg6dad2c3188414315@mail.gmail.com>

On Wed, Jun 4, 2008 at 7:32 PM, Andrew MacIntyre <
andymac at bullseye.apana.org.au> wrote:

> There are 2 disparate approaches to clearing/compacting free lists for
> basic types:
> - APIs of the form Py<type>_ClearFreeList() called from gc.collect()
>  [class, frame, method, tuple & unicode types];
> - APIs of the form Py<type>_CompactFreeList() called from
>  sys._compact_freelists()  [int & float types];
>
> Both approaches are new for 2.6 & 3.0.
>
> The patch at http://bugs.python.org/issue2862 is geared towards bring
> the int/float free list management into line with the others.
>
> The patch at http://bugs.python.org/issue3029 adds free list management
> to the dict, list & set types.  The value of this is probably minor,
> and this patch is thus not significant in its own right other than for
> consistency.
>
> However Raymond's comment to issue 3029 that the management routines
> shouldn't be public APIs is IMO important (& I happen to agree).
>
> It would be nice to reduce the 2 approaches to one.
>
> I would rather the gc.collect() approach, as this seems to be more
> obvious to many users who have gone looking for free list management in
> prior versions, however my opinion isn't particularly valuable on this.
>
> Can this be resolved for 2.6/3.0?
>

I agree with the gc.collect approach taken in your issue2862 patch.  Barring
any objections, I suggest we accept it and will commit it in the next couple
days.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080607/a3aad932/attachment.htm>

From solipsis at pitrou.net  Sat Jun  7 23:19:09 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 7 Jun 2008 21:19:09 +0000 (UTC)
Subject: [Python-3000] PEP 3134 status ? (Exception Chaining)
Message-ID: <loom.20080607T210450-703@post.gmane.org>


Hello,

Along the discussion of issue 3021 (a patch for the exception nesting issues
already discussed here), Adam Olsen suggested I bring on this mailing-list
the subject of PEP 3134. Indeed, he remarked, the patch I proposed, by 
implementing proper exception stacking, should make it relatively easy to 
adding the '__context__' attribute of exceptions a.k.a. implicit exception 
chaining.

However, the official status of PEP 3134 is not clear (it is not officially 
accepted, though many features of it have been implemented). Should my patch 
in issue 3021 try to be as much "PEP 3134-compliant" as possible?

More precisely, the fact that PEP 3134 proposes implicit exception chaining 
to also work inside finally blocks implies a more complicated implementation 
(mostly because the 'with' statement (ab)uses the existing try/finally 
infrastructure and likes to muck around with the interpreter stack).

In any case, both versions of the patch are available: the one which also
implies exception stacking in "finally" blocks, and the one which doesn't. 

Regards

Antoine.



From alexandre at peadrop.com  Mon Jun  9 00:26:17 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Sun, 8 Jun 2008 18:26:17 -0400
Subject: [Python-3000] Simplifying the copy protocol
Message-ID: <acd65fa20806081526l73062e4dn308a65261ceba2f6@mail.gmail.com>

Hello all,

I would like to propose to following simplifications to the copy
protocol (a.k.a the __reduce__ method):

  - Remove the type.__reduce_ex__ method and define __reduce__ method
to take a single optional integer argument that is the pickle protocol
version to use. And since this already the current behavior of
__reduce__, no change is required.
  - Deprecate copyreg.pickle in favor of the __getnewargs__ special
method. They both solve the exact same problem, but __getnewargs__
does it in a simpler and more robust manner.
  - Make __reduce__ raise a TypeError if the class of an instance
derives from one or more extension type (object, list and dict
excluded) and neither __getnewargs__ nor __getstate__ is defined.

I believe that these changes will make it easier for developers to
write classes that supports the copy protocol, which is already quite
complex in addition of being poorly documented. Evidently, I will
provide the patches and write the documentation for these changes.

Cheers,
-- Alexandre

From hughpittman at yahoo.com.au  Fri Jun  6 22:07:12 2008
From: hughpittman at yahoo.com.au (Hugh Pittman)
Date: Fri, 6 Jun 2008 13:07:12 -0700 (PDT)
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
Message-ID: <935271.36063.qm@web53711.mail.re2.yahoo.com>

I have been unable to install 3.0a5 on a Vista / AMD64 platform. 
I downloaded the amd64 3.0a5 installer and I have tried various ideas but always find that Vista complains that 'Installation package could not be opened'.
I would be grateful for instruction from anyone who has done this.
Cheers,
Hugh


      Get the name you always wanted with the new y7mail email address.
www.yahoo7.com.au/mail

From musiccomposition at gmail.com  Mon Jun  9 05:14:15 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 8 Jun 2008 22:14:15 -0500
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <935271.36063.qm@web53711.mail.re2.yahoo.com>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>
Message-ID: <1afaf6160806082014q67ce5495u20dc8c93255c1a33@mail.gmail.com>

Hi Hugh,
A better place to ask this would be the comp.lang.python newsgroup.

On Fri, Jun 6, 2008 at 3:07 PM, Hugh Pittman <hughpittman at yahoo.com.au> wrote:
> I have been unable to install 3.0a5 on a Vista / AMD64 platform.
> I downloaded the amd64 3.0a5 installer and I have tried various ideas but always find that Vista complains that 'Installation package could not be opened'.
> I would be grateful for instruction from anyone who has done this.
> Cheers,
> Hugh
>
>
>      Get the name you always wanted with the new y7mail email address.
> www.yahoo7.com.au/mail
> _______________________________________________
> 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  Mon Jun  9 07:16:51 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Jun 2008 07:16:51 +0200
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <935271.36063.qm@web53711.mail.re2.yahoo.com>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>
Message-ID: <484CBCC3.7080104@v.loewis.de>

> I have been unable to install 3.0a5 on a Vista / AMD64 platform. I
> downloaded the amd64 3.0a5 installer and I have tried various ideas
> but always find that Vista complains that 'Installation package could
> not be opened'.

Please run "msiexec /i <packagename> /l*v log.txt", and report what
kind of error shows up in the log file. If you cannot interpret the
log file, submit a bug report to bugs.python.org.

Regards,
Martin


From greg at krypto.org  Mon Jun  9 07:20:36 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 8 Jun 2008 22:20:36 -0700
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <48490121.5030701@egenix.com>
References: <48397ECC.9070805@cheimes.de> <483EF139.8000606@egenix.com>
	<483F34C3.3050402@gmail.com> <483FBCB4.5020007@egenix.com>
	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>
	<4843E884.1060705@egenix.com>
	<52dc1c820806021521g810d9f1wd282508f8452c13@mail.gmail.com>
	<ca471dc20806021609v258d7e8bk66b259694dd469b5@mail.gmail.com>
	<52dc1c820806021629k5491e8c0u67e8a6f5247d2368@mail.gmail.com>
	<48490121.5030701@egenix.com>
Message-ID: <52dc1c820806082220n2f0832e1l7af4bc2fecf31987@mail.gmail.com>

On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> On 2008-06-03 01:29, Gregory P. Smith wrote:
>
>> On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <guido at python.org>
>> wrote:
>>
>>  I will freely admit that I haven't followed this thread in any detail,
>>> but if it were up to me, I'd have the 2.6 internal code use PyString
>>>
>>
>> ...
>>
>> Should we read this as a BDFL pronouncement and make it so?
>>
>> All that would mean change wise is that trunk r63675 as well as possibly
>> r63672 and r63677 would need to be rolled back and this whole discussion
>> over if such a big change should have happened would turn into a moot
>> point.
>>
>
> I would certainly welcome reverting the change.
>
> All that's needed to support PyBytes API in 2.x is a set of #defines
> that map the new APIs to the PyString names. That's a clean and
> easily understandable solution.
>

Okay, I've reverted r63675 in trunk revision r64048.  That leaves all of the
python modules and internals using PyString_ api names instead of PyBytes_
api names as they were before.  PyBytes_ #define's exist for the appropriate
PyString methods incase anyone wants to use those.

Programmers interested in the code
> for a PyString API can then still look up the code in stringobject.c,
> e.g. to find out how a certain special case is handled or to check
> the ref counting - just like they did for years.


The files still exist with the new names.  bytesobject.c instead of
stringobject.c.  Those renames were done in the other CLs i mentioned which
have not yet been reverted.  The current state seems a bit odd because they
depend on the #defines to cause method definitions to be the PyString_ names
instead of the PyBytes_ names.


>
>
> Developer who want to start differentiating between mixed byte/text
> data and bytes-only can start using PyBytes for byte data.
>
>  I would also add macros that map the PyBytes_* APIs to PyString_*, but
>>> I would not start using these internally except in code newly written
>>> for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString
>>> for 8-bit strings containing text, and PyBytes for 8-bit strings
>>> containing binary data. For 8-bit strings that could contain either
>>> text or data, I'd use PyString, in the spirit of 2.x.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080608/efa67dcf/attachment.htm>

From ncoghlan at gmail.com  Mon Jun  9 08:07:28 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 09 Jun 2008 16:07:28 +1000
Subject: [Python-3000] PEP 3101 str.format() equivalent of '%#o/x/X'?
In-Reply-To: <4849BFF6.9060902@trueblade.com>
References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4@mail.gmail.com>	<483EAF95.5050503@trueblade.com>	<3f4107910805291116w37af38e3qb2c5145539d7e23e@mail.gmail.com>	<483F06FF.9090007@trueblade.com>
	<483F37DF.5060507@gmail.com> <4849BFF6.9060902@trueblade.com>
Message-ID: <484CC8A0.2070804@gmail.com>

Eric Smith wrote:
> Nick Coghlan wrote:
> This sort of surprised me when I was writing tests.  Even after having 
> implemented it, I was expecting "-#x" to work, but it needs to be "#-x".

If you can implement it either way, then after the sign character is 
probably the way to go (as Bruce pointed out, that's where the base 
indication will actually be inserted).

Cheers,
Nick.

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

From mal at egenix.com  Mon Jun  9 10:44:38 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 09 Jun 2008 10:44:38 +0200
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <52dc1c820806082220n2f0832e1l7af4bc2fecf31987@mail.gmail.com>
References: <48397ECC.9070805@cheimes.de>
	<483EF139.8000606@egenix.com>	<483F34C3.3050402@gmail.com>
	<483FBCB4.5020007@egenix.com>	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>	<4843E884.1060705@egenix.com>	<52dc1c820806021521g810d9f1wd282508f8452c13@mail.gmail.com>	<ca471dc20806021609v258d7e8bk66b259694dd469b5@mail.gmail.com>	<52dc1c820806021629k5491e8c0u67e8a6f5247d2368@mail.gmail.com>	<48490121.5030701@egenix.com>
	<52dc1c820806082220n2f0832e1l7af4bc2fecf31987@mail.gmail.com>
Message-ID: <484CED76.3070703@egenix.com>

On 2008-06-09 07:20, Gregory P. Smith wrote:
> On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> On 2008-06-03 01:29, Gregory P. Smith wrote:
>>
>>> On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <guido at python.org>
>>> wrote:
>>>
>>>  I will freely admit that I haven't followed this thread in any detail,
>>>> but if it were up to me, I'd have the 2.6 internal code use PyString
>>>>
>>> ...
>>>
>>> Should we read this as a BDFL pronouncement and make it so?
>>>
>>> All that would mean change wise is that trunk r63675 as well as possibly
>>> r63672 and r63677 would need to be rolled back and this whole discussion
>>> over if such a big change should have happened would turn into a moot
>>> point.
>>>
>> I would certainly welcome reverting the change.
>>
>> All that's needed to support PyBytes API in 2.x is a set of #defines
>> that map the new APIs to the PyString names. That's a clean and
>> easily understandable solution.
>>
> 
> Okay, I've reverted r63675 in trunk revision r64048.  That leaves all of the
> python modules and internals using PyString_ api names instead of PyBytes_
> api names as they were before.  PyBytes_ #define's exist for the appropriate
> PyString methods incase anyone wants to use those.

Thanks.

> Programmers interested in the code
>> for a PyString API can then still look up the code in stringobject.c,
>> e.g. to find out how a certain special case is handled or to check
>> the ref counting - just like they did for years.
> 
> 
> The files still exist with the new names.  bytesobject.c instead of
> stringobject.c.  Those renames were done in the other CLs i mentioned which
> have not yet been reverted.  The current state seems a bit odd because they
> depend on the #defines to cause method definitions to be the PyString_ names
> instead of the PyBytes_ names.

Please restore the original state, ie. PyString APIs live in
stringobject.h and stringobject.c. bytesobject.h should then have
the #defines for PyBytes APIs, pointing them to the PyString
names (basically what's currently in stringobject.h).

>> Developer who want to start differentiating between mixed byte/text
>> data and bytes-only can start using PyBytes for byte data.
>>
>>  I would also add macros that map the PyBytes_* APIs to PyString_*, but
>>>> I would not start using these internally except in code newly written
>>>> for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString
>>>> for 8-bit strings containing text, and PyBytes for 8-bit strings
>>>> containing binary data. For 8-bit strings that could contain either
>>>> text or data, I'd use PyString, in the spirit of 2.x.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 09 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/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            27 days to go

:::: 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  Mon Jun  9 20:03:38 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 09 Jun 2008 20:03:38 +0200
Subject: [Python-3000] PyNumberMethods cleanup
Message-ID: <g2jr9q$l22$1@ger.gmane.org>

Hi,

this is a request for a decision based on this bug report:

http://bugs.python.org/issue2997

In the current py3k branch, the nb_divide field (position 4) in the
PyNumberMethods has been removed, but three other fields further on were left
in for compatibility. Since the fourth field of that struct was removed,
existing Py2 C code cannot work unchanged with the current struct, so it would
not hurt at all to just start off Py3 with a cleaned up struct. However,
getting this clean requires someone who decides to either put the old division
field back in or to remove the three remaining legacy fields (which I'm in
favour of, a patch is attached to the issue). And it would be good to take
that decision before beta1.

Thanks,
Stefan


From mhammond at skippinet.com.au  Tue Jun 10 01:30:52 2008
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 10 Jun 2008 09:30:52 +1000
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <935271.36063.qm@web53711.mail.re2.yahoo.com>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>
Message-ID: <058b01c8ca88$dd5e0ab0$981a2010$@com.au>

> I have been unable to install 3.0a5 on a Vista / AMD64 platform.
> I downloaded the amd64 3.0a5 installer and I have tried various ideas
> but always find that Vista complains that 'Installation package could
> not be opened'.
> I would be grateful for instruction from anyone who has done this.

I just tested the 64bit 3.0a5 installer on Vista64 and it worked perfectly.
You might want to verify your download worked OK by comparing the md5sum of
your file with what is on the download page.

Cheers,

Mark


From martin at v.loewis.de  Tue Jun 10 06:16:26 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 10 Jun 2008 06:16:26 +0200
Subject: [Python-3000] PEP 3121 implemented
Message-ID: <484E001A.5000002@v.loewis.de>

I just finished a PEP 3121 implementation, uploaded at

http://codereview.appspot.com/1962

It contains all the API changes proposed in the PEP,
and updates all modules to conform to a minimal level
of the API. I'd like to commit the change later today,
so that it still makes the first beta.

There is more that can be done about using the API, i.e.
changing modules to actually stop keeping global variables,
so that proper garbage collection and separation of
interpreters becomes possible. I'll look into changing
some modules after the beta, but I expect that this will
evolve throughout the entire 3.x series. At a minimum,
xxmodule will be rewritten to work as a sample of how
this is supposed to be used.

In modifying all the modules, I found that an intermediary
mode supporting the 2.x semantics of importing an extension
several times is still necessary. So I changed the spec
to let modules indicate that they continue to assume that
model (i.e. fixupextensions, and making a copy of the
module dict on first import for reuse in later imports).

Regards,
Martin

From martin at v.loewis.de  Tue Jun 10 06:20:53 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 10 Jun 2008 06:20:53 +0200
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <058b01c8ca88$dd5e0ab0$981a2010$@com.au>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>
	<058b01c8ca88$dd5e0ab0$981a2010$@com.au>
Message-ID: <484E0125.3000206@v.loewis.de>

> I just tested the 64bit 3.0a5 installer on Vista64 and it worked perfectly.
> You might want to verify your download worked OK by comparing the md5sum of
> your file with what is on the download page.

One issue (probably not the one of the OP) is still unresolved (AFAIK -
I don't use Vista regularly); an issue that you brought up some time
ago: Installer unreasonably invokes UAC when running the MSI file, even
if this is a "just-for-me" installation. I actually don't know why it
does that - there is nothing in the MSI file specifically requesting
UAC. Instead, Installer makes its own determination of whether UAC is
needed, and I don't know what criteria it uses for that determination.

So any help would be appreciated.

Regards,
Martin

From murman at gmail.com  Tue Jun 10 07:48:58 2008
From: murman at gmail.com (Michael Urman)
Date: Tue, 10 Jun 2008 00:48:58 -0500
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <484E0125.3000206@v.loewis.de>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>
	<058b01c8ca88$dd5e0ab0$981a2010$@com.au>
	<484E0125.3000206@v.loewis.de>
Message-ID: <dcbbbb410806092248v38ebd14dm852c5acedad05c66@mail.gmail.com>

On Mon, Jun 9, 2008 at 11:20 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> One issue (probably not the one of the OP) is still unresolved (AFAIK -
> I don't use Vista regularly); an issue that you brought up some time
> ago: Installer unreasonably invokes UAC when running the MSI file, even
> if this is a "just-for-me" installation. I actually don't know why it
> does that - there is nothing in the MSI file specifically requesting
> UAC. Instead, Installer makes its own determination of whether UAC is
> needed, and I don't know what criteria it uses for that determination.
>
> So any help would be appreciated.

This UAC behavior is controlled by bit 3 of the word count property in
the summary information stream - specifically the legacy value zero
requests elevation. Unfortunately, it's not feasible to transform or
otherwise change this at run-time, so you have to know ahead of time.
If it's set to not require administrator privileges, it can only
successfully install into machine locations if it was launched by a
full administrator context.

http://msdn.microsoft.com/en-us/library/aa372870(VS.85).aspx

-- 
Michael Urman

From mhammond at skippinet.com.au  Tue Jun 10 10:32:47 2008
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 10 Jun 2008 18:32:47 +1000
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <dcbbbb410806092248v38ebd14dm852c5acedad05c66@mail.gmail.com>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>	<058b01c8ca88$dd5e0ab0$981a2010$@com.au>	<484E0125.3000206@v.loewis.de>
	<dcbbbb410806092248v38ebd14dm852c5acedad05c66@mail.gmail.com>
Message-ID: <061d01c8cad4$94828b80$bd87a280$@com.au>

> This UAC behavior is controlled by bit 3 of the word count property in
> the summary information stream - specifically the legacy value zero
> requests elevation. Unfortunately, it's not feasible to transform or
> otherwise change this at run-time, so you have to know ahead of time.
> If it's set to not require administrator privileges, it can only
> successfully install into machine locations if it was launched by a
> full administrator context.

I only tested the python3 installer using "install for all users", and it did correctly prompt for UAC during the install, after "install for all users" is selected.  Previous testing of the 2.x MSI installers shows that if you select "only for me", UAC is not requested, and I expect this installer will do the same.  Note that this is *during* the install process, not at the very start (ie, UAC is not unconditional).  FWIW, these issues don't relate specifically to the x64 version of Vista.

As mentioned, it installed (including UAC prompting) just fine for me just a few hours ago...

Cheers,

Mark


From murman at gmail.com  Tue Jun 10 15:14:44 2008
From: murman at gmail.com (Michael Urman)
Date: Tue, 10 Jun 2008 08:14:44 -0500
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <061d01c8cad4$94828b80$bd87a280$@com.au>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>
	<058b01c8ca88$dd5e0ab0$981a2010$@com.au>
	<484E0125.3000206@v.loewis.de>
	<dcbbbb410806092248v38ebd14dm852c5acedad05c66@mail.gmail.com>
	<061d01c8cad4$94828b80$bd87a280$@com.au>
Message-ID: <dcbbbb410806100614u2fe9100el2324311547ce8a01@mail.gmail.com>

On Tue, Jun 10, 2008 at 3:32 AM, Mark Hammond <mhammond at skippinet.com.au> wrote:
>> This UAC behavior is controlled by bit 3 of the word count property in
>> the summary information stream - specifically the legacy value zero
>> requests elevation. Unfortunately, it's not feasible to transform or
>> otherwise change this at run-time, so you have to know ahead of time.
>> If it's set to not require administrator privileges, it can only
>> successfully install into machine locations if it was launched by a
>> full administrator context.
>
> I only tested the python3 installer using "install for all users", and it did correctly prompt for UAC during the install, after "install for all users" is selected.  Previous testing of the 2.x MSI installers shows that if you select "only for me", UAC is not requested, and I expect this installer will do the same.  Note that this is *during* the install process, not at the very start (ie, UAC is not unconditional).  FWIW, these issues don't relate specifically to the x64 version of Vista.
>
> As mentioned, it installed (including UAC prompting) just fine for me just a few hours ago...

Right. This prompt-at-execute-sequence behavior corresponds to bit 3
being zero. However this means it will always prompt for elevation
unless it is already elevated. Thus it is not really capable of doing
a non-administrator per-user install on Vista.

I downloaded the package to confirm, and indeed the "UAC Compliant"
checkbox on ORCA's summary information stream view is not checked.
(It's a bad name for it, but it does correspond, inverted, to that
bit.)

-- 
Michael Urman

From mhammond at skippinet.com.au  Tue Jun 10 15:27:16 2008
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 10 Jun 2008 23:27:16 +1000
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <dcbbbb410806100614u2fe9100el2324311547ce8a01@mail.gmail.com>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>	
	<058b01c8ca88$dd5e0ab0$981a2010$@com.au>	
	<484E0125.3000206@v.loewis.de>	
	<dcbbbb410806092248v38ebd14dm852c5acedad05c66@mail.gmail.com>	
	<061d01c8cad4$94828b80$bd87a280$@com.au>
	<dcbbbb410806100614u2fe9100el2324311547ce8a01@mail.gmail.com>
Message-ID: <063901c8cafd$b742bcc0$25c83640$@com.au>

> Right. This prompt-at-execute-sequence behavior corresponds to bit 3
> being zero. However this means it will always prompt for elevation
> unless it is already elevated. Thus it is not really capable of doing
> a non-administrator per-user install on Vista.

Yeah - I stand corrected - a "per-user" install does indeed prompt for UAC.

Must-test-before-posting-rather-than-relying-on-memory ly,

Mark


From theller at ctypes.org  Tue Jun 10 17:58:21 2008
From: theller at ctypes.org (Thomas Heller)
Date: Tue, 10 Jun 2008 17:58:21 +0200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <484E001A.5000002@v.loewis.de>
References: <484E001A.5000002@v.loewis.de>
Message-ID: <g2m8ar$rka$1@ger.gmane.org>

Martin v. L?wis schrieb:
> I just finished a PEP 3121 implementation, uploaded at
> 
> http://codereview.appspot.com/1962
> 
> It contains all the API changes proposed in the PEP,
> and updates all modules to conform to a minimal level
> of the API. I'd like to commit the change later today,
> so that it still makes the first beta.
> 
> There is more that can be done about using the API, i.e.
> changing modules to actually stop keeping global variables,
> so that proper garbage collection and separation of
> interpreters becomes possible. I'll look into changing
> some modules after the beta, but I expect that this will
> evolve throughout the entire 3.x series. At a minimum,
> xxmodule will be rewritten to work as a sample of how
> this is supposed to be used.

So, when all modules are changed to properly support multiple interpreters,
it may be possible to implement a module combining the benefits of 
both threading and multiprocessing - moving computation to a separate
interpreter (with its own GIL) without the need to marshal data
across processes?

Thomas


From rhamph at gmail.com  Tue Jun 10 19:13:47 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 10 Jun 2008 11:13:47 -0600
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <g2m8ar$rka$1@ger.gmane.org>
References: <484E001A.5000002@v.loewis.de> <g2m8ar$rka$1@ger.gmane.org>
Message-ID: <aac2c7cb0806101013i107b732aie715bc034b85819b@mail.gmail.com>

On Tue, Jun 10, 2008 at 9:58 AM, Thomas Heller <theller at ctypes.org> wrote:
> Martin v. L?wis schrieb:
>> I just finished a PEP 3121 implementation, uploaded at
>>
>> http://codereview.appspot.com/1962
>>
>> It contains all the API changes proposed in the PEP,
>> and updates all modules to conform to a minimal level
>> of the API. I'd like to commit the change later today,
>> so that it still makes the first beta.
>>
>> There is more that can be done about using the API, i.e.
>> changing modules to actually stop keeping global variables,
>> so that proper garbage collection and separation of
>> interpreters becomes possible. I'll look into changing
>> some modules after the beta, but I expect that this will
>> evolve throughout the entire 3.x series. At a minimum,
>> xxmodule will be rewritten to work as a sample of how
>> this is supposed to be used.
>
> So, when all modules are changed to properly support multiple interpreters,
> it may be possible to implement a module combining the benefits of
> both threading and multiprocessing - moving computation to a separate
> interpreter (with its own GIL) without the need to marshal data
> across processes?

You'd still need to marshal across threads, as well as the thread
switch cost, and much of the extra memory of a process (due to
duplicated python modules.)  All you really save is the address space
switching cost, which I doubt anybody has benchmarked.  Multiple
interpreters aren't worth the extra complexity.

-- 
Adam Olsen, aka Rhamphoryncus

From martin at v.loewis.de  Tue Jun 10 21:32:58 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 10 Jun 2008 21:32:58 +0200
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <dcbbbb410806100614u2fe9100el2324311547ce8a01@mail.gmail.com>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>	
	<058b01c8ca88$dd5e0ab0$981a2010$@com.au>	
	<484E0125.3000206@v.loewis.de>	
	<dcbbbb410806092248v38ebd14dm852c5acedad05c66@mail.gmail.com>	
	<061d01c8cad4$94828b80$bd87a280$@com.au>
	<dcbbbb410806100614u2fe9100el2324311547ce8a01@mail.gmail.com>
Message-ID: <484ED6EA.5030602@v.loewis.de>

> I downloaded the package to confirm, and indeed the "UAC Compliant"
> checkbox on ORCA's summary information stream view is not checked.
> (It's a bad name for it, but it does correspond, inverted, to that
> bit.)

Thanks. I'll try to integrate this with the next beta releases -
that's bit 3 of PID_WORDCOUNT, right?

I hesitated setting it, as MSDN says setting it means

"Elevated privileges are not required to install this package."

My concern would be that it then *never* displays the UAC box,
which is not what I would like.

Regards,
Martin

From martin at v.loewis.de  Tue Jun 10 22:48:23 2008
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 10 Jun 2008 22:48:23 +0200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <g2m8ar$rka$1@ger.gmane.org>
References: <484E001A.5000002@v.loewis.de> <g2m8ar$rka$1@ger.gmane.org>
Message-ID: <484EE897.90309@v.loewis.de>

> So, when all modules are changed to properly support multiple interpreters,
> it may be possible to implement a module combining the benefits of 
> both threading and multiprocessing - moving computation to a separate
> interpreter (with its own GIL) without the need to marshal data
> across processes?

First, it will take a long to to get there: there are all the builtin
type objects (object, int, str, ..., also None, True, False) which
remain shared for a foreseeable future (although the mechanism of the
PEP *could* be used to make them per-interpreter as well).

Second, there is some code that would still be thread-unsafe afterwards,
pymalloc in particular.

Third, once you managed to truly separate interpreters, you *will*
have to marshal objects across interpreters, as there won't be any
shared ones. It's in the same address space, but you still would
have to do marshalling, or else you might introduce sharing again.

So in short: no :-)

Regards,
Martin

From murman at gmail.com  Tue Jun 10 23:34:37 2008
From: murman at gmail.com (Michael Urman)
Date: Tue, 10 Jun 2008 16:34:37 -0500
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <484ED6EA.5030602@v.loewis.de>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>
	<058b01c8ca88$dd5e0ab0$981a2010$@com.au>
	<484E0125.3000206@v.loewis.de>
	<dcbbbb410806092248v38ebd14dm852c5acedad05c66@mail.gmail.com>
	<061d01c8cad4$94828b80$bd87a280$@com.au>
	<dcbbbb410806100614u2fe9100el2324311547ce8a01@mail.gmail.com>
	<484ED6EA.5030602@v.loewis.de>
Message-ID: <dcbbbb410806101434s39b8307fp1705a169fb8ebdff@mail.gmail.com>

On Tue, Jun 10, 2008 at 2:32 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Thanks. I'll try to integrate this with the next beta releases -
> that's bit 3 of PID_WORDCOUNT, right?
>
> I hesitated setting it, as MSDN says setting it means
>
> "Elevated privileges are not required to install this package."
>
> My concern would be that it then *never* displays the UAC box,
> which is not what I would like.

Yes, that's the right bit. However your concern is spot on - if you
set the bit, it will never display the UAC prompt. That's what I
referred to in my previous message with "it can only successfully
install into machine locations if it was launched by a full
administrator context." In order for such a setup to succeed on Vista
when launched by a limited user, etc., it needs to have ALLUSERS
unset, and not install into any machine registry or file locations
(i.e. no HKLM or ProgramFilesFolder).

My recommendation would normally be to not set the bit (keep requiring
administrative privileges). If you need to support the limited user
case, either provide a second package (well, double the number of
packages) with the bit unset, provide a link to ORCA with
instructions, or provide a small helper utility (exe or VBS script)
which can swap the bit using MSI automation. I'm not certain whether
that's a great recommendation across the set of most Windows Python
users.

-- 
Michael Urman

From mhammond at skippinet.com.au  Wed Jun 11 00:55:44 2008
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 11 Jun 2008 08:55:44 +1000
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <dcbbbb410806101434s39b8307fp1705a169fb8ebdff@mail.gmail.com>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>	
	<058b01c8ca88$dd5e0ab0$981a2010$@com.au>	
	<484E0125.3000206@v.loewis.de>	
	<dcbbbb410806092248v38ebd14dm852c5acedad05c66@mail.gmail.com>	
	<061d01c8cad4$94828b80$bd87a280$@com.au>	
	<dcbbbb410806100614u2fe9100el2324311547ce8a01@mail.gmail.com>	
	<484ED6EA.5030602@v.loewis.de>
	<dcbbbb410806101434s39b8307fp1705a169fb8ebdff@mail.gmail.com>
Message-ID: <06a601c8cb4d$21bc2d80$65348880$@com.au>

[Getting slightly off-topic for py3k, but relevant to our universe anyway....]

Hi  Michael,

> Yes, that's the right bit. However your concern is spot on - if you
> set the bit, it will never display the UAC prompt. That's what I
> referred to in my previous message with "it can only successfully
> install into machine locations if it was launched by a full
> administrator context." In order for such a setup to succeed on Vista
> when launched by a limited user, etc., it needs to have ALLUSERS
> unset, and not install into any machine registry or file locations
> (i.e. no HKLM or ProgramFilesFolder).
> 
> My recommendation would normally be to not set the bit (keep requiring
> administrative privileges). If you need to support the limited user
> case, either provide a second package (well, double the number of
> packages) with the bit unset, provide a link to ORCA with
> instructions, or provide a small helper utility (exe or VBS script)
> which can swap the bit using MSI automation. I'm not certain whether
> that's a great recommendation across the set of most Windows Python
> users.

  Just to be clear, you are saying it is *impossible* to have a single .MSI file that, based on a user preference, either a) prompt for UAC and writes to HKLM or b) not prompt but writes to HKCU instead?  I'd find that somewhat ironic, as bdist_wininst based installers are now capable of doing that ;)

Cheers,

Mark


From guido at python.org  Wed Jun 11 02:07:28 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Jun 2008 17:07:28 -0700
Subject: [Python-3000] Have been sick, am behind on mail,
	let me know if there's anything urgent for me
Message-ID: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>

All,

I've been sick since Saturday and still don't feel up to much. I've
collected a severe email backlog going back to June 6th. If there's
anything someone really needs me to look at ASAP (e.g. a BDFL decision
affecting the impending beta release) please send me an email (a
followup to this thread is fine) and I'll try to look at it soon.

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

From greg.ewing at canterbury.ac.nz  Wed Jun 11 03:08:52 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 11 Jun 2008 13:08:52 +1200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <g2m8ar$rka$1@ger.gmane.org>
References: <484E001A.5000002@v.loewis.de> <g2m8ar$rka$1@ger.gmane.org>
Message-ID: <484F25A4.5070405@canterbury.ac.nz>

Thomas Heller wrote:
> So, when all modules are changed to properly support multiple interpreters,
> it may be possible to implement a module combining the benefits of 
> both threading and multiprocessing - moving computation to a separate
> interpreter (with its own GIL) without the need to marshal data
> across processes?

If each interpreter has its own GIL, then it can't share
*any* Python objects with other interpreters, so marshalling
would still be needed for Python data.

-- 
Greg

From long.muyi at gmail.com  Wed Jun 11 04:23:41 2008
From: long.muyi at gmail.com (Long Ge)
Date: Wed, 11 Jun 2008 10:23:41 +0800
Subject: [Python-3000] python3000 udp problem
Message-ID: <2a89045b0806101923h15d3ff78hcfbd2157de2d55aa@mail.gmail.com>

import socket
if __name__ == '__main__':
    print("main")
    udp = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
    udp.sendto("1",0,('127.0.0.1',3722))
    udp.close()


*output:*
main
Traceback (most recent call last):
  File "C:\Python30\Projects\udp.py", line 6, in <module>
    udp.sendto("1",0,('127.0.0.1',3722))
TypeError: sendto() argument 1 must be bytes or read-only buffer, not str

what is the problem about argument 1?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080611/d2023fa5/attachment.htm>

From musiccomposition at gmail.com  Wed Jun 11 04:25:11 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 10 Jun 2008 21:25:11 -0500
Subject: [Python-3000] python3000 udp problem
In-Reply-To: <2a89045b0806101923h15d3ff78hcfbd2157de2d55aa@mail.gmail.com>
References: <2a89045b0806101923h15d3ff78hcfbd2157de2d55aa@mail.gmail.com>
Message-ID: <1afaf6160806101925r60cf119x35937f3c798f2e58@mail.gmail.com>

On Tue, Jun 10, 2008 at 9:23 PM, Long Ge <long.muyi at gmail.com> wrote:
> import socket
>
> if __name__ == '__main__':
>     print("main")
>     udp = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
>     udp.sendto("1",0,('127.0.0.1',3722))
>     udp.close()
>
> output:
> main
> Traceback (most recent call last):
>   File "C:\Python30\Projects\udp.py", line 6, in <module>
>     udp.sendto("1",0,('127.0.0.1',3722))
> TypeError: sendto() argument 1 must be bytes or read-only buffer, not str
>
> what is the problem about argument 1?

You have to use bytes; try b"1".



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

From greg at krypto.org  Wed Jun 11 05:42:57 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Tue, 10 Jun 2008 20:42:57 -0700
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <484CED76.3070703@egenix.com>
References: <48397ECC.9070805@cheimes.de> <483FBCB4.5020007@egenix.com>
	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>
	<4843E884.1060705@egenix.com>
	<52dc1c820806021521g810d9f1wd282508f8452c13@mail.gmail.com>
	<ca471dc20806021609v258d7e8bk66b259694dd469b5@mail.gmail.com>
	<52dc1c820806021629k5491e8c0u67e8a6f5247d2368@mail.gmail.com>
	<48490121.5030701@egenix.com>
	<52dc1c820806082220n2f0832e1l7af4bc2fecf31987@mail.gmail.com>
	<484CED76.3070703@egenix.com>
Message-ID: <52dc1c820806102042x19c935cev61739772fddb2173@mail.gmail.com>

On Mon, Jun 9, 2008 at 1:44 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> On 2008-06-09 07:20, Gregory P. Smith wrote:
>
>> On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>
>>  On 2008-06-03 01:29, Gregory P. Smith wrote:
>>>
>>>  On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <guido at python.org>
>>>> wrote:
>>>>
>>>>  I will freely admit that I haven't followed this thread in any detail,
>>>>
>>>>> but if it were up to me, I'd have the 2.6 internal code use PyString
>>>>>
>>>>>  ...
>>>>
>>>> Should we read this as a BDFL pronouncement and make it so?
>>>>
>>>> All that would mean change wise is that trunk r63675 as well as possibly
>>>> r63672 and r63677 would need to be rolled back and this whole discussion
>>>> over if such a big change should have happened would turn into a moot
>>>> point.
>>>>
>>>>  I would certainly welcome reverting the change.
>>>
>>> All that's needed to support PyBytes API in 2.x is a set of #defines
>>> that map the new APIs to the PyString names. That's a clean and
>>> easily understandable solution.
>>>
>>>
>> Okay, I've reverted r63675 in trunk revision r64048.  That leaves all of
>> the
>> python modules and internals using PyString_ api names instead of PyBytes_
>> api names as they were before.  PyBytes_ #define's exist for the
>> appropriate
>> PyString methods incase anyone wants to use those.
>>
>
> Thanks.
>
>  Programmers interested in the code
>>
>>> for a PyString API can then still look up the code in stringobject.c,
>>> e.g. to find out how a certain special case is handled or to check
>>> the ref counting - just like they did for years.
>>>
>>
>>
>> The files still exist with the new names.  bytesobject.c instead of
>> stringobject.c.  Those renames were done in the other CLs i mentioned
>> which
>> have not yet been reverted.  The current state seems a bit odd because
>> they
>> depend on the #defines to cause method definitions to be the PyString_
>> names
>> instead of the PyBytes_ names.
>>
>
> Please restore the original state, ie. PyString APIs live in
> stringobject.h and stringobject.c. bytesobject.h should then have
> the #defines for PyBytes APIs, pointing them to the PyString
> names (basically what's currently in stringobject.h).
>

all done as of 64105
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080610/4cba5859/attachment.htm>

From murman at gmail.com  Wed Jun 11 06:42:00 2008
From: murman at gmail.com (Michael Urman)
Date: Tue, 10 Jun 2008 23:42:00 -0500
Subject: [Python-3000] Install on Vista / AMD64 AthlonX2 platform
In-Reply-To: <06a601c8cb4d$21bc2d80$65348880$@com.au>
References: <935271.36063.qm@web53711.mail.re2.yahoo.com>
	<058b01c8ca88$dd5e0ab0$981a2010$@com.au>
	<484E0125.3000206@v.loewis.de>
	<dcbbbb410806092248v38ebd14dm852c5acedad05c66@mail.gmail.com>
	<061d01c8cad4$94828b80$bd87a280$@com.au>
	<dcbbbb410806100614u2fe9100el2324311547ce8a01@mail.gmail.com>
	<484ED6EA.5030602@v.loewis.de>
	<dcbbbb410806101434s39b8307fp1705a169fb8ebdff@mail.gmail.com>
	<06a601c8cb4d$21bc2d80$65348880$@com.au>
Message-ID: <dcbbbb410806102142p203ee1b2o29485895d95ba215@mail.gmail.com>

On Tue, Jun 10, 2008 at 5:55 PM, Mark Hammond <mhammond at skippinet.com.au> wrote:
> [Getting slightly off-topic for py3k, but relevant to our universe anyway....]
>
> Hi  Michael,
>  Just to be clear, you are saying it is *impossible* to have a single .MSI file that, based on a user preference, either a) prompt for UAC and writes to HKLM or b) not prompt but writes to HKCU instead?  I'd find that somewhat ironic, as bdist_wininst based installers are now capable of doing that ;)

Yes, that is my experience with the matter. I haven't tested it
exhaustively (or recently), but set to not require the UAC prompt, it
never will show it; set to prompt, it never won't. I would have
expected a design based more on ALLUSERS, but Microsoft recommends
choosing ahead of time which way to set it (doing away with the
"install for all users or just for me" options), and this behavior
pretty much seals it.

-- 
Michael Urman

From mal at egenix.com  Wed Jun 11 10:52:06 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 11 Jun 2008 10:52:06 +0200
Subject: [Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
In-Reply-To: <52dc1c820806102042x19c935cev61739772fddb2173@mail.gmail.com>
References: <48397ECC.9070805@cheimes.de>
	<483FBCB4.5020007@egenix.com>	<52dc1c820806011630y7957ef90n2b7b3441ba9451b5@mail.gmail.com>	<4843E884.1060705@egenix.com>	<52dc1c820806021521g810d9f1wd282508f8452c13@mail.gmail.com>	<ca471dc20806021609v258d7e8bk66b259694dd469b5@mail.gmail.com>	<52dc1c820806021629k5491e8c0u67e8a6f5247d2368@mail.gmail.com>	<48490121.5030701@egenix.com>	<52dc1c820806082220n2f0832e1l7af4bc2fecf31987@mail.gmail.com>	<484CED76.3070703@egenix.com>
	<52dc1c820806102042x19c935cev61739772fddb2173@mail.gmail.com>
Message-ID: <484F9236.4020101@egenix.com>

On 2008-06-11 05:42, Gregory P. Smith wrote:
> On Mon, Jun 9, 2008 at 1:44 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> On 2008-06-09 07:20, Gregory P. Smith wrote:
>>
>>> On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>
>>>  On 2008-06-03 01:29, Gregory P. Smith wrote:
>>>>  On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <guido at python.org>
>>>>> wrote:
>>>>>
>>>>>  I will freely admit that I haven't followed this thread in any detail,
>>>>>
>>>>>> but if it were up to me, I'd have the 2.6 internal code use PyString
>>>>>>
>>>>>>  ...
>>>>> Should we read this as a BDFL pronouncement and make it so?
>>>>>
>>>>> All that would mean change wise is that trunk r63675 as well as possibly
>>>>> r63672 and r63677 would need to be rolled back and this whole discussion
>>>>> over if such a big change should have happened would turn into a moot
>>>>> point.
>>>>>
>>>>>  I would certainly welcome reverting the change.
>>>> All that's needed to support PyBytes API in 2.x is a set of #defines
>>>> that map the new APIs to the PyString names. That's a clean and
>>>> easily understandable solution.
>>>>
>>>>
>>> Okay, I've reverted r63675 in trunk revision r64048.  That leaves all of
>>> the
>>> python modules and internals using PyString_ api names instead of PyBytes_
>>> api names as they were before.  PyBytes_ #define's exist for the
>>> appropriate
>>> PyString methods incase anyone wants to use those.
>>>
>> Thanks.
>>
>>  Programmers interested in the code
>>>> for a PyString API can then still look up the code in stringobject.c,
>>>> e.g. to find out how a certain special case is handled or to check
>>>> the ref counting - just like they did for years.
>>>>
>>>
>>> The files still exist with the new names.  bytesobject.c instead of
>>> stringobject.c.  Those renames were done in the other CLs i mentioned
>>> which
>>> have not yet been reverted.  The current state seems a bit odd because
>>> they
>>> depend on the #defines to cause method definitions to be the PyString_
>>> names
>>> instead of the PyBytes_ names.
>>>
>> Please restore the original state, ie. PyString APIs live in
>> stringobject.h and stringobject.c. bytesobject.h should then have
>> the #defines for PyBytes APIs, pointing them to the PyString
>> names (basically what's currently in stringobject.h).
>>
> 
> all done as of 64105

Thank you !

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 11 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/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            25 days to go

:::: 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 Jun 11 11:16:07 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 11 Jun 2008 19:16:07 +1000
Subject: [Python-3000] python3000 udp problem
In-Reply-To: <2a89045b0806101923h15d3ff78hcfbd2157de2d55aa@mail.gmail.com>
References: <2a89045b0806101923h15d3ff78hcfbd2157de2d55aa@mail.gmail.com>
Message-ID: <484F97D7.6010609@gmail.com>

Long Ge wrote:
> import socket
> 
> if __name__ == '__main__':
>     print("main")
>     udp = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
>     udp.sendto("1",0,('127.0.0.1 <http://127.0.0.1>',3722))
>     udp.close()
> 
>  
> *output:*
> main
> Traceback (most recent call last):
>   File "C:\Python30\Projects\udp.py", line 6, in <module>
>     udp.sendto("1",0,('127.0.0.1 <http://127.0.0.1>',3722))
> TypeError: sendto() argument 1 must be bytes or read-only buffer, not str
>  
> what is the problem about argument 1?

Python 3.0 is much stricter than 2.x about the distinction between 
character based-data (i.e. Unicode strings) and 8-bit byte sequences 
(bytes and bytearray).

As Benjamin pointed out, socket.sendto expects a bytestream rather than 
a character string, so you need to either use bytes directly (such as 
b"1") or encode the character string to a byte sequence (such as 
"1".encode("utf-8")).

Cheers,
Nick.

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

From ncoghlan at gmail.com  Wed Jun 11 11:40:57 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 11 Jun 2008 19:40:57 +1000
Subject: [Python-3000] [Python-Dev] Have been sick, am behind on mail,
 let me know if there's anything urgent for me
In-Reply-To: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
Message-ID: <484F9DA9.3030606@gmail.com>

Guido van Rossum wrote:
> All,
> 
> I've been sick since Saturday and still don't feel up to much. I've
> collected a severe email backlog going back to June 6th. If there's
> anything someone really needs me to look at ASAP (e.g. a BDFL decision
> affecting the impending beta release) please send me an email (a
> followup to this thread is fine) and I'll try to look at it soon.
> 

As it involves adding a new standard library module, my proposal [1] to 
add a typetools.ProxyMixin class to 2.6/3.0 to make it practical to 
write type-agnostic interface adapter classes as new-style classes needs 
a pronouncement from yourself or Barry as to whether or not it can go in.

I think it's an important tool to add since 3.0 no longer has classic 
classes around to handle the task, and I'm suggesting a new module for 
it because none of the existing standard library modules seemed like a 
good fit for the functionality.

Cheers,
Nick.

[1] http://bugs.python.org/issue643841

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

From barry at python.org  Wed Jun 11 13:35:25 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Jun 2008 07:35:25 -0400
Subject: [Python-3000] Betas today - I hope
Message-ID: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>

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

So I had planned to do a bunch of work last night looking at the  
release blocker issues, but nature intervened.  A bunch of severe  
thunderstorms knock out my 'net access until this morning.

I'll try to find some time during the day to look at the RB issues.   
Hopefully we can get Guido to look at them too and Pronounce on some  
of them.  Guido please start with:

http://bugs.python.org/issue643841

My plan is to begin building the betas tonight, at around 9 or 10pm  
EDT (0100 to 0200 UTC Thursday).  If a showstopper comes up before  
then, I'll email the list.  If you think we really aren't ready for  
beta, then I would still like to get a release out today.  In that  
case, we'll call it alpha and delay the betas.

- -Barry

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

iQCVAwUBSE+4fXEjvBPtnXfVAQJ4AgP+MD0o3Mw5borZRnQffomXfsAFOMLD0PDr
fS5PwhxkVL/qJU7ZM7v9l8j5walI7Boj1aH7w8UQdV0KpEc0ruqWhsPFCOny3L0W
WgHMtyD0Wc+GAf6ckpOxxWI4Blg52MVzkhplKHaRJ5c4lNriBKt1o9xeupElWtHq
awcHgApvTms=
=iNK1
-----END PGP SIGNATURE-----

From barry at python.org  Wed Jun 11 14:06:55 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Jun 2008 08:06:55 -0400
Subject: [Python-3000] [Python-Dev] Have been sick, am behind on mail,
	let me know if there's anything urgent for me
In-Reply-To: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
Message-ID: <7F90796A-E7D2-4C32-A03A-794EFCE94C14@python.org>

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

On Jun 10, 2008, at 8:07 PM, Guido van Rossum wrote:

> I've been sick since Saturday and still don't feel up to much. I've
> collected a severe email backlog going back to June 6th. If there's
> anything someone really needs me to look at ASAP (e.g. a BDFL decision
> affecting the impending beta release) please send me an email (a
> followup to this thread is fine) and I'll try to look at it soon.

Hi Guido, sorry you've been sick!  If you're up to it, please  
pronounce on this issue:

http://bugs.python.org/issue643841

It's a long bug thread, but needs a decision.

Thanks,
- -Barry

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

iQCVAwUBSE+/4nEjvBPtnXfVAQJDzQP9FtWLT3+MIBoeRLRqFtXEZxphi+IDU7wp
Jtw82cFgKz/wPPxyyGEtnLSmt6duj3MTTftuVsTKS1plqsd6puC2S1VbEOvS9otp
xQ0E1mn/xb4B/BvH9n3xkS9FTiYlePkmU61IdAdmSAQ3gtFlwDPB8o5k30RuvhLl
S+Ai+mBqPq4=
=TUyr
-----END PGP SIGNATURE-----

From ncoghlan at gmail.com  Wed Jun 11 14:59:09 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 11 Jun 2008 22:59:09 +1000
Subject: [Python-3000] [Python-Dev] Have been sick, am behind on mail,
 let me know if there's anything urgent for me
In-Reply-To: <7F90796A-E7D2-4C32-A03A-794EFCE94C14@python.org>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
	<7F90796A-E7D2-4C32-A03A-794EFCE94C14@python.org>
Message-ID: <484FCC1D.1010605@gmail.com>

Barry Warsaw wrote:
> On Jun 10, 2008, at 8:07 PM, Guido van Rossum wrote:
> 
>> I've been sick since Saturday and still don't feel up to much. I've
>> collected a severe email backlog going back to June 6th. If there's
>> anything someone really needs me to look at ASAP (e.g. a BDFL decision
>> affecting the impending beta release) please send me an email (a
>> followup to this thread is fine) and I'll try to look at it soon.
> 
> Hi Guido, sorry you've been sick!  If you're up to it, please pronounce 
> on this issue:
> 
> http://bugs.python.org/issue643841
> 
> It's a long bug thread, but needs a decision.

I just added a couple of messages at the end that recap the more recent 
discussions (the early responses to the issue are *really* old...)

Cheers,
Nick.

_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com

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

From facundobatista at gmail.com  Wed Jun 11 16:25:06 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Wed, 11 Jun 2008 11:25:06 -0300
Subject: [Python-3000] Trunk / branch switch
Message-ID: <e04bdf310806110725kf13f45x35552cbcb40211fe@mail.gmail.com>

Hi all :)

Is already planned the moment when "trunk" will mean Py 3, and the Py
2 development will be carried on in a branch?

Thanks!

-- 
. Facundo

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

From guido at python.org  Wed Jun 11 16:32:02 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Jun 2008 07:32:02 -0700
Subject: [Python-3000] Trunk / branch switch
In-Reply-To: <e04bdf310806110725kf13f45x35552cbcb40211fe@mail.gmail.com>
References: <e04bdf310806110725kf13f45x35552cbcb40211fe@mail.gmail.com>
Message-ID: <ca471dc20806110732y2e147e7dsfc96ee6f2f54df2a@mail.gmail.com>

I don't think such a moment is planned. It would have to be far in the
future, when 2.x is only used by old farts.

On Wed, Jun 11, 2008 at 7:25 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> Is already planned the moment when "trunk" will mean Py 3, and the Py
> 2 development will be carried on in a branch?

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

From mal at egenix.com  Wed Jun 11 16:32:09 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 11 Jun 2008 16:32:09 +0200
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
Message-ID: <484FE1E9.2080904@egenix.com>

On 2008-06-11 13:35, Barry Warsaw wrote:
> So I had planned to do a bunch of work last night looking at the release 
> blocker issues, but nature intervened.  A bunch of severe thunderstorms 
> knock out my 'net access until this morning.
> 
> I'll try to find some time during the day to look at the RB issues.  
> Hopefully we can get Guido to look at them too and Pronounce on some of 
> them.  Guido please start with:
> 
> http://bugs.python.org/issue643841
> 
> My plan is to begin building the betas tonight, at around 9 or 10pm EDT 
> (0100 to 0200 UTC Thursday).  If a showstopper comes up before then, 
> I'll email the list.  If you think we really aren't ready for beta, then 
> I would still like to get a release out today.  In that case, we'll call 
> it alpha and delay the betas.

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)

I did not have time in the last few days to work on these and won't
in the next few days either. Next week looks much better.

If it's ok to make the above changes after the release (whatever you
call it ;-), that would be great.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 11 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/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            25 days to go

:::: 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 walter at livinglogic.de  Wed Jun 11 17:15:56 2008
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Wed, 11 Jun 2008 17:15:56 +0200
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <484FE1E9.2080904@egenix.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<484FE1E9.2080904@egenix.com>
Message-ID: <484FEC2C.6070409@livinglogic.de>

M.-A. Lemburg wrote:
> On 2008-06-11 13:35, Barry Warsaw wrote:
>> So I had planned to do a bunch of work last night looking at the 
>> release blocker issues, but nature intervened.  A bunch of severe 
>> thunderstorms knock out my 'net access until this morning.
>>
>> I'll try to find some time during the day to look at the RB issues.  
>> Hopefully we can get Guido to look at them too and Pronounce on some 
>> of them.  Guido please start with:
>>
>> http://bugs.python.org/issue643841
>>
>> My plan is to begin building the betas tonight, at around 9 or 10pm 
>> EDT (0100 to 0200 UTC Thursday).  If a showstopper comes up before 
>> then, I'll email the list.  If you think we really aren't ready for 
>> beta, then I would still like to get a release out today.  In that 
>> case, we'll call it alpha and delay the betas.
> 
> 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)

What would these methods do? Use the codec machinery without any type 
checks?

I think for transformations we don't need the full codec machinery:

We probably don't need extensible error handling.

There are transformation that are not invertible, so it doesn't make 
sense to have both operations in one object. If the operation *is* 
invertible, two tranformers can be used.

Do we really need a registry that maps function named to functions?

A simple API might look like this:

class TransformInfo:
    # stateless transformer
    def transform(self, input):

    # return stateful incremental transformer
    def incrementaltransformer(self):

    # wrap stream in a transforming stream
    def streamtransformer(self, stream):

incrementaltransformer() would return an object that has one method:

    def transform(self, input, final=False);

> [...]

Servus,
    Walter

From mal at egenix.com  Wed Jun 11 18:57:28 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 11 Jun 2008 18:57:28 +0200
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <484FEC2C.6070409@livinglogic.de>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>
	<484FEC2C.6070409@livinglogic.de>
Message-ID: <485003F8.40803@egenix.com>

On 2008-06-11 17:15, Walter D?rwald wrote:
> M.-A. Lemburg wrote:
>> On 2008-06-11 13:35, Barry Warsaw wrote:
>>> So I had planned to do a bunch of work last night looking at the 
>>> release blocker issues, but nature intervened.  A bunch of severe 
>>> thunderstorms knock out my 'net access until this morning.
>>>
>>> I'll try to find some time during the day to look at the RB issues.  
>>> Hopefully we can get Guido to look at them too and Pronounce on some 
>>> of them.  Guido please start with:
>>>
>>> http://bugs.python.org/issue643841
>>>
>>> My plan is to begin building the betas tonight, at around 9 or 10pm 
>>> EDT (0100 to 0200 UTC Thursday).  If a showstopper comes up before 
>>> then, I'll email the list.  If you think we really aren't ready for 
>>> beta, then I would still like to get a release out today.  In that 
>>> case, we'll call it alpha and delay the betas.
>>
>> 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)
> 
> What would these methods do? Use the codec machinery without any type 
> checks?

As discussed in another thread some weeks ago:

.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type.

E.g. text.transform('xml-escape') or data.transform('base64').

> I think for transformations we don't need the full codec machinery:
 > ...

No need to invent another wheel :-) The codecs already exist for
Py2.x and can be used by the .encode()/.decode() methods in Py2.x
(where no type checks occur).

In Py3.x, .encode()/.decode() only allow conversions of the type
unicode <-> bytes. .transform()/.untransform() add conversions
of the type unicode <-> unicode or bytes <-> bytes.

All other conversions in Py3.x have to go through codecs.encode() and
codecs.decode() which are the generic codec access functions from
the codec registry.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 11 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/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            25 days to go

:::: 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  Wed Jun 11 19:02:55 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Jun 2008 10:02:55 -0700
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
Message-ID: <ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>

On Wed, Jun 11, 2008 at 4:35 AM, Barry Warsaw <barry at python.org> wrote:
> So I had planned to do a bunch of work last night looking at the release
> blocker issues, but nature intervened.  A bunch of severe thunderstorms
> knock out my 'net access until this morning.
>
> I'll try to find some time during the day to look at the RB issues.
>  Hopefully we can get Guido to look at them too and Pronounce on some of
> them.  Guido please start with:
>
> http://bugs.python.org/issue643841

I've added a comment. Let me know if anything I said is unclear.

> My plan is to begin building the betas tonight, at around 9 or 10pm EDT
> (0100 to 0200 UTC Thursday).  If a showstopper comes up before then, I'll
> email the list.  If you think we really aren't ready for beta, then I would
> still like to get a release out today.  In that case, we'll call it alpha
> and delay the betas.

I'd rather call it beta even if certain things are still known to
change in the next release. Beta means we'll have a much easier time
pushing back on random other feature change proposals.

> - -Barry

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

From guido at python.org  Wed Jun 11 19:15:04 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Jun 2008 10:15:04 -0700
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <484FE1E9.2080904@egenix.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<484FE1E9.2080904@egenix.com>
Message-ID: <ca471dc20806111015g2cb4c023g6d5cdee1ec2ec3b8@mail.gmail.com>

On Wed, Jun 11, 2008 at 7:32 AM, M.-A. Lemburg <mal at egenix.com> 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)

I'm +0 on this. It is very minor syntactic sugar that typically saves
you only one import. I expect the argument will nearly always be a
literal, e.g. data.transform('gzip') rather than a variable like
data.transform(compression_method). But it *is* convenient and can
make code more readable, e.g.

  if compressed:
     data = data.untransform('gzip')

Nobody will have to guess what that does. (IMO the confusion about
which direction the transformation goes is theoretical. except perhaps
in the case of rot13. :-)

>  * 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)

I'm okay with this too.

> I did not have time in the last few days to work on these and won't
> in the next few days either. Next week looks much better.
>
> If it's ok to make the above changes after the release (whatever you
> call it ;-), that would be great.

That's up to the release manager, but IMO we could have a small list
of *specific* things that are not yet implemented in beta 1 but that
we know will be in beta 2. This is IMO better than just calling it
another alpha, because that keeps the floodgates for more feature
change requests open for another month.

--Guido

> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Jun 11 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/
>
> ________________________________________________________________________
> 2008-07-07: EuroPython 2008, Vilnius, Lithuania            25 days to go
>
> :::: 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
> _______________________________________________
> 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/guido%40python.org
>



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

From guido at python.org  Wed Jun 11 19:27:20 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Jun 2008 10:27:20 -0700
Subject: [Python-3000] [Python-Dev] Have been sick, am behind on mail,
	let me know if there's anything urgent for me
In-Reply-To: <g2nn1i$413$1@ger.gmane.org>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
	<g2nn1i$413$1@ger.gmane.org>
Message-ID: <ca471dc20806111027m23798254x9690d3fa8146a9e7@mail.gmail.com>

On Tue, Jun 10, 2008 at 10:15 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> This seems to require a BDFL decision:
>
> http://bugs.python.org/issue2997
>
> Executive Summary: PyNumberMethods has been changed on py3k back in 2006 with
> the nb_divide removal, so it's now incompatible with Py2. But there are three
> more unused struct members *behind* that field that can be removed for beta1,
> but have not been removed yet. Should they be removed for cleanliness (patch
> in the issue) or should nb_divide and nb_inplace_divide instead be restored
> (rev 43285) to restore backwards compatibility?

I've added a recommendation to apply this patch to the bug.

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

From guido at python.org  Wed Jun 11 19:29:42 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Jun 2008 10:29:42 -0700
Subject: [Python-3000] [Python-Dev] Have been sick, am behind on mail,
	let me know if there's anything urgent for me
In-Reply-To: <484FCC1D.1010605@gmail.com>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
	<7F90796A-E7D2-4C32-A03A-794EFCE94C14@python.org>
	<484FCC1D.1010605@gmail.com>
Message-ID: <ca471dc20806111029r202959ecy6b7b69208b1d3528@mail.gmail.com>

On Wed, Jun 11, 2008 at 5:59 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> http://bugs.python.org/issue643841
>>
>> It's a long bug thread, but needs a decision.
>
> I just added a couple of messages at the end that recap the more recent
> discussions (the early responses to the issue are *really* old...)

I've added my opinion to the bug: I am in favor of documenting the
current behavior (making it mandatory for all implementations). I
would like to hold back on adding a proxy mixin class until we've
found some actual use for it.

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

From barry at python.org  Wed Jun 11 19:37:01 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Jun 2008 13:37:01 -0400
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>
Message-ID: <F3F1C7BD-8D54-4320-BCD9-3608F4DDFB85@python.org>

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

On Jun 11, 2008, at 1:02 PM, Guido van Rossum wrote:

> On Wed, Jun 11, 2008 at 4:35 AM, Barry Warsaw <barry at python.org>  
> wrote:
>> So I had planned to do a bunch of work last night looking at the  
>> release
>> blocker issues, but nature intervened.  A bunch of severe  
>> thunderstorms
>> knock out my 'net access until this morning.
>>
>> I'll try to find some time during the day to look at the RB issues.
>> Hopefully we can get Guido to look at them too and Pronounce on  
>> some of
>> them.  Guido please start with:
>>
>> http://bugs.python.org/issue643841
>
> I've added a comment. Let me know if anything I said is unclear.

Nope, it was perfect, thanks.

>> My plan is to begin building the betas tonight, at around 9 or 10pm  
>> EDT
>> (0100 to 0200 UTC Thursday).  If a showstopper comes up before  
>> then, I'll
>> email the list.  If you think we really aren't ready for beta, then  
>> I would
>> still like to get a release out today.  In that case, we'll call it  
>> alpha
>> and delay the betas.
>
> I'd rather call it beta even if certain things are still known to
> change in the next release. Beta means we'll have a much easier time
> pushing back on random other feature change proposals.

Sounds good.  I'm going to go through the other release critical  
issues and will follow up on this thread if there are any other  
questions.

- -Barry

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

iQCVAwUBSFANPXEjvBPtnXfVAQIMfgQAovATNsivTKAMIUPsue+Tq5OwVlE8zxIf
KqmNfXDdyAWhWjnWrao0V73A2v6TKvgL2H6SON6UT1oHvRus1ahLWXQWpTUIdn4L
jiYfeek14XoVim8mRz7L8mhxThADPMj3YkhWK448QyZbMkColMqUIVCgvfaQYSxM
2+3zOWQJ/AQ=
=eqAr
-----END PGP SIGNATURE-----

From barry at python.org  Wed Jun 11 19:54:49 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Jun 2008 13:54:49 -0400
Subject: [Python-3000] [Python-Dev] Have been sick, am behind on mail,
	let me know if there's anything urgent for me
In-Reply-To: <g2nn1i$413$1@ger.gmane.org>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
	<g2nn1i$413$1@ger.gmane.org>
Message-ID: <F905426C-0722-4237-832A-3E09FD247B21@python.org>

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

On Jun 11, 2008, at 1:15 AM, Stefan Behnel wrote:

> Guido van Rossum wrote:
>> anything someone really needs me to look at ASAP (e.g. a BDFL  
>> decision
>> affecting the impending beta release) please send me an email
>
> This seems to require a BDFL decision:
>
> http://bugs.python.org/issue2997

Guido's approved the patch.  Please go ahead and apply it.  If no one  
gets to it before tonight, I'll put it in beta 1 if it applies cleanly.

- -Barry

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

iQCVAwUBSFARanEjvBPtnXfVAQJM/AP+I7gb3VM90c6iCAkvx8EijC2LmrIPtmN2
kSMtMLlyObEZLdGGiPOQdafwx+SeuKxwY2d/RF1VvM2K6fWyWjbw0wt2ZMLxs1UB
AVz4PmHSeS23jao2io75wBx4iUTmccte0dDBx6JJYojq6PZeMe4W5lJHuzuyrHWQ
i4EnPJHiqag=
=HaZV
-----END PGP SIGNATURE-----

From musiccomposition at gmail.com  Wed Jun 11 19:58:25 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 11 Jun 2008 12:58:25 -0500
Subject: [Python-3000] [Python-Dev] Have been sick, am behind on mail,
	let me know if there's anything urgent for me
In-Reply-To: <F905426C-0722-4237-832A-3E09FD247B21@python.org>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
	<g2nn1i$413$1@ger.gmane.org>
	<F905426C-0722-4237-832A-3E09FD247B21@python.org>
Message-ID: <1afaf6160806111058w2be5e0bbh60321954f752c420@mail.gmail.com>

On Wed, Jun 11, 2008 at 12:54 PM, Barry Warsaw <barry at python.org> wrote:
>>
>> http://bugs.python.org/issue2997
>
> Guido's approved the patch.  Please go ahead and apply it.  If no one gets
> to it before tonight, I'll put it in beta 1 if it applies cleanly.

I'm going to handle it.


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

From barry at python.org  Wed Jun 11 20:00:42 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Jun 2008 14:00:42 -0400
Subject: [Python-3000] [Python-Dev] Have been sick, am behind on mail,
	let me know if there's anything urgent for me
In-Reply-To: <1afaf6160806111058w2be5e0bbh60321954f752c420@mail.gmail.com>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
	<g2nn1i$413$1@ger.gmane.org>
	<F905426C-0722-4237-832A-3E09FD247B21@python.org>
	<1afaf6160806111058w2be5e0bbh60321954f752c420@mail.gmail.com>
Message-ID: <B75E20FF-D279-4D56-9FC7-8E234BD4C7F0@python.org>

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

On Jun 11, 2008, at 1:58 PM, Benjamin Peterson wrote:

> On Wed, Jun 11, 2008 at 12:54 PM, Barry Warsaw <barry at python.org>  
> wrote:
>>>
>>> http://bugs.python.org/issue2997
>>
>> Guido's approved the patch.  Please go ahead and apply it.  If no  
>> one gets
>> to it before tonight, I'll put it in beta 1 if it applies cleanly.
>
> I'm going to handle it.

Thanks!  You're awesome. :)

- -Barry

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

iQCVAwUBSFASynEjvBPtnXfVAQK9YgQAuVbLsvZd+O2RGac/Tqr0DHcCPHm7lOL9
QyqUMzideytmuGhw4IjaIIKhP2G1Dg7iskuCEqkosm5niRKz4vw6/R53kMC5xPRQ
Adm+KfCxohXzJoN7+ON89wnM5AqfT1AxeYlhGkKGvxRfjTydIXMTTTSJLC4ztyT6
BWIG49zqEJY=
=kLlY
-----END PGP SIGNATURE-----

From alexandre at peadrop.com  Wed Jun 11 22:54:48 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Wed, 11 Jun 2008 16:54:48 -0400
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
Message-ID: <acd65fa20806111354h3788345xcea09b5d30cc8b0e@mail.gmail.com>

On Wed, Jun 11, 2008 at 7:35 AM, Barry Warsaw <barry at python.org> wrote:
> My plan is to begin building the betas tonight, at around 9 or 10pm EDT
> (0100 to 0200 UTC Thursday).  If a showstopper comes up before then, I'll
> email the list.  If you think we really aren't ready for beta, then I would
> still like to get a release out today.  In that case, we'll call it alpha
> and delay the betas.

I have two release blockers pending review:

  http://bugs.python.org/issue2918
  http://bugs.python.org/issue2917

I believe both patches are ready to be committed to the py3k branch.
However, I would certainly like that someone would review the patches
(or at least test them).

Right now, I am currently looking at fixing issue 2919
(http://bugs.python.org/issue2919). The profile and the cProfile
module differ much more than I originally expected.  So, I won't be
able to get these two for the beta.

I have also been looking at http://bugs.python.org/issue2874, in which
Benjamin Peterson proposed an simple solution to fix it. Although I
haven't tried his approach, I think I could get this one done for
today.

Finally, I would like to commit the patch in
http://bugs.python.org/issue2523 which fix the quadratic behavior in
BufferedReader.read(). It would also be nice to have someone else
experienced with the io module to review the patch.

Cheers,
-- Alexandre

From barry at python.org  Wed Jun 11 23:42:59 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Jun 2008 17:42:59 -0400
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <acd65fa20806111354h3788345xcea09b5d30cc8b0e@mail.gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<acd65fa20806111354h3788345xcea09b5d30cc8b0e@mail.gmail.com>
Message-ID: <45AC8DA6-353F-41F5-997C-15E419D1D1F8@python.org>

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

On Jun 11, 2008, at 4:54 PM, Alexandre Vassalotti wrote:

> On Wed, Jun 11, 2008 at 7:35 AM, Barry Warsaw <barry at python.org>  
> wrote:
>> My plan is to begin building the betas tonight, at around 9 or 10pm  
>> EDT
>> (0100 to 0200 UTC Thursday).  If a showstopper comes up before  
>> then, I'll
>> email the list.  If you think we really aren't ready for beta, then  
>> I would
>> still like to get a release out today.  In that case, we'll call it  
>> alpha
>> and delay the betas.
>
> I have two release blockers pending review:
>
>  http://bugs.python.org/issue2918
>  http://bugs.python.org/issue2917
>
> I believe both patches are ready to be committed to the py3k branch.
> However, I would certainly like that someone would review the patches
> (or at least test them).

In IRC, Benjamin agreed to review these and commit them if they look  
okay.  I'm still 3-4 hours away from making the betas, so there's time  
to do this and still see how the buildbots react.

- -Barry

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

iQCVAwUBSFBG43EjvBPtnXfVAQJSYAP9FwvFppbeIQX8IhCUtXAXf5jSoGkpTKHQ
FT5PBhI/WmM1HTwtx3i06EA/3P+rB2yIVOJhCuK1ORoLvAZO1C8gKUp/8yvgH2KD
0OtlVYgfs4iXwgXe36dI9uBt9AIaohHNnuEgzqzH/IXIcdZ21bp3WKJTbvSgruFX
q0K3SkO9ano=
=TI1T
-----END PGP SIGNATURE-----

From barry at python.org  Thu Jun 12 00:13:49 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Jun 2008 18:13:49 -0400
Subject: [Python-3000] Potential beta showstopper (was Re: [Python-Dev] Have
	been sick, am behind on mail,
	let me know if there's anything urgent for me)
In-Reply-To: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
Message-ID: <0BFACB06-37F1-447A-8828-2B41DB7C98D1@python.org>

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

Okay, we have a potential showstopper for the betas today.  All the  
3.0 buildbots are bloody red:

http://www.python.org/dev/buildbot/stable/

Running the tests locally on OS X 10.5 and Ubuntu 8.04 confirm that  
the tests hang after test_xmlrpc.  The tests are uninterruptible.

I hereby give permission to any dev with commit privileges to checkin  
a fix, or back out the offending revision.  I will be off-line for  
about 3 more hours and if this can't be fixed by then, we will have to  
postpone the releases.

Once I'm back, I'll be on #python-dev @ freenode.

Thanks to Benjamin and Alexandre for helping me get through the  
current crop of release critical issues today.

- -Barry

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

iQCVAwUBSFBOHXEjvBPtnXfVAQK6zQP+Nnjt6Q97heAuquZgKEfMxXBL/QzodDgB
Th58+w04h0gTVW39Y9NEeKynVPrjsbjxKdrbdZ0i+1pEbqJMXyV65jFmxqb+mYdd
194s5hm+U0KEk7h+64aEkmvFPAgeZ2TGBrqCu5CWDNbWmqerPWuNDzqPxQrWd4Mt
wcaic8LFaaU=
=4MTf
-----END PGP SIGNATURE-----

From musiccomposition at gmail.com  Thu Jun 12 00:18:26 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 11 Jun 2008 17:18:26 -0500
Subject: [Python-3000] Potential beta showstopper (was Re: [Python-Dev]
	Have been sick, am behind on mail,
	let me know if there's anything urgent for me)
In-Reply-To: <0BFACB06-37F1-447A-8828-2B41DB7C98D1@python.org>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
	<0BFACB06-37F1-447A-8828-2B41DB7C98D1@python.org>
Message-ID: <1afaf6160806111518t3655df6bl80a6b4dc589d08c3@mail.gmail.com>

On Wed, Jun 11, 2008 at 5:13 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Okay, we have a potential showstopper for the betas today.  All the 3.0
> buildbots are bloody red:
>
> http://www.python.org/dev/buildbot/stable/
>
> Running the tests locally on OS X 10.5 and Ubuntu 8.04 confirm that the
> tests hang after test_xmlrpc.  The tests are uninterruptible.
>
> I hereby give permission to any dev with commit privileges to checkin a fix,
> or back out the offending revision.  I will be off-line for about 3 more
> hours and if this can't be fixed by then, we will have to postpone the
> releases.

Already done.


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

From skip at pobox.com  Wed Jun 11 21:14:03 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 11 Jun 2008 14:14:03 -0500
Subject: [Python-3000] Trunk / branch switch
In-Reply-To: <ca471dc20806110732y2e147e7dsfc96ee6f2f54df2a@mail.gmail.com>
References: <e04bdf310806110725kf13f45x35552cbcb40211fe@mail.gmail.com>
	<ca471dc20806110732y2e147e7dsfc96ee6f2f54df2a@mail.gmail.com>
Message-ID: <18512.9211.914169.987759@montanaro-dyndns-org.local>


    >> Is already planned the moment when "trunk" will mean Py 3, and the Py
    >> 2 development will be carried on in a branch?

    Guido> I don't think such a moment is planned. It would have to be far
    Guido> in the future, when 2.x is only used by old farts.

I suspect I might qualify as an old fart today.  If I qualify I suspect Tim
and Barry aren't too far behind.  Is the time machine running in reverse???

<wink>

Skip

From dalcinl at gmail.com  Thu Jun 12 01:13:18 2008
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Wed, 11 Jun 2008 20:13:18 -0300
Subject: [Python-3000] MANIFEST.in -> MANIFEST
Message-ID: <e7ba66e40806111613n2afe171ft6d4376e7ea641bc9@mail.gmail.com>

Could someone give a try to Py3K distutils to see iff 'MANIFEST' is
correctly generated from 'MANIFEST.in', specially in the case of
having 'include' and 'recursive-include' sentences?


-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

From barry at python.org  Thu Jun 12 03:38:06 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Jun 2008 21:38:06 -0400
Subject: [Python-3000] Trunk / branch switch
In-Reply-To: <18512.9211.914169.987759@montanaro-dyndns-org.local>
References: <e04bdf310806110725kf13f45x35552cbcb40211fe@mail.gmail.com>
	<ca471dc20806110732y2e147e7dsfc96ee6f2f54df2a@mail.gmail.com>
	<18512.9211.914169.987759@montanaro-dyndns-org.local>
Message-ID: <E9513F5F-BF27-439C-8CC0-A664C8DF54D4@python.org>

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

On Jun 11, 2008, at 3:14 PM, skip at pobox.com wrote:

>
>>> Is already planned the moment when "trunk" will mean Py 3, and the  
>>> Py
>>> 2 development will be carried on in a branch?
>
>    Guido> I don't think such a moment is planned. It would have to  
> be far
>    Guido> in the future, when 2.x is only used by old farts.
>
> I suspect I might qualify as an old fart today.  If I qualify I  
> suspect Tim
> and Barry aren't too far behind.  Is the time machine running in  
> reverse???

Tim is way way older than me.  I'm just a little cheek sneak compared  
to him.

playing-the-curmudgeon-with-gusto-ly y'rs,
- -Barry

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

iQCVAwUBSFB9/nEjvBPtnXfVAQI8pAP/Rs48pawkaJ4op5W6PP3mGRAPihRsFhJ5
sC8DirKRbf8ff1ctc+QTiVWkV4BxUkG8Pcp74zsKfTKIDgVx06JDOyV+B9U8lIfR
fjVYeqFbB6ZBjayouwxUDHzIOtOjftIR6dk3rpBwsvX1+KHX5eBRnVMDtujXcFEJ
FKIpd8Iakfw=
=wJYu
-----END PGP SIGNATURE-----

From guido at python.org  Thu Jun 12 04:16:36 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Jun 2008 19:16:36 -0700
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <45AC8DA6-353F-41F5-997C-15E419D1D1F8@python.org>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<acd65fa20806111354h3788345xcea09b5d30cc8b0e@mail.gmail.com>
	<45AC8DA6-353F-41F5-997C-15E419D1D1F8@python.org>
Message-ID: <ca471dc20806111916g7ffdc072i55ae6d10af9d1f0c@mail.gmail.com>

On Wed, Jun 11, 2008 at 2:42 PM, Barry Warsaw <barry at python.org> wrote:
> On Jun 11, 2008, at 4:54 PM, Alexandre Vassalotti wrote:
>> I have two release blockers pending review:
>>
>>  http://bugs.python.org/issue2918
>>  http://bugs.python.org/issue2917
>>
>> I believe both patches are ready to be committed to the py3k branch.
>> However, I would certainly like that someone would review the patches
>> (or at least test them).
>
> In IRC, Benjamin agreed to review these and commit them if they look okay.
>  I'm still 3-4 hours away from making the betas, so there's time to do this
> and still see how the buildbots react.

That's great, and I see these were committed and the bugs closed. Next
time, can we also have some kind of OK from the reviewer (Benjamin, I
presume) in the issue tracker? IRC does not leave a usable trail of
decisions.

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

From guido at python.org  Thu Jun 12 04:18:53 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Jun 2008 19:18:53 -0700
Subject: [Python-3000] [Python-Dev] Potential beta showstopper (was Re:
	Have been sick, am behind on mail,
	let me know if there's anything urgent for me)
In-Reply-To: <1afaf6160806111518t3655df6bl80a6b4dc589d08c3@mail.gmail.com>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
	<0BFACB06-37F1-447A-8828-2B41DB7C98D1@python.org>
	<1afaf6160806111518t3655df6bl80a6b4dc589d08c3@mail.gmail.com>
Message-ID: <ca471dc20806111918j5bf58f9vbcc9d8d01c2d1bad@mail.gmail.com>

On Wed, Jun 11, 2008 at 3:18 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> On Wed, Jun 11, 2008 at 5:13 PM, Barry Warsaw <barry at python.org> wrote:
>> Okay, we have a potential showstopper for the betas today.  All the 3.0
>> buildbots are bloody red:
>>
>> http://www.python.org/dev/buildbot/stable/
>>
>> Running the tests locally on OS X 10.5 and Ubuntu 8.04 confirm that the
>> tests hang after test_xmlrpc.  The tests are uninterruptible.
>>
>> I hereby give permission to any dev with commit privileges to checkin a fix,
>> or back out the offending revision.  I will be off-line for about 3 more
>> hours and if this can't be fixed by then, we will have to postpone the
>> releases.
>
> Already done.

Done what? Fixed, or backed out? Any more details? Old farts who
aren't on IRC want to know. :-)

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

From barry at python.org  Thu Jun 12 04:21:27 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Jun 2008 22:21:27 -0400
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <ca471dc20806111916g7ffdc072i55ae6d10af9d1f0c@mail.gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<acd65fa20806111354h3788345xcea09b5d30cc8b0e@mail.gmail.com>
	<45AC8DA6-353F-41F5-997C-15E419D1D1F8@python.org>
	<ca471dc20806111916g7ffdc072i55ae6d10af9d1f0c@mail.gmail.com>
Message-ID: <FDBE3994-7DD2-4CA6-869B-61DBDE346F82@python.org>

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

On Jun 11, 2008, at 10:16 PM, Guido van Rossum wrote:

> On Wed, Jun 11, 2008 at 2:42 PM, Barry Warsaw <barry at python.org>  
> wrote:
>> On Jun 11, 2008, at 4:54 PM, Alexandre Vassalotti wrote:
>>> I have two release blockers pending review:
>>>
>>> http://bugs.python.org/issue2918
>>> http://bugs.python.org/issue2917
>>>
>>> I believe both patches are ready to be committed to the py3k branch.
>>> However, I would certainly like that someone would review the  
>>> patches
>>> (or at least test them).
>>
>> In IRC, Benjamin agreed to review these and commit them if they  
>> look okay.
>> I'm still 3-4 hours away from making the betas, so there's time to  
>> do this
>> and still see how the buildbots react.
>
> That's great, and I see these were committed and the bugs closed. Next
> time, can we also have some kind of OK from the reviewer (Benjamin, I
> presume) in the issue tracker? IRC does not leave a usable trail of
> decisions.

Good point.
- -Barry

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

iQCVAwUBSFCIJ3EjvBPtnXfVAQIvXAP/fB6WAD4lS3XEKyEt/FwEoBfgileV4/bj
4km/LPOEtjN4jNks8dSoL+JHsym/76r0uylx3s3jH1sLCKmM7i9tD/SNo/Cim6r9
5fgDmreZkDU+zyyvhdiuxUl+jxmroDPd3R6vPptVbwly4SHsftceZ6jToJUvcNPd
p0nDoyCI8VU=
=xktw
-----END PGP SIGNATURE-----

From musiccomposition at gmail.com  Thu Jun 12 04:32:46 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 11 Jun 2008 21:32:46 -0500
Subject: [Python-3000] [Python-Dev] Potential beta showstopper (was Re:
	Have been sick, am behind on mail,
	let me know if there's anything urgent for me)
In-Reply-To: <ca471dc20806111918j5bf58f9vbcc9d8d01c2d1bad@mail.gmail.com>
References: <ca471dc20806101707v5017b81fx2232353d85e39753@mail.gmail.com>
	<0BFACB06-37F1-447A-8828-2B41DB7C98D1@python.org>
	<1afaf6160806111518t3655df6bl80a6b4dc589d08c3@mail.gmail.com>
	<ca471dc20806111918j5bf58f9vbcc9d8d01c2d1bad@mail.gmail.com>
Message-ID: <1afaf6160806111932v2371bdbbhca3e25ccea7c5620@mail.gmail.com>

On Wed, Jun 11, 2008 at 9:18 PM, Guido van Rossum <guido at python.org> wrote:
> On Wed, Jun 11, 2008 at 3:18 PM, Benjamin Peterson
>>
>> Already done.
>
> Done what? Fixed, or backed out? Any more details? Old farts who
> aren't on IRC want to know. :-)

That would be fixed.

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



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

From barry at python.org  Thu Jun 12 07:00:19 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 12 Jun 2008 01:00:19 -0400
Subject: [Python-3000] No betas today
Message-ID: <3F811617-7E55-4290-BB1E-14229E563C5F@python.org>

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

Much thanks to Benjamin Peterson and Alexandre Vassalotti for  
providing much help today trying to get the betas out.  Unfortunately,  
it's not gonna happen today.  There are two issues blocking the release.

http://bugs.python.org/issue3088
http://bugs.python.org/issue3089

The main problem (issue 3089) is that none of the Python 3.0 buildbots  
are green.  Issue 3088 may only happen for me, but  
test_multiprocessing simply hangs for me on OS X 10.5.3.

I'm going to bed now.  As soon as we can turn the bots green we can  
try again.  This weekend might be a good time for me.

Please help out by resolving these two issues.

- -Barry

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

iQCVAwUBSFCtZHEjvBPtnXfVAQLrHQQAoq1RCNeawpJHaefuvmZiS4VZzzvtV5Bm
HFW6FWyO86NNEcCK6Delthf+H1mgjCaoymHojxBJhWm7UJK0WjMz+0RpF8zcLo0R
i8I8SiFLy6kRB5UxlZHS/VXDi8QS92SogRvlnWLBwXNNK6wlgeqK8C0zt1ilL0q6
Fqk/AsGO/fA=
=HlEA
-----END PGP SIGNATURE-----

From stefan_ml at behnel.de  Thu Jun 12 08:03:14 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 12 Jun 2008 08:03:14 +0200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <484E001A.5000002@v.loewis.de>
References: <484E001A.5000002@v.loewis.de>
Message-ID: <g2qe71$mq$1@ger.gmane.org>

Martin v. L?wis wrote:
> I just finished a PEP 3121 implementation

Maybe a bit late for this question, but:

Was it necessary to remove Py_InitModule4() for this change? We use that in
Cython, so this breaks building extension module in current Py3.

Stefan


From stefan_ml at behnel.de  Thu Jun 12 08:18:42 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 12 Jun 2008 08:18:42 +0200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <g2qe71$mq$1@ger.gmane.org>
References: <484E001A.5000002@v.loewis.de> <g2qe71$mq$1@ger.gmane.org>
Message-ID: <g2qf42$3fu$1@ger.gmane.org>

Stefan Behnel wrote:
> Martin v. L?wis wrote:
>> I just finished a PEP 3121 implementation
> 
> Maybe a bit late for this question, but:
> 
> Was it necessary to remove Py_InitModule4() for this change? We use that in
> Cython, so this breaks building extension module in current Py3.

Hmmm, ok, looking into this some more, I realise that this was obviously
necessary to replace the API. When I first read this PEP, I imagined that this
would appear in addition to what was there already, or at least that there'd
be a compatibility layer.

So, next question: what's the migration path to write portable code, then? Up
to this change, we supported every Python version starting from 2.3, including
3.0alpha5, and it would be nice to continue to do so with 3.0 final.

Stefan


From talin at acm.org  Thu Jun 12 08:51:39 2008
From: talin at acm.org (Talin)
Date: Wed, 11 Jun 2008 23:51:39 -0700
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <484EE897.90309@v.loewis.de>
References: <484E001A.5000002@v.loewis.de> <g2m8ar$rka$1@ger.gmane.org>
	<484EE897.90309@v.loewis.de>
Message-ID: <4850C77B.3090806@acm.org>

Martin v. L?wis wrote:
> Third, once you managed to truly separate interpreters, you *will*
> have to marshal objects across interpreters, as there won't be any
> shared ones. It's in the same address space, but you still would
> have to do marshalling, or else you might introduce sharing again.

I saw a talk today in which the presenter was talking about "guaranteed 
transfer of ownership" enforced by the language runtime. Essentially, it 
was a technique to allow a data structure to be passed from one thread 
to another, with a guarantee that there would be no heap pointers under 
control of the old thread pointing to anywhere in the data structure. 
When ownership is transferred, the old thread loses all visibility 
within the data structure, and the new thread now gains visibility of 
the structure. This was used to implement a non-copying message passing 
framework.

(Not suggesting this for Python, just thought it was interesting.)

-- Talin


From martin at v.loewis.de  Thu Jun 12 09:06:30 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 12 Jun 2008 09:06:30 +0200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <4850C77B.3090806@acm.org>
References: <484E001A.5000002@v.loewis.de> <g2m8ar$rka$1@ger.gmane.org>
	<484EE897.90309@v.loewis.de> <4850C77B.3090806@acm.org>
Message-ID: <4850CAF6.9000807@v.loewis.de>

> I saw a talk today in which the presenter was talking about "guaranteed
> transfer of ownership" enforced by the language runtime. Essentially, it
> was a technique to allow a data structure to be passed from one thread
> to another, with a guarantee that there would be no heap pointers under
> control of the old thread pointing to anywhere in the data structure.
> When ownership is transferred, the old thread loses all visibility
> within the data structure, and the new thread now gains visibility of
> the structure. This was used to implement a non-copying message passing
> framework.

In the same spirit, .NET "smuggles" objects across app-domains, if
it can determine that sharing the objects is safe. It does so only for
string objects, though, IIRC (which are safe to smuggle because they
are immutable). The in-memory remoting channel then transfers a single
byte array (the marshalled data), plus an object array of smuggled
objects.

Regards,
Martin



From stefan_ml at behnel.de  Thu Jun 12 09:42:25 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 12 Jun 2008 09:42:25 +0200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <g2qf42$3fu$1@ger.gmane.org>
References: <484E001A.5000002@v.loewis.de> <g2qe71$mq$1@ger.gmane.org>
	<g2qf42$3fu$1@ger.gmane.org>
Message-ID: <g2qk10$glg$1@ger.gmane.org>

Hi Martin,

Stefan Behnel wrote:
>> Martin v. L?wis wrote:
>>> I just finished a PEP 3121 implementation
> 
> what's the migration path to write portable code, then?

Looking through your complete commit, I realised that it's actually not that
hard to work around the API changes by basically providing a dummy PyModuleDef
with the original Py_InitModule4() parameters, which I now did in Cython.

Just to mention it, I actually like the new API a lot, and we'll build upon
that to provide better module cleanup support in later versions. That's
something that we were missing for a while already.

Thanks,
Stefan


From ncoghlan at gmail.com  Thu Jun 12 12:35:40 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 12 Jun 2008 20:35:40 +1000
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>
Message-ID: <4850FBFC.9070501@gmail.com>

Guido van Rossum wrote:
> On Wed, Jun 11, 2008 at 4:35 AM, Barry Warsaw <barry at python.org> wrote:
>> So I had planned to do a bunch of work last night looking at the release
>> blocker issues, but nature intervened.  A bunch of severe thunderstorms
>> knock out my 'net access until this morning.
>>
>> I'll try to find some time during the day to look at the RB issues.
>>  Hopefully we can get Guido to look at them too and Pronounce on some of
>> them.  Guido please start with:
>>
>> http://bugs.python.org/issue643841
> 
> I've added a comment. Let me know if anything I said is unclear.

The bugtracker seems to be offline atm - I'll reply there once I can get 
to it again (as well as switching this issue back to being a 
documentation one).

I don't think we're going to see a major clamor for a value-based 
delegation mixin in the standard library until people using classic 
classes for value-based delegation start making serious attempts to port 
to Py3k (where that approach is no longer available). At the moment, 
such classes only need to care about the methods they want to fiddle 
with, leaving everything else to __getattr__ based delegation.

I've pushed as hard as I'm personally willing to for this without 
convincing anyone else that it's worth doing, so I'll start working on a 
documentation patch for the language reference instead which explicitly 
splits the special methods into the following categories:

1. Method lookup MUST bypass __getattribute__, shadowing the attribute 
in the instance dictionary MUST NOT have any ill effects. (All tp_* 
C-level slots and slots looked up via _PyType_Lookup will fit into this 
category)

2. Method lookup MAY bypass __getattribute__, shadowing the attribute in 
the instance dictionary MAY have ill effects. (slots such as __enter__ 
and __exit__ that are looked up via normal attribute lookup in CPython 
will fit into this category)

3. Technically a subcategory of group 1, these are special methods which 
can affect the interpreter's behaviour by their mere definition on a 
type. (The __get__, __set__ and __delete__ descriptor protocol methods 
fall into this category)

Cheers,
Nick.

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

From jnoller at gmail.com  Thu Jun 12 13:08:52 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Thu, 12 Jun 2008 07:08:52 -0400
Subject: [Python-3000] No betas today
In-Reply-To: <3F811617-7E55-4290-BB1E-14229E563C5F@python.org>
References: <3F811617-7E55-4290-BB1E-14229E563C5F@python.org>
Message-ID: <5F4CD1A3-867F-4E37-863A-C2B9324F02DD@gmail.com>

That's odd - I've been doing all of the mp work on osx 10.5.3 - I'll  
run the units in a loop today to see if I can catch it.
-Jesse

On Jun 12, 2008, at 1:00 AM, Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Much thanks to Benjamin Peterson and Alexandre Vassalotti for  
> providing much help today trying to get the betas out.   
> Unfortunately, it's not gonna happen today.  There are two issues  
> blocking the release.
>
> http://bugs.python.org/issue3088
> http://bugs.python.org/issue3089
>
> The main problem (issue 3089) is that none of the Python 3.0  
> buildbots are green.  Issue 3088 may only happen for me, but  
> test_multiprocessing simply hangs for me on OS X 10.5.3.
>
> I'm going to bed now.  As soon as we can turn the bots green we can  
> try again.  This weekend might be a good time for me.
>
> Please help out by resolving these two issues.
>
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Darwin)
>
> iQCVAwUBSFCtZHEjvBPtnXfVAQLrHQQAoq1RCNeawpJHaefuvmZiS4VZzzvtV5Bm
> HFW6FWyO86NNEcCK6Delthf+H1mgjCaoymHojxBJhWm7UJK0WjMz+0RpF8zcLo0R
> i8I8SiFLy6kRB5UxlZHS/VXDi8QS92SogRvlnWLBwXNNK6wlgeqK8C0zt1ilL0q6
> Fqk/AsGO/fA=
> =HlEA
> -----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/jnoller%40gmail.com

From barry at python.org  Thu Jun 12 13:35:15 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 12 Jun 2008 07:35:15 -0400
Subject: [Python-3000] No betas today
In-Reply-To: <5F4CD1A3-867F-4E37-863A-C2B9324F02DD@gmail.com>
References: <3F811617-7E55-4290-BB1E-14229E563C5F@python.org>
	<5F4CD1A3-867F-4E37-863A-C2B9324F02DD@gmail.com>
Message-ID: <217F21B5-0747-46A4-8B44-11FA81D83F68@python.org>

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

On Jun 12, 2008, at 7:08 AM, Jesse Noller wrote:

> That's odd - I've been doing all of the mp work on osx 10.5.3 - I'll  
> run the units in a loop today to see if I can catch it.
> -Jesse

Thanks.  It's definitely reproducible on both my Leopard boxes.  I  
haven't tried it on my Tiger box.  The buildbots seem unhappy too.

- -Barry

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

iQCVAwUBSFEJ9HEjvBPtnXfVAQJlNwQAsG2M/hNORYSuCsmKHU+nvbX3cASiFlhj
IIhNfdrtkRbjXBaDgxrr/Ps1+Q3I56lpSg5SDEWxXVufNdBdHXGAKKxnrYN22a1x
Nwuu+DXOGYmzBcQc2BS5L9/31yeDmSFBMP257BBstCZww97pt8VRLKpUL2Wzfzny
MZb6Km/NXwQ=
=Ab3l
-----END PGP SIGNATURE-----

From guido at python.org  Thu Jun 12 15:55:07 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Jun 2008 06:55:07 -0700
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <4850FBFC.9070501@gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>
	<4850FBFC.9070501@gmail.com>
Message-ID: <ca471dc20806120655s60e378bj8850b37c676b313b@mail.gmail.com>

[Barry]
>>> http://bugs.python.org/issue643841

[Guido]
>> I've added a comment. Let me know if anything I said is unclear.

On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> The bugtracker seems to be offline atm - I'll reply there once I can get to
> it again (as well as switching this issue back to being a documentation
> one).
>
> I don't think we're going to see a major clamor for a value-based delegation
> mixin in the standard library until people using classic classes for
> value-based delegation start making serious attempts to port to Py3k (where
> that approach is no longer available). At the moment, such classes only need
> to care about the methods they want to fiddle with, leaving everything else
> to __getattr__ based delegation.

Whether they'll care about this issue of course depends on whether
they need overloaded operators and other special delegations to be
delegated transparently. We'll have to see how important this is.
New-style classes have been around and recommended for a long time --
why haven't people pushed for a proxy class before?

> I've pushed as hard as I'm personally willing to for this without convincing
> anyone else that it's worth doing,

What does *it* refer to? Changing the behavior, or adding a proxy
class to the stdlib? I'm -1000 on the former, but only -0 on the
latter -- as I wrote in the tracker, I just don't want to see an
unproven proxy class (and I don't like the module name).

> so I'll start working on a documentation
> patch for the language reference instead which explicitly splits the special
> methods into the following categories:

Thanks for doing this, it is needed regardless!

> 1. Method lookup MUST bypass __getattribute__, shadowing the attribute in
> the instance dictionary MUST NOT have any ill effects. (All tp_* C-level
> slots and slots looked up via _PyType_Lookup will fit into this category)

Watch out: I think the term "method lookup" may be confusing here.
Certainly when the user writes x.__foo__(), the instance dict *is*
consulted. It is only on *implied* lookups (e.g. x[y] or x+y) where
the instance dict is bypassed.

> 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in the
> instance dictionary MAY have ill effects. (slots such as __enter__ and
> __exit__ that are looked up via normal attribute lookup in CPython will fit
> into this category)

Why even have a  MAY category? Are you expecting these to become tp_
slots at some point?

> 3. Technically a subcategory of group 1, these are special methods which can
> affect the interpreter's behaviour by their mere definition on a type. (The
> __get__, __set__ and __delete__ descriptor protocol methods fall into this
> category)

I don't follow why this is relevant. This is a different, AFAIK
orthogonal issue, used in many places: *if* an object used in a
certain context has a specific attribute, *then* that attribute is
used, *otherwise* a default action is taken. Applies to __repr__ just
as much. These belong in category 1 if and only if the lookup bypasses
the instance dict.

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

From ncoghlan at gmail.com  Thu Jun 12 16:50:36 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 13 Jun 2008 00:50:36 +1000
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <ca471dc20806120655s60e378bj8850b37c676b313b@mail.gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	
	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>	
	<4850FBFC.9070501@gmail.com>
	<ca471dc20806120655s60e378bj8850b37c676b313b@mail.gmail.com>
Message-ID: <485137BC.2070505@gmail.com>

Guido van Rossum wrote:
> [Barry]
>>>> http://bugs.python.org/issue643841
> 
> [Guido]
>>> I've added a comment. Let me know if anything I said is unclear.
> 
> On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> The bugtracker seems to be offline atm - I'll reply there once I can get to
>> it again (as well as switching this issue back to being a documentation
>> one).
>>
>> I don't think we're going to see a major clamor for a value-based delegation
>> mixin in the standard library until people using classic classes for
>> value-based delegation start making serious attempts to port to Py3k (where
>> that approach is no longer available). At the moment, such classes only need
>> to care about the methods they want to fiddle with, leaving everything else
>> to __getattr__ based delegation.
> 
> Whether they'll care about this issue of course depends on whether
> they need overloaded operators and other special delegations to be
> delegated transparently. We'll have to see how important this is.
> New-style classes have been around and recommended for a long time --
> why haven't people pushed for a proxy class before?

There was an easier way to do it in the form of classic classes - the 
2,x interpreter is riddled with special cases that ensure that 
__getattr__ is always consulted when looking for special methods on a 
classic class. The tracker issue regarding the fact that things aren't 
so simple with new style classes was actually raised way back in 2002 
when someone tried to port such a class to new-style and discovered that 
overriding __getattribute__ was no longer enough.

>> I've pushed as hard as I'm personally willing to for this without convincing
>> anyone else that it's worth doing,
> 
> What does *it* refer to? Changing the behavior, or adding a proxy
> class to the stdlib? I'm -1000 on the former, but only -0 on the
> latter -- as I wrote in the tracker, I just don't want to see an
> unproven proxy class (and I don't like the module name).

"It" referred to adding the proxy class - I'm personally ambivalent on 
adding it at this point, because the complexity of it reduces my 
confidence that I got it right, but it also makes it seem unfair to 
users of this feature of classic classes to take it away in 3.0 without 
giving them some kind of functional replacement.

As for as the module name goes, I don't particularly like it either - 
dropping something in the types module instead would be an alternative 
option.

>> so I'll start working on a documentation
>> patch for the language reference instead which explicitly splits the special
>> methods into the following categories:
> 
> Thanks for doing this, it is needed regardless!
> 
>> 1. Method lookup MUST bypass __getattribute__, shadowing the attribute in
>> the instance dictionary MUST NOT have any ill effects. (All tp_* C-level
>> slots and slots looked up via _PyType_Lookup will fit into this category)
> 
> Watch out: I think the term "method lookup" may be confusing here.
> Certainly when the user writes x.__foo__(), the instance dict *is*
> consulted. It is only on *implied* lookups (e.g. x[y] or x+y) where
> the instance dict is bypassed.

Ah good point, I'll make sure to be careful with that.

>> 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in the
>> instance dictionary MAY have ill effects. (slots such as __enter__ and
>> __exit__ that are looked up via normal attribute lookup in CPython will fit
>> into this category)
> 
> Why even have a  MAY category? Are you expecting these to become tp_
> slots at some point?

Either tp_* slots, or just having the invocation bypass the instance 
attributes and only look at the object's type.

I think it would actually be desirable for this category to be empty 
from a purity point of view (with all the special methods in category 
1), but given that CPython itself currently doesn't conform to such a 
language spec, this seems to be the next best option (i.e. allowing 
other implementations or later versions of CPython to put these special 
methods in category 1 along with the rest of the special methods)

>> 3. Technically a subcategory of group 1, these are special methods which can
>> affect the interpreter's behaviour by their mere definition on a type. (The
>> __get__, __set__ and __delete__ descriptor protocol methods fall into this
>> category)
> 
> I don't follow why this is relevant. This is a different, AFAIK
> orthogonal issue, used in many places: *if* an object used in a
> certain context has a specific attribute, *then* that attribute is
> used, *otherwise* a default action is taken. Applies to __repr__ just
> as much. These belong in category 1 if and only if the lookup bypasses
> the instance dict.

Actual hasattr() checks aren't a problem - those hit __getattribute__ 
and a delegating class can correctly check them against the target 
object. Methods like __str__ or __repr__ also aren't a major issue - 
those are easy to delegate in a way that reproduces the same behaviour 
as if the delegating class wasn't there (just reinvoke the appropriate 
builtin on your target object).

This category is specifically for method checks in category 1 which 
bypass __getattribute__ *and* have significant effects on the way an 
object gets handled that can't be readily dealt with by a value-based 
delegation class - the most significant methods I've actually found in 
that category so far are the descriptor protocol methods (that's why my 
ProxyMixin class skipped delegating them).

As long as the callable() builtin is around, __call__ actually lands in 
this category as well (since defining it will affect the answer returned 
by the callable() builtin). Being able to return different proxy classes 
with and without __callable__ defined is actually the reason 
weakref.proxy is a factory function rather than a type in its own right.

Cheers,
Nick.

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

From ncoghlan at gmail.com  Thu Jun 12 16:54:08 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 13 Jun 2008 00:54:08 +1000
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <48EE15E7.7020701@voidspace.org.uk>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>	<4850FBFC.9070501@gmail.com>
	<ca471dc20806120655s60e378bj8850b37c676b313b@mail.gmail.com>
	<48EE15E7.7020701@voidspace.org.uk>
Message-ID: <48513890.6080303@gmail.com>

Michael Foord wrote:
> Guido van Rossum wrote:
>> Whether they'll care about this issue of course depends on whether
>> they need overloaded operators and other special delegations to be
>> delegated transparently. We'll have to see how important this is.
>> New-style classes have been around and recommended for a long time --
>> why haven't people pushed for a proxy class before?
> 
> It's only in Python 3 that old style classes are going away fully, so up 
> until now you could at least use a classic class to do the proxying.
> 
> I've written my own proxy classes before that look very similar to this, 
> and there are other proxy classes around that do the same (I thought one 
> was by Phillip J Eby but can't find a reference easily). The last one I 
> wrote was to proxy CPython objects from IronPython via Python.NET...
> 
> I would prefer it if the proxy class wrapped the return values of 
> inplace operations.

Yeah, the latest version on the issue tracker does that, and allows 
subclasses to define a return_inplace() method to alter the behaviour 
(e.g. a weakref.proxy equivalent wouldn't want to wrap the return values 
so that it can ensure there is always at least one strong reference to 
the result of the operation).

Since you can also replace the .target attribute with a property to 
affect how the target object is stored and accessed, it's a reasonably 
flexible approach.

Cheers,
Nick.

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

From walter at livinglogic.de  Thu Jun 12 16:59:54 2008
From: walter at livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Thu, 12 Jun 2008 16:59:54 +0200
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <485003F8.40803@egenix.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>	<484FEC2C.6070409@livinglogic.de>
	<485003F8.40803@egenix.com>
Message-ID: <485139EA.1000502@livinglogic.de>

M.-A. Lemburg wrote:
> On 2008-06-11 17:15, Walter D?rwald wrote:
>> M.-A. Lemburg wrote:
>>> On 2008-06-11 13:35, Barry Warsaw wrote:
>>>> So I had planned to do a bunch of work last night looking at the 
>>>> release blocker issues, but nature intervened.  A bunch of severe 
>>>> thunderstorms knock out my 'net access until this morning.
>>>>
>>>> I'll try to find some time during the day to look at the RB issues.  
>>>> Hopefully we can get Guido to look at them too and Pronounce on some 
>>>> of them.  Guido please start with:
>>>>
>>>> http://bugs.python.org/issue643841
>>>>
>>>> My plan is to begin building the betas tonight, at around 9 or 10pm 
>>>> EDT (0100 to 0200 UTC Thursday).  If a showstopper comes up before 
>>>> then, I'll email the list.  If you think we really aren't ready for 
>>>> beta, then I would still like to get a release out today.  In that 
>>>> case, we'll call it alpha and delay the betas.
>>>
>>> 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)
>>
>> What would these methods do? Use the codec machinery without any type 
>> checks?
> 
> As discussed in another thread some weeks ago:
> 
> .transform() and .untransform() use the codecs to apply same-type
> conversions. They do apply type checks to make sure that the
> codec does indeed return the same type.
> 
> E.g. text.transform('xml-escape') or data.transform('base64').

So what would a base64 codec do with the errors argument?

>> I think for transformations we don't need the full codec machinery:
>  > ...
> 
> No need to invent another wheel :-) The codecs already exist for
> Py2.x and can be used by the .encode()/.decode() methods in Py2.x
> (where no type checks occur).

By using a new API we could get rid of old warts. For example: Why does 
the stateless encoder/decoder return how many input characters/bytes it 
has consumed? It must consume *all* bytes anyway!

> In Py3.x, .encode()/.decode() only allow conversions of the type
> unicode <-> bytes. .transform()/.untransform() add conversions
> of the type unicode <-> unicode or bytes <-> bytes.
> 
> All other conversions in Py3.x have to go through codecs.encode() and
> codecs.decode() which are the generic codec access functions from
> the codec registry.

Servus,
    Walter


From solipsis at pitrou.net  Thu Jun 12 17:04:56 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 12 Jun 2008 15:04:56 +0000 (UTC)
Subject: [Python-3000] Betas today - I hope
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>
	<4850FBFC.9070501@gmail.com>
	<ca471dc20806120655s60e378bj8850b37c676b313b@mail.gmail.com>
Message-ID: <loom.20080612T145037-126@post.gmane.org>


Hello all,

> Whether they'll care about this issue of course depends on whether
> they need overloaded operators and other special delegations to be
> delegated transparently.

Perhaps it may happen more implicitly than people think. Especially
for methods like __bool__, __str__, __iter__...
After all special methods are special in that they can get called
behind your back in a number of situations, and those are regularly
growing :)

Of course one can also argue that the __bool__ and the __str__ of
a proxy doesn't have to have the same semantics as the __bool__
and the __str__ of the proxied object. The counter-argument here
(and I agree with it) was that most people want a transparent proxy
behaviour, and those who don't want, want a nearly-transparent proxy
behaviour, i.e. they want to start from a transparent proxy
implementation and then override the few methods whose behaviour
they want to special-case.

Another potential (but perhaps far-fetched) motivation is that a proxy 
implementation in the stdlib could be tweaked or rewritten in C, and
thus be much quicker that the naive implementation most people (including
me :-)) might come up with.

Regards

Antoine.



From mal at egenix.com  Thu Jun 12 17:43:36 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 12 Jun 2008 17:43:36 +0200
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <485139EA.1000502@livinglogic.de>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>	<484FEC2C.6070409@livinglogic.de>	<485003F8.40803@egenix.com>
	<485139EA.1000502@livinglogic.de>
Message-ID: <48514428.7040001@egenix.com>

On 2008-06-12 16:59, Walter D?rwald wrote:
> M.-A. Lemburg wrote:
>> .transform() and .untransform() use the codecs to apply same-type
>> conversions. They do apply type checks to make sure that the
>> codec does indeed return the same type.
>>
>> E.g. text.transform('xml-escape') or data.transform('base64').
> 
> So what would a base64 codec do with the errors argument?

It could use it to e.g. try to recover as much data as possible
from broken input data.

Currently (in Py2.x), it raises an exception if you pass in anything
but "strict".

>>> I think for transformations we don't need the full codec machinery:
>>  > ...
>>
>> No need to invent another wheel :-) The codecs already exist for
>> Py2.x and can be used by the .encode()/.decode() methods in Py2.x
>> (where no type checks occur).
> 
> By using a new API we could get rid of old warts. For example: Why does 
> the stateless encoder/decoder return how many input characters/bytes it 
> has consumed? It must consume *all* bytes anyway!

No, it doesn't and that's the point in having those return values :-)

Even though the encoder/decoders are stateless, that doesn't mean
they have to consume all input data. The caller is responsible to
make sure that all input data was in fact consumed.

You could for example have a decoder that stops decoding after
having seen a block end indicator, e.g. a base64 line end or
XML closing element.

Just because all codecs that ship with Python always try to decode
the complete input doesn't mean that the feature isn't being used.
The interface was designed to allow for the above situations.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 12 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/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            24 days to go

:::: 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 Jun 12 19:24:38 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Jun 2008 10:24:38 -0700
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <485137BC.2070505@gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>
	<4850FBFC.9070501@gmail.com>
	<ca471dc20806120655s60e378bj8850b37c676b313b@mail.gmail.com>
	<485137BC.2070505@gmail.com>
Message-ID: <ca471dc20806121024v3a4f2bcdj85a13591255fb226@mail.gmail.com>

[-python-dev]

[Guido]
>> Whether they'll care about this issue of course depends on whether
>> they need overloaded operators and other special delegations to be
>> delegated transparently. We'll have to see how important this is.
>> New-style classes have been around and recommended for a long time --
>> why haven't people pushed for a proxy class before?

On Thu, Jun 12, 2008 at 7:50 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> There was an easier way to do it in the form of classic classes - the 2,x
> interpreter is riddled with special cases that ensure that __getattr__ is
> always consulted when looking for special methods on a classic class. The
> tracker issue regarding the fact that things aren't so simple with new style
> classes was actually raised way back in 2002 when someone tried to port such
> a class to new-style and discovered that overriding __getattribute__ was no
> longer enough.

And all that time people have been using classic classes as a crutch
rather than developing a future-proof approach? I can't believe that.
I think we should look for some existing proxies so we can identify
best practice and perhaps improve upon. (Sorry if that's what you did,
I haven't checked.)

>>> I've pushed as hard as I'm personally willing to for this without
>>> convincing
>>> anyone else that it's worth doing,
>>
>> What does *it* refer to? Changing the behavior, or adding a proxy
>> class to the stdlib? I'm -1000 on the former, but only -0 on the
>> latter -- as I wrote in the tracker, I just don't want to see an
>> unproven proxy class (and I don't like the module name).
>
> "It" referred to adding the proxy class - I'm personally ambivalent on
> adding it at this point, because the complexity of it reduces my confidence
> that I got it right,

Also Michael Foord just wrote "I would prefer it if the proxy class
wrapped the return values of inplace operations" -- which sounds like
one reason why it's hard to have a one-size-fits-all proxy class,
since when to wrap and when not to is probably very application
dependent.

> but it also makes it seem unfair to users of this
> feature of classic classes to take it away in 3.0 without giving them some
> kind of functional replacement.
>
> As for as the module name goes, I don't particularly like it either -
> dropping something in the types module instead would be an alternative
> option.

No! Not the doomed types module! :-)

[...]
>>> 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in
>>> the instance dictionary MAY have ill effects. (slots such as __enter__ and
>>> __exit__ that are looked up via normal attribute lookup in CPython will
>>> fit into this category)
>>
>> Why even have a  MAY category? Are you expecting these to become tp_
>> slots at some point?
>
> Either tp_* slots, or just having the invocation bypass the instance
> attributes and only look at the object's type.
>
> I think it would actually be desirable for this category to be empty from a
> purity point of view (with all the special methods in category 1), but given
> that CPython itself currently doesn't conform to such a language spec, this
> seems to be the next best option (i.e. allowing other implementations or
> later versions of CPython to put these special methods in category 1 along
> with the rest of the special methods)

OK, fair point.

>>> 3. Technically a subcategory of group 1, these are special methods which
>>> can affect the interpreter's behaviour by their mere definition on a type.
>>> (The __get__, __set__ and __delete__ descriptor protocol methods fall into
>>> this category)
>>
>> I don't follow why this is relevant. This is a different, AFAIK
>> orthogonal issue, used in many places: *if* an object used in a
>> certain context has a specific attribute, *then* that attribute is
>> used, *otherwise* a default action is taken. Applies to __repr__ just
>> as much. These belong in category 1 if and only if the lookup bypasses
>> the instance dict.
>
> Actual hasattr() checks aren't a problem - those hit __getattribute__ and a
> delegating class can correctly check them against the target object.

I never said hasattr(). AFAIK what happens sometimes is that
_PyType_Lookup() is called and if it returns NULL the default action
is used.

> Methods
> like __str__ or __repr__ also aren't a major issue - those are easy to
> delegate in a way that reproduces the same behaviour as if the delegating
> class wasn't there (just reinvoke the appropriate builtin on your target
> object).
>
> This category is specifically for method checks in category 1 which bypass
> __getattribute__ *and* have significant effects on the way an object gets
> handled that can't be readily dealt with by a value-based delegation class -
> the most significant methods I've actually found in that category so far are
> the descriptor protocol methods (that's why my ProxyMixin class skipped
> delegating them).

Ah, now I understand. These are things that you shouldn't define in
the proxy class if the target class doesn't define it. I think I've
seen solutions that dynamically define a proxy class depending on
whether the target class implements a certain special method or not.

> As long as the callable() builtin is around, __call__ actually lands in this
> category as well (since defining it will affect the answer returned by the
> callable() builtin). Being able to return different proxy classes with and
> without __callable__ defined is actually the reason weakref.proxy is a
> factory function rather than a type in its own right.

What I said. :-)

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

From jimjjewett at gmail.com  Thu Jun 12 20:11:14 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Thu, 12 Jun 2008 14:11:14 -0400
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <4850FBFC.9070501@gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>
	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>
	<4850FBFC.9070501@gmail.com>
Message-ID: <fb6fbf560806121111y6a9de736ra69b669211b55ff3@mail.gmail.com>

On 6/12/08, Nick Coghlan <ncoghlan at gmail.com> wrote:

> documentation patch for the language reference ...
> following categories:
...

>  2. Method lookup MAY bypass __getattribute__, shadowing the attribute in
> the instance dictionary MAY have ill effects. (slots such as __enter__ and
> __exit__ that are looked up via normal attribute lookup in CPython will fit
> into this category)

Should this category really be enumerated?

I thought that was the default meaning of __name__, so the real
clarification is:

(1)  Requiring that the specific names in category 1 MUST be treated this way.

(2)  Mentioning __*__ and listing any known exceptions.  (Can "next"
be treated this way despite the lack of __*__?  Is it forbidden to
treat __context__ this way?)

-jJ

From g.brandl at gmx.net  Fri Jun 13 00:13:45 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 13 Jun 2008 00:13:45 +0200
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <4850FBFC.9070501@gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>
	<4850FBFC.9070501@gmail.com>
Message-ID: <g2s72u$2q5$1@ger.gmane.org>

Nick Coghlan schrieb:

> 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in 
> the instance dictionary MAY have ill effects. (slots such as __enter__ 
> and __exit__ that are looked up via normal attribute lookup in CPython 
> will fit into this category)

I would argue that the __enter__ and __exit__ behavior should be changed too.
The reason for the current behavior is this:

   2           0 LOAD_GLOBAL              0 (a)
               3 DUP_TOP
               4 LOAD_ATTR                1 (__exit__)
               7 STORE_FAST               0 (_[1])
              10 LOAD_ATTR                2 (__enter__)
              13 CALL_FUNCTION            0
              16 STORE_FAST               1 (_[2])
              19 SETUP_FINALLY           18 (to 40)

IOW, when "with" is compiled, the attributes are retrieved using bytecode.
It wouldn't be hard to have a WITH_SETUP opcode (along with the already
existing WITH_CLEANUP) that would make the bytecode read like:

   2           0 LOAD_GLOBAL              0 (a)
               3 WITH_SETUP               0 (_[1])
               6 STORE_FAST               1 (_[2])
               9 SETUP_FINALLY           18 (to 40)

Georg


From martin at v.loewis.de  Fri Jun 13 01:39:17 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jun 2008 01:39:17 +0200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <g2qe71$mq$1@ger.gmane.org>
References: <484E001A.5000002@v.loewis.de> <g2qe71$mq$1@ger.gmane.org>
Message-ID: <4851B3A5.90105@v.loewis.de>

> Was it necessary to remove Py_InitModule4() for this change? We use that in
> Cython, so this breaks building extension module in current Py3.

Yes: the new module API takes a number of additional function pointers,
which can't be passed in through Py_InitModule4.

While the change indeed systematically breaks all modules, this breakage
is shallow: it's usually straight-forward to port a module to 3.0 with
little changes to the init function.

Regards,
Martin

From martin at v.loewis.de  Fri Jun 13 01:40:44 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jun 2008 01:40:44 +0200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <g2qf42$3fu$1@ger.gmane.org>
References: <484E001A.5000002@v.loewis.de> <g2qe71$mq$1@ger.gmane.org>
	<g2qf42$3fu$1@ger.gmane.org>
Message-ID: <4851B3FC.2030101@v.loewis.de>

> So, next question: what's the migration path to write portable code, then? Up
> to this change, we supported every Python version starting from 2.3, including
> 3.0alpha5, and it would be nice to continue to do so with 3.0 final.

I would split out the main body of the initialization into a separate
function, and then have both init<foo> and PyInit_<foo> call that
function.

Regards,
Martin

From martin at v.loewis.de  Fri Jun 13 01:47:31 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jun 2008 01:47:31 +0200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <g2qk10$glg$1@ger.gmane.org>
References: <484E001A.5000002@v.loewis.de>
	<g2qe71$mq$1@ger.gmane.org>	<g2qf42$3fu$1@ger.gmane.org>
	<g2qk10$glg$1@ger.gmane.org>
Message-ID: <4851B593.6030308@v.loewis.de>

> Just to mention it, I actually like the new API a lot, and we'll build upon
> that to provide better module cleanup support in later versions. That's
> something that we were missing for a while already.

Thanks. That actually needs proof in reality, as all core modules
currently only have the minimum compatibility with the API.

So if you could actually stress the API before the release, that would
be quite useful.

I found a few aspects to be difficult in porting some existing modules:
- PyModule_Create only creates the module, and doesn't yet put it into
  sys.modules. I find that more correct, as initialization might fail,
  in which case the regular cleanup should apply (i.e. decrefing the
  module). 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.
- the module object becomes the self parameter to module-level
  functions. This broke some modules who have module-level functions
  that also act as methods, and where checking for self being NULL
  to find out whether it's the function or the method. To fix them,
  test whether self is a module (or, vice versa, the expected type).

Regards,
Martin

From greg.ewing at canterbury.ac.nz  Fri Jun 13 03:57:24 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 13 Jun 2008 13:57:24 +1200
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <4851B593.6030308@v.loewis.de>
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>
Message-ID: <4851D404.90308@canterbury.ac.nz>

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.

-- 
Greg

From guido at python.org  Fri Jun 13 05:51:38 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Jun 2008 20:51:38 -0700
Subject: [Python-3000] [Python-3000-checkins] r64217 - in
	python/branches/py3k/Lib: bsddb/test/test_associate.py
	bsddb/test/test_join.py bsddb/test/test_lock.py
	bsddb/test/test_thread.py idlelib/rpc.py idlelib/run.py
	socketserver.py test/test_threadedtempfile.py thread
Message-ID: <ca471dc20806122051r6f7b0087lb0f0d6606793430c@mail.gmail.com>

It's water under the bridge now, but IMO it was too rash to *remove*
the old threading API from Py3k, and doubly rash to do so one day
before the beta release. Running up to a release (whether alpha, beta
or final) we should practice extra restraint, not rush to get things
in right before the deadline. Let's all be more careful the rest of
this release cycle! (I think it wasn't just Benjamin who raced to get
things in...)

--Guido

On Thu, Jun 12, 2008 at 7:00 PM, benjamin.peterson
<python-3000-checkins at python.org> wrote:
> Author: benjamin.peterson
> Date: Fri Jun 13 04:00:47 2008
> New Revision: 64217
>
> Log:
> fix more threading API related bugs
>
> Modified:
>   python/branches/py3k/Lib/bsddb/test/test_associate.py
>   python/branches/py3k/Lib/bsddb/test/test_join.py
>   python/branches/py3k/Lib/bsddb/test/test_lock.py
>   python/branches/py3k/Lib/bsddb/test/test_thread.py
>   python/branches/py3k/Lib/idlelib/rpc.py
>   python/branches/py3k/Lib/idlelib/run.py
>   python/branches/py3k/Lib/socketserver.py
>   python/branches/py3k/Lib/test/test_threadedtempfile.py
>   python/branches/py3k/Lib/threading.py
>
> Modified: python/branches/py3k/Lib/bsddb/test/test_associate.py
> ==============================================================================
> --- python/branches/py3k/Lib/bsddb/test/test_associate.py       (original)
> +++ python/branches/py3k/Lib/bsddb/test/test_associate.py       Fri Jun 13 04:00:47 2008
> @@ -9,7 +9,7 @@
>  from pprint import pprint
>
>  try:
> -    from threading import Thread, currentThread
> +    from threading import Thread, current_thread
>     have_threads = 1
>  except ImportError:
>     have_threads = 0
>
[etc.]

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

From g.brandl at gmx.net  Fri Jun 13 08:32:28 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 13 Jun 2008 08:32:28 +0200
Subject: [Python-3000] [Python-3000-checkins] r64217 - in
 python/branches/py3k/Lib: bsddb/test/test_associate.py
 bsddb/test/test_join.py bsddb/test/test_lock.py bsddb/test/test_thread.py
 idlelib/rpc.py idlelib/run.py socketserver.py test/test_threadedtempfile.py
 thread
In-Reply-To: <ca471dc20806122051r6f7b0087lb0f0d6606793430c@mail.gmail.com>
References: <ca471dc20806122051r6f7b0087lb0f0d6606793430c@mail.gmail.com>
Message-ID: <g2t4a2$3p7$1@ger.gmane.org>

Guido van Rossum schrieb:
> It's water under the bridge now, but IMO it was too rash to *remove*
> the old threading API from Py3k, and doubly rash to do so one day
> before the beta release. Running up to a release (whether alpha, beta
> or final) we should practice extra restraint, not rush to get things
> in right before the deadline. Let's all be more careful the rest of
> this release cycle! (I think it wasn't just Benjamin who raced to get
> things in...)

Also, for any method or module renaming, there is no way around a full
grep through the code base to really catch all uses of the old API.

It may be tedious, especially with common names, but such bugs really
must be avoided as they can easily be -- I still could find uses of
old-style threading names, even in the stdlib. (Fixed in r64222.)

Georg


From solipsis at pitrou.net  Fri Jun 13 09:52:43 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 13 Jun 2008 07:52:43 +0000 (UTC)
Subject: [Python-3000] Betas today - I hope
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>
	<4850FBFC.9070501@gmail.com> <g2s72u$2q5$1@ger.gmane.org>
Message-ID: <loom.20080613T075147-994@post.gmane.org>


Hi,

Georg Brandl <g.brandl <at> gmx.net> writes:
> 
> I would argue that the __enter__ and __exit__ behavior should be changed too.
> The reason for the current behavior is this:
> 
[...]
> 
> IOW, when "with" is compiled, the attributes are retrieved using bytecode.
> It wouldn't be hard to have a WITH_SETUP opcode (along with the already
> existing WITH_CLEANUP) that would make the bytecode read like:

It's not really a change in behaviour, just an optimization, isn't it?

Antoine.



From ncoghlan at gmail.com  Fri Jun 13 10:56:01 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 13 Jun 2008 18:56:01 +1000
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <g2s72u$2q5$1@ger.gmane.org>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>	<4850FBFC.9070501@gmail.com>
	<g2s72u$2q5$1@ger.gmane.org>
Message-ID: <48523621.6050604@gmail.com>

Georg Brandl wrote:
> Nick Coghlan schrieb:
> 
>> 2. Method lookup MAY bypass __getattribute__, shadowing the attribute 
>> in the instance dictionary MAY have ill effects. (slots such as 
>> __enter__ and __exit__ that are looked up via normal attribute lookup 
>> in CPython will fit into this category)
> 
> I would argue that the __enter__ and __exit__ behavior should be changed 
> too.
> The reason for the current behavior is this:
> 
>   2           0 LOAD_GLOBAL              0 (a)
>               3 DUP_TOP
>               4 LOAD_ATTR                1 (__exit__)
>               7 STORE_FAST               0 (_[1])
>              10 LOAD_ATTR                2 (__enter__)
>              13 CALL_FUNCTION            0
>              16 STORE_FAST               1 (_[2])
>              19 SETUP_FINALLY           18 (to 40)
> 
> IOW, when "with" is compiled, the attributes are retrieved using bytecode.
> It wouldn't be hard to have a WITH_SETUP opcode (along with the already
> existing WITH_CLEANUP) that would make the bytecode read like:
> 
>   2           0 LOAD_GLOBAL              0 (a)
>               3 WITH_SETUP               0 (_[1])
>               6 STORE_FAST               1 (_[2])
>               9 SETUP_FINALLY           18 (to 40)

No argument here - the PEP 343 implementation is the way it is mainly 
because it involved the least messing around with the 
performance-sensitive ceval loop.

That said, the with statement implementation is already a bit different 
in 2.6/3.0 (it moves things around on the stack so it can avoid the 
STORE_FAST/LOAD_FAST/DELETE_FAST operations):

def f():
   with a:
     pass

Python 2.5 disassembly:
  2           0 LOAD_GLOBAL              0 (a)
               3 DUP_TOP
               4 LOAD_ATTR                1 (__exit__)
               7 STORE_FAST               0 (_[1])
              10 LOAD_ATTR                2 (__enter__)
              13 CALL_FUNCTION            0
              16 POP_TOP
              17 SETUP_FINALLY            4 (to 24)
              20 POP_BLOCK
              21 LOAD_CONST               0 (None)
         >>   24 LOAD_FAST                0 (_[1])
              27 DELETE_FAST              0 (_[1])
              30 WITH_CLEANUP
              31 END_FINALLY

Python 2.6 disassembly:
   2           0 LOAD_GLOBAL              0 (a)
               3 DUP_TOP
               4 LOAD_ATTR                1 (__exit__)
               7 ROT_TWO
               8 LOAD_ATTR                2 (__enter__)
              11 CALL_FUNCTION            0
              14 POP_TOP
              15 SETUP_FINALLY            4 (to 22)
              18 POP_BLOCK
              19 LOAD_CONST               0 (None)
         >>   22 WITH_CLEANUP
              23 END_FINALLY

Cheers,
Nick.

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

From walter at livinglogic.de  Fri Jun 13 11:32:21 2008
From: walter at livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Fri, 13 Jun 2008 11:32:21 +0200
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <48514428.7040001@egenix.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>	<484FEC2C.6070409@livinglogic.de>	<485003F8.40803@egenix.com>
	<485139EA.1000502@livinglogic.de> <48514428.7040001@egenix.com>
Message-ID: <48523EA5.2070407@livinglogic.de>

M.-A. Lemburg wrote:
> On 2008-06-12 16:59, Walter D?rwald wrote:
>> M.-A. Lemburg wrote:
>>> .transform() and .untransform() use the codecs to apply same-type
>>> conversions. They do apply type checks to make sure that the
>>> codec does indeed return the same type.
>>>
>>> E.g. text.transform('xml-escape') or data.transform('base64').
>>
>> So what would a base64 codec do with the errors argument?
> 
> It could use it to e.g. try to recover as much data as possible
> from broken input data.
> 
> Currently (in Py2.x), it raises an exception if you pass in anything
> but "strict".
> 
>>>> I think for transformations we don't need the full codec machinery:
>>>  > ...
>>>
>>> No need to invent another wheel :-) The codecs already exist for
>>> Py2.x and can be used by the .encode()/.decode() methods in Py2.x
>>> (where no type checks occur).
>>
>> By using a new API we could get rid of old warts. For example: Why 
>> does the stateless encoder/decoder return how many input 
>> characters/bytes it has consumed? It must consume *all* bytes anyway!
> 
> No, it doesn't and that's the point in having those return values :-)
> 
> Even though the encoder/decoders are stateless, that doesn't mean
> they have to consume all input data. The caller is responsible to
> make sure that all input data was in fact consumed.
> 
> You could for example have a decoder that stops decoding after
> having seen a block end indicator, e.g. a base64 line end or
> XML closing element.

So how should the UTF-8 decoder know that it has to stop at a closing 
XML element?

> Just because all codecs that ship with Python always try to decode
> the complete input doesn't mean that the feature isn't being used.

I know of no other code that does. Do you have an example for this use.

> The interface was designed to allow for the above situations.

Then could we at least have a new codec method that does:

def statelesencode(self, input):
    (output, consumed) = self.encode(input)
    assert len(input) == consumed
    return output

Servus,
    Walter


From solipsis at pitrou.net  Fri Jun 13 11:58:19 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 13 Jun 2008 09:58:19 +0000 (UTC)
Subject: [Python-3000] Betas today - I hope
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>	<4850FBFC.9070501@gmail.com>
	<g2s72u$2q5$1@ger.gmane.org> <48523621.6050604@gmail.com>
Message-ID: <loom.20080613T094909-455@post.gmane.org>

Nick Coghlan <ncoghlan <at> gmail.com> writes:
> That said, the with statement implementation is already a bit different 
> in 2.6/3.0 (it moves things around on the stack so it can avoid the 
> STORE_FAST/LOAD_FAST/DELETE_FAST operations):

Hmm, check again with the current 3.0 - it has changed back to storing
__exit__ in a temporary variable. That's because "finally" blocks
have gotten more complex semantics, and it is too quirky to
try to find out the stack level where we stored __exit__.

cheers

Antoine.



From mal at egenix.com  Fri Jun 13 12:14:49 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 13 Jun 2008 12:14:49 +0200
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <48523EA5.2070407@livinglogic.de>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>	<484FEC2C.6070409@livinglogic.de>	<485003F8.40803@egenix.com>	<485139EA.1000502@livinglogic.de>
	<48514428.7040001@egenix.com> <48523EA5.2070407@livinglogic.de>
Message-ID: <48524899.2030609@egenix.com>

On 2008-06-13 11:32, Walter D?rwald wrote:
> M.-A. Lemburg wrote:
>> On 2008-06-12 16:59, Walter D?rwald wrote:
>>> M.-A. Lemburg wrote:
>>>> .transform() and .untransform() use the codecs to apply same-type
>>>> conversions. They do apply type checks to make sure that the
>>>> codec does indeed return the same type.
>>>>
>>>> E.g. text.transform('xml-escape') or data.transform('base64').
>>>
>>> So what would a base64 codec do with the errors argument?
>>
>> It could use it to e.g. try to recover as much data as possible
>> from broken input data.
>>
>> Currently (in Py2.x), it raises an exception if you pass in anything
>> but "strict".
>>
>>>>> I think for transformations we don't need the full codec machinery:
>>>>  > ...
>>>>
>>>> No need to invent another wheel :-) The codecs already exist for
>>>> Py2.x and can be used by the .encode()/.decode() methods in Py2.x
>>>> (where no type checks occur).
>>>
>>> By using a new API we could get rid of old warts. For example: Why 
>>> does the stateless encoder/decoder return how many input 
>>> characters/bytes it has consumed? It must consume *all* bytes anyway!
>>
>> No, it doesn't and that's the point in having those return values :-)
>>
>> Even though the encoder/decoders are stateless, that doesn't mean
>> they have to consume all input data. The caller is responsible to
>> make sure that all input data was in fact consumed.
>>
>> You could for example have a decoder that stops decoding after
>> having seen a block end indicator, e.g. a base64 line end or
>> XML closing element.
> 
> So how should the UTF-8 decoder know that it has to stop at a closing 
> XML element?

The UTF-8 decoder doesn't support this, but you could write a codec
that applies this kind of detection, e.g. to not try to decode
partial UTF-8 byte sequences at the end of input, which would then
result in error.

>> Just because all codecs that ship with Python always try to decode
>> the complete input doesn't mean that the feature isn't being used.
> 
> I know of no other code that does. Do you have an example for this use.

I already gave you a few examples.

>> The interface was designed to allow for the above situations.
> 
> Then could we at least have a new codec method that does:
> 
> def statelesencode(self, input):
>    (output, consumed) = self.encode(input)
>    assert len(input) == consumed
>    return output

You mean as method to the Codec class ?

Sure, we could do that, but please use a different name,
e.g. .encodeall() and .decodeall() - .encode() and .decode()
are already stateles (and so would the new methods be), so
"stateless" isn't all that meaningful in this context.

We could also add such a check to the PyCodec_Encode() and _Decode()
functions. They currently do not apply the above check.

In Python, those two functions are exposed as codecs.encode()
and codecs.decode().

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 13 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/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            23 days to go

:::: 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 steve at holdenweb.com  Fri Jun 13 12:53:14 2008
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 13 Jun 2008 06:53:14 -0400
Subject: [Python-3000] [Python-3000-checkins] r64217 - in
 python/branches/py3k/Lib: bsddb/test/test_associate.py
 bsddb/test/test_join.py bsddb/test/test_lock.py bsddb/test/test_thread.py
 idlelib/rpc.py idlelib/run.py socketserver.py test/test_threadedtempfile.py
 thread
In-Reply-To: <ca471dc20806122051r6f7b0087lb0f0d6606793430c@mail.gmail.com>
References: <ca471dc20806122051r6f7b0087lb0f0d6606793430c@mail.gmail.com>
Message-ID: <4852519A.6070506@holdenweb.com>

Guido van Rossum wrote:
> It's water under the bridge now, but IMO it was too rash to *remove*
> the old threading API from Py3k, and doubly rash to do so one day
> before the beta release. Running up to a release (whether alpha, beta
> or final) we should practice extra restraint, not rush to get things
> in right before the deadline. Let's all be more careful the rest of
> this release cycle! (I think it wasn't just Benjamin who raced to get
> things in...)

Well, it wouldn't be "adding a new feature" to reinstate the old API for 
beta two, would it, as long as we retain the new one too? It does seem 
that change was a little precipitate.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From fuzzyman at voidspace.org.uk  Thu Jun 12 16:43:02 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 12 Jun 2008 14:43:02 -0000
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <ca471dc20806120655s60e378bj8850b37c676b313b@mail.gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>	<4850FBFC.9070501@gmail.com>
	<ca471dc20806120655s60e378bj8850b37c676b313b@mail.gmail.com>
Message-ID: <48EE15E7.7020701@voidspace.org.uk>

Guido van Rossum wrote:
> [Barry]
>   
>>>> http://bugs.python.org/issue643841
>>>>         
>
> [Guido]
>   
>>> I've added a comment. Let me know if anything I said is unclear.
>>>       
>
> On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>   
>> The bugtracker seems to be offline atm - I'll reply there once I can get to
>> it again (as well as switching this issue back to being a documentation
>> one).
>>
>> I don't think we're going to see a major clamor for a value-based delegation
>> mixin in the standard library until people using classic classes for
>> value-based delegation start making serious attempts to port to Py3k (where
>> that approach is no longer available). At the moment, such classes only need
>> to care about the methods they want to fiddle with, leaving everything else
>> to __getattr__ based delegation.
>>     
>
> Whether they'll care about this issue of course depends on whether
> they need overloaded operators and other special delegations to be
> delegated transparently. We'll have to see how important this is.
> New-style classes have been around and recommended for a long time --
> why haven't people pushed for a proxy class before?
>
>   

It's only in Python 3 that old style classes are going away fully, so up 
until now you could at least use a classic class to do the proxying.

I've written my own proxy classes before that look very similar to this, 
and there are other proxy classes around that do the same (I thought one 
was by Phillip J Eby but can't find a reference easily). The last one I 
wrote was to proxy CPython objects from IronPython via Python.NET...

I would prefer it if the proxy class wrapped the return values of 
inplace operations.

Michael Foord

>> I've pushed as hard as I'm personally willing to for this without convincing
>> anyone else that it's worth doing,
>>     
>
> What does *it* refer to? Changing the behavior, or adding a proxy
> class to the stdlib? I'm -1000 on the former, but only -0 on the
> latter -- as I wrote in the tracker, I just don't want to see an
> unproven proxy class (and I don't like the module name).
>
>   
>> so I'll start working on a documentation
>> patch for the language reference instead which explicitly splits the special
>> methods into the following categories:
>>     
>
> Thanks for doing this, it is needed regardless!
>
>   
>> 1. Method lookup MUST bypass __getattribute__, shadowing the attribute in
>> the instance dictionary MUST NOT have any ill effects. (All tp_* C-level
>> slots and slots looked up via _PyType_Lookup will fit into this category)
>>     
>
> Watch out: I think the term "method lookup" may be confusing here.
> Certainly when the user writes x.__foo__(), the instance dict *is*
> consulted. It is only on *implied* lookups (e.g. x[y] or x+y) where
> the instance dict is bypassed.
>
>   
>> 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in the
>> instance dictionary MAY have ill effects. (slots such as __enter__ and
>> __exit__ that are looked up via normal attribute lookup in CPython will fit
>> into this category)
>>     
>
> Why even have a  MAY category? Are you expecting these to become tp_
> slots at some point?
>
>   
>> 3. Technically a subcategory of group 1, these are special methods which can
>> affect the interpreter's behaviour by their mere definition on a type. (The
>> __get__, __set__ and __delete__ descriptor protocol methods fall into this
>> category)
>>     
>
> I don't follow why this is relevant. This is a different, AFAIK
> orthogonal issue, used in many places: *if* an object used in a
> certain context has a specific attribute, *then* that attribute is
> used, *otherwise* a default action is taken. Applies to __repr__ just
> as much. These belong in category 1 if and only if the lookup bypasses
> the instance dict.
>
>   


From fuzzyman at voidspace.org.uk  Fri Jun 13 12:02:53 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 13 Jun 2008 11:02:53 +0100
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <ca471dc20806120655s60e378bj8850b37c676b313b@mail.gmail.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>	<4850FBFC.9070501@gmail.com>
	<ca471dc20806120655s60e378bj8850b37c676b313b@mail.gmail.com>
Message-ID: <485245CD.9000602@voidspace.org.uk>

Guido van Rossum wrote:
> [Barry]
>   
>>>> http://bugs.python.org/issue643841
>>>>         
>
> [Guido]
>   
>>> I've added a comment. Let me know if anything I said is unclear.
>>>       
>
> On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>   
>> The bugtracker seems to be offline atm - I'll reply there once I can get to
>> it again (as well as switching this issue back to being a documentation
>> one).
>>
>> I don't think we're going to see a major clamor for a value-based delegation
>> mixin in the standard library until people using classic classes for
>> value-based delegation start making serious attempts to port to Py3k (where
>> that approach is no longer available). At the moment, such classes only need
>> to care about the methods they want to fiddle with, leaving everything else
>> to __getattr__ based delegation.
>>     
>
> Whether they'll care about this issue of course depends on whether
> they need overloaded operators and other special delegations to be
> delegated transparently. We'll have to see how important this is.
> New-style classes have been around and recommended for a long time --
> why haven't people pushed for a proxy class before?
>
>   

It's only in Python 3 that old style classes are going away fully, so up
until now you could at least use a classic class to do the proxying.

I've written my own proxy classes before that look very similar to this,
and there are other proxy classes around that do the same (I thought one
was by Phillip J Eby but can't find a reference easily). The last one I
wrote was to proxy CPython objects from IronPython via Python.NET...

I would prefer it if the proxy class wrapped the return values of
inplace operations.

Michael Foord

>> I've pushed as hard as I'm personally willing to for this without convincing
>> anyone else that it's worth doing,
>>     
>
> What does *it* refer to? Changing the behavior, or adding a proxy
> class to the stdlib? I'm -1000 on the former, but only -0 on the
> latter -- as I wrote in the tracker, I just don't want to see an
> unproven proxy class (and I don't like the module name).
>
>   
>> so I'll start working on a documentation
>> patch for the language reference instead which explicitly splits the special
>> methods into the following categories:
>>     
>
> Thanks for doing this, it is needed regardless!
>
>   
>> 1. Method lookup MUST bypass __getattribute__, shadowing the attribute in
>> the instance dictionary MUST NOT have any ill effects. (All tp_* C-level
>> slots and slots looked up via _PyType_Lookup will fit into this category)
>>     
>
> Watch out: I think the term "method lookup" may be confusing here.
> Certainly when the user writes x.__foo__(), the instance dict *is*
> consulted. It is only on *implied* lookups (e.g. x[y] or x+y) where
> the instance dict is bypassed.
>
>   
>> 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in the
>> instance dictionary MAY have ill effects. (slots such as __enter__ and
>> __exit__ that are looked up via normal attribute lookup in CPython will fit
>> into this category)
>>     
>
> Why even have a  MAY category? Are you expecting these to become tp_
> slots at some point?
>
>   
>> 3. Technically a subcategory of group 1, these are special methods which can
>> affect the interpreter's behaviour by their mere definition on a type. (The
>> __get__, __set__ and __delete__ descriptor protocol methods fall into this
>> category)
>>     
>
> I don't follow why this is relevant. This is a different, AFAIK
> orthogonal issue, used in many places: *if* an object used in a
> certain context has a specific attribute, *then* that attribute is
> used, *otherwise* a default action is taken. Applies to __repr__ just
> as much. These belong in category 1 if and only if the lookup bypasses
> the instance dict.
>
>   



From orivej at yandex.ru  Tue Jun 10 06:50:05 2008
From: orivej at yandex.ru (Georgij Kondratjev)
Date: Tue, 10 Jun 2008 08:50:05 +0400
Subject: [Python-3000] PEP 3121 implemented
In-Reply-To: <484E001A.5000002@v.loewis.de>
References: <484E001A.5000002@v.loewis.de>
Message-ID: <200806100850.05338.orivej@yandex.ru>

On Tuesday 10 June 2008 08:16:26 Martin v. L?wis wrote:
> I just finished a PEP 3121 implementation, uploaded at
>
> http://codereview.appspot.com/1962

In the patch to 'Python/import.c' there is a comment line '
+   Modules which do support multiple multiple initialization set
+   their m_size field to a non-negative number (indicating the size
+   of the module-specific state).'
with twice repeated 'multiple'. Is not this a mistace?

From steve at holdenweb.com  Fri Jun 13 12:53:14 2008
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 13 Jun 2008 06:53:14 -0400
Subject: [Python-3000] [Python-3000-checkins] r64217 - in
 python/branches/py3k/Lib: bsddb/test/test_associate.py
 bsddb/test/test_join.py bsddb/test/test_lock.py bsddb/test/test_thread.py
 idlelib/rpc.py idlelib/run.py socketserver.py test/test_threadedtempfile.py
 thread
In-Reply-To: <ca471dc20806122051r6f7b0087lb0f0d6606793430c@mail.gmail.com>
References: <ca471dc20806122051r6f7b0087lb0f0d6606793430c@mail.gmail.com>
Message-ID: <4852519A.6070506@holdenweb.com>

Guido van Rossum wrote:
> It's water under the bridge now, but IMO it was too rash to *remove*
> the old threading API from Py3k, and doubly rash to do so one day
> before the beta release. Running up to a release (whether alpha, beta
> or final) we should practice extra restraint, not rush to get things
> in right before the deadline. Let's all be more careful the rest of
> this release cycle! (I think it wasn't just Benjamin who raced to get
> things in...)

Well, it wouldn't be "adding a new feature" to reinstate the old API for 
beta two, would it, as long as we retain the new one too? It does seem 
that change was a little precipitate.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/



From ncoghlan at gmail.com  Fri Jun 13 15:07:47 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 13 Jun 2008 23:07:47 +1000
Subject: [Python-3000] [Python-3000-checkins] r64217 - in
 python/branches/py3k/Lib: bsddb/test/test_associate.py
 bsddb/test/test_join.py bsddb/test/test_lock.py bsddb/test/test_thread.py
 idlelib/rpc.py idlelib/run.py socketserver.py test/test_threadedtempfile.py
 thread
In-Reply-To: <4852519A.6070506@holdenweb.com>
References: <ca471dc20806122051r6f7b0087lb0f0d6606793430c@mail.gmail.com>
	<4852519A.6070506@holdenweb.com>
Message-ID: <48527123.9010802@gmail.com>

Steve Holden wrote:
> Guido van Rossum wrote:
>> It's water under the bridge now, but IMO it was too rash to *remove*
>> the old threading API from Py3k, and doubly rash to do so one day
>> before the beta release. Running up to a release (whether alpha, beta
>> or final) we should practice extra restraint, not rush to get things
>> in right before the deadline. Let's all be more careful the rest of
>> this release cycle! (I think it wasn't just Benjamin who raced to get
>> things in...)
> 
> Well, it wouldn't be "adding a new feature" to reinstate the old API for 
> beta two, would it, as long as we retain the new one too? It does seem 
> that change was a little precipitate.

Although if we weren't actually planning on removing the old API in 3.0, 
I'm a little confused as to why we were adding Py3k warnings to it in 2.6...

Cheers,
Nick.

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

From g.brandl at gmx.net  Fri Jun 13 15:18:24 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 13 Jun 2008 15:18:24 +0200
Subject: [Python-3000] Betas today - I hope
In-Reply-To: <loom.20080613T075147-994@post.gmane.org>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<ca471dc20806111002w300abfd6y47d6a41148bd56a@mail.gmail.com>	<4850FBFC.9070501@gmail.com>
	<g2s72u$2q5$1@ger.gmane.org>
	<loom.20080613T075147-994@post.gmane.org>
Message-ID: <g2ts36$gon$1@ger.gmane.org>

Antoine Pitrou schrieb:
> Hi,
> 
> Georg Brandl <g.brandl <at> gmx.net> writes:
>> 
>> I would argue that the __enter__ and __exit__ behavior should be changed too.
>> The reason for the current behavior is this:
>> 
> [...]
>> 
>> IOW, when "with" is compiled, the attributes are retrieved using bytecode.
>> It wouldn't be hard to have a WITH_SETUP opcode (along with the already
>> existing WITH_CLEANUP) that would make the bytecode read like:
> 
> It's not really a change in behaviour, just an optimization, isn't it?

It is a change, since the new opcode would look up __enter__ and __exit__
via _PyType_Lookup instead of using PyObject_GetAttr like LOAD_ATTR does.

Georg


From walter at livinglogic.de  Fri Jun 13 15:26:47 2008
From: walter at livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Fri, 13 Jun 2008 15:26:47 +0200
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <48524899.2030609@egenix.com>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>	<484FEC2C.6070409@livinglogic.de>	<485003F8.40803@egenix.com>	<485139EA.1000502@livinglogic.de>
	<48514428.7040001@egenix.com> <48523EA5.2070407@livinglogic.de>
	<48524899.2030609@egenix.com>
Message-ID: <48527597.4090206@livinglogic.de>

M.-A. Lemburg wrote:
> On 2008-06-13 11:32, Walter D?rwald wrote:
>> M.-A. Lemburg wrote:
>>> On 2008-06-12 16:59, Walter D?rwald wrote:
>>>> M.-A. Lemburg wrote:
>>>>> .transform() and .untransform() use the codecs to apply same-type
>>>>> conversions. They do apply type checks to make sure that the
>>>>> codec does indeed return the same type.
>>>>>
>>>>> E.g. text.transform('xml-escape') or data.transform('base64').
>>>>
>>>> So what would a base64 codec do with the errors argument?
>>>
>>> It could use it to e.g. try to recover as much data as possible
>>> from broken input data.
>>>
>>> Currently (in Py2.x), it raises an exception if you pass in anything
>>> but "strict".
>>>
>>>>>> I think for transformations we don't need the full codec machinery:
>>>>>  > ...
>>>>>
>>>>> No need to invent another wheel :-) The codecs already exist for
>>>>> Py2.x and can be used by the .encode()/.decode() methods in Py2.x
>>>>> (where no type checks occur).
>>>>
>>>> By using a new API we could get rid of old warts. For example: Why 
>>>> does the stateless encoder/decoder return how many input 
>>>> characters/bytes it has consumed? It must consume *all* bytes anyway!
>>>
>>> No, it doesn't and that's the point in having those return values :-)
>>>
>>> Even though the encoder/decoders are stateless, that doesn't mean
>>> they have to consume all input data. The caller is responsible to
>>> make sure that all input data was in fact consumed.
>>>
>>> You could for example have a decoder that stops decoding after
>>> having seen a block end indicator, e.g. a base64 line end or
>>> XML closing element.
>>
>> So how should the UTF-8 decoder know that it has to stop at a closing 
>> XML element?
> 
> The UTF-8 decoder doesn't support this, but you could write a codec
> that applies this kind of detection, e.g. to not try to decode
> partial UTF-8 byte sequences at the end of input, which would then
> result in error.
> 
>>> Just because all codecs that ship with Python always try to decode
>>> the complete input doesn't mean that the feature isn't being used.
>>
>> I know of no other code that does. Do you have an example for this use.
> 
> I already gave you a few examples.

Maybe I was unclear, I meant real world examples, not hypothetical ones.

>>> The interface was designed to allow for the above situations.
>>
>> Then could we at least have a new codec method that does:
>>
>> def statelesencode(self, input):
>>    (output, consumed) = self.encode(input)
>>    assert len(input) == consumed
>>    return output
> 
> You mean as method to the Codec class ?

No, I meant as a method for the CodecInfo clas.

> Sure, we could do that, but please use a different name,
> e.g. .encodeall() and .decodeall() - .encode() and .decode()
> are already stateles (and so would the new methods be), so
> "stateless" isn't all that meaningful in this context.

I like the names encodeall/decodeall!

> We could also add such a check to the PyCodec_Encode() and _Decode()
> functions. They currently do not apply the above check.
> 
> In Python, those two functions are exposed as codecs.encode()
> and codecs.decode().

This change will probably have to wait for the 2.7 cycle.

Servus,
    Walter

From barry at python.org  Fri Jun 13 15:47:40 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 13 Jun 2008 09:47:40 -0400
Subject: [Python-3000] First betas (perhaps) on June 18
Message-ID: <26D65059-EDD6-4C90-98FE-111B5135E725@python.org>

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

It's unfortunate that I was not able to release the first betas on  
Wednesday.  The primary reason was that none of the 3.0 buildbots were  
green.

My proposal is this: I will spin another release this coming  
Wednesday, June 18.  If we can get both the 2.6 and 3.0 buildbots  
green by then, and close out all remaining release critical bugs, then  
Wednesday's release will be beta 1.  In that case, I will update PEP  
361 and push the entire schedule back by 2 weeks to account for our  
slippage.

If we can't get these releases stable by then, Wednesday's release  
will be alpha and I will make the July 2 release the first beta,  
updating and pushing back the PEP 361 schedule accordingly.

Thanks for all your help in getting 3.0 stable!
- -Barry

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

iQCVAwUBSFJ6fXEjvBPtnXfVAQJekgP/XzGR0h6Kcgwe/eo/hlAP2RJiEBny7iIT
avSkq5sDD4YiUHeSSVy/8A5rahjR3Bsrzgh0MSePrf8coUHz3N+OCGsJK07BVJIT
9wan/OXTkpsrqa2xQgrokk0PqCE80S2Lp6+P5jMW06tujx3fFn+NJNDjaNUOKPUc
nlfjFpdwYxc=
=Nwmx
-----END PGP SIGNATURE-----

From facundobatista at gmail.com  Fri Jun 13 15:54:08 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 13 Jun 2008 10:54:08 -0300
Subject: [Python-3000] First betas (perhaps) on June 18
In-Reply-To: <26D65059-EDD6-4C90-98FE-111B5135E725@python.org>
References: <26D65059-EDD6-4C90-98FE-111B5135E725@python.org>
Message-ID: <e04bdf310806130654o109c68e9l2e42e4fd899e1901@mail.gmail.com>

2008/6/13 Barry Warsaw <barry at python.org>:

> My proposal is this: I will spin another release this coming Wednesday, June
> 18.  If we can get both the 2.6 and 3.0 buildbots green by then, and close
> out all remaining release critical bugs, then Wednesday's release will be
> beta 1.  In that case, I will update PEP 361 and push the entire schedule
> back by 2 weeks to account for our slippage.

Next weekend, 21 and 22, it will be the Python Bug days.

Maybe it's worth to delay the betas one week to include this work?

Regards,

-- 
. Facundo

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

From guido at python.org  Fri Jun 13 16:20:09 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 13 Jun 2008 07:20:09 -0700
Subject: [Python-3000] [Python-Dev]  First betas (perhaps) on June 18
In-Reply-To: <e04bdf310806130654o109c68e9l2e42e4fd899e1901@mail.gmail.com>
References: <26D65059-EDD6-4C90-98FE-111B5135E725@python.org>
	<e04bdf310806130654o109c68e9l2e42e4fd899e1901@mail.gmail.com>
Message-ID: <ca471dc20806130720p6f0ec3d0y9d0a5f4560347d55@mail.gmail.com>

On Fri, Jun 13, 2008 at 6:54 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> 2008/6/13 Barry Warsaw <barry at python.org>:
>
>> My proposal is this: I will spin another release this coming Wednesday, June
>> 18.  If we can get both the 2.6 and 3.0 buildbots green by then, and close
>> out all remaining release critical bugs, then Wednesday's release will be
>> beta 1.  In that case, I will update PEP 361 and push the entire schedule
>> back by 2 weeks to account for our slippage.
>
> Next weekend, 21 and 22, it will be the Python Bug days.
>
> Maybe it's worth to delay the betas one week to include this work?

You mean one more week? (Barry's already delaying them one week.)

I'm fine with whatever delay Barry approves, but I want EVERYONE to
stick to the purpose of the delay: get the buildbots green and close
out release critical bugs. This means no new last-minute features or
big refactorings (unless there's really no more conservative way to
fix a critical bug). It also means try to get at least one other
person to review every change, no matter how small (or big!) *before*
submitting. It also means run the tests before submitting.

On the specific purpose of delaying for the bug day, I'm hesitant --
bug days tend to cause a great deal of commits of code by relatively
new developers, which is counter to our purpose of stability. I would
almost say it's better for the bug day to fall right after the beta.
That also has the advantage that the bug day can focus on new bugs in
the beta, and squash them right away...

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

From g.brandl at gmx.net  Fri Jun 13 16:27:17 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 13 Jun 2008 16:27:17 +0200
Subject: [Python-3000] [Python-Dev]  First betas (perhaps) on June 18
In-Reply-To: <ca471dc20806130720p6f0ec3d0y9d0a5f4560347d55@mail.gmail.com>
References: <26D65059-EDD6-4C90-98FE-111B5135E725@python.org>	<e04bdf310806130654o109c68e9l2e42e4fd899e1901@mail.gmail.com>
	<ca471dc20806130720p6f0ec3d0y9d0a5f4560347d55@mail.gmail.com>
Message-ID: <g2u04a$v8$1@ger.gmane.org>

Guido van Rossum schrieb:
> On Fri, Jun 13, 2008 at 6:54 AM, Facundo Batista
> <facundobatista at gmail.com> wrote:
>> 2008/6/13 Barry Warsaw <barry at python.org>:
>>
>>> My proposal is this: I will spin another release this coming Wednesday, June
>>> 18.  If we can get both the 2.6 and 3.0 buildbots green by then, and close
>>> out all remaining release critical bugs, then Wednesday's release will be
>>> beta 1.  In that case, I will update PEP 361 and push the entire schedule
>>> back by 2 weeks to account for our slippage.
>>
>> Next weekend, 21 and 22, it will be the Python Bug days.
>>
>> Maybe it's worth to delay the betas one week to include this work?
> 
> You mean one more week? (Barry's already delaying them one week.)
> 
> I'm fine with whatever delay Barry approves, but I want EVERYONE to
> stick to the purpose of the delay: get the buildbots green and close
> out release critical bugs. This means no new last-minute features or
> big refactorings (unless there's really no more conservative way to
> fix a critical bug). It also means try to get at least one other
> person to review every change, no matter how small (or big!) *before*
> submitting. It also means run the tests before submitting.

That is a new policy, isn't it?

> On the specific purpose of delaying for the bug day, I'm hesitant --
> bug days tend to cause a great deal of commits of code by relatively
> new developers, which is counter to our purpose of stability. I would
> almost say it's better for the bug day to fall right after the beta.
> That also has the advantage that the bug day can focus on new bugs in
> the beta, and squash them right away...

+1.

Georg


From guido at python.org  Fri Jun 13 16:33:37 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 13 Jun 2008 07:33:37 -0700
Subject: [Python-3000] [Python-Dev] First betas (perhaps) on June 18
In-Reply-To: <g2u04a$v8$1@ger.gmane.org>
References: <26D65059-EDD6-4C90-98FE-111B5135E725@python.org>
	<e04bdf310806130654o109c68e9l2e42e4fd899e1901@mail.gmail.com>
	<ca471dc20806130720p6f0ec3d0y9d0a5f4560347d55@mail.gmail.com>
	<g2u04a$v8$1@ger.gmane.org>
Message-ID: <ca471dc20806130733g478181den1d0aa99f97b8b9ac@mail.gmail.com>

On Fri, Jun 13, 2008 at 7:27 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> Guido van Rossum schrieb:
>>
>> On Fri, Jun 13, 2008 at 6:54 AM, Facundo Batista
>> <facundobatista at gmail.com> wrote:
>>>
>>> 2008/6/13 Barry Warsaw <barry at python.org>:
>>>
>>>> My proposal is this: I will spin another release this coming Wednesday,
>>>> June
>>>> 18.  If we can get both the 2.6 and 3.0 buildbots green by then, and
>>>> close
>>>> out all remaining release critical bugs, then Wednesday's release will
>>>> be
>>>> beta 1.  In that case, I will update PEP 361 and push the entire
>>>> schedule
>>>> back by 2 weeks to account for our slippage.
>>>
>>> Next weekend, 21 and 22, it will be the Python Bug days.
>>>
>>> Maybe it's worth to delay the betas one week to include this work?
>>
>> You mean one more week? (Barry's already delaying them one week.)
>>
>> I'm fine with whatever delay Barry approves, but I want EVERYONE to
>> stick to the purpose of the delay: get the buildbots green and close
>> out release critical bugs. This means no new last-minute features or
>> big refactorings (unless there's really no more conservative way to
>> fix a critical bug). It also means try to get at least one other
>> person to review every change, no matter how small (or big!) *before*
>> submitting. It also means run the tests before submitting.
>
> That is a new policy, isn't it?

Yes -- one that seems appropriate during a beta release period (i.e.
until 2.6 and 3.0 final are out).

>> On the specific purpose of delaying for the bug day, I'm hesitant --
>> bug days tend to cause a great deal of commits of code by relatively
>> new developers, which is counter to our purpose of stability. I would
>> almost say it's better for the bug day to fall right after the beta.
>> That also has the advantage that the bug day can focus on new bugs in
>> the beta, and squash them right away...
>
> +1.

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

From musiccomposition at gmail.com  Fri Jun 13 16:35:25 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 13 Jun 2008 09:35:25 -0500
Subject: [Python-3000] [Python-Dev] First betas (perhaps) on June 18
In-Reply-To: <ca471dc20806130720p6f0ec3d0y9d0a5f4560347d55@mail.gmail.com>
References: <26D65059-EDD6-4C90-98FE-111B5135E725@python.org>
	<e04bdf310806130654o109c68e9l2e42e4fd899e1901@mail.gmail.com>
	<ca471dc20806130720p6f0ec3d0y9d0a5f4560347d55@mail.gmail.com>
Message-ID: <1afaf6160806130735v40252796laf478e9e99f45148@mail.gmail.com>

On Fri, Jun 13, 2008 at 9:20 AM, Guido van Rossum <guido at python.org> wrote:
>
> I'm fine with whatever delay Barry approves, but I want EVERYONE to
> stick to the purpose of the delay: get the buildbots green and close
> out release critical bugs. This means no new last-minute features or
> big refactorings (unless there's really no more conservative way to
> fix a critical bug). It also means try to get at least one other
> person to review every change, no matter how small (or big!) *before*
> submitting. It also means run the tests before submitting.

I will quite happily abide by this; it's already causing more than
enough stress over here.



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

From gustavo at niemeyer.net  Fri Jun 13 18:56:09 2008
From: gustavo at niemeyer.net (Gustavo Niemeyer)
Date: Fri, 13 Jun 2008 17:56:09 +0100
Subject: [Python-3000] PyObject_REPR() macro
Message-ID: <4852A6A9.7010005@niemeyer.net>


Hello guys,

   /* Helper for passing objects to printf and the like */
   #define PyObject_REPR(obj) PyUnicode_AsString(PyObject_Repr(obj))

3k might be a good moment to kill that leak-suggesting macro.

-- 
Gustavo Niemeyer
http://niemeyer.net

From walter at livinglogic.de  Fri Jun 13 19:20:03 2008
From: walter at livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Fri, 13 Jun 2008 19:20:03 +0200
Subject: [Python-3000] [Python-Dev]  Betas today - I hope
In-Reply-To: <48527597.4090206@livinglogic.de>
References: <8D250561-B5D9-4943-AFE3-06EE872E6E11@python.org>	<484FE1E9.2080904@egenix.com>	<484FEC2C.6070409@livinglogic.de>	<485003F8.40803@egenix.com>	<485139EA.1000502@livinglogic.de>	<48514428.7040001@egenix.com>
	<48523EA5.2070407@livinglogic.de>	<48524899.2030609@egenix.com>
	<48527597.4090206@livinglogic.de>
Message-ID: <4852AC43.1090304@livinglogic.de>

Walter D?rwald wrote:

> [...] 
>> Sure, we could do that, but please use a different name,
>> e.g. .encodeall() and .decodeall() - .encode() and .decode()
>> are already stateles (and so would the new methods be), so
>> "stateless" isn't all that meaningful in this context.
> 
> I like the names encodeall/decodeall!
> 
>> We could also add such a check to the PyCodec_Encode() and _Decode()
>> functions. They currently do not apply the above check.
>>
>> In Python, those two functions are exposed as codecs.encode()
>> and codecs.decode().
> 
> This change will probably have to wait for the 2.7 cycle.

BTW, what I noticed is that the unicode-internal codec seems to be broken:

 >>> import codecs
 >>> codecs.getencoder("unicode-internal")(u"abc")
('a\x00b\x00c\x00', 6)

I would have expected it to return:

 >>> import codecs
 >>> codecs.getencoder("unicode-internal")(u"abc")
('a\x00b\x00c\x00', 3)

Servus,
    Walter


From guido at python.org  Fri Jun 13 19:25:41 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 13 Jun 2008 10:25:41 -0700
Subject: [Python-3000] [Python-3000-checkins] r64217 - in
	python/branches/py3k/Lib: bsddb/test/test_associate.py
	bsddb/test/test_join.py bsddb/test/test_lock.py
	bsddb/test/test_thread.py idlelib/rpc.py idlelib/run.py
	socketserver.py test/test_threadedtemp
Message-ID: <ca471dc20806131025p53b39256ob3e181283f65bea3@mail.gmail.com>

On Fri, Jun 13, 2008 at 6:07 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Steve Holden wrote:
>>
>> Guido van Rossum wrote:
>>>
>>> It's water under the bridge now, but IMO it was too rash to *remove*
>>> the old threading API from Py3k, and doubly rash to do so one day
>>> before the beta release. Running up to a release (whether alpha, beta
>>> or final) we should practice extra restraint, not rush to get things
>>> in right before the deadline. Let's all be more careful the rest of
>>> this release cycle! (I think it wasn't just Benjamin who raced to get
>>> things in...)
>>
>> Well, it wouldn't be "adding a new feature" to reinstate the old API for
>> beta two, would it, as long as we retain the new one too? It does seem that
>> change was a little precipitate.
>
> Although if we weren't actually planning on removing the old API in 3.0, I'm
> a little confused as to why we were adding Py3k warnings to it in 2.6...

It all went way too fast for anyone to think about the decision, so I
suspect these two issues are directly related.

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

From guido at python.org  Fri Jun 13 19:30:59 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 13 Jun 2008 10:30:59 -0700
Subject: [Python-3000] [Python-3000-checkins] r64217 - in
	python/branches/py3k/Lib: bsddb/test/test_associate.py
	bsddb/test/test_join.py bsddb/test/test_lock.py
	bsddb/test/test_thread.py idlelib/rpc.py idlelib/run.py
	socketserver.py test/test_threadedtemp
Message-ID: <ca471dc20806131030w104111cbmd3c148f0ca73dcd0@mail.gmail.com>

On Thu, Jun 12, 2008 at 11:32 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> Guido van Rossum schrieb:
>>
>> It's water under the bridge now, but IMO it was too rash to *remove*
>> the old threading API from Py3k, and doubly rash to do so one day
>> before the beta release. Running up to a release (whether alpha, beta
>> or final) we should practice extra restraint, not rush to get things
>> in right before the deadline. Let's all be more careful the rest of
>> this release cycle! (I think it wasn't just Benjamin who raced to get
>> things in...)
>
> Also, for any method or module renaming, there is no way around a full
> grep through the code base to really catch all uses of the old API.

Eh? Even a full grep won't reveal 3rd party uses of the old API. While
3.x is intentionally breaking some things, this is not (and was never
meant to be) as a blanket approval to break any API we feel like
breaking. Each specific breakage must have a good motivation, e.g. the
old API is confusing, or inefficient, or disallows certain uses --
non-PEP-8-conformance alone is not enough! In addition, each specific
breakage must be weighed against the cost of updating 3rd party code,
and whether a good (or at least fair) automatic conversion can be
added to 2to3.

> It may be tedious, especially with common names, but such bugs really
> must be avoided as they can easily be -- I still could find uses of
> old-style threading names, even in the stdlib. (Fixed in r64222.)

All the more reason not to rush into API renamings without due process
and lots of discussion. Let's err on the side of the status quo --
otherwise we'll never be ready for beta.

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

From g.brandl at gmx.net  Fri Jun 13 23:50:35 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 13 Jun 2008 23:50:35 +0200
Subject: [Python-3000] [Python-3000-checkins] r64217 - in
 python/branches/py3k/Lib: bsddb/test/test_associate.py
 bsddb/test/test_join.py bsddb/test/test_lock.py bsddb/test/test_thread.py
 idlelib/rpc.py idlelib/run.py socketserver.py test/test_threadedtemp
In-Reply-To: <ca471dc20806131030w104111cbmd3c148f0ca73dcd0@mail.gmail.com>
References: <ca471dc20806131030w104111cbmd3c148f0ca73dcd0@mail.gmail.com>
Message-ID: <g2uq3h$q1q$1@ger.gmane.org>

Guido van Rossum schrieb:
> On Thu, Jun 12, 2008 at 11:32 PM, Georg Brandl <g.brandl at gmx.net> wrote:
>> Guido van Rossum schrieb:
>>>
>>> It's water under the bridge now, but IMO it was too rash to *remove*
>>> the old threading API from Py3k, and doubly rash to do so one day
>>> before the beta release. Running up to a release (whether alpha, beta
>>> or final) we should practice extra restraint, not rush to get things
>>> in right before the deadline. Let's all be more careful the rest of
>>> this release cycle! (I think it wasn't just Benjamin who raced to get
>>> things in...)
>>
>> Also, for any method or module renaming, there is no way around a full
>> grep through the code base to really catch all uses of the old API.
> 
> Eh? Even a full grep won't reveal 3rd party uses of the old API. While
> 3.x is intentionally breaking some things, this is not (and was never
> meant to be) as a blanket approval to break any API we feel like
> breaking. Each specific breakage must have a good motivation, e.g. the
> old API is confusing, or inefficient, or disallows certain uses --
> non-PEP-8-conformance alone is not enough! In addition, each specific
> breakage must be weighed against the cost of updating 3rd party code,
> and whether a good (or at least fair) automatic conversion can be
> added to 2to3.

You misunderstand. This wasn't meant as a justification for doing these
specific renamings, but applies to every renaming, e.g. those done for
PEP 3108. Completely regardless of 3rd party code, the code base itself
must be cleanly adapted to the new name.

 >> It may be tedious, especially with common names, but such bugs really
 >> must be avoided as they can easily be -- I still could find uses of
 >> old-style threading names, even in the stdlib. (Fixed in r64222.)
 >
 > All the more reason not to rush into API renamings without due process
 > and lots of discussion. Let's err on the side of the status quo --
 > otherwise we'll never be ready for beta.

No argument here -- I wasn't speaking in favor of more renamings.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From solipsis at pitrou.net  Sat Jun 14 01:14:09 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 13 Jun 2008 23:14:09 +0000 (UTC)
Subject: [Python-3000] Implicit exception chaining (patch)
Message-ID: <loom.20080613T230547-545@post.gmane.org>


Hello,

In the true spirit of the anti-code retention meme launched by Guido, I've
posted a patch implementing the implicit exception chaining part of PEP 3134.
The core functionality is there, but its consequences on exception reporting
are still non-existent (no funky multi-traceback exception messages for you).

Interested people can read at: http://bugs.python.org/issue3108

Regards

Antoine.



From musiccomposition at gmail.com  Sat Jun 14 01:17:54 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 13 Jun 2008 18:17:54 -0500
Subject: [Python-3000] Implicit exception chaining (patch)
In-Reply-To: <loom.20080613T230547-545@post.gmane.org>
References: <loom.20080613T230547-545@post.gmane.org>
Message-ID: <1afaf6160806131617n79098882i29d0def5e35363e9@mail.gmail.com>

On Fri, Jun 13, 2008 at 6:14 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Hello,
>
> In the true spirit of the anti-code retention meme launched by Guido, I've
> posted a patch implementing the implicit exception chaining part of PEP 3134.
> The core functionality is there, but its consequences on exception reporting
> are still non-existent (no funky multi-traceback exception messages for you).

Wonderful! I was just about to make an issue for this anyway. I think
Guido said this is something that could be implemented post-beta,
though.



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

From barry at python.org  Sat Jun 14 23:18:34 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 14 Jun 2008 17:18:34 -0400
Subject: [Python-3000] First betas (perhaps) on June 18
In-Reply-To: <e04bdf310806130654o109c68e9l2e42e4fd899e1901@mail.gmail.com>
References: <26D65059-EDD6-4C90-98FE-111B5135E725@python.org>
	<e04bdf310806130654o109c68e9l2e42e4fd899e1901@mail.gmail.com>
Message-ID: <4F7E8331-D77E-4449-B8DD-305F0D3A50AB@python.org>

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

On Jun 13, 2008, at 9:54 AM, Facundo Batista wrote:

> 2008/6/13 Barry Warsaw <barry at python.org>:
>
>> My proposal is this: I will spin another release this coming  
>> Wednesday, June
>> 18.  If we can get both the 2.6 and 3.0 buildbots green by then,  
>> and close
>> out all remaining release critical bugs, then Wednesday's release  
>> will be
>> beta 1.  In that case, I will update PEP 361 and push the entire  
>> schedule
>> back by 2 weeks to account for our slippage.
>
> Next weekend, 21 and 22, it will be the Python Bug days.
>
> Maybe it's worth to delay the betas one week to include this work?

I think I'd rather stick to a one week delay, otherwise I think we're  
really talking about pushing the whole schedule back a month.  I think  
we should focus right now on getting the buildbots as green as  
possible (yay for some 3.0 greenness! thanks everyone!) and closing  
all the release critical bugs.  I think this will actually free us up  
a bit more on bug day to concentrate on fixing other issues.

Cheers,
- -Barry

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

iQCVAwUBSFQ1qnEjvBPtnXfVAQI13wP/Xj+my8YUNHuLG8i7pggHNC1Vn7/j5K7H
4l5vT9EMgkT6OHXKvrVPxOJSbm7TkoHd4k3M524IYwnKigFAVH/e9WmgTChp4hPv
7UsF9MGKcSsgnjB2LpWvbV9A6lSRLsNLjuLqqJSQgS7TvrD+0Omd91RM9twmV9io
BndCSNAALyE=
=g3RH
-----END PGP SIGNATURE-----

From musiccomposition at gmail.com  Sat Jun 14 23:22:35 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 14 Jun 2008 16:22:35 -0500
Subject: [Python-3000] [Python-Dev]  First betas (perhaps) on June 18
In-Reply-To: <4F7E8331-D77E-4449-B8DD-305F0D3A50AB@python.org>
References: <26D65059-EDD6-4C90-98FE-111B5135E725@python.org>
	<e04bdf310806130654o109c68e9l2e42e4fd899e1901@mail.gmail.com>
	<4F7E8331-D77E-4449-B8DD-305F0D3A50AB@python.org>
Message-ID: <1afaf6160806141422y14bfd5dcn1bc900bf984cbdf2@mail.gmail.com>

On Sat, Jun 14, 2008 at 4:18 PM, Barry Warsaw <barry at python.org> wrote:
> On Jun 13, 2008, at 9:54 AM, Facundo Batista wrote:
>> Next weekend, 21 and 22, it will be the Python Bug days.
>>
>> Maybe it's worth to delay the betas one week to include this work?
>
> I think I'd rather stick to a one week delay, otherwise I think we're really
> talking about pushing the whole schedule back a month.  I think we should
> focus right now on getting the buildbots as green as possible (yay for some
> 3.0 greenness! thanks everyone!) and closing all the release critical bugs.
>  I think this will actually free us up a bit more on bug day to concentrate
> on fixing other issues.

I kinda hate to do this to you, but I had to file another release blocker: #3114


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

From amauryfa at gmail.com  Tue Jun 17 21:44:45 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 17 Jun 2008 21:44:45 +0200
Subject: [Python-3000] Merging changes before beta
Message-ID: <e27efe130806171244t4b4689ect9ee8fa70014c282f@mail.gmail.com>

Hello,

I am in the process of merging changes from trunk to the py3k branch.
(If somebody else is already doing it, please tell me quickly!)

IMO it would be better to have the beta versions in sync;
the 2.6->3.0 migration should not be a regression!

I will integrate the changes that are either simple, or that I can understand,
or have unit tests.

The changes I will skip are (for the moment):

- r64114 (gregory.p.smith): a bunch of checks for integer overflows,
contributed by Google.
This change has many conflicts, I will do it later.

- r63828 (mark.hammond): Fix bdist_wininst --user-access-control for win2k
For this it is necessary to recompile the various wininst-*.exe,
and not all my compilers have the necessary headers or libraries.

- r63955 (ronald.oussoren): MacOS X: Enable 4-way universal builds
I may try the merge, but without any way to test the result.
OTOH, I could go and trust the buildbots.

- 64062,64068-64069,64080 (josiah.carlson): Asynchat
I may give a try, but it will be tricky. And I don't even know how
asynchat works
(I just remember it was hard to get it right for python 3.0)

- 63207,63210,63218,63403,63469,63537,63597-63598,63601,63604,63617-63618,
63714,63718,63742,63745,63799 (jesus.cea, gregory.p.smith): bsddb module
This is a important list of changes, and may require heavy adaptations
to the code.
issue2887 has been filed for this task.

Do you think these tasks should be considered as Release Blockers?
Beta1 is close...

-- 
Amaury Forgeot d'Arc

From barry at python.org  Tue Jun 17 21:59:46 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 17 Jun 2008 15:59:46 -0400
Subject: [Python-3000] Merging changes before beta
In-Reply-To: <e27efe130806171244t4b4689ect9ee8fa70014c282f@mail.gmail.com>
References: <e27efe130806171244t4b4689ect9ee8fa70014c282f@mail.gmail.com>
Message-ID: <C0DD0C67-D3D1-4404-A6F0-7BD0B94D8C96@python.org>

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

On Jun 17, 2008, at 3:44 PM, Amaury Forgeot d'Arc wrote:

> I am in the process of merging changes from trunk to the py3k branch.
> (If somebody else is already doing it, please tell me quickly!)

BTW, I will be hanging out on #python-dev @ freenode from now until  
tomorrow night, so if you have questions feel free to ping me.  My  
userid is 'barry' (so creative <wink>) and I keep generally UTC-0400  
time.

> The changes I will skip are (for the moment):
>
> - r64114 (gregory.p.smith): a bunch of checks for integer overflows,
> contributed by Google.
> This change has many conflicts, I will do it later.

Not a blocker.

> - r63828 (mark.hammond): Fix bdist_wininst --user-access-control for  
> win2k
> For this it is necessary to recompile the various wininst-*.exe,
> and not all my compilers have the necessary headers or libraries.

Not a blocker.

> - r63955 (ronald.oussoren): MacOS X: Enable 4-way universal builds
> I may try the merge, but without any way to test the result.
> OTOH, I could go and trust the buildbots.

Only if you're prepared to back it out if they go red.  Not a blocker.

> - 64062,64068-64069,64080 (josiah.carlson): Asynchat
> I may give a try, but it will be tricky. And I don't even know how
> asynchat works
> (I just remember it was hard to get it right for python 3.0)

Hmm.  I don't know the details of these.

> -  
> 63207,63210,63218,63403,63469,63537,63597 
> -63598,63601,63604,63617-63618,
> 63714,63718,63742,63745,63799 (jesus.cea, gregory.p.smith): bsddb  
> module
> This is a important list of changes, and may require heavy adaptations
> to the code.
> issue2887 has been filed for this task.

Not a blocker.

- -Barry

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

iQCVAwUBSFgXs3EjvBPtnXfVAQJdiQP8CIahHlmiwep5ljm0gakwYzEI7LJ1e7+0
5HXNqClrhntIP+wjR8BPR9oNTp04D0Y35v8ZZcZDh0t/2LtboP6fySO4eVmYcoma
p5/Ld6xPoaSRfy15jVb9xKx4AsegKNZlOdJWpZs9+jkYK5x5mcflns0Nn4KoRKwS
r3ExyMj5YIQ=
=liS1
-----END PGP SIGNATURE-----

From musiccomposition at gmail.com  Wed Jun 18 00:28:30 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 17 Jun 2008 17:28:30 -0500
Subject: [Python-3000] PEP 3118 struct changes
Message-ID: <1afaf6160806171528v1b2030f3ua8f42281bf432377@mail.gmail.com>

Amaury and I were remarking on IRC how the PEP 3118 changes to the
struct module haven't been implemented. What are the plans regarding
this, and can it go in after beta?

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

From barry at python.org  Wed Jun 18 13:45:47 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 18 Jun 2008 07:45:47 -0400
Subject: [Python-3000] Another run at beta one
Message-ID: <F7467050-4DEC-4663-AD2F-4C4739FCA948@python.org>

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

Well, I'm going to try again tonight to release beta one for Python  
2.6 and 3.0.  I'm planning on starting the release at 6pm US/Eastern  
or 2200 UTC.

Right now the Python 2.6 buildbots look pretty good.  We have /one/  
green buildbot for Python 3.0.  That's better than last week at least,  
but it would be great to get a few more.  I know folks have been  
working hard at this, and I really appreciate it.

I think we're looking fairly good on the release critical bugs.  I'll  
clear 3089 and 3009 tonight, and check locally on 3088 over the day.

If you're looking for a way to help out, see if you can turn any of  
the other 3.0 buildbots green.  I will be hanging out on #python-dev  
all day, but ping my nick (barry) if you need my attention.

Thanks, and let's get it done today!
- -Barry

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

iQCVAwUBSFj1bHEjvBPtnXfVAQLrvAP/ftfpN50HbeimRoK2WhX4RcuN9G81IfbJ
4+CXdjH7WLC/wwKvNp1Q6qc3vHWTqPgA7jF7yowU/a/3FretkzUPGNmtjoWvfQzM
BL1ktG6fh298+KRJTSTXGeNSEzjwBg2GryyQJV5xmwsUMiwvrI4OE3w8O6eE5AkS
gFmU86oZSFw=
=SiNl
-----END PGP SIGNATURE-----

From jnoller at gmail.com  Wed Jun 18 13:54:17 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 18 Jun 2008 07:54:17 -0400
Subject: [Python-3000] Another run at beta one
In-Reply-To: <F7467050-4DEC-4663-AD2F-4C4739FCA948@python.org>
References: <F7467050-4DEC-4663-AD2F-4C4739FCA948@python.org>
Message-ID: <4222a8490806180454i5671c8f6sd9d2423961eec940@mail.gmail.com>

On Wed, Jun 18, 2008 at 7:45 AM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Well, I'm going to try again tonight to release beta one for Python 2.6 and
> 3.0.  I'm planning on starting the release at 6pm US/Eastern or 2200 UTC.
>
> Right now the Python 2.6 buildbots look pretty good.  We have /one/ green
> buildbot for Python 3.0.  That's better than last week at least, but it
> would be great to get a few more.  I know folks have been working hard at
> this, and I really appreciate it.
>
> I think we're looking fairly good on the release critical bugs.  I'll clear
> 3089 and 3009 tonight, and check locally on 3088 over the day.
>
> If you're looking for a way to help out, see if you can turn any of the
> other 3.0 buildbots green.  I will be hanging out on #python-dev all day,
> but ping my nick (barry) if you need my attention.
>
> Thanks, and let's get it done today!
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Darwin)
>
> iQCVAwUBSFj1bHEjvBPtnXfVAQLrvAP/ftfpN50HbeimRoK2WhX4RcuN9G81IfbJ
> 4+CXdjH7WLC/wwKvNp1Q6qc3vHWTqPgA7jF7yowU/a/3FretkzUPGNmtjoWvfQzM
> BL1ktG6fh298+KRJTSTXGeNSEzjwBg2GryyQJV5xmwsUMiwvrI4OE3w8O6eE5AkS
> gFmU86oZSFw=
> =SiNl
> -----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/jnoller%40gmail.com
>

Please let me know about 3088 - I've disabled the more unreliable
tests until I can give the entire suite some TLC. I'm still trying to
work around/identify the "Function not Implemented" error in issue3111
 - this happens to be failing the tests on a few of the linux boxes. I
suspected it was due to a combination of chroot + lack of /dev/shm on
some of the build bots, ergo a patch put in by Ben last night to skip
the tests on machines lacking the device, but it doesn't seem to be
skipping/the device exists.

-jesse

From jnoller at gmail.com  Wed Jun 18 16:30:50 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 18 Jun 2008 10:30:50 -0400
Subject: [Python-3000] Another run at beta one
In-Reply-To: <4222a8490806180454i5671c8f6sd9d2423961eec940@mail.gmail.com>
References: <F7467050-4DEC-4663-AD2F-4C4739FCA948@python.org>
	<4222a8490806180454i5671c8f6sd9d2423961eec940@mail.gmail.com>
Message-ID: <4222a8490806180730i616ec5fdyfec8478a80ec6814@mail.gmail.com>

On Wed, Jun 18, 2008 at 7:54 AM, Jesse Noller <jnoller at gmail.com> wrote:
> On Wed, Jun 18, 2008 at 7:45 AM, Barry Warsaw <barry at python.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Well, I'm going to try again tonight to release beta one for Python 2.6 and
>> 3.0.  I'm planning on starting the release at 6pm US/Eastern or 2200 UTC.
>>
>> Right now the Python 2.6 buildbots look pretty good.  We have /one/ green
>> buildbot for Python 3.0.  That's better than last week at least, but it
>> would be great to get a few more.  I know folks have been working hard at
>> this, and I really appreciate it.
>>
>> I think we're looking fairly good on the release critical bugs.  I'll clear
>> 3089 and 3009 tonight, and check locally on 3088 over the day.
>>
>> If you're looking for a way to help out, see if you can turn any of the
>> other 3.0 buildbots green.  I will be hanging out on #python-dev all day,
>> but ping my nick (barry) if you need my attention.
>>
>> Thanks, and let's get it done today!
>> - -Barry
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (Darwin)
>>
>> iQCVAwUBSFj1bHEjvBPtnXfVAQLrvAP/ftfpN50HbeimRoK2WhX4RcuN9G81IfbJ
>> 4+CXdjH7WLC/wwKvNp1Q6qc3vHWTqPgA7jF7yowU/a/3FretkzUPGNmtjoWvfQzM
>> BL1ktG6fh298+KRJTSTXGeNSEzjwBg2GryyQJV5xmwsUMiwvrI4OE3w8O6eE5AkS
>> gFmU86oZSFw=
>> =SiNl
>> -----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/jnoller%40gmail.com
>>

Update: Most of the trunk bots went green post r64375, so I merged the
change over to py3k. The change aggressively skips the MP package
tests if RLock instantiation throws an OSError.

-jesse

From oliphant.travis at ieee.org  Wed Jun 18 18:41:36 2008
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Wed, 18 Jun 2008 11:41:36 -0500
Subject: [Python-3000] PEP 3118 struct changes
In-Reply-To: <1afaf6160806171528v1b2030f3ua8f42281bf432377@mail.gmail.com>
References: <1afaf6160806171528v1b2030f3ua8f42281bf432377@mail.gmail.com>
Message-ID: <g3bds0$mk4$1@ger.gmane.org>

Benjamin Peterson wrote:
> Amaury and I were remarking on IRC how the PEP 3118 changes to the
> struct module haven't been implemented. What are the plans regarding
> this, and can it go in after beta?

Unfortunately, I've had no time to do this and don't see getting time to 
do this in the near future. End of July, first of August I will have a 
bit of time.   It's not necessarily a problem as the PEP defines a 
standard for communication which it would be nice for the struct module 
support but not immediately essential.

-Travis


From barry at python.org  Thu Jun 19 01:38:19 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 18 Jun 2008 19:38:19 -0400
Subject: [Python-3000] releasing betas tonight
Message-ID: <8AE8BB5B-447B-4D31-854F-671AE902E4FF@python.org>

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

There are enough green buildbots and I think all the showstoppers are  
resolvable, so I'm going ahead and releasing beta 1 tonight.  Please  
refrain from any commits unless I ask you to check something in.

We've got a major thunderstorm blowing through right now, but when it  
clears I'll be on irc.freenode.net #python-dev.  I'll start making the  
release as soon as I get on, and feel free to ask any questions.

- -B

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

iQCVAwUBSFmca3EjvBPtnXfVAQICfAP8DHTOoQap9MnXJrUY0a3rurgRerMDNxSe
1dmOlhSVGmbQncPSZWP5x0xf1gC5QOCUAofGYfh2xY5ng6BbCQlzMX3Iogy1KvHQ
Fb1HQ4EPUO5PGEQipgvHlkN38OFDqevoyvaRBIOGOppIVjL0v8P66eXNkkLq4BvT
RztyojPrhxE=
=jZ8g
-----END PGP SIGNATURE-----

From barry at python.org  Thu Jun 19 03:02:05 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 18 Jun 2008 21:02:05 -0400
Subject: [Python-3000] Another run at beta one
In-Reply-To: <4222a8490806180454i5671c8f6sd9d2423961eec940@mail.gmail.com>
References: <F7467050-4DEC-4663-AD2F-4C4739FCA948@python.org>
	<4222a8490806180454i5671c8f6sd9d2423961eec940@mail.gmail.com>
Message-ID: <9E5AEF05-6169-42A5-8CC8-EEC8750EE00B@python.org>

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

On Jun 18, 2008, at 7:54 AM, Jesse Noller wrote:

> Please let me know about 3088 - I've disabled the more unreliable
> tests until I can give the entire suite some TLC. I'm still trying to
> work around/identify the "Function not Implemented" error in issue3111
> - this happens to be failing the tests on a few of the linux boxes. I
> suspected it was due to a combination of chroot + lack of /dev/shm on
> some of the build bots, ergo a patch put in by Ben last night to skip
> the tests on machines lacking the device, but it doesn't seem to be
> skipping/the device exists.

We're going to have to deal with 3088 after the beta release.  I'm not  
going to let it hold us up this time.  I think we're going to have a  
tougher time than we think getting the 3.0 release stabilized for  
final though.

- -Barry

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

iQCVAwUBSFmwDXEjvBPtnXfVAQIFjAP+LGwB1Z3eBLaF/ZEez5TgkpMWdhHZwmWA
zefJnlORHRN4TiawGDNkGdbs+B3O0An8vuCkXTnM97sdKqXYIUZ+0C8qdU5g9OaA
UlX2Wagl1UTC8HHMhmPVlo7AnIzcR0mUOlu7T9SgtjKeEbcrSB4vCT9Cqy7rH7r8
jsHzlmzjswI=
=r2K6
-----END PGP SIGNATURE-----

From barry at python.org  Thu Jun 19 04:46:06 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 18 Jun 2008 22:46:06 -0400
Subject: [Python-3000] RELEASED Python 2.6b1 and 3.0b1
Message-ID: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>

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

On behalf of the Python development team and the Python community, I  
am happy to announce the first 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.

 From now until the planned final releases in September 2008, we will  
be fixing known problems and stabilizing these new Python versions.   
You can help by downloading and testing them, providing feedback and  
hopefully helping to fix bugs.  You can also use these releases to  
determine how changes in 2.6 and 3.0 might impact you.  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.9 (Darwin)

iQCVAwUBSFnIbnEjvBPtnXfVAQKCMgP+L9Vpk9vQgYw01KShtF9HyvCKE0guSy86
0Q/IRbkXGahXg910D4nVLY9NORaOSq/VP8Kx+fOU8egUDHvVF9MuKkY75ZHYoixR
mieeV7BIpYHYKYhva48FVoF4p0+sUeNvfeOAP0nnV5Pi2icGqCpzizfSHZloXJjc
Y8M4F5vVrOM=
=Oo15
-----END PGP SIGNATURE-----

From p.f.moore at gmail.com  Thu Jun 19 10:43:25 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 19 Jun 2008 09:43:25 +0100
Subject: [Python-3000] RELEASED Python 2.6b1 and 3.0b1
In-Reply-To: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
References: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
Message-ID: <79990c6b0806190143n58e51a22ubafd3fe343291dfb@mail.gmail.com>

On 19/06/2008, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On behalf of the Python development team and the Python community, I am
> happy to announce the first beta releases of Python 2.6 and Python 3.0.

Any ETA for Windows builds? The web pages still point to the alphas.
(I'd like to see the Windows builds more closely integrated with the
releases now we're in beta stage...)

Paul.

From qrczak at knm.org.pl  Thu Jun 19 13:33:58 2008
From: qrczak at knm.org.pl (=?UTF-8?Q?Marcin_=E2=80=98Qrczak=E2=80=99_Kowalczyk?=)
Date: Thu, 19 Jun 2008 13:33:58 +0200
Subject: [Python-3000] RELEASED Python 2.6b1 and 3.0b1
In-Reply-To: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
References: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
Message-ID: <3f4107910806190433y6943290dx52249f955b157b3a@mail.gmail.com>

What is the current equivalent of:
   modulePy = Py_InitModule(\"_ko_unpickle\", ko_py_unpickle_defs);
?

-- 
Marcin Kowalczyk
qrczak at knm.org.pl
http://qrnik.knm.org.pl/~qrczak/

From barry at python.org  Thu Jun 19 13:53:10 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 19 Jun 2008 07:53:10 -0400
Subject: [Python-3000] RELEASED Python 2.6b1 and 3.0b1
In-Reply-To: <79990c6b0806190143n58e51a22ubafd3fe343291dfb@mail.gmail.com>
References: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
	<79990c6b0806190143n58e51a22ubafd3fe343291dfb@mail.gmail.com>
Message-ID: <5A74EFE6-0915-4EF9-9096-3CE75F32F00E@python.org>

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

On Jun 19, 2008, at 4:43 AM, Paul Moore wrote:

> On 19/06/2008, Barry Warsaw <barry at python.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On behalf of the Python development team and the Python community,  
>> I am
>> happy to announce the first beta releases of Python 2.6 and Python  
>> 3.0.
>
> Any ETA for Windows builds? The web pages still point to the alphas.
> (I'd like to see the Windows builds more closely integrated with the
> releases now we're in beta stage...)

Martin usually fills these in pretty quickly.  I think the current  
situation works fine for the betas but we'll make sure the final  
release (and candidates) are better coordinated.

- -Barry

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

iQCVAwUBSFpIpnEjvBPtnXfVAQJyWQP9FSH8Ipg93UDM3nmH3UtN+i61YGsQPd0O
ypHlnz4yHpxeRkJm1zkppHHI0hKMou6JOeUf05QCnPzrAdsG/mkuv5aoBrBt3dDd
UncHLoQOvXEhGrrPzexmHKv3ehxUXPQOzkiWBWVv9e69GYH4e4HcqV6s2Ya2733T
zC/EyOgkyMg=
=5wM5
-----END PGP SIGNATURE-----

From qrczak at knm.org.pl  Thu Jun 19 20:22:50 2008
From: qrczak at knm.org.pl (=?UTF-8?Q?Marcin_=E2=80=98Qrczak=E2=80=99_Kowalczyk?=)
Date: Thu, 19 Jun 2008 20:22:50 +0200
Subject: [Python-3000] RELEASED Python 2.6b1 and 3.0b1
In-Reply-To: <3f4107910806190433y6943290dx52249f955b157b3a@mail.gmail.com>
References: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
	<3f4107910806190433y6943290dx52249f955b157b3a@mail.gmail.com>
Message-ID: <3f4107910806191122j75f41dacpd87c7ef7ada67340@mail.gmail.com>

2008/6/19 Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl>:

> What is the current equivalent of:
>   modulePy = Py_InitModule(\"_ko_unpickle\", ko_py_unpickle_defs);
> ?

Ok, I found it out myself:

      modulePy = PyModule_Create(&ko_py_unpickle_module);
      if (modulePy == NULL) ...;
      status = PyDict_SetItemString(PyImport_GetModuleDict(),
         ko_py_unpickle_module.m_name, modulePy);
      Py_DECREF(modulePy);
      if (status == -1) ...;

with a suitable PyModuleDef ko_py_unpickle_module.

-- 
Marcin Kowalczyk
qrczak at knm.org.pl
http://qrnik.knm.org.pl/~qrczak/

From alexandre at peadrop.com  Thu Jun 19 23:19:13 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Thu, 19 Jun 2008 17:19:13 -0400
Subject: [Python-3000] Simplifying the copy protocol
In-Reply-To: <acd65fa20806081526l73062e4dn308a65261ceba2f6@mail.gmail.com>
References: <acd65fa20806081526l73062e4dn308a65261ceba2f6@mail.gmail.com>
Message-ID: <acd65fa20806191419o57f5d136md20b2f2d1db3751a@mail.gmail.com>

Any comment on the proposed changes? Well if no-one objects, I would
like to move forward and implement these changes:

  - Deprecate __reduce_ex__ and copyreg.pickle in 2.6 and 3.0 (with a
planned removal in 3.1).
  - Make __reduce__ raise a TypeError on the condition previously
described in 3.0.


-- Alexandre


On Sun, Jun 8, 2008 at 6:26 PM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
> Hello all,
>
> I would like to propose to following simplifications to the copy
> protocol (a.k.a the __reduce__ method):
>
>  - Remove the type.__reduce_ex__ method and define __reduce__ method
> to take a single optional integer argument that is the pickle protocol
> version to use. And since this already the current behavior of
> __reduce__, no change is required.
>  - Deprecate copyreg.pickle in favor of the __getnewargs__ special
> method. They both solve the exact same problem, but __getnewargs__
> does it in a simpler and more robust manner.
>  - Make __reduce__ raise a TypeError if the class of an instance
> derives from one or more extension type (object, list and dict
> excluded) and neither __getnewargs__ nor __getstate__ is defined.
>
> I believe that these changes will make it easier for developers to
> write classes that supports the copy protocol, which is already quite
> complex in addition of being poorly documented. Evidently, I will
> provide the patches and write the documentation for these changes.
>
> Cheers,
> -- Alexandre
>

From guido at python.org  Fri Jun 20 00:11:16 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 19 Jun 2008 15:11:16 -0700
Subject: [Python-3000] Simplifying the copy protocol
In-Reply-To: <acd65fa20806191419o57f5d136md20b2f2d1db3751a@mail.gmail.com>
References: <acd65fa20806081526l73062e4dn308a65261ceba2f6@mail.gmail.com>
	<acd65fa20806191419o57f5d136md20b2f2d1db3751a@mail.gmail.com>
Message-ID: <ca471dc20806191511j120794c7hba7276f30e29a4c3@mail.gmail.com>

I haven't had the time to look into this, but it sounds unintuitive to
drop __reduce_ex__ which is supposed to be the "extended" IOW "newer"
version of the API compared to __reduce__ which was deemed to be
missing something.

On Thu, Jun 19, 2008 at 2:19 PM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
> Any comment on the proposed changes? Well if no-one objects, I would
> like to move forward and implement these changes:
>
>  - Deprecate __reduce_ex__ and copyreg.pickle in 2.6 and 3.0 (with a
> planned removal in 3.1).
>  - Make __reduce__ raise a TypeError on the condition previously
> described in 3.0.
>
>
> -- Alexandre
>
>
> On Sun, Jun 8, 2008 at 6:26 PM, Alexandre Vassalotti
> <alexandre at peadrop.com> wrote:
>> Hello all,
>>
>> I would like to propose to following simplifications to the copy
>> protocol (a.k.a the __reduce__ method):
>>
>>  - Remove the type.__reduce_ex__ method and define __reduce__ method
>> to take a single optional integer argument that is the pickle protocol
>> version to use. And since this already the current behavior of
>> __reduce__, no change is required.
>>  - Deprecate copyreg.pickle in favor of the __getnewargs__ special
>> method. They both solve the exact same problem, but __getnewargs__
>> does it in a simpler and more robust manner.
>>  - Make __reduce__ raise a TypeError if the class of an instance
>> derives from one or more extension type (object, list and dict
>> excluded) and neither __getnewargs__ nor __getstate__ is defined.
>>
>> I believe that these changes will make it easier for developers to
>> write classes that supports the copy protocol, which is already quite
>> complex in addition of being poorly documented. Evidently, I will
>> provide the patches and write the documentation for these changes.
>>
>> Cheers,
>> -- Alexandre
>>
> _______________________________________________
> 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/guido%40python.org
>



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

From python at rcn.com  Fri Jun 20 00:43:46 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 19 Jun 2008 15:43:46 -0700
Subject: [Python-3000] Simplifying the copy protocol
References: <acd65fa20806081526l73062e4dn308a65261ceba2f6@mail.gmail.com><acd65fa20806191419o57f5d136md20b2f2d1db3751a@mail.gmail.com>
	<ca471dc20806191511j120794c7hba7276f30e29a4c3@mail.gmail.com>
Message-ID: <10E7EFA983A24E07B106DAE80292DD7F@RaymondLaptop1>

From: "Guido van Rossum" <guido at python.org>
>I haven't had the time to look into this, but it sounds unintuitive to
> drop __reduce_ex__ which is supposed to be the "extended" IOW "newer"
> version of the API compared to __reduce__ which was deemed to be
> missing something.

Right.  The version argument should be kept.
Recommend renaming __reduce_ex__ to  __reduce__
and dropping the older method.


Raymond

From guido at python.org  Fri Jun 20 00:46:30 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 19 Jun 2008 15:46:30 -0700
Subject: [Python-3000] Simplifying the copy protocol
In-Reply-To: <10E7EFA983A24E07B106DAE80292DD7F@RaymondLaptop1>
References: <acd65fa20806081526l73062e4dn308a65261ceba2f6@mail.gmail.com>
	<acd65fa20806191419o57f5d136md20b2f2d1db3751a@mail.gmail.com>
	<ca471dc20806191511j120794c7hba7276f30e29a4c3@mail.gmail.com>
	<10E7EFA983A24E07B106DAE80292DD7F@RaymondLaptop1>
Message-ID: <ca471dc20806191546k5cb599b2xf25fefaa09c248d5@mail.gmail.com>

On Thu, Jun 19, 2008 at 3:43 PM, Raymond Hettinger <python at rcn.com> wrote:
> From: "Guido van Rossum" <guido at python.org>
>>
>> I haven't had the time to look into this, but it sounds unintuitive to
>> drop __reduce_ex__ which is supposed to be the "extended" IOW "newer"
>> version of the API compared to __reduce__ which was deemed to be
>> missing something.
>
> Right.  The version argument should be kept.
> Recommend renaming __reduce_ex__ to  __reduce__
> and dropping the older method.

Hm. That's asking for hard-to-debug problems in 3rd party code.

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

From alexandre at peadrop.com  Fri Jun 20 00:52:45 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Thu, 19 Jun 2008 18:52:45 -0400
Subject: [Python-3000] Simplifying the copy protocol
In-Reply-To: <ca471dc20806191511j120794c7hba7276f30e29a4c3@mail.gmail.com>
References: <acd65fa20806081526l73062e4dn308a65261ceba2f6@mail.gmail.com>
	<acd65fa20806191419o57f5d136md20b2f2d1db3751a@mail.gmail.com>
	<ca471dc20806191511j120794c7hba7276f30e29a4c3@mail.gmail.com>
Message-ID: <acd65fa20806191552u254f1b77wf446437a5f50c69f@mail.gmail.com>

On Thu, Jun 19, 2008 at 6:11 PM, Guido van Rossum <guido at python.org> wrote:
> I haven't had the time to look into this, but it sounds unintuitive to
> drop __reduce_ex__ which is supposed to be the "extended" IOW "newer"
> version of the API compared to __reduce__ which was deemed to be
> missing something.
>

Well, the idea was not to drop __reduce_ex__, but to rename it to
__reduce__.  That said, I just realized that might not be a good idea
after all. Since __reduce_ex__ as __reduce__ would mean that
__reduce__ would need to always be called with the extra protocol
argument, thus breaking code that defines __reduce__ as a method
without argument.  I first thought that by making the argument
"optional" would avoid this, but that obviously won't work.

So, forget that idea.

-- Alexandre

From nirina at mail.blueline.mg  Fri Jun 20 03:18:58 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Fri, 20 Jun 2008 04:18:58 +0300 (EAT)
Subject: [Python-3000] failed to compile Python-3.0b1 with gcc-4.3.0: Fatal
	Python error:	Py_Initialize: can't initialize sys standard streams
Message-ID: <20080620011858.A7D0BF88C@mail.blueline.mg>

hello all,
i tried to build Python3.0b1 but the make process hangs
while running:

./python -E ./setup.py build

breaking the building with ctrl-C, i have:


<output>
gcc -pthread  -Xlinker -export-dynamic -o python
                        Modules/python.o
                        libpython3.0.a -lpthread -ldl  -lutil   -lm
^CFatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/usr/local/src/Python-3.0b1/Lib/encodings/__init__.py", line 31, in <module>
import codecs
  File "/usr/local/src/Python-3.0b1/Lib/codecs.py", line 8, in <module>
"""#"
KeyboardInterrupt
make: *** [sharedmods] Error 134
</output>

another make procedure also hangs, and with ctrl-C, i get this:

<output>
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/home/nirina/Python-3.0b1/Lib/io.py", line 63, in <module>
import warnings
  File "/home/nirina/Python-3.0b1/Lib/warnings.py", line 6, in <module>
import linecache
  File "/home/nirina/Python-3.0b1/Lib/linecache.py", line 10, in <module>
import re
  File "/home/nirina/Python-3.0b1/Lib/re.py", line 223, in <module>
_pattern_type = type(sre_compile.compile("", 0))
  File "/home/nirina/Python-3.0b1/Lib/sre_compile.py", line 497, in compile
p = sre_parse.parse(p, flags)
  File "/home/nirina/Python-3.0b1/Lib/sre_parse.py", line 685, in parse
p = _parse_sub(source, pattern, 0)
  File "/home/nirina/Python-3.0b1/Lib/sre_parse.py", line 321, in _parse_sub
if sourcematch("|"):
  File "/home/nirina/Python-3.0b1/Lib/sre_parse.py", line 210, in match
self.__next()
  File "/home/nirina/Python-3.0b1/Lib/sre_parse.py", line 190, in __next
self.next = None
KeyboardInterrupt
make: *** [sharedmods] Error 134
</output>

i have similar error when building Python-3.0a5 with gcc-4.3.0.

with gcc-4.2.3, however, the compilation succeeded, and
apparently it works fine:

#./python Lib/idlelib/idle.py

<output>
Python 3.0b1 (r30b1:64395, Jun 20 2008, 01:00:45)
[GCC 4.2.3] on linux2
Type "copyright", "credits" or "license()" for more information.

    ****************************************************************
    Personal firewall software may warn about the connection IDLE
    makes to its subprocess using this computer's internal loopback
    interface.  This connection is not visible on any external
    interface and no data is sent to or received from the Internet.
    ****************************************************************

IDLE 3.0b1      
>>> import tkinter.tix
>>> tkinter.tix.tkinter
<module 'tkinter' from '/usr/local/src/Python-3.0b1/Lib/tkinter/__init__.py'>
>>> tkinter.tix.TclVersion
8.5
</output>

but the following modules are not built:

<output>
Failed to find the necessary bits to build these modules:
_gestalt           _sqlite3
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

Failed to build these modules:
_multiprocessing
</output>

i don't have sqlite3 installed.
but what about _gestalt and _multiprocessing?
what to do in order to build them?

Python-2.5.2 and Python-3.0a1 are both successfully compiled
and work fine with gcc-4.3.0.
the building system is:

# cat /proc/version
<output>
Linux version 2.6.25.20080505 (root at nirinA) (gcc version 4.3.0 (GCC) ) #1 Mon May 5 15:44:45 EAT 2008
</output>

surely there is something missing with my system but i don't see what.
i've checked in pythonrun.c, the initstdio function initializes
some encodings. does Python-3.0b1 require some encodings to be installed?
as far as i can tell, the kernel supports utf_8 and iso-8859-1.
i will appreciate any help.

best regards,

nirinA

--


From musiccomposition at gmail.com  Fri Jun 20 04:04:44 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 19 Jun 2008 21:04:44 -0500
Subject: [Python-3000] failed to compile Python-3.0b1 with gcc-4.3.0:
	Fatal Python error: Py_Initialize: can't initialize sys
	standard streams
In-Reply-To: <20080620011858.A7D0BF88C@mail.blueline.mg>
References: <20080620011858.A7D0BF88C@mail.blueline.mg>
Message-ID: <1afaf6160806191904y8b09d48n94a731aed342e84c@mail.gmail.com>

On Thu, Jun 19, 2008 at 8:18 PM, nirinA raseliarison
<nirina at mail.blueline.mg> wrote:
> hello all,
> i tried to build Python3.0b1 but the make process hangs
> while running:

Building with gcc 4.3 is buggy. See
http://mail.python.org/pipermail/python-3000/2008-April/012965.html.



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

From jarausch at igpm.rwth-aachen.de  Fri Jun 20 09:10:49 2008
From: jarausch at igpm.rwth-aachen.de (Helmut Jarausch)
Date: Fri, 20 Jun 2008 09:10:49 +0200 (CEST)
Subject: [Python-3000]  2to3 fails here
In-Reply-To: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
References: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
Message-ID: <tkrat.11d1d8f7e99603f4@igpm.rwth-aachen.de>

Hi,

for 3.0-beta1 and SVN (2008/06/20) invocation of 2to3 fails with

2to3 -l                 

Available transformations for the -f/--fix option:
Traceback (most recent call last):
  File "/usr/local/bin/2to3", line 5, in <module>
sys.exit(refactor.main("lib2to3/fixes"))
  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 62, in main
for fixname in get_all_fix_names(fixer_dir):
  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 95, in get_all_fix_names
names = os.listdir(fixer_dir)
OSError: [Errno 2] No such file or directory: 'lib2to3/fixes'

What am I missing?

And could Python-3 please install  idle-3.0 instead of plain 'idle'?

Thanks for Python-3

Here: Linux 2.6.25-gentoo-r4  with gcc-4.3.1


-- 
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

From musiccomposition at gmail.com  Fri Jun 20 15:19:24 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 20 Jun 2008 08:19:24 -0500
Subject: [Python-3000] 2to3 fails here
In-Reply-To: <tkrat.11d1d8f7e99603f4@igpm.rwth-aachen.de>
References: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
	<tkrat.11d1d8f7e99603f4@igpm.rwth-aachen.de>
Message-ID: <1afaf6160806200619x217690b0l8c1a712e6c27b72a@mail.gmail.com>

On Fri, Jun 20, 2008 at 2:10 AM, Helmut Jarausch
<jarausch at igpm.rwth-aachen.de> wrote:
> Hi,
>
> for 3.0-beta1 and SVN (2008/06/20) invocation of 2to3 fails with
>
> 2to3 -l
>
> Available transformations for the -f/--fix option:
> Traceback (most recent call last):
>  File "/usr/local/bin/2to3", line 5, in <module>
> sys.exit(refactor.main("lib2to3/fixes"))
>  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 62, in main
> for fixname in get_all_fix_names(fixer_dir):
>  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 95, in get_all_fix_names
> names = os.listdir(fixer_dir)
> OSError: [Errno 2] No such file or directory: 'lib2to3/fixes'
>
> What am I missing?

Please see http://bugs.python.org/3131.



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

From nas at arctrix.com  Sat Jun 21 07:16:24 2008
From: nas at arctrix.com (Neil Schemenauer)
Date: Sat, 21 Jun 2008 05:16:24 +0000 (UTC)
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
Message-ID: <g3i2r8$l57$1@ger.gmane.org>

I wonder if it would make sense to start installing the Python
standard library as a .zip file by default.  Some benefits would be
a tidier and more compact install and slightly faster startup times.
One downside is that it becomes more difficult to look at the source
of modules.  That's an important feature of Python, especially for
people learning the language.  

I think that downside could be mitigated by adding an option to
pydoc that shows the source of a module.  For example, "pydoc -s
bisect" could show the source for the bisect module.

  Neil


From brett at python.org  Sat Jun 21 08:19:57 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 20 Jun 2008 23:19:57 -0700
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
In-Reply-To: <g3i2r8$l57$1@ger.gmane.org>
References: <g3i2r8$l57$1@ger.gmane.org>
Message-ID: <bbaeab100806202319u1cc2e81fpbde0ba031c281993@mail.gmail.com>

On Fri, Jun 20, 2008 at 10:16 PM, Neil Schemenauer <nas at arctrix.com> wrote:
> I wonder if it would make sense to start installing the Python
> standard library as a .zip file by default.  Some benefits would be
> a tidier and more compact install and slightly faster startup times.
> One downside is that it becomes more difficult to look at the source
> of modules.  That's an important feature of Python, especially for
> people learning the language.
>
> I think that downside could be mitigated by adding an option to
> pydoc that shows the source of a module.  For example, "pydoc -s
> bisect" could show the source for the bisect module.
>

Or zipimport grows the ability to store source and supplies the
get_source() method as specified in PEP 302. Then pydoc can just use
the loader to get at the source.

-Brett

From ncoghlan at gmail.com  Sat Jun 21 08:56:47 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 21 Jun 2008 16:56:47 +1000
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
In-Reply-To: <bbaeab100806202319u1cc2e81fpbde0ba031c281993@mail.gmail.com>
References: <g3i2r8$l57$1@ger.gmane.org>
	<bbaeab100806202319u1cc2e81fpbde0ba031c281993@mail.gmail.com>
Message-ID: <485CA62F.8070503@gmail.com>

Brett Cannon wrote:
> On Fri, Jun 20, 2008 at 10:16 PM, Neil Schemenauer <nas at arctrix.com> wrote:
>> I wonder if it would make sense to start installing the Python
>> standard library as a .zip file by default.  Some benefits would be
>> a tidier and more compact install and slightly faster startup times.
>> One downside is that it becomes more difficult to look at the source
>> of modules.  That's an important feature of Python, especially for
>> people learning the language.
>>
>> I think that downside could be mitigated by adding an option to
>> pydoc that shows the source of a module.  For example, "pydoc -s
>> bisect" could show the source for the bisect module.
>>
> 
> Or zipimport grows the ability to store source and supplies the
> get_source() method as specified in PEP 302. Then pydoc can just use
> the loader to get at the source.

It already provides that (it goes and gets it out of the zipfile when 
requested). [1]

I believe the only new part that Neil is suggesting is the "-s <mod>" 
option to get pydoc to import the module and return its source code (if 
available).

So "pydoc -s <mod>" would work for an installed python and "./python -m 
pydoc -s <mod>" for an uninstalled one.

Cheers,
Nick.

[1] http://docs.python.org/lib/zipimporter-objects.html

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

From nirina at mail.blueline.mg  Sat Jun 21 10:56:54 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Sat, 21 Jun 2008 11:56:54 +0300 (EAT)
Subject: [Python-3000] gcc-4.3.1 builds Python-3.0b1 fine [was:failed to
	compile	Python-3.0b1 with gcc-4.3.0: Fatal Python error:
	Py_Initialize:	can't initialize sys standard streams]
In-Reply-To: <1afaf6160806191904y8b09d48n94a731aed342e84c@mail.gmail.com>
References: <20080620011858.A7D0BF88C@mail.blueline.mg>
Message-ID: <20080621085654.7A605F824@mail.blueline.mg>

hello,
on Thu, 19 Jun 2008 21:04:44 -0500, Benjamin Peterson wrote:

>On Thu, Jun 19, 2008 at 8:18 PM, nirinA raseliarison
><nirina at mail.blueline.mg> wrote:
>> hello all,
>> i tried to build Python3.0b1 but the make process hangs
>> while running:
>
>Building with gcc 4.3 is buggy. See
>http://mail.python.org/pipermail/python-3000/2008-April/012965.html.

Python-3.0b1 is successfully compiled with gcc-4.3.1
without any additionnal flags.

for me, adding -fno-tree-vrp when building with gcc-4.3.0
doesn't fix the problem.

thanks,

nirinA

--


From python at tlinx.org  Sat Jun 21 11:05:29 2008
From: python at tlinx.org (Linda W.)
Date: Sat, 21 Jun 2008 02:05:29 -0700
Subject: [Python-3000] Question to _users_ -- about over all
	perceptions/feelings
Message-ID: <485CC459.50406@tlinx.org>


This isn't meant to stir controversy -- I'm more curious than anything else.

I was noticing some percentage (hard to say), that are less than excited 
about
the next incompatible version of Perl 6.  It's not that it may not 
'better' in some
design and orthogonal feature set, but its partly do to 'regularization' 
of the language
to change to other OS's ways of doing things (not just because, but for 
good reasons).

Yet and this is where my wonderings about python come in.  Alot 
built-ins and ven language semantics have changed.  builtins have become 
regularlized functions (as in python).  Few special cases, more, 
'standard' methods from other languages to solve problems in better 
thought out ways if the other way is really better -- sorta not letting 
'history drag development back from developing a better language.  All 
great stuff..
apple pie...etc. 

But *some* of thei things that may have attracted people to python or 
perl in the first place may be items replaced.  Prints are no longer 
builtin statements, but functions in standard function format.  Tends to 
'unbeautify' the code a bit.  A few other  regularizing features have a 
similar effect, perhaps adding extra line-noise syntax where none was 
needed before...

   While the infamous intermixing of tabs  & spaces will still prevail, 
the rest of the
code won't look at simple and clean as the original  I wonder how many 
will be turned off by the new changes?

   I've had similar wonderings about perl6 being a major incompat 
forward -- almost
looking like an 'off shoot more than a new version.

How do you think or will it at all, affect perceptions of the languages 
as they move
father away from the features and syntax that made them popular?  
Admittedly, new ways may be superior by several majors, but I wonder if 
the subtle 'debeautifying'
of the language will have a greater impact than the implementors perceive...

It's going to be hard for them to tell, since around them are all the 
excited enthused types that are in favor of the change, while those 
happy with the old ... well, just know to keep their mouths shut or risk 
time wasted justifying yourself to a hostile
questioner. 

Will it be in significant (<5%), or up in to 20-30% brackts.

Perls a bit of an odd one -- since people are still running the previous 
version (P4)
at some places.  And it seems like the newer versions are going way 
beyond their original design intent to replace most of the 
unix-string-power manipulation and search utils into 1 prog.l  The new 
one is moving more toward AI and higher level
langs (my percept) as time goes on.  Seems like a new language offshoot, 
but it isn't being billed that way.

What do python folk think?  Issue? Non-ussue?  Mostly curious...

Linda




From ncoghlan at gmail.com  Sat Jun 21 13:56:06 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 21 Jun 2008 21:56:06 +1000
Subject: [Python-3000] Question to _users_ -- about over
	all	perceptions/feelings
In-Reply-To: <485CC459.50406@tlinx.org>
References: <485CC459.50406@tlinx.org>
Message-ID: <485CEC56.2090704@gmail.com>

Linda W. wrote:
> But *some* of thei things that may have attracted people to python or 
> perl in the first place may be items replaced.  Prints are no longer 
> builtin statements, but functions in standard function format.  Tends to 
> 'unbeautify' the code a bit.  A few other  regularizing features have a 
> similar effect, perhaps adding extra line-noise syntax where none was 
> needed before...

Care to give any examples of 'unbeautifying' other than the print 
statement -> print function conversion?

As to what I think will happen with adoption of Python 3... I think 2.x 
and 3.x will coexist quite happily for a number of years (at least until 
a 2.7 release, possibly even a 2.8).

Cheers,
Nick.

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

From jnoller at gmail.com  Sat Jun 21 14:10:59 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Sat, 21 Jun 2008 08:10:59 -0400
Subject: [Python-3000] Question to _users_ -- about over all
	perceptions/feelings
In-Reply-To: <485CEC56.2090704@gmail.com>
References: <485CC459.50406@tlinx.org> <485CEC56.2090704@gmail.com>
Message-ID: <F1CDA940-671E-4E16-896A-447874D6A4F4@gmail.com>



On Jun 21, 2008, at 7:56 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Linda W. wrote:
>> But *some* of thei things that may have attracted people to python  
>> or perl in the first place may be items replaced.  Prints are no  
>> longer builtin statements, but functions in standard function  
>> format.  Tends to 'unbeautify' the code a bit.  A few other   
>> regularizing features have a similar effect, perhaps adding extra  
>> line-noise syntax where none was needed before...
>
> Care to give any examples of 'unbeautifying' other than the print  
> statement -> print function conversion?

I would tend to disagree that the new print function is less "pretty"  
- I've actually found it to be more consistent and 'pretty' within the  
language. But YMMV.

>
> As to what I think will happen with adoption of Python 3... I think  
> 2.x and 3.x will coexist quite happily for a number of years (at  
> least until a 2.7 release, possibly even a 2.8).
>
> Cheers,
> Nick.
>
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> ---------------------------------------------------------------
>            http://www.boredomandlaziness.org
> _______________________________________________
> 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/jnoller%40gmail.com

From aahz at pythoncraft.com  Sat Jun 21 15:19:23 2008
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 21 Jun 2008 06:19:23 -0700
Subject: [Python-3000] Question to _users_ -- about over all
	perceptions/feelings
In-Reply-To: <485CC459.50406@tlinx.org>
References: <485CC459.50406@tlinx.org>
Message-ID: <20080621131923.GA18552@panix.com>

On Sat, Jun 21, 2008, Linda W. wrote:
> 
> This isn't meant to stir controversy -- I'm more curious than anything else.

This is the wrong place for this discussion.  Please use comp.lang.python
(gateway of python-list).
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

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

From solipsis at pitrou.net  Sat Jun 21 15:47:48 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 21 Jun 2008 13:47:48 +0000 (UTC)
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
References: <g3i2r8$l57$1@ger.gmane.org>
Message-ID: <loom.20080621T132808-171@post.gmane.org>

Neil Schemenauer <nas <at> arctrix.com> writes:
> I wonder if it would make sense to start installing the Python
> standard library as a .zip file by default.  Some benefits would be
> a tidier and more compact install and slightly faster startup times.

Are any users complaining about Python's install size?

As for startup time, do we have any eloquent data? For example, here
is with the current py3k on my machine:

$ time ./python -c ""
0.06user 0.00system 0:00.07elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1021minor)pagefaults 0swaps

> One downside is that it becomes more difficult to look at the source
> of modules.  That's an important feature of Python, especially for
> people learning the language.  
> 
> I think that downside could be mitigated by adding an option to
> pydoc that shows the source of a module.  For example, "pydoc -s
> bisect" could show the source for the bisect module.

When you have an unexpected traceback for instance it is pratical
to go and read the various source files participating in the traceback
without having to type lots of "pydoc -s" commands to get at the files.
(also, the traceback normally shows the exact path to the file, which
doesn't work if the sources are in a zip)

It is a common argument against setuptools' "zip by default" behaviour.



From python3now at gmail.com  Sat Jun 21 15:49:14 2008
From: python3now at gmail.com (James Thiele)
Date: Sat, 21 Jun 2008 06:49:14 -0700
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
In-Reply-To: <g3i2r8$l57$1@ger.gmane.org>
References: <g3i2r8$l57$1@ger.gmane.org>
Message-ID: <8f01efd00806210649h7ff3f28dhe5a8d4d363e9bd7e@mail.gmail.com>

I'm -1 on this as it would make more cumbersome to grep all the
modules looking for something.

James

On Fri, Jun 20, 2008 at 10:16 PM, Neil Schemenauer <nas at arctrix.com> wrote:
> I wonder if it would make sense to start installing the Python
> standard library as a .zip file by default.  Some benefits would be
> a tidier and more compact install and slightly faster startup times.
> One downside is that it becomes more difficult to look at the source
> of modules.  That's an important feature of Python, especially for
> people learning the language.
>
> I think that downside could be mitigated by adding an option to
> pydoc that shows the source of a module.  For example, "pydoc -s
> bisect" could show the source for the bisect module.
>
>  Neil
>
> _______________________________________________
> 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/python3now%40gmail.com
>

From barry at python.org  Sat Jun 21 16:19:36 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 21 Jun 2008 10:19:36 -0400
Subject: [Python-3000] Question to _users_ -- about over
	all	perceptions/feelings
In-Reply-To: <485CEC56.2090704@gmail.com>
References: <485CC459.50406@tlinx.org> <485CEC56.2090704@gmail.com>
Message-ID: <04459ECE-016C-4CA5-9807-6C2130ACEE8A@python.org>

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

On Jun 21, 2008, at 7:56 AM, Nick Coghlan wrote:

> Linda W. wrote:
>> But *some* of thei things that may have attracted people to python  
>> or perl in the first place may be items replaced.  Prints are no  
>> longer builtin statements, but functions in standard function  
>> format.  Tends to 'unbeautify' the code a bit.  A few other   
>> regularizing features have a similar effect, perhaps adding extra  
>> line-noise syntax where none was needed before...
>
> Care to give any examples of 'unbeautifying' other than the print  
> statement -> print function conversion?
>
> As to what I think will happen with adoption of Python 3... I think  
> 2.x and 3.x will coexist quite happily for a number of years (at  
> least until a 2.7 release, possibly even a 2.8).

At Pycon we discussed a model where there will be several lockstep 3.x  
and 2.x releases for the next few years.  Each time the focus for the  
2.x series will be to get closer and closer to 3.x while still  
maintaining backward compatibility.  Not that we have a specific plan  
on how to do this, but the idea is that at some point, it will be as  
easy to upgrade from 2.9 to 3.3 as it would be to upgrade to a 2.10.   
I know Guido hopes there will never /be/ a 2.10 but if it's called  
3.3, well... :)

So yes, I think we are going to have 2.x and 3.x living harmoniously  
for several years to come.

- -Barry

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

iQCVAwUBSF0N+HEjvBPtnXfVAQL4cgQAohK/u4l7JrV+tfyz8PLmsTKNY/29TMEf
LSJUsYFifLl6bGdspF18NyQIev4rnEFc62ti2TT36Fm7MPS8ffnrmNZQVNHCK0Lp
/2q02y1lfmQxf6++qN3Iqgdrkae39puzFaU0ZTzzroYV5uD6XP09er7ewCO/VVTB
Ft1Mq50fOl4=
=fQ0Z
-----END PGP SIGNATURE-----

From ncoghlan at gmail.com  Sat Jun 21 17:14:29 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 22 Jun 2008 01:14:29 +1000
Subject: [Python-3000] Question to _users_ -- about over all
	perceptions/feelings
In-Reply-To: <F1CDA940-671E-4E16-896A-447874D6A4F4@gmail.com>
References: <485CC459.50406@tlinx.org> <485CEC56.2090704@gmail.com>
	<F1CDA940-671E-4E16-896A-447874D6A4F4@gmail.com>
Message-ID: <485D1AD5.70200@gmail.com>

Jesse Noller wrote:
> On Jun 21, 2008, at 7:56 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Care to give any examples of 'unbeautifying' other than the print 
>> statement -> print function conversion?
> 
> I would tend to disagree that the new print function is less "pretty" - 
> I've actually found it to be more consistent and 'pretty' within the 
> language. But YMMV.

I personally feel the same way you do, but I can also see how folks 
might prefer the version without parentheses in some ways and hence 
consider this to be "uglier" in Python 3.

My question was more to do with the fact that I can't think of anything 
other than the print changes where anyone might even *consider* the Py3k 
approach to be uglier than the 2.x equivalent. Exception handlers are 
cleaner, metaclasses are cleaner, string-based formatting is cleaner 
(well, for named substitutions, anyway), dealing with unicode is cleaner 
(albeit compulsory now, rather than letting ASCII-only programmers 
strive to ignore its existence), dict views are cleaner than using lists 
for everything... *shrug* 3.0 code is definitely going to be *different* 
when compared to 2.x - but uglier? Nah.

Cheers,
Nick.

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

From guido at python.org  Sat Jun 21 17:24:56 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 21 Jun 2008 08:24:56 -0700
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
In-Reply-To: <8f01efd00806210649h7ff3f28dhe5a8d4d363e9bd7e@mail.gmail.com>
References: <g3i2r8$l57$1@ger.gmane.org>
	<8f01efd00806210649h7ff3f28dhe5a8d4d363e9bd7e@mail.gmail.com>
Message-ID: <ca471dc20806210824j49856063vb46bc9a6e71084c8@mail.gmail.com>

I think this would be a mistake by default -- being able to read the
source *easily* (i.e. without any specific tools) is part of Python's
success.

However I think it would be useful to support this better for more
easy creation of Python distributions embedded in other apps. E.g. at
my previous job we distributed an "agent" implemented in Python, and
for isolation purposes we bundled our own copy of Python. It would
have been nice if we could've bundled the stdlib as a zipfile instead.
(I know we could've done the work ourselves, but it wasn't a priority,
and this is a wheel that really doesn't need to be invented by
everyone on their own.) And no, Py2exe wouldn't have helped.

--Guido

On Sat, Jun 21, 2008 at 6:49 AM, James Thiele <python3now at gmail.com> wrote:
> I'm -1 on this as it would make more cumbersome to grep all the
> modules looking for something.
>
> James
>
> On Fri, Jun 20, 2008 at 10:16 PM, Neil Schemenauer <nas at arctrix.com> wrote:
>> I wonder if it would make sense to start installing the Python
>> standard library as a .zip file by default.  Some benefits would be
>> a tidier and more compact install and slightly faster startup times.
>> One downside is that it becomes more difficult to look at the source
>> of modules.  That's an important feature of Python, especially for
>> people learning the language.
>>
>> I think that downside could be mitigated by adding an option to
>> pydoc that shows the source of a module.  For example, "pydoc -s
>> bisect" could show the source for the bisect module.
>>
>>  Neil
>>
>> _______________________________________________
>> 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/python3now%40gmail.com
>>
> _______________________________________________
> 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/guido%40python.org
>



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

From ncoghlan at gmail.com  Sat Jun 21 17:37:00 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 22 Jun 2008 01:37:00 +1000
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
In-Reply-To: <g3i2r8$l57$1@ger.gmane.org>
References: <g3i2r8$l57$1@ger.gmane.org>
Message-ID: <485D201C.5040604@gmail.com>

Neil Schemenauer wrote:
> I wonder if it would make sense to start installing the Python
> standard library as a .zip file by default.  Some benefits would be
> a tidier and more compact install and slightly faster startup times.
> One downside is that it becomes more difficult to look at the source
> of modules.  That's an important feature of Python, especially for
> people learning the language.  
> 
> I think that downside could be mitigated by adding an option to
> pydoc that shows the source of a module.  For example, "pydoc -s
> bisect" could show the source for the bisect module.

Better to split the two questions I think, since I'd be +1 on having a 
way for pydoc to display the source code of an importable module, but -1 
on having the standard lib installed solely as a zip file by default 
(for the reasons Guido noted in his post).

Cheers,
Nick.

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

From tjreedy at udel.edu  Sat Jun 21 21:20:39 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 21 Jun 2008 15:20:39 -0400
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
In-Reply-To: <ca471dc20806210824j49856063vb46bc9a6e71084c8@mail.gmail.com>
References: <g3i2r8$l57$1@ger.gmane.org>	<8f01efd00806210649h7ff3f28dhe5a8d4d363e9bd7e@mail.gmail.com>
	<ca471dc20806210824j49856063vb46bc9a6e71084c8@mail.gmail.com>
Message-ID: <g3jka2$jie$1@ger.gmane.org>



Guido van Rossum wrote:
> I think this would be a mistake by default -- 
 > being able to read the
> source *easily* (i.e. without any specific tools) is part of Python's
> success.

For startup and import speed (and self-contained distributions),
do not we only need a zip of the .pyc files?
Not having those around would make browsing the .py files easier.
Could tracebacks be make to still work then?


From tjreedy at udel.edu  Sat Jun 21 21:44:21 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 21 Jun 2008 15:44:21 -0400
Subject: [Python-3000] Question to _users_ -- about over all
	perceptions/feelings
In-Reply-To: <485CC459.50406@tlinx.org>
References: <485CC459.50406@tlinx.org>
Message-ID: <g3jlmf$nef$1@ger.gmane.org>

1. Non-issue to me, real issues to some.

2. Wrong group, expecially if you want dissenting opinions ;-).

3. print: 3.0 normal 'file = xxx' is visually prettier than 2.x 
idiosyncratic line-noisy '>> xxx'.  I also prefer new 'except TypeError 
as t' to old 'except TypeError,t' since latter falsely implied some sort 
of equality of status.  To me, 3.0 is a conceptually cleaner and hence 
nicer language.

tjr


From guido at python.org  Sat Jun 21 22:22:06 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 21 Jun 2008 13:22:06 -0700
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
In-Reply-To: <g3jka2$jie$1@ger.gmane.org>
References: <g3i2r8$l57$1@ger.gmane.org>
	<8f01efd00806210649h7ff3f28dhe5a8d4d363e9bd7e@mail.gmail.com>
	<ca471dc20806210824j49856063vb46bc9a6e71084c8@mail.gmail.com>
	<g3jka2$jie$1@ger.gmane.org>
Message-ID: <ca471dc20806211322s6dc1c03an94b3706f51fe0570@mail.gmail.com>

On Sat, Jun 21, 2008 at 12:20 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Guido van Rossum wrote:
>>
>> I think this would be a mistake by default --
>
>> being able to read the
>>
>> source *easily* (i.e. without any specific tools) is part of Python's
>> success.
>
> For startup and import speed (and self-contained distributions),
> do not we only need a zip of the .pyc files?
> Not having those around would make browsing the .py files easier.
> Could tracebacks be make to still work then?

It's kind of tricky to have the .pyc files in a different place than
the .py files. The module search code isn't really geared towards that
ATM.

(PS. Please try to use positive phrasing next time -- I had a hard
time understanding your comment.)

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

From adlaiff6 at gmail.com  Sat Jun 21 23:48:05 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Sat, 21 Jun 2008 14:48:05 -0700
Subject: [Python-3000] RELEASED Python 2.6b1 and 3.0b1
In-Reply-To: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
References: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
Message-ID: <cc7430500806211448k5f25bdf3i458c7cb86bcba6b9@mail.gmail.com>

There is a typo on the download page (http://python.org/download/releases/3.0/):

"""The release plan is to have a series of alpha releases in 2007,
beta releases in 2008, and a final release in September 2008. The
alpha releases are primarily aimed at developers who want a sneak peek
at the new langauge, especially those folks who plan to port their
code to Python 3000. The hope is that by the time of the final
release, many 3rd party packages will already be available in a
3.0-compatible form.
"""

Should be

"""The release plan is to have a series of alpha releases in 2007,
beta releases in 2008, and a final release in September 2008. The
alpha releases are primarily aimed at developers who want a sneak peek
at the new *language*, especially those folks who plan to port their
code to Python 3000. The hope is that by the time of the final
release, many 3rd party packages will already be available in a
3.0-compatible form.
"""

(I really need to add my other e-mail address to these lists...sorry
if my first message got through to one of them and this is a dupe.)

--
Cheers,
Leif

From solipsis at pitrou.net  Sun Jun 22 00:15:29 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 21 Jun 2008 22:15:29 +0000 (UTC)
Subject: [Python-3000] PEP 3134 exception reporting
Message-ID: <loom.20080621T221035-434@post.gmane.org>


Hi,

I have implemented PEP 3134 exception reporting in http://bugs.python.org/issue3112
The code is fully functional but it needs a final clean-up and that clean-up
is awaiting answers to the following questions:

1) API visibility: should we expose a function PyErr_DisplaySingle in order 
to display an exception without chaining (while PyErr_Display displays
all chained exceptions)?

2) API change: should those two functions (PyErr_Display / PyErr_DisplaySingle)
be changed to return an integer result (0: success, -1: failure)? In any case
they would continue swallow all errors, the result code would just be a means
for the calling code to know whether everything went well.

3) Optional question: should be harmonize traceback formatting between built-in
reporting and reporting through traceback.py? Right now there is a small 
discrepancy in code lines indentation, see:

With built-in reporting:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "f.py", line 22, in raise_cause
inner_raise_cause()
  File "f.py", line 13, in inner_raise_cause
raise KeyError from e
KeyError

With traceback.py:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "f.py", line 22, in raise_cause
    inner_raise_cause()
  File "f.py", line 13, in inner_raise_cause
    raise KeyError from e
KeyError


Thanks in advance for your advice

Antoine.



From barry at python.org  Sun Jun 22 00:55:33 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 21 Jun 2008 18:55:33 -0400
Subject: [Python-3000] RELEASED Python 2.6b1 and 3.0b1
In-Reply-To: <cc7430500806211445n52252bceq615e0220d0f1fc15@mail.gmail.com>
References: <1972109D-735D-4485-82F4-9BC8F2984967@python.org>
	<cc7430500806211445n52252bceq615e0220d0f1fc15@mail.gmail.com>
Message-ID: <ACE6F895-8D64-4703-B3ED-7D5BC850A639@python.org>

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

On Jun 21, 2008, at 5:45 PM, Leif Walsh wrote:

> There is a typo on the download page (http://python.org/download/releases/3.0/ 
> ):

Fixed, thanks!
- -Barry

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

iQCVAwUBSF2G5nEjvBPtnXfVAQJbqwQAkEMtWMYdsMFWnGmQCrpEV3BXZGipmZQs
7dnWoJIVsjN7pBY/5aVMiQEl5JM3n8IdVpwZMWM9Q+VHgkB04u8f7/wS2xmR7XsA
dySDMrxUJXqXX1ze/vWKosp39Yvey6HeTsiOUzvnXjS6IKM757IhyB94o4KQF69K
mOS8tjydwE8=
=cY+d
-----END PGP SIGNATURE-----

From ncoghlan at gmail.com  Sun Jun 22 03:49:44 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 22 Jun 2008 11:49:44 +1000
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
In-Reply-To: <ca471dc20806211322s6dc1c03an94b3706f51fe0570@mail.gmail.com>
References: <g3i2r8$l57$1@ger.gmane.org>	<8f01efd00806210649h7ff3f28dhe5a8d4d363e9bd7e@mail.gmail.com>	<ca471dc20806210824j49856063vb46bc9a6e71084c8@mail.gmail.com>	<g3jka2$jie$1@ger.gmane.org>
	<ca471dc20806211322s6dc1c03an94b3706f51fe0570@mail.gmail.com>
Message-ID: <485DAFB8.5020404@gmail.com>

Guido van Rossum wrote:
> On Sat, Jun 21, 2008 at 12:20 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> For startup and import speed (and self-contained distributions),
>> do not we only need a zip of the .pyc files?
>> Not having those around would make browsing the .py files easier.
>> Could tracebacks be make to still work then?
> 
> It's kind of tricky to have the .pyc files in a different place than
> the .py files. The module search code isn't really geared towards that
> ATM.

I'll second that "kind of tricky" comment.

Setting the basics up isn't that hard (we'd simply have to have the 
zipfile of .pyc files ahead of the directory of source files on 
sys.path), but doing so has the consequence that editing the source 
files no longer has any effect. The import machinery will find the pyc 
files first, and then stop looking.

If people are genuinely interested in this kind of thing, I suggest they 
talk to Brett about helping out with his import_in_py branch for 
2.7/3.1. Many things should become possible once we no longer need to 
babysit the code in import.c :)

Cheers,
Nick.


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

From python at tlinx.org  Sun Jun 22 09:25:46 2008
From: python at tlinx.org (Linda W.)
Date: Sun, 22 Jun 2008 00:25:46 -0700
Subject: [Python-3000] Q's 2 U's; Perceptions, growing into langs
Message-ID: <485DFE7A.3030107@tlinx.org>

>  Care to give any examples of 'unbeautifying' other than the print

> statement -> print function conversion?
???Care to?...not really :-)  I __really__ am not familiar enough with 
python, let alone the differences between the versions.
I tried to find a concise list of differences, but while I found long 
descriptions that were readable, I wasn't finding a full set of 
differences -- but part of that was, I believe, the incremental way Py3 
as been developed. 

I may be projecting more about my differences on perl versions than python.

> I would tend to disagree that the new print function is less "pretty" 
> - I've actually found it to be more consistent and 'pretty' within the 
> language. But YMMV.
----  
Ahhh....welll you know what they say, beauty is in the eye of the 
beholder. One of the things I thought was attractive about python is its 
cleanness -- from the perspective of it being nearly opposite of perl 
(which I like alot, BTW, so not trying to rag on it).  In that I mean 
how perl has more than once been described by some as looking like 'line 
noise'...:-)

>> As to what I think will happen with adoption of Python 3... I think 
>> 2.x and 3.x will coexist quite happily for a number of years (at 
>> least until a 2.7 release, possibly even a 2.8).
----
   That's what the perl folk claim somewhat of Pl5/Pl6.  But I was 
around for the Pl3-Pl4, Pl4-Pl5 transitions...I know Pl3 and Pl4 code 
could easily, often with no changes, run under Pl5 --  but Pl6 -- wish 
the creator when with a different language name so
Pl5 could evolve to fill in its gaps and holes -- but naming the new 
language is "Pl6" was intentional on L'Wall's part -- he specifically 
said he wanted to get the notoriety associated with Perl5 associated 
with his new language.  Also, IMO, deliberately or not, I think it is 
meant to bring a none-too-subtle end to Pl5 as a living, developing 
language.   But maybe Larry really reached the end of his creative 
'ropes' in trying to evolve Pl5 and just gave up the ghost by going with 
a new lang.

   Took me years before I started actually using Pl5-features like the 
object orientation (most of my p4 work had been mostly using it as a 
quick script/filter language).  When I sat down to actually try to use 
Pl5's OO features and use it as a higher-level lang (and not just a 
scripting lang), I began to run into its limitations -- and things I 
missed about high-level langs that seem to be more limited to compiled 
languages...  

I'm happy to hear there isn't the same type of schism in the Python 
community -- sounds like most things should just continue to 
'evolve'...with, what it sounds like, more 'gentle' paths to grown 
between the levels.  Hopefully Python won't hit the wall in another 8-12 
years and need a similar restart.  But we all  know what happens when 
you hang too much on to past compatibility -- you get Windows (and 
become some of the richest people on the planet...)...  compatibility 
over 'new' or 'better' seems to be what the market favors (even though 
it agreeably may not be the best technical choice).  But such are the 
limitations of a 'free market system'... 

It seemed like some of Py3's development and feature changes happened 
over a long time -- but not sure where they came from, where pl6 -- 
seems to be a complete semantic and source rewrite.  Not that the end 
result may not be good, but neither is it remotely pl5 compatible.

I do keep nudging at getting into doing something with python other than 
'hello universe', but I love all the 'verbs' in perl -- and having alot 
of experience in the environment many of those 'verbs' came from (unix 
cmd-line tools), it just feels natural to optimize 'shell' tasks into 
perl scripts... 

   But that's the area of perl-shine.  quick scripts that I can build 
up via repetitive re-edits of a previous 'line' -- under 'bash', 
(cmdline): execute, see if I am getting output I want from whatever the 
input was, no?  ESC, edit line, try again -- can have an entire little 
'1-line filter (multistatements)'.  Usually throw-aways...but if useful 
enough, can write them to a file to save and/or do proper indenting on 
them.  .

I miss that type of interactive development on the cmdline with python.  
Any thought ever been given to  allowing a cmd-line friendly syntax?  
I'm not wanting an attack or religious discussion here, BTW (**1).  But 
was thinking along the lines of something where statements could be 
separated by semi's (or embedded newlines) and indentation could be done 
using braces.
Something like (in 'bogo'-syntax):
<pipein>|\
py -e 'e=sub(x,y){x**y}; while((x,y)=<inline>) { outln (x  "**" y " = " 
e(x,y) ) }' |\
<etc>
....
I can't speak for everyone, but as someone who uses the cmdline "alot", 
it would make it much easier for me to learn and try out python "little 
bits" a time...from the cmdline...
little filter here, little filter there...etc.  then maybe they grow.  
Could even have a
python 'pretty printer' that got rid of all curly brackets and replaced 
them with
a user-specifiable amount of indentation.  The reverse might have other 
uses...dunno...

Certainly would provide a *less-steep* learning curve if one could start 
with 1-liners on the cmdline.  Not that I'd want to be able to play 
with/ and start using little snippets till I got
more comfy with syntax and standard libraries.

Perhaps I don't need to say it -- but going into a 'mode' (like a python 
interpreter
with a prompt) doesn't count as cmd-line usage.  You've still entered a 
non-command
line, special environment.


> >> BTW -- is there a CPyAN similar to perl's CP[l]AN?  Curious. <<<


Like someone said in the replies -- this list may not be the best place 
to get 'balanced' input.  Certainly -- as I *stress*....not looking to 
start 'arguments' or such...just getting input/'vague' impressions...

   Thanks for the feedback...I "hope" it was representative of the bulk 
of the Pythonisti (pythonistae?) :-) (pythonistas sounds too much like a 
south-american terrorist group... :-)

Linda

(**1) - not wanting a religious discussion here on the pluses/minus of 
enforced
   syntax. I admit, the last time I programmed in a language where 
white-space
   and columns were meaningful and essential was in a a college course 
running
   on a mainframe where the standard input was a punched cards).




From g.brandl at gmx.net  Sun Jun 22 11:07:10 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 22 Jun 2008 11:07:10 +0200
Subject: [Python-3000] PEP 3134 exception reporting
In-Reply-To: <loom.20080621T221035-434@post.gmane.org>
References: <loom.20080621T221035-434@post.gmane.org>
Message-ID: <g3l4o7$pdl$2@ger.gmane.org>

Antoine Pitrou schrieb:

> 3) Optional question: should be harmonize traceback formatting between built-in
> reporting and reporting through traceback.py? Right now there is a small 
> discrepancy in code lines indentation, see:
> 
> With built-in reporting:
> 
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "f.py", line 22, in raise_cause
> inner_raise_cause()
>   File "f.py", line 13, in inner_raise_cause
> raise KeyError from e
> KeyError
> 
> With traceback.py:
> 
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "f.py", line 22, in raise_cause
>     inner_raise_cause()
>   File "f.py", line 13, in inner_raise_cause
>     raise KeyError from e
> KeyError

This is how it should be, since 2.x does it like this for built-in and
traceback.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From ncoghlan at gmail.com  Sun Jun 22 14:25:36 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 22 Jun 2008 22:25:36 +1000
Subject: [Python-3000] Q's 2 U's; Perceptions, growing into langs
In-Reply-To: <485DFE7A.3030107@tlinx.org>
References: <485DFE7A.3030107@tlinx.org>
Message-ID: <485E44C0.3050403@gmail.com>

Linda W. wrote:
<off-topic things>

Your original post was at best only arguably on-topic for this list - 
your most recent reply is now well and truly off-topic. Please take any 
further discussion/questions to comp.lang.python 
(python-list at python.org) or to python-ideas at python.org

Regards,
Nick.

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

From solipsis at pitrou.net  Sun Jun 22 22:25:06 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 22 Jun 2008 20:25:06 +0000 (UTC)
Subject: [Python-3000] =?utf-8?q?PyException=5FSet=7BTraceback=2CCause=2CC?=
	=?utf-8?q?ontext=7D?=
Message-ID: <loom.20080622T202019-660@post.gmane.org>


Hi,

I don't know who designed that API but what is the reason for
PyException_Set{Traceback,Cause,Context} not to INCREF their argument? It means
the caller has to do it himself, and seems inconsistent with most of Python's C
API. Is it too late to change those functions to do the right thing?

Regards

Antoine.



From guido at python.org  Mon Jun 23 02:32:41 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 22 Jun 2008 17:32:41 -0700
Subject: [Python-3000] PyException_Set{Traceback,Cause,Context}
In-Reply-To: <loom.20080622T202019-660@post.gmane.org>
References: <loom.20080622T202019-660@post.gmane.org>
Message-ID: <ca471dc20806221732m22ef6b16lc63da7c27bfe32e8@mail.gmail.com>

On Sun, Jun 22, 2008 at 1:25 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> I don't know who designed that API but what is the reason for
> PyException_Set{Traceback,Cause,Context} not to INCREF their argument? It means
> the caller has to do it himself, and seems inconsistent with most of Python's C
> API. Is it too late to change those functions to do the right thing?

I'm guessing Collin Winter designed it when he implemented the first
half of PEP 3134. (There is no mention of these APIs in the PEP.)
Looking at the source code it looks like all the cases so far where
these are actually used, this API is actually fortunate -- in all
cases I've found the ownership for the argument needs to be passed
into the exception object anyway.

There are some precedents, e.g. PyList_SetItem().

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

From greg.ewing at canterbury.ac.nz  Mon Jun 23 03:25:03 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 23 Jun 2008 13:25:03 +1200
Subject: [Python-3000] PyException_Set{Traceback,Cause,Context}
In-Reply-To: <loom.20080622T202019-660@post.gmane.org>
References: <loom.20080622T202019-660@post.gmane.org>
Message-ID: <485EFB6F.2010504@canterbury.ac.nz>

Antoine Pitrou wrote:
> what is the reason for
> PyException_Set{Traceback,Cause,Context} not to INCREF their argument?

Probably because the vast majority of the time the
caller is not doing anything further with these
references, so this arrangement saves some increfs
and decrefs.

-- 
Greg

From collinw at gmail.com  Mon Jun 23 03:43:24 2008
From: collinw at gmail.com (Collin Winter)
Date: Sun, 22 Jun 2008 18:43:24 -0700
Subject: [Python-3000] PyException_Set{Traceback,Cause,Context}
In-Reply-To: <ca471dc20806221732m22ef6b16lc63da7c27bfe32e8@mail.gmail.com>
References: <loom.20080622T202019-660@post.gmane.org>
	<ca471dc20806221732m22ef6b16lc63da7c27bfe32e8@mail.gmail.com>
Message-ID: <43aa6ff70806221843w3c920691m5190956dc582e317@mail.gmail.com>

On Sun, Jun 22, 2008 at 5:32 PM, Guido van Rossum <guido at python.org> wrote:
> On Sun, Jun 22, 2008 at 1:25 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> I don't know who designed that API but what is the reason for
>> PyException_Set{Traceback,Cause,Context} not to INCREF their argument? It means
>> the caller has to do it himself, and seems inconsistent with most of Python's C
>> API. Is it too late to change those functions to do the right thing?
>
> I'm guessing Collin Winter designed it when he implemented the first
> half of PEP 3134. (There is no mention of these APIs in the PEP.)
> Looking at the source code it looks like all the cases so far where
> these are actually used, this API is actually fortunate -- in all
> cases I've found the ownership for the argument needs to be passed
> into the exception object anyway.

Correct. I'll add these to the PEP/C API docs.

Collin

> There are some precedents, e.g. PyList_SetItem().
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> 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/collinw%40gmail.com
>

From skip at pobox.com  Mon Jun 23 04:54:12 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 22 Jun 2008 21:54:12 -0500
Subject: [Python-3000] "make (alt)?install" with all the recent structural
	changes
Message-ID: <18527.4180.681839.238964@montanaro-dyndns-org.local>


I'm guessing we should be in the habit of zapping our Python 3.0
installations before executing "make (alt)?install", correct?  Looking at my
local Py3k install I see both urllib the package and urllib the module:

    % find /Users/skip/local/lib/python3.0 -name 'urllib*'
    /Users/skip/local/lib/python3.0/urllib
    /Users/skip/local/lib/python3.0/urllib.py
    /Users/skip/local/lib/python3.0/urllib.pyc
    /Users/skip/local/lib/python3.0/urllib.pyo
    /Users/skip/local/lib/python3.0/urllib2.py
    /Users/skip/local/lib/python3.0/urllib2.pyc
    /Users/skip/local/lib/python3.0/urllib2.pyo

Just an FYI more than anything else.

Skip

From nick at craig-wood.com  Mon Jun 23 13:07:00 2008
From: nick at craig-wood.com (Nick Craig-Wood)
Date: Mon, 23 Jun 2008 12:07:00 +0100
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
In-Reply-To: <loom.20080621T132808-171@post.gmane.org>
References: <g3i2r8$l57$1@ger.gmane.org>
	<loom.20080621T132808-171@post.gmane.org>
Message-ID: <20080623110701.3A2C414C6F2@irishsea.home.craig-wood.com>

Antoine Pitrou <solipsis at pitrou.net> wrote:
>  Neil Schemenauer <nas <at> arctrix.com> writes:
> > I wonder if it would make sense to start installing the Python
> > standard library as a .zip file by default.  Some benefits would be
> > a tidier and more compact install and slightly faster startup times.
> 
>  Are any users complaining about Python's install size?
> 
>  As for startup time, do we have any eloquent data? For example, here
>  is with the current py3k on my machine:
> 
>  $ time ./python -c ""
>  0.06user 0.00system 0:00.07elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
>  0inputs+0outputs (0major+1021minor)pagefaults 0swaps

That is for a warm cache.

If you drop your caches first (like this under linux) you get quite a
different story...

$ sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
$ time python -c ""

real    0m1.393s
user    0m0.004s
sys     0m0.004s
$ time python -c ""

real    0m0.007s
user    0m0.004s
sys     0m0.004s

I imagine having the stdlib in one .zip will stop lots of seeking and
improve the first time.

> > One downside is that it becomes more difficult to look at the source
> > of modules.  That's an important feature of Python, especially for
> > people learning the language.  
> > 
> > I think that downside could be mitigated by adding an option to
> > pydoc that shows the source of a module.  For example, "pydoc -s
> > bisect" could show the source for the bisect module.
> 
>  When you have an unexpected traceback for instance it is pratical
>  to go and read the various source files participating in the traceback
>  without having to type lots of "pydoc -s" commands to get at the files.
>  (also, the traceback normally shows the exact path to the file, which
>  doesn't work if the sources are in a zip)
> 
>  It is a common argument against setuptools' "zip by default"
>  behaviour.

I like the idea of "pydoc -s" on its own.  I often want to look at the
source of modules, and end up typing "locate pymodule" then looking
through the list of files first before looking at it.  "pydoc -s
pymodule" would be much easier!

-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick

From phd at phd.pp.ru  Mon Jun 23 13:46:05 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Mon, 23 Jun 2008 15:46:05 +0400
Subject: [Python-3000] stdlib as .zip by default
In-Reply-To: <20080623110701.3A2C414C6F2@irishsea.home.craig-wood.com>
References: <g3i2r8$l57$1@ger.gmane.org>
	<loom.20080621T132808-171@post.gmane.org>
	<20080623110701.3A2C414C6F2@irishsea.home.craig-wood.com>
Message-ID: <20080623114605.GC27051@phd.pp.ru>

On Mon, Jun 23, 2008 at 12:07:00PM +0100, Nick Craig-Wood wrote:
> I imagine having the stdlib in one .zip will stop lots of seeking and
> improve the first time.

   Instead of seeking in the filesystem you end up seeking in the zip. Why
do you expect it'd be faster?

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

From solipsis at pitrou.net  Mon Jun 23 14:23:37 2008
From: solipsis at pitrou.net (Antoine)
Date: Mon, 23 Jun 2008 14:23:37 +0200 (CEST)
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
In-Reply-To: <20080623110701.3A2C414C6F2@irishsea.home.craig-wood.com>
References: <g3i2r8$l57$1@ger.gmane.org>
	<loom.20080621T132808-171@post.gmane.org>
	<20080623110701.3A2C414C6F2@irishsea.home.craig-wood.com>
Message-ID: <444414cd30d147bb9d13d9386d21b434.squirrel@webmail.nerim.net>

> Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> That is for a warm cache.
>
> If you drop your caches first (like this under linux) you get quite a
> different story...
>
> $ sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
> $ time python -c ""
>
> real    0m1.393s
> user    0m0.004s
> sys     0m0.004s

But still that's only one second for the worst case where nothing is in
the filesystem cache (I suppose it would be higher under Windows). You
won't find lots of programs which launch in less than one second when none
of their dependent files are in FS cache.

> I imagine having the stdlib in one .zip will stop lots of seeking and
> improve the first time.

Someone would have to test it to know the extent of the improvement.



From guido at python.org  Mon Jun 23 18:05:35 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Jun 2008 09:05:35 -0700
Subject: [Python-3000] stdlib as .zip by default, pydoc to view source?
In-Reply-To: <444414cd30d147bb9d13d9386d21b434.squirrel@webmail.nerim.net>
References: <g3i2r8$l57$1@ger.gmane.org>
	<loom.20080621T132808-171@post.gmane.org>
	<20080623110701.3A2C414C6F2@irishsea.home.craig-wood.com>
	<444414cd30d147bb9d13d9386d21b434.squirrel@webmail.nerim.net>
Message-ID: <ca471dc20806230905v5910c72cm658613d1e51c30b@mail.gmail.com>

It's not the cost of starting up an empty Python. It's the cost of
loading the tons of stuff that every app uses.

Trust me, zip files *do* make for much speedier app startup times.
It's been tested many times.

--Guido

On Mon, Jun 23, 2008 at 5:23 AM, Antoine <solipsis at pitrou.net> wrote:
>> Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>> That is for a warm cache.
>>
>> If you drop your caches first (like this under linux) you get quite a
>> different story...
>>
>> $ sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
>> $ time python -c ""
>>
>> real    0m1.393s
>> user    0m0.004s
>> sys     0m0.004s
>
> But still that's only one second for the worst case where nothing is in
> the filesystem cache (I suppose it would be higher under Windows). You
> won't find lots of programs which launch in less than one second when none
> of their dependent files are in FS cache.
>
>> I imagine having the stdlib in one .zip will stop lots of seeking and
>> improve the first time.
>
> Someone would have to test it to know the extent of the improvement.
>
>
> _______________________________________________
> 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/guido%40python.org
>



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

From brett at python.org  Mon Jun 23 19:04:37 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 23 Jun 2008 10:04:37 -0700
Subject: [Python-3000] stdlib as .zip by default
In-Reply-To: <20080623114605.GC27051@phd.pp.ru>
References: <g3i2r8$l57$1@ger.gmane.org>
	<loom.20080621T132808-171@post.gmane.org>
	<20080623110701.3A2C414C6F2@irishsea.home.craig-wood.com>
	<20080623114605.GC27051@phd.pp.ru>
Message-ID: <bbaeab100806231004k617e63rbf6ede77791b5cfa@mail.gmail.com>

On Mon, Jun 23, 2008 at 4:46 AM, Oleg Broytmann <phd at phd.pp.ru> wrote:
> On Mon, Jun 23, 2008 at 12:07:00PM +0100, Nick Craig-Wood wrote:
>> I imagine having the stdlib in one .zip will stop lots of seeking and
>> improve the first time.
>
>   Instead of seeking in the filesystem you end up seeking in the zip. Why
> do you expect it'd be faster?
>

I am going to guess Nick meant seeking in terms of "looking in the
filesystem for a file", e.g. less stat calls.

-Brett

From phd at phd.pp.ru  Mon Jun 23 19:08:12 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Mon, 23 Jun 2008 21:08:12 +0400
Subject: [Python-3000] stdlib as .zip by default
In-Reply-To: <bbaeab100806231004k617e63rbf6ede77791b5cfa@mail.gmail.com>
References: <g3i2r8$l57$1@ger.gmane.org>
	<loom.20080621T132808-171@post.gmane.org>
	<20080623110701.3A2C414C6F2@irishsea.home.craig-wood.com>
	<20080623114605.GC27051@phd.pp.ru>
	<bbaeab100806231004k617e63rbf6ede77791b5cfa@mail.gmail.com>
Message-ID: <20080623170812.GA11279@phd.pp.ru>

On Mon, Jun 23, 2008 at 10:04:37AM -0700, Brett Cannon wrote:
> On Mon, Jun 23, 2008 at 4:46 AM, Oleg Broytmann <phd at phd.pp.ru> wrote:
> > On Mon, Jun 23, 2008 at 12:07:00PM +0100, Nick Craig-Wood wrote:
> >> I imagine having the stdlib in one .zip will stop lots of seeking and
> >> improve the first time.
> >
> >   Instead of seeking in the filesystem you end up seeking in the zip. Why
> > do you expect it'd be faster?
> 
> I am going to guess Nick meant seeking in terms of "looking in the
> filesystem for a file", e.g. less stat calls.

   Less stat calls in exchange for seeking in the zip "filesystem" plus
decompression. IWBN if someone shows real numbers...

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

From tjreedy at udel.edu  Mon Jun 23 21:04:14 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 23 Jun 2008 15:04:14 -0400
Subject: [Python-3000] stdlib as .zip by default
In-Reply-To: <20080623170812.GA11279@phd.pp.ru>
References: <g3i2r8$l57$1@ger.gmane.org>	<loom.20080621T132808-171@post.gmane.org>	<20080623110701.3A2C414C6F2@irishsea.home.craig-wood.com>	<20080623114605.GC27051@phd.pp.ru>	<bbaeab100806231004k617e63rbf6ede77791b5cfa@mail.gmail.com>
	<20080623170812.GA11279@phd.pp.ru>
Message-ID: <g3os3f$frq$1@ger.gmane.org>



Oleg Broytmann wrote:

>    Less stat calls in exchange for seeking in the zip "filesystem" plus
> decompression. IWBN if someone shows real numbers...

Decompression time is balanced, probably more than balanced, by shorter 
disk reading times.  In the last twenty years, cpus have speed up much 
more than disks, so tradeoffs have changed.


From nick at craig-wood.com  Mon Jun 23 23:16:57 2008
From: nick at craig-wood.com (Nick Craig-Wood)
Date: Mon, 23 Jun 2008 22:16:57 +0100
Subject: [Python-3000] stdlib as .zip by default
In-Reply-To: <g3os3f$frq$1@ger.gmane.org> <20080623170812.GA11279@phd.pp.ru>
References: <20080623114605.GC27051@phd.pp.ru>
	<bbaeab100806231004k617e63rbf6ede77791b5cfa@mail.gmail.com>
	<20080623170812.GA11279@phd.pp.ru> <g3os3f$frq$1@ger.gmane.org>
	<g3i2r8$l57$1@ger.gmane.org>
	<loom.20080621T132808-171@post.gmane.org>
	<20080623110701.3A2C414C6F2@irishsea.home.craig-wood.com>
	<20080623114605.GC27051@phd.pp.ru>
	<bbaeab100806231004k617e63rbf6ede77791b5cfa@mail.gmail.com>
	<20080623170812.GA11279@phd.pp.ru>
Message-ID: <20080623211657.GA28097@craig-wood.com>

On Mon, Jun 23, 2008 at 09:08:12PM +0400, Oleg Broytmann wrote:
> On Mon, Jun 23, 2008 at 10:04:37AM -0700, Brett Cannon wrote:
> > On Mon, Jun 23, 2008 at 4:46 AM, Oleg Broytmann <phd at phd.pp.ru> wrote:
> > > On Mon, Jun 23, 2008 at 12:07:00PM +0100, Nick Craig-Wood wrote:
> > >> I imagine having the stdlib in one .zip will stop lots of seeking and
> > >> improve the first time.
> > >
> > >   Instead of seeking in the filesystem you end up seeking in the zip. Why
> > > do you expect it'd be faster?
> > 
> > I am going to guess Nick meant seeking in terms of "looking in the
> > filesystem for a file", e.g. less stat calls.

Yes!  Your disk can read consecutive sectors off the disk at 50 MB/s
but it still takes an achingly long 10ms to seek to a different place
on the disk.  If you've got 100 files to read then that could be 1
second of wasted time.  Now it won't be that bad normally because
filesystems tend to cluster files that were written at the same time
but it makes a lot of difference.

If your files are in a nice big zip then there is much less seeking

>    Less stat calls in exchange for seeking in the zip "filesystem" plus
> decompression.

The zip filesystem is all layed out in one file which is very likely
to be contiguous on the disk and available for reading at full disk
speed.

> IWBN if someone shows real numbers...

Real numbers would be nice!

On Mon, Jun 23, 2008 at 03:04:14PM -0400, Terry Reedy wrote:
> Decompression time is balanced, probably more than balanced, by shorter  
> disk reading times.  In the last twenty years, cpus have speed up much  
> more than disks, so tradeoffs have changed.

I agree.

In a recent upgrade my linux computer got compressed suspend to disk
support.  It now unsuspends in about half the time showing that
decompression is much faster than disk reading.

-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick

From greg.ewing at canterbury.ac.nz  Tue Jun 24 03:31:10 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 24 Jun 2008 13:31:10 +1200
Subject: [Python-3000] stdlib as .zip by default
In-Reply-To: <20080623114605.GC27051@phd.pp.ru>
References: <g3i2r8$l57$1@ger.gmane.org>
	<loom.20080621T132808-171@post.gmane.org>
	<20080623110701.3A2C414C6F2@irishsea.home.craig-wood.com>
	<20080623114605.GC27051@phd.pp.ru>
Message-ID: <48604E5E.8070008@canterbury.ac.nz>

Oleg Broytmann wrote:
>    Instead of seeking in the filesystem you end up seeking in the zip. Why
> do you expect it'd be faster?

It might help if everything the interpeter needs during
startup could be grouped together in the zip file, so
that it's spread over less disk blocks.

-- 
Greg

From orivej at yandex.ru  Fri Jun 20 06:47:26 2008
From: orivej at yandex.ru (Georgij Kondratjev)
Date: Fri, 20 Jun 2008 08:47:26 +0400
Subject: [Python-3000] failed to compile Python-3.0b1 with gcc-4.3.0:
	Fatal Python error: Py_Initialize: can't initialize sys
	standard streams
In-Reply-To: <1afaf6160806191904y8b09d48n94a731aed342e84c@mail.gmail.com>
References: <20080620011858.A7D0BF88C@mail.blueline.mg>
	<1afaf6160806191904y8b09d48n94a731aed342e84c@mail.gmail.com>
Message-ID: <200806200847.26196.orivej@yandex.ru>

On Friday 20 June 2008 06:04:44 Benjamin Peterson wrote:
> On Thu, Jun 19, 2008 at 8:18 PM, nirinA raseliarison
>
> <nirina at mail.blueline.mg> wrote:
> > hello all,
> > i tried to build Python3.0b1 but the make process hangs
> > while running:
>
> Building with gcc 4.3 is buggy. See
> http://mail.python.org/pipermail/python-3000/2008-April/012965.html.

Only with gcc 4.3.0. The problem was fixed in 4.3.1.
If you really want to compile python with gcc 4.3.0,
do something like
export CC="gcc $CFLAGS -fno-tree-vrp"

From vizcaynot at gmail.com  Sat Jun 21 04:34:30 2008
From: vizcaynot at gmail.com (Vizcayno)
Date: Fri, 20 Jun 2008 19:34:30 -0700 (PDT)
Subject: [Python-3000] Some problems with urllib
Message-ID: <1d220b6d-0177-43ab-8790-d6301aa6d7bf@25g2000hsx.googlegroups.com>

For Windows XP SP3:

.python
Python 3.0b1 (r30b1:64403M, Jun 19 2008, 14:56:09) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib
>>> opener = urllib.FancyURLopener({})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'FancyURLopener'
>>> dir(urllib)
['__builtins__', '__doc__', '__file__', '__name__', '__package__',
'__path__']
>>>

From ncoghlan at gmail.com  Tue Jun 24 14:22:54 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Jun 2008 22:22:54 +1000
Subject: [Python-3000] Some problems with urllib
In-Reply-To: <1d220b6d-0177-43ab-8790-d6301aa6d7bf@25g2000hsx.googlegroups.com>
References: <1d220b6d-0177-43ab-8790-d6301aa6d7bf@25g2000hsx.googlegroups.com>
Message-ID: <4860E71E.3020705@gmail.com>

The last of the PEP 3108 (standard lib reorg) changes landed for the 
first beta, so urllib is now a package of assorted URL related modules.

 >>> import urllib
 >>> help(urllib)
Help on package urllib:

NAME
     urllib

FILE
     /home/ncoghlan/devel/py3k/Lib/urllib/__init__.py

PACKAGE CONTENTS
     error
     parse
     request
     response
     robotparser

DATA
     __package__ = None


 >>> import urllib.request
 >>> opener = urllib.request.FancyURLopener({})

(Hmm pydoc shouldn't be displaying __package__ as a DATA entry, since 
PEP 361 means that all modules now have it by default... issue 3190 
created for that)

Cheers,
Nick.

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

From charles.merriam at gmail.com  Tue Jun 24 21:40:31 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Tue, 24 Jun 2008 12:40:31 -0700
Subject: [Python-3000] Assert syntax change...
In-Reply-To: <48115A5E.9030302@gmail.com>
References: <b8c6f6c40804240227k55a6c39axad218a7c2b69d40d@mail.gmail.com>
	<ca471dc20804241137i2f9a6eb3x3e8441f65562d0f4@mail.gmail.com>
	<loom.20080424T204744-398@post.gmane.org>
	<ca471dc20804241401w5b394bbbibb8772819cfd295b@mail.gmail.com>
	<b8c6f6c40804241413l4207c1eet3eda671abf934b47@mail.gmail.com>
	<48115A5E.9030302@gmail.com>
Message-ID: <b8c6f6c40806241240y6a137b50m9c452bf3cb951046@mail.gmail.com>

Sorry to bring up the old assert syntax issue; I wanted to clarify it
before explaining to someone.

For:  assert expr, message_expr

It seems to be left at:
1.  The assert statement is left unchanged in 3.0.
2.  Asserting a tuple now creates a _compile time_ warning to try to
prevent assert(expr,message_expr).
3.  "assert expr, message_expr" is roughly equivalent to "if (expr):
raise AssertionError(message_expr)"
4.  The "as" keyword ("assert expr as message") was decided against
because it did not appear as the
     message renamed the expression.  Counter argument was that it did
rename expr to message_expr as
     original expr was lost.
5.  assert cannot be a function call, because message_expr is not
evaluated unless expr is false.
6.  There was some wish for assert to have a function call for ease of
debuggers, that is, "if (expr):  raise_assert(message_expr)".  No one
was too interested.

Did I miss anything?  I like problems to have accurate final solutions.

Thanks for the time,

Charles


On Thu, Apr 24, 2008 at 9:13 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Charles Merriam wrote:
>>
>> On Thu, Apr 24, 2008 at 2:01 PM, Guido van Rossum <guido at python.org>
>> wrote:
>>>
>>> On Thu, Apr 24, 2008 at 1:51 PM, Mikhail Glushenkov
>>>>
>>>>  Why not make ``assert`` a built-in function then?
>>>
>>>  Because then it can't be disabled by the compiler in -O mode.
>>
>> A reasonable conclusion, but needs better reasoning.  One could
>> certainly do an:
>>    assert_stmt        ::=     "assert" (expression ["," expression])
>> and implement it, when there isn't a -O, as:
>>    __assert__(expression, message=None)  # built-in
>
> Hmm, having an __assert__ builtin might be nice regardless - easier to have
> assertions in test suites that are executed regardless of -0, instead of
> every different Python test suite having to include its own function to wrap
> 'raise AssertionError(message)'.
>
> Independently of that, changing assert to allow surrounding parentheses
> (similar to the name list in a from module import name-list style import
> statement) would also be convenient for longer expressions or error
> messages.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> ---------------------------------------------------------------
>            http://www.boredomandlaziness.org
>

From nirina at mail.blueline.mg  Thu Jun 26 21:20:18 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Thu, 26 Jun 2008 22:20:18 +0300 (EAT)
Subject: [Python-3000] failed to compile Python-3.0b1 with gcc-4.3.0:
	Fatal Python error:	Py_Initialize: can't initialize sys
	standard streams]
Message-ID: <20080626192018.14DE0F8A7@mail.blueline.mg>

on Fri, 20 Jun 2008 08:47:26 +0400
Georgij Kondratjev wrote:

>On Friday 20 June 2008 06:04:44 Benjamin Peterson wrote:
>> On Thu, Jun 19, 2008 at 8:18 PM, nirinA raseliarison
>>
>> <nirina at mail.blueline.mg> wrote:
>> > hello all,
>> > i tried to build Python3.0b1 but the make process hangs
>> > while running:
>>
>> Building with gcc 4.3 is buggy. See
>> http://mail.python.org/pipermail/python-3000/2008-April/012965.html.
>
>Only with gcc 4.3.0. The problem was fixed in 4.3.1.
>If you really want to compile python with gcc 4.3.0,
>do something like
>export CC="gcc $CFLAGS -fno-tree-vrp"

i checked and yes it succeeded. i'd already tried to pass
this option through configure, but it didn't compile. maybe
i did something wrong. i switched to 4.3.1 now and didn't
verify any further with 4.3.0.

thanks,

nirinA

--


From nirina at mail.blueline.mg  Thu Jun 26 21:31:54 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Thu, 26 Jun 2008 22:31:54 +0300 (EAT)
Subject: [Python-3000] about bytes
Message-ID: <20080626193154.AC303F8A4@mail.blueline.mg>

why the following behavior:

    >>> b=b'thisisbytes'
    >>> b[0] == b't'
    False
    >>> b[0]
    116

i expected same thing as:

    >>> b.startswith(b't')
    True
    >>> b[0:1] == b't'
    True
    >>> b[0:1]
    b't'
    >>> b[:1]
    b't'

and this is a bit curious:

    >>> b[2:5]
    b'isi'
    >>> for i in b[2:5]:
        print(i)

    105
    115
    105

problems occur when filename is in bytes.

    >>> os.listdir('/usr/doc/kbd-1.08/utf')
    ['README', 'ethiopic', b'??????',
     'utfdemo', 'utflist']

os.stat for example works:

    >>> os.stat(b'/usr/doc/kbd-1.08/utf/??????')
    posix.stat_result(st_mode=33188, st_ino=1376259,
    st_dev=5633, st_nlink=1, st_uid=0, st_gid=0, st_size=295,
    st_atime=1211305274, st_mtime=1034334536, st_ctime=1190763635)

but other functions don't. especially os.path.join and os.walk complain:

    >>> w=os.walk('/usr/doc/kbd-1.08/utf/')
    >>> next(w)
    Traceback (most recent call last):
      File "<pyshell#36>", line 1, in <module>
        next(w)
      File "/root/Py3kb1/lib/python3.0/os.py", line 268, in walk
        if isdir(join(top, name)):
      File "/root/Py3kb1/lib/python3.0/posixpath.py", line 64, in join
        if b.startswith('/'):
    TypeError: expected an object with the buffer interface

and trying to open the file:

    >>> f=open('??????')
    Traceback (most recent call last):
      File "<pyshell#77>", line 1, in <module>
        f=open('??????')
      File "/root/Py3kb1/lib/python3.0/io.py", line 280, in __new__
        return open(*args, **kwargs)
      File "/root/Py3kb1/lib/python3.0/io.py", line 219, in open
        closefd)
    UnicodeEncodeError: 'ascii' codec can't encode characters in
    position 0-5: ordinal not in range(128)

    >>> f=open(b'??????')
    Traceback (most recent call last):
      File "<pyshell#78>", line 1, in <module>
        f=open(b'??????')
      File "/root/Py3kb1/lib/python3.0/io.py", line 280, in __new__
        return open(*args, **kwargs)
      File "/root/Py3kb1/lib/python3.0/io.py", line 180, in open
        raise TypeError("invalid file: %r" % file)
    TypeError: invalid file: b'??????'

so, how do you deal with bytes in these cases?

nirinA

--


From martin at v.loewis.de  Thu Jun 26 21:49:43 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 26 Jun 2008 21:49:43 +0200
Subject: [Python-3000] about bytes
In-Reply-To: <20080626193154.AC303F8A4@mail.blueline.mg>
References: <20080626193154.AC303F8A4@mail.blueline.mg>
Message-ID: <4863F2D7.4040701@v.loewis.de>

> so, how do you deal with bytes in these cases?

Set your locale correctly so that the filename is properly decoded
as a string. Then, bytes will not show up.

Regards,
Martin

From g.brandl at gmx.net  Thu Jun 26 22:23:38 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 26 Jun 2008 22:23:38 +0200
Subject: [Python-3000] about bytes
In-Reply-To: <20080626193154.AC303F8A4@mail.blueline.mg>
References: <20080626193154.AC303F8A4@mail.blueline.mg>
Message-ID: <g40tm0$jf1$1@ger.gmane.org>

nirinA raseliarison schrieb:
> why the following behavior:
> 
>     >>> b=b'thisisbytes'
>     >>> b[0] == b't'
>     False
>     >>> b[0]
>     116
> 
> i expected same thing as:
> 
>     >>> b.startswith(b't')
>     True
>     >>> b[0:1] == b't'
>     True
>     >>> b[0:1]
>     b't'
>     >>> b[:1]
>     b't'
> 
> and this is a bit curious:
> 
>     >>> b[2:5]
>     b'isi'
>     >>> for i in b[2:5]:
>         print(i)
> 
>     105
>     115
>     105

Yes. Bytes objects are sequences of bytes, which are integers.
So, in short, this is the way they work.

Georg


From facundobatista at gmail.com  Fri Jun 27 14:16:37 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 27 Jun 2008 09:16:37 -0300
Subject: [Python-3000] about bytes
In-Reply-To: <g40tm0$jf1$1@ger.gmane.org>
References: <20080626193154.AC303F8A4@mail.blueline.mg>
	<g40tm0$jf1$1@ger.gmane.org>
Message-ID: <e04bdf310806270516h182e0a8tfa395ee1b25b1dae@mail.gmail.com>

2008/6/26 Georg Brandl <g.brandl at gmx.net>:

> Yes. Bytes objects are sequences of bytes, which are integers.
> So, in short, this is the way they work.

I think that the OP confusion comes from the representation.

We have a data type called bytes. They are sequences of bytes. So, I build one:

>>> b = bytes((72, 105))


Then I check:

>>> b[0]
72
>>> b[1]
105


Great! But:

>>> b
b'Hi'


Why I see two letters? Wasn't them bytes? :o

I know that is great to represent bytes between 32 and 127 as letters,
and this has several compatibility details, but I think that the
surprise comes from that place.

If the behaviour were the following....

>>> b
b((72, 105))

...it would be less surprising.

Regards,

-- 
. Facundo

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

From guido at python.org  Fri Jun 27 20:08:21 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 27 Jun 2008 11:08:21 -0700
Subject: [Python-3000] about bytes
In-Reply-To: <e04bdf310806270516h182e0a8tfa395ee1b25b1dae@mail.gmail.com>
References: <20080626193154.AC303F8A4@mail.blueline.mg>
	<g40tm0$jf1$1@ger.gmane.org>
	<e04bdf310806270516h182e0a8tfa395ee1b25b1dae@mail.gmail.com>
Message-ID: <ca471dc20806271108j16390f13l792faf126f0ac76b@mail.gmail.com>

On Fri, Jun 27, 2008 at 5:16 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> 2008/6/26 Georg Brandl <g.brandl at gmx.net>:
>
>> Yes. Bytes objects are sequences of bytes, which are integers.
>> So, in short, this is the way they work.
>
> I think that the OP confusion comes from the representation.
>
> We have a data type called bytes. They are sequences of bytes. So, I build one:
>
>>>> b = bytes((72, 105))
>
>
> Then I check:
>
>>>> b[0]
> 72
>>>> b[1]
> 105
>
>
> Great! But:
>
>>>> b
> b'Hi'
>
>
> Why I see two letters? Wasn't them bytes? :o
>
> I know that is great to represent bytes between 32 and 127 as letters,
> and this has several compatibility details, but I think that the
> surprise comes from that place.
>
> If the behaviour were the following....
>
>>>> b
> b((72, 105))
>
> ...it would be less surprising.

Only if you didn't know that b'' is an alternative to bytes(). The b''
notation is so much more compact and so  much more helpful that I
really don't want to go back to it. We will somehow have to deal with
this through education and documentation.

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

From facundobatista at gmail.com  Fri Jun 27 20:11:10 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 27 Jun 2008 15:11:10 -0300
Subject: [Python-3000] about bytes
In-Reply-To: <ca471dc20806271108j16390f13l792faf126f0ac76b@mail.gmail.com>
References: <20080626193154.AC303F8A4@mail.blueline.mg>
	<g40tm0$jf1$1@ger.gmane.org>
	<e04bdf310806270516h182e0a8tfa395ee1b25b1dae@mail.gmail.com>
	<ca471dc20806271108j16390f13l792faf126f0ac76b@mail.gmail.com>
Message-ID: <e04bdf310806271111x5cc7d61kd83f8c8756df2285@mail.gmail.com>

2008/6/27 Guido van Rossum <guido at python.org>:

> Only if you didn't know that b'' is an alternative to bytes(). The b''
> notation is so much more compact and so  much more helpful that I
> really don't want to go back to it. We will somehow have to deal with
> this through education and documentation.

+1

-- 
. Facundo

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

From solipsis at pitrou.net  Fri Jun 27 21:19:59 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 27 Jun 2008 19:19:59 +0000 (UTC)
Subject: [Python-3000] PEP 3134 exception reporting
References: <loom.20080621T221035-434@post.gmane.org>
Message-ID: <loom.20080627T191406-431@post.gmane.org>


Hi,

I've submitted a final patch with the following variations:
 - no additions or changes to public APIs
 - tracebacks are standardized as suggested by Georg Brandl
 - reference cycles along the __context__ chain are broken in PyErr_SetObject
(it is an O(n) linear search but should show almost zero overhead in the 
common case where context chains are trivially short)

Regards

Antoine.



From tjreedy at udel.edu  Fri Jun 27 21:50:31 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 27 Jun 2008 15:50:31 -0400
Subject: [Python-3000] about bytes
In-Reply-To: <ca471dc20806271108j16390f13l792faf126f0ac76b@mail.gmail.com>
References: <20080626193154.AC303F8A4@mail.blueline.mg>	<g40tm0$jf1$1@ger.gmane.org>	<e04bdf310806270516h182e0a8tfa395ee1b25b1dae@mail.gmail.com>
	<ca471dc20806271108j16390f13l792faf126f0ac76b@mail.gmail.com>
Message-ID: <g43ga6$qmf$1@ger.gmane.org>

> Only if you didn't know that b'' is an alternative to bytes(). The b''
> notation is so much more compact and so  much more helpful that I
> really don't want to go back to it. We will somehow have to deal with
> this through education and documentation.

http://bugs.python.org/issue3220
Improve Bytes and Byte Array Methods doc

makes several suggestions.  For the issue here, I suggested (at the 
bottom) adding

"Just as a bytes objects can be constructed either with a literal or a 
class constructor call, they could be represented on output either by a 
literal or class constructor call.  The literal was chosen as being 
shorter, generally more useful, and consistent with how other classes 
are displayed.  Similarly, the display of bytearrays uses the 
corresponding bytes literal.  If you want to see the bytes of either 
class as integers, use tuple.

 >>> a, b = b'abc', bytes((1,2,3))
 >>> a,b
(b'abc', b'\x01\x02\x03')
 >>> tuple(a), tuple(b)
((97, 98, 99), (1, 2, 3))
 >>> c = bytearray(a)
 >>> c, tuple(c)
(bytearray(b'abc'), (97, 98, 99))
"

I am assuming that there is no .to_int method that I missed.

Terry Jan Reedy


From musiccomposition at gmail.com  Sat Jun 28 15:46:46 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 28 Jun 2008 08:46:46 -0500
Subject: [Python-3000] PyBytes_FromObject
Message-ID: <1afaf6160806280646w43258693j74f7966b135702fc@mail.gmail.com>

It seems PyBytes is missing the parallel call for
PyByteArray_FromObject. Should I add it?

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

From guido at python.org  Sat Jun 28 17:33:40 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 28 Jun 2008 08:33:40 -0700
Subject: [Python-3000] PyBytes_FromObject
In-Reply-To: <1afaf6160806280646w43258693j74f7966b135702fc@mail.gmail.com>
References: <1afaf6160806280646w43258693j74f7966b135702fc@mail.gmail.com>
Message-ID: <ca471dc20806280833v632d745bk6b83ace6e3f4ab92@mail.gmail.com>

Seems to make sense. Do you see many places where it would make
existing code shorter?

On Sat, Jun 28, 2008 at 6:46 AM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> It seems PyBytes is missing the parallel call for
> PyByteArray_FromObject. Should I add it?

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

From musiccomposition at gmail.com  Sat Jun 28 17:47:37 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 28 Jun 2008 10:47:37 -0500
Subject: [Python-3000] PyBytes_FromObject
In-Reply-To: <ca471dc20806280833v632d745bk6b83ace6e3f4ab92@mail.gmail.com>
References: <1afaf6160806280646w43258693j74f7966b135702fc@mail.gmail.com>
	<ca471dc20806280833v632d745bk6b83ace6e3f4ab92@mail.gmail.com>
Message-ID: <1afaf6160806280847u2b8d6e10yc75690487e202b16@mail.gmail.com>

On Sat, Jun 28, 2008 at 10:33 AM, Guido van Rossum <guido at python.org> wrote:
> Seems to make sense. Do you see many places where it would make
> existing code shorter?

It's a good way to convert a bytearray to bytes.


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

From guido at python.org  Sat Jun 28 18:38:05 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 28 Jun 2008 09:38:05 -0700
Subject: [Python-3000] PyBytes_FromObject
In-Reply-To: <1afaf6160806280847u2b8d6e10yc75690487e202b16@mail.gmail.com>
References: <1afaf6160806280646w43258693j74f7966b135702fc@mail.gmail.com>
	<ca471dc20806280833v632d745bk6b83ace6e3f4ab92@mail.gmail.com>
	<1afaf6160806280847u2b8d6e10yc75690487e202b16@mail.gmail.com>
Message-ID: <ca471dc20806280938j1a3c0e2fnf6951ead167ada07@mail.gmail.com>

On Sat, Jun 28, 2008 at 8:47 AM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> On Sat, Jun 28, 2008 at 10:33 AM, Guido van Rossum <guido at python.org> wrote:
>> Seems to make sense. Do you see many places where it would make
>> existing code shorter?
>
> It's a good way to convert a bytearray to bytes.

And how many places have you found where this is used?

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

From brett at python.org  Sat Jun 28 20:30:31 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 28 Jun 2008 11:30:31 -0700
Subject: [Python-3000] PyBytes_FromObject
In-Reply-To: <ca471dc20806280833v632d745bk6b83ace6e3f4ab92@mail.gmail.com>
References: <1afaf6160806280646w43258693j74f7966b135702fc@mail.gmail.com>
	<ca471dc20806280833v632d745bk6b83ace6e3f4ab92@mail.gmail.com>
Message-ID: <bbaeab100806281130h65c287d2wd25211a6fe303930@mail.gmail.com>

On Sat, Jun 28, 2008 at 8:33 AM, Guido van Rossum <guido at python.org> wrote:
> Seems to make sense. Do you see many places where it would make
> existing code shorter?
>

If it could be used to get the bytes from a file object, then
marshal.c could use it; the code calls the "read" method on file
objects and then has to check if it got a bytearray or bytes instance
in order to get the raw string to do its work. Otherwise the
conversion to bytes would help by eliminating the separate bytearray
check.

-Brett

> On Sat, Jun 28, 2008 at 6:46 AM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
>> It seems PyBytes is missing the parallel call for
>> PyByteArray_FromObject. Should I add it?
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> 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 solipsis at pitrou.net  Sat Jun 28 22:45:31 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 28 Jun 2008 20:45:31 +0000 (UTC)
Subject: [Python-3000] Regular expressions, py3k and unicode
Message-ID: <loom.20080628T203335-825@post.gmane.org>

Hello,

Several posters (including a certain GvR) in the bug tracker (*) have been
baffled by an apparent bug where the re.IGNORECASE flag didn't imply
case-insensitivity for non-ASCII characters. It turns out that, although the
pattern was a string object and although Py3k is supposed to be
unicode-friendly, you still need to supply the re.UNICODE flag if you want the
re module to use unicode-aware case-insensitive matching.

Wouldn't it be more natural that, at least when the pattern is a str object
rather a bytes object, the re.UNICODE be implied by default?

(*) http://bugs.python.org/issue2834


Another question in the same vein: is it normal that we can match a bytes object
with an str pattern and vice-versa?

 pat = re.compile('?', re.IGNORECASE | re.UNICODE)
 pat.match('?'.encode('latin1'))
 # gives <_sre.SRE_Match object at 0xb7c66c60>

 pat = re.compile('?'.encode('latin1'), re.IGNORECASE | re.UNICODE)
 pat.match('?')
 # gives <_sre.SRE_Match object at 0xb7c66c60>

Regards

Antoine.



From guido at python.org  Sun Jun 29 00:04:48 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 28 Jun 2008 15:04:48 -0700
Subject: [Python-3000] PyBytes_FromObject
In-Reply-To: <bbaeab100806281130h65c287d2wd25211a6fe303930@mail.gmail.com>
References: <1afaf6160806280646w43258693j74f7966b135702fc@mail.gmail.com>
	<ca471dc20806280833v632d745bk6b83ace6e3f4ab92@mail.gmail.com>
	<bbaeab100806281130h65c287d2wd25211a6fe303930@mail.gmail.com>
Message-ID: <ca471dc20806281504u3aaffd6dp2b73b18a6a483084@mail.gmail.com>

On Sat, Jun 28, 2008 at 11:30 AM, Brett Cannon <brett at python.org> wrote:
> On Sat, Jun 28, 2008 at 8:33 AM, Guido van Rossum <guido at python.org> wrote:
>> Seems to make sense. Do you see many places where it would make
>> existing code shorter?

> If it could be used to get the bytes from a file object, then
> marshal.c could use it; the code calls the "read" method on file
> objects and then has to check if it got a bytearray or bytes instance
> in order to get the raw string to do its work. Otherwise the
> conversion to bytes would help by eliminating the separate bytearray
> check.

Hm, that sounds like a novelty -- I don't think the corresponding
PyString or PyUnicode (or PyBytesArray) functions do anything remotely
that clever...

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

From musiccomposition at gmail.com  Sun Jun 29 00:06:31 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 28 Jun 2008 17:06:31 -0500
Subject: [Python-3000] PyBytes_FromObject
In-Reply-To: <ca471dc20806280938j1a3c0e2fnf6951ead167ada07@mail.gmail.com>
References: <1afaf6160806280646w43258693j74f7966b135702fc@mail.gmail.com>
	<ca471dc20806280833v632d745bk6b83ace6e3f4ab92@mail.gmail.com>
	<1afaf6160806280847u2b8d6e10yc75690487e202b16@mail.gmail.com>
	<ca471dc20806280938j1a3c0e2fnf6951ead167ada07@mail.gmail.com>
Message-ID: <1afaf6160806281506y47e713aeg613464271b2dc409@mail.gmail.com>

On Sat, Jun 28, 2008 at 11:38 AM, Guido van Rossum <guido at python.org> wrote:
> On Sat, Jun 28, 2008 at 8:47 AM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
>> On Sat, Jun 28, 2008 at 10:33 AM, Guido van Rossum <guido at python.org> wrote:
>>> Seems to make sense. Do you see many places where it would make
>>> existing code shorter?
>>
>> It's a good way to convert a bytearray to bytes.
>
> And how many places have you found where this is used?

I only see it (PyByteArray_FromObject) used 2 times outside
bytearrayobject.c: memoryview.c and marshal.c.

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

From guido at python.org  Sun Jun 29 00:16:39 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 28 Jun 2008 15:16:39 -0700
Subject: [Python-3000] Regular expressions, py3k and unicode
In-Reply-To: <loom.20080628T203335-825@post.gmane.org>
References: <loom.20080628T203335-825@post.gmane.org>
Message-ID: <ca471dc20806281516w242ba09bh9e5e506580baef6a@mail.gmail.com>

On Sat, Jun 28, 2008 at 1:45 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Several posters (including a certain GvR) in the bug tracker (*) have been
> baffled by an apparent bug where the re.IGNORECASE flag didn't imply
> case-insensitivity for non-ASCII characters. It turns out that, although the
> pattern was a string object and although Py3k is supposed to be
> unicode-friendly, you still need to supply the re.UNICODE flag if you want the
> re module to use unicode-aware case-insensitive matching.
>
> Wouldn't it be more natural that, at least when the pattern is a str object
> rather a bytes object, the re.UNICODE be implied by default?

+1

> (*) http://bugs.python.org/issue2834
>
>
> Another question in the same vein: is it normal that we can match a bytes object
> with an str pattern and vice-versa?
>
>  pat = re.compile('?', re.IGNORECASE | re.UNICODE)
>  pat.match('?'.encode('latin1'))
>  # gives <_sre.SRE_Match object at 0xb7c66c60>
>
>  pat = re.compile('?'.encode('latin1'), re.IGNORECASE | re.UNICODE)
>  pat.match('?')
>  # gives <_sre.SRE_Match object at 0xb7c66c60>

This made sense in 2.x where text could be represented by str or
unicode. It makes a lot less sense now, and I suspect it can cause
widespread confusion. Forbidding this would also be another step in
the direction we're already taking of never allowing implicit
conversion between str and bytes.

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

From tjreedy at udel.edu  Sun Jun 29 02:00:36 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 28 Jun 2008 20:00:36 -0400
Subject: [Python-3000] Regular expressions, py3k and unicode
In-Reply-To: <ca471dc20806281516w242ba09bh9e5e506580baef6a@mail.gmail.com>
References: <loom.20080628T203335-825@post.gmane.org>
	<ca471dc20806281516w242ba09bh9e5e506580baef6a@mail.gmail.com>
Message-ID: <g46jav$3jp$1@ger.gmane.org>



Guido van Rossum wrote:
> On Sat, Jun 28, 2008 at 1:45 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Several posters (including a certain GvR) in the bug tracker (*) have been
>> baffled by an apparent bug where the re.IGNORECASE flag didn't imply
>> case-insensitivity for non-ASCII characters. It turns out that, although the
>> pattern was a string object and although Py3k is supposed to be
>> unicode-friendly, you still need to supply the re.UNICODE flag if you want the
>> re module to use unicode-aware case-insensitive matching.
>>
>> Wouldn't it be more natural that, at least when the pattern is a str object
>> rather a bytes object, the re.UNICODE be implied by default?
> 
> +1

Would there be any reason (I do not know) to replace that with an 
re.ASCII flag to have the reverse effect (assuming there is not now)?


From ncoghlan at gmail.com  Sun Jun 29 06:39:57 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 29 Jun 2008 14:39:57 +1000
Subject: [Python-3000] Regular expressions, py3k and unicode
In-Reply-To: <g46jav$3jp$1@ger.gmane.org>
References: <loom.20080628T203335-825@post.gmane.org>	<ca471dc20806281516w242ba09bh9e5e506580baef6a@mail.gmail.com>
	<g46jav$3jp$1@ger.gmane.org>
Message-ID: <4867121D.906@gmail.com>

Terry Reedy wrote:
> 
> 
> Guido van Rossum wrote:
>> On Sat, Jun 28, 2008 at 1:45 PM, Antoine Pitrou <solipsis at pitrou.net> 
>> wrote:
>>> Wouldn't it be more natural that, at least when the pattern is a str 
>>> object
>>> rather a bytes object, the re.UNICODE be implied by default?
>>
>> +1
> 
> Would there be any reason (I do not know) to replace that with an 
> re.ASCII flag to have the reverse effect (assuming there is not now)?

I'd be inclined to have it implied by the type of the argument - a str 
argument implies re.UNICODE is set, a bytes or bytearray argument 
implies it isn't. Users could still set it explicitly to have it apply 
in the latter case.

Cheers,
Nick.

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

From solipsis at pitrou.net  Sun Jun 29 12:08:42 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 29 Jun 2008 10:08:42 +0000 (UTC)
Subject: [Python-3000] Regular expressions, py3k and unicode
References: <loom.20080628T203335-825@post.gmane.org>	<ca471dc20806281516w242ba09bh9e5e506580baef6a@mail.gmail.com>
	<g46jav$3jp$1@ger.gmane.org> <4867121D.906@gmail.com>
Message-ID: <loom.20080629T100618-612@post.gmane.org>

Nick Coghlan <ncoghlan <at> gmail.com> writes:
> > Would there be any reason (I do not know) to replace that with an 
> > re.ASCII flag to have the reverse effect (assuming there is not now)?
> 
> I'd be inclined to have it implied by the type of the argument - a str 
> argument implies re.UNICODE is set, a bytes or bytearray argument 
> implies it isn't. Users could still set it explicitly to have it apply 
> in the latter case.

Setting a hypothetical re.ASCII flag with a str pattern can have a sense, but
setting re.UNICODE with a bytes pattern doesn't have any (assuming we forbid
matching of bytes patterns with str objects and vice-versa).



From dickinsm at gmail.com  Sun Jun 29 13:05:27 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sun, 29 Jun 2008 12:05:27 +0100
Subject: [Python-3000] Regular expressions, py3k and unicode
In-Reply-To: <loom.20080628T203335-825@post.gmane.org>
References: <loom.20080628T203335-825@post.gmane.org>
Message-ID: <5c6f2a5d0806290405v317bba51we12102b0c51a94f5@mail.gmail.com>

On Sat, Jun 28, 2008 at 9:45 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Wouldn't it be more natural that, at least when the pattern is a str object
> rather a bytes object, the re.UNICODE be implied by default?

Might this have some unintended consequences?  For example, one
would then get the following undesirable behaviour from the decimal
module, using inputs with Unicode fullwidth digits.

>>> Decimal('\uff11')
Decimal('?')
>>> Decimal('\uff11') == Decimal('1')
False

There are plenty of easy fixes for this, of course, but I don't know
how many other modules might be similarly affected.

In any case, it seems to me that having something like re.ASCII
would be useful.

Mark

From solipsis at pitrou.net  Sun Jun 29 13:36:04 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 29 Jun 2008 13:36:04 +0200
Subject: [Python-3000] Regular expressions, py3k and unicode
In-Reply-To: <5c6f2a5d0806290405v317bba51we12102b0c51a94f5@mail.gmail.com>
References: <loom.20080628T203335-825@post.gmane.org>
	<5c6f2a5d0806290405v317bba51we12102b0c51a94f5@mail.gmail.com>
Message-ID: <1214739364.6020.6.camel@fsol>

Le dimanche 29 juin 2008 ? 12:05 +0100, Mark Dickinson a ?crit :
> Might this have some unintended consequences?  For example, one
> would then get the following undesirable behaviour from the decimal
> module, using inputs with Unicode fullwidth digits.
> 
> >>> Decimal('\uff11')
> Decimal('?')
> >>> Decimal('\uff11') == Decimal('1')
> False

Indeed. On the other hand it already works properly for ints and floats,
so perhaps Decimal shouldn't refuse unicode digits like it currently
does:

>>> int('\uff11')
1
>>> int('\uff11') == 1
True
>>> float('\uff11')
1.0
>>> float('\uff11') == 1.0
True
>>> decimal.Decimal('\uff11')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/py_setref/Lib/decimal.py", line 545, in __new__
"Invalid literal for Decimal: %r" % value)
  File "/home/antoine/py3k/py_setref/Lib/decimal.py", line 3766, in _raise_error
raise error(explanation)
decimal.InvalidOperation: Invalid literal for Decimal: '?'


On a sidenote, it seems int objects constructed from strings don't use
the interned smallint constants, I will file a bug for it:

>>> 1+1 is 2
True
>>> int('2') is 2
False




From nirina at mail.blueline.mg  Sun Jun 29 14:10:07 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Sun, 29 Jun 2008 15:10:07 +0300 (EAT)
Subject: [Python-3000] xrange is still present in idlelib/EditorWindow.py
Message-ID: <20080629121007.8B531F856@mail.blueline.mg>

Exception in Tkinter callback
Traceback (most recent call last):
  File "/root/Py3kb1/lib/python3.0/tkinter/__init__.py", line 1409,
  in __call__
    return self.func(*args)
  File "/root/Py3kb1/lib/python3.0/idlelib/MultiCall.py", line 165,
  in handler
    r = l[i](event)
  File "/root/Py3kb1/lib/python3.0/idlelib/EditorWindow.py", line 292,
  in home_callback
    for insertpt in xrange(len(line)):
NameError: global name 'xrange' is not defined

nirinA

--


From dickinsm at gmail.com  Sun Jun 29 14:56:33 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sun, 29 Jun 2008 13:56:33 +0100
Subject: [Python-3000] Regular expressions, py3k and unicode
In-Reply-To: <1214739364.6020.6.camel@fsol>
References: <loom.20080628T203335-825@post.gmane.org>
	<5c6f2a5d0806290405v317bba51we12102b0c51a94f5@mail.gmail.com>
	<1214739364.6020.6.camel@fsol>
Message-ID: <5c6f2a5d0806290556u2d75e268ndc24138c73564d4d@mail.gmail.com>

On Sun, Jun 29, 2008 at 12:36 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Indeed. On the other hand it already works properly for ints and floats,
> so perhaps Decimal shouldn't refuse unicode digits like it currently
> does:

Maybe.  The IBM standard doesn't seem to say whether other Unicode
digits should be accepted or not.

Is there a quick way to convert a general Unicode digit to its
ascii equivalent?  Having to run str(int(c)) on each numeric character
sounds painful, and the Decimal constructor doesn't need to
be any slower right now.

In any case, this potential problem with decimal has now been
identified, and is easy to deal with.  I'm more worried, perhaps
needlessly, about what other unidentified problems might be
lurking deep in the standard library.  Any use of '\d', '\w', '\s', etc.
might potentially be a problem.

Mark

From solipsis at pitrou.net  Sun Jun 29 16:15:14 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 29 Jun 2008 14:15:14 +0000 (UTC)
Subject: [Python-3000] Regular expressions, py3k and unicode
References: <loom.20080628T203335-825@post.gmane.org>
	<5c6f2a5d0806290405v317bba51we12102b0c51a94f5@mail.gmail.com>
	<1214739364.6020.6.camel@fsol>
	<5c6f2a5d0806290556u2d75e268ndc24138c73564d4d@mail.gmail.com>
Message-ID: <loom.20080629T140930-13@post.gmane.org>

Mark Dickinson <dickinsm <at> gmail.com> writes:
> 
> Is there a quick way to convert a general Unicode digit to its
> ascii equivalent?  Having to run str(int(c)) on each numeric character
> sounds painful, and the Decimal constructor doesn't need to
> be any slower right now.

In C it looks like PyUnicode_EncodeDecimal() does the trick (it's used by float
and int conversion functions). What is the status of C-accelerated Decimal?

In plain Python I don't know, perhaps you could keep the fast path for ASCII
strings and have a slow fallback for unicode digits. Or suggest exporting the
above C function as a str method.
(or perhaps, simply, just disallow non-ASCII digits by using [0-9] instead of
\d. I'm not sure anybody really cares)

> I'm more worried, perhaps
> needlessly, about what other unidentified problems might be
> lurking deep in the standard library.  Any use of '\d', '\w', '\s', etc.
> might potentially be a problem.

Yes, we should do a scan of the standard library for this kind of pattern and
try to find out where there might be a problem.




From tjreedy at udel.edu  Sun Jun 29 20:21:04 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 29 Jun 2008 14:21:04 -0400
Subject: [Python-3000] xrange is still present in idlelib/EditorWindow.py
In-Reply-To: <20080629121007.8B531F856@mail.blueline.mg>
References: <20080629121007.8B531F856@mail.blueline.mg>
Message-ID: <g48jqc$bfr$1@ger.gmane.org>



nirinA raseliarison wrote:
> Exception in Tkinter callback
> Traceback (most recent call last):
>   File "/root/Py3kb1/lib/python3.0/tkinter/__init__.py", line 1409,
>   in __call__
>     return self.func(*args)
>   File "/root/Py3kb1/lib/python3.0/idlelib/MultiCall.py", line 165,
>   in handler
>     r = l[i](event)
>   File "/root/Py3kb1/lib/python3.0/idlelib/EditorWindow.py", line 292,
>   in home_callback
>     for insertpt in xrange(len(line)):
> NameError: global name 'xrange' is not defined

http://bugs.python.org/issue3237
Register and you can submit these yourself.


From tjreedy at udel.edu  Sun Jun 29 20:28:16 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 29 Jun 2008 14:28:16 -0400
Subject: [Python-3000] 2to3: update? doc?
Message-ID: <g48k7t$co9$1@ger.gmane.org>

WinXP 3.0
lib2to3 has grammar3.0.0.alpha.4.pickle
was nothing updated for the beta?
or did grammar3.0.0.beta.a.pickle only make 2.6b1?

I cannot find any doc in the libref (it would belong, I believe, in 
Development Tools).  Intentional? Not done yet?

tjr


From martin at v.loewis.de  Sun Jun 29 21:38:51 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 29 Jun 2008 21:38:51 +0200
Subject: [Python-3000] 2to3: update? doc?
In-Reply-To: <g48k7t$co9$1@ger.gmane.org>
References: <g48k7t$co9$1@ger.gmane.org>
Message-ID: <4867E4CB.1030502@v.loewis.de>

Terry Reedy wrote:
> WinXP 3.0
> lib2to3 has grammar3.0.0.alpha.4.pickle

What do you mean by "has"? What did you do, what happened,
what did you expect to happen instead?

The MSI file should have installed no .pickle files whatsoever.

> was nothing updated for the beta?
> or did grammar3.0.0.beta.a.pickle only make 2.6b1?
> 
> I cannot find any doc in the libref (it would belong, I believe, in
> Development Tools).  Intentional? Not done yet?

Why would you think this file deserves any mentioning in the
documentation at all?

Regards,
Martin

From solipsis at pitrou.net  Sun Jun 29 22:38:07 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 29 Jun 2008 20:38:07 +0000 (UTC)
Subject: [Python-3000] Regular expressions, py3k and unicode
References: <loom.20080628T203335-825@post.gmane.org>
	<5c6f2a5d0806290405v317bba51we12102b0c51a94f5@mail.gmail.com>
Message-ID: <loom.20080629T203659-812@post.gmane.org>

Mark Dickinson <dickinsm <at> gmail.com> writes:
> 
> In any case, it seems to me that having something like re.ASCII
> would be useful.

Should an inline flag "(?a)" also be introduced to mirror the existing "(?u)" to
set the unicode flag inside a pattern?




From solipsis at pitrou.net  Sun Jun 29 23:13:30 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 29 Jun 2008 21:13:30 +0000 (UTC)
Subject: [Python-3000] re.LOCALE
References: <loom.20080628T203335-825@post.gmane.org>
Message-ID: <loom.20080629T210105-692@post.gmane.org>


Another question, about re.LOCALE. Its utility is dubious, and it's never used
in the stdlib (apart from the re tests themselves). What should we do:
 - drop it entirely
 - only allow it on bytes patterns (it doesn't make sense on unicode strings)
 - leave it as-is
?



From tjreedy at udel.edu  Mon Jun 30 00:01:16 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 29 Jun 2008 18:01:16 -0400
Subject: [Python-3000] 2to3: update? doc?
In-Reply-To: <4867E4CB.1030502@v.loewis.de>
References: <g48k7t$co9$1@ger.gmane.org> <4867E4CB.1030502@v.loewis.de>
Message-ID: <g490n5$fa3$1@ger.gmane.org>



Martin v. L?wis wrote:
> Terry Reedy wrote:
>> WinXP 3.0
specifically .0b1
>> lib2to3 has grammar3.0.0.alpha.4.pickle
> 
> What do you mean by "has"?

The standard sense of 'directory has file'

Directory of C:\Program Files\Python30\Lib\lib2to3

06/19/2008  10:57 PM    <DIR>          .
06/19/2008  10:57 PM    <DIR>          ..
06/19/2008  01:03 PM             6,589 fixer_base.py
06/19/2008  01:03 PM            12,518 fixer_util.py
06/19/2008  10:57 PM    <DIR>          fixes
04/02/2008  12:53 PM             6,418 Grammar.txt
05/09/2008  05:07 PM            20,187 Grammar3.0.0.alpha.4.pickle
04/02/2008  12:53 PM             6,714 patcomp.py
04/02/2008  12:53 PM               821 PatternGrammar.txt
06/19/2008  10:57 PM    <DIR>          pgen2
04/02/2008  12:53 PM             1,017 pygram.py
05/08/2008  09:07 AM            25,573 pytree.py
06/19/2008  01:03 PM            22,345 refactor.py
06/19/2008  10:57 PM    <DIR>          tests
06/19/2008  01:03 PM                 8 __init__.py
               10 File(s)        102,190 bytes

> What did you do,
Nothing relevant

> what did you expect to happen instead?
To see Grammar3.0.0.beta.1.pickle or nothing like that at all.

> The MSI file should have installed no .pickle files whatsoever.
Well, there it is, timestamped early May ;-)

>> was nothing updated for the beta?
>> or did grammar3.0.0.beta.a.pickle only make 2.6b1?
>>
>> I cannot find any doc in the libref (it would belong, I believe, in
>> Development Tools).  Intentional? Not done yet?
> 
> Why would you think this file deserves any mentioning in the
> documentation at all?

'Doc' refers to documentation for (lib)2to3 (see subject line), not the 
surprising g...pickle.  I expected mention of the former because

1. All other modules and packages in Lib seem to be in the Lib. Ref..
2. 2to3 is for developer-users as well as core developers.
3. The lib2to3/refactor.py doc string says it is meant to be used.

tjr


From martin at v.loewis.de  Mon Jun 30 00:02:51 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 30 Jun 2008 00:02:51 +0200
Subject: [Python-3000] re.LOCALE
In-Reply-To: <loom.20080629T210105-692@post.gmane.org>
References: <loom.20080628T203335-825@post.gmane.org>
	<loom.20080629T210105-692@post.gmane.org>
Message-ID: <4868068B.9020705@v.loewis.de>

> Another question, about re.LOCALE. Its utility is dubious, and it's never used
> in the stdlib (apart from the re tests themselves). What should we do:
>  - drop it entirely
>  - only allow it on bytes patterns (it doesn't make sense on unicode strings)
>  - leave it as-is
> ?

I suggest to drop it.

Of course, the beta has been released, and such a change (just as the
addition of an ASCII flag) require release manager approval, IMO.

Regards,
Martin

From martin at v.loewis.de  Mon Jun 30 00:10:29 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 30 Jun 2008 00:10:29 +0200
Subject: [Python-3000] 2to3: update? doc?
In-Reply-To: <g490n5$fa3$1@ger.gmane.org>
References: <g48k7t$co9$1@ger.gmane.org> <4867E4CB.1030502@v.loewis.de>
	<g490n5$fa3$1@ger.gmane.org>
Message-ID: <48680855.9040508@v.loewis.de>

>> What did you do,
> Nothing relevant

You didn't even install Python? If so, how did the
files get into \Program Files\Python30?

I really need to know the exact sequence of actions
done to this folder. One possible explanation is that
you installed alpha4, then upgraded to beta1. Another
explanation is that you copied the Python files
yourself into this folder, from a subversion checkout.

>> what did you expect to happen instead?
> To see Grammar3.0.0.beta.1.pickle or nothing like that at all.

Grammar3.0.0.beta.1.pickle won't be created until you
use lib2to3, so it's not there in a fresh installation.

Why Grammar3.0.0.alpha.4.pickle is there, I cannot guess
(not knowing what precisely you did); it should not be there.

>>> I cannot find any doc in the libref (it would belong, I believe, in
>>> Development Tools).  Intentional? Not done yet?
>>
>> Why would you think this file deserves any mentioning in the
>> documentation at all?
> 
> 'Doc' refers to documentation for (lib)2to3 (see subject line), not the
> surprising g...pickle.  I expected mention of the former because

Ah, ok. lib2to3 should certainly be documented. Contributions are
welcome.

Regards,
Martin


From tjreedy at udel.edu  Mon Jun 30 05:40:14 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 29 Jun 2008 23:40:14 -0400
Subject: [Python-3000] 2to3: update? doc?
In-Reply-To: <48680855.9040508@v.loewis.de>
References: <g48k7t$co9$1@ger.gmane.org>
	<4867E4CB.1030502@v.loewis.de>	<g490n5$fa3$1@ger.gmane.org>
	<48680855.9040508@v.loewis.de>
Message-ID: <g49kin$kmv$1@ger.gmane.org>



Martin v. L?wis wrote:

> I really need to know the exact sequence of actions
> done to this folder. One possible explanation is that
> you installed alpha4, then upgraded to beta1.

.0a3 to .0a4 to .0b1.

I do not know how to run 2to3 and do not remember trying to do so.
pickle.load(...) failed saying that the underlying read failed to 
product bytes.  So I deleted it.  I regard it as an unaccounted for and 
possible obsolete glitch.

tjr



From guido at python.org  Mon Jun 30 17:32:46 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 30 Jun 2008 08:32:46 -0700
Subject: [Python-3000] 2to3: update? doc?
In-Reply-To: <g490n5$fa3$1@ger.gmane.org>
References: <g48k7t$co9$1@ger.gmane.org> <4867E4CB.1030502@v.loewis.de>
	<g490n5$fa3$1@ger.gmane.org>
Message-ID: <ca471dc20806300832n5f2acfdbq98bc98ec357a34e@mail.gmail.com>

Methinks that from this evidence it is clear that on 05/09/2008  at
05:07 PM you used 2to3 with Python alpha 4. The pickle is left behind
as an optimization by 2to3's own parser. It will be ignored when you
use it with a different Python version. It is correct that Grammar.txt
hasn't changed since April -- this is expected (the grammar changes
only when the grammar of the input language changes, and we haven't
changed that in a long time).

--Guido

On Sun, Jun 29, 2008 at 3:01 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>
>
> Martin v. L?wis wrote:
>>
>> Terry Reedy wrote:
>>>
>>> WinXP 3.0
>
> specifically .0b1
>>>
>>> lib2to3 has grammar3.0.0.alpha.4.pickle
>>
>> What do you mean by "has"?
>
> The standard sense of 'directory has file'
>
> Directory of C:\Program Files\Python30\Lib\lib2to3
>
> 06/19/2008  10:57 PM    <DIR>          .
> 06/19/2008  10:57 PM    <DIR>          ..
> 06/19/2008  01:03 PM             6,589 fixer_base.py
> 06/19/2008  01:03 PM            12,518 fixer_util.py
> 06/19/2008  10:57 PM    <DIR>          fixes
> 04/02/2008  12:53 PM             6,418 Grammar.txt
> 05/09/2008  05:07 PM            20,187 Grammar3.0.0.alpha.4.pickle
> 04/02/2008  12:53 PM             6,714 patcomp.py
> 04/02/2008  12:53 PM               821 PatternGrammar.txt
> 06/19/2008  10:57 PM    <DIR>          pgen2
> 04/02/2008  12:53 PM             1,017 pygram.py
> 05/08/2008  09:07 AM            25,573 pytree.py
> 06/19/2008  01:03 PM            22,345 refactor.py
> 06/19/2008  10:57 PM    <DIR>          tests
> 06/19/2008  01:03 PM                 8 __init__.py
>              10 File(s)        102,190 bytes
>
>> What did you do,
>
> Nothing relevant
>
>> what did you expect to happen instead?
>
> To see Grammar3.0.0.beta.1.pickle or nothing like that at all.
>
>> The MSI file should have installed no .pickle files whatsoever.
>
> Well, there it is, timestamped early May ;-)
>
>>> was nothing updated for the beta?
>>> or did grammar3.0.0.beta.a.pickle only make 2.6b1?
>>>
>>> I cannot find any doc in the libref (it would belong, I believe, in
>>> Development Tools).  Intentional? Not done yet?
>>
>> Why would you think this file deserves any mentioning in the
>> documentation at all?
>
> 'Doc' refers to documentation for (lib)2to3 (see subject line), not the
> surprising g...pickle.  I expected mention of the former because
>
> 1. All other modules and packages in Lib seem to be in the Lib. Ref..
> 2. 2to3 is for developer-users as well as core developers.
> 3. The lib2to3/refactor.py doc string says it is meant to be used.
>
> tjr
>
> _______________________________________________
> 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/guido%40python.org
>



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

From nirina at mail.blueline.mg  Mon Jun 30 19:30:25 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Mon, 30 Jun 2008 20:30:25 +0300 (EAT)
Subject: [Python-3000] xrange is still present in idlelib/EditorWindow.py
Message-ID: <20080630173025.87644F839@mail.blueline.mg>

on Sun, 29 Jun 2008 14:21:04 -0400
Terry Reedy wrote:

>http://bugs.python.org/issue3237
>Register and you can submit these yourself.

i'll do so next time.

thanks,

nirinA

--


From phd at phd.pp.ru  Mon Jun 30 20:10:44 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Mon, 30 Jun 2008 22:10:44 +0400
Subject: [Python-3000] re.LOCALE
In-Reply-To: <loom.20080629T210105-692@post.gmane.org>
References: <loom.20080628T203335-825@post.gmane.org>
	<loom.20080629T210105-692@post.gmane.org>
Message-ID: <20080630181044.GA14362@phd.pp.ru>

On Sun, Jun 29, 2008 at 09:13:30PM +0000, Antoine Pitrou wrote:
> 
> Another question, about re.LOCALE. Its utility is dubious, and it's never used
> in the stdlib (apart from the re tests themselves). What should we do:
>  - drop it entirely
>  - only allow it on bytes patterns (it doesn't make sense on unicode strings)

   Leave it for bytes patterns.

>  - leave it as-is
> ?

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

From eric+python-dev at trueblade.com  Mon Jun 30 20:36:32 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Mon, 30 Jun 2008 14:36:32 -0400
Subject: [Python-3000] PEP 3101 str.format() equivalent of '%#o/x/X'?
In-Reply-To: <ca471dc20805301237p4a30dd5du4f3ecb2771a967ca@mail.gmail.com>
References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4@mail.gmail.com>	
	<483EAF95.5050503@trueblade.com>	
	<3f4107910805291116w37af38e3qb2c5145539d7e23e@mail.gmail.com>	
	<483F06FF.9090007@trueblade.com>	
	<78b3a9580805291634t3ed65ab3x29bedc80be887f8@mail.gmail.com>	
	<483F4E3A.9090403@trueblade.com>	
	<ca471dc20805301209j67c3e2a5nf819297680cbf3fb@mail.gmail.com>	
	<48405420.8010800@trueblade.com>
	<ca471dc20805301237p4a30dd5du4f3ecb2771a967ca@mail.gmail.com>
Message-ID: <486927B0.60300@trueblade.com>

I finally have some cycles for this.  Is it okay to add '#' to hex, bin, 
and oct for str.format(), even though it's now after the beta?

Eric.

Guido van Rossum wrote:
> Of course.
> 
> On Fri, May 30, 2008 at 12:23 PM, Eric Smith
> <eric+python-dev at trueblade.com> wrote:
>> Guido van Rossum wrote:
>>> I'd be fine with adding '#' back to the formatting language for hex and
>>> oct.
>> And bin, I assume?
>>
>>> On Thu, May 29, 2008 at 5:45 PM, Eric Smith
>>> <eric+python-dev at trueblade.com> wrote:
>>>> wesley chun wrote:
>>>>> On 5/29/08, Eric Smith <eric+python-dev at trueblade.com> wrote:
>>>>>> Marcin 'Qrczak' Kowalczyk wrote:
>>>>>>> Except that it works incorrectly for negative numbers.
>>>>> wow, that is a great point.  i didn't think of this either. it makes
>>>>> it very inconvenient (see below) and makes it more difficult to say
>>>>> we've completed replaced the '%' operator.
>>>>>
>>>>>
>>>>>>  I can't really think of any other way that doesn't involve converting
>>>>>> the
>>>>>> number to a string and then operating on that, just to get the sign.
>>>>> here's one way of doing it without converting to a string first (it's
>>>>> ugly
>>>>> too):
>>>>>
>>>>>>>> i = -45
>>>>>>>> '{0}0x{1:x}'.format('-' if i < 0 else '', abs(i))
>>>>> '-0x2d'
>>>> Agreed, ick!
>>>>
>>>>> thx for putting it (back) in,
>>>> I didn't say I would, I said I would if a decision was reached :)  I'd
>>>> like
>>>> to see some more consensus, and I hope that Talin (the PEP author) chimes
>>>> in.
>>>>
>>>> Eric.
>>>>
>>>> _______________________________________________
>>>> 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/guido%40python.org
>>>>
>>>
>>>
>>
> 
> 
>